Subject: [Fwd: I-D Action:draft-crocker-email-arch-11.txt]
From: Dave CROCKER <[email-masked]>
To: SMTP Interest Group <[email-masked]>
Date: Fri, 31 Oct 2008 08:30:26 -0700
List-Id: <ietf-smtp.imc.org>

html and pdf versions are available at:

    <http://bbiw.net/recent.html#emailarch>

They have true graphics, in place of the ascii-art.

This latest version It responds to additional, detailed review. The draft is 
incremental, with improved writing and figures, but no significant technical 
changes.

d/

-------- Original Message --------

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Internet Mail Architecture
	Author(s)       : D. Crocker
	Filename        : draft-crocker-email-arch-11.txt
	Pages           : 49
	Date            : 2008-10-31

Over its thirty-five year history, Internet Mail has changed
significantly in scale and complexity, as it has become a global
infrastructure service.  These changes have been evolutionary, rather
than revolutionary, reflecting a strong desire to preserve both its
installed base and its usefulness.  To collaborate productively on
this large and complex system, all participants must work from a
common view of it and use a common language to describe its
components and the interactions among them.  But the many differences
in perspective currently make it difficult to know exactly what
another participant means.  To serve as the necessary common frame of
reference, this document describes the enhanced Internet Mail
architecture, reflecting the current service.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-crocker-email-arch-11.txt

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Tue, 28 Oct 2008 13:37:56 +0000
From: Tony Finch <[email-masked]>
To: Chris Newman <[email-masked]>
cc: Paul Hoffman <[email-masked]>, [email-masked]
Subject: Re: RFC 3207 STARTTLS
Sender: [email-masked]

On Tue, 28 Oct 2008, Tony Finch wrote:
>
> The best-developed model that inter-domain SMTP might be based on is
> server-to-server XMPP.

I should have said something about client authentication. One significant
difference between SMTP and XMPP is that XMPP has a much simpler topology:
an XMPP entity (server or client) can't emit traffic "from" another
entity, in the way that occurs with email forwarding and relaying. It is
reasonable to restrict "from" addresses used by message submission clients
(RFC 4409 seciton 6.2) but not other uses of SMTP except by special
arrangement.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
NORTH UTSIRE: NORTHWEST BACKING SOUTH THEN NORTHEAST 5 TO 7, INCREASING GALE 8
OR SEVERE GALE 9 FOR A TIME. ROUGH OR VERY ROUGH, OCCASIONALLY HIGH. RAIN OR
SQUALLY WINTRY SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.

Date: Tue, 28 Oct 2008 11:52:21 +0000
From: Tony Finch <[email-masked]>
To: Chris Newman <[email-masked]>
cc: Paul Hoffman <[email-masked]>, [email-masked]
Subject: Re: RFC 3207 STARTTLS
Sender: [email-masked]

On Mon, 27 Oct 2008, Chris Newman wrote:
>
> An RFC 3207 STARTTLS revision needs text related to server identity
> check. I would prefer this text be as similar as possible to server
> identity check text in other IETF application protocols.

The best-developed model that inter-domain SMTP might be based on is
server-to-server XMPP. (However be warned there are significant revisions
in RFC 3920bis.) SRV records in XMPP have the same function as MX records
in SMTP. XMPP avoids SMTP+TLS's DNS MX vulnerability by authenticating the
server JID (SRV owner name) not the host name (SRV target name).

In order to avoid requiring an IP address per domain, there must be a way
for the client to indicate to the server which domain it is trying to
send mail to, before negotiating TLS. RFC 3207 doesn't allow this.

If you follow this model there are more subtle implications. At the
moment, a server that is an MX for multiple domains can accept a message
with multiple recipients at any of those domains. Simple server-to-server
TLS would not allow this; it would instead have to be complicated with
support for multiple domains in the server certificate. However, if the
XMPP experience is repeated, it'll be impossible to buy these special
certificates from the CAs because they're focussed on web servers to the
exclusion of anything else.

There are also problems with intra-site relaying. This should probably
follow the message submission model, in which the client's configuration
directs mail by host name and authenticates the server by host name.
However in practice many MTAs resolve the next hop server via MX records
by default (e.g. unless suppressed by wrapping the host name in square
brackets) even when this is unrelated to the mail domain of any recipient
address.

> For Submit, I'd expect the TLS server identity check to be
> mandatory-to-implement and very close to that of IMAP and POP (or to
> have a justification why it shouldn't follow IETF practices for this).

Agreed. (This is what is implemented.)

> For SMTP transfer, the situation is different and probably needs technical
> discussion to reach consensus on the path forward.  It would not surprise me
> if we needed one or more additional EHLO keywords/arguments to resolve
> legitimate concerns.

Yes.

> I will observe that for SMTP without SMTP AUTH, there is value in
> opportunistic STARTTLS encryption without authentication as long as the
> risks are understood.

It can help against on-path passive (snooping) attacks. It cannot help
against active attacks, and active attacks are much easier for an on-path
attacker.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
VIKING: NORTHWESTERLY BECOMING CYCLONIC THEN NORTHEASTERLY 5 TO 7, INCREASING
GALE 8 OR SEVERE GALE 9 FOR A TIME. VERY ROUGH OR HIGH. RAIN OR SQUALLY WINTRY
SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.

Date: Mon, 27 Oct 2008 19:50:53 -0700
From: Chris Newman <[email-masked]>
Subject: Re: RFC 3207 STARTTLS
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

Putting on my area director hat:

An RFC 3207 STARTTLS revision needs text related to server identity check. 
I would prefer this text be as similar as possible to server identity check 
text in other IETF application protocols.

For Submit, I'd expect the TLS server identity check to be 
mandatory-to-implement and very close to that of IMAP and POP (or to have a 
justification why it shouldn't follow IETF practices for this).

I've attempted to get volunteers to write a generalized TLS server identity 
check for use by applications so it can be included by reference.  The 
initial draft has unfortunately expired: 
<http://tools.ietf.org/html/draft-hodges-server-ident-check-00>
and needs work.  This issue has come up in _many_ WGs and protocols.

For SMTP transfer, the situation is different and probably needs technical 
discussion to reach consensus on the path forward.  It would not surprise 
me if we needed one or more additional EHLO keywords/arguments to resolve 
legitimate concerns.  I will observe that for SMTP without SMTP AUTH, there 
is value in opportunistic STARTTLS encryption without authentication as 
long as the risks are understood.

		- Chris

Date: Mon, 27 Oct 2008 22:39:16 -0400
From: John C Klensin <[email-masked]>
To: Tony Finch <[email-masked]>
cc: [email-masked]
Subject: Re: RFC 3207 STARTTLS
Sender: [email-masked]

--On Monday, October 27, 2008 3:03 PM +0000 Tony Finch 
<[email-masked]> wrote:

>...
> The same problem applies to the MX mail domain -> hostname
> mapping, where TLS is insecure because authenticates the
> target not the source.
>...

Absolutely.  My comment about DNSSEC referred only to increasing 
the odds that the MX target list specified by the administrator 
of the mail domain was the same as the one that was received by 
the remove SMTP server.  Obviously, I hope, if that information 
is bogus or the environment was compromised in some other way 
--some way that could be detected by properly structured 
CA-based certs-- DNSSEC would not help and would, indeed, not 
add tremendous value.   But first one has to find a server 
before one can validate it and, for that, we are pretty 
dependent on the DNS.

    john

Date: Mon, 27 Oct 2008 19:34:33 +0100
From: Alessandro Vesely <[email-masked]>
To: [email-masked]
Subject: Re: RFC 3207 STARTTLS
Sender: [email-masked]

Tony Finch wrote:
> The point of the certificate is to authenticate the name that the user
> typed in. If you don't authenticate the right thing then you will fail to
> detect attacks, for example, if an attack on the DNS produces a bogus name
> -> IP addres translation and the attacker has a valid certificate for
> that IP address.

I don't know why some certificate bear the IP _instead_ of the FQDN; 
could do both.

> The same problem applies to the MX mail domain -> hostname mapping, where
> TLS is insecure because authenticates the target not the source.

Do you mean the server requiring the client to STARTTLS?

If not, I think most server software can easily be modified so as to 
accept client certificates, if it doesn't accept them already. They 
are usually not _required_ to avoid handshake failures (e.g. the MDA 
software in turn asking the users which certificate they want to upload.)

Alternatively, after some sort of forwarding agreement has been 
established between two servers, in a TLS session it is possible to 
use rfc 4954 to say something like
    MAIL FROM:<original-envelope@example> AUTH=distinguished-relay

The distinguished name of the relay should help the spam filter in 
either case. After authentication, it makes little difference if it 
comes from the certificate or from a command parameter.

Date: Mon, 27 Oct 2008 19:37:07 +0200
From: Ivar Lumi <[email-masked]>
To: Hector Santos <[email-masked]>
CC: [email-masked]
Subject: Re: SMTP 500 Line too long
Sender: [email-masked]

Hi,

After a deep thought, the only way is to junk bytes and monitor for 
CRLF, once it's received, "500 Line too long" returned.
Otherwise it brakes SMTP protocol as some guys noted me.

Hector Santos wrote:
> Ivar Lumi wrote:
>>
>> Hi,
>>
>> After fast look on RFC 5321, i don't see exact place what describes 
>> how to handle "500 Line too long".
>>
>> Must server junk bytes(if max line exceeded) and try to read CRLF, 
>> after that returns "500 Line too long".
>> or
>> Must server send "500 Line too long" straight away.
>>
>> Thanks.
>
> Ivar, take a look at the actual transaction. I seem to recall this 
> being an erroneous response (by the some server, MS Exchange if I 
> recall?) related to NOOP.
>
> I don't recall the details, but Google "NOOP Line too Long"
>
> Here are few references:
>
> http://www.imc.org/ietf-smtp/mail-archive/msg04155.html
> http://www.imc.org/ietf-smtp/mail-archive/msg04156.html
>
>

Date: Mon, 27 Oct 2008 10:24:11 -0700
From: "Carl S. Gutekunst" <[email-masked]>
To: Tony Finch <[email-masked]>
CC: John C Klensin <[email-masked]>, Alexey Melnikov <[email-masked]>, Matti Aarnio <[email-masked]>, Philip Guenther <[email-masked]>, Ivar Lumi <[email-masked]>, [email-masked]
Subject: Re: RFC 3207 STARTTLS
Sender: [email-masked]

Tony Finch wrote:
> On Mon, 27 Oct 2008, Carl S. Gutekunst wrote:
>   
>> FWIW, I've actually measured that. Each of Postini's outbound SMTP
>> relays connects to roughly 30,000 domains per day that claim TLS
>> support. Of those, about 50% use self-signed certs. (Certain "demo"
>> certs come up over and over.) Another 35% are CA signed, but contain
>> errors, like incomplete chains or expired certs. Of the 15% where the
>> certificate chain is valid, half don't match the MX name. So -- only 7%
>> to 8% of all MX domains that implement TLS do so correctly. Note that
>> Postini's outbound service is heavily biased towards B-to-B.
>>     
>
> A useful survey, thanks. Did you check certificates against both the
> hostname and the mail domain?

Hostname only. My casual inspection of the failed hostnames suggested 
that checking the mail domain would not have helped. I do support 
wildcards in the cert, e.g., *.psmtp.com. I don't currently support IP 
addresses in the cert, although I didn't see any sites that failed 
because of that.

Note that there could have been lots of certs with correct hostnames 
that I wouldn't have checked. I don't check the hostname unless the cert 
chain is valid.

<csg>

Date: Mon, 27 Oct 2008 13:20:10 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Ivar Lumi <[email-masked]>
CC:  [email-masked]
Subject: Re: SMTP 500 Line too long
Sender: [email-masked]

Ivar Lumi wrote:
> 
> Hi,
> 
> After fast look on RFC 5321, i don't see exact place what describes how 
> to handle "500 Line too long".
> 
> Must server junk bytes(if max line exceeded) and try to read CRLF, after 
> that returns "500 Line too long".
> or
> Must server send "500 Line too long" straight away.
> 
> Thanks.

Ivar, take a look at the actual transaction. I seem to recall this 
being an erroneous response (by the some server, MS Exchange if I 
recall?) related to NOOP.

I don't recall the details, but Google "NOOP Line too Long"

Here are few references:

http://www.imc.org/ietf-smtp/mail-archive/msg04155.html
http://www.imc.org/ietf-smtp/mail-archive/msg04156.html

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Mon, 27 Oct 2008 16:43:56 +0000
From: Tony Finch <[email-masked]>
To: "Carl S. Gutekunst" <[email-masked]>
cc: John C Klensin <[email-masked]>, Alexey Melnikov <[email-masked]>, Matti Aarnio <[email-masked]>, Philip Guenther <[email-masked]>, Ivar Lumi <[email-masked]>, [email-masked]
Subject: Re: RFC 3207 STARTTLS
Sender: [email-masked]

On Mon, 27 Oct 2008, Carl S. Gutekunst wrote:
>
> FWIW, I've actually measured that. Each of Postini's outbound SMTP
> relays connects to roughly 30,000 domains per day that claim TLS
> support. Of those, about 50% use self-signed certs. (Certain "demo"
> certs come up over and over.) Another 35% are CA signed, but contain
> errors, like incomplete chains or expired certs. Of the 15% where the
> certificate chain is valid, half don't match the MX name. So -- only 7%
> to 8% of all MX domains that implement TLS do so correctly. Note that
> Postini's outbound service is heavily biased towards B-to-B.

A useful survey, thanks. Did you check certificates against both the
hostname and the mail domain?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
FITZROY: NORTH OR NORTHWEST 5 TO 7, PERHAPS GALE 8 LATER. ROUGH OR VERY ROUGH.
RAIN OR SQUALLY SHOWERS. MODERATE OR GOOD.

Date: Mon, 27 Oct 2008 09:36:47 -0700
From: "Carl S. Gutekunst" <[email-masked]>
To: Tony Finch <[email-masked]>
CC: John C Klensin <[email-masked]>, Alexey Melnikov <[email-masked]>, Matti Aarnio <[email-masked]>, Philip Guenther <[email-masked]>, Ivar Lumi <[email-masked]>, [email-masked]
Subject: Re: RFC 3207 STARTTLS
Sender: [email-masked]

Tony Finch wrote:
> There is no firm specification of how an SMTP implementation should use
> the results of TLS authentication, so in practice MTAs just ignore the
> results. (MUAs are better.) As a consequence many TLS certificates offered
> by MX hosts match neither the MX's mail domain nor its host name.

FWIW, I've actually measured that. Each of Postini's outbound SMTP 
relays connects to roughly 30,000 domains per day that claim TLS 
support. Of those, about 50% use self-signed certs. (Certain "demo" 
certs come up over and over.) Another 35% are CA signed, but contain 
errors, like incomplete chains or expired certs. Of the 15% where the 
certificate chain is valid, half don't match the MX name. So -- only 7% 
to 8% of all MX domains that implement TLS do so correctly. Note that 
Postini's outbound service is heavily biased towards B-to-B.

You'd be shocked by some of the sites that get it wrong. (Or not. :-)

As an experiment, I sent E-mail to the postmasters of 20-odd sites, 
complaining about their TLS certificates. One Tier-3 ISP responded very 
cordially and fixed the cert chain. One large E-tailer bounced me from 
department to department for *months*; apparently someone was being 
goaled on responding to customer complaints, even if they couldn't fix 
them. The rest gave no answer or an auto response.

I haven't run that report in about six months; time to do that again and 
see if the situation has improved any. Somehow I doubt it.

<csg>

Date: Mon, 27 Oct 2008 15:03:32 +0000
From: Tony Finch <[email-masked]>
To: Alessandro Vesely <[email-masked]>
cc: [email-masked]
Subject: Re: RFC 3207 STARTTLS
Sender: [email-masked]

On Sat, 25 Oct 2008, Alessandro Vesely wrote:
>
> Perhaps some black magic stems from associating certificate validation with
> authority acceptance.

In what way? If you don't accept a certificate's authority then you can't
validate it. I don't see what's complicated about it, other than the
choice of which authorities to trust (though that problem is easily
ignored).

> It is also a non-TLS specific problem, but it may be helpful to clarify
> the relationship between DNS hierarchical delegations and CA chains.

There is none.

> To wit, if a CA certificate were assigned along with each domain
> delegation then we would need no black magic.

RFC 4398.

> BTW, why don't we write the IP number on our server certificates?

The point of the certificate is to authenticate the name that the user
typed in. If you don't authenticate the right thing then you will fail to
detect attacks, for example, if an attack on the DNS produces a bogus name
-> IP addres translation and the attacker has a valid certificate for
that IP address.

The same problem applies to the MX mail domain -> hostname mapping, where
TLS is insecure because authenticates the target not the source.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
NORTH UTSIRE SOUTH UTSIRE: WESTERLY VEERING NORTHWESTERLY 5 TO 7. ROUGH OR
VERY ROUGH. SQUALLY WINTRY SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.

Date: Mon, 27 Oct 2008 14:51:27 +0000
From: Tony Finch <[email-masked]>
To: SM <[email-masked]>
cc: [email-masked]
Subject: Re: RFC 3207 STARTTLS
Sender: [email-masked]

On Fri, 24 Oct 2008, SM wrote:
>
> There is a need for TLS in some inter-domain relaying.  Some mail providers
> use it, by agreement, to provide a secure transport.  The environment is not
> your usual shared hosting.  The setup is more of a S/MIME "replacement" as TLS
> is viewed as cheaper and easier to deploy as it doesn't require as many
> changes for the end-user.

And the number of setups that actually use TLS in this situation in a
secure manner is vanishingly small. Just installing a certificate and
turning on TLS is NOT enough.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
BISCAY: NORTH OR NORTHWEST 5 OR 6. MODERATE OR ROUGH. RAIN OR SQUALLY SHOWERS.
MODERATE OR GOOD.

Date: Sun, 26 Oct 2008 12:01:21 -0700 (PDT)
From: [email-masked]
Subject: Re: SMTP 500 Line too long
To: Ivar Lumi <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> After fast look on RFC 5321, i don't see exact place what describes how
> to handle "500 Line too long".

AFAIK there isn't one. Unlike some other standards processes, we don't spend
much time trying to nail down how illegal inputs have to be handled in most
cases. (And IMO this is a very good thing - having been down this road in other
standards processes I've observed it takes a fantastic amount of time for
almost no benefit.)

In fact I would argue that we've done ourselves no good in the few cases when
we've gone down this path ourselves. The specified handling of bare CR and LF
is a case in point - I'm on record on that one as believing that what we've
done has actually harmed interoperability.

> Must server junk bytes(if max line exceeded) and try to read CRLF, after
> that returns "500 Line too long".

> or

> Must server send "500 Line too long" straight away.

The problem is the "right" answer depends on the client's intent, which of
course the server doesn't know. If the nefarious intent of the client is to
overrun the server with garbage, the right answer is to send the error once the
condition is detected. Waiting for a CRLF that's hever going to arrive isn't
useful.

But this fails in the case of a client that is confused in some way and for
whatever reason is sending a legitimate mail that happens to be too long. In
this case sending a response before getting the CRLF will probably
desynchronize the protocol.

There are also many other options. One is to have two threshholds, one where
the line has gotten too long but things still look legit, the other for
when the server believes it is just getting garbage from the client.

Another set of implementation choices revolves around whether or not the server
should disconnect in such situations. If the server decides that the client is
simply spewing garbage without end, disconnection, while frowned upon by the
specifications, is probably the right thing to do. But the devil is in the
detail of determining that this is really what's going on.

There's also a big difference between SMTP commands that are too long and
message lines that are too long, and arguably a distinction might even be drawn
between DATA and BDAT transfers. An error needs to be returned in the case of
an overly long command. The situation with message data is more ...
interesting. While RFC 5321 (incorrectly IMO) talks about not having limits on
things whenever possible, RFC 5322 is quite clear that line lengths MUST be
limited. So rejecting messages with overly long lines is a valid choice. But
it's hardly optimal, and in this case truncation, wrapping, or even forced MIME
encoding are all viable alternatives.

In any case, it strikes me that you're looking for a sort of implementation
guidance in the RFCs that just isn't there, and IMO at least its absence is 
almost always a feature, not a bug.

				Ned

Date: Sun, 26 Oct 2008 16:44:53 +0200
From: Ivar Lumi <[email-masked]>
To: [email-masked]
Subject: SMTP 500 Line too long
Sender: [email-masked]

Hi,

After fast look on RFC 5321, i don't see exact place what describes how 
to handle "500 Line too long".

Must server junk bytes(if max line exceeded) and try to read CRLF, after 
that returns "500 Line too long".
or
Must server send "500 Line too long" straight away.

Thanks.

Date: Sun, 26 Oct 2008 12:56:58 +0100
From: Alessandro Vesely <[email-masked]>
To: [email-masked]
Subject: Re: RFC 3207 STARTTLS
Sender: [email-masked]

Willie Gillespie wrote:
> Alessandro Vesely wrote:
>> BTW, why don't we write the IP number on our server certificates?
> 
> Because sometimes domains resolve to more than one IP address?

Not if one can issue multiple certificates.

I think people reckon that it doesn't add much so much to security to 
be worth the hassle. Hostmasters may prefer not tying certificates to 
IPs, so they are free to change them; thereby implying that 
certification is not part of ordinary DNS maintenance.

Date: Sat, 25 Oct 2008 13:38:36 -0600
From: Willie Gillespie <[email-masked]>
Organization: Engineering System Solutions
To: Alessandro Vesely <[email-masked]>
CC: [email-masked]
Subject: Re: RFC 3207 STARTTLS
Sender: [email-masked]

Alessandro Vesely wrote:
> BTW, why don't we write the IP number on our server certificates?

Because sometimes domains resolve to more than one IP address?

Date: Sat, 25 Oct 2008 10:45:31 +0200
From: Alessandro Vesely <[email-masked]>
To: [email-masked]
Subject: Re: RFC 3207 STARTTLS
Sender: [email-masked]

John C Klensin wrote:
> --On Friday, 24 October, 2008 17:22 +0100 Tony Finch wrote:
>> However I don't know how to address its weaknesses for
>> inter-domain relaying via MX records.
> 
> Of course, this is another area in which a functional DNSSEC,
> with signature verification by the SMTP clients, would make some
> of us sleep a lot more soundly.  But that is not specifically a
> TLS problem.

Perhaps some black magic stems from associating certificate validation 
with authority acceptance. It is also a non-TLS specific problem, but 
it may be helpful to clarify the relationship between DNS hierarchical 
delegations and CA chains. To wit, if a CA certificate were assigned 
along with each domain delegation then we would need no black magic.

BTW, why don't we write the IP number on our server certificates?

Date: Fri, 24 Oct 2008 16:07:59 -0400
From: John C Klensin <[email-masked]>
To: Tony Finch <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, Matti Aarnio <[email-masked]>, Philip Guenther <[email-masked]>, Ivar Lumi <[email-masked]>, [email-masked]
Subject: Re: RFC 3207 STARTTLS
Sender: [email-masked]

--On Friday, 24 October, 2008 17:22 +0100 Tony Finch
<[email-masked]> wrote:

>...
> However I don't know how to address its weaknesses for
> inter-domain relaying via MX records. At the same time
> relaying is often much less vulnerable to active attack than
> message submission, so there seems to me to be less need for
> TLS in this situation. (I'd probably have a less sanguine
> point of view if I had lots of mail going through a dodgy
> shared hosting environment...)

Of course, this is another area in which a functional DNSSEC,
with signature verification by the SMTP clients, would make some
of us sleep a lot more soundly.  But that is not specifically a
TLS problem.

    john

Date: Fri, 24 Oct 2008 11:39:13 -0700
To: [email-masked]
From: SM <[email-masked]>
Subject: Re: RFC 3207 STARTTLS
Sender: [email-masked]

At 09:22 24-10-2008, Tony Finch wrote:
>However I don't know how to address its weaknesses for inter-domain
>relaying via MX records. At the same time relaying is often much less
>vulnerable to active attack than message submission, so there seems to me
>to be less need for TLS in this situation. (I'd probably have a less
>sanguine point of view if I had lots of mail going through a dodgy shared
>hosting environment...)

There is a need for TLS in some inter-domain relaying.  Some mail 
providers use it, by agreement, to provide a secure transport.  The 
environment is not your usual shared hosting.  The setup is more of a 
S/MIME "replacement" as TLS is viewed as cheaper and easier to deploy 
as it doesn't require as many changes for the end-user.

Regards,
-sm 

Date: Fri, 24 Oct 2008 17:22:14 +0100
From: Tony Finch <[email-masked]>
To: John C Klensin <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, Matti Aarnio <[email-masked]>, Philip Guenther <[email-masked]>, Ivar Lumi <[email-masked]>, [email-masked]
Subject: Re: RFC 3207 STARTTLS
Sender: [email-masked]

On Fri, 24 Oct 2008, John C Klensin wrote:
>
> (2) Fix it, on the theory that the idea of using SMTP over TLS
> is reasonable but that the specification needs tightening up.
>
> The second is completely consistent with generating a new
> document and trying to advance it to Draft Standard.  If that
> were to fail because of the number and nature of changes that
> would be required, we would still have a document to recycle at
> Proposed that, presumably, would be better than what we have
> now, especially given the weaknesses you identify/claim.
>
> Are you suggesting some other course of action?

No, I agree this is the way to go, and I agree with your postscript too :-)

I thought I ought to do a quick brain dump of the major issues since the
topic came up and it's one of my hobby horses.

RFC 3207 works well for message submission, and the improvements I think
it needs are minor. The same is true for explicitly configured relaying.

However I don't know how to address its weaknesses for inter-domain
relaying via MX records. At the same time relaying is often much less
vulnerable to active attack than message submission, so there seems to me
to be less need for TLS in this situation. (I'd probably have a less
sanguine point of view if I had lots of mail going through a dodgy shared
hosting environment...)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT HUMBER: WESTERLY BACKING SOUTHWESTERLY 5 TO 7, PERHAPS GALE 8
LATER. MODERATE OR ROUGH, OCCASIONALLY VERY ROUGH. RAIN OR SHOWERS. MODERATE
OR GOOD.

Date: Fri, 24 Oct 2008 11:55:15 -0400
From: John C Klensin <[email-masked]>
To: Tony Finch <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, Matti Aarnio <[email-masked]>, Philip Guenther <[email-masked]>, Ivar Lumi <[email-masked]>, [email-masked]
Subject: Re: RFC 3207 STARTTLS
Sender: [email-masked]

--On Friday, 24 October, 2008 16:17 +0100 Tony Finch
<[email-masked]> wrote:

>...
> RFC 3207 is extremely weak from the security point of view.
> 
> For example, it says "The additional option of using TLS when
> possible SHOULD also be provided." This option makes most MUAs
> vulnerable to man-in-the-middle attacks in common
> configurations. The RFC suggests a mechanism to mitigate this
> weakness - "An implementation MAY provide the ability to
>...

Tony,

I'm going to pretend that I don't have an opinion on the
validity of your comments.  Let's just suppose that you are
correct and that some sufficient fraction of the community would
agree with you after, if necessary, some education and
persuasion.  There would then, IMO, be three choices:

(1) Move to deprecate the thing, presumably making it historic
(or using the long-forgotten recommendation levels to identify
it as NOT RECOMMENDED), on the theory that it is worse than
nothing.

(2) Fix it, on the theory that the idea of using SMTP over TLS
is reasonable but that the specification needs tightening up.  

(3) Just ignore the issues and pretend that they don't exist. 

I think the third is untenable if we believe our standards
should be credible, even if it is the default.

The second is completely consistent with generating a new
document and trying to advance it to Draft Standard.  If that
were to fail because of the number and nature of changes that
would be required, we would still have a document to recycle at
Proposed that, presumably, would be better than what we have
now, especially given the weaknesses you identify/claim.

Are you suggesting some other course of action?

      john

p.s. While others may have other reasons, this sort of thing is
exactly why I believe that we should put some effort into taking
the email documents that have been sitting around for some time
and that have an important role in the infrastructure, reviewing
them, and advancing them on the standards track.  Doing so isn't
just symbolic. It gives us both the opportunity and obligation
to review which requirements have turned out to be too weak or
too strong, what is ambiguous, and what people either haven't
implemented or cared about in practice ... and to fix things as
needed.   Too many of our Proposed Standards are a little too
close to what might be described as "compile and ship" from an
implementer standpoint.  That is fine for Proposed Standards,
but they shouldn't be the last word on the subject.   

Personally, I think Paul did a rather nice job with 2487/3207
given what we knew, what experience we had, and what we could
say with certainty at the time.  But it has been enough years
that, IMO, some updating and clarification is in order.  And
this certainly is not the only spec in that state.

   john

Date: Fri, 24 Oct 2008 16:17:47 +0100
From: Tony Finch <[email-masked]>
To: John C Klensin <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, Matti Aarnio <[email-masked]>, Philip Guenther <[email-masked]>, Ivar Lumi <[email-masked]>, [email-masked]
Subject: Re: RFC 3207 STARTTLS
Sender: [email-masked]

On Thu, 23 Oct 2008, John C Klensin wrote:
>
> Any chance that someone could get motivated to generate an I-D, with
> these documentation weaknesses fixed, and move it toward Draft Standard?
> Certainly there are a sufficient number of interoperable implementations
> to meet that particular requirement.

RFC 3207 is extremely weak from the security point of view.

For example, it says "The additional option of using TLS when possible
SHOULD also be provided." This option makes most MUAs vulnerable to
man-in-the-middle attacks in common configurations. The RFC suggests a
mechanism to mitigate this weakness - "An implementation MAY provide the
ability to record that TLS was used in communicating with a given peer and
generating a warning if it is not used in a later session" - but it's only
a MAY and no-one actually implements it.

There is no firm specification of how an SMTP implementation should use
the results of TLS authentication, so in practice MTAs just ignore the
results. (MUAs are better.) As a consequence many TLS certificates offered
by MX hosts match neither the MX's mail domain nor its host name. A
postmaster can only avoid this vulnerability by setting up a special
bilateral agreement to require TLS certificate authentication between two
MTAs, but this is impossible for general inter-domain email so TLS as
deployed provides no protection against active atacks.

There is no discussion of the mismatch between MX records and TLS
certificate authentication. Even if the problems in the previous paragraph
are fixed, an attacker can still eliminate any benefit of authentication
by attacking the DNS. Since TLS authenticates the host name not the mail
domain, it cannot detect that an MX has been redirected.

There are other problems with the specification but I think those are the
worst.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
NORTH UTSIRE SOUTH UTSIRE FORTIES CROMARTY FORTH: SOUTHWESTERLY 7 TO SEVERE
GALE 9, PERHAPS STORM 10 LATER. VERY ROUGH OR HIGH, OCCASIONALLY ROUGH IN
FORTH. RAIN OR SQUALLY SHOWERS. MODERATE OR POOR, OCCASIONALLY GOOD IN
CROMARTY AND FORTH.

Date: Fri, 24 Oct 2008 00:07:49 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Nate Leon <[email-masked]>
CC: Ivar Lumi <[email-masked]>, [email-masked]
Subject: Re: RFC 3207 STARTTLS
Sender: [email-masked]

Nate Leon wrote:

> That is what I did in the end.
> At first, my SMTP server was sending the client an error, and then 
> closing the connection, but it was breaking some clients.  
 > IIRC, it was  a Microsoft Exchange server complaining that
 > it received two responses to one command, and of coure, that was true.

The normal practice is for servers to "never" to drop connections.  If 
there is a negative response code to be provided, allow the client to 
decide what to do next.  In most automated cases, the client has no 
choice but to end the session.  It is better to allow the client to 
take control so that it can manage its retries, if necessary.

One good reason for the server to drop connection is when an "errant" 
client is not behaving properly, like trying to repeat something that 
will not change the state.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Thu, 23 Oct 2008 19:41:10 -0700
From: "Nate Leon" <[email-masked]>
To: "Ivar Lumi" <[email-masked]>
Subject: Re: RFC 3207 STARTTLS
Cc: "Philip Guenther" <[email-masked]>, [email-masked]
Sender: [email-masked]

------=_Part_448_4058125.1224816071035
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

That is what I did in the end.
At first, my SMTP server was sending the client an error, and then closing
the connection, but it was breaking some clients.  IIRC, it was a Microsoft
Exchange server complaining that it received two responses to one command,
and of coure, that was true.

e.g.
C: STARTTLS
S: 220 Ready to start TLS
<TLS negotiation fails>
S: 454  4.4.3  TLS not available: error negotiating handshake
C: huh?

So I just skipped the error, and dropped the connection.
n8

On Thu, Oct 23, 2008 at 1:19 AM, Ivar Lumi <[email-masked]> wrote:

>
>
> Thanks,  this is what i was looking for.
>
> So in case of SMTP, server just should close connection.
>
>
>
> Philip Guenther wrote:
>
>> On Thu, 23 Oct 2008, Ivar Lumi wrote:
>>
>>
>>> After reading RFC 3207, i found probably non documented item.
>>>
>>> For example:
>>> C: STARTTLS
>>> S: 220 Go ahead
>>> C: <starts TLS negotiation>
>>> C & S: <negotiate a TLS session>
>>> C & S: <check result of negotiation>
>>>
>>> Now if negotiation fails, whats then ?
>>> Send error ? close connection ?
>>> Whats the proper action ?
>>>
>>>
>>
>> RFC 3207 cites/defers to RFC 2246 for the definition of the TLS protocol.
>> So follow the rules over in the TLS specification.  To quote RFC 2246:
>>
>> 7.2.2. Error alerts
>>
>>   Error handling in the TLS Handshake protocol is very simple. When an
>>   error is detected, the detecting party sends a message to the other
>>   party. Upon transmission or receipt of an fatal alert message, both
>>   parties immediately close the connection.  <...>
>> ...
>>   handshake_failure
>>      Reception of a handshake_failure alert message indicates that the
>>      sender was unable to negotiate an acceptable set of security
>>      parameters given the options available.  This is a fatal error.
>>
>> (Other errors may apply, depending on exactly what you mean by
>> "negotiation fails".)
>>
>> I.e., if your end detects a fatal error, send a fatal error alert and
>> close the connection.  If your end receives a fatal error alert, close the
>> connection.
>>
>>
>> Philip Guenther
>>
>>
>
>

------=_Part_448_4058125.1224816071035
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div>That is what I did in the end.</div>
<div>At first, my SMTP server was sending the client an error, and then closing the connection, but it was breaking some clients.&nbsp; IIRC, it was a Microsoft Exchange server complaining that it received two responses to one command, and of coure,&nbsp;that was true.</div>

<div>&nbsp;</div>
<div>e.g.</div>
<div>C: STARTTLS<br>S: 220 Ready to start TLS<br>&lt;TLS negotiation fails&gt;<br>S:&nbsp;454&nbsp; 4.4.3&nbsp; TLS not available: error negotiating handshake</div><font color="#008000" size="2"><font color="#008000" size="2">
<div></div></font></font>C: huh?
<div>&nbsp;</div>
<div>So I just skipped the error, and dropped the connection.</div>
<div>n8<br><br></div>
<div class="gmail_quote">On Thu, Oct 23, 2008 at 1:19 AM, Ivar Lumi <span dir="ltr">&lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><br><br>Thanks, &nbsp;this is what i was looking for.<br><br>So in case of SMTP, server just should close connection. 
<div>
<div></div>
<div class="Wj3C7c"><br><br><br>Philip Guenther wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">On Thu, 23 Oct 2008, Ivar Lumi wrote:<br>&nbsp;<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">After reading RFC 3207, i found probably non documented item.<br><br>For example:<br>C: STARTTLS<br>S: 220 Go ahead<br>
C: &lt;starts TLS negotiation&gt;<br>C &amp; S: &lt;negotiate a TLS session&gt;<br>C &amp; S: &lt;check result of negotiation&gt;<br><br>Now if negotiation fails, whats then ?<br>Send error ? close connection ?<br>Whats the proper action ?<br>
&nbsp; &nbsp;<br></blockquote><br>RFC 3207 cites/defers to RFC 2246 for the definition of the TLS protocol. So follow the rules over in the TLS specification. &nbsp;To quote RFC 2246:<br><br><a href="http://7.2.2./" target="_blank">7.2.2.</a> Error alerts<br>
<br>&nbsp; Error handling in the TLS Handshake protocol is very simple. When an<br>&nbsp; error is detected, the detecting party sends a message to the other<br>&nbsp; party. Upon transmission or receipt of an fatal alert message, both<br>
&nbsp; parties immediately close the connection. &nbsp;&lt;...&gt;<br>...<br>&nbsp; handshake_failure<br>&nbsp; &nbsp; &nbsp;Reception of a handshake_failure alert message indicates that the<br>&nbsp; &nbsp; &nbsp;sender was unable to negotiate an acceptable set of security<br>
&nbsp; &nbsp; &nbsp;parameters given the options available. &nbsp;This is a fatal error.<br><br>(Other errors may apply, depending on exactly what you mean by &quot;negotiation fails&quot;.)<br><br>I.e., if your end detects a fatal error, send a fatal error alert and close the connection. &nbsp;If your end receives a fatal error alert, close the connection.<br>
<br><br>Philip Guenther<br>&nbsp;<br></blockquote><br></div></div></blockquote></div><br>

------=_Part_448_4058125.1224816071035--

From: Mark Crispin <[email-masked]>
To: Douglas Otis <[email-masked]>, "Murray S. Kucherawy" <[email-masked]>
CC: <[email-masked]>, <[email-masked]>, Mail-Vet-Discuss <[email-masked]>
Subject: RE: [mail-vet-discuss] Straw consensus call on auth-header draft
Date: Thu, 23 Oct 2008 19:07:55 -0700
Importance: Normal
Sender: [email-masked]

--_2b333ddd-2963-4a09-9d07-78b8bbdb2159_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

+1

> From: [email-masked]
> Get rid of the sales hype describing everything as "authentication".  =20
> Security is no time for muddled or misused terminology.  There is no =20
> reason to mislead recipients any more than they already are.

_________________________________________________________________
When your life is on the go=97take your life with you.
http://clk.atdmt.com/MRT/go/115298558/direct/01/=

--_2b333ddd-2963-4a09-9d07-78b8bbdb2159_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt=3B
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class=3D'hmmessage'>
+1<br><br>&gt=3B From: [email-masked]<br>&gt=3B Get rid of the sales =
hype describing everything as "authentication".   <br>&gt=3B Security is no=
 time for muddled or misused terminology.  There is no  <br>&gt=3B reason t=
o mislead recipients any more than they already are.<br><br><br /><hr />Whe=
n your life is on the go=97take your life with you. <a href=3D'http://clk.a=
tdmt.com/MRT/go/115298558/direct/01/' target=3D'_new'>Try Windows Mobile=AE=
 today</a></body>
</html>=

--_2b333ddd-2963-4a09-9d07-78b8bbdb2159_--

Cc: [email-masked], [email-masked], Mail-Vet-Discuss <[email-masked]>
From: Douglas Otis <[email-masked]>
To: "Murray S. Kucherawy" <[email-masked]>
Subject: Re: [mail-vet-discuss] Straw consensus call on auth-header draft
Date: Thu, 23 Oct 2008 18:03:00 -0700
Sender: [email-masked]

On Oct 23, 2008, at 11:49 AM, Murray S. Kucherawy wrote:

> Douglas Otis wrote:
>> The ADSP draft inhibits an assurance regarding _what_ the signing  
>> domain authenticated!  The Author Signature definition limits a  
>> signing-domain's associated "on-behalf-of" identifier to being an  
>> email address within the From header field or to being _blank_.     
>> As a result, any intra-domain abuse can not be safely identified.    
>> One would be mistaken to assume the From email-address is always  
>> what a signing domain authenticates.  No other assumption would be  
>> available without incurring an impractical second signature that is  
>> likely ignored anyway.  Should one care about the damage created by  
>> an incorrect assumption regarding authentication, even when the  
>> assumption is signed by the border MTA?  Perhaps this could be call  
>> the Assumed-Authentication-Results header. : )
>>
>> -Doug
>
> Doug,
>
> I'm pretty sure you're talking about the reliability/assertions of  
> ADSP or even DKIM.  That's orthogonal to what we're discussing here  
> on mail-vet-discuss.  This draft is about moving the evaluation  
> results from an MTA to MUAs in a consistent and reliable manner.   
> That the evaluations themselves could conceivably be flawed or  
> subverted is already discussed in Security Considerations for this  
> draft and is not within the scope of this document.

I responded to a different message on mail-vet and dkim.  Here is the  
portion that attempts to explain the concern:

A security mechanism should not recklessly abuse the term  
Authentication.  The term Authentication is _dangerously_ misleading  
for most methods logged by this header.  The term "Authentication"  
should be replaced by a neutral term "method" within draft where  
possible.  It would not be too misleading to use the terms   
"Authentication or Authorization" instead of just "Authentication"   
within a few sentences.   A header label "Source-Results"  would be  
less deceptive in respect to the nature of the results obtained.  The  
term Authentication is being misused more than 60 times through out  
this draft (ignoring the title and header labels).  Admittedly the  
word "authorized" is buried in the definition of some results,  but   
this term will _never_ be evident to the user.  Do you see the danger  
using the header label "Authentication-Results:"?  The draft's  
introductory statement does not help much either:

"At the time of publication of this draft, [AUTH], [DKIM],   
[DOMAINKEYS], [SENDERID] and [SPF] are the published e-mail  
authentication methods in common use."

Authentication methods?  Really?

It is _dangerous_ and _misleading_ to suggest that an SMTP client  
_authorization_ method results in the "authentication" of the PRA,  
MAILFROM, the valid origination of the message as stated in this  
draft.  An _unauthorized_ SMTP client MAY be an indication of the  
invalid use of a MAILFROM or PRA,  however an authorized SMTP client  
must not be assumed to indicate the valid use of an email-address, as  
suggested by the overused term "Authentication" through out this   
draft.  Describing an authorization method as being an authentication  
method results in a dangerous misrepresentation of the results  
produced for most of the methods currently defined, even for DKIM-ADSP  
at this time.

Get rid of the sales hype describing everything as "authentication".   
Security is no time for muddled or misused terminology.  There is no  
reason to mislead recipients any more than they already are.

-Doug

Date: Thu, 23 Oct 2008 11:49:27 -0700
From: "Murray S. Kucherawy" <[email-masked]>
To: Douglas Otis <[email-masked]>
CC: Dave CROCKER <[email-masked]>, [email-masked], Mail-Vet-Discuss <[email-masked]>, [email-masked]
Subject: Re: [mail-vet-discuss] Straw consensus call on auth-header draft
Sender: [email-masked]

Douglas Otis wrote:
> The ADSP draft inhibits an assurance regarding _what_ the signing 
> domain authenticated!  The Author Signature definition limits a 
> signing-domain's associated "on-behalf-of" identifier to being an 
> email address within the From header field or to being _blank_.    As 
> a result, any intra-domain abuse can not be safely identified.   One 
> would be mistaken to assume the From email-address is always what a 
> signing domain authenticates.  No other assumption would be available 
> without incurring an impractical second signature that is likely 
> ignored anyway.  Should one care about the damage created by an 
> incorrect assumption regarding authentication, even when the 
> assumption is signed by the border MTA?  Perhaps this could be call 
> the Assumed-Authentication-Results header. : )
>
> -Doug
>

Doug,

I'm pretty sure you're talking about the reliability/assertions of ADSP 
or even DKIM.  That's orthogonal to what we're discussing here on 
mail-vet-discuss.  This draft is about moving the evaluation results 
from an MTA to MUAs in a consistent and reliable manner.  That the 
evaluations themselves could conceivably be flawed or subverted is 
already discussed in Security Considerations for this draft and is not 
within the scope of this document.

Date: Thu, 23 Oct 2008 12:16:58 -0400
From: John C Klensin <[email-masked]>
To: Paul Hoffman <[email-masked]>, Alexey Melnikov <[email-masked]>, Tony Hansen <[email-masked]>
cc: [email-masked]
Subject: Re: RFC 3207 STARTTLS
Sender: [email-masked]

--On Thursday, 23 October, 2008 09:11 -0700 Paul Hoffman
<[email-masked]> wrote:

> Definitely not before Minneapolis, but I'm willing to open
> STARTTLS again and make clarifications.

I, at least, look forward to it.  Thanks.
   john

Date: Thu, 23 Oct 2008 09:11:34 -0700
To: John C Klensin <[email-masked]>, Alexey Melnikov <[email-masked]>, Tony Hansen <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: RFC 3207 STARTTLS
Cc: [email-masked]
Sender: [email-masked]

Definitely not before Minneapolis, but I'm willing to open STARTTLS again and make clarifications.

Date: Thu, 23 Oct 2008 11:48:13 -0400
From: John C Klensin <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Tony Hansen <[email-masked]>
cc: Paul Hoffman <[email-masked]>, [email-masked]
Subject: Re: RFC 3207 STARTTLS
Sender: [email-masked]

--On Thursday, 23 October, 2008 16:31 +0100 Alexey Melnikov
<[email-masked]> wrote:

>> Any chance that someone could get motivated to generate an
>> I-D, with these documentation weaknesses fixed, and move it
>> toward Draft Standard?   Certainly there are a sufficient
>> number of interoperable implementations to meet that
>> particular requirement.
>>  
>> 
> I was trying to encourage Paul Hoffman to update STARTTLS when
> I was updating SMTP AUTH.
> I think we might have a critical mass now.
> 
> I can certainly help to review changes. But I don't have much
> cycles to [co-]edit a new document before Minneapolis.

I was thinking less about "before Minneapolis" (although that
would be great) but about general efforts to get a bunch of
these email documents clarified, tightened up, and advanced
toward full standard.   If we need an excuse, the sorts of
perceived ambiguity, black magic/oral tradition, etc., that this
thread seems to have turned up should probably provide it.

Which remind me... Tony, I don't think I've seen a charter for
the consolidated "advance documents" effort.  Is it stalled for
some reason or just slipping toward the "few cycles" cracks?

   john

Date: Thu, 23 Oct 2008 16:31:48 +0100
From: Alexey Melnikov <[email-masked]>
To: John C Klensin <[email-masked]>
CC: Paul Hoffman <[email-masked]>, [email-masked]
Subject: Re: RFC 3207 STARTTLS
Sender: [email-masked]

John C Klensin wrote:

>--On Thursday, 23 October, 2008 10:48 +0100 Alexey Melnikov
><[email-masked]> wrote:
>  
>
>>Matti Aarnio wrote:
>>    
>>
>>>On Thu, Oct 23, 2008 at 12:44:05AM -0700, Philip Guenther
>>>wrote:
>>>      
>>>
>>>>On Thu, 23 Oct 2008, Ivar Lumi wrote:
>>>>        
>>>>
>>>>>After reading RFC 3207, i found probably non documented
>>>>>item.
>>>>>          
>>>>>
>>...
>>    
>>
>>>Most cases of using TLS and server certificates on SMTP are
>>>not getting even certificate CN quite right.  Certificate
>>>verification is purely black magic.
>>>      
>>>
>>Yes, this could have been better documented.
>>    
>>
>Any chance that someone could get motivated to generate an I-D,
>with these documentation weaknesses fixed, and move it toward
>Draft Standard?   Certainly there are a sufficient number of
>interoperable implementations to meet that particular
>requirement.
>  
>
I was trying to encourage Paul Hoffman to update STARTTLS when I was 
updating SMTP AUTH.
I think we might have a critical mass now.

I can certainly help to review changes. But I don't have much cycles to 
[co-]edit a new document before Minneapolis.

Date: Thu, 23 Oct 2008 11:18:11 -0400
From: John C Klensin <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Matti Aarnio <[email-masked]>
cc: Philip Guenther <[email-masked]>, Ivar Lumi <[email-masked]>, [email-masked]
Subject: Re: RFC 3207 STARTTLS
Sender: [email-masked]

--On Thursday, 23 October, 2008 10:48 +0100 Alexey Melnikov
<[email-masked]> wrote:

> 
> Matti Aarnio wrote:
> 
>> On Thu, Oct 23, 2008 at 12:44:05AM -0700, Philip Guenther
>> wrote:
>>  
>> 
>>> On Thu, 23 Oct 2008, Ivar Lumi wrote:
>>>    
>>> 
>>>> After reading RFC 3207, i found probably non documented
>>>> item.
>...
>> Most cases of using TLS and server certificates on SMTP are
>> not getting even certificate CN quite right.  Certificate
>> verification is purely black magic.
>>  
>> 
> Yes, this could have been better documented.

Any chance that someone could get motivated to generate an I-D,
with these documentation weaknesses fixed, and move it toward
Draft Standard?   Certainly there are a sufficient number of
interoperable implementations to meet that particular
requirement.

    john

Date: Thu, 23 Oct 2008 10:48:44 +0100
From: Alexey Melnikov <[email-masked]>
To: Matti Aarnio <[email-masked]>
CC: Philip Guenther <[email-masked]>, Ivar Lumi <[email-masked]>, [email-masked]
Subject: Re: RFC 3207 STARTTLS
Sender: [email-masked]

Matti Aarnio wrote:

>On Thu, Oct 23, 2008 at 12:44:05AM -0700, Philip Guenther wrote:
>  
>
>>On Thu, 23 Oct 2008, Ivar Lumi wrote:
>>    
>>
>>>After reading RFC 3207, i found probably non documented item.
>>>
>>>For example:
>>>C: STARTTLS
>>>S: 220 Go ahead
>>>C: <starts TLS negotiation>
>>>C & S: <negotiate a TLS session>
>>>C & S: <check result of negotiation>
>>>
>>>Now if negotiation fails, whats then ?
>>>Send error ? close connection ?
>>>Whats the proper action ?
>>>      
>>>
>>RFC 3207 cites/defers to RFC 2246 for the definition of the TLS protocol. 
>>So follow the rules over in the TLS specification.  To quote RFC 2246:
>>
>>7.2.2. Error alerts
>>
>>   Error handling in the TLS Handshake protocol is very simple. When an
>>   error is detected, the detecting party sends a message to the other
>>   party. Upon transmission or receipt of an fatal alert message, both
>>   parties immediately close the connection.  <...>
>>...
>>   handshake_failure
>>      Reception of a handshake_failure alert message indicates that the
>>      sender was unable to negotiate an acceptable set of security
>>      parameters given the options available.  This is a fatal error.
>>
>>(Other errors may apply, depending on exactly what you mean by 
>>"negotiation fails".)
>>
>>I.e., if your end detects a fatal error, send a fatal error alert and 
>>close the connection.  If your end receives a fatal error alert, close the 
>>connection.
>>    
>>
>So far so good, but what to do at SMTP level ?
>  
>
If the error happened once TLS negotiation started, then the server has 
no choice but to close the connection at SMTP level.

>  a)  If running as "opportunistic encrypter", one can degrade the connection
>      to plain and try to send the message (by making a new connection and not
>      trying to enable TLS).
>
>    a2)  Possibly sending additional informational warning to the email originator
>         about the failure to run opportunistic encryption, when the message was
>         sent over non-encrypted connection after STARTTLS fault.
>
>  b)  If the address specific routing sets a policy is to send given destination
>      only via encrypted and with certificate validated TLS connetion, and it
>      fails, then the only way is to return the message back to originator.
>
>Most cases of using TLS and server certificates on SMTP are not getting even
>certificate CN quite right.  Certificate verification is purely black magic.
>  
>
Yes, this could have been better documented.

Date: Thu, 23 Oct 2008 10:46:32 +0100
From: Alexey Melnikov <[email-masked]>
To: Ivar Lumi <[email-masked]>
CC: [email-masked]
Subject: Re: RFC 3207 STARTTLS
Sender: [email-masked]

Ivar Lumi wrote:

> Hi,
>
> After reading RFC 3207, i found probably non documented item.
>
> For example:
> C: STARTTLS
> S: 220 Go ahead
> C: <starts TLS negotiation>
> C & S: <negotiate a TLS session>
> C & S: <check result of negotiation>
>
> Now if negotiation fails, whats then ?
> Send error ? close connection ?
> Whats the proper action ?

Philip's response is correct.

I just want to add one more thing: if the server can detect TLS failure 
before issuing "220 Go ahead" (e.g. a server TLS certificate is not 
configured), it should do so and return failure at this stage.
Even better if the server pre-create TLS context upfront and don't 
advertise STARTTLS if there is no chance of it succeeding.

Date: Thu, 23 Oct 2008 11:19:16 +0300
From: Ivar Lumi <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: [email-masked]
Subject: Re: RFC 3207 STARTTLS
Sender: [email-masked]

Thanks,  this is what i was looking for.

So in case of SMTP, server just should close connection.

Philip Guenther wrote:
> On Thu, 23 Oct 2008, Ivar Lumi wrote:
>   
>> After reading RFC 3207, i found probably non documented item.
>>
>> For example:
>> C: STARTTLS
>> S: 220 Go ahead
>> C: <starts TLS negotiation>
>> C & S: <negotiate a TLS session>
>> C & S: <check result of negotiation>
>>
>> Now if negotiation fails, whats then ?
>> Send error ? close connection ?
>> Whats the proper action ?
>>     
>
> RFC 3207 cites/defers to RFC 2246 for the definition of the TLS protocol. 
> So follow the rules over in the TLS specification.  To quote RFC 2246:
>
> 7.2.2. Error alerts
>
>    Error handling in the TLS Handshake protocol is very simple. When an
>    error is detected, the detecting party sends a message to the other
>    party. Upon transmission or receipt of an fatal alert message, both
>    parties immediately close the connection.  <...>
> ...
>    handshake_failure
>       Reception of a handshake_failure alert message indicates that the
>       sender was unable to negotiate an acceptable set of security
>       parameters given the options available.  This is a fatal error.
>
> (Other errors may apply, depending on exactly what you mean by 
> "negotiation fails".)
>
> I.e., if your end detects a fatal error, send a fatal error alert and 
> close the connection.  If your end receives a fatal error alert, close the 
> connection.
>
>
> Philip Guenther
>   

Date:	Thu, 23 Oct 2008 11:19:05 +0300
From: Matti Aarnio <[email-masked]>
To: Philip Guenther <[email-masked]>
Cc: Ivar Lumi <[email-masked]>, [email-masked]
Subject: Re: RFC 3207 STARTTLS
Sender: [email-masked]

On Thu, Oct 23, 2008 at 12:44:05AM -0700, Philip Guenther wrote:
> On Thu, 23 Oct 2008, Ivar Lumi wrote:
> > After reading RFC 3207, i found probably non documented item.
> > 
> > For example:
> > C: STARTTLS
> > S: 220 Go ahead
> > C: <starts TLS negotiation>
> > C & S: <negotiate a TLS session>
> > C & S: <check result of negotiation>
> > 
> > Now if negotiation fails, whats then ?
> > Send error ? close connection ?
> > Whats the proper action ?
> 
> RFC 3207 cites/defers to RFC 2246 for the definition of the TLS protocol. 
> So follow the rules over in the TLS specification.  To quote RFC 2246:
> 
> 7.2.2. Error alerts
> 
>    Error handling in the TLS Handshake protocol is very simple. When an
>    error is detected, the detecting party sends a message to the other
>    party. Upon transmission or receipt of an fatal alert message, both
>    parties immediately close the connection.  <...>
> ...
>    handshake_failure
>       Reception of a handshake_failure alert message indicates that the
>       sender was unable to negotiate an acceptable set of security
>       parameters given the options available.  This is a fatal error.
> 
> (Other errors may apply, depending on exactly what you mean by 
> "negotiation fails".)
> 
> I.e., if your end detects a fatal error, send a fatal error alert and 
> close the connection.  If your end receives a fatal error alert, close the 
> connection.

So far so good, but what to do at SMTP level ?

  a)  If running as "opportunistic encrypter", one can degrade the connection
      to plain and try to send the message (by making a new connection and not
      trying to enable TLS).

    a2)  Possibly sending additional informational warning to the email originator
         about the failure to run opportunistic encryption, when the message was
         sent over non-encrypted connection after STARTTLS fault.

  b)  If the address specific routing sets a policy is to send given destination
      only via encrypted and with certificate validated TLS connetion, and it
      fails, then the only way is to return the message back to originator.

Most cases of using TLS and server certificates on SMTP are not getting even
certificate CN quite right.  Certificate verification is purely black magic.

-- 
/Matti Aarnio	<[email-masked]>

Date: Thu, 23 Oct 2008 00:59:49 -0700
To: Ivar Lumi <[email-masked]>
From: SM <[email-masked]>
Subject: Re: RFC 3207 STARTTLS
Cc: [email-masked]
Sender: [email-masked]

Hi Ivar,
At 23:49 22-10-2008, Ivar Lumi wrote:
>After reading RFC 3207, i found probably non documented item.
>
>For example:
>C: STARTTLS
>S: 220 Go ahead
>C: <starts TLS negotiation>
>C & S: <negotiate a TLS session>
>C & S: <check result of negotiation>
>
>Now if negotiation fails, whats then ?
>Send error ? close connection ?
>Whats the proper action ?

Quoting that RFC:

   "If the TLS negotiation fails or if the client receives a 454
    response, the client has to decide what to do next.  There are three
    main choices: go ahead with the rest of the SMTP session, retry TLS
    at a later time, or give up and return the mail to the sender.  If a
    failure or error occurs, the client can assume that the server may be
    able to negotiate TLS in the future, and should try negotiate TLS in
    a later session, until some locally-chosen timeout occurs, at which
    point, the client should return the mail to the sender.  However, if
    the client and server were only using TLS for authentication, the
    client may want to proceed with the SMTP session, in case some of the
    operations the client wanted to perform are accepted by the server
    even if the client is unauthenticated."

The proper action is a matter of local policy.  If the SMTP server 
requires a secure transport, then the SMTP client won't be able to 
send the message in that session.

Regards,
-sm 

Date: Thu, 23 Oct 2008 00:44:05 -0700
From: Philip Guenther <[email-masked]>
To: Ivar Lumi <[email-masked]>
cc: [email-masked]
Subject: Re: RFC 3207 STARTTLS
Sender: [email-masked]

On Thu, 23 Oct 2008, Ivar Lumi wrote:
> After reading RFC 3207, i found probably non documented item.
> 
> For example:
> C: STARTTLS
> S: 220 Go ahead
> C: <starts TLS negotiation>
> C & S: <negotiate a TLS session>
> C & S: <check result of negotiation>
> 
> Now if negotiation fails, whats then ?
> Send error ? close connection ?
> Whats the proper action ?

RFC 3207 cites/defers to RFC 2246 for the definition of the TLS protocol. 
So follow the rules over in the TLS specification.  To quote RFC 2246:

7.2.2. Error alerts

   Error handling in the TLS Handshake protocol is very simple. When an
   error is detected, the detecting party sends a message to the other
   party. Upon transmission or receipt of an fatal alert message, both
   parties immediately close the connection.  <...>
...
   handshake_failure
      Reception of a handshake_failure alert message indicates that the
      sender was unable to negotiate an acceptable set of security
      parameters given the options available.  This is a fatal error.

(Other errors may apply, depending on exactly what you mean by 
"negotiation fails".)

I.e., if your end detects a fatal error, send a fatal error alert and 
close the connection.  If your end receives a fatal error alert, close the 
connection.

Philip Guenther

Date: Thu, 23 Oct 2008 09:49:29 +0300
From: Ivar Lumi <[email-masked]>
To: [email-masked]
Subject: RFC 3207 STARTTLS
Sender: [email-masked]

Hi,

After reading RFC 3207, i found probably non documented item.

For example:
C: STARTTLS
S: 220 Go ahead
C: <starts TLS negotiation>
C & S: <negotiate a TLS session>
C & S: <check result of negotiation>

Now if negotiation fails, whats then ?
Send error ? close connection ?
Whats the proper action ?

Thanks,

Date: Wed, 22 Oct 2008 10:35:04 -0700 (PDT)
From: [email-masked]
Subject: Re: RFC 5321 4.4 Received BNF
To: Ivar Lumi <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> Hi,

> Below syntax seems to be obsolete for me:

> RFC 5321 4.4
>     From-domain     = "FROM" FWS Extended-Domain
>     By-domain       = CFWS "BY" FWS Extended-Domain
>     Extended-Domain = Domain / ( Domain FWS "(" TCP-info ")" ) / (
> address-literal FWS "(" TCP-info ")" )
>     TCP-info        = address-literal / ( Domain FWS address-literal )

> How TCP-info parsed ?
> The problem is if no TCP-info prsesnet and CFWS between By-domain
> contains comment.

> For example:
> Received: from domain.com (host.domain.com 10.0.0.1)  by ... - contains
> domain
> Received: from domain.com (this is comment text)  by ... - contains
> comment and not optional TCP-info

> Do i miss something or in real-life you can't be sure if TCP-info or
> comment was supplied ?

You can't be sure. The syntax is overloaded.

> (Just guessing if commect = address-literal or comment argument2 =
> address-literal is just not best option)

I'm afraid it's pretty much the only option.

				Ned

Date: Wed, 22 Oct 2008 12:28:30 +0300
From: Ivar Lumi <[email-masked]>
To: [email-masked]
Subject: RFC 5321 4.4 Received BNF
Sender: [email-masked]

Hi,

Below syntax seems to be obsolete for me:

RFC 5321 4.4
    From-domain     = "FROM" FWS Extended-Domain
    By-domain       = CFWS "BY" FWS Extended-Domain
    Extended-Domain = Domain / ( Domain FWS "(" TCP-info ")" ) / ( 
address-literal FWS "(" TCP-info ")" )
    TCP-info        = address-literal / ( Domain FWS address-literal )

How TCP-info parsed ?
The problem is if no TCP-info prsesnet and CFWS between By-domain 
contains comment.

For example:
Received: from domain.com (host.domain.com 10.0.0.1)  by ... - contains 
domain
Received: from domain.com (this is comment text)  by ... - contains 
comment and not optional TCP-info

Do i miss something or in real-life you can't be sure if TCP-info or 
comment was supplied ?
(Just guessing if commect = address-literal or comment argument2 = 
address-literal is just not best option)

Any comments are welcome.

Thanks,

Cc: Dave CROCKER <[email-masked]>, [email-masked], Mail-Vet-Discuss <[email-masked]>, [email-masked]
From: Douglas Otis <[email-masked]>
To: "Murray S. Kucherawy" <[email-masked]>
Subject: Re: [mail-vet-discuss] Straw consensus call on auth-header draft
Date: Tue, 21 Oct 2008 17:06:01 -0700
Sender: [email-masked]

On Oct 14, 2008, at 2:24 PM, Murray S. Kucherawy wrote:

>
> Douglas Otis wrote:
>> Agreed.  However, when a domain attempts to assert control over the  
>> From header field using DKIM and ADSP, they must "pretend" to  
>> authenticate an email-address within the From header field.
>
> I don't think we're talking about any such assertions here.  We're  
> only interested in protecting an Authentication-Results: header  
> added by a border MTA on inbound mail.  Seems like ADSP and even  
> From: are somewhat irrelevant to this discussion.

The ADSP draft inhibits an assurance regarding _what_ the signing  
domain authenticated!  The Author Signature definition limits a  
signing-domain's associated "on-behalf-of" identifier to being an  
email address within the From header field or to being _blank_.    As  
a result, any intra-domain abuse can not be safely identified.   One  
would be mistaken to assume the From email-address is always what a  
signing domain authenticates.  No other assumption would be available  
without incurring an impractical second signature that is likely  
ignored anyway.  Should one care about the damage created by an  
incorrect assumption regarding authentication, even when the  
assumption is signed by the border MTA?  Perhaps this could be call  
the Assumed-Authentication-Results header. : )

-Doug

Date: Wed, 15 Oct 2008 06:17:28 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Lisa Dusseault <[email-masked]>
CC: Mail-Vet-Discuss <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Straw consensus call on auth-header draft
Sender: [email-masked]

Lisa Dusseault wrote:
> I'd like to do a more explicit consensus call now to nail this down.  
> I've tried to identify the major points of attraction rather than every 
> variant, to see where people are leaning.   Please reply with one of 
> these options, a variant, and explanation if you like:
> 
> A)  auth-header to not require any feature advertising or auto-configuration
> B) auth-header to normatively RECOMMEND some kind of feature advertising
> C) auth-header to normatively REQUIRE some kind of feature advertising

"C" for having a reason for living (implementing it).  Otherwise, 
whats the point?  "A" will further create fuzzy unknowns about trust. 
    While B is the middle ground, it is just as bad as A.

> Separately, the unspecified feature advertising or auto-conf should be 
> (choose one or more):
> 1) IMAP Capabilities advertising
> 2) E/SMTP capabilities
> 3) IMAP annotations
> 4) Something else
> 5) Nothing

Thats just it.  Whats it for?

The only use I see for it is to pass intra-process (internal) state 
information, i.e. so that a 2nd trusted  process doesn't have to 
"re-do" whatever the first trusted process did.  For an Internal MUA 
(a trusted process), it can be used for state information.

Why and When would a offline MUA, for example, trust and make use of 
this information?  In terms of DKIM, does it replace the need for an 
MUA to do DKIM verification?

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

From: Steve Atkins <[email-masked]>
To: SMTP Interest Group <[email-masked]>, [email-masked], Mail-Vet-Discuss <[email-masked]>
Subject: Re: [mail-vet-discuss] Straw consensus call on auth-header draft
Date: Tue, 14 Oct 2008 15:04:42 -0700
Sender: [email-masked]

(I expect this message to be rejected by at least some of the mailing  
lists it was CCed to).

On Oct 14, 2008, at 2:24 PM, Murray S. Kucherawy wrote:

>
> Douglas Otis wrote:
>> Agreed.  However, when a domain attempts to assert control over the  
>> From header field using DKIM and ADSP, they must "pretend" to  
>> authenticate an email-address within the From header field.
>
> I don't think we're talking about any such assertions here.  We're  
> only interested in protecting an Authentication-Results: header  
> added by a border MTA on inbound mail.  Seems like ADSP and even  
> From: are somewhat irrelevant to this discussion.
>

If it's added by a border MTA, so it's only seen by your network after  
the header is added, what are you protecting it against?

Cheers,
   Steve

Date: Tue, 14 Oct 2008 14:24:55 -0700
From: "Murray S. Kucherawy" <[email-masked]>
To: Douglas Otis <[email-masked]>
CC: [email-masked], [email-masked], Mail-Vet-Discuss <[email-masked]>, [email-masked]
Subject: Re: [mail-vet-discuss] Straw consensus call on auth-header draft
Sender: [email-masked]

Douglas Otis wrote:
> Agreed.  However, when a domain attempts to assert control over the 
> From header field using DKIM and ADSP, they must "pretend" to 
> authenticate an email-address within the From header field.

I don't think we're talking about any such assertions here.  We're only 
interested in protecting an Authentication-Results: header added by a 
border MTA on inbound mail.  Seems like ADSP and even From: are somewhat 
irrelevant to this discussion.

Cc: [email-masked], [email-masked], Mail-Vet-Discuss <[email-masked]>, [email-masked]
From: Douglas Otis <[email-masked]>
To: "Murray S. Kucherawy" <[email-masked]>
Subject: Re: [mail-vet-discuss] Straw consensus call on auth-header draft
Date: Tue, 14 Oct 2008 09:52:13 -0700
Sender: [email-masked]

On Oct 13, 2008, at 12:58 PM, Murray S. Kucherawy wrote:

>
> Dave CROCKER wrote:
>> This begs the question:  why bother to do the first validation; why  
>> not simply wait and let whoever would have validated the first  
>> instead validate the first?
>
> If the only authentication method being applied at a site is DKIM or  
> other things that don't care about the path, that works.  But that's  
> a big "if", and moreover means all consumers of authentication  
> results data must now learn all local path-agnostic methods being  
> used to evaluate messages.
>
> The desire here is to secure arbitrary authentication results data  
> between the border MTA and the consuming MUA.  DKIM is one way that  
> could be achieved, meaning the consumers need to learn one and only  
> one message authentication scheme in order to validate that one  
> piece of protected internal data.

Agreed.  However, when a domain attempts to assert control over the  
 From header field using DKIM and ADSP, they must "pretend" to  
authenticate an email-address within the From header field.  ADSP,  
using a false premise of email-address authentication, has impaired  
DKIM's on-behalf-of field which is essential for evaluating intra- 
domain abuse.  If the source of a message is not abusive, there should  
be no reason to filter based upon content classifications.  In the  
case of ADSP, there no basis upon which classifications can be  
trusted.  The one exception would be for a perfect signing domain,  
otherwise these efforts represent an exercise in futility.

-Doug

Date: Tue, 14 Oct 2008 11:07:37 -0400
From: Dave CROCKER <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: "Murray S. Kucherawy" <[email-masked]>
CC: [email-masked], Mail-Vet-Discuss <[email-masked]>, [email-masked]
Subject: Re: [mail-vet-discuss] Straw consensus call on auth-header draft
Sender: [email-masked]

Murray,

Interesting and intriguing perspective.  I like it.

Perhaps I missed it, but I don't recall seeing such a coherent, focused and 
pragmatic requirements statement in this discussion, so far.

But note that what you are describing has nothing specific to mail-vet.

Really.

You are describing a generic requirement for trusted information exchange 
between two nodes that are possibly within a trust domain.  The fact that the 
information is, itself, security-related might affect some choices in the 
design, but not in a way that is specific to mail-vet (or the fact that it is 
security-releated...)  The other that might be a bit different is to protect a 
specified header field.  Again, I doubt that affects design choices all that much.

So mail-vet *might* be motivating it, but it is really an independent technical 
requirement.  It warrants an independent technical specification.

Let me repeat this:  To the extent that the current specification is for a data 
format, rather than an end-to-end exchange service, then an effort to satisfy 
this requirement belongs to a separate document.

And, of course, there are *lots* of ways to satisfy it.  That's a further reason 
to avoid burdening the current, core data spec with its details.

d/

Murray S. Kucherawy wrote:
> Dave CROCKER wrote:
>> This begs the question:  why bother to do the first validation; why 
>> not simply wait and let whoever would have validated the first instead 
>> validate the first?
> 
> If the only authentication method being applied at a site is DKIM or 
> other things that don't care about the path, that works.  But that's a 
> big "if", and moreover means all consumers of authentication results 
> data must now learn all local path-agnostic methods being used to 
> evaluate messages.
> 
> The desire here is to secure arbitrary authentication results data 
> between the border MTA and the consuming MUA.  DKIM is one way that 
> could be achieved, meaning the consumers need to learn one and only one 
> message authentication scheme in order to validate that one piece of 
> protected internal data.
> 

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Mon, 13 Oct 2008 18:00:15 -0700
To: Mail-Vet-Discuss <[email-masked]>, [email-masked], [email-masked]
From: SM <[email-masked]>
Subject: Re: [mail-vet-discuss] Straw consensus call on auth-header draft
Sender: [email-masked]

At 14:29 12-10-2008, Lisa Dusseault wrote:
>I'd like to do a more explicit consensus call now to nail this 
>down.  I've tried to identify the major points of attraction rather 
>than every variant, to see where people are leaning.   Please reply 
>with one of these options, a variant, and explanation if you like:
>
>A)  auth-header to not require any feature advertising or auto-configuration

I'm for (A).

>B) auth-header to normatively RECOMMEND some kind of feature advertising
>C) auth-header to normatively REQUIRE some kind of feature advertising

I gather that you are referring to advertising for the MUA through 
POP3 and IMAP.

>Separately, the unspecified feature advertising or auto-conf should 
>be (choose one or more):
>1) IMAP Capabilities advertising
>2) E/SMTP capabilities
>3) IMAP annotations
>4) Something else
>5) Nothing

I'm for (5).

Regards,
-sm 

Date: Mon, 13 Oct 2008 12:58:19 -0700
From: "Murray S. Kucherawy" <[email-masked]>
To: [email-masked]
CC: [email-masked], Mail-Vet-Discuss <[email-masked]>, [email-masked]
Subject: Re: [mail-vet-discuss] Straw consensus call on auth-header draft
Sender: [email-masked]

Dave CROCKER wrote:
> This begs the question:  why bother to do the first validation; why 
> not simply wait and let whoever would have validated the first instead 
> validate the first?

If the only authentication method being applied at a site is DKIM or 
other things that don't care about the path, that works.  But that's a 
big "if", and moreover means all consumers of authentication results 
data must now learn all local path-agnostic methods being used to 
evaluate messages.

The desire here is to secure arbitrary authentication results data 
between the border MTA and the consuming MUA.  DKIM is one way that 
could be achieved, meaning the consumers need to learn one and only one 
message authentication scheme in order to validate that one piece of 
protected internal data.

Date: Mon, 13 Oct 2008 15:50:39 -0400
From: Dave CROCKER <[email-masked]>
Organization: Brandenburg InternetWorking
To: Lisa Dusseault <[email-masked]>
CC: Mail-Vet-Discuss <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Straw consensus call on auth-header draft
Sender: [email-masked]

Lisa Dusseault wrote:
>> So, please clarify how can a technical specification contain normative 
>> language to cover something that doesn't exist?  More precisely, what 
>> does it mean to include such language, in terms of actual development 
>> or operation? What impact does such a statement have on the current 
>> specification?  On use of it?
> 
> Since that's not what I'm suggesting, I can't answer these questions.

It isn't?  Since your language was "normatively * some kind of feature 
advertising" then I am entirely confused.  The feature advertising for this does 
not yet exist.

You cite normatively referring to such advertising.  How did I mis-characterize 
your query?

>> The alternative seems to be to require the current specification to 
>> wait until there is an approved specification for 
>> advertising/configuration that can then, in turn, be recommended or 
>> required (presumably SHOULD OR MUST, respectively?)
> 
> That could be.

That's useful input, since it can level-set folks' expectations.

>> pps. What are examples of similar mechanisms, for application-level 
>> advertising or auto-configuration, that are already in Internet-scale 
>> use?   Knowing the answer to this can give some guidance about the 
>> likely risk of mandating such a mechanism here.
> 
> IMAP and SMTP have lots of application-level capabilities advertising.  
> Sometimes this can aid auto-configuration.

Hmmm.  Maybe it's jet-lag.  I'm not thinking of which ones you might have in mind.

I'd really appreciate some particulars, for advertising security-related 
features that rely on being within a trust boundary and are widely adopted and 
used.  What existing mechanisms qualify?

Thanks.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Mon, 13 Oct 2008 15:29:28 -0400
From: Dave CROCKER <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: "Murray S. Kucherawy" <[email-masked]>
CC: [email-masked], Mail-Vet-Discuss <[email-masked]>, [email-masked]
Subject: Re: [mail-vet-discuss] Straw consensus call on auth-header draft
Sender: [email-masked]

Murray S. Kucherawy wrote:
> 4 would include DKIM signing.  I'd be fine with adding a SHOULD there.

SHOULD?  You would specify a normative SHOULD for protecting a DKIM validation 
with a(nother) DKIM signature?

This begs the question:  why bother to do the first validation; why not simply 
wait and let whoever would have validated the first instead validate the first?

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Cc: Lisa Dusseault <[email-masked]>, Mail-Vet-Discuss <[email-masked]>, [email-masked], [email-masked]
From: Lisa Dusseault <[email-masked]>
To: [email-masked]
Subject: Re: Straw consensus call on auth-header draft
Date: Mon, 13 Oct 2008 10:56:54 -0700
Sender: [email-masked]

On Oct 12, 2008, at 4:44 PM, Dave CROCKER wrote:

>
>
>
> Lisa Dusseault wrote:
>> I'd like to do a more explicit consensus call now to nail this  
>> down.  I've tried to identify the major points of attraction rather  
>> than every variant, to see where people are leaning.   Please reply  
>> with one of these options, a variant, and explanation if you like:
>> A)  auth-header to not require any feature advertising or auto- 
>> configuration
>> B) auth-header to normatively RECOMMEND some kind of feature  
>> advertising
>> C) auth-header to normatively REQUIRE some kind of feature  
>> advertising
>
>
> Lisa,
>
> Your alternatives B & C appear to seek normative technical language  
> that refers to something that does not exist.  Further, a phrase  
> like "some kind of" makes it rather difficult to know whether the  
> 'requirement' is satisfied.

Yes, this is correct.  I realize this is somewhat of a charter-phase  
question, but that's a risk with individual submissions going for  
Proposed Standard -- the risk that without a consensus-based charter,  
the scope of the work will be questioned.

>
> It is generally ill-advised to have a specification make statements  
> about the unknown future, which of course means anything in the  
> future.  It seems an even poorer choice to make that statement be  
> normative, without specifying the details of that future precisely.

Agreed.

>
> So, please clarify how can a technical specification contain  
> normative language to cover something that doesn't exist?  More  
> precisely, what does it mean to include such language, in terms of  
> actual development or operation? What impact does such a statement  
> have on the current specification?  On use of it?

Since that's not what I'm suggesting, I can't answer these questions.
>
>
> The alternative seems to be to require the current specification to  
> wait until there is an approved specification for advertising/ 
> configuration that can then, in turn, be recommended or required  
> (presumably SHOULD OR MUST, respectively?)

That could be.

>
> ps.  But to conform to the precise confines of your exercise, I  
> suggest Alternative A, since there are many operational environments  
> for which manual configuration works just fine.  In those  
> environments, advertising and configuration mechanisms add  
> complexity without benefit.
>
>
> pps. What are examples of similar mechanisms, for application-level  
> advertising or auto-configuration, that are already in Internet- 
> scale use?   Knowing the answer to this can give some guidance about  
> the likely risk of mandating such a mechanism here.

IMAP and SMTP have lots of application-level capabilities  
advertising.  Sometimes this can aid auto-configuration.

Lisa

Date: Mon, 13 Oct 2008 10:37:41 -0700
From: "Murray S. Kucherawy" <[email-masked]>
To: Lisa Dusseault <[email-masked]>
CC: Mail-Vet-Discuss <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [mail-vet-discuss] Straw consensus call on auth-header draft
Sender: [email-masked]

Lisa Dusseault wrote:
> A)  auth-header to not require any feature advertising or auto-configuration
> B) auth-header to normatively RECOMMEND some kind of feature advertising
> C) auth-header to normatively REQUIRE some kind of feature advertising
>   

I'm currently between A and B.  I'm fine with referencing possible 
solutions, but I'm not sure I agree with the need for any normative 
language.

> Separately, the unspecified feature advertising or auto-conf should be
> (choose one or more):
> 1) IMAP Capabilities advertising
> 2) E/SMTP capabilities
> 3) IMAP annotations
> 4) Something else
> 5) Nothing
>   

I don't think 3 is relevant here.  It specifies a different mechanism 
entirely.

1 & 2 are what the draft should mention as experimental possibilities.

4 would include DKIM signing.  I'd be fine with adding a SHOULD there.

Date: Mon, 13 Oct 2008 11:09:28 +0100
From: Alexey Melnikov <[email-masked]>
To: Lisa Dusseault <[email-masked]>
CC: Mail-Vet-Discuss <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [mail-vet-discuss] Straw consensus call on auth-header draft
Sender: [email-masked]

Lisa Dusseault wrote:

> I'd like to do a more explicit consensus call now to nail this down.  
> I've tried to identify the major points of attraction rather than 
> every variant, to see where people are leaning.   Please reply with 
> one of these options, a variant, and explanation if you like:
>
> A)  auth-header to not require any feature advertising or 
> auto-configuration
> B) auth-header to normatively RECOMMEND some kind of feature advertising

I am in favour of B, but I want it to be described informatively with 
examples. (I.e. I think having a SHOULD would be a mistake)

> C) auth-header to normatively REQUIRE some kind of feature advertising
>
> Separately, the unspecified feature advertising or auto-conf should be 
> (choose one or more):
> 1) IMAP Capabilities advertising
> 2) E/SMTP capabilities
> 3) IMAP annotations
> 4) Something else
> 5) Nothing
>
> Note that I've left document organization out of the poll.  If people 
> feel strongly about that they can argue about it.

2) for auto-configuration.

I am still deciding between 1) and 3) on IMAP side. If the information 
can be different for different messages, then a new IMAP capability is a 
wrong way to do this. In this case IMAP per-message annotations are a 
better fit, but I do have some concerns about deployability.

>
> Lisa
>
>
> On Sat, Oct 11, 2008 at 10:13 AM, Alexey Melnikov 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Murray,
>     Some quick comments about your IMAP proposal that uses ANNOTATE.
>
>     >3.  IMAP Server Implementation
>     >
>     >   An [IMAP] server conforming to this specification MUST implement
>     >   [ANNOTATE] and MUST report these annotations to the client if they
>     >   are attached to the message(s) being requested.
>     >
>     >
>     The second MUST: I am not sure what you are trying to say here. If you
>     are saying that the new annotations must be reported whenever the
>     corresponding message body is send (or similar), then that is not how
>     the ANNOTATE extension works.
>      [...]
>
>     >5.1.  Formal Definition
>     >
>     >   The content of the annotation, as defined using [ABNF], is as
>     >   follows:
>     >
>     >      authres = 1*( version ":" authserv-id ":" methodspec
>     >                            ":" propspec )
>     >              ; relays a single unit of authentication results
>     >              ; information
>     >
>     >
>     Are you trying to list multiple authresults here? I think you are
>     missing some delimiter between individual values, e.g. SP.
>
>     _______________________________________________
>     NOTE WELL: This list operates according to
>     http://mipassoc.org/dkim/ietf-list-rules.html
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html 
>

Date: Mon, 13 Oct 2008 12:06:29 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: Straw consensus call on auth-header draft
Cc: Lisa Dusseault <[email-masked]>
Sender: [email-masked]

I read the auth-* drafts.

Lisa Dusseault writes:
> I'd like to do a more explicit consensus call now to nail this down.  
> I've tried to identify the major points of attraction rather than 
> every variant, to see where people are leaning.   Please reply with 
> one of these options, a variant, and explanation if you like:
>
> A)  auth-header to not require any feature advertising or auto-configuration
> B) auth-header to normatively RECOMMEND some kind of feature advertising
> C) auth-header to normatively REQUIRE some kind of feature advertising

I don't like auth-header, but if any, then A.

Comments and stuff.

1. Auth-header tells MTAs to add two (or more?) trace fields. The 
document doesn't specify order, so if it's not clear what was added by 
y below:

   Received: by x ...
   Authentication-Results: (1) ... (dkim stuff)
   Received: by y ...
   Authentication-Results: (2) ... (dkim stuff)
   Authentication-Results: (3) ... (iprev stuff)
   Received: by z ...

Y might have added 1, 2 or 2+3, right? Difficult to handle. Particularly 
if the analysis code wants to detect or handle reordered headers.

This could be fixed by adding a new level of hierarchy between header 
and field. Call it trace-field-group. But we have that for Resent-* and 
IMO that's one of the reasons Resent-* has faded from view.

Another solution would be to write this information inside the Received field.

2. I've noticed that some DKIM implementations like to sign every field 
they see, which might include auth-headers. The auth-header draft says 
to remove old auth-headers, breaking such signatures. That conflict 
needs advice, or at least a security consideration.

3. The reason I don't like advertising is that many people use so very 
complex delivery chains. Transmitting capability advertising from start 
to end is hard. Better to design the stuff so that's not needed.

4. Why isn't there a sieve extension to let people filter mail on this?

Arnt

Date: Sun, 12 Oct 2008 16:44:38 -0700
From: Dave CROCKER <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: Lisa Dusseault <[email-masked]>
CC: Mail-Vet-Discuss <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Straw consensus call on auth-header draft
Sender: [email-masked]

Lisa Dusseault wrote:
> I'd like to do a more explicit consensus call now to nail this down.  
> I've tried to identify the major points of attraction rather than every 
> variant, to see where people are leaning.   Please reply with one of 
> these options, a variant, and explanation if you like:
> 
> A)  auth-header to not require any feature advertising or auto-configuration
> B) auth-header to normatively RECOMMEND some kind of feature advertising
> C) auth-header to normatively REQUIRE some kind of feature advertising

Lisa,

Your alternatives B & C appear to seek normative technical language that refers 
to something that does not exist.  Further, a phrase like "some kind of" makes 
it rather difficult to know whether the 'requirement' is satisfied.

It is generally ill-advised to have a specification make statements about the 
unknown future, which of course means anything in the future.  It seems an even 
poorer choice to make that statement be normative, without specifying the 
details of that future precisely.

So, please clarify how can a technical specification contain normative language 
to cover something that doesn't exist?  More precisely, what does it mean to 
include such language, in terms of actual development or operation? What impact 
does such a statement have on the current specification?  On use of it?

The alternative seems to be to require the current specification to wait until 
there is an approved specification for advertising/configuration that can then, 
in turn, be recommended or required (presumably SHOULD OR MUST, respectively?)

ps.  But to conform to the precise confines of your exercise, I suggest 
Alternative A, since there are many operational environments for which manual 
configuration works just fine.  In those environments, advertising and 
configuration mechanisms add complexity without benefit.

pps. What are examples of similar mechanisms, for application-level advertising 
or auto-configuration, that are already in Internet-scale use?   Knowing the 
answer to this can give some guidance about the likely risk of mandating such a 
mechanism here.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Sun, 12 Oct 2008 14:29:11 -0700
From: "Lisa Dusseault" <[email-masked]>
To: Mail-Vet-Discuss <[email-masked]>, [email-masked], [email-masked]
Subject: Straw consensus call on auth-header draft
Sender: [email-masked]

------=_Part_127225_14626098.1223846951999
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I'd like to do a more explicit consensus call now to nail this down.  I've
tried to identify the major points of attraction rather than every variant,
to see where people are leaning.   Please reply with one of these options, a
variant, and explanation if you like:

A)  auth-header to not require any feature advertising or auto-configuration
B) auth-header to normatively RECOMMEND some kind of feature advertising
C) auth-header to normatively REQUIRE some kind of feature advertising

Separately, the unspecified feature advertising or auto-conf should be
(choose one or more):
1) IMAP Capabilities advertising
2) E/SMTP capabilities
3) IMAP annotations
4) Something else
5) Nothing

Note that I've left document organization out of the poll.  If people feel
strongly about that they can argue about it.

Lisa

On Sat, Oct 11, 2008 at 10:13 AM, Alexey Melnikov <[email-masked]
> wrote:

> Hi Murray,
> Some quick comments about your IMAP proposal that uses ANNOTATE.
>
> >3.  IMAP Server Implementation
> >
> >   An [IMAP] server conforming to this specification MUST implement
> >   [ANNOTATE] and MUST report these annotations to the client if they
> >   are attached to the message(s) being requested.
> >
> >
> The second MUST: I am not sure what you are trying to say here. If you
> are saying that the new annotations must be reported whenever the
> corresponding message body is send (or similar), then that is not how
> the ANNOTATE extension works.
>  [...]
>
> >5.1.  Formal Definition
> >
> >   The content of the annotation, as defined using [ABNF], is as
> >   follows:
> >
> >      authres = 1*( version ":" authserv-id ":" methodspec
> >                            ":" propspec )
> >              ; relays a single unit of authentication results
> >              ; information
> >
> >
> Are you trying to list multiple authresults here? I think you are
> missing some delimiter between individual values, e.g. SP.
>
> _______________________________________________
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rules.html
>

------=_Part_127225_14626098.1223846951999
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div dir="ltr">I&#39;d like to do a more explicit consensus call now to nail this down.&nbsp; I&#39;ve tried to identify the major points of attraction rather than every variant, to see where people are leaning. &nbsp; Please reply with one of these options, a variant, and explanation if you like:<br>
<br>A)&nbsp; auth-header to not require any feature advertising or auto-configuration<br>B) auth-header to normatively RECOMMEND some kind of feature advertising<br>C) auth-header to normatively REQUIRE some kind of feature advertising<br>
<br>Separately, the unspecified feature advertising or auto-conf should be (choose one or more):<br>1) IMAP Capabilities advertising<br>2) E/SMTP capabilities<br>3) IMAP annotations<br>4) Something else<br>5) Nothing<br><br>
Note that I&#39;ve left document organization out of the poll.&nbsp; If people feel strongly about that they can argue about it.<br><br>Lisa<br><br><br><div class="gmail_quote">On Sat, Oct 11, 2008 at 10:13 AM, Alexey Melnikov <span dir="ltr">&lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi Murray,<br>
Some quick comments about your IMAP proposal that uses ANNOTATE.<br>
<br>
&gt;3. &nbsp;IMAP Server Implementation<br>
&gt;<br>
&gt; &nbsp; An [IMAP] server conforming to this specification MUST implement<br>
&gt; &nbsp; [ANNOTATE] and MUST report these annotations to the client if they<br>
&gt; &nbsp; are attached to the message(s) being requested.<br>
&gt;<br>
&gt;<br>
The second MUST: I am not sure what you are trying to say here. If you<br>
are saying that the new annotations must be reported whenever the<br>
corresponding message body is send (or similar), then that is not how<br>
the ANNOTATE extension works.<br>
&nbsp;[...]<br>
<br>
&gt;5.1. &nbsp;Formal Definition<br>
&gt;<br>
&gt; &nbsp; The content of the annotation, as defined using [ABNF], is as<br>
&gt; &nbsp; follows:<br>
&gt;<br>
&gt; &nbsp; &nbsp; &nbsp;authres = 1*( version &quot;:&quot; authserv-id &quot;:&quot; methodspec<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&quot;:&quot; propspec )<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;; relays a single unit of authentication results<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;; information<br>
&gt;<br>
&gt;<br>
Are you trying to list multiple authresults here? I think you are<br>
missing some delimiter between individual values, e.g. SP.<br>
<div><div></div><div class="Wj3C7c"><br>
_______________________________________________<br>
NOTE WELL: This list operates according to <a href="http://mipassoc.org/dkim/ietf-list-rules.html" target="_blank">http://mipassoc.org/dkim/ietf-list-rules.html</a><br>
</div></div></blockquote></div><br></div>

------=_Part_127225_14626098.1223846951999--

Date: Wed, 08 Oct 2008 08:47:03 -0400
From: John C Klensin <[email-masked]>
To: [email-masked]
Subject: FWD: [Technical Errata Reported] RFC5321 (1543)
Sender: [email-masked]

For consideration if and when we open discussion on a full
standard version of 2821ter/ 5321bis

   john

---------- Forwarded Message ----------
Date: Wednesday, 08 October, 2008 05:11 -0700
From: RFC Errata System <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: [Technical Errata Reported] RFC5321 (1543)

The following errata report has been submitted for RFC5321,
"Simple Mail Transfer Protocol".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5321&eid=1543

--------------------------------------
Type: Technical
Reported by: Brett Watson <[email-masked]>

Section: 3.8

Original Text
-------------
   SMTP clients that experience a connection close, reset, or
other    communications failure due to circumstances not under
their control    (in violation of the intent of this
specification but sometimes    unavoidable) SHOULD, to maintain
the robustness of the mail system,    treat the mail transaction
as if a 451 response had been received and    act accordingly.

Corrected Text
--------------
   SMTP clients that experience a connection close, reset, or
other    communications failure due to circumstances not under
their control    (in violation of the intent of this
specification but sometimes    unavoidable) SHOULD, to maintain
the robustness of the mail system,    treat the mail transaction
as if a 421 response had been received and    act accordingly.

Notes
-----
SMTP clients are told to act as though a 451 response
("Requested action aborted: local error in processing") had been
received when context clearly indicates that a 421 response
("Service not available, closing transmission channel") was
intended.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary,
please use "Reply All" to discuss whether it should be verified
or rejected. When a decision is reached, the verifying party
(IESG) can log in to change the status and edit the report, if
necessary. 

--------------------------------------
RFC5321 (draft-klensin-rfc2821bis-11)
--------------------------------------
Title               : Simple Mail Transfer Protocol
Publication Date    : October 2008
Author(s)           : J. Klensin
Category            : DRAFT STANDARD
Source              : IETF - NON WORKING GROUP
Area                : N/A
Stream              : IETF-NWG
Verifying Party     : IESG

---------- End Forwarded Message ----------

From: Sabahattin Gucukoglu <[email-masked]>
To: [email-masked]
Subject: Re: 5321 and 5322 are published!
Date: Tue, 07 Oct 2008 02:33:58 +0100
Sender: [email-masked]

Tony Hansen writes:
> I haven't seen the official notices yet, but RFCs 5321 and 5322 are now
> available in the official RFC repository. I'm sure the announcement will
> be coming out shortly.

I came back from holiday to find them in my mailbox, and was delighted to 
get these documents, all clean and published, after a hiatus of absence from 
this list.  I'm only sorry I couldn't see it through to the end as I'm not 
the fastest there is, but of course the final publication is a great 
successor! 

Thank you and congratulations to all involved!  It's because of you that I 
can look forward to some tedious, but a great deal more unambiguous, 
implementing. :-) 

Cheers,
Sabahattin 

-- 
Sabahattin Gucukoglu <mail<at>sabahattin<dash>gucukoglu<dot>com>
Address harvesters, snag this: [email-masked]
Phone: +44 20 88008915
Mobile: +44 7986 053399
http://sabahattin-gucukoglu.com/

Date: Thu, 02 Oct 2008 12:03:05 -0400
From: Keith Moore <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked], [email-masked], Tony Hansen <[email-masked]>, John C Klensin <[email-masked]>
Subject: Re: 5321 and 5322 are published!
Sender: [email-masked]

let's just assume that it won't be necessary to revise the documents
again to move them to Full Standard.

Keith

Arnt Gulbrandsen wrote:
> John C Klensin writes:
>> Now we go to work on the full standard versions! :-)
> 
> The early bird, blah, 8881/8882?
> 
> Arnt
> 

Date: Thu, 2 Oct 2008 08:38:26 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: 5321 and 5322 are published!
Cc: Tony Hansen <[email-masked]>, John C Klensin <[email-masked]>
Sender: [email-masked]

John C Klensin writes:
> Now we go to work on the full standard versions! :-)

The early bird, blah, 8881/8882?

Arnt

Date: Wed, 01 Oct 2008 19:36:48 -0400
From: John C Klensin <[email-masked]>
To: Tony Hansen <[email-masked]>, [email-masked], ietf-822 mailing list <[email-masked]>
Subject: Re: 5321 and 5322 are published!
Sender: [email-masked]

--On Wednesday, 01 October, 2008 10:47 -0400 Tony Hansen
<[email-masked]> wrote:

> 
> I haven't seen the official notices yet, but RFCs 5321 and
> 5322 are now available in the official RFC repository. I'm
> sure the announcement will be coming out shortly.
> 
> Thanks to both John Klensin and Pete Resnick for their long,
> diligent work in producing these important updates to the mail
> standards.

It would not have been possible without your efforts.

Now we go to work on the full standard versions! :-)

     john

Date: Wed, 01 Oct 2008 08:45:20 -0700
To: [email-masked], ietf-822 mailing list <[email-masked]>
From: SM <[email-masked]>
Subject: Re: 5321 and 5322 are published!
Sender: [email-masked]

At 07:47 01-10-2008, Tony Hansen wrote:
>Thanks to both John Klensin and Pete Resnick for their long, diligent
>work in producing these important updates to the mail standards.

And thanks to Tony Hansen for sheparding the work.

Regards,
-sm 

Date: Wed, 01 Oct 2008 12:05:19 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Tony Hansen <[email-masked]>
CC:  [email-masked], ietf-822 mailing list <[email-masked]>
Subject: Re: 5321 and 5322 are published!
Sender: [email-masked]

Glad to see this finally done!  Good Show.  Congrats to all involved 
making it happen.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Tony Hansen wrote:
> I haven't seen the official notices yet, but RFCs 5321 and 5322 are now
> available in the official RFC repository. I'm sure the announcement will
> be coming out shortly.
> 
> Thanks to both John Klensin and Pete Resnick for their long, diligent
> work in producing these important updates to the mail standards.
> 
> http://tools.ietf.org/html/rfc5321
> http://tools.ietf.org/html/rfc5322
> 
> 	Tony Hansen
> 	[email-masked]
> 
> 
> 

Date: Wed, 01 Oct 2008 10:47:35 -0400
From: Tony Hansen <[email-masked]>
To: [email-masked], ietf-822 mailing list <[email-masked]>
Subject: 5321 and 5322 are published!
Sender: [email-masked]

I haven't seen the official notices yet, but RFCs 5321 and 5322 are now
available in the official RFC repository. I'm sure the announcement will
be coming out shortly.

Thanks to both John Klensin and Pete Resnick for their long, diligent
work in producing these important updates to the mail standards.

http://tools.ietf.org/html/rfc5321
http://tools.ietf.org/html/rfc5322

	Tony Hansen
	[email-masked]