Project

General

Profile

communication #59923

New e-mail servers/infrastructure for openSUSE domains

Added by stroeder 10 months ago. Updated 2 months ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
Project work
Start date:
2020-01-01
Due date:
% Done:

10%

Estimated time:

Description

As discussed at opensuse-heroes meeting on 2019-11-17 a new independent e-mail infrastructure will be setup for openSUSE domains like opensuse.org, opensuse.de, etc.

Overall goals:

  • Project independence
  • Improve security
  • More control

Checklist

  • Setup Dns
  • Setup test machines
  • Salting configuration
  • Run tests with test domain
  • Sent out announcements
  • Switch over to real domain and become.productive

History

#1 Updated by cboltz 10 months ago

  • Subject changed from New e-mail for openSUSE domains to New e-mail servers/infrastructure for openSUSE domains

#2 Updated by lrupp 10 months ago

  • Checklist set to [ ] Setup Dns, [ ] Setup test machines, [ ] Salting configuration, [ ] Run tests with test domain, [ ] Sent out announcements, [ ] Switch over to real domain and become.productive
  • Category set to Email
  • Status changed from New to In Progress
  • Assignee set to lrupp
  • Private changed from Yes to No

Taking over here for now to act as project manager. But I definitely need assistance in some areas.

Please note: DNS separation should be done first, before this project starts.

#3 Updated by lrupp 9 months ago

  • Category changed from Email to Project work

#4 Updated by lrupp 8 months ago

  • Checklist set to [x] Setup test machines

#5 Updated by lrupp 8 months ago

mx1 & mx2 are.ready. Thanks to Marco!

#6 Updated by lrupp 8 months ago

  • % Done changed from 0 to 10

#7 Updated by lrupp 2 months ago

  • Checklist set to [x] Setup Dns

#8 Updated by pjessen 2 months ago

I forgot we had this ticket - adding my update:

  • mx[12].o.o are both ready to relay email for “opensuse.org”, with TLS support and with spam and virus filtering. (see below).
  • TLS: I borrowed the certificates from pontifex, but of course they should be automagically distributed instead. (from crtmgr.i.o.o)
  • Member aliases are being retrieved from connect.o.o (thanks for the hint Christian) once a day, with a consistency check.
  • Mailing list aliases copied from baloo based on existing lists.
  • Firewall is open for smtp traffic only.
  • Freshclam – updated to log to own logfile, and notify admin-auto when software is outdated. (which it is).
  • Spam- and virus-filtering: I am unable to get rspamd to work. "milter unix:/run/rspamd/worker-proxy.socket: can't read SMFIC_BODYEOB reply packet header". Instead I have set up postgrey to do greylisting (selectively) and spampd to use spamassassin for spam-filter. I'm calling clamd from within spamassassin, it seems to work quite well.

There is some fine-tuning still be done on the spam- and virus filter, but I suggest we plan to go "live" some time in August (I'm back on 3 August. )

#9 Updated by cboltz 2 months ago

Sounds good :-) - thanks for your work!

AFAIK in the current setup, the aliases are fetched hourly - if it doesn't cause too much load ;-) it would be nice to keep that so that changes go live faster.

I also have a (maybe crazy?) idea for going live: in the first days, enable soft_bounce and keep mx*.suse.de as backup MX. This has the advantage that we don't break anything if something goes wrong (for example if we missed to setup an address or two, which would't surprise me too much with the "grown" setup). After running the parallel setup for some days and checking the logs for "user unknown" messages, we can drop mx*.suse.de from the MX entries and disable soft_bounce.

Oh, and most important - enjoy your vacation!

#10 Updated by pjessen 2 months ago

cboltz wrote:

AFAIK in the current setup, the aliases are fetched hourly - if it doesn't cause too much load ;-) it would be nice to keep that so that changes go live faster.

Yup, I know what you mean - there is no reason why not, I just figured it would be better to be a little conservative.

I also have a (maybe crazy?) idea for going live: in the first days, enable soft_bounce and keep mx*.suse.de as backup MX. This has the advantage that we don't break anything if something goes wrong (for example if we missed to setup an address or two, which would't surprise me too much with the "grown" setup). After running the parallel setup for some days and checking the logs for "user unknown" messages, we can drop mx*.suse.de from the MX entries and disable soft_bounce.

I agree with the idea, "better safe than sorry".

JFYI, we have three categories of forwarding -

  • member aliases
  • mailing lists
  • static addresses (postmaster, abuse, webmaster etc etc ).

I feel it would be difficult to actually miss anyone, but it does not hurt to use soft_bounce and keep mx*.suse.de for a while.

Also available in: Atom PDF