Re: [dmarc-ietf] AOL-compatible mailing lists
+1 to Doug's comments. I think an expected and desired state achievable in the foreseeable future (based on the flows I see) is to require at least some form of authentication (whether it's SPF, DKIM or ARC). On Mon, Apr 10, 2023, 8:18 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > The AOL breach obviously just magnified a problem that was already in > place - impersonation is a useful attack vector. Email addresses do not > have restricted distribution, and they fall into the hands of unwanted > senders all the time. > > We currently have a regime of semi-mandatory sender authentication. Some > domain owners request it and some do not, some evaluators enforce it and > some do not. Recipients assume that apparent identities can be trusted, > generally without understanding the nuances between Friendly Name, From > Address, and MailFrom address. At the same time, some participants > (including but not limited to mailing lists) depend on absence of sender > authentication, at least on their unauthenticated traffic, a practice which > works only as long as their traffic is not be impersonated. The whole > configuration is inherently unstable because domain owners and evaluators > can change their policy at any time, and unauthenticated traffic can > collect impersonators at any time. > > The stable designs involve no authentication and mutual distrust, or > mandatory authentication. Neither outcome is likely in the short term, so > the instability will persist. I don't know that our document can make > much impact either way.I think language which most closely reflects > reality is the tone that I have been pushing: "Sender Authentication is > too important to ignore, but too imperfect to trust unconditionally." > > Doug Foster > > > > On Mon, Apr 10, 2023 at 2:00 AM Wei Chuang 40google@dmarc.ietf.org> wrote: > >> >> >> On Sun, Apr 9, 2023 at 2:28 PM Murray S. Kucherawy >> wrote: >> >>> On Sun, Apr 9, 2023 at 2:07 PM Douglas Foster < >>> dougfoster.emailstanda...@gmail.com> wrote: >>> As an evaluator, what I can accept is that "Some intermediaries could be allowed to make some changes y do want unrestricto messages, if I have a list of intermediaries that should be allowed, sufficient reason to trust what they propose to do, and a reliable way to identify them."I do exceptions all the time. But lists don't want to make special arrangements with evaluators, and don't want to make special arrangements with senders. Apparently, lists don't even want to do rigorous verification to ensure that a post comes from the purported subscriber. But theted access to evaluators that filter based on simplistic triggers like "p=reject". >>> >>> I see two issues with this line of thinking: >>> >>> (1) "I do exceptions all the time" works when you are a relatively small >>> operator with a relatively small user base for whom you need to configure >>> exceptions. You can get away with doing those manually. What size staff >>> do you imagine GMail would need to hire to investigate and configure manual >>> exceptions on a timely basis for each time one of its billion-plus users >>> wants to subscribe to a mailing list? The notion screams for automation, >>> and automation screams for something deterministic or at least close to it >>> upon which to base automated decisions. That last bit is what's missing >>> here. >>> >> >> +1 >> >> >>> (2) "But lists don't want to make special arrangements with evaluators, >>> and don't want to make special arrangements with senders". They might, if >>> there existed a reliable way to do so. How would you accomplish this in a >>> way that prevents an attacker from making you think he's a list, and then >>> sending whatever he wants from inside that trust boundary? >>> >> >> +1 >> >> FWIW I'm starting to think this problem has two parts: >> 1) We know that a sender intends to send a message down some path that >> may include a mailing list, that got to me safely. This is to avoid DKIM >> replay and FROM spoofing attacks. >> 2) That we can identify the contributors to the content of the message in >> that path to distinguish malicious vs benign contributors. For certain >> constrained but hopefully reasonable scenarios of mailing list >> modifications, we might be able to distinguish the sources of content. If >> necessary, we can go back to first principles to determine which >> modifications have to be supported. For example I've seen Brandon mention >> that mailing list appending disclosure footers are required for compliance >> sometimes. Others hopefully we would not have to support to reduce >> implementation complexity. >> >> >>> >>> I think evaluators SHOULD NOT block on simplistic rules like p=reject, because a correct p=reject block requires follow-on work to block everything else from that malicious source, and should not be done incorrectly. They
Re: [dmarc-ietf] AOL-compatible mailing lists
On Sun, Apr 9, 2023 at 3:27 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > All of which is why I sketched out a very different mailing list design. > It's not my job or my agenda to sell it to people, not my job to build > the product, and not my job to deal with hurt feelings. > This, at a minimum, has the appearance of being rather cavalier and expecting a large installed base to cope with the sea change you want to impose upon them. If it's not your (or the WG's) job to sell it, build it, or deal with it, then whose job do you surmise it is? > The Internet changed when we realized that bad guys dominate the > environment, and Sender Authentication is one of the consequences. The > name-translating design provides a path to reliable list delivery when > Sender Authentication is mandatory. I think that kind of future-thinking > is what standards are supposed to do. > Standards track documents like DKIM and SPF have enjoyed relative success because they had a deployed base at the time they began their quests for standardization. They weren't written, published, and only then actually built and deployed. We had experience regarding what they look like and how effective they are in the field as part of the case for publication. Your idea might have merit, but it needs to be proven out rather than being purely theoretical. The IETF tends to favor for publication standards track documents that have implementations already. The "future-thinking" is where the idea comes from, to be sure, but it would suit us well to find a way to test them out somehow before sending them on their way. So again, who should do the work? -MSK, participating ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] AOL-compatible mailing lists
The AOL breach obviously just magnified a problem that was already in place - impersonation is a useful attack vector. Email addresses do not have restricted distribution, and they fall into the hands of unwanted senders all the time. We currently have a regime of semi-mandatory sender authentication. Some domain owners request it and some do not, some evaluators enforce it and some do not. Recipients assume that apparent identities can be trusted, generally without understanding the nuances between Friendly Name, From Address, and MailFrom address. At the same time, some participants (including but not limited to mailing lists) depend on absence of sender authentication, at least on their unauthenticated traffic, a practice which works only as long as their traffic is not be impersonated. The whole configuration is inherently unstable because domain owners and evaluators can change their policy at any time, and unauthenticated traffic can collect impersonators at any time. The stable designs involve no authentication and mutual distrust, or mandatory authentication. Neither outcome is likely in the short term, so the instability will persist. I don't know that our document can make much impact either way.I think language which most closely reflects reality is the tone that I have been pushing: "Sender Authentication is too important to ignore, but too imperfect to trust unconditionally." Doug Foster On Mon, Apr 10, 2023 at 2:00 AM Wei Chuang wrote: > > > On Sun, Apr 9, 2023 at 2:28 PM Murray S. Kucherawy > wrote: > >> On Sun, Apr 9, 2023 at 2:07 PM Douglas Foster < >> dougfoster.emailstanda...@gmail.com> wrote: >> >>> As an evaluator, what I can accept is that "Some intermediaries could be >>> allowed to make some changes y do want unrestricto messages, if I have a >>> list of intermediaries that should be allowed, sufficient reason to trust >>> what they propose to do, and a reliable way to identify them."I do >>> exceptions all the time. But lists don't want to make special >>> arrangements with evaluators, and don't want to make special arrangements >>> with senders. Apparently, lists don't even want to do rigorous >>> verification to ensure that a post comes from the purported subscriber. >>> But theted access to evaluators that filter based on simplistic triggers >>> like "p=reject". >>> >> >> I see two issues with this line of thinking: >> >> (1) "I do exceptions all the time" works when you are a relatively small >> operator with a relatively small user base for whom you need to configure >> exceptions. You can get away with doing those manually. What size staff >> do you imagine GMail would need to hire to investigate and configure manual >> exceptions on a timely basis for each time one of its billion-plus users >> wants to subscribe to a mailing list? The notion screams for automation, >> and automation screams for something deterministic or at least close to it >> upon which to base automated decisions. That last bit is what's missing >> here. >> > > +1 > > >> (2) "But lists don't want to make special arrangements with evaluators, >> and don't want to make special arrangements with senders". They might, if >> there existed a reliable way to do so. How would you accomplish this in a >> way that prevents an attacker from making you think he's a list, and then >> sending whatever he wants from inside that trust boundary? >> > > +1 > > FWIW I'm starting to think this problem has two parts: > 1) We know that a sender intends to send a message down some path that may > include a mailing list, that got to me safely. This is to avoid DKIM > replay and FROM spoofing attacks. > 2) That we can identify the contributors to the content of the message in > that path to distinguish malicious vs benign contributors. For certain > constrained but hopefully reasonable scenarios of mailing list > modifications, we might be able to distinguish the sources of content. If > necessary, we can go back to first principles to determine which > modifications have to be supported. For example I've seen Brandon mention > that mailing list appending disclosure footers are required for compliance > sometimes. Others hopefully we would not have to support to reduce > implementation complexity. > > >> >> I think evaluators SHOULD NOT block on simplistic rules like p=reject, >>> because a correct p=reject block requires follow-on work to block >>> everything else from that malicious source, and should not be done >>> incorrectly. They should review, either with pre-quarantine or >>> post-audit, which is what I do. I have no problem with >>> disposition=quarantine, even for p=none. I am obligated to protect my >>> users, while also obligated to provide my users the messages they need, not >>> the ones that are technically optimal I don't understand why Big Tech and >>> its A.I. tools cannot be deployed to do the best thing. >>> >> > Simplistic rules are more likely to be
Re: [dmarc-ietf] AOL-compatible mailing lists
On Sun, Apr 9, 2023 at 2:28 PM Murray S. Kucherawy wrote: > On Sun, Apr 9, 2023 at 2:07 PM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> As an evaluator, what I can accept is that "Some intermediaries could be >> allowed to make some changes y do want unrestricto messages, if I have a >> list of intermediaries that should be allowed, sufficient reason to trust >> what they propose to do, and a reliable way to identify them."I do >> exceptions all the time. But lists don't want to make special >> arrangements with evaluators, and don't want to make special arrangements >> with senders. Apparently, lists don't even want to do rigorous >> verification to ensure that a post comes from the purported subscriber. >> But theted access to evaluators that filter based on simplistic triggers >> like "p=reject". >> > > I see two issues with this line of thinking: > > (1) "I do exceptions all the time" works when you are a relatively small > operator with a relatively small user base for whom you need to configure > exceptions. You can get away with doing those manually. What size staff > do you imagine GMail would need to hire to investigate and configure manual > exceptions on a timely basis for each time one of its billion-plus users > wants to subscribe to a mailing list? The notion screams for automation, > and automation screams for something deterministic or at least close to it > upon which to base automated decisions. That last bit is what's missing > here. > +1 > (2) "But lists don't want to make special arrangements with evaluators, > and don't want to make special arrangements with senders". They might, if > there existed a reliable way to do so. How would you accomplish this in a > way that prevents an attacker from making you think he's a list, and then > sending whatever he wants from inside that trust boundary? > +1 FWIW I'm starting to think this problem has two parts: 1) We know that a sender intends to send a message down some path that may include a mailing list, that got to me safely. This is to avoid DKIM replay and FROM spoofing attacks. 2) That we can identify the contributors to the content of the message in that path to distinguish malicious vs benign contributors. For certain constrained but hopefully reasonable scenarios of mailing list modifications, we might be able to distinguish the sources of content. If necessary, we can go back to first principles to determine which modifications have to be supported. For example I've seen Brandon mention that mailing list appending disclosure footers are required for compliance sometimes. Others hopefully we would not have to support to reduce implementation complexity. > > I think evaluators SHOULD NOT block on simplistic rules like p=reject, >> because a correct p=reject block requires follow-on work to block >> everything else from that malicious source, and should not be done >> incorrectly. They should review, either with pre-quarantine or >> post-audit, which is what I do. I have no problem with >> disposition=quarantine, even for p=none. I am obligated to protect my >> users, while also obligated to provide my users the messages they need, not >> the ones that are technically optimal I don't understand why Big Tech and >> its A.I. tools cannot be deployed to do the best thing. >> > Simplistic rules are more likely to be deterministic and interoperate in an understandable way. Permitting exceptional cases and AI tools introduces complexity and variability as exceptions are given and AI models change. -Wei > I'm pretty sure they could, for their own use cases. But what about the > operators in between, who aren't Big Tech and don't have AI tools? A > standard has to work for everyone. > > -MSK, participating > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > smime.p7s Description: S/MIME Cryptographic Signature ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] AOL-compatible mailing lists
What is the operational experience with domains that stop at o=quarantine? On Sun, Apr 9, 2023, 5:28 PM Murray S. Kucherawy wrote: > On Sun, Apr 9, 2023 at 2:07 PM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> As an evaluator, what I can accept is that "Some intermediaries could be >> allowed to make some changes y do want unrestricto messages, if I have a >> list of intermediaries that should be allowed, sufficient reason to trust >> what they propose to do, and a reliable way to identify them."I do >> exceptions all the time. But lists don't want to make special >> arrangements with evaluators, and don't want to make special arrangements >> with senders. Apparently, lists don't even want to do rigorous >> verification to ensure that a post comes from the purported subscriber. >> But theted access to evaluators that filter based on simplistic triggers >> like "p=reject". >> > > I see two issues with this line of thinking: > > (1) "I do exceptions all the time" works when you are a relatively small > operator with a relatively small user base for whom you need to configure > exceptions. You can get away with doing those manually. What size staff > do you imagine GMail would need to hire to investigate and configure manual > exceptions on a timely basis for each time one of its billion-plus users > wants to subscribe to a mailing list? The notion screams for automation, > and automation screams for something deterministic or at least close to it > upon which to base automated decisions. That last bit is what's missing > here. > > (2) "But lists don't want to make special arrangements with evaluators, > and don't want to make special arrangements with senders". They might, if > there existed a reliable way to do so. How would you accomplish this in a > way that prevents an attacker from making you think he's a list, and then > sending whatever he wants from inside that trust boundary? > > I think evaluators SHOULD NOT block on simplistic rules like p=reject, >> because a correct p=reject block requires follow-on work to block >> everything else from that malicious source, and should not be done >> incorrectly. They should review, either with pre-quarantine or >> post-audit, which is what I do. I have no problem with >> disposition=quarantine, even for p=none. I am obligated to protect my >> users, while also obligated to provide my users the messages they need, not >> the ones that are technically optimal I don't understand why Big Tech and >> its A.I. tools cannot be deployed to do the best thing. >> > > I'm pretty sure they could, for their own use cases. But what about the > operators in between, who aren't Big Tech and don't have AI tools? A > standard has to work for everyone. > > -MSK, participating > ___ > 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] AOL-compatible mailing lists
Those are all valid points, and I don't have a solution for them which preserves the status quo. I see the world moving to more Sender Authentication, not less. Mandatory Sender Authentication is my expected end-state. ARC is an acknowledgement of this trend. ARC may not add much value to lists, because it requires out-of-band communication before From-munging can be disabled. But to the extent that ARC is useful to lists, it forces them to do more and better Sender Authentication than the previous norm. So even they are getting sucked in, willing or not. All of which is why I sketched out a very different mailing list design. It's not my job or my agenda to sell it to people, not my job to build the product, and not my job to deal with hurt feelings.The Internet changed when we realized that bad guys dominate the environment, and Sender Authentication is one of the consequences. The name-translating design provides a path to reliable list delivery when Sender Authentication is mandatory. I think that kind of future-thinking is what standards are supposed to do. Doug On Sun, Apr 9, 2023 at 5:28 PM Murray S. Kucherawy wrote: > On Sun, Apr 9, 2023 at 2:07 PM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> As an evaluator, what I can accept is that "Some intermediaries could be >> allowed to make some changes y do want unrestricto messages, if I have a >> list of intermediaries that should be allowed, sufficient reason to trust >> what they propose to do, and a reliable way to identify them."I do >> exceptions all the time. But lists don't want to make special >> arrangements with evaluators, and don't want to make special arrangements >> with senders. Apparently, lists don't even want to do rigorous >> verification to ensure that a post comes from the purported subscriber. >> But theted access to evaluators that filter based on simplistic triggers >> like "p=reject". >> > > I see two issues with this line of thinking: > > (1) "I do exceptions all the time" works when you are a relatively small > operator with a relatively small user base for whom you need to configure > exceptions. You can get away with doing those manually. What size staff > do you imagine GMail would need to hire to investigate and configure manual > exceptions on a timely basis for each time one of its billion-plus users > wants to subscribe to a mailing list? The notion screams for automation, > and automation screams for something deterministic or at least close to it > upon which to base automated decisions. That last bit is what's missing > here. > > (2) "But lists don't want to make special arrangements with evaluators, > and don't want to make special arrangements with senders". They might, if > there existed a reliable way to do so. How would you accomplish this in a > way that prevents an attacker from making you think he's a list, and then > sending whatever he wants from inside that trust boundary? > > I think evaluators SHOULD NOT block on simplistic rules like p=reject, >> because a correct p=reject block requires follow-on work to block >> everything else from that malicious source, and should not be done >> incorrectly. They should review, either with pre-quarantine or >> post-audit, which is what I do. I have no problem with >> disposition=quarantine, even for p=none. I am obligated to protect my >> users, while also obligated to provide my users the messages they need, not >> the ones that are technically optimal I don't understand why Big Tech and >> its A.I. tools cannot be deployed to do the best thing. >> > > I'm pretty sure they could, for their own use cases. But what about the > operators in between, who aren't Big Tech and don't have AI tools? A > standard has to work for everyone. > > -MSK, participating > ___ > 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] AOL-compatible mailing lists
On Sun, Apr 9, 2023 at 2:07 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > As an evaluator, what I can accept is that "Some intermediaries could be > allowed to make some changes y do want unrestricto messages, if I have a > list of intermediaries that should be allowed, sufficient reason to trust > what they propose to do, and a reliable way to identify them."I do > exceptions all the time. But lists don't want to make special > arrangements with evaluators, and don't want to make special arrangements > with senders. Apparently, lists don't even want to do rigorous > verification to ensure that a post comes from the purported subscriber. > But theted access to evaluators that filter based on simplistic triggers > like "p=reject". > I see two issues with this line of thinking: (1) "I do exceptions all the time" works when you are a relatively small operator with a relatively small user base for whom you need to configure exceptions. You can get away with doing those manually. What size staff do you imagine GMail would need to hire to investigate and configure manual exceptions on a timely basis for each time one of its billion-plus users wants to subscribe to a mailing list? The notion screams for automation, and automation screams for something deterministic or at least close to it upon which to base automated decisions. That last bit is what's missing here. (2) "But lists don't want to make special arrangements with evaluators, and don't want to make special arrangements with senders". They might, if there existed a reliable way to do so. How would you accomplish this in a way that prevents an attacker from making you think he's a list, and then sending whatever he wants from inside that trust boundary? I think evaluators SHOULD NOT block on simplistic rules like p=reject, > because a correct p=reject block requires follow-on work to block > everything else from that malicious source, and should not be done > incorrectly. They should review, either with pre-quarantine or > post-audit, which is what I do. I have no problem with > disposition=quarantine, even for p=none. I am obligated to protect my > users, while also obligated to provide my users the messages they need, not > the ones that are technically optimal I don't understand why Big Tech and > its A.I. tools cannot be deployed to do the best thing. > I'm pretty sure they could, for their own use cases. But what about the operators in between, who aren't Big Tech and don't have AI tools? A standard has to work for everyone. -MSK, participating ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] AOL-compatible mailing lists
This discussion is based on a mixture of theory and pragmatism. The pragmatism side is that AOL has created a problem, is unlikely to change, and we have to deal with life as it is rather than the way I would like it to be. The theoretical side is more difficult. I would like to be more sympathetic, but the theory doesn't support it. I hear the mailing list complaint as, "Any intermediary should be able to modify any traffic without restriction. These modifications are always beneficial, and therefore the modified message should be more acceptable than the original." In short, the whole idea of DKIM is rejected. As an evaluator, what I can accept is that "Some intermediaries could be allowed to make some changes to messages, if I have a list of intermediaries that should be allowed, sufficient reason to trust what they propose to do, and a reliable way to identify them."I do exceptions all the time. But lists don't want to make special arrangements with evaluators, and don't want to make special arrangements with senders. Apparently, lists don't even want to do rigorous verification to ensure that a post comes from the purported subscriber. But they do want unrestricted access to evaluators that filter based on simplistic triggers like "p=reject". I think evaluators SHOULD NOT block on simplistic rules like p=reject, because a correct p=reject block requires follow-on work to block everything else from that malicious source, and should not be done incorrectly. They should review, either with pre-quarantine or post-audit, which is what I do. I have no problem with disposition=quarantine, even for p=none. I am obligated to protect my users, while also obligated to provide my users the messages they need, not the ones that are technically optimal I don't understand why Big Tech and its A.I. tools cannot be deployed to do the best thing. Doug Foster On Sun, Apr 9, 2023 at 2:52 PM Murray S. Kucherawy wrote: > On Sat, Apr 8, 2023 at 2:13 AM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> It becomes a simple choice: Lists can adapt to operate the way AOL and >> others want them to work, or they can keep to the old ways and live with >> the consequences.When the old ways cause damage, I don't think the >> damage is any longer a DMARC problem. We should formally document how to >> implement a DMARC-compatible mailing list, and then stop worrying about >> those who don't want to be DMARC-compatible. >> > > In what way do "the old ways cause damage"? What damage? They didn't > change anything. Abruptly, unilaterally, declaring the entire global > deployed mailing list base to be obsolete is a strikingly audacious move. > > Still, if something like what you're proposing could gain acceptance and > commitment from the mailing list community, you just might have a consensus > solution on your hands. I suggest approaching them to ask. They may not > be able to accept it as-is, but could have a counter-proposal that we find > palatable. > > -MSK, participating > > ___ > 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] AOL-compatible mailing lists
On Sat, Apr 8, 2023 at 2:13 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > It becomes a simple choice: Lists can adapt to operate the way AOL and > others want them to work, or they can keep to the old ways and live with > the consequences.When the old ways cause damage, I don't think the > damage is any longer a DMARC problem. We should formally document how to > implement a DMARC-compatible mailing list, and then stop worrying about > those who don't want to be DMARC-compatible. > In what way do "the old ways cause damage"? What damage? They didn't change anything. Abruptly, unilaterally, declaring the entire global deployed mailing list base to be obsolete is a strikingly audacious move. Still, if something like what you're proposing could gain acceptance and commitment from the mailing list community, you just might have a consensus solution on your hands. I suggest approaching them to ask. They may not be able to accept it as-is, but could have a counter-proposal that we find palatable. -MSK, participating ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] AOL-compatible mailing lists
On Sat, Apr 8, 2023, at 4:12 AM, Douglas Foster wrote: > It is pretty clear how an AOL-compatible mailing list can be configured: > > • All messages come from the list domain > • Plus addressing is used to give each subscriber a unique From address.. > • To be standards-compliant the plus address still needs to fit within the > 64-character limit, so the suffix is a code, not the full email address. > "John.Doe@subscriberdomain" is translated to "ListName+17@listdomain" > • The Friendly Name is used to identify the subscriber, his email address, > and optionally the list itself. "John Doe John.Doe@subscriberdomain via > Listname" > • Reply-To is set to the list address > This approach: > • Eliminates impersonation of other domains > • Eliminates subscriber specific message blocking based on >• Subscriber domain has DMARC enforcement >• Subscriber domain matches recipient domain >• Subscriber domain is included in a geo-blocking rule > • Allows the list to be protected from impersonation using DMARC > • Allows list authentication to survive downstream forwarding. > I suspect that this configuration is within the capabilities of existing > products, but maybe some software changes would be needed. > > It becomes a simple choice: Lists can adapt to operate the way AOL and > others want them to work, or they can keep to the old ways and live with the > consequences.When the old ways cause damage, I don't think the damage is > any longer a DMARC problem. We should formally document how to implement a > DMARC-compatible mailing list, and then stop worrying about those who don't > want to be DMARC-compatible. > > Doug Foster I can say from experience, being responsible to retire and replace an aging EDU mailing list platform hosting thousands of lists, the choice was simple. The DMARC-incompatible options were immediately ruled out. An academic who happens to reside on a DMARC enabled domain should not have their thoughts quarantined or rejected. That would conflict with the mission of any university. It's been a few years, but I just checked one of the old EDU email admin chatter, and it appears that even more of of them are moving towards DMARC policies, or at least talking about it more than I remember. This trend appears to be encouraged by the dominant MBP and a new bundled service from a major DMARC deployment company. Jesse___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] AOL-compatible mailing lists
It is pretty clear how an AOL-compatible mailing list can be configured: - All messages come from the list domain - Plus addressing is used to give each subscriber a unique From address.. - To be standards-compliant the plus address still needs to fit within the 64-character limit, so the suffix is a code, not the full email address. "John.Doe@subscriberdomain" is translated to "ListName+17@listdomain" - The Friendly Name is used to identify the subscriber, his email address, and optionally the list itself. "John Doe John.Doe@subscriberdomain via Listname" - Reply-To is set to the list address This approach: - Eliminates impersonation of other domains - Eliminates subscriber specific message blocking based on - Subscriber domain has DMARC enforcement - Subscriber domain matches recipient domain - Subscriber domain is included in a geo-blocking rule - Allows the list to be protected from impersonation using DMARC - Allows list authentication to survive downstream forwarding. I suspect that this configuration is within the capabilities of existing products, but maybe some software changes would be needed. It becomes a simple choice: Lists can adapt to operate the way AOL and others want them to work, or they can keep to the old ways and live with the consequences.When the old ways cause damage, I don't think the damage is any longer a DMARC problem. We should formally document how to implement a DMARC-compatible mailing list, and then stop worrying about those who don't want to be DMARC-compatible. Doug Foster ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
