--On Sunday, September 09, 2012 21:58 +0000 Franck Martin
<fmartin(_at_)linkedin(_dot_)com> wrote:
I'm happier,
Made comments in another thread on why I believe it opens a
security hole wider rather than trying to close it.
I guess I could leave with it, when this downgrade is only
done from a SMTPUTF8 compatible MTA to an ASCII MTA.
But, as several people have tried to remind you, the EAI specs
are consistent with the prohibitions in RFC 5321, prohibitions
that expressedly forbid MTAs from changing addresses enrounte
(for downgrading or any other reason). The specs in Last Call
now don't apply to MTAs or MTA actions _at all_. They apply
_only_ to communication between an SMTPUTF8-compatible IMAP or
POP server and a legacy IMAP or POP client.
The experimental versions of the EAI specs did provide for
in-transit downgrading. The main conclusion from those
experiments (described in RFC 6530, which I'd still encourage
you to read) was that such MTA->MTA downgrading was a bad idea.
So the WG agrees with you, so do the specs, and you are
attacking a (rather worn and threadbare) strawman.
Please focus on where this actually occurs and what the specs
actually say. And, again, you might start by responding to
Ned's questions.
I mean a SMTPUTF8 MTA MUST reject such downgrade.
With regard to whether it will tolerate group syntax in
backward-pointing header fields, the decision has absolutely
nothing to do with EAI and whether MTA is SMTPUTF8-capable or
not. However, to get anything close to a "MUST reject", you'd
need to propose a very radical change to the way email is
specified. In theory and largely in practice, MTAs deal with
envelopes, not header fields. RFC 5321 and its successors are
carefully designed to never require that an MTA do anything with
header fields other than prepending information to them. I
think we all recognize that mail filtering and classification
has created a lot of exceptions in which header fields (and
content) are inspected prior to the final delivery server. Even
that typically occurs close to either the submission or final
delivery points. I think you would get a _lot_ of resistance to
a change that would _require_ SMTP MTAs to inspect message
bodies (including header fields) to see if they contained some
offending construction.
Let's not try to legitimize an attack vector (Friendly from
having nothing to do with the author of the email).
I've seen no evidence at all that this does any such thing.
john