diff options
Diffstat (limited to 'src')
| -rw-r--r-- | src/_posts/2021-07-06-maddy-vps.md | 115 | ||||
| -rw-r--r-- | src/assets/maddy-vps/success.png | bin | 0 -> 9360 bytes |
2 files changed, 115 insertions, 0 deletions
diff --git a/src/_posts/2021-07-06-maddy-vps.md b/src/_posts/2021-07-06-maddy-vps.md new file mode 100644 index 0000000..93c76d2 --- /dev/null +++ b/src/_posts/2021-07-06-maddy-vps.md @@ -0,0 +1,115 @@ +--- +title: >- + Setting Up maddy On A VPS +description: >- + We have delivery! +tags: tech +series: selfhost +--- + +In the previous post I left off with being blocked by my ISP from sending +outbound emails on port 25, effectively forcing me to set up [maddy][maddy] on a +virtual private server (VPS) somewhere else. + +After some research I chose [Vultr][vultr] as my VPS of choice. They apparently +don't block you from sending outbound emails on port 25, and are in general +pretty cheap. I rented their smallest VPS server for $5/month, plus an +additional $3/month to reserve an IPv4 address (though I'm not sure I really +need that, I have dDNS set up at home and could easily get that working here as +well). + +## TLS + +The first major hurdle was getting TLS certs for `mydomain.com` (not the real +domain) onto my Vultr box. For the time being I've opted to effectively +copy-paste my local [LetsEncrypt][le] setup to Vultr, using certbot to +periodically update my records using DNS TXT challenges. + +The downside to this is that I now require my Cloudflare API key to be present +on the Vultr box, which effectively means that if the box ever gets owned +someone will have full access to all my DNS. For now I've locked down the box as +best as I can, and will look into changing the setup in the future. There's two +ways I could go about it: + +* SCP the certs from my local box to the remote everytime they're renewed. This + would require setting up a new user on the remote box with very narrow + privileges. This isn't the worst thing though. + +* Use a different challenge method than DNS TXT records. + +But again, I'm trying to set up maddy, not LetsEncrypt, and so I needed to move +on. + +## Deployment + +In the previous post I talked about how I'm using nix to generate a systemd +service file which encompasses all dependencies automatically, without needing +to install anything to the global system or my nix profile. + +Since that's already been set up, it's fairly trivial to use `nix-copy-closure` +to copy a service file, and _all_ of its dependencies (including configuration) +from my local box to the remote Vultr box. Simply: + +``` +nix-copy-closure -s <ssh host> <nix store path> +``` + +I whipped up some scripts around this so that I can run a single make target and +have it build the service (and all deps), do a `nix-copy-closure` to the remote +host, copy the service file into `/etc/systemd/service`, and restart the +service. + +## Changes + +For the most part the maddy deployment on the remote box is the same as on the +local one. Down the road I will likely change them both significantly, so that +the remote one only deals with SMTP (no need for IMAP) and the local one will +automatically forward all submitted messages to it. + +Once that's done, and the remote Vultr box is set up on my [nebula][nebula] +network, there won't be a need for the remote maddy to do any SMTP +authentication, since the submission endpoint can be made entirely private. + +For now, however, I've set up maddy on the remote box's public interface with +SMTP authentication enabled, to make testing easier. + +## Testing + +And now, to test it! I changed the SMTP credentials in my `~/.mailrc` file as +appropriate, and let a test email rip: + +``` +echo 'Hello! This is a cool email' | mailx -s 'Subject' -r 'Me <me@mydomain.com>' 'test.email@gmail.com' +``` + +This would, ideally, send an email from my SMTP server (on my domain) to a test +gmail domain. Unfortunately, it did not do that, but instead maddy spit this out +in its log: + +> maddy[1547]: queue: delivery attempt failed {"msg_id":"330a1ed9","rcpt":"mediocregopher@gmail.com","reason":"[2001:19f0:5001:355a:5400:3ff:fe73:3d02] Our system has detected that\nthis message does not meet IPv6 sending guidelines regarding PTR\nrecords and authentication. Please review\n https://support.google.com/mail/?p=IPv6AuthError for more information\n. gn42si18496961ejc.717 - gsmtp","remote_server":"gmail-smtp-in.l.google.com.","smtp_code":550,"smtp_enchcode":"5.7.1","smtp_msg":"gmail-smtp-in.l.google.com. said: [2001:19f0:5001:355a:5400:3ff:fe73:3d02] Our system has detected that\nthis message does not meet IPv6 sending guidelines regarding PTR\nrecords and authentication. Please review\n https://support.google.com/mail/?p=IPv6AuthError for more information\n. gn42si18496961ejc.717 - gsmtp"} + +Luckily Vultr makes setting up PTR records for reverse DNS fairly easy. They +even allowed me to do it on my box's IPv6 address which I'm not paying to +reserve (though I'm not sure what the long-term risks of that are... can it +change?). + +Once done, I attempted to send my email again, and what do you know... + + + +Success! + +So now I can send emails. There are a few next steps from here: + +* Get the VPS on my nebula network and lock it down properly. + +* Fix the TLS cert situation. + +* Set up the remote maddy to forward submissions to my local maddy. + +* Use my sick new email! + +[maddy]: https://maddy.email +[le]: https://letsencrypt.org/ +[vultr]: https://www.vultr.com/ +[nebula]: https://github.com/slackhq/nebula diff --git a/src/assets/maddy-vps/success.png b/src/assets/maddy-vps/success.png Binary files differnew file mode 100644 index 0000000..3d24c25 --- /dev/null +++ b/src/assets/maddy-vps/success.png |
