Re: [spf-help] Re: SPF and SenderID

On Tue, 2005-07-19 at 22:59 -0700, Greg Connor wrote:

> Speaking of FUD, thank you for the eloquent reminders as to why I haven't 
> opened the MXCOMP mail folder for nearly a year.

I am surprised you consider a suggestion to permit use of a compatible
record (spf2.0) by SPF Classic (and Sender-ID) to be FUD.  I have just
returned from a large promotional meeting attended by SPF proponents,
such as Meng Wong and Wayne Schlitt.  On more than one occasion an
explanation was made that publishing the v=spf1 record would be used to
evaluate the PRA.  I never heard anyone object, so I don't understand
how one can conclude what people intend when they publish this record.
I would have hoped you could understand why not permitting a record that
declares its scope has become a problem.        

> MARID failed it's primary goal, but most of the people involved are moving 
> ahead with other proposals.  More power to them.  I don't even think of 
> them as "competing" proposals.  The best case would be if they all move 
> forward in some form or another.
> 
> I don't think it's productive to point to the actions taken by MARID and 
> say that those are the "official" versions of anything.

There are experimental versions of SPF Classic and Sender-ID with a few
still trying to find solutions for problems that remain with these
approaches.  Two areas still wanting is a means to assert scope in SPF
classic to indicate that the PRA has not been evaluated and should not
be used.  The other is a means to indicate the exclusive use of a domain
is or is not being assured by the server.

At this meeting there were companies that acknowledge the concern
created by such oversight and were providing domain owners their own
unique outbound IP address.  When considering the shared server problem
together with the loss of forwarded email, it is hard not to think that
DomainKeys and DKIM are already well ahead on the solutions curve.

There is no spam or phishing solution without the use of email
reputation.  The accrual of reputation demands authentication and not
just authorization, if to be fair.  Saying that authorization is good
enough sounds too much to me like "let them eat cake" when knowing those
that care will have their own servers.  Getting this right requires an
understanding that neither authorization nor authentication alone is a
solution. 

The next step in this process is reputation, however this step can only
be safely made when there is an ability to authenticate the entity being
held accountable.  Just calling it authentication is not productive,
when it is based upon an assumption that the server is not shared.  I
find this a bad assumption and one that will create endless support
issues when exploited by the millions of zombies known to exist.

-Doug