--On 8 July 2009 14:25:36 -0400 Chris Lewis <clewis at nortel.com> 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 spam".
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 later.
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 Asrg at irtf.org http://www.irtf.org/mailman/listinfo/asrg
-- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/