easily undermine confidence in the reliability of the Internet's mail systems. So silent dropping of messages should be considered only in those cases where there is very high confidence that the messages are seriously fraudulent or otherwise inappropriate." Not validating the sender is an inherent flaw in today's SMTP, which is without the deprecated source routes mentioned earlier. This is addressed by various proposals, most directly by BATV and SPF. Causes of a bounce message There are many reasons why an email may bounce. One reason is if the recipient address is misspelled, or simply does not exist on the receiving system. This is a user unknown condition. Other reasons include resource exhaustion — such as a full disk — or the rejection of the message due to spam filters. In addition, there are MUAs that allow users to "bounce" a message on demand. These user-initiated bounces are bogus bounces; by definition, a real bounce is automated, and is emitted by a MTA or MDA. Bounce messages in SMTP are sent with the envelope sender address <>, known as the null sender address. They are frequently sent with a From: header address of MAILER-DAEMON at the recipient site. Typically, a bounce message will contain several pieces of information to help the original sender in understanding the reason his message was not delivered: The date and time the message was bounced, The identity of the mail server that bounced it, The reason that it was bounced (e.g. user unknown or mailbox full), The headers of the bounced message, and Some or all of the content of the bounced message. RFC 3463 describes the codes used to indicate the bounce reason. Common codes are 5.1.1 (Unknown user), 5.2.2 (Mailbox full) and 5.7.1 (Rejected by security policy/mail filter). Format The format for the reporting of administrative messages is defined by . A DSN may be a MIME multipart/report message composed of three parts: a human readable explanation; a machine parsable message/delivery-status, a list of "name: type; value" lines that state several possible fields; and the original message, or a portion thereof, as an entity of type message/rfc822. The second part of a DSN is also quite readable. It is essential to understand which MTA played which role. The Reporting-MTA is responsible for composing and sending the DSN. When a Remote-MTA rejects a message during an SMTP transaction, a field Diagnostic-Code of type smtp