Home page logo

nanog logo nanog mailing list archives

Re: Remote email access
From: Daniel Senie <dts () senie com>
Date: Tue, 04 Feb 2003 08:57:44 -0500

At 01:07 AM 2/4/2003, Dave Crocker wrote:


Monday, February 3, 2003, 9:43:01 PM, you wrote:
JD> Dave Crocker wrote:
>> 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
JD> Why does a single solution need to be "broadly supported"?

interoperability. when there are choices for solving the same problem, a
service can make one choice -- or, in this case, each of at least two
different services can make different choices -- and a software vendor
can make yet another another. then there is no interoperability.

that is exactly the problem that I have repeatedly experienced.

I agree with this, but would approach it from a slightly different angle. From the vantage point of an email services provider, the issue is one of supportability. Having to walk customers through the advanced configuration options for each popular mailer to explain how to turn on an alternate SMTP port is a real time sink.

The Submission protocol RFC specifies an alternate port on which SMTP AUTH can be used, thereby providing separation between mail submission and mail transport. This has been well supported in sendmail, for example, since 8.10.0. My company has made use of it for several years, so that we can provide our customers with the SMTP services they require, without running afoul of port 25 blocking at their access provider (dialup ISP, cable, DSL, etc.). We provide the customer with a predictable and reliable SMTP configuration so that they may roam from one access network to another and have reliable email service.

SMTP AUTH winds up being used with authentication types of LOGIN and PLAIN. These are clear-text password methods. Delivery of mail to the user is over POP3, again with clear-text passwords. For both protocols, we support TLS, however, and encourage our customers to use it. Some MUAs (e.g. Eudora) implement TLS well, while others (Outlook, OE) don't do it very well. All support SMTP AUTH, however. Our customers' choice of MUA affects their level of security, to be sure.

The supportability issue is that it'd be really helpful if MUA vendors were to support Submission, either automatically by trying that port first, or manually by providing a check box that users can easily find (perhaps NOT on the advanced tab). It would also improve supportability if the MUAs would all default to using TLS if presented with a STARTTLS capability.

So back to the question Dave was responding to: "Why does a single solution need to be 'broadly supported?'" It's needed so that users can configure their mail clients with ease. It's needed so that ISPs, hosting companies and IT departments can give simple instructions for users configuring their mail clients. It's needed to improve the "customer experience" through greater predictability.

We've got the components, and the RFCs, to cover all of this. Perhaps we need a BCP that indicates what MUAs should support, and what MTAs should offer?

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]