Remote email access

Tue Feb 4 14:05:17 UTC 2003

At 08:20 AM 2/4/2003, Jack Bates wrote:

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