Re: [Asrg] Too Big to Block?

Ian Eiloart <> Thu, 09 July 2009 09:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BD5273A680F for <>; Thu, 9 Jul 2009 02:29:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.452
X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5oN4h+VchiWj for <>; Thu, 9 Jul 2009 02:29:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CFA103A6C83 for <>; Thu, 9 Jul 2009 02:29:44 -0700 (PDT)
Received: from ([]:52636) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from <>) id KMID2H-0006VO-MX for; Thu, 09 Jul 2009 10:30:17 +0100
Date: Thu, 09 Jul 2009 10:30:11 +0100
From: Ian Eiloart <>
To: Anti-Spam Research Group - IRTF <>
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <20090708155704.GN15652@verdi> <>
Originator-Info: login-token=Mulberry:01gE/oa+mwVtDBvDzN7HXzxFve5scJxeN19bo=;
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Sussex: true
X-Sussex-transport: remote_smtp
Subject: Re: [Asrg] Too Big to Block?
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <>
List-Id: Anti-Spam Research Group - IRTF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 09 Jul 2009 09:29:50 -0000

--On 8 July 2009 14:25:36 -0400 Chris Lewis <> wrote:

> John Leslie wrote:
>>    More useful is something like, "Hotmail MTA #49 is sending more spam
>> than usual right now: more severe graylisting might be called for."
> What good does graylisting do to a real MTA?  Unless MTA #49 is sending
> you enough email that forcing it to requeue causes it problems, it won't
> do anything useful.

It represents a cost to the provider for being sloppy about their account 
management. And, a cost to their users for sticking with an irresponsible 
provider. It's hard to tell your own users, "we don't accept mail from 
Hotmail because some of it's spam", but you might get away with "email from 
Hotmail often takes an hour or two because we need to check that its not 

And you could, in principle, quarantine a copy of the message during the 
greylist interval (eg, using Exim's "fakedefer" facility). That message 
could be compared with others, to give more accurate content based spam 
scores. You might want to lower your spam threshold if you see several 
copies to distinct recipients, or even from distinct senders.

Or, it could be manually inspected and then rejected next time it is seen. 
I'd like to have some kind of GUI tool that allowed me to see copies of 
greylisted messages in quarantine, so I could flag them up for rejection 

In fact, you could even give such a tool to a user - perhaps putting it 
behind a "this is spam" button!

Finally, if the provider is using SPF or DKIM, and you have a match, then 
you can safely blacklist the sender if you're certain they're spamming. 
That's the beauty of reliable identification mechanisms - it lets me 
blacklist sender addresses in the knowledge that I've got the right address.

> We've tended to let our automated defenses "fire where they may".  If MTA
> #49 is sending us so much spam that the defenses fire, they fire, and we
> don't whitelist.
> If the problem gets bad enough, we block /24s worth.  With MSN and Yahoo,
> that turns out to work particularly well, because at least with Nigerian
> floods and their provisioning methods, specific /24s tend to be
> substantially worse than others.
> Then we make a big public & private noise.  And sometimes things get
> better.
> _______________________________________________
> Asrg mailing list

Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see