MTA manipulação de e-mails muito grandes

Question

Se um MTA receber um email que exceda o limite de tamanho da mensagem, qual o preferido de bevaviour? Qual é o padrão para servidores de e-mail comuns?

1. Rejeitar o email durante a sessão SMTP. O MTA de entrega deve enviar uma mensagem de devolução ao remetente original.
2. Aceite o e-mail e envie uma mensagem devolvida ao remetente original imediatamente.
3. Aceite o e-mail e envie uma mensagem devolvida ao remetente original após um tempo limite.

Eu vi um servidor fazer 3. e aguarde cinco dias antes de enviar a devolução. Parece-me que este comportamento não faz sentido, uma vez que o limite de tamanho da mensagem não é susceptível de mudar frequentemente. Um limite de tamanho de mensagem excedido não deve ser considerado imediatamente como um erro permanente?

    

Answer 1

RFC 1860 A Seção 6.1 (2) informa que, após o recebimento de uma mensagem de e-mail maior que o limite máximo de tamanho , o servidor de recebimento pode responder ao servidor de envio com um status SMTP de " 552 message size exceeds fixed maximium message size "

O MTA não é obrigado a responder à rejeição com um 522, mas esse é o método preferido (e esperado pela maioria dos MTAs e administradores de email).

O aviso de rejeição ao remetente é tratado pelo MTA dos remetentes e não deve ser um fator do seu MTA. Seu servidor enviando notificações de falha na entrega é um possível problema de spam (eu elaborei mensagens SMTP com MAIL FROM: [email protected] e você recebe todos os meus saltos porque o MTA de outra pessoa enviou a você NDRs)

Mas para responder diretamente à sua pergunta. # 1 é o único método que segue com todos os RFCs relacionados ao SMTP, bem como práticas geralmente aceitas e práticas de redução de spam.

    

Answer 2

Note que eu suspeito que o # 3 esteja acontecendo porque a caixa de correio está cheia, mas o sistema de recebimento acredita que pode estar vazio o suficiente para receber o email. Ele provavelmente envia de volta um erro 4xx (falha temporária) e o sistema de envio continua tentando por 5 dias, e então envia uma devolução para o usuário.

Além disso, como comentário adicional ao excelente resumo de Ruscal acima, há uma complicação em receber e-mails que você não pode enviar esse código de resposta no meio da sessão de DATA. Você tem que esperar até o final do marcador de dados (\ r \ n. \ R \ n) antes de poder enviá-lo. Isto significa que alguns sistemas podem apenas desconectar (após tentar enviar a resposta 522 de qualquer maneira) no ponto do e-mail sendo muito grande, para evitar ataques DoS do tamanho DATA. Isso não é comum, mas é uma fraqueza infeliz do sistema SMTP (antigo).

Se, no entanto, ambos os sistemas estiverem usando o ESMTP e suportarem o RFC 1653, isso poderá ser atenuado antes que os DATA sejam transmitidos.