Re: [apps-discuss] I-D Action: draft-ietf-appsawg-malformed-mail-06.txt

[Dave Cridland <[e-mail]>]

First off, I should say this was my first run-through, and I've not been
following the discussion - if things have been discussed to death already,
then feel free to shoot me down.

On Tue, Jun 18, 2013 at 2:10 PM, Ned Freed <[e-mail]> wrote:

> > On Tue, Jun 18, 2013 at 8:27 AM, Murray S. Kucherawy <
> [e-mail]>wrote:
>
> > >
> > > Anyone else interested in providing feedback on it?  Should I poke
> > > Salvatore to start the machine?
> > >
>
> > §6, last para should explicitly state this is only a suitable fixup for
> > text/plain and text/html; and even then only in known character encodings
> > (charsets), such as ASCII, ISO 8859, and UTF-8. I'd hate everyone to
> > "correct" the 0x0A octets in my JPEGs.
>
> Disagree. This section is talking about processing messages as a whole
> as received via SMTP, prior to MIME interpretation.
>
> What needs to be made clear is that this is talking about SMTP
> specificially,
> not interpretation of MIME entities. And it probably should note that
> it doesn't apply to binary SMTP.
>
>
Right, I'd misunderstood the notion. So yes, it was the paragraph before
derailling me, because it starts discussing ASCII. I think if it merely
said that bare CRs and LFs were uncommon in non-binary messages, we'd be
good here.

   Within modern Internet Mail it is highly unlikely that an isolated CR
   or LF is valid in a message, outside of binary transfers [BINARY].
 Furthermore [MIME] presents
   mechanisms for encoding content that actually does need to contain
   such an unusual character sequence.



> > I'm concerned with §7.1.4's implication that implementations should be
> > looking for possibly email addresses in header field comments. I'm happy
> > that a bare ")" should be treated as a literal, but I'm wary of the
> > possibility of "hiding" email addresses in comments. Overall, I'm
> inclined
> > to say I'd prefer that we advised that an unterminated comment in a
> header
> > field value were treated as being terminated at the end of the value.
>
> I'm ambivalent about this one. It's quite true that addresses are sometimes
> hidden in comments, but as a practical matter, anyone who does that as
> opposed
> to removing the address outright and then gets the syntax wrong kinda
> deserves
> what they get.
>
>
What's concerning me here is that I wouldn't want to be trying to parse
comments in the hope of finding things there. I'd rather assume that the
error with an unterminated comment was the lack of termination, not that it
might contain something useful I should go hunting for.


> > I have similar concerns with $7.1.6 - more so because I suspect that "Foo
> > [e-mail] could also be interpreted as "Foo local"@example.net.
>
> Well, of the three, which do you think is more likely to have been the
> intent?
>
>        To: "Joe <[e-mail]>"@example.net
>        To: "Joe" <[e-mail]>
>        To: "Joe joe"@example.net
>
> Yes, they're all legal, but in practice how often do you see local parts in
> valid addresses containing angle brackets and spaces?
>
>
Bear in mind I worked for Isode for years, so I've built up a strong
immunity to local parts with spaces due to MIXER, but in any case the
middle one is likely to be the intent. However I'm again concerned that it
means finding an unterminated phrase and back-tracking to see if the phrase
"looks interesting".


> > §7.5 mentioned the case of two From fields - it doesn't mention the
> > possibility of combining the two, so:
>
> > From: First <[e-mail]>
> > From: Second <[e-mail]>
>
> > ... could become:
>
> > From: First <[e-mail]>, Second <[e-mail]>
>
> > Obviously you'd need to inject a Sender field as needed (as per §7.6 of
> > this memo).
>
> > I'm not suggesting it has to offer this, but I'm wondering if the lack of
> > offer is intentional?
>
> I hadn't considered this. It's kind of an interesting idea, but given the
> issues that arise in practice when more than one address is present in a
> From:
> field, I have doubts about its utility.
>
>
Yes, multiple addresses in a From is unusual; but I'd have thought that
collapsing multiple header fields into one would in general be sane?
(Another example might be concatenating two subject header fields into one
longer one).


> > §9.1 describes a technique of breaking lines at points that make no
> > semantic difference. Given the poor NLP capability in the majority of
> > deployed MTAs, I'm slightly suspect of this advice. Even without any
> snark
> > at all, cases such as format=flowed (and other message quoting) could
> > easily be warped or broken by breaking lines.
>
> Strongly disagree. The alternative of encoding oversized lines may not be
> practical, so the choices are truncate or wrap. The chances that truncation
> is going to produce better results than wrapping are pretty low.
>
> And I'm not even slightly sympathetic about the possible damage done due to
> lack of NLP knowledge in MTAs. If you want your format=flowed material to
> arrive intact, don't spew out illegal garbage.
>

Happy to let your strong disagreement trump my slight suspicion.

Dave.