--On Sunday, September 09, 2012 21:58 +0000 Franck Martin <fmartin@xxxxxxxxxxxx> 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