At 13:11 4/20/2004, you wrote:
Just to add my $0.02:
Your $0.02 was welcome, Rick, and very interesting to read. May I ask that next time you trim the previous $2.75 worth of messages from your reply?
I normally do, but the content kinda indicated I should leave it alone.
I'm using FC1 on a bunch of load-balanced SMTP servers. These are also running clamav-milter and bogofilter via procmail.
Do you have notes on how you set those up? I'm working on Ben Weiss's notes to write a Simple Mailserver HOWTO and I would love to have more information.
Oh, wow. My configuration is anything but simple, as I'm hosting about
10,000 domains and 60,000 users. I'll describe it below, so if you don't want to read how I did it, skip this message now.
There are actually two SMTP clusters--one for outgoing (relay) mail
(which we call the "SMTP" cluster) and one for incoming mail (what the domains' MX records point at and which we call the "MX" cluster). The
POP and IMAP clusters are also involved in this.
Users must, at least, check for incoming mail via POP3 or IMAP4 or a Web interface (which is a front end for IMAP4) before they're allowed to send any mail. The users are authenticated against an LDAP database (their records are RFC2307-based with a bunch of extensions to support our stuff).
If they're allowed in, the LDAP server logs their client's IP and the
current time. The pickup server (POP or IMAP) then fetches and delivers their mail to their client.
If they wish to send mail, they use our SMTP cluster. When they connect and give us the "mail from:" header, we check the sender address against the LDAP database. If it's in there, then we compare the client IP address from the LDAP record against the socket. If they match AND the current time is less than 15 minutes since they did a POP or IMAP session, they are allowed to send the message. If not, the connection is dropped with an appropriate error message issued.
The purpose of this is to block open relay attempts. You must be a user and domain we handle, you must connect from the same IP you last fetched your mail from, AND you must send your mail within 15 minutes. The mail is scanned via clamav-milter for viruses before it goes out. If it is a virus, the message is simply deleted. We don't bounce virus messages since, with Klez and Bagle, the sender address is bogus anyway. Why clog up our servers with useless bounce messages?
The incoming mail cluster will only accept mail where the "rcpt to:" header matches a user and domain we handle. The mail is scanned via clamav-milter for viruses. If it is contaminated, the connection is dropped with an error message and the messages is thrown away. The user's account in LDAP is checked for allowed mailbox size. If the box is too big, the connection is terminated with an appropriate error message.
The message is then handed from sendmail to a program called "mailwedge". This program checks the user's LDAP data for autoresponders and forwarding information. If the user has an autoresponse set up, mailwedge creates the message (adds a "Re:" to the subject, swaps the sender and receiver addresses and puts in the text specified by the user) and queues it for sending at this time.
If the message is to be forwarded, mailwedge handles that next by rewriting the "To:" to "Originally-to:" and adds a "To:" header with the forwarding address and queues the message for sending.
If, after all that, the message is to be put in their mailbox, mailwedge then feeds the message to procmail. Procmail has a recipe to run the message through bogofilter, which adds an "X-Bogocity" header depending on the message's "ham" and "spam" ratings and the message is finally delivered to the user mailbox.
Like I said, it isn't trivial. It IS all done with open-source software, with the exception of mailwedge (which is a beast I wrote), the extensions to the standard LDAP schema and a whole lot of tweaks to sendmail.cf.
And before you ask, no, I can't GPL mailwedge without the boss' approval. I wrote it on company time so I don't hold the copyright.
----------------------------------------------------------------------
- Rick Stevens, Senior Systems Engineer rstevens@xxxxxxxxxxxxxxx -
- VitalStream, Inc. http://www.vitalstream.com -
- -
- Do not taunt the sysadmins, for they are subtle and quick to anger -
----------------------------------------------------------------------
