>> [... that] doesn't seem like much of an argument compared to the
>> advantages laid out in my last message of having hosts default to not
>> being mail servers.
> I assume you're referring to the problem of mail sitting in the queues
waitinfg
> to be delivered to a system that's never going to accept it. I'm afraid I
don't
> buy your reasoning on this one either.
> 10 years or so ago this used to be a real issue - we used to get customer
> complaints all the time about stuck mail to some router, or to lab PCs, or
> whatever.
The mail sitting in the queues isn't the problem, it's the load on all of
the hosts that the bogus mail is hammering on. Remember my non-mail host
with the 30,000 spams per day. Those aren't just attempts, by the way, I
set up an MTA and collect 30,000 actual spams. I tried soft failing and
the load was somewhat more.
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.
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.
The bottom line is that the spammers are gonna do whatever they want
irrespective of what we specify. If they perceive some advantage (and it
doesn't have to be a real one) to attempting to send mail to stuff that has a
name and address in the DNS but no "I accept mail" flag then that's what's they
will do.
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. And yes, a secondary goal should
be not to create situations that spammers can exploit. But AFAICT nothing we
say or do is going to have any effect on what spammers do. And that's even
assuming we can predict the shape of the antispam problem in the medium to long
term - which I very much doubt we can.
The lack of complaints is probably because we no longer run versions of
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.
Most bounces these days are spam blowback, which tells me
that if the user doesn't see a failure report really soon while he still
remembers sending the message, it'll be lost in the noise.
Actually, I'm not entirely sure what has changed, but right now the majority of
the bounces I see personally are legitimate. This is in marked contrast to the
situation a few years ago where there was a period during which my getting tens
of thousands of bogus bounces in a single day wasn't at all unusual. It may not
last, but right now I'm enjoying it.
Speaking of lost in the noise, one thing that's really different from 25
years ago is that reliable mail depends as much on not delivering spam as
it depends on delivering the real mail. I don't know how many of the
other people in the conversation see the feedback reports when people at
AOL, Hotmail, and other large ISPs hit the spam button on your users'
mail, but if you can arrange to see them, do so, because it's a real eye
opener.
Unfortunately it is difficult for small operators to arrange for such reports
because of - you guessed it - DNS administrative issues. I've tried signing up
for them, but the ISPs I've used have historically had trouble keeping my PTR
records consistent on and up to date, so I always fail the
forward-reverse-forward check and end up getting denied.
I'm with a new ISP now so I suppose I should try again and see if I can't get
this working.
A message that is hidden in a mailbox full of spam is lost as
thoroughly as one that was never delivered. I cannot tell you how many
spam reports I get for utterly unobjectionable mail that was clearly
scooped up with a hundred other messages and reported en masse. I've had
to tell people on my church's mailing list that no, I can't keep putting
you back on the list if you keep reporting it as spam. So with that in
mind, even if something makes it a little harder for the least competent
to set up their mail servers, that's OK if will tend to improve mail
reliability overall.
Unfortunately the incompetent are often amazingly clever at working around such
restrictions (in fact they often seem much more willing to invest huge amounts
of time and effort in working around some problem in a way that causes huge
collateral damage when it would be far easier just to solve the problem). The
competent but overly restricted are usually the ones who end up suffering.
With respect to DNS setup, I spend a certain amount of time helping people
fix their SPF records. (Not because SPF is a good idea, but because it's
hard to get mail into Hotmail if you don't.) I see a fair number of DNS
management control panels, and I don't recall seeing any that made MXes
hard to set up. Maybe they exist, but I'd be surprised if they were any
more common than any other random DNS breakage.
Which itself is incredibly common. You're not exactly convincing me here...
> So I believe the correct course going forward is to have the same fallback
> rules for AAAA that we do for A. Having said all this, it certainly isn't a
> showstopper for me if this goes the other way
I can live with the current ambiguous language, particularly if we agree
that we need to have some way to declare in the DNS that a name accepts no
mail, be it no default to AAAA, MX . or whatever.
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.
If, OTOH, you are advocating switching back to what 2821 said, then you are in
effect saying that it is OK for 2821bis to be a proposed standard since that's
what the rules clearly say it will have to be. If you are in fact OK with then
then there's really nothing more to be said.
Ned