Subject: [Asrg] Quarantines and block lists

From: Dan Oetting <[email-masked]>
Date: Fri, 26 Jan 2007 01:14:01 -0700

On Jan 25, 2007, at 6:32 PM, [email-masked] 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  
the source.

Proposals #2 & #3 are for a fast global block advisory and  
distribution network

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg