Mailing lists & general purpose email

[m]

NC mentioned listservs. I'de like general purpose email at the space. Some user stories:

• Point an MX record for any domain at devhack, start being able to send/recieve emails using devhack's infra automatically
• be able to create alias / mailing lists to send out emails to groups of people without them being able to see all the members.
  • set up a members only mailing list. start putting announcements in there
  • bridge mailing lists to RSS feeds
  • bridge mailing lists to matrix
  • bridge mailing lists to forum/nncp
• special-case some internal auth-less or bot-based email. for messing around with telnet email sending.
  • some sort of way to provision arbitrary email address / mailbox / forwarding. More dynamic than git repos probably but idk

[m]

Very related: #374

[talija@…]

-No one should be sending or receiving emails through domains /dev/hack does not control through /dev/hack's mail server, this is just too much of a liability. Sorry, I'm not setting up the mail server as effectively an open relay. It's a miracle we can reach gmail and hotmail as is. You cannot just buy a domain and set up email, you have to let the domain age so it has some reputation as not being spam, and domains getting added to a blocklist can have a chain reaction of the IP also getting blocklisted. Mailcow will not let you do this anyway. I can explain in more detail why this is not a really feasible idea elsewhere. Once there are other IPs it may be possible to do something with a different mail server that's set up for selective relaying rather than oriented towards end user MUAs and webmail but I am not claiming ownership of that because I think it's too risky.

-This is doable though we probably want a specific mailing list server in a container or something. We can have it send from a subdomain that passes through the mail server and it can effectively exist independently of mailcow's need for a mailbox, with mailcow just acting as the relay for the host.

-Nothing forces you to use STARTTLS as is with the mail server so you can already connect with telnet over port 25. This is possible to do but only if whatever being used has been tested an proven to be working. We do have to manually add a bypass in the spam filtering though so it doesn't check for authentication from that address, but if it's sending to a valid recipient address when bypassing those checks you can just send to a local user. Honestly if it's internal only it may be worth setting up an internal only MTA that doesn't have the restriction of needing to go through mailcow and we could just automate ourselves.

-I am not sure what this subsection is asking

[talija@…]

What we could do on the first point is have a second server that can host domains as requested, the DNS setup is just too varied to really be automatic because everyone has differing providers, and mailcow needs you to set up email authentication inside the UI. Members can point a domain at that host once there's a second IP, and be set up as domain administrators for the domain(s) they control. Essentially, we don't want to be hosting uncontrolled domains on our internal server off our main IP because we need to make sure nothing coming out of that is misconfigured, which we can't guarantee if there's a bunch of domains with varying setups on them. There's not really any way to make it so that you just point the MX and it happens, as doing so is an enormous security risk. Mailcow is also a mess of PHP in terms of how it does user provisioning, if you decouple it, it probably makes more sense to just set up the component pieces yourself. Email is still something you need change control on though, because one person's actions on the servers on one domain could impact everyone else's email deliverability, even if it's accidental.