Steve Campbell said the following on 6/21/06 5:37 PM:
The primary already does throw out invalid users. The backup relays to the
primary, thus two sendmail process need be started - the first on the backup MX
to relay and the primary to delete.
You should have both the primary and the secondary able to operate
independently of each other. Having a secondary MX depending on the
primary in order to reject or queue something kind of defeats the
purpose of its existence.
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.
Great idea, except the secondary has it's own access for primary users. Recall
that the primary for one domain is secondary for another domain. So unless I am
misunderstanding you, this might not work.
>
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.
Doing so with MIMEDefang via md_check_against_smtp_server would impose
additional overhead (especially on high volume servers) and useless log
entries.
The entire purpose is to eliminate backup MX spammers, but I cannot block them
wholesalely, as this is a backup MX for when the primary is unreachable.
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.
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
