Subject: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00

From: Kurt Andersen <[email-masked]>
Date: Wed, 17 Jul 2013 18:18:13 -0700

After reviewing draft-wmills-rrvs-header-field-00, it looks like a
very promising step to support the security of potentially re-assigned
email addresses. I would like to see it employed not only for large
mailbox providers, but also by enterprises where employee churn can
easily lead to address re-use.

I have two technical comments/suggestions regarding the proposal:

1) Be explicit regarding the RFC3463 extended response code which
should be used when rejecting a message due to an out-of-date
attribution. By my reading, the code should be 5.1.6 with whatever
additional explanation the receiver chooses to supply;

2) Use epoch seconds in the rrvs header instead of the archaic RFC822
and successors date-time field. The use of epoch seconds for
machine-processed email headers has already been established in the
case of RFC6376 (DKIM Signatures), section 3.5 for the 't' and 'x'
fields. This will be much easier for parsing and smaller.

The widespread support for this header would help deal with a number
of situations that today can put otherwise innocent senders on
blacklists. Nothing is a panacea and senders who attempt to abuse this
system would have to be appropriately blocked, just as directory
harvest attacks need to be dealt with today.

Cheers,
  Kurt Andersen

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 17 Jul 2013 23:17:26 -0700

Hi Kurt, thanks for your comments.  Replies inline:

> additional explanation the receiver chooses to supply;

This has come up before, most recently in the SPFbis working group.  I'll
go along with consensus, but for the record, I've never been a fan of doing
this.  RFC3463 says quite clearly which codes are to be used for what
situations; it seems unnecessary to me to call out the specific code when
the document defining those codes already spells it out.

> fields. This will be much easier for parsing and smaller.

My co-author and I talked about that prior to posting the first draft.
We're aware of other standard expressions like UNIX epoch time and
RFC3339.  We decided on sticking with email format for now because things
parsing this content already know how to do that (at least for Date, and
possibly for scraping details from Received), and it seemed simpler to have
a single timestamp format in a message.  There's no guarantee that a DKIM
signature will be present on the message, introducing the second format.
Having stated all of that, I'm not especially married to that choice, so as
above I'll go with consensus.  I don't recall my co-author being
particularly passionate about it either, but I'll let him speak for himself.

-MSK

---

From: Bill Mills <[email-masked]>
Date: Wed, 17 Jul 2013 23:46:03 -0700

On timestamps...  I'm not married to any particular one.  The folks in our team who are implementing have a parser that already pulls in rfc822 format time,  they also know how and have code to parse DKIM times and ISO times.

I'm happy to leave it to consensus if we can make the decision fast, otherwise inertia will win because what they are planning on doing now is the -00 spec which is rfc822 times.  

I don't want to end up with several possible formats in the same field though.

-bill

--------------------------------
William J. Mills
"Paranoid" Yahoo!

________________________________
 From: Murray S. Kucherawy <[email-masked]>
To: Kurt Andersen <[email-masked]> 
Cc: IETF Apps Discuss <[email-masked]>; William Mills <[email-masked]> 
Sent: Wednesday, July 17, 2013 11:17 PM
Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00

>additional explanation the receiver chooses to supply;

This has come up before, most recently in the SPFbis working group.  I'll go along with consensus, but for the record, I've never been a fan of doing this.  RFC3463 says quite clearly which codes are to be used for what situations; it seems unnecessary to me to call out the specific code when the document defining those codes already spells it out.

>fields. This will be much easier for parsing and smaller.

My co-author and I talked about that prior to posting the first draft.  We're aware of other standard expressions like UNIX epoch time and RFC3339.  We decided on sticking with email format for now because things parsing this content already know how to do that (at least for Date, and possibly for scraping details from Received), and it seemed simpler to have a single timestamp format in a message.  There's no guarantee that a DKIM signature will be present on the message, introducing the second format.  Having stated all of that, I'm not especially married to that choice, so as above I'll go with consensus.  I don't recall my co-author being particularly passionate about it either, but I'll let him speak for himself.

-MSK

---

From: Kurt Andersen <[email-masked]>
Date: Thu, 18 Jul 2013 06:44:12 -0700

On Wed, Jul 17, 2013 at 11:17 PM, Murray S. Kucherawy
<[email-masked]> wrote:
> This has come up before, most recently in the SPFbis working group.  I'll go
> along with consensus, but for the record, I've never been a fan of doing

I would suggest that the document should not specify the numeric code,
but instead reference the "extended response code used for permanent
failures attributed to 'Destination mailbox has moved, No forwarding
address'".

--Kurt

---

From: Bill Mills <[email-masked]>
Date: Thu, 18 Jul 2013 09:09:17 -0700

I'm OK with making that the primary text as long as the 5.1.6 is parenthetical after, because in the end folks will want to know.

-bill

________________________________
 From: Kurt Andersen <[email-masked]>
To: Murray S. Kucherawy <[email-masked]> 
Cc: IETF Apps Discuss <[email-masked]>; William Mills <[email-masked]> 
Sent: Thursday, July 18, 2013 6:44 AM
Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00

--Kurt

---

From: Franck Martin <[email-masked]>
Date: Thu, 18 Jul 2013 11:51:27 -0500 (CDT)

I think what Kurt is saying, is let's avoid RFC chasing. Reference the RFC for Extended code, says it is authoritative, and state that currently the code that matches is 5.1.6 

In the text portion I would even be very explicit that this response is due to the presence of the rrvs header field. 

Let's avoid second guessing. 

----- Original Message -----

From: "Bill Mills" <[email-masked]> 
To: "Kurt Andersen" <[email-masked]>, "Murray S. Kucherawy" <[email-masked]> 
Cc: "IETF Apps Discuss" <[email-masked]> 
Sent: Thursday, July 18, 2013 9:09:17 AM 
Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 

On Wed, Jul 17, 2013 at 11:17 PM, Murray S. Kucherawy 
< [email-masked] > wrote: 
> On Wed, Jul 17, 2013 at 6:18 PM, Kurt Andersen < [email-masked] > wrote: 
>>

---

From: Bill Mills <[email-masked]>
Date: Thu, 18 Jul 2013 10:25:35 -0700

Text content in there is free form and up to the implementer.  I'm in favor of "this is not the droid you're looking for".  No objection to adding "(rrvs)" to the example text, but it's not normative and we should not try to make it so.

-bill

________________________________
 From: Franck Martin <[email-masked]>
To: Bill Mills <[email-masked]> 
Cc: Kurt Andersen <[email-masked]>; Murray S. Kucherawy <[email-masked]>; IETF Apps Discuss <[email-masked]> 
Sent: Thursday, July 18, 2013 9:51 AM
Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00

-bill

---

From: "John Levine" <[email-masked]>
Date: 18 Jul 2013 20:29:39 -0000

>email addresses.

I'm scratching my head about the security implications.  Using the
obvious binary search, you can determine the creation date of an
address to whatever precision the server will tell you.

That feels like one of those things that you can combine with other
data to figure out stuff that the server hadn't intended to disclose.
I realize you can deter the attack by testing the dates with a coarse
granularity, or by limiting the number of queries per address, but
that kind of blinding is known not to work well.

For example, let's say I don't like people who use throwaway mail
addresses, so whenever someone signs up for an account, I put in an
rrvs header in the welcome message to check if the address is less
than a week old and if it bounces, demand a different address before I
let the user activate the account.

R's,
John

---

From: Bill Mills <[email-masked]>
Date: Thu, 18 Jul 2013 14:41:40 -0700

Yeah, if there are age based things that you use in customer care, for example, for account recovery then it's an exposure.  Second order things like Alice knows where Bob used to live (or can data-mine that) let's Alice guess the postal code at the time of registration.

-bill

________________________________
 From: John Levine <[email-masked]>
To: [email-masked] 
Cc: [email-masked] 
Sent: Thursday, July 18, 2013 1:29 PM
Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00

R's,
John
_______________________________________________
apps-discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 18 Jul 2013 16:41:20 -0700

> address to whatever precision the server will tell you.

Right, and I think Security Considerations already calls this out.

> let the user activate the account.
Aren't those sorts of things merely side effects of what Security
Considerations already says?

-MSK

---

From: "John R Levine" <[email-masked]>
Date: 18 Jul 2013 19:53:39 -0400

> Considerations already says?

Probably, but I've found it's usually worth some head scratching to ponder 
the implications of any new information leak.

R's,
John

---

From: Bill Mills <[email-masked]>
Date: Thu, 18 Jul 2013 21:53:46 -0700

Gotta make sure we actually got it right.  I'm good with that :)

-bill

________________________________
 From: John R Levine <[email-masked]>
To: Murray S. Kucherawy <[email-masked]> 
Cc: IETF Apps Discuss <[email-masked]> 
Sent: Thursday, July 18, 2013 4:53 PM
Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00

R's,
John

---

From: Peter Koch <[email-masked]>
Date: Fri, 19 Jul 2013 12:51:46 +0200

> Considerations already says?

interestingly, part of the issue would belong into the Privacy Considerations
section. For the probing, I think the specification is ambiguous about
those time where an account was invalid/not assigned to anybody.
Depending on how that's solved, one would either be able to find the
initiation of termination date, but not nevessarily both.  Either is, of
course, a potential privacy breach.

Privacy/Security Considerations should mention that using the header
might give a flase sense of security and also, to state the obvious,
that public key cryptography is a much better solution (ignoring
usability issues).

-Peter

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 19 Jul 2013 07:20:03 -0700

> that public key cryptography is a much better solution (ignoring
I don't believe we need to call that out.  If an account was created at
time T1, then an inquiry as to whether it's been under continuous ownership
since time T0 (for T0 < T1) would be "no".  If the account has been
deleted, then there's no need to check for an existence or change of
ownership, because the mail won't be delivered anyway regardless of when it
might have been created, reassigned, or deleted.

What would the introduction of encryption solve?

-MSK

---

From: "John Levine" <[email-masked]>
Date: 19 Jul 2013 15:30:13 -0000

>What would the introduction of encryption solve?

I think the plan is that the user registers her PGP or S/MIME key with
the sender when she signs up, and subsequent mail is encrypted to that
key, so if it ends up at the wrong place it doesn't matter because
it'll be unreadable.

Other than the obvious problem that it's completely impossible to
implement due to the usual key distribution issues, and the privacy
issues just from knowing that a specific bank or other institution is
sending mail to that address, it's a great idea.

R's,
John

---

From: Peter Koch <[email-masked]>
Date: Fri, 19 Jul 2013 17:45:03 +0200

> since time T0 (for T0 < T1) would be "no".  If the account has been

with A and B denoting different "owners" of an account, and this timeline
and teh interpretation you just gave, instead of determining the end of
A's control, one could indeed find the inception time for B.  This is
a privacy risk.

-----------+-----------+-----------+-----------
           T0          T1          T2          
           AAAAAAAAAAAA            BBBBBBBBBBBB

> might have been created, reassigned, or deleted.

Sure, it doesn't influence the delivery, but it changes the
information leak.  If you'd instead account the interval
between T1 and T2 for B, you might be able to determine the
end of A's "ownership".

> What would the introduction of encryption solve?

To the extent it has solved anything so far, instead of relying
upon a (non-)delivery mechanism, for a message destined to A
it would conceal the content (not the fact of delivery) from B,
provided B didn't inherit the private key from A.

How to you envision the signalling for the header processing?
X-My-Provider-Supports-RRVS: Yes?

-Peter

---

From: Ned Freed <[email-masked]>
Date: Fri, 19 Jul 2013 07:45:49 -0700 (PDT)

I have a lot of problems with this document as it stands.

The biggest by far is the apparent lack of any comparison between what's in the
header with the current message envelope. Instead the check appears solely to
be of the form "if the address in the RRVS field is local, then check to see if
the current usage start of that address postdates the timestamp, and if it does
refuse delivery to all recipioents, never mind who the recipient(s) actually
is(are)".

There are many forms of resending and forwarding that preserve top-level header
fields, which could easily cause false positives. Indeed, this risk can never
be completely eliminated since it is possible that someone might resend an old
message containing this header to the *new* owner of an address. (This case
calls for a strong recommendation that clients remove this field when doing
this sort of forwarding.) But most of the false positives can be mitigated by
checking the address in the field against the envelope to make sure the named
party actually is a current recipient.

This now becomes a question of how to perform that comparison given the
possibility of complex forwarding. Specifically, while a match against the
actual recipient has the obvious implication that the mechanism is active for
that recipient, what about a check against the ORCPT field value? I don't think
such a check makes sense, but I could be convinced otherwise.

I'll also note that the example you give in section 4 serves as an excellent
example of why such a comparison is essential. In that example the actual
outcome depends on whether or not A and B are within the same administrative
domain. If they are then the result will be to reject the messagen, if they
aren't then the receiving MTA at B will see the address in the field as foreign
and ignore the field, resulting in successful delivery. This is a major least
astonishment principle violation.

Checking against current recipients prevents this problem from occurring, and
will result in successful delivery in the described case. And I would argue
strongly that that's the correct outcome: Once mail hits an address I own what
I do with it, and when, is my own damn busines, not yours. I'm willing, albeit
grudgingly, to give up some information about the age of the address you're
sending to in exchange for some protection against mail you send to me ending
up going to the guy in Oregon who wrote "Understanding Business Statistics" and
has much curlier hair than I do. (It's quite a good book, BTW.) But knowledge
of how I handle my mail after I receive it goes much much much too far.

Another thing that needs to be mentioned is use of this facility when
an entire domain changes ownership. This is a little more complex than
it appears because of the need for addresses like [email-masked]
to be immune to ownership changes. But I can see this as being very useful.

This document is going to need an explanation for why a header field is being
used to communicate to the MTA/MDA rather than defining an SMTP extension,
which would be the "correct" architectural choice, not to mention being able to
address all the various forwarding issues.  (I'm not saying the current choice
is wrong, but it needs to be strongly justified.)

I also find this paragraph:

   This header field SHOULD NOT be added to a message that is addressed
   to multiple recipients.  It is presumed that an author making use of
   this field is seeking to protect transactional or otherwise sensitive
   data intended for a single recipient.

to be more than a little wierd. I send mail all the time to multiple recipients
that I really rather not end up going to an unintended recipient. Indeed, I
don't really see who the number of recipients correlates well if at all with
data sensitivity. I think this whole thing needs to go, especially since
envelope checks mostly solve the problems associated with multiple recipients.

More generally, this gets into the entire issue of when a client should use
this facility. I suppose one way is to have a button you press to request
"additional recipient verification" or something like that, but let's face it,
users aren't going to have a clue about what this does and therefore aren't
going to know when to use it and when not to. The only way this makes sense is
to use it automatically when an address comes out of the user's address book.
And not having it work when there are muliple recipients will lead to more
least astonishment principle violations.

There absolutely has to be some text on mitigating failure cases. A user who is
effectively blocked from being able to send or receive legitimate mail because
of some screwup (e.g., the account got deleted by mistake and then was
reinstated with a new creation date) is not going to be a happy camper. And
MSPs are not fond of mechanisms that lead to a rise in support calls.

And speaking of failures, a new enhanced status code needs to be defined for
use when this mechanism bounces mail, and support for NOTARY and
ENHANCEDSTATUSCODES needs to be at least a SHOULD for anyone implementing this.
I would also suggest having a separate status code for the case of a domain
ownership change.

> > Considerations already says?

I'm sorry, but the notion that a single sentence security considerations
section is going to pass muster for a document like this is nothing short
of absurd. The consequences of revealing the age of an account need to
be elaborated on at least a little bit.

The cases where a false negative occurs absolutely are a security concern,
and need to be described as well.

There should also be some reference to the part about signing these headers. (I
view such recommendations as Mostly Harmless, but security folks like them.)

> the implications of any new information leak.

And this document needs a lot more of it. I've tried to provide the results of
some of that here, but this is nowhere near enough.

				Ned

---

From: Bill Mills <[email-masked]>
Date: Fri, 19 Jul 2013 10:19:04 -0700

Yes, it is possible to determine the inception of B.  The site owner needs to determine if they want to expose this and whether that risk is balanced by the benefit to A.

-bill

________________________________
 From: Peter Koch <[email-masked]>
To: IETF Apps Discuss <[email-masked]> 
Sent: Friday, July 19, 2013 8:45 AM
Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00

-Peter

---

From: Bill Mills <[email-masked]>
Date: Fri, 19 Jul 2013 10:56:12 -0700

- matching name in rrvs to the envelope.

A sends to B who has forwarded to C.  This needs to be applied at the MTA handling B, that's what we were trying to solve here.  Comparing to the original envelope seems useful for confirming validity of the header itself, but I don't see much utility beyond that.  Am I missing something?

- resending clients should strip the header

Seems fair.

- multiple recipients.

This starts to get a LOT hairier if we have to do a multi-valued rrvs header, and it's not the problem we're trying to solve right now.  So we might allow multiple rrvs headersto solve this?  Each one needing to apply to a recipient in the envelope?

- forwarding

The sender has no information on how delivery will happen, forwarding is a form of delivery in this use case, and once you're forwarding RRVS should never apply.  

- enhanced status codes

why do we need a new one?  X.1.6 seems to fit well?

- domain ownership change

A fair point.  A different error return could be useful here.  Another way to do this would be to have an RRVS SMTP extension that advertises domains and the length of ownership.  Needs more thought.

- security considerations

Can be fuller, sure.  Got text?

- false negatives

Meaning if a provider incorrectly rejects mail?  Is this significantly different from the impact of current failures to delver when a DB lookup fails and you get a "no such user" when you know it exists?

-bill

________________________________
From: Ned Freed <[email-masked]>
To: John R Levine <[email-masked]> 
Cc: IETF Apps Discuss <[email-masked]> 
Sent: Friday, July 19, 2013 7:45 AM
Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00

                Ned

---

From: "John Levine" <[email-masked]>
Date: 19 Jul 2013 18:54:03 -0000

>Yes, it is possible to determine the inception of B.  The site owner
>needs to determine if they want to expose this and whether that risk is
>balanced by the benefit to A.

You could return a random answer for queries for times between the end
of A and the beginning of B without, as far as I can see, affecting
the utility for the indended question of "is this still the same
person who signed up."

Still scratching my head, though.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 19 Jul 2013 13:36:12 -0700

On Fri, Jul 19, 2013 at 7:45 AM, Ned Freed <[email-masked]> wrote:

> [...]

The suggestion about comparing against the envelope recipient set seems to
be pretty solid, so I'll skip that for now.

Checking against current recipients prevents this problem from occurring,
> and
Would a change in language from advocating rejection to merely stressing
that the target recipient is not actually the intended recipient be
satisfactory?

> to be immune to ownership changes. But I can see this as being very useful.

Good point here.

> is wrong, but it needs to be strongly justified.)

Fair enough.

> envelope checks mostly solve the problems associated with multiple

The use case being addressed is only single-recipient messages, like
password change requests or user-specific activity.  Such things are never
sent to multiple users.  Certainly there's a class of messages that are
sensitive and have multiple recipients, but they're not part of this
problem space.  In that sense, allowing a list of addresses on the header
field rather than just one creates complexity that isn't needed for the
problem we're trying to solve.

That said, I'm pretty sure it doesn't clobber our use case to allow
multiple instances of this field to be added.

> least astonishment principle violations.

Is it necessary to go into this level of detail?  A client uses this
facility if the nature of the content means it's important to get to a
particular person rather than whatever person currently owns a given
mailbox.  Describing UI things like buttons seems to go into more specifics
than are really required, especially since the systems implementing early
versions are entirely backend systems that don't interact directly with
users.

> MSPs are not fond of mechanisms that lead to a rise in support calls.

Fair enough.

> I would also suggest having a separate status code for the case of a domain

That all seems fine to me.

> be elaborated on at least a little bit.

What I claimed was that the specific thing John brought up is covered.  I
didn't claim the current text of Security Considerations is comprehensive
or complete at this early stage.

> view such recommendations as Mostly Harmless, but security folks like

Sure, those can be added.  But don't we already do that near the end of
Section 3?

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 19 Jul 2013 23:51:38 -0700

> A's control, one could indeed find the inception time for B.  This is

(This looks different for proportional versus fixed-width fonts.  As I
understand it, you're saying A owned the mailbox only between T0 and T1,
and B owned it starting at T2, and there was no owner in between.)

Yes, this can be used to determine the time at which B took ownership of
the mailbox being probed.  The (brief, currently) Security Considerations
says this already.  However, ...

> between T1 and T2 for B, you might be able to determine the

The question being asked is "has the target mailbox been under constant
ownership since <time>?"  If B is the current owner, then the answer to
that question is "yes" if and only if the timestamp in the header field is
T2 or greater.  Thus, if it's less, the answer is "no", regardless of
whether the timestamp is during A's ownership of the same mailbox.  Given
that, I don't see how one could distinguish T1 as being different from any
other timestamp less than T2.

> provided B didn't inherit the private key from A.

Just so I understand the use case: If some service provider sends mail to A
using this field that's then forwarded to B, you want to make sure B
doesn't learn the confirmation date of A just in case the new mailbox B
changes owners?

> X-My-Provider-Supports-RRVS: Yes?
We won't be using "X-", that's for sure.

-MSK

---

From: Ned Freed <[email-masked]>
Date: Sat, 20 Jul 2013 09:23:25 -0700 (PDT)

It occurs to me that the interaction of this proposal with mailing lists
deserves more consideration. A mailing list processor isn't going to know what
this header is and is therefore likely to let it through, at least to all
non-digest recipients. Given the present proposal and the lack of an envelope
check, if I know someone is on the list under a certain address (easy to know
from their postings), I can mess with them as well as anyone else using the
same MSP by including a header listing their address and some date prior to
when the address came into use.

Note that an envelope check only partly mitigates this attack. A better
mitigation would be a comparison of the envelope from with the From:/Sender:
field, which I'm starting to think may be needed in addition to the envelope
recipient check.

Aside from being another point in favor of an envelope check, this strongly
argues for mailing list removal of this field.

Another thing that deserves consideration is in addition to checking the
account age, also check to see if there actually was any prior use of the
account. The problem is this has to be coupled with a domain age check in the
event of previous use of the domain, so it doesn't fully address the problem
and makes the resulting operation a lot more complex.

Interestingly, consideration of mailing lists brings up another use
of this facility. Mailing list software can (and in some cases already
does) store the subscription date. That date could then be used to
in an RRVS field to prevent mailing list messages from going to the
wrong recipient and instead unsubscribe the recipient from the list.

Note that an unsubscription notice probably needs to be sent unconditionally
in the case of screwups or intentional attackcs as previously described.

				Ned

---

From: Bill Mills <[email-masked]>
Date: Sat, 20 Jul 2013 10:39:35 -0700

That's an interesting use case.  A good thing for mailing lists.

-bill

Sent: Saturday, July 20, 2013 9:23 AM

                Ned

---

From: Bill Mills <[email-masked]>
Date: Sat, 20 Jul 2013 10:49:43 -0700

On how a server advertises... My thought was a simple SMPT extension to advertise the capability, the sender checks this to determine if they should expect a bounce or nor form RRVS.

-bill

Sent: Friday, July 19, 2013 11:51 PM

>A's control, one could indeed find the inception time for B.  This is

(This looks different for proportional versus fixed-width fonts.  As I understand it, you're saying A owned the mailbox only between T0 and T1, and B owned it starting at T2, and there was no owner in between.)

Yes, this can be used to determine the time at which B took ownership of the mailbox being probed.  The (brief, currently) Security Considerations says this already.  However, ...

>between T1 and T2 for B, you might be able to determine the

The question being asked is "has the target mailbox been under constant ownership since <time>?"  If B is the current owner, then the answer to that question is "yes" if and only if the timestamp in the header field is T2 or greater.  Thus, if it's less, the answer is "no", regardless of whether the timestamp is during A's ownership of the same mailbox.  Given that, I don't see how one could distinguish T1 as being different from any other timestamp less than T2.

>provided B didn't inherit the private key from A.

Just so I understand the use case: If some service provider sends mail to A using this field that's then forwarded to B, you want to make sure B doesn't learn the confirmation date of A just in case the new mailbox B changes owners?

-MSK

---

From: "John Levine" <[email-masked]>
Date: 20 Jul 2013 19:08:03 -0000

>That's an interesting use case. A good thing for mailing lists.

It's 99.9% the same as the original use case, check that the person
getting the mail is the same person who signed up.

I'm more interested in the complications involved when people send
their own rrvs headers through mailing lists, screwing up the victim's
subscription.  In this regard it is somewhat like what happens when you
send mail to a list from an address with a DMARC policy of quarantine
or reject.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 20 Jul 2013 19:10:19 -0000

>On how a server advertises... My thought was a simple SMPT extension to advertise the
>capability, the sender checks this to determine if they should expect a bounce or nor form
>RRVS.

Can you write down the use case that shows how mail handling with the
SMTP extension would be different from mail handling without?  Either
way, you deal with rrvs bounces when they happen.  Servers that don't
understand rrvs would just ignore the header, so there's no damage
from including it anyway.

---

From: Ned Freed <[email-masked]>
Date: Sat, 20 Jul 2013 18:31:47 -0700 (PDT)

> getting the mail is the same person who signed up.

It's actually a simpler case, because when you're dealing with a mailing
list you just set a policy for using this and then you're done. All the
user interaction issues pretty much go away.

> subscription.

As am I.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Sat, 20 Jul 2013 18:44:48 -0700 (PDT)

> be pretty solid, so I'll skip that for now.

OK.

> that the target recipient is not actually the intended recipient be

No, not really. Again, as far as the originator is concerned, the recipient
address they know about has been reached and it still belongs to the same
person. The mechanism's effect really needs to end there, because if you try
and extend it all kinds of wierd stuff can happen.

If you want another example, consider what happens when someone uses fetchmail
to suck the mail out of a mailbox after delivery and sending it on somewhere
else. People route mail in all kinds of ways. And yes, what people do does lead
to problems, like when an autoforwarded message bounces back to the message
originator who then gets a bounce from an address they have never heard of and
wonder what the hell is going on. But new mechanisms need to be designed
not to make the problems worse.

> Good point here.

Thanks. We deal with domain shifts all the time, and this would be good
tool to have in some cases.

> multiple instances of this field to be added.

Password change requests are an easy one, because they're automated. In fact
this makes me think about the more general use-case here of preventing a new
"owner" of an address from finding out about an account the previous owner had
somewhere. If I get mail - never mind what - directed at the previous owner,
and it's one of those systems that has a "I forgot my password" button that
works by sending the password reset sequence to the registered email address,
and the account has a stored credit card #... See the problem?

> mailbox.

OK, so how does a client determine the nature of the content automatically? I
don't know about anyone else, but I've written highly confidential reviews of
things using exactly the same commands that I used to forward an article to a
couple of friends.

> Describing UI things like buttons seems to go into more specifics

My point wasn't that the specification should go into these sorts of specifics,
but rather that such interfaces aren't going to work. Unless there's something
about this I'm not seeing, The only way this works is if it works
automatically.

> or complete at this early stage.

Fair point. I should also add that things like the password use-case
should be mentioned here. Security considerations aren't just about
problems but also the solutions the proposal provides.

> Sure, those can be added.  But don't we already do that near the end of

I was talking about a cite from the security considerations to section 3.

				Ned

---

From: "John R Levine" <[email-masked]>
Date: 20 Jul 2013 22:23:48 -0400

>> to be immune to ownership changes.

Huh?  If I buy some abandoned domain, [email-masked] will be a 
different entity/person/whatever than it was for the previous owner.  If 
you want to contact the current postmaster, send mail without an rrvs 
header.  If you have some mailing list where the previous owner signed up 
as postmaster (we know it's a bad idea but people do it), then it seems to 
me that rrvs would be as likely to do the right thing as it would for any 
other address.

It'd somewhat mitigate the damage if the advice to the receiver was to 
compare the address in the rrvs header to the envelope, if that address is 
one of the recipients then reject the message if the date is too old, 
otherwise ignore it, but unconditionally delete the header before 
subsequent forwarding or relaying.  Even if the address in the header 
turns out to be one to which it is subsequently relayed, if that's not the 
address to which the author originally sent the message, the chances of 
rrvs doing the right thing seem quite low.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: Bill Mills <[email-masked]>
Date: Sat, 20 Jul 2013 21:19:08 -0700

Well, not entirely.  One of my e-mail providers, eskimo.com, took over netcom.com and continued to run it, and we kept control of our accounts there.  That use case was not an abandoned domain, it was a loosely coupled transfer.  In the end that's pretty rare though, and they could solve it for RRVS without changing the spec.

-bill

________________________________
 From: John R Levine <[email-masked]>
To: Ned Freed <[email-masked]> 
Cc: IETF Apps Discuss <[email-masked]> 
Sent: Saturday, July 20, 2013 7:23 PM
Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00

>> Another thing that needs to be mentioned is use of this facility when an entire domain changes ownership. This is a little more complex than it appears because of the need for addresses like [email-masked] to be immune to ownership changes.

Huh?  If I buy some abandoned domain, [email-masked] will be a different entity/person/whatever than it was for the previous owner.  If you want to contact the current postmaster, send mail without an rrvs header.  If you have some mailing list where the previous owner signed up as postmaster (we know it's a bad idea but people do it), then it seems to me that rrvs would be as likely to do the right thing as it would for any other address.

It'd somewhat mitigate the damage if the advice to the receiver was to compare the address in the rrvs header to the envelope, if that address is one of the recipients then reject the message if the date is too old, otherwise ignore it, but unconditionally delete the header before subsequent forwarding or relaying.  Even if the address in the header turns out to be one to which it is subsequently relayed, if that's not the address to which the author originally sent the message, the chances of rrvs doing the right thing seem quite low.

Regards,

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 21 Jul 2013 01:02:47 -0700

> party actually is a current recipient.

Going back to this topic:

I'd like to understand your problem statement a little better.  Given this
(and being lazy about the field name and content):

--

MAIL FROM:<generator@example1>
RCPT TO:<user@example2>

From: generator@example1
To: user@example2
RRVS: user@example2; <Monday>
Date: <Today>

<some sensitive content>

--

Assume this arrives at the "example2" mail server.  The test is to
determine if the server handles "example2" mail (which, by definition, it
does), and then whether the named mailbox has been under continuous
ownership since "<Monday>".  If the answer to the first is "no", ignore the
field and process normally; if the answer to the second is "no", don't
deliver the message.

If I understand your concern, you're saying this is a problem where the
message gets forwarded, let's say to other@example3.  This would yield:

--

MAIL FROM:<generator@example1>
RCPT TO:<other@example3>

From: something@example1
To: user@example2
RRVS: user@example2; <Monday>
Date: <Today>

<some sensitive content>

--

Only the envelope recipient has changed; as you said, the main header
fields are unmodified.  Presumably though, this would land at a server that
handles mail for example3 mailboxes, not example2 mailboxes.  So yes, the
check against the envelope would fail, but the "is this local?" test would
also fail, so in this case the extra check wouldn't improve anything.

If the servers handling example2 and example3 are the same server, then
that same server is still in a position to evaluate the header field.

What's the forwarding scenario you're imagining?  Is it different from this?

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 21 Jul 2013 01:08:55 -0700

> not to make the problems worse.

So then a "process this once and then delete it" requirement is what you
have in mind?

> and the account has a stored credit card #... See the problem?

Yes, of course.  That's pretty much the entire use case that started this
effort.

We don't state anywhere that this is intended for use with auto-generated
messages only, but perhaps it would be good to mention that this is the use
case we have in mind.  It also answers the question about the conditions in
which an author would decide to use this.

> > > "additional recipient verification" or something like that, but let's
> face
> > > it,

I think this follows nicely from above.  This isn't anticipated to be used
by humans, but rather by automated things like password change requests and
other sensitive but automated things.

> about this I'm not seeing, The only way this works is if it works

Right, that's the primary use case.  I'm thinking we need to make that more
clear.

-MSK

---

From: Ned Freed <[email-masked]>
Date: Sun, 21 Jul 2013 07:42:00 -0700 (PDT)

No. The concern is when the RRVS header says:

RRVS: other@example3; <distant past>

This sort of thing happens when messages are resent without
encapsulation.

> What's the forwarding scenario you're imagining?  Is it different from this?

Yes. See above. And there's also the case of intentional inclusion of such
things to consider, which could allow probing of what happens to mail after
it reaches the address the originator specified as the destination.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Sun, 21 Jul 2013 08:44:07 -0700 (PDT)

> So then a "process this once and then delete it" requirement is what you

No, because you can't be sure that the processing will occur, so it creates
even more astonishment. And I don't see how this could be implemented while
retaining the semantics given in the specification in any case.

My objection was and is to the semantics the current draft calls for. It says:

 1.  A user subscribes to a service "S" on data "D" and confirms an
       email address at the user's current location, "A";

   2.  At some later date, the user intends to leave the current
       location, and thus creates a new mailbox elsewhere, at "B";

   3.  The user replaces mailbox "A" with forwarding to "B";

   4.  "S" constructs a message to "A" claiming that address was valid
       at date "D" and sends it to "A", which forwards to "B";

   5.  The receiving MTA at "B" asserts that "B" has not been under
       constant ownership since "D" and rejects the message.

I think the result in 5 is flat out wrong, and what should be happening is
exactly the opposite: The message goes through and is delivered.

First of all, as I noted previously, there is no way to actually implement
these semantics in a fashion that's consistent with what's in the draft. If
mailboxes A and B are under different administrative domains - and they often
will be - then implementing these semantics directly contradicts the semantics
called for in section 3 because address "A" in the RRVS field is going to be
seen as foreign by the receiving MTA at "B" and ignored. So unless we're simply
going to ignore the recipient address in the RRVS field entirely - and in that
case why is it even there -  the behavior you're going to get is going to be
wildly inconsistent. (Of course behavior is going to be wildly inconsistent
until this proposal either succeeds or fails, but the design really does need
to offer some measure of consistency in the event that it does succeed.)

And also as I noted earlier, I think this behavior produces the wrong result. I
personally have used forwarding extensively in order to be able to move where
my mail actually ends up to a new place without having to find and fix all of
the various things that send to the old address. When I do this what I want is
to have *everything* that was sent to the old address go to the new one,
including and in fact most especially sensitive stuff. I strongly doubt I'm
alone in this.

As long as I continue to own address A in this or many similar scenarios, what
happens to mail sent to it after it reaches address A is my business and also
my responsibility. And yes, there are attacks associated with bogus forwarding,
but you're not going to thwart those with this mechanism so they aren't
relevant. (Attackers setting up bogus forwarding are going to direct it to a
system that doesn't implement these checks.) And there will also be problems
associated with inexperienced users receiving mail at one address but sending
it from another - another thing this proposal can't fix.

I'll also that that there are mechanisms besides forwarding available that will
move mail sent to one place to another after delivery. Indeed, several of the
same MSPs this proposal will need support from offer "consolidated mailbox
views" and similar things as a value-add. (Think "fetchmail on steroids".) They
are certainly not going to implement the spirit of this specification as
written as part of those services because that would significantly reduce the
value-add.

And more generally, it's vitally important to keep in mind the asymmetries in
cost and benefit that affect so many email-related proposals, including this
one. The benefit of this mechanisms accrues to the actors at either end, and
also to the former mailbox owner. But the heavy lifting to be done here is by
the MSPs, who have to implement all this check-and-reject logic, or get their
software vendors to implement it for them. (And the supposedly simpler case the
draft tries to focus on doesn't really make implementation any easier, because
anything that's possible has to be handled sensibly, admonitions not to use it
notwithstanding.) And the benefit to MSPs is indirect at best, and likely
negligible in many cases. This means that anything that significant chance of
causing support calls - and the semantics you're calling for here absolutely
qualify - is a nonstarter.

> which an author would decide to use this.

Um, yeah, that's kind of critical. I certainly did not make that assumption
and it seems that pretty much nobody else did either.

But if we're going to standardize something here, given the difficulty getting
things like this deployed as well as the fact that having two slightly
different schemes solving the same problem for different constituencies is
almost certainly not going to happen, it's actually quite urgent that this be
as flexible and failsafe as possible, even if that means a bit more complexity.

> other sensitive but automated things.

I will also point out that by focusing on the automated responses from service
providers you're going to have a *very* tough time making the case that this
should not be done with an SMTP extension. Consider: You're basically talking
about Amazon sending notices to Gmail now. In such cases there aren't going to
be any SMTP intemediaries, so the value of using a header to avoid issues with
intermediary extension support is gone. And the SMTP extension for this is
incredibly simple: It's just a date parameter on the RCPT TO. It never ends up
in the message itself, so issues with resending all vanish. As to issues with
autoforwarding or messages sent to mailing lists - you simply drop the
parameter and all those problems go away. And if the receiving software doesn't
know how to handle those cases it isn't going to offer the extension. All the
issues with multiple recipients also disappear since the date is tightly
associated with the recipient. And so on.

Really, it's a win all around, except of course for regular clients, who can't
use the mechanism without support from their provider and thus end up screwed.
But you've just eliminated them from consideration so...

				Ned

---

From: "John R Levine" <[email-masked]>
Date: 21 Jul 2013 22:35:41 -0400

>       constant ownership since "D" and rejects the message.

But the rrvs header will have the "A" address in it, and B is supposed to 
ignore it.

I'm more worried about what happens when a hostile sender deliberately 
puts a "B" address in a message that's likely to be remailed or forwarded.

Regards,

---

From: Bill Mills <[email-masked]>
Date: Sun, 21 Jul 2013 19:54:40 -0700

No, what is supposed to happen is that the mail gets to the MTA for A where  forwarding is configured and the RRVS check needs to be done there.  They never forward to B.

-bill

________________________________
 From: Ned Freed <[email-masked]>
To: Murray S. Kucherawy <[email-masked]> 
Cc: John R Levine <[email-masked]>; Ned Freed <[email-masked]>; IETF Apps Discuss <[email-masked]> 
Sent: Sunday, July 21, 2013 8:44 AM
Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00

                Ned

---

From: "John R Levine" <[email-masked]>
Date: 21 Jul 2013 23:02:06 -0400

> No, what is supposed to happen is that the mail gets to the MTA for A where  forwarding is configured and the RRVS check needs to be done there.  They never forward to B.

In this case the person already has the "A" account and configures it to 
forward to his new "B" account.  The correct thing would be for A to look 
at rrvs, see an address it knows, accept the message and forward it.  B 
looks at rrvs, sees an unknown address and ignores it.

I think that for non-hostile senders this should work OK.  My concern is 
what happens with senders who deliberately or accidentally play games.

R's,
John

---

From: Bill Mills <[email-masked]>
Date: Sun, 21 Jul 2013 20:13:51 -0700

Yes, A applies the RRVS policy to determine if it will deliver (delivery happens to be a forward.  B in this case ignores.

-bill

Sent: Sunday, July 21, 2013 8:02 PM

R's,
John

---

From: Ned Freed <[email-masked]>
Date: Sun, 21 Jul 2013 22:24:44 -0700 (PDT)

> But the rrvs header will have the "A" address in it, and B is supposed to

That's exactly my point. It's supposed to ignore it, not notice that
"B" has not been under constant ownershp and reject. It can't do what the
document says it's supposed to do. THe only way it can do what this
section says to do is check address "B" against the date associated with "A",
which of course is all sorts of bad.

> puts a "B" address in a message that's likely to be remailed or forwarded.

I'm worried about that as well.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Sun, 21 Jul 2013 22:28:37 -0700 (PDT)

> No, what is supposed to happen is that the mail gets to the MTA for A where 
> forwarding is configured and the RRVS check needs to be done there.  They never
> forward to B.

Why would they do that? The address meets the ownership criteria. And it's
the wrong result in any case.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Sun, 21 Jul 2013 23:19:37 -0700 (PDT)

> header.

How is the user supposed to control that?

I grant you that it is unlikely for a postmaster address to appear in
a user address book. But if it happens it needs to do the right thing, and
bouncing mail sent to postmaster is not it.

> If you have some mailing list where the previous owner signed up

I don't think a bounce should be generated in this case.

> subsequent forwarding or relaying.

Agreed 100%. I think this is excellent advice that should be included,
but I do note that this may be the first time we've recommended doing 
header modifications on autoforwarding. Additions, sure, but this goes further.

> Even if the address in the header

Agreed again.

				Ned

---

From: William Mills <[email-masked]>
Date: Mon, 22 Jul 2013 06:32:30 +0000

I was thinking it would be a useful thing to advertisr in some way...  If not then no worries.

Sent from my Verizon Wireless 4G LTE Smartphone

---

From: Bill Mills <[email-masked]>
Date: Sun, 21 Jul 2013 23:49:58 -0700

I said it better in the other message.  The intent is to evaluate rrvs at the server that should know about the primary addressee, in this case A.  A applies the policy and then either bounces or delivers.  Once forwarded rrvs would never apply.  Conceptually this makes sense as the sender only knows about the primary recipient(s) and is ignorant of forwarding (how the mail will be delivered).

-bill

________________________________
 From: Ned Freed <[email-masked]>
To: Bill Mills <[email-masked]> 
Cc: Ned Freed <[email-masked]>; Murray S. Kucherawy <[email-masked]>; John R Levine <[email-masked]>; IETF Apps Discuss <[email-masked]> 
Sent: Sunday, July 21, 2013 10:28 PM
Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00

                Ned

---

From: Ned Freed <[email-masked]>
Date: Sun, 28 Jul 2013 09:05:12 -0700 (PDT)

Getting back to this; sorry for the delay in responding.

> A sends to B who has forwarded to C.  This needs to be applied at the MTA
> handling B, that's what we were trying to solve here.

Then you need to correct your example in section 4, because this is exactly the
opposite of what it says. 

I also note that your terminology is inconsistent; here you talk about A
sending to B forwarding to C, whereas in the document you talk about S sending
to A forwarding to B. So when you say this process needs to be "applied by B"
here that corresponds to "applied by A" in the document, but the document in
fact says it is to be "applied by B":

>  Comparing to the
> original envelope seems useful for confirming validity of the header itself,
> but I don't see much utility beyond that.  Am I missing something?

That's precisely what it's is useful for - enormously so. Why should there need
to be any utility beyond that?

> This starts to get a LOT hairier if we have to do a multi-valued rrvs header,
> and it's not the problem we're trying to solve right now.  So we might allow
> multiple rrvs headersto solve this?  Each one needing to apply to a recipient
> in the envelope?

It may not be the problem *you* are trying to solve right now, but if you
expect such a proposal to catch on, you need to make it as appealing as
possible to as wide an audience as possible. As I've noted previously, your
single proposed use-case has a significant cost-benefit asymmetry - the cost,
including explaining to people why their mail isn't working properly, is born
by receiving agent but the benefit accrues to sender.

In the past the fate of proposals with similar characteristics has been mixed
at best.

And this is hardly rocket science to get right given you already need to
perform an envelope check: For a given recipient, all
you need to do is check each RRVS header for that recipient address, and if
there's a match, do the date comparison. Speaking for myself, this adds
a whopping total of three additional lines of code to my imlementation.

Indeed, this process is easy part; the date comparison is in practice going
to be considerably more difficult. About the simplest form I can see working
is something like this:

(0) Is this one of several reserved addresses including, but maybe not limited
    to postmaster@* or abuse@*? If so ignore the check.

(1) Has the domain part of this address been associated with the same
    administrative entity since the date given in the header? If not reject
    the message.

(2) Has the address as a whole been under the same ownership since the
    data specified in the header? If not reject the message.

And this is the simplest it can be; there are going to be cases where the
notion of continuous ownership is the wrong one to apply and are going to be a
lot more complicated.

All that said, the main problem with the multiple recipient case is that it
leaks information about when the originator first started corresponding with
someone. This is actually a problem I hadn't considered before, and it exists
even for the single recipient case. In fact coupled with the narrow use-case
you're aiming at it argues strongly for recasting this as an SMTP extension.

If you really want to continue with this as a header mechanism you're going to
need both broaden your target audience and specify all the cases you've been
reluctant to deal with so far. My suggestion here is to either cut bait and
switch to an SMTP extension or else define the mechanism so it can handle
multiple reicpients but warn about the dangers and recommend sending separate
messages to each recipient.

> The sender has no information on how delivery will happen, forwarding is a
> form of delivery in this use case, and once you're forwarding RRVS should never
> apply. 

If so that's great, but again, that's not wnat your document says. I can only
go by what you write; I had no means of divining that your intent was exactly
the opposite.

> why do we need a new one?  X.1.6 seems to fit well?

On the contrary, it doesn't fit at all. The description of this error code is
very clear and it says it's to be issued when the address is no longer valid.
That's absolutely not the case here - the address is perfectly valid, but
ownership may not be the same so the message is being rejected rather than risk
delivery to the wrong person.

And even if this was within the scope of this error code, it would still
be a bad idea to use it. A separate error code is needed so it's clear
when this mechanism was used to reject a message.

> A fair point.  A different error return could be useful here.  Another way to
> do this would be to have an RRVS SMTP extension that advertises domains and
> the length of ownership.  Needs more thought.

An advertisement doesn't work, doesn't scale, and has all sorts of nasty
security implications.

The main reason it doesn't work is it requires no SMTP intermediaries be
present. But even if you assume a single hop, suppose I advertise domain.com.
Does that apply to foo.domain.com? (And I can assure you that while uncommon,
cases where foo.domain.com has been under the same management but domain.com
and all other subdomains of domain.com have not do exist.)

As for scaling, there are MSPs that service thousands or even 10s of thousands
of domains, and they absolutely are in your target audience. That's going to
a hell of an advertisement.

No, if you want to do this as an SMTP extension, it would need to look
something like this:

S:220 server.domain.com
C:EHLO [x]
S:250-server.domain.com
S:250-ENHANCEDSTATUSCODES
S:250 VALIDSINCE
C:MAIL FROM:<[email-masked]>
S:250 2.1.5 Ok
C:RCPT TO:<[email-masked]> VALIDSINCE=19961219T163957-08:00
S:550 5.1.x Address ownership has changed since 19961219T163957-08:00
...

> Can be fuller, sure.  Got text?

Not at present.

> Meaning if a provider incorrectly rejects mail?  Is this significantly
> different from the impact of current failures to delver when a DB lookup fails
> and you get a "no such user" when you know it exists?

Um, yeah, it's significantly different. For one thing, a DB lookup failure is
going to be erratic, whereas a failure caused by bogus data attached to an
account is going to occur consistently until the problem is corrected. The same
thing goes for problems caused by RRVS header fields escaping into messages
they weren't intended for.

Besides, we have a technical turn of phrase for such DB lookup failures:
Egregious bugs that should never occur in practice, and when they do occur they
are caused by incompetent software engineering. Whereas all it it takes for
RRVS to go wrong is an unfortunate combination of circumstances.

				Ned