Theo Schlossnagle <jesus@???> probably said:
> however, when I send mail to that address it is autoreplied and the
> Return-path is not filled out. Many SMTP hosts are rejecting my
> messages because the smtp layer is delivering with MAIL FROM:<> which is
> BAD.
Er, no, that's perfectly correct.
I suggest you send Philip's canned reply to postmasters who havn't read
RFCs to the people who run the SMTP hosts who are rejecting your mail;
Philip Hazel <ph10@???> probably said:
> It usually means the far end is running an MTA that does not conform to
> RFCs 821 and 1123 in that it does not recognize
>
> MAIL FROM:<>
>
> as the RFCs require. It is often a misconfigured sendmail. I have this
> stock message I sent to the postmaster of such hosts:
>
> ---------------------------------------------------------------------
> Hello!
>
> The system xxxxx.xx.xx.xx is refusing to accept an SMTP mail message from this
> system (cus.cam.ac.uk). 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.
>
> Unfortunately, some users of sendmail have configurations that don't handle
> this correctly. I suspect that the following line is missing from ruleset 3 of
> your /etc/sendmail.cf file:
>
> R<> $@@ return magic token
>
> This is documented in, for example, Sun's System and Networking Administration
> manual, in the section on customizing sendmail configuration files. Nothing
> much seems to be said about it, but the example contains this line, as do the
> standard configuration files distributed by Sun.
>
> I will edit the current offending message so that it is acceptable to your
> system. However, I suggest you consider fixing your configuration file, because
> many other systems on the Internet use this convention and, indeed, the RFC
> requires it to be honoured.
>
> Regards,
> Philip
> ---------------------------------------------------------------------
>
> Sometimes I telnet to the remote host and try the MAIL FROM command just
> to check. The way to get the message delivered is to use the Exim
> command line options, or the equivalent Eximon options to change the
> sender of the message from "" to "mailer-daemon@???" and then prod
> it.
>
> --
> Philip Hazel University Computing Service,
> ph10@??? New Museums Site, Cambridge CB2 3QG,
> P.Hazel@??? England. Phone: +44 1223 334714
>
>
> --
> *** Exim information can be found at http://www.exim.org/ ***
--
pir pir@??? pir@???
