Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-01.txt

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 13 Nov 2013 16:43:53 -0800

On Fri, Oct 25, 2013 at 4:03 PM, Ned Freed <[email-masked]> wrote:

> Anyway, once I had the extension I started in on the header stuff. I
> expected
> this to be harder due to the need to handle the header-envelope matcheup as
> well as the possibility of partial failures, but I was gobsmacked at the
> difficultly. This has taken me literally days to get right.
>
> The multiple recipient issue is a big part of it, but not all. Just as
> one example of how tricky the multiple recipient issue is, suppose you
> have two recipients A and B that forward to the same address C:
>
>   A -> C
>   B -> C
>

The author only has a timestamp at which it thought A and B had confirmed
owners of interest.  The author has no idea that A and B are forwarded to
C, or to anywhere at all.

> So what recreation date do you attach to that one address? If either one
> doesn't have a recreation date the answe is "you don't attach one". But
> they
> both do the correct thing is to attach and check both. That means making
> some
> data structure changes, which to be honest I didn't bother to do. I think
> this
> is enough of a corner case that I can ignore it. But I could be wrong, in
> which
> case this will be even more work.
>

The author would store the A and B confirmation dates.

> But this is nasty even if there's only a single recipient and header. The
> basic
> problem is you've introduced a new failure case after the content of the
> message has been received, and it turns out to have somewhat different
> semantics from other failure cases at this point, in my implementation at
> least.
>

The failure would be a bounce from the receiver, right?  If you're talking
about a failure from the MSA, I'm not sure why that would be a problem
specific to this extension.

>
> It's not like throwing out the message because, say, it was a big pile of
> binary nonsense. Or because it violated overall site policy in some way. In
> such cases there's justification for returning an error and dropping the
> trash
> in the trashcan. But RRVS differs in that it's almost certainly a bad idea
> to
> ignore legal intercept or other archiving requirements for what is, after
> all a
> valid message. (And before you say otherwise, think what happens when Silk
> Road
> supports this on the sending side.)
>

You're talking about a receiver implementing those features, I presume.  Is
that something that we need to talk about in this draft?  Seems like a
sentence or two would suffice if so, but I haven't seen that mentioned in
other extensions.

>
> This led me to conclude that RRVS is much more like a sieve ereject - which
> already had support in place for multiple recipients - and that's more or
> less
> how I ended up implementing it. But the interactions with actual sieves are
> different, the handling in the event of sieve errors are different, and
> ereject
> doesn't allow specification of a specific enhanced status code so support
> for
> that had to be added.
>

Wouldn't an implementing receiver just do an SMTP rejection for the RCPT TO
commands for which the test failed, and continue otherwise?  Again, is this
a new problem specific to RRVS?

-MSK

---

From: Ned Freed <[email-masked]>
Date: Thu, 14 Nov 2013 14:52:30 -0800 (PST)

> C, or to anywhere at all.

Assuming by "author" you mean sender, I'm not talking about what the author
knows, which is obviously one date per recipient address. I'm talking about how
the mail system handles the case where two accounts with their own creation
dates have both forwarded mail to a common destination.

This is the problem with having to wait to handle things until the message is
transferred - you've already accepted and expanded the recipients, and life is
no longer as simple as just issuing a 5YZ code to the RCPT TO. In order to do
this "correctly" what you have to do is store a list of every initial address
that mapped to a final address and the associated RRVS timestamp.

Of course this all depends on the data structures you've used. And as I said, I
think this is enough of a corner case given the focus of this extension that
I'll deal with this issue only if it becomes a problem.

> The author would store the A and B confirmation dates.

Of course, but the issue is that both apply to C and you have to keep track of
that fact.

> specific to this extension.

But that's exactly the problem: This is a failure case with somewhat different
semantics.

> sentence or two would suffice if so, but I haven't seen that mentioned in

I can't really recommend adding anything about any of this. The IETF seems to
have developed a rather peculiar attitude about implementation advice of late;
it seems it gets taken as directives as to how things have to be and judged on
that basis.

> a new problem specific to RRVS?

In the case of the SMTP extension, sure. I'm not talking about that; I'm
talking about the header approach. This is all part and parcel of why the
SMTP extension is easier to handle than the header.

				Ned