Qual é o objetivo de um limite de tamanho de sessão SMTP?

Question

Como servidor SMTP de recebimento, um tamanho máximo de mensagem faz sentido. Uma mensagem enorme ocupa espaço depois de ser recebida. Um disco cheio deixa os usuários infelizes.

Um número máximo de mensagens por remetente em um período fixo faz sentido, especialmente se combinado com outros indicadores de spam. O spam também deixa os usuários infelizes.

No momento, estou enviando e-mails por meio de um redirecionamento SMTP que tem um limite diferente de um desses: um tamanho máximo de sessão . É separado de qualquer limite no número de mensagens que podem ser aceitas ou no tamanho dessas mensagens.

Uma série de 1000 mensagens, cada uma com algumas centenas de KB, só será processada se a conexão TCP for fechada e reaberta até a metade. Se eles forem enviados em uma única conexão TCP, isso acontece:

552 4.3.1 Session size exceeds fixed maximum session size

(Há um relacionado pergunta que menciona a mesma mensagem de erro, mas ela apenas critica os limites do problema; minha pergunta é sobre decisões políticas, não sobre cálculos precisos do que se ajustará a um limite específico.)

Do ponto de vista do remetente, isso é um grande incômodo. Isso obriga você a dividir seus lotes de envio para se ajustar a um limite que você não pode sequer saber até que você o encontre.

Do ponto de vista do receptor, o que é ganho? Um remetente não é impedido de enviar para muitas mensagens ou mensagens muito grandes. Apenas é inconveniente enviar um número moderado de mensagens de tamanho médio. O uso de uma conexão TCP ou várias conexões TCP é algo que os usuários nunca podem conhecer.

Então, pergunta principal: o que estava acontecendo nas mentes dos implementadores quando eles inventaram o conceito de um limite de tamanho de sessão? E que motivo poderia ter um administrador de servidor para ativá-lo?

VOCÊ PODE PARAR A LEITURA AQUI, IGNORAR O DESCANSO E ENFRENTAR A PERGUNTA PRINCIPAL

Até agora, não nomeei nenhum nome, porque realmente quero alguma explicação da ideia fundamental aqui, e não uma solução inteligente para o cliente. Agora vou adicionar detalhes ...

O servidor e os clientes aqui estão sob o controle da mesma organização. Eu corro (alguns) os clientes, que são aplicativos da web do Adobe ColdFusion. A única coisa que posso fazer para influenciar o tamanho de uma sessão SMTP a partir desse fim seria desabilitar totalmente a reutilização da conexão. Então eu poderia ir para uma mensagem por conexão, mas então eu estaria fazendo uma tonelada de conexões, o que poderia ter algum outro limite (um mais justificável até mesmo).

O servidor é IIS (não é o Exchange, mencionado na outra pergunta). Ele se identifica assim:

220 sendmail.example Microsoft ESMTP MAIL Service, Version: 7.5.7601.17514 ready at  Wed, 1 Feb 2017 14:38:49 -0500

O problema é mais irritante do que você imagina ao ver a mensagem de erro, porque o IIS envia a resposta 552 e fecha a conexão imediatamente quando o limite de bytes é atingido, em vez de esperar por um ponto na conversa onde é a vez do servidor falar. Sendo interrompido no meio do envio de uma mensagem, o ColdFusion responde da maneira mais estúpida possível: registra a mensagem como enviada com sucesso. (Eu planejo um relatório de bug separado sobre isso.)

As mensagens desaparecem aleatoriamente com base em sua posição no fluxo TCP, e a única razão pela qual eu sei o que aconteceu é que eu finalmente percebi isso acontecendo com o Wireshark.

Eu quero pedir ao administrador do servidor SMTP para remover o limite de tamanho da sessão, pois isso não serve para nada e está acionando um bug desagradável que perde o e-mail. Portanto, a pergunta secundária: é possível no IIS remover o limite de tamanho da sessão sem também remover o limite de tamanho da mensagem? Tanto quanto eu posso dizer, esses dois limites atualmente têm o mesmo valor.

    

Answer 1

A partir das pequenas informações que vi da Microsoft, veja abaixo citação, eu acho que foi para evitar um loop quando um cliente de email enviar um email em uma sessão, o email é recusado durante a sessão e, em seguida, o cliente de email tentar enviar novamente . (fazendo assim um loop)

Select the Limit session size to (KB) check box, and then type a value to indicate the maximum total size (in kilobytes) of all messages in a given connection. This number will always be larger than the maximum message size and should be set carefully because the connecting message transfer agent (MTA) is likely to resubmit the message repeatedly. The default size is 10240 KB. This value should be greater than or equal to the value entered for Limit message size to (KB).

Do meu ponto de vista;

Eu vejo um uso para esse limite como se no exemplo eu comece a vender algum viagra, via e-mail "publicity", eu poderia direcionar um servidor de email e enviar muita "publicidade" em uma sessão antes do meu IP ser listado lista pública RBL, como o Exchange, verifique a conexão remota inicial. ( referência )

IP Block List Providers are part of the connection filtering feature in Exchange. When the IP Block List Providers feature is enabled on a computer, the Connection Filter agent queries the specified IP Block List provider services to determine if the messaging server that has initiated the connection is a host that is known to send spam.

Lembre-se também de que, se o seu servidor enviar um smarthost, como o servidor do ISP smtp, o ISP geralmente verifica e-mails enviados com a RBL para limitar o impacto do cliente na Internet se o cliente for infectado por um spambot.

Eu trago esse ponto como você pode procurar por estrangulamento de e-mail , pois muitos serviços grandes irão diminuir sua pontuação de reputação de IP se você enviar muitos e-mails para eles em um curto período.

Além disso, há uma interessante pergunta sobre um serviço da web que envia muitos emails.