[EMAIL PROTECTED] 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:[EMAIL PROTECTED] OK TO:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] 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 _______________________________________________ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [email protected] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
