JC, 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. JD> IMHO, all JD> that is needed is for each individual to find a solution that works for JD> 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. 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. d/ -- Dave <mailto:dcrocker@brandenburg.com> Brandenburg InternetWorking <http://www.brandenburg.com> t +1.408.246.8253; f +1.408.850.1850
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
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.
From: "Daniel Senie"
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: JB> 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). ... JB> I'm concerned with MTA to MTA. ... A flag day is JB> 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. -- Dave <mailto:dcrocker@brandenburg.com> Brandenburg InternetWorking <http://www.brandenburg.com> t +1.408.246.8253; f +1.408.850.1850
From: "Dave Crocker"
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
Jack, Tuesday, February 4, 2003, 8:24:58 AM, you wrote:
A flag day is not possible for changing the infrastructure of any network operation that is large. JB> That is true. However, there comes a day when enough people are implementing JB> a technology that one can make the decision to flip the switch on their JB> network.
You are willing to wait 10-15 years before seeing any improvement in service? You think people will bother to develop, ship and buy enhancements that will not be useful for 10-15 years? JB> While there is no single authority, I'd be happy with a US and JB> European based authorities for their respective companies. There is no single authority for U.S. companies' network operations. There is not single authority for European companies' network operations. Each has tens (or maybe hundreds) of thousands of "authorities". JB> happy if whois data was enforced to be accurate again. 555-5555 is not a JB> valid phone number the last time I checked yet it's listed all over whois You are confusing network operations with network address assignment. There IS a single global authority for the top of the global, telephone numbering scheme and it carefully delegates authority down the tree. Hence the fact that the 555-* numbers are reserved is because the North American Numbering Plan is under a single authority. The topic being discussed in this thread is not subject to any such authority hierarchy. To the extent that you might want to claim that IP addresses are like phone numbers, they differ in this specific regard: although there is an assignment hierarchy, the numbers, themselves, do not reflect that heirarchy. Hence there is no space-efficient way of noting an authority chain, other than entering every single IP address ever assigned, all in one big data base. Alas, that ain't feasible. At a minimum, it is essentially impossible to keep such a database up to date. d/ -- Dave <mailto:dcrocker@brandenburg.com> Brandenburg InternetWorking <http://www.brandenburg.com> t +1.408.246.8253; f +1.408.850.1850
On Tue, 04 Feb 2003 09:05:17 EST, Daniel Senie said:
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. -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech
At 01:07 AM 2/4/2003, Dave Crocker wrote:
JC,
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.
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?
DS> Date: Tue, 04 Feb 2003 08:57:44 -0500 DS> From: Daniel Senie DS> We've got the components, and the RFCs, to cover all of this. DS> Perhaps we need a BCP that indicates what MUAs should DS> support, and what MTAs should offer? If only BCPs actually were currently practiced. :-( Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.
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, ______________________________ Al Rowland
-----Original Message----- [Snip] ... JD> Why does a single solution need to be "broadly supported"?
Unnamed Administration sources reported that Al Rowland said:
Only convenient kludge that is (mostly) provider independent is a webmail service, a completely different can of worms/flame war.
Or a shell account at Panix, reached via SSH. $100.00/year is worth it to me; YMMV. -- A host is a host from coast to coast.................wb8foz@nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433
Don't even need that. I can telnet into the appropriate server/port from a command prompt but, like your solution below, that is not non-geek friendly. We need a solution that is AOL user friendly, not NANOG user friendly if we ever expect to make money with this thing called the Internet. This will always be tragedy-of-the-commons; the very things that make service attractive for Joe PayingCustomer also make it easy for Joe Spammer/Hax0r. Open<->Secure, choose your business plan carefully. Good Luck. Best regards, ______________________________ Al Rowland
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of David Lesher Sent: Tuesday, February 04, 2003 10:06 AM To: nanog list Subject: Re: Remote email access
Unnamed Administration sources reported that Al Rowland said:
Only convenient kludge that is (mostly) provider independent is a webmail service, a completely different can of worms/flame war.
Or a shell account at Panix, reached via SSH.
$100.00/year is worth it to me; YMMV.
-- A host is a host from coast to coast.................wb8foz@nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433
Unnamed Administration sources reported that Al Rowland said:
Don't even need that. I can telnet into the appropriate server/port from a command prompt but, like your solution below, that is not non-geek friendly. We need a solution that is AOL user friendly, not NANOG user friendly if we ever expect to make money with this thing called the Internet. This will always be tragedy-of-the-commons; the very things that make service attractive for Joe PayingCustomer also make it easy for Joe Spammer/Hax0r.
I'm not disagreeing re: a Jill Winecooler solution being needed. And I really wish mail over TLS/SSL/XYZ was straightforward; I'm finding it anything but. Here is a pipedream I'd like you gurus to grade. Could there be a cgi-script on a page that would test all|selected POP/IMAP/SMTP ISP mailer ports for secure compatablility, and report back? I think this could all be done pre-login, i.e. without a password being exposed. True? Could it probe and report back as to success/failure of modes? For example, some installations will NOT work with Eudora until you force it into V3 with "SSLSendVersion=6" in the ini. If told so, most customers could use their: <x-eudora-option:SSLReceiveVersion=6> <x-eudora-option:SSLSendVersion=6> pseudo-URL to set same. What say you all? Would this work, and thus help grease the secure mail skids? [Remember, I'm a hardware-type whose favorite language is solder. I'm sure this is obvious/trivial/noise to many of you....] -- A host is a host from coast to coast.................wb8foz@nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433
Al, Tuesday, February 4, 2003, 10:20:50 AM, you wrote: AR> Don't even need that. I can telnet into the appropriate server/port 1. as you note, that is a solution that does not scale to millions of non-technical users. 2. many people need access from their laptops (ie, their "office), rather than having all their mail accessible over the Internet, only accessible when online. AR> Open<->Secure, choose your business plan carefully. Good Luck. The issue is not about losing "openness" but about losing interoperability. There is no technical reason high quality interoperability prevents high quality security, or at least acceptable authentication (accountability). d/ -- Dave <mailto:dcrocker@brandenburg.com> Brandenburg InternetWorking <http://www.brandenburg.com> t +1.408.246.8253; f +1.408.850.1850
participants (7)
-
Al Rowland -
Daniel Senie -
Dave Crocker -
David Lesher -
E.B. Dreger -
Jack Bates -
Valdis.Kletnieks＠vt.edu