--On 8 July 2009 14:25:36 -0400 Chris Lewis <clewis(_at_)nortel(_dot_)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(_dot_)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/
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg