Section 6. Problem Detection and Handling

6.1.  Reliable Delivery and Replies by Email
   When the receiver-SMTP accepts a piece of mail (by sending a "250 OK"
   message in response to DATA), it is accepting responsibility for
   delivering or relaying the message.  It must take this responsibility
   seriously.  It MUST NOT lose the message for frivolous reasons, such
   as because the host later crashes or because of a predictable
   resource shortage.  Some reasons that are not considered frivolous
   are discussed in the next subsection and in Section 7.8.
   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.
   For example, suppose that an error notification must be sent for a
   message that arrived with:
      MAIL FROM:<@a,@b:user@d>
   The notification message MUST be sent using:
      RCPT TO:<user@d>
   Some delivery failures after the message is accepted by SMTP will be
   unavoidable.  For example, it may be impossible for the receiving
   SMTP server to validate all the delivery addresses in RCPT command(s)
   due to a "soft" domain system error, because the target is a mailing
   list (see earlier discussion of RCPT), or because the server is
   acting as a relay and has no immediate access to the delivering
   system.
   To avoid receiving duplicate messages as the result of timeouts, a
   receiver-SMTP MUST seek to minimize the time required to respond to
   the final <CRLF>.<CRLF> end of data indicator.  See RFC 1047 [40] for
   a discussion of this problem.
6.2.  Unwanted, Unsolicited, and "Attack" Messages
   Utility and predictability of the Internet mail system requires that
   messages that can be delivered should be delivered, regardless of any
   syntax or other faults associated with those messages and regardless
   of their content.  If they cannot be delivered, and cannot be
   rejected by the SMTP server during the SMTP transaction, they should
   be "bounced" (returned with non-delivery notification messages) as
   described above.  In today's world, in which many SMTP server
   operators have discovered that the quantity of undesirable bulk email
   vastly exceeds the quantity of desired mail and in which accepting a
   message may trigger additional undesirable traffic by providing
   verification of the address, those principles may not be practical.
   As discussed in Section 7.8 and Section 7.9 below, dropping mail
   without notification of the sender is permitted in practice.
   However, it is extremely dangerous and violates a long tradition and
   community expectations that mail is either delivered or returned.  If
   silent message-dropping is misused, it could 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.
   To stretch the principle of delivery if possible even further, it may
   be a rational policy to not deliver mail that has an invalid return
   address, although the history of the network is that users are
   typically better served by delivering any message that can be
   delivered.  Reliably determining that a return address is invalid can
   be a difficult and time-consuming process, especially if the putative
   sending system is not directly accessible or does not fully and
   accurately support VRFY and, even if a "drop messages with invalid
   return addresses" policy is adopted, it SHOULD be applied only when
   there is near-certainty that the return addresses are, in fact,
   invalid.
   Conversely, if a message is rejected because it is found to contain
   hostile content (a decision that is outside the scope of an SMTP
   server as defined in this document), rejection ("bounce") messages
   SHOULD NOT be sent unless the receiving site is confident that those
   messages will be usefully delivered.  The preference and default in
   these cases is to avoid sending non-delivery messages when the
   incoming message is determined to contain hostile content.
6.3.  Loop Detection
   Simple counting of the number of "Received:" header fields in a
   message has proven to be an effective, although rarely optimal,
   method of detecting loops in mail systems.  SMTP servers using this
   technique SHOULD use a large rejection threshold, normally at least
   100 Received entries.  Whatever mechanisms are used, servers MUST
   contain provisions for detecting and stopping trivial loops.
6.4.  Compensating for Irregularities
   Unfortunately, variations, creative interpretations, and outright
   violations of Internet mail protocols do occur; some would suggest
   that they occur quite frequently.  The debate as to whether a well-
   behaved SMTP receiver or relay should reject a malformed message,
   attempt to pass it on unchanged, or attempt to repair it to increase
   the odds of successful delivery (or subsequent reply) began almost
   with the dawn of structured network mail and shows no signs of
   abating.  Advocates of rejection claim that attempted repairs are
   rarely completely adequate and that rejection of bad messages is the
   only way to get the offending software repaired.  Advocates of
   "repair" or "deliver no matter what" argue that users prefer that
   mail go through it if at all possible and that there are significant
   market pressures in that direction.  In practice, these market
   pressures may be more important to particular vendors than strict
   conformance to the standards, regardless of the preference of the
   actual developers.
   The problems associated with ill-formed messages were exacerbated by
   the introduction of the split-UA mail reading protocols (Post Office
   Protocol (POP) version 2 [15], Post Office Protocol (POP) version 3
   [16], IMAP version 2 [41], and PCMAIL [42]).  These protocols
   encouraged the use of SMTP as a posting (message submission)
   protocol, and SMTP servers as relay systems for these client hosts
   (which are often only intermittently connected to the Internet).
   Historically, many of those client machines lacked some of the
   mechanisms and information assumed by SMTP (and indeed, by the mail
   format protocol, RFC 822 [28]).  Some could not keep adequate track
   of time; others had no concept of time zones; still others could not
   identify their own names or addresses; and, of course, none could
   satisfy the assumptions that underlay RFC 822's conception of
   authenticated addresses.
   In response to these weak SMTP clients, many SMTP systems now
   complete messages that are delivered to them in incomplete or
   incorrect form.  This strategy is generally considered appropriate
   when the server can identify or authenticate the client, and there
   are prior agreements between them.  By contrast, there is at best
   great concern about fixes applied by a relay or delivery SMTP server
   that has little or no knowledge of the user or client machine.  Many
   of these issues are addressed by using a separate protocol, such as
   that defined in RFC 4409 [18], for message submission, rather than
   using originating SMTP servers for that purpose.
   The following changes to a message being processed MAY be applied
   when necessary by an originating SMTP server, or one used as the
   target of SMTP as an initial posting (message submission) protocol:
   o  Addition of a message-id field when none appears
   o  Addition of a date, time, or time zone when none appears
   o  Correction of addresses to proper FQDN format
   The less information the server has about the client, the less likely
   these changes are to be correct and the more caution and conservatism
   should be applied when considering whether or not to perform fixes
   and how.  These changes MUST NOT be applied by an SMTP server that
   provides an intermediate relay function.
   In all cases, properly operating clients supplying correct
   information are preferred to corrections by the SMTP server.  In all
   cases, documentation SHOULD be provided in trace header fields and/or
   header field comments for actions performed by the servers.