ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:
Not exactly. The issue isn't what to do in general, it's what to do in this
document. I have no problem with someone starting an MX . effort or a require
MX effort and seeing if they can get consensus on it. (If the former gets
started I plan to support it, the latter I'll oppose.) It just doesn't belong
in 2821bis.
+1
Some feel that the transition to IPv6 is a once-in-a-lifetime opportunity
to make some of these fundamental changes.
And some of us feel that coupling such changes is ill advised.
15 years ago, IPv6's -- and, yes, I mean what we now call IPv6 and yes, I mean
1.5 decades ago -- once-in-a-lifetime occurrence was touted as the reason for
massively expanding the scope of the original problem that was being worked on
(limited address space.)
Please, oh please, let's not re-use that justification for scope-creep.
So let me postulate a world in which IPv4 is gone, A records are gone, and
IPv6 reins over the planet, and we have switched to requiring MX for any
inbound mail hosts.
That's somewhat uninteresting to me because I don't think it will happen in
any sort of time frame frame we're concerned with.
It can be useful to envision the end-point to a transition. It can also be
distracting.
As with Ned, I suspect we are going to be long-retired, and possibly long-dead,
before v4 use reduces sufficiently to be ignored.
Ned seems to be thinking about the bad guys, saying "So what? Spammers are
going to try to send to hosts whether or not they have MX records, so
what's the point?"
Well, I'm thinking about the bad guys only to the extent that I don't want to
give them any more opportunities to cause harm than they already have.
I can see how your "spammers are gonna do whatever they want", text might be
taken as a "so what", but only if one ignores the paragraph you wrote after
that, where you said:
"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."
That kind of language is difficult to interpret as "so what".
It's more like "let's be judicious" and "let's not let spamming fears whip our
requirements around trying to satisfy secondary goals."
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net