Seth Goodman wrote:
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.
Okay, but it's almost a year now. Waiting until DKIM is almost
ready would be a bad idea, if SES is really "better", then some
users you see on the DKIM list might be upset if they wasted
their time with DKIM. Keith and Ned, maybe Russ when it's a WG
in his area.
And then there was this big SES fan posting here sometimes as a
private user, but you did get the idea that she's working for
the biggest hoster of the world, didn't you ?
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.
Should be possible. So far we found that it's more a question
of what the receiver does, not really a "sender policy" issue.
Unless you insist on an "enforced" Sender (at the MSA) instead
of a "dummy" Sender (at the MDA), then we'd need op=secy (same
idea as op=pra). Advantage: op=secy allows to reject phishes,
if it's implemented. Disadvantage: that would be a DATA test,
and you only "catch" a few idiots shooting in their own foot.
In the DTA phase all SPF FAILs are already rejected. Okay,
you catch also phishing NEUTRAL and SOFTFAIL, an op=secy could
mean "but if it looks like a phish treat it like an SPF FAIL".
IMHO that leads nowhere, let's drop these modifier ideas, and
obscure DATA tests trying to reject a few phishes, let the user
handle it. SPF is for 2821 and SMTP before DATA, no nonsense.
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?
Adding the STD 11 concept is simple, then you have only two
additional cases:
1 - Has Resent-Sender
1a it matches MAIL FROM => okay (display it as responsible)
1b bad, display mismatch warning
2 - Has Resent-From (like 1)
3 - Has Sender (like 1)
4 - Has From
4a it matches MAIL FROM => okay
4b "missing Sender" => okay (use MAIL FROM as responsible)
We've discussed 3+4 before / elsewhere. If you want to handle
1+2 with a legacy MUA (with some POP-Proxy or SIEVE magic
between MDA and MUA) use Stuart's strategy: Copy the address
to a new dummy Sender (because the legacy MUA displays this),
if there was an old Sender preserve it as X-Original-Sender.
If you also want to "support" 2822 (multiple Resent-* blocks)
simply display this as warning and let the user decide. This
case should be very rare. Unless some attackers are trying to
play games with PRA, but then a warning is fine. Bye, Frank