Re: [dmarc-ietf] non-mailing list use case for differing header domains
On 8/7/2020 7:32 PM, John Levine wrote: I would be interested to better undertstand the meaning of "need" here. It is my impression that most people vastly overestimate how much of a phish target they are. Paypal and big banks certainly are, other places, a lot less so. I suspect the calculus is less in the pragmatic terms of asking how big this threat is and more in terms of wishing for some version of protection and thinking this helps to achieve it. The degree to which so many folk embrace does not appear to have that much empirical basis, but rather a sense of feeling a need to do something and at first blush this seems to be something. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] non-mailing list use case for differing header domains
In article <78fd8b26-0bed-ac36-842d-a851ec04d...@wisc.edu> you write: >On 8/7/20 2:12 PM, John Levine wrote: >> My guess is that MIT figured Microsoft will host this for free, that's >> great, totally unaware that some of its users' mail would silently >> break. > >Customers of Microsoft don't like to call things bundled in an expensive >package "free". I have no idea what their pricing ie. My university uses Gmail for the alumni service and I believe that actually is free. >Maybe it was inflicted by the domain owner onto the person maintaining the >mailing list. (In my experience, this is >where people realize that no one has been maintaining/patching the mailing >list, unaware of DMARC, etc.) The IETF is entirely aware of DMARC, and their main mailing lists use a version of my dmarc.fail hack. This one's off in a corner, on the list of things to be cleaned up. >My peeve in recent years is that universities were essentially coerced >(economically) into being the customers of >Microsoft/Google and then the email admins are told to sit down and let the >adults talk about what they think customers >need from DMARC, ARC, etc. It's why I'm constantly sticking my foot in my >mouth here and M3AAWG; trying to assert a >voice. If it's not obvious, we do appreciate it. Way too many of them say whew, we can blame the vendor and not worry about it. >We need faculty/alumni/emeriti forwarding to work without being told that >Microsoft can't do it without breaking DMARC. Yup. >We need spoofing protection for all of our domains without being told we're >misdeploying. I would be interested to better undertstand the meaning of "need" here. It is my impression that most people vastly overestimate how much of a phish target they are. Paypal and big banks certainly are, other places, a lot less so. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] non-mailing list use case for differing header domains
In article <10c441a53dec4277a3153ed8d89d3...@bayviewphysicians.com> you write: >-=-=-=-=-=- > >Murray, I have most recently used this link at AOL/Yahoo: >https://postmaster.verizonmedia.com/sender-request > >I have considered using the more complete "Complaint Feedback Loop", >https://postmaster.verizonmedia.com/cfl-request >but have never completed the process. Complaint feedback loops just mean you say (perhaps with verification) that you're the contact for this range of IPs or domain names, and if a user presses the Junk button, the system can send you a copy of the report. It's not whitelisting, and it only covers about the first quarter inch of the long tail. Some years back people kept asking Spamhaus to set up a whitelist, so they hired me to do it. Technically it worked fine, but it soon became apparent that the only people who were interested weren't people who we'd want to whitelist. The good quality senders get their mail delivered already, the terrible ones didn't bother, and all we heard from were people who sometimes sent some spam along with the good mail but assured us they were nice people. (Many universities fall into this category.) I think you'll find that all of the existing whitelist like things are a sideshow to the company's real business of deliverability consulting. For DMARC, it would be nice if there were a shared list of credible forwarders, not to automatically accept their mail, but just to say they're good enough that you can believe what's in their ARC seals when you're doing the usual spam filtering. You can't just let people sign themselves up for a list like that, since every dodgy bulk mailer will figure this will get them an extra 2% delivery, and we've never gotten past a vague hope that we could canvass people we know to make a combined set of mailing lists hosts we know. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] non-mailing list use case for differing header domains
Murray, I have most recently used this link at AOL/Yahoo: https://postmaster.verizonmedia.com/sender-request I have considered using the more complete "Complaint Feedback Loop", https://postmaster.verizonmedia.com/cfl-request but have never completed the process. Maybe they are the last to offer this type of feature. Or maybe my memory is imagining things Now that you have pressed me, I cannot remember whether I have had success with other services or not. My heart is not in prior registration either, but I was trying to lay out the next-best alternative for those who want an alternative to using the MLM domain identity. The goal of DMARC is to end spoofing, which requires everyone to send using their own domain, even when performing a favor for someone in another domain. A recipient domain owner has the right to define the rules for getting into its network.Those who want into that network should play by the rules of that network, whether the rules are liked or disliked. An incoming email is a take-it-or-leave-it proposition for most recipients. My domain does not have the market power to alter sender behavior. When I receive a spoofed message that the recipient actually wants, I end up creating an exception to allow the spoof. Spoofing senders are counting on their ability to force me to do that. However, Microsoft is powerful enough to engage in a standoff.Those who want to send to Microsoft destinations will need to not violate DMARC. I hope and expect that they will win this battle. DMARC is not new. Products that have not become DMARC-aware are as obsolete as WindowsXP. Unfortunately, that does include a lot of products. Over a year ago, I was about to recommend Proofpoint as our new email filtering vendor. But the next morning I realized that their secure email service will spoof the identity of non-clients when they respond to a message from a client. I had a real problem with a vendor promoting their ability to enforce DMARC on incoming mail, while also violating DMARC on their secure email service. Then I saw that Cisco Ironport did the same thing. I raised CIRT issues with both vendors, but nothing has changed. Maybe Microsoft will be able to change their attitudes. DF From: "Murray S. Kucherawy" Sent: 8/7/20 7:16 PM To: Doug Foster Cc: Dave Crocker , IETF DMARC WG Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains On Sun, Aug 2, 2020 at 5:44 PM Douglas E. Foster wrote: Murray took server too literally. I have expressed before that a system could do a sender authentication lookup on List-ID as easily as on From. In this respect, it is similar to Dave's proposal, without the added complexity of additional identifiers. So think "Registerd List-ID plus DKIM signature (or SPF, but DKIM seems both sufficient and preferable.) If we take "server" to mean a tuple made up of a List-ID value and a "d=" value from a validated DKIM signature, which I believe is what you're saying here, the first occurrence of this necessarily has no internal value (or history) attached to it. That means the operator has to develop meaning for it over time, which doesn't tell it how to handle the first N such messages. Err on the side of openness and you have a spam or attack vector; err on the side of defense and you irritate your users by denying them some list traffic until a reputation can develop. And it's probably actually a three-tuple, with the third part being the recipient. Otherwise, I could register (or trigger the auto-registration of) any two-tuple I want and thus intentionally let in my preferred list streams, good or bad, which affects every other user. Plus, you're trusting users to get this right. For a manual registration scheme, every time they get it wrong by entering the wrong data or failing to even do it at all, you've got a failure mode to deal with, usually in the form of user complaints which require other humans to resolve. That makes it relatively expensive. And finally, lists change once in a while, maybe to a new signing domain, maybe to a new name, maybe both. Every time that happens, the process has to start over. Naturally lists won't want to do this because of the sterling reputations they've developed, but the pain reappears whenever the process needs to be repeated for whatever reason. I'm not saying such a system can't or won't work. I'm also not saying I have a better idea. I am saying there's multi-faceted pain in every direction in this space, and this is no exception. Whatever path we choose to deploy here has to account for those choices and their side effects, and the ways they might be gamed. I am not sure what "Internet Scale" means to you. Most of the major recipients have bulk mailer registration systems. It does not guarantee whitelisting, but it tends to produce that effect.
Re: [dmarc-ietf] non-mailing list use case for differing header domains
On 8/7/20 2:12 PM, John Levine wrote: > In article > > you write: >> I feel like what is happening sometimes is that central university IT is >> trying to drag their whole institutions into a >> more secure posture before anybody in a position to stop them fully >> understands what's going on lest they be told to >> stop because it might make things a little inconvenient. > > I was with you up until that sentence, since it trivializes the real > problems that overly strict DMARC policies cause. Maybe Autumn was reflecting the reality that the industry has already trivialized DMARC problems for these "misdeployments". > Just yesterday I was sorting out a problem with people trying to > finish editing a revised IETF standard about real-time web > applications. Some of the authors' messages were disappearing, > apparently at random. I saw what the problem was, one of the authors > is at a big company whose IT department insists on p=reject (and has > blown off complaints from fairly senior people about the problems it > causes), the other uses an MIT alumni address that recently moved its > hosting to Microsoft without telling anyone that the new host enforces > DMARC policy while the old one didn't. > > My guess is that MIT figured Microsoft will host this for free, that's > great, totally unaware that some of its users' mail would silently > break. Customers of Microsoft don't like to call things bundled in an expensive package "free". My peeve in recent years is that universities were essentially coerced (economically) into being the customers of Microsoft/Google and then the email admins are told to sit down and let the adults talk about what they think customers need from DMARC, ARC, etc. It's why I'm constantly sticking my foot in my mouth here and M3AAWG; trying to assert a voice. We need faculty/alumni/emeriti forwarding to work without being told that Microsoft can't do it without breaking DMARC. We need spoofing protection for all of our domains without being told we're misdeploying. We know that we need advanced local policy controls for DMARC enforcement and we don't want to be blamed when the vendor doesn't give us those controls (to your MIT example) > I told them as a workaround they needed to directly cc each other when > they send anything to the group list, but the whole thing is a > self-inflicted wound. Maybe it was inflicted by the domain owner onto the person maintaining the mailing list. (In my experience, this is where people realize that no one has been maintaining/patching the mailing list, unaware of DMARC, etc.) Again, I think MLM header munging is here to stay, and list recipients needs to get used to it (I'd like p=quarantine pct=0 be the default behavior so that domains choosing to misdeploy DMARC aren't second class). I'd like to see a way to un-munge mail from trusted intermediaries, but that sounds impractical. I think ARC has promise but it has some challenges that I hope can be overcome; notably a mechanism for the receiver to indicate trust to the intermediary (so that it knows it doesn't need to munge). At that point, I can start to figure out how to deal with the mailbox-level forwarded mail for faculty/alumni/emeriti... Jesse ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] non-mailing list use case for differing header domains
On Sun, Aug 2, 2020 at 5:44 PM Douglas E. Foster < fost...@bayviewphysicians.com> wrote: > Murray took server too literally. I have expressed before that a system > could do a sender authentication lookup on List-ID as easily as on From. > In this respect, it is similar to Dave's proposal, without the added > complexity of additional identifiers. So think "Registerd List-ID plus > DKIM signature (or SPF, but DKIM seems both sufficient and preferable.) > If we take "server" to mean a tuple made up of a List-ID value and a "d=" value from a validated DKIM signature, which I believe is what you're saying here, the first occurrence of this necessarily has no internal value (or history) attached to it. That means the operator has to develop meaning for it over time, which doesn't tell it how to handle the first N such messages. Err on the side of openness and you have a spam or attack vector; err on the side of defense and you irritate your users by denying them some list traffic until a reputation can develop. And it's probably actually a three-tuple, with the third part being the recipient. Otherwise, I could register (or trigger the auto-registration of) any two-tuple I want and thus intentionally let in my preferred list streams, good or bad, which affects every other user. Plus, you're trusting users to get this right. For a manual registration scheme, every time they get it wrong by entering the wrong data or failing to even do it at all, you've got a failure mode to deal with, usually in the form of user complaints which require other humans to resolve. That makes it relatively expensive. And finally, lists change once in a while, maybe to a new signing domain, maybe to a new name, maybe both. Every time that happens, the process has to start over. Naturally lists won't want to do this because of the sterling reputations they've developed, but the pain reappears whenever the process needs to be repeated for whatever reason. I'm not saying such a system can't or won't work. I'm also not saying I have a better idea. I am saying there's multi-faceted pain in every direction in this space, and this is no exception. Whatever path we choose to deploy here has to account for those choices and their side effects, and the ways they might be gamed. I am not sure what "Internet Scale" means to you. Most of the major > recipients have bulk mailer registration systems. It does not guarantee > whitelisting, but it tends to produce that effect. I have had occasion to > register with most of them. So "does not scale" is not obvious to me. > "Internet Scale" means millions or billions of users, like GMail or Yahoo or AOL or Microsoft have. Since they have the bulk of the inboxes, a solution needs to at least consider that size of use case, or explain why those cases don't need to be considered. I've never seen this manual registration process to which you refer. Where can I find it, for example, on GMail? Even more to the point, check out this link: > > https://blog.postmaster.verizonmedia.com/post/616023179026202624/increasing-relevance-performance-through-vto > > > Verizon appears to be offering a service (probably for extra cost) which > is based on: > (a) a well-defined mail stream from a known sender, and > (b) a mailbox user identifying that mail stream as subscribed, and > therefore desirable. > > It appears that the target senders are retailers who want to ensure that > their sale announcements are read before the sale is over. It is an > "Internet scale" application of the type of registration I was suggesting: > Well-identified senders, coupled with end-user endorsement, receive > preferred treatment. > Is there a technical description someplace of the mechanism behind what they're doing? As to the transparency question, it should be clear that there will be no > simple solution to the ML problem. > Indeed. [...] But the only way to establish an acceptable reputation is to either > register with the receiver directly, or register with the sender in a way > that the receiver will honor. > This needs to scale, from both ends: 1) If I as a new list operator want my list traffic to get accepted, how could I possibly go about registering with all (or even most) mailbox providers in a way they will trust? 2) If I as a mailbox provider want to give my users quality service and also spam filtering, what way can I offer list operators to identify themselves that can't be spoofed, and will only be exploited by good actors? Putting this burden on my users doesn't feel tenable. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] non-mailing list use case for differing header domains
In article you write: >I feel like what is happening sometimes is that central university IT is >trying to drag their whole institutions into a >more secure posture before anybody in a position to stop them fully >understands what's going on lest they be told to >stop because it might make things a little inconvenient. I was with you up until that sentence, since it trivializes the real problems that overly strict DMARC policies cause. Just yesterday I was sorting out a problem with people trying to finish editing a revised IETF standard about real-time web applications. Some of the authors' messages were disappearing, apparently at random. I saw what the problem was, one of the authors is at a big company whose IT department insists on p=reject (and has blown off complaints from fairly senior people about the problems it causes), the other uses an MIT alumni address that recently moved its hosting to Microsoft without telling anyone that the new host enforces DMARC policy while the old one didn't. My guess is that MIT figured Microsoft will host this for free, that's great, totally unaware that some of its users' mail would silently break. I told them as a workaround they needed to directly cc each other when they send anything to the group list, but the whole thing is a self-inflicted wound. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] non-mailing list use case for differing header domains
What I find very interesting about this email from Jesse, and Mike's response is that I hear these words coming from two very different experiences of deploying DMARC. In my role doing onboarding at Agari, I have worked with many different organizations on their DMARC projects. I have worked with numerous corporate groups, as well as governmental organizations, nonprofits, and universities. Universities operate with a somewhat different set of expectations than other groups in ways that make DMARC additionally challenging. Here are a few things I have learned implementing DMARC for multiple universities: * Universities have a significantly higher degree of user and use case turnover than other organizations, by a lot. There are new students and staff every term, and many more of them will use their email address to send out email over various third party tools. In the corporate world, sure there are employees coming and going all the time, and new projects, but there is a much greater degree of stability in terms of systems sending out email. * University IT has much less control over their users than corporate IT. In corporate IT, it is not unusual for IT leadership to make decisions on what applications will and will not be supported, and to have general support for this from the top. In higher education, IT teams seem to frequently be told that they must support whatever their users request, and have very little authority. * Most universities serve a greater breadth of use cases than most other organizations. Consider an organization that is a fundraising nonprofit, scientific research group in multiple disciplines, hospital, mental health clinic, employer with HR tools, housing coordinator, childcare coordinator, gym, sports arena, transportation system, provider of continuing education to certified professionals, press agency, mailing list provider, forwarder, etc. all in one. There are a lot of niche tools that can send email in each of these different use cases, but universities are the only place I see so many of them all together. * Universities are highly decentralized. It seems like every major school inside a university (school of public health, school of humanities, etc.) has its own policies and culture, and sometimes its own IT staff. * Universities tend to have more legacy technology than other organizations (except government). The reason I mention all this stuff is that I feel like some of what is being suggested here misses this reality. Mike said, "You need buy-in from senior management for any email authentication efforts. When you add up the costs of customer support contacts for dealing with fraudulent email claiming to be from your organization, reputation damage, etc., management becomes more willing to buy into a comprehensive strategy." - in the higher education world, I don't see it working like this. IT staff can get enough buy-in to decide to work on DMARC as a project, but the costs of support contacts are likely spread out over multiple groups in a way that is very hard to quantify at a higher level, and even if they were to consider that, they would still be more likely to say that a comprehensive strategy is good and all, but it still matters more to them that good old Professor 1984 can still use his favorite application even though it doesn't conform to modern security standards. I feel like what is happening sometimes is that central university IT is trying to drag their whole institutions into a more secure posture before anybody in a position to stop them fully understands what's going on lest they be told to stop because it might make things a little inconvenient. Many universities do not attempt DMARC at all, so I think any work we can do to make it easier on them would encourage greater adoption. Thanks, Autumn Tyr-Salvia atyrsal...@agari.com Agari Principal Customer Success Engineer From: dmarc on behalf of Dotzero Sent: Wednesday, August 5, 2020 12:52 PM To: Jesse Thompson Cc: IETF DMARC WG Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains On Wed, Aug 5, 2020 at 12:39 PM Jesse Thompson mailto:40wisc@dmarc.ietf.org>> wrote: On 8/4/20 11:52 AM, Alessandro Vesely wrote: > On 2020-08-04 6:10 p.m., Dotzero wrote: >> On Tue, Aug 4, 2020 at 11:39 AM Jim Fenton >> mailto:fen...@bluepopcorn.net>> wrote: >>> On 8/2/20 5:43 PM, Douglas E. Foster wrote: As to the transparency question, it should be clear that there will be no simple solution to the ML problem. >>> >>> Actually, there is: If your domain has users that use mailing lists, >>> don't publish 'reject' or 'quarantine' policies. Generally this means to >>> just use those policies for domains used for transactional email. >>> >>> Unfortunately we seem to be focused on very complex technical solutions >>> to a misdeployment problem. I've never heard this
