Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On 4/29/15 12:09 AM, Stephen J. Turnbull wrote: > Franck Martin writes: > > > I think we should refrain to blame anything or anyone. > > I think that there is no solution attractive to email users possible > without naming names. > > AFAIK[1], it is a fact that the problems that have made "DMARC" a > four-letter word across the Internet are almost entirely due to the > unilateral decisions to publish "p=reject" by *two* domains. Call > that "blaming" if you like, but that fact matters because any *good* > mitigation[2] involves their participation. > > The only alternative I can see to participation by those specific > domains (and any domains producing similar mailflows that may publish > p=reject in the future) is a general agreement among DMARC receivers > to treat "p=reject" as purely advisory (say, -2 spam points if > alignment is verified in SpamAssassin). I know you don't like that > weakening of the protocol, and I don't think it's a good idea, either. > DMARC is a great protocol for direct mail streams, proven in practice. Dear Stephen, An update of Dmarc-Escape draft attempts to unbury what should be a workable solution. Once DMARC libraries are updated to support an addition that includes a requested policy of "public", the cooperation of problematic domains should quickly become a minor concern. Domains making misleading assertions regarding their email alignment practices, especially in regard to exchanges involving public email would only require a small override to be imposed where an inappropriate "reject" becomes "public". In that case, the Domain Owner wishes for Mail Receivers to reject email that fails a modified DMARC alignment mechanism check will now include the Sender header field or the first email address in a multiple From header field. Failure can only result in Quarantine thereby making DMARC far more compatible with SMTP while also better ensuring against misleading policy assertions and undetected phishing. Domain reputation remains an effective tool when narrowed to specific criteria. The current situation where Author identity of a message being munged is not sustainable nor safe. https://tools.ietf.org/html/draft-otis-dmarc-escape-02 Regards, Douglas Otis ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On Wed, Apr 29, 2015 at 6:26 AM, Michael Jack Assels < mjass...@encs.concordia.ca> wrote: > Right. I'd been avoiding that because I saw this as a relatively minor > change to Murray's draft-kucherawy-dkim-transform-00, but if message > wrapping is considered a nonstarter, a new I-D is in order, assuming that > there's a simple, secure, and palatable way to divide any arbitrary message > body into its "original Author part" and "list decoration part(s)", > irrespective of the Author's part being good-ol' text or MIME. Since we're just throwing out ideas, I don't mind adding your "stf" idea to the transform draft. Just send me some text. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On 29 Apr 2015 09:11:57 EDT, "John R Levine" wrote: > > I'm still hoping for something that users will like, so I guess it's back > > to the drawing board. > > The usual next step is to write up the proposal as an I-D and send it in, > so we have a concrete description. Even if we decide not to use it, > having a spec to refer to is often useful when looking at future > proposals. Right. I'd been avoiding that because I saw this as a relatively minor change to Murray's draft-kucherawy-dkim-transform-00, but if message wrapping is considered a nonstarter, a new I-D is in order, assuming that there's a simple, secure, and palatable way to divide any arbitrary message body into its "original Author part" and "list decoration part(s)", irrespective of the Author's part being good-ol' text or MIME. MJA ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
I'm still hoping for something that users will like, so I guess it's back to the drawing board. The usual next step is to write up the proposal as an I-D and send it in, so we have a concrete description. Even if we decide not to use it, having a spec to refer to is often useful when looking at future proposals. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On 28 Apr 2015 19:25:36 EDT, "John R Levine" wrote: > Discussions on the Mailman list say that users hate wrapped messages, > because in most MUAs they look really ugly. OK, I'll concede that. They don't bother me, but I don't count for much. > I still don't see what the advantage is compared to a single message > digest which requires no changes to DKIM, no changes to DMARC, and has > already been implemented in a widely used list manager. Do single message digests get sent with the original Author's mailbox in the From header? If so, there's no advantage at all, but I have the impression that digests in general are sent "From" the list. > The only downside is that it looks awful in most MUAs so users hate it, > which I expect would also apply to your proposal. I'm still hoping for something that users will like, so I guess it's back to the drawing board. MJA ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
Franck Martin writes: > I think we should refrain to blame anything or anyone. I think that there is no solution attractive to email users possible without naming names. AFAIK[1], it is a fact that the problems that have made "DMARC" a four-letter word across the Internet are almost entirely due to the unilateral decisions to publish "p=reject" by *two* domains. Call that "blaming" if you like, but that fact matters because any *good* mitigation[2] involves their participation. The only alternative I can see to participation by those specific domains (and any domains producing similar mailflows that may publish p=reject in the future) is a general agreement among DMARC receivers to treat "p=reject" as purely advisory (say, -2 spam points if alignment is verified in SpamAssassin). I know you don't like that weakening of the protocol, and I don't think it's a good idea, either. DMARC is a great protocol for direct mail streams, proven in practice. Two? Yes, *two*. Bank of America? No problem, it's all direct mail. LinkedIn? Who cares? Pretty clearly linkedin.com employees have figured out that posting to MLs from that domain is not good for their ability to communicate, and LinkedIn itself primarily uses *direct* mail to collect traffic to their website. Accidental leakage from either kind of domain is no big deal and self-correcting. Why single those two out? Because they've already demonstrated that they place their own security issues over the general functionality of the mail system, so it's questionable whether they will buy in to any solutions we come up with. We already know that there may be security issues (DKIM delegation-style proposals) or significant costs (TPA via DNS-style proposals) to implementing those solutions. The best way to get an answer about what *they* want in a solution is to ask them. For that, we need to say their names. And if those two buy in, I think there will be huge pressure on any future p=reject-niks to participate in the mitigation protocols, even if not 6-sigma secure or involving additional nameservers or other costs. > It is what it is, Indeed, and what it is, is a purely private protocol whose own specification deprecates the controversial use case. Don't forget that fact. > and we should just note it, technically describe it, It had better not stay what it is! One thing that is easy to forget and to ignore is that, without a practical third-party authorization protocol, "p=reject" from even one large group of mail users has a chilling effect on all *new* third- party mail services. A large service with an established user base such as Intuit's invoicing service can weather even something like what happened in April 2014, but I wonder how many new 3rd-party services rolled out in first quarter of 2014 just died without even a whimper because of how "unreliable" they were for ordinary mail users at p=reject domains after April. I wonder how many 3rd-party services won't ever be implemented commercially for that reason. Yes, as written those stillborn services are just FUD, but economists have ample evidence that removal of apparently minor hindrances can invigorate innovation and the general business climate.[3] Don't deprecate the potential for innovation just because I'm unable to provide figures for the case of 3rd-party email offhand -- these things are essential impossible to measure in advance. > and see if better solutions can be provided. They can only be "provided" if the unblameable domains implement, because as DMARC is currently specified "p=reject" is a unilateral decision by the Author Domain. Otherwise, the solutions aren't worth the paper they won't be printed on. > This atmosphere is not conducive for group work. The deafening silence of the "p=reject" domains which originate large general-use mail streams as to how they will contribute to mitigation of the bad effects of their DMARC policies isn't conducive to group work, either. I've observed that posters here consistently categorically reject potential solutions as unworkable based on FUD about DNS costs and insecurity and inability to scale user profiles that specify per-user "trusted 3rd party" lists, despite the fact that representatives of these two domains haven't even commented on them. That fact matters because nobody who doesn't (1) originate general-use mail streams and (2) publish "p=reject" has to pay those costs, and at present they are only ones that satisfy both criteria! Footnotes: [1] If I am ignorant of relevant facts, please inform me. [2] Conforming to existing normative RFCs and meeting the requirements of *email users* as expressed to the providers of services they use. Eg, "author appears in From on mailing list posts". [3] Two cases in point. 1. Relaxation of airline regulation. Air travel in the U.S. today is much cheaper, more flexible, and (remarkably) safer than it was up to the 1970s. 2. Relaxation of postal and transpo
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
John R Levine writes: > Discussions on the Mailman list say that users hate wrapped > messages, because in most MUAs they look really ugly. It's worse than that. As of 6 months ago, it was impossible to read wrapped messages (as implemented by Mailman, anyway) in Apple Mail for iOS. As for "really ugly", in MUAs that can read it but do nothing special (all MUAs that can read it AFAIK) it looks like a bare digest of a single message. My feeling is that users think it looks *stupid*, not ugly, and posters at p=reject domains (the recommended configuration for Mailman does the DNS lookup so only p=reject domains are wrapped) complain about discrimination. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
I think I've failed to communicate. Yes, the pristine original message will be appropriately MIME-wrapped, with the list decorations becoming separate MIME parts, but the MUA is not expected to do anything except to present the MIME message to the final recipient. Discussions on the Mailman list say that users hate wrapped messages, because in most MUAs they look really ugly. Apart from the addition of tags, there isn't much change for DKIM. What changes is the algorithm used by DMARC in the special case where there exists a From-aligned but invalid signature and a Sender-aligned valid signature specifying the tf= tag and (if there's a consensus) an stf= tag. I still don't see what the advantage is compared to a single message digest which requires no changes to DKIM, no changes to DMARC, and has already been implemented in a widely used list manager. The only downside is that it looks awful in most MUAs so users hate it, which I expect would also apply to your proposal. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On 28 Apr 2015 17:04:31 EDT, "John R Levine" wrote: > > 4. Because the Sender Domain signature is valid and contains tf= and stf= > >tags, Recipient validators reconstruct the original message ... > > Oh, it's message wrapping. There are easier ways to do that without > changing DKIM: have the list send the message as a single entry MIME > digest. Mailman already knows how do to that, and in the extremely > implausible event that you can persuade MUAs to do message reconstruction, > it's easy to unwrap using existing tools. I think I've failed to communicate. Yes, the pristine original message will be appropriately MIME-wrapped, with the list decorations becoming separate MIME parts, but the MUA is not expected to do anything except to present the MIME message to the final recipient. The message reconstruction is to be done by the validator at the recipient's end, which will presumably be an MTA because it has the job of accepting or rejecting messages. The only reason for reconstructing the original message is to let DKIM check the validity of the From-aligned signature against the original message. Apart from the addition of tags, there isn't much change for DKIM. What changes is the algorithm used by DMARC in the special case where there exists a From-aligned but invalid signature and a Sender-aligned valid signature specifying the tf= tag and (if there's a consensus) an stf= tag. MJA ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
- Original Message - > From: "Franck Martin" > To: "R E Sonneveld" > > I believe a number of the Mediators, described in par. 3.2 of > > https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-01, cannot > > easily be changed. To give an example: recently when I was working for > > company A, I forwarded an invitation I got from company B to one of my > > addresses at ESP C. I just used the Exchange/Outlook forward function at > > company A and discovered that the mail client I used at ESP C showed the > > address of company B, no the address I have with company A. Company A is > > using Exchange/Outlook 2010 and has no plans to upgrade for the next > > couple of years. Should Microsoft update Exchange to support some > > mediator 'change' for DMARC, then this probably won't be 'retrofitted' > > into Exchange 2010. So it may take many years before I can use a version > > that supports DMARC 'mediation'. > > > Personally, I consider this a bug, because it looks like to C that B invited > him/her, while it was A that did. > > This bug is on the wiki, but it falls under the "Message Forwarding" section, > not sure we need to spell it out there, but it is not uncommon. > Correction it is described in the draft and still is... ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
- Original Message - > From: "Terry Zink" > To: dmarc@ietf.org > Sent: Tuesday, April 28, 2015 11:26:00 AM > Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis > > > Who knows? Perhaps Yahoo and AOL would suffer "user diaspora" if they > > kept publishing p=reject and MLMs decided to be DMARC-compliant when > > reinjecting messages. > > I see a lot of "Yahoo and AOL did this", "Yahoo and AOL don't care", "Yahoo > and AOL pushed their problems onto everyone else", etc. I don't think it's > useful to blame Yahoo and AOL for everything. What happens when Hotmail.com, > outlook.com, and gmail.com start publishing p=reject? Are we going to say > "The big four email providers pushed their problems onto everyone else" ? > > Then, if other big email providers in non-American markets (mail.ru, > orange.fr, etc.) start doing it, are we going to say "Everyone but me pushes > their problems onto the smaller providers" ? I think we should refrain to blame anything or anyone. It is what it is, and we should just note it, technically describe it, and see if better solutions can be provided. This atmosphere is not conducive for group work. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On 4/28/15 11:35 AM, John Levine wrote: >> Are we going to say "The big four email providers pushed their problems onto >> everyone else" ? > Yes, of course. But as we've seen, we have little ability to push > back. Dear John, Standing up to abusive domains requires a fallback policy compatible with SMTP. https://tools.ietf.org/html/draft-otis-dmarc-escape-01 Describes a safer and SMTP compatible policy as "Public". By ignoring the role of Sender DMARC is not compatible with SMTP which leads to dangerous practices when handling email exchanges serving the general public. Hacks aimed at transforming the From header into playing this role, such as the dubious double signing or proposed reversible transformation are solutions making the problem worse. Why make the source of a message more confusing? A role clearly defined by the Sender header field when present. The efficiency hack used by DMARC for applying policy against transactional messaging fails badly when misapplied against mediated and valid third-party services. Regards, Douglas Otis ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
- Original Message - > From: "Rolf E. Sonneveld" > To: "John Levine" , dmarc@ietf.org > Cc: superu...@gmail.com > Sent: Thursday, April 16, 2015 3:21:33 PM > Subject: Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis > > Now I think Scott is right that we need to make a step back and his > analysis might help us to know on which solutions we'd best spend most > of our time. However, having said that, I'm afraid that we're biased by > our discussions around the 'DMARC/Mailing List problem'. Let's not > forget the other use cases of draft-ietf-dmarc-interoperability. > > I believe a number of the Mediators, described in par. 3.2 of > https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-01, cannot > easily be changed. To give an example: recently when I was working for > company A, I forwarded an invitation I got from company B to one of my > addresses at ESP C. I just used the Exchange/Outlook forward function at > company A and discovered that the mail client I used at ESP C showed the > address of company B, no the address I have with company A. Company A is > using Exchange/Outlook 2010 and has no plans to upgrade for the next > couple of years. Should Microsoft update Exchange to support some > mediator 'change' for DMARC, then this probably won't be 'retrofitted' > into Exchange 2010. So it may take many years before I can use a version > that supports DMARC 'mediation'. > Personally, I consider this a bug, because it looks like to C that B invited him/her, while it was A that did. This bug is on the wiki, but it falls under the "Message Forwarding" section, not sure we need to spell it out there, but it is not uncommon. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
4. Because the Sender Domain signature is valid and contains tf= and stf= tags, Recipient validators reconstruct the original message ... Oh, it's message wrapping. There are easier ways to do that without changing DKIM: have the list send the message as a single entry MIME digest. Mailman already knows how do to that, and in the extremely implausible event that you can persuade MUAs to do message reconstruction, it's easy to unwrap using existing tools. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On 28 Apr 2015 12:51:42 EDT, "John R Levine" wrote: > > This is merely an attempt to find a mechanism whereby DMARC and MLMs could > > cooperate, up to the point where subscriber Recipient validators could > > honour an Author domain's p=reject, without removing the original author's > > mailbox from the From header. > > Unless I've missed something, I don't see how this solves any of the well > known problems. Bad guys can do whatever lists do, so you need to know > whether to trust the list, at which point you might as well just trust the > list and not mess around with the headers. The main difference is that the original Author's message, including 5322.From, is precisely reproducible (modulo canonicalization changes) from the message sent to the list, and will match the original DKIM-Signature with the required 5322.From alignment. If it doesn't, the final Receiver should do what RFC7489 says it should do: "[A]pply the most strict policy selected among the checks that fail." Yes, bad guys can do whatever lists do, but in this case, they'll need to piggy-back on a recent DMARC-passing message sent legitimately to them from the originating domain with a p=reject policy, and they'll have to include that message in its entirety, including all the signed headers, in their spam/phishing message; they can't simply replace the original message with their own. It seems much easier just to open a disposable account at a p=reject ESP and send the spam directly from there. > Also, if you want to go down the sender + list route, how about that > double DKIM signing hack? It has the advantage that it's invisible to > MUAs and doesn't affect reciepient MTAs beyond the DKIM validation code > which probably comes from a library that Murray wrote. I'll grant the advantage of invisibility to MUAs, but double signing has the disadvantage that the originating signer has to know when to add a weak signature with an fs=lists-r-us.com tag. What I'm suggesting doesn't need the originating signer to have any special knowledge. There's another, slightly labour-intensive approach (still dependent on Murray's draft-kucherawy-dkim-transform-00, and an extra "stf=" tag for subject tagging) that doesn't modify 5322.From: 1. The list keeps the original author's mailbox alone in the From header, but makes the reversible transformations described, and adds a DKIM signature with d=list.domain and tf= and stf= tags. 2. The "decorated" message is sent to list members with list-domain address as Sender. 3. Recipient validators find an Author Domain signature that fails, and a Sender Domain signature that is valid but doesn't align with the From Domain. 4. Because the Sender Domain signature is valid and contains tf= and stf= tags, Recipient validators reconstruct the original message and check it against the Author Domain DKIM signature. If it passes, the message is deemed to pass DMARC; otherwise it fails. I'm not sure if that's an improvement on the multimailbox From approach, but at least it leaves no burden for MUAs (unless they happen to be validators). MJA ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
> Are we going to say "The big four email providers pushed their problems onto >everyone else" ? Yes, of course. But as we've seen, we have little ability to push back. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
> Who knows? Perhaps Yahoo and AOL would suffer "user diaspora" if they > kept publishing p=reject and MLMs decided to be DMARC-compliant when > reinjecting messages. I see a lot of "Yahoo and AOL did this", "Yahoo and AOL don't care", "Yahoo and AOL pushed their problems onto everyone else", etc. I don't think it's useful to blame Yahoo and AOL for everything. What happens when Hotmail.com, outlook.com, and gmail.com start publishing p=reject? Are we going to say "The big four email providers pushed their problems onto everyone else" ? Then, if other big email providers in non-American markets (mail.ru, orange.fr, etc.) start doing it, are we going to say "Everyone but me pushes their problems onto the smaller providers" ? -- Terry ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On Tuesday, April 28, 2015 6:11 AM [GMT+1=CET], Stephen J. Turnbull wrote: > J. Gomez writes: > > > That would force DMARC-compliant Mediators to reject (or accept > > but not resend) incoming email from p=reject domains, > > irrespective of whether such mail passes or not the initial > > incoming DMARC checks. > > Yahoo! and AOL are bigger than MLMs. MLMs would bear the brunt of > user rage at that treatment. So do you think it is proper for an email actor to knowingly inject DMARC-rejectable messages into the public email infrastructure? Because that is exactly what mailing lists are doing when: (a) they check DMARC for incoming email (therefore, they are DMARC-aware), and (b) they then reinject into the public email infrastructure messages whose original Author's domain has declared p=reject. That case I think looks like utter disregard for a standard they know about (DMARC), in the name of convenience. If a mailing list was DMARC-agnostic, i.e. it didn't care about DMARC and didn't check it for incoming email, I would have no problem with such mailing list also disregarding DMARC when reinjecting messages. However, if a mailing list cared about DMARC when receiving, I think it SHOULD also care for DMARC when sending (and therefore NEVER reinject DMARC-rejectable messages into the public email infrastructure). > I'm quite sure that the market test will give the answer "knuckle > under", regardless of whether the majority of AOL and Yahoo! users > would prefer to keep the current MLM features or not. They don't pay > for AOL/Yahoo!/GMail/Hotmail MUA dev costs, so those providers have > very little incentive to respond positively to their requests to > support MLM features better. And, in fact, they WONTFIX them > regularly (dunno about Hotmail, but GMail is as bad as the others in > this respect). Who knows? Perhaps Yahoo and AOL would suffer "user diaspora" if they kept publishing p=reject and MLMs decided to be DMARC-compliant when reinjecting messages. Regards, J.Gomez ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
- Original Message - > From: "Scott Kitterman" > To: dmarc@ietf.org > Sent: Thursday, April 16, 2015 7:11:14 AM > Subject: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis > > Another example of a potential solution is receivers amalgamating data from > across their user base to identify forwarders and utilize a local policy > override to not reject DMARC fail messages assessed to be sent via an > indirect > mail flow. This is supported by the DMARC specification, but it's not > something > that Receiver/Small is going to be able to do. It's only really useful for > Receiver/Big. It should be included in the family of solutions, but it could > not be said to 'solve' the indirect mail flow problem since it doesn't scale > down. Was not in dmarc-interoperability, surprisingly, added ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
This is merely an attempt to find a mechanism whereby DMARC and MLMs could cooperate, up to the point where subscriber Recipient validators could honour an Author domain's p=reject, without removing the original author's mailbox from the From header. Unless I've missed something, I don't see how this solves any of the well known problems. Bad guys can do whatever lists do, so you need to know whether to trust the list, at which point you might as well just trust the list and not mess around with the headers. Also, if you want to go down the sender + list route, how about that double DKIM signing hack? It has the advantage that it's invisible to MUAs and doesn't affect reciepient MTAs beyond the DKIM validation code which probably comes from a library that Murray wrote. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On 27 Apr 2015 21:29:51 -, "John Levine" wrote: > >Even if we were all to concur that altering the From by adding the list is > >the right way forward here (an intriguing idea at the moment), ... > > Just for the record, I haven't been responding to arguments about > rewriting the From: line because I don't any way they will lead to > anything useful, and I suspect I am far from the only one. This is merely an attempt to find a mechanism whereby DMARC and MLMs could cooperate, up to the point where subscriber Recipient validators could honour an Author domain's p=reject, without removing the original author's mailbox from the From header. > But in this case, silence definitely does not mean consent. Fair enough. For my own part, I'd be happy enough to see the list mailbox stripped from the From header after validation, but I can already hear a deafening silence from people not consenting to that. MJA ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On 4/27/2015 2:44 PM, Murray S. Kucherawy wrote: So it seems to me the points of contention here are: 1) Is the MLM violation of the SHOULD NOT cited above the kind of violation that we accept based on how "SHOULD NOT" is defined in RFC2119? It seems to me that it is, especially given how long they've been doing it without objection (until now). One could argue they've been "getting away with it" for too long, but we can't change history. For the record, there was objection in DKIM-WG and in particular cited with the deployment guide and also with the requirement guide where the integration conflicts was obvious. 2) Is the MLM emitting a new message? I would agree with Michael and contend that it is if there have been any content changes at all, in the same way that someone making a compilation of a series of independent works (a "mix tape") owns the copyright on the mix, though not on the original material. Now, MLMs do that with digests already -- who else could one legitimately put in the From of a digest? -- but typically not for resent messages. Its not a new author message. It is how the MLM massages the submission for redistribute for an One to Many groupware logic. MLM is technically an Email Kludge for an electronic messaging conferencing system. It is at best a "repackaged" message. But its not a "new" message per se that would warrant any kind of idea for rewriting the Mail Infrastructure persistent and consistent "From" field. Reply-ID is already on "iffy" grounds but it was done, pointing the mail back to the list in the name of reducing unintentional direct messages in legacy MUAs with layman users doing the most naturally thing. List-ID were still not widely adopted or around the time. A Digest would be a new message -- because not one list author created it. The MLM created it. -- HLS ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On Mon, 27 Apr 2015 12:38:15 PDT, "Murray S. Kucherawy" wrote: > Even if we were all to concur that altering the From by adding the list is > the right way forward here (an intriguing idea at the moment), the question > of ordering would need to be addressed, and then how that applies to all > the standards we're talking about, and how MUAs need to be nudged to make > use of such things. We're not all going to concur, but let me chime in anyhow: The ordering of "Authors" in the From ought to be fairly easy. In any applicable case, there will be at least two DKIM-Signatures, of which one (the list's) will be valid, and the other (the original Author's) will be invalid by itself. The list's valid signature includes (e.g.) "fsf=2", indicating that the From-transformation added the second From mailbox, so that the first is the original Author's. Reconstruction the original message my reversing all reversible transformations should result in a message for which the original Author's DKIM signature is valid, confirming that the first mailbox in the "new" message is the original Author's. (Here, I'm assuming that the consensus that we won't reach would want the From order to match the temporal order of mailbox addition.) Some gentle suggestions for MUAs: 1. Display the whole 5322.From header, as well as the Sender. 2. In the absence of "Reply-To", replies should go to the first 5322.From mailbox, and reply-to-all to everybody. MJA ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On Mon, 27 Apr 2015 11:44:38 PDT, "Murray S. Kucherawy" wrote: > On Mon, Apr 27, 2015 at 4:17 AM, Michael Jack Assels < > mjass...@encs.concordia.ca> wrote: > > > On Sun, 26 Apr 2015 12:21:04 +0200, > > "J. Gomez" wrote: > > > > > On Sunday, April 26, 2015 2:25 AM [GMT+1=CET], Stephen J. Turnbull wrote: > > > > > > > The From header field is not in the public domain, and not available > > > > for appropriation. "Taking ownership" of something that isn't yours is > > > > properly called "theft" > > > > > > Is the message Subject in the public domain? Is the message Body in the > > > public domain? Why are many mailing lists taking liberties with them? > > > Sorry, but I think your analogy of email vs property does not compute. > > > > Whether any header field is in the public domain is a legal question on > > which I won't venture an opinion, but the From header stands out as one > > that is treated specially by RFC5332, section 3.6.2: > > > >[...] The "From:" field specifies the author(s) of the message, > >that is, the mailbox(es) of the person(s) or system(s) responsible > >for the writing of the message. The "Sender:" field specifies the > >mailbox of the agent responsible for the actual transmission of the > >message. For example, if a secretary were to send a message for > >another person, the mailbox of the secretary would appear in the > >"Sender:" field and the mailbox of the actual author would appear in > >the "From:" field. If the originator of the message can be indicated > >by a single mailbox and the author and transmitter are identical, the > >"Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD > >appear. > > > >[...] > > > >In all cases, the "From:" field SHOULD NOT contain any mailbox that > >does not belong to the author(s) of the message. [...] > > > > It seems clear to me that, at the very least, the mailbox of the message's > > author ought not to be and replaced by the mailbox of an automaton that > > added a subject tag and a list trailer. If the mailing list software has > > made DKIM-breaking changes, it may make sense for it to *add* its own > > mailbox to the From header (as a "coauthor"), and make itself the > > Sender. > > > > The question to me is whether the message that the MLM software emits is > the same as the original message. If it is, then the Author ought to be > preserved across the MLM. If it is not, then the MLM emits a new message, > and it actually SHOULD NOT keep the Author the same, as described above. > So we get to argue about "same", and of course the specs aren't > particularly rigorous about this. In the context I was considering -- one in which the message had been reversibly transformed as indicated in draft-kucherawy-dkim-transform-00 and reversibly transformed by adding tags "ftf=" (From TransFormed) and "stf=" (Subject TransFormed) -- the initial Author's message is entirely contained in the "new" message, and it's easily reconstructed from the "new" message. A downstream Receiver can reconstruct the original message such that the reconstructed message passes the original DKIM test and aligns as required by DMARC. By hypothesis, since the transformed message has changed enough to invalidate the original DKIM signature, the MLM has also signed the transformed message (with its mailbox appended to the 5322.From header.) Given that the message has been transformed, the question arises whether it's "the same" as the original or not. Obviously it's not strictly identical, but equally obviously (at least in the case of normal mailing list decorations) it's not significantly different; it lies somewhere in the continuum between strictly identical and significantly different. According to RFC 5322, section 3.6.4: [...] In all cases, it is the meaning that the sender of the message wishes to convey (i.e., whether this is the same message or a different message) that determines whether or not the "Message-ID:" field changes, not any particular syntactic difference that appears (or does not appear) in the message. I can't see a reading of that sentence that would require a new Message-ID on a single message as transformed automatically by an ordinary mailing list. > RFC5598's definitions, in Section 5.3 (and indirectly 5.2) say that it > doesn't change From, from which I infer it doesn't change Author, although > it does say it's a "new" message that's emitted. That document is not a > proposed standard and merely documents current use (as I understand it), so > it's merely recording the fact that MLMs technically violate the SHOULD NOT. Right, although that had already been a long-standing and widely accepted practice long before RFC5598 was published in July 2009. Adherence to the normative RFC5322 counts for more, I'd say. > So it seems to me the points of contention here are: > > 1) Is the MLM violation of the SHOULD NOT cited above
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On Tuesday, April 28, 2015 3:39 AM [GMT+1=CET], Stephen J. Turnbull wrote: > Hector Santos writes: > > On 4/26/2015 8:34 PM, Stephen J. Turnbull wrote: > > > > The problem is that all are detested by some users, and none are > > > actually liked by any user. Therefore we developers continue to > seek > > alternatives -- but all desirable alternatives require > cooperation of > > "p=reject" posting domains because of the nature > of current validation/ > > authentication protocols as > Originator-Receiver agreements. > > > The mediator has a receiver. Doesn't it have the same > > Originator-Receiver agreements? > > The effects are different. According to DMARC, a message which passes > at the Mediator, will fail at the next Receiver. That is why it would be appropriate for the DMARC spec to explicitely say that a "DMARC-compliant Operator" CANNOT accept messages from p=reject domains AND then reinject them into the public email infrastructure in any why that would make them (or reveal them to be) susceptible to fail a DMARC check performed by the next-hop Recipient. The DMARC spec should declare that if any email operator did that, he could not be termed as "DMARC-compliant". Because if any email operator does that, he is in fact polluting the global email traffic stream with non-authorized email according to the public policies declared by DMARC-compliant original Senders. So that: to be a "DMARC-compliant Operator", it would be required to be (1) DMARC-compliant when performing the role of Receiver, and also to be (2) DMARC compliant when performing the role of Sender. So that lacking (1) or (2) it would render the email operator as non compliant with DMARC. DMARC-compliant Operator == DMARC-compliant in the role of Receiver + DMARC-compliant in the role of Sender Regards, J.Gomez ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
Murray S. Kucherawy writes: > The question to me is whether the message that the MLM software emits is > the same as the original message. If it is, then the Author ought to be > preserved across the MLM. If it is not, then the MLM emits a new message, > and it actually SHOULD NOT keep the Author the same, as described above. > So we get to argue about "same", and of course the specs aren't > particularly rigorous about this. > > RFC5598's definitions, in Section 5.3 (and indirectly 5.2) say that it > doesn't change From, from which I infer it doesn't change Author, although > it does say it's a "new" message that's emitted. That document is not a > proposed standard and merely documents current use (as I understand it), so > it's merely recording the fact that MLMs technically violate the SHOULD NOT. AFAICS the "new message" referred to there is from the point of view of the SMTP protocol, not the higher level of RFC 5322. In particular, RFC 5322 says that it the message is a "new message" at this level, Message-Id should change too. That would clearly screw up list traffic processing for many users. RFC 5598 itself says: In addition to sending the new message to a potentially large number of new Recipients, the Mailing List can modify content, for example, by deleting attachments, converting the format, and adding list-specific comments. Mailing Lists also archive messages posted by Authors. Still the message retains characteristics of being from the original Author. In particular, RFC5322.From: Set by - original Author Names and email addresses for the original Author of the message content are retained. > > So it seems to me the points of contention here are: > > 1) Is the MLM violation of the SHOULD NOT cited above the kind of violation > that we accept based on how "SHOULD NOT" is defined in RFC2119? It's not a violation IMO. See below. > 2) Is the MLM emitting a new message? I would agree with Michael See the discussion in RFC 5322 about when a new Message-Id should be assigned. Specifically, from sec. 3.6.4: In all cases, it is the meaning that the sender of the message wishes to convey (i.e., whether this is the same message or a different message) that determines whether or not the "Message-ID:" field changes, not any particular syntactic difference that appears (or does not appear) in the message. Here, sender refers to the MLM, and in most cases (not all!) the MLM intends that the distributed message be considered the same as the received message. Further more, human recipients rarely have any trouble distinguishing the MLM decorations and extracting the original message. MLMs which delete MIME parts and translate HTML to plain text are another matter, but even there I believe that both senders and recipients agree that it is the "same message". If (human) sender and recipient agree on this, I see *zero space* for the interpretation that it's a new message, unless you deprecate RFC 5322 at the same time. As I wrote elsewhere, the only people who ever claim that list messages as distributed are new messages in the sense of RFC 5322, sec. 3.6.4, are non-participants in almost all of the mailing lists on which they want to impose this interpretation. > and contend that it is if there have been any content changes at > all, in the same way that someone making a compilation of a series > of independent works (a "mix tape") owns the copyright on the mix, > though not on the original material. Now, MLMs do that with > digests already -- who else could one legitimately put in the From > of a digest? -- but typically not for resent messages. As long as you mention copyright, it's likely that the material typically appended by MLMs is not copyrightable, it's mostly determined by the MLM's interface (eg, unsubscription and archive URLs), and the rest is hardly an original work of expression. So the copyright analogy says there is no ground for claiming the MLM is an author. Not even in the case of deletion or transformation of MIME parts -- when automated, these are also not "expressive works". > Might it be sufficient to declare an "Original-Message-ID" or > "Author-Message-ID" or "List-Original-Message-ID" field that > contains the author-generated Message-ID, allowing for the > duplicate suppression that's done now? It's not just duplicate suppression, it's also threading, because some people have mixed sources for messages in the thread. That screws all existing MUAs in processing dupes and threading messages when some are received via and some off- list. Even once they are taught recognize Original-Message-ID, the threading algorithm will become *much* more complex. Somebody, perhaps this WG or more likely an appropriate WG with input from us, just needs to decide this issue one way or the other. If it's decided that MLM decorations create "new messages", and th
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
J. Gomez writes: > That would force DMARC-compliant Mediators to reject (or accept > but not resend) incoming email from p=reject domains, > irrespective of whether such mail passes or not the initial > incoming DMARC checks. Yahoo! and AOL are bigger than MLMs. MLMs would bear the brunt of user rage at that treatment. Really. We now have a couple of decades of experience. The big mailbox providers have our subscribers by the short hairs -- their Internet reputations are intimately tied to those email addresses. If the big provider won't change (and historically they've followed the principle of throw the garbage in their neighbor's yard and protest innocence loudly when users question them), then the subscriber/poster screams at the list owner. They're typically much less attached to their ML subscriptions than to their email addresses, and list owners tend to be much more responsive to their subscribers than big mailbox providers are. We have to jump through their hoops, or at least our list owner constituency thinks they do. I'm an economist even before I'm an MLM developer, I'm willing to go with the market if there is no market failure. But here there is a failure: email address lock-in. On many lists, the AOL and Yahoo! users are a small minority. If "customer is always right" considerations mandate catering to their mailbox providers' DMARC policies, the great majority loses MLM features they value -- but they are unlikely to kick up a corresponding fuss. I'm quite sure that the market test will give the answer "knuckle under", regardless of whether the majority of AOL and Yahoo! users would prefer to keep the current MLM features or not. They don't pay for AOL/Yahoo!/GMail/Hotmail MUA dev costs, so those providers have very little incentive to respond positively to their requests to support MLM features better. And, in fact, they WONTFIX them regularly (dunno about Hotmail, but GMail is as bad as the others in this respect). ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On Apr 27, 2015, at 2:29 PM, John Levine wrote: >> Even if we were all to concur that altering the From by adding the list is >> the right way forward here (an intriguing idea at the moment), ... > > Just for the record, I haven't been responding to arguments about > rewriting the From: line because I don't any way they will lead to > anything useful, and I suspect I am far from the only one. > > But in this case, silence definitely does not mean consent. +1. Cheers, Steve ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
Hector Santos writes: > On 4/26/2015 8:34 PM, Stephen J. Turnbull wrote: > > The problem is that all are detested by some users, and none are > > actually liked by any user. Therefore we developers continue to seek > > alternatives -- but all desirable alternatives require cooperation of > > "p=reject" posting domains because of the nature of current validation/ > > authentication protocols as Originator-Receiver agreements. > > The mediator has a receiver. Doesn't it have the same > Originator-Receiver agreements? The effects are different. According to DMARC, a message which passes at the Mediator, will fail at the next Receiver. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On 4/27/2015 6:20 PM, Scott Kitterman wrote: Lets not lump "mailing list" into the same kind or group of MLM operations. I care. I have a product to market.As a side note, there is a legal argument to make when a MLM has intentionally ignored a security protocol designed to protect a domain and end-users. Claims of MalPractice and Intentional Neglect can easily be made. There is most certainly, product liability issues. Can't have it both ways. I'm not aware of any cases where someone was successfully sued for not implementing something that's optional. Reread what I said. There is most certainly product liability concerns. You don't have to wait until a lawsuit occurs to know what is the ethical, common sense engineering thing to do that will minimize both technical and legal contention. The dilemma with this is the same as it was ADSP -- the MLM receiver can not skip a DKIM policy protocol and also do resigning. With a 3rd authorization scheme in place, the MLM SHOULD only work on the relaxed policies. The point is not what the MLM does, but what the MLM RECEIVER does. It MUST also be a DMARC compliant system too as a protocol design presumption. So as I always said, the first rule of thumb is to follow the honor protocol first. And if that doesn't make sense, then its broken. DMARC is an incomplete protocol until it offers support for ADID != SDID conditions whether its deemed feasible or not by some. As a mail receiver, they can accept or reject mail based on DMARC policies and be compliant as a receiver. That helps not at all when the mediator later modifies the message so a DKIM signature breaks. If the policy is relaxed, then it doesn't matter. DMARC may be incomplete, but it's sufficiently complete for large scale deployment. Dimensional Analysis -- what works for the smallest dimension will in theory work at any dimension. Anyway, we have been saying that since day one -- DKIM POLICY highest benefit is the direct 1st party signature polices and that satisfies MOST domains. But we still have the indirect problem because both ADSP and DMARC lacks the ADID != SDID protocol semantics. ADSP punted on it. DMARC tries to punt on it and we should not be surprise we are finding they can't. If they want to punt on it, then they MUST honor the restrictive policies at the MLM receiver, at the entry point. That is all the point was. -- HLS ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On Monday, April 27, 2015 06:11:57 PM Hector Santos wrote: > On 4/27/2015 5:51 PM, Scott Kitterman wrote: > >> What? There is an spec for DMARC. With the current DMARC specification, > >> anyone can do almost anything and still claim to be DMARC-compliant. What > >> about if to claim being DMARC-compliant, Receivers could not reinject > >> alien > >> messages into the email infrastructure if the original Sender is > >> publishing > >> p=reject and said reinjected messages would fail a DMARC check when > >> performed by its ultimate Recipient(s)? > > > > Why would a mailing list care to claim spec conformance? > > > > All they care about is getting the mail delivered, managing subscriber > > lists, etc. Since there are no internet police, can not doesn't mean > > anything. > Lets not lump "mailing list" into the same kind or group of MLM > operations. I care. I have a product to market.As a side note, > there is a legal argument to make when a MLM has intentionally ignored > a security protocol designed to protect a domain and end-users. > Claims of MalPractice and Intentional Neglect can easily be made. > There is most certainly, product liability issues. Can't have it both > ways. I'm not aware of any cases where someone was successfully sued for not implementing something that's optional. > The point is not what the MLM does, but what the MLM RECEIVER does. > It MUST also be a DMARC compliant system too as a protocol design > presumption. > > So as I always said, the first rule of thumb is to follow the honor > protocol first. And if that doesn't make sense, then its broken. > DMARC is an incomplete protocol until it offers support for ADID != > SDID conditions whether its deemed feasible or not by some. As a mail receiver, they can accept or reject mail based on DMARC policies and be compliant as a receiver. That helps not at all when the mediator later modifies the message so a DKIM signature breaks. DMARC may be incomplete, but it's sufficiently complete for large scale deployment. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On 4/27/2015 5:51 PM, Scott Kitterman wrote: What? There is an spec for DMARC. With the current DMARC specification, anyone can do almost anything and still claim to be DMARC-compliant. What about if to claim being DMARC-compliant, Receivers could not reinject alien messages into the email infrastructure if the original Sender is publishing p=reject and said reinjected messages would fail a DMARC check when performed by its ultimate Recipient(s)? Why would a mailing list care to claim spec conformance? All they care about is getting the mail delivered, managing subscriber lists, etc. Since there are no internet police, can not doesn't mean anything. Lets not lump "mailing list" into the same kind or group of MLM operations. I care. I have a product to market.As a side note, there is a legal argument to make when a MLM has intentionally ignored a security protocol designed to protect a domain and end-users. Claims of MalPractice and Intentional Neglect can easily be made. There is most certainly, product liability issues. Can't have it both ways. The point is not what the MLM does, but what the MLM RECEIVER does. It MUST also be a DMARC compliant system too as a protocol design presumption. So as I always said, the first rule of thumb is to follow the honor protocol first. And if that doesn't make sense, then its broken. DMARC is an incomplete protocol until it offers support for ADID != SDID conditions whether its deemed feasible or not by some. -- HLS ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On 4/27/2015 4:23 PM, J. Gomez wrote: Smooth operation? Mediators don't really need to change, but their entry points need to support DKIM+POLICY. For example, the Mediator receiver can simply support honoring restrictive policies and it doesn't need to bother with much else. That is interesting. Couldn't the DMARC specification spell out that Receivers claiming to be DMARC-compliant, when choosing to *accept* incoming messages from Senders publishing p=reject (irrespective of whether such accepted messages passed or not the DMARC checks), CANNOT after-the-fact reinject such received messages into the public email infrastructure in any way that could render them (or reveal them to be) DMARC-rejectable? Yes. To be protocol Z-ORDER correct, yes. So that if any Receiver-turned-Originator (i.e., Mediator) does otherwise, they CANNOT claim to be DMARC-compliant? It would be violation of he protocol engine -- causing potential grief. That would force DMARC-compliant Mediators to reject (or accept but not resend) incoming email from p=reject domains, irrespective of whether such mail passes or not the initial incoming DMARC checks. As DMARC is written yes, this is why we need the 3rd party authorization. It is incomplete otherwise. Then, if the market deems DMARC valuable by itself, pressure would be applied by the "invisible hand" there were it needs to be applied (so that reputable actors in the email ecosystem could claim to be DMARC-compatible). Can't have it both ways. If a MLM has resigning and touching based with DKIM, it needs to filter the unauthorized DMARC mail at the MLM receiver just like their is a presumption the distribution end-user MDA receivers will also apply DMARC. -- HLS ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On Mon, Apr 27, 2015 at 2:37 PM, J. Gomez wrote: > Apart from the CANNOT bit, is that different from where we are today? > > Well, the CANNOT part would impede the whole lot of problems we are trying > to solve, wouldn't it so? > Maybe. I was just confirming that that's the only part that's different in your proposal. I think there's a concern with this approach though. I don't believe we can just come up with something new on the standards track and then go hit operators over the head with it telling them they're non-compliant. That tends not to be well-received, to put it lightly. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On Monday, April 27, 2015 11:33:50 PM J. Gomez wrote: > On Monday, April 27, 2015 11:25 PM [GMT+1=CET], John Levine wrote: > > > Couldn't the DMARC specification spell out that Receivers claiming > > > to be DMARC-compliant, when choosing to *accept* incoming messages > > > from Senders publishing p=reject (irrespective of whether such > > > accepted messages passed or not the DMARC checks), CANNOT > > > after-the-fact reinject such received messages into the public > > > email infrastructure in any way that could render them (or reveal > > > them to be) DMARC-rejectable? > > > > Since there is no spec for "Receivers claiming to be DMARC-compliant" > > and there never will be, of course not. > > What? There is an spec for DMARC. With the current DMARC specification, > anyone can do almost anything and still claim to be DMARC-compliant. What > about if to claim being DMARC-compliant, Receivers could not reinject alien > messages into the email infrastructure if the original Sender is publishing > p=reject and said reinjected messages would fail a DMARC check when > performed by its ultimate Recipient(s)? Why would a mailing list care to claim spec conformance? All they care about is getting the mail delivered, managing subscriber lists, etc. Since there are no internet police, can not doesn't mean anything. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
Original Message From: Murray S. Kucherawy On Mon, Apr 27, 2015 at 1:23 PM, J. Gomez wrote: Couldn't the DMARC specification spell out that Receivers claiming to be DMARC-compliant, when choosing to *accept* incoming messages from Senders publishing p=reject (irrespective of whether such accepted messages passed or not the DMARC checks), CANNOT after-the-fact reinject such received messages into the public email infrastructure in any way that could render them (or reveal them to be) DMARC-rejectable? So that if any Receiver-turned-Originator (i.e., Mediator) does otherwise, they CANNOT claim to be DMARC-compliant? That would force DMARC-compliant Mediators to reject (or accept but not resend) incoming email from p=reject domains, irrespective of whether such mail passes or not the initial incoming DMARC checks. Then, if the market deems DMARC valuable by itself, pressure would be applied by the "invisible hand" there were it needs to be applied (so that reputable actors in the email ecosystem could claim to be DMARC-compatible). Apart from the CANNOT bit, is that different from where we are today? Well, the CANNOT part would impede the whole lot of problems we are trying to solve, wouldn't it so? Regards, J.Gomez ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On Monday, April 27, 2015 11:25 PM [GMT+1=CET], John Levine wrote: > > Couldn't the DMARC specification spell out that Receivers claiming > > to be DMARC-compliant, when choosing to *accept* incoming messages > > from Senders publishing p=reject (irrespective of whether such > > accepted messages passed or not the DMARC checks), CANNOT > > after-the-fact reinject such received messages into the public > > email infrastructure in any way that could render them (or reveal > > them to be) DMARC-rejectable? > > Since there is no spec for "Receivers claiming to be DMARC-compliant" > and there never will be, of course not. What? There is an spec for DMARC. With the current DMARC specification, anyone can do almost anything and still claim to be DMARC-compliant. What about if to claim being DMARC-compliant, Receivers could not reinject alien messages into the email infrastructure if the original Sender is publishing p=reject and said reinjected messages would fail a DMARC check when performed by its ultimate Recipient(s)? Regards, J.Gomez ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
>Even if we were all to concur that altering the From by adding the list is >the right way forward here (an intriguing idea at the moment), ... Just for the record, I haven't been responding to arguments about rewriting the From: line because I don't any way they will lead to anything useful, and I suspect I am far from the only one. But in this case, silence definitely does not mean consent. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
>Couldn't the DMARC specification spell out that Receivers claiming to be >DMARC-compliant, when choosing to *accept* incoming messages from Senders >publishing p=reject (irrespective of whether such accepted messages passed >or not the DMARC checks), CANNOT after-the-fact reinject such received >messages into the public email infrastructure in any way that could render >them (or reveal them to be) DMARC-rejectable? Since there is no spec for "Receivers claiming to be DMARC-compliant" and there never will be, of course not. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On Mon, Apr 27, 2015 at 1:23 PM, J. Gomez wrote: > Couldn't the DMARC specification spell out that Receivers claiming to be > DMARC-compliant, when choosing to *accept* incoming messages from Senders > publishing p=reject (irrespective of whether such accepted messages passed > or not the DMARC checks), CANNOT after-the-fact reinject such received > messages into the public email infrastructure in any way that could render > them (or reveal them to be) DMARC-rejectable? > > So that if any Receiver-turned-Originator (i.e., Mediator) does otherwise, > they CANNOT claim to be DMARC-compliant? > > That would force DMARC-compliant Mediators to reject (or accept but not > resend) incoming email from p=reject domains, irrespective of whether such > mail passes or not the initial incoming DMARC checks. > > Then, if the market deems DMARC valuable by itself, pressure would be > applied by the "invisible hand" there were it needs to be applied (so that > reputable actors in the email ecosystem could claim to be DMARC-compatible). > Apart from the CANNOT bit, is that different from where we are today? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On Monday, April 27, 2015 7:09 AM [GMT+1=CET], Hector Santos wrote: > On 4/25/2015 6:24 AM, Rolf E. Sonneveld wrote: > > > > > > I'd like to note that it is the presence/existance of actor > > > "Mediator" which induces the DMARC compatibility problems with > > > indirect flows. > > > > > > I.e., if you supress the Mediator, all is fine and dandy. That > > > fact should at leat put some pressure on Mediator regarding the > > > searching for a solution, and should induce Mediator to > > > acknowledge that he will have to assume certain costs for such a > > > solution. > > > > > > I see Originator already assuming costs: deploying SPF in DNS and > > > keeping it current, deploying DKIM records and DKIM-signing > > > outgoing email, deploying DMARC records and being vigilant > > > regarding Header-From alignment in his outgoing email, etc. > > > > > > And I see Receiver already assuming costs: setting up systems to > > > check SPF, DKIM and DMARC for incoming email, dealing with the > > > support costs of false positives and phised users, sending out > > > DMARC reports, etc. > > > > > > What costs are Mediators currently taking to improve > > > validation/authentication of the email system as a whole? > > > > and what benefits do they get in return? > > Smooth operation? > > Mediators don't really need to change, but their entry points need to > support DKIM+POLICY. For example, the Mediator receiver can simply > support honoring restrictive policies and it doesn't need to bother > with much else. That is interesting. Couldn't the DMARC specification spell out that Receivers claiming to be DMARC-compliant, when choosing to *accept* incoming messages from Senders publishing p=reject (irrespective of whether such accepted messages passed or not the DMARC checks), CANNOT after-the-fact reinject such received messages into the public email infrastructure in any way that could render them (or reveal them to be) DMARC-rejectable? So that if any Receiver-turned-Originator (i.e., Mediator) does otherwise, they CANNOT claim to be DMARC-compliant? That would force DMARC-compliant Mediators to reject (or accept but not resend) incoming email from p=reject domains, irrespective of whether such mail passes or not the initial incoming DMARC checks. Then, if the market deems DMARC valuable by itself, pressure would be applied by the "invisible hand" there were it needs to be applied (so that reputable actors in the email ecosystem could claim to be DMARC-compatible). Regards, J.Gomez ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On Mon, Apr 27, 2015 at 12:27 PM, J. Gomez wrote: > > The question to me is whether the message that the MLM software emits > > is the same as the original message. If it is, then the Author ought > > to be preserved across the MLM. If it is not, then the MLM emits a > > new message, and it actually SHOULD NOT keep the Author the same, as > > described above. So we get to argue about "same", and of course the > > specs aren't particularly rigorous about this. > > > > RFC5598's definitions, in Section 5.3 (and indirectly 5.2) say that > > it doesn't change From, from which I infer it doesn't change Author, > > although it does say it's a "new" message that's emitted. > > It seems RFC5598 says 3 things: > > 1. That the Author and only the Author goes in the Header-From. Period. > 2. That mailing lists keep the "original Author" (sic) in the Header-From. > 3. That mailing lists also become an Author when they retransmit a message > (Section 5.3: "Because a Mailing List can modify the content of a message > in any way, it is responsible for that content; that is, it is an > Author."). > > I see point 1 as normative, point 3 as an arrived conclusion (logical > deduction) and therefore also normative as long as it is logically valid, > and point 2 as documenting customary practice at the time that document was > written. > > So it seems, as per RFC5598, that a message mediated by a mailing list > which alters its content has, at least, to Authors: the "original Author", > and the mailing list itself. > Keep in mind that RFC5598 is Informational. It doesn't prescribe or proscribe anything. It just describes the "current" (at the time) email architecture. RFC5322 and its ilk are Standards track, and thus normative. Even if we were all to concur that altering the From by adding the list is the right way forward here (an intriguing idea at the moment), the question of ordering would need to be addressed, and then how that applies to all the standards we're talking about, and how MUAs need to be nudged to make use of such things. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
Original Message from: Murray S. Kucherawy > The question to me is whether the message that the MLM software emits > is the same as the original message. If it is, then the Author ought > to be preserved across the MLM. If it is not, then the MLM emits a > new message, and it actually SHOULD NOT keep the Author the same, as > described above. So we get to argue about "same", and of course the > specs aren't particularly rigorous about this. > > RFC5598's definitions, in Section 5.3 (and indirectly 5.2) say that > it doesn't change From, from which I infer it doesn't change Author, > although it does say it's a "new" message that's emitted. It seems RFC5598 says 3 things: 1. That the Author and only the Author goes in the Header-From. Period. 2. That mailing lists keep the "original Author" (sic) in the Header-From. 3. That mailing lists also become an Author when they retransmit a message (Section 5.3: "Because a Mailing List can modify the content of a message in any way, it is responsible for that content; that is, it is an Author."). I see point 1 as normative, point 3 as an arrived conclusion (logical deduction) and therefore also normative as long as it is logically valid, and point 2 as documenting customary practice at the time that document was written. So it seems, as per RFC5598, that a message mediated by a mailing list which alters its content has, at least, to Authors: the "original Author", and the mailing list itself. Hmm, I see several ways to go from here. Regards, J.Gomez ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On Monday, April 27, 2015 2:34 AM [GMT+1=CET], Stephen J. Turnbull wrote: > > Well, I don't "attack" anyone, I express my opinion about what I > > think would be the easiest and lest painful --considering the email > > system as a whole-- solution to the problem. > > It's already available, and already used when the actual participants > in a mediated channel so prefer. Your expression of opinion therefore > is useless I am sorry my opinion is useless to you. It does not intent to have an utility per se, but to express my point of view as an actor in the email system. > > I also feel I am advocating my users's best interests. I am not mad > > at you, don't be mad at me. :-) > > Why is it in *your* users' interests to tell *me* how to run my lists? > That's what I perceive as an attack, since I see no good reason. You asked "What else do you propose that we do?". I obliged. Again, I am sorry you didn't like it. Regards, J.Gomez ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On Mon, Apr 27, 2015 at 4:17 AM, Michael Jack Assels < mjass...@encs.concordia.ca> wrote: > On Sun, 26 Apr 2015 12:21:04 +0200, > "J. Gomez" wrote: > > > On Sunday, April 26, 2015 2:25 AM [GMT+1=CET], Stephen J. Turnbull wrote: > > > > > The From header field is not in the public domain, and not available > > > for appropriation. "Taking ownership" of something that isn't yours is > > > properly called "theft" > > > > Is the message Subject in the public domain? Is the message Body in the > > public domain? Why are many mailing lists taking liberties with them? > > Sorry, but I think your analogy of email vs property does not compute. > > Whether any header field is in the public domain is a legal question on > which I won't venture an opinion, but the From header stands out as one > that is treated specially by RFC5332, section 3.6.2: > >[...] The "From:" field specifies the author(s) of the message, >that is, the mailbox(es) of the person(s) or system(s) responsible >for the writing of the message. The "Sender:" field specifies the >mailbox of the agent responsible for the actual transmission of the >message. For example, if a secretary were to send a message for >another person, the mailbox of the secretary would appear in the >"Sender:" field and the mailbox of the actual author would appear in >the "From:" field. If the originator of the message can be indicated >by a single mailbox and the author and transmitter are identical, the >"Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD >appear. > >[...] > >In all cases, the "From:" field SHOULD NOT contain any mailbox that >does not belong to the author(s) of the message. [...] > > It seems clear to me that, at the very least, the mailbox of the message's > author ought not to be and replaced by the mailbox of an automaton that > added a subject tag and a list trailer. If the mailing list software has > made DKIM-breaking changes, it may make sense for it to *add* its own > mailbox to the From header (as a "coauthor"), and make itself the > Sender. > The question to me is whether the message that the MLM software emits is the same as the original message. If it is, then the Author ought to be preserved across the MLM. If it is not, then the MLM emits a new message, and it actually SHOULD NOT keep the Author the same, as described above. So we get to argue about "same", and of course the specs aren't particularly rigorous about this. RFC5598's definitions, in Section 5.3 (and indirectly 5.2) say that it doesn't change From, from which I infer it doesn't change Author, although it does say it's a "new" message that's emitted. That document is not a proposed standard and merely documents current use (as I understand it), so it's merely recording the fact that MLMs technically violate the SHOULD NOT. So it seems to me the points of contention here are: 1) Is the MLM violation of the SHOULD NOT cited above the kind of violation that we accept based on how "SHOULD NOT" is defined in RFC2119? It seems to me that it is, especially given how long they've been doing it without objection (until now). One could argue they've been "getting away with it" for too long, but we can't change history. 2) Is the MLM emitting a new message? I would agree with Michael and contend that it is if there have been any content changes at all, in the same way that someone making a compilation of a series of independent works (a "mix tape") owns the copyright on the mix, though not on the original material. Now, MLMs do that with digests already -- who else could one legitimately put in the From of a digest? -- but typically not for resent messages. To the point of Message-IDs, I would say that should follow the same rule as the From change: If the content changes, it's a new message, and it gets a new Message-ID. Might it be sufficient to declare an "Original-Message-ID" or "Author-Message-ID" or "List-Original-Message-ID" field that contains the author-generated Message-ID, allowing for the duplicate suppression that's done now? If MUAs do unpredictable things with multimailbox From headers, it > may be because they don't see them often enough. I'm sure they'll fix > their errors if list mail begins to arrive with heretofore unusual but > RFC5322-compliant headers. > I would far rather have MUA developers work with us directly, but the IETF has a persistent allergy to us tampering in user space. As I understand it, our desire in general tends to be to create well-defined interfaces (not APIs, mind you) at which MUAs can "meet" us on their own, and let them take it from there. Thus, the best we can do is be very clear about what information is presented by a multi-From message and perhaps why, and hope they'll adapt. The sad legacy is that different mail operators have historically done different things, which has led to MUAs doing different things, which has in turn led to a global sy
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On Mon, 27 Apr 2015 07:17:05 EDT, Michael Jack Assels wrote: > [...] > From: "Need enhancement? See http://bad-example.com"; > , > Sender: > DKIM-Signature: [...]i=bad-example.com[...] > DKIM-Signature: [...]i=example.org[...] > [...] Sigh. All instances of "i=" were intended to be "d=", passim. MJA ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On 4/26/2015 8:34 PM, Stephen J. Turnbull wrote: GNU Mailman, for example, provides several DMARC mitigations. The traditionally available "just forward" configuration is still available, but disliked strongly because users really like have unsubscribe and archive links in the footer. The "steal authorship" option is available since Oct 2013 (6 months before the April Fiasco). Encapsulation of the decorated message in a message/rfc822 MIME part was provided later in 2013 IIRC. The problem is that all are detested by some users, and none are actually liked by any user. Therefore we developers continue to seek alternatives -- but all desirable alternatives require cooperation of "p=reject" posting domains because of the nature of current validation/ authentication protocols as Originator-Receiver agreements. The mediator has a receiver. Doesn't it have the same Originator-Receiver agreements? -- HLS ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On Sun, 26 Apr 2015 12:21:04 +0200, "J. Gomez" wrote: > On Sunday, April 26, 2015 2:25 AM [GMT+1=CET], Stephen J. Turnbull wrote: > > > The From header field is not in the public domain, and not available > > for appropriation. "Taking ownership" of something that isn't yours is > > properly called "theft" > > Is the message Subject in the public domain? Is the message Body in the > public domain? Why are many mailing lists taking liberties with them? > Sorry, but I think your analogy of email vs property does not compute. Whether any header field is in the public domain is a legal question on which I won't venture an opinion, but the From header stands out as one that is treated specially by RFC5332, section 3.6.2: [...] The "From:" field specifies the author(s) of the message, that is, the mailbox(es) of the person(s) or system(s) responsible for the writing of the message. The "Sender:" field specifies the mailbox of the agent responsible for the actual transmission of the message. For example, if a secretary were to send a message for another person, the mailbox of the secretary would appear in the "Sender:" field and the mailbox of the actual author would appear in the "From:" field. If the originator of the message can be indicated by a single mailbox and the author and transmitter are identical, the "Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD appear. [...] In all cases, the "From:" field SHOULD NOT contain any mailbox that does not belong to the author(s) of the message. [...] It seems clear to me that, at the very least, the mailbox of the message's author ought not to be and replaced by the mailbox of an automaton that added a subject tag and a list trailer. If the mailing list software has made DKIM-breaking changes, it may make sense for it to *add* its own mailbox to the From header (as a "coauthor"), and make itself the Sender. MUAs may have widely varying methods of dealing with multiple mailbox From headers, but in my experience, MTAs have no trouble with them, and they're generally the ones handling DMARC issues. RFC7489 has this to say (in Section 6.6.1) about multiple-mailbox From headers: o Messages bearing a single RFC5322.From field containing multiple addresses (and, thus, multiple domain names to be evaluated) are typically rejected because the sorts of mail normally protected by DMARC do not use this format; [...] The case of a syntactically valid multi-valued RFC5322.From field presents a particular challenge. The process in this case is to apply the DMARC check using each of those domains found in the RFC5322.From field as the Author Domain and apply the most strict policy selected among the checks that fail. The first paragraph seems to imply that DMARC admits the validity of a multimailbox From field, but simply doesn't plan to support it. The second paragraph makes clear how the nonsupport is to be accomplished. I understand that a ne'er-do-well might craft a spammy message with From: "Need enhancement? See http://bad-example.com"; , Sender: DKIM-Signature: [...]i=bad-example.com[...] DKIM-Signature: [...]i=example.org[...] among the headers; hence the second quoted paragraph of RFC7489 above. However, given an opportunity by DKIM, e.g., implementing Murray's draft-kucherawy-dkim-transform-00, with some extra detail to accommodate reversible From and Subject transformations, a mailing list could fairly easily get away with something like From: , Sender: Subject: [list] Original subject DKIM-Signature: [...]i=example.com; ftf=2; stf=[list]; [...] DKIM-Signature: [...]i=example.org[...] where "ftf=2" means "the second mailbox in the From header was added", and "stf=[list]" means "the tag '[list]' in the Subject header was added. Both transformations are easily reversed. MTAs implementing draft-kucherawy-dkim-transform-00 supplemented with ftf and stf transformations should be able to reconstruct the original message and verify its DKIM-Signature. This adds plenty of work for Mediators -- possibly more than they can handle if the MLM has no direct access to DKIM -- and only a little extra for Receivers. RFC 7489's paragraph dealing with multimailbox From headers would have to be change to something like The case of a syntactically valid multi-valued RFC5322.From field presents a particular challenge. The process in this case is to apply the DMARC check using each of those domains found in the RFC5322.From field as the Author Domain and apply the most strict policy selected among the checks that fail. However, if one DKIM-Signature fails on its own but passes under the reversal of transformations specified by another passing DKIM-Signature, then the first DKIM-Signature is deemed to have passed. > I think that point was settled as "it is debatable"
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On 4/25/2015 6:24 AM, Rolf E. Sonneveld wrote: I'd like to note that it is the presence/existance of actor "Mediator" which induces the DMARC compatibility problems with indirect flows. I.e., if you supress the Mediator, all is fine and dandy. That fact should at leat put some pressure on Mediator regarding the searching for a solution, and should induce Mediator to acknowledge that he will have to assume certain costs for such a solution. I see Originator already assuming costs: deploying SPF in DNS and keeping it current, deploying DKIM records and DKIM-signing outgoing email, deploying DMARC records and being vigilant regarding Header-From alignment in his outgoing email, etc. And I see Receiver already assuming costs: setting up systems to check SPF, DKIM and DMARC for incoming email, dealing with the support costs of false positives and phised users, sending out DMARC reports, etc. What costs are Mediators currently taking to improve validation/authentication of the email system as a whole? and what benefits do they get in return? Smooth operation? Mediators don't really need to change, but their entry points need to support DKIM+POLICY. For example, the Mediator receiver can simply support honoring restrictive policies and it doesn't need to bother with much else. -- HLS ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On Apr 26, 2015, at 5:34 PM, Stephen J. Turnbull wrote: > > That's possible, but really, only yahoo.com and aol.com matter. No > Yahoo! or AOL affiliate that I've checked other than those two > publishes p=reject or even p=quarantine, and in fact I've never seen > p=reject on a domain that posts to a mailing list other than those two. > > It's true that a great majority of mail is sent from domains that > participate in the DMARC protocol, and many of them publish p=reject. > But IME only yahoo.com and aol.com cause problems for mailing lists. > he others either don't post to lists or don't publish p=reject. They're the vast majority of breakage today, for sure. There's also linkedin.com and one or two other corporates that use the same domain for both their bulk mail and some of their employee mail. And libero.it went to p=quarantine last month, which will also break mailing list interaction, though with less damage to bystanders than p=reject. Cheers, Steve ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
J. Gomez writes: > Is the message Subject in the public domain? Is the message Body in > the public domain? Why are many mailing lists taking liberties with > them? Our interpretation is that no liberties are being taken: we have tacit permission from the authors. I've *never* seen an author object to those changes. The only people who interpret them as not consonant with the authors' wishes are spamfighters like you who aren't even subscribed to the lists whose policy they advocate changing. On the other hand, authors (and recipients) do object to lists falsely claiming authorship of posts, for several reasons. The cases are quite different in the minds of the users. Ask yours; you find the same, I'm sure. > Sorry, but I think your analogy of email vs property does not > compute. "Taking ownership" is your term, not mine. I simply pointed out that it has pretty wretched connotations of theft, forgery, and fraud. > That field contains the Author, and if the Author signed with DKIM > and the mediated message breaks that signature, it can then be > argued that Authorship has suffered and therefore that the From: > Header should reflect that fact. Anything can be argued. But I've never seen a *subscriber* ask for this change, except when directed to do so by the "customer placation" department at their provider. I conclude that "cure worse than the disease" spamfighters are the only advocates of this interpretation. > What changes have happened to the role of Mediator, to improve > validation/authentication of the email system as a whole? None that > I see, yet. You won't, because there are none possible. Currently, validation/ authentication is a protocol agreed between the originator and the recipient, and as currently formulated, it is the originator's option to deprecate *all* mediation unilaterally by signing the whole message -- and that's the common practice. Further, originators can use the DMARC protocol to *forbid* mediation by signing the whole message and publishing p=reject, again unilaterally. Several attempts to devise ways for Mediators to participate in these protocols are in the internet-draft stage, but all have strong detractors. And of course one option (of abstaining from mediation) is as old as mailing lists -- the earliest MLMs were simple exploders -- and is still availabie at the list owner's option. > Well, I don't "attack" anyone, I express my opinion about what I > think would be the easiest and lest painful --considering the email > system as a whole-- solution to the problem. It's already available, and already used when the actual participants in a mediated channel so prefer. Your expression of opinion therefore is useless -- *you* can already do what you claim is best on your own lists, and at least the MLM product I help develop provides the option, but experience shows that many subscribers and owners strongly dislike it and very few favor it. > I think we should get past the Yahoos and the AOLs. They pioneered > the misue of DMARC, but that misuse is here to stay and will > certainly grow, That's possible, but really, only yahoo.com and aol.com matter. No Yahoo! or AOL affiliate that I've checked other than those two publishes p=reject or even p=quarantine, and in fact I've never seen p=reject on a domain that posts to a mailing list other than those two. It's true that a great majority of mail is sent from domains that participate in the DMARC protocol, and many of them publish p=reject. But IME only yahoo.com and aol.com cause problems for mailing lists. he others either don't post to lists or don't publish p=reject. > problem space is now bigger than just Yahoo and AOL. Name some other domains whose actual interaction with Mediators is problematic. > I also feel I am advocating my users's best interests. I am not mad > at you, don't be mad at me. :-) Why is it in *your* users' interests to tell *me* how to run my lists? That's what I perceive as an attack, since I see no good reason. GNU Mailman, for example, provides several DMARC mitigations. The traditionally available "just forward" configuration is still available, but disliked strongly because users really like have unsubscribe and archive links in the footer. The "steal authorship" option is available since Oct 2013 (6 months before the April Fiasco). Encapsulation of the decorated message in a message/rfc822 MIME part was provided later in 2013 IIRC. The problem is that all are detested by some users, and none are actually liked by any user. Therefore we developers continue to seek alternatives -- but all desirable alternatives require cooperation of "p=reject" posting domains because of the nature of current validation/ authentication protocols as Originator-Receiver agreements. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On Sunday, April 26, 2015 2:25 AM [GMT+1=CET], Stephen J. Turnbull wrote: > J. Gomez writes: > > > > What else do you propose that we do? > > > > Well, if you ask... Mediators could take ownership of the > > Header-From whenever their involvement results in the Originator's > > DKIM signature being invalidated. > > The From header field is not in the public domain, and not available > for appropriation. "Taking ownership" of something that isn't yours > is properly called "theft" Is the message Subject in the public domain? Is the message Body in the public domain? Why are many mailing lists taking liberties with them? Sorry, but I think your analogy of email vs property does not compute. > and as I understand it is it forbidden by > all of the mail header RFCs since 733, which assign that field to the > originator, and no role in editing it to other participants in the > mail system. I think that point was settled as "it is debatable". That field contains the Author, and if the Author signed with DKIM and the mediated message breaks that signature, it can then be argued that Authorship has suffered and therefore that the From: Header should reflect that fact. > > Everyone (Originators and Receivers) > > And Mediators. I don't understand why you refuse to admit that > Mediators *must* perform the same functions as Receivers and > Originators in order to safely accept and reinject messages. Because the fact that Mediators also do the role of Originators and the role of Receivers is not what makes them special, but the very fact that they are the only ones doing the role of Mediators. So the role of Originator has had to change and adapt. The role of Receiver has had to change and adapt. What changes have happened to the role of Mediator, to improve validation/authentication of the email system as a whole? None that I see, yet. > I don't understand why you insist on attacking the mediators, when (1) > the DMARC Originators who publish p=reject are in conflict with their > own users, (2) the DMARC Originators are not only signing their own > content, but unilaterally asserting that it is the only content > permitted in any version of messages originated in their system, in > violation of the expectations of their own users as originators and of > mailing list subscribers as recipients, and (3) the particular > "p=reject" use case causing issues was pre-deprecated in their own > standard. Well, I don't "attack" anyone, I express my opinion about what I think would be the easiest and lest painful --considering the email system as a whole-- solution to the problem. If your feel that as an "attack", what can I do? Yes, Mediators did not create the problem. It is not their fault. But live systems change, and we have to adapt. The roles of Originator and Receiver already are trying very hard to adapt. What is the role of Mediator doing to adapt to such change? > In any case, your "burden-equalization" approach is purely political, > and does not respect that fact that the technical opportunities to > mitigate the problem are not equally distributed. Mediators have very > little power to improve service unless the Originators participate; > all we can do is watch the services we are allowed to provide be > deprecated. Yes, I see that danger of deprecation to mailing lists too (at least, to mailing lists managed/configured old-style). Email is heavily used in corporate settings; inter-domain mailing lists used as "discussion groups many-to-many", not so much. Market is a powerful force... > Mediators such as mailing lists can adapt, *and already have done so*, > but we also advocate our users' interests. Those interests continue > to be harmed, to the profit of Yahoo! and AOL, and to the detriment of > *everybody else* in the mail system. I think we should get past the Yahoos and the AOLs. They pioneered the misue of DMARC, but that misuse is here to stay and will certainly grow, to the point it will become "common usage". So the problem space is now bigger than just Yahoo and AOL. I also feel I am advocating my users's best interests. I am not mad at you, don't be mad at me. :-) > > Email is changing. We all have to change to accomodate the fact > > that email is changing. Mediators don't seem willing to change at > > all. What I see is that email is about to evolve to the next level, > > and Mediators are at risk of being left behind if they refuse to > > change to accomodate the fact that email is changing. > > Thank you for your concern. We Mediators can and will take care of > our own interests, and ask you to desist with your efforts to help -- > they are not helpful because they do not respect our users' > requirements. Well, I also have users whose interests I humbly try to present and defend here. I don't see why I should desist from doing so. Regards, J.Gomez ___ dmarc mailing list dmarc@ietf.org https://www.ietf
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
J. Gomez writes: > > What else do you propose that we do? > > Well, if you ask... Mediators could take ownership of the > Header-From whenever their involvement results in the Originator's > DKIM signature being invalidated. The From header field is not in the public domain, and not available for appropriation. "Taking ownership" of something that isn't yours is properly called "theft", and as I understand it is it forbidden by all of the mail header RFCs since 733, which assign that field to the originator, and no role in editing it to other participants in the mail system. The fact that Message-ID changes not only are not performed, but actually cause annoyance (unfilterable duplicates for subscribing recipients and inability to search archives for non-subscribers) suggests that to recipients as well as to originators and mediators the two messages are the same. Therefore the authors of the original messages remain the authors for the purpose of "From ownership". We (MLMs in general, as exemplified by GNU Mailman) in fact *do* allow this (as a per-list option). Not only does it violate the RFCs according to our interpretation, not only is it ugly and inconvenient, but it even causes some users to identify our posts as spam. This is hardly a desirable change if other changes can be made to improve the situation. > Or some other change to their "entrenched" traditional behavior, > like stop adding subject tags and body footers and being content > with using some List-ID header to identify themselves, etc. My own Internet facing lists don't add any such, although the lists where I can effectively forbid use of DMARC-abusing mailbox providers do. In general, it's not the mediators who care. It's the recipient users, who have a conflict of interest with their mailbox providers, not with the mediators. > Everyone (Originators and Receivers) And Mediators. I don't understand why you refuse to admit that Mediators *must* perform the same functions as Receivers and Originators in order to safely accept and reinject messages. In the case of GNU Mailman, with the help of Franck Martin, we also released (publicly, as part of our normal development cycle) a version including DMARC mitigations 6 months *in advance* of the April Fiasco. I don't understand why you insist on attacking the mediators, when (1) the DMARC Originators who publish p=reject are in conflict with their own users, (2) the DMARC Originators are not only signing their own content, but unilaterally asserting that it is the only content permitted in any version of messages originated in their system, in violation of the expectations of their own users as originators and of mailing list subscribers as recipients, and (3) the particular "p=reject" use case causing issues was pre-deprecated in their own standard. In any case, your "burden-equalization" approach is purely political, and does not respect that fact that the technical opportunities to mitigate the problem are not equally distributed. Mediators have very little power to improve service unless the Originators participate; all we can do is watch the services we are allowed to provide be deprecated. > is changing their email usage patterns/processes in order to take > email to the next level (in reality, just to keep it a viable > communication option in an increasingly hostile Internet > environment), but Mediators seem totally unwilling to change their > email usage patterns/processes. Nonsense, and your insistence on this nonsense is getting very tiresome. The reality is that Mediators *have* changed their patterns and processes *already*, in fact some of the changes anticipated the issues we now are wrestling with. It's not the Mediators who are unwilling to change. It's the *users*. The agents who are blocking the changes needed to satisfy the users' requirements are the DMARC p=reject mailbox providers, in view of (1) and (2) above. Mediators such as mailing lists can adapt, *and already have done so*, but we also advocate our users' interests. Those interests continue to be harmed, to the profit of Yahoo! and AOL, and to the detriment of *everybody else* in the mail system. "Everybody else" includes those DMARC participating domains who respect the SHOULDs and SHOULD NOTs of DMARC! That's because a protocol that brings them benefit is now a dirty word all over the Internet. For example, are you aware that the Japanese government has deprecated use of *all* yahoo.* addresses for official business, despite the fact that only yahoo.com publishes p=reject? > Email is changing. We all have to change to accomodate the fact > that email is changing. Mediators don't seem willing to change at > all. What I see is that email is about to evolve to the next level, > and Mediators are at risk of being left behind if they refuse to > change to accomodate the fact that email is changing. Thank you for your concern. We Mediators can and will take care o
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On Saturday, April 25, 2015 4:29 PM [GMT+1=CET], Stephen J. Turnbull wrote: > J. Gomez writes: > > > What costs are Mediators currently taking to improve > > validation/authentication of the email system as a whole? > > Isn't it obvious that Mediators bear all of the burden that *both* > ends do? Of course, we perform both roles on each message. We verify > signatures and filter messages on the way in, which potentially could > reduce costs system-wide due to the multiplier effect of mailing lists > (except of course nobody trusts us to do it well). We sign the > version of the message that we send out. (These are functions of the > MTA, of course, and we can't do a better or worse job than any > Originator or Recipient. Except that to some extent Mediators may > have information about the Originator that Recipient systems don't, > which may improve filtering.) > > What else do you propose that we do? Well, if you ask... Mediators could take ownership of the Header-From whenever their involvement results in the Originator's DKIM signature being invalidated. Or some other change to their "entrenched" traditional behavior, like stop adding subject tags and body footers and being content with using some List-ID header to identify themselves, etc. Everyone (Originators and Receivers) is changing their email usage patterns/processes in order to take email to the next level (in reality, just to keep it a viable communication option in an increasingly hostile Internet environment), but Mediators seem totally unwilling to change their email usage patterns/processes. Email is changing. We all have to change to accomodate the fact that email is changing. Mediators don't seem willing to change at all. What I see is that email is about to evolve to the next level, and Mediators are at risk of being left behind if they refuse to change to accomodate the fact that email is changing. Regards, J.Gomez ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
J. Gomez writes: > What costs are Mediators currently taking to improve > validation/authentication of the email system as a whole? Isn't it obvious that Mediators bear all of the burden that *both* ends do? Of course, we perform both roles on each message. We verify signatures and filter messages on the way in, which potentially could reduce costs system-wide due to the multiplier effect of mailing lists (except of course nobody trusts us to do it well). We sign the version of the message that we send out. (These are functions of the MTA, of course, and we can't do a better or worse job than any Originator or Recipient. Except that to some extent Mediators may have information about the Originator that Recipient systems don't, which may improve filtering.) What else do you propose that we do? GNU Mailman has been working (desultorily) on lists which authenticate posters via personal digital signatures, but that isn't going to help much. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On 4/25/2015 6:32 AM, J. Gomez wrote: >>> I.e., if you supress the Mediator, all is fine and dandy. ... >> > and what benefits do they get in return? > The benefit to Mediators is that they will avoid becoming an obsolete > artifact of the past, like open SMTP relays. The word that is needed here is 'Procrustean'. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On Saturday, April 25, 2015 12:24 PM [GMT+1=CET], Rolf E. Sonneveld wrote: > On 04/25/2015 11:50 AM, J. Gomez wrote: > > On Thursday, April 16, 2015 4:11 PM [GMT+1=CET], Scott Kitterman > > wrote: > > > > > I will probably regret this, but since people are throwing around > > > things like Pareto to argue in favor or against specific solution > > > areas, I thought it might be useful to take a step back and look > > > at what might make a solution (or set > > > of solutions) useful to pursue. > > > > > > For indirect mail flows like mailing lists, there are three actors > > > involved: > > > > > > 1. Originator > > > 2. Mediator > > > 3. Receiver > > > > > > For the purposes of this discussion I'll further categorize the > > > entities involved as big and small (yes, it's way more complex > > > than that, but I think that's sufficient). > > > > > > That leads to six combinations: Originator/Big, Originator/Small, > > > Mediator/Big, Originator/Small, Receiver/Big, and Receiver/Small. > > > > > > There have been solutions proposed that only require changes for > > > one of the three above, that require changes at two of the above, > > > and that require > > > changes at all three. > > Nice framework. > > > > I'd like to note that it is the presence/existance of actor > > "Mediator" which induces the DMARC compatibility problems with > > indirect flows. > > > > I.e., if you supress the Mediator, all is fine and dandy. That fact > > should at leat put some pressure on Mediator regarding the > > searching for a solution, and should induce Mediator to acknowledge > > that he will have to assume certain costs for such a solution. > > > > I see Originator already assuming costs: deploying SPF in DNS and > > keeping it current, deploying DKIM records and DKIM-signing > > outgoing email, deploying DMARC records and being vigilant > > regarding Header-From alignment in his outgoing email, etc. > > > > And I see Receiver already assuming costs: setting up systems to > > check SPF, DKIM and DMARC for incoming email, dealing with the > > support costs of false positives and phised users, sending out > > DMARC reports, etc. > > > > What costs are Mediators currently taking to improve > > validation/authentication of the email system as a whole? > > and what benefits do they get in return? The benefit to Mediators is that they will avoid becoming an obsolete artifact of the past, like open SMTP relays. Regards, J.Gomez ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On 04/25/2015 11:50 AM, J. Gomez wrote: On Thursday, April 16, 2015 4:11 PM [GMT+1=CET], Scott Kitterman wrote: I will probably regret this, but since people are throwing around things like Pareto to argue in favor or against specific solution areas, I thought it might be useful to take a step back and look at what might make a solution (or set of solutions) useful to pursue. For indirect mail flows like mailing lists, there are three actors involved: 1. Originator 2. Mediator 3. Receiver For the purposes of this discussion I'll further categorize the entities involved as big and small (yes, it's way more complex than that, but I think that's sufficient). That leads to six combinations: Originator/Big, Originator/Small, Mediator/Big, Originator/Small, Receiver/Big, and Receiver/Small. There have been solutions proposed that only require changes for one of the three above, that require changes at two of the above, and that require changes at all three. Nice framework. I'd like to note that it is the presence/existance of actor "Mediator" which induces the DMARC compatibility problems with indirect flows. I.e., if you supress the Mediator, all is fine and dandy. That fact should at leat put some pressure on Mediator regarding the searching for a solution, and should induce Mediator to acknowledge that he will have to assume certain costs for such a solution. I see Originator already assuming costs: deploying SPF in DNS and keeping it current, deploying DKIM records and DKIM-signing outgoing email, deploying DMARC records and being vigilant regarding Header-From alignment in his outgoing email, etc. And I see Receiver already assuming costs: setting up systems to check SPF, DKIM and DMARC for incoming email, dealing with the support costs of false positives and phised users, sending out DMARC reports, etc. What costs are Mediators currently taking to improve validation/authentication of the email system as a whole? and what benefits do they get in return? /rolf ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On Thursday, April 16, 2015 4:11 PM [GMT+1=CET], Scott Kitterman wrote: > I will probably regret this, but since people are throwing around > things like Pareto to argue in favor or against specific solution > areas, I thought it might be useful to take a step back and look at > what might make a solution (or set > of solutions) useful to pursue. > > For indirect mail flows like mailing lists, there are three actors > involved: > > 1. Originator > 2. Mediator > 3. Receiver > > For the purposes of this discussion I'll further categorize the > entities involved as big and small (yes, it's way more complex than > that, but I think that's sufficient). > > That leads to six combinations: Originator/Big, Originator/Small, > Mediator/Big, Originator/Small, Receiver/Big, and Receiver/Small. > > There have been solutions proposed that only require changes for one > of the three above, that require changes at two of the above, and > that require > changes at all three. Nice framework. I'd like to note that it is the presence/existance of actor "Mediator" which induces the DMARC compatibility problems with indirect flows. I.e., if you supress the Mediator, all is fine and dandy. That fact should at leat put some pressure on Mediator regarding the searching for a solution, and should induce Mediator to acknowledge that he will have to assume certain costs for such a solution. I see Originator already assuming costs: deploying SPF in DNS and keeping it current, deploying DKIM records and DKIM-signing outgoing email, deploying DMARC records and being vigilant regarding Header-From alignment in his outgoing email, etc. And I see Receiver already assuming costs: setting up systems to check SPF, DKIM and DMARC for incoming email, dealing with the support costs of false positives and phised users, sending out DMARC reports, etc. What costs are Mediators currently taking to improve validation/authentication of the email system as a whole? Regards, J.Gomez ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On 4/16/2015 8:16 PM, Scott Kitterman wrote: +1 Extremely bias. Lets keep in mind that there are two minimum receivers generally with a MLM transaction that also need to be part of the cost and impact analysis: MDA1 -- receiver and resigner MDA2 -- final user(s) receiver(s). Another solution (partial) is for MDA1 honor policy and not allow resigning to take place. The one that is talked about the most are the MDA2 end user receivers rejecting messages. We will want to maximize the MDA2 consistent and persistent result factor since there could be many different implementations at the MDA2 nodes. It's a bit more complex than just not resigning (actually resigning shouldn't hurt). What I meant about actually, is for the MDA1 to respect the restrictive policy and reject the message (list submission, subscription attempts, etc) and use a reply code/response to explain why. What MDA/MTA1 needs to do is avoid any transformations that would invalidate the originator's DKIM signature. Thats optional. Again Domain Policy based: Policy is relaxed, the MLM may resign, including stripping. Policy is strict, the MLM should block the subscription/submission. Again, as long as the policy also give options for the 3rd party, it can satisfy all boundary conditions. See below. For some, that's a reasonable solution, but for others it's not because they aren't willing to give up the traditional mailing list transformations, i.e. there is a side effect that leads the mediator to consider the approach to costly (costs aren't just money). Scott, when it comes to products, you will have all sides and the good way to address is to make it optional. Everyone is happy. Sure, its more work, but thats the life of a product developer. So yes, we need to separate all the subjective, possible Administrator/Operator options, local policy related stuff and extract the basic protocol engine stuff, the state machine. If you control the access points, then much of this is resolved. See below. I'd still rather focus on an assessment framework before we go zooming into solutions again. I don't think we're getting very far without it. We went thru a threat analysis (RFC4686) and functional requirements (RFC5016) RFC productions and have the basic ideas and problem points well understood. At the end of the day, no matter what, the receiver will have a fixed set of boundary conditions regarding what the ADID and SDID will look like. There are nine basic combinations of signatures when you assign to each NEVER, ALWAYS, OPTIONAL expectations: 1st party: NEVER, ALWAYS, OPTIONAL 3rd party: NEVER, ALWAYS, OPTIONAL So your protocol engine needs to be able to deal with each combination of possible policy. Some will fold providing a smaller set of conditions. The following is an example diagram illustrating this: +---+ | PAYLOAD | +---+ | v ++ ||++ | DKIM |--->| CONTINUE | | Signature | UNSIGNED: OPTIONAL (1) ++ | Authorization | | Protocol | ||++ ||--->|| || SIGNED: EXPIRED (2)|| ||--->|| || NO MAIL EXPECTED (3) | FAILURE/ | ||--->| CLASSIFY | || UNSIGNED: REQUIRED (4) || ||--->|| || SIGNED: NOT EXPECTED (5) || ||--->|| || 3P SIGNED: NOT ALLOWED (6) || ++++ | | SIGNED MESSAGE | v ++ +--+| CONTINUE/ | | |--->| CLASSIFY | | |INVALID SIGNATURE ++ | DKIM | | SIGNATURE| | VERIFICATION |++ | (7) |--->| PASS | | |VALID SIGNATURE ++ +--+ No matter what system you have, they all have be persistent and consistent on what is expected for each condition. That is not a mandate (you have local policy), but it tells you what are the MUSTs, SHOULDs and MAYs. Overall, you are looking for the failure points. (1) Unsigned mail arrives and the policy says its optional. Indeterminate condition, punt, continue. (2) Signed mail, but it expired. Negative classification. (3) No mail is expected for this domain,
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On April 16, 2015 8:05:25 PM EDT, Douglas Otis wrote: > > >On 4/16/15 3:40 PM, Scott Kitterman wrote: >> I think it would be better to await the results of the recently >chartered dbound working group. Whatever DMARC does should, in the end, >align to that, so it would be better not to have this group expend >effort in that area for now. >Dear Scott, > >This misses the point. There is precedence for DMARC using >lists composed without an official basis yet essential to >its operation. Why wait for dbound aimed at offering >completely different results? As this WG considers special >handling for domains that operate some type of third-party >service, these same considerations become critical elements >in achieving a network effect toward practical solutions >safely restoring the role of Sender wholly ignored by DMARC. > >Achieving a network effect requires consensus on how to >effectively deal with problems DMARC creates when handling >third-party services and dealing with misleading assertions >made in DMARC policy. Consensus should avoid endorsing >modes of operation that detract from the social and civic >benefits derived from an open exchange of email. The WG >should strive to ensure an email notification scheme will >not cripple other services in use for decades. Finding a >balance likely means algorithmically categorizing either >third-party domains or domains making misleading assertions. We're going to have to use whatever PSL replacement dbound produces. Let's not have to change twice. I agree that harmonizing DMARC and various third-party originator's operations will be complicated. I think the mediator case is more tractable, so I have focused there for now. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On April 16, 2015 7:06:02 PM EDT, Hector Santos wrote: >On 4/16/2015 6:21 PM, Rolf E. Sonneveld wrote: > >> Now I think Scott is right that we need to make a step back and his >> analysis might help us to know on which solutions we'd best spend >most >> of our time. However, having said that, I'm afraid that we're biased >> by our discussions around the 'DMARC/Mailing List problem'. Let's not >> forget the other use cases of draft-ietf-dmarc-interoperability. > >+1 Extremely bias. > >Lets keep in mind that there are two minimum receivers generally with >a MLM transaction that also need to be part of the cost and impact >analysis: > >MDA1 -- receiver and resigner >MDA2 -- final user(s) receiver(s). > >Another solution (partial) is for MDA1 honor policy and not allow >resigning to take place. The one that is talked about the most are >the MDA2 end user receivers rejecting messages. We will want to >maximize the MDA2 consistent and persistent result factor since there >could be many different implementations at the MDA2 nodes. It's a bit more complex than just not resigning (actually resigning shouldn't hurt). What MDA/MTA1 needs to do is avoid any transformations that would invalidate the originator's DKIM signature. For some, that's a reasonable solution, but for others it's not because they aren't willing to give up the traditional mailing list transformations, i.e. there is a side effect that leads the mediator to consider the approach to costly (costs aren't just money). Although we've been focused on mailing lists in discussing the possible solution space, the framework I laid out is suitable for any mediated message transaction. I think the solution space for third-party originators is likely disjoint from the solution space for mediated transactions, so I haven't worried about it too much. I'd still rather focus on an assessment framework before we go zooming into solutions again. I don't think we're getting very far without it. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On 4/16/15 3:40 PM, Scott Kitterman wrote: > I think it would be better to await the results of the recently chartered > dbound working group. Whatever DMARC does should, in the end, align to that, > so it would be better not to have this group expend effort in that area for > now. Dear Scott, This misses the point. There is precedence for DMARC using lists composed without an official basis yet essential to its operation. Why wait for dbound aimed at offering completely different results? As this WG considers special handling for domains that operate some type of third-party service, these same considerations become critical elements in achieving a network effect toward practical solutions safely restoring the role of Sender wholly ignored by DMARC. Achieving a network effect requires consensus on how to effectively deal with problems DMARC creates when handling third-party services and dealing with misleading assertions made in DMARC policy. Consensus should avoid endorsing modes of operation that detract from the social and civic benefits derived from an open exchange of email. The WG should strive to ensure an email notification scheme will not cripple other services in use for decades. Finding a balance likely means algorithmically categorizing either third-party domains or domains making misleading assertions. Regards, Douglas Otis ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
>yes, but the problem with cost imposed on third parties is that it is >valued different by the one who imposes it on someone else and the one, >on which is it imposed. Well, sure. If I can force you to solve my problem, as far as I'm concerned that's a free solution. I hope we agree we want to stay away from that dark corner. >I believe a number of the Mediators, described in par. 3.2 of >https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-01, cannot >easily be changed. That seems reasonable. We can have a discussion about whether things like my double signer trick, which might be implemented in a wrapper or a postprocessor qualify as not changing the mediator. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On 4/16/2015 6:21 PM, Rolf E. Sonneveld wrote: Now I think Scott is right that we need to make a step back and his analysis might help us to know on which solutions we'd best spend most of our time. However, having said that, I'm afraid that we're biased by our discussions around the 'DMARC/Mailing List problem'. Let's not forget the other use cases of draft-ietf-dmarc-interoperability. +1 Extremely bias. Lets keep in mind that there are two minimum receivers generally with a MLM transaction that also need to be part of the cost and impact analysis: MDA1 -- receiver and resigner MDA2 -- final user(s) receiver(s). Another solution (partial) is for MDA1 honor policy and not allow resigning to take place. The one that is talked about the most are the MDA2 end user receivers rejecting messages. We will want to maximize the MDA2 consistent and persistent result factor since there could be many different implementations at the MDA2 nodes. -- HLS ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On April 16, 2015 5:57:10 PM EDT, Douglas Otis wrote: > > >On 4/16/15 2:26 PM, Scott Kitterman wrote: >> I don't think market share in the abstract is useful for >> this discussion. Per my utility analysis, the question is >> not percent of market (however that is defined), but >> breadth of market scope being sufficient to enable >> interoperability when it's needed. I would still >> appreciate solution independent discussion of how to do >> the utility analysis or I fear we'll continue to just >> argue past each other. >Dear Scott, > >DMARC is leveraging a public-suffix list to reduce >overhead. This approach will cause problems if it leaves a >gap between the domains provided by a registrar and those >listed as part of the public suffix. With the massive >amounts of DMARC feedback being generated, perhaps there >should be a way to consolidate these domains into some type >of list. Of course, I'll suggest a hashed label approach. >Can anyone envision some type of community or specialized >effort at consolidating this category of the domain space? I think it would be better to await the results of the recently chartered dbound working group. Whatever DMARC does should, in the end, align to that, so it would be better not to have this group expend effort in that area for now. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On 04/16/2015 11:20 PM, John Levine wrote: Rolf kind of said what I'm thinking here: I agree that we need to look at the costs. But are we willing, or not willing, to accept costs that are not zero? Sure, everything has some cost. Something I should have made clearer is the difference between the costs of changes one imposes on one's self and those forced on third parties, particularly on third parties that didn't volunteer to accept them. yes, but the problem with cost imposed on third parties is that it is valued different by the one who imposes it on someone else and the one, on which is it imposed. And that is due to the fact, like you said earlier today: The whole reason we're having this discussion is that a few large originators had nontechnical costs that they decided to push off onto other people. Now I think Scott is right that we need to make a step back and his analysis might help us to know on which solutions we'd best spend most of our time. However, having said that, I'm afraid that we're biased by our discussions around the 'DMARC/Mailing List problem'. Let's not forget the other use cases of draft-ietf-dmarc-interoperability. I believe a number of the Mediators, described in par. 3.2 of https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-01, cannot easily be changed. To give an example: recently when I was working for company A, I forwarded an invitation I got from company B to one of my addresses at ESP C. I just used the Exchange/Outlook forward function at company A and discovered that the mail client I used at ESP C showed the address of company B, no the address I have with company A. Company A is using Exchange/Outlook 2010 and has no plans to upgrade for the next couple of years. Should Microsoft update Exchange to support some mediator 'change' for DMARC, then this probably won't be 'retrofitted' into Exchange 2010. So it may take many years before I can use a version that supports DMARC 'mediation'. Maybe we should assign a higher score/priority to solutions that only cover Originator and Receiver, as (in general) the Originator and Receiver are primary stakeholders re. the proper transfer and delivery of the message. /rolf ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On 4/16/15 2:26 PM, Scott Kitterman wrote: > I don't think market share in the abstract is useful for > this discussion. Per my utility analysis, the question is > not percent of market (however that is defined), but > breadth of market scope being sufficient to enable > interoperability when it's needed. I would still > appreciate solution independent discussion of how to do > the utility analysis or I fear we'll continue to just > argue past each other. Dear Scott, DMARC is leveraging a public-suffix list to reduce overhead. This approach will cause problems if it leaves a gap between the domains provided by a registrar and those listed as part of the public suffix. With the massive amounts of DMARC feedback being generated, perhaps there should be a way to consolidate these domains into some type of list. Of course, I'll suggest a hashed label approach. Can anyone envision some type of community or specialized effort at consolidating this category of the domain space? Regards, Douglas Otis ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On Thursday, April 16, 2015 05:20:01 PM Hector Santos wrote: > On 4/16/2015 4:58 PM, Murray S. Kucherawy wrote: > > On Thu, Apr 16, 2015 at 11:34 AM, John R Levine wrote: > >> At least, we need to look at what non-technical costs they push onto > >> other > >> parties. > >> > >> Some changes have insignificant non-techincal costs and are not > >> controversial, e.g., adding a List-ID header for the benefit of > >> recipients > >> who know how to use it. Changes that seem similar may have quite > >> different > >> costs, e.g., adding a List-ID and removing subject tags, forcing > >> recipients > >> to change the way they sort and organize their incoming messages. > > > > Rolf kind of said what I'm thinking here: I agree that we need to look at > > the costs. But are we willing, or not willing, to accept costs that are > > not zero? > > > > For example, asserting that all parties should have to take on zero > > non-technical cost here seems like it might leave us dead in the water > > before we even start. I don't have a good non-zero suggestion though, > > because it's hard (or maybe even impossible) to be specific. > > Murray, we don't need to go that far. > > We are talking about a IETF protocol engine that has two basic flows: > > ADID == SDID conditions > ADID != SDID conditions > > We just need to come up with the models for this and let the market > decide. > > The problem is that ATPS was short-changed as an extension to ADSP > which was being abandoned. > > The APIs were ready for this. Since DMARC replaces ADSP, you need to > update RFC6541 to have it piggy back off DMARC. Since DMARC is now > being adopted to replace ADSP in the industry, you now need to make it > market ready for the 3rd party check allowing them to learn how to > scale it too. > > If you want to do this IN-BAND stuff for those systems that can not do > DMARC+ATPS, that would be great and it would cover a wider market, > including the biggest one who can afford the additional changes to all > this. They can also afford to do both ATPS and IN-BAND as well if > they choose to so. I don't think market share in the abstract is useful for this discussion. Per my utility analysis, the question is not percent of market (however that is defined), but breadth of market scope being sufficient to enable interoperability when it's needed. I would still appreciate solution independent discussion of how to do the utility analysis or I fear we'll continue to just argue past each other. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
>Rolf kind of said what I'm thinking here: I agree that we need to look at >the costs. But are we willing, or not willing, to accept costs that are >not zero? Sure, everything has some cost. Something I should have made clearer is the difference between the costs of changes one imposes on one's self and those forced on third parties, particularly on third parties that didn't volunteer to accept them. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On 4/16/2015 4:58 PM, Murray S. Kucherawy wrote: On Thu, Apr 16, 2015 at 11:34 AM, John R Levine wrote: At least, we need to look at what non-technical costs they push onto other parties. Some changes have insignificant non-techincal costs and are not controversial, e.g., adding a List-ID header for the benefit of recipients who know how to use it. Changes that seem similar may have quite different costs, e.g., adding a List-ID and removing subject tags, forcing recipients to change the way they sort and organize their incoming messages. Rolf kind of said what I'm thinking here: I agree that we need to look at the costs. But are we willing, or not willing, to accept costs that are not zero? For example, asserting that all parties should have to take on zero non-technical cost here seems like it might leave us dead in the water before we even start. I don't have a good non-zero suggestion though, because it's hard (or maybe even impossible) to be specific. Murray, we don't need to go that far. We are talking about a IETF protocol engine that has two basic flows: ADID == SDID conditions ADID != SDID conditions We just need to come up with the models for this and let the market decide. The problem is that ATPS was short-changed as an extension to ADSP which was being abandoned. The APIs were ready for this. Since DMARC replaces ADSP, you need to update RFC6541 to have it piggy back off DMARC. Since DMARC is now being adopted to replace ADSP in the industry, you now need to make it market ready for the 3rd party check allowing them to learn how to scale it too. If you want to do this IN-BAND stuff for those systems that can not do DMARC+ATPS, that would be great and it would cover a wider market, including the biggest one who can afford the additional changes to all this. They can also afford to do both ATPS and IN-BAND as well if they choose to so. -- HLS ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On Thursday, April 16, 2015 01:58:59 PM Murray S. Kucherawy wrote: > On Thu, Apr 16, 2015 at 11:34 AM, John R Levine wrote: > > At least, we need to look at what non-technical costs they push onto other > > parties. > > > > Some changes have insignificant non-techincal costs and are not > > controversial, e.g., adding a List-ID header for the benefit of recipients > > who know how to use it. Changes that seem similar may have quite > > different > > costs, e.g., adding a List-ID and removing subject tags, forcing > > recipients > > to change the way they sort and organize their incoming messages. > > Rolf kind of said what I'm thinking here: I agree that we need to look at > the costs. But are we willing, or not willing, to accept costs that are > not zero? > > For example, asserting that all parties should have to take on zero > non-technical cost here seems like it might leave us dead in the water > before we even start. I don't have a good non-zero suggestion though, > because it's hard (or maybe even impossible) to be specific. I think there's a wide enough variety of participants in the working group that we'll know if it's 'too much', whatever that turns out to be. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On Thu, Apr 16, 2015 at 11:34 AM, John R Levine wrote: > At least, we need to look at what non-technical costs they push onto other > parties. > > Some changes have insignificant non-techincal costs and are not > controversial, e.g., adding a List-ID header for the benefit of recipients > who know how to use it. Changes that seem similar may have quite different > costs, e.g., adding a List-ID and removing subject tags, forcing recipients > to change the way they sort and organize their incoming messages. > Rolf kind of said what I'm thinking here: I agree that we need to look at the costs. But are we willing, or not willing, to accept costs that are not zero? For example, asserting that all parties should have to take on zero non-technical cost here seems like it might leave us dead in the water before we even start. I don't have a good non-zero suggestion though, because it's hard (or maybe even impossible) to be specific. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
I don't have a summary. To the extent I mentioned any specific proposal it was meant to be merely exemplary. The point, is to come up with a framework to discuss solution utility. Because there is a certain breadth of deployment needed for interoperability for some solutions, I don't think Pareto analysis is useful at all. We've spent a lot of time going around in circles about various proposals and so I'm trying to come up with a useful way for us to focus. It doesn't eliminate the need to make sure any method we pursue works and is secure, it's just a way to see what clears the minimum threshold for deployability to provide a potential for interoperability. Your mail is mostly arguing about specifics of different solutions. That means we're not at all on the same page. I'm attempting a step back to define a framework we can use to move the group forward. Please look at it at that level and take a step back both from the well known history and the particular solutions you like or don't like. Scott K On Thursday, April 16, 2015 01:03:20 PM Hector Santos wrote: > Scott, > > what is your summary with all this? > > We probably should understand optimization concepts such as Pareto > Optimality and Query Dissemination. Both are applicable here as well. > > I've actually have two receivers; one for the mediator and one for the > end-users. The problem was that Levine did not want the mediator > receivers to support policy. Hence ADSP got no support by MLM receivers > (except for us, but we didn't flip the rejection switch, just recorded > results). What Levine forgot was the user receivers, and that is what > DMARC forgot too. Overall, they presumed no one will take it serious and > honor it, including controlling the MLM entry points. > > Well. It did. > > We got many IETF-MAN-YEARS of engineering into all this and the policy > lookup was the method ultimately devised as the baseline. While it was > confused with mandates to limit the business damage to the resigner market, > and a focus to kill policy methods all together, it never removed the need > to get 3rd authorization from the ADID. > > Blind resigners was a security threat. DKIM could not separate the purported > author from the signature and signer. The 5322.From is required. If it > wasn't, we would then have a different security model. From all historical > angles, from rewrites is simply not a good idea to crack open that door. > It changes everything and makes the entire discussions moot. As mentioned > before, a rewrite is most certainly IETF Appeal sensitive. Just saying. > > RFC work was done for threats, requirements and overall the DKIM > architecture and using 1st and 3rd party policy framework is a result and > consistent with all the IETF-MAN-YEARS put into this work. We were > complaining about the actually record and query method and possible > management complexity. Not so much the registration part of it because > that can also be learned over time. This work is still relevant and even > more so today because the mindset has changed to enable policy (via DMARC). > We simply did not have this before with ADSP. So DMARC has changed the > game. > > The in-band is fine but it's weaker and more expensive to implement, and the > registration is still required by the organizations still interested in > keeping with a higher level of DKIM security strength a policy framework > provides. Let's not assume that given no other design option, sites will > just blindly sign all mail. Given no other choice, who knows, you might > force sites to re-invest in their DKIM engine to do this double signing > and also do the policy level verification, > > Also, keep in mind, the failures points of the proposal too. That's very > important here. Are we ready to do the MUST/SHOULD for negative > classification (reject/discard/quarantine) when the detectable @fs= > protocol failures exist? Remember, it's not just about looking for the > good, but filtering the failures from the stream, and we can't once again > get the disillusionment that no one will honor rejection because the two > receivers are also using query dissemination methods to minimize connection > abuse issues. > > Look, supposedly opendkim has support for ADSP/ATPS. A simple change to > piggy back off the DMARC record itself with the renewed interest for policy > now, we can better measure the level of support and also provide the > opportunity for sites to do registration R&D. > > -- > Hector Santos > http://www.santronics.com > > > On Apr 16, 2015, at 10:11 AM, Scott Kitterman > > wrote: > > > > I will probably regret this, but since people are throwing around things > > like Pareto to argue in favor or against specific solution areas, I > > thought it might be useful to take a step back and look at what might > > make a solution (or set of solutions) useful to pursue. > > > > For indirect mail flows like mailing lists, th
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On 04/16/2015 08:34 PM, John R Levine wrote: The most tedious and unhelpful discussions here have implicitly (or perhaps explicitly) assumed that receiver nontechnical costs don't matter, then repeatedly pointed out the true but useless fact that there are single party mediator changes with trivial technical costs. Useless because it presumes the non-technical costs of those changes are high? At least, we need to look at what non-technical costs they push onto other parties. Some changes have insignificant non-techincal costs and are not controversial, e.g., adding a List-ID header for the benefit of recipients who know how to use it. Changes that seem similar may have quite different costs, e.g., adding a List-ID and removing subject tags, forcing recipients to change the way they sort and organize their incoming messages. I (think I) understand what you mean and I sympathize with your reasoning. But how are we supposed to compare non-technical costs with technical costs? And what would be the formula to make a fair comparison between Technical/Non-technical Costs for Big/Small Originators/Mediators/Receivers? The concept of technical vs non-technical cost at least doubles the six combinations, mentioned by Scott. /rolf ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
The most tedious and unhelpful discussions here have implicitly (or perhaps explicitly) assumed that receiver nontechnical costs don't matter, then repeatedly pointed out the true but useless fact that there are single party mediator changes with trivial technical costs. Useless because it presumes the non-technical costs of those changes are high? At least, we need to look at what non-technical costs they push onto other parties. Some changes have insignificant non-techincal costs and are not controversial, e.g., adding a List-ID header for the benefit of recipients who know how to use it. Changes that seem similar may have quite different costs, e.g., adding a List-ID and removing subject tags, forcing recipients to change the way they sort and organize their incoming messages. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On Thu, Apr 16, 2015 at 9:31 AM, John Levine wrote: > The most tedious and unhelpful discussions here have implicitly (or > perhaps explicitly) assumed that receiver nontechnical costs don't > matter, then repeatedly pointed out the true but useless fact that > there are single party mediator changes with trivial technical costs. > Useless because it presumes the non-technical costs of those changes are high? ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
Scott, what is your summary with all this? We probably should understand optimization concepts such as Pareto Optimality and Query Dissemination. Both are applicable here as well. I've actually have two receivers; one for the mediator and one for the end-users. The problem was that Levine did not want the mediator receivers to support policy. Hence ADSP got no support by MLM receivers (except for us, but we didn't flip the rejection switch, just recorded results). What Levine forgot was the user receivers, and that is what DMARC forgot too. Overall, they presumed no one will take it serious and honor it, including controlling the MLM entry points. Well. It did. We got many IETF-MAN-YEARS of engineering into all this and the policy lookup was the method ultimately devised as the baseline. While it was confused with mandates to limit the business damage to the resigner market, and a focus to kill policy methods all together, it never removed the need to get 3rd authorization from the ADID. Blind resigners was a security threat. DKIM could not separate the purported author from the signature and signer. The 5322.From is required. If it wasn't, we would then have a different security model. From all historical angles, from rewrites is simply not a good idea to crack open that door. It changes everything and makes the entire discussions moot. As mentioned before, a rewrite is most certainly IETF Appeal sensitive. Just saying. RFC work was done for threats, requirements and overall the DKIM architecture and using 1st and 3rd party policy framework is a result and consistent with all the IETF-MAN-YEARS put into this work. We were complaining about the actually record and query method and possible management complexity. Not so much the registration part of it because that can also be learned over time. This work is still relevant and even more so today because the mindset has changed to enable policy (via DMARC). We simply did not have this before with ADSP. So DMARC has changed the game. The in-band is fine but it's weaker and more expensive to implement, and the registration is still required by the organizations still interested in keeping with a higher level of DKIM security strength a policy framework provides. Let's not assume that given no other design option, sites will just blindly sign all mail. Given no other choice, who knows, you might force sites to re-invest in their DKIM engine to do this double signing and also do the policy level verification, Also, keep in mind, the failures points of the proposal too. That's very important here. Are we ready to do the MUST/SHOULD for negative classification (reject/discard/quarantine) when the detectable @fs= protocol failures exist? Remember, it's not just about looking for the good, but filtering the failures from the stream, and we can't once again get the disillusionment that no one will honor rejection because the two receivers are also using query dissemination methods to minimize connection abuse issues. Look, supposedly opendkim has support for ADSP/ATPS. A simple change to piggy back off the DMARC record itself with the renewed interest for policy now, we can better measure the level of support and also provide the opportunity for sites to do registration R&D. -- Hector Santos http://www.santronics.com > On Apr 16, 2015, at 10:11 AM, Scott Kitterman wrote: > > I will probably regret this, but since people are throwing around things like > Pareto to argue in favor or against specific solution areas, I thought it > might > be useful to take a step back and look at what might make a solution (or set > of solutions) useful to pursue. > > For indirect mail flows like mailing lists, there are three actors involved: > > 1. Originator > 2. Mediator > 3. Receiver > > For the purposes of this discussion I'll further categorize the entities > involved as big and small (yes, it's way more complex than that, but I think > that's sufficient). > > That leads to six combinations: Originator/Big, Originator/Small, > Mediator/Big, Originator/Small, Receiver/Big, and Receiver/Small. > > There have been solutions proposed that only require changes for one of the > three above, that require changes at two of the above, and that require > changes at all three. > > Two examples of solutions that require changes only for one actor are > configuring mailing lists not to make changes that break DKIM signatures and > mailing lists rewriting the body From to a local value. While both of those > have drawbacks, from a utility analysis perspective, I think they are useful > to include in the family of solutions to the indirect mail flow problems > caused > by DMARC. > > Rationale: They can be deployed by mediators both big and small with no > further coordination with other actors. For mediators that choose to go down > this path and accept the downsides of the
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
>That leads to six combinations: Originator/Big, Originator/Small, >Mediator/Big, Originator/Small, Receiver/Big, and Receiver/Small. This is indeed useful. But I think it's also important to look at technical vs. nontechnical costs for each actor. The whole reason we're having this discussion is that a few large originators had nontechnical costs that they decided to push off onto other people.* The most tedious and unhelpful discussions here have implicitly (or perhaps explicitly) assumed that receiver nontechnical costs don't matter, then repeatedly pointed out the true but useless fact that there are single party mediator changes with trivial technical costs. R's, John * - the essence of Internet economics is forcing as many of your costs onto other people as you can, but that doesn't make it a virtue ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
Scott, Thanks for laying the problem space out in this manner. Mike > -Original Message- > From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Scott Kitterman > Sent: Thursday, April 16, 2015 10:11 AM > To: dmarc@ietf.org > Subject: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis > > I will probably regret this, but since people are throwing around things like > Pareto to argue in favor or against specific solution areas, I thought it > might > be useful to take a step back and look at what might make a solution (or set > of solutions) useful to pursue. > > For indirect mail flows like mailing lists, there are three actors involved: > > 1. Originator > 2. Mediator > 3. Receiver > > For the purposes of this discussion I'll further categorize the entities > involved > as big and small (yes, it's way more complex than that, but I think that's > sufficient). > > That leads to six combinations: Originator/Big, Originator/Small, > Mediator/Big, Originator/Small, Receiver/Big, and Receiver/Small. > > There have been solutions proposed that only require changes for one of the > three above, that require changes at two of the above, and that require > changes at all three. > > Two examples of solutions that require changes only for one actor are > configuring mailing lists not to make changes that break DKIM signatures and > mailing lists rewriting the body From to a local value. While both of those > have drawbacks, from a utility analysis perspective, I think they are useful > to > include in the family of solutions to the indirect mail flow problems caused > by > DMARC. > > Rationale: They can be deployed by mediators both big and small with no > further coordination with other actors. For mediators that choose to go > down this path and accept the downsides of these approaches, they can > solve the indirect mail flow problem. > > Another example of a potential solution is receivers amalgamating data from > across their user base to identify forwarders and utilize a local policy > override > to not reject DMARC fail messages assessed to be sent via an indirect mail > flow. This is supported by the DMARC specification, but it's not something > that Receiver/Small is going to be able to do. It's only really useful for > Receiver/Big. It should be included in the family of solutions, but it could > not > be said to 'solve' the indirect mail flow problem since it doesn't scale down. > > While none of these three solutions are complete, they are complete at least > for those entities willing and able to deploy them. > > Once a solution requires changes from multiple actors, the assessment is > more complex. If a solution requires (as an example) both sender and > receiver changes to work, then if it only works for small entities, then I > don't > think it has utility. Since Big sends to Small and Small sends to Big, any > solution that affects multiple types of actors needs to work for both Big and > Small, otherwise if a Small only solution is deployed it will fail when Small > sends to Big. Conversely, if a Big only solution is deployed, it will fail > when Big > sends to Small. > > This type of assessment is why I was attracted to John Levine's fs= proposal. > While it is inherently very complex to deploy (it definitely requires sender > and receiver changes and for some indirect mail flows [those that strip > signatures today]), there is nothing inherently Big or Small about it. I > think it > has other problems that may or may not be resolvable, but from a solution > space coverage perspective it is attractive. > > For the complex solution set that covers multiple actors, I think we have to > have a single solution to propose. If we have multiple, multiple actor > solutions, then interoperability in this space gets much more complex. For > single actor solutions, any solution that works and can be deployed helps > interoperability because if any actor deploys it, the breakage is reduced. > For multi-actor solutions, adding additional solutions probably reduces > interoperability since in any given mail transaction (Originator -> Mediator - > > Receiver) all three have to have the same solution deployed. If the > Originator and Receiver have deployed three part solution #1 and the > Mediator has deployed three part solution #2, then both solutions fail. It's > the same as having done nothing. > > In terms of what makes sense to specify in the output of the working group, I > think we should be willing to accept as many single actor solutions as we > discover and have energy to document. They are always good. None of > these solutions is free of side effects and actors should be free to pick > their > poison as long as it doesn't break things elsewhere. > > For multi-entity solutions, I think we should be more constrained. I think > any > multi-actor solution has to work for both Big and Small actors or else there > is > no interoperability.
