Date: Sat, 06 Jan 2007 14:33:46 +0000 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: RW <fbsd06@mlists.homeunix.com> Cc: freebsd-questions@freebsd.org Subject: Re: Mail being sent from my domain... Message-ID: <459FB34A.9000507@infracaninophile.co.uk> In-Reply-To: <20070106133209.0cdda901@gumby.homeunix.com> References: <00bb01c73134$b061fa60$0a32a8c0@rob> <459F0D1B.7090608@tandon.net> <459F1719.9010407@optusnet.com.au> <20070106133209.0cdda901@gumby.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7A05E30CBA7EC3404433E08E Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable RW wrote: > On Sat, 06 Jan 2007 14:27:21 +1100 > Colin House <col-h@optusnet.com.au> wrote: >=20 >> Check out http://openspf.org - implementing SPF will help prevent=20 >> spoofed emails from being delivered and will start to cut down on the = >> "backscatter" >=20 > This often claimed, but I don't really see how it's going to help much.= >=20 > Any benefit relies on an initial MTA/MSA refusing to relay for domains > that don't set the correct SPF records, i.e. it replies on the security= > of MTA's that are owned, controlled or abused by spammers. >=20 > On the other hand setting SPF records means that more spam using the > domain will be rejected at the SMTP level. This actually leads to more > backscatter. Your reasoning is incorrect. The presence or absence of SPF records affects how the systems that are the targets of the spam attack work, and those are not in the control of the spammers. The ability of a mail system to realise by analysis of SPF records that the mailer connecting to it is an impostor that has no right to send mail from the falsely claimed sender address means that the message can be rejected early during the SMTP dialogue with a 5xx error (ie permanent delivery failure) even before the body of the message has been transmitted. At that point it is not yet the recipient's duty to send any delivery failure notification. Firstly this helps to discourage spammers from trying to forge e-mail addresses at all by lowering the rate at which they get their messages in front of their target audiences. It isn't by any means a perfect defence, but it certainly does help raise the marginal costs of the spammers and if that can be done widely enough, the spamming model will become uneconomic. Secondly, you are assuming that the software the spammers use to inject e-mail is compliant with the various standards (RFCs 2821, 2822 etc.) That is patently not the case: spammers typically use networks of compromised machines (indeed, there is actually a black market in the sale of such machines) with small, custom written, but fairly stupid software which in most cases can do little more than replay one side of an SMTP dialogue. This is why techniques such as greylisting, greeting-wait and tarpitting are so very effective. It also means that the spammers are not going to be sending bounce-o-grammes to the addresse= s they have forged: to do so will require them to actually write standards compliant software to install on their bot-net hosts, and that is (again)= going to drive up their marginal costs. Remember: it's the real MTAs which abide by the standards that result in the backscatter, but they only do that if they are badly configured and make the mistake of accepti= ng the message in the first place. SPF is by no means perfect. Indeed it has a quite obvious flaw: spammers= can just operate by creating their own throwaway domains and publish thei= r own SPF records for them. Not complying with SPF is pretty good evidence= that a message is spam, but the converse: that an SPF compliant message i= s not spam; that is certainly not true. Of course, if the spammers do star= t using their own sacrificial domains to send spam, then the backscatter problem disappears too. Plus they open themselves to another line of att= ack against the registrars and DNS providers needed to pursue that strategy. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW --------------enig7A05E30CBA7EC3404433E08E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.1 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFn7NS8Mjk52CukIwRCOQQAKCNxh3j0I/5rtWxSQdb7/fW4p5vOQCfYz5A Bkr8X60zBT/Jb4YVFfnKr60= =Sn5x -----END PGP SIGNATURE----- --------------enig7A05E30CBA7EC3404433E08E--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?459FB34A.9000507>