Tony Hansen wrote:
[proposed text]
This specification does not deal with the verification of return
paths for use in delivery notifications. Recent work, such as
[add REFERENCES here], has been done in providing ways to
ascertain that an address is valid or belongs to the person who
actually sent the message. A server MAY attempt to verify the return
path before using its address for delivery notifications, but
methods of doing so are not defined here nor is any particular
method recommended at this time.
Thoughts on an addition like this?
Looks good, and one of the references (RFC 4409 "enforced submission
rights") is even not exactly "recent work". The other 4408 reference
is strictly based on a "voluntary opt-in" mode, i.e. the domain owner
of the alleged sender and the postmaster of the receiver volunteer to
opt-in their users, or they don't. (No sarcasm, IMO that's how it is)
Whether those references are added or not, I still think the general
SMTP model has to be "tuned" for this millennium. All the "MUST NOT
reject" should be toned down (or removed if the problem they tried to
solve is meanwhile solved). Any "SHOULD bounce" has to be put under
a magnifying glass, there's a clear "MUST bounce" somewhere, so any
additional "SHOULD bounce" rules might be a bad idea. Especially if
they try to emulate "selective reject" by bouncing... :-(
And the "MUST accept responsibility" + "MUST bounce to originator"
have to state clearly that this can't work if the originator is in
fact unknown or at least dubious. There are situations where the
originator should be known (on the sending side from MSA to mailout),
by implementing 4409 6.1 or similar magic, otherwise the MSA is an
open relay and/or needs to be fixed.
And there are many other situations where the originator is known or
at least plausible (mail from a known "good" source, SPF PASS, etc.)
But there's only one place for the receiving side to decide this, at
the border MTA. Later is too late, it can cause bounces to innocent
bystanders, or - if the mail is dropped - it loses legit mail (in
the case of a "false positive").
While that's "obvious" after reading 2821 again and again and between
the lines the actual prose hides this flaw, it pretends that delayed
bounces are no problem and therefore accept is always the right thing
if there's a minimal chance that it could work out.
But that'a not true. Everybody HERE knows that it's not true. Many
readers out there missed that carefully hidden hole. If it's not
possible to fix a bug immediately the minimum that must be done is
to document this bug as clear and good as possible, and to mitigate
the undesirable effects.
Frank