gconnor wrote:
I don't like PRA really, but hopefully PRA won't get in the
way of SPF2.0 much. If we give people permission to use PRA
if they opt in, and also give them a few other choices too,
my bet is that PRA will atrophy and die.
I'll answer your other article later, but here we obviously
disagree: IMHO PRA is the _best_ you can do with anything in
2822 header fields. It's almost impossible to improve PRA.
Two ideas were proposed:
- add the concept of a "default Sender := MAIL FROM identity"
for mail without any Resent-From, Resent-Sender, or Sender.
In other words fix PRA at the side of the receiver instead
of hoping that the whole world fixes their software at the
side of the sender (MUA or MSA).
But that idea was "rejected" (= almost nobody in MARID agreed
with it), so we're stuck with PRA as it is, i.e. different
spf2.0/pra vs. spf2.0/mfrom scopes.
- invent a better PRA by introducing eh= modifiers, or in the
bare bone version op=rfc822 to get the effect of the first
idea. That got no traction, but maybe we could discuss it
again (after the pending senderid appeals are resolved).
As far a I'm concerned anything else is always worse than PRA.
E.g. your idea to have separate 2822-From- and Sender-policies,
why on earth should anyody want this ? If we write something
together (two co-authors) the correct way to post it would be
either 2822-From: greg, frank with Sender: greg coming from one
your IPs, or the same 2822-From with Sender: frank coming from
one of my IPs, or if we get William to post it for us we still
have 2822-From: greg, frank with Sender: william and of course
one of William's IPs.
All attempts to redefine what 2822-From and Sender mean for
about three decades are futile, therefore 2822-From policies
are useless. Maybe you could decree that William and I have
no business to mention you as co-author in the 2822-From, but
that's utter dubious, we're talking about STD 11, it's a full
Internet standard, it has no "opt-out by an 2822-From-policy".
From there the scenario deteriorates, you might argue with me
and William, but what if somebody resends mail from you ? This
would result in a 2822-From: greg with a Resent-From: somebody.
You can't decree that that's wrong, it is allowed by STD 11.
Your 2822-From also shows up in news that you post, including
mail submissions from your news server to the moderator in the
case of moderated newsgroups, or mails behind some news2mail-
gateway you've never heard of.
I even get a news (!) From: greg because I read this list as
newsgroup on GMaNe. You could still insist that it's your
address, and that you're entitled to cripple yourself as it
pleases you in your 2822-From policy.
But then the fatal question remains, why should anybody bother
to check your obscure "2822-From policy" ? They'd get tons of
FPs, so they could at best use PASS for simple cases, with a
green blinking icon on their MUA maybe.
OTOH it would be trivial for the opposition to get the same
green blinking icons for phishes for From: paypal.example.com,
and then that green icon is meaningless, unless the receiver
combines it with a white list (From: greg could be in his WL).
That's a lot of effort for something you can also have with
v=spf1 as is, just use the WL idea combined with Return-Path
instead of 2822-From.
IMHO the Return-Path (and to a lesser degree the HELO or EHLO)
are the levers to get the whole SMTP-mess under control, 2822
header fields are a hopeless case as far as SPF (= sets of IPs)
is concerned.
Sets of IPs always mean "works best at the border". If you
want something that works everywhere you need signatures. Bye
-------
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