Subject: Re: [apps-discuss] Not splitting RRVS

From: Hector Santos <[email-masked]>
Date: Tue, 01 Apr 2014 12:43:35 -0400

If I may add some points......

I don't think it it a good idea to inject a S/MIME complexity into 
this solution. I don't see how it can help the adoption of either. 
But the fact it is being considered supports my feeling this is still 
all an experimental concept.

IMO, Yahoo made an critical, strategic operational decision to begin 
to expire old accounts a lot quicker than perhaps in the past.  While 
it is an old issue for many hosting systems with their maintenance 
tools of user accounts, just because YAHOO is cracking open this door 
doesn't mean the potential millions of public and private hosting 
sites, especially private businesses are going to buy into the idea of 
its suddenly OK to begin reusing old email addresses. Just because 
YAHOO has decided to accelerate expirations and begin making email 
addresses a premium item to own, doesn't remove the idea its a very 
risky proposition for a much more wider set of operations. I believe 
there needs to be a more solid client/server protocol negotiated 
understanding of its main purposes and limits.  I believe it hasn't 
been all worked out and the development investment into this can be 
costly and foremost wasteful.  We are talking changes at all 
components of a complete mail system:

    Receiver
    Router
    Gateways
    Senders

The draft needs to be more clear on its purpose. It shouldn't be 
open-ended.  In the abstract it says:

    The intended use of these facilities is on automatically generated
    messages, such as account statements or password change instructions,
    that might contain sensitive information, though it may also be
    useful in other applications.

That last stated open ended potential purpose should be removed or the 
whole statement should be written to be more specific towards SMTP 
outcomes; positive/negative determination of an (RCPT) user account 
acceptability at a mail hosting domain.  The communication is done via 
SMTP reply codes.  This means that it can done at the SMTP  RCPT 
and/or DATA state machine points. IOW, it should not be delayed 
(accept and then processed afterwards, routed and/or bounced.

But whether its an SMTP command extension or payload header solution, 
delayed or otherwise at the backend, it MUST be a single consistent 
functional logic.  The header solution is a time shifted, time delayed 
method that could be complex in its queuing, meta data framework and 
exposed to additional pervasive monitoring/security related concerns. 
Nonetheless, there could not be any difference in overall logic 
otherwise we have a potential security loophole.

Related to the security, it makes me wonder how well its going to go 
at LC.  After all these security and privacy discussions, the recent 
related I-Ds and RFC work,  we are considering something that seems to 
thumb its nose at those concerns.

Thanks

--
HLS

On 3/31/2014 6:56 PM, Barry Leiba wrote:
>>> Could you do me a big favor and stop attempting to rephrase what I said?
>>> You're not very good at it.
> ...
>> Also, I didn't "rephrase" what you said.  I offered an assessment of it.
>> The difference is fundamental.
>
> I find this discussion between the two of you tr�s bizarre, because
> you're working against each other, when what John brought up seems to
> support what Dave wants.
>
> Here, let me try to bring it around to a resolution of a significant issue:
>
> What started this was a contention that the SMTP extension is "better"
> (latitude here, for the moment) than the header field.  No one really
> disputes that.  And then, that because it's better, the two should be
> defined separately, with the extension set up as Standards Track, and
> the header field not.  That's where the dispute is.
>
> One basis for the dispute is that the extension is not *sufficiently*
> better to make a real difference: neither is a guarantee, so does it
> really matter whether we have a very loose non-guarantee, or a
> somewhat, but not completely better non-guarantee?  Senders might be
> willing to get failures bounced, but are senders really willing to get
> non-support bounced?  If they try, it's likely that people will sign
> up with their banks and *never* get any transactional mail because
> they happen to be on a mail system that doesn't support the RRVS
> extension.
>
> So John points out something that's worth discussing in the document,
> and that might address Pete's concerns:  The guaranteed way to do this
> is with S/MIME mail encrypted to the recipient's key.  No intermediary
> support is needed for this -- it's only that the recipient's email
> system has to support S/MIME (not a huge problem today, though I'll
> note that Gmail doesn't), and that the recipient has to have certs set
> up (Oy!).
>
> I still think it's better to split out the header-field version and
> make it Informational.  But the argument above makes it less of an
> issue.  Perhaps the RRVS document should have a section that talks
> about the advantages of the extension over the header field, the
> realities of the header field over the extension, and the real
> security limitations of both.  Perhaps that section should say that if
> guarantees are needed, neither of these does it, and senders should
> consider S/MIME.  But if a "do your best" request suffices, these
> mechanism are useful.
>
> We could now ask what Pete would think about that.
>
> Barry
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>

-- 
HLS

---

From: Bill Mills <[email-masked]>
Date: Tue, 1 Apr 2014 11:07:47 -0700

Yahoo and others have been recycling accounts in volume for many many years, this isn't new.  

-bill

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

On Tuesday, April 1, 2014 9:44 AM, Hector Santos <[email-masked]> wrote:

    Receiver
    Router
    Gateways
    Senders

Thanks

--
HLS

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Tue, 01 Apr 2014 14:38:34 -0400

Yes, I understand that but so has everyone else since the annal of 
computerized mail/user hosting applications including network versions 
such as BBSes with UUCP/SLIP and then replaced with SMTP transports. 
Every commercial system, including ours, had tools or means to provide 
operators the ability to expire and/or delete user accounts since the 80s.

So why the RRVS now?  How does it resolve the old problem?

I would like to know what is different today than yesterdays that 
resolve the problem we had then and also remove, or perhaps just 
lowers the risk.  Obviously Yahoo made the decision that its OK to do 
this.  I should note, that I saw a developer's article/blog saying 
that it should only be applied to YAHOO accounts.  Why?  If there is a 
statistical spread of risk, we should see that information.

Look, I am not opposing it, I just don't think it has been completely 
worked out.   I would love to sell this to my customers:

     "Hey, look, you can now expire/delete accounts and ALMOST SAFELY 
secure
      clobbering of email accounts allow you to offer reusability of the
      accounts."

Maybe for YAHOO purposes it works ok because of sheer volume. I should 
note there is some commoditization going too with the reusability (a 
charge). Which is not an issue, but if thats the case, then the 
proposal should be very specific in its application need, not leave it 
open-ended as probable reason to appease the IETF community of its 
wider purpose and thus justification for standardization.

     Side issue: The IETF lacks a category for a new form of 
proposals, which
     I like to called Internet Methods or IM.

I would like to see interop and personal operational reports. Some 
statistics. I would like to time to test it to see how we need to fit 
it.  What has Yahoo learned for software design changes needed at the 
router, receiver, sender and also gateway side? etc.  These are 
rhetorical questions expressing my level of concerns and perhaps 
resistance to endorse, adopt and implement the proposed solution as it 
is written.

Thanks Bill

--
HLS

On 4/1/2014 2:07 PM, Bill Mills wrote:
>>[email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Tue, 01 Apr 2014 14:56:51 -0400

Bill, one way that an implementation can add this, is to do so only 
for ACCOUNTS that not has received any transaction attempts for X 
periods, for example 2 years.

Today, at our specific support site, over 60% of RCPT attempts are 
rejects for non-existing accounts, existing but expired accounts 
and/or valid accounts but does not have SMTP/POP3/IMAP (internet 
email) access. It is common for a security group profile to have 
online mail access only. Just not with IETF RFC-based store and 
forward methods.

Overall, the proposal is suggesting that it might be OK today to begin 
reassigning many of these currently rejected accounts.

I can see a lowered risk if there was a strong emphasis on the length 
of non-usage.

--
HLS

-- 
HLS

---

From: Bill Mills <[email-masked]>
Date: Tue, 1 Apr 2014 13:07:53 -0700

We're going over old ground here.  As has been discussed ad nauseum on the blogosphere (a word which still makes me think of something you cough up when you're sick) this is exactly what Yahoo does.

The impetus for RRVS was the FUD and commotion around a public announcement on account recycling for more desirable names.

Yes, it's an old old problem that no one had been forced to solve previously.  It's a problem that has changed in scope and user impact as accounts and identities become more linked and valuable.

-bill

On Tuesday, April 1, 2014 11:57 AM, Hector Santos <[email-masked]> wrote:

--
HLS

-- 
HLS

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 1 Apr 2014 22:13:37 +0200

These days an unspeakably large fraction of of all mail is to/from/cc/bcc 
gmail. (I bet this mail goes to at least one gmail address.) Hotmail didn't 
have that immense presence in 1994, so the need for RRVS has increased.

Arnt

---

From: Barry Leiba <[email-masked]>
Date: Tue, 1 Apr 2014 16:20:07 -0400

> The impetus for RRVS was the FUD and commotion around a public
> announcement on account recycling for more desirable names.
>
> Yes, it's an old old problem that no one had been forced to solve
> previously.  It's a problem that has changed in scope and user impact as
> accounts and identities become more linked and valuable.

Indeed, but here:
This is exactly why Pete and I are pushing on this.  Read what you say
above and think about where it might go in the future, as awareness of
risks and exposures becomes greater, and fear (whether it's real or
FUD) increases.

It's easy to say that all we need *today* is a best-effort solution,
something that's better than nothing.  What happens when the problem
continues to change in scope and user impact, and accounts and
identities become even more linked and more valuable?  When we need
something more robust than "please try, but it's not a big deal".

Wouldn't it be best to (1) document what's better than nothing, and
(2) prepare a more robust standard?

Barry

---

From: Bill Mills <[email-masked]>
Date: Tue, 1 Apr 2014 14:36:30 -0700

As I have said, my only objection to splitting the draft would be if the current RRVS header specification becomes other than standards track.

If this is split will both drafts be standards track?
 
-bill

 

Indeed, but here:

Barry

---

From: "John Levine" <[email-masked]>
Date: 1 Apr 2014 21:39:01 -0000

>(2) prepare a more robust standard?

Yes, although I don't see the SMTP extension as interestingly more
robust than the header.  Account reuse is only one of many reasons
that mail goes to someone other than the intended recipient.

I still think we should do one standards track document with both the
header and the SMTP extension, put in reasonable warnings about the
limitations of both, and worry about the hopeless swamp of reliably
identifying mail recipients later.

R's,
John

---

From: Barry Leiba <[email-masked]>
Date: Tue, 1 Apr 2014 17:43:21 -0400

Which is my proposal, if not my first preference, from my other message:

> Perhaps the RRVS document should have a section that talks

And so, putting Pete explicitly on the "to" line for this.  (Pete, if
you haven't already, you need to read at least the key messages in the
thread to fully follow this.)

Barry

---

From: Pete Resnick <[email-masked]>
Date: Tue, 1 Apr 2014 17:12:23 -0500

Thanks for the heads-up. I don't follow apps-discuss on a daily basis 
and I have not read *any* of the thread so far. I will catch up, and 
respond as needed.

pr

On 4/1/14 4:43 PM, Barry Leiba wrote:
> On Tue, Apr 1, 2014 at 5:39 PM, John Levine<[email-masked]>  wrote:
>    

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Hector Santos <[email-masked]>
Date: Tue, 01 Apr 2014 22:12:21 -0400

I can only hope you read other messages besides the so called "Key" ones.

-- 
HLS

---

From: Pete Resnick <[email-masked]>
Date: Wed, 2 Apr 2014 14:00:22 -0500

So, I've read through the entire thread. Barry's reflected most of what 
I would have said. To summarize:

- Yes, the document split and status change was just a suggestion of how 
to cleanly separate out the problems with the header, but there are 
plenty of other ways for the WG to choose to address my concerns.

- That something happens to be deployed is not a reason in and of itself 
to standardize it. Document it, sure, if that's helpful to the world, 
but deployed *and* interoperable *and* it fulfills design goals are what 
you'd want for standardization.

On that latter bit, as Barry said in response to Dave's comment:

> 1. If it must not be delivered unless there is confirmation that it is 
> the 'correct' user of the address, then of course, use the SMTP 
> extension and reject the message if the extension fails or is not 
> implemented along the path.

- If the current document actually specified rejection on failure, or 
gave a mechanism whereby the sender could request it, that would be 
peachy. It currently does not. It gives the receiving implementation the 
option to silently downgrade to the header and never again report 
whether the header was acted on or not. That seems problematic.

- The above points to a lack of specificity in the document about what 
problem either mechanism intends to address. It *seems* like the SMTP 
mechanism, if it actually had the constraint above, addresses the 
*sender* wanting to not deliver the message if the addressee has 
changed. But the header mechanism seems to be addressing the *receiving 
site* not wanting to deliver the message if it gets additional 
information that the addressee has changed. Those seem like two very 
different models.

If the document described:

1. the SMTP extension as a way to request that the message not get 
delivered if the addressee has changed and (optionally) bounce it if you 
can't tell, along with its security and privacy implications;

and then described:

2. the header mechanism as something to use (a) to tunnel when you have 
knowledge that an intermediary or the receiving MDA is going to do 
something with; it or (b) when you just want to use a best-effort 
mechanism to not deliver messages when someone along the line cares to 
check it, and described the security and privacy implications of that 
(which are very different)

that would be fine. But the current state of the document doesn't 
clearly state the very different uses and security/privacy 
considerations for the two mechanisms, and indeed seems to imply that 
the header mechanism is actually addressing the same issue that the SMTP 
mechanism is addressing, of the sender not wanting delivery if the 
address has changed. It does not interoperably do that.

pr

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 2 Apr 2014 16:48:21 -0700

On Wed, Apr 2, 2014 at 12:00 PM, Pete Resnick <[email-masked]>wrote:

> - If the current document actually specified rejection on failure, or gave
> a mechanism whereby the sender could request it, that would be peachy. It
> currently does not. It gives the receiving implementation the option to
> silently downgrade to the header and never again report whether the header
> was acted on or not. That seems problematic.
>

I suspect the prose that's there is predicated on various other
policy-style extensions we've seen over the years (SPF, DKIM, ADSP, on and
on) that are adamant about the fact that the sender cannot reasonably make
a demand upon the receiver in terms of specifying a handling action.
Perhaps this is one case where there really can't be a choice; if you're a
receiver and you're implementing this, you're explicitly buying in to the
notion that the sender knows what it's doing and it's willing to deal with
the consequences of rejection, so you reject.  If that's the case, I'm
certainly happy to be more specific on the text in terms of what a receiver
is supposed to do where the continuous ownership test fails.

> mechanism, if it actually had the constraint above, addresses the *sender*
> wanting to not deliver the message if the addressee has changed. But the
> header mechanism seems to be addressing the *receiving site* not wanting to
> deliver the message if it gets additional information that the addressee
> has changed. Those seem like two very different models.
>

No they definitely have the same intent, but simply have a different way to
go about it.  If there's ambiguity there, then that needs to be cleaned up.

> can't tell, along with its security and privacy implications;

Given the discussion, should we really have an ESMTP parameter that allows
the sender to assert that the message should {continue, bounce} when a
non-participating relay is encountered, perhaps defaulting to bounce, or
should the action be normatively fixed?

> something with; it or (b) when you just want to use a best-effort mechanism
> to not deliver messages when someone along the line cares to check it, and
> described the security and privacy implications of that (which are very
> different)
>

I'm fine with that.  I thought we were at least there with (a), and had
implied (b), but being more explicit is fine with me too.

> that would be fine. But the current state of the document doesn't clearly
> state the very different uses and security/privacy considerations for the
> two mechanisms, and indeed seems to imply that the header mechanism is
> actually addressing the same issue that the SMTP mechanism is addressing,
> of the sender not wanting delivery if the address has changed. It does not
> interoperably do that.
>

What of your MUST NOT point about multiple recipients?  It seems to me that
if, in the header case, you're OK with allowing best-effort, then SHOULD
NOT is adequate.

Did you have any other specific issues?

-MSK

---

From: "John Levine" <[email-masked]>
Date: 3 Apr 2014 02:23:26 -0000

>the consequences of rejection, so you reject.

Seems to me that it's in the tradition of SPF -all and ADSP
discardable and DMARC p=reject.  It's a little different in that it is
hard to think of a plausible scenario in which RRVS would say to
discard a good message, but I can still imagine a certain kind of mail
system would accept the message anyway and display it with a warning
"this message may not be for you."

As I've been saying, my main concern about RRVS is that it only
addresses one of a gazillion reasons that a message might be sent to
the wrong person and I wouldn't want people to think of it as more
than it is.  It's a useful hack primarily for a small set of large
public mail systems, so I think we should write it up along with its
limitations, e.g., if you care about data leakage from the header,
send separate copies of mail to separate recipients, and publish it as
standards track, since people are using it, and we can help them to
interoperate as best a limited hack like this can.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Thu, 03 Apr 2014 08:20:03 -0400

Pete,

This proposal is not just about rejection, but also about changing a 
Rejection into an Acceptance.

Today, most of these potential applicable accounts are REJECTS because 
they are expired or just no longer used for some reason or another. It 
is proposing a method that would claims to allow some form of 
reactivation protection.  It doesn't address the full repercussions 
that can come with reactivation.  The new "owner" is now open to 
getting slammed with spam and unwanted mail.  Many old accounts are so 
polluted with age, they get turned off or are highly filtered.   It 
could introduce a new concept or solution where a system will add an 
option that would reactivate an email address WITH a RRVS only 
requirement.

   [X] Only Accept Mail from RRVS attributes as part of the target 
address.

Or could also add logic such as:

   [X] Accounts MUST NOT get mail for 2 years before RRVS can apply.

This is all part of what I am saying that it is still all half-baked. 
It is still an experiment and that application is wide, wide enough 
that it wouldn't be covered by the few big sites, specifically the two 
promoters; YAHOO and FACEBOOK.  Their sheer public site size could 
mean it could apply to them with an acceptable risk, but this risk may 
not be acceptable across the board for most of the domain hosting 
applications.

In principle, we are trying to "kludge" in a way to get a new 
identifier for users where the reactivated accounts would have a new 
assigned "user-id" bit/component to it, otherwise its the OLD account 
by default.  In theory, although complex, it could allow for both old 
and new account users and persons to concurrently exist:

    [email-masked]           ---> mapped to old user: "Mary Jones"
    [email-masked] RRVS=xxx  ---> mapped to new new:  "Bill Smith"

All mail is accepted and moved to the specific user mail bins based on 
the RRVS identifier.

This is still all an experiment to me.

--
HLS

On 4/2/2014 3:00 PM, Pete Resnick wrote:
> So, I've read through the entire thread. Barry's reflected most of
> what I would have said. To summarize:
>
> - Yes, the document split and status change was just a suggestion of
> how to cleanly separate out the problems with the header, but there
> are plenty of other ways for the WG to choose to address my concerns.
>
> - That something happens to be deployed is not a reason in and of
> itself to standardize it. Document it, sure, if that's helpful to the
> world, but deployed *and* interoperable *and* it fulfills design goals
> are what you'd want for standardization.
>
>> 1. If it must not be delivered unless there is confirmation that it
>> is the 'correct' user of the address, then of course, use the SMTP
> peachy. It currently does not. It gives the receiving implementation
> the option to silently downgrade to the header and never again report
> changed. But the header mechanism seems to be addressing the
> *receiving site* not wanting to deliver the message if it gets
> additional information that the addressee has changed. Those seem like
> two very different models.
>
> delivered if the addressee has changed and (optionally) bounce it if
> you can't tell, along with its security and privacy implications;
>
> and then described:
>
> 2. the header mechanism as something to use (a) to tunnel when you
> have knowledge that an intermediary or the receiving MDA is going to
> do something with; it or (b) when you just want to use a best-effort
> the header mechanism is actually addressing the same issue that the
> SMTP mechanism is addressing, of the sender not wanting delivery if
> the address has changed. It does not interoperably do that.
>
> pr
>