[ On Tuesday, February 6, 2001 at 11:07:52 (+0100), Marc Haber wrote: ]
> Subject: Re: [Exim] How to get rid of bounces on a secondary MX?
>
> People demand it. So we do it.
Are you sure? Do they really know what they're asking for? Have you
ever challenged them and asked them to explain exactly, and technically,
why they need such a service? Do they really understand what the
purpose is and what problems it causes in the modern Internet?
I suspect most people would only have answers such as "Well I read about
it in a book", or "Some dim-witted consultant I hired said I needed
one!" Tell them such advice lost its relevance for the real big-I
Internet back in 1985 or even before, and was almost certainly totally
wrong by 1995.
> Define "configured properly". We have adopted the hubbed_hosts setup
> from the FAQ 0301(B), but we don't have (read: don't want to have) a
> list of valid addresses on our downstream hosts. So, we deliver to our
> downstream, and if that machine decides to refuse an address, fine.
> But I don't really want to see that kind of bounce - it should go to
> the sender, but not to our postmaster mailbox.
Well, that was a bit of an over-statement perhaps....
If I understand correctly the problem is that you are seeing "bounces"
that are sent to your system since it is an MX for the target domain in
questoin, but which your mailer cannot deliver (the customer's mailer
gives an SMTP error code instead of blindly accepting everything your
mailer tosses at it).
In this scenario there is no way to win but to refuse to act as an MX
and to refuse all messages to the target domain at the SMTP level.
That is unless you can convince your customers to configure their
mailers such that they do not ever refuse any mail at SMTP time...
That's a far less than ideal situation for the customer though.
There is really no way for everyone to win with secondary MX's unless
you own outright both mailers and all of the domains they handle. If
you don't own both mailers and/or don't have final say on all
deliverable mailboxes in every domain then will undoubtably cause a
loophole in any policies established on the primary and you will receive
undue load on the postmaster mailbox at the secondary(ies).
Just wait until you get more spammers sending with an empty sender
address (i.e. "<>"), and choosing your MX host instead of first trying
the primary MX. This is happening to many folks now. The only (sane)
solution is to refuse to be a secondary MX for anyone any more.
> I know. Do I really make the impression of being _that_ stupid?
Oh, no! I'm just trying to be thorough and make sure none of the
corners have been left undisturbed! ;-)
> Mail comes in for the internet for foobar@??? from
> sender@???. mx.we.example.com accepts mail,
> spools it, delivers it to mx.customer.example.com.
> mx.customer.example.com says "500 unknown local part foobar in
> <foobar@???>. mx.we.example.com generates bounce to
> sender@???, copies to
> postmaster@???. This is the scenario I am talking about.
Does the bounce get delivered successfully to the sender?
If so then you want to simply turn off errors_copy (it is supposedly off
by default)! [In smail it is called error_copy_postmaster, and I get no
end of complaints from people who turn it on without thinking and then
say they get too many bounces! :-)] Unless you're debugging something
you do not ever want to see copies on all bounces!
If on the other hand the problem is that you're seeing bounces of
bounces, then you're just going to continue to suffer until you refuse
to be a secondary MX for anyone's mailer/domain but your own.
> Yes, they are getting charged for that anyway. But I am looking for a
> way to hide bounces for causes that I know that I am not the cause
> for.
The other thing you could do is simply tell every customer who insists
on having a secondary MX that they can only achieve this configuration
by co-locating one at your facility (and of course paying you full
co-location fees), assuming of course that you offer this co-location. :-)
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwoods@???> <robohack!woods>
Planix, Inc. <woods@???>; Secrets of the Weird <woods@???>
