Subject: Re: Mail, not to be confused with spam...
From: Hector Santos <[email-masked]>
To: SMTP Discussion <[email-masked]>
Date: Wed, 30 Nov 2011 14:00:28 -0500
List-Id: <ietf-smtp.imc.org>

Alessandro Vesely wrote:
> There are already 500+ comments on yesterday's post on Slashdot on
> "Europe's Largest IT Company To Ban Internal Email" [1].
> 
> Is it because of spam that people stops using email?
> 
> Someone noted that "the IESG has trouble dealing with anything related
> to spam" [2].  Is the IESG part of the problem?
> 
> 
> [1]
> http://slashdot.org/submission/1864038/europes-largest-it-company-to-ban-internal-email
> [2] http://www.ietf.org/mail-archive/web/domainrep/current/msg00538.html

I think the average 80-90% spam is about right for most systems - its 
a common number often cited.  But thats also one where they really 
don't have system wide policies in place and its more per user.  When 
filters are system wide, users don't see that much spam.

These 'no more email' statements have been around for a long time, its 
also 100% a Business Personal Community thinking that changes from 
time to time.  Sometimes it comes from the idea the "person" just 
discovered something new (old to others) that he thinks is better, 
i.e, an Intranet, or the need to just get everyone to authenticate. 
This is the pattern with support companies, like Microsoft who early 
this year abandoned their public newsgroup servers for their web-based 
Online Forums that requires LiveID authentication, or even using 
something like IMAP.

The conflicts come when they realize they can't control or monitor 
"personal communications" which can only happen when they centralize 
the network and provide their employees Smart Phones - however, in the 
name of saving moving, companies are now beginning to not to subsidize 
it for employees.

One of our largest customers, network manager for a big national 
chain, told me the other day, they are moving to IMAP for the 
employees, mostly because of greater use of Smart Phones, tablets, etc 
and seek 100% online communications. But they are not abandoning email 
simply because they still need to communicate with the outside public 
world.  So email is received filtered and gated IN/OUT into the IMAP 
server.

Overall, this article is just an opinion that they need to do better 
integrated electronic messaging and what they relied on before was too 
expensive for them.   The statement that one just need to "come to me, 
pick up the phone or text me" is typical attitude you see when 
technology becomes too overwhelming - I recall we few of us at 
Westinghouse said the same thing about when X.400 and also Voice 
Messages came to a company phone/mail network. Some felt it was a 
waste of time to go thru that loop.

But as a early Mail Reader/Writer product developer, I always felt it 
was a problem with the UI - the ergonomics, the clutter was always 
there, at any level, that needs too be filtered, consolidated and 
presented to users.   In addition, it was not just the MUA, but how 
the backend gave the MUA this data.  In other words, the 
sorted/filter/folders can be done at the backend and just dumped to 
the MUA for it to filter and sort.

So IMO, its just a matter of getting control of your communications 
methods.

-- 
Sincerely

Hector Santos
http://www.santronics.com
jabber: [email-masked]

From: "Murray S. Kucherawy" <[email-masked]>
To: SMTP Discussion <[email-masked]>
Date: Wed, 30 Nov 2011 09:50:13 -0800
Subject: RE: Mail, not to be confused with spam...
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Wednesday, November 30, 2011 6:30 AM
> To: SMTP Discussion
> Subject: Mail, not to be confused with spam...
> 
> Is it because of spam that people stops using email?

I think if that were the case, email would've been abandoned long ago.  This is just reactionary and sensationalist, just like the articles it cites about email being dead.

> Someone noted that "the IESG has trouble dealing with anything related
> to spam" [2].  Is the IESG part of the problem?

I think you're taking that remark (which I believe was also reactionary, IMO) somewhat out of context here...

Date: Wed, 30 Nov 2011 07:30:10 -0800
To: SMTP Discussion <[email-masked]>
From: SM <[email-masked]>
Subject: Re: Mail, not to be confused with spam...
Sender: [email-masked]

At 06:30 30-11-2011, Alessandro Vesely wrote:
>There are already 500+ comments on yesterday's post on Slashdot on
>"Europe's Largest IT Company To Ban Internal Email" [1].
>
>Is it because of spam that people stops using email?

According to the news article, "only 10 per cent of the 200 
electronic messages his employees receive per day on average turn out 
to be useful".  There wasn't any mention of "internal email" or "spam".

>Someone noted that "the IESG has trouble dealing with anything related
>to spam" [2].  Is the IESG part of the problem?

The initial discussion was about consensus on using DNS as a kind of 
"23-bits whois".

Regards,
-sm

Date: Wed, 30 Nov 2011 15:30:29 +0100
From: Alessandro Vesely <[email-masked]>
To: SMTP Discussion <[email-masked]>
Subject: Mail, not to be confused with spam...
Sender: [email-masked]

There are already 500+ comments on yesterday's post on Slashdot on
"Europe's Largest IT Company To Ban Internal Email" [1].

Is it because of spam that people stops using email?

Someone noted that "the IESG has trouble dealing with anything related
to spam" [2].  Is the IESG part of the problem?

[1]
http://slashdot.org/submission/1864038/europes-largest-it-company-to-ban-internal-email
[2] http://www.ietf.org/mail-archive/web/domainrep/current/msg00538.html

Date: Sun, 20 Nov 2011 09:09:44 +0000
From: Alexey Melnikov <[email-masked]>
To: "Robert A. Rosenberg" <[email-masked]>
CC: SMTP Interest Group <[email-masked]>
Subject: Re: Any interest in rigorous definition for SSL certificate verification in SMTP?
Sender: [email-masked]

On 16/11/2011 02:44, Robert A. Rosenberg wrote:
>
> At 18:14 -0800 on 11/14/2011, Carl S. Gutekunst wrote about Re: Any 
> interest in rigorous definition for SSL certificate:
>
>> Alexey Melnikov wrote:
>> >> ... one of the references for DANE -- RFC 6125 -- seems to be exactly
>>>>  what I was looking for. Unfortunately, it very deliberately codifies
>>>>  the language from RFC 2818 for wildcards, with the established
>>>>  practice for SMTP being a SHOULD NOT.
>>>  Backward compatibility might be a sufficient reason to violate the
>>>  SHOULD NOT.
>> I don't think it's that easy. The issue is with Email virtual hosting
>> implementations that embed the virtual domain name (or any token with
>> dots in it) in the MX record. For example, if you look up the MX record
>> for gutekunst.org, you'll see:
>>
>>     gutekunst.org.        86382    IN    MX    100
>>     gutekunst.org.s8a1.psmtp.com.
>>     gutekunst.org.        86382    IN    MX    200
>>     gutekunst.org.s8a2.psmtp.com.
>>     [snip]
>>
>> Postini's SSL certificate reads:
>>
>>     Subject: C=US, ST=California, L=Mountain View, O=Google Inc, 
>> CN=*.psmtp.com
I would like to know how well this kind of SubjectName DN works for 
email clients. Do you have any information on this?
> Why not use a Certificate with CN=*.*.s8??.psmtp.com (or whatever is 
> needed to map the s8XX section) to solve this issue? - or is more than 
> one wild card level invalid or having more than one certificate with 
> different specificity levels also invalid?
I don't think "?" is allowed. Multiple wildcards are either disallowed 
or discouraged by RFC 5280.

Date: Sun, 20 Nov 2011 09:04:25 +0000
From: Alexey Melnikov <[email-masked]>
To: "Carl S. Gutekunst" <[email-masked]>
CC: "Robert A. Rosenberg" <[email-masked]>, SMTP Interest Group <[email-masked]>
Subject: Re: Any interest in rigorous definition for SSL certificate verification in SMTP?
Sender: [email-masked]

On 16/11/2011 03:04, Carl S. Gutekunst wrote:
> Robert A. Rosenberg wrote:
>> Why not use a Certificate with CN=*.*.s8??.psmtp.com (or whatever is
>> needed to map the s8XX section) to solve this issue? - or is more
>> than one wild card level invalid or having more than one certificate
>> with different specificity levels also invalid?
>
> First thing I thought of. :-)
>
> Alas, RFC 6125 explicitly disallows multiple wildcard characters.
Right. This prohibition came from PKIX WG which worked on RFC 5280. I
can try to find out more about the reason, if you want.
> I want to read through the archives for the WG that published RFC 6125
> so I understand their reasoning better; although they reference RFC
> 4954, I'm still wondering if the WG had any input from anyone in the
> SMTP space. As Tony noted, matching at a single level is incompatible
> with DNS's own wildcard semantics. And the document's writing style
> and voice feels much more like a BCP, not a standards track protocol
> specification.
Yes, the original plan was to have RFC 6125 as a BCP, but there was some
pushback to the idea, thus it is a PS.

From: "Murray S. Kucherawy" <[email-masked]>
To: SMTP Discussion <[email-masked]>
Date: Sun, 20 Nov 2011 11:03:43 -0800
Subject: RE: FW: I-D Action: draft-kucherawy-received-state-00.txt
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Bill McQuillan
> Sent: Sunday, November 20, 2011 1:06 AM
> To: SMTP Discussion
> Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
> 
> While I would *encourage* an MTA to add this sub-field I have to agree
> with Hector that it does not qualify for SHOULD. Other than that, the
> paragraph satisfies my concerns about the meaning of the sub-field.

This document doesn't say that it updates RFC5321 or RFC5322.  It's a standalone document.  Thus, the SHOULD here only applies to MTAs that decide to participate.

Put another way, you can't claim compliance with this document unless you apply the SHOULD, but extant implementations are otherwise completely unaffected.

Date: Sun, 20 Nov 2011 01:05:38 -0800
From: Bill McQuillan <[email-masked]>
To: SMTP Discussion <[email-masked]>
Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
Sender: [email-masked]

On Sat, 2011-11-19, Hector wrote:

> Murray S. Kucherawy wrote:
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On Behalf Of Bill McQuillan
>>> Sent: Saturday, November 19, 2011 11:50 AM
>>> To: SMTP Discussion
>>> Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
>>>
>>> Since the motivation for the "state" sub-field is to help figure out
>>> why gaps in the Received: date-time stamp sequence occured, I think
>>> that knowing for sure whether the named "state" is responsible for the
>>> gap BEFORE the current Received: date-time stamp or AFTER that date-
>>> time stamp is crucial.
>> 
>> I'm guessing my earlier suggestion was inadequate.  So how's this:
>> 
>> 3.  New Trace Clause
>> 
>>    This memo creates a new trace field clause, called "state", which can
>>    be used to indicate the nature of a delay imposed on relaying of a
>>    message toward its recipient(s).  It is followed by a single keyword
>>    that provides that detail.  An MTA or other handling agent that
>>    determines a message is about to enter a state other than normal
>>    queueing of messages for delivery SHOULD generate a trace field
>>    including one of these clauses.  That is, the presence of this clause
>>    on a trace field is an indication of the entry of the message into
>>    that state; a later trace field added would indicate its departure
>>    from that state.

> -1

> That has to be a MAY - not a SHOULD.  There is no requirement to 
> honor, nor technical requirement to follow this whatsoever with a
> SHOULD mandate. There is no interoperability issue to required it,
> there is no *pain* to justify it and the *cost* is high in code 
> change.  Same thing can be done with other headers as it already is
> where required.

While I would *encourage* an MTA to add this sub-field I have to 
agree with Hector that it does not qualify for SHOULD. Other than 
that, the paragraph satisfies my concerns about the meaning of the 
sub-field.

-- 
Bill McQuillan <[email-masked]>

Date: Sun, 20 Nov 2011 02:35:43 -0500
From: Hector <[email-masked]>
To: SMTP Discussion <[email-masked]>
Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
Sender: [email-masked]

Murray S. Kucherawy wrote:
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of Bill McQuillan
>> Sent: Saturday, November 19, 2011 11:50 AM
>> To: SMTP Discussion
>> Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
>>
>> Since the motivation for the "state" sub-field is to help figure out
>> why gaps in the Received: date-time stamp sequence occured, I think
>> that knowing for sure whether the named "state" is responsible for the
>> gap BEFORE the current Received: date-time stamp or AFTER that date-
>> time stamp is crucial.
> 
> I'm guessing my earlier suggestion was inadequate.  So how's this:
> 
> 3.  New Trace Clause
> 
>    This memo creates a new trace field clause, called "state", which can
>    be used to indicate the nature of a delay imposed on relaying of a
>    message toward its recipient(s).  It is followed by a single keyword
>    that provides that detail.  An MTA or other handling agent that
>    determines a message is about to enter a state other than normal
>    queueing of messages for delivery SHOULD generate a trace field
>    including one of these clauses.  That is, the presence of this clause
>    on a trace field is an indication of the entry of the message into
>    that state; a later trace field added would indicate its departure
>    from that state.

-1

That has to be a MAY - not a SHOULD.  There is no requirement to 
honor, nor technical requirement to follow this whatsoever with a 
SHOULD mandate. There is no interoperability issue to required it, 
there is no *pain* to justify it and the *cost* is high in code 
change.  Same thing can be done with other headers as it already is 
where required.

--

From: "Murray S. Kucherawy" <[email-masked]>
To: SMTP Discussion <[email-masked]>
Date: Sat, 19 Nov 2011 22:09:15 -0800
Subject: RE: FW: I-D Action: draft-kucherawy-received-state-00.txt
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Bill McQuillan
> Sent: Saturday, November 19, 2011 11:50 AM
> To: SMTP Discussion
> Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
> 
> Since the motivation for the "state" sub-field is to help figure out
> why gaps in the Received: date-time stamp sequence occured, I think
> that knowing for sure whether the named "state" is responsible for the
> gap BEFORE the current Received: date-time stamp or AFTER that date-
> time stamp is crucial.

I'm guessing my earlier suggestion was inadequate.  So how's this:

3.  New Trace Clause

   This memo creates a new trace field clause, called "state", which can
   be used to indicate the nature of a delay imposed on relaying of a
   message toward its recipient(s).  It is followed by a single keyword
   that provides that detail.  An MTA or other handling agent that
   determines a message is about to enter a state other than normal
   queueing of messages for delivery SHOULD generate a trace field
   including one of these clauses.  That is, the presence of this clause
   on a trace field is an indication of the entry of the message into
   that state; a later trace field added would indicate its departure
   from that state.

...and the rest unchanged.

-MSK

Date: Sat, 19 Nov 2011 11:49:57 -0800
From: Bill McQuillan <[email-masked]>
To: SMTP Discussion <[email-masked]>
Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
Sender: [email-masked]

On Sat, 2011-11-19, Dave CROCKER wrote:

> On 11/19/2011 3:21 PM, Bill McQuillan wrote:
>> What I am trying to get clear is whether the date-time on the
>> Received: field is the instant that the delaying state *started* or
>> the instant that the delaying state *ended*.
>>
>> Perhaps I'm being pedantic,

> You are, but this is a spec and it's kinda expected.

> That said, the Received semantics have always been quite vague about
> distinctions such as entering into vs. departing from.  I think the general
> belief is that it's applied when the message "enters into" but I would /never/
> want to have any system action be based on that assumption.

> Hence the challenge for the current work is whether to stay with that vagueness
> or attempt to impose much more precise sequence definitions than (I believe) has
> previously applied.

> I'm not a fan of false precision and I /am/ a fan of flexibility -- don't
> constrain things unless there's a strong need -- and I don't see the clear and
> immediate benefit of our imposing the precision that you are (implicitly?)
> asking for.

> I think it's fine that you are asking about this; I'm merely expressing a
> preference for coarse-grained precision.[1]

Since the motivation for the "state" sub-field is to help figure
out why gaps in the Received: date-time stamp sequence occured, I
think that knowing for sure whether the named "state" is
responsible for the gap BEFORE the current Received: date-time
stamp or AFTER that date-time stamp is crucial.

In fact, IMHO, without this knowledge, the proposed "state"
sub-field is USELESS.

-- 
Bill McQuillan <[email-masked]>

Date: Sat, 19 Nov 2011 13:57:13 +0000
From: Tony Finch <[email-masked]>
To: [email-masked]
cc: SMTP Discussion <[email-masked]>
Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
Sender: [email-masked]

Dave CROCKER <[email-masked]> wrote:
> On 11/16/2011 7:55 PM, Tony Finch wrote:
> > I think held-for would be a better (more descriptive) keyword than state.
>
> state, or transition, or something that generic, is just that:
> generic.  It pertains to an abstraction.
>
> "held for" says "held" which is a very specific semantic that might not
> apply for some uses of this field.

But the purpose of this field is to explain why a message was deliberately
delayed. The other Received: fields are similarly specific.

There's no need for multiple layers of abstraction and genericity here,
since the Received: field extension mechanism already accommodates that.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Portland, Plymouth: Southeast 5 or 6 decreasing 3 or 4. Moderate or rough in
Portland, rough or very rough in Plymouth. Mainly fair. Moderate or good.

Date: Sat, 19 Nov 2011 16:18:13 +0800
From: Dave CROCKER <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: Tony Finch <[email-masked]>
CC: SMTP Discussion <[email-masked]>
Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
Sender: [email-masked]

On 11/16/2011 7:55 PM, Tony Finch wrote:
> I think held-for would be a better (more descriptive) keyword than state.

state, or transition, or something that generic, is just that:  generic.  It 
pertains to an abstraction.

"held for" says "held" which is a very specific semantic that might not apply 
for some uses of this field.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Sat, 19 Nov 2011 16:14:43 +0800
From: Dave CROCKER <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: Bill McQuillan <[email-masked]>
CC: SMTP Discussion <[email-masked]>
Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
Sender: [email-masked]

On 11/19/2011 3:21 PM, Bill McQuillan wrote:
> What I am trying to get clear is whether the date-time on the
> Received: field is the instant that the delaying state *started* or
> the instant that the delaying state *ended*.
>
> Perhaps I'm being pedantic,

You are, but this is a spec and it's kinda expected.

That said, the Received semantics have always been quite vague about 
distinctions such as entering into vs. departing from.  I think the general 
belief is that it's applied when the message "enters into" but I would /never/ 
want to have any system action be based on that assumption.

Hence the challenge for the current work is whether to stay with that vagueness 
or attempt to impose much more precise sequence definitions than (I believe) has 
previously applied.

I'm not a fan of false precision and I /am/ a fan of flexibility -- don't 
constrain things unless there's a strong need -- and I don't see the clear and 
immediate benefit of our imposing the precision that you are (implicitly?) 
asking for.

I think it's fine that you are asking about this; I'm merely expressing a 
preference for coarse-grained precision.[1]

d/

[1]  The first message system I specified displayed an "incorporating new mail" 
message, with a 3-dot elipses since things tended to be slow.  It then put out 
an additional dot for each new message.  My boss came in one day and asked me to 
remove the elipses.  This seemed odd so I asked why.  he said he wanted to be 
able to count the dots and know how many messages he had gotten.  This was my 
first experience with seeking too much precision at the wrong place...

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Fri, 18 Nov 2011 23:21:29 -0800
From: Bill McQuillan <[email-masked]>
To: SMTP Discussion <[email-masked]>
Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
Sender: [email-masked]

On Thu, 2011-11-17, Murray S. Kucherawy wrote:

>> I guess it would help if it were made clear whether the "state"
>> is being entered into or being exited when the Received: field is
>> added.

> The introduction says:

>    This memo registers a new optional clause that can be used in trace
>    fields to indicate that a message entered such a special processing
>    queue for some period.  This allows analysis to reveal that the cause
>    for a time gap in trace fields was an imposed delay rather than one
>    caused by transient technical difficulties.

> It sounds like if we changed "entered" to "has entered", that would resolve it for you?

What I am trying to get clear is whether the date-time on the 
Received: field is the instant that the delaying state *started* or 
the instant that the delaying state *ended*.

Perhaps I'm being pedantic, but there may be other developers
that are as obtuse as I am. I don't feel that the language:
"message entered such a special processing queue for some
period" is completely clear on that point. 

Perhaps: "message is *beginning* a period of special processing"?

Or: "...*ending*...".

-- 
Bill McQuillan <[email-masked]>

Date: Sat, 19 Nov 2011 13:45:35 +0800
From: Dave CROCKER <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: Bill McQuillan <[email-masked]>
CC: SMTP Discussion <[email-masked]>
Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
Sender: [email-masked]

On 11/16/2011 5:44 PM, Bill McQuillan wrote:
>
>
> The issue I have trouble with is the fact that a Received: field
> is added as an *event* and doesn't correspond to a *state*.
>
> I guess it would help if it were made clear whether the "state"
> is being entered into or being exited when the Received: field is
> added.

In my brain, I keep using the word 'transition' and note that your next 
paragraph did too.  But that's a word that we tend to use about states...

A discussion about the difference between states and events might be fun, if 
rather computer sciency.

Received fields are typically added to mark a change from one 'place' to 
another.  Queue, state, responsible party, i don't care.

Let's decide on the word we like and shift the spec to use it.  It won't change 
the details of the spec, but might make it's nature more intuitive to some readers.

> I note that currently Received: fields are commonly added where
> the From and By values are the same which I presume is used to
> indicate some sort of internal queue transition. I would hope
> that this option would allow me to get a better picture of the
> processing steps involved.

That's exactly the intent.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Fri, 18 Nov 2011 05:21:14 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: SMTP Discussion <[email-masked]>
Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
Sender: [email-masked]

Murray S. Kucherawy wrote:

>> I agree with Bill McQuillan's remarks. If the server knows at the time
>> it receives the message that there is going to be a delay then it can
>> include the new clause in its usual Received: header. Otherwise it'll
>> have to add a new header. Would it be OK to edit the previously-added
>> header?
> 
> I think RFC5321 says clearly that you're not supposed to do that ever.  
> Adding another one is more appropriate.

I feel like chop liver here.

Of course, you can edit it.  It depends on when the message become, oh 
whats a good word, "live" again for the next process, or outside the 
network when you can't touch it again.

Read my initial response. Its a chicken and egg redesign issue - A.K.A 
Code Change.

Half the problem with many proposals is that they are based on one's 
idea of how code is written with their own software.  Not always the case.

Again, depending on your ware or the mode of the mail processor, the 
initial Received may be added immediately.  This memo is written more 
like its geared towards a non-SMTP receiver mail processors, where it 
would be a 2nd header.

For a SMTP receiver MTA that may be doing rejection at the transport 
level, I personally have trouble adding a second Received field for 
the same process. So to me, for our own implementation consideration, 
it would require a delay of the initial Received added by the receiver 
MTA for the purposes of appending the proposed state clause.

What I am saying is this:

Making this a proposed standard carries weight for developers mindful 
of being uptopar standards to consider it.  The conflict is what I 
described in my original response.

I personally think a different header is ideal and its make it easier 
for all implementations. Like Received-SPF, this could be 
Received-State or Received-Status, and I also think it might carry the 
same ID clause from the last or top Received line.  That will allow 
for existing tracking where the receiver SMTP MTA could be recording 
the ID for tracking.  When the initial ID is already strong for 
auditing and tracking in operations, the alternative approach would be 
to delay the initial Received field to add the state clause to it.

-- 
Sincerely

Hector Santos
http://www.santronics.com
jabber: [email-masked]

From: "Murray S. Kucherawy" <[email-masked]>
To: SMTP Discussion <[email-masked]>
Date: Thu, 17 Nov 2011 20:43:29 -0800
Subject: RE: FW: I-D Action: draft-kucherawy-received-state-00.txt
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

> -----Original Message-----
> From: Tony Finch [mailto:[email-masked]] On Behalf Of Tony Finch
> Sent: Wednesday, November 16, 2011 3:55 AM
> To: Murray S. Kucherawy
> Cc: SMTP Discussion
> Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
> 
> I agree with Bill McQuillan's remarks. If the server knows at the time
> it receives the message that there is going to be a delay then it can
> include the new clause in its usual Received: header. Otherwise it'll
> have to add a new header. Would it be OK to edit the previously-added
> header?

I think RFC5321 says clearly that you're not supposed to do that ever.  Adding another one is more appropriate.

> The examples all have syntax errors. Received: sub-fields have a
> prescribed order.

Ah right.  Will fix those.

> I think held-for would be a better (more descriptive) keyword than
> state.

Hmm, maybe.  Anyone else have an opinion on the name?

-MSK

From: "Murray S. Kucherawy" <[email-masked]>
To: SMTP Discussion <[email-masked]>
Date: Thu, 17 Nov 2011 20:36:17 -0800
Subject: RE: FW: I-D Action: draft-kucherawy-received-state-00.txt
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

Hello Bill,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Bill McQuillan
> Sent: Wednesday, November 16, 2011 1:44 AM
> To: SMTP Discussion
> Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
> 
> The issue I have trouble with is the fact that a Received: field is
> added as an *event* and doesn't correspond to a *state*.
> 
> I guess it would help if it were made clear whether the "state"
> is being entered into or being exited when the Received: field is
> added.

The introduction says:

   This memo registers a new optional clause that can be used in trace
   fields to indicate that a message entered such a special processing
   queue for some period.  This allows analysis to reveal that the cause
   for a time gap in trace fields was an imposed delay rather than one
   caused by transient technical difficulties.

It sounds like if we changed "entered" to "has entered", that would resolve it for you?

> I note that currently Received: fields are commonly added where the
> From and By values are the same which I presume is used to indicate
> some sort of internal queue transition. I would hope that this option
> would allow me to get a better picture of the processing steps
> involved.

Sure, this memo doesn't proscribe that at all.

Date: Wed, 16 Nov 2011 11:55:26 +0000
From: Tony Finch <[email-masked]>
To: "Murray S. Kucherawy" <[email-masked]>
cc: SMTP Discussion <[email-masked]>
Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
Sender: [email-masked]

I agree with Bill McQuillan's remarks. If the server knows at the time it
receives the message that there is going to be a delay then it can include
the new clause in its usual Received: header. Otherwise it'll have to add
a new header. Would it be OK to edit the previously-added header?

The examples all have syntax errors. Received: sub-fields have a
prescribed order.

I think held-for would be a better (more descriptive) keyword than state.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
East Sole, Lundy, Fastnet: Southeasterly 4 or 5, veering southwesterly 5 or 6
later, occasionally 7 later except Lundy. Moderate, becoming moderate or
rough. Rain or showers. Moderate or good.

Date: Wed, 16 Nov 2011 01:44:27 -0800
From: Bill McQuillan <[email-masked]>
To: SMTP Discussion <[email-masked]>
Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
Sender: [email-masked]

The issue I have trouble with is the fact that a Received: field 
is added as an *event* and doesn't correspond to a *state*.

I guess it would help if it were made clear whether the "state"
is being entered into or being exited when the Received: field is
added.

I note that currently Received: fields are commonly added where 
the From and By values are the same which I presume is used to 
indicate some sort of internal queue transition. I would hope 
that this option would allow me to get a better picture of the 
processing steps involved.

-- 
Bill McQuillan <[email-masked]>

Date: Wed, 16 Nov 2011 03:42:54 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: "[email-masked]" <[email-masked]>
Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
Sender: [email-masked]

This is a follow up to my post, after thinking about this, the I-D is 
assuming that middle ware that touches the message and happens to add 
another Received: trace line would be appropriate for the proposed 
state clause.  In that case, it would be easier to implement.

I don't think it correct to mix up two different functionalities with 
the MTA hop Received hop stamping, so maybe the I-D should make a 
point of stating that the focus is with additional Received lines 
after the MTA required HOP Received field stamping.  Reading the doc, 
especially with the usage of the terms like "transient" and 
"transition," it would applicable to hop to hop required Received 
trace fields.  It could because the SMTP could be doing all the mail 
filtering.  While we do add more Received lines, there are done with 
different processes as the message is passed off to each. I have 
trouble with the idea the SMTP would add a 2nd receive line so I would 
probably be one that will add the state clause to the initial Received 
line.

-- 
Sincerely

Hector Santos
http://www.santronics.com
jabber: [email-masked]

Murray S. Kucherawy wrote:
> As previously discussed.  Feedback would be quite welcome.
> 
> -MSK
> 
> 
> ------------------------------------------------------------------------
> 
> Subject:
> I-D Action: draft-kucherawy-received-state-00.txt
> From:
> "[email-masked]" <[email-masked]>
> Date:
> Tue, 15 Nov 2011 21:59:27 -0800
> To:
> "[email-masked]" <[email-masked]>
> 
> To:
> "[email-masked]" <[email-masked]>
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : Indicating Email Handling States in Trace Fields
> 	Author(s)       : D. Crocker
>                           Murray S. Kucherawy
> 	Filename        : draft-kucherawy-received-state-00.txt
> 	Pages           : 7
> 	Date            : 2011-11-15
> 
>    This memo registers a trace field clause for use in indicating
>    transitions between handling queues, including enacting inter-host
>    message transitions.  This might include message quarantining,
>    mailing list moderation, timed delivery, or other similar causes.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-kucherawy-received-state-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-kucherawy-received-state-00.txt
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Date: Wed, 16 Nov 2011 03:23:31 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: "[email-masked]" <[email-masked]>
Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
Sender: [email-masked]

Hi,

I read the document.  My comments.

I guess the irony here is that when I got your post, I was actually 
working precisely at the moment, on a new ID clause algorithm because 
of a new change in our receiver model would lose the uniqueness of the 
ID.  :)

Anyway, after reading the memo and its intent, I immediately saw it 
may present a "chicken and egg" design implementation issue for 
receivers models that will record the Received field into a temporary 
spool file and append the data payload into it.  They either have to 
split the capturing of information, do the STATE processing result, 
and then merge it for a final spool file.

For example, for our receiver, when a new mail transaction is started 
(at MAIL), a new file is created:

     hMailFile - holds the final result merging of meta headers and email.

This file would have the ENVELOPE records as the client goes thru MAIL 
to RCPT, etc.  When the DATA is reached before the 354 responses is 
issued:

    1.0 - Received Line is written to hMailFile
    2.0 - Any Received-SPF field is written (from MAIL/RCPT shims) to 
hMailFile

So at this point, it contains:

    ENV-FROM:
    [ENV-AUTH information, if any]
    *(ENV-RCPT):
    ENV-DATA:
    Received: required hop trace line
    Received-SPF: (if any)

BEFORE DATA FILTERING DESIGNS were added:

    3.0 - PayLoad DATA was captured and written into hMailFile

WITH MEW DATA FILTERING DESIGNS (i.e. DKIM validation) were added:

    3.0 - A new file hDataFile is created for receiving the payload DATA
    3.1 - RFC822/2822/5322 enforcement/corrections are done
    3.2 - DATA FILTERS create any META fields (i.e. AUTH-RES) are added
          to hMailFile
    3.3 - hDataFile is rewound and written to hMailFile

To implement this I-D trace State clause, the code change is 
significant.  Off hand, 1.0 and 2.0 would need to be delayed and moved 
to step 3.2 with an ORDER concept depending on what it is.

    3.2  DATA FILTERS create meta fields, if any, for example

            RECEIVED-SPF.META             - already done at MAIL/RCPT
            AUTHENTICATION-RESULT.META    - done at DATA
            RECEIVER-STATE.META           - done at DATA

    3.2.1 Before added the Received field, check for 
RECEIVER-STATE.META and
          add the clause or create/regenerate the Received field
    3.2.2 Add the adjusted Received field to hMailFile
    3.2.3 Add any other meta field to hMailFile

Overall:

For the SMTP receivers models of all kinds will be presented with code 
changes that will require delaying the adding of the initial MTA 
receiver hop trace.  It will depend on how they are doing it, but IMO, 
a different field would probably easier to implement if it can be safe 
to assume a "Received-State" field would follow the MTA Received hop 
stamping and no ordering issues are involved.

It also can't be assumed that models who currently add their own 
headers, X-SPAM stuff, for example, outside the main SMTP processing, 
will be changed in order to coordinate a new chicken and egg design 
issue to order and consolidate the information for the top single MTA 
hop trace line.

-- 
Sincerely

Hector Santos
http://www.santronics.com
jabber: [email-masked]

Murray S. Kucherawy wrote:
> As previously discussed.  Feedback would be quite welcome.
> 
> -MSK
> 
> 
> ------------------------------------------------------------------------
> 
> Subject:
> I-D Action: draft-kucherawy-received-state-00.txt
> From:
> "[email-masked]" <[email-masked]>
> Date:
> Tue, 15 Nov 2011 21:59:27 -0800
> To:
> "[email-masked]" <[email-masked]>
> 
> To:
> "[email-masked]" <[email-masked]>
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : Indicating Email Handling States in Trace Fields
> 	Author(s)       : D. Crocker
>                           Murray S. Kucherawy
> 	Filename        : draft-kucherawy-received-state-00.txt
> 	Pages           : 7
> 	Date            : 2011-11-15
> 
>    This memo registers a trace field clause for use in indicating
>    transitions between handling queues, including enacting inter-host
>    message transitions.  This might include message quarantining,
>    mailing list moderation, timed delivery, or other similar causes.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-kucherawy-received-state-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-kucherawy-received-state-00.txt
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

From: "Murray S. Kucherawy" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 15 Nov 2011 22:00:10 -0800
Subject: FW: I-D Action: draft-kucherawy-received-state-00.txt
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

--_002_F5833273385BB34F99288B3648C4F06F19C6C15088EXCHC2corpclo_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

As previously discussed.  Feedback would be quite welcome.

-MSK

--_002_F5833273385BB34F99288B3648C4F06F19C6C15088EXCHC2corpclo_
Content-Type: message/rfc822

From: "[email-masked]" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sender: "[email-masked]" <[email-masked]>
Date: Tue, 15 Nov 2011 21:59:27 -0800
Subject: I-D Action: draft-kucherawy-received-state-00.txt
Reply-To: "[email-masked]" <[email-masked]>

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.

	Title           : Indicating Email Handling States in Trace Fields
	Author(s)       : D. Crocker
                          Murray S. Kucherawy
	Filename        : draft-kucherawy-received-state-00.txt
	Pages           : 7
	Date            : 2011-11-15

   This memo registers a trace field clause for use in indicating
   transitions between handling queues, including enacting inter-host
   message transitions.  This might include message quarantining,
   mailing list moderation, timed delivery, or other similar causes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kucherawy-received-state-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-kucherawy-received-state-00.txt
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--_002_F5833273385BB34F99288B3648C4F06F19C6C15088EXCHC2corpclo_--

Date: Tue, 15 Nov 2011 19:04:56 -0800
From: "Carl S. Gutekunst" <[email-masked]>
To: "Robert A. Rosenberg" <[email-masked]>
CC: SMTP Interest Group <[email-masked]>
Subject: Re: Any interest in rigorous definition for SSL certificate      verification in SMTP?
Sender: [email-masked]

Robert A. Rosenberg wrote:
> Why not use a Certificate with CN=*.*.s8??.psmtp.com (or whatever is 
> needed to map the s8XX section) to solve this issue? - or is more than 
> one wild card level invalid or having more than one certificate with 
> different specificity levels also invalid?

First thing I thought of. :-)

Alas, RFC 6125 explicitly disallows multiple wildcard characters.

I want to read through the archives for the WG that published RFC 6125 
so I understand their reasoning better; although they reference RFC 
4954, I'm still wondering if the WG had any input from anyone in the 
SMTP space. As Tony noted, matching at a single level is incompatible 
with DNS's own wildcard semantics. And the document's writing style and 
voice feels much more like a BCP, not a standards track protocol 
specification.

<csg>

Date: Tue, 15 Nov 2011 21:44:08 -0500
To:  SMTP Interest Group <[email-masked]>
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: Any interest in rigorous definition for SSL certificate verification in SMTP?
Sender: [email-masked]

At 18:14 -0800 on 11/14/2011, Carl S. Gutekunst wrote about Re: Any 
interest in rigorous definition for SSL certificate:

>Alexey Melnikov wrote:
>  >> ... one of the references for DANE -- RFC 6125 -- seems to be exactly
>>>  what I was looking for. Unfortunately, it very deliberately codifies
>>>  the language from RFC 2818 for wildcards, with the established
>>>  practice for SMTP being a SHOULD NOT.
>>  Backward compatibility might be a sufficient reason to violate the
>>  SHOULD NOT.
>
>I don't think it's that easy. The issue is with Email virtual hosting
>implementations that embed the virtual domain name (or any token with
>dots in it) in the MX record. For example, if you look up the MX record
>for gutekunst.org, you'll see:
>
>     gutekunst.org.        86382    IN    MX    100
>     gutekunst.org.s8a1.psmtp.com.
>     gutekunst.org.        86382    IN    MX    200
>     gutekunst.org.s8a2.psmtp.com.
>     [snip]
>
>Postini's SSL certificate reads:
>
>     Subject: C=US, ST=California, L=Mountain View, O=Google Inc, 
>CN=*.psmtp.com

Why not use a Certificate with CN=*.*.s8??.psmtp.com (or whatever is 
needed to map the s8XX section) to solve this issue? - or is more 
than one wild card level invalid or having more than one certificate 
with different specificity levels also invalid?

Date: Tue, 15 Nov 2011 10:46:11 +0000
From: Tony Finch <[email-masked]>
To: "Carl S. Gutekunst" <[email-masked]>
cc: [email-masked], SMTP Interest Group <[email-masked]>
Subject: Re: Any interest in rigorous definition for SSL certificate verification in SMTP?
Sender: [email-masked]

Carl S. Gutekunst <[email-masked]> wrote:
>
> However, one of the references for DANE -- RFC 6125 -- seems to be exactly
> what I was looking for. Unfortunately, it very deliberately codifies the
> language from RFC 2818 for wildcards, with the established practice for SMTP
> being a SHOULD NOT. I'll have to figure out what to do about that.

That is bizarrely incompatible with DNS wildcard semantics.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Plymouth: Easterly 5 or 6, occasionally 7 in north, veering southeasterly 4 or
5 later. Moderate, occasionally slight later. Mainly fair. Moderate or good.

Date: Tue, 15 Nov 2011 10:30:33 +0000
From: Tony Finch <[email-masked]>
To: "Carl S. Gutekunst" <[email-masked]>
cc: SMTP Interest Group <[email-masked]>
Subject: Re: Any interest in rigorous definition for SSL certificate verification in SMTP?
Sender: [email-masked]

Carl S. Gutekunst <[email-masked]> wrote:
> Tony Finch wrote:
> >
> > For inter-domain SMTP, STARTTLS is hopeless because the majority of MX
> > server certificates cannot be verified, as Carl has previously described
> > on this list http://www.imc.org/ietf-smtp/mail-archive/msg05366.html
>
> I think the situation has improved slightly.

Good :-)

> > There is also the problem of which identity is to be verified. There is no
> > point verifying the MX target host name unless the recipient's DNS zone is
> > signed and the sender's MTAs are doing DNSSEC validation.
>
> I think that latter element as it the heart of the DANE working group? (No, I
> hadn't heard of that WG until Dave pointed it out.)

It's orthogonal. DANE is about replacing and/or augmenting PKIX
certificate verification with DNSSEC-based certificate verification. It
does not address the question of which identity in the protocol being
layered on top of TLS is being authenticated by the certificate.

The answer for SMTP should be the same as the answer for inter-domain
XMPP. I don't know what they have settled on.

> I'm trying to stay simple at this point, and only verify the recipient MX
> server, not the recipient domains. That's already being widely done, but (as I
> noted to Dave) without any clear specification for how to do that in SMTP.

OK, provided the recipient domain has DNSSEC and the sender validates it.

> However, as I go through RFC 6125, it pretty much does seem to be covering
> everything I wanted (other than deprecating the current common practice...
> *SIGH*)

Right, as I said, we need extra signalling to turn on strict verification.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Irish Sea: Southeast 4 or 5, increasing 6 at times. Slight or moderate. Mainly
fair. Moderate or good, occasionally poor.

Date: Tue, 15 Nov 2011 00:10:52 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
CC: SMTP Interest Group <[email-masked]>
Subject: SMTP TLS and CN Domain  Matching
To: [email-masked]
Sender: [email-masked]

Carl S. Gutekunst wrote:
> 
> Alexey Melnikov wrote:
>> Backward compatibility might be a sufficient reason to violate the 
>> SHOULD NOT.
> 
> I don't think it's that easy. The issue is with Email virtual hosting 
> implementations that embed the virtual domain name (or any token with 
> dots in it) in the MX record. For example, if you look up the MX record 
> for gutekunst.org, you'll see:
> 
>    gutekunst.org.        86382    IN    MX    100
>    gutekunst.org.s8a1.psmtp.com.
>    gutekunst.org.        86382    IN    MX    200
>    gutekunst.org.s8a2.psmtp.com.
>    gutekunst.org.        86382    IN    MX    300
>    gutekunst.org.s8b1.psmtp.com.
>    gutekunst.org.        86382    IN    MX    400
>    gutekunst.org.s8b2.psmtp.com.
> 
> Postini's SSL certificate reads:
> 
>    Subject: C=US, ST=California, L=Mountain View, O=Google Inc, CN=*.psmtp.com
> 
> I'm sure they aren't the only ESP that does this; MXLogic for sure, 
> probably CheckFree, possibly FrontBridge.

Very interesting.  I can see this will need to be addressed in our 
server where, if enabled, the certificate is stored based on the CN 
name.  Using our consoled-based SMTP testing client, here is the result:

* connecting to host: gutekunst.org.s8a1.psmtp.com ip: 64.18.7.10:25
S: 220 Postini ESMTP 296 y6_45_0c2 ready.  CA Business and Professions 
Code Section 17538.45 forbids use of th
is system for unsolicited electronic mail advertisements.
C: EHLO main2.addom.santronics.com
S: 250-Postini says hello back
S: 250-STARTTLS
S: 250-8BITMIME
S: 250 HELP
C: STARTTLS
S: 220 Go ahead
** SSL Negotiated session
!! ERROR 123 - saving server's cert to *.psmtp.com.cert
** CERT Common Name : *.psmtp.com
** CERT Organization: Google Inc
** CERT Valid Until : May 25 00:34:28 2012 GMT (Days Left: 191)
** CA Country       : US
** CA Organiziation : Google Inc
** CA Common Name   : Google Internet Authority
!! connection domain : gutekunst.org.s8a1.psmtp.com
!! common name       : *.psmtp.com
!! Certificate CONNECTION DOMAIN and COMMON NAME mismatch! Accept? Yes 
or No?

The error is minor, of course, but I can see your point here.  I did 
another run with a match check of the computer name (rDNS) and got this:

!! computer name     : s8a1.psmtp.com
!! common name       : *.psmtp.com
!! Certificate COMPUTER NAME and COMMON NAME mismatch. Accept? Yes or No?

I wonder how the current MUAs will work here. What have you see with 
the MUAs? like OE, Thunderbird and others?

To answer your question about interest,  here is what I think:

First, I think getting a baseline of who are the beneficiaries, is the 
client mandating correctness or if the server requiring a correct 
matching client certificate?

Second, finding out if wild cards is done in this fashion across the 
board. Is this how its done all CA do it?   I think OCSP should be 
looked at as a possible optional solution or something that would be 
part of the validation suite:

    RFC2560  X.509 IPKI Online Certificate Status Protocol, Updated by 
6277
    RFC6277  Online Certificate Status Protocol Algorithm Agility
    RFC4806  Online Certificate Status Protocol (OCSP) Extensions to IKEv2

My experience here began with a very large national chain customer who 
paid the bucks for a wild card certificate and unbeknownst to them, 
there was some SSL purchasing mixup issue that the CA revoked had 
revoked it. But that didn't show up with the browsers (no SSL error) 
until some users with updated browsers which now had OCSP enabled 
began to show the insecure warning error "do you wish to continue" 
pages.  That provided the clue that there was an SSL purchasing mix up 
with the group of domains they wanted signed by the CA. Turning off 
the OSCP at the browser got by it, but of course, thats not realistic 
to presume to be off with new browsers now enabling it.

and third, work out the "algorithm" for the matching options of the 
CN, possibly by first seeing the current practice by MUAs where there 
is an interactive HUMAN involved to help with the decisions.   The end 
goal here is to see is automation is possible with two MTAs.

Keep in mind, at least for us where we have it setup on a per remote 
host setup where specific MTA connection details are provided for a 
target email domain or host, they could bypass the MX host.  For 
example, I did the same test run for your domain:

* connecting to host: mail.gutekunst.org.s8a1.psmtp.com ip: 
128.177.28.115:25
S: 220 alameth.user.openhosting.com ESMTP Postfix (2.4.1)
C: EHLO main2.addom.santronics.com
S: 250-alameth.user.openhosting.com
S: 250-PIPELINING
S: 250-SIZE 10240000
S: 250-VRFY
S: 250-ETRN
S: 250-STARTTLS
S: 250-ENHANCEDSTATUSCODES
S: 250-8BITMIME
S: 250 DSN
C: STARTTLS
S: 220 2.0.0 Ready to start TLS
** SSL Negotiated session
** CERT Common Name : mail.gutekunst.org
** CERT Organization:
** CERT Valid Until : Nov 10 22:35:42 2012 GMT (Days Left: 361)
** CA Country       : IL
** CA Organiziation : StartCom Ltd.
** CA Common Name   : StartCom Class 1 Primary Intermediate Server CA
!! computer name     : 128-177-28-115.ip.openhosting.com
!! common name       : mail.gutekunst.org
!! Certificate COMPUTER NAME and COMMON NAME mismatch. Accept? Yes or 
No? n

So it passed the connection name test, and it would pass the computer 
name test if I disable the rDNS matching check.

Point here is I believe that when it comes to prearranged remote host 
routing, the authentication and TLS details may be already worked out 
for validation.

-- 
Sincerely

Hector Santos
http://www.santronics.com
jabber: [email-masked]

From: "Murray S. Kucherawy" <[email-masked]>
To: "[email-masked]" <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Date: Mon, 14 Nov 2011 19:04:37 -0800
Subject: RE: [apps-discuss] Feedback on draft-moonesamy-smtp-ipv6-00
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of S Moonesamy
> Sent: Monday, November 14, 2011 2:35 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [apps-discuss] Feedback on draft-moonesamy-smtp-ipv6-00
> 
> The change from RFC 3974 is:
> 
>   - Removal of the Basic DNS Resource Record Definitions for Mail
> Routing section
> 
>   - Removal of the SMTP Sender Algorithm in a Dual-Stack Environment
> section

Why were these removed?  They seemed useful for illustration in RFC3974.

>   - Removal of the Operational Experience and open issues sections.

Replacing this with more current operational experience might be better than removing it outright.

Also, I wonder if the v6ops "Happy Eyeballs" work might be an interesting reference here.

> Please note that the algorithm has already been used in several
> existing implementations.

Excellent.

RFC5321 talked about aspects of RFC3974 that were in conflict with what RFC5321 says.  Have those been resolved in your draft?  (Alas, I can't tell after a cursory read what those might've been.  Maybe it's simply the thing John Levine just pointed out in another message.)

It's worth pointing out the document state change as well (which I support).

-MSK

Date: Mon, 14 Nov 2011 18:14:56 -0800
From: "Carl S. Gutekunst" <[email-masked]>
To: Alexey Melnikov <[email-masked]>
CC: SMTP Interest Group <[email-masked]>
Subject: Re: Any interest in rigorous definition for SSL certificate      verification in SMTP?
Sender: [email-masked]

Alexey Melnikov wrote:
>> ... one of the references for DANE -- RFC 6125 -- seems to be exactly 
>> what I was looking for. Unfortunately, it very deliberately codifies 
>> the language from RFC 2818 for wildcards, with the established 
>> practice for SMTP being a SHOULD NOT.
> Backward compatibility might be a sufficient reason to violate the 
> SHOULD NOT.

I don't think it's that easy. The issue is with Email virtual hosting 
implementations that embed the virtual domain name (or any token with 
dots in it) in the MX record. For example, if you look up the MX record 
for gutekunst.org, you'll see:

    gutekunst.org.        86382    IN    MX    100
    gutekunst.org.s8a1.psmtp.com.
    gutekunst.org.        86382    IN    MX    200
    gutekunst.org.s8a2.psmtp.com.
    gutekunst.org.        86382    IN    MX    300
    gutekunst.org.s8b1.psmtp.com.
    gutekunst.org.        86382    IN    MX    400
    gutekunst.org.s8b2.psmtp.com.

Postini's SSL certificate reads:

    Subject: C=US, ST=California, L=Mountain View, O=Google Inc, CN=*.psmtp.com

I'm sure they aren't the only ESP that does this; MXLogic for sure, 
probably CheckFree, possibly FrontBridge.

<csg>

Date: Mon, 14 Nov 2011 20:45:09 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: SMTP Interest Group <[email-masked]>
Subject: Re: Any interest in rigorous definition for SSL certificate verification in SMTP?
Sender: [email-masked]

Carl S. Gutekunst wrote:
> 
> RFC 3207 punts on the issue of certificate verification. Is there any 
> interest in a rigorous specification for certificate verification in 
> SMTP/STARTTLS ? Is this the appropriate WG for such a discussion?

Our SMTP client has options to check the server certificate on a per 
domain basis. So where it is mandated that it be non-expired and 
common names match the connection name and/or the rDNS is local policy.

But one thing I was thinking about supporting is OCSP (Online 
Certificate Status Protocol) RFC2560 as the another way to check for 
the vendor revocation and also deal with the wild card issues.

The major browsers do OCSP and at first it was OFF by default. But 
within the last year or so of updates, they are now ON by default, 
specifically starting with CHROME and FIREFOX 3.0.

I think this may be doable today if the SMTP client wanted to push the 
check that far.

-- 
Sincerely

Hector Santos
http://www.santronics.com
jabber: [email-masked]

Date: Tue, 15 Nov 2011 01:28:39 +0000
From: Alexey Melnikov <[email-masked]>
To: "Carl S. Gutekunst" <[email-masked]>
CC: [email-masked], SMTP Interest Group <[email-masked]>
Subject: Re: Any interest in rigorous definition for SSL certificate verification in SMTP?
Sender: [email-masked]

On 14/11/2011 22:40, Carl S. Gutekunst wrote:
> Dave CROCKER wrote:
>> On 11/15/2011 4:10 AM, Carl S. Gutekunst wrote:
>>> The purpose is to define a standard way for an SMTP sender (client) 
>>> to determine
>>> that the SMTP receiver that it's talking to is the one it thinks 
>>> it's talking
>>> to. The mechanism would detect man-in-the-middle attacks and connection
>>> hijacking at either the routing or DNS level.
>>
>> Isn't that exactly the problem that the DANE working group attacking. 
>
> DANE is looking at DNSSEC extensions, which may well be what Tony was 
> looking for.
>
> However, one of the references for DANE -- RFC 6125 -- seems to be 
> exactly what I was looking for. Unfortunately, it very deliberately 
> codifies the language from RFC 2818 for wildcards, with the 
> established practice for SMTP being a SHOULD NOT.
Backward compatibility might be a sufficient reason to violate the 
SHOULD NOT.
> I'll have to figure out what to do about that. (That said, I can count 
> the number of MTA implementations that support wildcard domains in 
> certificates without taking off my shoes.)
>
> Thanks!
>
> <csg>

Date: Tue, 15 Nov 2011 01:27:03 +0000
From: Alexey Melnikov <[email-masked]>
To: "Carl S. Gutekunst" <[email-masked]>
CC: [email-masked], SMTP Interest Group <[email-masked]>
Subject: Re: Any interest in rigorous definition for SSL certificate verification in SMTP?
Sender: [email-masked]

On 14/11/2011 20:10, Carl S. Gutekunst wrote:
> Dave CROCKER wrote:
>> On 11/14/2011 3:57 PM, Carl S. Gutekunst wrote:
>>>
>>> RFC 3207 punts on the issue of certificate verification. Is there 
>>> any interest
>>> in a rigorous specification for certificate verification in 
>>> SMTP/STARTTLS ? Is
>>> this the appropriate WG for such a discussion?
>> what's the purpose?  what problem is this intended to solve?  how 
>> prevalent is that problem now?
> The purpose is to define a standard way for an SMTP sender (client) to 
> determine that the SMTP receiver that it's talking to is the one it 
> thinks it's talking to. The mechanism would detect man-in-the-middle 
> attacks and connection hijacking at either the routing or DNS level.
>
> I agree completely with the language in RFC 3207 that says "The 
> decision of whether or not to believe the authenticity of the other 
> party in a TLS negotiation is a local matter." It has to be that way, 
> if only because of the highly inconsistent deployment of PKI. But I 
> think there should be language that says SMTP senders MAY use TLS 
> certificate verification, and if they do, they MUST do it in the 
> specified way.
I agree that RFC 3207 is underspecified or outdated (depending on how 
one looks at this) in this area. I already have a draft (based on RFC 
6125) that tries to address this problem to some extend: 
draft-melnikov-email-tls-certs-00.txt.

If you would like to help out with the above, please contact me off-list.
> There's obviously common practice; many of the MTAs that support TLS 
> also support some form of server certificate verification. However, 
> the behavior is all inferred from the TLS specifications for other 
> protocols, e.g., RFC 2818 section 3.1 for HTTP, or RFC 3501 section 
> 11.1 for IMAP. As far as I know, the closest to an SMTP TLS spec is 
> RFC 4954 Section 14, but that's only for SMTP AUTH. And I think the 
> (almost identical) language in RFC 2595, 3501, and 4954 is ambiguous 
> and incomplete.
Right. This is pretty much what motivated creation of RFC 6125.
> What got me (re)started on this was an argument over interpretation of 
> wildcard names. RFC 2818 (for HTTP) is clear that a wildcard matches 
> the current level only; but it is common practice among Email service 
> providers to match everything to the left. That is, given a dnsName in 
> the certificate of "*.a.com," it's clear in RFC 2818 that 
> "bar.foo.a.com" would not match. But the existing Email deployments 
> assume that it does, and I've heard folks argue that is what is 
> implied in RFC 2595.
>
> <csg>

Date: Mon, 14 Nov 2011 15:18:03 -0800
From: "Carl S. Gutekunst" <[email-masked]>
To: SM <[email-masked]>
CC: SMTP Interest Group <[email-masked]>
Subject: Re: Any interest in rigorous definition for SSL certificate  verification in SMTP?
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------070801090501090305010305
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

SM wrote:
>
> At 01:34 AM 11/14/2011, Dave CROCKER wrote:
>> what's the purpose?  what problem is this intended to solve?  how 
>> prevalent is that problem now?
>
> There was a discussion about this subject a year ago ( it may be 
> related to 
> http://www.ietf.org/mail-archive/web/yam/current/msg00420.html ).

That's client verification, a worthy topic for sure, and one I'm going 
to be deep-diving into soon. But different from the problem I was 
thinking of at the moment.

> I vaguely recall some discussion about SSL certificate verification.  
> See RFC 6125 as well.

Right, until proven otherwise, RFC 6125 was what I was looking for.

    % ls /srv/docs/internet/rfc6???.txt
    ls: No match.

Doh.

<csg>

--------------070801090501090305010305
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
SM wrote:
<blockquote class="cite"
 id="mid_6_2_5_6_2_20111114063242_08cad4c0_resistor_net"
 cite="mid:[email-masked]" type="cite"><br>
At 01:34 AM 11/14/2011, Dave CROCKER wrote:
  <br>
  <blockquote class="cite" id="StationeryCiteGenerated_1" type="cite">what's
the purpose?&nbsp; what problem is this intended to solve?&nbsp; how prevalent is
that problem now?
    <br>
  </blockquote>
  <br>
There was a discussion about this subject a year ago ( it may be
related to
<a class="moz-txt-link-freetext" href="http://www.ietf.org/mail-archive/web/yam/current/msg00420.html">http://www.ietf.org/mail-archive/web/yam/current/msg00420.html</a> ). <br>
</blockquote>
<br>
That's client verification, a worthy topic for sure, and one I'm going
to be deep-diving into soon. But different from the problem I was
thinking of at the moment.<br>
<br>
<blockquote class="cite"
 id="mid_6_2_5_6_2_20111114063242_08cad4c0_resistor_net"
 cite="mid:[email-masked]" type="cite">
I vaguely recall some discussion about SSL certificate verification.&nbsp;
See RFC 6125 as well.
  <br>
</blockquote>
<br>
Right, until proven otherwise, RFC 6125 was what I was looking for.<br>
<blockquote>% ls /srv/docs/internet/rfc6???.txt<br>
ls: No match.<br>
</blockquote>
Doh.<br>
<br>
&lt;csg&gt;<br>
</body>
</html>

--------------070801090501090305010305--

From: Frank Ellermann <[email-masked]>
Date: Tue, 15 Nov 2011 00:11:56 +0100
Subject: Re: [apps-discuss] Feedback on draft-moonesamy-smtp-ipv6-00
To: S Moonesamy <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

On 14 November 2011 23:35, S Moonesamy wrote:

> I would appreciate some feedback on draft-moonesamy-smtp-ipv6-00.

Hi, apparently you've removed the MX examples; including the hint
that a primary IPvX-only MX cannot be combined with a secondary
IPvY-only (X != Y).  It is kind of obvious, but it helped me to
understand what RFC 3974 was about.

Maybe it could make sense to discuss the IPv6-only behaviour if
IPv4 addresses are reachable by some mapping mechanism.  It's not
exactly "on topic" for your draft, but I'd be interested to know
how that's supposed to work in 2011 (the last time I tried to get
the idea was for RFC 4408, but there are many new IPv6 RFCs...)

-Frank

To: Tony Finch <[email-masked]>
Cc: "Carl S. Gutekunst" <[email-masked]>, SMTP Interest Group <[email-masked]>
From: Mark Andrews <[email-masked]>
Subject: Re: Any interest in rigorous definition for SSL certificate verification in SMTP?
Date: Tue, 15 Nov 2011 10:11:01 +1100
Sender: [email-masked]

In message <[email-masked]>, Tony Finch writes:
> 
> Carl S. Gutekunst <[email-masked]> wrote:
> >
> > RFC 3207 punts on the issue of certificate verification. Is there any interest
> > in a rigorous specification for certificate verification in SMTP/STARTTLS ? Is
> > this the appropriate WG for such a discussion?
> 
> I am interested.
> 
> STARTTLS as it is currently used is fine for message submission, but it
> could do with a more precise specification.
> 
> For inter-domain SMTP, STARTTLS is hopeless because the majority of MX
> server certificates cannot be verified, as Carl has previously described
> on this list http://www.imc.org/ietf-smtp/mail-archive/msg05366.html
> 
> So we need something that allows MXs to say explicitly, "please strictly
> verify my certificate". For this to be any use it needs downgrade
> prevention, which probably requires a declaration in the DNS protected
> with DNSSEC.
> 
> There is also the problem of which identity is to be verified. There is no
> point verifying the MX target host name unless the recipient's DNS zone is
> signed and the sender's MTAs are doing DNSSEC validation.
> 
> If you prefer to avoid requiring DNSSEC, you must verify the recipient
> mail domain. In this case you have a much greater need for some kind of
> support for server certificate selection (either SNI in TLS or perhaps a
> new ESMTP TLS service extension), and you have to decide how to deal with
> messages that have recipients at multiple different domains on the same MX
> target server. This is all rather complicated and messy.

We have RFC's which say that the target of the MX record should be
the canonical name of the server.  We have RFC's which allow us to
validate as secure MX records (implicit and explict).  DANE is
looking at signalling that secure services for a port exist.  We
have everything in these RFCs / drafts to do STARTTLS in general
rather than just submission and avoid downgrade attacks.

With MX

example.net MX 0 mail.example.net
_25._tcp.mail.example.net TLSA
mail.example.net A
mail.example.net AAAA

Wildcard MX

*.example.net MX 0 mail.example.net
_25._tcp.mail.example.net TLSA
mail.example.net A
mail.example.net AAAA

Without MX

example.net A
example.net AAAA
_25._tcp.example.net TLSA
(Implict MX "example.net MX 0 example.net")

Without MX and with CNAME

example.net CNAME example.com
example.com A
example.com AAAA
_25._tcp.example.com TLSA
(Implict MX "example.net MX 0 example.com")

All the zones involved above are DNSSEC signed with secure delegations.

> Tony.
> -- 
> f.anthony.n.finch  <[email-masked]>  http://dotat.at/
> Lundy, Fastnet, Irish Sea: East or southeast 5 to 7, decreasing 4 at times.
> Moderate or rough, occasionally very rough in Fastnet. Fair. Moderate or good,
> occasionally poor later.
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

Date: Mon, 14 Nov 2011 15:10:37 -0800
From: "Carl S. Gutekunst" <[email-masked]>
To: Tony Finch <[email-masked]>
CC: SMTP Interest Group <[email-masked]>
Subject: Re: Any interest in rigorous definition for SSL certificate verification in SMTP?
Sender: [email-masked]

Tony Finch wrote:
> STARTTLS as it is currently used is fine for message submission, but it
> could do with a more precise specification.
>
> For inter-domain SMTP, STARTTLS is hopeless because the majority of MX
> server certificates cannot be verified, as Carl has previously described
> on this list http://www.imc.org/ietf-smtp/mail-archive/msg05366.html
>   

I think the situation has improved slightly. All of the Fortune 500 
domains I'd identified in 2008 as having unverifiable certificates have 
since been fixed. I'm also seeing more customer interest in more robust 
TLS deployments, particular from the Federal Government.

> So we need something that allows MXs to say explicitly, "please strictly
> verify my certificate". For this to be any use it needs downgrade
> prevention, which probably requires a declaration in the DNS protected
> with DNSSEC.
>
> There is also the problem of which identity is to be verified. There is no
> point verifying the MX target host name unless the recipient's DNS zone is
> signed and the sender's MTAs are doing DNSSEC validation.
>   

I think that latter element as it the heart of the DANE working group? 
(No, I hadn't heard of that WG until Dave pointed it out.)

> If you prefer to avoid requiring DNSSEC, you must verify the recipient
> mail domain. In this case you have a much greater need for some kind of
> support for server certificate selection (either SNI in TLS or perhaps a
> new ESMTP TLS service extension), and you have to decide how to deal with
> messages that have recipients at multiple different domains on the same MX
> target server. This is all rather complicated and messy.

I'm trying to stay simple at this point, and only verify the recipient 
MX server, not the recipient domains. That's already being widely done, 
but (as I noted to Dave) without any clear specification for how to do 
that in SMTP.  However, as I go through RFC 6125, it pretty much does 
seem to be covering everything I wanted (other than deprecating the 
current common practice... *SIGH*)

<csg>

Date: Mon, 14 Nov 2011 14:40:50 -0800
From: "Carl S. Gutekunst" <[email-masked]>
To: [email-masked]
CC: SMTP Interest Group <[email-masked]>
Subject: Re: Any interest in rigorous definition for SSL certificate verification in SMTP?
Sender: [email-masked]

Dave CROCKER wrote:
> On 11/15/2011 4:10 AM, Carl S. Gutekunst wrote:
>> The purpose is to define a standard way for an SMTP sender (client) 
>> to determine
>> that the SMTP receiver that it's talking to is the one it thinks it's 
>> talking
>> to. The mechanism would detect man-in-the-middle attacks and connection
>> hijacking at either the routing or DNS level.
>
> Isn't that exactly the problem that the DANE working group attacking. 

DANE is looking at DNSSEC extensions, which may well be what Tony was 
looking for.

However, one of the references for DANE -- RFC 6125 -- seems to be 
exactly what I was looking for. Unfortunately, it very deliberately 
codifies the language from RFC 2818 for wildcards, with the established 
practice for SMTP being a SHOULD NOT. I'll have to figure out what to do 
about that. (That said, I can count the number of MTA implementations 
that support wildcard domains in certificates without taking off my shoes.)

Thanks!

<csg>

Date: Tue, 15 Nov 2011 06:13:34 +0800
From: Dave CROCKER <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: "Carl S. Gutekunst" <[email-masked]>
CC: SMTP Interest Group <[email-masked]>
Subject: Re: Any interest in rigorous definition for SSL certificate verification in SMTP?
Sender: [email-masked]

On 11/15/2011 4:10 AM, Carl S. Gutekunst wrote:
> Dave CROCKER wrote:
>> On 11/14/2011 3:57 PM, Carl S. Gutekunst wrote:
>>>
>>> RFC 3207 punts on the issue of certificate verification. Is there any interest
>>> in a rigorous specification for certificate verification in SMTP/STARTTLS ? Is
>>> this the appropriate WG for such a discussion?
>>
>> what's the purpose? what problem is this intended to solve? how prevalent is
>> that problem now?
>
> The purpose is to define a standard way for an SMTP sender (client) to determine
> that the SMTP receiver that it's talking to is the one it thinks it's talking
> to. The mechanism would detect man-in-the-middle attacks and connection
> hijacking at either the routing or DNS level.

Isn't that exactly the problem that the DANE working group attacking.

If not, how is it different?  Can this issue be extended from their work?

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Mon, 14 Nov 2011 12:10:56 -0800
From: "Carl S. Gutekunst" <[email-masked]>
To: [email-masked]
CC: SMTP Interest Group <[email-masked]>
Subject: Re: Any interest in rigorous definition for SSL certificate verification in SMTP?
Sender: [email-masked]

Dave CROCKER wrote:
> On 11/14/2011 3:57 PM, Carl S. Gutekunst wrote:
>>
>> RFC 3207 punts on the issue of certificate verification. Is there any 
>> interest
>> in a rigorous specification for certificate verification in 
>> SMTP/STARTTLS ? Is
>> this the appropriate WG for such a discussion?
>
>
> what's the purpose?  what problem is this intended to solve?  how 
> prevalent is that problem now?

The purpose is to define a standard way for an SMTP sender (client) to 
determine that the SMTP receiver that it's talking to is the one it 
thinks it's talking to. The mechanism would detect man-in-the-middle 
attacks and connection hijacking at either the routing or DNS level.

I agree completely with the language in RFC 3207 that says "The decision 
of whether or not to believe the authenticity of the other party in a 
TLS negotiation is a local matter." It has to be that way, if only 
because of the highly inconsistent deployment of PKI. But I think there 
should be language that says SMTP senders MAY use TLS certificate 
verification, and if they do, they MUST do it in the specified way.

There's obviously common practice; many of the MTAs that support TLS 
also support some form of server certificate verification. However, the 
behavior is all inferred from the TLS specifications for other 
protocols, e.g., RFC 2818 section 3.1 for HTTP, or RFC 3501 section 11.1 
for IMAP. As far as I know, the closest to an SMTP TLS spec is RFC 4954 
Section 14, but that's only for SMTP AUTH. And I think the (almost 
identical) language in RFC 2595, 3501, and 4954 is ambiguous and incomplete.

What got me (re)started on this was an argument over interpretation of 
wildcard names. RFC 2818 (for HTTP) is clear that a wildcard matches the 
current level only; but it is common practice among Email service 
providers to match everything to the left. That is, given a dnsName in 
the certificate of "*.a.com," it's clear in RFC 2818 that 
"bar.foo.a.com" would not match. But the existing Email deployments 
assume that it does, and I've heard folks argue that is what is implied 
in RFC 2595.

<csg>

Date: Mon, 14 Nov 2011 06:38:12 -0800
To: SMTP Interest Group <[email-masked]>
From: SM <[email-masked]>
Subject: Re: Any interest in rigorous definition for SSL certificate verification in SMTP?
Sender: [email-masked]

At 01:34 AM 11/14/2011, Dave CROCKER wrote:
>what's the purpose?  what problem is this intended to solve?  how 
>prevalent is that problem now?

There was a discussion about this subject a year ago ( it may be 
related to 
http://www.ietf.org/mail-archive/web/yam/current/msg00420.html ).  I 
vaguely recall some discussion about SSL certificate 
verification.  See RFC 6125 as well.

Regards,
-sm 

Date: Mon, 14 Nov 2011 13:22:46 +0000
From: Tony Finch <[email-masked]>
To: "Carl S. Gutekunst" <[email-masked]>
cc: SMTP Interest Group <[email-masked]>
Subject: Re: Any interest in rigorous definition for SSL certificate verification in SMTP?
Sender: [email-masked]

Carl S. Gutekunst <[email-masked]> wrote:
>
> RFC 3207 punts on the issue of certificate verification. Is there any interest
> in a rigorous specification for certificate verification in SMTP/STARTTLS ? Is
> this the appropriate WG for such a discussion?

I am interested.

STARTTLS as it is currently used is fine for message submission, but it
could do with a more precise specification.

For inter-domain SMTP, STARTTLS is hopeless because the majority of MX
server certificates cannot be verified, as Carl has previously described
on this list http://www.imc.org/ietf-smtp/mail-archive/msg05366.html

So we need something that allows MXs to say explicitly, "please strictly
verify my certificate". For this to be any use it needs downgrade
prevention, which probably requires a declaration in the DNS protected
with DNSSEC.

There is also the problem of which identity is to be verified. There is no
point verifying the MX target host name unless the recipient's DNS zone is
signed and the sender's MTAs are doing DNSSEC validation.

If you prefer to avoid requiring DNSSEC, you must verify the recipient
mail domain. In this case you have a much greater need for some kind of
support for server certificate selection (either SNI in TLS or perhaps a
new ESMTP TLS service extension), and you have to decide how to deal with
messages that have recipients at multiple different domains on the same MX
target server. This is all rather complicated and messy.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Lundy, Fastnet, Irish Sea: East or southeast 5 to 7, decreasing 4 at times.
Moderate or rough, occasionally very rough in Fastnet. Fair. Moderate or good,
occasionally poor later.

Date: Mon, 14 Nov 2011 17:34:21 +0800
From: Dave CROCKER <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: "Carl S. Gutekunst" <[email-masked]>
CC: SMTP Interest Group <[email-masked]>
Subject: Re: Any interest in rigorous definition for SSL certificate verification in SMTP?
Sender: [email-masked]

On 11/14/2011 3:57 PM, Carl S. Gutekunst wrote:
>
> RFC 3207 punts on the issue of certificate verification. Is there any interest
> in a rigorous specification for certificate verification in SMTP/STARTTLS ? Is
> this the appropriate WG for such a discussion?

what's the purpose?  what problem is this intended to solve?  how prevalent is 
that problem now?

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Subject: Re: Any interest in rigorous definition for SSL certificate verification in SMTP?
From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 14 Nov 2011 09:23:39 +0100
To: "Carl S. Gutekunst" <[email-masked]>, SMTP Interest Group <[email-masked]>
Sender: [email-masked]

Makes me wonder: What's the current (informal) status of the certificate-from-dns drafts?

Viele Grüße
Arnt Gulbrandsen

Date: Sun, 13 Nov 2011 23:57:31 -0800
From: "Carl S. Gutekunst" <[email-masked]>
To: SMTP Interest Group <[email-masked]>
Subject: Any interest in rigorous definition for SSL certificate verification in SMTP?
Sender: [email-masked]

RFC 3207 punts on the issue of certificate verification. Is there any 
interest in a rigorous specification for certificate verification in 
SMTP/STARTTLS ? Is this the appropriate WG for such a discussion?

<csg>

Date: Mon, 7 Nov 2011 13:20:52 -0500
Subject: Re: 4yz Temporary Rejections is part of the SMTP Protocol
From: Jeff Macdonald <[email-masked]>
To: [email-masked]
Sender: [email-masked]

On Thu, Oct 27, 2011 at 6:12 PM, John C Klensin <[email-masked]> wrote:

>
> I'm not suggesting it, but, to the extent to which SMTP
> extension are involved here (rather than a description of how to
> use the base protocol in a particular way and improve
> interoperability if it is used that way), one could even thinks
> about a new series of reply codes for traffic management of
> various types (6yx? �9yz?) rather than trying to do tricky
> things with 4yz.
>

+1

-- 
Jeff Macdonald
Ayer, MA

Date: Sat, 5 Nov 2011 20:28:04 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: SMTP Kerberos Considerations
Sender: [email-masked]

--============_-891583188==_mr============
Content-Type: multipart/alternative; boundary="============_-891583188==_ma============"

--============_-891583188==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 03:42 -0400 on 11/05/2011, Hector Santos wrote about Re: SMTP 
Kerberos Considerations:

>Robert A. Rosenberg wrote:
>>
>>At 17:54 -0400 on 11/02/2011, Hector Santos wrote about SMTP 
>>Kerberos Considerations:
>>
>>>I don't know enough about how IPv6 are assigned today.
>>
>>The idea is that the user gets a IPv6/64 Network address from their 
>>Connection Provider like they currently get a IPv4/32.
>
>So you can get one or a bank of addresses?  Depending on the 
>business package?  Note, we have a class C address.

If you are a home user you would get a single IPv6/64 Network 
address. That address will allow you to set up your own LAN. There is 
no need for your connectivity provider to supply you more than one 
address prefix since all of your devices are hosts under that prefix. 
If you currently have a IP4/24 (Class C Network address) all of your 
252 devices would still each get their own routable address from your 
router. A company as opposed to a single user might get a IPv6/56 or 
IPv6/48 (see http://en.wikipedia.org/wiki/IPv6_subnetting_reference).
>
>>The low 64 bits are the Host Address. Normally this includes the 
>>device's MAC Address although it can be a random number to prevent 
>>tracking the device via the address. The user can use the high part 
>>of the low 64 bits to make up their own LAN (like the current NAT 
>>mapping does for the single supplied IPv4 address).
>
>I think that is the "AH HA" I was missing.

As I said when the device connects it uses its MAC Address as part of 
its address so each address is unique.
See http://en.wikipedia.org/wiki/IPv6_subnetting#IPv6_subnetting.

>
>So you can get one ISP provided IPv6 address and and use it for 
>internal addresses without needing a NAT?

Yes. Since each device would fill in the low 64 bits with its unique 
MAC Address you get the equivalent of NAT. Your connectivity provider 
hands off all packed via a /64 mask so all the packets go to you 
(just like a IPv4/32 goes to a NAT box and passed by it to the LAN) 
for LAN routing. Note that a device can hide its MAC address by using 
a random number that does not match the MAC Address format so 
identification of the device for tracking purposes stops at the 
network interface (just like with a NAT Box).

>
>>So long as each user is given their own IPv6/64 network address 
>>this would avoid identification scaling issues vs the current use 
>>of an IPv4 address (ie: Treat the IPv6/64 masked address as the 
>>current IPv4/32 one is treated and you have the same granularity 
>>for graylisting/etc. purposes).
>
>Thanks. Very helpful overview.
>
>--
>Sincerely
>
>Hector Santos
>http://www.santronics.com
>jabber: [email-masked]

--============_-891583188==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: SMTP Kerberos
Considerations</title></head><body>
<div>At 03:42 -0400 on 11/05/2011, Hector Santos wrote about Re: SMTP
Kerberos Considerations:</div>
<div><br></div>
<blockquote type="cite" cite>Robert A. Rosenberg wrote:
<blockquote type="cite" cite><br>
At 17:54 -0400 on 11/02/2011, Hector Santos wrote about SMTP Kerberos
Considerations:<br>
<blockquote type="cite" cite>I don't know enough about how IPv6 are
assigned today.</blockquote>
</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>The idea is that the user gets a IPv6/64
Network address from their Connection Provider like they currently get
a IPv4/32.</blockquote>
</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>So you can get one or a bank of
addresses?&nbsp; Depending on the business package?&nbsp; Note, we
have a class C address.</blockquote>
<div><br></div>
<div>If you are a home user you would get a single IPv6/64 Network
address. That address will allow you to set up your own LAN. There is
no need for your connectivity provider to supply you more than one
address prefix since all of your devices are hosts under that prefix.
If you currently have a IP4/24 (Class C Network address) all of your
252 devices would still each get their own routable address from your
router. A company as opposed to a single user might get a IPv6/56 or
IPv6/48 (see
http://en.wikipedia.org/wiki/IPv6_subnetting_reference).</div>
<blockquote type="cite" cite><br>
<blockquote type="cite" cite>The low 64 bits are the Host Address.
Normally this includes the device's MAC Address although it can be a
random number to prevent tracking the device via the address. The user
can use the high part of the low 64 bits to make up their own LAN
(like the current NAT mapping does for the single supplied IPv4
address).</blockquote>
</blockquote>
<blockquote type="cite" cite><br>
I think that is the &quot;AH HA&quot; I was missing.<img
src="cid:p06240805cadb7e893914@[192.168.1.11].1.0"></blockquote>
<div><br></div>
<div>As I said when the device connects it uses its MAC Address as
part of its address so each address is unique.</div>
<div>See
http://en.wikipedia.org/wiki/IPv6_subnetting#IPv6_subnetting.</div>
<div><br></div>
<blockquote type="cite" cite><br>
So you can get one ISP provided IPv6 address and and use it for
internal addresses without needing a NAT?</blockquote>
<div><br></div>
<div>Yes. Since each device would fill in the low 64 bits with its
unique MAC Address you get the equivalent of NAT. Your connectivity
provider hands off all packed via a /64 mask so all the packets go to
you (just like a IPv4/32 goes to a NAT box and passed by it to the
LAN) for LAN routing. Note that a device can hide its MAC address by
using a random number that does not match the MAC Address format so
identification of the device for tracking purposes stops at the
network interface (just like with a NAT Box).</div>
<div><br></div>
<blockquote type="cite" cite><br>
<blockquote type="cite" cite>So long as each user is given their own
IPv6/64 network address this would avoid identification scaling issues
vs the current use of an IPv4 address (ie: Treat the IPv6/64 masked
address as the current IPv4/32 one is treated and you have the same
granularity for graylisting/etc. purposes).</blockquote>
</blockquote>
<blockquote type="cite" cite><br>
Thanks. Very helpful overview.<br>
<br>
--<br>
Sincerely<br>
<br>
Hector Santos<br>
http://www.santronics.com<br>
jabber: [email-masked]</blockquote>
<div><br></div>
</body>
</html>
--============_-891583188==_ma============--
--============_-891583188==_mr============
Content-Id: <p06240805cadb7e893914@[192.168.1.11].1.0>
Content-Type: image/gif; name="-!3a) Happy.gif"
 ; x-mac-type="47494666"
 ; x-mac-creator="474B4F4E"
Content-Disposition: attachment; filename="-!3a) Happy.gif"
Content-Transfer-Encoding: base64

--============_-891583188==_mr============--

Date: Sat, 05 Nov 2011 03:42:09 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: [email-masked]
Subject: Re: SMTP Kerberos Considerations
Sender: [email-masked]

Robert A. Rosenberg wrote:
> 
> At 17:54 -0400 on 11/02/2011, Hector Santos wrote about SMTP Kerberos 
> Considerations:
> 
>> I don't know enough about how IPv6 are assigned today.
> 
> The idea is that the user gets a IPv6/64 Network address from their 
> Connection Provider like they currently get a IPv4/32. 

So you can get one or a bank of addresses?  Depending on the business 
package?  Note, we have a class C address.

> The low 64 bits 
> are the Host Address. Normally this includes the device's MAC Address 
> although it can be a random number to prevent tracking the device via 
> the address. The user can use the high part of the low 64 bits to make 
> up their own LAN (like the current NAT mapping does for the single 
> supplied IPv4 address). 

I think that is the "AH HA" I was missing. :)

So you can get one ISP provided IPv6 address and and use it for 
internal addresses without needing a NAT?

> So long as each user is given their own IPv6/64 
> network address this would avoid identification scaling issues vs the 
> current use of an IPv4 address (ie: Treat the IPv6/64 masked address as 
> the current IPv4/32 one is treated and you have the same granularity for 
> graylisting/etc. purposes).

Thanks. Very helpful overview.

-- 
Sincerely

Hector Santos
http://www.santronics.com
jabber: [email-masked]

Date: Sat, 5 Nov 2011 00:14:27 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: SMTP Kerberos Considerations
Sender: [email-masked]

At 17:54 -0400 on 11/02/2011, Hector Santos wrote about SMTP Kerberos 
Considerations:

>I don't know enough about how IPv6 are assigned today.

The idea is that the user gets a IPv6/64 Network address from their 
Connection Provider like they currently get a IPv4/32. The low 64 
bits are the Host Address. Normally this includes the device's MAC 
Address although it can be a random number to prevent tracking the 
device via the address. The user can use the high part of the low 64 
bits to make up their own LAN (like the current NAT mapping does for 
the single supplied IPv4 address). So long as each user is given 
their own IPv6/64 network address this would avoid identification 
scaling issues vs the current use of an IPv4 address (ie: Treat the 
IPv6/64 masked address as the current IPv4/32 one is treated and you 
have the same granularity for graylisting/etc. purposes).

Date: Fri, 04 Nov 2011 16:30:25 -0700
From: Douglas Otis <[email-masked]>
To: Hector Santos <[email-masked]>
CC: [email-masked]
Subject: Re: SMTP and Kerberos
Sender: [email-masked]

On 11/4/11 2:54 PM, Douglas Otis wrote:
> Just guessing, it seems growth will top out at 1.4 trillion (a million 
> million) /64 equivalent prefixes.
Correction: 10^15 not 10^12.

Just guessing, it seems growth will top out at 1.4 quadrillion (a 
thousand trillion) /64 equivalent prefixes.

-Doug

Date: Fri, 04 Nov 2011 14:54:58 -0700
From: Douglas Otis <[email-masked]>
To: Hector Santos <[email-masked]>
CC: [email-masked]
Subject: Re: SMTP and Kerberos
Sender: [email-masked]

On 11/4/11 5:46 AM, Hector Santos wrote:
>  Douglas Otis wrote:
> >> The way I see it, practically speaking, Ipv6 will bring back the
> >> old simple solution of using "Allow IP Relay Tables" and the
> >> "Roaming user" issue would be a thing of the past.
> > http://bgp.potaroo.net/v6/as6447/
> >
> > Please notice currently there are 228,848 billion announced IPv6
> > /64 equivalent prefixes. A size 65k larger than the entire IPv4
> > unicast space. Also note this space is growing exponentially,
> > where the chart has become vertical. Have fun keeping up with
> > that.
>  I seriously doubt any one system is going to need to record all that,
>  after all, a site is are only going to record their "protected realm"
>  A.K.A network of users, partners or known senders just like its
>  currently done without sweating it. To assume a single system is
>  going to need to record 228,848 billion of anything, well, is very
>  ambitious for any single organization.

Doubts about managing each source within this space using CIDR lists is 
shared.

The term "protected realm" describes inbound MTAs associated with 
designated Kerberos services.   Kerberos is likely to be an attacked 
service.  As such it should be offered from distributed and robust 
networks, perhaps by third-parties.  This service should include 
intra-realm communications to indicate which domains were offered 
tickets.  This information could selectively open firewalls protecting 
services within the vast IPv6 environment.

> > At the smaller /48 prefixes, 538, 474, 403, 271, and 270 million
> > announcements are in Germany, Japan, rest of EU, Australia, and
> > Korea respectively. Even so, all /48s represent just .000067% of
> > the entire announced space.
>
>  The large spectrum of IPv6 is well understood, but IMV, no single
>  system is going to need to record anything close to these sizes,
>  unless of course, your company is planning to take over the world.
>  :)

Hardly.  Just guessing, it seems growth will top out at 1.4 trillion (a 
million million) /64 equivalent prefixes.  This represents a dramatic 
increase from 3.8 billion, especially since practices used to dismiss a 
sizable portion of IPv4 can not apply.  Ignoring an inability to reduce 
the monitored space, 370,000 to 1 compression would be required to 
utilize resources currently available.

> > Placing your inbound servers into a "protected realm" says you wish
> > to establish a robust method for accepting messages from legitimate
> > domains that you'll take steps to protect.
>  Lets assume your I-D proposes something really fantastic - that it
>  can have a high payoff and impact to lower spam.

The goal is to permit a method for defending services to ensure desired 
exchanges.  You seem to suggest this would be your approach, but 
permissions would be referenced by domain rather than by IP address.  
Domain names should be easier to manage and can apply even when 
confronting LSNs.

>  What happens to the other AUTH methods? Do we enforce KERBEROS only
>  senders?

The use of Kerberos based upon domain certificates is envisioned to 
represent a robust lightweight method to supplant reliance upon source 
IP addresses.  This might be used only where needed, and might 
eventually become the norm.  Either way, acceptance is still determined 
by inbound MTAs: either based upon source IP address or verified domain 
name.  Kerberos simply affords an efficient method for the added 
validation that perhaps happens every N hours per source.

>  My concern is the idea that SMTP systems will no longer need to
>  accept mail from non-authenticated senders for local users and to
>  move into a mode where all senders are (Kerberos) authenticated. In
>  other words, the Public Port SMTP network will no longer be public.

That is not the change envisioned.  This is to ensure desired exchanges 
are able to occur using manageable data-sets.

>  If enforcement is not mandated, then why would a sender use it? What
>  benefits do they get over others that using something else? That is
>  something I would like to know in your I-D.

Again, the protections offered directly benefit senders.  It affords a 
robust and lightweight basis in which exchanges can be accepted.  The 
enhanced name based source information directly benefits senders that 
might otherwise contend with recipients suffering from resource constraints.

-Doug

Date: Fri, 04 Nov 2011 08:46:41 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
CC: [email-masked]
Subject: Re: SMTP and Kerberos
To: [email-masked]
Sender: [email-masked]

Douglas Otis wrote:
> 
>> The way I see it, practically speaking, Ipv6 will bring back the old 
>> simple solution of using "Allow IP Relay Tables" and the "Roaming 
>> user" issue would be a thing of the past.
> http://bgp.potaroo.net/v6/as6447/
> 
> Please notice currently there are 228,848 billion announced IPv6 /64 
> equivalent prefixes.  A size 65k larger than the entire IPv4 unicast 
> space.  Also note this space is growing exponentially, where the chart 
> has become vertical.  Have fun keeping up with that.

I seriously doubt any one system is going to need to record all that, 
after all, a site is are only going to record their "protected realm" 
A.K.A network of users, partners or known senders just like its 
currently done without sweating it.  To assume a single system is 
going to need to record 228,848 billion of anything, well, is very 
ambitious for any single organization.

> At the smaller /48 prefixes, 538, 474, 403, 271, and 270 million 
> announcements are in Germany, Japan, rest of EU, Australia, and Korea 
> respectively.  Even so, all /48s represent just .000067% of the entire 
> announced space.

The large spectrum of IPv6 is well understood, but IMV, no single 
system is going to need to record anything close to these sizes, 
unless of course, your company is planning to take over the world. :)

> Placing your inbound servers into a "protected realm" says you wish to 
> establish a robust method for accepting messages from legitimate domains 
> that you'll take steps to protect.

Lets assume your I-D proposes something really fantastic - that it can 
have a high payoff and impact to lower spam.

What happens to the other AUTH methods?  Do we enforce KERBEROS only 
senders?

My concern is the idea that SMTP systems will no longer need to accept 
mail from non-authenticated senders for local users and to move into a 
mode where all senders are (Kerberos) authenticated. In other words, 
the Public Port SMTP network will no longer be public.

If enforcement is not mandated, then why would a sender use it?  What 
benefits do they get over others that using something else?   That is 
something I would like to know in your I-D.

-- 
Sincerely

Hector Santos
http://www.santronics.com
jabber: [email-masked]

Date: Thu, 03 Nov 2011 19:12:05 -0700
From: Douglas Otis <[email-masked]>
To: Hector Santos <[email-masked]>
CC: [email-masked]
Subject: Re: SMTP and Kerberos
Sender: [email-masked]

On 11/3/11 4:54 PM, Hector Santos wrote:
> Douglas Otis wrote:
>> John,
>>
>> I would like to thank you, Russ, and Keith for the feedback. 
> Hilarious. Are you intentionally trying to be ignorant? I guess you are.
Hector,

Not at all.  I agree with most of the issues that John raised.  I also 
do not believe in pixie dust, secret sauce, or other forms of magic 
being helpful either.  Domain protection is intended for MTA to MTA 
exchanges.  Use of user/password in base64 is unworkable on a global 
scale.  It is a complex problem having many possible configurations.  
The challenge is to find solutions causing the fewest changes that still 
retains the general goals represented by Kerberos constructs.
>> The goal is to ensure the domain name used by an entity can remain a 
>> solid basis for acceptance. 
> The way I see it, practically speaking, Ipv6 will bring back the old 
> simple solution of using "Allow IP Relay Tables" and the "Roaming 
> user" issue would be a thing of the past.
http://bgp.potaroo.net/v6/as6447/

Please notice currently there are 228,848 billion announced IPv6 /64 
equivalent prefixes.  A size 65k larger than the entire IPv4 unicast 
space.  Also note this space is growing exponentially, where the chart 
has become vertical.  Have fun keeping up with that.

At the smaller /48 prefixes, 538, 474, 403, 271, and 270 million 
announcements are in Germany, Japan, rest of EU, Australia, and Korea 
respectively.  Even so, all /48s represent just .000067% of the entire 
announced space.
> You can ignore that feedback too.
I would never do that.   Also don't depend upon tools to categorize 
sources based upon rDNS crawls.  Neither of us will live long enough to 
make a dent at this mapping.  What clues will you use?  What games can 
be played with that strategy?  There is little within email that is 
trustworthy.

When one looks at the number of domains used for legitimate email, the 
numbers become dramatically more manageable.  The challenge is to find a 
robust method to identify domain sources where the burden has been 
shifted toward the sender.  After all, domain protection largely 
benefits senders.

The requirement to retain invalid DKIM signatures, and lack of 
requirements for specific relationships makes dependence on DKIM this 
highly prone.  If you are not planning on accepting IPv6 connections, 
also expect a growing portion of inbound traffic carried through Large 
Scale NATs.  Good luck at figuring out where that traffic originated. :^(

Placing your inbound servers into a "protected realm" says you wish to 
establish a robust method for accepting messages from legitimate domains 
that you'll take steps to protect.

-Doug

From: Russ Allbery <[email-masked]>
To: SMTP Interest Group <[email-masked]>
Subject: Re: SMTP and Kerberos
Organization: The Eyrie
Date: Thu, 03 Nov 2011 17:46:57 -0700
Sender: [email-masked]

Douglas Otis <[email-masked]> writes:

> I would like to thank you, Russ, and Keith for the feedback.  I'll
> attempt to pull together an I-D to further clarify.  This is to allow
> inbound MTAs the means to belong to a "protected" realm as specified by
> their SRV records.  The SRV indicated servers are to leverage the
> verification of domain based certificates prior to the granting of
> tickets.  These tickets are protected by the realm's shared secrets.

An I-D would be helpful, yes, because the words that you're putting
together don't make a lot of sense to me.  For example, you're talking
about using all of DNS, X.509 (I assume) for certificates, and Kerberos
tickets, and I'm not sure why you'd use all those together, or if you're
talking about using PKINIT to obtain Kerberos tickets.

If I had to guess, I'd say that you're postulating per-realm Kerberos KDCs
tied together via an X.509 infrastructure (with what issuing CA?) and
doing cross-realm authentication using something akin to the PKCROSS
proposals, but I'm not sure if I'm following.  Having it all laid out in
an I-D would be helpful for that.

> Generally, the change relevant to SMTP would be retrieving and caching
> tickets for specific destinations within a protected realm at extended
> intervals of perhaps every 10 hours.

Why would you need an SMTP-related change for the standard Kerberos
functionality of obtaining and caching service tickets?  That would be a
good thing to explain in the I-D.

> Kerberos can limit use of a ticket, which may inhibit ticket forwarding.

In practice, address restrictions in Kerberos tickets don't actually work
(due largely to NAT), which means that everyone turns them off, which
means that Kerberos has very little protection against ticket forwarding.
You can set a flag in the ticket saying whether it is forwardable or not,
but that flag is advisory for addressless tickets, and an attacker can
just copy the ticket to another host and use it anyway.

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

Date: Thu, 03 Nov 2011 19:54:09 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
CC: SMTP Interest Group <[email-masked]>
Subject: Re: SMTP and Kerberos
To: [email-masked]
Sender: [email-masked]

Douglas Otis wrote:

> John,
> 
> I would like to thank you, Russ, and Keith for the feedback. 

Hilarious. Are you intentionally trying to be ignorant? I guess you are.

> The goal is to ensure the domain name used by an entity can remain a 
> solid basis for acceptance.  

The way I see it, practically speaking, Ipv6 will bring back the old 
simple solution of using "Allow IP Relay Tables" and the "Roaming 
user" issue would be a thing of the past.

You can ignore that feedback too.

-- 
Sincerely

Hector Santos
http://www.santronics.com
jabber: [email-masked]

Date: Thu, 03 Nov 2011 16:07:15 -0700
From: Douglas Otis <[email-masked]>
To: John C Klensin <[email-masked]>
CC: Tim Kehres <[email-masked]>, Tony Finch <[email-masked]>, Steve Atkins <[email-masked]>, SMTP Interest Group <[email-masked]>
Subject: Re: SMTP and Kerberos
Sender: [email-masked]

On 11/2/11 8:57 PM, John C Klensin wrote:
>  Russ and I have assumed that your intended use of Kerberos was
>  hop-by-hop client-server, the sort of thing that could be done by
>  attaching some conventions to SMTP AUTH. I can imagine using it end
>  to end, with the message originator obtaining a ticket, including
>  that ticket with the message, and then having the delivery server
>  validate the ticket. That does eliminate the issues of relays and
>  hop-by-hop arrangements, but the result is the same problem in a
>  slightly different guise: the assumption that the recipient will be
>  able to access appropriate mechanisms to validate the ticket may not
>  hold up in a relay environment, especially if the relays cross
>  realms, just may not be true... and we are back to how one
>  establishes a global trust model and makes it work.

John,

I would like to thank you, Russ, and Keith for the feedback.  I'll 
attempt to pull together an I-D to further clarify.  This is to allow 
inbound MTAs the means to belong to a "protected" realm as specified by 
their SRV records.  The SRV indicated servers are to leverage the 
verification of domain based certificates prior to the granting of 
tickets.  These tickets are protected by the realm's shared secrets.

Generally, the change relevant to SMTP would be retrieving and caching 
tickets for specific destinations within a protected realm at extended 
intervals of perhaps every 10 hours.  Protection is achieved by ticket 
verification based upon the realm's shared secret.  The low overhead (in 
comparison to other schemes) associated with ticket verification would 
precede protected sessions.

The goal is to ensure the domain name used by an entity can remain a 
solid basis for acceptance.  When any identity granting acceptance can 
be easily spoofed or replayed, it will be.  Since the introduction of 
IPv6, recognized domain names have become a more constrained dataset 
than that of IP addresses.  DKIM lacks practical replay protections and 
SPF's authorization can not cope with shared resources or source 
translations imposed by receiving networks.

Kerberos can limit use of a ticket, which may inhibit ticket 
forwarding.  The domain protection was intended for MTA to MTA 
exchanges.  Depending upon the Kerberos configuration, subsequent MTAs 
may need to request separate tickets.

-Doug

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: SMTP Kerberos Considerations
Organization: The Eyrie
Date: Thu, 03 Nov 2011 11:09:18 -0700
Sender: [email-masked]

Keith Moore <[email-masked]> writes:
> On Nov 3, 2011, at 12:55 PM, Russ Allbery wrote:

>> Federated cross-institutional authentication is a Very Hard Problem.

> Trust is inherently not transitive.

Right, and non-transitive and even asymmetric trust is one of the things
that these systems attempt to address.  In addition to non-transitive,
asymmetric trust, you also have to deal with limited information release
issues.  And in some cases you *do* want transitive trust (such as to a
parent organization which has multiple child organizations for which it
vouches), and you have to identify where those cases are and how to
represent them, and how you build exceptions to them.

One needs a *lot* of policy layers, and the overall complexity of the
system is high.  The SAML federation space is probably the most mature
implementation of this, and has some very strong drivers for forming
federations, and it's still messy and constantly evolving, with most of
the agreements made point-to-point.

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

Subject: Re: SMTP Kerberos Considerations
From: Keith Moore <[email-masked]>
Date: Thu, 3 Nov 2011 14:02:25 -0400
Cc: [email-masked]
To: Russ Allbery <[email-masked]>
Sender: [email-masked]

--Apple-Mail-108-586245662
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii

On Nov 3, 2011, at 12:55 PM, Russ Allbery wrote:

> Federated cross-institutional authentication is a Very Hard Problem.

Trust is inherently not transitive.

Keith

--Apple-Mail-108-586245662
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Nov 3, 2011, at 12:55 PM, Russ Allbery wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">Federated cross-institutional authentication is a Very Hard Problem.<br></span></blockquote></div><br><div>Trust is inherently not transitive.</div><div><br></div><div>Keith</div><div><br></div></body></html>
--Apple-Mail-108-586245662--

From: [email-masked]
Cc: [email-masked]
Date: Thu, 03 Nov 2011 10:17:57 -0700 (PDT)
Subject: Re: SMTP Kerberos Considerations
To: Russ Allbery <[email-masked]>
Sender: [email-masked]

+1 to everything Russ says here.

				Ned

> Federated cross-institutional authentication is a Very Hard Problem.
> Those of us whose primary work is in the authentication space have been
> working on it for a long time.  Huge amounts of effort have been put into
> systems like SAML or OpenID, which continue to only solve small, tightly
> constrained portions of the problem.  There is by no means a federated
> authentication story that's strong enough to tackle email as a whole at
> this time.  It just doesn't exist.

> The protocol isn't the problem.  We have lots of protocols.  The
> management and trust requirements are the problem.

> Also, even if one wants to move forward with an SMTP solution for a
> constrained case of the problem, Kerberos is an odd choice.  Kerberos is a
> symmetric shared-secret authentication system based on a central authority
> or network of central authorities.  In other words, except within an
> institution, you couldn't find an authentication protocol more unlike the
> way that SMTP networks are currently assembled.

> We already have an authentication protocol that looks much more like SMTP,
> given that for the normal SMTP case you want to authenticate end-to-end
> rather than point-to-point, authenticate the message rather than the
> transport so that you don't have lots of complexity around intermediate
> hops and backup MX records, decouple the system as much as possible due to
> the huge number of institutional boundaries, avoid requiring shared
> secrets due to their point-to-point agreement requirements, and allow
> authentication of messages after arbitrary delays.  That's a classic set
> of feature requirements for public key cryptography.  And we already have
> standardized authentication protocols for content using either X.509 or
> PGP, and those could be fairly easily adopted to cover, say, the message
> headers as well if one really wanted.

> I think it's telling that, apart from some specific work for some narrow
> use cases, no one has done widespread deployment of a general-purpose SMTP
> system that requires public-key message authentication.  I think there are
> very good reasons for that, most of which are related to the difficulty of
> key management, inter-institutional trust, and getting all SMTP traffic
> originators to authenticate their outgoing messages.

> >> The time synchronization requirement for Kerberos is nowhere near as
> >> strong as you seem to think it is.

> > It's 5 minutes isn't it? While that should be possible, it's a new
> > requirement for SMTP, so could cause problems for some people.

> Five minutes is only an application-side default.  The application can use
> any time skew that it wants.  The primary implications are around replay
> attacks: you need to keep a replay cache for the length of your supported
> time skew.  This is a minor issue; if the cross-realm trust problem could
> be solved, there are various ways to deal with this.

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

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: SMTP Kerberos Considerations
Organization: The Eyrie
Date: Thu, 03 Nov 2011 09:55:12 -0700
Sender: [email-masked]

Paul Smith <[email-masked]> writes:

> This is where I have trouble as well. I can't see how Kerberos would
> help at all, as it's essentially like any other SMTP AUTH system (which
> could be used as well, AFAICS) so would involve giving everyone else
> (except for spammers) in the world authentication details to our server.

This is the primary problem indeed.  Now, of course you wouldn't use your
regular authentication system for this necessarily, but you still have to
solve a significant cross-institutional authentication problem.

Federated cross-institutional authentication is a Very Hard Problem.
Those of us whose primary work is in the authentication space have been
working on it for a long time.  Huge amounts of effort have been put into
systems like SAML or OpenID, which continue to only solve small, tightly
constrained portions of the problem.  There is by no means a federated
authentication story that's strong enough to tackle email as a whole at
this time.  It just doesn't exist.

The protocol isn't the problem.  We have lots of protocols.  The
management and trust requirements are the problem.

Also, even if one wants to move forward with an SMTP solution for a
constrained case of the problem, Kerberos is an odd choice.  Kerberos is a
symmetric shared-secret authentication system based on a central authority
or network of central authorities.  In other words, except within an
institution, you couldn't find an authentication protocol more unlike the
way that SMTP networks are currently assembled.

We already have an authentication protocol that looks much more like SMTP,
given that for the normal SMTP case you want to authenticate end-to-end
rather than point-to-point, authenticate the message rather than the
transport so that you don't have lots of complexity around intermediate
hops and backup MX records, decouple the system as much as possible due to
the huge number of institutional boundaries, avoid requiring shared
secrets due to their point-to-point agreement requirements, and allow
authentication of messages after arbitrary delays.  That's a classic set
of feature requirements for public key cryptography.  And we already have
standardized authentication protocols for content using either X.509 or
PGP, and those could be fairly easily adopted to cover, say, the message
headers as well if one really wanted.

I think it's telling that, apart from some specific work for some narrow
use cases, no one has done widespread deployment of a general-purpose SMTP
system that requires public-key message authentication.  I think there are
very good reasons for that, most of which are related to the difficulty of
key management, inter-institutional trust, and getting all SMTP traffic
originators to authenticate their outgoing messages.

>> The time synchronization requirement for Kerberos is nowhere near as
>> strong as you seem to think it is.

> It's 5 minutes isn't it? While that should be possible, it's a new
> requirement for SMTP, so could cause problems for some people.

Five minutes is only an application-side default.  The application can use
any time skew that it wants.  The primary implications are around replay
attacks: you need to keep a replay cache for the length of your supported
time skew.  This is a minor issue; if the cross-realm trust problem could
be solved, there are various ways to deal with this.

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

Date: Thu, 03 Nov 2011 14:09:51 +0100
From: Alessandro Vesely <[email-masked]>
To: SMTP Interest Group <[email-masked]>
Subject: Re: draft-atkins-smtp-traffic-control
Sender: [email-masked]

On 28.10.2011 23:17, Steve Atkins wrote:
> 
> An ESMTP client, such as your ISP smarthost, will wait a while before
> retrying in response to a 4xx deferral. The RFCs say they should wait at
> least 30 minutes the first time.
> 
> Hence https://datatracker.ietf.org/doc/draft-atkins-smtp-traffic-control/
> It's a very lightweight approach that allows a server to tell a
> cooperating client how long it would like the client to wait before
> retrying.

A related topic is to determine the delivery time based on a message's
priority.  As both priority and wait time are about similar topic, perhaps
they shouldn't ignore one another.  Priority is being drafted here:
http://tools.ietf.org/html/draft-melnikov-smtp-priority

Date: Thu, 03 Nov 2011 12:43:47 +0000
From: Paul Smith <[email-masked]>
To: Russ Allbery <[email-masked]>
CC: [email-masked]
Subject: Re: SMTP Kerberos Considerations
Sender: [email-masked]

On 03/11/2011 00:12, Russ Allbery wrote:
> Hector Santos<[email-masked]>  writes:
I'm with Hector a bit on this.
>
>> 2) There is a licensing issue, and unless it is already licensed by the
>> OS and offered as an API entry point, adding this to your software is a
>> costly endeavor.  Again see #1
> There is no licensing requirement for Kerberos.  There are multiple
> interoperating free software (not even GPL'd) implementations and the
> protocol is an IETF standard.
While that's true. It doesn't help THAT much. Many MTAs are run by small 
businesses, with limited technical know-how. Asking them to install and 
manage an open-source Kerberos server is doomed to dramatic failure.

Mail server software vendors selling to small businesses could include 
an open-source Kerberos server with their software and try to handle it 
themselves, but then they are opening themselves up to all sorts of 
grief - eg bugs in critical software written by a third party which they 
will be expected to resolve.

> If one wanted to put together a more comprehensive framework, there 
> may need to be a new standard governing what specific principal names 
> should be used by SMTP services and how to handle the (very serious) 
> cross-realm trust issues, but that's another matter entirely and 
> doesn't require any changes to the SMTP protocol. 
This is where I have trouble as well. I can't see how Kerberos would 
help at all, as it's essentially like any other SMTP AUTH system (which 
could be used as well, AFAICS) so would involve giving everyone else 
(except for spammers) in the world authentication details to our server.

Unless I'm missing something.

Douglas's mantra of 'Kerberos and SMTP is the solution to our problems' 
doesn't seem to explain how it would work at all.

>> #1) Kerberos is deemed much stronger largely due to its client/server
>> time synchronization dependency.
> The time synchronization requirement for Kerberos is nowhere near as
> strong as you seem to think it is.
It's 5 minutes isn't it? While that should be possible, it's a new 
requirement for SMTP, so could cause problems for some people.

If all we're talking about is senderMTA-to-receiverMTA authentication 
(without authorisation), then I can imagine lots of ways of doing it 
without the complexity of Kerberos. Unless you have millions of MTA 
admins sending login details to millions of other MTA admins, then you 
have to actually authenticate the sender with the sender itself. SPF 
does this by using DNS entries from the sender as authentication. If SPF 
is inefficient (because of lots of DNS queries), then using a simple 
'callback' to a server at the sender's domain (possibly just using 2 UDP 
packets)  would work

eg
C: EHLO stuff
S: AUTH LOGIN PLAIN CALLBACK
C: AUTH CALLBACK <myname> <mypassword>

then S does finds an appropriate authentication server based on 'myname' 
(which would be something like 'yahoo.com') (eg using SRV DNS lookup), 
sends a UDP packet containing
<myname> <mypassword> <IP address of C> <secret code>
the 'myname' auth server sends back a UDP packet containing '<OK/not OK> 
<secret code> <max time to remember result>'

S: OK

S can now cache that that IP address is OK or not so it doesn't need to 
do the UDP exchange in the future for a while (up to the maximum cache 
time specified by the auth server)

<mypassword> can be an OTP or password calculated based on time (the 
exchange between the client sending the password and the server 
verifying it would be less than a couple of minutes), so don't need to 
worry too much about replay attacks
The auth server could even just base the authentication result on the IP 
address of the sender - eg Yahoo could ignore the password, and just 
authenticate the IP address of any of their outward servers.

<secret code> is just to stop address spoofing when using UDP

If this passes, then we know the sender is who it says it is. 
Authorisation could be based on the 'myname' part of the authentication.

We have four extra UDP packets (2 to get the SRV record, 2 for the 
authentication itself) for authentication per session (SPF needs a 
minimum of two (for the TXT record) per message and usually many more). 
If the IP address has been authenticated before, even this isn't needed.

We do need an extra authentication server, but that would be trivial in 
many cases (just compare the IP address against a list of valid IP 
addresses, or against a hash of a secret+time for the last few minutes). 
The authentication server here would be much simpler than a Kerberos 
server, and you wouldn't need to exchange authentication details. There 
are no timing constraints (other than a requirement that the receiving 
SMTP server does the authentication process within, say, 5 minutes of 
receiving the AUTH CALLBACK command)

Date: Wed, 02 Nov 2011 23:57:56 -0400
From: John C Klensin <[email-masked]>
To: Douglas Otis <[email-masked]>
cc: Tim Kehres <[email-masked]>, Tony Finch <[email-masked]>, Steve Atkins <[email-masked]>, SMTP Interest Group <[email-masked]>
Subject: SMTP and Kerberos  (was: Re: smtp-traffic-control)
Sender: [email-masked]

--On Wednesday, November 02, 2011 12:45 -0700 Douglas Otis
<[email-masked]> wrote:

> On 11/2/11 10:21 AM, John C Klensin wrote:
>> In the context of the present discussion, I haven't noticed
>> anyone suggesting linking traffic control options and
>> responses to authentication, so I don't really understand
>> where that part of your comment is relevant.   If you are
>...

> John,
> 
> To clarify, as IPv6 becomes more pervasive, the need for
> Kerberos services will become more apparent.  IMHO, likely to
> the point of become a common ISP or OS vender offering.
>...

> For email to remain practical, a better solution at
> controlling use of resources is needed.  There are several
> advocating creation of reputation systems that don't
> authenticate acting domains involved in sending email.  Only
> those domains considered "too big to block" are likely able to
> survive the many exploits such a strategy would permit.
> 
> I can put together an I-D describing the Kerberos ticket
> extension if you think this would be a logical next step.
> Its use would supplant RBL like reputation services and
> gray-listing normally cached by IP address applied at every
> SMTP exchange.

Aha.  Now that I know what you are talking about...

First, consider Keith's and Hector's comments in the broadest
sense (free of Kerberos specifics which, as Russ essentially
points out, may not have been completely understood for this
context): establishing global trust structures is really hard
and most of the problems are policy, not technical.  That is
true whether the mechanisms are based on shared secrets,
Kerberos (in a cross-realm environment?), some kind of PKI,
PGP-like webs of trust, or something else.  This is the problem
that DNS-based techniques, like DKIM, were intended to solve.
The good news about the DNS-based approaches is that, if one can
use them and they work, techniques based on domain names don't
get worse with IPv6 or anything else that causes explosive
growth of the address space.  The bad news, almost independent
of any of the subtle technical issues that you and others have
raised is that trust models based on the DNS are very fragile if
someone has a serious incentive to attack them -- not because of
issues with DNSSEC or its applicability, but because there is no
general requirement for a verified identity for the registrant,
much less a verified identity as a good entity, in order to
obtain such a name.

But, as far as I know, the thing that all of those methods have
in common is a model in which the recipient system decides that,
if a message comes it, either it is associated with some sort of
credential that the would-be recipient finds acceptable or it
gets rejected or treated it with more suspicion than a message
that is associated with such a credential.  Whether that
credential is bound to the sending system, the previous-hop
server, the message originator, or the sender really are small
details by comparison, as is just what the credentials are.

I understand that these problems clear up if sprinkled with
adequate quantities of pixie dust, but I'm not aware of a
sufficient, readily-available, supply.

That isn't exactly a new model.  I, and I assume many others,
have had mailboxes around on and off since the early 70s for
which the receiving mail server looks for a particular
credential and rejects or discards the message if it isn't
there.  That credential started out as the presence of a magic
cookie in the subject line or message body (really a shared
not-very-secret) and evolved into the presence of signatures
based on shared secrets, PGP, or S/MIME; SMTP AUTH with various
flavors and trust agreements; and SPF, Sender-ID, DKIM, and
friends.   The cookie plan tests something the sender knows, the
signatures provide authentication of the sender and the message,
SMTP AUTH authenticates the last-hop server, and so on -- all
effective if that is what is wanted and one trusts the trust
system.   In a different thread, we had the notion that one
could send mail across administrative domains only via
authorization from a (probably government-certified) ADMD and
then bilateral arrangements among ADMDs -- I note that the
amount of spam sent and delivered via X.400 mail systems with
Distinguished Names based in the ITU arc in the last few years
has been rather small.

I don't see how use of Kerberos would change that basic picture.
In the final analysis, one either needs to require that anyone
who is going to send you mail make prior arrangements out of
band, centralize the trust system, depend on indirect trust
arrangements (e.g., reputation systems or address blacklists),
or centralize the mail system itself, possibly via bilateral
arrangements among mutually-trusting relaying parties.

Russ and I have assumed that your intended use of Kerberos was
hop-by-hop client-server, the sort of thing that could be done
by attaching some conventions to SMTP AUTH.   I can imagine
using it end to end, with the message originator obtaining a
ticket, including that ticket with the message, and then having
the delivery server validate the ticket.  That does eliminate
the issues of relays and hop-by-hop arrangements, but the result
is the same problem in a slightly different guise:  the
assumption that the recipient will be able to access appropriate
mechanisms to validate the ticket may not hold up in a relay
environment, especially if the relays cross realms, just may not
be true... and we are back to how one establishes a global trust
model and makes it work.

best,
    john

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: SMTP Kerberos Considerations
Organization: The Eyrie
Date: Wed, 02 Nov 2011 17:12:01 -0700
Sender: [email-masked]

Hector Santos <[email-masked]> writes:

> 2) There is a licensing issue, and unless it is already licensed by the
> OS and offered as an API entry point, adding this to your software is a
> costly endeavor.  Again see #1

There is no licensing requirement for Kerberos.  There are multiple
interoperating free software (not even GPL'd) implementations and the
protocol is an IETF standard.

> I support a Kerberos SMTP AUTH extension proposal, if only as another
> AUTH alternative.

There's no need for any such proposal.  RFC 4752 has been a proposed
standard for five years.

If one wanted to put together a more comprehensive framework, there may
need to be a new standard governing what specific principal names should
be used by SMTP services and how to handle the (very serious) cross-realm
trust issues, but that's another matter entirely and doesn't require any
changes to the SMTP protocol.

> #1) Kerberos is deemed much stronger largely due to its client/server
> time synchronization dependency.

The time synchronization requirement for Kerberos is nowhere near as
strong as you seem to think it is.

I think it's a poor fit for this problem space for the reasons pointed out
by Keith Moore, but some of these objections seem to come from a serious
lack of understanding of what Kerberos is, how it integrates with SMTP,
and how it works.

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

Date: Wed, 02 Nov 2011 17:54:40 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
CC: SMTP Interest Group <[email-masked]>
Subject: SMTP Kerberos Considerations
To: [email-masked]
Sender: [email-masked]

Douglas Otis wrote:

> John,
> 
> To clarify, as IPv6 becomes more pervasive, the need for Kerberos 
> services will become more apparent.  IMHO, likely to the point of become 
> a common ISP or OS vender offering.

And thats a critical framework presumption - centralization requirement.

> Changes required  of SMTP to make use of Kerberos would be minimal.  I 
> believe it would only require an SMTP-Auth extension to exchange 
> retained tickets for destination domains.  

It will require more than that at the infrastructure level. There are 
many critical issues so I can only list most immediate ones

1) Not everyone uses the same software.

2) There is a licensing issue, and unless it is already licensed by 
the OS and offered as an API entry point, adding this to your software 
is a costly endeavor.  Again see #1

3) While it may be viewed as insignificant, it its security value is 
highly dependent on time synchronization of servers and clients. That 
means your machines MUST be properly prepared with a 3rd party 100% 
availability Time Server. I can tell you may not always get that to 
work right for whatever reasons we have given up trying to figure out. 
  I believe it is KERBEROS related - a chicken and egg situation and 
off hand, as we last left it, kerberos related login failures disables 
some of the OS components such as the client ability to access time 
servers.

> The resulting reduction in unwanted traffic and message overhead 
> should produce a sizable reduction in the cost of providing email, 
> and allow SMTP to properly function within Today's Internet.

Any client/server authentication will provide the same overhead 
reduction simply because the transports frictions factor are now zero.

> SMTP will not function within amber.
> 
> It would seem appropriate for error codes to be defined for "invalid 
> ticket" and a "valid ticket required".  It will be years before "valid 
> ticket required" messages could be used.  Even so, this is likely the 
> best solution to deal with LSNs, and the large IPv6 address space that 
> will negate most anti-abuse strategies.
> 
> For email to remain practical, a better solution at controlling use of 
> resources is needed.  There are several advocating creation of 
> reputation systems that don't authenticate acting domains involved in 
> sending email.  Only those domains considered "too big to block" are 
> likely able to survive the many exploits such a strategy would permit.
> 
> I can put together an I-D describing the Kerberos ticket extension if 
> you think this would be a logical next step.   Its use would supplant 
> RBL like reputation services and gray-listing normally cached by IP 
> address applied at every SMTP exchange.

I support a Kerberos SMTP AUTH extension proposal, if only as another 
AUTH alternative.   However, IMO, the reasons for it would be 
difference than what the discussions were about.

#1) Kerberos is deemed much stronger largely due to its client/server 
time synchronization dependency.  There are all kinds of requirements 
here, including making sure a common Time Server is used, making sure 
clock batteries are ok!! Now a machine off by just a minute is important.

#2) In centralized networks, included clouds, a single ticket can be 
used for many things during its life span for the entire 
machine/device. But with this machine wide applicability, it can also 
be viewed as a Threat Entry point as well.

#3) This is so server specific policy dependent, it offers no 
additional payoff over any other authenticated method as it relates to 
mail filtering needs. Since the receiver MTA behavior mode is now that 
of an MSA (not MDA), it will more than likely disable most of the 
filtering restrictions especially those related to intentional 4yz 
temporary rejections designed to force anonymous senders to retry 
after some blocked time.  Will it change other user or system level 
4yx reasons?

I don't see how and while I am thinking about it, I did scratched my 
head regarding your comment that IPv6 can not be used for reputation. 
  I am thinking that IPv6 offers more of a theatrical static and 
forever assignment as oppose to IPv4 today which can not be guarantee 
to be static (event though ISP today don't often change on users 
unlike the past).

In other words, IMV, with a higher guarantee that a device, machines, 
even IPv6 ready SMTP clients, they will have a constant IPv6 that will 
never change and this can be leveraged for all kinds of things, not 
just the cat's meow for tracking and direct marketing Advertisers.

In fact, I believe that in the future, a person will be able to have 
an IPv6 address that is permanent and/or *legally* transportable, like 
an telephone # is today. But again, if its unlimited, than it might be 
argued that once a IPv6 is burned into a device (or new born baby :), 
its becomes its DNA and can not be duplicated (used on another device 
the user upgraded to).  I don't know enough about how IPv6 are 
assigned today.

-- 
Sincerely

Hector Santos
http://www.santronics.com
jabber: [email-masked]

Date: Wed, 02 Nov 2011 14:53:48 -0700
From: Douglas Otis <[email-masked]>
To: Hector Santos <[email-masked]>
CC: [email-masked]
Subject: Re: SMTP Kerberos support
Sender: [email-masked]

On 11/2/11 1:57 PM, Hector Santos wrote:
> Of course, the #1 reason it doesn't apply in an public port 25 SMTP 
> standard is because it can not be enforced.  And I should note that 
> the discussions regarding 4yz policy based rejections w/o time hints, 
> to me, was understood to be only applicable to unauthenticated, 
> anonymous senders.  Once a sender is known by any form of 
> authentication, policies such as greylisting or other sender filtering 
> methods should not be applied.  I know there is the possibility of a 
> compromised user, but thats a different set of issues (and most 
> complex, costly considerations) in my opinion.
Hector,

Authenticating outbound SMTP servers provides an effective enforcement 
method for dealing with compromised systems.  Ensuring certainty of a 
requirement to mitigate compromised accounts makes this happen.  A 
preliminary authentication process providing a lead of many hours offers 
a reasonable strategy to offer advanced notice when a problem requires 
intervention.  Often this only entails a reply that action will be taken.

To get an idea about how Kerberos might be deployed in wider 
environments, see RFC6281.  Duration of these tickets were set at 10 
hours.  Not exactly a difficult timing constraint.  There could also be 
servers acting in their stead to facilitate ticket retrial when clients 
are within highly constrained environments.

-Doug

From: Russ Allbery <[email-masked]>
To: SMTP Interest Group <[email-masked]>
Subject: Re: smtp-traffic-control
Organization: The Eyrie
Date: Wed, 02 Nov 2011 14:33:11 -0700
Sender: [email-masked]

Douglas Otis <[email-masked]> writes:

> Changes required of SMTP to make use of Kerberos would be minimal.  I
> believe it would only require an SMTP-Auth extension to exchange
> retained tickets for destination domains.

There aren't any changes at all required of SMTP to make use of Kerberos.
SMTP AUTH supports Kerberos right now, via SASL.  So no protocol changes
are required for you to start testing such a system right now to see how
well it works.

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

Date: Wed, 02 Nov 2011 16:57:42 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
CC: SMTP Interest Group <[email-masked]>
Subject: SMTP Kerberos support
To: [email-masked]
Sender: [email-masked]

Douglas Otis wrote:
> 
> Agreed, crypto offers recognition of previous encounters.  A desire to 
> make exchanges that traverse LSNs is clearly where something like 
> Kerberos tickets can play a suitable role in offering a low overhead 
> process.  Kerberos can also offer a lower frequency rate where it 
> remains practical to identify all domains prior to issuing tickets.  
> Reputations MUST BE based on AUTHENTICATED identities.  

I am not sure Kerberos is suitable as you may think for public port 
SMTP market. I can see it works well when employed with centralized 
vendor networking and control is in place and timing can be 
auto-configured among clients

But it does requires time synchronization across the board and I think 
its quite unrealistic (to achieve reliably) in a *decentralized* SMTP 
public port environment of different servers and clients. Note the 
emphasis on decentralized.

Of course, the #1 reason it doesn't apply in an public port 25 SMTP 
standard is because it can not be enforced.  And I should note that 
the discussions regarding 4yz policy based rejections w/o time hints, 
to me, was understood to be only applicable to unauthenticated, 
anonymous senders.  Once a sender is known by any form of 
authentication, policies such as greylisting or other sender filtering 
methods should not be applied.  I know there is the possibility of a 
compromised user, but thats a different set of issues (and most 
complex, costly considerations) in my opinion.

-- 
Sincerely

Hector Santos
http://www.santronics.com
jabber: [email-masked]

Subject: Re: smtp-traffic-control
From: Keith Moore <[email-masked]>
Date: Wed, 2 Nov 2011 15:59:29 -0400
Cc: John C Klensin <[email-masked]>, Tim Kehres <[email-masked]>, Tony Finch <[email-masked]>, Steve Atkins <[email-masked]>, SMTP Interest Group <[email-masked]>
To: Douglas Otis <[email-masked]>
Sender: [email-masked]

On Nov 2, 2011, at 3:45 PM, Douglas Otis wrote:

> I can put together an I-D describing the Kerberos ticket extension if you think this would be a logical next step.   Its use would supplant RBL like reputation services and gray-listing normally cached by IP address applied at every SMTP exchange.

Before you try to describe protocol extensions, perhaps you should start by writing an I-D describing how Kerberos actually helps.  e.g. How do you establish trust between realms on the scale required for global email?

Keith

Date: Wed, 02 Nov 2011 12:45:50 -0700
From: Douglas Otis <[email-masked]>
To: John C Klensin <[email-masked]>
CC: Tim Kehres <[email-masked]>, Tony Finch <[email-masked]>, Steve Atkins <[email-masked]>, SMTP Interest Group <[email-masked]>
Subject: Re: smtp-traffic-control
Sender: [email-masked]

On 11/2/11 10:21 AM, John C Klensin wrote:
> In the context of the present discussion, I haven't noticed
> anyone suggesting linking traffic control options and responses
> to authentication, so I don't really understand where that part
> of your comment is relevant.   If you are suggesting either
> replacing SMTP with a different type of mail model or, as you
> have suggested before, replacing the DATA command and
> transmission of content with some sort of pointer to where the
> recipient can pick the content up... Well, by all means turn
> those ideas into a coherent and comprehensive proposal and see
> if you can get traction for it.  But I'm not sure they are
> relevant to the current discussion.
John,

To clarify, as IPv6 becomes more pervasive, the need for Kerberos 
services will become more apparent.  IMHO, likely to the point of become 
a common ISP or OS vender offering.

Changes required  of SMTP to make use of Kerberos would be minimal.  I 
believe it would only require an SMTP-Auth extension to exchange 
retained tickets for destination domains.  The resulting reduction in 
unwanted traffic and message overhead should produce a sizable reduction 
in the cost of providing email, and allow SMTP to properly function 
within Today's Internet.  SMTP will not function within amber.

It would seem appropriate for error codes to be defined for "invalid 
ticket" and a "valid ticket required".  It will be years before "valid 
ticket required" messages could be used.  Even so, this is likely the 
best solution to deal with LSNs, and the large IPv6 address space that 
will negate most anti-abuse strategies.

For email to remain practical, a better solution at controlling use of 
resources is needed.  There are several advocating creation of 
reputation systems that don't authenticate acting domains involved in 
sending email.  Only those domains considered "too big to block" are 
likely able to survive the many exploits such a strategy would permit.

I can put together an I-D describing the Kerberos ticket extension if 
you think this would be a logical next step.   Its use would supplant 
RBL like reputation services and gray-listing normally cached by IP 
address applied at every SMTP exchange.

-Doug

Date: Wed, 02 Nov 2011 13:21:19 -0400
From: John C Klensin <[email-masked]>
To: Douglas Otis <[email-masked]>
cc: Tim Kehres <[email-masked]>, Tony Finch <[email-masked]>, Steve Atkins <[email-masked]>, SMTP Interest Group <[email-masked]>
Subject: Re: draft-atkins-smtp-traffic-control
Sender: [email-masked]

--On Wednesday, November 02, 2011 09:24 -0700 Douglas Otis
<[email-masked]> wrote:

>> (3) Would such an extension be useful enough in practice, and
>> implemented and deployed enough in practice, to be worth the
>> trouble?  I don't know and don't have an opinion.

And, to be explicit about it, I will listen intermittently, but,
because I no longer have significant responsibility for either
implementations or large-scale mail operations, expect to
continue to not have an opinion.

> John,
> 
> A short term "come back 15 minutes later" does not address a
> much greater concern.  Within IPv4, categorization of dynamic
> or abusive sources currently abates a fair amount of undesired
> traffic prior to establishment of a connection.  This
> abatement has become necessary for preserving resources within
> smaller networks.  IPv6 will soon offer a prefix space about
> 400,000 times larger than IPv4 unicast space.  The greater
> size of IPv6 and an inability to crawl its rDNS thwarts
> similar efforts at either collecting or publishing similar
> categorizations.
>...
> While SMTP could attempt to include an authentication process
> within SMTP exchanges, an existing structure based on tickets
> offers an extremely efficient alternative able to facilitate
> use of LSNs and offers better control than that found with
> "come back in 15 minutes".

You have said this, with small variations, many times.  You are
certainly correct to warn others that you see that particular
danger with the interaction between IPv6 and larger-scale mail
operations.  I'll let others, and history, figure out whether
you are correct or not.  

In the context of the present discussion, I haven't noticed
anyone suggesting linking traffic control options and responses
to authentication, so I don't really understand where that part
of your comment is relevant.   If you are suggesting either
replacing SMTP with a different type of mail model or, as you
have suggested before, replacing the DATA command and
transmission of content with some sort of pointer to where the
recipient can pick the content up... Well, by all means turn
those ideas into a coherent and comprehensive proposal and see
if you can get traction for it.  But I'm not sure they are
relevant to the current discussion.

best,
   john

Date: Wed, 02 Nov 2011 09:24:47 -0700
From: Douglas Otis <[email-masked]>
To: John C Klensin <[email-masked]>
CC: Tim Kehres <[email-masked]>, Tony Finch <[email-masked]>, Steve Atkins <[email-masked]>, SMTP Interest Group <[email-masked]>
Subject: Re: draft-atkins-smtp-traffic-control
Sender: [email-masked]

On 11/2/11 6:07 AM, John C Klensin wrote:
>
>
> --On Wednesday, November 02, 2011 19:25 +0800 Tim Kehres
> <[email-masked]>  wrote:
>
>> From: "John C Klensin"<[email-masked]>
>>
>>> The "retry strategy" text in RFC 5321 was written more on the
>>> assumption that most cases would be connection failures,
>>> rather than 4yz-induced retries.  It does not differentiate
>>> between the two because, when 4yz really meant "system down
>>> or going down" or "no service right now" on a global, rather
>>> than
>>> sender-selective basis, it was reasonable to assume that a
>>> retry within a short period of time would get a connection
>>> failure.
>> Understood, however the use of 4yz during the RCPT TO: phase
>> has been common for a long time now.   5321 seems to also
>> acknowledge this in stating the following definition for the
>> 450 response:
>>
>>     450  Requested mail action not taken: mailbox unavailable
>> (e.g.,
>>          mailbox busy or temporarily blocked for policy reasons)
> Yes.  I know.  I wrote that text.  I'm not suggesting that this
> newer usage is invalid, or even wrong.  I'm just suggesting that
> (i) it is not precisely in line with the original model (which
> may or may not be a problem) and (ii) that we did not rewrite
> the discussion of the retry/queuing model, nor the maximum and
> minimum timeout discussions, to reflect uses radically different
> from "machine going down".  Perhaps we should have done that,
> but we didn't.  From one point of view, the problem with this
> practice vis-a-vis 5321 isn't that the statement you cite is
> there but that the WG didn't follow up with a reanalysis of
> waiting times.
>
>> Am I being too simplistic in thinking we could formalize a
>> retry= extension that could be used here (as well as other
>> contexts)?   In practice many MTA's simply tag each queue item
>> with a timestamp at which time retries can be valid with
>> actual queue runs being scheduled on a regular basis (skipping
>> over messages not available yet for retry).  For these types
>> of systems having the client read the response and adjust the
>> retry time tag should not be that difficult, and not rely upon
>> any queuing system changes.  This could apply for greylisting,
>> server not accepting mail (for whatever reasons), pizza and
>> beer break, or other unanticipated outages (either planned or
>> automated).   On the protocol side, no need for extending the
>> basic response codes either.
> Let me try to be clear.   Again, I'm not advocating anything (or
> pushing back on anything).  I just want to encourage people to
> examine all of the options and tradeoffs.  So...
>
> (1) Could we formalize such an extension?  Yes.  No problem.
> Well within the extension model.  Whether we can reach consensu
> on the details is a separate question but I believe the answer
> is probably "yes", especially if it isn't purely an anti-spam
> measure.
>
> (2) Is it necessary to extend the basic response codes?  No.
> There might be some advantages (as well as disadvantages) to
> doing so.  IMO, someone needs to work out the use cases, the
> relationships among various combinations of extended and
> unextended servers, and so on and sort that out.
>
> (3) Would such an extension be useful enough in practice, and
> implemented and deployed enough in practice, to be worth the
> trouble?  I don't know and don't have an opinion.
John,

A short term "come back 15 minutes later" does not address a much 
greater concern.  Within IPv4, categorization of dynamic or abusive 
sources currently abates a fair amount of undesired traffic prior to 
establishment of a connection.  This abatement has become necessary for 
preserving resources within smaller networks.  IPv6 will soon offer a 
prefix space about 400,000 times larger than IPv4 unicast space.  The 
greater size of IPv6 and an inability to crawl its rDNS thwarts similar 
efforts at either collecting or publishing similar categorizations.

When receivers refuse to accept IPv6 due to failed traditional 
constraints, this IPv6 traffic will eventually become translated through 
various Large Scale NATs.  After which, efforts to decide which traffic 
should be delayed or refused based upon the source address becomes 
impractical.  Gray listing or applying address based bandwidth control 
is likely to produce undesirable results.

While SMTP could attempt to include an authentication process within 
SMTP exchanges, an existing structure based on tickets offers an 
extremely efficient alternative able to facilitate use of LSNs and 
offers better control than that found with "come back in 15 minutes".

-Doug

Date: Wed, 02 Nov 2011 09:07:52 -0400
From: John C Klensin <[email-masked]>
To: Tim Kehres <[email-masked]>, Tony Finch <[email-masked]>, Steve Atkins <[email-masked]>
cc: SMTP Interest Group <[email-masked]>
Subject: Re: draft-atkins-smtp-traffic-control
Sender: [email-masked]

--On Wednesday, November 02, 2011 19:25 +0800 Tim Kehres
<[email-masked]> wrote:

> From: "John C Klensin" <[email-masked]>
> 
>> The "retry strategy" text in RFC 5321 was written more on the
>> assumption that most cases would be connection failures,
>> rather than 4yz-induced retries.  It does not differentiate
>> between the two because, when 4yz really meant "system down
>> or going down" or "no service right now" on a global, rather
>> than
>> sender-selective basis, it was reasonable to assume that a
>> retry within a short period of time would get a connection
>> failure.
> 
> Understood, however the use of 4yz during the RCPT TO: phase
> has been common for a long time now.   5321 seems to also
> acknowledge this in stating the following definition for the
> 450 response:
> 
>    450  Requested mail action not taken: mailbox unavailable
> (e.g.,
>         mailbox busy or temporarily blocked for policy reasons)

Yes.  I know.  I wrote that text.  I'm not suggesting that this
newer usage is invalid, or even wrong.  I'm just suggesting that
(i) it is not precisely in line with the original model (which
may or may not be a problem) and (ii) that we did not rewrite
the discussion of the retry/queuing model, nor the maximum and
minimum timeout discussions, to reflect uses radically different
from "machine going down".  Perhaps we should have done that,
but we didn't.  From one point of view, the problem with this
practice vis-a-vis 5321 isn't that the statement you cite is
there but that the WG didn't follow up with a reanalysis of
waiting times.

> Am I being too simplistic in thinking we could formalize a
> retry= extension that could be used here (as well as other
> contexts)?   In practice many MTA's simply tag each queue item
> with a timestamp at which time retries can be valid with
> actual queue runs being scheduled on a regular basis (skipping
> over messages not available yet for retry).  For these types
> of systems having the client read the response and adjust the
> retry time tag should not be that difficult, and not rely upon
> any queuing system changes.  This could apply for greylisting,
> server not accepting mail (for whatever reasons), pizza and
> beer break, or other unanticipated outages (either planned or
> automated).   On the protocol side, no need for extending the
> basic response codes either.

Let me try to be clear.   Again, I'm not advocating anything (or
pushing back on anything).  I just want to encourage people to
examine all of the options and tradeoffs.  So...

(1) Could we formalize such an extension?  Yes.  No problem.
Well within the extension model.  Whether we can reach consensu
on the details is a separate question but I believe the answer
is probably "yes", especially if it isn't purely an anti-spam
measure.

(2) Is it necessary to extend the basic response codes?  No.
There might be some advantages (as well as disadvantages) to
doing so.  IMO, someone needs to work out the use cases, the
relationships among various combinations of extended and
unextended servers, and so on and sort that out.

(3) Would such an extension be useful enough in practice, and
implemented and deployed enough in practice, to be worth the
trouble?  I don't know and don't have an opinion.

best regards,
    john

From: "Tim Kehres" <[email-masked]>
To: "John C Klensin" <[email-masked]>, "Tony Finch" <[email-masked]>, "Steve Atkins" <[email-masked]>
Cc: "SMTP Interest Group" <[email-masked]>
Subject: Re: draft-atkins-smtp-traffic-control
Date: Wed, 2 Nov 2011 19:25:13 +0800
Sender: [email-masked]

From: "John C Klensin" <[email-masked]>

> The "retry strategy" text in RFC 5321 was written more on the
> assumption that most cases would be connection failures, rather
> than 4yz-induced retries.  It does not differentiate between the
> two because, when 4yz really meant "system down or going down"
> or "no service right now" on a global, rather than
> sender-selective basis, it was reasonable to assume that a retry
> within a short period of time would get a connection failure.

Understood, however the use of 4yz during the RCPT TO: phase has been common 
for a long time now.   5321 seems to also acknowledge this in stating the 
following definition for the 450 response:

   450  Requested mail action not taken: mailbox unavailable (e.g.,
        mailbox busy or temporarily blocked for policy reasons)

Am I being too simplistic in thinking we could formalize a retry= extension 
that could be used here (as well as other contexts)?   In practice many 
MTA's simply tag each queue item with a timestamp at which time retries can 
be valid with actual queue runs being scheduled on a regular basis (skipping 
over messages not available yet for retry).  For these types of systems 
having the client read the response and adjust the retry time tag should not 
be that difficult, and not rely upon any queuing system changes.  This could 
apply for greylisting, server not accepting mail (for whatever reasons), 
pizza and beer break, or other unanticipated outages (either planned or 
automated).   On the protocol side, no need for extending the basic response 
codes either.

Best Regards,

-- Tim 

Date: 1 Nov 2011 21:07:59 -0000
From: "John Levine" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: draft-atkins-smtp-traffic-control
Organization: 
Sender: [email-masked]

>> (1) The difference between "not able to accept any mail right
>> now" and "trying to manage traffic" (or greylist, or...) really
>> may justify a different reply code set.

Call me grumpy, but I'm having trouble understanding why I would want
to help people who underprovision their mail systems push the extra
work off on me.

Yes, I know that Yahoo's mail system is chronically overloaded and
sheds load all the time.  This is a business decision, not a law of
nature.

R's,
John

Subject: Re: draft-atkins-smtp-traffic-control
From: Steve Atkins <[email-masked]>
Date: Tue, 1 Nov 2011 12:21:15 -0700
To: SMTP Interest Group <[email-masked]>
Sender: [email-masked]

On Nov 1, 2011, at 6:17 AM, John C Klensin wrote:

> 
> 
> 
> --On Tuesday, November 01, 2011 12:47 +0000 Tony Finch
> <[email-masked]> wrote:
> 
>> I was thinking higher but not much higher, e.g. have a
>> starting interval of several minutes and increase it by a
>> small percentage each time. If a site is deliberately
>> deferring mail then prompt delivery is clearly less important
>> to them than some other consideration, so it doesn't make much
>> sense to bust a gut to deliver their mail asap.
> 
> The "retry strategy" text in RFC 5321 was written more on the
> assumption that most cases would be connection failures, rather
> than 4yz-induced retries.  It does not differentiate between the
> two because, when 4yz really meant "system down or going down"
> or "no service right now" on a global, rather than
> sender-selective basis, it was reasonable to assume that a retry
> within a short period of time would get a connection failure.
> 
> Combined with Tony's observation, this suggests two things to me:
> 
> (1) The difference between "not able to accept any mail right
> now" and "trying to manage traffic" (or greylist, or...) really
> may justify a different reply code set.

That's the direction I've been moving in too.

> 
> (2) Maybe the 4yz- (or new code)-induced retries aren't as
> different from the traditional case as we have been assuming.
> What 5321 recommends is, essentially, "wait 30 minutes or so,
> try a couple of times at that interval, then back off retry
> times significantly because something more serious (or of
> lasting duration) is probably going on".  What Tony is
> suggesting is much like that, only with a much shorter initial
> retry time and a slower backoff rate.    That feels like "just
> about the same model, different parameters" rather than "new
> model".

Pretty much. The SMTP client is always going to have the infrastructure
to spool messages[1], the only change is to the scheduling algorithm it
uses. In the simplest case that might just be changing a timestamp.

Cheers,
  Steve

[1] Well, some SMTP clients don't have the ability to do that, instead
they pass any deferral off to an entirely different SMTP client on a
different IP address to do the retry, but the same reasoning applies

Subject: Re: draft-atkins-smtp-traffic-control
From: Steve Atkins <[email-masked]>
Date: Tue, 1 Nov 2011 12:09:42 -0700
To: SMTP Interest Group <[email-masked]>
Sender: [email-masked]

On Nov 1, 2011, at 11:59 AM, Douglas Otis wrote:

> 
> On 10/31/11 8:03 PM, Mark Andrews wrote:
>> Crypto is good at identifying returnees.  It does nothing in terms
>> of identifying whether a player is good or bad.  Unless there is a
>> way to map that identity into a reputation system, which can't be
>> gamed, it buys little in terms of spam prevention.
> 
> Agreed, crypto offers recognition of previous encounters.  A desire to make exchanges that traverse LSNs is clearly where something like Kerberos tickets can play a suitable role in offering a low overhead process.  Kerberos can also offer a lower frequency rate where it remains practical to identify all domains prior to issuing tickets.  Reputations MUST BE based on AUTHENTICATED identities.  Clearly, IPv6 makes use of IP Addresses as an identifier unsuitable.

None of which has anything to do with the subject line. Please take it to a spam filtering or reputation thread.

Cheers,
  Steve

Date: Tue, 01 Nov 2011 11:59:05 -0700
From: Douglas Otis <[email-masked]>
To: Mark Andrews <[email-masked]>
CC: "Murray S. Kucherawy" <[email-masked]>, SMTP Interest Group <[email-masked]>
Subject: Re: draft-atkins-smtp-traffic-control
Sender: [email-masked]

On 10/31/11 8:03 PM, Mark Andrews wrote:
> Crypto is good at identifying returnees.  It does nothing in terms
> of identifying whether a player is good or bad.  Unless there is a
> way to map that identity into a reputation system, which can't be
> gamed, it buys little in terms of spam prevention.

Agreed, crypto offers recognition of previous encounters.  A desire to 
make exchanges that traverse LSNs is clearly where something like 
Kerberos tickets can play a suitable role in offering a low overhead 
process.  Kerberos can also offer a lower frequency rate where it 
remains practical to identify all domains prior to issuing tickets.  
Reputations MUST BE based on AUTHENTICATED identities.  Clearly, IPv6 
makes use of IP Addresses as an identifier unsuitable.

-Doug

Date: Tue, 01 Nov 2011 09:17:26 -0400
From: John C Klensin <[email-masked]>
To: Tony Finch <[email-masked]>, Steve Atkins <[email-masked]>
cc: SMTP Interest Group <[email-masked]>
Subject: Re: draft-atkins-smtp-traffic-control
Sender: [email-masked]

--On Tuesday, November 01, 2011 12:47 +0000 Tony Finch
<[email-masked]> wrote:

> I was thinking higher but not much higher, e.g. have a
> starting interval of several minutes and increase it by a
> small percentage each time. If a site is deliberately
> deferring mail then prompt delivery is clearly less important
> to them than some other consideration, so it doesn't make much
> sense to bust a gut to deliver their mail asap.

The "retry strategy" text in RFC 5321 was written more on the
assumption that most cases would be connection failures, rather
than 4yz-induced retries.  It does not differentiate between the
two because, when 4yz really meant "system down or going down"
or "no service right now" on a global, rather than
sender-selective basis, it was reasonable to assume that a retry
within a short period of time would get a connection failure.

Combined with Tony's observation, this suggests two things to me:

(1) The difference between "not able to accept any mail right
now" and "trying to manage traffic" (or greylist, or...) really
may justify a different reply code set.

(2) Maybe the 4yz- (or new code)-induced retries aren't as
different from the traditional case as we have been assuming.
What 5321 recommends is, essentially, "wait 30 minutes or so,
try a couple of times at that interval, then back off retry
times significantly because something more serious (or of
lasting duration) is probably going on".  What Tony is
suggesting is much like that, only with a much shorter initial
retry time and a slower backoff rate.    That feels like "just
about the same model, different parameters" rather than "new
model".

     john

Date: Tue, 1 Nov 2011 12:47:24 +0000
From: Tony Finch <[email-masked]>
To: Steve Atkins <[email-masked]>
cc: SMTP Interest Group <[email-masked]>
Subject: Re: draft-atkins-smtp-traffic-control
Sender: [email-masked]

Steve Atkins <[email-masked]> wrote:
>
> Tony suggested that modifying SMTP clients to always retry 4xx responses
> at a much higher rate than is currently done would be a solution to
> that, and one that would be effectively free on the modern Internet.
> Which is a decent observation, for some SMTP servers.

I was thinking higher but not much higher, e.g. have a starting interval
of several minutes and increase it by a small percentage each time. If a
site is deliberately deferring mail then prompt delivery is clearly less
important to them than some other consideration, so it doesn't make much
sense to bust a gut to deliver their mail asap.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
FitzRoy, Sole: South 5 or 6, increasing 7 to severe gale 9. Rough or very
rough, occasionally high later. Showers then thundery rain. Moderate or good,
occasionally poor.