Re: A lot of random comments
> Random comments... (I'm in the process
> of rolling out a setup similar to
> this for a smallish local ISP, and have
> already started testing with a
> couple hundred guinea pigs, er, brave
> dialup customers)
> For historical reasons, we're using
> IMail. I'm not happy about it either.
Google for IMGate. It is a Postfix configuration designed to reject spam even before it hits the content filter.
> Anyway, our experimental setup is this:
> We set a domain's MX record in DNS
> to be the Postfix system, it processes
> mail through AMaViS and friends,
> then hands it off to the "real" mail
> server specified in Postfix's
> transport_maps database.
> I've had no problems getting viruses to
> be logged properly, with Perl
> 5.8.0. I'm not using Red Hat, though,
> nor am I using ClamAV. (Slackware,
> and the boss spent the $500 on F-Prot
> for Linux.) Actually, I've only sent
> the EICAR "test virus,"
> as nobody in our office has any real
> sitting around. :) Maybe Red Hat went
> out and "improved" Perl like they
> did with GCC
AFAIK, you will have no problems with the RedHat supplied Perl so long as you fix the UTF8 probelms with RedHat (They turn it on by default, you need to fix the LANG environment setting).
> 2.96 a while back?
> For a system-wide rollout, you may also
> want to disable SpamAssassin's
> Bayesian rules, or at least give them a
Bayesian, unhappily, is individual, and definitely does not scale up at the MX server point, which is exactly where spam needs to be rejected.
> much lower weight, since they
> supposedly don't work nearly as well
> when the database isn't tuned to the
> individual user. One man's trash is
> another man's... oh, skip it. I'm sure
> there are a few dial-up customers out
> there interested in enlarging their
> naughty bits, or enjoying goatse.cx or
> The AMaViS configuration file isn't
> nearly as bad as these examples make
> it look. For instance, the destiny
> settings have NAMES, not just numbers.
> ($final_virus_destiny = D_BOUNCE and so
> on). They're also heavily
The author might have been using a slightly older version.
> commented, such that by stripping out
> all the examples that didn't apply
> to me, the config file was easily
> reduced in size by half.
I wouldn't do that. The documentation in the config files doesn't take up all that much space and is very helpful when you need to make a change.
> There's a LOT of other things you can do
> to speed up the whole Postfix ->
> AMaViS -> Postfix-again routine. A
> daemonized virus scanner (this is why
> we bought F-Prot), using LMTP instead of
> SMTP for parts of the mail
SMTP will send all recipients through at one shot. LMTP is a one recipient at a time protocol, allowing for finer grained control of the spam filtering.
ClamAV has a daemonised mode, clamd, which works quite well.
Ralf Hildebrandt has a good howto on tuning Postfix, and figuring out system bottlenecks.
> processing (this is covered in AMaViS'
> file and in amavisd.conf itself).
> And yes, a couple RFCs for people who
> have set up something similar to
> Should I strip out the two added
> Received: headers? (the one added by
> amavis, and the one added when amavisd
> hands mail back to postfix). They
> could just be confusing.
You could tell amavisd-new not to insert those. It is a boolean option in the configuration file.
> Any preferences on the destiny settings?
> Right now, viruses get
> D_BOUNCEd, spam is just plain D_REJECTed
> (but there's so many bogus
> mailer-daemon things sitting in the
> queue, I'm tempted to just make that
> one 'delete'). If possible, I'd like to
Why are you accepting them in the first place?
Postfix 2.x will not accept mail for unknown recipients by default.
> get this right before rolling it
> out to the other 5000 mail accounts. :)
> (swinging desperately off-topic) Can
> postfix be configured to add
> arbitrary headers to email? It'd be nice
> to put in a hotmail-style
> "X-Received-From: your.ip.address.here"
Let your webmail client insert that header.
I hope this helps.