- clo-devel - mailman3.common-lisp.net

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

Does GMail consider itself "low reputation"?
by Erik Huelsmann 20 Jul '24

20 Jul '24

Hi, In the mail server logs, I found: 2024-07-19 10:39:16 1sUl13-00EJCh-1P ** andy.arvid(a)gmail.com R=outbound T=remote_smtp H=gmail-smtp-in.l.google.com [2a00:1450:400c:c04::1a] X=TLS1.3:ECDHE_X25519__ECDSA_SECP256R1_SHA256__AES_256_GCM:256 CV=yes: SMTP error from remote mail server after end of data: 550-5.7.1 [2a01:4f8:160:83c4::8 19] Gmail has detected that this message is\n550-5.7.1 likely suspicious due to the very low reputation of the sending\n550-5.7.1 domain. To best protect our users from spam, the message has been\n550-5.7.1 blocked. For more information, go to\n550 5.7.1 https://support.google.com/mail/answer/188131 ffacd0b85a97d-368786b3865si463916f8f.529 - gsmtp This is from sending my prior mail from a GMail account. The " common-lisp.net" domain has a High (=highest) domain reputation and the IP reputation is not published, but also not referred to. So I can nothing but conclude this must be the @gmail.com address that I'm sending from that's triggering this response? How can I fight this?! -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

2 2

More mail settings changes
by Erik Huelsmann 19 Jul '24

19 Jul '24

Hi, Yesterday, I've changed the settings on the server to stop doing sender/callout: verification of existence of the mail address of the sender; although it's considered abuse (of the server of the owner of the verified domain), it's been a very effective method of keeping spam in check in the past. However, it seems to keep out some DMARC reports as well. At the same time, I've changed the mail processing parameters: SPF is now checked earlier in the mail transaction and instead of calling out to an external application, it's processed by Exim's SPF capability internally. This mail is both a heads-up as well as a test mail to see if mail still comes through. Regards, -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

3 2

Mail system status: some problems solved (and some not)
by Erik Huelsmann 19 Jul '24

19 Jul '24

Hi, Introduction of ARC signing and a DMARC DNS record seem to have satisfied Google's bulk sender requirements again: the domain reputation has gone back to High (from Medium since mid-June). Also, mails to GMail addresses from our mailing lists are not being blocked by GMail anymore. So far, so good. What's not working yet, is the mail forwarding service where users have an @common-lisp.net address where the forward address is hosted by Google. These mails are not being ARC signed; while Exim has an (experimental) feature to apply ARC signing to mails, the maintainer(s) at Debian will not consider enabling it ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058808) There are mail-filters (milters) in the Debian ecosystem which *will* allow ARC signing for this mail flow, but Exim doesn't support milters under the pretense that it is sufficiently extensible not to need that. Which is probably true since they embed a Perl interpreter (why?!). On the other hand, since milters are a generally accepted extension mechanism for mail servers, the combination of positions taken by the Exim developers and the Debian Exim packagers, is rather unfortunately resulting in the fact that we can't forward mail to Google... I'm open to ideas or options that I may have missed while doing my research for solutions. Regards, -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

1 1

ARC signing with mailman
by erik＠hucs.nl 15 Jul '24

15 Jul '24

Injecting a mail from c-l.net doesn't work too cleanly. Injecting the mail from my other server.

2 1

ARC test
by ehuelsmann＠common-lisp.net 15 Jul '24

15 Jul '24

Because GMail discarded my earlier mails, trying again...

1 0

ARC signing test
by Erik Huelsmann 15 Jul '24

15 Jul '24

This message *could* be signed, but testing the new setup...

1 0

ARC signing test
by Erik Huelsmann 15 Jul '24

15 Jul '24

This message *could* be ARC signed. This is a test. -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

1 0

SRS rewriting fixed & simplified
by Erik Huelsmann 15 Jul '24

15 Jul '24

Hi, When checking the mail setup to figure out what we can do to get ARC signing working (both for forwarded as well as for mailing list mail), I found from my testing that SRS rewriting wasn't working anymore. I have changed and simplified the mail system setup: it's now using the built-in SRS in Exim and instead of very complex setup with an external daemon, I was able to copy (almost verbatim) the example setup from the Exim manuals to make it work. This, however, doesn't solve the ARC signing problem. Hopefully at least *some* of our setup starts working better again. My next thought is to enable ARC signing in mailman3, because at least that will fix mailing list traffic handling, if nothing else. Other ideas? Regards, Erik.

1 0

Implement ARC signing of e-mail / help wanted
by Erik Huelsmann 14 Jul '24

14 Jul '24

Hi, The common-lisp.net domain is getting bounces from GMail that the reputation of our domain is too low to accept some messages. Apparently, GMail wants mail forwarded by a host to be ARC-signed ( http://arc-spec.org/) in addition to having it DKIM signed by the original domain. Since our setup has multiple functions, mail forwarding is handled by different parts of the mail system setup. In relation to ARC-signing, we: * Forward mail for users with *(a)common-lisp.net mail addresses (directly by Exim4) * Handle mail for common-lisp.net mailing lists (using mailman) Does anybody have experience setting up a system like this? Questions that need to be answered, I think: * Can we set up ARC signing on the exim4 outbound level (so that we have ARC signing only once, both for the mailing lists and forwarded mail? * Does every step in the mail chain on the host need to implement ARC signing (i.e. Mailman level *and* the mail service responsible for managing the mail queue)? * How to implement ARC signing for forwarded mail on exim4 on Debian, since the exim4 instance (version 4.96) only supports DKIM signing, not ARC signing... Any thoughts? Experiences to be shared? Regards, -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

3 2