[Mimedefang] COMMANDS file including invalid e-mail addresses

[Sven Willenberger]

james.madill at duke.edu presumably uttered the following on 05/16/05 17:29:
> A recent bout of spam illuminated an issue that I would like to eliminate.
> 
> The SMTP gateways I run MIMEDefang on both relay messages to internal hosts as well as act as local hosts for the institutional e-mail address format.  An anti-spam package ahead of these SMTP gateways tags each incoming message with a 'spam score'  if this score is higher than either the defaults or the recipient's personal settings, the message is quarantined, shunted to a seperate server for viewing or releasing, and eventual automatic deletion.
> 
> The spammer sent out massive amounts of mail to bogus accounts @ our institutional address domain.  The result was that despite sendmail indicating to the sending host that an e-mail address was invalid, that address was included as a recipient in the MIMEDefang COMMANDS file.  Once there, the message was acted on as if the address was a valid one and mail would be quarantined for a non-existant user.
> 
> I haven't yet been able to track down whether it is MIMEDefang including the these invalid addresses, or sendmail passing them on to the milter as if they were indeed valid.
> 
> Does anyone know what I might be able to do to eliminate these invalid addresses from appearing in the COMMANDS file?
> 
> 
> -- James

We use sendmail access list to to allow email only for legit users 
through the system. Our inbound gateway relays are not the local 
destinations so we store our users in a database. As users are added or 
deleted a script updates our access file; the result is that any email 
to a non-existent user get bounced at the gateway before having to be 
parsed by anything. Sample entry:

TO:mydomain.com		REJECT
TO:user1 at mydomain.com	OK
TO:user2 at mydomain.com	OK

and so on. Using delayed checks we even have entries for users who don't 
want rbl checks enabled. I have written an mc file for sendmail that 
checks the access file for:
SPAM:user2 at mydomain.com	FRIEND
and if that is there, then it does RBL checks and simply marks headers 
... the next series of servers in the chain then invoke mimedefang/SA to 
do SURLBL and content checking. If the user is not listed as a "SPAM 
FRIEND", then any email that fails RBL checks gets rejected at the 
gateway again.

We find this both gives the end user the option of choosing to have RBL 
blocks or not (or even which ones courtesy of some procmail scripts on 
the LDA end of things) and saves a lot of wear via unnecessary 
processing of emails.

This type of system dramatically reduced the load throughout our entire 
email system once we had it fully implemented.

Sven