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

From: Kurt Andersen <[email-masked]>
Date: Mon, 9 Dec 2013 03:17:55 +0000

On 2013-11-20 02:00 , "[email-masked]"
<[email-masked]> wrote:

>	Title           : The Require-Recipient-Valid-Since Header Field and
>SMTP Service Extension
>	Filename        : draft-ietf-appsawg-rrvs-header-field-04.txt
>	Date            : 2013-11-19

A few comments and questions, mostly detail clarification except for the
last one:

* Section 3.0 last para, sentence 1 says "under the continuous ownership.
. ." but I think that the key factor here is that the mailbox in question
has been associated with the expected entity.  Continuity is not
necessarily the necessary piece (for instance, if a user's subscription
lapses, but is subsequently renewed, rrvs should still pass).

* Section 7.1 para 2 - Recommending that MTAs change from headers to
extension may break signing if MTAs arbitrarily delete headers based on
next-hop capabilities.  I can see downgrading if needed.

* Section 9.1 How will an MTA know whether it is handing over to a
"mailing list"? Wouldn't this be better determined/handled by the mailing
list software itself?

* Section 10 seems to be three different points (paragraph 1/ everything
in the middle / the last paragraph)

* Section 14.2 para 3 - and the suggested handling would be? It is unclear
whether the suggestion is to ignore the rrvs header in this case or to
treat the result as unkown.

* Not addressed anywhere: What happens if a message is received with
conflicting information between the extension mechanism and the header
mechanism?  In this case, it seem like the header info should be ignored,
but suggesting deletion risks damaging DKIM signatures.

--Kurt Andersen

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 9 Dec 2013 11:28:46 -0800

> lapses, but is subsequently renewed, rrvs should still pass).

So you're looking at the case where a mailbox owner changes from A to B,
then back to A?

I'll add a paragraph at the top of Section 11 that accounts for this
possibility

> next-hop capabilities.  I can see downgrading if needed.

I'll add a remark to this effect.  However, we do need to encourage the
upgrade wherever possible.

> "mailing list"? Wouldn't this be better determined/handled by the mailing

We're not saying here that the MTA has to know anything.  The point being
made is that the MLM can't expect any RRVS information to be passed to it
by the MTA.

> in the middle / the last paragraph)

Right, it's a general discussion section.  All but the first paragraph
explain why the current syntax was chosen.

> treat the result as unkown.

Will say so.

> but suggesting deletion risks damaging DKIM signatures.

Will say something about that as well.

Thanks!

-MSK

---

From: Dave Cridland <[email-masked]>
Date: Mon, 9 Dec 2013 20:59:20 +0000

> I'll add a paragraph at the top of Section 11 that accounts for this

Ooooh, ouch, no, please. I think that opens too many weird edge cases.

I'd prefer s/continuous/exclusive/ - so it can go from A to nobody to A -
but the place to discuss this in detail is probably a new first paragraph
of §11, and simply insert a pointer to this detailed definition in §3 as a
new second sentence.

So in §3, a new sentence:

[confirmed its understanding of who owned
   that mailbox.] The precise definition of "continuous ownership" is
discussed in Section 11. [Two mechanisms are defined here: an]

And in §11, we add a paragraph as first:

<t>For the purposes of this specification, we define an address as having
been under continuous ownership since a given date if a message sent to the
address at any point since the given date would not go to anyone except the
owner at that given date. That is, while an address may have been
suspended, or otherwise disabled, for some period, any mail actually
delivered would have been delivered exclusively to the same owner.</t>

Dave.

---

From: Bill Mills <[email-masked]>
Date: Mon, 9 Dec 2013 13:08:37 -0800

I agree with Dave's point and like his proposed paragraph.

-bill

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

On Monday, December 9, 2013 12:59 PM, Dave Cridland <[email-masked]> wrote:

On Mon, Dec 9, 2013 at 7:28 PM, Murray S. Kucherawy <[email-masked]> wrote:

On Sun, Dec 8, 2013 at 7:17 PM, Kurt Andersen <[email-masked]> wrote:
>So you're looking at the case where a mailbox owner changes from A to B, then back to A?
>
>
>I'll add a paragraph at the top of Section 11 that accounts for this possibility
>

I'd prefer s/continuous/exclusive/ - so it can go from A to nobody to A - but the place to discuss this in detail is probably a new first paragraph of §11, and simply insert a pointer to this detailed definition in §3 as a new second sentence.

[confirmed its understanding of who owned
   that mailbox.] The precise definition of "continuous ownership" is discussed in Section 11. [Two mechanisms are defined here: an]

<t>For the purposes of this specification, we define an address as having been under continuous ownership since a given date if a message sent to the address at any point since the given date would not go to anyone except the owner at that given date. That is, while an address may have been suspended, or otherwise disabled, for some period, any mail actually delivered would have been delivered exclusively to the same owner.</t>

Dave.

_______________________________________________
apps-discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: "John Levine" <[email-masked]>
Date: 10 Dec 2013 04:54:14 -0000

>So you're looking at the case where a mailbox owner changes from A to B,

There's a whole range of possibilities that I don't think we want to
try to enumerate.  The key question is whether the party who receives
mail at that address now is the same as or an appropriate replacement
for the person who received it at the RRVS time.  When I say
appropriate replacement, I'm thinking of both stuff like role accounts
where noc@blah is whoever handles NOC tickets, or my someone's died
and a family member or executor deals with the mail.

>made is that the MLM can't expect any RRVS information to be passed to it

Surely it could get RRVS info for the list itself.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 9 Dec 2013 22:24:56 -0800

> Surely it could get RRVS info for the list itself.
What for?  I would think the MTA knows when the list was established, but
it goes no further than that.

-MSK

---

From: "John R Levine" <[email-masked]>
Date: 10 Dec 2013 01:36:33 -0500

> it goes no further than that.

You could imagine some Google Groups sort of setup recycling abandoned 
list names, but I agree it's not very plausible.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Ned Freed <[email-masked]>
Date: Mon, 09 Dec 2013 22:54:04 -0800 (PST)

> it goes no further than that.

It's not when the list was established, it's when a given address was added to
it.

				Ned

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 10 Dec 2013 00:28:11 -0800

> It's not when the list was established, it's when a given address was

Doesn't that mean mail addressed to a list has to consider the subscription
times of all of the subscribers?  That seems way beyond the reach of this
work, especially when the result will be Boolean for a list with an
arbitrary number of subscribers.

-MSK

---

From: Ned Freed <[email-masked]>
Date: Tue, 10 Dec 2013 07:58:49 -0800 (PST)

> times of all of the subscribers?

The answer is no, it doesn't.

> That seems way beyond the reach of this

On the contrary, it's a use-case that fits perfectly within the scope of this
work. A mailing list is just another means of sending mail to a bunch of
people whose addresses may no longer be valid.

But the key point here is we have to be careful not to comflate two separate
things: Sending mail to the list itself and the list sending mail to all of
its subscribers. Semantically this is a delivery-resubmit event, and RRVS
information doesn't make it across that any more than it makes it across
delivering a message to a user and the user subsequently forwarding or
resending the message.

I don't really see much point to having a valid-since date on the list itself,
but if you want to do that, you can. But once that check is made, the
valid-since information has been used up and is itself no longer valid.

Look at it this way: The minute an envelope recipient address is changed
downstream from whoever originally attached valid-since information to it, the
new address is coming from someone who has different information about the
validity of the addresses they are using. It's entirely possible for a message
to be sent to two recipient addresses, one of which is still valid and the
other not, and then for the one valid recipient to forward the message to the
other address, except this time the address is valid.

				Ned

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 10 Dec 2013 09:02:37 -0800

> other address, except this time the address is valid.

OK, I think the draft already says all of this.  I guess I misunderstood
your earlier message.  Let me know if you think there's other text that
needs to be added.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Tue, 10 Dec 2013 18:24:11 -0500

On 12/10/2013 12:02 PM, Murray S. Kucherawy wrote:
>
> Let me know if you think there's
> other text that needs to be added.
>

Why not tell us how Facebook and Yahoo is intending to use this as a 
joint venture?

You never addressed my questions I think,  what is this "RRVS" time?

It seems the basic, across the board change and proposal that you are 
asking systems to create is a new field in their user databases and to 
carry this new "field" as part of some new "good/bad" message 
acceptance/authorization concept.

We have CREATION, LAST_UPDATE, EXPIRATION dates in our databases, we 
even have birth dates, etc.

What is this "RRVS" data/time going to be compared to if its 
implemented with the single purpose to do rejection of what is 
otherwise a 250 (accept) operation?

All I can see here is a proposed need to create a new "Validity" 
date/time field in user records that can be shared, leverage in 
transactions.  This is important because not all backend systems is a 
SQL database system where a new database record field can be added 
without sweat.

But even then, one problem I see is who's validity would a receiver be 
comparing too?   How would a new "RRVS" field be initialized?  The 
first time? By whom? Sender A, B, or C?   This is why I asked about 
how Facebook & Yahoo are intending to use this.   What is their logic 
for others to follow or get a better grip to also emulate in their own 
hosting system?

I understand the problem YAHOO is seeing.  All public hosting systems 
A.K.A BBS software have had this problem since the days of allowing 
users to create their own accounts.  But it was less of an issue 
because the collisions were minimal, and if you did have a collision, 
you got a different address, period.    The old school MHS and naming 
formats are perhaps still common, using first name initial and full 
last names, or vice-versa, e.g.  [email-masked], [email-masked].

Basically, this is about REUSING addressing and doing so safely.  The 
collision rates are higher, i.e.  there are many "Hector Santos" out 
there, as opposes to the early days developing and using hosting 
sites.  I guess older, possibly expired, unused addresses can become a 
"premium" today. I can see the theory to help address part of this 
problem but only because all systems would need to have a common 
understanding on what "date/time' this is. The security can only exist 
when a consistent rejection taking place.  No rejection - no security.

Anyway, the problem I see with this draft/proposal is its attempt to 
be "open ended" when it really isn't an open-ended solution.

I believe it can help make it more general by having a specific 
outline or example design requirement needed by systems in order to 
make it work.    Do systems need to add a "Validity" field to their 
user database records?   Is this sufficient?

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 10 Dec 2013 16:19:11 -0800

On Tue, Dec 10, 2013 at 3:24 PM, Hector Santos <[email-masked]> wrote:

>
> Why not tell us how Facebook and Yahoo is intending to use this as a joint
> venture?
>

The header field version of this has been deployed as a prototype, and
we're getting some useful results out of it.  We're considering the switch
to the SMTP extension given the issues raised in this working group.

> You never addressed my questions I think,  what is this "RRVS" time?

I did:
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10847.html

> We have CREATION, LAST_UPDATE, EXPIRATION dates in our databases, we even
> have birth dates, etc.
>
> What is this "RRVS" data/time going to be compared to if its implemented
> with the single purpose to do rejection of what is otherwise a 250 (accept)
> operation?
>

That's entirely up to you.  The protocol only explains what the test is
supposed to accomplish, provides you with a date-time for comparison, and
explains how the sender probably got the value being presented.  How you
answer that question when it's posed to you is entirely a local matter,
because every receiver has a different data set about its mailboxes and
users.  It doesn't make sense to try to require receivers conform to a
specific schema or something like that.

>
> All I can see here is a proposed need to create a new "Validity" date/time
> field in user records that can be shared, leverage in transactions.  This
> is important because not all backend systems is a SQL database system where
> a new database record field can be added without sweat.
>

Right, if you want to participate in this extension (which is entirely
optional), you'd obviously have to keep that information about your mailbox
owners.

> comparing too?   How would a new "RRVS" field be initialized?  The first
> time? By whom? Sender A, B, or C?   This is why I asked about how Facebook
> & Yahoo are intending to use this.   What is their logic for others to
> follow or get a better grip to also emulate in their own hosting system?
>

The same logic we're using in production is spelled out in the document
already.  Essentially, when a user registers for an account at a particular
service, she also includes an email address that can be used for things
like password recovery.  There's a confirmation step there to confirm
ownership of the mailbox.  The timestamp when that confirmation completes
would be what's used as the RRVS parameter, because that's when the sender
was certain of who owned the mailbox.  (One might periodically re-confirm,
and update the timestamp.)  The receiver would likewise record a timestamp
of when that mailbox was created.  If the mailbox is ever reassigned, that
receiver timestamp would be updated.  Then, if the creation date of the
mailbox is newer than the RRVS parameter, then the sender no longer has a
correct notion of who owns the mailbox, and the message shouldn't be
delivered.

>
> Anyway, the problem I see with this draft/proposal is its attempt to be
> "open ended" when it really isn't an open-ended solution.
>

It's not open-ended, but at the same time we do lay out only the minimum
requirements for what data each end has to keep in order for the protocol
to be useful.  We can't be more specific than that because, as I said
above, every environment is different.  We can only say in the abstract
what you need to do to participate.

-MSK

---

From: Ned Freed <[email-masked]>
Date: Wed, 11 Dec 2013 10:38:45 -0800 (PST)

> your earlier message.  Let me know if you think there's other text that

I haven't had a chance to review the current draft in detail, but I think the
language in the draft about this is fine.

				Ned