Re: [apps-discuss] Pete Resnick's Yes on draft-ietf-appsawg-malformed-mail-10: (with COMMENT)

[Pete Resnick <[e-mail]>]

I know Barry sent through his approval, but I wanted to send you my 
comments just in case there is room to change during AUTH48. (I was sick 
with a cold over the weekend; sorry for the delay.)

On 11/23/13 11:04 AM, Ned Freed wrote:

> Murray wrote:
>
>> All of this works for me except:
>>
>> On Wed, Nov 20, 2013 at 2:35 PM, Pete Resnick<[e-mail]>wrote:
>>
>>> 4 - It seems worth pointing out somewhere in this section that the
>>> prepending of Received fields is the safest thing to do if changes must
>>> be made to the message to pass information between modules.

Your new text says:

    Where a change to content between modules is unavoidable, adding
    trace data (such as prepending a standard Received field) will at
    least allow tracing of the handling by modules that actually see
    different input.

I think this is misplaced, and I think you missed the point. Your 
paragraph seems to say you *want* to insert trace data, and that 
prepending Received fields is one way to do it. I think the main point 
of the section is generally correct: You *don't* want to be adding trace 
data. What I meant for you to add was that, if you do need to add trace 
data, then the *only* recommended way to do it is to prepend Received 
fields. I would change the paragraph to:

    Where a change to content between modules is unavoidable, for example
    to add trace data, the safest way to do so is to prepend Received
    fields with the appropriate information.

And I'd move it right after paragraph 2.

>>> 7.1.6 - Why is the second example not obviously better? I have a hard
>>> time imagining circumstances where an unterminated quoted-string that
>>> contains an angle-bracketed thing that looks like an addr-spec is in fact
>>> a local part.

Your change here doesn't address my comment. You still say, "leaves 
software with no obvious "good" interpretation". I disagree. I think the 
second *is* an obvious good interpretation.

>>> 7.5 -
>>> What's the difference between 3&  4? Or maybe I don't know what "compound
>>> instance" means in 3.

You never did answer that question.

>>> 7.5.3 - What's the harm in more than one Return-Path? Only one of
>>> interest is the top-most.
>> The issue here is that some components pick the last one, and some pick the
>> first, in general.  More often this happen with From, but Return-Path is
>> not special in this regard.
>>      
> FWIW, one thing an MDA can do is check and see if the top Return-path: agrees
> with the current MAIL FROM, and if it does don't add a redundant Return-path:
> field.
>    

Yep. And I worry about the fact that 7.5.3 pretty directly contradicts 
[MAIL] on this point without mentioning it. 5322 clearly allows multiple 
Return-Path fields, so long as they're block prepended with Received 
fields. Maybe that's now considered a problem, but it seems like you'd 
want to mention that this is a change. And I'm still not clear on the 
harm given that Return-Path is supposed to be trace and ignored by end 
systems (unlike From, which is clearly going to be used).

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - [phone]