[Asrg] Disaster looming: SPF

[Matthew Elvey <matthew at elvey.com>]

Vipul:  Here's how CSV or SPF handle the scenario you paint:
Systems that are able to keep their noses clean will have better 
reputations than other systems.
An ISP (typically) (in the case of CSV) or a .com domain (typically) (in 
the case of SPF) will be motivated by the scheme to keep its nose clean 
(the mail stream emanating from its users' systems, that is, to be precise).
If it doesn't, there will be consequences.  Its infrastructure costs 
will go up, as it has to work hard to deliver a huge mail queue that 
piles up as it tries do deliver to machines that are throttling or 
tempfailing it's delivery attempts for as long as it's reputation is 
questionable.
Make sense? You're familiar with the aspen framework?  One difference 
between CSV and SPF is that the latter doesn't do a good a job defining 
the party most able to do something about the problem.  (The SPF 
protocol allows the party to be poorly defined and hard to trace.)

On 11/27/2004 4:32 PM, Frank Ellermann sent forth electrons to convey:

> SPF is not the FUSSP, it's the next "necessary" step.

Nonsense.  SPF breaks MUCH MORE than is necessary to achive sender 
authorization and authentication.

> Defining "necessary" by the minimal modification you can get
> away with (excl. radical approaches like "delete all bounces"
> because that breaks SMTP).
>
>  
>
> > At this point, strong SPF checking breaks too much stuff
> > (especially forwarding).
> >    
>
> It's not "especially forwarding"
True, that's not the biggest problem of SPF.  A bigger problem is the 
ISP end-user support nightmare looming around the corner: the 
reconfiguration of every power user's MUA, since SPF breaks their 
current configuration. It's not going to happen.



_______________________________________________
Asrg mailing list
Asrg at ietf.org
https://www1.ietf.org/mailman/listinfo/asrg