Re: [DNG] Again, again: DMARC is a no-win problem for mailing lists (was: Can we fix this DMARC thing?)
Hi, Steve. First, apologies last night if I was a bit peeved. It's just that I really had put quite a lot of effort into making sure Dyne.org people and the Dng community understood the problem, and that my recommendation was to enable a least-bad mitigation within GNU Mailman that 'munged' _only_ mail from domains that made the (IMO, bad) choice to publish highly aggressive DMARC policies, not out of any liking for Reply-To munging, but because there wasn't a better alternative. Quoting Steve Litt (sl...@troubleshooters.com): > So, if we insist on assisting Yahoo, Gmail, Hotmail, and their ilk, and > all their users, by incorporating DMARC at all, we could at least > change the munge string from: > > Firstname Lastname via Dng > > to: > > GOES TO DNG (IRT Firstname Lastname) Are you in the middle of submitting a patch to GNU Mailman, then? I'm expect they will give it appropriate consideration, and give you expert feedback (which, possibly, the rest of us will appreciate hearing). OTOH, expecting Dyne.org people to hand-hack the local Mailman installation, rather than trying to get it accepted by the developers, and not even providing anyone with a patch, doesn't strike me as even a tiny bit reasonable. And, gosh, I'm sorry to say you appear to be so suggesting, which again, for the second night in a row, makes me a little sad. Also, have you bothered to make sure you understand Mailman's DMARC mitigation, before jumping in? I'm guessing 'nope'. (Again, just to be crystal-clear, I myself am neither a Dyne.org administrator nor a GNU Mailman developer, further underlining my point about how you would be best advised to address the correct people with your, um, semi-developed notions, and not the wrong ones.) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Result of the Debian vote 'General Resolution: Init systems and systemd'
Result of the Debian vote 'General Resolution: Init systems and systemd' https://www.debian.org/vote/2019/vote_002 The voting period ended on Friday 2019-12-27 23:59:59 UTC Result https://vote.debian.org/~secretary/gr_initsystems/results.txt The winners are: Option 2 "B: Systemd but we support exploring alternatives" Proposal B Proposer: Sam Hartman [hartm...@debian.org] [text of proposal] [amendment] Choice 2: B: Systemd but we support exploring alternatives Using its power under Constitution section 4.1 (5), the project issues the following statement describing our current position on Init systems, multiple init systems, and the use of systemd facilities. This statement describes the position of the project at the time it is adopted. That position may evolve as time passes without the need to resort to future general resolutions. The GR process remains available if the project needs a decision and cannot come to a consensus. The Debian project recognizes that systemd service units are the preferred configuration for describing how to start a daemon/service. However, Debian remains an environment where developers and users can explore and develop alternate init systems and alternatives to systemd features. Those interested in exploring such alternatives need to provide the necessary development and packaging resources to do that work. Technologies such as elogind that facilitate exploring alternatives while running software that depends on some systemd interfaces remain important to Debian. It is important that the project support the efforts of developers working on such technologies where there is overlap between these technologies and the rest of the project, for example by reviewing patches and participating in discussions in a timely manner. Packages should include service units or init scripts to start daemons and services. Packages may use any systemd facility at the package maintainer's discretion, provided that this is consistent with other Policy requirements and the normal expectation that packages shouldn't depend on experimental or unsupported (in Debian) features of other packages. Packages may include support for alternate init systems besides systemd and may include alternatives for any systemd-specific interfaces they use. Maintainers use their normal procedures for deciding which patches to include. Debian is committed to working with derivatives that make different choices about init systems. As with all our interactions with downstreams, the relevant maintainers will work with the downstreams to figure out which changes it makes sense to fold into Debian and which changes remain purely in the derivative. Miscelánea Natural http://www.miscelaneanatural.org Anfibios de Asturias http://www.anfibiosdeasturias.org HackLab Pica Pica http://www.picahack.org Actividades de informática con software libre http://eslibreasturias.rf.gd ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Result of the Debian vote 'General Resolution: Init systems and systemd'
My comments:
A mediocre result, neither good nor bad.
The best option for people who don't want to use systemd, Option 6 "E: Support
for multiple init systems is Required", came in last.
But Option 1 "F: Focus on systemd" came in second place, if it had won it would
have been a tragedy.
We remain more or less as we are ("The Debian project recognizes that systemd
service units are the preferred configuration", "Packages may include support
for alternate init systems besides systemd and may include alternatives for any
systemd-specific interfaces they use", "Maintainers use their normal procedures
for deciding which patches to include", "Debian is committed to working with
derivatives that make different choices about init systems" as a simple
recommendation), now with the certainty that it will remain so for at least
some time. A project offering Debian packages free of systemd dependencies
remains necessary.
Best regards!
Miscelánea Natural http://www.miscelaneanatural.org
Anfibios de Asturias http://www.anfibiosdeasturias.org
HackLab Pica Pica http://www.picahack.org
Actividades de informática con software libre http://eslibreasturias.rf.gd
En sábado, 28 de diciembre de 2019 10:27:35 CET, Alexis PM via Dng
escribió:
Result of the Debian vote
'General Resolution: Init systems and systemd'
https://www.debian.org/vote/2019/vote_002
The voting period ended on Friday 2019-12-27 23:59:59 UTC
Result
https://vote.debian.org/~secretary/gr_initsystems/results.txt
The winners are:
Option 2 "B: Systemd but we support exploring alternatives"
Proposal B Proposer: Sam Hartman [hartm...@debian.org] [text of proposal]
[amendment]
Choice 2: B: Systemd but we support exploring alternatives
Using its power under Constitution section 4.1 (5), the project issues the
following statement describing our current position on Init systems, multiple
init systems, and the use of systemd facilities. This statement describes the
position of the project at the time it is adopted. That position may evolve as
time passes without the need to resort to future general resolutions. The GR
process remains available if the project needs a decision and cannot come to a
consensus.
The Debian project recognizes that systemd service units are the preferred
configuration for describing how to start a daemon/service. However, Debian
remains an environment where developers and users can explore and develop
alternate init systems and alternatives to systemd features. Those interested
in exploring such alternatives need to provide the necessary development and
packaging resources to do that work. Technologies such as elogind that
facilitate exploring alternatives while running software that depends on some
systemd interfaces remain important to Debian. It is important that the project
support the efforts of developers working on such technologies where there is
overlap between these technologies and the rest of the project, for example by
reviewing patches and participating in discussions in a timely manner.
Packages should include service units or init scripts to start daemons and
services. Packages may use any systemd facility at the package maintainer's
discretion, provided that this is consistent with other Policy requirements and
the normal expectation that packages shouldn't depend on experimental or
unsupported (in Debian) features of other packages. Packages may include
support for alternate init systems besides systemd and may include alternatives
for any systemd-specific interfaces they use. Maintainers use their normal
procedures for deciding which patches to include.
Debian is committed to working with derivatives that make different choices
about init systems. As with all our interactions with downstreams, the relevant
maintainers will work with the downstreams to figure out which changes it makes
sense to fold into Debian and which changes remain purely in the derivative.
Miscelánea Natural http://www.miscelaneanatural.org
Anfibios de Asturias http://www.anfibiosdeasturias.org
HackLab Pica Pica http://www.picahack.org
Actividades de informática con software libre http://eslibreasturias.rf.gd
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Result of the Debian vote 'General Resolution: Init systems and systemd'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, On 28/12/19 9:03 pm, Alexis PM via Dng wrote: > A mediocre result, neither good nor bad. The best option for people > who don't want to use systemd, Option 6 "E: Support for multiple > init systems is Required", came in last. But Option 1 "F: Focus on > systemd" came in second place, if it had won it would have been a > tragedy. It's completely broken when only one group of interested parties have the only say; DDs should be ashamed. Another wasted opportunity to make things right has been blown and there probably won't be any other opportunity afforded ever again :( Debian needs to somehow find a way to include users (especially sysadmins) in a meaningful way in votes of such significance. A. -BEGIN PGP SIGNATURE- iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCXgdGXQAKCRCoFmvLt+/i +z4mAP4x7ateI5rKrp4KelB64iy5prRlmb7C5Dz6/QBaol4FLQEAk3FcV0Poiy+f dJyq5lOuMZfEk7PvQlZluOU5bUKeeM4= =oikP -END PGP SIGNATURE- ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Again, again: DMARC is a no-win problem for mailing lists
On 28/12/2019 07:01, Steve Litt wrote: > So, if we insist on assisting Yahoo, Gmail, Hotmail, and their ilk, and > all their users, by incorporating DMARC Really, it's surely not a matter of willingly helping them. It's more a matter of survival at all in a world where they carry a significant proportion (possibly a majority but it's not certain) of the world's email and where they re-make the rules to suit themselves. Just be glad they still support SMTP at all! -- Mark Rousell ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Again, again: DMARC is a no-win problem for mailing lists
On 28/12/2019 08:34, Rick Moen wrote: > Are you in the middle of submitting a patch to GNU Mailman, then? I'm > expect they will give it appropriate consideration, and give you expert > feedback (which, possibly, the rest of us will appreciate hearing). > > OTOH, expecting Dyne.org people to hand-hack the local Mailman installation, > rather than trying to get it accepted by the developers, and not even > providing anyone with a patch, doesn't strike me as even a tiny bit > reasonable. And, gosh, I'm sorry to say you appear to be so suggesting, > which again, for the second night in a row, makes me a little sad. > > Also, have you bothered to make sure you understand Mailman's > DMARC mitigation, before jumping in? I'm guessing 'nope'. > > (Again, just to be crystal-clear, I myself am neither a Dyne.org > administrator nor a GNU Mailman developer, further underlining my point > about how you would be best advised to address the correct people with > your, um, semi-developed notions, and not the wrong ones.) Chillax, it's Christmas (or the seasonal celebration of one's choice)! :-) Even without having to submit a patch or knowing the full ins and out of Mailman's DMARC mitigation, it strikes me that Steve's request was a reasonable one. It would help for non-standard behaviour to be more clear. That said, the mail list *does* seem to work as Steve wants. At least it does for my mail client (Thunderbird). On a message posted by someone posting to the list from a p=reject DMARC domain:- When I click 'Reply to List' the reply goes to the list. When I click 'Reply' the reply goes to the message's 'Reply-To' header contents which is the poster's personal email address. When I click 'Reply All' the reply goes to everyone mentioned in any To, Cc or Reply-To header. -- Mark Rousell ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Again, again: DMARC is a no-win problem for mailing lists
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 29/12/19 12:01 am, Mark Rousell wrote: > On 28/12/2019 07:01, Steve Litt wrote: >> So, if we insist on assisting Yahoo, Gmail, Hotmail, and their >> ilk, and all their users, by incorporating DMARC > > Really, it's surely not a matter of willingly helping them. It's > more a matter of survival at all in a world where they carry a > significant proportion (possibly a majority but it's not certain) > of the world's email and where they re-make the rules to suit > themselves. Just be glad they still support SMTP at all! Sadly that is too true. They screw up greylisting, they screw up SPF and they screw up DMARC. And to make matters worse, you can easily block IP addresses and IP blocks of bad email servers unless it comes from the rotten lot as above (including Apple and Microsoft). I see plenty of forwarded junk coming through my server from Apple and it's a real pain point. I just wish everyone would stop using those rotten service providers when it comes to email :( A. -BEGIN PGP SIGNATURE- iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCXgdZ/AAKCRCoFmvLt+/i +0ywAPwK9LnPkzeVNaatCEloqyHDEFDAcO08W+mGMhJdFAN1EQD/VuBBBnlmFUxv HGebU11GuFOusgjdz6YHbhrr2GwK8cU= =eaLf -END PGP SIGNATURE- ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Again, again: DMARC is a no-win problem for mailing lists
On Sat, 28 Dec 2019 13:16:19 +, Mark wrote in message <5e0755a3.80...@signal100.com>: > That said, the mail list *does* seem to work as Steve wants. ..you almost nailed it with the above observation, I'd go "the mail list does *seem* to work as Steve wants", which is how and why Steve got fooled into doing what he did. -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Result of the Debian vote 'General Resolution: Init systems and systemd'
On 2019-12-28 5:03 a.m., Alexis PM via Dng wrote:
My comments:
A mediocre result, neither good nor bad.
The best option for people who don't want to use systemd, Option 6 "E:
Support for multiple init systems is Required", came in last.
But Option 1 "F: Focus on systemd" came in second place, if it had won
it would have been a tragedy.
We remain more or less as we are ("The Debian project recognizes that
systemd service units are the preferred configuration", "Packages may
include support for alternate init systems besides systemd and may
include alternatives for any systemd-specific interfaces they use",
"Maintainers use their normal procedures for deciding which patches to
include", "Debian is committed to working with derivatives that make
different choices about init systems" as a simple recommendation), now
with the certainty that it will remain so for at least some time. A
project offering Debian packages free of systemd dependencies remains
necessary.
It looks like the mess that exists, continues to exist unabated and will
only get worse over time.
Debian has really lost its reason for being, which differentiated it
from other distros.
The strength and safety of Dev level decision making in Debian and loss
of sight of its history has turned out to be the weakness.
In several ways it looks like world politics.
The lure of continuing to use Debian as a base distro is still there,
the breadth of the repos and the freedom and strength of individual
developers remains.
This all further reinforces, now more than ever the need for Devuan.
Yes there are other non-systemd Linux choices out there, but for me the
Devuan, Debian based combination will continue to be the best choice for
general use.
Clarke
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Again, again: DMARC is a no-win problem for mailing lists
On 28/12/2019 15:02, Arnt Karlsen wrote: > On Sat, 28 Dec 2019 13:16:19 +, Mark wrote in message > <5e0755a3.80...@signal100.com>: > >> That said, the mail list *does* seem to work as Steve wants. > ..you almost nailed it with the above observation, I'd go > "the mail list does *seem* to work as Steve wants", which > is how and why Steve got fooled into doing what he did. It certainly does work as he wants it for me (as I understand his intention). :-) I.e. For senders on DMARC "p=reject" or "p=quarantined" domains, what would originally have been their From address is placed in the Reply-To field of the mailing list post. For me running Thunderbird, this ensures that when I click the Reply button my reply goes to the individual sender's Reply-To address (what was originally in their email's From field), not to the list. That is, as I understand it, what Steve wants. It could well be that Steve's mail client is failing to prioritise the Reply-To address over the From address (whereas mine priorities the Reply-To address over the >From address when I click the Reply button). For the avoidance of doubt, I have separate 'Reply to List', 'Reply All' and 'Reply' buttons. -- Mark Rousell ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Again, again: DMARC is a no-win problem for mailing lists (was: Can we fix this DMARC thing?)
Steve Litt wrote: > ... we could at least > change the munge string from: > > Firstname Lastname via Dng > > to: > > GOES TO DNG (IRT Firstname Lastname) > > So when you do "return to sender" and it crazily puts > dng@lists.dyne.org in the To field, at least that To field won't be > disguised as the user. Quick question ... Does your MUA show the full address, or does it follow the MS rule of actively hiding the actual address and only showing the name part ? I am now forced to use Outlook for mail at work, and it's a pile of steaming manure in many respects. Prior to starting work, I had to have some email exchanges with my manager so his outlook has cached both my personal and work addresses. Since Outlook makes it hard to see the email address that's behind the name, there are times when he's sent work email to my home address. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Can we fix this DMARC thing?
Hi Steve In the DMARC FAQ, Section "Receiver Questions" they say: "If emails from mailing lists are important to your users, you may therefore consider to apply specific rules for emails coming from mailing lists." [1] This is the situation right now with the DNG list: It's up to the people who do DMARC checking on the receiving end to not deny mails from the list. If a mail administrator decides to do DMARC checking on incoming mail the DMARC people advise to take special measures like "a sort of whitelist". Their tips on operating a compatible mailing list is not satisfying, all listed solutions [2] have "Cons". The best option in my opinion is to follow 3.C. This could be achieved with an ARC seal [3]. The exim-user mailing list uses this technique and it seems to work. I don't see your point of accidentally sending to the list when using "reply to sender". DNG does not change the From header. It adds an Envelope-Sender address which is correct. You might should check your Claws Mail, that it does use the From-Adress and not the Enveloppe-From for replies. What might be wrong with vm6.ganeti.dyne.org is its ability to check DKIM signatures. I have not found one that this host recognises as valid. This seems to be the receiving host for mails to the list. It should be able to successfully verify DKIM signatures before passing on a message to mailman. Regards, Adrian. [1] https://dmarc.org/wiki/FAQ#Is_there_special_handling_required_to_receive_DMARC_email_from_mailing_lists.3F [2] https://dmarc.org/wiki/FAQ#I_operate_a_mailing_list_and_I_want_to_interoperate_with_DMARC.2C_what_should_I_do.3F [3] https://en.wikipedia.org/wiki/Authenticated_Received_Chain ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Again, again: DMARC is a no-win problem for mailing lists (was: Can we fix this DMARC thing?)
On Sat, 28 Dec 2019 00:34:09 -0800 Rick Moen wrote: > Are you in the middle of submitting a patch to GNU Mailman, then? I'm > expect they will give it appropriate consideration, and give you > expert feedback (which, possibly, the rest of us will appreciate > hearing). > > OTOH, expecting Dyne.org people to hand-hack the local Mailman > installation, rather than trying to get it accepted by the > developers, and not even providing anyone with a patch, doesn't > strike me as even a tiny bit reasonable. And, gosh, I'm sorry to say > you appear to be so suggesting, which again, for the second night in > a row, makes me a little sad. In my wildest imagination, I never dreamed that Mailman wouldn't give the admin control over the text assembly of the munged from. If Mailman gives this string as a take-it-or-leave-it constant, I guess I'll just have to implement a fix on my end. Anyone know of an equivalent for procmail on the *sending* side? SteveT Steve Litt December 2019 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Again, again: DMARC is a no-win problem for mailing lists
Is there a clear rule about when the sender displays as an individual, vs "individual via DNG"? Just during this discussion I've seen it both ways. It hasn't been a problem for me, likely because I seldom participate (that won't always be the case), but I can see it being a hassle for a regular contributor. Just something I noticed, I thought I'd share in case it's helpful, I use evolution and, every time I reply to an email from the list, it prompts that I'm replying privately and then gives four options: (1)reply privately, (2)cancel, (3)reply to group (goes to individual AND mailing list), or just (4)reply to list. Oddly it gives this option every time I reply, whether to an individual or to individual via DNG. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Again, again: DMARC is a no-win problem for mailing lists
Quoting Mark Rousell (mark.rous...@signal100.com): > Even without having to submit a patch or knowing the full ins and out of > Mailman's DMARC mitigation, it strikes me that Steve's request was a > reasonable one. OK, cool, I nominate you to handle everything about this situation, from this point forward. Take charge, Mark. That'll save me the effort of trying to talk sense into people. > That said, the mail list *does* seem to work as Steve wants. It really doesn't. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Again, again: DMARC is a no-win problem for mailing lists
Quoting 'smee via Dng (dng@lists.dyne.org): > Is there a clear rule about when the sender displays as an individual, > vs "individual via DNG"? Herewith, a repost: Date: Thu, 6 Dec 2018 02:02:30 -0800 From: Rick Moen To: dng@lists.dyne.org Subject: Dng now alters (some) posts to compensate for DMARC antiforgery As of today, the esteemed Dng listadmins have made a small tweak to Mailman's operation, and have asked me to explain the change. _No_ action is required on your end. tl;dr: Mailman will now munge the From: address if and only if the sender's domain publishes a problematic DMARC policy, to substitute the mailing list's address for the sender's. On those mails, Mailman also appends a Reply-To: header pointing to the sender's real address. No other mails will be touched. Forgery of SMTP mail is a serious problem, leading to a series of proposals for extensions to the SMTP standard, to permit domains and users at mail-receipt time to detect and reject forgeries: SPF, DKIM (formerly DomainKeys), and DMARC. DMARC, from Yahoo, is the most recent of these SMTP extensions (incorporating DKIM and SPF as sub-components). Unfortunately, DMARC, when implemented by sending domains publishing a strongly asserted DMARC antiforgery policy, tends to be a disaster for mailing lists: Subscribers sending from such mail domains gradually discover that their outbound mail, when routed out through mailing list software and thus retransmitted to mailing list subscribers, gets refused (as forged) upon arrival at many of the subscribers' receiving SMTP servers. Q: Why does that mail get rejected as forged? A: Because the mailing list manager (MLM) software alters and makes additions to the sender's headers and body text, on the copies retransmitted to subscribers, with the result that the message no longer matches its DKIM cryptographic signature. Q: Which sending domains are affected? A: I referred to these as sending domains with 'strongly asserted DMARC antiforgery policies'. Specifically, this means domains that publish p=reject or p=quarantine as part of the DMARC policies in their DNS. Here's an example of the former, domain mongodb.com: $ dig -t txt _dmarc.mongodb.com [...] _dmarc.mongodb.com.300INCNAME mongodb.com.hosted.dmarc-report.com. mongodb.com.hosted.dmarc-report.com. 300 IN TXT"v=DMARC1; p=reject; rua=mailto:1eed4...@mxtoolbox.dmarc-report.com,mailto:dmarc_agg@vali.email,mailto:dmarc_repo...@mongodb.com; ruf=mailto:1eed4...@forensics.dmarc-report.com,mailto:dmarc_repo...@mongodb.com"; [...] $ Q: Which receiving domains reject such mail? A: Domains that implement DMARC and respect/enforce (some) sending domains' strongly asserted DMARC policies. For example, GMail exactly enforces sending domains' published DMARC policies (if any), when it decides what arriving mail to reject as forged. Q: If Mailman rewrites my mail for transmission to subscribers, what would that look like? A: Like this (using me as an example poster) From: Rick Moen via Dng (with) Reply-To: Rick Moen instead of the normal From: Rick Moen This example is what would occur if domain linuxmafia.com had a strongly asserted DMARC policy, which in reality it doesn't (because domain owner Rick Moen doesn't like DMARC). Q: Isn't 'munging' (forcing) of the Reply-To: header by anyone but the sender been officially a bad idea ever since IETF adopted RFCs 2822 and 2369 in 2001? A: Yes. Ironic, isn't it? GNU Mailman adopted and recommended this mitigation for the problems caused by DMARC anway, as it's the least-bad response to the fundamental hostility DMARC has for mailing lists as reflectors. The Mailman developers might eventually come up with something better, but this is the best solution they have at this writing. Q: Are other MLMs also affeected? A: Yes. Q: Who decided to adopt this modification to Dng's operation? A: It was a unanimous recommendation of the Devuan Project's weekly Jitsi conference on December 5, 2018. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Again, again: DMARC is a no-win problem for mailing lists (was: Can we fix this DMARC thing?)
Quoting Steve Litt (sl...@troubleshooters.com): > In my wildest imagination, I never dreamed that Mailman wouldn't give > the admin control over the text assembly of the munged from. Then, possibly you can suggest how. Why don't you test your solution on a test GNU Mailman installation, and advise Dyne.org's administrators about specifics you have in mind? Also, it would be a good idea for you to skim details of GNU Mailman's relevant documentation. To help you in that, here is the advice that I give on the subject to Mailman listadmins, identifying a specific admin WebUI configuration I recommend. In this case, it's my recommendation to _OSI's_ listadmins (which FWIW they implemented), because that was the easiest copy for me to find, but I gave near-identical advice to Devuan Project: Date: Sat, 1 Dec 2018 18:47:16 -0800 From: Rick Moen To: license-review-ow...@lists.opensource.org Subject: (forw) Re: [License-review] Approval: Server Side Public License, Version 2 (SSPL v2) I wish to strongly recommend, based on my own listadmin experience, the best available DMARC mitigation. DMARC is proving to be an utter nightmare for mailing lists, in as much as they are mail forwarders, and DMARC was IMO botched in its ability to accomodate the way they work. From memory, and so I'm probably dropping a bunch of detail: Because MLMs such as Mailman (appropriately) change the internal SMTP headers upon retransmitting the poster's mail to subscribers (notably the To: header), it no longer validates against the sender's domain if it is a DMARC-using one with a strict policy. Yahoo and Gmail are examples of sending domains with strict DMARC policies. There is an (IMO unhappy but least-bad-available) kludge setting in Mailman's admin WebUI to make the MLM compensate for DMARC brain-damage: You go to Privacy Options, Sender Filters, item 'Action to take when anyone posts to the list from a domain with a DMARC Reject/Quarantine Policy' aka dmarc_moderation_action. Change the radio button from Accept (default) to Munge from. To quote the help text: from_is_list (general): Replace the From: header address with the list's posting address to mitigate issues stemming from the original From: domain's DMARC or similar policies. Several protocols now in wide use attempt to ensure that use of the domain in the author's address (ie, in the From: header field) is authorized by that domain. These protocols may be incompatible with common list features such as footers, causing participating email services to bounce list traffic merely because of the address in the From: field. This has resulted in members being unsubscribed despite being perfectly able to receive mail. The following actions are applied to all list messages when selected here. To apply these actions only to messages where the domain in the From: header is determined to use such a protocol, see the dmarc_moderation_action settings under Privacy options... -> Sender filters. Settings: [...] Munge From This action replaces the poster's address in the From: header with the list's posting address and adds the poster's address to the addresses in the original Reply-To: header. So, for example, _if_ my sending domain linuxmafia.com had a strong DMARC policy (which it doesn't, because I hate DMARC with a passion), then the 'Munge from' setting would cause my post to license-review to get this 'From: ' header upon retransmission to subscribers: From: Rick Moen via license-review instead of the normal From: Rick Moen The reason this helps sidestep DMARC validation is that it's now no longer considered needing validation against linuxmafia.com's (hypothetical) DMARC policy, but rather lists.opensource.org's. I personally detest this solution because, when I send out my sending address on a mailing list, it is deliberately there so that people can, if necessary, contact me offlist. The kludge complicates this, albeit, if I remember correctly, it tries to compensate for the brain-damage by inserting a Reply-To as well. It should be noted that the Munge from kludge thus alters -only- the postings of subscribers from DMARC-damaged^H^H^H^W^W^W^Wusing domains, so only _some_ postings will get disfigured in this manner. Sadly, I recommend opting for this kludge, because otherwise deliverability suffers. I am specifically _not not not_ recommending the similar-looking setting 'Replace the From: header address with the list's posting address to mitigate issues stemming from the original From: domain's DMARC or similar policies' aka from_is_list on General Options. My understanding is that opting for _that_ version of the kludge unconditionally applies it to all postings whether they are from badly DMARC-impaired domains (ones with published p=reject or p=quarantine DMARC policies) or not. My recommendations: On Privacy options, Sender filters: dmarc_moderation_action: Munge from dmarc_quarantine_mo
Re: [DNG] Again, again: DMARC is a no-win problem for mailing lists
Quoting Andrew McGlashan via Dng (dng@lists.dyne.org): > They screw up greylisting, they screw up SPF and they screw up DMARC. They didn't screw up SPF. If you as the domain stakeholder of an SMTP-sending domain deterministically know and can specify in SPF's flexible spec format for DNS TXT records where _all_ your domain's legitimate mail will originate, then you can use SPF to good effect to make forged sending IPs detectable and rejectable at the time of SMTP receipt. I happen to be able to thus specify. It's particularly simple in my domain's case, because the sole authorised origin is one IPv4 address. Therefore... :r! dig -t txt linuxmafia.com. @ns1.linuxmafia.com. +short "v=spf1 ip4:96.95.217.99 -all" ...Works for Me[tm]. (Please note that the '-all' means my DNS recommends _permfail_ of non-compliant mail.) Occasionally, I see claims in Linux forums, including in a discussion two years ago on this mailing list, that SPF breaks on mailing lists. This is simply not true. If it'd been true, I'd have noticed at some point over the last couple of decades. Domain owners for whom SPF does _not_ work include ones who insist on originating port 25 unauthenticated SMTP from arbitary unplanned IP addresses without that mail getting rejected as a suspected of being a forgery. (Good luck with that.) For them, fortunately, even if they take that rather impractical position, SPF still doesn't hurt them: They retain the option of not publishing an SPF record, or one declaring that their mail might originate from anywhere. Oddly enough, I _can_ identify a time when my SPF record did hurt my mail delivery. It was the afternoon of December 17, 2019, when because of an ISP shutdown I had to re-IP my server for the first time in 18 years. Everything appeared to go smoothly, in part because I'd shortened TTLs to 3600 many days in advance. Less than an hour after cutover, one of my outgoing mailing list postings was rejected by luv.asn.au on grounds that my own SMTP server supposedly violated my own SPF policy. Explanation: Someone there was for some reason retaining my old SPF RR in cache longer than was supposed to happen. Problem did not recur. ;-> ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Can we fix this DMARC thing?
Quoting Adrian Zaugg (devuan@mailgurgler.com): > In the DMARC FAQ, Section "Receiver Questions" they say: "If emails from > mailing lists are important to your users, you may therefore consider to > apply specific rules for emails coming from mailing lists." [1] This is > the situation right now with the DNG list: It's up to the people who do > DMARC checking on the receiving end to not deny mails from the list. This is terrible advice, and they know it. Moreover, it's particularly cheeky. Basically, they're saying 'We created SMTP extensions that break mailing lists if a sending domain sets p=reject or p=quarantine in their policies, so we recommend as a remedy that any domain that thinks it might receive mail relayed through a mailing list set up whitelisting to compensate for the breakage we created.' > Their tips on operating a compatible mailing list is not satisfying, all > listed solutions [2] have "Cons". The best option in my opinion is to > follow 3.C. The best option is to ignore what the DMARC people recommend, and do what the mailing list people recommend. Which is -- mirabile dictu! -- what Devuan Project and innumerable other operations supporting mailing lists have done. > This could be achieved with an ARC seal [3]. 'Our SMTP extensions break mailing lists if a sending domain sets p=reject or p=quarantine in their policies, so we recommend as a remedy that the mailing list server, when getting ready to forward and retransmit the mail, do a complicated workaround where the mailing list server attests on its own to the original version's DMARC validation, and then _if_ and only if the end-receiving servers implement DMARC-crutch experimental SMTP extensions to do so, they can choose to believe the secondary attestation and let the mail through.' I'm not even going to bother articulating my view on that. The exim-user > What might be wrong with vm6.ganeti.dyne.org is its ability to check > DKIM signatures. Nope. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Again, again: DMARC is a no-win problem for mailing lists (was: Can we fix this DMARC thing?)
One note about my advice to OSI on December 1, 2018: That was, IIRC, my earliest attempt to advise fellow GNU Mailman listadmins about how to contend with the DMARC problem. A probably-mistaken small datum in what I said to OSI now sticks out: > Yahoo and Gmail are examples of sending domains with strict DMARC > policies. Correction: Either that was never true about GMail, or it was at the time of writing, but is no longer. (More likely the former.) Today: ~ $ dig -t txt _dmarc.gmail.com. +short "v=DMARC1\; p=none\; sp=quarantine\; rua=mailto:mailauth-repo...@google.com"; Substring 'p=none' means _not_ an aggressive/strict DMARC policy[1] -- unlike, say, yahoo.com's published policy: :r! dig -t txt _dmarc.yahoo.com. +short "v=DMARC1\; p=reject\; pct=100\; rua=mailto:dmarc_y_...@yahoo.com\;"; What _is_ true of GMail is that it enforces upon receipt at GMail all published DMARC policies of SMTP-sending domains (as relatively few SMTP-receiving domains yet do). Ergo, often one of the places mailing lists first notice delivery problems owing to aggressive DMARC policies is among subscribers receiving their subscription mail on GMail, who suddenly aren't getting some mailing list traffic, report their subscriptions disabled on account of mysteriously high 'bounce scores' or get mysteriously unsubscribed (for the same reason). Back when I was advising OSI, I probably confused the issues of GMail's strong application of _other_ domains' DMARC policies with its lack of an aggressive policy published for outbound gmail.com mail. What's linuxmafia.com's published policy, you might ask: :r! dig -t txt _dmarc.linuxmafia.com. +short "DMARC: tragically misdesigned since 2012. Check our SPF RR, instead." [1] gmail.com's 'sp=quarantine' in the DMARC TXT RR is a policy for any/all subdomains, one of innumerable baroque features that'll eat your evening if you start studying the hideous thing. -- Cheers, "Maybe the law ain’t perfect, but it’s the only Rick Moenone we got, and without it we got nuthin'." r...@linuxmafia.com -- U.S. Deputy Marshal Bass Reeves, circa 1875 McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
