In <20040325135911(_dot_)GA37479(_at_)uk(_dot_)tiscali(_dot_)com> Brian Candler
<B(_dot_)Candler(_at_)pobox(_dot_)com> writes:
I'm hoping that as soon as I add SPF to my domain it'll cut all these
bounces
and in turn eventually stop the joe-jobbing
It's very unlikely that you'll see a significant decrease in joe-jobs in the
short to medium term, since the vast majority of MTAs will ignore your SPF
records.
I agree that in the short term, SPF will do little to reduce bounces,
but hold that thought.
My suggestion would be to choose a solution which fits the problem. If your
problem is that you receive lots of joe-job bounces, the solution is to use
SRS-style sender cookies in the envelope of your outgoing mail, as
documented on this list. It's an instant solution which doesn't require
cooperation of anyone else on the Internet.
I agree that using SRS on all outgoing email can be very useful. It
doesn't solve as many problems as SPF does and it has different costs
which make impractical for certain cases, but using more than one
defense has it's own advantages.
Implementing SPF breaks perfectly valid and established practices, such as
mail forwarding, and risks losing legitimate bounces.
For better or worse, forwarding is already broken due to the number of
people who have already implemented ad-hoc and home-grown SPF-like
checks. SPF accelerates this trend, but anyone who cares about
forwarding needs to deal with the issue anyway.
As far as risking losing legitimate bounces, that can only happen if
the sending MTA is misconfigured to send the wrong string in the HELO
command or if they have the SPF record misconfigured. Detecting such
errors early when bounces can be created is the reason why I advocate
always checking the HELO string (for SPF "deny"), not just on bounces.
(2) The disease will mutate
It's so trivial for spammers and virus writers to bypass SPF, that it would
happen almost overnight. When you send mail from exampleisp.com's IP address
space, send MAIL FROM:<anyrandomuser(_at_)exampleisp(_dot_)com>. Cleverer
spam and
virus writers will also use other domains which SPF permits from that IP
address (or which do not declare SPF information); such information is
easily located in the DNS.
First off, most domain owners who publish SPF records do not open up
their entire address space to being authorized to use their domain
name, they only open up their mail servers. So, your example won't
work.
However, the fact that spammers and worm authors will react by not
using domains that publish SPF records is a huge *FEATURE*. There are
far fewer spammers and worm authors than MTAs, domains or email
users. If all you need to do to prevent spammers from using your
domain is publish SPF records, then you don't need a significant
number of mail servers checking SPF records. You will get almost
complete protections when only a small fraction of the MTAs start
using SPF.
This of course does not make spam any easier to trace. Anyone with half a
brain cell would be able to tell that the mail came from exampleisp.com by
looking at the Received: headers. The Return-Path: header is a red herring.
The From: header, which the vast majority of users see, is unaffected.
[snip]
The disease which SPF attempts to fix is "untrustworthiness of
envelope-sender information", which means the Return-Path: header on
delivered mail. In some instances it may check the EHLO name which appears
in a Received: header. Both are invisible to normal users.
Wait, you say that "anyone with half a brain cell would be able to
tell" because of the Received: headers, but then you say that the
Received headers are invisible to normal users.
I disagree with both of these claims. Correctly tracing through the
Received: headers can be tricky in large part because spammers try
hard to trick people. Also, enough people know how to look at the
headers (but not correctly parse them) that having your domain name
show up in them will cause you abuse-desk problems.
I agree that we need to also tackle the RFC2822 headers such as From:,
Sender:, Resent-*:, etc. That is, for many reasons, a harder
problem, and I'll start working on that after I get done with the
easier problem of the envelope-from.
(4) To have any effect it requires 100% deployment across the Internet
No, it will have a significant effect long before then.
(5) It gives no additional information to identify spammers
Domains give you nothing else, and it's far easier to get fresh domains than
fresh IP addresses.
Domains *do* give you much more information in the form of the Whois
registration information. Domain Registrars require you to pay money
to get a new domain, so there is a money trail that can be tracked.
The name servers of a domain name can not be changed very quickly and
tracking the name servers is already a common way of detecting
spammer's domain names.
What would this final solution look like? I think:
[long discussion deleted]
Let me know when you have actual code that implements your ideas.
-wayne