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
