Re: [Exim] Canned clue?

Top Page
Delete this message
Reply to this message
Author: Philip Hazel
Date:  
To: Dave C.
CC: exim-users
Subject: Re: [Exim] Canned clue?
On Tue, 28 Nov 2000, Dave C. wrote:

> Someone on here once had posted a canned clue-brick type of message
> that they used to send to admins who had either accidentally or
> intentionally disabled reception of MAIL FROM:<> , but I cant seem to
> find it.


'Twas I. Here is is again.

-- 
Philip Hazel            University of Cambridge Computing Service,
ph10@???      Cambridge, England. Phone: +44 1223 334714.





Hello!

The system

xxxxx.xx.xx.xx

is refusing to accept an SMTP mail message from this system (xxx.xxx.xx.xx).
The message is an error message, caused by receipt of a message for an unknown
user. This system sends out such messages using the SMTP "from" command in the
following format:

MAIL FROM:<>

This is a standard SMTP usage to indicate an error message that should not
itself generate another error message. Here are two extracts from RFC1123:

      5.2.9  Command Syntax: RFC-821 Section 4.1.2


         The syntax shown in RFC-821 for the MAIL FROM: command omits
         the case of an empty path:  "MAIL FROM: <>" (see RFC-821 Page
         15).  An empty reverse path MUST be supported.


[...]

      5.3.3  Reliable Mail Receipt


         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, i.e., it MUST NOT lose the
         message for frivolous reasons, e.g., because the host later
         crashes or because of a predictable resource shortage.


         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; see Section 3.6 of RFC-821.  The
         recipient of this notification SHOULD 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.  If the address is an explicit source route, it
         SHOULD be stripped down to its final hop.


Your system reacts as follows:

<insert copy of SMTP dialogue>

On this occasion I will edit the message so that it is acceptable to your
system. However, I suggest you consider getting your mail transfer agent fixed,
because most other systems on the Internet use this convention and, indeed, the
RFC requires it to be honoured. If you don't, your users will never be able to
receive delivery failure reports from other hosts.