DKIM signature on all mail hosts

TPA-RFC-44 emergency procedures (#40981 (closed)) was adopted, let's move on with the next step:

Same as #40988 (closed), but for other mail hosts:

• BridgeDB
• CiviCRM
• GitLab
• LDAP
• MTA
• rdsys
• RT
• Submission done in #40988 (closed)

To be done in Puppet. See https://gitlab.torproject.org/tpo/tpa/team/-/wikis/service/email#manual-dkim-configuration for the manual procedure, make sure to update the Installation docs there to take into account the DKIM procedure when done in puppet.

marked this issue as related to #40981 (closed)

marked this issue as related to #40988 (closed)

changed milestone to %improve mail services

added Email Next labels

assigned to @anarcat

marked this issue as related to #40990 (closed)

mentioned in issue #40981 (closed)

mentioned in issue #40986 (closed)

assigned to @lavamind and unassigned @anarcat

changed the description

mentioned in issue #40988 (closed)

changed the description

mentioned in issue #40990 (closed)

I've deployed the new classes and templates in Puppet for OpenDKIM, and tested on rude aka RT. It seems to be working, and mails sent to my riseup.net address report a valid signature. I'll hold off on deploying to other hosts, because @anarcat is out for the weekend, and because its late in the week. We should be able to wrap this up and deploy to other hosts next Monday.

I'm also curious if enabling DKIM verification on rude would be beneficial for the RT spam problem.

DKIM, but also SPF and DMARC checks would definitely be a must here. I set that up at home with OpenDMARC:

https://anarc.at/services/mail/#dmarc-spf-pre-checks

... and that's certainly something we could do there as well. RT could be a good candidate, but i'd eventually deploy this across the board as well.

a.

...

On 2022-12-08 20:01:11, Jérôme Charaoui (@lavamind) wrote:

I'm also curious if enabling DKIM verification on rude would be beneficial for the RT spam problem.

-- Antoine Beaupré torproject.org system administration

marked the checklist item RT as completed

added Doing label and removed Next label

marked the checklist item BridgeDB as completed

BridgeDB is now signing outbound email, and it still verifying incoming emails as before. However, since incoming emails are relayed from eugeni and this host has recently gained the ability to verify DKIM itself, perhaps we don't need to verify DKIM signatures on polyanthum, and we could rely on the Authentication-Results from OpenDKIM on eugeni.

After looking at the BridgeDB source, I don't think the AlwaysAddARHeader is really needed, since it does not appear to handle none results any differently, which is what the setting affects.

marked the checklist item LDAP as completed

DKIM deployed on alberti and signing mail from @db.torproject.org senders.

marked the checklist item rdsys as completed

DKIM deployed on rdsys-frontend-01 and signing mail sent from gettor@torproject.org.

marked the checklist item CiviCRM as completed

marked the checklist item GitLab as completed

marked the checklist item MTA as completed

OpenDKIM deployed on all hosts identified in the ticket description. We should note that Nagios and Puppet also send notifications, and their mails are not signed. Either we deploy OpenDKIM on these hosts, or we can have eugeni sign them on their behalf.

Those hosts currently relay mail through eugeni right? So they shouldn't need to do any signing on their own...

(Now, nagios should really not be relaying mail through eugeni because we want it to be able to send notifications autonomously, but that's a different problem.)

...

On 2022-12-13 20:23:52, Jérôme Charaoui (@lavamind) wrote:

OpenDKIM deployed on all hosts identified in the ticket description. We should note that Nagios and Puppet also send notifications, and their mails are not signed. Either we deploy OpenDKIM on these hosts, or we can have eugeni sign them on their behalf.

-- Antoine Beaupré torproject.org system administration

They do relay mail through eugeni, however the sender domain part is @<HOSTNAME>.torproject.org. In that context, we either need to use SubDomains true (unclear if that actually works) or add <HOSTNAME>.torproject.org to the Domain list.

In both cases, we'd also need to add a DNS entry to put the eugeni DKIM _domainkey under those subdomains.

hmm... but then all hosts do this: they all send mail as HOSTNAME.tpo... do we want to have all of those signed with OpenDKIM? Or should we just sweep that one under the rug and pretend it's okay to have root jobs not signed?

humpf...

...

On 2022-12-14 15:40:22, Jérôme Charaoui (@lavamind) wrote:

They do relay mail through eugeni, however the sender domain part is @<HOSTNAME>.torproject.org. In that context, we either need to use SubDomains true (unclear if that actually works) or add <HOSTNAME>.torproject.org to the Domain list.

In both cases, we'd also need to add a DNS entry to put the eugeni DKIM _domainkey under those subdomains.

-- Antoine Beaupré torproject.org system administration

One thing we could do, maybe, is have eugeni rewrite the sender part from <HOSTNAME>.torproject.org to torproject.org before sending the mails out into the world, and adding our internal hosts IPv4 and IPv6 blocks to InternalHosts on eugeni.

That way we'd avoid both the need to extra keys in DNS, and listing every single hostname in opendkim.conf.

Interesting idea... sounds an awful lot like #40987 (closed) (sender-rewriting MX), but for eugeni... i was thinking of building a new host for this (called MTA)... but yeah, that makes sense!

...

On 2022-12-14 15:53:48, Jérôme Charaoui (@lavamind) wrote:

One thing we could do, maybe, is have eugeni rewrite the sender part from <HOSTNAME>.torproject.org to torproject.org before sending the mails out into the world, and adding our internal hosts IPv4 and IPv6 blocks to InternalHosts on eugeni.

-- Antoine Beaupré torproject.org system administration

We did a test mailing with @mattlav this afternoon and scored a 0% bounce rate on a small mailing of a few hundred recipients, up for the abysmal 50-60% we were seeing lately. Hopefully that holds up mostly true with the (much larger) upcoming mailings, but I think so far so good.

By adding crm-ext-01.tpo to InternalHosts on eugeni, newsletter subscription confirmation emails are now also DKIM-signed.

mentioned in commit wiki-replica@8f9758ce

I've updated the wiki documentation to replace the fully manual setup instructions with the Puppetized setup steps, mainly involving Hiera confiuration and deploying the generated keys to DNS.

I thought keeping both the manual and puppetized procedures would be too confusing.

i restored the manual procedure. there are parts of it that are not documented in the new one (at least the REmoveOldSignatures bit, for example). THe manual procedure also contains rationale like how the selectors were picked that doesn't seem represented in the new procedure.

closed

mentioned in commit wiki-replica@34924b66

@lavamind could you give me a rough estimate of the time spent here?

I spent about half a day last week, and a full day this week, so about 10 hours.

Actually now that I think of it it was more like a full day last week, but over several days. So 14 hours would be more accurate.

can you actually mark it here, with /spend 14h? :)

added 14h of time spent