On Thu, 2004-03-11 at 21:33 -0800, Greg Connor wrote:
The problem with this is:
when the primary MX host is actually down
which assumes that spammers will not target the secondary MX,
There are two ways to consider what you're saying.
Firstly, without context. On its own, the phrase "when the primary MX
host is actually down" does not make any assumptions. It's merely a
statement of a condition. So I disagree.
Secondly, we could consider it in context. In particular, consider it in
the context of
<1078868976(_dot_)17344(_dot_)5(_dot_)camel(_at_)imladris(_dot_)demon(_dot_)co(_dot_)uk>
in which
I said "backup MX servers ... perform recipient verification callouts so
that the only time they may accept a mail which eventually gets accepted
is if the primary is _actually_ uncontactable at the time".
Again, no assumption is made that spammers won't contact the secondary
MX when the primary is running. The secondary will call out to the
primary to verify the address, and will accept mail to invalid
localparts only of the primary is _actually_ down, as I said.
Please do credit me with the intelligence to say what I mean.
which is a known bad assumption.
It would indeed be a very stupid assumption to make. With that I agree.
That is what Wayne meant by "it is more than just the potential" and from
experience I would have to say I agree with him.
Then Wayne wasn't paying attention either :)
An "accept-then-bounce" strategy IS abuse. It is cost-shifting. Someone
else can eat their crap mail and not complain, because you can't be
bothered to configure both servers the same. It may have been common
practice before, but general agreement now is that accept-then-bounce is
considered harmful. If you can't configure the secondary correctly,
consider not publishing a secondary at all.
Like I said, I accept-then-bounce _only_ in the case that the secondary
cannot contact the primary to verify an address, for those domains for
which I provide MX backup only and not primary. That's a _rare_ case.
Domains for which I provide primary MX services _do_ share their user
table. It's actually done with TXT records in a private DNS domain, and
the owners of each domain can update their aliases with DDNS.
Um, yeah. Carl at AOL is working hard to correct all the
accept-then-bounce situations, but it's going to be tough to reform all
their MTA's to do this. But they are trying.
Good. I think everyone agrees that accept-then-bounce should be avoided
as much as possible. However, my point was that if you _cannot_ avoid
accepting the mail in the first place, it's better to accept-then-bounce
spam than to accept-and-drop valid mail.
For 'cannot' in the above, read 'have not yet implemented a scheme which
allows you to'. I have not yet implemented a scheme which allows me to
verify local users at domains for which I provide MX backup, when the
primary is uncontactable. That's not easy, when the primaries belong to
other people and run extremely varied configurations with different
MTAs. But since the secondaries almost always _can_ contact the primary
to do recipient verification callouts, it's not a problem I lose sleep
over.
Strangely enough, I just started doing this for altavista.com - forged,
bounced mail will now be rejected with a 454 message. Hopefully this will
fill up the mail queues of irresponsible admins who accept-then-bounce.
That's an interesting idea. I currently give a 5xx rejection to bounces
to dwmw2(_at_)infradead(_dot_)org (which address never sends email, qv.). Giving
4xx errors would cause it to stay on their queue...
On the other hand, I half suspect that those who can't be bothered to
fix their mailers to reject mail at SMTP time are _also_ unlikely to
bother to watch their mail queue or logs. We'd cause the offending MTA
to keep retrying for a few days and then the mail would bounce anyway,
and a lot of the owners of these machines wouldn't even notice the
difference. I would though, in my own logs. It'd probably annoy me more
than it'd annoy the offenders :)
--
dwmw2