[Mimedefang] Should I try to do MIMEDefang with Mailscanner forbackup MX

Atanas mimedefang at asd.aplus.net
Fri Jun 23 21:23:05 EDT 2006


Steve Campbell said the following on 6/23/06 1:42 AM:
> I'm getting the feeling that I am not using sendmail properly with regards to
> mail accounts. Right now, whenever I need a new mail account, I just create a
> new user on the box. Imap and pop accounts are then available when needed. I
> dont add anything to the access files for users. For now, I just use the access
> files for spam, blocking IPs, and the like.
> 
Actually no, on the primary you are doing that right. It's me who 
wrongly assumed that you already have all valid mail boxes listed in 
your access database.

I primarily deal with non-standard sendmail setups hosting virtual 
domains (e.g. multiple mailboxes and multiple domains per single user) 
via local delivery agent (LDA) like procmail and maildrop, where 
sendmail acts as a middleman between the sender and the LDA.

For your standard sendmail setup (i.e. one mailbox per user and no LDA) 
on your primary MX you don't really need that list in your access.db. 
Sendmail already knows how to deal with non-deliverable messages and 
effectively rejects them before entering the queue.

   1. Sender <=> Primary MTA -> Mailbox

On your secondary MX however, the situation is quite similar to my 
virtual domain setup. Here's what your delivery chain looks like:

   2. Sender <=> Secondary MTA <=> Primary MTA -> Mailbox

and here's mine:

   3. Sender <=> Primary MTA <=> LDA -> Mailbox

In both cases (#2 and #3) there's one middleman - your secondary MTA or 
my primary MTA. I have also longer delivery chain with two middlemans in 
case mail comes in through my secondary:

   4. Sender <=> Secondary MTA <=> Primary MTA <=> LDA -> Mailbox

In all of the above scenarios, leaving at least one middleman with no 
clue about the destination end point what's valid and what not, creates 
a gap which depending on the mail volume (or a dictionary attack for 
instance) could quickly get filled with useless junk floating around.

For example, some years ago the Primary MTA for case #3 was initially 
set up to accept mail for all mailboxes within all locally hosted 
domains, and the rejecting was left to the LDA. This resulted in so big 
queues full of useless and undeliverable bounces, so most of the mail 
server resources were going for handling junk.

>> You could deliver the primary's access database to the secondary somehow 
>> (via scp/rsync, ftp, etc. like in every 5 minutes or so, or just when 
>> your primary access database gets updated, e.g. when you add a new 
>> mailbox) and merge both access files before building the access.db. Thus 
>> the secondary MX will always have all the information needed to reject 
>> mail coming to non-existing recipients for both of your domains.
> 
> My paragraph above sort of explains why this won't work, since my access file
> doesn't contain much. I'll look and see what it has, though, and maybe I can do
> something with it. 
> 
Here's what my access DB entries look like:

domain1.com           ERROR:5.1.1:"550 User unknown"
mbox1 at domain1.com     OK
mbox2 at domain1.com     OK
...

Entries could be prefixed with "To:" if you like (check the sendmail's 
cf/README for details), but without that it also should work fair enough.

You might need to write a little script that takes all user accounts 
(i.e. valid mailboxes) from your primary, creates a similarly formatted 
list and pushes that to the secondary when needed. Sendmail does not 
need to be restarted on each access DB update, it will pick up the 
changes right after you "makemap" the access.db.

> I kept wondering why everyone kept saying I didn't need MD, and now I see why.
> I'll have to rethink my entire access scheme. At the moment, all mailboxes for a
> domain are on the primary MX. If mail goes to the backup MX, it gets relayed,
> but only because I relay the entire domain to the where the mailboxes are (the
> primary MX for the domain).
> 
MIMEDefang is an excellent piece of software. It can do anti-virus (via 
third party virus scanners) and anti-spam (SpamAssassin) content checks. 
It can reject after the SMTP data phase leaving the unpleasant work of 
generating and sending bounces to the remote parties, which leads to 
shorter mail spools. It's very customizable. It's efficient, ..., ...

I have several mail filtering machines (just about to add the next one) 
dedicated to run only MIMEDefang and its dependencies, Clamav and a 
home-grown greylist. I have another bunch of mail servers with sendmail 
connected to these mail filters over TCP sockets, and the entire thing 
works very well.

Regards,
Atanas



More information about the MIMEDefang mailing list