[Mimedefang] Should I try to do MIMEDefang with Mailscanner forbackup MX
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.
More information about the MIMEDefang