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:31:33 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

On Tue, Oct 16, 2007 at 11:22:46AM -0400, Andrew Sullivan wrote:
> On Tue, Oct 16, 2007 at 05:02:48PM +0200, Magnus Hagander wrote:
> > 
> > Sure, but does it help us in any way at all? Why do we care where the mail
> > is queued up, reall?
> 
> We can't control the policies on all those servers, and some of them
> may not queue as long as we like.  Also, it's polite to have more
> than one mail server, and not force others to queue mail when you
> have an outage.  This is part of the reason one has more than one MX
> possible, after all.
> 
> > 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.
> 
> You mustn't _ever_ "just drop them".  Yes, I know people are doing
> that instead of bouncing, but it's wrong, bad, evil, and completely
> in contradiction of the totally plain MUSTs in the relevant RFCs.  

I meant reject, not drop. But it's better for us to reject them at the SMTP
level than it is to generate our own bounce.

> I think you meant refuse, though, which is a different matter.  It's
> not actually hard to rsync the user map among the various servers
> using postfix (I do it myself), so that seems to me to be an
> alternative, yes.  And that can be done with multiple user lists.

As do I, so yeah, it's fairly simple. But if you have to interface with an
external system (in this case, hub.org) that makes things a lot more
complex quickly.


> There is another thing we could do, BTW, to try to reduce the
> spam-induced bounces, and still have multiple servers in place.  What
> you do is add an MX with priority 0 that always gives a soft error. 
> Most spambots won't try the next MX, so your "real" MX (with, say,
> priority 1) doesn't get the spam attempt.

Hmm. Interesting idea :) But I'm not sure how big of a problem that part
really is.

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