spf-discuss
[Top] [All Lists]

Re: [spf-discuss] Re: Preparing the IAB appeal

2006-02-08 06:50:00
Very good Frank.

However, I would say that False "PRA PASS" *are* worth mentioning in the appeal. Here is a stab at it:

In addition to the loss of legit emails are the potential for PRA flagging forged emails as legitimate based on misinterpretation of v=spf1. Phishers etc could use these false "PRA PASS" events for harmful means, especially if PR encourages the public to believe that a "PRA PASS" means the email is safe/secure in some fashion.

Terry

Frank Ellermann wrote:
Julian Mehnle wrote:


I'd be happy to read any advice you have when I wake up.


Here's an attempt with a short line of arguments:

Deployment of SPF began in early 2004.  It was designed to
check the MAIL FROM (2821-From) Return-Path in SMTP, not
any 2822-header fields like PRA.

Inspired by Stuart's article here:  The _titles_ of Meng's
and Mark's drafts alone show this.

Last before MARID draft-mengwong-spf-01.txt
A Convention to Describe Hosts Authorized to Send SMTP Traffic

First after MARID draft-lentczner-spf-00
Authorizing Use of Domains in MAIL FROM

MARID decided that using existing v=spf1 policies for PRA
cannot work, evidence Meng's v=marid article.

For a substantial portion of mail (some say 80%, pointer to
one of Hector's article stating this) MAIL FROM and PRA are
different, as explained in (pointer to old appeal).

The v=spf1 spec. draft-schlitt-spf-classic-02 explains why
checking other identities (not limited to PRA) against v=spf1
policies is NOT RECOMMENDED.

More than a million v=spf1 policies have been published
under this assumption since early 2004.

In chapter 3.4 senderid-core claims that v=spf1 SHOULD be
handled like sp2.0/mfrom,pra (i.e. PRA == MAIL FROM routes).

This is incorrect, v=spf1 is almost the same as spf2.0/mfrom
but can be very different from spf2.0/pra.

Participants in the v=spf1 "experiment" (quotes intended)
are not necessarily interested to participate in the later
(fall 2004) PRA-experiment.

They're not necessarily interested to publish dummy sp2.0/pra
policies to "opt-out" from PRA as explained in senderid-core.

PRA is known to be cumbersome and violate Internet standards
(pointer to IESG reply wrt William's appeal).  It's not
feasible (sp?) to upgrade all existing v=spf1 policies with
dummy PRA opt-out records.

The IESG note (pointer to IESG reply wrt your appeal) simply
reiterates the "opt-out" recipe in senderid-core.  Many
participants in the v=spf1 "experiment" do not wish to be
non-voluntary participants in the PRA-scheme with their mail.

They consider this as unethical and violating even the lowest
conceivable (sp?) engineering standards.  It would cause the
loss of legit mails.

For the IAB the more tricky point of bogus PRA PASS results
with their potential damage is probably a bit too esoterical.

                            Bye, Frank


-------
Sender Policy Framework: http://www.openspf.org/
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


--
Terry Fielder
terry(_at_)greatgulfhomes(_dot_)com
Associate Director Software Development and Deployment
Great Gulf Homes / Ashton Woods Homes
Fax: (416) 441-9085

-------
Sender Policy Framework: http://www.openspf.org/
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