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

On Sun, 2005-06-19 at 08:12 -0400, Terry Fielder wrote: 
> Douglas Otis wrote:
> >
> > From the day of the SPF/Sender-ID merger in the interim meeting at
> > Qualcomm, it has been clear the SPF record would be utilized to evaluate
> > the PRA.  Microsoft wanted to use their XML record, but the WG convinced
> > them to use the existing record syntax. 
> 
> Inaccurate at best, the working group convinced MS not to put bloated 
> inefficient unnecessary XML records in DNS.  It had nothing to do with 
> "convincing MS to use their syntax", it had to do with "don't make SPF 
> have to use an XML format"

Part of the pitch for the SPF syntax, during the transition from the
bounce-address to the PRA, included using the _exact_ syntax to avoid
causing a change to the existing record.  It has become obvious, this
was a mistake from the point of view of the bounce-address-only
proponents.  It is also clear from the onset of the requests to publish
SPF records, little consideration has been given to the potential
outcome when reputation is applied.

Although I repeatedly warned SPF does NOT prevent spoofing and that this
assumption is dangerous for those that share outbound MTA servers, this
caution was never heeded.  The typical response from various proponents
has been, "It is the publisher's fault for not considering these
potential problems."  It is also the proponent's fault for failing to
provide _any_ warning regarding these concerns.

It is rather outrageous to see statements like "Everyone and their dog
should publish SPF records."  This advice should include, "provided you
and your dog control exclusive access to the authorized outbound MTA."
If the MTA is being shared, then you and your dog should be indemnified
by your outbound service provider against their not maintaining your
exclusive use of both the bounce-address and the PRA.   

It is not surprising that SPF promoters don't care what problems they
may cause the average mailbox-domain owner.  Often these promoters are
bulk email service providers or network service providers looking to
escape accountability when one of their customers abuses email.  An
understandable goal and one safely achieved using email signatures,
rather than SPF.

With signatures, the providers would not alter signed messages nor
attempt to evaluate SPF.  With SPF, providers would need to evaluate
user/mailbox-domain permissions for the bounce-address and the PRA, or
place their customers in serious peril.  Signatures expect nothing from
the providers.  Whereas, SPF expects much more from providers, without
providing any ramification when they fail these added duties.

Sender-ID wants to change Sender-Header handling in conflict with the
much safer signature scheme.  SPF wants to change the bounce-address
handling and place providers at risk with its poor level of security.
The risk and incompatibility created by either SPF or Sender-ID is
without merit, when there is a much better and safer alternative
possible.

Remember, SPF is simply an historical document that attempts to capture
SPF as it was before Sender-ID had been adopted, according to Meng.
Sender-ID is the only active document relevant to the application of the
SPF record, in his view.  Sender-ID now permits evaluation of both the
bounce-address and the PRA.  It seems that the SPF classic group are
confused about the current relevance of their document.  The problem of
requiring assurances for the PRA or publishing a record destined to be
refused seems of little concern. 

To get a better understanding why SPF is historical, and that only
Sender-ID defines use of the SPF record read:
http://spf.pobox.com/whitepaper.pdf

-Doug