Dave Crocker <dhc(_at_)dcrocker(_dot_)net> wrote:
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.)
IPv6 has been a _very_ interesting study in scope-creep, and I hope
to get to read some professional historians' views on this subject.
Please, oh please, let's not re-use that justification for scope-creep.
Alas, the only way to avoid that is by _having_ other alternatives
for adding features some of us see as essential.
Happily, SMTP has a feature for Extensions. :^)
Thus, when somebody proposes a feature which could reasonably be
done by an SMTP Extension, we can send them off to design one.
Alas, there are features which _can't_ be done using extensions.
One which I particularly cared about was recording more trace
information. We had some flame-wars about that, and ended up with
rather less than I wanted, but an extension of Received trace headers
which can serve the needs I envisioned.
Our current flame-war concerns what Dave likes to call "registration"
of email-receiving services for a domain. This is another thing we
_can't_ do via SMTP Extensions.
I'm happy to call it "registration" too. I think this should tend
to get us thinking about the right thing. How should the intent to
receive email for a domain be signaled?
In RFC2821, it's signaled by MX RRs (whether actual or implied).
The actual MX RR seems to fulfil an "adequate" registration. The
implied-MX, to be frank, doesn't. The presence of an A RR indicates
nothing about such an intent. We must go further to make implied-MX
even barely tolerable as "registration".
Discussion here has centered on, "Well, try port 25: if it wants
email for that domain it'll be listening on port 25!"
That's false, of course: there are any number of reasons it might
not be listening at any moment. So we write in language that requires
multiple tries. (Others have noted problems inherent in this.)
And merely listening on port 25 isn't enough. It's actually common
for a host to listen on port 25 without the slightest intent of
accepting email to a domain identical to whatever domain's A RR may
have returned its IP address. Thus we have to endure things like
Verizon's Call-Back Verification... :^(
I make no apologies for having proposed a step away from
implied-MX as "registration". It's a real issue. It can't be fixed
by any SMTP Extension. Is it "scope-creep"? Perhaps. But it's also
an interoperability problem which would ordinarily be considered
when moving to Draft Standard.
It's more like "let's be judicious" and "let's not let spamming fears
whip our requirements around trying to satisfy secondary goals."
The problem which concern me are "related to" spam, yes; but they'd
still be issues if spam disappeared entirely.
May I suggest, "Let's be judicious, and not let the mention of
spamming fears prevent us from considering issues which deserve our
attention regardless of spam."
John Leslie <john(_at_)jlc(_dot_)net>