[LINK] identifying mail forgery (was Re: Aussie IvP6 registrations)

[Craig Sanders]

On Sat, Jan 31, 2009 at 10:27:38AM +1100, Jan Whitaker wrote:
> Fortunately I've not had complaints. And yet, I live in fear that I
> might at some point because of the abuse of my domain and sometimes my
> own real address in spamming. And there's not a thing I can do about
> it, unless someone on here can advise what it might be. So far when
> I've asked, I've gotten no suggestions.
>
> There was a time when it stopped last month, about the time that major
> spam operation was caught and taken off 'air'. But it seems to be
> ramping up again with the same spoofed usernames on my domain name.

there's absolutely NOTHING you can do to prevent spammers from forging
your domain name.

what you can do, however, is make it easy to identify forgeries of your
domain.

one common method is to add Sender Policy Framework[1] (SPF) entries to
your DNS.

The basic idea of SPF is that you list all the hosts (by hostname, IP
address, netblock, etc) which are allowed to send mail claiming to be
from your domain.

any mail system that receives mail claiming to be from your domain from
an un-listed host can easily identify the mail as a forgery.


obviously, this works better if you have a static IP address for your
mail server and route all your outbound mail via that machine (e.g. by
configuring your mail client to use encrypted smtp auth to your own mail
server), but it can be done with a dynamic IP if necessary either by
listing all the IP addresses belonging to your ISP or, if your ISP has
their own SPF records, by referring to their SPF records in your own.



SPF is probably the easiest to get up and running, but there are other
mechanisms for enabling other systems to identify forgeries of your
mail.

DomainKeys Identified Mail[2] (DKIM) is another common method. it uses
cryptographic signatures to authenticate mail. it requires more work to
set up and integrate into your mail server, but it avoids the need to
pre-list all authorised hosts (as is required by SPF).



to summarise:

 - forgery prevention: impossible
 - enabling forgery detection: quite easy



References:

[1] http://www.openspf.org/

    (BTW, check the "Deploying SPF" section of the front page. it has
     a setup wizard for creating SPF entries to add to your domain)

[2] http://www.dkim.org/

craig

ps: neither of these tools will completely stop complaints - there will
always be idiots who can't read mail headers yet somehow feel qualified
to make definitive claims about guilt. and many mail servers don't
bother to implement either SPF or DKIM checking. but SPF or DKIM *will*
give you an easy answer that you can use to prove that the mail did not
originate from you or your system, and that if THEIR mail server were
properly configured (i.e. implemented SPF or DKIM checking) then the
spam would have been identified as a forgery.


pps: don't make the (unfortunately far too common) mistake of thinking
of either SPF or DKIM as spam prevention tools. they're not. they're
forgery identification tools. if you google either of them, you'll see
lots of people whinging about the fact that they don't block spam.
that's about as meaningful as complaining that cheese doesn't cut
through steel - they're not supposed to block spam, that's not their
purpose. their purpose is to identify forgeries. and it would be a damn
good thing if banks etc. used them. in fact, it would be an even better
thing if banks were required by law to use them on all email sent by
them.



-- 
craig sanders <cas at taz.net.au>