Hi Dave,

This should probably move to apps-discuss.= =A0 I'll let you decide if you agree before doing so.

On Mon, Oc= t 7, 2013 at 6:18 PM, Dave Cridland <dave@cridland.net> wrot= e:

My fundamental problem with the design is that if it were an ESMT= P extension, it would fail clearly per-recipient, whereas this is an all or= nothing approach. There's no way to tell, from the defined response, w= hich mailbox[es] have changed ownership.

We discussed this in there (Section 5 of t= he current draft).=A0 The concern is that there might be an intermediary th= at doesn't support it, at which point you either have to turn the messa= ge back or lose the security as it goes forward.=A0 Neither is acceptable i= n our use case.

That said, given the sc= ope, this may not be an issue - however, I'm slightly confused by this = scope. At Arcode, we were considering using this to mark outgoing messages = from our MUA, but this is stated to be intended only for use by automated s= enders. It's not obvious why, and no rationale is given.

We said that to highlight what the origin of the work is = and describe our use cases.=A0 That doesn't mean this can't be used= in other contexts where it might work; if it makes sense to use this in th= e context of user-generated email, that's fine, but we wouldn't exp= ect end users to maintain a table of when they last knew their various reci= pients to be valid so it seems less useful overall for MUAs to do it.=A0 We= could add a remark about that if it would help.

Section 3 contains the recommendation to remove the header f= ield. This seems wrong to me - I would suggest that:

a) It's useful for debugging purposes to keep it.

b) If the header is signed via DKIM (which is breifly discus= sed later) removal would invalidate the signature, I think.
Right on both counts, which is why we went with RECOMMENDED, which al= lows for local exceptions as long as you have a really good reason to do wh= at you're doing.=A0 Those both seem like good reasons to ignore the rec= ommendation to me.=A0 We should probably point out the DKIM thing explicitl= y, however.

Also, I suggest that only those RRVS fields below the upperm= ost set of trace fields should be examined. That is, any trace field after = any RRVS field should cause any further RRVS fields to be ignored. This sho= uld prevent cases where a mail is resent, or automatically forwarded, from = causing any complications.

This is definitely something that should get wider discus= sion, because I don't know the implications of making that change.=A0 I= t seems okay off the top of my head though.
=A0

Section 8.2 includes the suggestion to restrict use to recip= ients known to implement; but as far as I can tell, there's no signalli= ng to allow this to be discovered.

There isn't. =A0

I suggest:

1) We should do an ESMTP extension. I agree that a header fi= eld would also be useful; but deciding explicitly not to do an ESMTP extens= ion to avoid the possibility of loss, and *only* doing a header field seems= to me to be optimizing for the failure case.

In my experience, adding support for a header field to an= MTA (or more commonly, plugin or filter) has a much faster deployment rate= than adding support for an ESMTP extension.=A0 That means solving the imme= diate problem will take a lot longer.=A0 There's also been other work (= RFC 6758, for example) that takes this approach where tunneling of the valu= e through non-participants is important.

2) The signalling problem above solves itself if an ESMTP ex= tension is done, of course. But even if not a basic extension simply with a= keyword in the EHLO response would help. Otherwise, the only option I can = suggest is to have a special RRVS field value, or another field name, which= could be used to probe for support. Seems very ugly, though.

Using ESMTP for signaling doesn't always help.=A0 The= ultimate recipient might have support for it, but it's not meaningful = if there's an intermediary that doesn't support it.=A0 The "kn= own to support" thing just means the sender has a list of domains it k= nows a priori will know what to do with this field, and only generates the = field for them.

3) The 5.7.7 ESC needs to have the text syntax defined to in= clude the failing mailbox[es].

Dave.

Isn't the text part typically free-for= m and not specified?

-MSK