RW wrote: > On Sat, 06 Jan 2007 14:27:21 +1100 > Colin House <[EMAIL PROTECTED]> wrote: > >> Check out http://openspf.org - implementing SPF will help prevent >> spoofed emails from being delivered and will start to cut down on the >> "backscatter" > > This often claimed, but I don't really see how it's going to help much. > > 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. > > 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 addresses 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 accepting 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 their 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 is not spam; that is certainly not true. Of course, if the spammers do start using their own sacrificial domains to send spam, then the backscatter problem disappears too. Plus they open themselves to another line of attack against the registrars and DNS providers needed to pursue that strategy. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW
signature.asc
Description: OpenPGP digital signature