Remote email access

Daniel Senie dts at senie.com
Tue Feb 4 13:57:44 UTC 2003


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

>JC,
>
>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?




More information about the NANOG mailing list