Meng Weng Wong wrote:
the worst-case scenario under SPF is that legitimate
forwarded mail is rejected because the forwarder doesn't do
SRS.
Yes, hopefully it's rejected resulting in a bounce from the
pre-SPF forwarder to me. Even if it's deleted somehow (e.g.
SPF-test after SMTP + spam-filter) this worst case is a known
consequence of publishing "-all".
the worst-case scenario under PRA is that legitimate mailing
list (and forwarded mail) is rejected because PRA is, as you
say, fubar.
You said here several times that you expect PRA to be mainly a
MUA application, and then it's "delete", not "reject". With a
worst case of "applying PRA on pure v=spf1 policies", breaking
the (pick one of three) v=spf1 spec.
they are qualitatively within the same range of fubarness,
In the 1st case it's something I accept, because I said "-all"
(or rather my ISP did). In the 2nd case it's an intentional
abuse of pure v=spf1 by PRA-implementations (new Sender-ID).
in fact those problems are less fubar than credit cards
That's possible. Credit cards are very unusual in my country.
And amazon.de lives, I'm one of many happy customers (without
credit card).
i'm not sure how we can defend SPF Classic's fubaredness wrt
forwarding
IMNSHO the whole idea of "forwarding to 3rd parties" is insane.
SPF / RMX fix a blatant hole in RfC 2821. And you demonstrate
that it's still possible to forward mails in responsible ways,
with SRS resp. remailing schemes, with global white lists like
trusted-forwarder.org, maybe local white lists and op=trusted,
or similar ideas. BTW, I renamed option "meng" to "trusted",
the new op-set is "helo", "trusted", "auth", "rfc822", "pra".
[continued]
and attack PRA wrt mailing lists. that's like the small pot
calling the big kettle black.
Doing something in the SMTP-dialogue is _very_ different from
doing something with the SMTP DATA (here 2822 headers). If a
snail mail is forwarded to your new address nobody had to open
the envelope and inspect / modify your letter.
You'd have a point if you say "pure PRA" is somewhat similar to
"pure SPF" for those who want it. But PRA-forced-on-pure-SPF
is neither pot nor kettle, it's a fire burning mails and SPF.
all the talk I've heard so far says that people are going to
use Sender ID and SPF Classic more for whitelisting than for
rejection for a long long time.
Essentially that's "don't use -all", and without "-all" SPF is
dead. No receiver is interested to fetch and evaluate sender
policies (on his time and bandwidth) without a good chance to
get some FAILs (paying back the invested time and bandwidth).
Bye, Frank