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

From: Dave Cridland <[email-masked]>
Date: Tue, 8 Oct 2013 21:01:05 +0100

On 8 Oct 2013 01:42, "Murray S. Kucherawy" <[email-masked]> wrote:
>
> Hi Dave,
>
> This should probably move to apps-discuss.  I'll let you decide if you
agree before doing so.

*blinks*

Yes. Yes, it totally should have been on that mailing list. That'll teach
me to write things while jetlagged. Or indeed read them. Or try to think.

> On Mon, Oct 7, 2013 at 6:18 PM, Dave Cridland <[email-masked]> wrote:
>>
>> 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.
>
>
> 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.

Yes, and I do understand that, but that's an argument against any
extension. I agree that this would benefit from header field magic, I just
think having that as a fallback would be better than having it as a default.

>>
>> 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.
>
> 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.

If this is merely a perspective, that's fine, and yes - a remark or two
clarifying scope would be useful.

>>
>> 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.
>
> 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.

What are the really good reasons not to ignore your recommendation, though?

>>
>> 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.
>
> 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.
>
>>
>> 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.
>
> There isn't.
>
>>
>> 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.
>
> 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.

I agree, but I don't think this is a case where the circumstances rule out
a ESMTP RCPT parameter entirely, though.

In fact, RFC 6758 is itself a fallback mechanism for an ESMTP extension, so
you're supporting my argument with that example, thanks. :-)

>>
>> 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.
>
> 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.

I'll admit to being slightly over-enthusiastic there; I think that an ESMTP
extension would give a considerably better idea, though.

>>
>> 3) The 5.7.7 ESC needs to have the text syntax defined to include the
failing mailbox[es].
>>
>> Dave.
>
> Isn't the text part typically free-form and not specified?

Typically, but there are exceptions - RFC 5321's EXPN response is specified
for the 250 case, for example, in section 3.5.

Dave.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 8 Oct 2013 13:20:01 -0700

On Tue, Oct 8, 2013 at 1:01 PM, Dave Cridland <[email-masked]> wrote:

> > 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.
>
I'm inclined to think that this is a pretty general problem with this sort
of work (RFC 6758 being another recent example), and so maybe there's some
work to be done around a general description for the method of tunneling
SMTP extensions through header fields since it's come up before.

That said, I suppose this point needs commentary from more people in the
area.  Ned in particular mentioned it before, saying that an extension is
architecturally the right way to do it but it's possible to be successful
arguing for doing it this way.  I don't know if we've made the right
arguments here, so more feedback is needed.

> > 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.
>

Added for the next version.

> > 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
The date/time at which A verified that B had a particular owner is probably
not the kind of thing that should be accidentally revealed should the
message be forwarded or exposed in some other way.

> Typically, but there are exceptions - RFC 5321's EXPN response is
> specified for the 250 case, for example, in section 3.5.
>
> Dave.
>

Why's it appropriate here and not elsewhere?  I'm trying to be lazy by
asking that question, but rather I'm trying to understand when it's
necessary to establish syntax around something that's nearly always
free-form, and when it's better not to do so.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Mon, 14 Oct 2013 14:21:00 -0400

> arguments here, so more feedback is needed.

This is a clever ("tunneling") argument, but there are two key reasons 
to support a dual solution (ESMTP extension and the RRVS payload header):

  1) The already highly optimized (no payload transfer required)
     rejection rate for local user account validation.  This is a major
     consideration in reducing the SORBIG-like bounce attacks by
     avoiding the higher overhead DATA transfer and processing
     requirement.

  2) As with our package, this may be two different scripting tools;
     one tool for processing envelope parameters (IP, EHLO/HELO,
     MAIL FROM, RCPT TO) and one tool for processing the payload
     using RBM (Rule-Based Messaging) scripts tools, i.e. SIEVE-like
     based tools.

Look at it as supporting the wider coverage because the proposal is 
promoting a major shift in repeating the same functional design 
requirement (USER API lookup) with the ultimate same result (55x) to 
the DATA state machine point from the highly more optimal RCPT TO 
state machine point.  This will definitely increase the processing 
overhead and also could require a different programming tool with 
increase complexity in order to implement. Again, with ultimately the 
same result (55x) there is no real gain in benefits in this design to 
shift to DATA.

So offer both for wider coverage (and potential adoption).

-- 
Hector Santos, CTO
http://www.santronics.com