Re: Why SPF and DK are not being used

James A. Donald wrote:
>
>     --
> Chris Drake wrote:
> > all authentication schemes are being actively avoided
> > by every responsible ISP, because when they activate
> > these schemes - they find they they are preventing
> > their own customers from being able to get emails
> > through to recipients.  
 But there's a difference here btw SPF and DKIM approaches. See below.
> If an ISPs customer wants to
> > sned an email form their own address when not using
> > the ISP's mail server - it's going to get rejected if
> > the ISP has SPF etc in place (unless the customer
> > knows how to use SRS).  As a responsible ISP -
> > ensuring your own customer emails reach their target
> > is a much higher priority than helping to stop random
> > strangers who are not your customers from receiving
> > spam that forged the ISPs domain.  Why would anyone in
> > their right mind do harm to their *customers* in order
> > to help **strangers**???   THAT's the reason none of
> > this stuff is widely deployed - it's got little to do
> > with filter tools.
>
> Rejecting emails on the basis that they are not SPF
> authenticated is foolish, for there are many innocent
> reasons why an email might fail authentication.
I think that's a bit too strong. If an organization wants to use SPF and 
is willing to accept that its users cannot use other mail servers, and 
indicates this in its SPF record, this seems of use - the remaining 
problem are forwarding services, and I admit that requiring all of them 
to adopt SRS or similar schemes is a problematic approach; plus, user 
agents that are willing to present the original `from` (or `on behalf of 
` - i.e. the PRA & submitter `trick`), are failing the goal, since users 
of such forwarding services are still subject to spoofing (by a rogue 
forwarding agent sending to the honest forwarder). Anyway, I think this 
list is not a spam one, I think we are getting off topic and probably 
much more clarifications are needed for everybody to follow this 
discussion, so I better stop here (btw I have a lot of foils about 
anti-spam in my `secure messaging and e-commerce` course in my site, and 
also a pretty extensive overview of spam, both available from my 
homepage http://AmirHerzberg.com).
>
> I guess  many people have now seen this message six
> times, so I had best stop repeating it.  But
> nonetheless, now the seventh repetition:
>
>     Authentication without reputation management is
>     useless.  The purpose of authentication is to
>     support reputation management. DK and SPF are
>     attempting to walk around on one leg.
I agree on the importance of reputation and/or penalty mechanisms 
(that's where most of my work in this area is). However, I think you are 
a bit carrying it too far. DKIM, and even SPF, allow organizations to 
use whitelisting ; that's already valuable (and of course, it is also a 
basic reputation system, so you are not wrong - but I still think that 
this clarification is needed to avoid confusion - not all people realize 
that blacklists and whitelists are repuation/penalty mechanisms).
>
> Repeating my previous two posts in slightly different
> words:  What needs to be done, and is not being done, is
> to attribute reputation to the originating domain on the
> basis of the quality of the emails that *are* SPF and/or
> DK authenticated, and then attribute quality to
> authenticated emails on the basis of the reputation of
> their originating domain.  If email fails authentication
> that is a weak reason for rejection.  If an email passes
> authentication, then we can apply an additional test:
> the reputation of the originating domain.
Right.
>
> SPF and DK is not being used correctly on the client
> side.  This makes it useless, indeed dangerous, to
> recipients, and useless to legitimate senders.
>
>     --digsig
>          James A. Donald
>      6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
>      fcRA2K9ZPwRchjhPLqwaBigOHca0bbrrtd1MotTT
>      40IL8CIuRLubJR1esD5UmdzI26SCcBY7BT/Ss0pDL
>
>
>
> .
>

Received on Sunday, 18 June 2006 05:55:41 UTC