David,
----- Original Message -----
From: "David F. Skoll" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, July 12, 2006 9:57 AM
Subject: Secondary MX (was Re: [Mimedefang] What is the order of things
thatoccur)
Chiming in...
If you are going to have a secondary MX machine, then it should have
knowledge of all local accounts on the primary MX machine, and this
knowledge
should be accessible even if the primary is down. That means some kind
of periodic synchronization of user lists from the primary to the
secondary. Be aware that there may be windows in which the secondary
rejects a recipient the primary would have accepted, or vice-versa,
but if your synchronization interval is small enough, it's probably
an acceptable tradeoff.
Creating, and syncing a user database, would be the proper way to go if dual
MXs are used. I agree. My first thread's replies convinced me of that. Just
getting management to go along with it is a huge problem here. It's just not
"their idea".
md_check_against_smtp_server was *not* designed for a secondary to
check against a primary. It was designed for people who use an
Internet-facing MIMEDefang box as a front-end to relay to their real
mail server. In this situation, the real mail server can reasonably
be expected to be highly-available (and if it's down, then it's OK for
the MIMEDefang box to tempfail.)
I still see this as being the same situation, in some instances, and to some
degree, my situation. Other than the real purpose of MX records in the DNS
scheme, MX records are become an advertisement for spammers to use to decide
where they can attempt to send mail. A single MX gateway could fail, leaving
all incoming mail to tempfail. A backup gateway could be just that, a
machine that is inserted for the failed machine. Or it could be a secondary
MX, but still acting as a gateway to the mailstore and always online.
In my case, the secondary MX is acting as a second gateway to my primary
MX+mailstore. The primary is highly available. But because it is a published
MX, it attracks spam. The "designed" purpose of md_check_against_smtp_server
is, in some ways, being used correctly here, as it does what it should do
when you consider it is running on a gateway. It's the design of my mail
system that is not being used properly. And the distributed user base would
fix that. Unfortunately, the 'suits' won't let me fix that for now. (Maybe
I'll just do it behind their backs)
I didn't write the md_check_against_smtp_server code, and can't pretend to
say what it really is for. I just feel that the way it is being used here,
and whether it is correct in usage, is a matter of what needs to be done in
the time and situation I have here.
Thank you very much for chiming in. I have not been on this list very long,
but always feel comfortable with your words, and respect them very much. I
realize that my words above may sound adverse to what you say, but I really
do agree with you wholeheartedly.
Steve
Regards,
David.
_______________________________________________
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
_______________________________________________
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
