Gentoo Archives: gentoo-user

From: Grant Taylor <gtaylor@×××××××××××××××××××××.net>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Setting up postfix and dovecot
Date: Tue, 25 Dec 2018 17:49:51
In Reply to: [gentoo-user] Setting up postfix and dovecot by Peter Humphrey
On 12/25/18 5:58 AM, Peter Humphrey wrote:
> Hello list,
> Is there a guide anywhere to setting up dovecot to work with postfix > and serve IMAP mail to a client on the same LAN segment? I've only found > fragmentary, outdated guides to certain aspects of the whole setup and > I'm left scratching my head.
I have no idea about a guide / How-To. But I do have responses (they might not qualify as answers) to your questions below.
> The first difficulty is knowing what domain names to use.
You can use any domain name that you want. But there are some pros and cons to various domain names. You can use completely internal domain names that the world has zero idea about, if you want to. Or you can use a (sub)domain of a domain that you can claim some ""ownership of. I think the biggest question about the domain name is if there is any chance that these emails will ever interact with the outside world. Or will you ever add additional services. For example if you have a multi function printer / scanner combo that you want to scan and email to your external email address? It is possible to get private internal domain completely unknown to the world to work with the world. But doing so will cause extra effort. I'd recommend using a (sub)domain of a domain that the world will recognize /if/ that is a /convenient/ option. - This is what I do. My internal things are in sub-domain of one of my globally registered domains. The depth depends on the situation.
> I have a account, which I could assign to my Internet connection > and then ask my ISP to forward its mail to me,
There's a lot in that statement. I'm not familiar with accounts or what the features thereof are. I have a Gmail account, but I'm fairly confident that I can't get Google to route information to my servers on an SMTP level. Does your internet connection have a static IP? (Dynamic can be made to work, but it will require more work.) Will your ISP allow you to host an email server? Some are quite stringent in their Terms of Service. Others don't care as long as you aren't causing a problem. Forwarding is different and has fewer features than having MX records pointing at your own server. 1) Forwarding usually uses different destination addresses to reach the forward and where the forward points to. 2) Running your own MX means that you have more visibility into the raw message stream and can do as much or as little spam / virus / etc filtering as you want. Something you very likely have no control of for the addresses that is forwarding to you. 3) You are completely dependent on the forwarding party.
> or should I only consider the local traffic on the LAN and use its ID?
I'm not quite sure what to make of that. In my opinion, the only thing that constitutes "local traffic" is how far the traffic needs to go. There is little reason for your local scanner to send to an external 3rd party that you subsequently pull email down from. The traffic crosses your internet connection twice, likely unnecessarily. What do you mean by "it's ID" and using it as such. Systems in my house / lab have the ability to send email to a local server, which then routes email to the other local systems or out to my main public mail server as necessary. - I could configure things such that my local systems could email each other directly if I wanted, but they all forward to my main account on my main email server which is external. Aside: My main email server used to be inside my house before a cross country move. But, not knowing what sort of connectivity I would have, much less timing issues, I moved my email external prior to the move. I've not yet had good connectivity to pull it back in house yet after the move.
> What names do I put in my self-certified SSL?
I would recommend that you use the fully qualified domain name of the machine / service that the certificate will be used on. What said FQDN actually is is up to you. Note: I would suggest avoiding self-signed certificates if /reasonably/ possible. Especially when email clients are involved. - Let's Encrypt helps a LOT here. You can get certificates for any host in a (sub)domain that you control and have DNS properly configured for and that the world can resolve. (It is possible to have two different DNS spaces, public and private.) Note: Let's Encrypt, et al, will want you to use properly registered domain names, even for internal things. So things like "" or "nas.lan" won't work as they aren't uniquely identifiable. (You can make them work with self signed certificates.) I put the host's FQDN in both the Common Name (CN) and Subject Alternate Name (SAN) field. Then I add any nicknames / service names / other names I want to work to the SAN field. ProTip: Make sure that the CN value is also included in the SAN. Google Chrome is starting to ignore the CN field, and only looking at the SAN field.
> And where should all the SSL files go? /etc/postfix, /etc/dovecot or > /etc/ssl?
I don't use postfix or dovecot, so I can't say for sure. But I can say that the certificates live in the following locations on my servers. /home/$USER/$FQDN - My normal user interfaces with Let's Encrypt. /etc/ssl/certs - This is the main system location. /etc/$SERVICE/ssl - This is the per service location that can't use the system wide location. My Let's Encrypt client ( runs out of my home directory. Then I have a script that runs as root to copy the new certificate to the system wide location. The script also copies from the system wide location to specific service locations that can't use the system wide location for permissions / ownership reasons. I prefer to have sym-links living in the per-service location that point to the system wide location when ever possible. Though sometimes services demand that the certificate be owned by the user that they run as, thus necessitating the need for another copy.
> I don't intend to run a web server on the same box,
I've found that plans like that almost invariably change. Will this box ever run backups? Will they be administered via a (private) web interface? Now it's a (private) web server. ;-) The point is, don't paint yourself into a corner. I'd suggest leaving room for this box being a (private) web server, even if you never end up using it. That way you won't need to re-architect things if (when) you do have reason for it to be a (private) web server.
> nor to use the postfix box to send outgoing mail:
Same as above, just a different service. Though this one may actually surprise you and try to send outgoing email without you realizing it. - Consider an internal message that is sent from your real email address (there be dragons here) and it has a problem on the local email server such that the message bounces, back to your real email address, thus going out to the world. Or if you live ~1,000 miles away from someone and it becomes convenient to scan something and email the picture to them, through your infrastructure. If you use legitimate hostnames / domain name(s) for things, it has a much higher chance of succeeding. Conversely, it's almost guaranteed that if you use private hostnames / domain name(s) things will fail. Maybe you want that. But I'd put barriers in place if that's what you want and not rely on things failing.
> I just want to fetch my ISP's mail via POP3 (they don't offer IMAP) > and serve it to my workstation via IMAP.
Okay. That's a very definitive task. One I completely understand. Note: "fetching" email is completely different than "forwarding" email. Despite the fact that email ends up on another server. Do you have a smart phone? Will you want it to access your local server? What about when said smart device is traveling and away from home? Accessing email from a smart device when away from home is a very reasonable thing. It also means that you will likely need some sort of externally recognized name to be able to locate your mail server when out and about. It also likely means that you will want some way to access it more directly when at home. There are more than a few options for this, some of which are nastier (hair pinning) than others (split DNS).
> It would be good to start the new year with a working setup.
I think it's entirely possible to get this working in the next ~5 days. But I think there may be more subtle things than you might be aware of. I say that based on the context of your email. You are asking very reasonable questions. But they seem fairly new to the process. As such, I think some of the things along the way are going to surprise you. With that in mind, please allow me to make some recommendations: 1) Use a (sub)domain that is globally registered. 2) Use a Let's Encrypt SSL certificate on the globally recognized FQDN. 3) Use split DNS for internal / external resolution. 4) I think forwarding might be the slightly lesser of the evils to get email from your ISP to your server. But that requires external accessibility to your email server. - I say this because fetchmail (et al) functionally retrieves email and re-injects it as SMTP to your local server. Thus forwarding at least doesn't switch protocols. Finally, postfix / dovecot / et al, make little difference in my opinion. I think you could easily substitute different daemons in their place. IMHO there is quite a bit more to think about than which of the specific daemons you will run or how to configure them. Rather the specific daemons fall in line after you have the answers to all the other questions and a plan of action.


Subject Author
Re: [gentoo-user] Setting up postfix and dovecot Peter Humphrey <peter@××××××××××××.uk>