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"
[EMAIL PROTECTED] OK
[EMAIL PROTECTED] 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
_______________________________________________
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list [email protected]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
