David MacQuigg wrote:
It would help if someone could provide a clear, concise
statement of the PRA/SPF problem and post it on the new
website.
It's the same "CYA" problem as one year ago, only the idea
that a bogus PASS might be less harmful than a bogus FAIL
was new (but incorrect).
Many attempts to provide a clear, concise statement exist:
Meng's "CYA" slide show (aka "Olson objection") is probably
the oldest. Meng also found the "Sympa incompatibility" on
mxcomp. I contributed the "MSA 6.1 incompatibility", and a
"moderated newsgroup" problem. Others found similar issues
with Yahoo! and SES. The Council published a resolution.
For the SPF community position see <http://www.openspf.org>
I'll help with the wording to make sure it is clear to
non-experts.
You just have to know how PRA works, it's very simple: If
there's any Resent-Sender take the last (bottom-up). Else
if there's any Resent-From address take the last. Else if
if you got a Sender take it. Otherwise take the From.
If you got no or more than one address in the picked header
field forget it as illegal, otherwise the address is the PRA.
To construct conflicts with v=spf1 you just need a MAIL FROM
different from the PRA. The most simple case is a user with
his favourite 2822-From like nobody(_at_)xyzzy submitting it at
an MSA enforcing MAIL FROM:<user(_at_)msa(_dot_)example> (2476bis 6.1).
A very similar case is 2822-From company(_at_)olson(_dot_)example with
MAIL FROM:<outsourced(_at_)bulkmail(_dot_)example>. The Sympa-case is
a mailing list using MAIL FROM:<admin(_at_)list(_dot_)example> keeping
the original 2822-From without adding a Sender - these lists
use an Errors-To admin(_at_)list(_dot_)example(_dot_)
And on and on and on, it's pretty basic to get the idea that
PRA and MAIL FROM are sometimes different. As soon as that
is clear you can also construct bogus PRA-PASS results. It
is abuse, everybody with an IQ near room temperature sees it.
If they try it nevertheless it's because they want to steal
the installed v=spf1 base for their patented commercial PRA.
CSV neither prevents bogus bounces (like SPF), nor does it
try to do something about phishing (like PRA). TTBOMK it
wants to support HELO-based reputation systems. For that
you can also use SPF-HELO. If the MIPAS evangelists want to
educate the world why there system is _in theory_ better for
this purpose (I don't doubt this) SMTP would be long history
before it's deployed.
They don't have the SPF catch 22: _spammers_ are among the
early adopters of SPF, they can't afford FAIL results. And
if they want to play whack-a-mole with AOL they need a PASS.
I don't see any reason why they would need CSV. Bye, Frank