From: Frank Ellermann [mailto:nobody(_at_)xyzzy(_dot_)claranet(_dot_)de]
Sent: Wednesday, August 17, 2005 7:07 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: [spf-discuss] Re: possibilities for 2822
Seth Goodman wrote:
<...>
Snipping your DKIM arguments, they all make sense, but I can't
judge it really at the moment. And I don't understand why the
SES folks don't publish their ideas as an I-D. From an IETF
POV SES doesn't exist, and SPF is this odd mail experiment with
the longest IESG Caveat I've ever seen.
We mean to, but there is this little commodity called time that we are
unable to manufacture quickly enough. There is also the issue of how and
whether to apply it to 2822 identities, which I'd rather not do at all.
That's part of what this discussion is for, though I didn't mention it.
It's easy to integrate the 2821 part of SES with SPF to solve the forwarding
problem. SES _could_ be used for 2822 identities, but I prefer to think
that if we can come with acceptable header equivalence rules, it won't be
necessary.
I doubt that folks like Bruce, Keith, or Ned know that DKIM
might be not the only game in town. Dito some other heavy
weights, Dave, John L., Doug, Phil, Andy, Hector, Tony, etc.
I prefer to respond to that offline.
I think there ought to be more of an enforced relationship
between MAIL FROM and _something_ in the 2822 headers than
presently exists in common practice.
Okay, let's get this clear. You've excluded Resent-* for the
moment, because we agree that it's rare and not more essential,
MIME offers similar features to resend mail.
Yes, though it is still there.
That leaves us with two important cases from your POV:
1: MAIL FROM doesn't match From, no Sender
2: MAIL FROM doesn't match From, Sender reflects MAIL FROM
You claim that we could simply outrule (1) and enforce (2).
Well, there's the obvious and most common case #0:
0: MAIL FROM matches From
If by outrule #1, you mean not allow the message to leave the MSA in that
condition, then yes. What to do with a message that arrives at an MTA where
domain(MAIL FROM) != domain(From:) is a harder question. It is the same
problem as what do you do with an SPF unknown, softfail or fail. Not
everyone has the same answer. It would be _really nice_ if we could get to
the point that we could reject on that, but that's a long way off.
IMHO the list is incomplete, there are more cases. You've
mentioned the known "secy" case, that was how Dave "invented"
the Sender before 821, SMTP, and MAIL FROM existed. RfC 724.
AFAICT, the secretary case is supposed to be sent as:
MAIL FROM:<secretary(_at_)megacorp(_dot_)com>
From:BigBoss<boss(_at_)megacorp(_dot_)com>
Sender:<secretary(_at_)megacorp(_dot_)com>
so it is your case #2. In fact, since both of us seemed to agree in prior
posts to this thread that the local-part is of no consequence (until the
message reaches the delivery MTA), this could equally be considered to be
case #0. In any case, it is a pass.
Maybe not literally invented, but he was a coauthor 30 years
ago. Whatever we'd wish, we can't change one rule about it:
If there's more than one address in the From, then there MUST
be a Sender. Not necessarily a conflict with your ideas, you
want (2) instead of (1).
No conflict at all. It answers a separate problem. In the case of multiple
authors, there can still be only one party that submits the message, and
only one address is allowed as argument to MAIL FROM to receive bounces. So
we're back to the equivalence of MAIL FROM and Sender: in this case, at
least for the domain part of the address.
But it starts to get tricky if you want (2) for mailing lists.
If a list member X normally posts as X the list redistributes
it as MAIL FROM list, From X, Sender list (= your case 2).
If list member X wants to post an article with authors X, Y, Z
it's MAIL FROM X, From X+Y+Z, Sender X following your rule (2).
So how should the list redistribute it ? The issue is NOT that
you can't answer this, of course you can, there are at least
two possibilities (use another header field like Resent-*, or
use Original-Sender X with a new Sender list).
I would be interested to see how actual list packages handle this case.
The issue is how you want to convince the world that there's a
new rule about the Sender for mailing lists.
It would only be worth something if the majority of current mailing list
installations already used Sender: in this way. If some used Resent-From:
and some used Sender:, then we have a problem, Houston.
Second problem, your original idea is that the Sender reflects
the MAIL FROM. But we know that it doesn't for legit cases of
"bounces-to". You could get something like...
MAIL FROM list-bounces@, From X, Sender list@ (or similar).
That's not more strictly (2), your solution is "same domain is
okay". Besides you need the same exception for BATV and other
rewriting schemes.
That's a key point. It's only the domain that needs to be the same.
Without making that assumption, it is almost impossible to make any sense of
the current and proposed standards' descriptions of MAIL FROM, From: and
Sender:. With that assumption, the documents appear pretty consistent. I
don't know if that's what the authors intended or not, this is just an
observation.
Keith posted some good articles yesterday on the DKIM list,
and one of his points was apparently, if there is a "feature"
(or bug) in mail, then somebody somewhere will use it, and
saying that this usage is irrelevant or "broken" by decree is
A Bad Thing.
If that's the case, then we can't ignore Resent-*: even though virtually
nobody uses it, and if anyone does, no one would notice. Well, maybe we can
ignore it if we don't say it's broken!
Of courss he also doesn't like SPF. In that case I claim that
251-forwarding is a special case, <insert my known source route
arguments>. But generally I agree with his attitude, we don't
have any right to break unkown legal mail uses only because it
pleases us for wannabe-anti-spam reasons.
Good point. I happened to like source routes much better than SRS, but I
lost that one, too.
Last but not least, let's assume that that's all irrelevant,
and your "enforced Sender rule" (2) is possible, then it is
redundant:
If all I have to do for (1) to get (2) is to add a Sender
reflecting the MAIL FROM, because that pleases somebody or
something, why on earth doesn't it do it by itself ? Just
assume that the missing Sender is there.
Yes, in theory my MUA could have done this, or my MSA (using
IIRC option 8.1 in 2476bis), but for various reasons they
didn't, so just pretend that the redundant Sender is there.
Yes, that's the same argument as one year ago in MARID.
Like it or not, _essentially_ your proposal is op=pra: You
want to enforce PRA == MAIL FROM (maybe modulo Resent-* and
dummy Sender if missing). Then you test the MAIL FROM, and
let the MUA display the relevant "equivalent header field"
(using William's term), which ought to be the same as the
MAIL FROM, or at least the same domain.
As Groucho Marx once said, "I don't deny it but I resent it". (pun not
intended)
So putting it all together the MUA should check that this
is really the case. But if the MUA checks it, it could as
well display the Return-Path as is:
To tell the truth, if MUA's routinely displayed the return-path, we wouldn't
be discussing how to stop phishing, it would be largely dead. This whole
thing is a problem because the common MUA's, and not just MS's, fail to
display all the originator information. The authors of SMTP created an
extremely flexible system with a plethora of originator identities to
facilitate a very wide variety of practice. Along with that wide variety of
reasonable uses comes an equally large number of malicious uses. Without
displaying all the information, you can't tell the reasonable uses from the
malicious ones. But, they cry, the average user can't deal with that many
identities, so we can only show a few. Well, then the protocol has too many
identities for general use by a technically non-expert user base, which is
what we currently have. The internet was not built for the non-expert user,
but we haven't gotten around to accommodating that reality.
I can't dictate what mailing practice is, but the current situation clearly
does not make sense. Unless you can automate the interpretation of multiple
overlapping identities, which this is one attempt to do, you have to show
all the identities. That means you either deprecate some of the identities
that are barely used, so that an average non-expert can tell that they are
looking at a phish, or you throw your hands up and display everything, flag
any possible problems and hope the users don't get used to ignoring the
flags.
Zero modifications to mail header fields, no PRA headaches,
if I get your proposal right it's just a matter of the MUA
displaying a warning for suspicious cases:
MAIL FROM ~ From => okay (no warning)
MAIL FROM ~ Sender => okay (no warning)
otherwise no Sender => okay (assume that MAIL FROM is Sender)
In all other cases display a warning. Is that really all, or
did I miss something ?
No, you don't miss much. If MUA's always displayed MAIL FROM, or only
displayed it when it didn't match From: or Sender:, there probably wouldn't
be much need for 2822 authentication at all. Of course, what do we do when
someone starts to use the not broken feature of Resent-*: headers?
--
Seth Goodman