Question
Here is a typical transaction log when sending email to an account at yahoo.com (20-Feb-02):
S: 220 YSmtp mta540.mail.yahoo.com ESMTP service ready C: EHLO mail.somewhere.com S: 250-mta540.mail.yahoo.com S: 250-8BITMIME S: 250-SIZE 10485760 S: 250 PIPELINING C: MAIL From:<>l C: RCPT To:<globalremove2000@yahoo.com> C: DATA S: 250 null sender <> ok S: 553 VS10-RT Possible forgery see http://help.yahoo.com/help/us/mail/spam/ spam-18.html (5.1.1)
In the GMS log, the following is reported immediately after the last message from the remote server:
ReadFromStream mx1.mail.yahoo.com 0 bytes (0) dropped by mx1.mail.yahoo.com
This transaction shows that GMS Mail or GMS Webmail attempted to send a message to the remote server. The remote server refused the message and then immediately dropped the connection.
Since the remote server refused the message, why didn’t GMS Mail or GMS Webmail return the message to the sender?
Answer
The internet standard for sending email messages (RFC2821 – which replaced RFC821) states that:
The receiver should not close the transmission channel until
it receives and replies to a QUIT command (even if there was
an error). The sender should not close the transmission
channel until it send a QUIT command and receives the reply
(even if there was an error response to a previous command).
If the connection is closed prematurely the receiver should
act as if a RSET command had been received (canceling any
pending transaction, but not undoing any previously
completed transaction), the sender should act as if the
command or transaction in progress had received a temporary
error (4xx).
In order to comply with the RFC, GMS Mail or GMS Webmail re-queues the message in order to attempt to resend it later.
Keywords:553 yahoo.com sending email return failure