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

["Murray S. Kucherawy" <[e-mail]>]

On Tue, Nov 26, 2013 at 9:44 AM, Pete Resnick <[e-mail]>wrote:

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

No objection to working on this during AUTH48.


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


OK by me.


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

Will revisit.  I think I agreed (it's not in front of me now), but I guess
I didn't capture it properly.


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


I thought I clarified that in the latest draft by explaining what was meant
by "compound instance".


>
>
>  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).
>
>
My recollection of Return-Path is that there's always zero or one, and it's
typically added at the top only during local delivery; any instance of it
in transit is basically wrong and subject to removal.  I'll have to revisit
this as well if that's wrong.

Thanks for persisting on these points.

-MSK