What is the BCP for allowing multiple RCPT TO
when the return path is NULL?
It is not appropriate for a server to assume that MAIL FROM:<> is an
indication of a bounce message. There are valid reasons to use <>
with other than bounced mail. For instance, an MDN can be sent to
multiple parties if the originator of the subject message requests it
and the recipient explicitly consents to do so, and such an MDN should
still have a return-path of <>.
There is also no reason that a server should refuse multiple RCPT TOs
when given a return path of <>. Of course, a server is free to refuse
a RCPT TO with a 452 error code (too many recipients) if it's not
willing to accept more than one RCPT address. But either returning a
5xx error code with a valid recipient address, or returning a 2xx error
code and silently failing to deliver mail to that recipient, are
contrary to the standards and will break things.
In general, since the message that's sent with the null
MAIL FROM generates the RCPT TO from the
inbound MAIL FROM, and there's only one of those, then
you can only get one outbound RCPT TO.
Wrong. There is no prohibition that I'm aware of against using <> for
other purposes, and there are some standards that specifically require
using <> - e.g. MDNs and responses from mail robots, neither of
which are constrained to exactly one recipient.
It could be, however, as Keith suggest, be operating in post smtp
I don't know what "post smtp mode" is, or what you think I suggested.
I mean it, there are two options for "no bounce needed" requests:
Mail from: <> or <postmaster[(_at_)domain]>
no. MAIL FROM:<> is the recommended way to say "no bounce needed".
For MTAs that support the DSN extension, you can also say NOTIFY=NEVER,
but that's not as widely supported and it only applies to DSNs (not to
other kinds of notifications like MDNs or messages from mail robots).
There are no other standard ways to do that that I'm aware of .
MAIL FROM:<postmaster(_at_)domain> means "send bounces to
postmaster(_at_)domain", NOT "no bounce needed".
Why should the rest of the compliant world be bothered by a broken list
server mail agent?
It's not clear what is broken in this case. But in general, lots of
mail software authors and/or operators are making dubious assumptions
about what kinds of spam countermeasures are reasonable, and those
assumptions conflict with one another far too often. It's not
reasonable to assume that a message with an invalid MAIL FROM address
is spam. Nor is it reasonable for a server to assume that a message
with MAIL FROM:<> can only have one recipient. I'm not aware of
anything in the standards that says it's safe to make these assumptins.
I have on my personal setup as a filtering rule:
Reject if MailFrom "<>" and TotalRcpt > 1
well, it appears that your mail server rejects a lot of perfectly valid
mail for other reasons known only to you, so I guess I'm not surprised.