> -----Original Message----- > From: James Pifer > Subject: SMTP Gateway with Spam Filters and AntiVirus > > > I company I do some work for is looking at spending a whole > lot of money on a product from sendmail.com that offers an > smtp gateway with spam filtering and anti-virus. > > I'm thinking they could save a lot of money by doing it > themselves using Redhat. I've searched the archives and > certainly found stuff on spam, like using Procmail, but I > have some questions that would clear up some confusion for > me if anyone has the time to answer. > > 1) If I run procmail do I need to run sendmail or will procmail do > everything? ie, receive mail, process it for spam, then forward to > another mail server, like Exchange, Lotus Notes, or even another > sendmail server for delivery to the user.
Procmail is a MDA (Mail Delivery Agent) i.e. delivers e-mail to a local mailbox. Sendmail, Exim, Postfix, etc... are MTA's (Mail Transport Agent). i.e. Accepts inbound mail and hands it off to procmail for local delivery. MTA's can also be configured to act as a gateway. i.e. Accept inbound e-mail, process it for spam and/or virus's, then relay to an internal email server (like Exchange). MTA's can also handle outbound mail. > > 2) I'm also thinking they should use DNSBL so I guess that means using > rblcheck? Would this then be using Sendmail, Procmail, AND rblcheck? DNSBL is typically done at the MTA level. i.e. sendmail, exim, postfix. > > 3) I see procmail mentioned a lot. Anyone think there is a > better way of doing it? Procmail is a great MDA, But your decision should be based on where the final delivery of e-mail is going to be. i.e. local or internal mail server. > > 4) Is there a open-source or inexpensive anti-virus solution available > for smtp servers? Can't help you here. > > For it to be worth it, I figure any mail that gets tagged as spam or > containing a virus will need to be held somewhere for someone to go > through it. For example, to make sure it really is spam. This would > need to be easy to do, it could be just a normal user like an HR > person who has to do this. It will also need to be fairly easy to > update the spam filters to adjust for email that gets through. For anti-virus, absolutely! Configure your anti-virus software to delete the virus from the e-mail. But I think you will find out that having a spam program dispose of e-mail will lead to frustration on your part. Employees will want there newsletters, etc... that will be tagged as spam (HTML). Your requirements may be different, but I decided to have spamassasin simply tag the e-mail as spam (within the header) based on it rules for identifying spam. Then have each user write an accept rule in Outlook to either accept/deny the e-mail. BTW: I have found spamassassin to be the best program at identifying spam I have ever used. Until I implemented SA, I was getting 60-70 spam e-mails a day. Now I get maybe 2-3 a week!!! All with one Outlook rule. > > I apologize if this exact question has been asked before. I would > appreciate any feedback you have or suggestions you may have. > For reference: I run sendmail as a front-end (MTA gateway) to an internal Exchange Server. The Exchange server runs the anti-virus software (Trend Micro). Sendmail is configured to process (tag) the inbound e-mails for spam using spamassassin. Since procmail is not used in any way, I use an MTA milter to intercept the inbound e-mail (at the MTA layer) and process it for spam before relaying to the Exchange server. Basically a milter splits an e-mail into header/body sections. Then each section (header/body) can be processed by spam software and/or antivirus software before being re-assembled for final delivery. ON the other side of the coin, if final delivery is local, then anti-virus/spam software can be called by procmail prior to it being stored in the actual mailbox. As you can tell, you have many options on how to implement spam/anti-virus. Steve Cowles -- redhat-list mailing list unsubscribe mailto:redhat-list-request@;redhat.com?subject=unsubscribe https://listman.redhat.com/mailman/listinfo/redhat-list
