Subject: Re: Last Call: SMTP Service Extension for Secure SMTP over TLS to Proposed Standard
From: Eric Rescorla <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: Todd Vierling <[email-masked]>, Bodo Moeller <[email-masked]>, [email-masked], [email-masked], [email-masked]
Date: Fri, 27 Jul 2001 22:57:29 -0700
List-Id: <ietf-smtp.imc.org>

> > There are three primary cryptographic changes between SSLv3 and
> > TLS:
> 
> at least one other significant change comes to mind - TLS requires 
> implementation of TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.
True, but this isn't a *cryptographic* change, it's simply a policy
change. SSLv3 included an equivalent cipher suite. 

In any case, I don't really see why this change is relevant to this
discussion: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA is a must *implement*,
not a must *speak*. Since most servers have RSA certificates, even if
the implementation supports DSS ciphersuites, in practice the servers
do not. An implementation certainly cannot support only
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA and have any confidence
that it will be able to interoperate with other implementations
in practice.

-Ekr

From: Keith Moore <[email-masked]>
To: EKR <[email-masked]>
cc: Keith Moore <[email-masked]>, Todd Vierling <[email-masked]>, Bodo Moeller <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: SMTP Service Extension for Secure SMTP over TLS to Proposed Standard 
Date: Sat, 28 Jul 2001 00:27:48 -0400
Sender: [email-masked]

> There are three primary cryptographic changes between SSLv3 and
> TLS:

at least one other significant change comes to mind - TLS requires 
implementation of TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.

Keith

To: Keith Moore <[email-masked]>
Cc: Todd Vierling <[email-masked]>, Bodo Moeller <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: SMTP Service Extension for Secure SMTP over TLS to Proposed Standard
Reply-to: EKR <[email-masked]>
From: Eric Rescorla <[email-masked]>
Date: 27 Jul 2001 20:43:37 -0700
Lines: 38
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

> > One very important thing to note is that clients on Microsoft's rather
> > popular OS family (as much as I loathe it personally) will *not* use TLS 1.0
> > at all, by default.
> 
> then they shouldn't claim to conform to the SMTP STARTTLS RFC, and 
> they shouldn't try to negotiate STARTTLS with a server.
> if they can call Microsoft's library with non-default settings that
> cause the library to use TLS, fine.  if not, they can supply their
> own library - because the Microsoft one doesn't allow them to conform
> to the standards.
> 
> we didn't write a specification for SMTP over TLS so that people could
> pretend to support it and actually support something weaker.  there 
> are reasons that TLS was approved for standards track and SSLv3 wasn't.
Hmm... I think this rather overstates the case. SSLv3 has no
known cryptographic weaknesses that TLS does not. The cryptographic
changes made to TLS are more "tightening-up" than anything.

There are three primary cryptographic changes between SSLv3 and
TLS:
(1) The key derivation function is different (it uses an
HMAC-derived PRF rather than the rather ad hoc MD5(SHA())
nesting.
(2) The MAC is replaced with HMAC. The original MAC was
a variant of an earlier version of HMAC.
(3) The Finished message computation is slightly different and
is truncated.

None of these changes are particularly significant. No good
attacks are known against the old versions of the functions.
At best, these changes might protect against some hypothetical
future attack.

-Ekr

From: Keith Moore <[email-masked]>
To: Todd Vierling <[email-masked]>
cc: Keith Moore <[email-masked]>, Bodo Moeller <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: SMTP Service Extension for Secure SMTP over TLS to Proposed Standard 
Date: Fri, 27 Jul 2001 21:14:25 -0400
Sender: [email-masked]

> One very important thing to note is that clients on Microsoft's rather
> popular OS family (as much as I loathe it personally) will *not* use TLS 1.0
> at all, by default.

then they shouldn't claim to conform to the SMTP STARTTLS RFC, and 
they shouldn't try to negotiate STARTTLS with a server.
if they can call Microsoft's library with non-default settings that
cause the library to use TLS, fine.  if not, they can supply their
own library - because the Microsoft one doesn't allow them to conform
to the standards.

we didn't write a specification for SMTP over TLS so that people could
pretend to support it and actually support something weaker.  there 
are reasons that TLS was approved for standards track and SSLv3 wasn't.

Keith

Date: Fri, 27 Jul 2001 20:58:10 -0400 (Eastern Daylight Time)
From: Todd Vierling <[email-masked]>
To: Keith Moore <[email-masked]>
cc: Bodo Moeller <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Last Call: SMTP Service Extension for Secure SMTP over TLS to Proposed Standard
Sender: [email-masked]

: I've seen zero discussion of the extent of broken vs. conforming
: implementations in groups that are frequented by SMTP implementors.
: All I've seen is your claim that most client implementations fail to
: follow the spec in sending TLS 1.0 Hello messages.  No offense,
: but I don't think that's sufficient justification to change the spec.

[Please excuse me if I don't have the full story here, but this crept over
onto ietf-smtp from ietf-apps-tls, and I think something's been missed here.
I'm making this response under the assumption, gleaned from the context of
the crossposts, that the currently draft SMTP-TLS spec says that TLS 1.0 is
required and SSL 2.0/3.0 is not sufficient for a client.]

One very important thing to note is that clients on Microsoft's rather
popular OS family (as much as I loathe it personally) will *not* use TLS 1.0
at all, by default.

The reason for this is that the MS crypto APIs provide SSL/TLS functionality
built-in, and Win32-native client programs typically use them with default
settings -- which are the settings in Internet Exploder, where TLS 1.0 is
still not enabled by default as of version 5.5.  (Only SSL 2.0 and SSL 3.0
are; much to my surprise for a Microsoft product, MS's own proprietary "PCT
1.0" isn't turned on by default either.  8-)

-- 
-- Todd Vierling ([email-masked])

To: Keith Moore <[email-masked]>
Cc: Bodo Moeller <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: SMTP Service Extension for Secure SMTP over TLS to Proposed Standard
Reply-to: EKR <[email-masked]>
From: Eric Rescorla <[email-masked]>
Date: 27 Jul 2001 16:39:31 -0700
Lines: 28
Sender: [email-masked]

Keith Moore <[email-masked]> writes:
> I've seen zero discussion of the extent of broken vs. conforming 
> implementations in groups that are frequented by SMTP implementors.
> All I've seen is your claim that most client implementations fail to 
> follow the spec in sending TLS 1.0 Hello messages.  No offense,
> but I don't think that's sufficient justification to change the spec.
I've just checked out a number of implementations:

qmail STARTTLS patch		       SSLv2 backwards compatible hello
Postfix STARTTLS patch		       SSLv2 backwards compatible hello
Sendmail 8.11			       SSLv2 backwards compatible hello
				       (turned off if you're not using
				       RSA).

The Sendmail STARTTLS page
(http://www.sendmail.org/~ca/email/starttls.html) claims
that CommuniGate Pro 3.3BetaX and Interchange v.3.61.01
support SSLv3 only. It's unknown--at least to me what
sort of ClientHello they send.

I don't have Exchange so I can't say what it does.

-Ekr

From: Keith Moore <[email-masked]>
To: Bodo Moeller <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: SMTP Service Extension for Secure SMTP over TLS to Proposed Standard 
Date: Fri, 27 Jul 2001 18:55:44 -0400
Sender: [email-masked]

> > I agree that we shouldn't worry about being non-interoperable with
> > nonexistent implementations.  But I seriously question whether you
> > can determine that there aren't a significant number of such
> > implementations.  I expect there would be a delay between deployment
> > of such implementations and use of the STARTTLS feature, so the
> > "would not survive in the wild" argument is, for me, unpersuasive.
> 
> Surely *someone* would have heard of such an implementation if it
> existed anywhere?

I've seen zero discussion of the extent of broken vs. conforming 
implementations in groups that are frequented by SMTP implementors.
All I've seen is your claim that most client implementations fail to 
follow the spec in sending TLS 1.0 Hello messages.  No offense,
but I don't think that's sufficient justification to change the spec.

Keith

Date: Sat, 28 Jul 2001 00:22:26 +0200
From: Bodo Moeller <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: SMTP Service Extension for Secure SMTP over TLS to Proposed Standard
Sender: [email-masked]

On Fri, Jul 27, 2001 at 03:33:52PM -0400, Keith Moore wrote:

>> The successor of RFC 2487 with those backwards-compatibility-compatibility
>> requirements will actually be easier to implement than RFC 2487. Here's
>> some RFC 2487 fun:
>> 
>>    After receiving a 220 response to a STARTTLS command, the client
>>    SHOULD start the TLS negotiation before giving any other SMTP
>>    commands.
>> 
>> I.e., when the server expects a Client Hello message (in whatever
>> format), it may receive an SMTP command in plain ASCII instead if the
>> client has decided that it does not want to use TLS after all.

> because it's only a SHOULD and not a MUST.  
> I agree, that's a bug in the spec.

>> I bet that not only most clients are 'broken' (because they use
>> SSL 2.0 compatible Client Hello messages), but all servers are 'broken'
>> too because they cannot handle cleartext SMTP commands directly after
>> they have accepted STARTTLS.
>> 
>> This, too, should be changed.  This time the change to the
>> specification will magically repair lots of broken servers at the risk
>> of turning some conforming clients into non-conforming ones.

> even conforming clients need a good reason to violate a SHOULD.
> how many good reasons to do this have been identified?

It is easy to make up a reason.  E.g. the client TLS implementation
wants /dev/random-style randomness and some other process on the same
host has used up all the entropy, so instead of sending a Client Hello
the client falls back to cleartext.

>> These are two specification changes that will adjust the RFC to
>> reality.  There's a minor chance that some previously conforming
>> implementations suddenly will stop to be conforming, 

> that's not the issue.  the issue is whether implementations conforming
> to the old specification will stop interoperating with those conforming 
> to the new specification.
> 
> I agree that we shouldn't worry about being non-interoperable with
> nonexistent implementations.  But I seriously question whether you
> can determine that there aren't a significant number of such 
> implementations.  I expect there would be a delay between deployment
> of such implementations and use of the STARTTLS feature, so the
> "would not survive in the wild" argument is, for me, unpersuasive.

Surely *someone* would have heard of such an implementation if it
existed anywhere?

-- 
Bodo Möller <[email-masked]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

Date: Fri, 27 Jul 2001 14:31:59 -0700 (PDT)
From: [email-masked]
Subject: Re: Last Call: SMTP Service Extension for Secure SMTP over TLS to Proposed Standard
To: Keith Moore <[email-masked]>
Cc: Bodo Moeller <[email-masked]>, Keith Moore <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> > The successor of RFC 2487 with those backwards-compatibility-compatibility
> > requirements will actually be easier to implement than RFC 2487. Here's
> > some RFC 2487 fun:
> >
> >    After receiving a 220 response to a STARTTLS command, the client
> >    SHOULD start the TLS negotiation before giving any other SMTP
> >    commands.
> >
> > I.e., when the server expects a Client Hello message (in whatever
> > format), it may receive an SMTP command in plain ASCII instead if the
> > client has decided that it does not want to use TLS after all.

> because it's only a SHOULD and not a MUST.
> I agree, that's a bug in the spec.

I also agree that this is a bug and it needs to be changed.

				Ned

From: Keith Moore <[email-masked]>
To: Bodo Moeller <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: SMTP Service Extension for Secure SMTP over TLS to Proposed Standard 
Date: Fri, 27 Jul 2001 15:33:52 -0400
Sender: [email-masked]

> >         I have a difficult time understanding why SMTP client authors
> > thought it was acceptable to send SSL 2.0 Hello messages.  Maybe they just
> > blindly linked in SSL libraries without telling them what protocol
> > version to use?
> 
> Or they chose a pragmatic approach.  Some alleged 'STARTTLS' servers
> only support SSL 3.0.  These are clearly broken, but making clients
> backwards compatible with them still looks like a good idea.

it looks like a good idea IF it doesn't keep them from being
compatible with servers that conform to the standard.

> The successor of RFC 2487 with those backwards-compatibility-compatibility
> requirements will actually be easier to implement than RFC 2487. Here's
> some RFC 2487 fun:
> 
>    After receiving a 220 response to a STARTTLS command, the client
>    SHOULD start the TLS negotiation before giving any other SMTP
>    commands.
> 
> I.e., when the server expects a Client Hello message (in whatever
> format), it may receive an SMTP command in plain ASCII instead if the
> client has decided that it does not want to use TLS after all.

because it's only a SHOULD and not a MUST.  
I agree, that's a bug in the spec.

> I bet that not only most clients are 'broken' (because they use
> SSL 2.0 compatible Client Hello messages), but all servers are 'broken'
> too because they cannot handle cleartext SMTP commands directly after
> they have accepted STARTTLS.
> 
> This, too, should be changed.  This time the change to the
> specification will magically repair lots of broken servers at the risk
> of turning some conforming clients into non-conforming ones.

even conforming clients need a good reason to violate a SHOULD.
how many good reasons to do this have been identified?

> These are two specification changes that will adjust the RFC to
> reality.  There's a minor chance that some previously conforming
> implementations suddenly will stop to be conforming, 

that's not the issue.  the issue is whether implementations conforming
to the old specification will stop interoperating with those conforming 
to the new specification.

I agree that we shouldn't worry about being non-interoperable with
nonexistent implementations.  But I seriously question whether you
can determine that there aren't a significant number of such 
implementations.  I expect there would be a delay between deployment
of such implementations and use of the STARTTLS feature, so the
"would not survive in the wild" argument is, for me, unpersuasive.

Keith

Date: Fri, 27 Jul 2001 20:52:38 +0200
From: Bodo Moeller <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: Bodo Moeller <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: SMTP Service Extension for Secure SMTP over TLS to Proposed Standard
Sender: [email-masked]

On Fri, Jul 27, 2001 at 10:51:07AM -0400, Keith Moore wrote:

>>> Servers can tolerate such clients if they wish.  But clients that send 
>>> anything other than a TLS 1.0 Hello message shouldn't expect to 
>>> interoperate with servers that assert STARTTLS.  The way the TLS
>>> protocol is designed, the burden is on the client to send an appropriately
>>> formatted Hello message.

>> The TLS protocol includes provisions for protocol version negotiation.

> Yes, I understand.  It's the SSL 2.0 Hello messages that I'm concerned 
> about, not SSL 3.0 Hello messages with a maximum version # >= 3.1.

Even such SSL 3.0 backwards compatible Client Hello messages are not
strictly TLS 1.0, so servers might reject them out of spite.

> And yes, this is really a bug in the TLS spec, and maybe that's where
> it should be fixed.  
> 
> But given that SMTP STARTTLS has *never* supported anything less than
> TLS 1.0

RFC 2487 (January 1999) says

   TLS [TLS], more commonly known as SSL, is a popular mechanism for
   enhancing TCP communications with privacy and authentication. TLS is
   in wide use with the HTTP protocol, and is also being used for adding
   security to many other common protocols that run over TCP.

The version number (TLS 1.0) appears only in the 'References' section.
It is clear that RFC 2487 is intended primarily for TLS 1.0, but the
RFC does not discuss differences between TLS 1.0 and the earlier SSL
protocols, and it does not discuss backwards compatibility issues.  I
assume this was mainly an oversight -- the 'more commonly known as
SSL' part reveals some fuzziness with respect to protocol version
differences, and I doubt that TLS 1.0 was 'in wide use with the HTTP
protocol' in January 1999.  (The TLS 1.0 RFC is from January 1999 too.
Microsoft browsers have supported TLS 1.0 for some time, but it still
is disabled by default.  Netscape may have started to support TLS 1.0
by now.  TLS with HTTP is in wide use among Lynx-SSL users, though.)

>         I have a difficult time understanding why SMTP client authors
> thought it was acceptable to send SSL 2.0 Hello messages.  Maybe they just 
> blindly linked in SSL libraries without telling them what protocol
> version to use?

Or they chose a pragmatic approach.  Some alleged 'STARTTLS' servers
only support SSL 3.0.  These are clearly broken, but making clients
backwards compatible with them still looks like a good idea.

> I think it's quite reasonable to document the fact that lots of SMTP
> clients have been shipped that send out SSL 2.0 Hello messages, and
> that servers might want to support these messages (you could even
> say RECOMMENDED) in addition to TLS 1.0 messages.  But in the future, 
> clients should send TLS 1.0 Hello messages.

In the future, yes.  But I am also concerned about the present.

> I have limited faith in a WG's ability to enumerate all existing 
> implementations, and I don't like the WG deciding that broken 
> implementations are more deserving of compatibility with future
> versions of the standard, than ones that followed the original spec.

The successor of RFC 2487 with those backwards-compatibility-compatibility
requirements will actually be easier to implement than RFC 2487. Here's
some RFC 2487 fun:

   After receiving a 220 response to a STARTTLS command, the client
   SHOULD start the TLS negotiation before giving any other SMTP
   commands.

I.e., when the server expects a Client Hello message (in whatever
format), it may receive an SMTP command in plain ASCII instead if the
client has decided that it does not want to use TLS after all.
I bet that not only most clients are 'broken' (because they use
SSL 2.0 compatible Client Hello messages), but all servers are 'broken'
too because they cannot handle cleartext SMTP commands directly after
they have accepted STARTTLS.

This, too, should be changed.  This time the change to the
specification will magically repair lots of broken servers at the risk
of turning some conforming clients into non-conforming ones.

These are two specification changes that will adjust the RFC to
reality.  There's a minor chance that some previously conforming
implementations suddenly will stop to be conforming, but there's
serious doubt that this kind of conforming implementation has ever
existed -- and if they did, they were not too useful because they
could not interoperate with the rest of the known world.

>> As I said before, essentially all existing
>> STARTTLS clients are 'broken' in the sense that they use backwards
>> compatible Client Hello messages; so STARTTLS servers not supporting
>> backwards compatible Client Hello messages wouldn't be able to survive
>> in the wild.  

> not necessarily true - it just means that people wouldn't use the
> STARTTLS feature of the client.

OK, they might have been able to survive, but surely they were hiding
well.  Make that 'publicly referenced STARTTLS servers', then.
While I don't know what people do in the privacy of their intranets,
I am not aware of compatibility problems with public MXes insisting on
pure TLS 1.0 Client Hello messages.

-- 
Bodo Möller <[email-masked]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

From: Keith Moore <[email-masked]>
To: Bodo Moeller <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: SMTP Service Extension for Secure SMTP over TLS to Proposed Standard 
Date: Fri, 27 Jul 2001 10:51:07 -0400
Sender: [email-masked]

> [...]
> >>> This is completely bogus.  The reason we have a TLS specification
> >>> is so people can get interoperability by implementing it.  If they 
> >>> instead implement some earlier specification that isn't TLS, they're
> >>> not meeting the requirements of the standard.  SMTP servers that claim 
> >>> to support STARTTLS and don't accept TLS 1.0 Hello messages are BROKEN, 
> >>> full stop.
> 
> >> I agree that such servers are broken.  But clients may want to
> >> tolerate them anyway, and it is easy for TLS-only servers to tolerate
> >> clients tolerating such broken servers.
> 
> > Servers can tolerate such clients if they wish.  But clients that send 
> > anything other than a TLS 1.0 Hello message shouldn't expect to 
> > interoperate with servers that assert STARTTLS.  The way the TLS
> > protocol is designed, the burden is on the client to send an appropriately
> > formatted Hello message.
> 
> The TLS protocol includes provisions for protocol version negotiation.

Yes, I understand.  It's the SSL 2.0 Hello messages that I'm concerned 
about, not SSL 3.0 Hello messages with a maximum version # >= 3.1.

And yes, this is really a bug in the TLS spec, and maybe that's where
it should be fixed.  

But given that SMTP STARTTLS has *never* supported anything less than
TLS 1.0 I have a difficult time understanding why SMTP client authors
thought it was acceptable to send SSL 2.0 Hello messages.  Maybe they just 
blindly linked in SSL libraries without telling them what protocol
version to use?

I think it's quite reasonable to document the fact that lots of SMTP
clients have been shipped that send out SSL 2.0 Hello messages, and
that servers might want to support these messages (you could even
say RECOMMENDED) in addition to TLS 1.0 messages.  But in the future, 
clients should send TLS 1.0 Hello messages.

> > does it matter?  the current specification defines rules such that if you 
> > follow them, you should be able to interoperate.  what you're proposing 
> > to do is to change the rules so that servers that followed the old 
> > spec, might not interoperate with clients that follow the new spec.
> 
> This is true, but I seriously doubt that there are any servers that
> would have such problems.  

I have limited faith in a WG's ability to enumerate all existing 
implementations, and I don't like the WG deciding that broken 
implementations are more deserving of compatibility with future
versions of the standard, than ones that followed the original spec.

> As I said before, essentially all existing
> STARTTLS clients are 'broken' in the sense that they use backwards
> compatible Client Hello messages; so STARTTLS servers not supporting
> backwards compatible Client Hello messages wouldn't be able to survive
> in the wild.  

:-)

not necessarily true - it just means that people wouldn't use the
STARTTLS feature of the client.

Keith

Date: Fri, 27 Jul 2001 13:05:17 +0200
From: Bodo Moeller <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: SMTP Service Extension for Secure SMTP over TLS to Proposed Standard
Sender: [email-masked]

On Thu, Jul 26, 2001 at 06:08:38PM -0400, Keith Moore wrote:

[...]
>>> This is completely bogus.  The reason we have a TLS specification
>>> is so people can get interoperability by implementing it.  If they 
>>> instead implement some earlier specification that isn't TLS, they're
>>> not meeting the requirements of the standard.  SMTP servers that claim 
>>> to support STARTTLS and don't accept TLS 1.0 Hello messages are BROKEN, 
>>> full stop.

>> I agree that such servers are broken.  But clients may want to
>> tolerate them anyway, and it is easy for TLS-only servers to tolerate
>> clients tolerating such broken servers.

> Servers can tolerate such clients if they wish.  But clients that send 
> anything other than a TLS 1.0 Hello message shouldn't expect to 
> interoperate with servers that assert STARTTLS.  The way the TLS
> protocol is designed, the burden is on the client to send an appropriately
> formatted Hello message.

The TLS protocol includes provisions for protocol version negotiation.
The client's Client Hello message indicates a maximum supported
version number and a minimum supported version number.  The maximum
supported version certainly must be 3.1 (= TLS 1.0) for clients using
STARTTLS (and servers must be able to handle higher version numbers
that may be used in the future when a new revision of the TLS
specification assigns a higher version number).  The minimum supported
version number must be lower than 3.1 if the client wants to achieve
backwards compatibility.

If a client wants backwards compatibility with SSL 3.0 servers, the
only difference is that the record header of the Client Hello message
may contain version number 3.0 rather than 3.1.  The 'client_version'
field in the actual Client Hello message still will be 3.1 (or
higher).  This is easy for servers to handle -- and this is exactly
how protocol version negotiation between different versions of TLS
will work in the future.

Backwards compatibility with SSL 2.0 servers is a little more
difficult in theory, but turns out to be less error-prone in practice.
The Client Hello message has some structural differences, and the SSL
3.0/TLS 1.0 record format is not used; so servers have to copy some
data around to transform the Client Hello message into the TLS 1.0
format.  Version number 2.0 is not explicitly contained in the
message, and this avoids certain bugs in broken SSL/TLS server
software that is probably still around.

The problem with the TLS RFC is that it describes how backwards
compatibility can be achieved, but not in a way such that
interoperability is guaranteed:

E. Backward Compatibility With SSL

   [...]

   TLS 1.0 clients that support SSL Version 2.0 servers must send SSL
   Version 2.0 client hello messages [SSL2]. TLS servers should accept
   either client hello format if they wish to support SSL 2.0 clients on
   the same connection port. [...]

This means that TLS 1.0 clients that support SSL 2.0 servers cannot
necessarily communicate with TLS 1.0 servers that do not with to
support SSL 2.0 clients -- even though both the client and the server
are willing to use TLS 1.0.

>>>             Similarly, clients that issue a STARTTLS command and don't 
>>> send TLS 1.0 Hello messages are also BROKEN, full stop.  

>> Can you name an existing SMTP client with STARTTLS support that is not
>> 'broken' by your definition?  

> does it matter?  the current specification defines rules such that if you 
> follow them, you should be able to interoperate.  what you're proposing 
> to do is to change the rules so that servers that followed the old 
> spec, might not interoperate with clients that follow the new spec.

This is true, but I seriously doubt that there are any servers that
would have such problems.  As I said before, essentially all existing
STARTTLS clients are 'broken' in the sense that they use backwards
compatible Client Hello messages; so STARTTLS servers not supporting
backwards compatible Client Hello messages wouldn't be able to survive
in the wild.  The change from RFC 2487 is just meant to adjust the
STARTTLS specification to reality.  After all this is not about some
ITU networking protocol that should merely look nice on paper :-)

-- 
Bodo Möller <[email-masked]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

From: Keith Moore <[email-masked]>
To: Bodo Moeller <[email-masked]>
cc: Keith Moore <[email-masked]>, To: ;
Subject: Re: Last Call: SMTP Service Extension for Secure SMTP over TLS to Proposed Standard 
Date: Thu, 26 Jul 2001 18:08:38 -0400
Sender: [email-masked]

> >>> Also, why is it not a MUST that Clients send TLS 1.0 Hello messages?
> 
> >>       Clients MAY use backwards compatible SSL Client Hello message
> >>       formats.  However, except for SSL session resumption, Client
> >>       Hello messages MUST be suitable for negotiating TLS 1.0 or later
> >>       (i.e. the version field of SSL 2.0 compatible Client Hello
> >>       messages or the client_version field of SSL 3.0 compatible Client
> >>       Hello messages must be at least 3.1).
> >> 
> >>       Servers MUST be able to understand backwards compatible SSL
> >>       Client Hello messages, provided that the client indicates that
> >>       it supports TLS 1.0 or later.
> >> 
> >>       Note that neither clients nor servers are required to actually
> >>       support protocol versions other than TLS 1.0; but the above rules
> >>       make sure that clients can operate in a backwards-compatible mode
> >>       without risking interoperability with servers following the
> >>       current specifications.
> 
> > This is completely bogus.  The reason we have a TLS specification
> > is so people can get interoperability by implementing it.  If they 
> > instead implement some earlier specification that isn't TLS, they're
> > not meeting the requirements of the standard.  SMTP servers that claim 
> > to support STARTTLS and don't accept TLS 1.0 Hello messages are BROKEN, 
> > full stop.
> 
> I agree that such servers are broken.  But clients may want to
> tolerate them anyway, and it is easy for TLS-only servers to tolerate
> clients tolerating such broken servers.

Servers can tolerate such clients if they wish.  But clients that send 
anything other than a TLS 1.0 Hello message shouldn't expect to 
interoperate with servers that assert STARTTLS.  The way the TLS
protocol is designed, the burden is on the client to send an appropriately
formatted Hello message.

> >             Similarly, clients that issue a STARTTLS command and don't 
> > send TLS 1.0 Hello messages are also BROKEN, full stop.  
> 
> Can you name an existing SMTP client with STARTTLS support that is not
> 'broken' by your definition?  

does it matter?  the current specification defines rules such that if you 
follow them, you should be able to interoperate.  what you're proposing 
to do is to change the rules so that servers that followed the old 
spec, might not interoperate with clients that follow the new spec.
That's not something that should be done lightly.

if you can define a set of rules by which old and new clients can
interoperate with old and new servers, without compromising security,
I would find that acceptable.  but I actually think it's more 
important to allow implementations *that followed the spec*
to continue to interoperate, as it is to allow implementations that
failed to follow the spec to interoperate.  (unless of course there
was a fundamental bug in the spec, which doesn't seem to be the case here.)

> > If a server wants to accept older Hello messages, that's its own
> > business.
> 
> This is not about 'older' Client Hello messages, this is about
> backwards compatible Client Hello messages -- old format, but new
> content.

yes, I understand the distinction.

> >            And servers would do well to parse older Hello messages
> > and continue with the TLS dialog even if they don't accept the
> > resulting client authentication as valid and don't treat the 
> > negotiated session as if it were secure - just because it makes
> > for better error recovery.
> 
> A backwards compatible Client Hello message does not mean that the
> connection actually uses the older protocol.  (And anyway, client
> authentication isn't worse in SSL 3.0 than in TLS 1.0; in fact, most
> cryptographic defects of SSL 3.0 have been preserved in TLS 1.0.)

hmmm.  I thought TLS 1.0 had fixed a few of these.
(but it's been a while since I analyzed it in detail, and that was
quite painful enough.)

> >                             But client implementations shouldn't 
> > expect that sending older Hello messages are going to make them
> > interoperable with servers that advertise STARTTLS. 
> 
> They cannot expect interoperability if they support only SSL 3.0 or
> even SSL 2.0, but that's not what this is about.  No-one requires
> servers to support SSL 3.0 or SSL 2.0; all that is required is support
> for backwards compatible Client Hello handshake messages so that it is
> possible for clients to tolerate SSL-only servers if they feel like
> it.  Backwards compatible Client Hello messages are described in the
> TLS RFC.

I think the problem is that you're adding a new requirement that would
keep conforming older servers (that did not recognize old format hello
messages) from interoperating with new clients.

Keith

Date: Thu, 26 Jul 2001 23:33:35 +0200 (CEST)
From: Bodo Moeller <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: To:[email-masked], Paul Hoffman / IMC <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Last Call: SMTP Service Extension for Secure SMTP over TLS to Proposed Standard 
Sender: [email-masked]

Keith Moore <[email-masked]>:

>>> Also, why is it not a MUST that Clients send TLS 1.0 Hello messages?

>>       Clients MAY use backwards compatible SSL Client Hello message
>>       formats.  However, except for SSL session resumption, Client
>>       Hello messages MUST be suitable for negotiating TLS 1.0 or later
>>       (i.e. the version field of SSL 2.0 compatible Client Hello
>>       messages or the client_version field of SSL 3.0 compatible Client
>>       Hello messages must be at least 3.1).
>> 
>>       Servers MUST be able to understand backwards compatible SSL
>>       Client Hello messages, provided that the client indicates that
>>       it supports TLS 1.0 or later.
>> 
>>       Note that neither clients nor servers are required to actually
>>       support protocol versions other than TLS 1.0; but the above rules
>>       make sure that clients can operate in a backwards-compatible mode
>>       without risking interoperability with servers following the
>>       current specifications.

> This is completely bogus.  The reason we have a TLS specification
> is so people can get interoperability by implementing it.  If they 
> instead implement some earlier specification that isn't TLS, they're
> not meeting the requirements of the standard.  SMTP servers that claim 
> to support STARTTLS and don't accept TLS 1.0 Hello messages are BROKEN, 
> full stop.

I agree that such servers are broken.  But clients may want to
tolerate them anyway, and it is easy for TLS-only servers to tolerate
clients tolerating such broken servers.

>             Similarly, clients that issue a STARTTLS command and don't 
> send TLS 1.0 Hello messages are also BROKEN, full stop.  

Can you name an existing SMTP client with STARTTLS support that is not
'broken' by your definition?  Most clients that I am aware of use
backwards compatible Client Hello messages indicating support for
TLS 1.0.  (But everything after this single handshake message is
usually pure TLS 1.0 -- SSL/TLS protocol version negotiation makes
sure they highest common protocol version is used.)

Forbidding backwards compatible Client Hello messages makes it a
little bit easier to implement servers in theory, but this does does
not help anyone in real life because virtually all connection attempts
will fail.

> If a server wants to accept older Hello messages, that's its own
> business.

This is not about 'older' Client Hello messages, this is about
backwards compatible Client Hello messages -- old format, but new
content.

>            And servers would do well to parse older Hello messages
> and continue with the TLS dialog even if they don't accept the
> resulting client authentication as valid and don't treat the 
> negotiated session as if it were secure - just because it makes
> for better error recovery.

A backwards compatible Client Hello message does not mean that the
connection actually uses the older protocol.  (And anyway, client
authentication isn't worse in SSL 3.0 than in TLS 1.0; in fact, most
cryptographic defects of SSL 3.0 have been preserved in TLS 1.0.)

>                             But client implementations shouldn't 
> expect that sending older Hello messages are going to make them
> interoperable with servers that advertise STARTTLS. 

They cannot expect interoperability if they support only SSL 3.0 or
even SSL 2.0, but that's not what this is about.  No-one requires
servers to support SSL 3.0 or SSL 2.0; all that is required is support
for backwards compatible Client Hello handshake messages so that it is
possible for clients to tolerate SSL-only servers if they feel like
it.  Backwards compatible Client Hello messages are described in the
TLS RFC.

-- 
Bodo Möller <[email-masked]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

Date: Sun, 15 Jul 2001 15:53:22 +0300
Subject: Re:Need info on LOGIN / PLAIN SMTP authentication mechanisams.
From: "Levent Serinol"<[email-masked]>
To: [email-masked]
Sender: [email-masked]

http://www.ietf.org/iesg/1rfc_index.txt

> Is these are standered mechanisams? Is available any drafts on this?
> 
> Thanks,
> - Koteswara Rao
> Ph: 040 6513274 Extn: 8842
> JUNO online services Dev Pvt Ltd.
> GPR building, Begumpet,
> Hyderabad, India

__________________________________________________
ÜCRETSÝZ E-MAIL ALDINIZ MI?
Türkçe ilk Portal  http://www.mynet.com

From: "Koti" <[email-masked]>
To: <[email-masked]>
Subject: Need info on LOGIN / PLAIN SMTP authentication mechanisams.
Date: Sat, 14 Jul 2001 12:52:58 +0530
Sender: [email-masked]

Hi,

Ref: http://www.sendmail.org/~ca/email/mel/SASL_ClientRef.html
In SMTP_ClientRef HTML mentioned SMTP authentication mechanisams supported
by
few email clients. I found RFCs on CRAM-MD5, Kerberos_v4 mechanisams.
I was unable to find RFC on PLAIN , LOGIN.

1. Is there any specific draft on LOGIN, PLAIN mechanisams?
2. Please send me links where can i get more info on these LOGIN, PLAIN
mechanisams.

One more doubt: Out look express is supporting NTLM, DPA SMTP authentication
mechanisms.
Is these are standered mechanisams? Is available any drafts on this?

Thanks,
- Koteswara Rao
Ph: 040 6513274 Extn: 8842
JUNO online services Dev Pvt Ltd.
GPR building, Begumpet,
Hyderabad, India
----------------------------------------------------------------
When one door of happiness closes, another opens; but often we look so long
at the closed door
that we do not see the one, which has opened for us. - Hellen Keller.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

To: [email-masked]
From: Eric Allman <[email-masked]>
cc: [email-masked]
Subject: Re: SMTP Service Extension for Priority 
Date: Mon, 09 Jul 2001 12:42:51 -0700
Sender: [email-masked]

It's worth noting that if you are looking to put this in a header,
sendmail has had such a thing for a long time in the form of the
Precedence: header.  As I recall, it went in because someone in a
military environment had to have this feature.  We can argue about
the implementation, but the goals were almost exactly as have been
described.

I didn't tie this in as an ESMTP extension or AUTH or any such
thing because it pre-dated ESMTP entirely, so none of that existed.

Precedence: is completely unsecured, and when I put it in I was
deeply sceptical about whether it would work (that is, if everyone
put in Precedence: 99 then it would be the same as everyone omitting
the header entirely).  However, that hasn't proven to be much of a
problem, perhaps because the main parameter it impacts is queue
sorting, and with high bandwidth links most mail queues move "fast
enough" to keep users happy.

I don't think anyone has played with tying it to AUTH or restricting
queue processing to messages above a certain precedence.

eric

============= In Reply To: ===========================================
: From:  [email-masked]
: Subject:  Re: SMTP Service Extension for Priority
: Date:  Wed, 27 Jun 2001 12:09:23 -0700 (PDT)

: 
: > > > yeah, it's a tradeoff.  priority is definitely an MTA function, and for
: > > > the past few years we've been fairly strict about requiring that MTA
: > > > protocol be transmitted in SMTP.  also, if a message is resent then
: > > > it will keep the same headers but should not necessarily keep the same
: > > > priority.
: > >
: > > Not necessarily, but it may make sense as a default. So this could argue
: > > for a header field rather than against.
: 
: > well, it forces MTAs to look at the message header, and IMHO we shouldn't
: > encourage this.  but most do it anyway...
: 
: > the purist in me doesn't like it. the pragmatist in me is almost
: > ambivalent about it.
: 
: The purist in me doesn't like it either, but the pragmatist is way way way
: in favor of a new header field.
: 
: > but if we accept that priority requires some kind of authenticaiton by
: > the sender, I do think it's in some sense cleaner if we get both the
: > authentication and the priority setting from the same protocol.
: > and I don't see how we can transmit the sender's authentication for
: > priority to servers other than the first hop  without an SMTP extension
: > anyway.  in other words, for submission SMTP AUTH might be sufficient,
: > but for relaying the sender's credentials to subsequent MTAs we're
: > going to need something new.
: 
: I'm not sure it is a good idea, but we could use the AUTH parameter stuff for
: this. (In other words, we already have a mechanism for conveying
: authrization information across multiple hops.)
: 
: > > (2) Don't split and process the recipients at the lower of the two priori
ties.
: 
: > surely that would violate the notion that higher priority messages should
: > be treated as least as favorably as lower priority ones.
:  
: Look at the phrasing you just used. You talked about higher priority
: *messages*, not *recipients*. I could easily argue that the priority of the
: *message* is that of the lowest priority recipient. Or the highest. Or an
: average.
: 
: Regardless of how you word this, aren't people going to think of this in term
s
: of message priority, not recipient priority? And what's the interface for
: setting per-recipient priorities going to look like?
: 
: > > And remember that when mapping to systems that only support per-message
: > > priority you'd be forced to split to retain the right semantics.
: 
: > not clear.  I think you could also comply by just giving the message
: > the same priority as that of the higest recipient.
: 
: Not when other semantics are conveyed by priority setting, as they sometimes
: are in other environments.
: 
: 				Ned

To: Keith Moore <[email-masked]>
cc: Paul Hoffman / IMC <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Last Call: SMTP Service Extension for Secure SMTP over TLS to Proposed Standard 
Date: Mon, 09 Jul 2001 08:15:15 -0700
From: Eric Rescorla <[email-masked]>
Sender: [email-masked]

> I guess I'm of the opinion that such knowledge must be explicitly configured 
> if MTAs are going to fail if it is not accurate - MTAs should not be making 
> guesses.
Disallowing this sort of caching makes autodiscovery a losing strategy
in any environment which includes active attack as part of its threat
model. I suspect that we'll have to suck that up but we should do
so conscious of the tradeoff.

-Ekr

From: Keith Moore <[email-masked]>
To: Keith Moore <[email-masked]>
cc: EKR <[email-masked]>, Paul Hoffman / IMC <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Last Call: SMTP Service Extension for Secure SMTP over TLS to Proposed Standard 
Date: Mon, 09 Jul 2001 10:53:59 -0400
Sender: [email-masked]

I should clarify this for the benefit of folks who aren't deep into email.
By "temporary failures" I mean 4xx response codes in SMTP - codes that will
tell the client "this won't work now, try again later".  As opposed to 
permanent (5xx) failures which tell the client "this won't ever work" and
cause the client to bounce the message.

> I don't think this will fly.  Any period of time during which valid mail will
> be bounced is too long.  Brief periods of time during which temporary failures
> would result from a mismatch might be tolerable, but a day is too long.

From: Keith Moore <[email-masked]>
To: EKR <[email-masked]>
cc: Keith Moore <[email-masked]>, Paul Hoffman / IMC <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Last Call: SMTP Service Extension for Secure SMTP over TLS to Proposed Standard 
Date: Mon, 09 Jul 2001 10:51:47 -0400
Sender: [email-masked]

> Idle speculation: Perhaps a compromise position would be to allow this
> sort of caching but to limit the period for which it may be
> used. E.g. the cache must expire in no more than 1 day. This would
> produce some bouncing but limit the scope of that bouncing. The
> advantage would be that the attacker would have to mount a concerted
> active attack over a period of a day.

I don't think this will fly.  Any period of time during which valid mail will 
be bounced is too long.  Brief periods of time during which temporary failures 
would result from a mismatch might be tolerable, but a day is too long.

I guess I'm of the opinion that such knowledge must be explicitly configured 
if MTAs are going to fail if it is not accurate - MTAs should not be making 
guesses.

Keith

To: Keith Moore <[email-masked]>
Cc: Paul Hoffman / IMC <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Last Call: SMTP Service Extension for Secure SMTP over TLS to Proposed Standard
Reply-to: EKR <[email-masked]>
From: Eric Rescorla <[email-masked]>
Date: 09 Jul 2001 07:50:13 -0700
Lines: 41
Sender: [email-masked]

Keith Moore <[email-masked]> writes:
> > This was discussed at length during the first round on this document, 
> > and the consensus was to use the words that are here. 
> 
> This is also bogus.  People need to be able to change server configurations,
> or switch from one server to another, without it causing bounced mail.
> Experimenting with TLS on an SMTP server (and turning it off later)
> should not cause subsequent mail for that SMTP server to bounce.
I'm afraid that Keith is right here. Unfortunately, this leaves
STARTTLS very vulnerably to active attack. 

Idle speculation: Perhaps a compromise position would be to allow this
sort of caching but to limit the period for which it may be
used. E.g. the cache must expire in no more than 1 day. This would
produce some bouncing but limit the scope of that bouncing. The
advantage would be that the attacker would have to mount a concerted
active attack over a period of a day.

> > >and if there is explicit configuration to require STARTTLS along a
> > >particular path, it seems perfectly reasonable for the client to refuse to
> > >relay the message for as long as the server fails to support STARTTLS,
> > >which could eventually result in a bounced message if delivery times out.
> > 
> > Again, that was not the consensus of the group.
> 
> the proposal needs consensus of the IETF, not just "the group".
> "the group" probably needs to go back and think about this again.
> (what group is this anyway?)
> 
> I find it completely bizarre that "the group" thinks that it's okay to
> fall back to an insecure path if the client knows that a secure path
> is supposed to be available. 
I agree with Keith here as well. However, note that said configuration
would have to include the expected identify of the server as well as
the fact that you expected TLS. Otherwise, a different form of active
attack is possible.

-Ekr

Date: Sun, 08 Jul 2001 21:17:17 -0700 (PDT)
From: [email-masked]
Subject: Re: SMTP QoS
To: Keith Moore <[email-masked]>
Cc: Pete Resnick <[email-masked]>, Dave Crocker <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> I think the problem here is the characterization of this proposal
> as an end-to-end QoS-assurance mechanism rather than just a way
> that trusted and authenticated parties can request priority
> handling of important messages through those parts of the mail
> system that trust their credentials and are willing to do that.

Nicely put. I agree. However, let's remember that it is this discussion that
has characterized the draft in this way, not the draft itself.

And let's also remember that there are all sorts of ways to skin the
authorization cat and authentication is but one means to that end. We have
ample experience authorizing relay in a variety of ways, including hacks  like
so-called POP-before-SMTP (shudder). There's no reason to expect that similar
tricks, or possibly very different tricks, could be used with priority.

> If we're trying to do the end-to-end QoS, I have huge doubts about
> our being able to make that happen.   We'd not only have to
> rigidly define the various levels of service, we'd also have to
> solve the general cross-realm trust problem.  (And then we'd have
> to get people to deploy something that they probably couldn't
> understand how to use.)

In general you may well be right. But it may be possible to build services with
enhanced capabilities that operate on a subset of our infrastructure using
these tools as a starting point.

> OTOH, If we're just trying to design a standard interface to a
> general-purpose mechanism for requesting priority handling
> among mutually consenting parties, that's much easier, and IMHO
> quite doable.

Exactly.

				Ned

Date: Sun, 08 Jul 2001 21:00:37 -0700 (PDT)
From: [email-masked]
Subject: Re: Last Call: SMTP Service Extension for Secure SMTP over TLS to Proposed Standard
To: Keith Moore <[email-masked]>
Cc: Paul Hoffman / IMC <[email-masked]>, Keith Moore <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> >       Note that neither clients nor servers are required to actually
> >       support protocol versions other than TLS 1.0; but the above rules
> >       make sure that clients can operate in a backwards-compatible mode
> >       without risking interoperability with servers following the
> >       current specifications.

> This is completely bogus.  The reason we have a TLS specification
> is so people can get interoperability by implementing it.  If they
> instead implement some earlier specification that isn't TLS, they're
> not meeting the requirements of the standard.  SMTP servers that claim
> to support STARTTLS and don't accept TLS 1.0 Hello messages are BROKEN,
> full stop.  Similarly, clients that issue a STARTTLS command and don't
> send TLS 1.0 Hello messages are also BROKEN, full stop.

Sigh. It is my understanding that there's a fair amount of SSL out there
masquerading as TLS. And using SSL is certainly better than using nothing.

Nevertheless, I think Keith is right. We have to take the long view. We cannot
cannot afford to be wishy-washy about this, much as short-term pragmatism would
say otherwise.

> If a server wants to accept older Hello messages, that's its own
> business.  And servers would do well to parse older Hello messages
> and continue with the TLS dialog even if they don't accept the
> resulting client authentication as valid and don't treat the
> negotiated session as if it were secure - just because it makes
> for better error recovery.  But client implementations shouldn't
> expect that sending older Hello messages are going to make them
> interoperable with servers that advertise STARTTLS.

Exactly. We're not precluding nonstandard behavior, but we're also not
condoning it.

> > >     An SMTP client can partially protect against these attacks by
> > >     recording the fact that a particular SMTP server offers TLS during
> > >     one session and generating an alarm if it does not appear in the
> > >     EHLO response for a later session. The lack of TLS during a session
> > >     SHOULD NOT result in the bouncing of email, although it could result
> > >     in delayed processing.

> > > it seems quite reasonable to explicitly configure a client to insist
> > > on the server supporting TLS, and refusing to send a message to the
> > > server if it doesn't advertise STARTTLS.  this also seems safer than
> > > the "automatic discovery" mechanism above.

> > This was discussed at length during the first round on this document,
> > and the consensus was to use the words that are here.

> This is also bogus.  People need to be able to change server configurations,
> or switch from one server to another, without it causing bounced mail.
> Experimenting with TLS on an SMTP server (and turning it off later)
> should not cause subsequent mail for that SMTP server to bounce.

At one point I toyed with the idea of a SASL mechanism based on a
Diffie-Hellman exchange. Clients and servers would remember the credentials
established from past exchanges and use them to mitigate man in the middle
attacks.

I gave up on this idea for precisely the reason Keith cites: Our SMTP
infrastucture is just too variable for such a scheme to work in wide
deployment. There will be too many times when retained information will be at
odds with infrastructure shifts and messages will fail to transfer.

				Ned

From: Keith Moore <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: Keith Moore <[email-masked]>, Dave Crocker <[email-masked]>, [email-masked], [email-masked]
Subject: Re: SMTP QoS 
Date: Sun, 08 Jul 2001 23:33:26 -0400
Sender: [email-masked]

> The decision to allow priority requests may not be based on
> identifying trusted and authenticated parties at all.

understood.  but if this turns out to be the usual policy, we will
have added a fair amount of useless complexity to the mail system.
I don't think we should dictate the policy by which sites choose
to honor a priority request, but I do think we have to make sure
that adequate authentication mechanisms exist so that sites that
want to prevent abuse of priority (while still being able to extend
that privlege it to those for whom they want to) can do so.

Keith

Date: Sun, 8 Jul 2001 22:19:24 -0500
To: Keith Moore <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: SMTP QoS
Cc: Dave Crocker <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On 7/8/01 at 10:56 PM -0400, Keith Moore wrote:

>I think the problem here is the characterization of this proposal as 
>an end-to-end QoS-assurance mechanism...

The draft certainly makes no such characterization.

>...rather than just a way that trusted and authenticated parties can 
>request priority handling of important messages through those parts 
>of the mail system that trust their credentials and are willing to 
>do that.

The decision to allow priority requests may not be based on 
identifying trusted and authenticated parties at all. A particular 
server for a mailing list may decide that its external spam blocking 
software is enough protection against unwanted attacks and that 
anyone sending to the mailing list (authenticated or not) may set 
their priorities as they choose: Perhaps people who bother to 
contribute to this especially esoteric mailing list can, on the 
whole, be trusted not to abuse priority setting.

Of course, the tools need to be available to only prioritize mail 
from authenticated and trusted parties for this to be a general and 
ubiquitous end-to-end service. But let's work on the tools first, and 
see if the general service falls out, or we end up with only a 
"consenting adults" service.

>If we're trying to do the end-to-end QoS, I have huge doubts about 
>our being able to make that happen.[...]
>
>OTOH, If we're just trying to design a standard interface to a 
>general-purpose mechanism for requesting priority handling among 
>mutually consenting parties, that's much easier, and IMHO quite 
>doable.

It very well may be that we can't do the former. However, I think we 
are reasonably able to do design that leaves room for the former if 
we get all of the other pieces in place, and settle for the latter 
either for the time being or never if we can't get the pieces in 
place. (Mail still isn't internationalized well, but leaving a 
charset label in MIME and pushing UTF-8 where we can may end us up in 
that place in the long run.)

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

From: Keith Moore <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: Dave Crocker <[email-masked]>, [email-masked], [email-masked]
Subject: Re: SMTP QoS 
Date: Sun, 08 Jul 2001 22:56:33 -0400
Sender: [email-masked]

I think the problem here is the characterization of this proposal
as an end-to-end QoS-assurance mechanism rather than just a way
that trusted and authenticated parties can request priority 
handling of important messages through those parts of the mail 
system that trust their credentials and are willing to do that.

If we're trying to do the end-to-end QoS, I have huge doubts about
our being able to make that happen.   We'd not only have to 
rigidly define the various levels of service, we'd also have to
solve the general cross-realm trust problem.  (And then we'd have
to get people to deploy something that they probably couldn't 
understand how to use.)

OTOH, If we're just trying to design a standard interface to a 
general-purpose mechanism for requesting priority handling 
among mutually consenting parties, that's much easier, and IMHO
quite doable.

Keith

From: Keith Moore <[email-masked]>
To: Paul Hoffman / IMC <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Last Call: SMTP Service Extension for Secure SMTP over TLS to Proposed Standard 
Date: Sun, 08 Jul 2001 22:35:49 -0400
Sender: [email-masked]

[[email-masked] copied - I suspect we need more SMTP folks on this]

> At 12:51 AM -0400 7/1/01, Keith Moore wrote:
> >here are some comments on this document
> >
> >1. section 5 says:
> >
> >     A publicly-referenced SMTP server MUST NOT require use of the
> >     STARTTLS extension in order to deliver mail locally. This rule
> >     prevents the STARTTLS extension from damaging the interoperability of
> >     the Internet's SMTP infrastructure. A publicly-referenced SMTP server
> >     is an SMTP server which runs on port 25 of an Internet host listed in
> >     the MX record (or A record if an MX record is not present) for the
> >     domain name on the right hand side of an Internet mail address.
> >
> >this might seem like a nit, but the fact that a host is listed as an MX
> >for a particular domain does not compel that host to run an SMTP server
> >that accepts mail for that domain - because nothing ensures that the party
> >that administers the DNS zone containing the MX record  has the
> >authorization of the party running the SMTP server to list that server
> >as a mail exchanger for that domain.
> >
> >(lately, several people report seeing lots of SMTP errors of the form
> >"we're not a mail exchanger for this domain".  whether this is more
> >likely due to a misconfiguration of the SMTP server, or of the DNS zone,
> >is unclear.)
> >
> >so I might suggest a slight change in wording
> >
> >     A publicly-referenced SMTP server
> >     is an SMTP server which runs on port 25 of an Internet host listed in
> >     the MX record (or A record if an MX record is not present) for the
> >     domain name on the right hand side of an Internet mail address, and
> >     when the SMTP server is configured to act as a mail exchanger for that
> >     domain.
> 
> That seems fine to me.
> 
> >but more generally, it seems like what needs to happen in response to
> >the RCPT command, when an SMTP server wishes to refuse non-TLSed mail,
> >is this:
> >
> >server listed  |	SMTP server configured to act as mail exchanger
> >as an MX for   |	for recipient domain
> >the recipient  |
> >domain         |                  no            |           yes
> >--------------------------------------------------------------------------
> >       no        | 530 must use starttls          | 530 must use starttls
> >                 |   or                           |
> >                 | 5xx not configured as an MX    |
> >                 |   for domain x.y               |
> >--------------------------------------------------------------------------
> >      yes        | 5xx server incorrectly listed  | return 2xx, 4xx, or 5xx
> >                 |  in DNS as MX for domain x.y   | based on whether the
> >                 |  (or similar message)          | recipient address is valid
> 
> Do others agree with this chart? I'm not that comfortable with 
> describing what a server that is not listed as an MX for a domain but 
> is configured to accept mail for that domain should do. Also, how 
> would a server that is not configured to accept mail for a domain 
> know whether or not it is listed as an MX for that domain? This is 
> not the document to describe those situations. I'm OK with no/no and 
> yes/yes parts of the table.

I think the upper right box is also correct.

The text in the lower left box was only a suggestion for providing 
text for the bounced mail that actually explains what is going
on.    It would be sufficient if the message were "5xx we do not 
accept mail for domain x.y".  (the usual message is something 
like "local configuration error")  Of course if the server is willing
to act as a third-party relay, it can return "2xx message not local;
will forward" and go on its merry way...  and it can decide whether
to accept third-party traffic based on whether the submitter has
authenticated with TLS and also on that submitter's identity.

(The server knows whether it's listed as an MX by looking up x.y in 
DNS and seeing whether any of the domain names returned resolve to 
any of its IP addresses.)

The point here is that the SMTP server is under no obligation to accept
mail (TLSed or otherwise) for a domain if it's not explicitly configured 
as a mail exchanger for that domain.  The fact that it's listed in DNS
is irrelevant.

I agree that this the text to be returned when the DNS and SMTP
configuration are out-of-sync isn't something that should be 
defined in an SMTP-over-TLS document; it's a general SMTP issue.

> >2.  similarly, if the client does do STARTTLS, if the server is *listed* in
> >DNS as an MX for the recipient's domain, it should not refuse to accept the
> >mail because the server doesn't recognize the client's credentials, or
> >because the server doesn't like the ciphersuite used, etc.
> >the server should act like is specified in the second row in the table above.
> >
> >in other words, if the client is talking to a publically-listed server,
> >and has a proper implementation of TLS, its use of STARTTLS shouldn't lessen
> >the chance that the mail will be delivered.
> 
> That sounds right, but I would like to hear specific wording on it.

How's this?

A client's attempt (successful or otherwise) to use the STARTTLS command 
SHOULD NOT cause a server to refuse to accept mail from a client, if the 
server would have accepted the message without authentication, even if 
the STARTTLS command or the subsequent TLS negotiation resulted in an error.

> >3. also in section 5
> >
> >I don't understand the reason for this being a MUST:
> >
> >     Servers MUST be able to understand backwards compatible SSL Client
> >     Hello messages (provided that client_version is TLS 1.0 or later),
> >     and clients MAY use backwards compatible Client Hellos messages.
> >     Neither clients or servers are required to actually offer Client
> >     Hello messages for anything other than TLS 1.0.
> >
> >I can see it being a SHOULD, but why should we insist that a SMTP server
> >that supports STARTTLS, also support outdated and nonstandard versions of SSL?
> >
> >Also, why is it not a MUST that Clients send TLS 1.0 Hello messages?
> 
> This was also noted by some TLS folks. Bodo Möller suggested the 
> following replacement:
> 
>       Clients MAY use backwards compatible SSL Client Hello message
>       formats.  However, except for SSL session resumption, Client
>       Hello messages MUST be suitable for negotiating TLS 1.0 or later
>       (i.e. the version field of SSL 2.0 compatible Client Hello
>       messages or the client_version field of SSL 3.0 compatible Client
>       Hello messages must be at least 3.1).
> 
>       Servers MUST be able to understand backwards compatible SSL
>       Client Hello messages, provided that the client indicates that
>       it supports TLS 1.0 or later.
> 
>       Note that neither clients nor servers are required to actually
>       support protocol versions other than TLS 1.0; but the above rules
>       make sure that clients can operate in a backwards-compatible mode
>       without risking interoperability with servers following the
>       current specifications.

This is completely bogus.  The reason we have a TLS specification
is so people can get interoperability by implementing it.  If they 
instead implement some earlier specification that isn't TLS, they're
not meeting the requirements of the standard.  SMTP servers that claim 
to support STARTTLS and don't accept TLS 1.0 Hello messages are BROKEN, 
full stop.  Similarly, clients that issue a STARTTLS command and don't 
send TLS 1.0 Hello messages are also BROKEN, full stop.  

If a server wants to accept older Hello messages, that's its own
business.  And servers would do well to parse older Hello messages
and continue with the TLS dialog even if they don't accept the
resulting client authentication as valid and don't treat the 
negotiated session as if it were secure - just because it makes
for better error recovery.  But client implementations shouldn't 
expect that sending older Hello messages are going to make them
interoperable with servers that advertise STARTTLS. 

> >4. in section 7
> >
> >     An SMTP client can partially protect against these attacks by
> >     recording the fact that a particular SMTP server offers TLS during
> >     one session and generating an alarm if it does not appear in the
> >     EHLO response for a later session. The lack of TLS during a session
> >     SHOULD NOT result in the bouncing of email, although it could result
> >     in delayed processing.
> >
> >it seems quite reasonable to explicitly configure a client to insist
> >on the server supporting TLS, and refusing to send a message to the
> >server if it doesn't advertise STARTTLS.  this also seems safer than
> >the "automatic discovery" mechanism above.
> 
> This was discussed at length during the first round on this document, 
> and the consensus was to use the words that are here. 

This is also bogus.  People need to be able to change server configurations,
or switch from one server to another, without it causing bounced mail.
Experimenting with TLS on an SMTP server (and turning it off later)
should not cause subsequent mail for that SMTP server to bounce.

> What you 
> propose does not go against the words in section 7 *if the client is 
> the orignator of the message*. 

or if the client and the server are in the same administrative domain
and have an a priori agreement to use TLS.

> If the client is an SMTP relay, what 
> you are proposing would cause mail to bounce, 

I don't see how.  What I'm proposing is intended to do two things
(a) to refuse to send mail over an insecure path if the client knows
a prior that the path is supposed to be secure
(b) to keep mail from bouncing when a server changes configuration
in the absence of firm knowledge that the path is supposed to be
secure

To put it simply, the fact that a particular server has used TLS in the
past should not be considered any indicator of whether it will do so
in the future.

> >and if there is explicit configuration to require STARTTLS along a
> >particular path, it seems perfectly reasonable for the client to refuse to
> >relay the message for as long as the server fails to support STARTTLS,
> >which could eventually result in a bounced message if delivery times out.
> 
> Again, that was not the consensus of the group.

the proposal needs consensus of the IETF, not just "the group".
"the group" probably needs to go back and think about this again.
(what group is this anyway?)

I find it completely bizarre that "the group" thinks that it's okay to
fall back to an insecure path if the client knows that a secure path
is supposed to be available.  To behave in this way makes it easy
to defeat any confidentiality service that might be gained by 
using TLS with SMTP.

Keith

Date: Sun, 8 Jul 2001 21:00:50 -0500
To: Dave Crocker <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: SMTP QoS
Cc: [email-masked], [email-masked]
Sender: [email-masked]

On 7/8/01 at 2:55 PM -0400, Dave Crocker wrote:

>At 12:54 PM 7/7/2001, [email-masked] wrote:
>
>>Tools first. Then services.
>
>Not quite.  What you are saying is syntax first.  Then semantics.

Nonsense. Your just making a straw man argument. Service != 
semantics. Service == infrastructure. What you do is define syntax 
and semantics and then let the infrastructure that is required for 
wide deployment be built later.

>No doubt I'm wrong.  Please provide some examples of Internet 
>standards that have been defined in this way and that have succeeded.

MX records (cf: routing mail into firewalled domains).
SASL
DSNs (for mailing list management)
BEEP/APEX

I can come up with more if you need. We *constantly* come up with 
ideas in the IETF, document syntax and semantics, and wait for the 
infrastructure to catch up and figure out how to make it work well on 
the net.

Dave, I think you're just way off base here, and knocking over 
strawmen isn't helping your credibility.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Sun, 08 Jul 2001 15:47:47 -0700 (PDT)
From: [email-masked]
Subject: Re: SMTP QoS
To: Dave Crocker <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> Continuing to try to focus on the core concern:

> At 12:54 PM 7/7/2001, [email-masked] wrote:

> >>However, note that we still do not have a way to specify QoS at the lower
> >>layers and that all efforts to provide that capability over the last 30
> >>years have failed.
> >
> >And what makes you think that exactly the same thing won't happen here if we
> >turn a simple priority label into a full-featured QoS scheme with tightly
> >specified semantics?

> I think you flipped the high-order bit on the semantics of my comment.

> The 30 years has been marked by a syntactic field that has had no semantics
> standard.  That is what you are supporting now, though the 30 years says it
> won't be productive.

This isn't my area, but the lower layer folks I've heard talk about QoS
problems don't appear to agree with this analysis or conclusion.

> IPv6 is attempting to provide detailed semantics.  Last I heard, that is
> both difficult and believed to be essential for v6 QoS.

Again, this isn't what I've been hearing. Only today I heard from one of the
IPv6 folks saying that what's needed is a simple, lightweight mechanism that is
actually implementable and doesn't promise more than it can deliver, and that
this is what has been missing all these years.

> > I believe that a less nailed down mechanism is potentially quite useful as a
> > tool that MTA implementors and service providers can use to build various
> > services. It is NOT a service in and of itself,

> This is an interesting approach to Internet standards.  Let's define field
> syntax, but defer defining standard semantics until the industry
> experiments enough to converge on a specific.

Nowhere did I say that there need be no absolutely semantics associated with
priority. Such a notion is clearly absurd, since it would allow someone to
assign opposite meaning to priority labels, or to assign different meaning
depending on the day of the week, or whatever.

The rest of your "argument" is nothing more than a straw man derived from this
gross exaggeration, so I'm not going to bother to refute it. And as for
examples of standardized things with incompletely specified semantics, there
are so many examples of these in successful standards I don't know where to
begin.

> Apparently we ARE ready for private efforts at exploring preferred
> semantics.  That's excellent.

And in order to conduct such efforts you have to have a way of labelling
things. That, IMO, is what Julian is trying to create.

				Ned

Date: Sun, 08 Jul 2001 14:55:12 -0400
To: [email-masked]
From: Dave Crocker <[email-masked]>
Subject: Re: SMTP QoS
Cc: [email-masked]
Sender: [email-masked]

Continuing to try to focus on the core concern:

At 12:54 PM 7/7/2001, [email-masked] wrote:

>>However, note that we still do not have a way to specify QoS at the lower
>>layers and that all efforts to provide that capability over the last 30
>>years have failed.
>
>And what makes you think that exactly the same thing won't happen here if we
>turn a simple priority label into a full-featured QoS scheme with tightly
>specified semantics?

I think you flipped the high-order bit on the semantics of my comment.

The 30 years has been marked by a syntactic field that has had no semantics 
standard.  That is what you are supporting now, though the 30 years says it 
won't be productive.

IPv6 is attempting to provide detailed semantics.  Last I heard, that is 
both difficult and believed to be essential for v6 QoS.

>I believe that a less nailed down mechanism is potentially quite useful as a
>tool that MTA implementors and service providers can use to build various
>services. It is NOT a service in and of itself,

This is an interesting approach to Internet standards.  Let's define field 
syntax, but defer defining standard semantics until the industry 
experiments enough to converge on a specific.

Imagine how much more effective Internet development would have been had 
that been done for, say, IP addressing.  To use your words, the field would 
have been "quite useful as a tool that [IP] implementors and service 
providers [could] use to build various services."  The same for domain name 
semantics.

Or wouldn't it be fun to specify a TCP windowing syntax, and then told 
implementors to develop whatever semantics they wanted.  I'm sure the 
interaction between, say, a Sun implementation and a Microsoft 
implementation would be treat to watch.

Of course, what you are describing is something that warrants -- at most -- 
experimental status, not Internet standards status.  Even then, the idea of 
having syntax without semantics are downright strange as an IETF activity.

>and if you succeed in turning
>it into one at the outset I predict you will find that it will either fail to
>match up to what customers want, what service providers can provide, or what
>enough MTAs can implement to actually deploy.

Thank you.  You are saying that we do not know enough to specify a standard 
semantics for priority.  I entirely agree.

We are not ready for an IETF standards effort for email priority.

Apparently we ARE ready for private efforts at exploring preferred 
semantics.  That's excellent.

>Tools first. Then services.

Not quite.  What you are saying is syntax first.  Then semantics.

That worked really well for IP precedence and SNMPv1 security didn't it? 
Debating methodology dictates that I cite 3 examples, but these two seem 
more than sufficient.

No doubt I'm wrong.  Please provide some examples of Internet standards 
that have been defined in this way and that have succeeded.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

From: Keith Moore <[email-masked]>
To: "White Snake" <[email-masked]>
cc: [email-masked]
Subject: Re: Max. no of allowed "rcpt to" commands in a smtp session? 
Date: Sun, 08 Jul 2001 11:07:57 -0400
Sender: [email-masked]

> That's what I'm saying. That MUST be a requirement for smtp protocol.

simply put, that's BS.  it won't reduce spam, and it would overly
constrain operations.

To: [email-masked]
Subject: Re: Max. no of allowed "rcpt to" commands in a smtp session?
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: 08 Jul 2001 07:01:32 -0700
Lines: 38
Sender: [email-masked]

White Snake <Snake"<[email-masked]> writes:

> That's what I'm saying. That MUST be a requirement for smtp protocol.
> It's a MUST. This kind'o approch will reduce spam.

Reducing spam isn't a MUST for the SMTP protocol, let alone any specific
way to attempt to do that.  Remember, the SMTP protocol is used in more
places than just the open Internet, and in many places where spam isn't an
issue.  On top of that, different people place different priorities on
reducing spam.

> Generally spammers use their client PCs to send a lot of junk mail to 
> specific destionation through that destionation's smtp server.What can
> you do about it ? simply nothing :-(

There's quite a bit that one can do about it.  For the particular problem
that you name, if you don't want to accept mail from systems that are not
regular mail servers, you may want to investigate using one of the mail
blocking lists designed for that purpose.  In this particular case, the
MAPS DUL sounds appropriate.  See <http://www.mail-abuse.org/dul/>.

One significant advantage of solutions like that is that different sites
can pick their own solutions as fit their user base, spam tolerance, and
willingness to reject possibly valid e-mail.  Some sites will want to only
accept mail from a very restricted subset of the Internet and some sites
will want to accept mail from anywhere.

> There must be a law that defines spam as illegal action in your 
> country.

I'm afraid that discussion of laws against abuses of Internet protocols is
a bit far afield for this mailing list, as it's not really a mailing list
about politics.  In order to get laws passed, you would need to get
involved in the political process, and it's unlikely that anyone here will
be able to help much with that.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Sun,  8 Jul 2001 14:45:12 +0300
Subject: Re:Re: Max. no of allowed "rcpt to" commands in a smtp session?
From: "White Snake"<[email-masked]>
To: [email-masked]
Sender: [email-masked]

>
> > Spammers always use weakness of smtp protocol. For example yahoo
can
> > accept any mail form any client. They do not check if the sender
is an
> > SMTP server and it's MX record to be ensure that sender's domain
and
> > IP belongs to right smtp server that has a MX record.
> 
> since there's no protocol requirement that an SMTP be both a client
and 
> a server on the same IP address, such a check would be tremendously
> stupid and misguided.
> 
> 
That's what I'm saying. That MUST be a requirement for smtp protocol.
It's a MUST. This kind'o approch will reduce spam. 
Generally spammers use their client PCs to send a lot of junk mail to 
specific destionation through that destionation's smtp server.What can
you do about it ? simply nothing :-(
There must be a law that defines spam as illegal action in your 
country. But if you consider that many countries aware of this action.
Than here is the point why someone does not change smtp protocol to
reduce this kind'o problems. Why do we mail administrators left alone
to find  out our own solutions ? 

Regards,

__________________________________________________
ÜCRETSÝZ E-MAIL ALDINIZ MI?
Türkçe ilk Portal  http://www.mynet.com

From: Keith Moore <[email-masked]>
To: "White Snake" <[email-masked]>
cc: [email-masked]
Subject: Re: Max. no of allowed "rcpt to" commands in a smtp session? 
Date: Sun, 08 Jul 2001 00:18:53 -0400
Sender: [email-masked]

> Spammers always use weakness of smtp protocol. For example yahoo can
> accept any mail form any client. They do not check if the sender is an
> SMTP server and it's MX record to be ensure that sender's domain and
> IP belongs to right smtp server that has a MX record.

since there's no protocol requirement that an SMTP be both a client and 
a server on the same IP address, such a check would be tremendously
stupid and misguided.

Date: Sat, 07 Jul 2001 09:54:13 -0700 (PDT)
From: [email-masked]
Subject: Re: SMTP QoS
To: Dave Crocker <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> Having thoroughly overdosed on fireworks, and trying to focus on the
> substantial issues, and being surprised how many there are...

>          Perhaps the most basic issue is that the specification
>          is standardized syntax, without any standardized
>          semantics.

>          The specification says that each MTA can do whatever it
>          feels like with the message.

> How can we possibly expect any sort of Internet-wide useful service out of
> this?

This may well be true. But getting such an outcome is not a requirement for
IETF standards work, your opinions to the contrary notwithstanding.

> I apologize for misunderstanding the examples you were citing.  Worse, I am
> astonished to hear that Internet mail has been functioning with a mechanism
> -- even a non-standard one -- that would permit me to specify increased
> handling priority.

The Internet is a very big place. I suspect that there are all sorts of
mechanisms in wide use in email and other protocols that all of us
participating in this discussion are unaware of. I know I find out about
various things that have deployed without my knowledge on a regular basis, and
I suspect my job connects me with a wide range of operational situations far
more than yours does.

> The fact of that ignorance prompts me to suggest that the reason we do not
> have a track record of abuse for this feature is because the general
> population of users does not know about it.  I am, of course, stating that
> explanation vastly more tentatively than I believe it.

First, I think the term "general population" is largely meaningless when
talking about the Internet. 

> > One more time: Past experience directly contradicts this (IMO overly
> > simplistic) assessment.

> Alas, I wish that this were simplistic or, at least, just a matter of my
> own opinion.  And since it has been 25 years since I made a habit or
> reading the relevant research literature, I can't counter your disbelief
> with a mass of citation.  Somehow I suspect that assuring you the citations
> are there won't be convincing either...

> Just for fun, I did a single sample query of a Cognitive Psych PhD and they
> could not quite believe that anyone would assert that this sort of
> mechanism (zero cost to the requester) would not be abused.

It surely is tempting to dig into the generally dismal track record of
predictions made by such "experts", but in this case it would be unfair to do
so because your query grossly misrepresented the situation. Nobody is saying
that the cost will be zero. Indeed, in my previous response I argued that in
one case exactly the opposite is true -- the cost to spammers is effectively
quite high.

And that was only one, and far from the only, example. Here's another: I cannot
speak to other implementations of priority mechanisms in MTAs, but the ones
I've done have various theshholds and therefore costs associated with them.

I'm not going to bother responding to the remainder of this section since
it all proceeds from the incorrect assumption that priority has no cost
associated with it.

> III.    TRANSPORT PRIORITY AS SMTP OPTION

> > However, this discussion does lead me to conclude that priority is best
> > done as an SMTP extension.

> Given that the goal is transport handling I entirely agree.

> (In case it has been looking as if I am against having any mechanism, let
> me try to be clear that I think having one is essential.  The rest of the
> communications world has priority mechanisms, so we need them in email
> too.  Business use demands it.  My concern is that we specify something
> that will work.)

And to be equally clear, I am neither for nor against having such a mechanism.
But additionally, I have no desire to force what is being proposed here into
something that tries to meet from the outset what you believe the requirements
of business to be.

> > > Do you really expect that relaying across the
> > > open Internet will require use of SMTP Auth?  In which century?

> > Nobody said anything about requiring it for relaying across the open Internet.
> > Using it as means of facilitating the use of extensions like priority
> > is another matter.

> This is getting confusing.  You don't like my use of the word "require" yet
> you accept that use of Auth for "facilitating" a priority extension.

No, what I'm saying is that one possible basis for transfer of priority
indicators is the SMTP AUTH parameter. This doesn't mean end users would
have to use SMTP AUTH (although in fact it is fairly widely deployed). Nor
does such usage require a network-wide authentication scheme. The credentials
passed around by SMTP AUTH may be derived from a service level arrangement,
not from the end-user's creditentials.

> If the priority extension is to be seriously useful -- and for Internet
> mail to satisfy business requirements, it does need to be -- you claim that
> the Auth mechanism will enable, facilitate or otherwise be relevant to
> creating that utility, then I claim it will need to be Internet-wide.

You are conflating end-user use of authentication with relay use of the AUTH
parameter. The two can be intertwined or disjoint. And even when they are
intertwined it doesn't mean that different administrative domains have to share
or cross-validate all their end-user's authentication credentials.

> (Can you only send FedEx to places with which you have made a prior
> arrangement?

Actually, yes. You can only send FedEx to places where they have service.

> Bi-lateral agreements are a good way to start, but they don't
> scale, of course.)

Hierarchical ones do.

> My point, therefore, is that wide-scale, inter-organization use of security
> has been essentially non-existent for anything except SSL, and then only
> for privacy, not authentication.  That makes it highly problematic to
> specify a facility that relies on inter-group authentication.  (The current
> proposal does not do that; but your argument seems to rely on it.)

And this is entirely irrelevant since even if priority came to depend on SMTP
AUTH (which I don't claim will necessarily be the outcome) that would not in
turn require sharing of all authentication credentials.

> > Well, one of the things that happens all the time is private bilateral
> > agreements between service providers to provide improved QoS

> In fact, bilateral agreements are the essence of the public international
> phone service and have always been the essence of the public, commercial
> Internet.  No ISP is ever forced to peer with another.  And peering is a
> bilateral action.

In other words, bilateral agreements between service providers have scaled
sufficiently well to get us the Interent we have today. Doesn't this
argue that bilateral agreements about transfer of simple labels will
scale as well? Such an agreement would be FAR simpler than an existing
peering arrangement.

> But your point is, of course, about TAILORING the service on a bilateral
> basis.  And it's just fine that a) it happens, and b) the terms are kept
> private.

> However, note that we still do not have a way to specify QoS at the lower
> layers and that all efforts to provide that capability over the last 30
> years have failed.

And what makes you think that exactly the same thing won't happen here if we
turn a simple priority label into a full-featured QoS scheme with tightly
specified semantics?

I believe that a less nailed down mechanism is potentially quite useful as a
tool that MTA implementors and service providers can use to build various
services. It is NOT a service in and of itself, and if you succeed in turning
it into one at the outset I predict you will find that it will either fail to
match up to what customers want, what service providers can provide, or what
enough MTAs can implement to actually deploy.

Tools first. Then services. Priority labelling is a tool that could prove
useful in providing an SMTP QoS service. But we need to have it specified and
play around with it before we'll ever be able to define the service. (And while
I've used past ad-hoc forays into this area in arguing that various dire
predictions are far from certain outcomes, I'll be the first to admit that
there's a world of difference between a standardized, fine-grained, SMTP-level
facility and nonstandard, coarse-grained, header-level facilities.) 

And it should be understood that such tools in and of themselves aren't going
to make your business users happy. But given the number of so-called
"business-quality" email services springing up out there I will be very
surprised if they don't take any tool we provide and run with it. They
certainly have done so with DELIVERBY.

Divide and conquer, Dave. Divide and conquer.

				Ned

Date: Sat,  7 Jul 2001 20:40:34 +0300
Subject: Re:Re: Max. no of allowed "rcpt to" commands in a smtp session?
From: "White Snake"<[email-masked]>
To: [email-masked]
Sender: [email-masked]

> > I don't wanna let any spammer to send
> > hundereds of mails in a single smtp session.
> 
> Actually, you may want them to do this since it is possible to
detect such
> traffic and act on it in various ways. But if you block it outright
spammers

 detecting the spammer does not make any sense. 'cause first of all I
would be received that bunch of junk mails. secondly this can be a
dial-up/ASDL/leased-line or cable user (as generally it is) that
sending spam and of course blocking that IP does not stop them.

Spammers always use weakness of smtp protocol. For example yahoo can
accept any mail form any client. They do not check if the sender is an
SMTP server and it's MX record to be ensure that sender's domain and
IP belongs to right smtp server that has a MX record.

Regards,

__________________________________________________
ÜCRETSÝZ E-MAIL ALDINIZ MI?
Türkçe ilk Portal  http://www.mynet.com

Date: Sat, 07 Jul 2001 08:01:09 -0700 (PDT)
From: [email-masked]
Subject: Re: Max. no of allowed "rcpt to" commands in a smtp session?
To: white_snake <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> I couldn't find any information about max no of "rcpt to" commands
> allowed in a single smtp session in rfc2821.

See Section 4.5.3.1. It says:

recipients buffer
 
       The minimum total number of recipients that must be buffered is 100
       recipients. Rejection of messages (for excessive recipients) with fewer
       than 100 RCPT commands is a violation of this specification. The general
       principle that relaying SMTP servers MUST NOT, and delivery SMTP
       servers SHOULD NOT, perform validation tests on message headers suggests
       that rejecting a message based on the total number of recipients
       shown in header fields is to be discouraged. A server which imposes a
       limit on the number of recipients MUST behave in an orderly fashion,
       such as to reject additional addresses over its limit rather than
       silently discarding addresses previously accepted. A client that needs
       to deliver a message containing over 100 RCPT commands SHOULD be
       prepared to transmit in 100-recipient "chunks" if the server declines to
       accept more than 100 recipients in a single message. 

The wording is quite different but the limit value hasn't changed from RFC 821.

> It looks like there is no limit defined for it.

Nope. See above.

> I don't wanna let any spammer to send
> hundereds of mails in a single smtp session.

Actually, you may want them to do this since it is possible to detect such
traffic and act on it in various ways. But if you block it outright spammers
will simply accomodate your policy and in the process they may make the spam
they send harder to detect.

> So , what is the resonable
> max number of "rcpt to" commands for a single smtp session?
  
You may not want to limit the number at all. However, if you must limit it you
can put the limit no lower than 100 without violating the standard. And of
course a limit of 100 isn't much of a limit.

The bottom line is that hard limits on the number of recipients are not in and
of themselves an effective means of controlling spam and you should not be
pursuing them as such a solution.

				Ned

Date: Sat,  7 Jul 2001 13:22:18 +0300
Subject: Max. no of allowed "rcpt to" commands in a smtp session?
From: "white_snake"<[email-masked]>
To: [email-masked]
Sender: [email-masked]

Hi All,
 
I couldn't find any information about max no of "rcpt to" commands
allowed in a single smtp session in rfc2821. It looks like there is
no limit defined for it. I don't wanna let any spammer to send
hundereds of mails in a single smtp session.So , what is the resonable
max number of "rcpt to" commands for a single smtp session?
  
Regards,

__________________________________________________
ÜCRETSÝZ E-MAIL ALDINIZ MI?
Türkçe ilk Portal  http://www.mynet.com

To: [email-masked]
Subject: heads up:  IPv6 SMTP operational requirements draft
cc: [email-masked]
From: Keith Moore <[email-masked]>
Date: Fri, 06 Jul 2001 12:12:22 -0400
Sender: [email-masked]

SMTP folks might want to look at this Internet-Draft:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Next Generation Transition Working Group of the IETF.

        Title           : IPv6 SMTP operational requirements
        Author(s)       : M. Nakamura, J. Hagino
        Filename        : draft-ietf-ngtrans-ipv6-smtp-requirement-01.txt
        Pages           : 6
        Date            : 05-Jul-01
        
The memo lists operational requirements for IPv6 SMTP, and IPv6-capable
MX DNS records.  As we deploy IPv6 SMTP servers, it became apparent that
we need certain configuration in IPv6-capable MX DNS record, for stable
dual-stack (IPv4 and IPv6) SMTP operations.  The document tries to
clarify the problems we have in transition period between IPv4 SMTP and
IPv6 SMTP, and operational requirements for stable IPv4/v6 SMTP
operation.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-ipv6-smtp-requirement-01.txt

Date: Wed, 04 Jul 2001 23:21:36 -0700
To: [email-masked]
From: Dave Crocker <[email-masked]>
Subject: Re: SMTP QoS
Cc: [email-masked]
Sender: [email-masked]

Howdy,

Having thoroughly overdosed on fireworks, and trying to focus on the 
substantial issues, and being surprised how many there are...

I.      LACK OF SEMANTICS

At 03:07 PM 7/1/2001, [email-masked] wrote:
>Now, none of this implies that priority cannot be carried in a header.

         Perhaps the most basic issue is that the specification
         is standardized syntax, without any standardized
         semantics.

         The specification says that each MTA can do whatever it
         feels like with the message.

How can we possibly expect any sort of Internet-wide useful service out of 
this?

-----

II.     LIKELIHOOD OF ABUSE

>>The past experience you have been citing pertains to LOWER priority.  That
>>is quite different from one which includes HIGHER priority.
>
>Only one instance of past experience pertains to LOWER priority. Other
>instances pertain to higher priority, and there has been no indication of
>substantial abuse.

I apologize for misunderstanding the examples you were citing.  Worse, I am 
astonished to hear that Internet mail has been functioning with a mechanism 
-- even a non-standard one -- that would permit me to specify increased 
handling priority.

The fact of that ignorance prompts me to suggest that the reason we do not 
have a track record of abuse for this feature is because the general 
population of users does not know about it.  I am, of course, stating that 
explanation vastly more tentatively than I believe it.

>>   As I noted, we have well
>>seen that the Internet is now under the strong influence of selfish
>>actors. They do not participate as good neighbors.
>
>One more time: Past experience directly contradicts this (IMO overly
>simplistic) assessment.

Alas, I wish that this were simplistic or, at least, just a matter of my 
own opinion.  And since it has been 25 years since I made a habit or 
reading the relevant research literature, I can't counter your disbelief 
with a mass of citation.  Somehow I suspect that assuring you the citations 
are there won't be convincing either...

Just for fun, I did a single sample query of a Cognitive Psych PhD and they 
could not quite believe that anyone would assert that this sort of 
mechanism (zero cost to the requester) would not be abused.

The fact is, however, that the Internet today sees a considerable amount of 
abusive behavior.  Some is intentional and some is through 
ignorance.  Either way, a mechanism that is open, cost-free, and might have 
substantial benefit for the user WILL get used.

And abused.

It will get used excessively by some percentage of the population.  Will it 
get used enough to undermine the global mechanism?  (And remember that this 
particular mechanism has no solid specification of semantics, so the 
freedom of choice by each relay is particularly large.)

I claim yes.

And I claim that we have more than enough history with email abuse to 
substantiate that belief.

>anything that stands out, like a flood of mail from a single source all 
>marked priority urgent, is a sign of spam and is likely to be used as a 
>means of filtering mail.

The flood is the warning.  The priority is not.

In fact we all frequently see postal direct marketing folks emulate 
priority packaging, as a scam to get you to look at the contents.  Why do 
you believe that won't happen with email?

>Priority labelling used as a honeypot, in other words. But unlike you, I 
>doubt they are that stupid.

Sorry, but spammers are but one example of folks who will abuse the 
mechanism.

An open, cost-free mechanism that provides better service provides an 
inherent incentive for over-use.  The psychology of this point is not even 
slightly controversial because the incentives are far too clear.  And 
over-use will destroy the benefit.

-----

III.    TRANSPORT PRIORITY AS SMTP OPTION

>However, this discussion does lead me to conclude that priority is best 
>done as
>an SMTP extension.

Given that the goal is transport handling I entirely agree.

(In case it has been looking as if I am against having any mechanism, let 
me try to be clear that I think having one is essential.  The rest of the 
communications world has priority mechanisms, so we need them in email 
too.  Business use demands it.  My concern is that we specify something 
that will work.)

-----

IV.     DEPLOYMENT OF INTER-OPERATOR SMTP AUTH

>> > > 2.  References to usage of SMTP Auth with this option are confusing,
>> > >     since it is used for posting, not relaying.  I'd appreciate
>
>> >   SMTP AUTH not only provides facility for posting, it also
>> > provides facilities for relaying authentication credentials.
>
>>Do you really expect that relaying across the
>>open Internet will require use of SMTP Auth?  In which century?
>
>Nobody said anything about requiring it for relaying across the open Internet.
>Using it as means of facilitating the use of extensions like priority
>is another matter.

This is getting confusing.  You don't like my use of the word "require" yet 
you accept that use of Auth for "facilitating" a priority extension.

If the priority extension is to be seriously useful -- and for Internet 
mail to satisfy business requirements, it does need to be -- you claim that 
the Auth mechanism will enable, facilitate or otherwise be relevant to 
creating that utility, then I claim it will need to be Internet-wide.

(Can you only send FedEx to places with which you have made a prior 
arrangement? Bi-lateral agreements are a good way to start, but they don't 
scale, of course.)

My point, therefore, is that wide-scale, inter-organization use of security 
has been essentially non-existent for anything except SSL, and then only 
for privacy, not authentication.  That makes it highly problematic to 
specify a facility that relies on inter-group authentication.  (The current 
proposal does not do that; but your argument seems to rely on it.)

>I'm going to turn one of your own arguments back on you here. You like making
>analogies to lower layers.

Ned, this is worth being clear about:  my use of lower layers is not for 
"analogies".  I like looking to the history of lower layers engineering 
because it so often points up issues and approaches to solutions for the 
transport aspects of email.  Both are packet switching.  Vast differences, 
yes, but core similarities.

Staying on the high protocol ground, EDI provides an interesting tidbit of 
relevant experience:  Here we have a service that is commercial 
messaging.  In fact, it does have QoS.

But only within single providers.

No QoS guarantees between providers.  And that was with customers willing 
to pay remarkable premiums for good service.

>Well, one of the things that happens all the time is
>private bilateral agreements between service providers to provide improved QoS

In fact, bilateral agreements are the essence of the public international 
phone service and have always been the essence of the public, commercial 
Internet.  No ISP is ever forced to peer with another.  And peering is a 
bilateral action.

But your point is, of course, about TAILORING the service on a bilateral 
basis.  And it's just fine that a) it happens, and b) the terms are kept 
private.

However, note that we still do not have a way to specify QoS at the lower 
layers and that all efforts to provide that capability over the last 30 
years have failed.

With luck, the experience with private arrangements is providing useful 
input to the IPv6 QoS work.  Otherwise, the v6 effort will suffer the same 
likelihood of being a theoretical, inadequately specified service that does 
not match real needs.

Just like this proposal for email.

>At present there's no reason to do anything similar based on SMTP AUTH 
>because there aren't any facilities tied to its use. But if there were, 
>who's to say it would not happen?

Again I am thoroughly confused.  This hypothetical, future, inter-provider 
use of SMTP Auth is entirely independent of the proposal under 
discussion.  If not, then where does it appear in the specification?

>>If my request for special handling (priority) carries no expectation of
>>what actual handling will take place, then the option is entirely
>>useless.  If it does correlate with actual handling, then I had better have
>>better knowledge about the delivery behavior of my message than I had
>>without the option.  That constitutes increased predictability.  That is
>>what quality of service work is about.
>
>And actual experience disproves this line of reasoning completely. People will
>use such facilities even without even a scintilla of evidence of their
>efficacy.

Huh?  So the spammers will use it whether it works or not.

But you believe that regular users will regularly and differentially use a 
feature, even  if they have no idea whether it does any good?  Is this 
supposed to be a cargo cult explanation of system use?  They saw an email 
once get delivered and it had a priority bit set.  So they keep setting the 
bit hoping that, someday, their own email will get delivered quicker?

>This is why I find the arguments made in the FAX WG relating to the
>unreliable nature of MDNs to be unpersuasive

And I'll gladly swap bar wg anecdotes about the variable and creative ways 
people analyze protocol behavior and use, in the Fax wg and 
elsewhere.  However I'm unclear how to apply your point to the current 
discussion.

Please remember that my highest-order concern is in fact the first major 
section in this note:  no standardized semantics.

-----

V.      INTRANET

>> > > 4.      The IETF does not do intranet standards.
>
>> > Actually, the IETF does intranet standards all the time. This is 
>> especially
>
>No, what we conclude is that the notion of the IETF not doing intranet
>standards is complete hooey now and always has been.

Though probably frustrating, this exchange has actually been pretty useful.

It is clear that the oft-uttered claim "the IETF does not do protocols for 
intranets" is entirely the wrong wording.  And it is clear that small 
attempts at more precise wording, such as my earlier comment:

>>It is about being limited to an operational infrastructure that has 
>>significant dependence on a single, coherent administrative control.

Is equally inadequate.  The reference to 'infrastructure' was trying to 
distinguish between end-point behavior vs. intermediaries.

I am now suspecting that the whole point hinges on the IETF protocols 
having a) universal semantics, and b) data transfer performance 
characteristics that must work over the Internet as well as intranets.

Media-specific tailorings, such as ARP and DHCP using a broadcast 
mechanism, clearly do not work over the Big I.  However neither do they 
have different semantics from one intranet to another.

Bilateral agreement on semantics is an EDI speciality.  It's not the soup 
the IETF stirs.  Yet is is, in reality, the stock of the current proposal.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

From: Keith Moore <[email-masked]>
To: "D. J. Bernstein" <[email-masked]>
cc: [email-masked]
Subject: Re: SMTP QoS 
Date: Mon, 02 Jul 2001 19:49:44 -0400
Sender: [email-masked]

> I prefer to have all messages delivered immediately.

so would we all.  the only time that a priority mechanism is an issue
is when there are limited resources.

Date: 2 Jul 2001 23:22:37 -0000
Mail-Followup-To: [email-masked]
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: IANA SMTP registry
Sender: [email-masked]

http://cr.yp.to/smtp/ehlo.html includes a list of all the extension
names I've seen from SMTP servers.

The goal of the list is to prevent accidental conflicts. That's why ONEX
and VERB and various X* names are listed. I'm not going to limit the
list to IETF projects; that would interfere with the goal.

Let me know if you have any new names.

---Dan

Date: 2 Jul 2001 23:10:37 -0000
Mail-Followup-To: [email-masked]
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: SMTP QoS
Sender: [email-masked]

Here's a quote from the sendmail release notes in 1996: ``Conditions
were reversed for the Priority: header, resulting in all values being
interpreted as non-urgent except for non-urgent, which was interpreted
as normal.''

How long did this bug go unnoticed? Ten years? Fifteen years? And we're
supposed to believe that priority is a useful feature?

I prefer to have all messages delivered immediately.

Dave Crocker writes:
> 4. The IETF does not do intranet standards.

I have a mailing list for Internet mail implementors. To subscribe, send
an empty message to [email-masked].

Contributors can focus on the needs of their users, without artificially
separating Internet discussions from intranet discussions, SMTP
discussions from POP discussions, etc.

---Dan

Date: Mon, 2 Jul 2001 11:58:46 -0700 (PDT)
To: [email-masked]
From: Eric Allman <[email-masked]>
cc: Blake Ramsdell <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: IANA SMTP registry
Sender: [email-masked]

FWIW, even Allman thinks that these shouldn't be listed, at least without
a proper definition in some RFC.  As I recall, I did send in something of
this form at some point to some one (it was enough years ago that I can't
recall any details), but those clearly didn't get published.

eric

============= In Reply To: ===========================================
: From:  [email-masked]
: Subject:  RE: IANA SMTP registry
: Date:  Thu, 28 Jun 2001 20:14:53 -0700 (PDT)

:
:
: > So far, the only comment has been "the Sendmail extensions shouldn't be
: > listed", which makes it sound like I'm not completely nuts, so 
I'm going to
: > press on.
:
: Your assessment of the situation was IMO correct.
:
: > I think that most of the comments that I've presented here are valid.  Who
: > maintains the document that I mentioned, and how does it go about being
: > updated?
:
: This is already being taken care of. A number of changes, including but
: not limited to the ones you pointed out, are in progress now.
:
: > I can certainly create a draft, as I've recently spent a lot of time
: > researching this.
:
: There should be no need to do this.
:
:				Ned

Date: Sun, 01 Jul 2001 15:07:35 -0700 (PDT)
From: [email-masked]
Subject: Re: SMTP QoS
To: Dave Crocker <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> At 03:54 AM 6/29/2001, [email-masked] wrote:
> >Would you favor/suggest that this be re-cast as an option for message
> >posting?

> The current proposal is for SMTP.

And SMTP is the basis for the one submission (posting) protocol we have (RFC
276). "Recast" is therefore a bit of a stretch -- it is simply a matter of
profiling where the extension is (or is not) to be used.

> The way that a posting user gets to
> specify an SMTP option is a human factors issue that outside the scope of
> the IETF (unless we also decide that the information should be encoded in
> RFC 2822 headers.)

On the contrary, posting is a standardized function based on SMTP. And this is
true both in theory and in practice -- various posting APIs failed to pick up
NOTARY support in a timely fashion so many if not most MUAs elected to
transition to SMTP as means of submitting messages.

Now, none of this implies that priority cannot be carried in a header. It can
be, although I will argue below that it should not be. But not because only
headers are available as part of a posting mechanism. That's simply not the
case.

> > > 1.      As stated, the option leaves senders with an incentive to always
> > >         set high priority.  It costs them nothing to do this.

> > Even if you assume this is true (past experience with priority facilities
> > indicates it is not),

> The past experience you have been citing pertains to LOWER priority.  That
> is quite different from one which includes HIGHER priority.

Only one instance of past experience pertains to LOWER priority. Other
instances pertain to higher priority, and there has been no indication of
substantial abuse.

> One more time:  For a service that imposes no costs on the requester, the
> incentive is to always ask for higher priority.  As I noted, we have well
> seen that the Internet is now under the strong influence of selfish
> actors. They do not participate as good neighbors.  That is the reason we
> needed a major generational upgrade to router queuing and it is the reason
> that the proposed mechanism, here, suffers scaling limitations for the open
> Internet.

One more time: Past experience directly contradicts this (IMO overly
simplistic) assessment.

I've tried to avoid making behavioral predictions since we're collectively
pretty bad at it, but I cannot resist the temptation any longer. So here's an
alternative analysis of spammer behavior that predicts an entirely different
outcome.

The goal of spammers is to get as many of their messages through to end users
as possible. Period. We're all well aware that other concerns like use of
resources that belong to other people are ignored by these people.

But consider what this means for a moment. It means that quality of service
facilities like priority aren't all that interesting to a spammer. Indeed, the
goal of spammers these days is to have their mail look as normal as possible --
anything that stands out, like a flood of mail from a single source all marked
priority urgent, is a sign of spam and is likely to be used as a means of
filtering mail.

It used to be that spam mail stood out like a sore thumb. Bogus return
addresses, missing required header fields, and other telltales were the norm.
But as filter sophistication has increased so have the techniques spammers use.
Yes, there's still a residual amount of spam that's sent by clueless spammers
using older tools and which carries such telltales, but ask anyone who build
spam filters and you'll find out that filtering is getting harder and harder
over time.

In fact there's nothing I would like better than for all the spammers to start
using the highest possible priority to label their messages.  Priority
labelling used as a honeypot, in other words. But unlike you, I doubt they are
that stupid. (Actually, the individual actors probably are that stupid. But the
people who write the tools they use are not. They'll see priority for what it
is -- a potential telltale -- and avoid it.)

However, this discussion does lead me to conclude that priority is best done as
an SMTP extension. Why? Because there are still a lot of open relays out there,
and an open relay will pass through any header priority field we add unchanged.
In contrast, an open relay is usually some system running an old mail system
without relay blocking and that old system isn't going to support any new
priority extension. And if it gets upgraded to support it support for relay
blocking will inevitably come along for the ride. So if we deploy a priority
extension we can be reasonably sure that use of it is unlikely to come from an
open relay -- it will either be a legitimate system sending legitimate mail or
a spammer sending spam directly. And this makes all sorts of approaches
possible: Statistical analysis, quotas on high priority messages, and so on.

> > > 2.  References to usage of SMTP Auth with this option are confusing,
> > >     since it is used for posting, not relaying.  I'd appreciate
> > >     clarification to this point.

> > Read the spec. SMTP AUTH not only provides facility for posting, it also
> > provides facilities for relaying authentication credentials.

> As with most security topics, the difference between specification and
> practise are significant.  Do you really expect that relaying across the
> open Internet will require use of SMTP Auth?  In which century?

Nobody said anything about requiring it for relaying across the open Internet.
Using it as means of facilitating the use of extensions like priority
is another matter.

> What will be the incentives that will cause people to adopt such a
> considerable mechanism?

> (There is an argument that opt-in volume mailers, and ISPs receiving their
> bulk postings, might like to use a certified channel.  This would permit
> distinguish the Good Bulk mail from the Bad Bulk Mail.  That argument has
> so far proved unpersuasive to ISPs.)

I'm going to turn one of your own arguments back on you here. You like making
analogies to lower layers. Well, one of the things that happens all the time is
private bilateral agreements between service providers to provide improved QoS
or enhanced types of service between their respective customer bases. (Don't
bother to ask for details of such things because I don't know any. I only know
there are lots of such agreements in place, and I also know that they are
routinely coupled to extremely draconian nondisclosure agreements. Attempts to
make realistic assessments of the number and effect of such agreements have
been made, and they were met with "what have you been smoking" responses from
the people who know about them.) At present there's no reason to do anything
similar based on SMTP AUTH because there aren't any facilities tied to its use.
But if there were, who's to say it would not happen?

> > I have no clear idea what "increase predictability" means, but I'm pretty
> > sure that nobody views priority as a means to achieve that end.

> If my request for special handling (priority) carries no expectation of
> what actual handling will take place, then the option is entirely
> useless.  If it does correlate with actual handling, then I had better have
> better knowledge about the delivery behavior of my message than I had
> without the option.  That constitutes increased predictability.  That is
> what quality of service work is about.

> In other words, Dan Chaney's interpretation is accurate.

And actual experience disproves this line of reasoning completely. People will
use such facilities even without even a scintilla of evidence of their
efficacy. This is why I find the arguments made in the FAX WG relating to the
unreliable nature of MDNs to be unpersuasive -- I know otherwise from direct
experience.

> > > 4.      The IETF does not do intranet standards.

> > Actually, the IETF does intranet standards all the time. This is especially
> > true if you equate administrative domains with intranets. By this rule POP3,
> > IMAP4 and SMTP submit are all intranet protocols that don't scale to the
> > entire Internet.

> All of those protocols work quite well over the open Internet just
> fine.  There is nothing about them that requires constraints on the
> operational network.

> (I suppose one might claim that a login identification technique is the
> contradiction but then we would have to claim that all web mechanisms that
> require identification are intranet-limited.)

No, what we conclude is that the notion of the IETF not doing intranet
standards is complete hooey now and always has been. The most that can be said
is that we try to build protocols that are capable of being used on the big-I
Internet and are not restricted to intranets. And we don't always succeed even
at that. (The best example of this is the service location protocol, which
required a broadcast service to operate. And if you want some real fun you
should sample what's happening now in the storage-over-IP camp.)

And priority is definitely an example of a protocol that can be used on the
big-I Internet.

> My point about being limited to an intranet is not about constraints on an
> end-point.  It is about being limited to an operational infrastructure that
> has significant dependence on a single, coherent administrative
> control.  POP, IMAP and Submit have not such dependence.

Dave, you have seriously taken leave of your senses if you believe this to be
the case. Excluding the insignificant case of anonymous logins, all of these
protocls require authentication, and authentication requires administative
coordination. And I don't think a gloal authentication infrastructure deployed
when I wasn't looking.

> The proposed
> priority mechanism does, unless and until the rest of the system
> specification is provided, and controls are provided to distinguish
> authorized high priority users from unauthorized.

Even if I grant this point, the degree of authorization is no different than
that needed for using the protocols you listed. And not only are MTA authors 
used to tying the ability to do various things to authentication state, we're
getting good at it.

				Ned

Date: Sun, 01 Jul 2001 10:07:57 -0700
To: [email-masked]
From: Dave Crocker <[email-masked]>
Subject: Re: SMTP QoS 
Sender: [email-masked]

At 03:54 AM 6/29/2001, [email-masked] wrote:
>Would you favor/suggest that this be re-cast as an option for message
>posting?

The current proposal is for SMTP.  The way that a posting user gets to 
specify an SMTP option is a human factors issue that outside the scope of 
the IETF (unless we also decide that the information should be encoded in 
RFC 2822 headers.)

At 04:16 AM 6/29/2001, [email-masked] wrote:
>>1.      As stated, the option leaves senders with an incentive to always
>>set high priority.  It costs them nothing to do this.
>
>Even if you assume this is true (past experience with priority facilities
>indicates it is not),

The past experience you have been citing pertains to LOWER priority.  That 
is quite different from one which includes HIGHER priority.

One more time:  For a service that imposes no costs on the requester, the 
incentive is to always ask for higher priority.  As I noted, we have well 
seen that the Internet is now under the strong influence of selfish 
actors.  They do not participate as good neighbors.  That is the reason we 
needed a major generational upgrade to router queuing and it is the reason 
that the proposed mechanism, here, suffers scaling limitations for the open 
Internet.

>this ignores the need to lower as well as raise priority.

If the proposal were only for requesting lower priority, I'd say fine, 
though I would expect only marginal benefit.

>>2.      References to usage of SMTP Auth with this option are confusing,
>>since it is used for posting, not relaying.  I'd appreciate clarification
>>to this point.
>
>Read the spec. SMTP AUTH not only provides facility for posting, it also
>provides facilities for relaying authentication credentials.

As with most security topics, the difference between specification and 
practise are significant.  Do you really expect that relaying across the 
open Internet will require use of SMTP Auth?  In which century?

What will be the incentives that will cause people to adopt such a 
considerable mechanism?

(There is an argument that opt-in volume mailers, and ISPs receiving their 
bulk postings, might like to use a certified channel.  This would permit 
distinguish the Good Bulk mail from the Bad Bulk Mail.  That argument has 
so far proved unpersuasive to ISPs.)

>>   Users will have no
>>basis for knowing what to expect from the relay path.  The purpose of QoS
>>mechanisms is to increase predictability.  This will not achieve that.
>
>I have no clear idea what "increase predictability" means, but I'm pretty
>sure that nobody views priority as a means to achieve that end.

If my request for special handling (priority) carries no expectation of 
what actual handling will take place, then the option is entirely 
useless.  If it does correlate with actual handling, then I had better have 
better knowledge about the delivery behavior of my message than I had 
without the option.  That constitutes increased predictability.  That is 
what quality of service work is about.

In other words, Dan Chaney's interpretation is accurate.

>>4.      The IETF does not do intranet standards.
>
>Actually, the IETF does intranet standards all the time. This is especially
>true if you equate administrative domains with intranets. By this rule POP3,
>IMAP4 and SMTP submit are all intranet protocols that don't scale to the 
>entire
>Internet.

All of those protocols work quite well over the open Internet just 
fine.  There is nothing about them that requires constraints on the 
operational network.

(I suppose one might claim that a login identification technique is the 
contradiction but then we would have to claim that all web mechanisms that 
require identification are intranet-limited.)

My point about being limited to an intranet is not about constraints on an 
end-point.  It is about being limited to an operational infrastructure that 
has significant dependence on a single, coherent administrative 
control.  POP, IMAP and Submit have not such dependence.  The proposed 
priority mechanism does, unless and until the rest of the system 
specification is provided, and controls are provided to distinguish 
authorized high priority users from unauthorized.

At 04:50 AM 6/29/2001, Julian Onions wrote:
>It will only be any use if the MTA acts on it. I can already set these
>sorts of things using UA's. Outlook Express allows me to flag messages
>I post as High Priority. It does this by inserting its own header
>field X-MSMail-Priority: High

This thread has gotten confused a few times between communicating priority 
between the originator and recipient, versus between originator and the 
transport infrastructure.

So let me suggest that any citations of existing mechanisms make explicit 
which is which.

>As I keep reiterating, whilst an MTA is unlikely to take notice of a
>request to do priority=high processing from joe-average-mta, it may
>well take note of priority=low processing. There seems little to lose
>in doing this.

agreed.  completely.

> > 3.      The proposal presumes that a simple rank-ordering approach,
>
>It provides a mechanism for one MTA to tell another what it thinks the
>priority of this message is in comparison to others it has.

I am trying to imagine a relay that does something useful with such 
entirely source-relative prioritization information.  The algorithm escapes 
me.  Or overwhelms me.

>I doubt there is any way I could convince your MTA to give my messages
>high priority processing without some agreement before hand.

correct.

>I see two ways of passing priority information. As a hint (as in this
>draft) which given communities may respect; or passing it, together with
>sufficient other information, that an MTA can independantly validate to
>its satisfaction that this message was and is suitable to be processed
>at the given priority.  The second strikes me as so heavy weight no
>one will implement it much, even if it can be specified in a
>reasonable way.
>
>The military people would be happy with the first, they would just
>have a policy that you MUST take the hint. Some internet MTAs will be
>happy to demote low priority requests too. In certain circumstances
>they may honor high priority too (consider two large companies that
>exchange mail and want to allow priority processing to occur between
>their management).

I think you have summarized things quite well in these two paragraphs.

My only point of disagreement is to note that the global business community 
clearly does want and need differential handling and that individual 
express delivery companies, as well as the formal, international 
aggregation of postal services, have a long and successful history of 
providing it.

Hence there is some basis for believing that Internet-wide mechanisms for 
differential handling are entirely appropriate.  The challenge is designing 
the mechanism to work for the global system.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464