Spam

[Robert Dinse <nanook@eskimo.com>]

     Over this weekend, I've installed a number of things to reduce spam. An
unfortunate side effect is that some legitimate mail will be blocked from sites
that are improperly configured or improperly secured.  There is no way to stop
or even slow down spam if mail is accepted from such sites.

     All of the facilities I have added at present will not delete mail without
warning, any e-mail not accepted will be bounced with an error that explains
why.

     The connecting host is required to have functional correct DNS, if it does
not e-mail will be rejected.  Spammers prefer relays with non-functional DNS
because it makes it harder to trace them and report their activity and there is
no legitimate reason for not properly configuring DNS, it is just not that
difficult and name server software is free.  This check was previously
partially in place but the check is more stringent now.  Before there was a
more obscure message, "Have you read DNS and BIND?", the intent being one that
system admins would understand but spammers wouldn't.  But as it turns out many
system admins didn't either so the error message is more straight forward.  It
will tell you that the relay host is not resolvable and to check your reverse
IP configuration (not my wording, I would have said inverse DNS and maybe I'll
change that).

     The 'mail from:' address is now checked.  If the address does not have a
domain portion, it is assumed to be local.  Before it was delivered whether it
was valid or not, but now, if the address is not a valid local address it will
be rejected.  This will get rid of at least that portion of spam that is forged
to appear to have originated here but from an account that doesn't exist.

     If the address is not local, it will be expected to resolve.  If it does
not it will be rejected.  This will get rid of spam forged with addresses using
invalid domains or domains that don't exist.  It will give an error message
that says the host is not resolvable, to check the reverse IP configuration,
and references an RFC for those that want to read further.

     The relay host and IP address are checked against a locally maintained
black list, if there is a match, the mail is rejected with a messaging telling
the sender that mail from thier IP address or host as the case may be, is
banned.

     The e-mail address and domain of the sender are checked against a
blacklist, and again if they match the mail is rejected and the sender is
informed that his or her e-mail address or domain, as the case may be, is
banned.

     Lastly, the relay host IP is also checked against the ORDB open relay
database, and if found the mail is rejected with a message giving a website for
further information.

     These things are in place now, and a big thanks to Jimmie Farmer for
pointing me at the necessary resources for doing this.

     Further things we are working on here is a spamtrap facility that will use
a number of spamtrap addresses scattered in the password file and extract relay
host information and add to the local blacklist in realtime, and remove them
after a short period.  This is intended to try to limit the damage spammers
that actively keep switching relayhosts and are careful to use hosts that
aren't presently blacklisted.

     And there are several other realtime blacklists I am considering.

     Lastly, I'm working on a "whitelist" facility, so that we can allow mail
from sites or individuals that are blacklisted in cases where we disagree with
the maintainer of the list or wish to make a specific exception to a broad
block.