Re: SPF (was: Re: Bug#257644: ITP: libspf2 -- Sender Policy Framework library, written in C)
>>>>> "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
Erik> I forward that to my roadrunner account without using SRS,
Erik> Roadrunner could use the SPF record on the original aol.com
Erik> envelope header to see that my university account is not a
Erik> valid mail agent for AOL.com. and block my forwarded files.
This is a problem completely orthogonal to your original post. Your
original post says that you're worry about the following sequence of
events, in an environment in which A@b.com, say normally receive
forwarded mails from his university, in the following way:
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.
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
trouble at all. And given that your university do not enable SRS you
have pretty much no option. So what it means is that *not* implement
SRS would force its users to receive spam, which shows that SRS is
part of an important weapon against spam. This is no worse than to
use no strategy against spam, and your recourse is of course to push
your university to use an MTA that implements SRS.
Erik> The only people involved in the blocking of my valid,
Erik> forwarded mail here would be AOL and Roadrunner... not me.
Current I still have no idea whether the popular choice of
implementation is to deliver the spam to the user and mark them as
spam for spam filtering, or to have the MTA directly filter out the
mail. Your concern would only matter in the second case. Most
in-house mail processing system will not delete those mails determined
as spam right away, so what it means is simply that you must ignore
the spam filter of your ISP. Again, it means that the lack of SRS
would force you to receive spam.
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
domains in mails being more reliable. System admins, by definition,
are people who have to continuously work towards making their systems
more usable to the user, and I believe that they will be happy to
provide the effort in making the MTA configuration.
Erik> Every single one of them will need to modify their .forward
Erik> scripts and patch their MTA's, etc. to use SRS.
Erik> This solution is an enormous amount of work for everyone on
Erik> the Internet.
This assumes that the amount of work needed for "everyone" is
"enormous". If this is the truth, then SPF simply won't take off. On
the other hand, I'm a bit more optimistic, and believe that the MTA
that most people actually use (e.g., sendmail, exim, postfix, etc)
will soon have SRS built-in, and to use it you only have to make a
configuration no more difficult than to enable forwarding in the first
place. (Indeed, I believe that it would be made difficult to
*disable* SRS in those mailers.)
Regards,
Isaac.
Reply to: