Dave Crocker <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
