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