Subject: [appsdir] Review request: draft-ietf-appsawg-rrvs-header-field

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 7 Oct 2013 16:18:08 -0700

In the interests of early reviews, can I please get a reviewer for the
above draft?  It is still in WG development, but it appears to be stable
since the discussion of it has dropped off.  If it's in good shape
according to others, it might be WGLC-ready.

I'm both co-chair and co-author, so I can't help here.  :-)

Thanks!

-MSK

---

From: Dave Cridland <[email-masked]>
Date: Tue, 8 Oct 2013 02:18:56 +0100

I've had a quick read-through; in fact this one came up at work so I had it
on my list anyway.

My fundamental problem with the design is that if it were an ESMTP
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, which
mailbox[es] have changed ownership.

That said, given the scope, 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 senders. It's not obvious why, and no rationale
is given.

Section 3 contains the recommendation to remove the header field. 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 discussed later)
removal would invalidate the signature, I think.

Also, I suggest that only those RRVS fields below the uppermost 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 should
prevent cases where a mail is resent, or automatically forwarded, from
causing any complications.

Section 8.2 includes the suggestion to restrict use to recipients known to
implement; but as far as I can tell, there's no signalling to allow this to
be discovered.

I suggest:

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

2) The signalling problem above solves itself if an ESMTP extension 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.

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

Dave.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 7 Oct 2013 22:42:31 -0700

Hi Dave,

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

> mailbox[es] have changed ownership.

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

> only for use by automated senders. It's not obvious why, and no rationale
We said that to highlight what the origin of the work is and describe our
use cases.  That doesn't mean this can't be used in other contexts where it
might work; if it makes sense to use this in the context of user-generated
email, that's fine, but we wouldn't expect end users to maintain a table of
when they last knew their various recipients to be valid so it seems less
useful overall for MUAs to do it.  We could add a remark about that if it
would help.

> removal would invalidate the signature, I think.
Right on both counts, which is why we went with RECOMMENDED, which allows
for local exceptions as long as you have a really good reason to do what
you're doing.  Those both seem like good reasons to ignore the
recommendation to me.  We should probably point out the DKIM thing
explicitly, however.

> causing any complications.
This is definitely something that should get wider discussion, because I
don't know the implications of making that change.  It seems okay off the
top of my head though.

> implement; but as far as I can tell, there's no signalling to allow this to
There isn't.

> 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.  That means solving the immediate problem
will take a lot longer.  There's also been other work (RFC 6758, for
example) that takes this approach where tunneling of the value through
non-participants is important.

> used to probe for support. Seems very ugly, though.
Using ESMTP for signaling doesn't always help.  The ultimate recipient
might have support for it, but it's not meaningful if there's an
intermediary that doesn't support it.  The "known to support" thing just
means the sender has a list of domains it knows 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 include the
Isn't the text part typically free-form and not specified?

-MSK

---

From: Claudio Allocchio <[email-masked]>
Date: Tue, 8 Oct 2013 14:35:31 +0200 (CEST)

> This should probably move to apps-discuss.  I'll let you decide if you

I also think we should move it to apps-discuss. And then we can take a 
summary of the discussion also in the AppsDir archive for further 
consultation.

> Isn't the text part typically free-form and not specified?

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 8 Oct 2013 06:40:16 -0700

On Tue, Oct 8, 2013 at 5:35 AM, Claudio Allocchio <[email-masked]
> wrote:

> summary of the discussion also in the AppsDir archive for further
No problem.  I'd also like to get someone assigned to look at it as an
actual AppsDir review.  It could be Dave Cridland if he wants to do it, or
he can work on it free-form and Claudio could assign someone else.  Either
way, we've been talking about getting directorates engaged earlier in the
process, hence the request.

-MSK

---

From: Claudio Allocchio <[email-masked]>
Date: Tue, 8 Oct 2013 15:45:01 +0200 (CEST)

> process, hence the request.

ok!

Dave, do you want to make a "formal" one, too?