Dave Carrigan wrote:
Maybe you need no re-think the requirement to scan at SMTP time. I also prefer that, but statistical scanning is so much more powerful than anything else that I finally gave up on SMTP scanning and moved todelivery-agent scanning, just so I could use statistical methods. Ham/Spam reporting is done by forwarding false positives/negatives to a special address.
Which to me is kludgy. It is because it is adding a slew of headers that aren't needed. It also relies on the person knowing how to forward in a particular format. It introduces statistics which are meaningless in the final analysis. One also has to lock down those addresses to prevent contamination from outside sources. For example, spammers sending mail to the ham address. :P
Is there a particular reason that you need SMTP scanning?
I do not believe it is right to accept and then silently drop messages. If the MTA is going to reject the mail then that should be reflected at SMTP time so that the other side, if they are legitimate, will get an indication of the problem in their logs. Silently dropping the message means it is far harder to track down problems. The remote side sees that it was accepted. The local user sees that it never arrived.
If one isn't silenting accepting yet isn't rejecting at SMTP time then one is polluting the general 'net with bounces to forged addresses. Rejecting at SMTP time places the onus of the bounce squarely where it deserves, on the machine sending it. If they are an open vector for spam/viruses they'll get complains about their idiot bounces. If the other side is a spam engine or virus w/SMTP the odds of them generating a bounce are slim to none.
Because of those two factors if one is doing global virus/spam checks then one should clearly reject at SMTP. This, however, does not mean that the *user* cannot do their own filtering after delivery. In fact my personal mail goes through two bayes DBs. The first is the global DB and the second is the one maintained by Thunderbird. Nothing ever said that mail that gets through the first layer should be treated as if it's status were positively assertained. However when the user does their own filtering it again places responsibility where it properly deserves to be. IE the owner/maintainer of the MTA can say that his logs are accurage. He reported 250, the message was delivered. It must then be something in the user's configuration which caused the message to disappear.
So SMTP time rejection is not under discussion. It remains. The global bayes DB is not under discussion. It, too, remains. It has worked exceedingly well and when one knows the limitations and possibile ramifications one can control it. I know the limitations. I know the possivle ramifications. I prefer to reject as much as safely possible at SMTP time to lower the overall cost for myself and my users.
That being said, Cyrus fits the bill for everything you want except the mbox requirement. But, there are plenty of scripts around that can migrate mbox onto an IMAP server, so that's not necessarily a showstopper. Cyrus 2.1 works just fine with Squirrelmail, and it supports shared folders with full ACLs. Plus, after you move your mbox messages into the Cyrus message store, they're available from anywhere.
Except for the local machine unless I'm mistaken in that mutt and elmo can access Cyrus' DBs directly? :P
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------
Attachment:
signature.asc
Description: OpenPGP digital signature