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

[Ned Freed <[e-mail]>]

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

Similar considerations do apply to 7bit and 8bit entities and types under text,
but this section isn't written to cover that. And covering all the permutations
of entity type/encoding/contnent mismatch is a pretty tall order. Do we really
want to get into this so late in the game/

> §6 title is misnamed - missing "i" in "terminaton".

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

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

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

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

				Ned