On Jan 25, 2007, at 6:32 PM, gep2(_at_)terabites(_dot_)com wrote:
OTOH, taking the definition of spam as Unsolicited Bulk Email
makes detecting a spamming IP address almost trivial.
I guess that depends on what you call "bulk", and how you propose
to detect it. Again, whatever rule you put into effect (on a
global-type basis) is going to be discovered by spammers and they
will engineer their sending patterns to avoid violating it.
[On second thought, I DON'T want to define spam as UBE. Labeling UBE
as spam labels the sender as a spammer which carries a negative
connotation. I just want to block UBE without calling anyone a
spammer and getting sued]
Here is my proposal. I'm sure I haven't thought of everything so
please tell me where it breaks or how spammers are going to game it.
The goal is to stop the majority of the spam while not loosing ANY
legitimate email (broken MTAs don't count). This is not intended to
replace existing blocklists but to handle the initial onslaught from
a spam source until the source can be properly categorized and listed.
Proposal #1 is a quarantine for new sources:
Connections from unknown source addresses would be initially rejected
by returning a temporary error code (4xx) for a probation period. The
probation period could be as short as 5 minutes depending on how fast
the blocklists can respond. The reject would occur after the
recipient list is accepted so the recipients can be checked against
local spamtraps and valid user lists. After the probation period,
global blocklists would be queried to find the current reputation of
Proposals #2 & #3 are for a fast global block advisory and
Any email addressed to a spamtrap would generate a report to a local
trap handler. The local trap handler would forward appropriate
reports to the regional or global blocklist managers. The blocklist
managers would publish advisories based on the reputations and counts
of the traps that were hit by the sending IP. If the source is
emitting a sufficient volume of spam this happens before the initial
probation period expires.
DNS is probably a poor choice for distribution of the global fast
response block advisories. I think a form of flood distribution
through a mesh of peer nodes would be more robust. The distribution
would feed local databases that could be queried directly or through
a DNS front end. The mesh can handle data from multiple sources and
needs no central authority.
Proposal #4 is back reporting unsolicited email:
If email addressed to certain spamtraps is received from a sender
that has registered to accept back reports, accept the mail but
return a specific code in the response that the sending MTA can
interpret to make a determination if the sender is spamming.
Alternatively, the site may register a different protocol to use for
the back report. The spamtraps used for back reporting should be
different from those reported to global blocklists to prevent
disclosing the traps to rogue ISPs that would forward them to
spammers. Only some of the traps would be used for back reporting to
any given network or host.
Proposal #5 is a quarantine while a site is listed in a block advisory.
Established sources that get listed in local or global block
advisories should have their mail quarantined while the mail is
sorted out. The best place to quarantine the mail is on the sending
server. It's already queued there and if it is eventually determined
that it should be rejected, that can be done with a 5xx on the next
delivery attempt instead of sending a bounce. If the sending ISP is
on their toes an offending user or host will be shut down quickly and
the remaining mail will be delivered when the block advisory is
lifted or expires. Local whitelists can be used to allow mail to
bypass the quarantine.
-- Dan Oetting
Asrg mailing list