Using Sendmail Queue Groups & Per User (long)

[Jim Flowers]

On Thu, 9 Oct 2003 15:53:48 -0700, Ken Anderson <ka at PACIFIC.NET> wrote:

>Jim Flowers wrote:
...
>> But the main  thing that I am looking for is to configure an efficient,
>> flexible mail relay that can select virus and/or spam scanning on a per
>> domain and per user basis.
>>
>
>I'm already splitting multiple recipients at the MTA level using queue
>groups, but I'm interested in what you are doing. Can you post your
>changes to sendmail.mc or sendmail.cf? I like the idea of whitelisting
>at the MTA level. It would save MS/SA some work.
>
>Also, it would be nice to put messages that are sent to multiple
>recipients and ARE split into single recipient messages by sendmail into
>lower priority mailscanner queues, since 99% of them are spam. When a
>MTA is configured to split messages, and it gets hit by 1000 x 10 recip
>per messages spams, it tends to put quite a load on the system as they
>are all expanded to 10 x 1000 messages, scanned and deleted or
quarantined.

Ken,

I don't have anything that I can post/send yet as I am treading carefully
using production servers that I temporarily modify on the fly.  For the
general approach, look at the perl code in 'mailstats' (
http://www.while.homeunix.net/mailstats/ ).  This program, among other
things, watches the maillog for rejected IPs and when found, adds a
blacklist entry to the 'access' database and removes it after (tunable) 48
hours.  Regex is weak but that is fixable.  You might also want to look
at 'spamilter' (http://www.wanlink.com/spamilter/) which takes a similar
approach but is a milter that adds/deletes rules to the ipfw ruleset
(FreeBSD) to block the tcp/ip connection so that even DNS activity is
avoided.

Ultimately, I want to reject all inbound mail that is not destined for a
local or relayed user.  I read in the sendmail docs and it is clarified in
the sendmail newsgroup that recipients matching an 'access' tag
Spam:thisuser at thatdomain.tld FRIEND will apply specifically to that user
and will not affect the other recipients in the same envelope.  At that
point in check_rcpt the recipient user has been identified and will skip
check_mail and check-relay, bypassing any dnsbl processing for thisuser
while not affecting the processing path of the message for the other users.

I am not sure exactly where the queuegroup processing takes place but it
seems reasonable to assume that it is late and follows the routing
function of gathering up all the filtered and unfiltered (tagged)
recipients that go to a single destination and writing the qf file to the
mqueue-in directory.  What I propose here is to use an 'access' tag of
MQUEUE:thisuser at thatdomain.tld outqueue to put messages for thisuser
directly in the mqueue directory bypassing mailscanner entirely.

In this way, user whitelisting of a recipient for sendmail check_* and
dnsbl processing is combined with user whitelisting for mailscanner
processing.  I think it will work to whitelist sendmail alone, or sendmail
+ mailscanner but whitelisting mailscanner alone depends on the queue
group processing being per recipeient.

I like the idea of using queue groups with maxrcptpermessage=1 to just
split the messages but Steve Swaney pointed out this could really increase
traffic.  Not too bad, as the destination mailservers are on the same
network.  So this would allow true per user whitelisting within
mailscanner.  Thanks for the posting reference.

In the frontend sendmail processor, exisitence of local recipients is
checked during check_rcpt, rejecting messages and saving bandwidth.  For
relayed mailers, however, everything is accepted.  This is particularly
burdensome with so many spammers just opening a circuit and then throwing
a dictionary of names at it with RCPT commands.  So the next step is to
implement a check_rcpt routine that verifys that the destination
mailserver has such a user, accepting mail, something like the milter-
sender ( http://www.snert.com/Software/milter-sender/index.shtml) does for
sender email addresses