# Mail Server Tutorial



## l008com (Oct 28, 2018)

I've set up several mail servers over the years, but I've always used GUI tools to setup and manage them. Now I want do to it "by hand" and I find myself not really even knowing where to begin. And it turns out it's hard topic to google on because you end up catching "how to set up your email client" tutorials no matter what "mail server setup" terms you use. 

So I figured I'd ask here. Anyone know of a good "mail server setup" guide for people familiar with running servers on unix, but haven't messed with a mail server. All I really know is I probably want postfix for smtp and dovecot for imap. I honestly don't even know if that's all I need, or if there are other necessary pieces to the mail server puzzle.


----------



## obsigna (Oct 28, 2018)

A few days ago I finished a comprehensive setup guide for a mail server on FreeBSD using postfix/dovecot + webmail provided by roundcube/apache on my BLog: https://obsigna.com/articles/1539726598.html


----------



## Birdy (Oct 29, 2018)

Some references (from my reading & to-do list) which might be useful:
- FreeBSD 10 Web & Email Server Manual
- How To Run Your Own Mail Server


----------



## DanDare (Oct 30, 2018)

I used this (quite good) tutorial to do it in the past. The tutorials are Debian focused but it was easy to follow an make it working in the FreeBSD box. https://workaround.org/ispmail


----------



## ikbendeman (Oct 30, 2018)

Handbook?


----------



## SirDice (Nov 1, 2018)

I would start by looking at how mail is actually sent around the world, learn the basics first. I.e. how does SMTP work and how it's used to transfer mail from one site to another. Once you have a good idea how it should work you can take a look how the different MTAs have implemented it.

IMAP and POP3 don't have much to do with transferring mail. They're client protocols for reading email that's stored on a server. But before you can do that you have the get the email there first.


----------



## ShelLuser (Nov 1, 2018)

l008com said:


> I've set up several mail servers over the years, but I've always used GUI tools to setup and manage them. Now I want do to it "by hand" and I find myself not really even knowing where to begin.


The manual(s) of whatever mail server ("MTA") you picked would be a good choice in my opinion. See, without telling us what mailservers you used it's somewhat difficult to answer. For all I know your MTA doesn't even support editing of config files (Exchange comes to mind).

Also noteworthy is that depending on your setup and your needs most MTA's don't require that much tweaking to get them to work.

Still, to keep this relevant to FreeBSD I think that  Chapter 28 of the handbook ("Electronic mail") is a good place to start, especially the section about Sendmail. Despite it's seemingly complexity (and general dislike?) Sendmail is actually a pretty straight forward mail server, and it all starts in /etc/mail.  I've been using Postfix for most of my e-mail services but for my local Intranet started relying on Sendmail and so far I'm actually enjoying it.


----------



## chrbr (Nov 1, 2018)

In the good old days it was a good practice to connect by telnet(1) to a server and send a mail. At least I found that very impressive.


----------



## ShelLuser (Nov 1, 2018)

chrbr said:


> In the good old days it was a good practice to connect by telnet(1) to a server and send a mail.


It still is. In fact it's a very good way to test if a mail server is properly configured or it can be a good way to sent an e-mail if you don't have a client handy (or if using /usr/bin/mail proves to be a little too annoying and/or complex).


```
peter@zefiris:/home/peter $ telnet smtp.intranet.lan 25
Trying 10.0.0.5...
Connected to smtp.intranet.lan.
Escape character is '^]'.
220 smtp.catslair.org ESMTP Postfix
helo zefiris
250 smtp.intranet.lan
mail from: pl@intranet.lan
250 2.1.0 Ok
rcpt to: <cut>@hotmail.com
250 2.1.5 Ok
data
354 End data with <CR><LF>.<CR><LF>
Subject: This is a nice demo ;)
Howdy, if you're reading this you got my demo.
.
250 2.0.0 Ok: queued as 966FBE75
quit
221 2.0.0 Bye
Connection closed by foreign host.
```
Now if you'll excuse me, seems I got mail


----------



## xtaz (Nov 2, 2018)

Now try the same telnet test with IMAP and pull your hair out at how insane the IMAP protocol actually is


----------



## obsigna (Nov 2, 2018)

The challenging part is not getting mails in and out. The user management might become complex, unless we serve system and aliased users only. Some of us need to deal with a scalable number of e-mail accounts perhaps on a handful of different domains and want to provide web mail access to our users, allow for disposable e-mail addresses for each user (aka personalized catchall addresses). In addition we want single sign-on for all services, utilizing non plaintext authentication mechanisms which are bullet proof even when passed through transparent TLS proxies.


----------



## olli@ (Nov 2, 2018)

chrbr said:


> In the good old days it was a good practice to connect by telnet(1) to a server and send a mail. At least I found that very impressive.





ShelLuser said:


> It still is. In fact it's a very good way to test if a mail server is properly configured […]



That's true.
However, a _really_ properly configured mail server should also support TLS, and you can't test that with telnet. But you can use openssl(1) to do it: `openssl s_client -starttls smtp -connect your-mta.example.com:25`. It performs the complete STARTTLS and TLS handshake, verifies the certificate and so on. If that is successful, you can then enter (E)SMTP commands, just like you would with telnet.

By the way: It can be very enlightening to run `tcpdump -A port 25` at the same time in another window to watch the actual network traffic. If you use openssl, the last thing you see is the “STARTTLS command”, and after that there is only garbage. No readable commands, no mail headers, no mail body.  If you use telnet, you can clearly see _all_ the data crossing the wires. Show this to someone who doubts that encryption is useful …


----------



## SirDice (Nov 2, 2018)

I often use this: https://mxtoolbox.com/diagnostic.aspx
They run a whole slew of tests on your mailserver to see if it can be abused to relay. But it's obviously only useful for mailservers attached to the internet.


----------



## sko (Nov 2, 2018)

SirDice said:


> I often use this: https://mxtoolbox.com/diagnostic.aspx
> They run a whole slew of tests on your mailserver to see if it can be abused to relay. But it's obviously only useful for mailservers attached to the internet.



Hm, it thinks spamd is an open relay 

I usually use https://ssl-tools.net/mailservers and ssllabs.com for webservers. But using any test tool at all is already a good start. But you shouldn't only test for encrypted channels, also test if a service is _only_ available via SSL/TLS and doesn't accept plaintext connections. Except of course the incoming/outgoing SMTP in case some old/weird/crappy server still doesn't support it but you need to get mails delivered from/to that server... (yes, there are still plenty of them out there )

@Topic:
As others have pointed out: make yourself familiar with HOW mails are sent around the internet (SMTP). Sendmail might be a hard entry point due to its arcane config syntax.
Postfix is nicely modular and can run with a very minimal config; also it is very well documented and due to its very wide usage (IIRC >60% market share) there are tons of good books and "quickstart" guides as well as solutions for very specific problems out there.
For a quick, simple and secure private mail server I'd suggest looking at OpenSMTPd. It's very clean and configuration is extremely easy to understand - if you understand PF rulesets, you will understand the OpenSMTPd config syntax; they're very similar. Also the defaults are very sane and secure - in contrast to other MTAs, e.g. postfix defaulted a long time to "free for all", hence there were tons of open relays in the wild...

I've been running postfix/dovecot based mailservers for >10 years now, so here are some general suggestions that come to mind:

- Pick your MTA (and other parts) depending on your needs, not how much (unused) features it has, and how comfortable you are with its layout/architecture and configuration syntax. E.g. getting your head around how the delivery chain in postfix works is absolutely essential to later add filters/milters and inject/extract mail at the right point in the chain.
Same goes for the MDA and other parts of the mailserver (e.g. database for users if needed; webmail; spam filter etc...). It makes no sense to use the software with most bells & whistles if you don't need them and are overwhelmed with its configuration. In fact it is only dangerous and often frustrating.
Even if its quite a heavyweight, dovecot would also be my suggestion for IMAP - it is very powerful but can run with a very minimal configuration and subset of its features enabled. The default configuration shipped with FreeBSD is very well documented and essentially "everything switched off" - so you have to specifically enable everything first, which often boils down to uncomment and adjust a few lines in the example config.
As an addition to the official documentation I can highly recommend the dovecot book from Peer Heinlein. The author has been running big mailserver installations for >20 years, so the book (as well as his Postfix book, but AFAIK it's only available in german) is full of real-world examples and very helpful suggestions/recommendations.

- Add SSL to _all_ externally available services at an early stage, so you won't have to change stuff around everywhere at the end. Use the staging environment of let's encrypt during testing/setup; there's nothing more annoying than running into the rate-limiting in the middle of configuration/testing...

- Always use the tightest access rules possible; never "give up" and let everything pass just to get something working; this WILL bite you in the (usually very near) future! If your domain ends up on a spamlist its _very_ hard to use it reliably for email for quite a long time and even months later you will occasionally get delivery failures.

- Put every service in its own jail; only run PF and spamd on the host. I've been setting up my last 2 mail servers like this and it might have been one of the best choices I've made in my life during the last 3 years (well, not necessarily because my life choices are usually stupid...). Not only confines this everything in case of a security flaw (be it a bug or misconfiguration), but it also makes maintenance and scaling a walk in the park.

- Don't have A good backup plan - have several of them! Never only rely on snapshots/fullbackups of a VPS by your provider. They usually break exactly the week before you need them. Put the mailstore on ZFS; this makes it easy to send snapshots to a backup storage as well as an off-site pool (e.g. a hot-standby machine) and/or a backup host that dumps them on tape. If the server handles anything remotely connected to business emails, have 2 backup paths more than you think you need - you will need them! (It also makes scaling very easy - just add more storage or attach more/bigger block storage to the VPS...)

- Don't let yorself talk into using whitelists to bypass security checks e.g. for misbehaving/outdated mail clients or stupidly written contact forms on websites. These are a constant source of trouble, tears and screaming and _always_ lead to a major incident one day. Best Answer to such requests: "technically not feasable". Whoever thinks he's technically adept to challenge that statement gets an additional: "due to a customized setup to fulfill our business needs [...] only with major changes which will impact availability [...] less features afterwards [...] need you to sign all these points off by 'my/our/yor boss' to make the requested changes....". I have long resigned to discuss the technical details and security impacts esp. with 'web designers' - just give them the path of highest resistance as the only way to go forward.


----------



## sevendogzero (Jul 3, 2020)

obsigna said:


> A few days ago I finished a comprehensive setup guide for a mail server on FreeBSD using postfix/dovecot + webmail provided by roundcube/apache on my BLog: https://obsigna.com/articles/1539726598.html



Good day,

I have an old email server running on Centos 6. The server is loud and I need some peace and quiet.

I have a new quiet HP DL380 server running Server 2012 and Hyper-v.
I want to create a new email server running under hyper-v as a vm.

I've used FreeBSD on other projects, and want to use your tutorial to setup my new email server.

Would you say the tutorial is up to date?

Best regards,
Bret Stern


----------



## rootbert (Jul 3, 2020)

mail is probably the most complex protocol out there, so administering a mailserver is clearly challenging. I can also throw a link in: http://www.purplehat.org/?page_id=4


----------



## zirias@ (Jul 3, 2020)

olli@ said:


> a _really_ properly configured mail server should also support TLS, and you can't test that with telnet. But you can use openssl(1) to do it:


At least, almost. Trying to issue the RCPT TO command will kill your connection  That's because openssl interprets the capital R as the command to renegotiate....
Typical workaround is to try "rcpt to" (lowercase) instead, most MTAs will accept that.



sevendogzero said:


> Would you say the tutorial is up to date?


Which tutorial? Anyways, a mail server is a prime target for abuse, spammers will continuously try to find and exploit holes and configuration errors, and once your mail server was abused in that way, it depends on how quickly you notice and counteract ... a server that was sending spam for 24 hours is probably useless for a few weeks or even months. Therefore: I don't think following a tutorial is a good way to set up a mail server. You really *must* understand what you are doing.

That said, there are probably "good" tutorials. If you find one, pay attention that it really explains every step in a way that you understand both the "why?" and the "how?". Ideally, you get an idea what your alternatives would be. If this isn't the case, better don't follow that tutorial.


----------



## obsigna (Jul 3, 2020)

sevendogzero said:


> obsigna said:
> 
> 
> > A few days ago I finished a comprehensive setup guide for a mail server on FreeBSD using postfix/dovecot + webmail provided by roundcube/apache on my BLog: https://obsigna.com/articles/1539726598.html
> ...



Yes it is up to date in that everything would work out of the box with the latest versions of the utilized software, although the versions mentioned in the tutorial are outdated. I myself follow the very tutorial when deploying new mail server installations for customers. In addition I added the improvements to the tutorial which I developed in the course of some deployments.

In case you got some questions, either post it here or sendt me a PM or send me an e-mail to the address which is available on my BLog. https://obsigna.com/imprint.html


----------

