Actually, i haven't. Section 5.2.9 states the following:
An empty reverse path MUST be supported.
I clearly stated that this was not in dispute.
Section 5.3.3 does indeed state that the null return-path _is_ required for
use, however references itself with section 3.6 of RFC 821, which is the actual
specification of the SMTP protocol. Section 3.6 of RFC 821, however, does
_not_ state that the null return-path is required when sending bounces. It
clearly states that the null return-path is _one_ option:
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.
I stand by my original statement.
ari
[EMAIL PROTECTED] said this stuff:
> You've misread the spelling of 'MUST' in sections 5.2.9 and 5.3.3 of
> RFC 1123.
>
> -- Jeff Hayward
>
> On Mon, 7 Feb 2000, ari wrote:
>
> Of what i remember from RFC 821, the null reverse-path is _not_ required, but
> is rather mentioned as "one way" to get around the "bounce of a bounce"
> problem.
>
> Yes, all mailers should allow this, even though many spammers abuse it. True,
> rejecting it can be considered breaking RFC-compliance. But it is by no means
> required for use.
>
> Or maybe i'm nitpicking.
>
> ari
>
>
>
--
.------------------------Ari Edelkind--------------------------.
Unix Systems and Network Administrator [EMAIL PROTECTED]
Public Health Research Institute (212) Phone: 578 0822
New York, NY [USA] Fax : 576 8442
`--------------------------------------------------------------'
