Subject: Re: Proprietary or non-standard SMTP AUTH mechanisms
From: Hector Santos <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 12 Jan 2012 22:30:50 -0500
List-Id: <ietf-smtp.imc.org>

Murray S. Kucherawy wrote:

> Do they deviate from the SMTP AUTH framework in any way, other than 
> maybe the method name?

No deviation other than a private method name, proprietary, but 
standard implementation of SMTP AUTH. Just a private/unique method 
100% designed for proprietary client entry only.

> That's really what I'm after.  If you do your own thing with its own 
> name but still stick to the general base64 and "334" and such, then 
> it's still compliant as far as the context about which I'm asking.

I see your point.

We consider it a trade secret and part of our corporate and legal 
security policy not divulge details, but frankly nothing special other 
than leveraging a standard protocol method including the client/server 
base64 SASL challenge/response handshaking and the expected SMTP AUTH 
reply codes that by design offers the flexibility to offer new 
methods, including non-standard ones.

While off hand at the moment I can't recall any specific method by 
name, I would swear there are quite a few of others private methods by 
just seeing some obscure/unknown AUTH names exposed in logs.  But I 
don't known if they were ever proposed I-D or not.

-- 
Sincerely

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

Date: Thu, 12 Jan 2012 12:53:52 -0800
From: "Carl S. Gutekunst" <[email-masked]>
To: "Murray S. Kucherawy" <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
Sender: [email-masked]

Murray S. Kucherawy wrote:
> If however there are extant or possible implementations that actually queue a message for spam evaluation by some other agent, and that's a totally separate step (even by separate software) than the basic message intake, then it makes sense to denote that as a state in this context.
>
> My own experience with various MTA implementations is that spam, virus, and other content evaluation is all part of the intake step, before it hits a queue where prolonged delay is likely.  That's why this is giving me quite a bit of pause.
>   
Shoveling the message off to another service for evaluation is indeed 
rare among stand-alone MTAs, but pretty common in cloud-based 
implementations, especially those that use a forest of single-purpose 
blades. There are frontends to SpamAssassin that support this as well.

<csg>

From: "Murray S. Kucherawy" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 12 Jan 2012 12:42:43 -0800
Subject: RE: Proprietary or non-standard SMTP AUTH mechanisms
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Hector Santos
> Sent: Thursday, January 12, 2012 12:31 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Proprietary or non-standard SMTP AUTH mechanisms
> 
> We have a few proprietary SMTP AUTH mechanism. The design goal was to
> lower the development overhead for coding the standard mechanisms, or
> the need for encryption and SSL libraries for our proprietary mail/user
> clients. For an example, the GUI Frontend Navigator client:
> 
>         http://www.winserver.com/public/wcnavigator.wct
> 
> provided by our operators to their users, uses an internal SMTP AUTH
> mechanism to send mail to its online backend connected local server
> only.   In the past, only IP was used, but with dynamic IPs or mail
> bot clients moved around, SMTP AUTH helps here.

Do they deviate from the SMTP AUTH framework in any way, other than maybe the method name?

That's really what I'm after.  If you do your own thing with its own name but still stick to the general base64 and "334" and such, then it's still compliant as far as the context about which I'm asking.

-MSK

From: "Murray S. Kucherawy" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 12 Jan 2012 12:40: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: Carl S. Gutekunst [mailto:[email-masked]]
> Sent: Thursday, January 12, 2012 11:47 AM
> To: Robert A. Rosenberg
> Cc: Murray S. Kucherawy; [email-masked]
> Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
> 
> Offline or deferred processing for potential threats or detecting
> policy violations is pretty common. But the keyword "spam" is a
> judgment, not a reason. How about verbs like "study", "analyze", or
> even "filter"?

I was thinking about "content-eval" as a generic, and then the implementation could use a comment after that to be more specific, e.g. "state content-eval (spam checking)".  The ABNF already allows this.

From: "Murray S. Kucherawy" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 12 Jan 2012 12:39:44 -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: Robert A. Rosenberg [mailto:[email-masked]]
> Sent: Thursday, January 12, 2012 11:11 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> Subject: RE: FW: I-D Action: draft-kucherawy-received-state-00.txt
> 
> I was thinking of checking the message to see if it were possible spam.
> You might have some cases where your processing can not do an immediate
> SPAM/HAM determination but have some delay in making that decision.
> Thus the spam state while the message is delayed while the extended
> check is being done.

OK, this makes more sense.  What I'd seen so far suggested using "state spam" to indicate that the agent adding the field tagged it as spam.  The intent here is to show a transition into a processing state.  The particular impact I'm hoping to enable is the ability to see why there was a delay between timestamps.

If however there are extant or possible implementations that actually queue a message for spam evaluation by some other agent, and that's a totally separate step (even by separate software) than the basic message intake, then it makes sense to denote that as a state in this context.

My own experience with various MTA implementations is that spam, virus, and other content evaluation is all part of the intake step, before it hits a queue where prolonged delay is likely.  That's why this is giving me quite a bit of pause.

Date: Thu, 12 Jan 2012 15:31:25 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
CC: "[email-masked]" <[email-masked]>
Subject: Re: Proprietary or non-standard SMTP AUTH mechanisms
To: [email-masked]
Sender: [email-masked]

We have a few proprietary SMTP AUTH mechanism. The design goal was to 
lower the development overhead for coding the standard mechanisms, or 
the need for encryption and SSL libraries for our proprietary 
mail/user clients. For an example, the GUI Frontend Navigator client:

        http://www.winserver.com/public/wcnavigator.wct

provided by our operators to their users, uses an internal SMTP AUTH 
mechanism to send mail to its online backend connected local server 
only.   In the past, only IP was used, but with dynamic IPs or mail 
bot clients moved around, SMTP AUTH helps here.

Murray S. Kucherawy wrote:
> Are there any known proprietary or other non-standard SMTP AUTH mechanisms that deviate from the syntax specified un RFC4954?
> 
> For example, is there an unofficial SMTP AUTH mechanism that allows unencoded binary data in the challenges or responses?  A vendor controlling both the client and the server could get away with something like that, but something standards-based analyzing that traffic might be confused by it.
> 
> Thanks,
> -MSK
> 
> 

-- 
Sincerely

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

Date: Thu, 12 Jan 2012 11:47:13 -0800
From: "Carl S. Gutekunst" <[email-masked]>
To: "Robert A. Rosenberg" <[email-masked]>
CC: "Murray S. Kucherawy" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
Sender: [email-masked]

Robert A. Rosenberg wrote:
>> If a "spam" state were to exist, what are the conditions under which 
>> it would be released for processing and delivery?
>>
>
> I was thinking of checking the message to see if it were possible 
> spam. You might have some cases where your processing can not do an 
> immediate SPAM/HAM determination but have some delay in making that 
> decision. Thus the spam state while the message is delayed while the 
> extended check is being done. 

Offline or deferred processing for potential threats or detecting policy 
violations is pretty common. But the keyword "spam" is a judgment, not a 
reason. How about verbs like "study", "analyze", or even "filter"?

("Weigh" and "adjudge" are arguable more accurate, except no one would 
have idea what they mean. Which is heavier, ham or spam?)

<csg>

Date: Thu, 12 Jan 2012 14:11:21 -0500
To: "Murray S. Kucherawy" <[email-masked]>
From: "Robert A. Rosenberg" <[email-masked]>
Subject: RE: FW: I-D Action: draft-kucherawy-received-state-00.txt
Cc: "[email-masked]" <[email-masked]>
Sender: [email-masked]

At 22:30 -0800 on 01/11/2012, Murray S. Kucherawy wrote about Re: FW: 
I-D Action: draft-kucherawy-received-state-00.txt:

>  > -----Original Message-----
>>  From: Robert A. Rosenberg [mailto:[email-masked]]
>>  Sent: Wednesday, January 11, 2012 9:20 PM
>>  To: [email-masked]
>>  Cc: Murray S. Kucherawy; [email-masked]; Dave CROCKER
>>  Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
>> 
>>  That depends on the meaning of the SPAM state. If it means checking if
>>  the message IS spam that is different from it meaning that the message
>>  has been identified AS spam. You are treating as the latter when the
>>  intent might be the former (ie: The check might introduce a delay in
>>  processing the message so you are marking it to show the reason for the
>>  delay).
>
>I don't know what it means for a message to be in a "spam" state.
>
>A message in a "hold for moderation" state means it's stuck in a 
>queue until a moderator does something with it.
>
>A message in a "quarantine" state means it's quarantined, 
>inaccessible, until an operator brings it out or destroys it.
>
>A message in a "timed" state means it's held in a queue until a 
>certain release time arrives.
>
>All of these are states that cause processing delays, but ultimately 
>from which the message will be released.
>
>If a "spam" state were to exist, what are the conditions under which 
>it would be released for processing and delivery?
>
>-MSK

I was thinking of checking the message to see if it were possible 
spam. You might have some cases where your processing can not do an 
immediate SPAM/HAM determination but have some delay in making that 
decision. Thus the spam state while the message is delayed while the 
extended check is being done.

Date: Thu, 12 Jan 2012 17:31:19 +0000
From: Alexey Melnikov <[email-masked]>
To: John C Klensin <[email-masked]>
CC: "Murray S. Kucherawy" <[email-masked]>, [email-masked]
Subject: Re: Proprietary or non-standard SMTP AUTH mechanisms
Sender: [email-masked]

On 12/01/2012 16:14, John C Klensin wrote:
> --On Thursday, January 12, 2012 10:12 +0000 Alexey Melnikov
> <[email-masked]>  wrote:
>
>>> For example, is there an unofficial SMTP AUTH mechanism that
>>> allows  unencoded binary data in the challenges or responses?
>>> A vendor  controlling both the client and the server could
>>> get away with  something like that, but something
>>> standards-based analyzing that  traffic might be confused by
>>> it.
>>>
>> All SASL exchange data in SMTP must be base64 encoded, so no
>> unencoded binary data can ever occur if IETF standards are
>> followed.
> Alexey,
Hi John,
> Yes, but I don't think that was Murray's question.  SMTP AUTH
> was originally designed in the absence of SASL.  We hope all
> non-SASL applications/implementations have disappeared, but I
> wouldn't count on it.   When we designed CRAM-MD5, we were at
> least vaguely aware of an assortment of cookie/ shared
> not-very-secret approaches floating around, some of which relied
> on binary data.  I hope those have disappeared too, but I have
> no way to verify that they have.
>
> What people forget as they quibble about the security properties
> of CRAM-MD5 was that it was specified precisely to illustrate
> that something was possible that would not require much more
> server effort and support than plain-text passwords (a
> requirement that Kerberos and assorted digital signature plans
> could not satisfy) and that would be at least a tad more secure
> against eavesdropping than either those passwords or [other]
> cleartext shared secrets.  Our goal wasn't "high security
> mechanism" (we knew how to do those), but "significantly better
> than clear text" and that largely to prove a point in the IETF.
>
> But security by obscurity always has some appeal, especially
> when eavesdropping in the transmission channel are not believed
> to be issues, and old SMTP implementations tend to linger around
> as long as they are still perceived as working (e.g., no new
> feature appears that they don't have and that is considered
> important).  So I don't have much confidence that all of those
> old cases have been eliminated and Murray's question, at least
> as I understood it, starts me muttering about proving universal
> negatives.
While what you say is possible (AUTH= hack is a proof), the requirement 
for base64 encoding AUTH exchange comes from 
draft-myers-smtp-auth-00.txt dated April 1995 (which later became RFC 
2554). So it looks like binary data was never allowed in SMTP AUTH.

(In general SASL mechanisms can exchange arbitrary binary data. How such 
data is transfered on the wire is defined by protocols that use SASL.)

Date: Thu, 12 Jan 2012 11:14:20 -0500
From: John C Klensin <[email-masked]>
To: Alexey Melnikov <[email-masked]>, "Murray S. Kucherawy" <[email-masked]>
cc: [email-masked]
Subject: Re: Proprietary or non-standard SMTP AUTH mechanisms
Sender: [email-masked]

--On Thursday, January 12, 2012 10:12 +0000 Alexey Melnikov
<[email-masked]> wrote:

>> For example, is there an unofficial SMTP AUTH mechanism that
>> allows  unencoded binary data in the challenges or responses?
>> A vendor  controlling both the client and the server could
>> get away with  something like that, but something
>> standards-based analyzing that  traffic might be confused by
>> it.
>> 
> All SASL exchange data in SMTP must be base64 encoded, so no
> unencoded binary data can ever occur if IETF standards are
> followed.

Alexey,

Yes, but I don't think that was Murray's question.  SMTP AUTH
was originally designed in the absence of SASL.  We hope all
non-SASL applications/implementations have disappeared, but I
wouldn't count on it.   When we designed CRAM-MD5, we were at
least vaguely aware of an assortment of cookie/ shared
not-very-secret approaches floating around, some of which relied
on binary data.  I hope those have disappeared too, but I have
no way to verify that they have.

What people forget as they quibble about the security properties
of CRAM-MD5 was that it was specified precisely to illustrate
that something was possible that would not require much more
server effort and support than plain-text passwords (a
requirement that Kerberos and assorted digital signature plans
could not satisfy) and that would be at least a tad more secure
against eavesdropping than either those passwords or [other]
cleartext shared secrets.  Our goal wasn't "high security
mechanism" (we knew how to do those), but "significantly better
than clear text" and that largely to prove a point in the IETF.

But security by obscurity always has some appeal, especially
when eavesdropping in the transmission channel are not believed
to be issues, and old SMTP implementations tend to linger around
as long as they are still perceived as working (e.g., no new
feature appears that they don't have and that is considered
important).  So I don't have much confidence that all of those
old cases have been eliminated and Murray's question, at least
as I understood it, starts me muttering about proving universal
negatives.

    john

Date: Thu, 12 Jan 2012 10:12:45 +0000
From: Alexey Melnikov <[email-masked]>
To: "Murray S. Kucherawy" <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: Proprietary or non-standard SMTP AUTH mechanisms
Sender: [email-masked]

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

On 11/01/2012 23:46, Murray S. Kucherawy wrote:
>
> Are there any known proprietary or other non-standard SMTP AUTH 
> mechanisms that deviate from the syntax specified un RFC4954?
>
Not that I know of.
>
> For example, is there an unofficial SMTP AUTH mechanism that allows 
> unencoded binary data in the challenges or responses?  A vendor 
> controlling both the client and the server could get away with 
> something like that, but something standards-based analyzing that 
> traffic might be confused by it.
>
All SASL exchange data in SMTP must be base64 encoded, so no unencoded 
binary data can ever occur if IETF standards are followed.

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

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 11/01/2012 23:46, Murray S. Kucherawy wrote:
    <blockquote
cite="mid:[email-masked]"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <meta name="Generator" content="Microsoft Word 12 (filtered
        medium)">
      <style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
      <div class="WordSection1">
        <p class="MsoNormal">Are there any known proprietary or other
          non-standard SMTP AUTH mechanisms that deviate from the syntax
          specified un RFC4954?</p>
      </div>
    </blockquote>
    Not that I know of.<br>
    <blockquote
cite="mid:[email-masked]"
      type="cite">
      <div class="WordSection1">
        <p class="MsoNormal"><o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p>For example, is there an
          unofficial SMTP AUTH mechanism that allows unencoded binary
          data in the challenges or responses?&nbsp; A vendor controlling
          both the client and the server could get away with something
          like that, but something standards-based analyzing that
          traffic might be confused by it.</p>
      </div>
    </blockquote>
    All SASL exchange data in SMTP must be base64 encoded, so no
    unencoded binary data can ever occur if IETF standards are followed.<br>
    <br>
  </body>
</html>

--------------080806010906080908020501--

From: "Murray S. Kucherawy" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 11 Jan 2012 22:30:08 -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: Robert A. Rosenberg [mailto:[email-masked]]
> Sent: Wednesday, January 11, 2012 9:20 PM
> To: [email-masked]
> Cc: Murray S. Kucherawy; [email-masked]; Dave CROCKER
> Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
>  
> That depends on the meaning of the SPAM state. If it means checking if
> the message IS spam that is different from it meaning that the message
> has been identified AS spam. You are treating as the latter when the
> intent might be the former (ie: The check might introduce a delay in
> processing the message so you are marking it to show the reason for the
> delay).

I don't know what it means for a message to be in a "spam" state.

A message in a "hold for moderation" state means it's stuck in a queue until a moderator does something with it.

A message in a "quarantine" state means it's quarantined, inaccessible, until an operator brings it out or destroys it.

A message in a "timed" state means it's held in a queue until a certain release time arrives.

All of these are states that cause processing delays, but ultimately from which the message will be released.

If a "spam" state were to exist, what are the conditions under which it would be released for processing and delivery?

-MSK

Date: Thu, 12 Jan 2012 00:20:07 -0500
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
Cc: "Murray S. Kucherawy" <[email-masked]>, "[email-masked]" <[email-masked]>, Dave CROCKER <[email-masked]>
Sender: [email-masked]

At 10:15 -0800 on 01/10/2012, Dave CROCKER wrote about Re: FW: I-D 
Action: draft-kucherawy-received-state-00.txt:

>On 1/10/2012 10:02 AM, Murray S. Kucherawy wrote:
>>>>  Those aren't queueing states though; they're metadata about the message.
>>>
>>>  I think I don't understand what this means.
>>
>>  The example given was "spam", which strikes me as a label attached to a
>>  message somehow (perhaps as metadata) and not a phase of message handling
>>  enroute to its destination.
>
>This suggests a confusion about the clause.  Does it provide a label 
>to explain
>the specific Received field or does it label the message?  I think that having
>it used as a label for the message is just plain wrong.  Put those 
>somewhere else.

That depends on the meaning of the SPAM state. If it means checking 
if the message IS spam that is different from it meaning that the 
message has been identified AS spam. You are treating as the latter 
when the intent might be the former (ie: The check might introduce a 
delay in processing the message so you are marking it to show the 
reason for the delay).

From: "Murray S. Kucherawy" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 11 Jan 2012 15:46:48 -0800
Subject: Proprietary or non-standard SMTP AUTH mechanisms
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

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

Are there any known proprietary or other non-standard SMTP AUTH mechanisms =
that deviate from the syntax specified un RFC4954?

For example, is there an unofficial SMTP AUTH mechanism that allows unencod=
ed binary data in the challenges or responses?  A vendor controlling both t=
he client and the server could get away with something like that, but somet=
hing standards-based analyzing that traffic might be confused by it.

Thanks,
-MSK

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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV=3D"Content-Type" CONTENT=
=3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros=
oft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli=
nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal>Are there any kn=
own proprietary or other non-standard SMTP AUTH mechanisms that deviate fro=
m the syntax specified un RFC4954?<o:p></o:p></p><p class=3DMsoNormal><o:p>=
&nbsp;</o:p></p><p class=3DMsoNormal>For example, is there an unofficial SM=
TP AUTH mechanism that allows unencoded binary data in the challenges or re=
sponses?&nbsp; A vendor controlling both the client and the server could ge=
t away with something like that, but something standards-based analyzing th=
at traffic might be confused by it.<o:p></o:p></p><p class=3DMsoNormal><o:p=
>&nbsp;</o:p></p><p class=3DMsoNormal>Thanks,<o:p></o:p></p><p class=3DMsoN=
ormal>-MSK<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p></div></=
body></html>=

--_000_F5833273385BB34F99288B3648C4F06F19C6C1582FEXCHC2corpclo_--

Date: Wed, 11 Jan 2012 16:57:05 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: [email-masked]
Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
Sender: [email-masked]

Tony Finch wrote:

>> The problem with this is lack of flexibility.
> 
> Which is why the Received: header can be extended with other clauses for
> other purposes. We don't need multiple layers of genericity here.

+1, ideal, but will most likely required the larger code change, in 
logic flow and when to add the Received since it has to be at the top 
for the current hop.

-- 
Sincerely

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

Date: Wed, 11 Jan 2012 16:12:17 +0000
From: Tony Finch <[email-masked]>
To: [email-masked]
cc: John Levine <[email-masked]>, [email-masked]
Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
Sender: [email-masked]

Dave CROCKER <[email-masked]> wrote:
> On 1/10/2012 9:26 AM, John Levine wrote:
> >
> > Well, yeah, but there are a lot of kind of states other than queueing
> > states.  That's why I'd suggest a keyword that tells you this is about
> > queues or delays or something.
>
> This puts the specific semantic into the definition of the clause, rather than
> the value used in the clause.

Just like the other Received: header clauses.

> The problem with this is lack of flexibility.

Which is why the Received: header can be extended with other clauses for
other purposes. We don't need multiple layers of genericity here.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Lundy, Fastnet, Irish Sea, Shannon: Southwest, veering west or northwest, 4 or
5, increasing 6 or 7 for a time in Irish Sea and Shannon. Slight or moderate,
occasionally rough in Fastnet and Shannon. Occasional rain. Moderate or good.

Date: Wed, 11 Jan 2012 16:05:56 +0000
From: Tony Finch <[email-masked]>
To: John Levine <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
Sender: [email-masked]

John Levine <[email-masked]> wrote:
>
> Other nits: if this is really about deliberate delays, I'd suggest
> using a term like "queued" or "delay" or "hold" rather than "state".
> I can think of states that might be interesting but don't involve a
> delay, e.g. characterized as spam, or downcoded from 8 bits to 6 bits.

I agree and I have previously made the same suggestion.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Tyne, Dogger, Fisher, German Bight, Humber: West or southwest, veering
northwest later, 4 or 5, increasing 6 to gale 8, occasionally severe gale 9 in
Fisher, perhaps severe gale 9 later in Tyne, Dogger and German Bight. Moderate
or rough, occasionally very rough. Rain or squally showers. Moderate or good.

Date: Tue, 10 Jan 2012 21:28:20 +0100
From: "Rolf E. Sonneveld" <[email-masked]>
To: [email-masked]
Cc: Dave CROCKER <[email-masked]>, "Murray S. Kucherawy" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
Sender: [email-masked]

On 1/10/12 8:01 PM, Dave CROCKER wrote:
>
>
>
> On 1/10/2012 10:21 AM, Murray S. Kucherawy wrote:
>>> OK.  Putting this simplistically, we already have lots of Received: 
>>> fields
>>> being generated and we should have a clause value that covers this
>>> probably-uninteresting set?  I suggest "normal" or somesuch, not 
>>> "none".
>>> The message, /is/ after all, making a transition.  Whatever state or 
>>> queue
>>> it just entered, it does exist.
>>
>> John suggested what's essentially a no-op state name to accommodate 
>> those
>> implementations that, in supporting this, will always want to put 
>> some kind
>> of state clause down, and that seems a decent idea to me.
>>
>> "normal" would be fine with me too.
>
>
> Doing what sales folk call "selling past the sale" I'll note that 
> there is no such thing as a no-op, since the presence of the Received: 
> field means that some sort of 'op' took place.  So the question is 
> what the "nature" of the op is. 

The "nature" of the op (or no-op) is 'received'. I.e. the message was 
received. A state of 'received' more or less duplicates the header name 
(Received), but if there needs to be a no-op state, then let's call it 
just 'received'.

/rolf

From: "Murray S. Kucherawy" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 10 Jan 2012 11:18:45 -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 John Levine
> Sent: Tuesday, January 10, 2012 11:11 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
> 
> >If the new clause is only for delays, then we can't extend use of the
> >clause to cover extra processing steps.  If the label is for more
> >general use, then we can.
> 
> That's OK, but now I'm wondering if the syntax should allow a list of
> states rather than just one
> 
> Received: blah blah STATE DOWNCODED-TO-7,MODERATED blah blah

I don't think we're talking about this kind of metadata here.  Really this is meant to talk about a delay introduced while waiting for something to happen, usually operator intervention of some kind (quarantine, list moderation).  An automatic step like downcoding or (for another example) virus scrubbing only introduces a compute delay and a bit of I/O, not an enforced usually-human-caused delay like the other cases.

Date: 10 Jan 2012 19:10:45 -0000
From: "John Levine" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
Organization: 
Sender: [email-masked]

>If the new clause is only for delays, then we can't extend use of the clause to 
>cover extra processing steps.  If the label is for more general use,
>then we can.

That's OK, but now I'm wondering if the syntax should allow a list of
states rather than just one

> Received: blah blah STATE DOWNCODED-TO-7,MODERATED blah blah

I suppose you could use two received headers for two states, but that
seems unlike the way people use them now.

R's,
John

Date: Tue, 10 Jan 2012 11:01:32 -0800
From: Dave CROCKER <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: "Murray S. Kucherawy" <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
Sender: [email-masked]

On 1/10/2012 10:21 AM, Murray S. Kucherawy wrote:
>> OK.  Putting this simplistically, we already have lots of Received: fields
>> being generated and we should have a clause value that covers this
>> probably-uninteresting set?  I suggest "normal" or somesuch, not "none".
>> The message, /is/ after all, making a transition.  Whatever state or queue
>> it just entered, it does exist.
>
> John suggested what's essentially a no-op state name to accommodate those
> implementations that, in supporting this, will always want to put some kind
> of state clause down, and that seems a decent idea to me.
>
> "normal" would be fine with me too.

Doing what sales folk call "selling past the sale" I'll note that there is no 
such thing as a no-op, since the presence of the Received: field means that some 
sort of 'op' took place.  So the question is what the "nature" of the op is.  A 
label like "normal" therefore can cover the existing header fields with a 
generic term for the nature.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From: "Murray S. Kucherawy" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 10 Jan 2012 10:21:11 -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: Dave CROCKER [mailto:[email-masked]]
> Sent: Tuesday, January 10, 2012 10:15 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
> 
> This suggests a confusion about the clause.  Does it provide a label to
> explain the specific Received field or does it label the message?  I
> think that having it used as a label for the message is just plain
> wrong.  Put those somewhere else.

+1.

> OK.  Putting this simplistically, we already have lots of Received:
> fields being generated and we should have a clause value that covers
> this probably-uninteresting set?  I suggest "normal" or somesuch, not
> "none".  The message, /is/ after all, making a transition.  Whatever
> state or queue it just entered, it does exist.

John suggested what's essentially a no-op state name to accommodate those implementations that, in supporting this, will always want to put some kind of state clause down, and that seems a decent idea to me.

"normal" would be fine with me too.

-MSK

Date: Tue, 10 Jan 2012 10:15:15 -0800
From: Dave CROCKER <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: "Murray S. Kucherawy" <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
Sender: [email-masked]

On 1/10/2012 10:02 AM, Murray S. Kucherawy wrote:
>>> Those aren't queueing states though; they're metadata about the message.
>>
>> I think I don't understand what this means.
>
> The example given was "spam", which strikes me as a label attached to a
> message somehow (perhaps as metadata) and not a phase of message handling
> enroute to its destination.

This suggests a confusion about the clause.  Does it provide a label to explain 
the specific Received field or does it label the message?  I think that having 
it used as a label for the message is just plain wrong.  Put those somewhere else.

>> Use of the clause requires a new Received header field.  The condition the
>> 'none' value seems intended for is for typical header fields as are
>> generated today.  Either these should get meaningful labels or the existing
>> label 'other' should suffice.
>
> I think "other" implies the message is entering some kind of queue state that
> will introduce an atypical delay, where "none" is an explicit statement that
> this is not the case.  They are semantically different.

OK.  Putting this simplistically, we already have lots of Received: fields being 
generated and we should have a clause value that covers this 
probably-uninteresting set?  I suggest "normal" or somesuch, not "none".  The 
message, /is/ after all, making a transition.  Whatever state or queue it just 
entered, it does exist.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Tue, 10 Jan 2012 13:02:21 -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]

+1 Dave.

My Take:

1) This should be a MAY implement
2) It can only be a SHOULD with a presumption of other ideas already
    existing.

Its like I MAY build a house, and if I do, I SHOULD do certain things 
expected in building a house.

This should not say I SHOULD build a house.

Dave CROCKER wrote:
> 
> 
> 
> On 1/9/2012 10:50 PM, Murray S. Kucherawy wrote:
>> I just changed it to MAY, on the grounds that it will probably be 
>> user/admin
>> pressure that gets the feature added rather than something normative 
>> (e.g.,
>> nobody requires this, but all the cool kids do it).
> 
> Mumble.  Although I can see the merit in choosing MAY, I suggest you 
> revert to SHOULD.
> 
> This is a point of continuing confusion.  Does the normative language in 
> an extension spec mean "relative to the overall service" or "relative to 
> /this/ specification?
> 
> And then there is the usual debate about degree of importance that 
> guides must/may/should.
> 
> My take:
> 
>      If we think use of the STATE clause is nice but not all that 
> important, then the normative word should be MAY.  If we think this can 
> have significant benefit and especially when widely adopted, the word 
> should be SHOULD.
> 
> We could argue that email has done well enough without it for many 
> years, so this should be MAY.  We could also argue that obscure delays 
> are a significant problem and that the current scale of Internet mail 
> and challenges in diagnosing problems means that it's important to guide 
> potential implementers about the importance of implementing this.
> 
> I prefer SHOULD.
> 
> We need better insight into mail transit.
> 
> 
>>> Other nits: if this is really about deliberate delays, I'd suggest 
>>> using a
>>> term like "queued" or "delay" or "hold" rather than "state". I can 
>>> think of
>>> states that might be interesting but don't involve a delay, e.g.
>>> characterized as spam, or downcoded from 8 bits to 6 bits.
> 
> The choice of word affects possible later use.  STATE makes is 
> reasonable to consider other uses.  DELAY or HOLD constrain the used.  
> QUEUED strikes me as synonymous with STATE, actually.
> 
> 
>> Those aren't queueing states though; they're metadata about the message.
> 
> I think I don't understand what this means.
> 
> The choice of the word STATE does imply that there is a grand state 
> machine that describes handling of the message and that this annotation 
> records the timing of a transition through it.  The implication is correct.
> 
> While the motivation for this annotation is to account for unusual 
> delays, I do not see why the semantics of the clause label needs to be 
> limited to that more constrained semantic.  Using the more general label 
> does not make the software for the clause more complex; but it does make 
> it easier to consider extended use, later.
> 
> 
>> I saw "state downcode", I'd conclude that the time gap implied by the 
>> delta
>> between adjacent Received fields indicated the amount of time that 
>> host spent
>> downcoding the message.
>>
>>> Also, it might be a good idea to have a state name for no delay, e.g
>>> "queued none", both for the benefit of dorky software that always 
>>> wants to
>>> put the same set of clauses in its Received: headers, and to provide an
>>> explicit way to say hey, this delay wasn't my idea.
>>
>> That's not a bad idea.  Thanks.
> 
> Use of the clause requires a new Received header field.  The condition 
> the 'none' value seems intended for is for typical header fields as are 
> generated today.  Either these should get meaningful labels or the 
> existing label 'other' should suffice.
> 
> d/
> 

-- 
Sincerely

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

From: "Murray S. Kucherawy" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 10 Jan 2012 10:02:08 -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: Dave CROCKER [mailto:[email-masked]]
> Sent: Tuesday, January 10, 2012 8:02 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
> 
> > Those aren't queueing states though; they're metadata about the
> > message.
> 
> I think I don't understand what this means.

The example given was "spam", which strikes me as a label attached to a message somehow (perhaps as metadata) and not a phase of message handling enroute to its destination.

> Use of the clause requires a new Received header field.  The condition
> the 'none' value seems intended for is for typical header fields as are
> generated today.  Either these should get meaningful labels or the
> existing label 'other'
> should suffice.

I think "other" implies the message is entering some kind of queue state that will introduce an atypical delay, where "none" is an explicit statement that this is not the case.  They are semantically different.

From: "Murray S. Kucherawy" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 10 Jan 2012 09:59:33 -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: John Levine [mailto:[email-masked]]
> Sent: Tuesday, January 10, 2012 9:26 AM
> To: [email-masked]
> Cc: Murray S. Kucherawy
> Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
> 
> It seems reasonable to use MUSTard that assumes that the reader is
> going to implement this spec, in which case it's SHOULD and
> RECOMMENDED.  Or not, in which case it's MAY and OPTIONAL.

Then given this and Dave's post, I'm inclined to go back to SHOULD.

> It wasn't
> clear to me that you're only expected to add the clause when you queue
> the message for longer than normal, but that should be easy enough to
> fix.

The second paragraph of the Introduction section is meant to make this plain, i.e., that you do this for anything other than queue-for-later-when-transport-fails.  Can you suggest wording tweaks?

> Well, yeah, but there are a lot of kind of states other than queueing
> states.  That's why I'd suggest a keyword that tells you this is about
> queues or delays or something.

I've never heard "spam" (your example) used as part of a state machine.  It's essentially a label attached to a message, not a phase of handling while a message is in transit.

-MSK

Date: Tue, 10 Jan 2012 09:53:06 -0800
From: Dave CROCKER <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: John Levine <[email-masked]>
CC: [email-masked]
Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
Sender: [email-masked]

On 1/10/2012 9:26 AM, John Levine wrote:
>> Those aren't queueing states though; they're metadata about the message.
>> >If I saw "state downcode", I'd conclude that the time gap implied by the
>> >delta between adjacent Received fields indicated the amount of time that
>> >host spent downcoding the message.
> Well, yeah, but there are a lot of kind of states other than queueing
> states.  That's why I'd suggest a keyword that tells you this is about
> queues or delays or something.

This puts the specific semantic into the definition of the clause, rather than 
the value used in the clause.

The problem with this is lack of flexibility.

For example, it could be noteworthy to record a processing step that introduces 
no interesting delay.

If the new clause is only for delays, then we can't extend use of the clause to 
cover extra processing steps.  If the label is for more general use, then we can.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: 10 Jan 2012 17:26:24 -0000
From: "John Levine" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
Organization: 
Sender: [email-masked]

>> In that case, suggest changing the OPTIONAL to something like
>> "RECOMMENDED if the message has been held."
>
>But RECOMMENDED is the same as SHOULD, to which you originally objected.

Quoting Abraham Lincoln*, when a judge pointed out that he was arguing
the opposite position from one in a case earlier in the day, "Your honor,
this morning I was wrong."

It seems reasonable to use MUSTard that assumes that the reader is going
to implement this spec, in which case it's SHOULD and RECOMMENDED.  Or not,
in which case it's MAY and OPTIONAL.  It wasn't clear to me that you're
only expected to add the clause when you queue the message for longer
than normal, but that should be easy enough to fix.

>> Other nits: if this is really about deliberate delays, I'd suggest
>> using a term like "queued" or "delay" or "hold" rather than "state".
>> I can think of states that might be interesting but don't involve a
>> delay, e.g. characterized as spam, or downcoded from 8 bits to 6 bits.
>
>Those aren't queueing states though; they're metadata about the message.
>If I saw "state downcode", I'd conclude that the time gap implied by the
>delta between adjacent Received fields indicated the amount of time that
>host spent downcoding the message.

Well, yeah, but there are a lot of kind of states other than queueing
states.  That's why I'd suggest a keyword that tells you this is about
queues or delays or something.

R's,
John

* - an American politician of the Victorian era, a contemporary of MacDonald

Date: Tue, 10 Jan 2012 08:02:02 -0800
From: Dave CROCKER <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: "Murray S. Kucherawy" <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
Sender: [email-masked]

On 1/9/2012 10:50 PM, Murray S. Kucherawy wrote:
> I just changed it to MAY, on the grounds that it will probably be user/admin
> pressure that gets the feature added rather than something normative (e.g.,
> nobody requires this, but all the cool kids do it).

Mumble.  Although I can see the merit in choosing MAY, I suggest you revert to 
SHOULD.

This is a point of continuing confusion.  Does the normative language in an 
extension spec mean "relative to the overall service" or "relative to /this/ 
specification?

And then there is the usual debate about degree of importance that guides 
must/may/should.

My take:

      If we think use of the STATE clause is nice but not all that important, 
then the normative word should be MAY.  If we think this can have significant 
benefit and especially when widely adopted, the word should be SHOULD.

We could argue that email has done well enough without it for many years, so 
this should be MAY.  We could also argue that obscure delays are a significant 
problem and that the current scale of Internet mail and challenges in diagnosing 
problems means that it's important to guide potential implementers about the 
importance of implementing this.

I prefer SHOULD.

We need better insight into mail transit.

>> Other nits: if this is really about deliberate delays, I'd suggest using a
>> term like "queued" or "delay" or "hold" rather than "state". I can think of
>> states that might be interesting but don't involve a delay, e.g.
>> characterized as spam, or downcoded from 8 bits to 6 bits.

The choice of word affects possible later use.  STATE makes is reasonable to 
consider other uses.  DELAY or HOLD constrain the used.  QUEUED strikes me as 
synonymous with STATE, actually.

> Those aren't queueing states though; they're metadata about the message.

I think I don't understand what this means.

The choice of the word STATE does imply that there is a grand state machine that 
describes handling of the message and that this annotation records the timing of 
a transition through it.  The implication is correct.

While the motivation for this annotation is to account for unusual delays, I do 
not see why the semantics of the clause label needs to be limited to that more 
constrained semantic.  Using the more general label does not make the software 
for the clause more complex; but it does make it easier to consider extended 
use, later.

> I saw "state downcode", I'd conclude that the time gap implied by the delta
> between adjacent Received fields indicated the amount of time that host spent
> downcoding the message.
>
>> Also, it might be a good idea to have a state name for no delay, e.g
>> "queued none", both for the benefit of dorky software that always wants to
>> put the same set of clauses in its Received: headers, and to provide an
>> explicit way to say hey, this delay wasn't my idea.
>
> That's not a bad idea.  Thanks.

Use of the clause requires a new Received header field.  The condition the 
'none' value seems intended for is for typical header fields as are generated 
today.  Either these should get meaningful labels or the existing label 'other' 
should suffice.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From: "Murray S. Kucherawy" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 9 Jan 2012 22:50:45 -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: John Levine [mailto:[email-masked]]
> Sent: Monday, January 09, 2012 9:13 PM
> To: [email-masked]
> Cc: Murray S. Kucherawy
> Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
> 
> In that case, suggest changing the OPTIONAL to something like
> "RECOMMENDED if the message has been held."

But RECOMMENDED is the same as SHOULD, to which you originally objected.  The "if the message has been held" is implicit in the idea that this is only used if some kind of administrative hold has been imposed (rather than caused by a transport anomaly).

I just changed it to MAY, on the grounds that it will probably be user/admin pressure that gets the feature added rather than something normative (e.g., nobody requires this, but all the cool kids do it).

> Other nits: if this is really about deliberate delays, I'd suggest
> using a term like "queued" or "delay" or "hold" rather than "state".
> I can think of states that might be interesting but don't involve a
> delay, e.g. characterized as spam, or downcoded from 8 bits to 6 bits.

Those aren't queueing states though; they're metadata about the message.  If I saw "state downcode", I'd conclude that the time gap implied by the delta between adjacent Received fields indicated the amount of time that host spent downcoding the message.

> Also, it might be a good idea to have a state name for no delay, e.g
> "queued none", both for the benefit of dorky software that always wants
> to put the same set of clauses in its Received: headers, and to provide
> an explicit way to say hey, this delay wasn't my idea.

That's not a bad idea.  Thanks.

-MSK

Date: 10 Jan 2012 05:13:03 -0000
From: "John Levine" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
Organization: 
Sender: [email-masked]

>But since you're the second person to mention that, I guess some
>wordsmithing is in order to make that clear.

In that case, suggest changing the OPTIONAL to something like "RECOMMENDED
if the message has been held."

Other nits: if this is really about deliberate delays, I'd suggest
using a term like "queued" or "delay" or "hold" rather than "state".
I can think of states that might be interesting but don't involve a
delay, e.g. characterized as spam, or downcoded from 8 bits to 6 bits.

Also, it might be a good idea to have a state name for no delay, e.g
"queued none", both for the benefit of dorky software that always wants
to put the same set of clauses in its Received: headers, and to provide
an explicit way to say hey, this delay wasn't my idea.

R's,
John

From: "Murray S. Kucherawy" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 9 Jan 2012 20:17:25 -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: John Levine [mailto:[email-masked]]
> Sent: Monday, January 09, 2012 8:08 PM
> To: [email-masked]
> Cc: Murray S. Kucherawy
> Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
> 
> In the first paragraph of section 3, I'd say MAY rather than SHOULD,
> both because it conflicts with the OPTIONAL at the end of the section,
> and just because the world has gotten along without this feature for
> 30 years so its practical necessity remains debatable.

The SHOULD only applies to people that are implementing this, meaning if you claim to be compliant with this, then you'll always add it unless you have a very good (operational) reason why you don't.  If it was SHOULD and also "Updates RFC5321", I'd agree with you, but this is meant as an independent and optional extension.

But since you're the second person to mention that, I guess some wordsmithing is in order to make that clear.

> Other than that it seems mostly harmless.  Has anyone implemented it
> yet?

I've floated the idea to some open source and commercial MTAs and mailbox providers, and one popular MLM.  We'll see what traction it gets.

Date: 10 Jan 2012 04:08:07 -0000
From: "John Levine" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
Organization: 
Sender: [email-masked]

In the first paragraph of section 3, I'd say MAY rather than SHOULD,
both because it conflicts with the OPTIONAL at the end of the section,
and just because the world has gotten along without this feature for
30 years so its practical necessity remains debatable.

Other than that it seems mostly harmless.  Has anyone implemented it yet?

R's,
John

From: "Murray S. Kucherawy" <[email-masked]>
To: SMTP Discussion <[email-masked]>
Date: Mon, 9 Jan 2012 14:45:44 -0800
Subject: RE: FW: I-D Action: draft-kucherawy-received-state-00.txt
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

Hi all,

In response to feedback here, I posted an -01 version of this document over a month ago.  It includes text addressing Bill's question about what exactly is going on when a state change is indicated.

Further review and comments welcome, which will guide me toward selecting next steps (if any).

Cheers,
-MSK