Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-received-state-00.txt

From: [email-masked]
Date: Thu, 03 May 2012 10:44:54 -0700

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

	Title           : Indicating Email Handling States in Trace Fields
	Author(s)       : D. Crocker
                          Murray S. Kucherawy
	Filename        : draft-ietf-appsawg-received-state-00.txt
	Pages           : 11
	Date            : 2012-05-03

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

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-appsawg-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-ietf-appsawg-received-state-00.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-received-state/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 3 May 2012 17:55:24 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Thursday, May 03, 2012 10:45 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: I-D Action: draft-ietf-appsawg-received-state-00.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Applications Area Working
> Group Working Group of the IETF.
> 

This got a couple of rounds of development prior to becoming a working group document, but that was a few months ago.  I'd love some fresh eyes on it and some new reviews.  Or if you think it's pretty well-baked already, please do say so.

I know John Klensin had some more general concerns in the area of trace data, but I seem to recall that we landed on the fact that it was a general concern, and not something specific to this proposal.  So we should have that conversation as well, perhaps, and I'll let him get it re-started if he wishes.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Thu, 03 May 2012 11:21:53 -0700

> This got a couple of rounds of development prior to becoming a working group document, but that was a few months ago.  I'd love some fresh eyes on it and some new reviews.  Or if you think it's pre…

+1 to the request.

It will help to distinguish between basic, philosophical concerns, 
versus issues with the details.

As the name of the field implies, it was originally targeting a very 
specific event, roughly characterized as "coming into the MTA".  This 
new draft clearly (and I hope explicitly) expands the scope to cover any 
handling transition that the message undergoes that is worth recording.

d/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

---

From: Ned Freed <[email-masked]>
Date: Fri, 11 May 2012 19:09:54 -0700 (PDT)

> > This got a couple of rounds of development prior to becoming a working
> > group document, but that was a few months ago.  I'd love some fresh eyes
> > on it and some new reviews.  Or if you think it's pretty well-baked
> > already, please do say so.

I fully approve of publishing this, but I think a little more work is needed
before it's ready.

> handling transition that the message undergoes that is worth recording.

I agree with the goal, but I think that actually a bit of a problem with the
current specification. At one place it says:

   Rather, an agent is encouraged to apply state annotations
   only when a message enters a handling queue where substantial delay
   is possible, and especially when a handoff has occurred between two
   different, independent agents.

This is saying "only record when there's a delay", which is hardly the same as
"record when you think it is worth it". And some of the states on the list,
like "normal" and "outbound", don't really match either criteria.

The Introduction also seems to justify use of this mechanism in terms
of delays. That should also be revisited.

At another point it says:

   The degree of granularity -- and therefore the degree of verbosity --
   recorded through the use of this additional trace clause will vary
   according to the needs of the operator making use of this
   specification.  In normal operation, the verbosity would likely be
   limited to record only "unusual" transitions, such as to a
   quarantine.

The sentiment is fine, but I question whether or not the addition of
this field will be under operator control. In most implementations I rather
suspect it won't be.

The convert state is described as:

 convert:  The message entered a queue pending content conversion for
      passage through a gateway.

Since we have standards-track specifications talking about content conversion
within the SMTP mail system, I don't think it makes sense to assume that
content conversion is always associated with gateways. Additionally, while I
agree with the inclusion of this state, it doesn't seem to be all that similar
to the other things listed in the abstract, so maybe it should be mentioned
there.

Finally, an obvious source of delays is use of the FUTURERELEASE SMTP
extension. The "timed" state seems appropriate to use for this, but  perhaps a
explicit reference to the FUTURERELEASE RFC would be in order. (We could also
define a futurerelease state, I guess, but that seems unnecessary.)

				Ned

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 12 May 2012 04:19:18 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ned Freed
> Sent: Friday, May 11, 2012 7:10 PM
> To: Dave Crocker
> Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-received-state-00.txt
> 
> I agree with the goal, but I think that actually a bit of a problem
> with the current specification. At one place it says:
> 
> This is saying "only record when there's a delay", which is hardly the
> same as "record when you think it is worth it". And some of the states
> on the list, like "normal" and "outbound", don't really match either
> criteria.

Seems like dropping "only" from that sentence clears this up, correct?

> of delays.  That should also be revisited.

That is indeed the impetus for the work, which is the focus of the third paragraph of the Introduction, i.e., answering the question "What's with this big time gap?"

You're right that "normal" and "outbound" are not strictly necessary in that context, but there was some earlier input that suggested this document should allow the case where some mail handling agent is coded such that it always uses this clause, so accommodating those cases where there wasn't some kind of handling exception needs to be included.

> this field will be under operator control. In most implementations I
> rather suspect it won't be.

Interesting point.  I believe the vision here is that adding this trace information might be a configurable option, since it could lead to some of the header interpretation issues described two paragraphs lower.  That does put it in the control of the operator.

> Since we have standards-track specifications talking about content
> conversion within the SMTP mail system, I don't think it makes sense to
> assume that content conversion is always associated with gateways.
> Additionally, while I agree with the inclusion of this state, it
> doesn't seem to be all that similar to the other things listed in the
> abstract, so maybe it should be mentioned there.

Fair enough, so instead of "through a gateway", use "to another mail handling agent with reduced capabilities"?

> extension. The "timed" state seems appropriate to use for this, but
> perhaps a explicit reference to the FUTURERELEASE RFC would be in
> order. (We could also define a futurerelease state, I guess, but that
> seems unnecessary.)

Didn't know about that one.  Will add such a reference.

Thanks,
-MSK

---

From: Ned Freed <[email-masked]>
Date: Fri, 11 May 2012 22:03:26 -0700 (PDT)

> Seems like dropping "only" from that sentence clears this up, correct?

Yes, that seems sufficient.

> That is indeed the impetus for the work, which is the focus of the third
> paragraph of the Introduction, i.e., answering the question "What's with this
> big time gap?"

> You're right that "normal" and "outbound" are not strictly necessary in that
> context, but there was some earlier input that suggested this document should
> allow the case where some mail handling agent is coded such that it always uses
> this clause, so accommodating those cases where there wasn't some kind of
> handling exception needs to be included.

I wasn't objecting to the cases being there, but rather that that don't
seem to align to what the text says the field is for.

> Interesting point.  I believe the vision here is that adding this trace
> information might be a configurable option, since it could lead to some of the
> header interpretation issues described two paragraphs lower.  That does put it
> in the control of the operator.

Not in the sense of that paragraph, it doesn't. That paragraph is talking about
the granularity being under the control of the operator, not whether or not the
parameter is used at all. The latter is entirely justifiable, the former, not
so much.

> agent with reduced capabilities"?

I'd prefer to simply drop the last five words. Conversions are used for
all sorts of different reasons.

> Didn't know about that one.  Will add such a reference.

Always good to have a specific example of its use.

				Ned

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 12 May 2012 05:44:59 +0000

> From: Ned Freed [mailto:[email-masked]]
> Sent: Friday, May 11, 2012 10:03 PM
> To: Murray S. Kucherawy
> > Interesting point.  I believe the vision here is that adding this
> > trace information might be a configurable option, since it could lead
> > to some of the header interpretation issues described two paragraphs
> > lower.  That does put it in the control of the operator.
> 
> Not in the sense of that paragraph, it doesn't. That paragraph is
> talking about the granularity being under the control of the operator,
> not whether or not the parameter is used at all. The latter is entirely
> justifiable, the former, not so much.

If there's a configuration option in some handling agent that in one mode adds a single unannotated Received field, and in the other mode adds several of them, some of which use this annotation capability, I would call that an increase in granularity, and also say that's under operator control.

So is that not a valid claim?  And if it is, what wording might say it more correctly?
 
> > Fair enough, so instead of "through a gateway", use "to another mail
> > handling agent with reduced capabilities"?
> 

OK.

-MSK

---

From: Ned Freed <[email-masked]>
Date: Sat, 12 May 2012 08:09:17 -0700 (PDT)

> If there's a configuration option in some handling agent that in one mode
> adds a single unannotated Received field, and in the other mode adds several of
> them, some of which use this annotation capability, I would call that an
> increase in granularity, and also say that's under operator control.

> So is that not a valid claim?

This isn't about what's possible, it's about what's likely. Sure, someone
could implement such an option. For that matter, they could implement
something far more granular, with dozens of settings allowing anything
from generation of nothing to generation of dozens of fields on, I don't
know, a per-IP basis.

But it's not likely. And you shouldn't spend a lot of text in the document
talking about what is essentially configurationless control and then suddently
assume elaborate controls are going to be present.

> And if it is, what wording might say it more correctly?
 
The text should not assume any of this is under the operators control while
still making the point that granularity of use is going to vary based on need.
So something like:

   The degree of granularity -- and therefore the degree of verbosity --
   recorded through the use of this additional trace clause is likely to
   vary depending on circumstances. It will typically be the case that
   use of this clause will be limited to "unusual" transitions, such
   when a message requires additional scrutiny or needs to be quarantined.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Sat, 12 May 2012 08:36:02 -0700

>     when a message requires additional scrutiny or needs to be quarantined.

+1

wfm.

d/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 13 May 2012 04:49:05 +0000

> From: Dave Crocker [mailto:[email-masked]]
> Sent: Saturday, May 12, 2012 8:36 AM
> To: Ned Freed
> Cc: Murray S. Kucherawy; [email-masked]
> Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-received- state-00.txt
> 

Ditto; done in the working copy.  Thanks!

-MSK