--On 14 April 2004 12:17 +0300 Petri Helenius <pete@he.iki.fi> wrote:

How many MUAs default to port 587? How many even know about 587 and give it as an option other than fill-in-the-blank?

So until they do, treat unauthenticated port 25 connections skeptically, and authenticated port 587 connections not skeptically. Skeptically might defined as: do not allow connections from outside known IP's and reply "550: Denied - please see http://myisp.net/relay.html" which explains how to fix your mail client. <metaargument> Not to pick on you in particular: This argument (at least on NANOG) seems to be characterized by the following 1. A suggests X, where X is a member of S, being a set of largely well known solutions. 2. B1 ... Bn, where n>>1 says X is without value as X does not solve the entire problem, each using a different definition of "problem". 3. C1 ... Cn, where n>>1 says X violates a "fundamental principle of the internet" (in general without quoting chapter & verse as to its definition, or noting that for its entire history, fundamental principles, such as they exist, have often been in conflict, for instance "end-to-end connectivity", and "taking responsibility for ones own network" in the context of (for instance) packets sourced from 127.0.0.1 etc.) 4. D1 .. Dn, where n>>1 says X will put an enormous burden on some network operators and/or inconvenience users (normally without reference to the burden/inconvenience from the problem itself, albeit asymmetrically distributed, and normally without reference to the extent or otherwise that similar problems have been solved in a pragmatic manner before - viz route filtering, bogon filtering etc.) 5. E1 .. En, where n>>1 insert irrelevant and ill-argued invective thus obscuring any new points in 1..4 above. 6. Goto 1. It may be that NANOG (mailing list) is a particularly unproductive place to discuss tackling the spam problem, but I don't know of anywhere less bad. In my view, we have to recognize: A. The problem is complex, else it would have been solved by now. There is unlikely to be a single silver-bullet solution. Any solution will be a composite of multiple different solutions, none of which alone (possibly together) will be perfect. B. Solutions need to be proportionate to what they achieve - where they challenge "fundamental principles" we need to evaluate that in the context of why those fundamental principles exist in the first place. C. Many solutions require hard work by network engineers. That is the value add. The problem is asymmetric which means that at least some part of the solution must have some normative component (see, for example, route filtering) as far as network operators are concerned. D. There also needs to be a normative component as far as users are concerned. Much of the behaviour we seek to change is not reliably distinguishable from acceptable behaviour at a technical level; whilst we may be able to improve that with better technology or simply different default settings, technology alone is not going to produce a solution in the absence of (say) AUPs and/or legislation. <metaargument> Alex

On 14 Apr 2004, at 10:31, Todd Vierling wrote:

On Wed, 14 Apr 2004, Joe Abley wrote:

: > That was solved 6 years ago. You let them use port 587 instead of 25. : > http://www.faqs.org/rfcs/rfc2476.html

: Several graphical, consumer-grade mail clients let you select a port : for "outgoing mail (SMTP)" and also have a checkbox for "use a secure : connection (SSL)".

: If (port != 25 && use_ssl) the client will assume an SSL-wrapped SMTP : server on the other end, and will not use STARTTLS.

: I thought I'd mention it.

You forgot to name the clients in question, since you're trying to help out helpdesks here. I'm sure several folks would like to know the real details.

I didn't give a list because I don't have a good one. I fell over half a thousand half-crazed, pulling-out-hair e-mails on list archives using google when I first went hunting for details on this, which is mainly what makes me think this implementation decision (to wrap or not to wrap) is widespread. This is how it works using Apple's Mail.app which ships with Mac OS X; it's how it works with the various versions of Outbreak Express that I've had occasion to (distainfully!) mess with on relatives' computers. It's how it works with the mail client on the Sony Ericsson P800 phone (which incidentally only supports SMTP AUTH if you leave SSL turned off, which is why the P800 is going back on ebay some time soon). I'm SMTP/SSL works this way with Outlook 2002 (although that one is a bit fuzzy; it also maybe sounds like STARTTLS on a non-wrapped connection isn't implemented at all). I've also heard that certain vintages of Netscape/Mozilla mail and also Eudora provide STARTTLS as an option as well as "use SSL", so maybe the semantics are different there. Joe

Joe Abley wrote:

On 14 Apr 2004, at 04:09, Miquel van Smoorenburg wrote:

...

That was solved 6 years ago. You let them use port 587 instead of 25. http://www.faqs.org/rfcs/rfc2476.html

There's a slight wrinkle with that for people who want to submit mail over SSL.

Several graphical, consumer-grade mail clients let you select a port for "outgoing mail (SMTP)" and also have a checkbox for "use a secure connection (SSL)".

If (port == 25 && use_ssl) the client will EHLO to 25/tcp, and will attempt to use STARTTLS in order to encrypt the session.

If (port != 25 && use_ssl) the client will assume an SSL-wrapped SMTP server on the other end, and will not use STARTTLS.

If (port != 25 && !use_ssl) the client will assume a non-SSL-wrapped SMTP server, and will not use STARTTLS.

This provides an operational/support issue for people running mail servers who want to support both SSL and also non-encrypted mail submission for their clients. It's an implementation problem in mail clients, not a protocol issue, but since it sounds like it might make the helpdesk phone ring, I thought I'd mention it.

Talking about implementations: Sendmail 8.12.11 -- See _FFR_SMTP_SSL build time define/m4 directive value Sendmail 8.13.0Alpha: -- From http://www.sendmail.org/8.13.0.Alpha0.html Support for SMTP over SSL (smtps), activated by Modifier=s for DaemonPortOptions. Clients: Outlook versions I am familiar with follow above rules Mozilla/Thunderbird IIRC have fixes for this issue

Joe