Secondary MX (was Re: [Mimedefang] What is the order of things thatoccur)

[Steve Campbell]

David,

----- Original Message ----- 
From: "David F. Skoll" <dfs at roaringpenguin.com>
To: <mimedefang at lists.roaringpenguin.com>
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 MIMEDefang at lists.roaringpenguin.com
> http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
>