Powerful anti-spam rule that never discards valid e-mail
David F. Skoll
As part of the development of my commercial anti-spam solution CanIt
(http://www.canit.ca/), I discovered a powerful anti-spam rule that I'm
sharing with the Sendmail community.
Empirical evidence suggests about 35-45% of spammers use special software
to spam from home computers rather than relaying through legitimate MTA's.
More empirical evidence tells me that this special spamware ignores
temporary-failure codes, never retrying a failed message.
Therefore, my CanIt product allows you to return a temporary-failure code
at the MAIL FROM: phase for a sender you've never seen before. (It keeps
a database of all known MAIL FROM: senders, and tempfails new entries.)
If you have many people at your site, you can keep a database of MAIL FROM:
per RCPT TO:, and do the tempfail at the RCPT TO: phase. (Your database may
grow rather large in this case.)
If you're worried about legitimate mail being delayed, just give your
mail server another IP address and publish it as a secondary MX record.
Legitimate MTA's will immediately fall back to the "secondary" MX,
and will be accepted (the MAIL FROM: is already known, now.) Spamware
will never retry.
Try it. This simple rule is amazingly effective. I should probably
patent it, but I hate software patents, and I'm disclosing it now
to establish prior art in case someone else tries patenting it. :-)
Regards,
David.
Neil W Rickert
>Empirical evidence suggests about 35-45% of spammers use special software
>to spam from home computers rather than relaying through legitimate MTA's.
>More empirical evidence tells me that this special spamware ignores
>temporary-failure codes, never retrying a failed message.
I agree with that observation, although I don't know whether the
percentages are correct.
>Therefore, my CanIt product allows you to return a temporary-failure code
>at the MAIL FROM: phase for a sender you've never seen before. (It keeps
>a database of all known MAIL FROM: senders, and tempfails new entries.)
I have thought about such an idea, but haven't tried to implement
it. There is an obvious downside (see below).
>If you have many people at your site, you can keep a database of MAIL FROM:
>per RCPT TO:, and do the tempfail at the RCPT TO: phase. (Your database may
>grow rather large in this case.)
>If you're worried about legitimate mail being delayed, just give your
>mail server another IP address and publish it as a secondary MX record.
>Legitimate MTA's will immediately fall back to the "secondary" MX,
>and will be accepted (the MAIL FROM: is already known, now.) Spamware
>will never retry.
A slight correction here. Some of the spamware will start at the
secondary MX, and then work up. So your method won't be effective
against that spamware if you add the second address.
>Try it. This simple rule is amazingly effective. I should probably
>patent it, but I hate software patents, and I'm disclosing it now
>to establish prior art in case someone else tries patenting it. :-)
Good for you.
The downside -- if your approach becomes popular, the next generation
of spamware will do more retries.
It also does nothing about the big time abusers who retry messages
multiple times even after "550 User unknown"
Andrzej Filip
> "David F. Skoll" <d...@roaringpenguin.com> writes:
>
> >Empirical evidence suggests about 35-45% of spammers use special software
> >to spam from home computers rather than relaying through legitimate MTA's.
> >More empirical evidence tells me that this special spamware ignores
> >temporary-failure codes, never retrying a failed message.
>
> I agree with that observation, although I don't know whether the
> percentages are correct.
>
> >Therefore, my CanIt product allows you to return a temporary-failure code
> >at the MAIL FROM: phase for a sender you've never seen before. (It keeps
> >a database of all known MAIL FROM: senders, and tempfails new entries.)
>
> I have thought about such an idea, but haven't tried to implement
> it. There is an obvious downside (see below).
Some MTAs I have seen use default retry period of 2h.
> >If you have many people at your site, you can keep a database of MAIL FROM:
> >per RCPT TO:, and do the tempfail at the RCPT TO: phase. (Your database may
> >grow rather large in this case.)
>
> >If you're worried about legitimate mail being delayed, just give your
> >mail server another IP address and publish it as a secondary MX record.
> >Legitimate MTA's will immediately fall back to the "secondary" MX,
> >and will be accepted (the MAIL FROM: is already known, now.) Spamware
> >will never retry.
>
> A slight correction here. Some of the spamware will start at the
> secondary MX, and then work up. So your method won't be effective
> against that spamware if you add the second address.
You can make the same host serve primary and secondary IP address.
Delivery attempt to primary of "unseen" sender/recipient pair may create short
"ready to accept" window for deliveries to secondary IP.
> >Try it. This simple rule is amazingly effective. I should probably
> >patent it, but I hate software patents, and I'm disclosing it now
> >to establish prior art in case someone else tries patenting it. :-)
>
> Good for you.
David, You have lost your chance to patent it outside USA by publishing it :)
> The downside -- if your approach becomes popular, the next generation
> of spamware will do more retries.
>
> It also does nothing about the big time abusers who retry messages
> multiple times even after "550 User unknown"
--
Andrzej [pl>en: Andrew] Adam Filip http://www.polbox.com/a/anfi/
*Random epigram* :
"Let's not be too tough on our own ignorance. It's the thing that makes
America great. If America weren't incomparably ignorant, how could we
have tolerated the last eight years?"
-- Frank Zappa, Feb 1, 1989
David F. Skoll
> Neil W Rickert wrote:
>> A slight correction here. Some of the spamware will start at the
>> secondary MX, and then work up. So your method won't be effective
>> against that spamware if you add the second address.
A lot of spamware never retries, ever. Remember, the goal of spamware
is to make sending millions of messages very cheap. Retrying failed
messages slows you down and increases your cost.
> You can make the same host serve primary and secondary IP address.
> Delivery attempt to primary of "unseen" sender/recipient pair may create
> short "ready to accept" window for deliveries to secondary IP.
That's what I meant, or you can have two different MX machines sharing
the same database (CanIt uses PostgreSQL to store its data.)
>> It also does nothing about the big time abusers who retry messages
>> multiple times even after "550 User unknown"
That can be handled with other methods.
There are some second-order problems, such as mailing lists that use
"disposable" sender addresses (they change for each outgoing message),
but the solutions to these are straightforward (if tedious) and CanIt
handles them correctly.
--
David.