dave's cd player (dcd) is a simple command-line CD player. It plays CDs, loops (sequences of) tracks, plays tracks at random, and so on. Its a full featured, but simple-to-use CD player. It supports libmusicbrainz (musicbrainz.org) for CD information if desired, yet remains one of the leanest CD players out there.
Re: A lot of random comments
% Google for IMGate. It is a Postfix
> configuration designed to reject spam
> even before it hits the content filter.
Looks a lot like the configuration I've already got worked out. Not a bad program, though...
> Bayesian, unhappily, is individual, and
> definitely does not scale up at the MX
> server point, which is exactly where
> spam needs to be rejected.
Bloody shame, that. I wonder how hard it would be to modify SpamAssassin to keep separate databases on a per-email-address basis, even when it's processing all the email through a single account.
(Also setting up some sort of mail system so that people can train the Bayesian filters themselves. Maybe sending copies of spam to 'spam@somewhere' and have that get automatically added to the sender's filters. It'd obviously need to be made a bit smarter than that so a spammer can't train the system to think his spam isn't spam, but you get the idea. These are dialup customers using Windows and many of them don't even know what a mouse is. It needs to be relatively idiot-resistant...)
> % (Received: headers)
> You could tell amavisd-new not to insert
> those. It is a boolean option in the
> configuration file.
amavisd-new can only disable its own extra Received: header. Postfix still merrily adds its own.
> %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').
> Why are you accepting them in the first
> % It'd be nice
> % to put in a hotmail-style
> % "X-Received-From:
> Let your webmail client insert that
I want this to be added to incoming mail, not outgoing mail. No matter where an email comes from, it should have that IP header added.
I have subsequently learned that this just isn't possible with Postfix right now (or if it is, NOBODY knows how to do it).
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 <A
HREF="http://www.ipswitch.com/">IMail. I'm not happy about it either.
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
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. (<A
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 viruses
sitting around. :) Maybe Red Hat went out and "improved" Perl like they
did with <A
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 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 whatever...
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
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.
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
processing (this is covered in AMaViS' <A
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.
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 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" header.