North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: Remote email access
- From: Daniel Senie
- Date: Tue Feb 04 09:01:38 2003
At 01:07 AM 2/4/2003, Dave Crocker wrote:
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.
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.
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
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?