[clue-admin] Mail issues

[Jed S. Baer]

Hi Folks.

Just to summarize and followup.

Crawford is still working on the Comcast block.

Roy has looked at RDNS. We're mostly OK there, but some ISPs might still
reject our e-mail for what is an extremely minor nit.

I don't know if these bounce messages (March 2 logwatch output) are due
to the nit, or a temporary lookup failure.

> E599B2D4C1E9: host depot.dial.pipex.com[62.241.162.107] said: 450
> Client host rejected: cannot find your hostname, [64.79.210.234] (in
> reply to RCPT TO command)
> CFF992D4CBD1: host smtp-in.iomartmail.com[62.128.193.140] said: 451
> 4.1.8 Possibly forged hostname for 64.79.210.234 (in reply to MAIL
> FROM command)

We are being (at least on a temporary basis) blocked by other ISPs.

> 8A82D2D4D385: host mx4.qwest.net[207.109.18.206] said: 451 4.2.1 mail 
> from 64.79.210.234 temporary greylist embargoed (in reply to end of
> DATA command)

> 6B4022D4D39C: host e.mx.mail.yahoo.com[216.39.53.1] said: 451 Message
> temporarily deferred - [250] (in reply to end of DATA command)
> 041872D4D376: host g.mx.mail.yahoo.com[206.190.53.191] said: 421
> Message temporarily deferred - 4.16.51. Please refer to
> http://help.yahoo.com/help/us/mail/defer/defer-06.html (in reply to
> end of DATA command)

The Yahoo page is saying, either your mail looks like spam, or someone
complained to us, so we're temporarily blocking you to get your attention
-- please look into it.

After looking at a sample of the logwatch output, there's such an
enormous amount of cruft in there, that finding issues which
really need our attention is difficult. This is in large part due to
spam.

For example, spammer sends an e-mail to a non-existent cluedenver.org
recipient, with a bogus sender address. We send out a bounce message, and
get a bounce message back. So the foreign bounce section of the report is
filled up with the chaff of messages generated solely from spam. Finding
bounce messages that need our attention is difficult, at best, in all
that cruft.

Another side-effect of spam coming to our server is that with the
forwarding we do for the admin aliases, it can look, to the receiving
end, as if we're sending the spam. This could get us blocked.

To whittle down these messages, there are a couple things we can do.

1) Crawford has suggested setting up SpamAssassin. I'm fine with that.
I'll even contribute my collection of spam for training it, though it's
pretty old. IIRC, Jeff has mentioned that the president address gets lots
of spam, but some legitimate inquiry. No reason for us to forward the spam
along, if we can stop it. If we toss spam into the bitbucket (or wherever
SpamAssassin sends it) we'll cut down on those spam-resultant bounce
messages.

2) We have a lot of e-mail addresses that can get e-mail from the outside
world, but in reality, never need to get any e-mail at all, not even
internally. For example, apache. Anyone looking at the /etc/aliases file
on their own machines can see what I mean. We can use the aliases file to
forward such email to /dev/null. In cases where these aliases need to get
mail internally (e.g. root gets cron messages, etc.), use procmail to
accept internal mail, and /dev/null the rest. We have a working
postmaster alias, so I can't think of any legitimate reason for root to
accept mail from outside.

I think we should be good netizens and do our part to dump spam when we
get it, rather than generating spurious bounce messages, and forwarding
it on where the aliase file says to. That will also help with us being
able to notice real mail problems when they occur (and hopefully prevent
some from occurring).

Anyone thoughts?

jed