Re: [gentoo-user] Setting up postfix and dovecot

[Grant Taylor]

On 12/25/18 5:58 AM, Peter Humphrey wrote:
> Hello list,

Hi,

> 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 .me.uk 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 me.uk 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 "example.com" 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/.acme.sh/$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 (acme.sh) 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.