Seth Goodman wrote:
there is no MUST that I can find that says it has to have any
relation to the actual sender
Yes, that used to be obvious, and the 2119 keywords like MUST
were invented after 821 / 1123.
If an RFC defines X = Y, then it cannot say "<X> MUST be <Y>",
it's a definition and no requirement. So the MAIL FROM is the
Return-Path, it's not any "report-trouble-elsewhere-address".
Of course you can twist it to get this effect, and in many
cases like mailing-lists automatically unsubscribing bouncing
addresses that makes sense.
In other cases it makes no sense, if mail from A does not make
it to B, then the very last you need to analyze this problem
between A and B is a third system MAIL FROM C.
But MAIL FROM troubleshooter(_at_)A instead of stupid_user(_at_)A can be
a good idea. That's a variant of what mailing lists do, they
don't use MAIL FROM list_member(_at_)elsewhere, they also don't use
MAIL FROM list_owner(_at_)here, they probably use list_bounces(_at_)here(_dot_)
[arbitrary "errors-to"]
This is obviously different from today's best commercial
practice, and, in fact, the operating assumption behind SPF.
It's also different from the original 821 concept. The special
case "user not local" was always a special case. BTW, that's
IMHO all clear since at least 2003 and RMX, anything new ?
At the moment I get about 500 bounces in 16 hours again, that
is not much better than the 1000 per day in the first series
in 2004. But now I spamcop each and every bounce, and I also
got more "feedback" (replies) in one week than in the three
years since I use SpamCop.
Hilarious, "this is only a single NDN, just delete it" and
"this is no spam, it's a bounce" are my favourites so far.
It's also fascinating if clueless "postmasters" inform me why
they don't like spam and I should stop it, or they try to tell
me which of their users don't exist, are over quota, and what
else. I can only hope that my reports blacklist their mailers
until they get a clue.
[outgoing SPF]
SPF happens to be a great tool for that, even for ISP's that
don't publish their own SPF record or check SPF on incoming.
Julian has implemented this. I'm more a fan of the "enforced
submission rights" in 2476(bis), but it's a similar direction.
Mailing lists are classified as remailers and have to keep
the From: and add their own address as Sender:.
The latter is AFAIK nowhere required. Many mailing lists do
it, but not all. IMHO they could restrict themselves to the
standard List-header fields and not touch any existing Sender.
Systems that do not comply with this are BROKEN.
IBTD. Let the "Sender" be what it always was, a more or less
irrelevant feature if sender != author, or if there are two or
more authors.
MS MUA's, which unfortunately are the predominant ones on
the planet, only support what I would call encapsulation
forwarding. In this style, it is treated as a new message
with appropriate headers for the new sender.
Actually that's fine if they only would use a message/rfc822
or multipart/digest as specified for minimal MIME conformance.
The forwarded message is either in-line with the body or as
a MIME attachment
Forwarded mails are not necessarily a "MIME attachent", the
default Content-Disposition is _inline_ for message/rfc822.
For obscure reasons MS twists that into _attachment_ with a
type "eml", but that is their own proprietary invention, it
is legal but unnecessary. Actually it's a royal PITA.
Thunderbird is similar to MS MUA's in this regard, as I
believe are Netscape and Mozilla Suite.
My vintage 1997 "Mozilla 3" uses the default, no attachment.
Pine handles the "redirect" style of forwarding properly
For a definition of "proper = Resent". MIME introduced the
more flexible solutions later. 2822 twisted the old Resent-
style into "multiple blocks of Resent-headers", but that's
FUBAR. Just look into the Sender-ID draft, it's a major pain
to "decode" this correctly at the receiver.
It appears that MUA's probably do not contribute
significantly to these headers being misused.
ACK. For Sender-ID we're more interested in bad actors, not
harmless Pine-users trying to resend an already resent mail.
I would argue that should we eventually decide to apply the
SPF record to the current sender in the 2822 headers, it
would not be that hard to fix the few problems that would
result.
It's impossible, the cases without Sender and From != MAIL FROM
don't go away by wishful thinking. That's the kind of wishful
thinking you find in the Sender-ID drafts.
It's also the reason why SPF and Sender-ID have an impressive
IESG note which is essentially the polite form of "FUBAR". Bye