OK, so we established back at the beginning of this that we're only
really concerned with people using 465 for SSL submission. Let's see
how this play's out with Jeff's and Ned's most recent comments:
On 1/16/03 at 11:30 AM -0800, ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:
>>Registering SMTPS again would only provide short-term relief
>>(providers would soon block it as well) at the cost of creating
>>standards confusion.
>
>Exactly right. SMTPS really is a solution to a very different
>problem, one that cannot be leveraged as a solution to the problem
>you describe except in, as you say, the short term.
Actually, I think this might argue *in favor* of registering 465.
Right now, 465 is used for unauthenticated encrypted submission. We
don't want people using unauthenticated encrypted submission; we want
them using authenticated submission, either on port 25 or on port
587. As a matter of fact, open 465 ports mean that, for example,
spammers will have a new way to get through firewalls and spam. (And
I would not be at all shocked if there were installed SMTP
implementations with SSL-SMTP listening on port 465 without their ops
knowing about it.) Maybe 465 should be registered to, in effect,
encourage people to make sure it is turned off.
Let me be clear here: I am not opposed to providing information about the use
of this port for SMTPS.
However, as Keith points out, registration by itself doesn't provide much
information. And because of this the registration can end up being in effect an
invitation to the uninformed to be used incorrectly.
I think it's rather ostrich like to say, "No, no, no, there's nothing
at all on port 465 that looks like SMTP; we're not registering
anything there and we're not going to talk about it." I think
documenting the current state of affairs (people are submitting mail
encrypted but unauthenticated on port 465) and labelling it "Worst
Current Practice" has some hope of cutting down on it getting more
widespread and acceptable.
A document describing the practice as a bad idea is another matter. I think
such a document would be a fine thing to have.
Unfortunately the current state of affairs in the IETF is that such documents
are incredibly difficult to get through the process. The line that has to be
tread between not criticizing the two port practice in general (it arguably
makes sense in some cases) while not in any way supporting the use of the two
port approach for SMTP specifically ends up being a lot thinner than you'd
think. The underlying problem I've encountered in such cases is that quite a
few people who review such things tend to see them more in light of their own
prejudices than in light of what the document actually says.
John Klensin had quite a bit to say about this meta-issue in another context on
the main IETF list; I think a lot of what he said was very much on
target. And the fact that this is a sad state of affairs doesn't change it.
Ned