-
A opção II está incorreta, como a comunicação é feita sobre protocolo tcp/ip (em que há garantia de entrega), se não conseguir realizar a entrega o retorno é um NACK, ou seja, não conseguiu entregar a mensagem ao servidor destinatário. A mensagem ficará armazenada no servidor caso não consiga entregar a mensagem.
-
"Se uma mensagem não puder ser entregue, um relatório de erros contendo a primeira parte da mensagem não entregue será retornado ao remetente."
Tanenbaum. Redes de Computadores. P. 401
-
"28.2 SMTP Protocol
The communication between the two MTAs uses NVT ASCII. Commands are sent by the client to the server, and the server responds with numeric reply codes and optional human-readable strings."
Stevens, TCP/IP Illustrated, Vol 1
-
Vandereli, o NACK no caso que você citou seria quando o servidor SMTP não recebesse o pacote TCP que contém o conteúdo do e-mail dentro do seu payload.
A opção II se refere ao servidor receber corretamente a mensagem e ao tentar colocar na caixa do fulano@dominio.com, por algum motivo não teve sucesso. A maioria dos servidores SMTP implementam uma resposta caso não consigam destinar o e-mail para o destinatário, entretanto, não é mandatório e por isso não há garantias.
-
SMTP: Realiza o envio de mensagens de e-mail, trabalhando nas portas 25 ou 587.
-
Errei por considerar a II errada. Sempre achei que a mensagem de erro/insucesso era sempre retornada em caso de falha.
Gabarito: E
-
O colega Alessandro Soncini tem razaão, sobre o item II.
O RFC 5321 define o comportamento de mensagens de notificação erro e já elenca possibilidade em que pode não ser possível enviar essa mensagem de notificação de erro, por isso o item II está correto, já que não há garantia.
"6. Problem Detection and Handling
6.1. Reliable Delivery and Replies by Email
...
If there is a delivery failure after acceptance of a message, the receiver-SMTP MUST formulate and mail a notification message. This notification MUST be sent using a null ("<>") reverse-path in the envelope. The recipient of this notification MUST be the address from the envelope return path (or the Return-Path: line). However, if this address is null ("<>"), the receiver-SMTP MUST NOT send a notification. Obviously, nothing in this section can or should prohibit local decisions (i.e., as part of the same system environment as the receiver-SMTP) to log or otherwise transmit information about null address events locally if that is desired. If the address is an explicit source route, it MUST be stripped down to its final hop."
Fonte: https://tools.ietf.org/html/rfc5321#section-6
-
Além da excelente citaçaõ do Alessandro, trago um trecho de [1];
"No exemplo, o servidor rejeita o destinatário Green, pois não reconhece o nome como um destino de correio válido (ou seja, Green nem é um usuário nem uma lista de correio). O protocolo SMTP não especifica os detalhes de como um cliente trata desses erros – ele mesmo precisa decidir. Embora os clientes possam abortar a entrega completamente se houver um erro, a maioria deles não faz isso. Ao contrário, eles continuam a entrega a todos os destinatários válidos e depois informam sobre problemas com o emissor original. Normalmente, o cliente informa erros usando o correio eletrônico. A mensagem de erro contém um resumo do erro, além do cabeçalho das mensagens de correio que causaram o problema".
Fonte:
[1] Douglas Comer