On ons, 2004-10-13 at 14:22 -0400, Greg A. Woods wrote:
> In the case of the <postmaster> or <postmaster@???> addresses
> there's really no good reason why you shouldn't accept transactions
> using an empty return path. (and neither you nor anyone else has given
> any even remotely valid reason)
so you say, but you haven't made any argument to back it up.
[RFC 2821, section 3.7]
| The reverse-path consists of the sender mailbox. Historically, that
| mailbox might optionally have been preceded by a list of hosts, but
| that behavior is now deprecated (see appendix C). In some types of
| reporting messages for which a reply is likely to cause a mail loop
| (for example, mail delivery and nondelivery notifications), the
| reverse-path may be null (see section 3.7).
[RFC 2821, section 4.5.5]
| All other types of messages (i.e., any message which is not required
| by a standards-track RFC to have a null reverse-path) SHOULD be sent
| with with a valid, non-null reverse-path.
[RFC 2119]
| 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
| may exist valid reasons in particular circumstances to ignore a
| particular item, but the full implications must be understood and
| carefully weighed before choosing a different course.
I don't see any valid reason for a message to postmaster to have null
reverse-path. can you come up with one?
(we accept _all_ e-mail to postmaster, but I defend the right of others
to block bounces to any non-sending address.)
> About the only time it's ever valid to reject a message with an empty
> return path is when there's more than one recipient specified. It's
> impossible, by design, for there to ever by more than one recipient when
> the recipient has been specified from another envelope return addr.
this is patently false. the RFC states how this can happen, and the
issue has been brought up on this list before. for your home system, it
may be appropriate to reject them, but "by design", this _will_ happen.
on our system with 70k users, it happens quite often.
--
Kjetil T.
