Subject: [apps-discuss] Applications Area Review of draft-ietf-appsawg-rrvs-header-field-05

From: Eric Burger <[email-masked]>
Date: Mon, 23 Dec 2013 13:29:45 -0500

I have been selected as the Applications Area Review Team reviewer for this draft. For background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team
 
Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft.
 
Document: draft-ietf-appsawg-rrvs-header-field-05
Title: The Require-Recipient-Valid-Since Header Field and SMTP Service Extension
Reviewer: Eric Burger
Review Date: 23-December-2013
 
Summary: Short of a toxic waste warning indicating that this mechanism does not provide a guarantee of delivery to the intended addressee, this document is pretty much ready for publication.

MAJOR ISSUES
While this mechanism is not as bad as the ill-fated recall message mechanism, it shares the same characteristic. Namely, this extension is at best a request. What makes is not as bad as recall message is the use case is for big, industrial message senders sending messages to big, industrial messaging service providers (MSPs). In this scenario, the sender presumably fully understands this mechanism will not relieve them of SOX or HIPPA or other regulatory requirement not to inadvertently release information. Likewise, the MSP is advertising (out of band) to these large enterprises that they will do their best to honor the RRVS mechanism.

The problem is like anything in the Internet, this mechanism will leak out from this particular use case. Specifically, someone will invariably expose the mechanism to a MUA UI. Therefore, I would insert the following language in the document. My proposal would be at the end of Section 4, to the effect of:
   The initial use for the mechanism described in this document is for machine-generated
   messages, such as from a bank to a user. This specification presumes an enterprise
   application developer understands the limitations of the mechanism. For an interactive
   mail application used by casual users, if the user requests the use of the mechanism
   described in this document, we RECOMMEND the application displays a dialog box or
   other appropriate indicator, in the user's language, stating the RRVS request is a
   suggestion only and the message is likely to be delivered, without warning or notice
   to the sender.
 
Along the lines of the above, we could use a mechanism such as RFC3459. If you are a MUA and your SUBMIT server does not support RRVS, fail. If you are a SUBMIT server or MTA and the next hop does not support RRVS, fail.
 
There is no way to prevent a bad actor from commandeering a domain for the purposes of snagging personal information from unsuspecting users. Because of this, I would insist that the Security section point out that this mechanism does not provide any security against a sender inadvertently releasing personal information to a stale address. One known mechanism to ensure the right user receives the information is to encrypt the message in such a manner that only the right user can decrypt the message. See S/MIME (RFC5751) or PGP (RFC4880) for examples of how to ensure only the right user* can read the message.  [* Admittedly, this only says that an entity with a decryption key can read the message, but that is infinitely more security than what RRVS offers.]
 
p. 17, Section 15.3: How would an MTA know the message was forwarded and not originated? Is this not a UA thing?
 
I would offer Ned's issues raised on 13 December 2013 at 9:50am PT should all be addressed. I have no opinion on the DKIM signature issues, other than that if we have a header that pops in and out of existence, it makes no sense to attempt to calculate a signature over it (except for hop-by-hop).

MINOR ISSUES
p. 8, step 7: "being forwarded" is ambiguous. Is this a user forwarding amessage in a MUA UI or is this a mail server forwarding a message to a more appropriate address?
 
p. 8, Section 6: Does this say something? If it does, it is not clear what it is saying. A "user handling those mailboxes" would know if ownership changed, because they are a "user *handling*" the mailbox. If it is about a sender learning that ownership changed, then this is a no-op because the MTA/MUA are not supposed to do RRVS processing on role mailboxes.
 
p. 8, Section 7: as others have noted, there needs to be a forward reference to Section 10 here, or move Section 10 earlier in the document.
 
p. 9, Section 7.1: There is a complement to the spam processing discussed in Section 14.2. Specifically, if a malevolent actor is monitoring mail traffic, a RRVS header might be an indicator the message will be of interest or high value.
 
p. 10ff, Section 9.2: Would it not be better to just say this whole think is a "matter of local policy"? The goal is to make sure it makes sense to deliver, or reject, a message in the case of a change of ownership of the mailbox. These steps are all situation-dependent and not really of general value. Same for Section 9.4.

NITS
Others have found them, so no need to reiterate them here.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 23 Dec 2013 10:51:41 -0800

>     suggestion only and the message is likely to be delivered, without warning or notice

The basic concern that the specification highlight the limitations of 
the mechanism being specified is fine.

However IETF specs need to keep away from offering advice about 
interactions with human users.  Every time we try to offer that advice, 
it demonstrates how little the IETF community knows about human computer 
interaction, usability, and user-centered design.

Hence, if a warning is required, it needs to be from the specification 
writer to the specification reader.  How the reader chooses to act on 
the warning is not the business of the IETF.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 24 Dec 2013 01:58:21 -0800

Hi Eric, thanks for your comments.

On Mon, Dec 23, 2013 at 10:29 AM, Eric Burger <[email-masked]>wrote:

> MAJOR ISSUES
> While this mechanism is not as bad as the ill-fated recall message
> mechanism, it shares the same characteristic. Namely, this extension is at
> best a request. What makes is not as bad as recall message is the use case
> is for big, industrial message senders sending messages to big, industrial
> messaging service providers (MSPs). In this scenario, the sender presumably
> fully understands this mechanism will not relieve them of SOX or HIPPA or
> other regulatory requirement not to inadvertently release information.
> Likewise, the MSP is advertising (out of band) to these large enterprises
> that they will do their best to honor the RRVS mechanism.
>
> The problem is like anything in the Internet, this mechanism will leak out
> from this particular use case. Specifically, someone will invariably expose
> the mechanism to a MUA UI. Therefore, I would insert the following language
> in the document. My proposal would be at the end of Section 4, to the
> effect of:

I agree with Dave Crocker's reply here; I believe we've gone out of our way
lately to acknowledge that UI matters are outside of our scope, and we
should consider that a luxury and enjoy it as long as we can.

That said, it's probably reasonable to be clear that use of either form of
RRVS is not a guarantee of anything.  It's more likely to give a sender
what it wants if the receiving system advertises the extension, but even
then it's not certain to do what's being asked.

>
> Along the lines of the above, we could use a mechanism such as RFC3459. If
> you are a MUA and your SUBMIT server does not support RRVS, fail. If you
> are a SUBMIT server or MTA and the next hop does not support RRVS, fail.
>
>
The latter is certainly an option, and some prefer it.  Section 7 indicates
that preference in general.  However, there is running code out there
already that we need to acknowledge which isn't so strict.

>
> There is no way to prevent a bad actor from commandeering a domain for the
> purposes of snagging personal information from unsuspecting users. Because
> of this, I would insist that the Security section point out that this
> mechanism does not provide any security against a sender inadvertently
> releasing personal information to a stale address. One known mechanism to
> ensure the right user receives the information is to encrypt the message in
> such a manner that only the right user can decrypt the message. See S/MIME
> (RFC5751) or PGP (RFC4880) for examples of how to ensure only the right
> user* can read the message.  [* Admittedly, this only says that an entity
> with a decryption key can read the message, but that is infinitely more
> security than what RRVS offers.]
>

If by this you mean someone can intercept messages destined for a given
domain, then of course that's true, but doesn't that also mean any document
about email has to cite that as a possibility?

Of course RRVS could be supplanted by S/MIME or PGP to reach the same
goals, but those protocols haven't enjoyed anywhere close to enough
deployment to make them practical solutions to this application, and that
seems unlikely to change in the near future.

> not originated? Is this not a UA thing?

Either way, the RRVS header field is now in the hands of some third party
(i.e., not the one named in the header field), and the timestamp is thus no
longer private.  Given that, is it an important distinction to make?

>
> I would offer Ned's issues raised on 13 December 2013 at 9:50am PT should
> all be addressed. I have no opinion on the DKIM signature issues, other
> than that if we have a header that pops in and out of existence, it makes
> no sense to attempt to calculate a signature over it (except for
> hop-by-hop).
>

They've all been addressed for the next revision.

>
> MINOR ISSUES
> p. 8, step 7: "being forwarded" is ambiguous. Is this a user forwarding
> amessage in a MUA UI or is this a mail server forwarding a message to a
> more appropriate address?
>

The latter.  Will change the section to start "A receiving MTA ...".

>
> p. 8, Section 6: Does this say something? If it does, it is not clear what
> it is saying. A "user handling those mailboxes" would know if ownership
> changed, because they are a "user *handling*" the mailbox. If it is about a
> sender learning that ownership changed, then this is a no-op because the
> MTA/MUA are not supposed to do RRVS processing on role mailboxes.
>

Will clarify.

>
> p. 8, Section 7: as others have noted, there needs to be a forward
> reference to Section 10 here, or move Section 10 earlier in the document.
>

Section 10 merely discusses our choices for the syntax of the header
field.  I'm not sure what relocating it or referring to it from Section 7
would accomplish.  Can you clarify?

>
> p. 9, Section 7.1: There is a complement to the spam processing discussed
> in Section 14.2. Specifically, if a malevolent actor is monitoring mail
> traffic, a RRVS header might be an indicator the message will be of
> interest or high value.
>

Good point.  Will mention this in 14.2.

> p. 10ff, Section 9.2: Would it not be better to just say this whole think
> is a "matter of local policy"? The goal is to make sure it makes sense to
> deliver, or reject, a message in the case of a change of ownership of the
> mailbox. These steps are all situation-dependent and not really of general
> value. Same for Section 9.4.
>

This seems to go hand-in-hand with your first point about the whole thing
being no more than a request to the receiving system.  We could probably
cover both points in one short paragraph or two.  Will take a run at doing
so for the next version.

-MSK

---

From: Eric Burger <[email-masked]>
Date: Tue, 24 Dec 2013 07:19:56 -0500

Looks like a plan. Responses in line. Unless someone else wants to jump in and insist on something. I am happy. Other thoughts in line.

On Dec 24, 2013, at 4:58 AM, Murray S. Kucherawy <[email-masked]> wrote:

> On Mon, Dec 23, 2013 at 10:29 AM, Eric Burger <[email-masked]> wrote:
> MAJOR ISSUES
> I agree with Dave Crocker's reply here; I believe we've gone out of our way lately to acknowledge that UI matters are outside of our scope, and we should consider that a luxury and enjoy it as long as we can.
> 
> That said, it's probably reasonable to be clear that use of either form of RRVS is not a guarantee of anything.  It's more likely to give a sender what it wants if the receiving system advertises the extension, but even then it's not certain to do what's being asked.

A recommendation carries zero force, but highlights something the IETF feels is important. How users perceive what the mechanism does is important.

> The latter is certainly an option, and some prefer it.  Section 7 indicates that preference in general.  However, there is running code out there already that we need to acknowledge which isn't so strict.

Which part of “draft-“ is not understood by the community? I thought this was a standards track document, not an individual informational documenting current practice.

> If by this you mean someone can intercept messages destined for a given domain, then of course that's true, but doesn't that also mean any document about email has to cite that as a possibility?
> 
> Of course RRVS could be supplanted by S/MIME or PGP to reach the same goals, but those protocols haven't enjoyed anywhere close to enough deployment to make them practical solutions to this application, and that seems unlikely to change in the near future.

The difference is RRVS is being marketed as an answer to the problem of delivering a message to the right *person*, not just the right *mailbox*. I am not aware of other email protocol proposals that offer this property, other than S/MIME and PGP.

> Either way, the RRVS header field is now in the hands of some third party (i.e., not the one named in the header field), and the timestamp is thus no longer private.  Given that, is it an important distinction to make?

It was just confusing to me. If the point is the header To and RRVS are different, maybe just say that?
[snip]
> MINOR ISSUES
[snip]
> Section 10 merely discusses our choices for the syntax of the header field.  I'm not sure what relocating it or referring to it from Section 7 would accomplish.  Can you clarify?

Section 10 also describes how things can break. When I first read the document, I was thinking to myself “why all of these rules for putting in and taking out headers?” It became clearer after I got to Section 10.
[snip]

---

From: Ned Freed <[email-masked]>
Date: Tue, 24 Dec 2013 09:36:47 -0800 (PST)

Quick comment here.

> longer private.  Given that, is it an important distinction to make?

More to the point, nothing in section 15.3 calls for MTAs to have any knowledge
of whether a message is forwarded or not. Indeed, this puts the cart before the
horse: The sequence is for the field to be removed as the message is delivered,
so that if the message is forwarded later the field isn't there to leak
information or cause other mischief.

That said, there's a problem with the prose in this section: The earlier
recommendation is to remove the field as messages are delivered. MDAs deliver
messages, not MTAs. And this section does not make it clear that it is talking
about delivery-time removal. So how about changing

    MTAs might not implement the recommendation to remove the header
   field defined here, either out of ignorance or due to error.

to something like

    MDAs might not implement the recommendation to remove the header
    field defined here when messages are delivered, either out of
    ignorance or due to error.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Tue, 24 Dec 2013 09:53:33 -0800

On 12/24/2013 4:19 AM, Eric Burger wrote:
> Looks like a plan. Responses in line. Unless someone else wants to jump
> in and insist on something. I am happy. Other thoughts in line.
>
> On Dec 24, 2013, at 4:58 AM, Murray S. Kucherawy <[email-masked]
> <mailto:[email-masked]>> wrote:
>> That said, it's probably reasonable to be clear that use of either
>> form of RRVS is not a guarantee of anything.

+1

> A recommendation carries zero force, but highlights something the IETF
> feels is important. How users perceive what the mechanism does is important.

The issue is not whether this is important but whether advice that is 
given is appropriate.

With respect to the IETF giving user interface advice, it typically is 
far outside the scope of the IETF's expertise and frankly what the IETF 
writes in that realm usually demonstrates the limitation.  The typical 
example I cite is represented here, namely that we tend to think that 
giving users more information is always a good thing.

For the IETF, what is important is making clear the semantics.  In this 
case, making clear that a request is only a request.

d/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 24 Dec 2013 22:31:03 -0800

On Tue, Dec 24, 2013 at 4:19 AM, Eric Burger <[email-masked]>wrote:

>
>
>
>> Along the lines of the above, we could use a mechanism such as RFC3459.
>> If you are a MUA and your SUBMIT server does not support RRVS, fail. If you
> The latter is certainly an option, and some prefer it.  Section 7
> indicates that preference in general.  However, there is running code out
> there already that we need to acknowledge which isn't so strict.
>
>
> Which part of “draft-“ is not understood by the community? I thought this
> was a standards track document, not an individual informational documenting
> current practice.
>

I don't believe "standards track document" and "documenting current
practice" are mutually exclusive, are they?

>
>
>
>>
>> There is no way to prevent a bad actor from commandeering a domain for
>> the purposes of snagging personal information from unsuspecting users.
>> Because of this, I would insist that the Security section point out that
>> this mechanism does not provide any security against a sender inadvertently
> The difference is RRVS is being marketed as an answer to the problem of
> delivering a message to the right *person*, not just the right *mailbox*. I
> am not aware of other email protocol proposals that offer this property,
> other than S/MIME and PGP.
>
>
RRVS also has limitations that don't affect S/MIME and PGP, namely the
impacts of forwarding.  I believe that the document already discusses those
issues sufficiently, however.

> different, maybe just say that?

That isn't the point.  The issue here is a message that gets forwarded when
it contained the RRVS header field.  It might get forwarded by an MTA, a
list, or an MUA.  If the previous MTA(s) failed to scrub the RRVS
information as the spec says they should have, then that information has
now possibly been given to someone that shouldn't have it.  In the specific
case of a user agent doing so, the forwarding user might not (in fact,
probably wouldn't) know the RRVS information was there in the message being
forwarded because it's likely not a header field made visible to that
user.  The scrubbing rules don't apply to a message that was locally
originated, so that's not the case being discussed here.

> Section 10 also describes how things can break. When I first read the
> document, I was thinking to myself “why all of these rules for putting in
> and taking out headers?” It became clearer after I got to Section 10.
> [snip]
>
>
Ah, I see what you mean.  I'll re-distribute the content of Section 10
upward.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Thu, 26 Dec 2013 11:59:34 -0500

On 12/25/2013 1:31 AM, Murray S. Kucherawy wrote:
> On Tue, Dec 24, 2013 at 4:19 AM, Eric Burger
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     �
>>
>>
>>         Along the lines of the above, we could use a mechanism such
>>         as RFC3459. If you are a MUA and your SUBMIT server does not
>>         support RRVS, fail. If you are a SUBMIT server or MTA and
>>         the next hop does not support RRVS, fail.
>>
>>
>>     The latter is certainly an option, and some prefer it.� Section
>>     7 indicates that preference in general.� However, there is
>>     running code out there already that we need to acknowledge which
>>     isn't so strict.
>
>     Which part of �draft-� is not understood by the community? I
>     thought this was a standards track document, not an individual
>     informational documenting current practice.
>
>

IMO, in this case, yes, they are.  Given a short list of:

1) The unclear, "non-standard" definition of what the RRVS "time" is,
2) Its potential for inconsistent usage,
3) The high risk of user data exposure here, a Pandora Box consideration,
4) The risk of still sending and received unsecured messages,
5) No one is using this yet across the board, not in production mode 
yet, that I am aware of, etc.

This all sounds like an EXPERIMENT, not a standard track item.  It 
could be an INFORMATIONAL document at this time and probably better to 
be describing a problem looking for a solution. I am not sure the RRVS 
is it.  This is currently an experimentation with a very high 
potential of being only used for exclusive relationships, i.e. a joint 
venture (Yahoo and Facebook) with a technology transfer of information 
to better synchronized heterogeneous user databases.   To do this in a 
standard way, the RRVS time has to be better defined. It is not.

The "problem" has long existed for all Online Application Hosting 
Vendors, such as us with over 30 years of deployments systems in all 
market segments, all vendors that offer a public signup service had 
the same constraints. It absolutely did not nor does not apply to just 
the "big industrial" guys.  It applies to all market segments, small, 
large, even the hobbiest public service system and especially the 
smaller systems were user account expirations is more frequent.

What has changed since yesteryears is the higher collision rates of 
more people with similar user names, not only within the USA, but 
global, to be used for authentication and electronic media contact 
addresses.  In the past, the normal practice to deal with a collision 
was to just assign a different user id.

But if the user account was deleted (for whatever reasons), and then 
reclaimed by a different person or assigned to a different person by 
the owner domain, we have the email security risk this proposal is 
attempting to address.  So the problem is well understood, But I am 
not sure the RRVS is the solution without a well defined terminology 
for the TIME attribute.  It is too open-ended for this to be declared 
a standard.  I don't think it is correct to just say this is a local 
design/policy decision. There has to be some persistency and 
consistency in the public and private mail transport business.

Note, this is not to say I won't support it in our package, but I 
can't until that TIME value is better defined.  The way I see it from 
an software engineering standpoint, each potential RRVS client can 
have different definitions of what the RRVS time is and what also 
different fields of what it is suppose to be compared to in the 
receiver's local user database.  Overall, it sounds like it wants us 
to create a new "Change of Ownership Date" field in user databases. 
Yet, it also appears this means this is more of a 1 to Many multiple 
definition field -- one for each potential RRVS client sending mail to 
a user but each has their own idea for what this time is.  This means 
that a SENDER DOMAIN field may need to be added as well

     OwnerShipDateTime.DateTime
     OwnerShipDateTime.SenderDomain

Overall, this smells, walks and talks all like an experimentation.  We 
should slow down on labeling everything that comes out of here as a 
"Proposed Standard" when there hasn't been any long term, multiple 
vendors R&D done.

I suggest, change this to a experimental status and let Yahoo and 
Facebook work out the details of this "experiment" as far as what this 
RRVS TIME field is and come back in a few year and let us know how it 
worked out.  I think once the RRVS field is defined, we might see a 
higher potential for adoption and rest assured, this is one idea that 
can apply across all market segments, not just the big guys.

-- 
HLS

---

From: Dave Crocker <[email-masked]>
Date: Thu, 26 Dec 2013 14:15:55 -0800

On 12/24/2013 10:31 PM, Murray S. Kucherawy wrote:
> impacts of forwarding.  I believe that the document already discusses
> those issues sufficiently, however.

This sort of discussion can confused about the precise actions and 
actors that are meant.  So, I'll highlight that the sequence being 
referred to above is relaying, not forwarding.

Per RFC 5598, forwarding is one of the things that can happen after 
delivery when (a version of) the original message is re-posted.

RRVS should work transparently for relaying -- assuming the SMTP 
enforcement mechanism is either not used or is successful -- but as 
noted, delivery should terminate it.  (As for whether s/mime or pgp sigs 
survive forwarding, well...)

And if I've gotten this bit of clarification wrong, well that nicely 
demonstrates that my concern about accuracy on the term is valid...

On 12/26/2013 8:59 AM, Hector Santos wrote:>
 > 1) The unclear, "non-standard" definition of what the RRVS "time" is,

I haven't seen discussion or agreement that it's using a non-standard 
definition, especially since it specifically cites RFC5322's definition 
of <date-time>.

What is the basis for the assertion of a non-standard definition?

 > 2) Its potential for inconsistent usage,

The arguments put forward here, concerning non-standard usage, apply to 
all protocols, and to none.  In effect, the logic being attempted, to 
disallow standardization, means that no new protocol ever qualifies for 
standards track.

Stated differently:  Every new protocol has a degree of risk that it 
will fail.  Yet we choose to place them on standards track.  So this 
criterion, as offered, clearly does not disqualify RRVS.

 > 3) The high risk of user data exposure here, a Pandora Box consideration,

The real irony to this claim is that the mechanism has been developed in 
order to /reduce/ mis-delivery and hence reduce the likelihood of 
inappropriate user data exposure.

 > 4) The risk of still sending and received unsecured messages,

I don't even know what this one means.

 > yet, that I am aware of, etc.

Ahh, so indeed we should not standardize anything until after it has 
achieved widespread use.  That might be a worthy topic of discussion, 
but it would constitute an IETF-wide policy change and hence is not 
reasonable for disallowing standardization of the current specification, 
given current IETF common policies.

 > This all sounds like an EXPERIMENT, not a standard track item.

Sorry, no it doesn't.

Experimental status is for the purpose of understanding a protocol that 
might not be well enough understood, yet, or with exploring its possible 
dangers.  Neither is at issue here.

Given the above, I can't tell what Eric's "Agreed" response means or 
why he issued it.

d/

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 27 Dec 2013 10:25:10 +1100

On 24 Dec 2013, at 5:29 am, Eric Burger <[email-masked]> wrote:

> While this mechanism is not as bad as the ill-fated recall message mechanism, it shares the same characteristic. Namely, this extension is at best a request.

…which makes me wonder why a header field name beginning in “Require-“ was chosen, instead of (for example) “Request-“.

Even with such a warning in the spec, people’s understanding of the header field is going to be (at a minimum) hugely influenced by its name, and the implication that it can “require” any kind of behaviour is not a good start.

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: Ned Freed <[email-masked]>
Date: Thu, 26 Dec 2013 15:10:57 -0800 (PST)

> demonstrates that my concern about accuracy on the term is valid...

This looks correct to me.

> What is the basis for the assertion of a non-standard definition?

I'm not entirely clear on what's being claimed here either, but I think it has
to do with semantics and not syntax. Specifically, I think the complaint is
basically that the document does not describe how to map from account
provisioning to the valid-since time value this extension requires in order to
function.

If I'm correct in this, then my position is that the document already provides
sufficient information about the semantics that are needed, and it is neither
appropriate nor, frankly, possible to get into how such information can or
will be generated from whatever account data is available in a given
environment.

For example, it's possible for user accounts to be keyed to a username rather
than an email address, for the account data to only contain the date when the
user name was assigned and not the date when the current email address was
attached to the account. In such cases it won't be possible to emit correct
valid-since information, because the account could be much older than the
current address assignment.

Or consider the case on the receiving end of a corporate role account like
[email-masked]. Of course such addresses should not be used when setting up
personal vendor accounts, but rest assured people are going to do it anyway.

When the assignment of such addresses change from one person to another, the
only sensible thing for the corp.com to do is not to update the associated
valid-since date (even if the actual underlying account does change) since
continuity of receiving corporate communications is far more important than the
privacy exposure of the previous holder of the address.

These variations and doubtless many others are going to crop up out in the
field, depending on how accounts are provisioned and managed.

However, it is neither our responsibility nor our area of expertise to plumb
the depths of the provisioning swamp. So once we've described the needed
semantics - which flow directly from the intended purpose of the extension in
any case - we're done.

> criterion, as offered, clearly does not disqualify RRVS.

Quite true and nicely stated.

> inappropriate user data exposure.

Exactly. And paying a price for this ability is inherent in the
store-and-forward nature of email: Valid-since information has to be attached
to the messages that are sent in some way, and once that information is there
is always the chance that it will leak. Using the extension rather than the
header mitigates this, but the clear consensus is to retain the header
mechanism.

> I don't even know what this one means.

Neither do I.

> given current IETF common policies.

In point of fact support for the header variant is already deployed by some
large MSPs. But as you say, this is for the most part irreelevant.

> dangers.  Neither is at issue here.

Agreed.

				Ned

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 26 Dec 2013 20:03:13 -0800

On Thu, Dec 26, 2013 at 8:59 AM, Hector Santos <[email-masked]> wrote:

>
> This all sounds like an EXPERIMENT, not a standard track item.  It could
> be an INFORMATIONAL document at this time and probably better to be
> describing a problem looking for a solution. I am not sure the RRVS is it.
>  This is currently an experimentation with a very high potential of being
> only used for exclusive relationships, i.e. a joint venture (Yahoo and
> Facebook) with a technology transfer of information to better synchronized
> heterogeneous user databases.   To do this in a standard way, the RRVS time
> has to be better defined. It is not.
>
> [...]
>

Dave and Ned have nicely handled this point-by-point already, but I'll
reply more generally by noting that the definition of Proposed Standard in
RFC2026 (specifically, Section 4.1.1) allows for something that is
relatively young but has significant interest and likely utility.  There's
a reason we call it "Proposed".  I also believe the amount of discussion
and contributions that support the work, and the fact that independent
implementations exist -- which, in fact, influenced the document's current
content -- indicate that it qualifies.

The remainder of this message repeated the previous claim that the
timestamp involved in the protocol is ill-defined, but I think Ned has
re-stated my previous (and unacknowledged) answer to that point, so I don't
have anything to add there.

-MSK

---

From: Ned Freed <[email-masked]>
Date: Fri, 27 Dec 2013 06:29:18 -0800 (PST)

> > best a request.

Not really. It's only a request in the sense that processing of all header
fields is contingent on the field being recognized and processed. A compliant
implementation will treat what the header says as a requirement that must be
met for the message to be delivered.

> …which makes me wonder why a header field name beginning in “Require-“ was
> chosen, instead of (for example) “Request-“.

Perhaps because it specifies a requirement?

This is not to say that I think the field is well-named. It isn't, and in fact
the entire thing should have been done as an SMTP extension only from the
start. But given existing deployment along with the clear consensus to keep the
header-based mechanism, changing the field name isn't a reasonable thing to do
at this point.

> Even with such a warning in the spec, people’s understanding of the header
> field is going to be (at a minimum) hugely influenced by its name, and the
> implication that it can “require” any kind of behaviour is not a good start.

That's true only if those people are unaware of the essential semantics behind
the use of header fields in email. And yes, that's a problem from time to
time, but one that's far beyond the purview of this specification to try
and solve.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Fri, 27 Dec 2013 08:49:49 -0800

> met for the message to be delivered.

While the above is of course correct, I think there can be two 
legitimate bases for distinguishing 'request' from 'requirement' within 
a protocol specification, and I think this is one of them:

The first basis is when the issuer is sending blind.

Most protocols contain an opening sequence which includes the semantic: 
both/all agents agree to participate in the sandbox covered by the 
protocol specification.  After that, it's reasonable to have one side 
impose a 'requirement' on the other, if that's what the protocol spec 
asserts.

However in some protocols, the issuer is sending things in the blind; it 
has no information that the receiver is playing in the sandbox of the 
protocol.  In such cases, the issuer can only send a 'request'.  In 
effect, what is sent combines two bits of semantics, the first is the 
opening "please play in this protocol sandbox" and the second is 'if you 
are playing in the sandbox, here's an action I want done."

For the current specification, the two bits are separated, when the SMTP 
extension is used.  The point behind having things implemented in the 
SMTP infrastructure is to first confirm that the recipient is playing in 
the sandbox and then enforce -- rather than request -- the semantics of 
addressee confirmation.  So when the SMTP extension is used, the issuer 
sends a 'requirement' rather than a 'request'.

When only the header field is used, it is only a 'request', because 
there is no step of first confirming that the receiver supports the 
protocol.

The second basis for making the distinction is within a protocol.

Here, the semantics of the protocol might be that the issuer really is 
only making a request, or really is issuing a requirement.  It depends 
entirely on what the specification asserts. What is important here, 
therefore, is that specification writers be very clear about the 
distinction, both in making the choice and in explaining it.

d/

---

From: Eric Burger <[email-masked]>
Date: Fri, 27 Dec 2013 12:10:31 -0500

This hits on the request vs. requirement.

I like Dave’s distinction: if I talk with you and you agree to supporting X, then I can reasonably ‘require’ you to do something in the scope of X.

If I just send you something without ‘knowing’ (via negotiation, contractual understanding, etc.) that you support X, then I can only reasonably ‘request’ you to do something in the scope of X.

Unfortunately for RRVS, as it is currently specified, it is a request, not a requirement. Even with the SMTP extension, unless the normative behavior is to fail if the next MTA or final MUA does not support RRVS, the present MTA cannot guarantee the delivery chain will support RRVS. Therefore, it is only a request.

As for the folks with this implemented, there is nothing to fear — how many MUA’a are more than two MTA’s away from the sending MUA? Especially since we are talking banks sending messages to gmail/hotmail/Yahoo!Mail/etc., I do not think anything would break to make the Require a real require. That is, fail if one or more MTA’s do not support the RRVS extension. This also has the nice side effect of making the header, corner cases which makes up almost a quarter the draft, by the way, obsolete.

If you are really worried about the bank’s Submit server talking to an MTA that does not support RRVS but the next MTA does support RRVS, then call it a Request and be done with it.

On Dec 27, 2013, at 11:49 AM, Dave Crocker <[email-masked]> wrote:

> While the above is of course correct, I think there can be two legitimate bases for distinguishing 'request' from 'requirement' within a protocol specification, and I think this is one of them:
> 
> Most protocols contain an opening sequence which includes the semantic: both/all agents agree to participate in the sandbox covered by the protocol specification.  After that, it's reasonable to have one side impose a 'requirement' on the other, if that's what the protocol spec asserts.
> 
> However in some protocols, the issuer is sending things in the blind; it has no information that the receiver is playing in the sandbox of the protocol.  In such cases, the issuer can only send a 'request'.  In effect, what is sent combines two bits of semantics, the first is the opening "please play in this protocol sandbox" and the second is 'if you are playing in the sandbox, here's an action I want done."
> 
> For the current specification, the two bits are separated, when the SMTP extension is used.  The point behind having things implemented in the SMTP infrastructure is to first confirm that the recipient is playing in the sandbox and then enforce -- rather than request -- the semantics of addressee confirmation.  So when the SMTP extension is used, the issuer sends a 'requirement' rather than a 'request'.
> 
> When only the header field is used, it is only a 'request', because there is no step of first confirming that the receiver supports the protocol.
> 
> Here, the semantics of the protocol might be that the issuer really is only making a request, or really is issuing a requirement.  It depends entirely on what the specification asserts. What is important here, therefore, is that specification writers be very clear about the distinction, both in making the choice and in explaining it.
> 
> 
> d/
> 
> -- 
> Dave Crocker
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Dave Crocker <[email-masked]>
Date: Fri, 27 Dec 2013 09:32:29 -0800

On 12/27/2013 9:10 AM, Eric Burger wrote:
> As for the folks with this implemented, there is nothing to fear — how many MUA’a are more than two MTA’s away from the sending MUA?

Probably quite a bit of b2b mail.

Any enterprise with department-level servers introduces larger numbers 
of MTAs.  Even without 'department' servers, large organizations often 
distinguish internal mail handling from external, so that mail starts 
with an internal-facing MTA and exits through an external-facing MTA.[*]

There is a continuing myth that all Internet mail is now 'direct', but 
while it's true for a large amount of mail, it's also not true for a 
large amount.

d/

[*] By way of example -- Although I did have to search through the 
archive a bit, I did finally find an example on the apps-discuss mailing 
list of author-side, multi-MTA handling before a message hit the open 
Internet.

---

From: Ned Freed <[email-masked]>
Date: Fri, 27 Dec 2013 10:42:56 -0800 (PST)

> This hits on the request vs. requirement.

Given the semantics you seem to be proposing, the latter is, with the exception
of encrpytion schemes, pretty much an empty set.

> I like Dave’s distinction: if I talk with you and you agree to supporting X,
> then I can reasonably ‘require’ you to do something in the scope of X.

No, not really, because interoperability trumps everything else in practice.
If I have to offer an extension in order to get you to send me a message
my users want to get, and I can't convince you to change your requirements,
then that's exactly what I'm going to do. Even if I don't intend to 
actually conform to the extension in practice.

Within the email world X.400 has proved to be the best example of this. Our
implementation was forced to offer support of several extensions that we didn't
actually support, because sending sites couldn't figure out how to turn them
off. In some cases nobody involved had any idea what the extension even was.
(Gotta love OID labels.)

And similar things have happened in the SMTP world. There used to be (and
probably still are) cases of the 8bitmime extension being offered with no
actual support for it.

Given this reality the distinction you and Dave are making becomes a lot less
meaningful than you seem to think.

> If I just send you something without ‘knowing’ (via negotiation, contractual
> understanding, etc.) that you support X, then I can only reasonably ‘request’
> you to do something in the scope of X.

> Unfortunately for RRVS, as it is currently specified, it is a request, not a
> requirement. Even with the SMTP extension, unless the normative behavior is to
> fail if the next MTA or final MUA does not support RRVS, the present MTA cannot
> guarantee the delivery chain will support RRVS. Therefore, it is only a
> request.

Not quite. The document makes this a SHOULD. By your way of thinking that's
more than a request, less than a requirement.

> As for the folks with this implemented, there is nothing to fear — how many
> MUA’a are more than two MTA’s away from the sending MU

I know from direct persanal experience that number is easily in the hundreds 
of millions. Mind you, the number isn't that much higher than two in most
cases, but it *is* higher than two.

What you should have asserted here is that the number of ADMDs involved between
submission and delivery is rarely more than two. And that is indeed an
important observation, and why the extension makes sense. But since the number
of MTAs involved is often larger it's also why it doesn't make sense to
require transfer of RRVS information. The legitimate exceptions to the SHOULD
I can think of all involve various permutations of inter-ADMD relay.

Now, I suppose the language could be change to make not dropping the RRVS 
information a MUST when transitioning out of the ADMD. But as I noted
previously, people are gonna do what they think is necessary, and so the
criteria for inclusiong of such language isn't "loopholes are bad so let's
close them all", but rather "this will actually aid implementators in knowing
what to do".

> A? Especially since we are talking banks sending messages to
> gmail/hotmail/Yahoo!Mail/etc., I do not think anything would break to make the
> Require a real require. That is, fail if one or more MTA’s do not support the
> RRVS extension. This also has the nice side effect of making the header, corner
> cases which makes up almost a quarter the draft, by the way, obsolete.

As it happens this is how I implemented RRVS, but even so, I disagree. I think
the SHOULD is appropriate here.

> If you are really worried about the bank’s Submit server talking to an MTA
> that does not support RRVS but the next MTA does support RRVS, then call it a
> Request and be done with it.

I really don't care about the labels, other than the header needs to remain
unchanged for backwards compatibility despite the poor choice of name.

				Ned

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sat, 28 Dec 2013 09:41:16 +0900

> list of author-side, multi-MTA handling before a message hit the open

Just look at mails from me. The way I counted, there were three or four 
MTAs on the way out (as well as on the way in, but you won't see that). 
I'm only tangentially involved in one of them, and not at all in the 
others, but that's how it works. One of these is the departmental MTA, 
the others are University-wide.

If I want to go out (or in) directly (sometimes needed for some special 
testing), I have to go through lots of hoops and make sure the IT 
department understands it's for research.

Regards,   Martin.

---

From: Hector Santos <[email-masked]>
Date: Sat, 28 Dec 2013 08:44:19 -0500

On 12/26/2013 5:15 PM, Dave Crocker wrote:

> Experimental status is for the purpose of understanding a protocol
> that might not be well enough understood, yet, or with exploring its
> possible dangers.  Neither is at issue here.

Dave,

This proposal is impossible to implement *without* a sound 
client/server time negotiation contract and definition.  As such, it 
contains many privacy and security exposure problems.  That certainly 
fits your definition for experimental status.

I will add it also increases new level of both client domain and 
server domains responsibilities and product liability issues that can 
not be ignored.  As Eric pointed out with SOX and HIPAA regulatory 
compliancy considerations, you also have PCI/DSS (Payment Card 
Industry/Data Security Systems) industry compliancy issues to contend 
with as well.

Without a client/server time definition, you are not sure what times 
are being issued by different RRVS clients and the clients themselves 
will not be sure what backend user times will they be compared with. 
  This is a higher risk and thus until it is well know what times are 
being used, I can not at this time endorse implementing it (for our 
package).

On the other hand, we perhaps know that times YAHOO or FACEBOOK are 
expecting so if this proposal is documenting the YAHOO/FACEBOOK 
behavior for time negotiations as a standard, this would be more 
acceptable and practical for implementation.

If not, there are more project R&D that need to be done.  For example, 
there might be a Sender Domain Time Definition Factor in the 
negotiating handshake for message acceptability.  If you say there is 
not, then this presumes a single design time definition by all clients.

Finally, with the advent of increased industry awareness to better 
"engineer" privacy and security considerations into our protocols, it 
is prudent that we have these discussions about having a solid 
understanding on how these protocols are expected to work.  Its about 
"Getting it right, the first time."  Increasing the engineering 
quality of the work.  Hopefully, to reduced all lost of 
project/product R&D investment being asked to be done.

IMO, with all the unknowns, especially with the inability to implement 
this without resolving these unknowns, eliminating or reduction 
potential security related concerns with these exposures, qualifies 
this proposal as an experimental status.   The IETF should consider it 
as an experiment when there are still many unknowns.

Thanks for your considerations.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Sat, 28 Dec 2013 09:27:24 -0500

On 12/27/2013 12:10 PM, Eric Burger wrote:
> I like Dave�s distinction: if I talk with you and you agree to supporting X, then I can reasonably �require� you to do something in the scope of X.
>
> If I just send you something without �knowing� (via negotiation, contractual understanding, etc.) that you support X, then I can only reasonably �request� you to do something in the scope of X.
>

+1.

> As for the folks with this implemented, there is nothing to fear � how many MUA�a are more than two MTA�s away from the sending MUA? Especially since we are talking banks sending messages to gmail/hotmail/Yahoo!Mail/etc., I do not think anything would break to make the Require a real require. That is, fail if one or more MTA�s do not support the RRVS extension. This also has the nice side effect of making the header, corner cases which makes up almost a quarter the draft, by the way, obsolete.
>

This is beginning to sound more like a VRFY-like proposal.  Perhaps, 
the reduction of the security concerns, the sending of sensitive 
content, can be done by delaying the transaction until a destination 
user can be verified using some other (enhanced) mechanism.

BTW, How does VRFY change with the possibility of RCPT command now 
having RRVS?

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 28 Dec 2013 09:36:21 -0800

On Sat, Dec 28, 2013 at 5:44 AM, Hector Santos <[email-masked]> wrote:

>
> Without a client/server time definition, you are not sure what times are
> being issued by different RRVS clients and the clients themselves will not
> be sure what backend user times will they be compared with.  This is a
> higher risk and thus until it is well know what times are being used, I can
> not at this time endorse implementing it (for our package).
>
> expecting so if this proposal is documenting the YAHOO/FACEBOOK behavior
> for time negotiations as a standard, this would be more acceptable and
> practical for implementation.
>

None of the enormous complexity being proposed here is necessary for this
protocol definition to be effective, nor is dragging a bunch of layer nine
stuff down to the level of an SMTP extension.  The question the extension
asks is a simple one.  As Ned has already pointed out, what data one needs
to retain in order to answer it is entirely a local matter on the part of
the receiving system, and is inappropriate to specify here.

If the receiver can't answer that question, for whatever reason, it simply
doesn't participate.

-MSK