Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
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
Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
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 On October 8, 2021 12:47:38 AM UTC, 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? > > >Doug Foster > > >On Thu, Oct 7, 2021 at 3:19 PM Benny Pedersen wrote: > >> On 2021-10-07 15:38, Scott Kitterman wrote: >> >> > I'm out of time, but something like that which defines the solution >> > space >> > rather then trying to specify THE solution is probably the only path >> > forward. >> >> maillists can dmarc reject posters that use dmarc reject policy or >> quarantine, problem solved downstream >> >> for postfix there is a nice smtpd_milter_maps so maillists ips is not >> dkim/arc/dmarc rejected at all >> >> i pick my games, but if maillists stops dkim sign non orginating mails >> 50% of the main problem is solve there >> >> maillist should only ARC seal / and ARC sign, nothing more, if that is >> done BEFORE dkim is breaked, then it wont break dmarc from github trunk >> of opendmarc, time to stablelize >> >> ___ >> 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
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? Doug Foster On Thu, Oct 7, 2021 at 3:19 PM Benny Pedersen wrote: > On 2021-10-07 15:38, Scott Kitterman wrote: > > > I'm out of time, but something like that which defines the solution > > space > > rather then trying to specify THE solution is probably the only path > > forward. > > maillists can dmarc reject posters that use dmarc reject policy or > quarantine, problem solved downstream > > for postfix there is a nice smtpd_milter_maps so maillists ips is not > dkim/arc/dmarc rejected at all > > i pick my games, but if maillists stops dkim sign non orginating mails > 50% of the main problem is solve there > > maillist should only ARC seal / and ARC sign, nothing more, if that is > done BEFORE dkim is breaked, then it wont break dmarc from github trunk > of opendmarc, time to stablelize > > ___ > 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] Experiments
On September 24, 2021 1:43:25 AM UTC, Scott Kitterman wrote: >On Thursday, September 23, 2021 3:03:39 AM EDT Murray S. Kucherawy wrote: >> On Wed, Sep 22, 2021 at 1:59 PM Scott Kitterman >> >> wrote: >> > I can comment on the status of PSD. >> >> Please do! > >There is progress, but it is still early to expect much in the way of >information. Keep in mind that RFC 9091 is less than two months old. > >As most of you will probably recall from the discussion around PSD DMARC, the >ICANN managed TLDs (essentially everything except ccTLDs and a few special >cases like .mil and .gov) require permission to publish via non-IETF >processes. > >I'm aware of three PSDs which currently publish records. Both .gov.uk and >.mil have had records published for some time. Additionally, .police.uk >published a record in July of this year. I understand that .gov plans to >publish their record this month. > >Until we see publication from an ICANN managed TLD, I don't think we'll have >enough variety to seriously begin the assessments contemplated in the >experiment section of RFC 9091, so it's difficult to predict how soon we will >have conclusions. This isn't the right place to go into details on non-IETF >processes. > >Based on what I've heard so far, the PSD records are being queried and there >is some feedback reporting, so I'm confident we'll get data once we get a >little further on deployment. > >If anyone is aware of others, please let me know. Small update, earlier this month .gov published their PSD record. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
On 2021-10-07 15:38, Scott Kitterman wrote: I'm out of time, but something like that which defines the solution space rather then trying to specify THE solution is probably the only path forward. maillists can dmarc reject posters that use dmarc reject policy or quarantine, problem solved downstream for postfix there is a nice smtpd_milter_maps so maillists ips is not dkim/arc/dmarc rejected at all i pick my games, but if maillists stops dkim sign non orginating mails 50% of the main problem is solve there maillist should only ARC seal / and ARC sign, nothing more, if that is done BEFORE dkim is breaked, then it wont break dmarc from github trunk of opendmarc, time to stablelize ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
On 10/7/2021 8:21 AM, Barry Leiba wrote: and I don't think I've exhibited symptoms of bizarritude (though I suppose if I had I might not know...). no more than usual, no. but to be fair -- or, perhaps bizarrely fair -- my comment wasn't just a concern about your own preferences... 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
It appears that Murray S. Kucherawy said: >He didn't specify, but I took the suggestion to mean a new document, not >any of the current ones. You're welcome to start with the stuff in the ASRG wiki: https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail It's a real wiki, if you think there's stuff missing ask me for a password if you don't already have one and add it. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
>> Sorry, but I've lost track of which document would informationally >> document this issue. >> >> The re-writing hack is an operational one that might or might not prove >> the be transient. Having a spec note the effect of what it does, in >> terms of rendering mailing use problematic, is reasonable. >> >> Having a spec go into details about the hack of the moment isn't. On >> the other hand, it's reasonable to put such discussion into a companion >> 'usage' doc, IMO. > > > He didn't specify, but I took the suggestion to mean a new document, not any > of the current ones. Indeed; it would be bizarre to put it into an existing document, and I don't think I've exhibited symptoms of bizarritude (though I suppose if I had I might not know...). Barry ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
On 10/7/2021 8:11 AM, Murray S. Kucherawy wrote: He didn't specify, but I took the suggestion to mean a new document, not any of the current ones. The use of DMARC, and its collateral effects, are atypically complex. So a separate discussion piece would certainly make sense. 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
On Thu, Oct 7, 2021 at 7:57 AM Dave Crocker wrote: > Sorry, but I've lost track of which document would informationally > document this issue. > > The re-writing hack is an operational one that might or might not prove > the be transient. Having a spec note the effect of what it does, in > terms of rendering mailing use problematic, is reasonable. > > Having a spec go into details about the hack of the moment isn't. On > the other hand, it's reasonable to put such discussion into a companion > 'usage' doc, IMO. > He didn't specify, but I took the suggestion to mean a new document, not any of the current ones. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
On 10/7/2021 6:57 AM, Barry Leiba wrote: 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). Sorry, but I've lost track of which document would informationally document this issue. The re-writing hack is an operational one that might or might not prove the be transient. Having a spec note the effect of what it does, in terms of rendering mailing use problematic, is reasonable. Having a spec go into details about the hack of the moment isn't. On the other hand, it's reasonable to put such discussion into a companion 'usage' doc, IMO. d/ ps. As soon as there is text talking about From rewriting, there should be associated text discussing related mechansisms. The Author spec has already been mentioned, but the discussion should try to be exhaustive. ARC and whatever else makes sense, too. -- 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
Hi, (I'm trimming my own message severely to avoid overwhelming the list) Le 06/10/2021 à 20:22, Alessandro Vesely a écrit : > >> A) The From field >> 1) >> a) > > A list claims some responsibility for the message as well. […] >> b) > > > Right. Yet, posters do trust the MLM operator somewhat. Traditionally, these have been a very weak "some", and a weak "somewhat". Mailing list stem from a time where not everything had to be moderated and sanitized. This old Internet with weak "editors" has served us well, and though some people want it dead, not everybody has to agree. Standards should stay neutral on this political matter. >> 2) > > The usual rewriting is "Baptiste Carvello *via* IETF". It is shorter > than MS's "on behalf of", and hence better. The draft should cover this > detail, IMHO. "via" is better than anything else. Still, that's too much emphasis on what I consider a technical intermediary. >> Any mechanism that rewrites the address alone gives a wrong idea of the >> contact point and thus possibly "hijacks" communication attempts. The >> present proposal is especially egregious in that is does so without any >> hint to the reader. […] > > The "via IETF" or similar wording /is/ a hint. It is both a hint to the > user and a disambiguator for automated address books. This too should > be mentioned in the draft. The draft should be much clarified: I had understood it would use the name alone by default, with some configuration possible for subscribed users (N.B.: not every list is subscriber-only). Still, you're only answering the *easy half* of my paragraph: the hard part is the author's real contact address no more being accessible (with "traditional" munging, you can at least try and guess it; with this draft, you can't even). The alias is only useful if you are a subscriber (I suppose mailing lists won't resend alien mail) and if it is still operating (any free service expires eventually…) In the use case I know best (Open Source development mailing lists), there are good reasons to contact posters, even years after the fact (say you have inquiries about an old design decision). An yes, mailing-list archives often outlive bug/patch trackers. In the worst case, aliases can lead to communication hijacking. That's my point B3), which you didn't answer either. Typically the provider of an Open Source mailing list goes "evil", either with aggressive monetizing a la sourceforge, or by trying to turn the product proprietary. > Which unwrapping are you talking about? I developed an unwrapping > mechanism[*] to be used by the server, not the MUA. […] Yes, that's it, thanks for the pointers. I didn't remember it only kicks in when modifications can be undone. Then, it doesn't create a loophole in DMARC checks, but is only useful for part of the problem (how big a part, your draft doesn't say). >> B) Mailing lists >> 1) >> Fragmenting the ecosystem by creating a new incompatible "blessed by >> DMARC" kind of mailing list is of course worse than everything. > > Why is that incompatible? It's incompatible with the existing usage patterns of mailing lists and expectations of the end users, as informed by 40 years of "tradition". Communication is people talking to people, not domains talking to domains, so you have to take a broad view of backward compatibility when a change leaks up to the UI. >> 2) >> Doug's note on authors' privacy addresses a kind of mailing lists. > IETF's lists are public and publicly archived. Other lists preserve > anonymity. That's not my point. My point is, in the lists I know, preserving anonymity is a bug, not a feature. Hiding the author's real address prevents some useful communication patterns. Granted, addresses in messages bring SPAM, but users already know how to protect themselves. I'm not denying this is a judgment call which you may well disagree with. Standards work however should only consider facts: accessibility of the author's real address is by design, and it has valid use cases. > In all cases, rewriting From: betters a list's deliverability. In other words, it solves the problem DMARC introduced, at the expense of forcing list users to learn new usage patterns. We should not expect them to be grateful :-) >> C) Now what >> 1) > > I agree with Doug on lists not being automatically recognizable as such. It depends for what. A message with a "List-Id" header purports to be a mailing list message. If all you have to decide is whether to bounce a rejected message or just trash it, why not take this affirmation at face value? > An alternative would be that MLM don't delist when the rejection message > text contains "DMARC". I know this is horrible, but there will never be > a dedicated 5xx code for that. […] That would be a possible variant, but what's the point of producing a bounce, if it's going to be ignored anyway? I understand the a priori reluctance to trash a message with no feedback, but here, the case is well
Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
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
Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
On Thursday, October 7, 2021 5:37:43 AM EDT Alessandro Vesely wrote: > On Thu 07/Oct/2021 09:48:12 +0200 Laura Atkins wrote: > >> On 7 Oct 2021, at 01:08, Scott Kitterman wrote: > >> > >> On October 6, 2021 11:37:26 PM UTC, John Levine wrote: > >>> It appears that Alessandro Vesely said: > Doug's emphasis on aliases tends to give that impression. Otherwise it > can > finally be a much needed attempt at formalizing the old, known From: > rewriting.>>> > >>> To point out what I would think is obvious, formalizing a bad idea > >>> doesn't make it any less bad an idea. > >> > >> Agreed. > >> > >> To give a specific example: > >> > >> The mobile mail client I use (K-9 Mail) will either display friendly name > >> or email address. Due to the compact user interface, both isn't an > >> option. > >> > >> There's one Google Group I'm a member of with a number of users with > >> DMARC p=reject domains, so their addresses are rewritten to the list > >> address. As a result, when people don't bother to say who they are in a > >> message, I end up digging through the message header to find out who > >> wrote it. > >> > >> This is not a good user experience. It's not salvageable. > > > > Agreed. The other day I was trying to refer work to a colleague I’ve only > > really interacted with on a professional mailing list. Due to header > > re-writing and no email address in any other place in the email, I didn’t > > actually have a direct email address for her. > > > > It’s also become almost impossible to search for messages from some people > > in some clients because you can’t search on from: address any longer. > > > > These are usability and UX problems induced by DMARC. > > What do we want to do, then? > > Let's exclude, for the sake of reality, both dropping DMARC altogether and > stopping to use mailing lists. What realistic possibilities are there? > > ARC, when 60% of receivers will have (reliably) implemented it? This is not > more realistic than the Vernon's kook I cited upstream. > > After careful consideration, header re-writing doesn't have to imply no > email address in any other place. Savvy lists save the original From: in > Reply-To: or Cc:. If some lists don't do that, perhaps specifying how to > re-write From: can improve that condition, no? When everything is done > well, it is possible to unmunge From: and fully recover pre-DMARC > functionality while still enjoying DMARC checks. > > > Do you see other possibilities? I don't think there is a single "solution". If there was, we would have achieved some kind of consensus around it. There is a mix of different things which can be done to mitigate the impact of DMARC on mailing lists. 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. The From field and its related semantics are nearing a half-century in age. It's out of our charter's scope to try and change them and even if we could, I don't think we should try. I doubt anyone can anticipate the unintended consequences of doing so. I'm also extremely skeptical of solutions that require user interface changes. If reading email "correctly" requires training a non-technical end user, we've lost. Some of you will recall what we did to address the SPF "forwarding problem" in Appendix D of RFC 7208. I suspect that a compendium of solutions like this is the best way forward, although I doubt that's the right way to structure it. Note that this appendix didn't standardize anything. For problems that don't have a single, or even small, solution set this is essential. Here's a start on some ideas (none new): Things a MLM can do on their own: 1. Don't modify messages in ways that break DKIM signatures 2. Don't accept messages for delivery by the list from p=reject domains 3. Rewrite From to avoid negative DMARC assessments (I seriously dislike this, but let's not pretend it's going to go away) Things a MLM can do to support receivers: 1. Add and DKIM sign List-* header fields 2. Exclude mail originally from p=reject domains from bounce counts related to unsubscribing bouncing list participants 3. ARC Things receivers can do 1. Don't reject based on DMARC fail 2. I'm out of time, but something like that which defines the solution space rather then trying to specify THE solution is probably the only path forward. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
On Thu 07/Oct/2021 11:56:19 +0200 Laura Atkins wrote: On 7 Oct 2021, at 10:37, Alessandro Vesely wrote: On Thu 07/Oct/2021 09:48:12 +0200 Laura Atkins wrote: On 7 Oct 2021, at 01:08, Scott Kitterman wrote: On October 6, 2021 11:37:26 PM UTC, John Levine wrote: It appears that Alessandro Vesely said: Doug's [...] can finally be a much needed attempt at formalizing the old, known From: rewriting. formalizing a bad idea doesn't make it any less bad an idea. Agreed. Agreed. The other day I was trying to refer work to a colleague I’ve only really interacted with on a professional mailing list. Due to header re-writing and no email address in any other place in the email, I didn’t actually have a direct email address for her. What do we want to do, then? I don’t know, honestly. Convince people to actually sign their emails and put .sig files in? There are multiple lists I’m on that has people who post and I have no idea who it is because they neither sign their messages nor include a .sig file and the list sets the reply-to: as back to the list. Implement a ‘original author / submittor’ header for mailing lists? There's Dave's Author: RFC 9057. It assumes From: rewriting, but doesn't specify it. It complains that using Reply-To: distorts its meaning, in case the MLM wanted to set it to the list itself, so adds the new field. RFC 9057 came out as independent submission. I'd support adopting Doug's I/D, but all this stuff, specifications of DMARC improvements to support indirect mail flows, is part of phase II of the charter, which is considered complete. It might be easier to update mailing list software to include a new header than trying to change every SMTP server out there. Sure! Maybe it is because the IETF is so slow in reacting. Maybe the IETF is so slow because there are no beautiful solutions. The result is that we are confined to techniques which can be applied unilaterally. Let's exclude, for the sake of reality, both dropping DMARC altogether and stopping to use mailing lists. What realistic possibilities are there? If I had a realistic solution I’d have proposed it years ago. But just because I don’t have a solution doesn’t mean that any other solution is better than nothing. Sometimes proposed solutions compound the problem, not fix it. ARC, when 60% of receivers will have (reliably) implemented it? This is not more realistic than the Vernon's kook I cited upstream. After careful consideration, header re-writing doesn't have to imply no email address in any other place. Savvy lists save the original From: in Reply-To: or Cc:. If some lists don't do that, perhaps specifying how to re-write From: can improve that condition, no? When everything is done well, it is possible to unmunge From: and fully recover pre-DMARC functionality while still enjoying DMARC checks. The avalanche has started, it’s too late for the pebbles to vote. Do you see other possibilities? There are fewer legitimate intermediaries (although there is the inevitable long tail of older installations) than there are legitimate SMTP services. Fixing the mailing list problem by adding a new header to identify the original posters email address may be a better solution than codifying the horrible hack that is From munging / rewriting. Uh?!? What's the new field worth for if we don't codify the horrible hack? My unmunging filter looks at each candidate field, Reply-To:, Cc:, Original-From:, and Author:, and compares the display names with that of From:. An unvarying way of rewriting would make that easier. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
OK, I will talk real. Message rewriting is a privileged function, because it can be misused. Privileges require trust and trust requires a trusted identity. In this context, the privilege has to be granted by the evaluator, and the list has to know that the evaluator has granted that privilege. You have two options: - use only the list organization identity, so that the evaluation is based on the list identity, OR - register with the evaluator, so that you are granted privileged status to use other organization identities, and know that you have been granted privileged status. ARC fails on exactly this point. ARC only works if the evaluator examines ARC and the List knows that the evaluator will use ARC to allow list messages. Without that knowledge, the list has to assume an absence of trust and use a fallback method of sender rewrite. When 60% of the world implements ARC, we will still need 100% From-munging, unless there is out-of-band communication between the evaluator and the list. Doug On Thu, Oct 7, 2021 at 5:06 AM Alessandro Vesely wrote: > On Thu 07/Oct/2021 00:32:30 +0200 Douglas Foster wrote: > > I can define three ways that a list can be reliably identified. > > The list bounce address is known to the evaluator, and: > > - The list bounce address is known to the evaluator and the message is > DKIM-signed by the list bounce address. > > - The list bounce address is known to the evaluator, is the message's > MailFrom address, and the message produces SPF PASS. > > - The list's server identities are known to the evaluator, and can be > verified by IP address and/or Forward-confirmed DNS. > > > How come a list is known to the evaluator? I don't want to go hunting > each and > every mailing list I ever subscribed to, let alone pester my users for > doing so > in turn. > > For wet dreams, I did outline a three-way opt-in whereby servers become > aware > when their users subscribe to mailing lists... Let's talk real. > > > Best > Ale > -- > > > > > > > > > ___ > 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
My proposal provides a unique, permanent, user-selected alias which can be used as a valid email address as long as both sender and receiver are still subscribed to the same list. When they want to switch over to actual email addresses, they use the member-to-member alias communication to disclose that information to other person. This design is not revolutionary; it is used successfully in many other contexts. - Scott's problem is that an individual address was rewritten to a generic list address. - Laura's problem was that the rewritten address was not usable. - John complained about users not having control over their rewritten list identity. None of these problems are applicable to my proposal. Please read the whole thing. Doug Foster On Wed, Oct 6, 2021 at 8:08 PM Scott Kitterman wrote: > > > On October 6, 2021 11:37:26 PM UTC, John Levine wrote: > >It appears that Alessandro Vesely said: > >>Doug's emphasis on aliases tends to give that impression. Otherwise it > can > >>finally be a much needed attempt at formalizing the old, known From: > rewriting. > > > >To point out what I would think is obvious, formalizing a bad idea > doesn't make > >it any less bad an idea. > > Agreed. > > To give a specific example: > > The mobile mail client I use (K-9 Mail) will either display friendly name > or email address. Due to the compact user interface, both isn't an option. > > There's one Google Group I'm a member of with a number of users with DMARC > p=reject domains, so their addresses are rewritten to the list address. As > a result, when people don't bother to say who they are in a message, I end > up digging through the message header to find out who wrote it. > > This is not a good user experience. It's not salvageable. > > Scott K > > ___ > 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
> On 7 Oct 2021, at 10:37, Alessandro Vesely wrote: > > On Thu 07/Oct/2021 09:48:12 +0200 Laura Atkins wrote: >>> On 7 Oct 2021, at 01:08, Scott Kitterman wrote: >>> On October 6, 2021 11:37:26 PM UTC, John Levine wrote: It appears that Alessandro Vesely said: > Doug's emphasis on aliases tends to give that impression. Otherwise it > can finally be a much needed attempt at formalizing the old, known From: > rewriting. To point out what I would think is obvious, formalizing a bad idea doesn't make it any less bad an idea. >>> Agreed. >>> To give a specific example: >>> The mobile mail client I use (K-9 Mail) will either display friendly name >>> or email address. Due to the compact user interface, both isn't an option. >>> There's one Google Group I'm a member of with a number of users with DMARC >>> p=reject domains, so their addresses are rewritten to the list address. As >>> a result, when people don't bother to say who they are in a message, I end >>> up digging through the message header to find out who wrote it. >>> This is not a good user experience. It's not salvageable. >> Agreed. The other day I was trying to refer work to a colleague I’ve only >> really interacted with on a professional mailing list. Due to header >> re-writing and no email address in any other place in the email, I didn’t >> actually have a direct email address for her. >> It’s also become almost impossible to search for messages from some people >> in some clients because you can’t search on from: address any longer. >> These are usability and UX problems induced by DMARC. > > > What do we want to do, then? I don’t know, honestly. Convince people to actually sign their emails and put .sig files in? There are multiple lists I’m on that has people who post and I have no idea who it is because they neither sign their messages nor include a .sig file and the list sets the reply-to: as back to the list. Implement a ‘original author / submittor’ header for mailing lists? It might be easier to update mailing list software to include a new header than trying to change every SMTP server out there. > Let's exclude, for the sake of reality, both dropping DMARC altogether and > stopping to use mailing lists. What realistic possibilities are there? If I had a realistic solution I’d have proposed it years ago. But just because I don’t have a solution doesn’t mean that any other solution is better than nothing. Sometimes proposed solutions compound the problem, not fix it. > ARC, when 60% of receivers will have (reliably) implemented it? This is not > more realistic than the Vernon's kook I cited upstream. > > After careful consideration, header re-writing doesn't have to imply no email > address in any other place. Savvy lists save the original From: in Reply-To: > or Cc:. If some lists don't do that, perhaps specifying how to re-write > From: can improve that condition, no? When everything is done well, it is > possible to unmunge From: and fully recover pre-DMARC functionality while > still enjoying DMARC checks. The avalanche has started, it’s too late for the pebbles to vote. > Do you see other possibilities? There are fewer legitimate intermediaries (although there is the inevitable long tail of older installations) than there are legitimate SMTP services. Fixing the mailing list problem by adding a new header to identify the original posters email address may be a better solution than codifying the horrible hack that is From munging / rewriting. laura -- Having an Email Crisis? 800 823-9674 Laura Atkins Word to the Wise la...@wordtothewise.com (650) 437-0741 Email Delivery Blog: http://wordtothewise.com/blog ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
On Thu 07/Oct/2021 09:48:12 +0200 Laura Atkins wrote: On 7 Oct 2021, at 01:08, Scott Kitterman wrote: On October 6, 2021 11:37:26 PM UTC, John Levine wrote: It appears that Alessandro Vesely said: Doug's emphasis on aliases tends to give that impression. Otherwise it can finally be a much needed attempt at formalizing the old, known From: rewriting. To point out what I would think is obvious, formalizing a bad idea doesn't make it any less bad an idea. Agreed. To give a specific example: The mobile mail client I use (K-9 Mail) will either display friendly name or email address. Due to the compact user interface, both isn't an option. There's one Google Group I'm a member of with a number of users with DMARC p=reject domains, so their addresses are rewritten to the list address. As a result, when people don't bother to say who they are in a message, I end up digging through the message header to find out who wrote it. This is not a good user experience. It's not salvageable. Agreed. The other day I was trying to refer work to a colleague I’ve only really interacted with on a professional mailing list. Due to header re-writing and no email address in any other place in the email, I didn’t actually have a direct email address for her. It’s also become almost impossible to search for messages from some people in some clients because you can’t search on from: address any longer. These are usability and UX problems induced by DMARC. What do we want to do, then? Let's exclude, for the sake of reality, both dropping DMARC altogether and stopping to use mailing lists. What realistic possibilities are there? ARC, when 60% of receivers will have (reliably) implemented it? This is not more realistic than the Vernon's kook I cited upstream. After careful consideration, header re-writing doesn't have to imply no email address in any other place. Savvy lists save the original From: in Reply-To: or Cc:. If some lists don't do that, perhaps specifying how to re-write From: can improve that condition, no? When everything is done well, it is possible to unmunge From: and fully recover pre-DMARC functionality while still enjoying DMARC checks. Do you see other possibilities? Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
On Thu 07/Oct/2021 00:32:30 +0200 Douglas Foster wrote: I can define three ways that a list can be reliably identified. The list bounce address is known to the evaluator, and: - The list bounce address is known to the evaluator and the message is DKIM-signed by the list bounce address. - The list bounce address is known to the evaluator, is the message's MailFrom address, and the message produces SPF PASS. - The list's server identities are known to the evaluator, and can be verified by IP address and/or Forward-confirmed DNS. How come a list is known to the evaluator? I don't want to go hunting each and every mailing list I ever subscribed to, let alone pester my users for doing so in turn. For wet dreams, I did outline a three-way opt-in whereby servers become aware when their users subscribe to mailing lists... Let's talk real. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
> On 7 Oct 2021, at 01:08, Scott Kitterman wrote: > > > > On October 6, 2021 11:37:26 PM UTC, John Levine wrote: >> It appears that Alessandro Vesely said: >>> Doug's emphasis on aliases tends to give that impression. Otherwise it can >>> finally be a much needed attempt at formalizing the old, known From: >>> rewriting. >> >> To point out what I would think is obvious, formalizing a bad idea doesn't >> make >> it any less bad an idea. > > Agreed. > > To give a specific example: > > The mobile mail client I use (K-9 Mail) will either display friendly name or > email address. Due to the compact user interface, both isn't an option. > > There's one Google Group I'm a member of with a number of users with DMARC > p=reject domains, so their addresses are rewritten to the list address. As a > result, when people don't bother to say who they are in a message, I end up > digging through the message header to find out who wrote it. > > This is not a good user experience. It's not salvageable. Agreed. The other day I was trying to refer work to a colleague I’ve only really interacted with on a professional mailing list. Due to header re-writing and no email address in any other place in the email, I didn’t actually have a direct email address for her. It’s also become almost impossible to search for messages from some people in some clients because you can’t search on from: address any longer. These are usability and UX problems induced by DMARC. laura -- Having an Email Crisis? 800 823-9674 Laura Atkins Word to the Wise la...@wordtothewise.com (650) 437-0741 Email Delivery Blog: http://wordtothewise.com/blog ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
