Re: [EAI] Last Call: draft-ietf-eai-popimap-downgrade-07.txt (Post-delivery Message Downgrading for Internationalized Email Messages) to Proposed Standard
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. I mean a SMTPUTF8 MTA MUST reject such downgrade. Let's not try to legitimize an attack vector (Friendly from having nothing to do with the author of the email). On 9/9/12 2:01 PM, Barry Leiba barryle...@computer.org wrote: I will make the change. I'll also remind the EAI group that there have been a couple of objections to the 5322upd-from-group spec, which I have to address. I might do that by scoping it down a bit with some SHOULD NOT use sort of language to address those concerns. Have to review them and see. My suggestion is to say something like the following: ... That could be either in Security Considerations or a separate section. You could even do something radical and incorporate it as a section called Applicability and use the words LIMITED USE (and, since no one seems to remember, a citation of RFC 2026 Section 3.3). I have just posted drft-leiba-5322upd-from-group-04: http://datatracker.ietf.org/doc/draft-leiba-5322upd-from-group/ That changes the definition of Sender as well as From, and also adds a new Applicability Statement section that has an edited version of John's suggested text. I like the result, and I hope others do as well. I will post something to the 5322upd-from-group thread, asking that those who had objected look at the new text and see if they're happy (or at least somewhat happier) with it. Barry ___ IMA mailing list i...@ietf.org https://www.ietf.org/mailman/listinfo/ima
Re: [EAI] Last Call: draft-ietf-eai-popimap-downgrade-07.txt (Post-delivery Message Downgrading for Internationalized Email Messages) to Proposed Standard
The IESG has received a request from the Email Address Internationalization WG (eai) to consider the following document: - 'Post-delivery Message Downgrading for Internationalized Email Messages' draft-ietf-eai-popimap-downgrade-07.txt as Proposed Standard Rats; I missed this in earlier review: -- Section 3.2.1 -- This procedure may generate empty group elements in From:, Sender: and Reply-To: header fields. [I-D.leiba-5322upd-from-group] updates [RFC5322] to allow (empty) group elements in From:, Sender: and Reply-To: header fields. It does not. It adds group syntax to From only. Group syntax is already allowed in Reply-To, and the draft does not change the rules for Sender. If this spec also needs Sender to change, I can update the 5322upd-from-group for that, but it's not there now. Barry
Re: [EAI] Last Call: draft-ietf-eai-popimap-downgrade-07.txt (Post-delivery Message Downgrading for Internationalized Email Messages) to Proposed Standard
--On Sunday, September 09, 2012 11:33 -0400 Barry Leiba barryle...@computer.org wrote: ... Rats; I missed this in earlier review: -- Section 3.2.1 -- This procedure may generate empty group elements in From:,Sender: and Reply-To: header fields. [I-D.leiba-5322upd-from-group] updates [RFC5322] to allow (empty)group elements in From:, Sender: and Reply-To: header fields. It does not. It adds group syntax to From only. Group syntax is already allowed in Reply-To, and the draft does not change the rules for Sender. If this spec also needs Sender to change, I can update the 5322upd-from-group for that, but it's not there now. Barry, I think it does. The presumption (since before 822) has been that Sender: can contain any address that can appear in From:. The ancient history is that From: need not even contain a deliverable address if Sender: is specified to match a business correspondence model in which: From: Big boss who doesn't use computers Sender: assistanct-to-b...@example.com has to be legitimate. 5322 and its predecessors took some of that capability away, but the only difference now is that From: can take a list of mailboxes and Sender: can take only one. I think 5322upd-from-group needs to apply to both backward-pointing address types to be effective for what popimap-downgrade needs. Sorry for not finding this in my reviews -- I should have. john
Re: [EAI] Last Call: draft-ietf-eai-popimap-downgrade-07.txt (Post-delivery Message Downgrading for Internationalized Email Messages) to Proposed Standard
I think 5322upd-from-group needs to apply to both backward-pointing address types to be effective for what popimap-downgrade needs. I will make the change. I'll also remind the EAI group that there have been a couple of objections to the 5322upd-from-group spec, which I have to address. I might do that by scoping it down a bit with some SHOULD NOT use sort of language to address those concerns. Have to review them and see. Sorry for not finding this in my reviews -- I should have. As should I have. Flrg. Barry
Re: [EAI] Last Call: draft-ietf-eai-popimap-downgrade-07.txt (Post-delivery Message Downgrading for Internationalized Email Messages) to Proposed Standard
I think 5322upd-from-group needs to apply to both backward-pointing address types to be effective for what popimap-downgrade needs. I will make the change. But in any case, the downgrade doc needs to remove reply-to from the list of header fields that 5322upd-from-group changes. Maybe this: OLD This procedure may generate empty group elements in From:, Sender: and Reply-To: header fields. [I-D.leiba-5322upd-from-group] updates [RFC5322] to allow (empty) group elements in From:, Sender: and Reply-To: header fields. NEW This procedure may generate empty group elements in From:,Sender: and Reply-To: header fields. [I-D.leiba-5322upd-from-group] updates [RFC5322] to allow (empty) group elements in From: and Sender:. Barry
Re: [EAI] Last Call: draft-ietf-eai-popimap-downgrade-07.txt (Post-delivery Message Downgrading for Internationalized Email Messages) to Proposed Standard
--On Sunday, September 09, 2012 11:52 -0400 Barry Leiba barryle...@computer.org wrote: I think 5322upd-from-group needs to apply to both backward-pointing address types to be effective for what popimap-downgrade needs. I will make the change. I'll also remind the EAI group that there have been a couple of objections to the 5322upd-from-group spec, which I have to address. I might do that by scoping it down a bit with some SHOULD NOT use sort of language to address those concerns. Have to review them and see. My suggestion is to say something like the following: A great deal of Internet email procedures and software assume that the addresses in From: and Sender: fields can be replied to and are suitable for use in mail organizing and filtering. The use of groups instead of mailboxes may disrupt those uses. Consequently, with this specification legitimizes the use of group syntax, that syntax should be used in those fields only under special circumstances and with caution. In particular, users and MUAs should generally not permit the use of group syntax in those fields in outgoing messages since the syntax will usually provide even less information than a null address () which is already prohibited by RFC 5321. That could be either in Security Considerations or a separate section. You could even do something radical and incorporate it as a section called Applicability and use the words LIMITED USE (and, since no one seems to remember, a citation of RFC 2026 Section 3.3). You can probably figure out how to use fewer words, but something like that would address the comments I've seen so far and, IMO, generally strengthen the spec. best, john
Re: [EAI] Last Call: draft-ietf-eai-popimap-downgrade-07.txt (Post-delivery Message Downgrading for Internationalized Email Messages) to Proposed Standard
The IESG has received a request from the Email Address Internationalization WG (eai) to consider the following document: - 'Post-delivery Message Downgrading for Internationalized Email Messages' draft-ietf-eai-popimap-downgrade-07.txt as Proposed Standard Rats; I missed this in earlier review: -- Section 3.2.1 -- This procedure may generate empty group elements in From:, Sender: and Reply-To: header fields. [I-D.leiba-5322upd-from-group] updates [RFC5322] to allow (empty) group elements in From:, Sender: and Reply-To: header fields. It does not. It adds group syntax to From only. Group syntax is already allowed in Reply-To, and the draft does not change the rules for Sender. If this spec also needs Sender to change, I can update the 5322upd-from-group for that, but it's not there now. I think the answer to that is yes, this needs to be allowed for Sender. Ned
Re: [EAI] Last Call: draft-ietf-eai-popimap-downgrade-07.txt (Post-delivery Message Downgrading for Internationalized Email Messages) to Proposed Standard
I think 5322upd-from-group needs to apply to both backward-pointing address types to be effective for what popimap-downgrade needs. I will make the change. But in any case, the downgrade doc needs to remove reply-to from the list of header fields that 5322upd-from-group changes. Maybe this: OLD This procedure may generate empty group elements in From:, Sender: and Reply-To: header fields. [I-D.leiba-5322upd-from-group] updates [RFC5322] to allow (empty) group elements in From:, Sender: and Reply-To: header fields. NEW This procedure may generate empty group elements in From:,Sender: and Reply-To: header fields. [I-D.leiba-5322upd-from-group] updates [RFC5322] to allow (empty) group elements in From: and Sender:. Looks like the correct change to me. Ned
Re: [EAI] Last Call: draft-ietf-eai-popimap-downgrade-07.txt (Post-delivery Message Downgrading for Internationalized Email Messages) to Proposed Standard
I will make the change. I'll also remind the EAI group that there have been a couple of objections to the 5322upd-from-group spec, which I have to address. I might do that by scoping it down a bit with some SHOULD NOT use sort of language to address those concerns. Have to review them and see. My suggestion is to say something like the following: ... That could be either in Security Considerations or a separate section. You could even do something radical and incorporate it as a section called Applicability and use the words LIMITED USE (and, since no one seems to remember, a citation of RFC 2026 Section 3.3). I have just posted drft-leiba-5322upd-from-group-04: http://datatracker.ietf.org/doc/draft-leiba-5322upd-from-group/ That changes the definition of Sender as well as From, and also adds a new Applicability Statement section that has an edited version of John's suggested text. I like the result, and I hope others do as well. I will post something to the 5322upd-from-group thread, asking that those who had objected look at the new text and see if they're happy (or at least somewhat happier) with it. Barry
Re: [EAI] Last Call: draft-ietf-eai-popimap-downgrade-07.txt (Post-delivery Message Downgrading for Internationalized Email Messages) to Proposed Standard
--On Sunday, September 09, 2012 21:58 + Franck Martin fmar...@linkedin.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
