[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: SPF (was: Re: Bug#257644: ITP: libspf2 -- Sender Policy Framework library, written in C)



Isaac To <iketo2@netscape.net> wrote in message news:<2mAvh-2Yj-33@gated-at.bofh.it>...
> >>>>> "Erik" == Erik Aronesty <erik@zoneedit.com> writes:
> 
>     Erik> It cannot be stopped by the client.
>     Erik> If someone from AOL sends email to my university account and
> 
> This is a problem completely orthogonal to your original post.  Your

Yes, but it was not orthogonal to the "it can be stopped by the
client" statement.

> ...
>   External mail => AA@univ.edu => A@b.com
> 
> and then a spammer says "let's register a throw-away domain", let's
> say "TA.com", and pretend to be relaying mails from V@aol.com through
> TA.com through the path
> 
>   V@aol.com => SS@TA.com => A@b.com
> 
> and thus make it seems like V@aol.com is sending to A@b.com, with
> nobody knowing that SS@TA.com is bad.  This certainly does not work,
> as SS@TA.com is not in the normal delivery path ofr A@b.com, so it is
> trivial (more or less) for A@b.com to drop the mail without even
> reading a single byte of it.

I see, this assumes that the client, not the ISP is dropping the mail
based on SPF, and that SPF filtering is never implemented by the ISP.
As long as ISP never use SPF to filter mail, I would agree that this
case is not a problem.

(1) In the real world, however, ISP's will use SPF to filter mail and
end users don't know their asses from their elbows when it comes to
"normal delivery paths".  So SPF filtering *will* break a lot of legit
mail.

> Your current concern is different: you are concerned that you, as
> A@b.com, will not be able to receive mails forwarded from AA@univ.edu
> because AA@univ.edu does not have SRS implemented.  But if you think
> clearly about it, the trouble comes only because you are running
> roadrunner with spam detection turned on.  If you don't, you've got no

As if you can tell Time Warner whether or not to turn spam detection
on?  The point is that SPF, as much as it prevents domain forgery,
equally gives ISP's a reason to block legit mail.

SPF makes claims to prevent spam.  Preventing domain forgery is not
spam prevention.  Domains are forged all the time for valid reasons.

>     Erik> Remember, millions of people forward mail like this in many,
>     Erik> varied ways.
> 
> But not every of them are system admins.  Only those system admins
> need to take action, and the rest can reap from the result that mail

Small business users with shareware mail servers are going to patch
their mail servers with SRS?  Perhaps.  Perhaps not.



Reply to: