Re: [apps-discuss] Splitting RRVS

[Dave Crocker <[e-mail]>]

On 3/27/2014 3:35 PM, Murray S. Kucherawy wrote:
> 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/


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/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net