Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
Murray, Thanks for your comments. The key difference today is that we have finally achieved the long term engineering considerations of: 1) Getting domains to publish DNS policy records, 2) Receivers performing the DNS policy record lookup, 3) Receivers honoring the mail handling. We did not have this with ADSP when ATPS was first introduced as an extended ADSP add-on. ADSP, the DKIM WG proposed standard track item, was in conflict with what we reestablished today as indirect mail flows and the key cogs of the DKIM WG was focused on eliminating the Author Domain Identity (ADID) from the specification and making 3rd party Trust Signers (SDID) the key focus identity for DKIM evaluation. ADSP was being abandoned and you help kill it by eventually replacing it with DMARC. If you redid ATPS as an add-on DMARC, I suspect we will have a higher interest in its exploration. The marketing and need would be much higher than before. It will certainly push forward our own update efforts (Replaced ADSP with DMARC and I would like believe other mail product and EPS vendors, including MLS developers would also would update DMARC to support a new SDID (Signer Domain Identity) optional parameter in the DNS policy record lookup: DMARC = DKIM_POLICY_DMARC(ADID [,SDID]) We are already doing the lookup as a function of ADID. We established that. Thats the difference today than yesteryears. Now we just proposing to make it flexible for the 3rd party signature condition when the ADID != SDID. We also long established, which I believe all the trust advocates agreed, that resigners are good. They are needed when the original authenticity is lost, i.e MLM. Will the vendors support it?Who knows? But the market is different today and that is all I am saying, you can't judge the lack of interest before because ADSP was being abandoned. DMARC is not being abandoned. It now needs to be completed with that 3rd party component. I suggest a simple update of ATPS to anchor off DMARC and see if we will get the exploration. You will get two immediate packages to support it. Yours and mine. If in the mean time, you come up with something better, great. I don't see it because it will always need to be verifiable with the 1st party again, but now we will be able to explore all the scalability issues. I personally don't think the the non-ESP domains will need to worry about that. Perhaps the biggest challenge for the larger ESP is how to best register the domains. But thats an implementation issue, perhaps using a Web site with other business decisions such as free or fee-based. Let the each market vendor decide that. In the mean time, we need the 3rd party Authorization extension for DMARC. Thanks -- HLS On 3/27/2015 2:59 AM, Murray S. Kucherawy wrote: On Thu, Mar 26, 2015 at 11:22 PM, Stephen J. Turnbull step...@xemacs.org mailto:step...@xemacs.org wrote: Murray's point is that proof of illegitimacy is probably a pipe dream, as shown by past experience with policy frameworks.[1] Legitimacy, on the other hand, is fairly easy to prove, as DMARC shows in daily use by financial institutions and in other transactional mail flows. Put another way, you only really know something when DMARC, DKIM, SPF, etc. produce a passing result. (Due credit to Dave for this observation.) All of them have false negatives with respect to anything that's not a direct mail flow, so fail results don't tell you anything conclusive if you plan to accept any sort of mail that isn't direct. What Hector characterizes as a watering down of SPF with the publication of RFC7208 was merely this fact put into text, even though it's been true since RFC4408. Footnotes: [1] Hector is right that they haven't really been tried, but I don't think the chance that they'll be tried in the future is high, because the reasons they've been hard to implement in the past remain true. I agree. And although Hector likes to ascribe considerable power and influence to me, I'm not the one standing in the way of their success. I would happily embrace any such solution that stood a chance of working. I, and others, simply ask some basic questions about scalability of such solutions, their complexity, and their ability to be gamed, and then they never go anywhere because there simply aren't any good answers to those questions. Thinking I might be wrong, and since the same people insist I am, I published RFC6541 (ATPS) as an experimental draft to try to tackle the third-party problem, and made a free version of it available via open source. That was over three years ago. There has been exactly one site (one person, rather) that tried it besides me and reported back about its effectiveness. Though Doug will shortly claim that ATPS saw no uptake because it is flawed, I also had a grand total of zero operators report that they were using it in any modified form or
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
On Thu, Mar 26, 2015 at 11:59 PM, Murray S. Kucherawy superu...@gmail.com wrote: There are those among you that disagree, I know. Does anyone have actual data (not theory, not passion, but data) that any of the policy or third-party solutions we've discussed before can work, work just about everywhere, and work at scale? If the answer to that is no (or, as usual, silence), then I suggest this (still!) isn't a productive use of our precious time or energy. ...by which I mean we should really not spend any more time re-hashing the past, and instead focus on figuring out the future. I'm all for learning from our past mistakes, but I think we've gotten all the blood we're going to get out of that particular stone. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
Michael Jack Assels writes: I can't think of any. Some, many, or most of them were supposed to be, but it has never turned out that way. I don't know why DMARC is being held to a different standard. Isn't DMARC holding itself to a different standard? That's a reasonable interpretation given the choice of mood (reject is a command), but in the end it's untenable. As Murray says, policy frameworks have been tried before, and they just don't work for generic email, although they work very well (as indeed DMARC does) for several important, but restricted, mail flows. The problem with generic email is that the incentives of Author Domains which provide mailboxes for personal use are poorly aligned with the incentives of their mailboxes' users. Specifically, Author Domains consider spam-fighting priority one, and consider mailing lists and other indirect flows at best neutral, and often on net a nuisance, while their users want to participate freely in indirect flows (leaving the costs of spam-fighting up to the Author Domains). What's a receiver supposed to do with unaligned mail whose From: domain specifies p=reject? Whatever they want to. If they think they can do filtering better than the sender, they may choose to ignore it, and there's nothing that can be done about it. Furthermore, I don't see why anyone other than the receiver's mailbox users should care what the receiver chooses to do. Clearly, the domain owner is explicitly asking that the message be rejected. No, they are not, not in the case of AOL and Yahoo!. Representatives of both domains have thanked MLM developers for providing mitigations so that messages that in the normal (until DMARC) course of events would fail From alignment can be delivered to DMARC-participating receiving domains which (since DMARC) would reject them. Thus, Yahoo! and AOL are clearly taking the position that they would like those messages to be delivered. Hector, J. Gomez, Franck, and others take the position that the world has changed due to spam and phishing, and therefore what *was* normal is now irrelevant. The new norm is conform to DMARC and other dictatorial sender policy frameworks or you're part of the problem. I disagree. Spamming and phishing are the problem, traditional practices of mailing lists are not. If DMARC intends that this be merely one of many factors to consider, then doesn't it boil down to nothing more than p=do-whatever? No, there is valuable information in the policy. As far as I can see, the semantics of p=reject are We have a serious spoofing problem. It is so serious compared to the potential damage due to rejecting legitimate messages that we accept all responsibility for nondelivery and collateral damage if you choose to reject. In the case of direct mail flows, the potential damage due to rejection of legitimate mail is very low, and the potential damage from accepting spoofed mail is extremely high. If you know that a mail flow is direct, as a receiver you'd be crazy not to reject, and as a sender you'd be crazy not to accept the responsibility for receivers rejecting. In the case of indirect flows, receivers may (or may not) want to prefer their judgment to that of the author domain, because often the expected damage from accepting is much lower, and the expected damage from rejecting much higher. Yes, I know that receivers can and will do as they please, but some receivers would be pleased as punch to cooperate in a scheme that gave solid proof of a message's illegitimacy in every case where it was asserted. Murray's point is that proof of illegitimacy is probably a pipe dream, as shown by past experience with policy frameworks.[1] Legitimacy, on the other hand, is fairly easy to prove, as DMARC shows in daily use by financial institutions and in other transactional mail flows. Footnotes: [1] Hector is right that they haven't really been tried, but I don't think the chance that they'll be tried in the future is high, because the reasons they've been hard to implement in the past remain true. The big problem is that policy frameworks proposed so far work only if you define legitimacy tautologically: if it gets past the policy framework, it's legit, else not. That's not what my users want, though. They want to receive the mail they want to receive, and otherwise not, and no policy framework so far has shown promise of implementing that. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
Murray S. Kucherawy writes: Does anyone have actual data (not theory, not passion, but data) that any of the policy or third-party solutions we've discussed before can work, work just about everywhere, and work at scale? Speaking only for myself, at this stage I would accept *theory* that it *can work*, with the caveat that it must be accompanied by an analysis of all possible failure modes, and preferably with (theoretical :-) mitigations for the failures. I haven't seen anything like that, just handwaving about if we implement the policy framework, spam will go away and the mailing lists will have to come to heel (ie, register with the author domains for 3rd party auth). Again speaking for myself, I think it's inappropriate to ask for data about working at scale at this point (although that's a bridge that eentually needs to be crossed). ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
Franck Martin writes: Hard Bounce: no such mailbox/user/email address here (SMTP enhanced status code, like 5.1.1), usually a permanent failure Soft Bounce: there may be a valid mailbox/user/email address here, but we are not accepting this email (SMTP enhanced status code like 5.7.1), a permanent or temporary failure That's not the terminology we use around Mailman: a hard bounce is exactly a permanent failure. I'll keep it in mind that you at least use the term differently here. Nor is the soft bounce as you define it useful if it is permanent (5.x.x). Even if the site admits it's a policy bounce, you have to parse the error text in hope of determining whether there's something wrong with the message (the next message might go through, even from the same author), or if the receiver doesn't like the mailing list (messages aren't going to go through period) or doesn't like the author (the next message might or might not go through, depending on the author). And usually it's useless for the purpose, so has to be passed on to the site admin for forensic analysis. And even that doesn't help with sites that deliberately don't use appropriate codes. I don't really see that (from a protocol standpoint) we're any better off than we were before the enhanced status codes for the purpose of determining whether to stop mail to or unsubscribe a bouncing address. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
On Fri, 27 Mar 2015 15:22:04 +0900, Stephen J. Turnbull step...@xemacs.org wrote: Michael Jack Assels writes: What's a receiver supposed to do with unaligned mail whose From: domain specifies p=reject? Whatever they want to. If they think they can do filtering better than the sender, they may choose to ignore it, and there's nothing that can be done about it. Furthermore, I don't see why anyone other than the receiver's mailbox users should care what the receiver chooses to do. Right, but that leaves DMARC as just another factor to consider when calculating a spam score. Actually, it's a little better than that; it comes pretty close to the desired really reliably reliable for direct mail flows. Clearly, the domain owner is explicitly asking that the message be rejected. No, they are not, not in the case of AOL and Yahoo!. Representatives of both domains have thanked MLM developers for providing mitigations so that messages that in the normal (until DMARC) course of events would fail From alignment can be delivered to DMARC-participating receiving domains which (since DMARC) would reject them. Thus, Yahoo! and AOL are clearly taking the position that they would like those messages to be delivered. As I read it, that means AOL and Yahoo are taking the position that DMARC's p=reject is The Right Thing To Do, while accepting that it's going to give wrong answers for indirect mail flows, and that it's up to MLM developers (and other producers of indirect flows) to deal with it. Hector, J. Gomez, Franck, and others take the position that the world has changed due to spam and phishing, and therefore what *was* normal is now irrelevant. The new norm is conform to DMARC and other dictatorial sender policy frameworks or you're part of the problem. I disagree. Spamming and phishing are the problem, traditional practices of mailing lists are not. If DMARC intends that this be merely one of many factors to consider, then doesn't it boil down to nothing more than p=do-whatever? No, there is valuable information in the policy. As far as I can see, the semantics of p=reject are We have a serious spoofing problem. It is so serious compared to the potential damage due to rejecting legitimate messages that we accept all responsibility for nondelivery and collateral damage if you choose to reject. I can accept that that may be what p=reject means, but I can't take seriously the idea that domain owners with p=reject really do take all responsibility for nondelivery of legitimate messages. When one of my users bangs on my door demanding to know why her message message wasn't delivered, can I really refer her to a giant ESP for an explanation? I don't think so. I'd be happier to interpret p=reject as meaning Spoofing is a serious problem. With a very high degree of certainty, we assert that the message you're handling is not legitimate direct mail. Please take this into account when deciding whether to accept or reject the message. This is worth a lot, despite the fact that it leaves the receiver with two tasks: Determining the message is direct or indirect, and if indirect, determining whether it's legitimate. Yes, I know that receivers can and will do as they please, but some receivers would be pleased as punch to cooperate in a scheme that gave solid proof of a message's illegitimacy in every case where it was asserted. Murray's point is that proof of illegitimacy is probably a pipe dream, as shown by past experience with policy frameworks.[1] Legitimacy, on the other hand, is fairly easy to prove, as DMARC shows in daily use by financial institutions and in other transactional mail flows. I agree that absolute proof of illegitimacy for arbitrary messages is hopeless, but DMARC actually provides a decision procedure for legitimacy of in the restricted area of direct mail flows (assuming that mail from compromised accounts is legitimate). For DMARC participants, legitimacy and illegitimacy are equally easy to prove for transactional mail flows, and equally hard to prove for indirect flows. MJA ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
On Sat, 28 Mar 2015 04:07:51 +0900, Stephen J. Turnbull step...@xemacs.org wrote: Michael Jack Assels writes: As I read it, that means AOL and Yahoo are taking the position that DMARC's p=reject is The Right Thing To Do, while accepting that it's going to give wrong answers for indirect mail flows, and that it's up to MLM developers (and other producers of indirect flows) to deal with it. First, I don't think that interpretation is tenable, because their explanations to us are along the lines of we know that we're a little out of line, but we have no choice. So it's more like p=reject is The Wrong Thing To Do, and it's up to you to deal with it? :-) Second, the relevant producers of indirect mail flows are not the MLMs. They generally produce a direct mail flow, albeit unaligned. It's the mailbox provider's own users who produce indirect mail flows, by posting to the mailing lists. You're right. Producers was certainly the wrong word. I should have said players or participants -- entities involved in indirect flows. We have a serious spoofing problem. It is so serious compared to the potential damage due to rejecting legitimate messages that we accept all responsibility for nondelivery and collateral damage if you choose to reject. I can accept that that may be what p=reject means, but I can't take seriously the idea that domain owners with p=reject really do take all responsibility for nondelivery of legitimate messages. When one of my users bangs on my door demanding to know why her message message wasn't delivered, can I really refer her to a giant ESP for an explanation? I don't think so. No, of course you can't, because they'll tell her that's not what they intended, and that it wouldn't be a problem if the third party behaved well. However, you can tell her that the giant provider told the receiver not to accept her messages. That's what DMARC actually says, and that's why I phrase it accept reponsibility. Actually, there's some ambiguity of emphasis in Section 6.3 of RFC7489: p: Requested Mail Receiver policy (plain-text; REQUIRED for policy records). Indicates the policy to be enacted by the Receiver at the request of the Domain Owner. [...] Possible values are as follows: [...] reject: The Domain Owner wishes for Mail Receivers to reject email that fails the DMARC mechanism check. A policy to be enacted by the Receiver at the request of the Domain Owner sounds compulsory, while [t]he Domain Owner wishes for Mail Receivers to reject email sounds optional. I'm pretty sure my boss will go with optional for mail that we receive. I'd be happier to interpret p=reject as meaning Spoofing is a serious problem. With a very high degree of certainty, we assert that the message you're handling is not legitimate direct mail. Please take this into account when deciding whether to accept or reject the message. There's only one problem with that interpretation, and that is that you don't need DMARC p=reject to make it: it's a logical deduction from the mere fact of lack of From alignment. That's right. The Domain Owner's policy becomes a consideration if, and only if, there's a lack of From alignment. Otherwise everybody's happy. But notice that the hypothetical Domain Owner who makes me happy (a) is only certain that the message is not legitimate *direct* mail, and (b) is asking me to take that into account. In an earlier message, you wrote that a receiver would have to be crazy not to reject a direct message that had no From alignment, and I'm just sane enough to agree. What I don't like is the idea that DMARC-failed *indirect* mail should be rejected solely on the From Domain Owner's say-so. I'm willing to consider rejection as a default option if other factors don't indicate the message's legitimacy, but please leave me the freedom to consider other factors without falling into the RFC-ignorant category. (Is this message a mailing list post? Is the SMTP client one of the SPF-authorized mailers for the mailing list's domain? Does the list appear in my database of legitimate mailing lists?) For DMARC participants, legitimacy and illegitimacy are equally easy to prove for transactional mail flows, and equally hard to prove for indirect flows. That's actually false. There are many indirect flows that don't cause signatures to be invalidated, such as Unix-style .forwards and GNU Mailman mailing lists configured with no subject tag, no header, and no footer. I didn't mean that you can't prove legitimacy or illegitimacy for any indirect flows, only that there doesn't exist a reliable method of proving either in all cases, the point being that there are plenty of cases of DMARC-failing legitimate indirect mail to match the DMARC-failing illegitimate indirect mail. And that's where the shoe pinches
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
Franck Martin writes: 2) Mailing lists should be able to differentiate between an Hard bounce and a Soft bounce (by now). http://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml is 7 years old now. They can, but the problem that caused collateral damage to subscribers is hard bounces, and p=reject is a hard bounce. Perhaps you mean discriminating between technical hard bounces and policy hard bounces, but even there (a) I don't understand why you think there's a difference in the way the ML should treat them, and (b) many receiving sites deliberately conceal policy bounces, and especially the reason for them. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
On Thursday, March 26, 2015 3:08 AM [GMT+1=CET], Hector Santos wrote: SPF had a strong REJECTION concept with RFC4408 and with the latest spec RFC7202, it was relaxed with allowing for quarantining ideas (mail separation). RFC7208 made RFC4408 more costly by adding more complexity for an ACCEPT/SEPARATE mode of operation for failed SPF messages as opposed to just REJECTING failed SPF messages. Part of the problem is that the idea of quarantine does presumed a backend mail storage design that mail separation was even possible. It is not an universal concept to have this multiple mail folders idea, ability and/or MUA/UI infrastructure for end-users. So in that vain, it does come with a high support and also high implementation cost to include Mail Quarantine functionality into a specification. REJECTION is a must lower design implementation cost. +1. For Google/Hotmail/big-ESP, the support costs are already accounted for in their cost structure. For small or boutique Email Service Providers, support costs are very important and can grow very fast: an user has a problem with suspect or missing email?, we go on-site, we hand-hold them, we give face, we remote into their system and get to deal with the mess, we do whatever until the troubled user finds peace... If DMARC is going to increase support costs for small email operators, I may as well migrate all my clients to Google Apps or Office 365 and be done with costly email. That is why, in my view, DMARC's p=reject has to either be reliable to be relied on, or be suppressed from DMARC's formal specification if it is going to mainly be equal to p=do-whatever. Regards, J.Gomez ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
On Thursday, March 26, 2015 4:08 AM [GMT+1=CET], Stephen J. Turnbull wrote: J. Gomez writes: But I would love to be able to reliably rely on DMARC's p=reject. Even if you can in practice, you can't get to 100.0%. Even at ducks-in-a-row sites like frequent-DMARC-contributor-employer.com (which is a financial institution and uses that domain for transactional mailflows), frequent-DMARC-contributor has at least once used his/her p=reject address to post to a mailing list I subscribe to (which didn't implement DMARC). These things happen. Yes, but then in that DMARC rejection which you describe above the Receiver can blame it on the Sender, who did not put his ducks neatly in a row as he should have done. The question is: who bears the cost of DMARC's p=reject false positives? As a Receiver, I will be blind and will not obey to Sender's p=reject unless I can blame on said Sender the rejection --derived form the Sender's declared DMARC of p=reject-- of legitimate email. The set (DMARC + p=reject) is unreliable, in the current situation, because it fails to describe the legitimate and real scenario of mailing lists. Technically, it does describe them: author domains should not use p=reject if it authorizes indirect mailflows From its mailboxes. AOL and Yahoo! were abusing p=reject according to the draft of April 2014. That Yahoo and AOL are abusing p=reject is a way to see the case. Another way to see it, is that DMARC's p=reject fails to describe real email usage, and therefore is unreliable (i.e., cannot be relied on). Regards, J.Gomez ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
- Original Message - From: J. Gomez jgo...@seryrich.com That is why, in my view, DMARC's p=reject has to either be reliable to be relied on, or be suppressed from DMARC's formal specification if it is going to mainly be equal to p=do-whatever. when you see a p=reject and DMARC tells you, you should bounce the email, then just bounce it. Why? 1) there are reports to tell the sender why you bounced the email. And it should get the bounce too. If it is not what the sender wants, he has all the tools to assess if it was important for the receiver to receive this message or not and what can the sender do to change that. 2) Mailing lists should be able to differentiate between an Hard bounce and a Soft bounce (by now). http://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml is 7 years old now. If you do anything else, it is because you want to be nice to the sender. (pulling leg here) ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
On 03/26/2015 04:22 PM, Franck Martin wrote: What I learn for all the combinations: It does not change much, people still ignore my posts :P Franck, that's wy outside the charter of this working group... ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
- Original Message - From: Steven M Jones s...@crash.com To: dmarc@ietf.org Sent: Thursday, March 26, 2015 4:38:08 PM Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) On 03/26/2015 04:22 PM, Franck Martin wrote: What I learn for all the combinations: It does not change much, people still ignore my posts :P Franck, that's wy outside the charter of this working group... We were there a few posts back already... Can people please review the last version of https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/ and comment? This document still needs some improvemments and its completion is a milestone to progress further. Thanks. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
On Thu, 26 Mar 2015 15:23:08 PDT, Murray S. Kucherawy superu...@gmail.com wrote: On Thu, Mar 26, 2015 at 1:21 PM, J. Gomez jgo...@seryrich.com wrote: If DMARC is going to increase support costs for small email operators, I may as well migrate all my clients to Google Apps or Office 365 and be done with costly email. That is why, in my view, DMARC's p=reject has to either be reliable to be relied on, or be suppressed from DMARC's formal specification if it is going to mainly be equal to p=do-whatever. Can anyone point to a single instance of a sender-receiver policy protocol that was reliable by this definition, enough that receivers would blindly agree to do whatever the sender asked/suggested/demanded? I can't think of any. Some, many, or most of them were supposed to be, but it has never turned out that way. I don't know why DMARC is being held to a different standard. Isn't DMARC holding itself to a different standard? What's a receiver supposed to do with unaligned mail whose From: domain specifies p=reject? Clearly, the domain owner is explicitly asking that the message be rejected. If DMARC intends that this be merely one of many factors to consider, then doesn't it boil down to nothing more than p=do-whatever? Yes, I know that receivers can and will do as they please, but some receivers would be pleased as punch to cooperate in a scheme that gave solid proof of a message's illegitimacy in every case where it was asserted. The problem is that publishing p=reject effectively asserts that almost all submissions to mailing lists by users in the domain are illegitimate, and I'm afraid the real world doesn't believe that to be the case. That's not to say that DMARC should change anything about itself. It's just recognition that making it a great success will depend on someone finding a way to let mailing lists collaborate with DMARC without alienating their list users, owners or managers. I'd love to announce that I've found the way, but I'm as befuddled as anyone else. MJA ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
- Original Message - From: Michael Jack Assels mjass...@encs.concordia.ca To: Murray S. Kucherawy superu...@gmail.com Cc: dmarc@ietf.org, J. Gomez jgo...@seryrich.com Sent: Thursday, March 26, 2015 4:12:13 PM Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) On Thu, 26 Mar 2015 15:23:08 PDT, Murray S. Kucherawy superu...@gmail.com wrote: On Thu, Mar 26, 2015 at 1:21 PM, J. Gomez jgo...@seryrich.com wrote: That's not to say that DMARC should change anything about itself. It's just recognition that making it a great success will depend on someone finding a way to let mailing lists collaborate with DMARC without alienating their list users, owners or managers. You can't please everyone at the moment, and there are solutions to please various subsets of your lists. I'm on various mailings lists, some friendly to DMARC, some not, with email with a domain with p=reject, or not... What I learn for all the combinations: It does not change much, people still ignore my posts :P ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
On Tuesday, March 24, 2015 10:08 PM [GMT+1=CET], MH Michael Hammer (5304) wrote: On Tuesday, March 24, 2015 4:59 PM [GMT+1=CET], Anne Bennett wrote: ... and again, if those decisions result merely in rejecting a message, the user isn't involved, but as soon as those decisions can result in tagging a message for possible consideration by the user (probably via different display by the UI), we can't ignore the user. I agree that this isn't the place to delve deeply into user behaviour and UI design. But we shouldn't ignore the context of our work. +1 Email is for the users. p=quarantine is a USER PROBLEM. No, p=quarantine is a problem WE cause. Yes, but a problem that ultimately the user gets directly planted before his eyes, and which the user has to roll up his sleeves to deal with as well/bad as he can possibly manage. Translation: p=quarantine has vey high support costs. As I understand it, in the beginning of the coming up with DMARC, p=quarantine was designed as a stepping stone in the journey towards p=reject. In that view, the high support costs of p=quarantine were tolerable because p=quarantine was meant to be a temporary situation for the sender domain Owner. Now that p=reject is a dead end for all practical purposes, p=quarantine has less and less utility. Only p=none is safe to use unless you do not have real people as users. We must work hard to find a solution which makes p=reject a viable setting which can be reliably relied on. Regards, J.Gomez ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
On Tuesday, March 24, 2015 10:32 PM [GMT+1=CET], Steve Atkins wrote: Mailing lists are only an issue if the domain owner of the email addresses of the participants have published a DMARC p=reject record, despite having actual users who are legitimate source of email that fails authentication. That's a small enough set of domains at the moment (I can think of about five) that there are several obvious solutions for mailing lists - a blacklist of DMARC records to treat specially would be the simplest, though something more nuanced might be better. That blacklist of DMARC records [with p=reject] to treat specially I'm afraid is a solution which will not scale. You say there are now about five of such domains. Well, about five big enough for everyone to notice them, but surely there are many more which are small enough to fly under our radar. It would take just some more data breaches and we might get to a blacklist for DMARC records with p=reject in the form of: * ;-) Regards, J.Gomez ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
Hi, Murray. (Aside: Your email client is sending messages in multipart/alternative format, but then its text/plain section has the quoting broken... Could you fix that, please? I had to manually add below to differentiate your text from mine, I hope I didn't gaffe it...) Original Message From: Murray S. Kucherawy To: J. Gómez Cc: dmarc@ietf.org Sent: Tuesday, March 24, 2015 10:01 PM Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) On Tue, Mar 24, 2015 at 1:38 PM, J. Gomez jgo...@seryrich.com wrote: I know for sure I will publish only p=none for my client's domains, and use DMARC only as a reporting tool, as long as DMARC's p=reject cannot be reliably relied on. But I would love to be able to reliably rely on DMARC's p=reject. I'm not sure I agree with the claim that p=reject is unreliable. It seems to me that it's working as designed, and the results are deterministic. It's not flaky. How receivers use it is the mushy part, but that's really outside of the protocol. The set (DMARC + p=reject) is unreliable, in the current situation, because it fails to describe the legitimate and real scenario of mailing lists. Even if DMARC didn't have these mediator problems, there still would be no ultimate compulsion for receivers to do what domain owners ask. It might be a lot more likely that they would comply without reservations, but there would still be some operators that don't. So just to be clear, are you using reliable here to talk about how receivers apply it? No. It is unreliable for Receivers to apply it. Sure, for the Sender p=reject is perfectly reliable, if he happens to have all his ducks neatly in a row. But the Receiver cannot know if the Sender has all his ducks neatly in a row when said Sender publishes p=reject. Question that the Receiver asks to himself: Is the Sender aware of p=reject drawbacks and can therefore the Receiver rely on the Sender's declared p=reject? Answer to that question: The Receiver has no way to know, therefore p=reject is unreliable from the point of view of the Receiver, irrespective of what the Receiver ultimately decides to do with the Sender's declared p=reject. Regards, J.Gomez ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
On Wed, Mar 25, 2015 at 12:58 PM, J. Gomez jgo...@seryrich.com wrote: No. It is unreliable for Receivers to apply it. Sure, for the Sender p=reject is perfectly reliable, if he happens to have all his ducks neatly in a row. But the Receiver cannot know if the Sender has all his ducks neatly in a row when said Sender publishes p=reject. Question that the Receiver asks to himself: Is the Sender aware of p=reject drawbacks and can therefore the Receiver rely on the Sender's declared p=reject? Answer to that question: The Receiver has no way to know, therefore p=reject is unreliable from the point of view of the Receiver, irrespective of what the Receiver ultimately decides to do with the Sender's declared p=reject. I think you're actually saying exactly what I thought you meant. Thanks for confirming. I just wanted to be clear for context. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
Mr. Gomez, Traditionally, many in the IETF and the mail industry had an aversion towards strong deterministic transport (system) level filtering ideas. This is burned into RFC2821/5321: 7. Security Considerations 7.1 Mail Security and Spoofing This specification does not further address the authentication issues associated with SMTP other than to advocate that useful functionality not be disabled in the hope of providing some small margin of protection against an ignorant user who is trying to fake mail. The text different between 2821 and 5321 is that the user is no longer ignorant. Many preferred to pass the buck to the user for making decisions on what is considered accepted mail. The DMA, the Spammer world, good or bad, want you to ACCEPT the mail to pass to the user. CAN-SPAM also plays a role here too in the area of User Vendor contracts. So in general, whenever we had new strong deterministic rejection protocols, we had the friction of dealing with ACCEPT/SEPARATE or Quarantine ideas embedded as well as means to reduce the potential false positive nature of rejection policies. Case in point with SPF. SPF had a strong REJECTION concept with RFC4408 and with the latest spec RFC7202, it was relaxed with allowing for quarantining ideas (mail separation). RFC7208 made RFC4408 more costly by adding more complexity for an ACCEPT/SEPARATE mode of operation for failed SPF messages as opposed to just REJECTING failed SPF messages. Part of the problem is that the idea of quarantine does presumed a backend mail storage design that mail separation was even possible. It is not an universal concept to have this multiple mail folders idea, ability and/or MUA/UI infrastructure for end-users. So in that vain, it does come with a high support and also high implementation cost to include Mail Quarantine functionality into a specification. REJECTION is a must lower design implementation cost. In theory, rejection or quarantine, both must provide the same end of result of protecting users from harm and also the domain from being exploited. If you are going to quarantine mail instead of rejecting it, then you need to make sure the USER does not get the mail directly in the natural in-box, including the POP3 mail stream -- it must not be part of the pick up. -- HLS On 3/25/2015 3:17 PM, J. Gomez wrote: On Tuesday, March 24, 2015 10:08 PM [GMT+1=CET], MH Michael Hammer (5304) wrote: On Tuesday, March 24, 2015 4:59 PM [GMT+1=CET], Anne Bennett wrote: ... and again, if those decisions result merely in rejecting a message, the user isn't involved, but as soon as those decisions can result in tagging a message for possible consideration by the user (probably via different display by the UI), we can't ignore the user. I agree that this isn't the place to delve deeply into user behaviour and UI design. But we shouldn't ignore the context of our work. +1 Email is for the users. p=quarantine is a USER PROBLEM. No, p=quarantine is a problem WE cause. Yes, but a problem that ultimately the user gets directly planted before his eyes, and which the user has to roll up his sleeves to deal with as well/bad as he can possibly manage. Translation: p=quarantine has vey high support costs. As I understand it, in the beginning of the coming up with DMARC, p=quarantine was designed as a stepping stone in the journey towards p=reject. In that view, the high support costs of p=quarantine were tolerable because p=quarantine was meant to be a temporary situation for the sender domain Owner. Now that p=reject is a dead end for all practical purposes, p=quarantine has less and less utility. Only p=none is safe to use unless you do not have real people as users. We must work hard to find a solution which makes p=reject a viable setting which can be reliably relied on. Regards, J.Gomez ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
On Tuesday, March 24, 2015 1:54 AM [GMT+1=CET], Stephen J. Turnbull wrote: J. Gomez writes: Verifiable authenticity of email greatly depends on DMARC's success. Because without DMARC's success the authenticity of email can only be verified heuristically and not systematically. This is an error of logic. *Authenticity* (defined as did the message satisfy DMARC From alignment when injected?) of *each* message *can* be verified independently of other messages, and if From alignment is verified, the message *is* authentic (modulo black helicopters with 4096-bit encryption breaking equipment). It's what to think about non-verifiable mail that becomes unclear. I think we are not talking about the same thing: when I said depends on DMARC's success, I meant depends on DMARC's success as an implemented technology in the real world, whereas it seems you understood depends on a successful DMARC check. So I say it again, now in fully qualified terms: Verifiable authenticity of email greatly depends on DMARC's success as an implemented technology in the real world. Since the important mail is direct mail, From alignment will be preserved until received by the addressee. Therefore list behavior only affects DMARC verifiability of list traffic, *not* those other mail flows, as far as I can see. I explain: if mailing-lists configured old-style keep DMARC from being a success in the real world, then mailing-lists are hindering the extra notch of trustworthiness that DMARC could bring to important email communications for end users as a whole. So it's not about individual messages, as you seem to be talking about, but about the big picture. And it is that big picture which is begging for mailing-lists operators to abandon their old-style practices and to begin to take ownership in the Header-From of the email they relay and modify while in-flight rendering its original DKIM signature invalid. The requirement you propose is not implementable in a software system alone, whether it is satisfied or not cannot be verified from the behavior of software alone, and therefore cannot be posited as a requirement in the sense used in software engineering. I know that DMARC is not the silver bullet. That's way I said it brings an extra notch of trustworthiness to email, I didn't say DMARC brings final and ultimate trustworthiness. Regards, J.Gomez ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
On 3/24/2015 1:02 PM, Stephen J. Turnbull wrote: Dave Crocker writes: A mailing list typically defines a 'community' for discussion. At least some of the modifications it does are to assert that community in some visible ways. Sure, but From-munging is not an assertion of community, it's an assertion that there's a war out there, and the community is taking hits from friendly fire. Your 'but' suggests that your comment counters mine, but I said 'some' not all and I didn't mention the From field. Nor did I intend to count From munging as an exemplar. Mailing lists therefore have the right to make the changes they make. That's an incomplete statement. They have the right to make the changes as long as they are compatible with community standards. There is a very long list of additional qualifiers and requirements one might choose to include. However I think they distract from the point I was making, which really merely reflects what is in the Email Architecture RFC: When an intermediary is re-posting a message, it owns the message it is re-posting and has the right to do what it wants. That's a system architecture right, not a social' right. Back to Dave: I think the historical challenge has less been a case of philosophical legitimacy From-munging is hardly open-and-shut philosophically legitimate. So it's probably good that I wasn't talking about that. It has its advocates, but it sucks for many users because of the way their MUAs handle it, it arguably violates RFC 5322, and is ugly to boot. Nevertheless, GNU Mailman has a From-Munging option.[1] There are three operational problems with From munging: 1. The recipient sees a different string than they are used to, for identifying the author of the message. That invites confusion. 2. The recipient's filtering engine will misbehave if it keys off of author's name; a related problem is that message threading software will misbehave. 3. From munging teaches spoofers how to bypass DMARC protections. and more of inability to gain active, constructive participation of mailing list software maintainers. Hey, I resent that. You guys use GNU Mailman; you know where to find us if you want participation. I was making an historical comment. Many years ago. Ancient Internet. Most of you folk probably weren't born yet. (just kidding.) (maybe.) It's not the MLM developers you have a problem getting cooperation from. It's our users. We need to stop worrying about users. They are simply a distraction. Or maybe... Bottom line: making indirect mail flows compatible with DMARC-style spoof-protection is a hard problem. +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
On 03/24/2015 01:38 PM, J. Gomez wrote: I do not agree. As long a major ESPs downgrade p=reject to p=quarantine or even p=none on reception of email which fails DMARC checks from domains whose Owner has published p=reject, DMARC is little more than a reporting protocol as Vlatko Salaj has already said in another post to this list. Which is nice, but is not a success as an implemented technology in the real world for DMARC, because DMARC aims to be more than just a reporting tool. DMARC is not some declaration of the divine right of domain owners to exercise absolute control over any message where their domain appears. DMARC is a protocol that enables domain owners/senders and receivers to *collaborate* in detecting and eliminating fraudulent messages that claim to originate from a given domain. There is implicit and explicit give-and-take in that relationship. Policy expressions from domain owners (p=reject) are requests - ones that are followed in most cases - but no receiver is offering an unreserved, 100% guarantee that they won't act otherwise when they feel doing so is in the best interest of their users. The fact that receivers can and will do what they think best, even in the face of a given policy request, runs throughout the DMARC specification. In fact, I think that if at the end of all this process we cannot find a way to make p=reject to be reliably relied on, then p=reject should be suppressed from the DMARC formal specification, as p=reject would effectively be equal to p=do-whatever-who-cares. Again, in my experience, receivers do honor policy assertions in an overwhelming majority of cases. The reporting mechanisms in DMARC are there to help domain owners/senders improve the authentication rates of their legitimate mailflows - so the receivers can block more fraudulent messages, more reliably. Without the support for so-called blocking policies, you have eliminated the reason for receivers to pay for complex, expensive DMARC filtering and reporting. --Steve. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
On 3/24/2015 10:59 AM, Anne Bennett wrote: Dave, You make an assumption about user assumptions. Forgive me, but I doubt you have a reliable, objective, empirical basis for making that assertion or much that derives from it. In fact there's a reasonable chance that your assumption is flawed. I have a 24-year-long parade of users worried that their account was compromised because they're receiving bounces for spam they never sent, Forgive me (yet again) but that wasn't the issue. Yes there's a problem. Long-standing, real and serious. However the issue on the table is an assertion of efficacy by presenting certain kinds of information to end-users. And it's that assertion that is (highly) problematic. Which is why I urge everyone to bypass it. But we're straying from the topic, which is indeed to come up with technical specs that software can obey. Having said that: One could argue, I suppose, that once again we're talking about the behaviour of software, but the point of all this, unless I woefully misunderstand, is to protect the user from fraud due to the faked provenance of a message. As a very general mission statement -- or an even higher-level motivator for working in this space -- perhaps, but that has essentially no effect on design choices here. If the point of all this has essentially no effect on design choices, we have a serious problem. It's all very well do do things right, but we have to make sure we're doing the right thing too. Protecting users does not automatically or necessarily entail presenting spoofing/validity information to those users. In practical and operational terms, the point of all this is to allow filtering engines to make better decisions about possibly-spoofed mail. ... and again, if those decisions result merely in rejecting a message, the user isn't involved, but as soon as those decisions can result in tagging a message for possible consideration by the user (probably via different display by the UI), we can't ignore the user. The presumption that 'tagging a message for possible consideration by the user' is in any way relevant or helpful is problematic. Highly problematic. I agree that this isn't the place to delve deeply into user behaviour and UI design. But we shouldn't ignore the context of our work. Any consideration here, which leads to assumptions or expectations of things being presented to end users for their consideration, is a pure distraction -- at its best. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
On Tue, Mar 24, 2015 at 2:19 PM, Anne Bennett a...@encs.concordia.ca wrote: But yes, the ideal situation is where we sort every message correctly and unambiguously. Meanwhile... Even if we grant that p=quarantine is a problem WE cause, the fact is that until we have a *good* solution for mailing lists, most of us don't dare publish p=reject, which leaves us with p=none, or no DMARC records at all. Which means that (a) many of us cannot benefit from using DMARC under the current circumstances, and (b) many sites don't have the resources to implement it yet, but we still have to deal with their mail. I'm not willing to throw the baby out with the bathwater. +1. To be a bit flippant about it: Now that we have everyone's attention, possibly moreso than ever before, maybe it's possible to come up with a compromise that all corners of the email ecosystem can accept. But that doesn't mean we need to settle for creating schisms in that ecosystem. Entrenching is not the answer. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
Dave, You make an assumption about user assumptions. Forgive me, but I doubt you have a reliable, objective, empirical basis for making that assertion or much that derives from it. In fact there's a reasonable chance that your assumption is flawed. I have a 24-year-long parade of users worried that their account was compromised because they're receiving bounces for spam they never sent, wondering why their best friend is suddenly sending them ads or malware, or responding to phish messages. In the first two cases, they believe the From: header when they shouldn't; in the last case, too often they don't even look at the domain in the From: header. I haven't kept incident stats, so I cannot give you data that we could reliably use to measure the likely effectiveness of one approach or another, but my experience is objective and empirical, in the sense of having been acquired by means of observation or experimentation. But we're straying from the topic, which is indeed to come up with technical specs that software can obey. Having said that: One could argue, I suppose, that once again we're talking about the behaviour of software, but the point of all this, unless I woefully misunderstand, is to protect the user from fraud due to the faked provenance of a message. As a very general mission statement -- or an even higher-level motivator for working in this space -- perhaps, but that has essentially no effect on design choices here. If the point of all this has essentially no effect on design choices, we have a serious problem. It's all very well do do things right, but we have to make sure we're doing the right thing too. In practical and operational terms, the point of all this is to allow filtering engines to make better decisions about possibly-spoofed mail. ... and again, if those decisions result merely in rejecting a message, the user isn't involved, but as soon as those decisions can result in tagging a message for possible consideration by the user (probably via different display by the UI), we can't ignore the user. I agree that this isn't the place to delve deeply into user behaviour and UI design. But we shouldn't ignore the context of our work. Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 a...@encs.concordia.ca+1 514 848-2424 x2285 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
J. Gomez writes: I think we are not talking about the same thing: when I said depends on DMARC's success, I meant depends on DMARC's success as an implemented technology in the real world, whereas it seems you understood depends on a successful DMARC check. No, we are talking about the same thing. What I am saying is that DMARC is already a success as an implemented technology in the real world by any reasonable standard, because it *does* work for exactly the transactional mail flows you worry about. And it is possible to *prove* that it does work by looking at the properties of checks for individual messages. On the other hand, DMARC and similar technologies *cannot* solve the problem of spam and other abuse by those with whom you've had no previous relationship. That's easy to prove too: anybody with access to a DNS server can add DMARC and DKIM records and sign their mail. Mailing lists (among other indirect mail flows) do have problems interacting with DMARC, and it's worth trying to solve those problems. But they are not going to reverse DMARC's success. I know that DMARC is not the silver bullet. If you know that, I do not understand how you can classify DMARC as anything but a success. I'm an MLM developer; I hate p=reject with a passion. But I can't deny that for the vast majority of mail, DMARC works as advertised, p=reject included. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
For nearly 10+ years we have discussed the same basic design issues. Nothing has changed other than the fact it is DMARC, as it is currently written as the replacement protocol for a DKIM POLICY SSP/ADSP framework, is very lacking intentionally. We don't have enough of the advocates we once had, pushing the COMPLETE DKIM POLICY FRAMEWORK concept. Either they got tired walked away, they saw can't beat a dead horse or realize the people in IETF control were pushing other ideas that were not necessarily wrong, but they PUT barriers up to support the AUTHOR domain framework. We will not move forward in a major way until the 3rd party SIGNATURE authorization methodology is worked out. It was a thorn on the side then and it continues to be a thorn on the side today. We have quite a few RFCs related to DKIM signature methodologies and we never did properly resolved it (3rd party signers) because the key folks running the show were pushing a 3rd party TRUST methodology. They were militarily adamant about making sure the AUTHOR domain would not be dictating anything, hence the DKIM myth the AUTHOR DOMAIN was not related to the DKIM SIGNER AUTHENTICATION and AUTHORIZATION. That SEPARATION was impossible to ACHIEVE because the AUTHOR was a minimal hash binding requirement. But today, the TRUST part has gone no where, i.e. VBR was the closest thing to a DKIM TRUST model (we support it, do you?). It was AUTHOR POLICY that has prevailed but DMARC crippled it by sticking with the same problems ADSP had. Add 3rd party POLICY extensions and we will begin to get sensible software solutions again. We done it with ADSP/ATPS. So can large boys too with DMARC/ATPS. Add ATPS support or similar and we will begin to move forward with a framework for proper SOFTWARE CHANGE at the MLM. Wasting too much time again. Just update ATPS for DMARC and get MURRY to support the idea and maybe we will get others to get it a try. But if he is going to continue to block it, talk negative about it, well, we have a technical marketing problem that is not representative of a good technical, plug and play, easier solution for DKIM SIGNATURE AUTHORIZATION PROTOCOL. -- HLS On 3/24/2015 4:38 PM, J. Gomez wrote: On Tuesday, March 24, 2015 5:14 PM [GMT+1=CET], Stephen J. Turnbull wrote: J. Gomez writes: I think we are not talking about the same thing: when I said depends on DMARC's success, I meant depends on DMARC's success as an implemented technology in the real world, whereas it seems you understood depends on a successful DMARC check. No, we are talking about the same thing. What I am saying is that DMARC is already a success as an implemented technology in the real world by any reasonable standard, because it *does* work for exactly the transactional mail flows you worry about. I do not agree. As long a major ESPs downgrade p=reject to p=quarantine or even p=none on reception of email which fails DMARC checks from domains whose Owner has published p=reject, DMARC is little more than a reporting protocol as Vlatko Salaj has already said in another post to this list. Which is nice, but is not a success as an implemented technology in the real world for DMARC, because DMARC aims to be more than just a reporting tool. I know for sure I will publish only p=none for my client's domains, and use DMARC only as a reporting tool, as long as DMARC's p=reject cannot be reliably relied on. But I would love to be able to reliably rely on DMARC's p=reject. In fact, I think that if at the end of all this process we cannot find a way to make p=reject to be reliably relied on, then p=reject should be suppressed from the DMARC formal specification, as p=reject would effectively be equal to p=do-whatever-who-cares. Regard, J.Gomez ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
J. Gomez writes: On Tuesday, March 24, 2015 7:02 PM [GMT+1=CET], Stephen J. Turnbull wrote: From-munging is hardly open-and-shut philosophically legitimate. It has its advocates, but it sucks for many users because of the way their MUAs handle it, it arguably violates RFC 5322, and is ugly to boot. Well, it seems to me the above paragraph could also be written like this: MLM taking ownership of the Header-From (a.k.a. From-munging in your terms) has its detractors, but it works fine for many users who don't have a problem with it, arguably conforms to RFC 5322, and looks just nice. OK, well, we'll just have to agree to disagree. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
Steve Atkins writes: Mailing lists are only an issue if the domain owner of the email addresses of the participants have published a DMARC p=reject record, despite having actual users who are legitimate source of email that fails authentication. False. Mailing lists only have an obvious problem if p=reject is published, but DMARC doesn't say that you can't differentiate between aligned mail and unaligned mail, only that you can't differentiate between a failed signature verification and no signature at all. Sites can and do assign negative spam points to verified signatures, so there is a (smaller, but still real) problem for MLs even if nobody publishes p=reject. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
J. Gomez writes: given that the traditional practice of mailing lists adding tags to Subject and footers to the message body breaks DMARC, [...] I vote for steam-rolling mailing lists configured old-style to the history books. Mailing list operators just need to take ownership in the Header-From for the messages whose DKIM signature they break, and all is back to working great again! In most cases it would be inappropriate for mailing lists to take ownership of the messages. They are merely the distribution mechanism, and wrecking (IMHO) the From: header to avoid a verification failure seems the wrong way to go in the long run, even if it has had to be adopted as a workaround in the short run. As for subject tags and list trailers, at least the former is really helpful to me as a user (sorry, Dave! ;-) ), as it lets me know that a given message is in the context of a public or semi-public discussion. I'm not against the idea that mailing list software might have to adapt to the new reality (of the need for protection against spoofing), even though there will be a lengthy transition period. But we can also consider whether there are any changes to DKIM which would enable mailing lists not to break, or at least, which would not require changes which negatively affect the user experience for mailing list subscribers. Please forgive me if this has been discussed before (it seems inconceivable to me that it hasn't), but it should be possible to specify a format for header tags such that the tag is not included in the DKIM signature check for the Subject: line. rfc6376 has: Note that Verifiers may treat unsigned header fields with extreme skepticism, including refusing to display them to the end user or even ignoring the signature if it does not cover certain header fields. Would it be so awful to change that to: Note that Verifiers may treat unsigned header fields (or unsigned parts of header fields) with extreme skepticism, including refusing to display them to the end user, displaying them with an indication of unreliabiliy, or even ignoring the entire signature if it does not cover certain header fields. So, risking Dave's wrath once again by discussing possible UI approaches to verification information, if a header tag format were specified (for example) to be contained within square brackets, the UI could display the verified part one way, and the tagged-and-ignored part another way. I do freely admit that I don't know the implications of making it possible to sign only part of a given header. And I suspect that my suggestion may belong more on a DKIM discussion list than a DMARC discussion list... Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 a...@encs.concordia.ca+1 514 848-2424 x2285 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
On 3/24/2015 11:23 AM, Anne Bennett wrote: In most cases it would be inappropriate for mailing lists to take ownership of the messages. They are merely the distribution mechanism, and wrecking (IMHO) the From: header to avoid a verification failure seems the wrong way to go in the long run, even if it has had to be adopted as a workaround in the short run. Formally and practically, they are more than mere re-distributors. A mailing list typically defines a 'community' for discussion. At least some of the modifications it does are to assert that community in some visible ways. Mailing lists therefore have the right to make the changes they make. That said, recipients consider the message to be 'from' and 'by' the original author, not the mailing list. As for subject tags and list trailers, at least the former is really helpful to me as a user (sorry, Dave! ;-) ), as it lets Huh? I /like/ Subject tags. They help to distinguish list mail from personal mail. me know that a given message is in the context of a public or semi-public discussion. Right. I'm not against the idea that mailing list software might have to adapt to the new reality (of the need for protection against spoofing), even though there will be a lengthy transition period. I think the historical challenge has less been a case of philosophical legitimacy and more of inability to gain active, constructive participation of mailing list software maintainers. rfc6376 has: Note that Verifiers may treat unsigned header fields with extreme skepticism, including refusing to display them to the end user or even ignoring the signature if it does not cover certain header fields. Would it be so awful to change that to: Note that Verifiers may treat unsigned header fields (or unsigned parts of header fields) with extreme skepticism, including refusing to display them to the end user, displaying them with an indication of unreliabiliy, or even ignoring the entire signature if it does not cover certain header fields. So, risking Dave's wrath once again by discussing possible UI approaches to verification information, if a header tag format were specified (for example) to be contained within square brackets, the UI could display the verified part one way, and the tagged-and-ignored part another way. This is less a case of wrath -- should I be glad of such de facto and automatic intimidation, even when it doesn't work well enough to squelch others' views I disagree with? Hmmm... -- and more a case of efficacy. To make any assertions about preferred or appropriate UI behavior is to require establishing the basis that the behavior will be useful. The problem here is that the empirical basis for efficacy is lacking. So making a recommendation might serve to make the specification writers feel better, but they won't help fight abuse. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
On Tuesday, March 24, 2015 5:14 PM [GMT+1=CET], Stephen J. Turnbull wrote: J. Gomez writes: I think we are not talking about the same thing: when I said depends on DMARC's success, I meant depends on DMARC's success as an implemented technology in the real world, whereas it seems you understood depends on a successful DMARC check. No, we are talking about the same thing. What I am saying is that DMARC is already a success as an implemented technology in the real world by any reasonable standard, because it *does* work for exactly the transactional mail flows you worry about. I do not agree. As long a major ESPs downgrade p=reject to p=quarantine or even p=none on reception of email which fails DMARC checks from domains whose Owner has published p=reject, DMARC is little more than a reporting protocol as Vlatko Salaj has already said in another post to this list. Which is nice, but is not a success as an implemented technology in the real world for DMARC, because DMARC aims to be more than just a reporting tool. I know for sure I will publish only p=none for my client's domains, and use DMARC only as a reporting tool, as long as DMARC's p=reject cannot be reliably relied on. But I would love to be able to reliably rely on DMARC's p=reject. In fact, I think that if at the end of all this process we cannot find a way to make p=reject to be reliably relied on, then p=reject should be suppressed from the DMARC formal specification, as p=reject would effectively be equal to p=do-whatever-who-cares. Regard, J.Gomez ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
On Tue, Mar 24, 2015 at 1:38 PM, J. Gomez jgo...@seryrich.com wrote: I know for sure I will publish only p=none for my client's domains, and use DMARC only as a reporting tool, as long as DMARC's p=reject cannot be reliably relied on. But I would love to be able to reliably rely on DMARC's p=reject. I'm not sure I agree with the claim that p=reject is unreliable. It seems to me that it's working as designed, and the results are deterministic. It's not flaky. How receivers use it is the mushy part, but that's really outside of the protocol. Even if DMARC didn't have these mediator problems, there still would be no ultimate compulsion for receivers to do what domain owners ask. It might be a lot more likely that they would comply without reservations, but there would still be some operators that don't. So just to be clear, are you using reliable here to talk about how receivers apply it? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
Dave Crocker writes: A mailing list typically defines a 'community' for discussion. At least some of the modifications it does are to assert that community in some visible ways. Sure, but From-munging is not an assertion of community, it's an assertion that there's a war out there, and the community is taking hits from friendly fire. Mailing lists therefore have the right to make the changes they make. That's an incomplete statement. They have the right to make the changes as long as they are compatible with community standards. For example, some lists provide advertising space in the footer. Others would have a revolution if you tried. From-munging is just not part of the community standard in most lists I participate in (and I've heard that some Yahoo! and AOL users object violently to the mitigations used to keep their posts from bouncing all over the world). Anne Bennett: I'm not against the idea that mailing list software might have to adapt to the new reality (of the need for protection against spoofing), even though there will be a lengthy transition period. Hardly. It's already done, at least in GNU Mailman: all of the transformations that invalidate DKIM signatures are optional. From-munging was *released* in October 2013 (in 2.1.16 IIRC). That's right, *before* the April DMARC Debacle. We have continued to refine the features (it's now possible in 2.1.18-1 to condition mitigations on a DNS lookup for p=reject). The software is not the problem. The list owners and list subscribers are. Back to Dave: I think the historical challenge has less been a case of philosophical legitimacy From-munging is hardly open-and-shut philosophically legitimate. It has its advocates, but it sucks for many users because of the way their MUAs handle it, it arguably violates RFC 5322, and is ugly to boot. Nevertheless, GNU Mailman has a From-Munging option.[1] and more of inability to gain active, constructive participation of mailing list software maintainers. Hey, I resent that. You guys use GNU Mailman; you know where to find us if you want participation. Sure, we resist doing what is proposed. The fact is that choices we've been offered suck. Go away (the choice offered by experimental early versions of SPF)? You jest. From-Munging? Yuck -- and guess what, you're no fan, yourself. No subject tags, no footers? Excuse me, but prohibiting a valuable feature is exactly the opposite of a constructive change -- and you don't like this mitigation yourself. Note that these mitigations are now in GNU Mailman, as options. But most list owners don't want them. We've come up with our own (RFC-conforming) mitigations. They suck, too (MUAs are not prepared to deal with them gracefully, or in the case of iOS Apple Mail, at all). It's not the MLM developers you have a problem getting cooperation from. It's our users. Bottom line: making indirect mail flows compatible with DMARC-style spoof-protection is a hard problem. Footnotes: [1] Patch courtesy of Franck Martin. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
-Original Message- From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of J. Gomez Sent: Tuesday, March 24, 2015 4:39 PM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) On Tuesday, March 24, 2015 5:14 PM [GMT+1=CET], Stephen J. Turnbull wrote: J. Gomez writes: I think we are not talking about the same thing: when I said depends on DMARC's success, I meant depends on DMARC's success as an implemented technology in the real world, whereas it seems you understood depends on a successful DMARC check. No, we are talking about the same thing. What I am saying is that DMARC is already a success as an implemented technology in the real world by any reasonable standard, because it *does* work for exactly the transactional mail flows you worry about. I do not agree. As long a major ESPs downgrade p=reject to p=quarantine or even p=none on reception of email which fails DMARC checks from domains whose Owner has published p=reject, DMARC is little more than a reporting protocol as Vlatko Salaj has already said in another post to this list. Which is nice, but is not a success as an implemented technology in the real world for DMARC, because DMARC aims to be more than just a reporting tool. Mailbox providers/ISPs are going to do what they do. Recognizing local policy is one of the reasons that the large mailbox providers/ISPs decided to validate DMARC and play ball. By and large they get it right (at least in my experience and I've been doing DMARC since before it was public). Even for transactional mail from originators which have control over their mail flows, there will always be some small percentage of mail that gets broken because of certain types of forwarding (beyond mail lists). From my perspective, when a mailbox provider/ISP chooses to implement local policy over my request (through a published p=reject policy) then they are taking responsibility for their decision. To demand more from them is simply unrealistic. Any organization can publish a standard - the real proof is the extent to which people adopt that standard. I know for sure I will publish only p=none for my client's domains, and use DMARC only as a reporting tool, as long as DMARC's p=reject cannot be reliably relied on. But I would love to be able to reliably rely on DMARC's p=reject. My experience is that the overwhelming majority of time you can reliably rely on DMARC's policy implementation - and I'm looking at a corpus of Billions of sent mail. You can check this yourself by looking at the reporting you receive. If mailbox providers would have overridden your p=reject it will show in the reporting you receive and you can gauge the potential outcome yourself. You are making assertions that the data doesn't support. Mailbox providers have no incentive to randomly override DMARC with local policy for non-trivial reasons. The real problem is that once you get past the top mailbox providers, the remainder of them don't have the resources/expertise/large enough data sets to implement local policy overrides in a manner that is workable and sustainable. Perhaps someone can make a go of offering this as a service - perhaps not. In fact, I think that if at the end of all this process we cannot find a way to make p=reject to be reliably relied on, then p=reject should be suppressed from the DMARC formal specification, as p=reject would effectively be equal to p=do-whatever-who-cares. Mike ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
On 3/23/2015 3:15 AM, Murray S. Kucherawy wrote: I'm not disagreeing, but I'm not sure where you're going with this... As always, I'm seeking to have thinking and discussion focus on software behavior, not user behavior. Any discussion of end user perception or behavior is distracting to meaningful analysis or development of technologies like DMARC. At a minimum, a reference to users tends to cause people to project benefits that will not accrue. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
J. Gomez writes: But do you think the general email-using population will be happy to miss authentic email from eBay, Amazon, Paypal and American Airlines, just to get email from some mailing list(s) delivered to their inbox? I don't see why enabling mailing lists to continue their traditional practice of adding tags to Subject and footers to the message body would cause any problems whatsoever for authentic direct mail from the businesses you mention. You say that as if a solution that works but you don't like is not a solution but a kludge. It is. A *solution* is a practice or product that satisfies user requirements. If there's only one such user, OK, you can say tough on you. However, *many* mailing list users wish to have the author's address in From where it will be automatically and naturally used for reply-to-author in almost all MUAs. As far as I know there is no configuration of From and Reply-To that satisfies this requirement in all use cases. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
Anne, On 3/23/2015 3:07 PM, Anne Bennett wrote: But if the message is delivered, either because it passes DMARC, or it fails but is quarantined, then the receiver will see the message, and will make assumptions regarding the authenticity of its origin based, most likely, on the From: header. It seems Unfortunately, user references for this sort of work have no productive use to that work, but instead often prove counter-productive. You make an assumption about user assumptions. Forgive me, but I doubt you have a reliable, objective, empirical basis for making that assertion or much that derives from it. In fact there's a reasonable chance that your assumption is flawed. That's why I keep stressing the importance of keeping user references out of these discussions. They are not helpful to the work and they are distracting. not unreasonable to suppose that the writer of a user interface would want to indicate somehow to the user that the message was (or was not) vetted as coming from where it says it came from. The DMARC results seem like an obvious source of information for such an indication. Not unreasonable' is a common justification for UI design choices. The reality of successful UI design is that many choices that are not unreasonable don't work or work poorly. Consequently, not unreasonable is a singularly insufficient justification. At the very best, it can serve to provide input to experimental processes that investigate actual efficacy. One could argue, I suppose, that once again we're talking about the behaviour of software, but the point of all this, unless I woefully misunderstand, is to protect the user from fraud due to the faked provenance of a message. As a very general mission statement -- or an even higher-level motivator for working in this space -- perhaps, but that has essentially no effect on design choices here. In practical and operational terms, the point of all this is to allow filtering engines to make better decisions about possibly-spoofed mail. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
Dave Crocker writes: As always, I'm seeking to have thinking and discussion focus on software behavior, not user behavior. Any discussion of end user perception or behavior is distracting to meaningful analysis or development of technologies like DMARC. I can't entirely agree, though I'm not without sympathy to your point of view. DMARC is obviously intended to be applied by the software, and it's tempting to think that the message is either accepted or rejected, end of story, so this shouldn't affect the user interface or user behaviour. In practice I don't think it's that simple. Of course, because of the way DMARC is applied (in the DNS) and messages are signed (by the ISP), the sending user is not of concern here. The expressed concerns center on the perceptions and behaviour of the receiving user. If p=none (or if DMARC is not used), then the receiving user gets the message (modulo other de-spamming techniques), but nothing can be implied about its authenticity, so nothing changes with respect to the non-DMARC behaviour (of the software or the user!). And if the message is rejected due to p=reject, then the user never gets the message at all, so we needn't be concerned with the receiving user's behaviour. But if the message is delivered, either because it passes DMARC, or it fails but is quarantined, then the receiver will see the message, and will make assumptions regarding the authenticity of its origin based, most likely, on the From: header. It seems not unreasonable to suppose that the writer of a user interface would want to indicate somehow to the user that the message was (or was not) vetted as coming from where it says it came from. The DMARC results seem like an obvious source of information for such an indication. One could argue, I suppose, that once again we're talking about the behaviour of software, but the point of all this, unless I woefully misunderstand, is to protect the user from fraud due to the faked provenance of a message. I don't think it will ever be the case that we can sort 100% of messages as authentic or fake before they reach the user; we have to accept that even if we block the known fakes based on DMARC, there will still be authenticated and not-checkable messages that reach the user - and ideally we'd have a way to indicate which are which. Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 a...@encs.concordia.ca+1 514 848-2424 x2285 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
On Monday, March 23, 2015 7:02 AM [GMT+1=CET], Stephen J. Turnbull wrote: J. Gomez writes: But do you think the general email-using population will be happy to miss authentic email from eBay, Amazon, Paypal and American Airlines, just to get email from some mailing list(s) delivered to their inbox? I don't see why enabling mailing lists to continue their traditional practice of adding tags to Subject and footers to the message body would cause any problems whatsoever for authentic direct mail from the businesses you mention. Verifiable authenticity of email greatly depends on DMARC's success. Because without DMARC's success the authenticity of email can only be verified heuristically and not systematically. If mailing-lists configured old-style hinder the adoption and ultimate success of DMARC, then received email will not be able to be verified as authentic in any systematic way, but only heuristically. That greatly lessens the value of email as a viable medium for important[*] communications that users want to receive. [*] I define here important as: potentially expensive for the user if missed and/or potentially expensive for the user if successfully spoofed. Therefore, as per the above reasoning, given that the traditional practice of mailing lists adding tags to Subject and footers to the message body breaks DMARC, it is also breaking the mechanism (DMARC) which could take email to the next level as a viable medium for important communications. I vote for steam-rolling mailing lists configured old-style to the history books. Mailing list operators just need to take ownership in the Header-From for the messages whose DKIM signature they break, and all is back to working great again! You say that as if a solution that works but you don't like is not a solution but a kludge. It is. A *solution* is a practice or product that satisfies user requirements. If there's only one such user, OK, you can say tough on you. However, *many* mailing list users wish to have the author's address in From where it will be automatically and naturally used for reply-to-author in almost all MUAs. As far as I know there is no configuration of From and Reply-To that satisfies this requirement in all use cases. Well, I posit the user requirement is, at large, to take email to the next level a viable medium for important communications. Regards, J.Gomez ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
Verifiable authenticity of email greatly depends on DMARC's success. Because without DMARC's success the authenticity of email can only be verified heuristically and not systematically. Rehashing old arguments will not change anyone's mind. False assertions are like these are utterly useless. Please stop. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
On Monday, March 23, 2015 10:45 PM [GMT+1=CET], John Levine wrote: Verifiable authenticity of email greatly depends on DMARC's success. Because without DMARC's success the authenticity of email can only be verified heuristically and not systematically. Rehashing old arguments will not change anyone's mind. False assertions are like these are utterly useless. Please stop. To castle into old denial will not change anyone's mind, either. But please, go on. Regards, J. Gomez ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
J. Gomez writes: Verifiable authenticity of email greatly depends on DMARC's success. Because without DMARC's success the authenticity of email can only be verified heuristically and not systematically. This is an error of logic. *Authenticity* (defined as did the message satisfy DMARC From alignment when injected?) of *each* message *can* be verified independently of other messages, and if From alignment is verified, the message *is* authentic (modulo black helicopters with 4096-bit encryption breaking equipment). It's what to think about non-verifiable mail that becomes unclear. Since the important mail is direct mail, From alignment will be preserved until received by the addressee. Therefore list behavior only affects DMARC verifiability of list traffic, *not* those other mail flows, as far as I can see. Well, I posit the user requirement is, at large, to take email to the next level a viable medium for important communications. I understand what you're saying, and we all agree that email as we currently know it has an important role for Internet communication, and that for it to continue to fulfill that role we need to improve its security in several ways. But (as Dave Crocker is emphasizing in another subthread), we need to be very careful to define requirements in terms of what the software can do, and then do our best to define and implement protocols that satisfy the requirements and *prove* that the software does satisfy those requirements. The requirement you propose is not implementable in a software system alone, whether it is satisfied or not cannot be verified from the behavior of software alone, and therefore cannot be posited as a requirement in the sense used in software engineering. Please think about what I've written. It's a very useful way to think about software systems, and IETF discussions are normally phrased using this kind of language. If you don't use it, people will not know what you're talking about, and your ideas will not be picked up. Steve ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
On Saturday, March 21, 2015 3:36 PM [GMT+1=CET], Hector Santos wrote: As a long time total mail system product(s) developer, at this point, IMV, we have a marketing problem. We did have technical solutions laid out with 3rd party authorization concerns. However, it hasn't been sold enough and if even if you do work it, you have to champion it. One can't write documents nor work on ideas while still believing it won't work. If you (the authors) don't believe it, no one else will -- the bottom line. I consider that any 3rd party authorization scheme for DMARC will fail --not to fail technically, but to fail be implemented in the real world-- if it happens to need, to be workable, the nuanced and labour-intensive participation of the sender's domain Owner. Consider Yahoo and OAL reckless usage of p=reject. Why would they suddenly be any less reckless and choose to take into account any 3rd party authorization scheme for DMARC? Do we have any hint from big ESPs currently using p=reject that they are willing to take into account any 3rd party authorization scheme for DMARC? If not, we have the risk to taking the effort to design a great 3rd party authorization scheme for DMARC which ultimately will fail to be taken into account in any significant way in the real world. So, Hector, no matter how good marketing is, it is going to be next to impossible to sell something which is nuanced and labour-intensive, and at the same time provides little --perceived-- reward to the agents tasked with implementing it and keeping it current and running in a well-oiled fashion. Regards, J.Gomez ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
On Saturday, March 21, 2015 10:31 PM [GMT+1=CET], John Levine wrote: How big is the volume of DMARC-problematic indirect email flows, compared to the general volume of email which can readily benefit from DMARC? The numbers I've seen say that the volume of mail that DMARC screws up is fairly low, but it is very high value. Personally, I would be happy never to get any more mail from my bank, if it meant that my mailing lists would work again. But do you think the general email-using population will be happy to miss authentic email from eBay, Amazon, Paypal and American Airlines, just to get email from some mailing list(s) delivered to their inbox? Also, your mailing list would work again in a heartbeat, in a DMARC-world, if you just configured them to put the original Header-From into the description of a new Header-From, like: From: Pedro Antunez pe...@example.com == From: Pedro Antunez pe...@example.com l...@domain.com It's about time that MLM software that modifies the in-flight message, rendering its DKIM signature invalid, takes ownership as Author of the new modified message they are resending. Regards, J.Gomez ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
But do you think the general email-using population will be happy to miss authentic email from eBay, Amazon, Paypal and American Airlines, just to get email from some mailing list(s) delivered to their inbox? My impression is that most users put a very low value on commercial bulk mail. I'm not aware of any statistics available to the public. Also, your mailing list would work again in a heartbeat, in a DMARC-world, if you just configured them to put the original Header-From into the description of a new Header-From, like: We are aware of the various kludges to circumvent DMARC breakage. We have a whole wiki about them at http://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail Rehashing them here and asserting that they are solutions rather than kludges would not be productive. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
Dave Crocker writes: On 3/22/2015 1:39 PM, Stephen J. Turnbull wrote: I took you to mean that the relationship between the purported identity in From, based on the address in that field, and the user's behavior is irrelevant to specification of DMARC and related protocols. I didn't say that, but I'll say it now, too. (Ignoring the underying truth that users get tricked, which provides the motivation for worrying about spoofing.) Ignoring motivation was appropriate for Milestone 1, which was concerned with ensuring a lack of ambiguity in RFC 7489, which has a well-defined set of requirements. But we are now looking at next steps, ie, a new set of requirements, because implementing the RFC 7489 requirements turned out to be insufficient to enable many use cases people participating in this WG care about, and to have some rather nasty side effects in combination with preexisting systems. I think discussion of motivation and agent (not limited to mail recipients) behavior is exactly what is needed at this stage, even if it's rather speculative and not founded in formal user interface research. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
On Fri, Mar 20, 2015 at 4:40 PM, Dave Crocker d...@dcrocker.net wrote: On 3/19/2015 12:52 PM, Murray S. Kucherawy wrote: And since the From field is the only one users really see every time, I'm not sure that declaring and supporting yet another no-seriously-this-is-the-author field would be of benefit. I'd like to try to get us to phrase this differently. In particular, it does not matter what user's 'see'. The information is processed by a filtering agent, independent of the user. So what matters is that the From: field domain is the only field certain to be provided by the author. Isn't it important that this information is also the most likely to be presented to the end user as the author of the content that's also shown to the user? Why do you claim it doesn't matter? There would be a lot less incentive to be concerned about From: alignment if that were not the case. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
Dave Crocker writes: From: happens to be the only place that always has the presence of a domain associated with the origin. Except it doesn't always have a domain associated with the originating MTA, and there's nothing in RFC 5322 that says it does. RFC 5322 says you shouldn't put an address in From that you don't have the right to use, not that it must be aligned with the domain of the injecting MTA. So I must be missing something, because it seems to me that you've got the DMARC From alignment tail wagging the whole RFC 5322 dog here. And note that without DMARC, these days users typically don't see the domain. In other words, it isn't presented to the user. This inconvenient fact is ignored or dismissed every time someone touts the user's role in DMARC. What's so inconvenient about it? I'm apparently missing something, but I don't see how the fact that the domain sometimes isn't presented is particularly inconvenient for the position that user behavior matters. Specifically, in many cases failure to present the domain as a character string doesn't mean that the displayed identity isn't associated with the address in some way such as presentation of an avatar looked up by address, or in a tool-tip. There may be other subtle channels by which the address can influence user behavior without being displayed as a character string. And sometimes it is presented as a string. Note that these subtle channels are MUA functions, and thus outside the purview of current MTA-based DMARC implementations. I think it's quite valid to emphasize the user's role here. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
As a long time total mail system product(s) developer, at this point, IMV, we have a marketing problem. We did have technical solutions laid out with 3rd party authorization concerns. However, it hasn't been sold enough and if even if you do work it, you have to champion it. One can't write documents nor work on ideas while still believing it won't work. If you (the authors) don't believe it, no one else will -- the bottom line. Just consider that DMARC has a problem that all the previous POLICY FRAMEWORKS long had. So how could DMARC replaced ADSP as the Super ADSP when ADSP was abandoned by the key DKIM people within the IETF? It does the same thing, same problem? How was that possible? Marketing. DMARC did have the REPORTING part that we intentionally left out in coming up with SSP/ADSP. The view was it would eventually could be abused and most certainly it would be become a high overhead redundant reporting feature -- can't be reporting forever. Thats the one thing I believe I underestimated when I strongly supported and implemented the previous DKIM policy ideas such as SSP and ADSP and also my I-D DSAP (DKIM Signature Authorization Protocol) where some of the initial MLM interfacing ideas were written down. Overall, you got to have a solid protocol first that makes sense independent of any mail component that touches mail. I believe we had something with DKIM + POLICY but it requires you to change the the MLM software or its frontend interface to follow the POLICY concept. Until that happens, nothing is going to change. -- HLS On 3/20/2015 4:56 PM, J. Gomez wrote: On Wednesday, March 18, 2015 11:40 PM [GMT+1=VET], Douglas Otis wrote: Dear DMARC WG, Now that RFC7489 has been published, there remains several unresolved problems this WG is charted to resolve, primarily-- 1. Addressing the issues with indirect mail flows Why is it better for DMARC to be adapted to indirect email flows, instead of indirect email flows to be adapted to DMARC? What does provide more value to end users at large: indirect email flows to be kept old-style, or the extra notch of trustworthiness that DMARC alignment provides? How big is the volume of DMARC-problematic indirect email flows, compared to the general volume of email which can readily benefit from DMARC? Regards, Regards, J.Gomez ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
How big is the volume of DMARC-problematic indirect email flows, compared to the general volume of email which can readily benefit from DMARC? The numbers I've seen say that the volume of mail that DMARC screws up is fairly low, but it is very high value. Personally, I would be happy never to get any more mail from my bank, if it meant that my mailing lists would work again. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
On 3/21/2015 9:41 AM, Stephen J. Turnbull wrote: Dave Crocker writes: From: happens to be the only place that always has the presence of a domain associated with the origin. Except it doesn't always have a domain associated with the originating MTA, Well, I said 'origin' and not 'originator' but yeah, I should have thought of a more generic term. I meant not to invoke 'originator' and meant mean something around the creation of the message, such as author, originator, gateway mta, whatever...[*] and there's nothing in RFC 5322 that says it does. RFC 5322 says you shouldn't put an address in From that you don't have the right to use, not that it must be aligned with the domain of the injecting MTA. Thanks for the refresher. So I must be missing something, because it seems to me that you've got the DMARC From alignment tail wagging the whole RFC 5322 dog here. No idea what you mean. And note that without DMARC, these days users typically don't see the domain. In other words, it isn't presented to the user. This inconvenient fact is ignored or dismissed every time someone touts the user's role in DMARC. What's so inconvenient about it? Folks tend to promote DMARC's choice of From field due to the fact that it's presented to the end-user, as if the end-user will behave differently with DMARC active. The end-user won't. They mostly don't see the domain name, and it mostly doesn't matter when they do. On the other hand, the fact that the From field is the only domain name reliably associated with content creation and that receiving filtering engines can do an assessment of validity when DMARC validates, is extremely meaningful. But there is no 'user' in the handling equation for DMARC. There may be other subtle channels by which the address can influence user behavior without being displayed as a character string. And sometimes it is presented as a string. Note that these subtle channels are MUA functions, and thus outside the purview of current MTA-based DMARC implementations. I think it's quite valid to emphasize the user's role here. Subtle channels is a fun idea. Unfortunately there is an infinite number of fun ideas. Perhaps you can cite some empirical research evidence of its relevance to this topic? d/ [*] However note that the essence of DMARC is a /very/ tight coupling between content author's domain owner and the originator. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
J. Gomez writes: Why is it better for DMARC to be adapted to indirect email flows, instead of indirect email flows to be adapted to DMARC? Because they *can't* be adapted by definition. DMARC p=reject prohibits indirect mail, and p=quarantine sends it to the spam bucket. Or perhaps you're thinking of the same thing that Douglas is. To him, I suppose adapting DMARC includes third-party authorization mechanisms. I consider those actually to be adapting DMARC because they require participation of the first party. YMMV, you may consider that adapting indirect mail because often it will be initiated by the 3rd party applying for authorization. However, several proposals have been made for limited authorization by mailbox owners who can't actually change the DMARC policies of the authorizing domain. These also require participation of the authorizing domain but not necessarily the third party. So I prefer our interpretation that TPA is adapting DMARC. Steve ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
On Wednesday, March 18, 2015 11:40 PM [GMT+1=CET], Douglas Otis wrote: Dear DMARC WG, Now that RFC7489 has been published, there remains several unresolved problems this WG is charted to resolve, primarily-- 1. Addressing the issues with indirect mail flows Why is it better for DMARC to be adapted to indirect email flows, instead of indirect email flows to be adapted to DMARC? What does provide more value to end users at large: indirect email flows to be kept old-style, or the extra notch of trustworthiness that DMARC alignment provides? How big is the volume of DMARC-problematic indirect email flows, compared to the general volume of email which can readily benefit from DMARC? Regards, Regards, J.Gomez ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
On Friday, March 20, 2015 09:56:15 PM J. Gomez wrote: On Wednesday, March 18, 2015 11:40 PM [GMT+1=CET], Douglas Otis wrote: Dear DMARC WG, Now that RFC7489 has been published, there remains several unresolved problems this WG is charted to resolve, primarily-- 1. Addressing the issues with indirect mail flows Why is it better for DMARC to be adapted to indirect email flows, instead of indirect email flows to be adapted to DMARC? What does provide more value to end users at large: indirect email flows to be kept old-style, or the extra notch of trustworthiness that DMARC alignment provides? How big is the volume of DMARC-problematic indirect email flows, compared to the general volume of email which can readily benefit from DMARC? I think it's fair to say it varies a lot. I took a look at the reports for my personal domain for roughly the last week. All the mail was SPF pass, DKIM signed, and aligned went sent. Here's the numbers (keep in mind that receivers are likely to count multiple recipients of mailing list messages as multiple message - I don't actually write 5,000 emails a week): Total: 5,029 My Serverss: 6 Mail List/Forwarded SPF and DKIM fail: 5,022 Mail List DKIM pass: 1 In my case (since a lot of my mail is via email lists) it's essentially all of it. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
On Fri, Mar 20, 2015 at 1:56 PM, J. Gomez jgo...@seryrich.com wrote: Why is it better for DMARC to be adapted to indirect email flows, instead of indirect email flows to be adapted to DMARC? What does provide more value to end users at large: indirect email flows to be kept old-style, or the extra notch of trustworthiness that DMARC alignment provides? How big is the volume of DMARC-problematic indirect email flows, compared to the general volume of email which can readily benefit from DMARC? I'm pretty sure volumes are not the problem as much as the painful side effects, most notably unsubscription of uninvolved users from mailing lists when someone protected by DMARC posts to the list. (See Section 5.2 of RFC6377, which describes the same problem in the context of ADSP. RFC7372 might help with this, if and when it ever gets widely implemented.) My own view is that we should pursue whichever of the two avenues is the lower-hanging fruit. The problem at the moment is that it's not at all clear to me which of the two that is. We have among us implementers of both MLM packages and DKIM/SPF packages and standards, so at least the right people are in the room. There are, however, substantial barriers in both directions. We definitely have our work cut out for us. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
On Wed, Mar 18, 2015 at 4:38 PM, Terry Zink tz...@exchange.microsoft.com wrote: If bulk email providers have shown no interest in promoting a solution, why do we think they'd latch onto this new non-aligned header field as a solution? +1. And since the From field is the only one users really see every time, I'm not sure that declaring and supporting yet another no-seriously-this-is-the-author field would be of benefit. Rather, I think it would just confuse things further. The closest thing I can see is considering use of Sender somehow, since there are even a few MUAs that do pay vague attention to it. But that's extremely hand-wavy to start with. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
On Mar 18, 2015, at 4:38 PM, Terry Zink tz...@exchange.microsoft.com wrote: Based upon the almost complete lack of interest of bulk email providers at promoting a solution, it seems the path forward is to define a new non-aligned header field able to retain the author role information, otherwise the From is likely overwritten as the only practical means of ensuring message acceptance in the face of provider DMARC (ab)use. If bulk email providers have shown no interest in promoting a solution, why do we think they'd latch onto this new non-aligned header field as a solution? -- Terry Dear Terry, Thank you for your comment. This WG seems indicative of most bulk sender's who often ask How is DMARC's disruption of legitimate messaging a problem for me? They are clearly not interested in preserving the social and civic benefits derived from open exchanges enabled by email affected by the DMARC (ab)use occurring against millions of users. This is further evidenced by the current DMARC scheme that offers no strategy for preserving the role of Author for messages handled by various third-parties. Those operating a mailing-list are being forced to either reject a large percentage of their users, or replace the From header with what was likely to have been the Sender header field. The identity of the Author becomes undefined and might be moved to the Reply-to or perhaps x-original-from header fields. Unless DMARC defines a fallback policy which allows alignment with that of the Sender header field, the role of Author is placed at risk. In such cases, defining a special Non-Aligned From header field could help better define where this role might be found in a message without it being automatically displayed. This header field might even offer provisions for the tagging often found in the Subject header field. Perhaps call this new header field Author. Since few MUAs are likely to display this header, only those that make extensive use of email that depends on third-party services are likely to ensure it being displayed. An approach that would not require cooperation from Bulk senders, while still allowing forums a means to track a history of who said what. Regards, Douglas Otis -Original Message- From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Douglas Otis Sent: Wednesday, March 18, 2015 3:41 PM To: Murray S. Kucherawy Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) Dear DMARC WG, Now that RFC7489 has been published, there remains several unresolved problems this WG is charted to resolve, primarily-- 1. Addressing the issues with indirect mail flows These are reviewed by https://tools.ietf.org/html/draft-dmarc-interoperability-00 https://tools.ietf.org/html/draft-otis-dmarc-author-align-01 was written to highlight possible solutions. John Levine's recommendation that mailing-list operators take on the costly burden of having their participants change their providers is not practical. Based upon the almost complete lack of interest of bulk email providers at promoting a solution, it seems the path forward is to define a new non-aligned header field able to retain the author role information, otherwise the From is likely overwritten as the only practical means of ensuring message acceptance in the face of provider DMARC (ab)use. By defining a new header field, this should reduce disparity in where to find the author role than that caused by current ad hoc solutions. Such a definition would also better avoid downgrading 'reject' into 'quarantine'. Any thoughts? Regards, Douglas Otis ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
Dear DMARC WG, Now that RFC7489 has been published, there remains several unresolved problems this WG is charted to resolve, primarily-- 1. Addressing the issues with indirect mail flows These are reviewed by https://tools.ietf.org/html/draft-dmarc-interoperability-00 https://tools.ietf.org/html/draft-otis-dmarc-author-align-01 was written to highlight possible solutions. John Levine's recommendation that mailing-list operators take on the costly burden of having their participants change their providers is not practical. Based upon the almost complete lack of interest of bulk email providers at promoting a solution, it seems the path forward is to define a new non-aligned header field able to retain the author role information, otherwise the From is likely overwritten as the only practical means of ensuring message acceptance in the face of provider DMARC (ab)use. By defining a new header field, this should reduce disparity in where to find the author role than that caused by current ad hoc solutions. Such a definition would also better avoid downgrading 'reject' into 'quarantine'. Any thoughts? Regards, Douglas Otis ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)
Based upon the almost complete lack of interest of bulk email providers at promoting a solution, it seems the path forward is to define a new non-aligned header field able to retain the author role information, otherwise the From is likely overwritten as the only practical means of ensuring message acceptance in the face of provider DMARC (ab)use. If bulk email providers have shown no interest in promoting a solution, why do we think they'd latch onto this new non-aligned header field as a solution? -- Terry -Original Message- From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Douglas Otis Sent: Wednesday, March 18, 2015 3:41 PM To: Murray S. Kucherawy Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) Dear DMARC WG, Now that RFC7489 has been published, there remains several unresolved problems this WG is charted to resolve, primarily-- 1. Addressing the issues with indirect mail flows These are reviewed by https://tools.ietf.org/html/draft-dmarc-interoperability-00 https://tools.ietf.org/html/draft-otis-dmarc-author-align-01 was written to highlight possible solutions. John Levine's recommendation that mailing-list operators take on the costly burden of having their participants change their providers is not practical. Based upon the almost complete lack of interest of bulk email providers at promoting a solution, it seems the path forward is to define a new non-aligned header field able to retain the author role information, otherwise the From is likely overwritten as the only practical means of ensuring message acceptance in the face of provider DMARC (ab)use. By defining a new header field, this should reduce disparity in where to find the author role than that caused by current ad hoc solutions. Such a definition would also better avoid downgrading 'reject' into 'quarantine'. Any thoughts? Regards, Douglas Otis ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
