On Monday 07 June 2004 08:51 am, Alan J. Flavell wrote:
> I don't know your exact situation,
That's true, Alan.
> so these are only some random
> thoughts which you might want to consider.
While your answer gave me some very good direction, my lack of better
explanation left some holes in your reply which are entirely my fault.
So I'm going to go ahead and fill in the blanks; thanks for bringing to
my attention that I improperly left them out of the original post...
> Well, I won't say outright that it isn't, but try this for logic: if
> the primary MX is willing to respond to callouts from the backup, why
> isn't it accepting the mail in the first place? The backup MX is
> only supposed to be used as a backup.
In a misguided attempt to make the post simple, I completely
misexplained the entire setup.
Actually it's like this:
Our system in question isn't backup MX at all; it's the primary MX, and
will be used for spam and virus checking for lots of domains running on
Sun Cobalt RaQs (and other older systems) which are still in heavy use
but which are woefully underpowered (and in the case of
sendmail-powered system, woefully underconfigurable) for the necessary
blocking and filtering.
Our system will be the only advertised MX for the domains for which
we're doing this.
The other systems won't even be listening on port 25. We'll be
forwarding the email on another port.
We'd like to use recipient callouts to see if the recipient exists
because it's the easiest way to keep track of which recipients exist in
real time.
If the "real" mailserver is completely down we can handle it in one of
several ways (your suggestions are welcome); we can either refuse all
email for the domains (we're doing spam and virus checking/blocking,
not backup MX), or we can suspend recipient checking and accept and
hold all the email, attempting to deliver it later. Which we'll do
will depend on how easy it is to somehow add on to the callout
mechanism to not use it if the system isn't reachable; that may be a
subject for another thread.
Our purpose in wanting to authenticate recipients is twofold; (1) we
want to refuse undeliverable email at receipt time, and (2) we want to
avoid overloading our server with checking for spam and viruses for
undeliverable addresses.
> Having the backup MX accept mail "blind" while the primary was down
> used to be a normal approach, way back; but it's getting increasingly
> untenable "thanks" to spammers and viruses which fake sender
> addresses: if you *do* accept mail "blind", you'll risk sending
> bounces to faked sender addresses when the primary comes back up,
> right?
Yes, but if we successfully identify the spam and viruses, we can throw
them away.
> But if the primary is where the list of valid addresses lives,
> then when the primary is down, the list of valid addresses isn't
> going to be changing much...?
Absolutely <smile>. But it's when it's up and changing that we'd like
to be in realtime, since our server will be the only advertised MX
server for the domain(s).
Now that I've better identified our needs and interests, do you, does
anyone, have any further suggestions or comments?
Thanks!
Jeff
--
Jeff Lasman, nobaloney.net, P. O. Box 52672, Riverside, CA 92517 US
Professional Internet Services & Support / Consulting / Colocation
Our blists address used on lists is for list email only
Phone +1 909 324-9706, or see: "
http://www.nobaloney.net/contactus.html"
