Re: Mail setup broken (still/again?) - Mailing list pgsql-www

On Tue, Oct 16, 2007 at 10:52:09AM +0200, Magnus Hagander wrote:
> 1) Tries to deliver to svr1.postgresql.org. This machine response that the
> user is unknown, *but does so with a 450 error code indicating that this
> is a temporary error*. This is of course wrong, it should be responding
> with 550.

This does appear to be an error.

> 1b) Also, that machine is supposedly named "postgresql.org" for some reason
> that I don't really understand.  But the MX rcord still points to svr1,
> which is an alias. (I don't say this should be fixed, because I don't see

Nit: it's not an alias; if it were (i.e. a CNAME or probably a
DNAME), it would be an error, because MX records can't point to
CNAMEs.  It's just another name for the same address, which is
perfectly acceptable.  It does seem a little baroque.

> 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.

> 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.

> 2c) mx3 is then *graylisted* by svr1. A backup MX must *NOT* be graylisted
> by the primary machine. I know I have mentioned this several times before
> wrt other machines.

Absolutely.  

> 3) At the risk of soundling like a real broken record again, we really
> need *some kind of basic documentation* of this system.

+1

> 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.

A

-- 
Andrew Sullivan  | ajs@crankycanuck.ca
A certain description of men are for getting out of debt, yet are
against all taxes for raising money to pay it off.    --Alexander Hamilton