-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Steve,
Steve Campbell wrote: ...snip... >> >>>> Why don't you just use sendmail to trow them away? As others already >>>> pointed that out, you could provision your primary access database(s) to >>>> the secondary (or make the secondary use the primary's access.db over a >>>> TCP socket) and have sendmail do the rejecting without bothering >> MIMEDefang. > > 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. You're using sendmail properly. My setup is nearly identical to yours (only my primary MX is the primary MX for *ALL* my domains, and my secondary MX is the secondary MX for *ALL* my domains, that's the only difference) > >> 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. Distributed access lists, while providing an independant means of rejecting unknown users even if the primary MX is unavailable, is more of an administrative burden. Plus, if whatever system that provides the list of valid users for you to distribute to your secondary MX is unavailable, your access list will be out of sync and you could potentially accept messages for no longer valid users and somewhere down the road end up generating a DSN. > >> If your backup MX is unable to reject unknown recipients when the >> primary is unreachable, it would need either to accept and queue >> everything and then relay that to the primary, or to tempfail >> everything. The first could result in a lot of junk and useless bounces >> clogging the queues, the second would be equivalent to not having a >> secondary at all. > > Agreed, and the former is what it does at the present time. if your MX servers are decent hardware, and regularly monitored / maintained, your primary MX shouldn't be offline much (if at all) and this shouldn't really be a big issue. > > 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). > > It all used to be so simple. It's still pretty simple. The reason people are telling you you don't need MD is because you apparently JUST want to reject unknown users on your secondary MX. of course, if you wanted to implement AV and SA scanning into your MD filter, it makes sense to use it to do all of that, instead of using MD to only check recipients against the primary MX and then using other milters, etc to do the other functions. especially since you can do so much more with MD that could reduce (even more) the amount of mail that's being processed by your AV scanner and SA (like bogus HELO checks, greylisting, etc). Also, since your primary MX is the secondary MX for *SOME* of your domains, and your secondary MX is the primary MX for *SOME* of your domains, you essentially make this process more difficult. so you'd either need to manage nearline access/virtual domain lists carefully enough to know which is on which machine, or you'll need to write an MD filter that'll check against the proper primary MX machine based on which domain the mail is coming in for. then you'll have to take into consideration "what happens if one mail comes in for users in two overlapping domains?" (i.e. one domains's primary MX is the other domain's secondary MX) you could potentially use MD's stream_by_domain() functions, but then that'll basically nullify your ability to 5xx reject mail and force you to generate DSNs for even unknown users (which kind of defeats your purpose and everyone elses' arguments about rejecting mail) I would say that if you want to keep your (real) user accounts on two separate servers for certain domains, then your ideal setup would be to make each of those servers the primary MX for those domains respectively and then install one or more additional servers as backup MX for all domains. since a backup MX isn't intended to be used for much traffic, and only intended to queue mail if the primary MX is down, you should have problem using an old (lower-spec) machine to do this. I have my backup MX machine running multiple other functions (such as backup DNS) as well, since it basically just rejects mail on a regular basis since my primary MX is *rarely* offline. anyways, i hope this clears some things up and helps a bit. Alan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEnLkeE2gsBSKjZHQRAtWjAKDZnwpL0hwldhRi45gjJOFi0AqENgCfcN/d Z94R+ZIR2jrCTNKdMMgbB4I= =yjF6 -----END PGP SIGNATURE----- _______________________________________________ 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 MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang