The MailServer is a built-in application that can be used to send or receive mail on a Synology NAS device. It can be configured to send mail (using the SMTP protocol) or receive and store mail, which can then be accessed by an external email client (using IMAP or POP3). However, I strongly advise you not to use the MailServer SMTP function. The Internet mail system records the fact that the mail originates from an untrusted server, and it is quite likely that your recipients will flag your mail as spam (Unsolicited Commercial Email).
These notes record how I attempted to configure the IMAP server part of MailServer to use SSL with a private server and CA certificate.
The Synology MailServer application is actually implemented as the open source dovecot program.
According to the official documentation, the location of the dovecot
configuration file can be found by issuing:
doveconf -n | head -n 1
but this doesn't work because the doveconf program is not
in the executable path: it is in /volume1/@appstore/MailServer/bin.
However, on executing:
/volume1/@appstore/MailServer/bin/doveconf -n | head -n 1
we get the result:
# 2.2.15: /var/packages/MailServer/target/etc/dovecot/dovecot.conf
It turns out that /var/packages/MailServer/target is a
symbolic link for /volume1/@appstore/MailServer.
According to this
forum post, changes to /volume1/@appstore/MailServer/etc/dovecot
get overwritten after a DiskStation reboot. When using the symbolic link,
this is the same directory as /var/packages/MailServer/target/etc/dovecot.
The forum post suggests that the program /volume1/@appstore/MailServer/bin/syno_set_config
causes the overwrite, and that this is executed during the boot sequence.
The first thing to do is to confirm that this really happens. I made an
innocuous change to /volume1/@appstore/MailServer/etc/dovecot/dovecot.conf
by changing the text for login_greeting and then rebooting.
The change was preserved across the reboot. I then executed /volume1/@appstore/MailServer/bin/syno_set_config
dovecot and the file remained unchanged. However, I did notice
that the files 10-master.conf and 10-mail.conf
in the conf.d directory has their timestamps changed acroos
these processe, but I couldn't tell whether this was due to the reboot or
the execution of syno_set_config. So I executed syno_set_config
again. This did not change these two files. So I rebooted again. The two
files acquired new timestamps during the boot process. No other files were
changed.
This led me to investigate how the boot sequence actually works.
Before I began this investigation, I didn't know much about booting up a
UNIX system. I did know that boot
is an abbreviation for
bootstrap, which is an allegory for lifting yourself off the ground by
pulling at your own bootstraps: the loops at the backs of boots that used
to be used to help you to pull them on to your feet. In the mainframe
environment that I am more familiar with, bootstrapping was better known
as initial program load
(IPL).
I have now found out that in distributions of Linux, the bootstrap is
immediately followed by an execution of the program /etc/rc.
This is not a binary executable program, but a script written in the
arcane language called shell scripting language
.