> OK, so let me see if I have this straight. You're claiming that something we
> write into a standard is going to change future spammer behavior in a good
> and predictable way? I'm afraid I just don't buy it.
No, of course not. It's going to change the way that MTAs are set up
which will make it harder for spammers to abuse.
I completely fail to see how the availability or nonavailability of DNS
fallback behavior will lead to increased spam abuse. As I pointed out
previously, if spammers percieve an advantage to sending directly to
hosts named in A/AAA records they are going to do so no matter what. By
the same token, if they don't perceive an advantage they won't do it.
> I run several secondary MXes here and they are directly targetted by spammers
> all the time even when the primary is up and the standards clearly say that
> you shouldn't be sending mail to the secondary.
Right. That's one of the reasons I've been telling people for years that
unless your mail setup is on a really flaky connection, secondary MXes
create more problems than they solve, since they invariably create
blowback problems. Back in the day, when the net was slow and flaky,
secondaries were useful. These days, any BCP that recommended them would
just be wrong.
This reallly isn't relevant to the matter at hand, but whether or not
secondaries create problems depends critically on their ability to do filtering
and address validation. If their filtering is decent and they validate
recipient addresses they can be very useful indeed, even for relatively
reliable connections.
> The bottom line is that the spammers are gonna do whatever they want
> irrespective of what we specify.
Well, of course. The goal here is to specify something for the legit
operators to follow that will narrow the range for abuse by bad guys.
No, that isn't the goal at all. The goal is to get a revision to a
specification published that is suitable for a move to draft. In the process we
certainly don't want to open any new holes if we can help it, but it is NOT a
goal of this exercise to try and tighten things down. As others have stated
repeatedly, if you want to do that you need to stop objecting and start writing
additional specifications and building a consensus behind them.
This really isn't open for debate. The rules for this effort were laid out very
clearly by Tony and John, as was the DRUMS charter before that. If you wanted
to object the time for doing that is long since past.
> The goal here is to try and come up with an operational policy which, when
> implemented by legitimate operators, will result in the greatest amount of
> interoperability in the medium to long term.
I completely agree. But how does a design that maximizes the number of
false MTAs that can't easily be distinguished from temporarily broken MTAs
advance that goal?
It does so by not preventing a decades-old practice from continuing, one that
has yet to have been shown to cause significant harm. (And I will add that if
the current practice can be shown to cause harm that would call for a change to
the current fallback policy for A records and that in turn would have to be
dealt with in a separate document.)
>> sendmail that report back every two hours to say that your message hasn't
>> bounced yet.
> Um, well, maybe the people you talk to don't, but we spend a
> not-inconsiderable amount of time trying to convince some fairly large
> players that retry intervals of _five_ _minutes_ or less are
> inappropriate for INternet-directed traffic. And we don't always
> succeed, more's the pity.
That's not what I said -- there are plenty of MTAs with ridiculous retry
policies, but it's been a long time since I've seen one that sent a faux
bounce saying "it's been two hours and I'm still trying." Those are what
made people complain.
And that's exactly the sort of policy I was talking about: Five minutes before
complaining about unable to deliver.
> Actually, I'm not entirely sure what has changed, but right now the
> majority of the bounces I see personally are legitimate.
You're extremely lucky. I see as many as 400,000 bogus bounces a day on
my tiny network. This is a no kidding serious problem. I know people
who've had their networks knocked off the air by bounce storms.
> IMO the language in 2821bis is not ambiguous. The language in 2821 is. So if
> you're saying that the current language in 2821bis, which says to allow
> AAAA fallback, is OK, then I'm also good with that.
Well, then, we'll have to try to fix it, since for all the reasons I've
laid out, AAAA fallback will make the current situation worse. Since it
looks like people are bound and determined to do that, I guess millions of
MX . records will have to be a very poor second best.
I'm afraid you haven't even come close to making the case yet as far as I'm
concerned.
Ned