Setting up postfix and dovecot

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Setting up postfix and dovecot

Peter Humphrey-3
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.

The first difficulty is knowing what domain names to use. 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, or should I only consider the local traffic on the LAN
and use its ID? What names do I put in my self-certified SSL? And where should
all the SSL files go? /etc/postfix, /etc/dovecot or /etc/ssl? I don't intend
to run a web server on the same box, nor to use the postfix box to send
outgoing mail: I just want to fetch my ISP's mail via POP3 (they don't offer
IMAP) and serve it to my workstation via IMAP.

It would be good to start the new year with a working setup.

--
Regards,
Peter.




Reply | Threaded
Open this post in threaded view
|

Re: Setting up postfix and dovecot

Grant Taylor-2
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.

Reply | Threaded
Open this post in threaded view
|

Re: Setting up postfix and dovecot

Neil Bothwick
In reply to this post by Peter Humphrey-3
On Tue, 25 Dec 2018 12:58:39 +0000, Peter Humphrey wrote:

> I just want to fetch my ISP's mail via POP3 (they don't offer
> IMAP) and serve it to my workstation via IMAP.

In that case, you don't need postfix at all. You can fetch with getmail
and deliver to local mailboxes with procmail. I use this method to
collect the occasional mails from my Zen mailbox.

However, consider Grant's comments about allowing for possible future
uses - although this setup doesn't preclude also using Postfix, which I
do.


--
Neil Bothwick

We all know what comes after 'X', said Tom, wisely.

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Setting up postfix and dovecot

Peter Humphrey-3
In reply to this post by Grant Taylor-2
On Tuesday, 25 December 2018 17:49:36 GMT Grant Taylor wrote:

[Big snip...]

> 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.

That's been my difficulty all along: understanding what I need to do, before
trying to set it up. Your recommendations are a great help in that, together
with the considerable detail you offered.

Many thanks for all the time and trouble you put into your reply, Grant. I am
grateful, and you can be sure I'll act on it.

Thanks again.

--
Regards,
Peter.




Reply | Threaded
Open this post in threaded view
|

Re: Setting up postfix and dovecot

Grant Taylor-2
On 01/10/2019 09:59 AM, Peter Humphrey wrote:
> That's been my difficulty all along: understanding what I need to do,
> before trying to set it up. Your recommendations are a great help in that,
> together with the considerable detail you offered.

Been there.  Done that.  If I can help others avoid some of the pain,
great!  Or at the very least streamline some things so it's less painful.

> Many thanks for all the time and trouble you put into your reply,
> Grant. I am grateful, and you can be sure I'll act on it.

You're quite welcome.

Feel free to reply or email me directly if you want to discuss more
details.  (gtaylor (at) tnetconsulting (dot) net)

> Thanks again.

:-)



--
Grant. . . .
unix || die