Jon Kyme wrote:
So, we inform the "original sender" that the *forwarded to*
address (which they may never have heard of) is broken? How
useful is this?
Depends. So far I got one "551 emulation" bounce in 21 months
caused by the SPF FAIL: The original receiver was some kind of
"whoisguard" encrypted Tech-C address forwarded to a 3rd party
checking SPF.
This 3rd party rejected the FAIL, therefore the forwarder sent
a bounce to me with the complete error message it got, that
included the address of the final receiver, so I could simply
send my message again to the final address.
Working as designed for "5.3.6(a) forwarders" not interested
in SPF FAIL issues.
OTOH if one of the next hops has serious problems like "no such
user" this would be very interesting for the forwarder: If it
forwards arbitrary mails to a destination that never works it's
net abuse, today most mails are spam with a bogus MAIL FROM.
1123 5.3.6(a) forwarding cannot work when most mails are spam:
If any hop behind the forwarder rejects the mail the bounces
hit innocent bystanders.
Unless it was an SPF PASS, auto-responses (NDNs or challenges)
to a Return-Path with SPF PASS cannot hit innocent bystanders.
Quite simple, no chance to get it wrong as long as SPF checking
systems _reject_ FAIL. If they _drop_ FAIL they're in trouble.
It's arguable that forwarding is a function of the MDA
logically - A local delivery to a software agent (rather than
to a mailbox) has taken place and a *new* message
consequently enters the MTS.
If all new recipients are within the same organization (no MX
of a 3rd party involved) keeping the MAIL FROM as is should be
okay. But even if it's modified, and the mail is forwarded to
addresses at 3rd parties it's still the same *old* message and
the same *old* Message-ID.
For a really *new* message you'd also need a *new* Message-ID
or at least a Resent-Message-ID. One of the many issues with
PRA aka SenderID, here violating a 2822-SHOULD without saying
so - I'm too lazy to check this, a formal but no real problem.
Of course, the particular issue with forwarding messages with
the null sender has to be addressed. But that's not a general
objection.
MAIL FROM:<> can't cause bounces to innocent bystanders. If it
attracts backscatter to (2)822-addresses the auto-responder is
broken (from a 3834 POV).
Bye, Frank
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg