Logan Shaw wrote:
On Mon, 19 Jun 2006, David B Funk wrote:On Mon, 19 Jun 2006, Justin Mason wrote:
[snip]
OK, if that's the case, let me offer my own personal justification of why it might be worthwhile to combine greylisting with SpamAssassin. Basically, greylisting has an achilles heel: legit messages from unknown senders are delayed a long time. This is fine for certain types of organizations, but what if all the accounts on your mail server are for salespeople? They're constantly trying to generate new contacts and leads, and they really don't want their communications to be delayed. This is just one example; there are surely other people who don't want any delays that can be avoided. So, what does this have to do with greylisting + content-based filtering? It's simple: if you receive a message from an unknown sender / domain / IP / whatever, you can then do a spamassassin run on it. If it comes up with a very low score (almost definitely not spam), let it pass. If it comes up with a very high score (almost definitely spam), drop it right away. If it comes up with an indeterminate score, apply the greylisting approach and delay it until later. What does this buy you? Two things. The first is that low-risk messages (based on content) go right through, eliminating much of the downside of greylisting. The second is that for messages which SpamAssassin is unsure about, you get the added benefit of greylisting. By definition, SpamAssassin by itself is insufficient in these cases, so any extra information you can gather (i.e. whether the sender retries) is valuable information. To put it another way, greylisting has a high cost in terms of convenience. So, apply greylisting only when SpamAssassin is not confident in its judgement; in those cases, you can easily justify the cost, and in the other cases, you can avoid the cost of greylisting completely. - Logan
I've been following this thread closely... and I have a few thoughts on how SA could be used... as a feed back loop device.
Currently in SA is the AWL, we all know this is a table of senders, ip's, mail count, and total scores. If one has a good AWL database - then this could be used in part of the graylist decision. In my mind, how this could work is:
1) Message comes in, check against AWL, if sender/ip pair do not exist, send the tempfail, if sender/ip pair do exist: 2) Check the average score against some threshold (say 4 points as a figure.) If sender's score is over this value (still at the header stage) send tempfail, if the sender's average score is below:
3) Send the message on through to the AV's, SA, etc.. 4) SA will adjust the totals, rinse and repeat. This to me has 2 good effects:1) Uses graylisting as an efficient means to stop spam (early on in the SMTP conversation.) 2) Integrates SpamAssassin in what it does best, scoring. Thus feeds back to the graylisting mech.
Of course, this assume that the standard table of senders, ip's, and their last try time are kept. Along with whitelist/blacklist entries. I think this is a good use of SpamAssassin, graylisting and our tight IT budgets for processor time.
My $0.25 worth. -- Thanks, JamesDR
smime.p7s
Description: S/MIME Cryptographic Signature
