Q:
What happens when spammers adapt and try to get around the
techniques described in this document?
A:
Well, that depends. :-)
Some of the checks described (such as SMTP checks and Greylisting)
specifically target ratware behavior.
It is certainly possible to imagine that this behavior will
change if enough sites incorporate these checks. Hatmut
Danisch notes:
Ratware contains buggy SMTP protocols because they didn't
need to do any better. It worked this way, so why should
they have spent more time? Meanwhile
"ratware" has a higher quality, and even the
quality of spam messages has significantly improved. Once
enough people reject spam by detecting bad SMTP protocols,
spam software authors will simply improve their
software.
That said, there are challenges remaining for such ratware:
To get around SMTP transaction delays, they need to
wait for each response from the receiving SMTP server.
At that point, we have collectively accomplished a
significant reduction in the rate of mail that a given
spamming host is able to deliver per unit of time.
Since spammers are racing against time to deliver as
many mails as possible before DNS blocklists and
collaborative content filters catch up, we are improving
the effectiveness of these tools.
The effect is similar to the goal of Micropayment Schemes, wherein the sender spends a few
seconds working on a computational challenge for each
recipient of the mail, and adds a resulting signature to
the e-mail header for the recipient to validate. The
main difference, aside from the complexity of these
schemes, is that they require the participation of
virtually everyone in the world before they can
effectively be used to weed out spam, whereas SMTP
transaction delays start being effective with the first
recipient machine that implements it.
To get around a HELO/EHLO check, they need
to provide a proper greeting, i.e. identify themselves
with a valid Fully Qualified Domain Name. This provides for
increased traceability, especially with receiving Mail Transport Agents that do not automatically insert the
results of a rDNS lookup into the Received: header of
the message.
To get all of the Sender Address Checks, they
need to provide their own valid sender address (or, at
least, a valid sender address
within their own domain). Nuff said.
To get around Greylisting, they need
to retry deliveries to temporarily failed recipients
addresses after one hour (but before four hours). (As
far as implementation goes, in order to minimize machine
resources, rather than keeping a copy of each
temporarily failed mail, ratware may keep only a list of
temporarily failed recipients, and perform a second
sweep through those addresses after an hour or two).
Even so, greylisting will remain
fairly effective in conjunction with DNS Blacklists that are fed from Spam Traps. That is because the mandatory
one-hour retry delay will give these lists a chance to
list the sending host.
Software tools, such as Spam Scanners and
Virus Scanners, are in constant evolution.
As spammers evolve, so do these (and vice versa). As long
as you use recent versions of these tools, they will remain
quite effective.
Finally, this document is itself subject to change. As the
nature of junk mail changes, people will come up with new,
creative ways to block it.
Fedora Core 4 Tutorial
