Subject: Re: [apps-discuss] Back to draft-ietf-appsawg-rrvs-header-field-05 (was Re: Scope of protocol authority)

From: Eric Burger <[email-masked]>
Date: Sat, 28 Dec 2013 21:00:48 -0500

I never claimed all mail was one hop. My claim was that given the use case of a large enterprise that seends high value emails to consumers who use large MSPs, the enterprise controls their MTAs and the large MSP controls their MTAs. In the unlikely event the enterprise relies on their ISP for mail delivery, the likelihood of the enterprise successfully negotiating (commercial, not protocol) for RRVS service is pretty high. It is also extremely likely that the path from the enterprise's border to the MSP's border is direct is rather high. 

Sent from my mobile device. Thanks be to LEMONADE: http://www.standardstrack.com/ietf/lemonade
S2ERC: http://s2erc.georgetown.edu/
GCSC: http://gcsc.georgetown.edu/
Me: http://www.cs.georgetown.edu/~ eburger

-------- Original message --------
From: Dave Crocker <[email-masked]> 
Date:12/28/2013  8:09 PM  (GMT-05:00) 
To: Eric Burger <[email-masked]>,[email-masked] 
Cc: The IESG <[email-masked]>,IETF Apps Discuss <[email-masked]> 
Subject: Re: [apps-discuss] Back to draft-ietf-appsawg-rrvs-header-field-05
   (was Re: Scope of protocol authority) 

On 12/27/2013 10:12 AM, Eric Burger wrote:
> Yes, and look at the use case. If you are the enterprise sending the
> message, you will upgrade all the MTAs under your control. If you are
> the massive, public MSP advertising RRVS on the receiving side,  not a
> problem.
>
> If it is b2b, then as Ned pointed out, even if you are sending to
> [email-masked], you most likely don't want the last one.

Eric,

You've changed the argument.

I was responding to your claim that all mail was one-hop.

Now you are claiming that enterprises upgrade all their servers at the 
same time.  But of course, that's not the way operations in large 
organizations work.

Let's move back to the simple architectural and operational reality: 
Email is a distributed, multi-hop.  The fact that quite a bit of mail is 
essentially one-hop is a distraction from serious architectural discussions.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Dave Crocker <[email-masked]>
Date: Sat, 28 Dec 2013 22:56:42 -0800

On 12/28/2013 6:00 PM, Eric Burger wrote:
> I never claimed all mail was one hop. My claim was that given the use
> case of a large enterprise that seends high value emails to consumers
> who use large MSPs, the enterprise controls their MTAs and the large MSP
> controls their MTAs. In the unlikely event the enterprise relies on
> their ISP for mail delivery, the likelihood of the enterprise
> successfully negotiating (commercial, not protocol) for RRVS service is
> pretty high. It is also extremely likely that the path from the
> enterprise's border to the MSP's border is direct is rather high.

Eric,

With any sufficiently simplified set of assumptions, almost any 
assertion of feasibility can be justified.

However in the real world of enterprise operations, things are usually 
far more complicated than the model you've put forward.  Complicated in 
a number of different ways.  Complicated enough to make assurances of 
near-term (or 'timely') infrastructure support problematic, in my 
experience.

d/

---

From: Eric Burger <[email-masked]>
Date: Sun, 29 Dec 2013 07:27:33 -0500

Thinking about how email gets deployed and why there are multiple MTA’s in an enterprise, a lot of them are for filtering. I buy the argument that it would be a lot easier to change / add a single network element to implement RRVS than to change everything in the enterprise network.

Given that, I would humbly suggest giving up on the SMTP extension and only rely on the header. The rules and specifications for the header popping into and out of existence for what everyone on the list is arguing is a corner case (all MTA’s in the chain implement RRVS), that we might as well design for the general case (lots of MTA in the chain, and almost none of them implement RRVS).

Real MTA’s read headers anyway, so is there any operational harm from dropping the SMTP extension, even if we all agree it is the right place to do this processing from an architectural perspective?

On Dec 29, 2013, at 1:56 AM, Dave Crocker <[email-masked]> wrote:

> With any sufficiently simplified set of assumptions, almost any assertion of feasibility can be justified.
> 
> However in the real world of enterprise operations, things are usually far more complicated than the model you've put forward.  Complicated in a number of different ways.  Complicated enough to make assurances of near-term (or 'timely') infrastructure support problematic, in my experience.
> 
> d/
> -- 
> Dave Crocker

---

From: Ned Freed <[email-masked]>
Date: Sun, 29 Dec 2013 08:59:07 -0800 (PST)

> Given that, I would humbly suggest giving up on the SMTP extension and only
> rely on the header.

I strongly object. The extension is both easier to implement correctly
as well as far less prone to information leakage.

> The rules and specifications for the header popping into and out of
> existence for what everyone on the list is arguing is a corner case (all
> MTA’s in the chain implement RRVS)

I have never made that argument, nor do I believe that this is a corner case.

> , that we might as well design for the general case (lots of MTA in the
> chain, and almost none of them implement RRVS).

And give up on the mechanism that actually works correctly. Not acceptable.

> Real MTA’s read headers anyway, so is there any operational harm from
> dropping the SMTP extension, even if we all agree it is the right place to do
> this processing from an architectural perspective?

Yes. See above.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Mon, 30 Dec 2013 10:37:09 -0800

Eric,

On 12/29/2013 4:27 AM, Eric Burger wrote:
> Thinking about how email gets deployed and why there are multiple
> MTA’s in an enterprise, a lot of them are for filtering. I buy the

And a lot aren't.   Real-world operational networking environments make 
all sorts of different topology choices.  To repeat an example cited 
earlier, there is case of department-vs-enterprise division of labor.

Anyhow the nature of the use seems to be irrelevant to the current 
discussion.  So why do you cite it?  The point being made was that email 
is often multi-hop.  It was offered to counter your claim that it's direct.

> argument that it would be a lot easier to change / add a single
> network element to implement RRVS than to change everything in the
> enterprise network.
>
> Given that, I would humbly suggest giving up on the SMTP extension
> and only rely on the header.

Except that it doesn't permit the kind of handling assurance the SMTP 
option does.

The two mechanisms have different enforcement and adoption trade-offs 
and hence satisfy /very/ different operational needs.

You don't seem to be raising any claims of technical deficiency, so I do 
not understand the basis for your insisting that there are problems with 
the spec.

> The rules and specifications for the
> header popping into and out of existence for what everyone on the
> list is arguing is a corner case (all MTA’s in the chain implement

As Ned notes and as I've been trying to stress, multi-hop is more common 
than folks seem to realize.  Hence, not a corner case.

> RRVS), that we might as well design for the general case (lots of MTA
> in the chain, and almost none of them implement RRVS).
>
> Real MTA’s read headers anyway,

Perhaps you have heard of the Shannon-Weaver model for communication, 
with the essential enhancement over the original version, where 
"feedback" is added, to close the loop.  What you are proposing loses 
that essential capability, which the SMTP option provides.  Hence it 
loses the ability to make enforcement assurances to the requester.

Again, I'm entirely missing what is driving your concerns, especially 
since your suggestions seem to keep shifting.

d/

---

From: Eric Burger <[email-masked]>
Date: Tue, 31 Dec 2013 14:55:03 -0500

On Dec 30, 2013, at 1:37 PM, Dave Crocker <[email-masked]> wrote:

> And a lot aren't.   Real-world operational networking environments make all sorts of different topology choices.  To repeat an example cited earlier, there is case of department-vs-enterprise division of labor.
> 
> Anyhow the nature of the use seems to be irrelevant to the current discussion.  So why do you cite it?  The point being made was that email is often multi-hop.  It was offered to counter your claim that it's direct.

Reminder: I NEVER said email was direct. My assertion was that it is most often, but not always, direct between the sending enterprise and the MSP. On the one hand, no one has EVER said that was not the case. On the other hand, it does not matter, so I dropped it last week.

> Except that it doesn't permit the kind of handling assurance the SMTP option does.
> 
> The two mechanisms have different enforcement and adoption trade-offs and hence satisfy /very/ different operational needs.
> 
> You don't seem to be raising any claims of technical deficiency, so I do not understand the basis for your insisting that there are problems with the spec.

I guess my IETF sensibilities were sensitized. The spec is very confusing and has a lot of machinery to deal with a hop here that understands RRVS and a hop there that does not and a hop over there that sort of understands RRVS. My observation was that if one went for architectural purity, e.g., only have an SMTP Extension, the people who need this today can get what they need. So far, no one has SAID I am wrong with this assertion, as people have been focusing on the red herring of thinking what I said was that email was direct, with no intervening MTAs.

Subsequently, and without anyone pointing it out, *I* pointed out that I could see situations where it would be hard for an enterprise to get all of their internal MTA’s to support RRVS.

> As Ned notes and as I've been trying to stress, multi-hop is more common than folks seem to realize.  Hence, not a corner case.

I never said the corner case is multi-hop! RTFE. I said the corner case is where there are intervening MTAs that are not under the direct control of the sending enterprise or under the direct control of the MSP. RTFE.

> Perhaps you have heard of the Shannon-Weaver model for communication, with the essential enhancement over the original version, where "feedback" is added, to close the loop.  What you are proposing loses that essential capability, which the SMTP option provides.  Hence it loses the ability to make enforcement assurances to the requester.
> 
> 
> Again, I'm entirely missing what is driving your concerns, especially since your suggestions seem to keep shifting.

What I am not understanding is when I say that we should use a mechanism with direct feedback (SMTP extension), I get told that most email gets delivered multi hop. When I say multi hop is a red herring, because those hops are almost always under the control of those who would upgrade their servers to support RRVS, I get told that I am ignorant, because most email gets delivered multi hop. So, here is disconnect #1. Multi hop is not the issue. Who controls the servers, and whether they get support for RRVS is the issue.

When I say, OK, if the assertion is that email gets delivered multi hop and most random hops will never support RRVS, then why bother doing RRVS as an SMTP extension, I get told that it is important to have a real, closed loop protocol. When I point out that is where I started, I get told that I am ignorant, because most random MTAs will not implement RRVS. When I point out that if that is the case, and you do not believe that the people who want this extension will implement the specification, I throw up my hands and say enjoy publishing.

No veto here, just pointing out that we are in a circular loop of shifting requirements and a realization and ignoring of the reality of the network topology this draft is supposed to be addressing.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 31 Dec 2013 17:25:10 -0800

On Tue, Dec 31, 2013 at 11:55 AM, Eric Burger <[email-masked]>wrote:

>
> No veto here, just pointing out that we are in a circular loop of shifting
> requirements and a realization and ignoring of the reality of the network
> topology this draft is supposed to be addressing.
>
>
I don't understand why there's a perception of shifting requirements.
Rather, the two approaches have different capabilities and attempt to
address different parts of the ecosystem.  The SMTP extension route is
architecturally speaking more correct for reasons identified in the draft
-- and according to Ned at least, easier to implement -- while the header
field has a much lower barrier to entry and actually is in production use.

There isn't a single true topology to address here.  The sender can decide
which method is most practical given its own operational and security
concerns.

-MSK