Re: not delivering, and History of fallback to A
2008-03-30 14:38:51
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 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.
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.
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?
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.
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.
R's,
John
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
Re: not delivering, and History of fallback to A, John R Levine
- Re: not delivering, and History of fallback to A, ned+ietf-smtp
- Re: not delivering, and History of fallback to A,
John R Levine <=
- Re: not delivering, and History of fallback to A, ned+ietf-smtp
- Re: not delivering, and History of fallback to A, John R Levine
- Re: not delivering, and History of fallback to A, Hector Santos
Re: not delivering, and History of fallback to A, Dave Crocker
Re: not delivering, and History of fallback to A, Russ Allbery
Message not availableRe: not delivering, and History of fallback to A, ned+ietf-smtp
Re: not delivering, and History of fallback to A, Dave Crocker
Re: not delivering, and History of fallback to A, Keith Moore
Re: not delivering, and History of fallback to A, Frank Ellermann
|
|
|