Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Remote email access

  • From: Dave Crocker
  • Date: Fri Jan 31 00:29:50 2003

Eliot,

Thursday, January 30, 2003, 7:25:05 PM, you wrote:
EL> The submission port, according to IANA is 587.

Sorry about that detail.  I searched the IANA port assignment file for
'submit' rather than 'submission'.

Luckily, the error does not affect the core concern I am raising.


EL> I'm not a fan.  I also
EL> think experience has shown that it is POSSIBLE to protect port 25 
EL> appropriately.  It's just a matter of doing it...

EL> See http://www.iana.org/assignments/port-numbers

Recently I had protracted discussions with a number of Ops folks about
this issue and have chosen to drop that debate. I do not agree with
blocking port 25, either, but am far more concerned about having a
coherent, workable means of remote access than I am about it being the
particular one I prefer.

As long as it is technically adequate and supported broadly (ie,
predictably) by service providers and software providers, the details
frankly do not matter to me.


>> Standardized privacy for SMTP uses SMTP over SSL or it uses SMTP with
>> SASL.  SASL can be used on any SMTP or Submit port.  SSL can only be
>> used on port 25 if the SMTP service is not available to other SMTP
>> servers for relaying (or, really, for last-hop SMTP delivery).

EL> Although Dave is correct about SSL, RFC 3207 discusses the use of TLS
EL> for purposes of encryption AND authentication.  I use this for my own
EL> sendmail.  The biggest problem is ensuring that appropriate certificates
EL> are installed.  Most of the common MUAs I tested have a way to do it,
EL> but it's messy (to say the least).

Thanks for the clarification.  Unfortunately it mostly means there are
even more choices to make and, therefore, less predictability and,
therefore, less interoperability at Internet scale.

d/
-- 
 Dave <mailto:dcrocker@brandenburg.com>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 t +1.408.246.8253; f +1.408.850.1850





Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.