----- Original Message ----- > From: "John Levine" <jo...@taugh.com> > To: dmarc@ietf.org > Cc: fra...@peachymango.org > Sent: Wednesday, April 29, 2015 2:36:46 PM > Subject: Re: [dmarc-ietf] New Version Notification for > draft-ietf-dmarc-interoperability-02.txt > > >Please post more reviews... > > Hmmn. Section 3.1.2.3 on EAI is, to a first approximation, completely > wrong. Please delete it, since the problems it describes do not > actually exist. > > EAI does not, repeat NOT, downgrade messages in transit. If I send > you an EAI message, either it'll be delivered as that EAI message, or > it'll be bounced back. There's no reason that DMARC wouldn't work > just the same as it does on normal mail, give or take some minor and > easily resolved ambiguities about whether the domains in DKIM > signatures are U-labels or A-labels.
Yes, they are not downgraded in transit. I improved the solution section in "receivers", but I realize the description of the problem is not accurate. Fixing (and see below). > > All of the downgrade stuff to which this section refers only happens > in one rather arcane situation -- the MTA that received the mail does > EAI but the user's MUA doesn't, and the user is trying to pick up the > mail with POP or IMAP. Our choices boiled down to invent a new error > code that says "you have new mail but you can't see it neener neener" > or downgrade messages during POP or IMAP retrieval. Since the normal > place to check DMARC is at delivery time, DMARC will have done its > thing long before any possible downgrade, so the downgrade doesn't > matter. > I don't see anywhere in RFC6854 that the group syntax is for MDA/MS sole use as you describe it above. I wish it would say so. An MTA that has an EAI message that tries to pass it to an MTA that do not support SMTPUTF8 will bounce the message. The MUA or MSA or user may then decide to change the message and use the group syntax to transmit it to an non-EAI environment if it has a normal email address to send to. One can envision such process to be automatic without the user input, especially when the MUA/MSA/MTA is on the same server. See how Coremail handles it transparently (tho they don't use group-syntax). RFC6854 lacks a lot of guidance. Even in your case when the MDA/MS gets such message with group-syntax and forwards it, then an MTA will have to deal with it. > People might try to forward downgraded messsages, but the issues there > are the same as for any message that's smashed when it's forwarded, > as described in 3.2.2. > > We invented the RFC6854 empty From: group syntax hack to enable simple > EAI downgrades, but it applies to any mail, normal or EAI. My strong > suggestion would be that if there's no address on the From: line, > there is nothing for DMARC to do and no problem to solve. It's just > like any other message with a return address for which the MTA has no > reputation info. Yes there is nothing for DMARC to do, but a DMARC aware MTA, may not like to have a message with an RFC5322.From header field with no valid domain in it. Also moving to email over IPv6 requires you to move to domain blocking. So the point here, there is little incentive to do DMARC if you are not stricter in what you tolerate in the RFC5322.From. Therefore, if you don't want to reject emails from EAI based mail system, your system must support EAI. > > In 3.2.3, I've never seen list software do PGP encryption, but I have > seen it do S/MIME decryption and re-encryption. You might want to > change the example. I have seen lists do PGP encryption. Adding S/MIME nevertheless > > In section 4.1.1.1, add: > > * Senders can use different domains for mail sent directly and mail > sent in ways likely to have DMARC problems, the former with a DMARC policy > and the latter without. Added and rephrased > > Please also delete Section 4.1.2.3, since again the EAI problem it > describes does not exist. See above > > In the first long paragraph in 4.1.3.3, at this point I don't know > anyone adding .INVALID, but I know people rewriting the From: address > to a different valid address that forwards to the real author. Some > people do it the way I do, e.g. mari...@yahoo.com.dmarc.fail, or > LISTSERV invents a pseudo-random address in the list's domain. You used to do it no? Anyhow this is just an example of suffix to use. The LISTSERV solution is a derivative of rewriting the RFC5322.From header field to use your own domain. Not sure if we should describe it too? > > Section 4.2.1 is hard to follow. Is it describing Doug's thing? not specifically, people have searched to do some form of transitive trust. > > In Sec 7, it's often considered tacky to acknowledge people listed > as document authors. roger. will confer with other authors. It was to acknowledge my lack of contribution to the core of the document :P > > R's, > John > > PS: I could swear we went around the EAI stuff in the last version of this > draft. > Yes but both of our reality fields need to be adjusted... :P The solution part has been fixed but not the problem part correctly, I overlooked that part. While I'm doing some EAI+DMARC and have some practical operational experience, the large implementation that I know of is Google. It would be nice to have some guidance from them here. We may need a few iterations here. _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
