It absolutely is a standard! I got into a pissing match the other day
with an NT mail server admin somewhere in Vancouver, WA, who's mail
server was rejecting email with NULL return-paths. I told him his
customers would not know their mail is bouncing when sending to a
large number of domains.. well he basically started telling me that I
should be setting the bounce envelope sender to something other than
NULL, and I told him "no way". After he called me a "d*ck" I hung
up the phone :)
BTW, he instituted the block on null return-paths due to being
mailbombed or something by someone. As if the dude couldn't have
done the same thing with a forged return address somewhere at aol.com.
Goodness.
Aaron
To quote RFC 821 (SMTP):
If a server-SMTP has accepted the task of relaying the mail and
later finds that the forward-path is incorrect or that the mail
cannot be delivered for whatever reason, then it must construct an
"undeliverable mail" notification message and send it to the
originator of the undeliverable mail (as indicated by the
reverse-path).
This notification message must be from the server-SMTP at this
host. Of course, server-SMTPs should not send notification
messages about problems with notification messages. One way to
prevent loops in error reporting is to specify a null reverse-path
in the MAIL command of a notification message. When such a
message is relayed it is permissible to leave the reverse-path
null. A MAIL command with a null reverse-path appears as follows:
MAIL FROM:<>
To quite RFC 1123 (Requirements for Internet Hosts) section 5.2.9:
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.
Quoting Greg Owen {gowen} ([EMAIL PROTECTED]):
>
> This is not a qmail question per se, but a general "internet mail"
> question which came up because my qmail system got in a mail loop with
> someone else's SLMail system. I'm asking here because this falls into the
> domain of expertise that most people on this list excel at ;>.
>
> Most mail systems I've dealt with, when bouncing email, set the
> envelope sender to "<>" (and the header sender to "mailer-daemon" or
> "postmaster" or some such). This keeps it from double-bouncing back to
> the original system.
>
> Is this the result of any particular mail-related RFC, or a
> widespread but unofficial convention, or an unofficial convention which I
> incorrectly assumed was widespread?
>
> --
> gowen -- Greg Owen -- [EMAIL PROTECTED] -- [EMAIL PROTECTED]
>
> Please note my new [EMAIL PROTECTED] address which will
> become my default address in March, and which works now.
--
Aaron L. Meehan [EMAIL PROTECTED]
Systems Administrator Central Oregon Internet
http://www.coinet.com/
