On Tue, Oct 16, 2007 at 10:07:50AM -0400, Andrew Sullivan wrote:
> On Tue, Oct 16, 2007 at 10:52:09AM +0200, Magnus Hagander wrote:
<snip>
> > 2a) Why do we even bother with secondary MXes since all they do is relay
> > back to svr1 anyway? It doesn't actualliy *help* us anything that i can
> > see, it only makes the configuration more complex.
>
> If svr1 goes down, the secondaries queue up the mail. This is a
> robust answer, and a good one, because it prevents mail from getting
> queued up all over the Internet.
Sure, but does it help us in any way at all? Why do we care where the mail
is queued up, reall?
> > 2b) If we do relay, then the secondary MX must *also* know the list of
> > users, so it can give a proper bounce.
>
> No. The classic way of relaying through a secondary that you
> normally don't use except in emergency is just to relay everything
> that arrives on the secondary. When it arrives at the restrictive
> server, that server bounces. You get into trouble from the soft
> error you're encountering, because if the user isn't in the map and
> that server is the final destination, then you really do need to
> bounce and be done.
If we reject it on the secondary MX, we'll be creating a whole bunch of
bounces for invalid addresses that spammers sent to. If our secondary MX
can just drop them, that never happens since they get a reject at the SMTP
protocol level.
> > infrastructure, thus making things a lot simpler and less likely to break.
>
> I don't think removing the secondaries makes things less likely to
> break; mail servers are easily overwhelmed and can produce soft
> errors all the time. Having store-and-forward secondaries is an
> extremely good idea, and I'd hate to see that feature abandones.
> Your other remarks are right on the money, though.
Well, we clearly don't entirely agree. But if we *do* want
store-and-forward secondaries, I would propose we use dedicated ones so we
can do things like push our own userlists over there.
//Magnus
