Re: [Uta] What's the right thing to do about Port 465?

[Keith Moore <[e-mail]>]

On 03/10/2014 03:54 PM, Chris Newman wrote:
> --On March 10, 2014 3:01:12 -0400 Keith Moore 
> <[e-mail]> wrote:
>> On 03/10/2014 02:51 AM, Eliot Lear wrote:
>>> Routers running URD intercept all packets using port 465, regardless
>>> of destination.
>>
>> So is the right thing to do:
>>
>> a)  Recommend port 465 anyway, but document the problem with these
>> routers?
>>
>> b)  Allocate and recommend a different port, even though that's going to
>> increase configuration difficulties for the vast majority of legacy
>> clients? (and assuming that new clients default to the new port, also
>> complicate configuration of those clients with legacy servers?)
>>
>> c) Allocate a different port to be the "official" port, recommend that
>> servers support both ports when feasible (for the benefit of legacy
>> clients), and recommend that new clients use SRV lookup to discover the
>> submissions port?
>>
>> d) something else?
>
> I don't think there's a "right thing" to do in this situation. I am 
> opposed to registering a new well-known-port for "submissions"; that 
> will create real interoperability and deployment problems for no 
> benefit other than registry purity. So I do not support options b & c. 
> Here are three options, in my order of preference, that I do not 
> believe make things worse than they are today:
>
> 1. Recommend port 465, but document the problem with these routers.
>
> 2. Recommend use of STARTTLS on port 587. This makes our Submission + 
> TLS recommendation asymmetric with our recommendation for other MUA 
> protocols, but it does not make the current deployment situation 
> worse. STARTTLS remains the only option for SMTP relay, so it could be 
> argued this keeps SMTP consistent. However, STARTTLS does seem to be 
> somewhat more difficult to deploy/test/configure than implicit TLS in 
> practice so I believe option 1 will result in more use of TLS for 
> submission than this option.
>
> 3. Do not register a new well-known-port for "submissions". Clients 
> wishing to use "submissions" service MUST use SRV record lookups as 
> documented RFC 6186. Choice of port is a matter for service providers. 
> This will be more difficult to deploy than 1, particularly because it 
> requires SRV-ID (or DANE) support and has near zero deployment today.

I suspect it's really useful to have a well-known port for submissions 
so that paranoid network admis / network access providers can punch 
holes in their "deny all outgoing" filtering rules to accommodate mail 
submission.  I seem to recall that one of the reasons we wanted a 
separate submission port in the first place (not the only one, surely) 
was widespread blocking of port 25, but at least a few network providers 
seem to be really aggressive about blocking of outbound traffic other 
than obviously safe/necessary ports.

And it might actually be this kind of port blocking that is the biggest 
reason to continue using port 587, since it's been around long enough, 
and advertised as being for mail submission, long enough to have holes 
punched for it.
>
> I prefer 1, but can live with any of these three options.
>

Keith