1 |
On 12/25/18 5:58 AM, Peter Humphrey wrote: |
2 |
> Hello list, |
3 |
|
4 |
Hi, |
5 |
|
6 |
> Is there a guide anywhere to setting up dovecot to work with postfix |
7 |
> and serve IMAP mail to a client on the same LAN segment? I've only found |
8 |
> fragmentary, outdated guides to certain aspects of the whole setup and |
9 |
> I'm left scratching my head. |
10 |
|
11 |
I have no idea about a guide / How-To. But I do have responses (they |
12 |
might not qualify as answers) to your questions below. |
13 |
|
14 |
> The first difficulty is knowing what domain names to use. |
15 |
|
16 |
You can use any domain name that you want. But there are some pros and |
17 |
cons to various domain names. |
18 |
|
19 |
You can use completely internal domain names that the world has zero |
20 |
idea about, if you want to. Or you can use a (sub)domain of a domain |
21 |
that you can claim some ""ownership of. |
22 |
|
23 |
I think the biggest question about the domain name is if there is any |
24 |
chance that these emails will ever interact with the outside world. Or |
25 |
will you ever add additional services. For example if you have a multi |
26 |
function printer / scanner combo that you want to scan and email to your |
27 |
external email address? |
28 |
|
29 |
It is possible to get private internal domain completely unknown to the |
30 |
world to work with the world. But doing so will cause extra effort. |
31 |
|
32 |
I'd recommend using a (sub)domain of a domain that the world will |
33 |
recognize /if/ that is a /convenient/ option. - This is what I do. My |
34 |
internal things are in sub-domain of one of my globally registered |
35 |
domains. The depth depends on the situation. |
36 |
|
37 |
> I have a .me.uk account, which I could assign to my Internet connection |
38 |
> and then ask my ISP to forward its mail to me, |
39 |
|
40 |
There's a lot in that statement. I'm not familiar with me.uk accounts |
41 |
or what the features thereof are. I have a Gmail account, but I'm |
42 |
fairly confident that I can't get Google to route information to my |
43 |
servers on an SMTP level. |
44 |
|
45 |
Does your internet connection have a static IP? (Dynamic can be made to |
46 |
work, but it will require more work.) |
47 |
|
48 |
Will your ISP allow you to host an email server? Some are quite |
49 |
stringent in their Terms of Service. Others don't care as long as you |
50 |
aren't causing a problem. |
51 |
|
52 |
Forwarding is different and has fewer features than having MX records |
53 |
pointing at your own server. 1) Forwarding usually uses different |
54 |
destination addresses to reach the forward and where the forward points |
55 |
to. 2) Running your own MX means that you have more visibility into |
56 |
the raw message stream and can do as much or as little spam / virus / |
57 |
etc filtering as you want. Something you very likely have no control of |
58 |
for the addresses that is forwarding to you. 3) You are completely |
59 |
dependent on the forwarding party. |
60 |
|
61 |
> or should I only consider the local traffic on the LAN and use its ID? |
62 |
|
63 |
I'm not quite sure what to make of that. |
64 |
|
65 |
In my opinion, the only thing that constitutes "local traffic" is how |
66 |
far the traffic needs to go. There is little reason for your local |
67 |
scanner to send to an external 3rd party that you subsequently pull |
68 |
email down from. The traffic crosses your internet connection twice, |
69 |
likely unnecessarily. |
70 |
|
71 |
What do you mean by "it's ID" and using it as such. |
72 |
|
73 |
Systems in my house / lab have the ability to send email to a local |
74 |
server, which then routes email to the other local systems or out to my |
75 |
main public mail server as necessary. - I could configure things such |
76 |
that my local systems could email each other directly if I wanted, but |
77 |
they all forward to my main account on my main email server which is |
78 |
external. |
79 |
|
80 |
Aside: My main email server used to be inside my house before a cross |
81 |
country move. But, not knowing what sort of connectivity I would have, |
82 |
much less timing issues, I moved my email external prior to the move. |
83 |
I've not yet had good connectivity to pull it back in house yet after |
84 |
the move. |
85 |
|
86 |
> What names do I put in my self-certified SSL? |
87 |
|
88 |
I would recommend that you use the fully qualified domain name of the |
89 |
machine / service that the certificate will be used on. |
90 |
|
91 |
What said FQDN actually is is up to you. |
92 |
|
93 |
Note: I would suggest avoiding self-signed certificates if /reasonably/ |
94 |
possible. Especially when email clients are involved. - Let's Encrypt |
95 |
helps a LOT here. You can get certificates for any host in a |
96 |
(sub)domain that you control and have DNS properly configured for and |
97 |
that the world can resolve. (It is possible to have two different DNS |
98 |
spaces, public and private.) |
99 |
|
100 |
Note: Let's Encrypt, et al, will want you to use properly registered |
101 |
domain names, even for internal things. So things like "example.com" or |
102 |
"nas.lan" won't work as they aren't uniquely identifiable. (You can |
103 |
make them work with self signed certificates.) |
104 |
|
105 |
I put the host's FQDN in both the Common Name (CN) and Subject Alternate |
106 |
Name (SAN) field. Then I add any nicknames / service names / other |
107 |
names I want to work to the SAN field. |
108 |
|
109 |
ProTip: Make sure that the CN value is also included in the SAN. |
110 |
Google Chrome is starting to ignore the CN field, and only looking at |
111 |
the SAN field. |
112 |
|
113 |
> And where should all the SSL files go? /etc/postfix, /etc/dovecot or |
114 |
> /etc/ssl? |
115 |
|
116 |
I don't use postfix or dovecot, so I can't say for sure. |
117 |
|
118 |
But I can say that the certificates live in the following locations on |
119 |
my servers. |
120 |
|
121 |
/home/$USER/.acme.sh/$FQDN - My normal user interfaces with Let's Encrypt. |
122 |
/etc/ssl/certs - This is the main system location. |
123 |
/etc/$SERVICE/ssl - This is the per service location that can't use the |
124 |
system wide location. |
125 |
|
126 |
My Let's Encrypt client (acme.sh) runs out of my home directory. Then I |
127 |
have a script that runs as root to copy the new certificate to the |
128 |
system wide location. The script also copies from the system wide |
129 |
location to specific service locations that can't use the system wide |
130 |
location for permissions / ownership reasons. |
131 |
|
132 |
I prefer to have sym-links living in the per-service location that point |
133 |
to the system wide location when ever possible. Though sometimes |
134 |
services demand that the certificate be owned by the user that they run |
135 |
as, thus necessitating the need for another copy. |
136 |
|
137 |
> I don't intend to run a web server on the same box, |
138 |
|
139 |
I've found that plans like that almost invariably change. Will this box |
140 |
ever run backups? Will they be administered via a (private) web |
141 |
interface? Now it's a (private) web server. ;-) |
142 |
|
143 |
The point is, don't paint yourself into a corner. I'd suggest leaving |
144 |
room for this box being a (private) web server, even if you never end up |
145 |
using it. That way you won't need to re-architect things if (when) you |
146 |
do have reason for it to be a (private) web server. |
147 |
|
148 |
> nor to use the postfix box to send outgoing mail: |
149 |
|
150 |
Same as above, just a different service. |
151 |
|
152 |
Though this one may actually surprise you and try to send outgoing email |
153 |
without you realizing it. - Consider an internal message that is sent |
154 |
from your real email address (there be dragons here) and it has a |
155 |
problem on the local email server such that the message bounces, back to |
156 |
your real email address, thus going out to the world. |
157 |
|
158 |
Or if you live ~1,000 miles away from someone and it becomes convenient |
159 |
to scan something and email the picture to them, through your |
160 |
infrastructure. |
161 |
|
162 |
If you use legitimate hostnames / domain name(s) for things, it has a |
163 |
much higher chance of succeeding. Conversely, it's almost guaranteed |
164 |
that if you use private hostnames / domain name(s) things will fail. |
165 |
Maybe you want that. But I'd put barriers in place if that's what you |
166 |
want and not rely on things failing. |
167 |
|
168 |
> I just want to fetch my ISP's mail via POP3 (they don't offer IMAP) |
169 |
> and serve it to my workstation via IMAP. |
170 |
|
171 |
Okay. That's a very definitive task. One I completely understand. |
172 |
|
173 |
Note: "fetching" email is completely different than "forwarding" email. |
174 |
Despite the fact that email ends up on another server. |
175 |
|
176 |
Do you have a smart phone? Will you want it to access your local |
177 |
server? What about when said smart device is traveling and away from home? |
178 |
|
179 |
Accessing email from a smart device when away from home is a very |
180 |
reasonable thing. It also means that you will likely need some sort of |
181 |
externally recognized name to be able to locate your mail server when |
182 |
out and about. |
183 |
|
184 |
It also likely means that you will want some way to access it more |
185 |
directly when at home. There are more than a few options for this, some |
186 |
of which are nastier (hair pinning) than others (split DNS). |
187 |
|
188 |
> It would be good to start the new year with a working setup. |
189 |
|
190 |
I think it's entirely possible to get this working in the next ~5 days. |
191 |
But I think there may be more subtle things than you might be aware of. |
192 |
I say that based on the context of your email. You are asking very |
193 |
reasonable questions. But they seem fairly new to the process. As |
194 |
such, I think some of the things along the way are going to surprise you. |
195 |
|
196 |
With that in mind, please allow me to make some recommendations: |
197 |
|
198 |
1) Use a (sub)domain that is globally registered. |
199 |
2) Use a Let's Encrypt SSL certificate on the globally recognized FQDN. |
200 |
3) Use split DNS for internal / external resolution. |
201 |
4) I think forwarding might be the slightly lesser of the evils to get |
202 |
email from your ISP to your server. But that requires external |
203 |
accessibility to your email server. - I say this because fetchmail (et |
204 |
al) functionally retrieves email and re-injects it as SMTP to your local |
205 |
server. Thus forwarding at least doesn't switch protocols. |
206 |
|
207 |
Finally, postfix / dovecot / et al, make little difference in my |
208 |
opinion. I think you could easily substitute different daemons in their |
209 |
place. IMHO there is quite a bit more to think about than which of the |
210 |
specific daemons you will run or how to configure them. Rather the |
211 |
specific daemons fall in line after you have the answers to all the |
212 |
other questions and a plan of action. |