email-setup.md (9232B)
1 # Keeping my email sorted (the hard way) 2 3 I have recently made some changes to my email setup. In this post I'll 4 explain the motivation behind these changes and what I did in practice. 5 6 ## Self-hosting? 7 8 When I got my virtual machine up and running at 9 [openbsd.amsterdam](https://openbsd.amsterdam/) - the one where this 10 website is hosted - I originally planned to host my private email 11 server there too. I knew this was probably a hard task, but you know, 12 everything is hard until you learn how to do it. 13 14 I wanted to do this for a couple of reasons. The main one was to use my 15 `@tronto.net` email address, but I also liked the idea of staying away 16 from large internet companies (my main email address was connected to my 17 Google account). Not that there is anything inherently wrong with using 18 services from this big companies, but I like the idea of not being too 19 dependent on them. 20 21 After reading 22 [a nice tutorial at poolp.org](https://poolp.org/posts/2019-09-14/setting-up-a-mail-server-with-opensmtpd-dovecot-and-rspamd/) 23 I was a bit discouraged. The guide was well-written, all the steps seemed 24 doable if taken one by one, and I was happy to have dug into this topic 25 because I learned a lot. However, an email server apparently consists of 26 a lot of moving pieces: an smtp server, spam filter, DNS, DKIM... it is 27 a lot to keep track of. Even assuming that I would be able to set this 28 thing up AND to keep in mind what each of these pieces does, as soon as a 29 problem of any kind arises - config-breaking updates? domain registration 30 expiring? me messing up with my VM and making it unreachable? - I knew I 31 had to be one to fix the mistake. And I cannot afford to be immediately 32 available whenever something bad happens. Sometimes I might just have a 33 full week were I don't have time to fiddle around with smtpd and whatnot, 34 and I can't afford being unreachable via email for a week. 35 36 ## My old setup (until September 2022) 37 38 Having abandoned the idea of self-hosting, I looked for alternatives. I 39 figured that if my goals were just to use my own domain and stay away 40 from Google, I could sign up for a smaller email provider that offers 41 custom domains. It turns out there are a lot of them. After some careful 42 considerations I decided to go with [mailbox.org](https://mailbox.org). I 43 like their transparency and privacy focus and the fact that they are 44 based in the EU. I pay 3€ per month (the 1€ tier does not offer 45 custom domains) and I am happy with their service. 46 47 Setting up the server side was quite simle. Using custom domains 48 requires a tiny bit of work, but it was all well explained in the 49 [FAQs](https://kb.mailbox.org/en/private/custom-domains). 50 51 On my local machine I used (and still use) the amazing 52 [mblaze](https://github.com/leahneukirchen/mblaze), which is essentially 53 [MH](https://en.wikipedia.org/wiki/MH_Message_Handling_System) 54 for [Maildir](https://en.wikipedia.org/wiki/Maildir) folders. 55 In practice, mblaze is a set of commands to manage emails directly 56 from the command line, without using a graphical environment or a 57 [TUI](https://en.wikipedia.org/wiki/Text-based_user_interface) like 58 [Mutt](https://en.wikipedia.org/wiki/Mutt_(email_client)). This system 59 is incredibly flexible, check it out if you don't know it! 60 61 Being just a mail user agent, mblaze cannot retrieve or send 62 email. These tasks can be accomplished by other small pieces of 63 software: I used [msmtp](https://marlam.de/msmtp) for sending 64 email and [mpop](https://marlam.de/mpop) for downloading it 65 from mailbox.org's server. As the name suggests, mpop uses the 66 [POP3](https://en.wikipedia.org/wiki/Post_Office_Protocol) 67 protocol instead of the more common 68 [IMAP](https://en.wikipedia.org/wiki/Internet_Message_Access_Protocol). 69 The main difference is that POP3 simply retrieves your email, while 70 IMAP keeps the server and client folders synchronized. There are many 71 advantages and disadvantages to this choice, I won't go into detail on 72 them in this post. 73 74 As for my other devices, my local mailfolder is kept in sync with my 75 server using [syncthing](https://syncthing.net). I also use an amail 76 client on my phone with IMAP, connected directly to the mail server. 77 78 ## Nitpicking 79 80 Since I am subscribed to a couple of high-traffic mailing lists that 81 I read just for curiosity, it is necessary for me to have an easy way 82 to download and view regular emails separately from that coming from 83 mailing lists. 84 85 This was kinda easy to set up with mpop's filters, but my configuration 86 was a bit of a hack. One disadvantage of this soution was that it 87 only solved the problem on my laptop(s). On my webmail and on my phone, 88 my inbox was a complete mess of mailing lists, newsletter and a few 89 important emails. 90 91 After thinking about it for a while I figured that an elegant solution 92 would be to set up alternative email addresses for receiving mailing 93 list emails, like `list@tronto.net`. Then I would manage those different 94 mailboxes separately. 95 96 Setting the aliases up on mailbox.org was easy, but unfortunately all my 97 `@tronto.net` address used the same inbox, so I did not solve any problem 98 at all. I could add some sub-folders and set up filters so that incoming 99 mail gets sorted out, but the app on my phone could not read sub-folders 100 and mailbox did not allow top-level folders (or I could not find a way to 101 create them). Besides, tinkering with IMAP folders was not something 102 that I found particularly exciting. 103 104 But there was another solution... 105 106 ## My current setup (since September 2022) 107 108 I decided to try and redirect the mailing list emails to my personal 109 server. Configuring OpenBSD's smtp to receive emails from one specific 110 outside source (my mailbox.org account) and sort them into some local 111 folders is order of magnitudes easier than setting up a full-fledged 112 email server. No problems with DKIM, no incoming spam, no nothing. 113 114 It took me a few hours to figure our how to do this, but in the 115 end it is just a matter of configuring a few filters on mailbox.org 116 and adding a couple of lines to `/etc/mail/stmp.conf`. 117 118 ### mailbox.org filters 119 120 On my mailbox.org webmail I simply set up a filter to redirect any email 121 sent to `list@example.com` (a made-up name for the mailing list I am 122 subscribed to) to my private server. No copy of these emails is kept on 123 the server, so they don't clutter my normal (IMAP) inbox. I risk missing 124 a few of these emails if my server goes down, but it is a public mailing 125 list and I can always check the archives online. 126 127 I could not just send these emails to `something@tronto.net`, otherwise 128 they would simply be taken care of by mailbox - the MX records for my 129 domain point to their servers. But it turns out you can send mail to 130 a server using its IP address, as long as the server is configured to 131 accept such mail. So I set up the redirects to `list@[46.23.91.214]` - 132 where `46.23.91.214` is the IP address of my server. 133 134 ### smtpd.conf 135 136 The second step is configuring smtpd, OpenBSD's default mail server 137 daemon, to deal with incoming email. 138 139 First of all we need to list the virtual user `list` in 140 `/etc/mail/aliases` so that any mail sent to it is interpreted as being 141 sent to my regular user. 142 143 ``` 144 # cat 'list: sebastiano' >> /etc/mail/aliases 145 ``` 146 147 Then we have to change the line `listen on lo0` to `listen on all` 148 in `/etc/smtp.conf`. 149 150 Then we need to add an `action` and a `match` lines to the same file: 151 152 ``` 153 # cat << EOF >> /etc/mail/smtpd.conf 154 > action "list" maildir "~/mail/list" alias <aliases> 155 > match from any for rcpt-to "list@[46.23.91.214]" action "list" 156 > EOF 157 ``` 158 159 And finally restart smtpd with `rcctl restart smtpd`. 160 161 This does the trick: now all email I receive from the `list@example.com` 162 mailing list is redirected by my mailbox account to my private server, 163 where smtpd takes care of sending it to the mail directory `~/mail/list`. 164 165 ### No mpop needed 166 167 Once the mail is delivered to `~/mail/list`, I can get it from there 168 to my laptop in any way I like - for example using syncthing, like I 169 do for all my important files. In this way the mailing list emails are 170 regularly downloaded and kept in sync, and I don't need to use mpop to 171 retrieve them. 172 173 This is quite convenient, one less piece of software to keep track of! 174 In fact, I can do the same for all other email I receive. I just need 175 to set up the appropriate rules on mailbox: this time I want the mail 176 to be sent to `sebastiano@[46.23.91.214]` and *a copy to be kept on the 177 mailbox.org server*, so that I can easily access it from my phone's app as 178 well. Then I add two slightly different lines to `/etc/mail/smtpd.conf`: 179 180 ``` 181 # cat << EOF >> /etc/mail/smtpd.conf 182 > action "seb" maildir "~/mail/inbox" user sebastiano 183 > match from any for rcpt-to "sebastiano@[46.23.91.214]" action "seb" 184 > EOF 185 ``` 186 187 And the new setup is ready! 188 189 ### Sending email 190 191 I did not change the way I send email: I still use msmtp. 192 193 ## Happy now? 194 195 Yes, this new setup works and I am always happy when things work. 196 Of course, one might make the case that things worked before as well... 197 198 I am happy that I could work my way around a basic smtpd configuration. 199 Besides being useful knowledge on its own, it may make a second attempt 200 at self-hosting my email less daunting. I don't know if I am ever going 201 to try that, though.