Remote email access

Tue Feb 4 13:20:34 UTC 2003

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.

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