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

From: [email-masked]
Date: Wed, 06 Nov 2013 13:39:38 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Applications Area Working Group Working Group of the IETF.

	Title           : The "Require Recipient Valid Since" SMTP Service Extension
	Author(s)       : William J. Mills
                          Murray S. Kucherawy
	Filename        : draft-ietf-appsawg-rrvs-header-field-02.txt
	Pages           : 9
	Date            : 2013-11-06

Abstract:
   This document defines an extension for the Simple Mail Transfer
   Protocol, called RRVS (for "Require Recipient Valid Since"), to
   provide a method for senders to indicate to receivers the time when
   the sender last confirmed the ownership of the target mailbox.  This
   can be used to detect changes of mailbox ownership, and thus prevent
   mail from being delivered to the wrong party.

   The intended use of this facility is on automatically generated
   messages that might contain sensitive information, though it may also
   be useful in other applications.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-rrvs-header-field

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-appsawg-rrvs-header-field-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-rrvs-header-field-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

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

>    be useful in other applications.

This version removes the header field altogether, leaving the SMTP
extension only.  The timestamp syntax has been changed to RFC3339 format,
and there's been some minor wordsmithing.

Ned's made an implementation based on this, and I'll be taking a run at it
after I get home from this trip, though I'll also need to convince a
receiver to play along.  :-)

Other than waiting for implementation results, are there any other changes
we need to make or at least consider?

-MSK

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 06 Nov 2013 19:23:36 -0800

> 	Filename        : draft-ietf-appsawg-rrvs-header-field-02.txt
Some quick comments on the latest version:

4.2.  SMTP Extension Not Offered

    For a message being sent that includes content meant to be protected
    by this extension, the client MUST NOT continue to deliver a message
    to a server

That might be nitpicking, but if a message has multiple recipients on 
the same server, some with the RRVS parameter and some without, I think 
you only want non deliver for recipients with the RRVS parameter 
present. The above doesn't say that.

    where the server does not advertise the RRVS SMTP
    extension.

What is the error code to return?

6.  Use with Mailing Lists

    Mailing list services can store the timestamp at which a subscriber
    was added to a mailing list.  This specification can be used in
    conjunction with that information in order to restrict traffic to the
    original subscriber, rather than a different person now in possession
    of an address under which the original subscriber registered. Upon
    receiving a rejection caused by this specification, the list service
    can remove that address from further distribution.

I am a bit confused about this section. You are not talking about using 
RRVS parameter on a mailing list address, right?

Which also reminds me: should the document talk about mailing list 
expansions, i.e. whether the RRVS parameter should be copied for each 
recipient on expansion.

11.2.  Enhanced Status Code Registration

    IANA is requested to register the following in the SMTP Enhanced
    Status Codes registry:

       Code:               X.7.15
       Sample Text:        Mailbox owner has changed
       Associated basic status code:  5
       Description:        This status code is returned when a message is
                           received with a Require-Recipient-Valid-Since

This is still referencing the header field that you removed in -02.

                           field and the receiving system is able to
                           determine that the intended recipient mailbox
                           has not been under continuous ownership since
                           the specified date.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 06 Nov 2013 19:31:47 -0800

10.1. Probing Attacks

    [...]
    Given that MSPs have chosen to allow transfers of mailbox ownership
    without the prior owner's involvement, the information leakage from
    the header field specified here creates far fewer risks than the

Again, this is talking about the removed header field.

    potential for delivering mail to the wrong party.

---

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

On Wed, Nov 6, 2013 at 7:23 PM, Alexey Melnikov
<[email-masked]>wrote:

> That might be nitpicking, but if a message has multiple recipients on the
> same server, some with the RRVS parameter and some without, I think you
> only want non deliver for recipients with the RRVS parameter present. The
> above doesn't say that.
>
> What is the error code to return?

We're going back a version, so this will disappear.

> RRVS parameter on a mailing list address, right?

Either.

> This is still referencing the header field that you removed in -02.

We're adding it back.

-MSK

---

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

> We're going back a version, so this will disappear.

The text may have disappeared, but the issue of how to handle forwarding
a message using the extension to a system that doesn't support it still exists.

There are basically three options:

(1) Do what the SMTP-extension-only draft said, and assign an error code
    for that case.

(2) Silently drop the RRVS parameter.

(3) Downgrade the RRVS parameter into a Require-Recipient-Valid-Since header
    field.

I'm currently doing (2), but Chris has convinced me that this is a security
issue and (1) is the right choice for a relay client, so I'm going to switch.
(I believe this is only the second time we've ever specified an SMTP extension
that calls for bouncing certain messages if the extension isn't there. The
first was EAI.)

A submission client is another matter. This client actually "owns" the data
being exposed, as such, it is in a position to elect to use (3) if it wants to.

				Ned