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

From: [email-masked]
Date: Thu, 14 Nov 2013 00:03:34 -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 Header Field and SMTP Service Extension
	Author(s)       : William J. Mills
                          Murray S. Kucherawy
	Filename        : draft-ietf-appsawg-rrvs-header-field-03.txt
	Pages           : 14
	Date            : 2013-11-14

Abstract:
   This document defines an extension for the Simple Mail Transfer
   Protocol called RRVS, and a header field called 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 these facilities 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-03

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

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: Thu, 14 Nov 2013 00:06:37 -0800

>    be useful in other applications.

Reverts removal of the header field definition, adds a second enhanced
status code to indicate domain ownership changes, makes use of enhanced
status codes a SHOULD, and differentiates between relays and re-senders in
terms of whether the ESMTP material should be relayed when a message passed
to a downstream MTA.

Please (Bill, John and Ned especially) let me know if I've missed anything
here.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Thu, 14 Nov 2013 08:40:44 -0500

> Please (Bill, John and Ned especially) let me know if I've missed anything

I'm not Bill, John nor Ned, but I hope you can shine some light here.

Suppose I create an account at winserver.com to sign up at facebook.com.

What RRVS value is going to be passed to winserver.com and what do I 
compare it with?

Is Winserver.com expected to save this value for the user?

It sounds to me that we will need to save RRVS values PER client 
domain because each can have its own understanding of the RRVS value 
or not at all. Is this correct?

I still don't have the complete "Ah Ha" on how this is going to work 
to safely deal with expired accounts which I expect this proposal is 
expecting the accounts will never be deleted but perhaps marked 
inactive in order to be able to have a history of RRVS values.

Overall:

   Deleted Accounts yield 550
   Demoted Accounts yield 550
   Active Accounts with non-RRVS yield 250
   Active Accounts with pass RRVS yield 250
   Active Accounts with failed RRVS yield 550

Before I am even try to implement this, I'm trying to see what RRVS 
value is compared too in order to change an active account 250 to 550.

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 14 Nov 2013 06:47:48 -0800

> What RRVS value is going to be passed to winserver.com and what do I

You would in theory go through a "confirm you own this email address" step,
and Facebook (or whoever) would save the timestamp when you did so.  After
that, email to your winserver.com address would include RRVS=that-timestamp
on RCPT TO lines, and your MTA would determine whether that email address
has changed owners since that-timestamp before deciding to accept or reject.

> Is Winserver.com expected to save this value for the user?

If it advertises the RRVS extension or understands the header field, it is
expected to save the local account's creation date for comparison to
incoming timestamps from clients that also use this extension or header
field.  Otherwise, obviously, it can't participate.

>
> It sounds to me that we will need to save RRVS values PER client domain
> because each can have its own understanding of the RRVS value or not at
> all. Is this correct?
>

If you're participating in this, you need to save account creation dates
for all mailboxes for which you do local delivery, or otherwise derive them.

>
> I still don't have the complete "Ah Ha" on how this is going to work to
> safely deal with expired accounts which I expect this proposal is expecting
> the accounts will never be deleted but perhaps marked inactive in order to
> be able to have a history of RRVS values.
>

If the account is deleted, I presume you return 550.  If you then reassign
that account to someone else, you would remember the timestamp when you did
so, and then start rejecting messages that fail the RRVS check on a
reassigned mailbox, and deliver the rest.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 14 Nov 2013 17:54:17 -0000

>Please (Bill, John and Ned especially) let me know if I've missed anything

Near the bottom of page 5, in 4.1.1 it says RRVS RRVS.

When you fix that, you might say something like:

  If the relaying system knows the time when the alias was established,
  it MAY add an RRVS parameter for the new target address that includes
  that time.

(Based on recent mail, Ned was confused by this, and if it confuses
him, it could confuse anyone.)

On page 7, near the top, the paragraph about multiple recipients seems
wrong.  It says "and if any one of them fails the test, the delivery
fails to all of them".  The options are to interpret the header at the
end of data and reject, which will fail for all the recipients, or to
accept at the end of data, deliver to some and send DSNs for the
others.

Last pp of section 8 at the top of page 9, there are lots of reasons
for the recipient not to be on the To: line beyond morally
questionable address munging.  Obvious examples are mailing lists
where the To: is the list address, and ordinary correspondence where
the recipient is on the Cc: or Bcc: lines.  Just note that SMTP has
never required that envelope and header addresses correspond, so the
RRVS header contains the envelope address to which the timestamp
applies.

I'd still like the A-R phrase to log the RRVS envelope info.  If I
implement it, that's what I'll use.