Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
On 10/9/2021 3:08 PM, Scott Kitterman wrote: Technically it's pretty easy to set up a mailing list which doesn't modify the message in ways likely to make DKIM fail. Almost no one bothers to do so despite pressures resulting from widespread use of DMARC p=reject. This highlights the difference between technical details, versus group operational culture. As we all keep noting, the humans using these lists have lived with a certain kind of operational style, for decades. Entirely legal and -- more important -- deemed useful. So while one can describe various, feasible changes that circumvent the intrusive, destructive effects of DMARC, they requires changes to a long history of use. The word that you might be looking for, here, is Procrustean. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
Technically it's pretty easy to set up a mailing list which doesn't modify the message in ways likely to make DKIM fail. Almost no one bothers to do so despite pressures resulting from widespread use of DMARC p=reject. Operators do not need to justify anything to us. We are not the internet police. For our purposes it's enough to know that they do and there's no evidence that it's likely to change. Scott K On October 9, 2021 7:39:36 PM UTC, Douglas Foster wrote: >I would be pleased to see a document which explains why lists MUST or >SHOULD alter content.After more than 2 years following this discussion, >no reason for this practice has ever been documented. > >Content changes would be easier to justify if subscribers granted >authorization to modify as part of the subscription process. But there >was not informed consent when I joined this list, so I doubt that informed >consent occurs on other lists either. > >What if, after reviewing the SHOULD list, an organization says "That's >interesting but unconvincing. Please send messages to our domain without >alteration?" Are lists equipped to give participants what they want, or >not? > >Doug > >On Thu, Oct 7, 2021 at 9:58 AM Barry Leiba wrote: > >> Just on one point, for us to consider: >> >> > Personally, I think mailing lists changing From has horrible UX and I >> don't >> > really think anyone disagrees. It's only advantages are that it's >> relatively >> > easy to implement in a Mailing List Manager (MLM) and it solves the >> entire >> > DMARC problem for a specific mailing list without needing anyone else to >> change >> > anything. I understand the appeal. >> >> I think Scott is right that we all agree that rewriting From mitigates >> problems that mailing lists have with DMARC, but at a significant cost >> in usability. >> >> I think it would be bad to publish From-rewriting as a standard. >> >> But here: I think it is reasonable, perhaps advisable, to >> informationally document From-rewriting as a mechanism that is in use, >> and to include in that documentation a clear exposition of the >> problems that it causes. Why not get those horrible UX issues down on >> paper so that when someone decides to deploy it they are better >> informed? Perhaps we can lead people to take steps to reduce the UX >> challenges (for example, rewriting the way the IETF is doing it at >> least addresses the issue of knowing who sent the message, and how to >> reply to the actual sender, as compared to a rewrite directly to the >> mailing list address). >> >> Doesn't that make sense? >> >> Barry >> >> ___ >> 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] DMARC-Compliant Mailing Lists
I would be pleased to see a document which explains why lists MUST or SHOULD alter content.After more than 2 years following this discussion, no reason for this practice has ever been documented. Content changes would be easier to justify if subscribers granted authorization to modify as part of the subscription process. But there was not informed consent when I joined this list, so I doubt that informed consent occurs on other lists either. What if, after reviewing the SHOULD list, an organization says "That's interesting but unconvincing. Please send messages to our domain without alteration?" Are lists equipped to give participants what they want, or not? Doug On Thu, Oct 7, 2021 at 9:58 AM Barry Leiba wrote: > Just on one point, for us to consider: > > > Personally, I think mailing lists changing From has horrible UX and I > don't > > really think anyone disagrees. It's only advantages are that it's > relatively > > easy to implement in a Mailing List Manager (MLM) and it solves the > entire > > DMARC problem for a specific mailing list without needing anyone else to > change > > anything. I understand the appeal. > > I think Scott is right that we all agree that rewriting From mitigates > problems that mailing lists have with DMARC, but at a significant cost > in usability. > > I think it would be bad to publish From-rewriting as a standard. > > But here: I think it is reasonable, perhaps advisable, to > informationally document From-rewriting as a mechanism that is in use, > and to include in that documentation a clear exposition of the > problems that it causes. Why not get those horrible UX issues down on > paper so that when someone decides to deploy it they are better > informed? Perhaps we can lead people to take steps to reduce the UX > challenges (for example, rewriting the way the IETF is doing it at > least addresses the issue of knowing who sent the message, and how to > reply to the actual sender, as compared to a rewrite directly to the > mailing list address). > > Doesn't that make sense? > > Barry > > ___ > 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] DMARC-Compliant Mailing Lists
Yes, savvy users could use the proxy to establish offline communication, but it is not what most users would do, so the lure for bad actors is real. Our previous discussion about online stalking was very much in mind when I wrote the specification. Because of the proxy mechanism, stalking can be stopped by (a) the list operator preventing messages from the stalker's real address to the victim's alias address, or (b) the system operator evicting the stalker from the list, or (c) the victim leaving the list. In any of these scenarios, the harassment is stopped immediately, as long as the stalker does not have the real email address of his target. In the absence of such measures, the best defense is to use a separate email address for each list in which one participates. Doug Foster On Sat, Oct 9, 2021 at 12:35 PM Grant Taylor wrote: > On 10/9/21 6:05 AM, Douglas Foster wrote: > > The substantive argument is the problem of trust in list operators. My > > proposal made list infrastructure significantly more complex, and > > allowed list operators to intercept member-to-member communication. > > This creates an incentive for nation-state intelligence agencies and > > big tech privacy violators to move into management of lists. > > I believe that it makes the list operator effectively a communications > proxy. Nothing states that two parties need to use the proxy for any > more than the minimum communications necessary to establish direct > communications. I also believe that this is a well established > communications bootstrap method; eBay, Craigslist, various dating > sites, etc. tend to provide a way for people to say things like "please > email me at my main email address". > > > > -- > Grant. . . . > unix || die > > ___ > 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] DMARC-Compliant Mailing Lists
It appears that Alessandro Vesely said: >Would it make sense to extend DMARC commitment to the whole From: field? For >example, assert that the local part and the display name have been set by an >authenticated user? (Rather than automatically munged.) All of the mail that comes out of my system (other than the stuff sent by scripts) is sent by authenticated users who can put whatever they want in the From: header. It's quite useful, particularly for those of use who use multiple addresses. It puts info about who authenticated in other places. This partcular bad idea has been batted around for years. Nobody has ever been able to explain how you could distinguish "real" address comments from unreal ones. If you're just wondering whether the header has been changed, DKIM already does that. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
On Fri 08/Oct/2021 19:57:59 +0200 Dave Crocker wrote: On 10/8/2021 10:44 AM, Alessandro Vesely wrote: On Fri 08/Oct/2021 18:18:45 +0200 Dave Crocker wrote: Whether signed fields are validated depends on the signing domain's policy. That statement is both true and misleading. DKIM has a semantic that is not dependent on the choices of folk who use DKIM. DKIM's semantic for what it signs does NOT include validation of the content. That some signers might do some sorts of validation does not affect DKIM's semantics. Within the context of the DKIM specification there is no way to tell that a signer has these added constraints or meanings. Therefore, if you are interpreting a signature as meaning that some aspect of the data are valid, you have gone beyond DKIM. DMARC is an example of going beyond DKIM semantics, with incremental specification, but only for the domain name in the From field. Would it make sense to extend DMARC commitment to the whole From: field? For example, assert that the local part and the display name have been set by an authenticated user? (Rather than automatically munged.) DMARC adds to the semantics with its definition of alignment. It's part of DMARC, not DKIM. So it's certainly reasonable to include the Author: field in the set that produce the DKIM signature, but that inclusions does not have any semantic other than it didn't get changed since the signing. Data integrity is nice but is quite different from validation. If the author's domain signed Author:, then a receiver knows that they are aware of the mailing list problem and presumably interested in validation results. I think understand this thinking but I also think it imparts far too much thought and diligence that is going to validly apply. It is the same sentiment that makes one add Author:. There are mailbox providers who set p=quarantine or harder (and possibly pct=0) just so that MLMs are forced to rewrite From: and thus they get rid of aggregate reports containing failed DMARC checks. Mailbox providers who add Author: must belong to a different category. Perhaps they care that their signatures survive MLM transformations. Such possibility depends on how they sign, relaxed rather than simple, which header fields, how to do Content-Transfer-Encoding:, and the like. DMARC feedback is essential to guide those choices, so it should be addressed also to the author's domains. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
On 10/9/21 6:05 AM, Douglas Foster wrote: The substantive argument is the problem of trust in list operators. My proposal made list infrastructure significantly more complex, and allowed list operators to intercept member-to-member communication. This creates an incentive for nation-state intelligence agencies and big tech privacy violators to move into management of lists. I believe that it makes the list operator effectively a communications proxy. Nothing states that two parties need to use the proxy for any more than the minimum communications necessary to establish direct communications. I also believe that this is a well established communications bootstrap method; eBay, Craigslist, various dating sites, etc. tend to provide a way for people to say things like "please email me at my main email address". -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
I believe I asked a straightforward question, which I have asked previously in other ways in other contexts. The silence confirms that, unfortunately, there is no good answer. We have had much discussion which assumes that ARC will reduce From rewrite, because ARC will allow an evaluator to identify trustworthy changes made by mailing lists. When the mailing list operator is unaware that the recipient is using ARC to trust his messages, he must continue to rewrite From. This means that ARC must be combined with the reverse-encoding techniques described by Ale, so that the diminishing of >From rewrite is accomplished entirely by the evaluator before presenting the message to the user. List operators could diminish From rewrite by collecting data about which evaluators require it. There are two obvious ways to collect this data: asking subscribers and sending test messages.Yet I have been repeatedly told, most recently by Ale, that list operators are unwilling to collect evaluator-specific data.Perhaps this resistance exists because the supporting software does not exist, and that could be fixed if the concept was formalized by IETF. Without reverse-encoding or evaluator-specific rewrite decisions, ARC has failed at its original purpose. Doug Foster On Fri, Oct 8, 2021 at 1:02 AM Benny Pedersen wrote: > On 2021-10-08 02:47, Douglas Foster wrote: > > Assume the following: > > > > List "L" has implemented ARC and has subscribers from 10 domains, > > Domain through DomainJ. > > > > A user from DomainA, which publishes p=reject, submits a post to the > > list. > > > > What information does List "L" use to decide whether to rewrite > > "From", for each of the 10 domains? > > How is that information obtained? > > what info ? > > are you asking how to break dkim ? > > dkim have still adsp, and atleast this still stands in spamassassin, > since it uses metacpan Mail::DKIM perl module > > simple do not break dkim > > i think its endless debate on we want to fix it, but no one can see the > light in the jungle of solutions on problems never existed on servial > maillists that does not break dkim > > ___ > 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] DMARC-Compliant Mailing Lists
I don't understand your user experience argument, because the proposed UX would be very different from the current UX. Nor do I think that security should be compromised for user convenience. But I am ready to withdraw the proposal. The substantive argument is the problem of trust in list operators. My proposal made list infrastructure significantly more complex, and allowed list operators to intercept member-to-member communication. This creates an incentive for nation-state intelligence agencies and big tech privacy violators to move into management of lists.I underestimated that risk, and it creates a veto. Doug foster On Fri, Oct 8, 2021 at 12:30 AM Scott Kitterman wrote: > If we were the voting sort, my vote would be "rewriting from is a horrible > hack that destroys UX". That should be sufficient information. > > Scott K > > > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
