More documentation copied
This commit is contained in:
parent
f2df688c33
commit
1546fa8199
3 changed files with 311 additions and 206 deletions
|
|
@ -3,11 +3,13 @@ title: ISPmail guide for Debian 12 “Bookworm”
|
|||
lastUpdated: 2023-09-24
|
||||
---
|
||||
|
||||
Once upon a time there were many mail servers on the internet. If your organisation wanted to receive and send emails then you would have your system administrator set up a mail server. He would add a DNS record and create a cryptic Sendmail configuration file. Fast forward a few decades and suddenly we have arrived in the cloud ages. The world of internet services is dominated by a few monopolistic companies. Having worked in IT for 25 years I feel frustrated about the ignorance and laziness of decision makers. Cloud providers rip obscene profits while IT staff is evolving into dumb customers instead of doing their actual job.
|
||||
Once upon a time there were many mail servers on the internet. If your organisation wanted to receive and send emails then you would have your system administrator set up a mail server. He would add a DNS record and create a cryptic Sendmail configuration file.
|
||||
|
||||
Fast forward a few decades and suddenly we have arrived in a monopolistic dystopy. The world of internet services is dominated by a few companies. Having worked in IT for 25 years I feel frustrated about the ignorance and laziness of decision makers. Cloud providers rip obscene profits and lock clueless customers in, while their IT staff is evolving into dumb victims instead of doing their actual job.
|
||||
|
||||
If you are like me then you want to stay as independent as possible. And that includes being in charge of your own email service. Maybe not for your employer but at least for yourself, your friends and family. Become your own internet service provider (ISP) for email. Hence the name: ISPmail.
|
||||
|
||||
This is a complete and free guide that teaches you how to set up and run your own mail server. At the end of the guide you will have your own fully featured mail server based on open-source software using a cheap virtual 5€ server. And you will have learned all about the various components, protocols and technologies. This guide has been battle-tested by thousands of other sysadmins and constantly evolved over the last 20 years. I am publishing this guide without any commercial motives, so all you would have to invest is your time.
|
||||
This is a complete and free guide that teaches you how to set up and run your own mail server. At the end of the guide you will have your own fully featured mail server based on open-source software using a cheap virtual server for a few bucks per month. And you will have learned all about the various components, protocols and technologies. This guide has been battle-tested by thousands of other sysadmins and constantly evolved over the last 20 years. I am publishing this guide without any commercial motives, so all you would have to invest is your time.
|
||||
|
||||
## What your mail server can do
|
||||
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ Let us look at the first two in detail. The third one – relay domains – is n
|
|||
Once upon a time users logged into servers using [Telnet](https://en.wikipedia.org/wiki/Telnet) or
|
||||
[SSH](https://en.wikipedia.org/wiki/Secure_Shell) to read their email in basic text-based mail clients. Their email
|
||||
addresses were often just a combination of their login name and the server name. Something like
|
||||
_mpauls@server17.biology.example.net_.
|
||||
`mpauls@server17.biology.example.net`.
|
||||
|
||||
At least that made things pretty simple for the server administrator. He just accepted emails for any valid login user
|
||||
on that server. The mail server knew what to do. It checked if “mpauls” is found in /etc/passwd and then stored emails
|
||||
|
|
@ -40,8 +40,8 @@ If you wanted to do it that way…
|
|||
essentially inviting attackers to harm your server.
|
||||
2. If you want to host many email accounts this becomes impractical.
|
||||
3. Postfix cannot distinguish the local domains. If you have three local domains “example.org”, “example.com” and
|
||||
“example.net” then all these email addresses would lead to the same mailbox: john@example.org, john@example.com and
|
||||
john@example.net. So you cannot use different domains for different purposes.
|
||||
“example.net” then all these email addresses would lead to the same mailbox: `john@example.org`, `john@example.com` and
|
||||
`john@example.net`. So you cannot use different domains for different purposes.
|
||||
|
||||
To tell Postfix which domain you consider local you list them in the “mydestination” configuration setting in your
|
||||
main.cf configuration file. Example:
|
||||
|
|
@ -76,9 +76,9 @@ Postfix handles hosted email addresses by checking two _mappings_:
|
|||
|
||||
So much terminology. Time for an example, isn’t it? Let’s tell Postfix we want to have three email addresses:
|
||||
|
||||
- john@example.org
|
||||
- jack@example.org
|
||||
- jack@example.com (_note that this is another domain than example.org_)
|
||||
- `john@example.org`
|
||||
- `jack@example.org`
|
||||
- `jack@example.com` _(note that this is another domain than example.org)_
|
||||
|
||||
Postfix only understands _mappings_. They are much easier than they sound. A mapping is just a table that has a left and
|
||||
a right column. Postfix always looks for stuff in the left column (_key_) to find more information in the right column
|
||||
|
|
@ -86,7 +86,122 @@ a right column. Postfix always looks for stuff in the left column (_key_) to fin
|
|||
|
||||
| Virtual mailbox (key) | Virtual mailbox location on disk (value) |
|
||||
| --------------------- | ---------------------------------------- |
|
||||
| john@example.org | /var/vmail/example.org/john/Maildir |
|
||||
| jack@example.org | /var/vmail/example.org/jack/Maildir |
|
||||
| jack@example.com | /var/vmail/example.com/jack/Maildir |
|
||||
| `john@example.org` | /var/vmail/example.org/john/Maildir |
|
||||
| `jack@example.org` | /var/vmail/example.org/jack/Maildir |
|
||||
| `jack@example.com` | /var/vmail/example.com/jack/Maildir |
|
||||
|
||||
So the left column lists the valid email addresses. And the right column is apparently some path on disk. Right, that’s all the magic. If an email for `jack@example.org` is received then Postfix will find the entry in the left column and can figure out where Jack’s mails are stored on disk.
|
||||
|
||||
Before checking if a specific email address is valid Postfix first checks if it is responsible for the domain at all. That’s done by this mapping:
|
||||
|
||||
|
||||
| Virtualdomain (key) | Whateve (value) |
|
||||
| ------------------- | --------------- |
|
||||
| example.org | Kittens |
|
||||
| example.com | Puppies |
|
||||
|
||||
So there are two domains in the left column. But what is that in the right column? Kittens? Really? Well, the truth is: it doesn’t matter. It can be anything. So why is that column there at all? The reason is that _mappings_ always have two columns. Postfix wants a list of domains but it has no concepts for _lists_. So it uses this format and ignores the right column.
|
||||
|
||||
Essentially these two mappings are all we need. Add a little configuration and you can already receive emails. However Postfix provides another useful feature: _aliases_. An alias is a redirection (or _forwarding_) of one email address to one or more other addresses. Possible uses:
|
||||
|
||||
- forward postmaster@… for all your domains to one mailbox
|
||||
- create an email distribution list for a team or department
|
||||
- forward copies of all your emails to another address
|
||||
- redirect emails meant for a coworker who has left the organisation
|
||||
|
||||
As usual Postfix expects a mapping for aliases. Time for another example:
|
||||
|
||||
| Step | Virtual email address (left) | Redirect to (right) |
|
||||
| :--- | :--------------------------- | :---------------------------------------- |
|
||||
| 1 | `postmaster@example.org` | `jack@example.com` |
|
||||
| 2 | `abuse@example.org` | `jack@example.com` |
|
||||
| 3 | `jack@example.com` | `jack@example.com`,`jacky@workaround.org` |
|
||||
| 4 | `sophie@example.net` | `hr@example.net` |
|
||||
| 5 | `hr@example.net` | `rick@example.net` |
|
||||
| | `hr@example.net` | `tina@example.net` |
|
||||
| 6 | `@example.org` | `jack@example.com` (DANGEROUS!) |
|
||||
|
||||
Quite a lot happens here. How does Postfix interpret this table?
|
||||
|
||||
1. Redirect emails for `postmaster@example.org` to `jack@example.org`
|
||||
2. Redirect emails for `abuse@example.org` also to `jack@example.org`
|
||||
3. Keep a copy of an incoming email for `jack@example.com` in his mailbox and send another copy to `jacky@workaround.org.` Yes, you can use multiple email addresses seperated by commas.
|
||||
4. Sophie has left the organisation so her address is forwarded to HR.
|
||||
5. The HR team consists of two members: `rick@example.net` and `tina@example.net.` Every email to `hr@example.net` will be forwarded to each of them. This works similar to (3) but this time the target addresses are not seperated by commas but stored in different rows.
|
||||
6. Forward any email address of the _example.org_ domain to `jack@example.com.` We call this a _catch-all_ address. This is dangerous for two reasons. First it will send the poor Jack anything that is sent to the _example.org_ domain if there is no user account for that address. (Yes, spammers guess addresses.) And second it disables a security check in Postfix that the destination address `jack@example.com` actually exists. Postfix may first receive the email and then be confused if the recipient is not reachable. That leads to backscatter and harms your reputation. But don’t worry. I will show you the proper way to use catch-all addresses later.
|
||||
|
||||
So basically this is the way that Postfix handles aliases:
|
||||
|
||||
1. Is the domain of the email address defined as a virtual domain?
|
||||
2. Get all rows of the table where the email address is found in the left column. Send a copy of the email to everyone mentioned in the right column. If the right column contains multiple email addresses separated by commas then split them first.
|
||||
3. If there was no such row then check again if there is an `_@domain_` row.
|
||||
4. Still nothing found? Then reject the email.
|
||||
|
||||
<Aside type="tip">
|
||||
Two email addresses are mandatory for every domain that you host. `postmaster@domain` and `abuse@domain.` These requirements are documented in RFC 521 and RFC 2142. Be sure to add aliases for them. If an email to those addresses will bounce your domain reputation will suffer.
|
||||
</Aside>
|
||||
|
||||
## Database
|
||||
|
||||
Did you get the idea of mappings? Two columns? Keys and values? Good. Now how do those mappings work when we want to put the information into an SQL database?
|
||||
|
||||
Basically a relational database works in rows and columns, too. So we can take the format of the tables shown above and put them into database tables. Let’s call these tables…
|
||||
|
||||
- virtual_domains (for the list of domains)
|
||||
- virtual_aliases (for the aliases mapping)
|
||||
- virtual_users (for the email users and their mailboxes respectively)
|
||||
|
||||
I won’t bore you with the SQL stuff right now. Let’s do that in a later chapter. Let’s just briefly cover how Postfix can get data from the database. We provide Postfix with configuration files for that purpose. These files often have a “.cf” suffix (**c**onfiguration **f**ile).
|
||||
|
||||
Let’s take the virtual_domains table for example. This is the contents of a file that is located at `/etc/postfix/mysql-virtual-mailbox-maps.cf`:
|
||||
|
||||
```
|
||||
# Information on how to connect to your MySQL server
|
||||
user = someone
|
||||
password = some_password
|
||||
hosts = 127.0.0.1
|
||||
dbname = mailserver
|
||||
|
||||
# The SQL query string
|
||||
query = SELECT mailbox_path FROM virtual_users WHERE email_address='%s'
|
||||
```
|
||||
|
||||
The first four lines describe how the database can be connected to. You provide a database user and database password as well as the IP address or hostname of the SQL server and the name of the database.
|
||||
|
||||
A more interesting bit is the _query_ that is defined in the last line. Postfix still thinks in left and right columns. So it will run this query and replace the %s by the email address it is looking for – that’s what is expected in the left column. The database will then get all rows from the database table that match this criterion. If one row matches the query then the “SELECT mailbox_path” will return just the value of what Postfix would expect to be in the right column.
|
||||
|
||||
That’s all the magic that Postfix needs to talk to your SQL database. You tell Postfix how to connect to the database and how the data in the database table corresponds to the left and right columns.
|
||||
|
||||
Note that a lookup here must only return just one row from the database. Postfix must uniquely know where the mailbox path for a given user is. There are other mappings though where it’s allowed to have multiple right-hand side items for one left-hand side item – for example in virtual aliases.
|
||||
|
||||
To use the above configuration file you have to configure it in Postfix’s main.cf file:
|
||||
|
||||
```
|
||||
virtual_mailbox_maps = mysql:/etc/postfix/mysql-virtual_mailbox_maps.cf
|
||||
```
|
||||
|
||||
If you find that this mapping is not working as you expected then the “postmap -q” command is your friend. You can ask Postfix what the right-hand side value for a given left-side value is. Say that you are interested in the mailbox_path for the email_address “`john@example.org`”:
|
||||
|
||||
```
|
||||
postmap -q `john@example.org` mysql:/etc/postfix/mysql-virtual_mailbox_maps.cf
|
||||
```
|
||||
|
||||
Postfix will then run the above SQL query with your “`john@example.org`” argument:
|
||||
|
||||
```
|
||||
SELECT mailbox_path FROM virtual_users WHERE email_address='`john@example.org`'
|
||||
```
|
||||
|
||||
The result should be:
|
||||
|
||||
```
|
||||
/var/vmail/example.org/john/Maildir
|
||||
```
|
||||
|
||||
In this guide we will use a slight variation of that SQL query:
|
||||
|
||||
```
|
||||
query = SELECT 1 FROM virtual_users WHERE email='%s'
|
||||
```
|
||||
|
||||
Postfix does not need to know where the mailbox is located on disk. We will not use Postfix to store the email to disk. Instead we will make Postfix hand over the email to Dovecot which stores the email. Dovecot has a couple of nice extra features (like server-side scripts) that we want to use. So Postfix just needs to know whether an email address is valid or not. We just return “1” because actually the right column is not considered anyway. Postfix just needs to know whether there is a database row or not.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue