[conspire] Re: Linux program to remove mail from server?

[Rick Moen]

Quoting Bill Moseley (moseley at hank.org):

> Seems like you are asking for a (GUI?) client application to do things
> you shouldn't bother with.  Multiple POP accounts?  Why not forward
> all to a single server?  Or just use one address. (Seems like people
> that get the least amount of spam complain the most about. Rick, do
> you use multiple accounts?  What's your personal email volume
> like?)

My treatment of mail's a little eccentric:  I get absolutely all mail,
with one small exception, delivered to SMTP server (the
uncle-enzo.linuxmafia.com AKA linuxmafia.com machine in my living room),
where the mail remains and is never pulled down from.  That is, I
generally don't bother running any POP3 or IMAP services.

So, how do I get to my mail, you ask?  From wherever I am, I ssh to
linuxmafia.com, where GNU screen already has "mutt" running for me.  I
reconnect to my "screen" session to my ssh presence by typing 
"screen -d -r", and I'm right back where I left mutt when I last
detached.

One advantage is relative simplicity:  I don't end up with mail in
multiple locations -- and I have absolutely instant access to new mail,
the moment it hits uncle-enzo.  The main disadvantage is that I have no
_detached_ mail access.

The "one small exception" is that my wife kindly gives me a
"rick at deirdre.net" e-mail presence on one of her servers at Hurricane
Electric, which I use for my domain registrations, in order to ensure
that uncle-enzo isn't a single point of failure for reaching me to talk
to me about domain / DNS problems.  (It would be silly to require people
to send mail to uncle-enzo to tell me that uncle-enzo is down.)

My personal mail volume, including mailing lists, is probably several
hundred per day.  Procmail drops it off into several separate mbox
files, so I can have some hope of attending to the important mail first, 
and mostly ignore some high-traffic mailing lists such as debian-devel.

> Then use the tools that so many people are working with/on
> to do your filtering.

Incidentally -- and this, alas, will not help Edward, but I thought you
might be interested -- by far the best time to detect and deal with
incoming spam is _during_ the incoming SMTP session, prior to your SMTP
server accepting the mail.  uncle-enzo is set up to make maximal use of
that opportunity, doing quite a few tests of the IP address that's
attempting to drop off mail to identify spam hosts (and spam mail) right
then.  Almost all spam is detected and _rejected_ at that point -- not
accepted and then bounced or discarded later.

That's a key distinction:  It's much easier and more reliable to
accurately detect spam _during_ the SMTP session, as compared to after
acceptance -- and rejecting rather than bouncing means uncle-enzo is
never guilty of generating "secondary spam" in the form of bogus notices
sent to forged sender addresses.

The unfortunate bit is that such improvements are possible only to those
of us who run our own SMTP servers:  People who POP or IMAP their mail
from someone else's SMTP host are mostly at the mercy of the latter
site's antispam policy.

> Here's yesterday on my home machine (which are not all unique
> messages, btw):
> 
> $ wc -l /var/log/exim4/mainlog.1
>    4437 /var/log/exim4/mainlog.1

linuxmafia:/var/log/exim4# wc -l /var/log/exim4/mainlog.1
15329 /var/log/exim4/mainlog.1