In article <cistron.407CDBCC.60004@he.iki.fi>,
Miquel van Smoorenburg wrote:
That was solved 6 years ago. You let them use port 587 instead of 25.
RFC 2476 - Message Submission (RFC2476)
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?
...back to the computer literacy requirement again...
How many support calls you get by requiring 587 instead of 25?
Pete
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
Alex,
Are you going to print up some "Nanog Problem Solving Algorithm" T-shirts?
/John
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.
Joe
: > 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:
That was solved 6 years ago. You let them use port 587 instead of 25.
RFC 2476 - Message Submission (RFC2476)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
I'm
told that
Date: Wed, 14 Apr 2004 10:07:30 -0400
From: Joe Abley
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)".
It gets worse: OE/Outlook offer a "use Secure Password Auth"
option, which is _not_ SSL.
Although SMTP auth is orthogonal to SSL, they tend to be used
together. When Netscape Communicator 4.7 is offered the chance
to authenticate, it _insists_ on authenticating.
Then certain Eudora versions have quirks IIRC...
Eddy