public inbox for [email protected]  

help / color / mirror / Atom feed

From: Magnus Hagander <[email protected]>
To: Andrew Sullivan <[email protected]>
Cc: [email protected]
Subject: Re: Mail setup broken (still/again?)
Date: Tue, 16 Oct 2007 17:02:48 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>

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

view thread (15+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected]
  Subject: Re: Mail setup broken (still/again?)
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox