Greg Connor wrote:
Can you explain what you mean by "Sender is stillborn" - that
seems to imply that Sender usage will never (or almost never)
match 2821 assertions for the same domain.
There are too many odd and incompatible cases. Everybody has
his own idea what "Sender" = the (2)822 header field means,
and who sets it. Many mailing lists use it, AFAIK covered by
no RfC, others don't, it's a mess.
Only one thing is sure, there must be a "Sender" as soon as
the number of addresses in the 2822-From isn't one. It's IMHO
hopeless to educate the world about whatever definition we'd
like as anti-abuse tool. For some odd cases like gateways or
moderated newsgroups it would fail. It's already broken, even
2476(bis) missed the Resent-* issues, and that's one point of
William's appeal (or at least it's how I interpret his appeal).
I still think the majority of domains will have the same
set of servers that send their 2821 mail also sending 2822
mail.
In the majority of cases you don't need a "Sender", probably
that's the reason why it attracts various rare and odd cases.
Even if DKIM works better, it may not be adopted by the same
crowds as SPF-next.
I'm far from sure that it works better (or at all), but it has
a nice feature, it's independent of SMTP, you can use it in any
mail (not only SMTP) or news. All it needs are some header
fields plus its own header field plus DNS. It could also work
with HTTP header fields (if I didn't miss something important).
Even if DKIM works better, I don't think that's a valid
reason for excluding it if we're trying to build an
all-inclusive domain-to-ip matcher.
What's an "all-inclusive domain-to-IP matcher" ? Without the
context here I'd guess you're talking about DNS and A or AAAA
records... :-)
[op=]
It's a hack applied after the fact to try to make up for a
design constraint SPF had since day one.
It's only a shorthand for all kinds of "yes", "false", "0",
"me too", or similar modifiers with essentially one value
"modifier present". So far it's no hack, bytes are precious
in policy records, and potential modifier-present-modifiers
all share the same problems of "absence doesn't mean 'NO'".
Because old policies and implementations cannot know future
modifiers. That's a fundamental concept, and actually it's
not limited to op=, it hits all _future_ modifiers. If you
want more interesting new tricks you need a new SPF version,
and that won't happen anytime soon.
I don't think we can logically conclude that all types of
"scope" ideas, or anything that smells like Unified, is
"therefore useless".
The relevant scopes are HELO and MAIL FROM, and for that you
could do all you need with op=. As soon as you add 2822 you
get PRA, it's the best possible idea for 2822. For that we
have spf2.0/pra,mfrom or op=pra.
What other scopes are you talking about ? Message-Is ? It's
normally a joke when I propose Message-Id as "scope", but it
could in theory make sense, like PRA.
[about DKIM]
there's no clear authoritative statement from the domain
owner saying "Drop all mail not signed with DK".
Doesn't SSP allow this ? We could offer op=I-use-always-dkim,
but the DKIM folks should also find their own solution. The
SSP draft says in chapter 4 "operation":
| (3) All valid messages from this entity are signed, and
| SHOULD have a valid signature from this entity. Third-party
| signatures SHOULD not be accepted.
[...]
| If a message is encountered by a verifier without a valid
| signature from the Originator Address, the policy results
| MUST be interpreted as follows:
[...]
| If the result of the check is policy (3), the message MUST
| be considered suspicious.
Now you managed what reading the DKIM list didn't manage, I
looked into the SSP draft... :-)
Now everyone is so hopping mad at Microsoft, that they are
avoiding anything that smells like MARID out of sheer
prejudice.
As long as PRA would do PRA without abusing SPF I wouldn't be
mad at them. It has serious technical problems as outlined in
William's appeal, but that's not necessarily only their fault.
The IETF process failure is the SPF abuse (= Julian's appeal).
But ignoring these issues you'll find that I always said "if
you want 2822 use PRA" (after I gave up to fix it with ideas
to define default-Sender := MAIL FROM identity).
It's no prejudice from my POV, it's a technical issue. If the
whole world has to upgrade all MSAs to do 2476(bis) 8.1 "MAY
add Sender", and then William shows that even this is not good
enough for Resent-*, that's FUBAR. Most mailer admins wouldn't
let their MTAs manipulate header fields in mail, it's against
all their instincts, "never try to fix it, you'd always make it
worse, bounce or forward it, but don't touch the mail DATA".
Bye, Frank
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com