Received: from localhost (unknown [200.46.204.191])
	by postgresql.org (Postfix) with ESMTP id 04BEC9FB489
	for <pgsql-www-postgresql.org@postgresql.org>;
	Tue, 16 Oct 2007 12:02:53 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.191]) (amavisd-maia, port 10024)
	with ESMTP id 19721-04 for <pgsql-www-postgresql.org@postgresql.org>;
	Tue, 16 Oct 2007 12:02:50 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.5
Received: from svr2.hagander.net (svr2.hagander.net [88.198.128.226])
	by postgresql.org (Postfix) with ESMTP id BF3129FB3F1
	for <pgsql-www@postgresql.org>; Tue, 16 Oct 2007 12:02:49 -0300 (ADT)
Received: by svr2.hagander.net (Postfix, from userid 1000)
	id 02F19DCC936; Tue, 16 Oct 2007 17:02:48 +0200 (CEST)
Date: Tue, 16 Oct 2007 17:02:48 +0200
From: Magnus Hagander <magnus@hagander.net>
To: Andrew Sullivan <ajs@crankycanuck.ca>
Cc: pgsql-www@postgresql.org
Subject: Re: Mail setup broken (still/again?)
Message-ID: <20071016150248.GJ22159@svr2.hagander.net>
References: <20071016085209.GD22159@svr2.hagander.net>
	<20071016140750.GF3255@crankycanuck.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20071016140750.GF3255@crankycanuck.ca>
User-Agent: Mutt/1.5.11
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200710/102
X-Sequence-Number: 12689

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