Mail being sent from my domain...

[Matthew Seaman]

RW wrote:
> On Sat, 06 Jan 2007 14:27:21 +1100
> Colin House <col-h at optusnet.com.au> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20070106/85d81b08/signature.pgp