spf-discuss
[Top] [All Lists]

Re: possibilities for 2822

2005-08-17 17:07:02
Seth Goodman wrote:

source routes really are deprecated, even if 2821 is only a
proposed standard.

Yes, it's already in RfC 1123 / STD 3 (credits to Tony Finch,
I didn't know that last year, it hit my "back to the routes"
chain of arguments like a meteor... ;-)

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.

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 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.

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).

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.

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).

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).

The issue is how you want to convince the world that there's a
new rule about the Sender for mailing lists.

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.

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.

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.

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.

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:

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 ?
                           Bye, Frank