Remote email access

Folks,

The Ops community and the IETF Email community appear to have different
views about appropriate methods for email posting. The difference
frequently means that an effort to post a new message from a network
with a firewall, to a remote SMTP, is blocked by the outbound firewall.

Blocking outbound SMTP (port 25) is supported by the Ops community as a
spam-suppression mechanism. Ops support for this blockage appears to be
deeply and broadly held.

This note is *not* an effort to debate the Ops concern or the preference
for blocking outbound port 25. Rather, I would like to pursue a
discussion that simply resolves the disparity between the two
communities.

The goal is to obtain a coherent recommendation that is acceptable to
the Ops and the Email communities.

It would permit normal users to easily use their normal software and
achieve normal access to normal services. Whatever the current choices
are, they are inconsistently available and they frequently require
technically knowledgeable users and/or special cooperation by the user's
remote ISP.

My guess is that a brief IETF BCP document would suffice for describing
the recommended profile. For completeness, I suggest that the BCP cover
"Remote email access" for posting and retrieval, and that it recommend
the details that will permit private, authenticated access for all
standardized email services.

Some current choices:

Email standards provide for posting of email to the usual port 25 or to
port 773 for the newer "submit" service. (Submit is a clone of SMTP that
operates on a different port and is permitted to evolve independently of
SMTP, in order to tailor posting by originators, differently from
server-to-server email relaying.) There is also a de facto standard for
doing SMTP over SSL on port 465, although this collides with the IANA
assignment of that port to another service.

Standardized SMTP authentication uses the SMTP Auth command or the SASL
service within SMTP. It can also use the de fact "POP hack". All 3 of
these mechanisms are inline -- as part of the posting protocol -- so
that they work over whatever port is being used for posting.

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).

Some choices are easier for users. Some are easier for service
providers. Some are supported more broadly in current software.

We need to narrow down the recommended choices, preferably to one per
service.

Thoughts?

d/

The goal is to obtain a coherent recommendation that is acceptable to
the Ops and the Email communities.

Email communities? You can't even get people to do proper reverse or secure
open relays. A large section of the 'net isn't RFC compliant. Most servers
are privately hacked so that no two are alike. And if an ISP is large enough
and known for distributing information you don't want in your network,
you're forced to accept it because your customers demand access to some of
their customers. Most people are ill informed and have no conception of what
the Internet is or how it works. Nor do they care. They just want to go
access information from so and so site and don't care that the information
they want forces you to allow traffic to pass between your network and a
network that doesn't handle abuse@ complaints, keeps a poor rwhois database,
allows customers to be signed up with falsified POCs for IP assignment as
well as domain assignment, and trashes your servers with garbage such as
spam knowingly. A community would imply people of like mind and
collaboration. Yet it is the people who know the least that are making the
demands.

-Jack

A large chunk of the spam I am seeing these days are due to exploitable formmail.pl scripts (i.e. insecure customer web apps) and open proxies (1080,8080 3128 etc). These forms of delivery are also preferred by spammers as their original IP addresses are hidden. Blocking port 25 will do nothing to stop this.

I would be surprised if your premise holds true, that the majority of the Ops community support this. Blocking port 25 results in lost customers as well as additional support headaches. I know when the local big ISP (Sympatico) starting blocking port 25, we gained quite a few business customers. So our sales staff certainly supported their Ops implementing it.

         ---Mike

It's a rare day when I differ with Dave over mail standards, so something's weird.

Dave Crocker wrote:

Some current choices:

Email standards provide for posting of email to the usual port 25 or to
port 773 for the newer "submit" service. (Submit is a clone of SMTP that
operates on a different port and is permitted to evolve independently of
SMTP, in order to tailor posting by originators, differently from
server-to-server email relaying.) There is also a de facto standard for
doing SMTP over SSL on port 465, although this collides with the IANA
assignment of that port to another service.

The submission port, according to IANA is 587. I'm not a fan. I also think experience has shown that it is POSSIBLE to protect port 25 appropriately. It's just a matter of doing it...

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

Standardized SMTP authentication uses the SMTP Auth command or the SASL
service within SMTP. It can also use the de fact "POP hack". All 3 of
these mechanisms are inline -- as part of the posting protocol -- so
that they work over whatever port is being used for posting.

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).

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

Eliot

It's a rare day when I differ with Dave over mail standards, so something's weird.

Dave Crocker wrote:

Some current choices:
Email standards provide for posting of email to the usual port 25 or to
port 773 for the newer "submit" service. (Submit is a clone of SMTP that
operates on a different port and is permitted to evolve independently of
SMTP, in order to tailor posting by originators, differently from
server-to-server email relaying.) There is also a de facto standard for
doing SMTP over SSL on port 465, although this collides with the IANA
assignment of that port to another service.

The submission port, according to IANA is 587. I'm not a fan. I also think experience has shown that it is POSSIBLE to protect port 25 appropriately. It's just a matter of doing it...

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

I am a fan of port 587 being a viable alternative, as it provides a way for our customers who are blocked on port 25 to send their email through our servers (with SMTP AUTH or SMTP-after-POP). If this is going to be the norm from now on, it'd sure be nice if the MUAs had an automated way to set up users to use the SUBMISSION port. It'd also be nice if a certain large vendor fixed their MUA to understand STARTTLS and properly implemented it.

Port 25 blocking, especially on dialups, did for a time cut down on the spam levels. This benefit has largely disappeared as the spammers now use open proxies found all over the 'net.

Standardized SMTP authentication uses the SMTP Auth command or the SASL
service within SMTP. It can also use the de fact "POP hack". All 3 of
these mechanisms are inline -- as part of the posting protocol -- so
that they work over whatever port is being used for posting.
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).

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

We encourage our users to use STARTTLS, but they're using username/password for the SMTP AUTH (and the POP auth) rather than client certs.

Eliot,

Thursday, January 30, 2003, 7:25:05 PM, you wrote:

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.

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

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).

Although Dave is correct about SSL, RFC 3207 discusses the use of TLS
for purposes of encryption AND authentication. I use this for my own
sendmail. The biggest problem is ensuring that appropriate certificates
are installed. Most of the common MUAs I tested have a way to do it,
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/

JC,

Monday, February 3, 2003, 9:43:01 PM, you wrote:

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

...

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.

IMHO, all
that is needed is for each individual to find a solution that works for
them, given their preferred email client, email host, and provider options.

hmmm. sounds like I have not described the problem clearly enough. So
here is the short form:

My email service provider permits me to post new email from anywhere on
the net, as long as I go through proper authentication. (The details of
how this is done do not matter; the method is reasonable and
sufficient.)

The provider happens to support this posting via port 25.

When I am traveling, my access often is through a provider that kindly
block outbound port 25, so I cannot post email.

Each provider has behaved as you suggest, and the result is that I
cannot post email.

My present solution is to ssh into a server where I have an account,

Once again: I have no doubt that individuals are able to solve their
individual problems, individually, especially when they are technically
savvy.

That approach does not make for a viable, large-scale (as in
mass-market) industry.

d/

We need to narrow down the recommended choices, preferably to one
per service.

I'm seeing a lot of SMTP-AUTH and pop-before-smtp (which can easily
coexist on the same server) on port 587. Current versions of popular
MTAs all seem to support at least one of those, albeit sometimes
not very conveniently.

It would be nice if we could use SMTP-AUTH on port 25, but the
spammers ruined that for us around the same time they ruined courtesy
relay.

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.

Submit is relatively new in the MTA I use. I know I thought the new config
file for it was kinda cute, although completely useless to me at this time.
SMTP AUTH is a good example of issues with interoperability. If you wanted
to narrow the choices, you're almost stuck with plain/login for maximum
client support. The actual port value for one to use usually isn't an issue
as man, if not all, MUAs support changing the submission port. Granted, it's
somewhat of a manual intervention.

The provider happens to support this posting via port 25.

When I am traveling, my access often is through a provider that kindly
block outbound port 25, so I cannot post email.

Each provider has behaved as you suggest, and the result is that I
cannot post email.

Sounds like an issue with the provider not recognizing newer methods of
supporting remote posting. There are many that don't even realize that MTA's
have support for submission on other ports.

> My present solution is to ssh into a server where I have an account,

Once again: I have no doubt that individuals are able to solve their
individual problems, individually, especially when they are technically
savvy.

That approach does not make for a viable, large-scale (as in
mass-market) industry.

And the average customer isn't technically savvy, nor do many large ISPs
allow for ssh access or another other form of shell access into their
servers due to security reasons. Yet I ask why your provider hasn't supplied
one of the newer methods for remote posting? Are they unaware that such
technologies exist? Have you discussed it with them?

Personally, I'd like to see the following implemented on a mass scale with
low processing overhead:

A CA that verifies and issues certificates for an entity that wishes to run
SMTP. All SMTP sessions requiring authentication of certificates.
Limitations should be in place so that certs aren't issued multiple times to
essentially the same person; ie, spammer who owns 500 certs. MUA support for
a standardized cert system that works with the provider being the CA,
allowing each provider to issue out certs for authentication and encryption
to their system, yet seperate from current cert systems that allow users to
identify themselves and encrypt for public use.

The purpose? I want to know who my mail server is talking to reguardless of
IP address space, and I want the right to not accept mail from that entity
without having to monitor the entities movement accross address pace and
block on an IP basis. Even if the processing is a little more, the practice
of having such a system should cut down on connections by at least 50% (30%
below current spam level). Such certs could support multiple domain support
where one cert could be used to also authenticate the smtp MAIL and
HELO/EHLO protocols to verify integrity. Deploy on a mass scale, refuse
unauthenticated E/SMTP, and enjoy mail as it was made to be enjoyed.

-Jack

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?

From: "Dave Crocker"

> 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.
Submit is relatively new in the MTA I use. I know I thought the new config
file for it was kinda cute, although completely useless to me at this time.
SMTP AUTH is a good example of issues with interoperability. If you wanted
to narrow the choices, you're almost stuck with plain/login for maximum
client support. The actual port value for one to use usually isn't an issue
as man, if not all, MUAs support changing the submission port. Granted, it's
somewhat of a manual intervention.

>
> The provider happens to support this posting via port 25.
>
> When I am traveling, my access often is through a provider that kindly
> block outbound port 25, so I cannot post email.
>
> Each provider has behaved as you suggest, and the result is that I
> cannot post email.
Sounds like an issue with the provider not recognizing newer methods of
supporting remote posting. There are many that don't even realize that MTA's
have support for submission on other ports.

>
> > My present solution is to ssh into a server where I have an account,
>
> Once again: I have no doubt that individuals are able to solve their
> individual problems, individually, especially when they are technically
> savvy.
>
> That approach does not make for a viable, large-scale (as in
> mass-market) industry.
>
And the average customer isn't technically savvy, nor do many large ISPs
allow for ssh access or another other form of shell access into their
servers due to security reasons. Yet I ask why your provider hasn't supplied
one of the newer methods for remote posting? Are they unaware that such
technologies exist? Have you discussed it with them?

Personally, I'd like to see the following implemented on a mass scale with
low processing overhead:

A CA that verifies and issues certificates for an entity that wishes to run
SMTP. All SMTP sessions requiring authentication of certificates.
Limitations should be in place so that certs aren't issued multiple times to
essentially the same person; ie, spammer who owns 500 certs. MUA support for
a standardized cert system that works with the provider being the CA,
allowing each provider to issue out certs for authentication and encryption
to their system, yet seperate from current cert systems that allow users to
identify themselves and encrypt for public use.

This is, IMO, unworkable in the near term. While I support and promote the use of TLS with SMTP (and POP), requiring client certs is likely too cumbersome for users to manage at this stage. Using STARTTLS to transition clients to an encrypted connection works exceptionally well. The server does need a cert, but the users are identifying with a methodology they understand, usernames and passwords.

The purpose? I want to know who my mail server is talking to reguardless of
IP address space, and I want the right to not accept mail from that entity
without having to monitor the entities movement accross address pace and
block on an IP basis. Even if the processing is a little more, the practice
of having such a system should cut down on connections by at least 50% (30%
below current spam level). Such certs could support multiple domain support
where one cert could be used to also authenticate the smtp MAIL and
HELO/EHLO protocols to verify integrity. Deploy on a mass scale, refuse
unauthenticated E/SMTP, and enjoy mail as it was made to be enjoyed.

The question this raises is whether you're concerned about MTA to MTA communication, or MUA to MTA? I'd be happy to see certs in use for MTA-MTA (and indeed support this today on my systems when talking to other MTAs which are using STARTTLS). However, there are definitely reasons why this would be a difficult requirement if made mandatory. Many embedded devices use SMTP for alerting to trouble (example: the monitoring cards in UPSs). Having a flag day for a switch to requiring certificates would be unworkable in so many ways.

The question this raises is whether you're concerned about MTA to MTA
communication, or MUA to MTA? I'd be happy to see certs in use for MTA-MTA
(and indeed support this today on my systems when talking to other MTAs
which are using STARTTLS). However, there are definitely reasons why this
would be a difficult requirement if made mandatory. Many embedded devices
use SMTP for alerting to trouble (example: the monitoring cards in UPSs).
Having a flag day for a switch to requiring certificates would be
unworkable in so many ways.

I'm concerned with MTA to MTA. I disagree with your embedded devices issue
as it is considered "trusted" or should be. I think that such devices should
also quit pretending to be an MTA and act like an MUA. A flag day is
necessary, and certification from MTA to MTA is necessary. The key is that
the certification should be for the company and not just the server, as well
as lookups for said company's certificates should be simplistic. When it
comes to mail, people are screaming that they have the right to accept and
refuse mail from anyone they want. The problem is that identifying a person
by their domain name which no longer has the strict requirements it once did
or by their IP address, which is often not kept accurate in SWIPS and Rwhois
databases nor managed with proper rdns or even kept static, is near
impractical. We talk about security on the Internet. Forget encryption for a
moment. We can't even keep track of identities so that we can say "I do not
accept email from entity X" and be done with it.

-Jack

Jack,

Tuesday, February 4, 2003, 7:16:04 AM, you wrote:

From: "Daniel Senie"

I'd be happy to see certs in use for MTA-MTA
(and indeed support this today on my systems when talking to other MTAs
which are using STARTTLS).

...

I'm concerned with MTA to MTA. ... A flag day is
necessary, and certification from MTA to MTA is necessary.

Please consider how many MTAs interact on the global Internet. Please
consider that each is operated by a different, independent organization.
Please consider that there is no single authority over all those
organizations.

A flag day is not possible for changing the infrastructure of any
network operation that is large. Even when there is a single authority,
service operators cannot perform a conversion "instantly".

In a medium-sized company -- and that means that theoretically there is
a single authority over everyone -- a serious change to the network
infrastructure will take at least 6 months.

For the Internet, it takes many years to obtain broad adoption of a
change.

d/

ps. Please note that there is still no large-scale use of certificates,
although the technology for them has existed for years. Therefore it is
important to be very conservative, when specifying a system behavior
that depends upon their use.

Date: Tue, 04 Feb 2003 08:57:44 -0500
From: Daniel Senie

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?

If only BCPs actually were currently practiced. :frowning:

Eddy

How did they ruin SMTP Auth? Thanks.

andy

> It would be nice if we could use SMTP-AUTH on port 25, but the
> spammers ruined that for us around the same time they ruined courtesy
> relay.

How did they ruin SMTP Auth? Thanks.

ip access-list 100 deny ip any any eq 25

> It would be nice if we could use SMTP-AUTH on port 25, but the
> spammers ruined that for us around the same time they ruined courtesy
> relay.

How did they ruin SMTP Auth? Thanks.

They made it impossible to use port 25 at all, since it's impractical for
ISPs to sniff outgoing traffic to permit SMTP AUTH connections and block
others, and way too much of the other port 25 traffic was
direct-from-dialup spam.

SMTP AUTH works fine on port 587, since there should be no traffic to that
port that isn't authenticated somehow.

Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://iecc.com/johnl, Sewer Commissioner
"A book is a sneeze." - E.B. White, on the writing of Charlotte's Web

A flag day is not possible for changing the infrastructure of any
network operation that is large. Even when there is a single authority,
service operators cannot perform a conversion "instantly".

That is true. However, there comes a day when enough people are implementing
a technology that one can make the decision to flip the switch on their
network. While there is no single authority, I'd be happy with a US and
European based authorities for their respective companies. This would allow
for monitoring and filtering of a large portion of netspace. I'd even be
happy if whois data was enforced to be accurate again. 555-5555 is not a
valid phone number the last time I checked yet it's listed all over whois
information. Not all ISPs are being forced to handle their IP allocation
records properly, and the ISP doesn't take responsibility for the complaints
and issues. Perhaps a little more policing and withdraws from our various
registrars would at least help make things more manageable. When does a /18
that has client entities on it still maintain only the initial ARIN whois
data.

ps. Please note that there is still no large-scale use of certificates,
although the technology for them has existed for years. Therefore it is
important to be very conservative, when specifying a system behavior
that depends upon their use.

MTA certificates are unreliable in a "I do not trust this organization"
setup at this time. If they were reliable in such a setup, people would
adopt them more readily. The reason why there is identity theft is because
we don't enforce identities on the network. Do you have to send in business
letterhead or proof of incorporation when registering many of the
"identities" available? No one wants the responsibility, and until we build
the social structure into the technical structure, we will always find our
network abused.

-Jack

You have a laptop because you travel. You have multiple accounts to
assure you have connectivity wherever you travel. Every time you
connect, you have to adjust your mail client settings based on the whims
of the provider you're using at that moment. Starts to be a pain if you
travel a lot. Yes, there are some client solutions. "broadly supported"
is a different matter.

Only convenient kludge that is (mostly) provider independent is a
webmail service, a completely different can of worms/flame war.

Best regards,

This is, IMO, unworkable in the near term. While I support and promote the
use of TLS with SMTP (and POP), requiring client certs is likely too
cumbersome for users to manage at this stage. Using STARTTLS to transition
clients to an encrypted connection works exceptionally well. The server
does need a cert, but the users are identifying with a methodology they
understand, usernames and passwords.

I've personally been advocating setting up Sendmail with a self-signed
certificate and opportunistic STARTTLS. Yes, I know it's not immune to
man-in-the-middle attacks - but it's *quite* sufficient to stop passive
sniffing of userids/passwords/text. And it doesn't require much infrastructure.

The question this raises is whether you're concerned about MTA to MTA
communication, or MUA to MTA? I'd be happy to see certs in use for MTA-MTA
(and indeed support this today on my systems when talking to other MTAs
which are using STARTTLS). However, there are definitely reasons why this

One of my hosts (a fair-sized Listserv server) sent out some 278K connections
to other sites yesterday. Of the 3,453 domains it talked to, 123 were
willing to do STARTTLS, for a deployment rate of 3.5%.

Unfortunately, working across connections, only 0.53% used it. If the 10
busiest sites we talked to deployed STARTTLS, it would jump to some 27% of
the traffic.