clo-devel August 2024

clo-devel@common-lisp.net

3 participants
5 discussions

Re: Now that mail transfer is encrypted: stricter DMARC?
by Erik Huelsmann 27 Aug '24

27 Aug '24

Hi Philipp, On Tue, Aug 27, 2024 at 8:16 AM Philipp Marek <philipp(a)marek.priv.at> wrote: > > Does this affect anybody on this mailing list? Any comments with > > respect to the stricter policy? > > - Thanks for the hard work > > - My biggest worry is about notifications and error messages to admin@ > not arriving > You mean because of the fact that more mails might classified as SPAM on our host? If that's your worry, I can say that that's not the impact of this setting: the "quarantine" value is read from DNS by hosts processing mail claiming to originate from the @common-lisp.net domain. These processors establish the authenticity of the mail through SPF and DKIM. If the authenticity test fails, the current setting ("none") has no effect on mail delivery. The proposed value ("quarantine") does have effect on mail delivery: the value requests to separate from the regular mail flow. Most mail providers do this by sending those mails straight to SPAM. Either way, we will receive reports from the big mail processing companies (fastmail, zoho, microsoft, google, ...) describing what they did with mail flow coming from @common-lisp.net. There are applications to process these mails to have (visual) integrated reports; we don't have that software in place at the moment. It would be nice to process the individual reports into a visualization like that. Maybe that's something someone else can work on. -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

1 0

Now that mail transfer is encrypted: stricter DMARC?
by Erik Huelsmann 26 Aug '24

26 Aug '24

Hi, Since a few weeks now, we're running DMARC for the mailing lists. So far, we've run with the loosest policy possible ("none"). The other options are "quarantine" and "reject". I'm thinking we'll want mail sent using our domain (common-lisp.net), failing the DMARC checks (failing SPF and/or DKIM), to be quarantined (moved to SPAM) at the very least. I noticed that fastmail is using an even stricter policy ("reject"), but moving straight from "none" to "reject" seems too much (because "reject" prevents delivery; not just moving to SPAM). This will affect everybody using an @common-lisp.net mail address with their own mail server. Does this affect anybody on this mailing list? Any comments with respect to the stricter policy? Regards, Erik.

2 1

Exim changes: encrypted mail outflow
by Erik Huelsmann 26 Aug '24

26 Aug '24

Hi all, Finally, I've been able to configure outgoing mail on common-lisp.net using TLS on outbound connections. As it turns out, I had to resort to ACLs (setfacl/getfacl) to assign Exim's primary group (Debian-exim) read access to /etc/letsencrypt/{live,archive}. For some reason, being granted read access through the secondary group, doesn't work for Exim and leads to "Error reading file" messages in the logs. On my test messages, GMail now reports that common-lisp.net used encryption to send the mails.) (Consider this mail to be a test-case for mails sent through the mailing list software.) Regards, -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

1 0

Testing email
by Raymond Toy 22 Aug '24

22 Aug '24

Just testing if I can send email here, after the latest DMARC changes. -- Ray

2 1

Stricter DMARC?
by Erik Hulsmann 04 Aug '24

04 Aug '24

Hi, Since a few weeks now, we're running DMARC for the mailing lists. So far, we've run with the loosest policy possible ("none"). The other options are "quarantine" and "reject". This will affect everybody using an @common-lisp.net domain for their mail while sending these mails from their own service provider rather than injecting via common-lisp.net. I'm thinking we'll want mail sent using our domain, failing the DMARC checks, to be quarantined (moved to SPAM) at the very least. I noticed that fastmail is using an even stricter policy ("reject"). Is it time to increase the barriers on (ab)using our domain? Will this impact anybody on this list? Regards, Erik.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

clo-devel August 2024