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

From: [email-masked]
Date: Mon, 21 Oct 2013 15:27:17 -0700

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-01.txt
	Pages           : 14
	Date            : 2013-10-21

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-01

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

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: Mon, 21 Oct 2013 15:29:38 -0700

>    be useful in other applications.
This takes into account feedback we've received to date.  Most notably, it
adds an SMTP extension, as a couple of people have suggested.  It looks
like we'll need to have some discussion about whether this is feasible,
practical, procedurally correct, etc., so please have at it!

-MSK (co-author)

---

From: Stephan Bosch <[email-masked]>
Date: Tue, 22 Oct 2013 02:25:35 +0200

On 10/22/2013 12:29 AM, Murray S. Kucherawy wrote:
> This takes into account feedback we've received to date.  Most
> notably, it adds an SMTP extension, as a couple of people have
> suggested.  It looks like we'll need to have some discussion about
> whether this is feasible, practical, procedurally correct, etc., so
> please have at it!

I gave this a quick read and I have one comment:

Section 3.1 describes the SMTP extension. The value it takes is
described as follows:

   The new parameter is "RRVS", which takes a value
   that is an integer timestamp expressed as an "epoch" time, namely the
   number of seconds since midnight on January 1, 1970.

For consistency with e.g. RFC 4865 ("SMTP Future Message Release"), I'd suggest using the ISO 8601-based format described in RFC 3339 ("Date and Time on the Internet: Timestamps") instead.

Regards,

Stephan.

---

From: "John Levine" <[email-masked]>
Date: 22 Oct 2013 18:23:37 -0000

>practical, procedurally correct, etc., so please have at it!

Hmmn.

Section 6 asserts that:

   "the additional detail about the relationship	
    between the message author and its intended recipient is at best a	
    property of the message transaction and not part of the message	
    itself. 

That seems wrong.  RRVS says this message is for the person who had
the target address at time T, which sure seems like a property of the
message.  If it were a property of the transaction, that suggests you
might have one transaction that delivers a message with RRVS, and
another which delivers the same message to the same recipient without
it, which is silly.

Sec 6 suggests deleting RRVS headers when a subsequent relay supports
the SMTP extension, which will break signatures.  You could suggest
not signing RRVS headers, I suppose, but I'm not sure if that has
security implications.

I'm aware of two problems the SMTP extension might solve, neither of
which is important.  One is to allow reject before data, which seems
to me like a horse that left the barn long before DMARC burned the
barn down.  The other is that it allows selective rejection on
messages with multiple recipients, but the kind of mail this is likely
to be used on rarely has multiple recipients.  But the stuff about
adding and deleting headers based on the next hop's EHLO responses
strikes me as the kind of stuff that won't ever be implemented, or if
it is, it'll be wrong, e.g., it'll add headers but won't delete them.

So my preference is still to take it out.

R's,
John

---

From: Ned Freed <[email-masked]>
Date: Fri, 25 Oct 2013 16:03:55 -0700 (PDT)

> not signing RRVS headers, I suppose, but I'm not sure if that has

You actually want to delete the headers you recognize regardless, in order
to limit information exposures.

> barn down.

That's entirely wrong. It's a huge benefit to be able to reject this stuff
early; see below.

> The other is that it allows selective rejection on
> to be used on rarely has multiple recipients.

No, the advantage is that you can handle multiple recipients trivially instead
of with considerable difficulty. I don't care how "likely" such usage is; an
implementor that cares about producing a high quality product has to deal with
it. And people take stuff we define and use it in unexpected ways all the time,
to the point where the surprise is when this doesn't happen.

>  But the stuff about

> So my preference is still to take it out.

I just finished implementing this draft, and based on that experience I have to
strongly disagree. I now believe that if anything the header mechanism is what
needs to go.

The SMTP extension turns out to be very easy to implement. The RRVS value
is directly attached to the address, so there only two cases:

(1) The address is local, in which case you check the information against
    the account if you have it. And throw the information away no matter
    what.

(2) The address is nonlocal, in which case you attach the information to
    the address so it can be relayed.

This only took me a couple of hours to code.

I actually implemented the SMTP extension before the new draft came out, and
what I did matched the draft with the exception that I used same format for the
time value as was specified in RFC 4865. Note that  Stephan Bosch reached the
same conclusion about the right format to use independently. (Obviously I
concur with Stephan that the draft needs to be changed.)

A nice thing about the SMTP extension is most of the security issues just take
care of themselves. The information is never part of the message so you don't
have to worry about it leaking. The only remaining issue is the ability to use
the extension to determine the age of the account, which is made a little
easier. But the mitigation given in the draft addresses most of this,
and applies to both approaches.

I also find the argument about deployability problems to be a bit overblown, at
least as far as the primary use-case is concerned. As I understand it, the
primary use-case is for banks, e-sellers, and similar sorts sending status
messages to MSPs and ISPs. In such cases what intermediaries are there likely
to be? (I'll also note that you can't on the one hand argue that only one
use-case really matters while on the other hand using the problems associated
with other use-cases to dismiss the simpler approach.)

Anyway, once I had the extension I started in on the header stuff. I expected
this to be harder due to the need to handle the header-envelope matcheup as
well as the possibility of partial failures, but I was gobsmacked at the 
difficultly. This has taken me literally days to get right.

The multiple recipient issue is a big part of it, but not all. Just as
one example of how tricky the multiple recipient issue is, suppose you
have two recipients A and B that forward to the same address C:

  A -> C
  B -> C

So what recreation date do you attach to that one address? If either one
doesn't have a recreation date the answe is "you don't attach one". But they
both do the correct thing is to attach and check both. That means making some
data structure changes, which to be honest I didn't bother to do. I think this
is enough of a corner case that I can ignore it. But I could be wrong, in which
case this will be even more work.

But this is nasty even if there's only a single recipient and header. The basic
problem is you've introduced a new failure case after the content of the
message has been received, and it turns out to have somewhat different
semantics from other failure cases at this point, in my implementation at
least.

It's not like throwing out the message because, say, it was a big pile of
binary nonsense. Or because it violated overall site policy in some way. In
such cases there's justification for returning an error and dropping the trash
in the trashcan. But RRVS differs in that it's almost certainly a bad idea to
ignore legal intercept or other archiving requirements for what is, after all a
valid message. (And before you say otherwise, think what happens when Silk Road
supports this on the sending side.)

This led me to conclude that RRVS is much more like a sieve ereject - which
already had support in place for multiple recipients - and that's more or less
how I ended up implementing it. But the interactions with actual sieves are
different, the handling in the event of sieve errors are different, and ereject
doesn't allow specification of a specific enhanced status code so support for
that had to be added.

The bottom line is this ended up being a fair bit of work. I think I finally
have it right, but the final call for tht will be for the Q/A folks to make,
who I'm sure will just love it to pieces. Or perhaps not.

				Ned

---

From: John R Levine <[email-masked]>
Date: Fri, 25 Oct 2013 21:13:04 -0400 (EDT)

> As I understand it, the primary use-case is for banks, e-sellers, and 
> similar sorts sending status messages to MSPs and ISPs. In such cases 
> what intermediaries are there likely to be?

I'm thinking of spam filtering proxies, either services like Messagelabs, 
or a linux box put in front of an organization's Exchange server.  My 
impression is that they often do some sort of LDAP call to find out what 
addresses are valid.  I don't know enough about LDAP to know how hard it 
would be to check the age of the address at the same time.

R's,
John

---

From: Ned Freed <[email-masked]>
Date: Fri, 25 Oct 2013 20:00:20 -0700 (PDT)

> would be to check the age of the address at the same time.

These "solutions" tend to work spectacularly badly for all sorts of reasons. In
regards to using LDAP, the real problem is getting them to do the lookup
competently. Getting at an additional attribute is very small beer compared
to other issues.

It would actually be far better to define a non-LDAP way to retrieve both this
and other important information (e.g., spam filter settings), but unfortunately
nobody seems inclined to work on it.

				Ned

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 26 Oct 2013 13:54:35 +0200

>     the address so it can be relayed.

I agree the extension looks easier than the header field.  However,
the concept of "local" is not thoroughly clear.  An MTA can have both
some sort of alias database and dot-forward recipes.  The latter can
be scripts or other artifacts dealt with by the local MDA only.  So a
message can be relayed even if it looked local when it was accepted.

I rise this in order to check how this extension would work for email
address portability.  I client can learn a forwarding address from a
251/551 reply, or sending a test message with NOTIFY=SUCCESS and
waiting for the DSN, or some other to-be-devised mechanism.  I'd call
_email address portability_ the possibility that an MTA reliably
stores and uses addresses learned that way.  In such scenario, RRVS
would add the ability to tell it "go back and relearn, because
something changed."  Does that make sense?

Ale

---

From: Ned Freed <[email-masked]>
Date: Sun, 27 Oct 2013 19:27:46 -0700 (PDT)

> message can be relayed even if it looked local when it was accepted.

But in both of the cases you cite, you have effectively validated the incoming
address in terms of RRVS, breaking the RRVS chain. The entire point of having
aliases and dot-forward files is to have a stable address that can be
redirected in various ways.

Of course nothing says that the forwarding address can't start a new RRVS
chain by recording when forwarding to that particular was first set up. The
only problem with that is going to be error reporting: Who do you report
the problem to so whoever owns the forwarding address can update it?

In any case, unless there's some sort of special relationship between the
forwarder and where it forwards to, the RRVS information should not carry
through an alias, redirection, whatever. And if such a relationship exists,
then I don't see much point in regarding this as anything other than a local
matter.

> something changed."  Does that make sense?

First of all, I don't see this RRVS into forwarding entry as having anything to
do with email address portability. Use of RRVS to insure the forwarder itself
doesn't end up forwarding to the wrong might make sense, but that doesn't
really impact the portability issue per se.

Second, the 251/551 mechanism is *very* different than a success DSN. Anyone
who updates addresses on their list in any way other than deleting it on the
basis of a DSN response is way out in the weeds - there is no DSN-based
mechanism defined for updating addresses. The x.1.6 status code for "mailbox
has moved" explicitly says "no forwarding address". 

As for 251/551, I'm afraid I regard the whole approach as obsolete. The main
problem is security: As noted in section 7.2 of RFC 5321, a MITM attack on such
mechanisms can be used to redirect not only the current but all future
messages. Absent far more ubiquitous use of security on relay connections, this
whole approach is just too risky.

All that said, if someone was, let's call it "bold" enough to enable use of
251/551, and there was a server that actually sent such replies often enough to
matter, then I fail to see much semantic difference between this and having a
user update their email address on some account using a web form or whatever.
Updating the address associated with an account obviously has to wipe out any
RRVS information on file and so should a 251/551 update.

The only wrinkle I see is that the old address does need to be notified of the
change, and that notification has to operate using the old RRVS info.

				Ned

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 28 Oct 2013 11:11:21 +0100

On Mon 28/Oct/2013 03:27:46 +0100 Ned Freed wrote:
>>>
>>> The SMTP extension turns out to be very easy to implement. The RRVS
>>>  value is directly attached to the address, so there only two cases:
>>>
>>> (1) The address is local, in which case you check the information
>>>     against the account if you have it. And throw the information
>>>     away no matter what.
>>>
>>> (2) The address is nonlocal, in which case you attach the
>>>     information to the address so it can be relayed.
> 
>> I agree the extension looks easier than the header field.
>> However, the concept of "local" is not thoroughly clear.  An MTA
>> can have both some sort of alias database and dot-forward
>> recipes.  The latter can be scripts or other artifacts dealt with
>> by the local MDA only.  So a message can be relayed even if it
>> looked local when it was accepted.
> 
> But in both of the cases you cite, you have effectively validated
> the incoming address in terms of RRVS, breaking the RRVS chain. The
> entire point of having aliases and dot-forward files is to have a
> stable address that can be redirected in various ways.
> 
> Of course nothing says that the forwarding address can't start a
> new RRVS chain by recording when forwarding to that particular was
> first set up. The only problem with that is going to be error
> reporting: Who do you report the problem to so whoever owns the
> forwarding address can update it?

Hm, I thought the whole purpose of saving the RRVS to the header was
to reinstate using it as a client in case it forwarded.  You consider
it a MAY(?), while I thought it was meant to be a SHOULD.  Perhaps,
the draft needs to clarify this point.

For simple forwarding, rejection would trigger an NDN as usual.  No?

> In any case, unless there's some sort of special relationship
> between the forwarder and where it forwards to, the RRVS
> information should not carry through an alias, redirection,
> whatever.

You mean "SHOULD NOT"?

> First of all, I don't see this RRVS into forwarding entry as having
> anything to do with email address portability. Use of RRVS to
> insure the forwarder itself doesn't end up forwarding to the wrong
> might make sense, but that doesn't really impact the portability
> issue per se.

Yes, of course.  The idea is just to check the robustness of the
specification by considering how it can be (mis)understood when viewed
from a different angle.

> Second, the 251/551 mechanism is *very* different than a success
> DSN. Anyone who updates addresses on their list in any way other
> than deleting it on the basis of a DSN response is way out in the
> weeds - there is no DSN-based mechanism defined for updating
> addresses. The x.1.6 status code for "mailbox has moved" explicitly
> says "no forwarding address".

AFAIK, sending servers maintain no lists of "ported addresses", so
there is no mechanism to update them.  (The traffic increase due to
dot-forward recipes seems to be negligible compared to spam, and
forwarding can be used to add spam filters.)  But a protocol-fiction
story could consider shortcuts as a means to skip possible spy-points,
besides using domain-level encryption, say.

> As for 251/551, I'm afraid I regard the whole approach as obsolete.
> The main problem is security: As noted in section 7.2 of RFC 5321,
> a MITM attack on such mechanisms can be used to redirect not only
> the current but all future messages. Absent far more ubiquitous use
> of security on relay connections, this whole approach is just too
> risky.

I assume you mean Section 7.4, "Mail Rerouting Based on the 251 and
551 Response Codes".  I never saw code to act on it automatically.

> All that said, if someone was, let's call it "bold" enough to
> enable use of 251/551, and there was a server that actually sent
> such replies often enough to matter, then I fail to see much
> semantic difference between this and having a user update their
> email address on some account using a web form or whatever. 
> Updating the address associated with an account obviously has to
> wipe out any RRVS information on file and so should a 251/551
> update.
> 
> The only wrinkle I see is that the old address does need to be
> notified of the change, and that notification has to operate using
> the old RRVS info.

Consider a sending server which stored the forwarding A->B after a 251
reply.  When it sends directly to B it uses RRVS with the date on
which it learned A->B.  If the recipient subsequently changes A->B
into A->C, he or she should also set B->C or B->A.  In that case, the
receiving server will have a dot-forward file with an st_mtime more
recent than the RRVS date used by the sending server.  That does not
necessarily imply a change of ownership, but it might.

How about modifying the spec so as to have the receiving server reply
something different in the "unknown" cases?  For example:

   251 Something changed; will possibly forward to <unknown>

Ale

---

From: Ned Freed <[email-masked]>
Date: Mon, 28 Oct 2013 07:28:49 -0700 (PDT)

> to reinstate using it as a client in case it forwarded.

Absolutely not! This is not now and never has been a mechanism intended
for clients to be involved in. If the mechanism hasn't done it's job
before the message is in the user's hands, it has failed.

>  You consider

I think you're seeing things that aren't there. I can't find a single
reference in the draft anywhere to the recieving client being involved
in any RRVS handling. You'd think that there would be some mention of
it if the header was intended for that purpose.

> For simple forwarding, rejection would trigger an NDN as usual.  No?

I assume you're talking about the case where the forwarder itself
is using RRVS and the check fails. If so, then yes, a DSN will be
sent, but the question is to where and to what purpose. If the
forwarder didn't alter the envelope from then the DSN will go back to
original sender, and if that sender happens to be one that knows how
to deal with RRVS mail sending will be suspended or whatever. Which is
a reasonable outcome, except that when the user notices the problem and
goes to fix it it may be difficult for them to figure out what's wrong.

But suppose the forwarder overrode the envelope from. This will likely
have the effect of dropping the message on the floor. Not the greatest
outcome, but there's really no other realistic alternative.

> You mean "SHOULD NOT"?

It's already a SHOULD in the draft for every case that is described. Right
now there is insufficient discussion of the RRVS extension, including
discussing whether or not to carry the parameter through.

>    251 Something changed; will possibly forward to <unknown>

I seriously doubt this is worth worrying about.

				Ned

---

From: Bill Mills <[email-masked]>
Date: Mon, 28 Oct 2013 09:21:04 -0700

Am I right that the SMTP extension is a one-time thing, and no state is carried through with the message itself?

How does this ensure that the RRVS check passes all the way through to the authoritative MX?  If you're passing through a chain of MX boxes then the whole chain has to support the extension?

-bill

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

---

From: "John Levine" <[email-masked]>
Date: 28 Oct 2013 16:35:46 -0000

>to reinstate using it as a client in case it forwarded.

I think we may be confusing relays and forwards here.

First case: I send a mail to [email-masked].  The MX for example.com
is just a gateway, and it relays the mail to another locally
determined host, still addressed to [email-masked].

Second case: I send a mail to [email-masked].  The MX for example.com
decides to forward it to [email-masked], so it sends it using the
address [email-masked], to the MX for example.net.

In the first relay case, it makes sense to preserve the RRVS info.  In
the second forward case it does not.  An extra complication that Ned
mentioned is that in the second case, the forwarder might want to add
new RRVS info noting the time that the forward to bar was set up.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 28 Oct 2013 16:38:35 -0000

>Am I right that the SMTP extension is a one-time thing, and no state
>is carried through with the message itself?

Maybe.  If the message is delivered through gateways that don't
rewrite the address, it's possible that the host that knows the
creation date of the address will be a few hops down.

A plausible scenario would be a spam filtering proxy like the ones
provided by Symantec and Tucows.

---

From: Ned Freed <[email-masked]>
Date: Mon, 28 Oct 2013 10:59:06 -0700 (PDT)

> carried through with the message itself?

No, that's incorrect, and it's something the draft needs to cover. An MTA
operating as a front-end proxy without full knowledge of account ownership
should pass the information along.

I implemented this as a matter of course and accounted for it in my previous
notes about implementation difficulty.

> How does this ensure that the RRVS check passes all the way through to the
> authoritative MX?  If you're passing through a chain of MX boxes then the whole
> chain has to support the extension?

I'll again note that the issues faced by forwards operating outside the
administative domain are formidable. RRVS is at best a tiny part of this.

But absent any interest in working on a solution, I see no reason for RRVS to
wade into this morass. It should simply note this as an issue and move on.

				Ned

P.S. Anyone who thinks there aren't problems in this area really should try
operating a secondary MX for someone. Doesn't need to be a big site, doesn't
need to handle a lot of traffic, doesn't have to involve RRVS, it's still a
PITA.

---

From: Ned Freed <[email-masked]>
Date: Mon, 28 Oct 2013 11:08:13 -0700 (PDT)

> new RRVS info noting the time that the forward to bar was set up.

Nice summary!

				Ned

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 29 Oct 2013 09:27:36 -0700

> wade into this morass. It should simply note this as an issue and move on.

That's an option, of course, but isn't tunneling the sender's request via a
header field something potentially workable?  I think what I mean by that
is: Should this draft just take out the header field and be hand-wavey on
that topic, as opposed to what's there now?

-MSK

---

From: Ned Freed <[email-masked]>
Date: Tue, 29 Oct 2013 09:33:52 -0700 (PDT)

> that topic, as opposed to what's there now?

That's an entirely different topic - my point was that whether or not you
"solve" the RRVS problem in the case of secondary MXes isn't going to have any
real impact on the MX problem space.

I have to say I'm not wild about the notion of downgrading the RRVS extension
to the header mechanism on the fly, because it grots up code that otherwise is
able to do things like BDAT in a single, simple operation. But it is
implementable.

				Ned

---

From: "John Levine" <[email-masked]>
Date: 29 Oct 2013 19:02:35 -0000

>able to do things like BDAT in a single, simple operation. But it is

I don't think anyone is, but considering the number of relay servers
that exist, we need to say something.

I'm pretty much with Murray, note it and don't try to solve the
problem.  

If a relay is able to remember the RRVS envelope info, it can pass it
along in the next SMTP session.  Or it could stick it in the message
as an RRVS header, although since RRVS isn't a trace header that runs the
risk of breaking signatures and other confusion.

R's,
John