Subject: [apps-discuss] Splitting RRVS

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 27 Mar 2014 14:42:39 -0700

Colleagues,

The IESG Evaluation of draft-ietf-appsawg-rrvs-header-field has resulted in
the draft being sent back to the working group for reworking.  In the same
manner as the MT-PRIORITY work, they would like us to split the document
into a standards track document that defines the SMTP extension independent
of the header field, and a document not on the standards track that defines
the header field as it relates to the extension.

Fortunately, most of the text that goes into both of the documents already
exists in the one we have now.  Some of the points raised during evaluation
that will need to be considered in the split are:

1) More attention should be paid to the issue of invalidating content
signatures when the header field gets removed.

2) The potential for revealing information unnecessarily to end users when
the message is relayed to non-participating MTAs needs to be underscored.

3) There should be a mechanism for the sender to request that the message
be bounced when a relay that doesn't support the SMTP extension is
encountered, rather than encouraging the tunneling option.

4) There should be stronger discouragement, possibly even a MUST NOT, for
the multiple recipients case.

5) When using the header field version, there's no guarantee at all that
downstream agents actually understand and will respect the semantics.  In
that scenario the sender is essentially tossing the message over the wall
and hoping for the best.  Even if the first hop supports the SMTP
extension, there's no guarantee that a downstream MTA won't downgrade and
be sloppy about it.

To minimize the impact of this, I plan to try to produce the two documents
this weekend and get them available to the WG for review.  Assuming we can
come to consensus quickly (the text changes shouldn't be too huge), we
should be able to send this back to the IESG in just one or two telechat
cycles.

There's a separate issue in general about better guidance around when to
use SMTP extensions vs. header fields.  I tried to address that in
draft-kucherawy-email-caps, which also needs some work after some review
comments I've received.  I'll try to do all three this weekend.

Barry and Pete, please add or correct anything above as necessary.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Thu, 27 Mar 2014 15:31:30 -0700

On 3/27/2014 2:42 PM, Murray S. Kucherawy wrote:
> and a document not on the standards track that defines the header field
> as it relates to the extension.

Why should the header field not be on standards track?

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 27 Mar 2014 15:35:56 -0700

> Why should the header field not be on standards track?

The IESG's answer to that can probably be found in the comments from the
IESG ballots:

https://datatracker.ietf.org/doc/draft-ietf-appsawg-rrvs-header-field/ballot/

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Fri, 28 Mar 2014 09:04:52 -0700

> https://datatracker.ietf.org/doc/draft-ietf-appsawg-rrvs-header-field/ballot/

Yeah.  I keep forgetting that we now have access to such things...

I don't recall the rationale for the outcome of SMTP Priority, but the 
logic in Pete's note appears to be quite broken.

Pete's argument is:

http://datatracker.ietf.org/doc/draft-ietf-appsawg-rrvs-header-field/ballot/#pete-resnick 

> It seems to me that the header field is a complete hack, and has
> potential for screwing up content signatures when stripped,
> potentially unnecessarily revealing information to the end user,  and
> standardizing it encourages trying to tunnel the message instead of
> bouncing it when the SMTP extension fails.

      1.  Stripping is an issue for most header fields.  And yes, it 
certainly will break a DKIM signature... IF the signature covers such 
fields and the field is stripped.  The issue is general.  Applied 
consistently, therefore, Pete's concern means that we can never make any 
new header field a standard.  Alternatively, Pete fails to consider 
(recommending) simply not having the signature cover the (potentially) 
problematic field, or, at least, documenting the danger.

      2.  The concern for hiding information from the recipient does not 
distinguish between the intended recipient, versus an unintended 
recipient who now has the mailbox address.  This probably makes a 
difference, but I won't pursue it here.  In any event, the premise of 
the stated concern is that having the information only in the envelope 
somehow hides it from the recipient.  Given that envelope information is 
regularly transferred into header fields at delivery time, this 
assumption is not valid.  A separate question to ask is whether 
revealing the information matters. It might also be worth noting that 
most MUAs do not show more than a few, common header fields.

      3. Lastly, the argument that standardization "encourages" use of 
the header field misses the point behind documenting it in the first 
place:  to get consistent behavior.  Pete's argument is that of a purist 
rather than a pragmatist.  Worse, it ignores the nature and purpose of 
standardization, and replaces these with an aesthetic preference.  Is 
the header field a protocol element? (yes)  Is it expected to be useful? 
(presumably yes) Is there a better way to achieve its function? 
(presumably no)  Does it need to be used consistently? (yes)  These are 
the normal kinds of criteria used to determine whether something is 
worthy of standardization, rather than "it's a hack".

The email operations world would certainly be a better place if 
SMTP-level adoption of options were more progressive.  So the desire to 
rely on the SMTP option, here, makes sense.  This is a delivery-related 
mechanism; so it's optimal to place it in the handling/delivery 
sub-system.  But it's not practical, given long and UNreliable adoption 
of SMTP options.

Of course, it's easy to just give the IESG whatever it wants, just to 
move the spec along.  The IETF has a long history of doing that.

It also has a long history of problems with that pacification model.

d/

---

From: t.petch <[email-masked]>
Date: Fri, 28 Mar 2014 16:34:04 +0000

It would be good to see minutes from IETF89 before April 4th.

Tom Petch

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 28 Mar 2014 10:16:46 -0700

On Fri, Mar 28, 2014 at 9:04 AM, Dave Crocker <[email-masked]> wrote:

> The email operations world would certainly be a better place if SMTP-level
> adoption of options were more progressive.  So the desire to rely on the
> SMTP option, here, makes sense.  This is a delivery-related mechanism; so
> it's optimal to place it in the handling/delivery sub-system.  But it's not
> practical, given long and UNreliable adoption of SMTP options.
>

I think this is the crux of my concern with this result.  The email
operations world has, as a result of a couple of decades of abuse, evolved
high agility in terms of header field manipulation because all of the
attacks have been focused on abuse of the content.  However, there have
been few (if any) attacks involving transport.  That has left them with
relatively zero agility in terms of adding SMTP extensions; they need to
wait for vendors to provide full software releases to get a new SMTP
extension, and that means it can take months or longer for very serious
things like this to get handled.

The disparity between operational reality and architectural purity leaves
these decisions with a distinct Ivory Tower feeling.  We appear to be
telling email operators, the folks in the trenches, that they've been doing
it wrong all these years, they can't have what they want, they need go back
and do it right.  Until (or, perhaps, if) that happens, they're stuck with
solutions at which we turn up our noses.  There doesn't seem to be any
convergence either.

I think that chasm is a large and growing problem, and we need to think
about how to improve it.  I started draft-kucherawy-email-caps to at least
describe the problem and hopefully encourage some progress, but I don't
think it's going to be enough.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 28 Mar 2014 10:17:50 -0700

They'll be posted this weekend.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 28 Mar 2014 10:56:41 -0700

On 3/28/2014 10:16 AM, Murray S. Kucherawy wrote:
> On Fri, Mar 28, 2014 at 9:04 AM, Dave Crocker <[email-masked]
> <mailto:[email-masked]>> wrote:
>    ...
 >    But it's not practical, given long
>     and UNreliable adoption of SMTP options.
>
>
> I think this is the crux of my concern with this result.
...
> about how to improve it.  I started draft-kucherawy-email-caps to at
> least describe the problem and hopefully encourage some progress, but I
> don't think it's going to be enough.

OK.  With the above as worthy validation of my concern, I'll suggest the 
following path for this draft:

      1.  Keep the document in its current form; do not split the header 
field spec out.

      2.  Add a "Design Considerations" section that discusses any 
distinctive or potentially controversial choices made in formulating 
this mechanism.  At a minimum, list and respond to Pete's concerns. 
While I don't think those concerns justify non-standards status, they 
certainly are real issues warranting commentary.

To pursue this path -- pushing back on the IESG -- we will need broader 
community support.

d/

ps. I think your point about the differential histories as a basis for 
explaining differential agility is quite interesting.  But I'd add the 
inherent and long-noted point that SMTP changes require adoption by a 
multi-hop, multi-administration infrastructure, whereas header fields 
only require adoption by author and receiver/recipient.  Even an 'agile' 
infrastructure is far less easy to change than a pair of end-systems.

---

From: "John Levine" <[email-masked]>
Date: 28 Mar 2014 21:14:16 -0000

>To pursue this path -- pushing back on the IESG -- we will need broader 

That seems reasonable to me.  Keeping in mind that the original
impetus for RRVS was Yahoo's header, it seems odd not to make the
existing practice standards track.  After all, even if it's not an
ideal implementation, we're better off having people interperate as
well as they can.

R's,
John

---

From: Dave Cridland <[email-masked]>
Date: Fri, 28 Mar 2014 21:50:17 +0000

On 28 March 2014 17:56, Dave Crocker <[email-masked]> wrote:

> distinctive or potentially controversial choices made in formulating this
> mechanism.  At a minimum, list and respond to Pete's concerns. While I
> don't think those concerns justify non-standards status, they certainly are
> real issues warranting commentary.
>
I think this is a good path to follow. I agree that the header-based
solution has problems, which is why I argued it should be a fallback, but I
think it's a valid fallback which needs the weight of standards-track.

> multi-hop, multi-administration infrastructure, whereas header fields only
> require adoption by author and receiver/recipient.  Even an 'agile'
That's an excellent principle. We could call it "end to end" or something.

Dave.

---

From: "J. Trent Adams" <[email-masked]>
Date: Fri, 28 Mar 2014 16:22:59 -0600

I support maintaining a single document and adding the necessary
clarifications.  Splitting the document, IMO, will be confusing and
result in fragmented deployments.

- Trent

On 3/28/14 3:50 PM, Dave Cridland wrote:
> On 28 March 2014 17:56, Dave Crocker <[email-masked]
>         On Fri, Mar 28, 2014 at 9:04 AM, Dave Crocker
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>            ...
>
>     OK.  With the above as worthy validation of my concern, I'll
>     suggest the following path for this draft:
>
>          1.  Keep the document in its current form; do not split the
>     header field spec out.
>
>     distinctive or potentially controversial choices made in
>     formulating this mechanism.  At a minimum, list and respond to
>     Pete's concerns. While I don't think those concerns justify
>     non-standards status, they certainly are real issues warranting
>     commentary.
>
>     To pursue this path -- pushing back on the IESG -- we will need
>     broader community support.
>
>
> solution has problems, which is why I argued it should be a fallback,
> but I think it's a valid fallback which needs the weight of
> standards-track.
>  
>
>
>     d/
>
>     ps. I think your point about the differential histories as a basis
>     for explaining differential agility is quite interesting.  But I'd
>     add the inherent and long-noted point that SMTP changes require
>     adoption by a multi-hop, multi-administration infrastructure,
>     whereas header fields only require adoption by author and
>     receiver/recipient.  Even an 'agile' infrastructure is far less
>     easy to change than a pair of end-systems.
>
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

-- 
J. Trent Adams

Profile: http://www.mediaslate.org/jtrentadams/
LinkedIN: http://www.linkedin.com/in/jtrentadams
Twitter: http://twitter.com/jtrentadams

---

From: Hector Santos <[email-masked]>
Date: Sat, 29 Mar 2014 13:55:37 -0400

On 3/28/2014 1:16 PM, Murray S. Kucherawy wrote:
>     SMTP-level adoption of options were more progressive. �So the
>     desire to rely on the SMTP option, here, makes sense. �This is a
>     delivery-related mechanism; so it's optimal to place it in the
>     handling/delivery sub-system. �But it's not practical, given long
> I think this is the crux of my concern with this result.� The email
> operations world has, as a result of a couple of decades of abuse,
> evolved high agility in terms of header field manipulation because all
> of the attacks have been focused on abuse of the content.� However,
> there have been few (if any) attacks involving transport.�

Accept/Bounce Mail Attacks, SORBIG?   That is what made the emergency 
MARID to happen.

> That has
> left them with relatively zero agility in terms of adding SMTP
> extensions; they need to wait for vendors to provide full software
> releases to get a new SMTP extension, and that means it can take
> months or longer for very serious things like this to get handled.

I see your point, but SMTP software has evolved.  Not sure from your 
perspective and/or package you are use to using, but the concept of 
adding what we called HOOKS, SHIMS, CALLBACKS, etc, at the SMTP State 
Machine points has evolved.   The point it well taken that it could be:

     native op-code compiled
     p-code compiled, or
     interpretive

and the more you have with intepretive scripting, the more "Agile' you 
are, where its more and APPLICATION LEVEL solution now as opposed to 
SYSTEM LEVEL.  With P-code and interpretive language systems, you need 
a RTE (run time engine).

The packages do support this higher level of programmability. I know 
ours does.  What I don't think I have ever seen though (I don't recall 
it), nor the need to add the logic for passing RCPT TO modifiers to 
programmable scripts   For MAIL FROM, there exist a quite a few 
extension, i.e. SIZE, SUBMITTER.   SIZE was built in. I believe with 
SUBMITTER, we finally made it flexible so that the entire MAIL FROM 
was passed to scripts.

So I get this point of why the header method adds "agility."  However, 
that also comes with a design presumption that the all SMTP packages 
have evolved to doing DATA level payload scripting.  Keep in mind that 
there has been old and new (relatively) expressed processing delay 
concerns with the increased amount payload related scripting. For us, 
the delays have reached a point where the RTE needed to have a GLOBAL 
DEFAULT TIMER to avoid unexpected DATA processing delays by the 
open-ended scripts written by operators and 3rd party developers.

> The disparity between operational reality and architectural purity
> leaves these decisions with a distinct Ivory Tower feeling.� We appear
> to be telling email operators, the folks in the trenches, that they've
> been doing it wrong all these years, they can't have what they want,
> they need go back and do it right.� Until (or, perhaps, if) that
> happens, they're stuck with solutions at which we turn up our noses.�
> There doesn't seem to be any convergence either.

I'm not sure what that all means, but it sounds like you are 
suggesting that most SMTP package are not flexible enough.  I guess we 
all get a different perspective based on what SMTP packages one is 
using.

I would agree that we did add more power to DATA processing but that 
was because of the need to give operators more PAYLOAD processing 
power.  It doesn't scale when your operators begin to add multiple 
scripts as they come along to do the different things.  We have, for 
example, the default stock scripts at the DATA level:

     RFC 5322 Validity/Sanity Check (Remember double From potential 
exploit?)
     DKIM verification
     Greylist checking
     White Listing
     Carbon Copies
     Forwarding

And we got at least dozen new scripts being explored in R&D,  So I 
understand the agility idea, but then again these were PAYLOAD level 
needs.

RRVS is not a PAYLOAD solution. Thats the "Kludge" that pete talks 
about. You call it a "Tunnel."

In that regard, I agree with the separation, but I also do believe 
this all is an experiment.  We have not been able to explore or test 
this idea with anyone. There is no interop report and there are still 
too much CON vs PRO on this.  Unless we can explore this, we support 
the idea --  not the rush to standardize it yet.

> I think that chasm is a large and growing problem, and we need to
> think about how to improve it.� I started draft-kucherawy-email-caps
> to at least describe the problem and hopefully encourage some
> progress, but I don't think it's going to be enough.

Switch your software! :)   Of course, we can't publicly preach that... 
right?

Can we do a generic solution?

If anything, we need to update RFC5321 to perhaps add a section that 
deals with SHIMS, HOOKS, CALLOUT flexibility and designs and adds SMTP 
process model flexibility in passing variable state machine parameters.

Short of telling people to switch to your "Favorite" smtp package, 
that is the best we can do.  But do keep in mind, the packages have 
evolved and this should not be a reason to always push for a PAYLOAD 
solution.  If it belongs at SMTP, then thats were it belongs. What you 
can do is add a 2nd WRAPPER solution.  I think this what Pete is 
suggesting.

I suppose reducing the complexity would have with the SMTP extension 
standard. So I can support this split, but overall, I still strongly 
believe we are still at the experimental stage.  I don't think we 
worked out all the details and thats probably because it looks to me, 
we only got two domains attempting to work this out with others being 
able to test it with them.

-- 
HLS

---

From: Barry Leiba <[email-masked]>
Date: Sat, 29 Mar 2014 14:40:31 -0400

To make some clarification here:

Splitting the document was a suggestion for how to deal with this.  I
support that suggestion.  But no one made it a requirement, and one
answer the working group can give about that is "No, we do not think
that's the right way to proceed."

Similarly, making the header-field portion Experimental also wasn't a
requirement.  That came from pointing out that the mt-priority
document was made Experimental.  One thing that would help greatly
here would be feedback from Alexey (or others) about how that
experiment has worked out.

That said, this protocol has much greater issues with the header field
than mt-priority does.

Mt-priority is a best-effort attempt to get priority handling for
certain messages, under certain conditions.  If that handling is given
when it shouldn't be, there's a certain level of "damage", but it's
not likely severe.  Similarly if it's not given when it should be.
But there's no data leakage, no privacy issues, nothing of that sort.

Given the use cases this document puts forward, I don't see how a
header field is workable at all.  The sender isn't *really* saying, do
your best, but I don't much care whether you get it right.  Modulo the
understanding that one can never be *certain*, what the sender is
saying here is that it would be bad for this to be delivered to the
wrong recipient, to the point that I'd rather have it bounce than for
that to happen.

That sort of request can only be handled by an SMTP change, where
support by the next hop is discoverable, and where the message can be
bounced if there's no support.  Once you stick it into a header field,
it becomes a total crap-shoot.  The sender has *no* idea whether any
party along the line is listening to the request at all.

Despite the ease of deployment using header fields, for the use cases
we're talking about here the header field just seems to be a bad
implementation.

I would say that that's the primary issue you need to address if you
really want to keep the header field (and I honestly don't understand
why you do).

> mechanism.  At a minimum, list and respond to Pete's concerns. While I don't
> think those concerns justify non-standards status, they certainly are real
> issues warranting commentary.
>

Yes to (2) and the unnumbered (3), clearly.

Barry

---

From: "John Levine" <[email-masked]>
Date: 29 Mar 2014 22:26:54 -0000

>header field [isn't] workable at all.  The sender isn't *really* saying, do
>your best, but I don't much care whether you get it right.

We've been sending mail without RRVS for 30 years, so it can't be all
that urgent.

Just like everything else a sennder says, RRVS is somewhere between a
request and a suggestion to the recipient.  So now after 30 years of
mail landing in reassigned mailboxes, we have a tiny twiddle that
allows senders to send a suggestion about what to do with it.

While I entirely understand all the ways that the RRVS header might
fail, in practice it's most likely to be useful in mail to large
webmail systems, most mail to those systems takes a pretty simple
path, and in most cases it'll do what it's supposed to do.  It is also
my impression that Yahoo has actually implemented the header, while
nobody other than maybe Ned has implemented the SMTP extension.

So put in all the warnings about how the header could screw up, and
perhaps a suggestion not to include it in DKIM signatures, but this
is existing practice.  We'll look silly if we make the experiment
standards track and the running code experimental.

R's,
John

---

From: Barry Leiba <[email-masked]>
Date: Sat, 29 Mar 2014 18:40:51 -0400

> We've been sending mail without RRVS for 30 years, so it can't be all

Then why bother with it at all?
If you're going to have it at all, it ought to be done in a way that
has some reasonable assurance that it will be paid attention to.

> nobody other than maybe Ned has implemented the SMTP extension.

Maybe -- just maybe -- standardizing the extension and not the header
will be a push to change that.

> is existing practice.

If that's the consensus, then so be it.  I think it'd be sad to limit
it to that... but, yes, as John says, better than nothing.

Barry

---

From: "John R Levine" <[email-masked]>
Date: 29 Mar 2014 18:51:17 -0400

> Then why bother with it at all?

It's an incremental security improvement.  I'd think you could have made
the same argument against DKIM, SPF, and S/MIME.

> will be a push to change that.

I'm not planning to implement it, but I've never reused a mail address.

It seems to me that the most signficant places where mailboxes are reused 
are large public mail systems, so how about asking if any of them have any 
plans to do an SMTP extension.

R's,
John

---

From: Barry Leiba <[email-masked]>
Date: Sat, 29 Mar 2014 19:00:24 -0400

> plans to do an SMTP extension.

Is that the right question?  Or is the better question "How many WOULD
implement it if it were standardized?"

b

---

From: "John R Levine" <[email-masked]>
Date: 29 Mar 2014 19:08:18 -0400

> implement it if it were standardized?"

Given that we know people at all of the relevant organizations, I don't 
think the two questions are likely to have very different answers.

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

---

From: "John Levine" <[email-masked]>
Date: 29 Mar 2014 23:15:59 -0000

>think the two questions are likely to have very different answers.

That wasn't very clear.  Might as well ask both questions.  My point
is that if none of the large webmail systems are going to implement
it, there's negligible point in going ahead.  Yahoo says they already
do the RRVS header on some of their mail.

R's,
John

---

From: Kurt Andersen <[email-masked]>
Date: Sat, 29 Mar 2014 16:23:13 -0700

> do the RRVS header on some of their mail.

We employ the RRVS header on security-related emails from our platform. I
think that the better point is not that "Yahoo [does] RRVS", but that they
support it as a receiver. I've not seen any indication that they employ it
when sending (though they may).

--Kurt

---

From: Dave Crocker <[email-masked]>
Date: Sat, 29 Mar 2014 16:37:38 -0700

> has some reasonable assurance that it will be paid attention to.

Barry, your line of argumentation is tailored to a perfect world.

In that perfect world, everything having to do with 'handling' is 
restricted to the transport envelope and anything made standard is 
readily implemented.

In the imperfect world of the deployed Internet, we often have to settle 
for architectural compromises.

The semantics I assign to the distinction created by the two component 
mechanisms in the current draft is:

      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.

      2. If it is preferable that the mail be delivered to the correct 
user, but not essential, then let the header field provide advisory 
information.

These choices are embodied in the draft's Section 7.1 text, '"B" elects 
not to reject the message'.

> will be a push to change that.

This is essentially coercive thinking.  It presumes that the IETF 
somehow can dictate operational paradigm changes in the market, when the 
market has long-standing demonstration of resistance.

That is, it reverses the well-demonstrated model, which repeatedly shows 
that IETF work is successful when it matches what the market wants. 
Instead, the thinking you are offering presumes that the IETF can tell 
the market what it wants.  Since the market has made clear that it has 
high resistance to infrastructure change, playing games with standards 
status mostly will serve to marginalize the IETF.

The current topic is a particularly weak agent of such coercion.  It's 
not as if masses of email operators are demanding the facility.  That 
does not mean there is no interest in it, but it does mean there is a 
serious limit to the costs that can be imposed for adopting it.

Worse, the thinking you offer ignores the lack of incentives for 
intermediaries that have no concern for whether the address belongs to 
the 'correct' user.

But there's a deeper problem in this Discuss:

      It seems to represent a misunderstanding of the purpose of 
standardization, namely declaring something to be a common mechanism to use.

There is a long history of trying to worry about "communicating" the 
"wrong" thing and it mostly winds up blocking progress and/or looking silly.

The pragmatic reality is that infrastructure mechanisms, like an SMTP 
extension, require massive community interest to gain adoption, and even 
then usually take a very long time.

By contrast there is massive history showing far easier and more 
successful adoption of header-based mechanisms.

d/

---

From: Bill Mills <[email-masked]>
Date: Sat, 29 Mar 2014 18:13:08 -0700

Yahoo sends it on some pieces of mail and honors it when received.

Yahoo would likely not move to implement an SMTP mechanism until it's part of the mailer packages we use.

-bill

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

R's,

John

---

From: "John Levine" <[email-masked]>
Date: 30 Mar 2014 03:30:09 -0000

>implemented along the path.

This still makes unwarranted assumptions about mail receivers.  

If I were to implement an RRVS SMTP extension (unlikely even though my
MTA supports SMTP extension plugins), I would continue to accept all
the mail sent to my spamtraps regardless of what the RRVS said.  So
sue me.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Sat, 29 Mar 2014 21:11:56 -0700

> the mail sent to my spamtraps regardless of what the RRVS said.  So

If your receiver purported to conform to the extension and then violated 
its semantics, well, of course, there's no way to stop that.

But that outcome does not demonstrate my making an unwarranted 
assumption.  It demonstrates a protocol violation.

d/

---

From: "John R Levine" <[email-masked]>
Date: 30 Mar 2014 00:43:32 -0400

> But that outcome does not demonstrate my making an unwarranted assumption. 
> It demonstrates a protocol violation.

The unwarranted assumption is that receivers will follow the protocol. 
They will when they feel it's in their interest to do so, they won't when 
they won't.  This shouldn't come as a big surprise to anyone.

My point is that since RRVS can never be more than a non-binding hint to 
the receiver, there's little point to building a lot of complex mechanism 
around it.  Despite its theoretical advantages, It's hard for me to 
imagine a realistic scenario in which the SMTP extension would work much 
better than the header.

Regards,

---

From: Barry Leiba <[email-masked]>
Date: Sun, 30 Mar 2014 11:05:17 -0400

>      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.
>
>      2. If it is preferable that the mail be delivered to the correct user,
> but not essential, then let the header field provide advisory information.

The problem is that an MTA in the middle of things is allowed to
downgrade the SMTP extension to the header field, without consulting
the sender.  That breaks (1).

> This is essentially coercive thinking.  It presumes that the IETF somehow
> can dictate operational paradigm changes

You spin it as coercion, but I look at it as influence, which is not
the same thing.

Apart from that:
We don't standardize everything that's out there.  We standardize the
things that we think are the right, interoperable ways to do things.
Sometimes we also document, as Informational, other ways that we don't
recommend as standards.

This is an idea case for this.  One mechanism is easy to deploy, so
it's out there in use because folks could start experimenting with it
without a documented standard.  But it doesn't interoperate properly
and it has serious issues with respect to the use cases we're saying
we want to support.

The other mechanism isn't practical to deploy until there's a
documented standard that everyone can start updating their SMTP
implementations to, and it will take a while to deploy once that
happens.  But it's a more robust, solid mechanism that addresses the
use cases better.

In many other situations we would make the better mechanism be our
Standards Track solution, and we'd document the other as Informational
(Experimental probably isn't right for this one; in the mt-priority
situation we didn't already have deployment).  That doesn't say anyone
is "bad" for implementing the Informational mechanism.  It might or
might not result in deployment of the Standards Track one.  But it
standardizes what we consider to the the ight technology for the job,
while documenting the other one for those who need it.

We've done this many times and will continue to do so.  Why is this
not an appropriate time to do it?

> standardization, namely declaring something to be a common

I would say that you're misunderstanding the purpose of
standardization.  It's not to declare as a standard anything that's
deployed, even widely deployed.  It's to declare as a standard a
recommended, interoperable, robust solution... not just any solution.
The IETF isn't here to look at what people are doing, and to say,
"Hey, let's write that one down."  We're here to develop properly
engineered standards.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Sun, 30 Mar 2014 11:20:08 -0400

> My point is that since RRVS can never be more than a non-binding hint to the
> receiver, there's little point to building a lot of complex mechanism around
> it.  Despite its theoretical advantages, It's hard for me to imagine a
> realistic scenario in which the SMTP extension would work much better than
> the header.

The realistic scenario is one in which the sender can know whether the
receiving system understands the extension.  Senders have to assume
that extensions will be implemented properly, and, of course, we know
that there may be faulty or even malicious implementations.  That
aside, there's a big difference between getting a message bounced
because the extension isn't supported... and having the senders
request silently and undetectably ignored because it isn't.

Barry

---

From: "John R Levine" <[email-masked]>
Date: 30 Mar 2014 11:56:49 -0400

On Sun, 30 Mar 2014, Barry Leiba wrote:

>> Despite its theoretical advantages, It's hard for me to imagine a 
>> realistic scenario in which the SMTP extension would work much better 
>> than the header.

> receiving system understands the extension. ...

I suppose, but it still seems far fetched.  If the receiving system 
doesn't support the SMTP extension, there is some chance that the message 
will go to the wrong person due to mailbox reuse.  If it does implement 
the extension, there is some other chance it'll go to the wrong person, 
through malice (my scenario) or bugs of various sorts.

This strikes me as the public works department installing a bright new 
lamp post, and we drunks wandering toward it to look for something but 
we're not quite sure what.  If you really care that a message only goes to 
the correct recipient, you use S/MIME or PGP to encrypt it to the 
recipient's key.  So we have the niche here of mail that is sensitive 
enough that it should go to the right person, yet sufficiently unsensitive 
that it's not worth encrypting.  It still doesn't seem like a large enough 
niche to merit a lot of mechanism.

R's,
John

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 30 Mar 2014 18:07:13 +0200

It feels like one of those web things: "The location of the pubsubhubbub 
hub is specified using the Thinga-Monga HTTP Response field, or in the 
Wanga-Wanga XML element, or in..." I forget the third alternative. Reading 
it made me quite happy SMTP servers are always on TCP port 25. There is 
much good about making up one's mind.

Arnt

---

From: Dave Crocker <[email-masked]>
Date: Sun, 30 Mar 2014 09:12:32 -0700

> The unwarranted assumption is that receivers will follow the protocol.

All protocol specifications suffer that assumption.  It's the 
distinction between technical specifications and enforceable laws.  IETF 
standards do not have the leverage of the state.  So it's good not to 
confuse the meaning of normative language with legal language.

The confusion about specification meta-language semantics is a 
continuing point of distraction.  Simply put, either one is operating by 
the rules of the specification or one isn't.  If one isn't, then they 
are on their own.

Perhaps ironically to your comment, I've been tending to refer to this 
issue by borrowing a perspective from contract law, calling this The 
Four Walls of Protocol Authority:  A specification constructs a space 
for its application.  The specification is the authority within the 
walls.  Step outside the four walls, and the specification is 
essentially irrelevant.

So while true, your observation adds nothing to the substance of the 
current thread.

d/

---

From: Barry Leiba <[email-masked]>
Date: Sun, 30 Mar 2014 12:25:04 -0400

> If you really care that a message only goes to the correct
> recipient, you use S/MIME or PGP to encrypt it to the recipient's key.  So
> we have the niche here of mail that is sensitive enough that it should go to
> the right person, yet sufficiently unsensitive that it's not worth
> encrypting.

That's a very good point.  It's a pity that S/MIME isn't really
deployable at the scale we'd want for this, but I think you're right
that it's the Truly Proper solution to the use cases we have here.
Thanks for raising that point.

Barry

---

From: Dave Crocker <[email-masked]>
Date: Sun, 30 Mar 2014 09:27:45 -0700

On 3/30/2014 9:25 AM, Barry Leiba wrote:
> That's a very good point.

It's a good theoretical point, but not a practical one, for the reason 
you note:  neither encryption mechanism has scaled.  Therefore the 
thought of relying on either of them isn't useful.

It might be an added incentive for pursuing an encryption mechanism that 
does scale, but one phrases such things as desirable goals rather than 
usable alternatives.

d/

---

From: "John R Levine" <[email-masked]>
Date: 30 Mar 2014 13:03:28 -0400

> It might be an added incentive for pursuing an encryption mechanism that does 
> scale, but one phrases such things as desirable goals rather than usable 
> alternatives.

The obvious one is self-signed S/MIME keys.

In case it wasn't clear, I think that RRVS is a reasonable idea, but it's 
not a security mechanism, it's just a hint.  Yes, the header can leak info 
about signup dates, but since it's likely to be attached to someone else's 
bank statement, it's not worth a lot of work to fix.

Regards,

---

From: Ned Freed <[email-masked]>
Date: Sun, 30 Mar 2014 09:51:05 -0700 (PDT)

Dave Crocker wrote:

...

> market has long-standing demonstration of resistance.

Agreed.

> status mostly will serve to marginalize the IETF.

Additionally, matching what the market wants isn't all that easy. For one
thing, the IETF is (necessarily) slow, whereas market conditions can
change fairly quickly.

> serious limit to the costs that can be imposed for adopting it.

The truth is we don't actually know what the market is for this mechanism, and
we won't know for some time. The past accuracy of our predictions of the
success of various extensions has not been good. Just as one example among
many, not only was there considerable resistance to standardizing and
subsequently advancing the PIPELINING extension, in part because it was an
individual effort. It turned out the market didn't seem to care about where the
extension came from. Funny that.
 
> intermediaries that have no concern for whether the address belongs to

Indeed. Cost/benefit assymetries are often the bane of extension deployment,
and tunneling mechanisms are an effective means of working around that.

That said, this assumes that the important use cases will involve
intermediaries. That may or may not be true.

> "wrong" thing and it mostly winds up blocking progress and/or looking silly.

There's also a long history, aided in part by what some see as the effective
elevation of the meaning of "proposed standard", to demand ever-increasing
amounts of evidence of widespread interest in deployment prior to
standardization. And this almost always done absent any assessment of actual
standardization costs. (Putting a two page document that specifies a minor
tweak to an existing protocol is a very different thing than standardizing an
alternative to some existing and fairly complex protocol, yet the criteria we
apply don't seem all that different to me.)

> then usually take a very long time.

In practice it's even wierder than that. Back in the day the NOTARY extension
received substantial deployment because it happened to get implemented in a
couple of popular implementations right before serious security flaws were
found in those implementations.

Or consider mobile clients and IMAP, which is starting to look a little like a 
small group of monopsonies: A single large vendor can add support for some
extension for whatever reason which then drives servers to support it, and in
so doing significantly shape of how the protocol is used.

> successful adoption of header-based mechanisms.

Quite true, but there have also been some spectcular failures in that space.
Sender/X-Sender/X-X-Sender comes to mind, as does
Priority/X-MTS-Priority/X-MSMail-priority.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Sun, 30 Mar 2014 10:20:18 -0700 (PDT)

> I don't recall the rationale for the outcome of SMTP Priority,

If memory serves, it was essentially the opposite situation: The
original focus was on the SMTP extension and the header mechanism was
added later.

Whereas here the header mechanism came first and the extension was added
later.

> but the

I would not call it broken, but it's definitely overwrought.

> problematic field, or, at least, documenting the danger.

SSDD. Every time one of our security mechanisms has the great good luck to get
some traction, we try and build on it, usually with mixed results. (It's really
hard to fault this given how poor our track record with security mechanisms
is.)

DKIM is no exception. It solves an important identification problem for
messages traveling between ADMDs, and arguably does it in a fairly optimal
fashion. But that does not make it a candidate for things like end-to-end user
signatures, where issues including, but hardly limited to, header stripping
invariably show up.

> most MUAs do not show more than a few, common header fields.

Er, no. Copying envelope information into the header requires implementation
work: You have to not only implement the extension to even have the information
in hand, you'd also have to intentionally extend it to do this. There may be
some implementors out there that go considerably out of their way to violate
security models, but I haven't run into them. Corners get cut a lot more often
than they get added.

> worthy of standardization, rather than "it's a hack".

I for one don't have a problem calling it a hack. It puts it in good company
with a lot of other standards, some quite important and successful.

> sub-system.  But it's not practical, given long and UNreliable adoption

I'd characterize it as more unpredictable than unreliable, but that's just
a nit.

				Ned

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 30 Mar 2014 13:49:23 -0700

> niche to merit a lot of mechanism.
This summary seems just a little bit hyperbolic to me, and discards the
fact (which I don't believe is in dispute) that S/MIME and PGP simply have
not had the uptake we need in order for them to be viable options.  So the
messages that are the primary use case for RRVS are certainly worth
encrypting, but encryption is a nonsense solution when it's unlikely that
the receiver would know what to do with such a thing.

-MSK

---

From: "John R Levine" <[email-masked]>
Date: 30 Mar 2014 17:15:59 -0400

> the receiver would know what to do with such a thing.

I'd turn it around the other way--if there were a lot of mail for which it 
were really important that it be sent to the same person who received 
prior mail sent to the same address (which is not the same as sending it 
to the "right" person), we'd have a way to do it by now.

S/MIME with self-signed certificates would come pretty close.  There are 
off the shelf list managers now that can do S/MIME mailing lists, with 
outgoing mail encrypted with each subscribers's key, with the keys managed 
largely automatically from subscription messages. (Sympa, if you were 
wondering.) But hardly anyone uses them.

The RRVS SMTP extension feels to me like a FUSSP, where the second S is 
Security.  Yeah, it'll avoid some misdelivery, but particularly due to 
downgrades on forwards and various misimplementations, it's not likely to 
do in practice much more than the actual implemented RRVS header will, and 
is more likely to provoke the usual FUSSP arguments in which its 
proponents demand that everyone in the world change their software to deal 
with its limitations.

Also, so far none of the receivers that count say they'd even implement 
it, so why bother?

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Sun, 30 Mar 2014 14:19:38 -0700

> intermediaries. That may or may not be true.

It counts use cases with intermediaries as being important.  That's 
different than saying "the" important use cases.

Intermediaries are not required, but they must be permitted in the 
scenarios.

On the average, these days, there is a tendency to ignore or discount 
scenarios with intermediaries.

What we're supposed to do, for average IETF protocols, is assume general 
use, over the open Internet.  For email, that means supporting scenarios 
with independently administered intermediaries.

For cases in which intermediaries are explicitly not supported, the 
burden of justification lies with the proposers.

> standardization.

For Proposed Standard, I haven't seen that.

Rather, I've seen a tendency to approve working groups -- and the 
documents they produce  -- with only the narrowest of activity, where 
activity is our primary means for assessing community interest.  That 
is, we often approve work that was really done by only a few people, 
with very little diversity in the wg review of the work.

And this almost always done absent any assessment of
> actual
> standardization costs.

+1.  The IETF largely ignores cost considerations (or, rather, 
cost/benefit considerations) or uses highly constrained models.

> Priority/X-MTS-Priority/X-MSMail-priority.

"Easier" was meant to be different from saying "certain".

d/

---

From: Dave Crocker <[email-masked]>
Date: Sun, 30 Mar 2014 14:31:40 -0700

On 3/30/2014 2:15 PM, John R Levine wrote:
> S/MIME with self-signed certificates would come pretty close.

John,

What part of "S/MIME has a solid track record of failure as a viable 
choice for large-scale Internet use" is unclear?

So why are you focusing on using it?

Argumentation of the form "I don't like what you are proposing and think 
you should instead use something that we know won't work" is quite 
common in the IETF, but it's never constructive.

d/

---

From: "John R Levine" <[email-masked]>
Date: 30 Mar 2014 17:51:35 -0400

> What part of "S/MIME has a solid track record of failure as a viable choice 
> for large-scale Internet use" is unclear?

None.

> So why are you focusing on using it?

I know it doesn't work as is.  It's not obvious to me that it's unfixable, 
which is why I said S/MIME with self-signed certs, which fixes (or at 
least changes) the key distribution problem.

> Argumentation of the form "I don't like what you are proposing and think you 
> should instead use something that we know won't work" is quite common in the 
> IETF, but it's never constructive.

Sigh.  Straw man arguments aren't much help either.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Sun, 30 Mar 2014 14:59:31 -0700

On 3/30/2014 2:51 PM, John R Levine wrote:
>
> I know it doesn't work as is.  It's not obvious to me that it's
> unfixable, which is why I said S/MIME with self-signed certs, which
> fixes (or at least changes) the key distribution problem.
>
>> Argumentation of the form "I don't like what you are proposing and
>> think you should instead use something that we know won't work" is
>> quite common in the IETF, but it's never constructive.
>

So it's good that that wasn't what I was doing.

There is a simple, concrete proposal in front of us.

You are attempting to argue against it by proposing a very general 
concept, not a very specific specification.  Better still is that the 
concept is to be applied to a long-standing problematic path that likely 
has multiple other barriers, not just the one you are addressing.

Pursuing a viable encryption effort is fine, but in practical terms it 
has nothing to do with the current draft.  Or at least, it currently 
doesn't and it certainly won't have, anytime soon.

d/

---

From: "John R Levine" <[email-masked]>
Date: 30 Mar 2014 18:08:07 -0400

> concept ...

Could you do me a big favor and stop attempting to rephrase what I said? 
You're not very good at it.

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Sun, 30 Mar 2014 15:17:23 -0700

> You're not very good at it.

Really, John.  You had to resort to an ad hominem attack, rather deal 
with the substance of concerns being raised?  Thanks.

Also, I didn't "rephrase" what you said.  I offered an assessment of it. 
  The difference is fundamental.

If you have been doing something different than I described, please 
explain how.

d/

---

From: Bill Mills <[email-masked]>
Date: Mon, 31 Mar 2014 12:34:30 -0700

I can see splitting the spec if there is enough desire to differentiate between the header mechanism and the SMTP extension.  I object to splitting it if this becomes a way to treat one as "less" than the other.  The RRVS header spec 
should be standards track.  Full stop.  It's implemented and 
interoperable on 4 of the largest user impacting sites in the world.
 
I thought we had called out the potential issues such as modifying headers and the effect on DKIM and other such signing extensions.  If that language isn't strong enough that's easy to fix.  Those issues a sufficient reason to split the doc IMO.

I agree that the extension is better in almost all ways.  If that wants to be it's own spec that's fine.  It has all the adoptability hurdles already discussed here, and is probably (the right/a good) long term strategy.

-bill

---

From: Bill Mills <[email-masked]>
Date: Mon, 31 Mar 2014 12:34:54 -0700

I thought we had called out the potential issues such as modifying headers and the effect on DKIM and other such signing extensions.  If that language isn't strong enough that's easy to fix.  Those issues do not constitue a reason to split the doc.

I agree that the extension is better in almost all ways.  If that want's to be it's own spec, fine.  It has all the adoptability hurdles already discussed here, and is the right long term strategy.

-bill

---

From: Barry Leiba <[email-masked]>
Date: Mon, 31 Mar 2014 18:56:31 -0400

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