A user reported that she was unable to check her email today; she had also reported the problem yesterday. When I checked Sendmail, which would handle her outgoing email, by using Telnet to connect to the well-known port for Simple Mail Transfer Protocol (SMTP) on the server with telnet mail.example.com 25, I saw the Sendmail banner as expected, so I presumed her problem was likely with Dovecot, the software on the system that would allow her to receive her incoming email. I tried connecting to port 110, the well-known port for Post Office Protocol version 3 (POP3) connections using Telnet. When I saw the "Connected to" and "Escape character is" messages, I entered the POP3 user command followed by the user's name, but I would shortly thereafter see a "Connection closed" message every time I tried the connection with Telnet. I never saw the "Dovecot ready" prompt appear.

# telnet 127.0.0.1 110
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
user nell
Connection closed by foreign host.
You have new mail in /var/spool/mail/root
#

[ More Info ]

[/network/email/dovecot] permanent link

A user reported that she wasn't receiving any email. When I logged into the mail servers, which runs Dovecot for POP3/POP3S and used Telnet to connect to port 110, the well-known port for POP3, I didn't get any response after I entered the user command, so I exited to the telnet prompt with Ctrl-].

$ telnet 127.0.0.1 110
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
user nell
^]
telnet> quit
Connection closed.
$

I logged into the root account and checked today's and yesterday's maillog files for any references to Dovecot or POP3 issues, but saw none.

# grep -i dovecot /var/log/maillog
# grep -i dovecot /var/log/maillog.1
# grep -i pop3 /var/log/maillog.1
# grep -i pop3 /var/log/maillog
#

[ More Info ]

[/network/email/dovecot] permanent link

Microsoft Telnet> open mail.example.com 110
Connecting To mail.example.com...

So I logged into the mail server, which is a CentOS 7 Linux server running Sendmail and Dovecot, and tried connecting to the localhost address, 127.0.0.1, but Dovecot never responded with a banner, nor did I receive any response when I issued a user command to provide login credentials. I had to hit Ctrl-] to exit from the Telnet program, since I wasn't getting any response from Dovecot.

# telnet 127.0.0.1 110
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
user lila
^]
telnet> quit
Connection closed.
#

[ More Info ]

[/network/email/dovecot] permanent link

$ telnet 127.0.0.1 25
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
220 moonpoint.com ESMTP Sendmail 8.14.7/8.14.7; Sat, 6 Aug 2016 09:26:06 -0400
quit
221 2.0.0 moonpoint.com closing connection
Connection closed by foreign host.
$

Since the Sendmail SMTP service seemed to be functioning properly, I next checked the Dovecot POP3/POP3S software on the system. I entered the commands an email client would submit to authenticate with the server on the POP3 port, port 110, i.e., pass followed by the user's login id then pass and the password for the user's account. I received an immediate response to the user command, but when I entered the pass command followed by the password and hit Enter I didn't see any response even after waiting much longer than I would expect to have to wait for a response. So I hit Ctrl-], i.e., the Ctrl and ] keys to return to the Telnet prompt and then exited from the telnet program.

[ More Info ]

[/network/email/dovecot] permanent link

# telnet 127.0.0.1 110
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
user nell
Connection closed by foreign host.
#

So I then checked Dovecot's log file. I saw many entries similar to the following ones in that file:

# grep dovecot /var/log/maillog | tail -5
Jul  4 09:15:44 moonpoint dovecot: master: Warning: service(pop3-login): process
_limit (100) reached, client connections are being dropped
Jul  4 09:18:55 moonpoint dovecot: master: Warning: service(pop3-login): process
_limit (100) reached, client connections are being dropped
Jul  4 09:19:57 moonpoint dovecot: master: Warning: service(pop3-login): process
_limit (100) reached, client connections are being dropped
Jul  4 09:21:01 moonpoint dovecot: master: Warning: service(pop3-login): process
_limit (100) reached, client connections are being dropped
Jul  4 09:26:13 moonpoint dovecot: master: Warning: service(pop3-login): process
_limit (100) reached, client connections are being dropped
#

[ More Info ]

[/network/email/dovecot] permanent link

# grep "Permission denied" /var/log/maillog.1 | tail -n 3
Jun 17 18:56:08 moonpoint dovecot: pop3(nell): Error: open(/home/nell/mail/.imap
/INBOX/dovecot.index.log) failed: Permission denied (euid=503(nell) egid=1002(ne
ll) missing +x perm: /home/nell/mail/.imap/INBOX, dir owned by 0:0 mode=0700)
Jun 17 19:26:44 moonpoint dovecot: pop3(nell): Error: open(/home/nell/mail/.imap
/INBOX/dovecot.index.log) failed: Permission denied (euid=503(nell) egid=1002(ne
ll) missing +x perm: /home/nell/mail/.imap/INBOX, dir owned by 0:0 mode=0700)
Jun 17 19:57:29 moonpoint dovecot: pop3(nell): Error: open(/home/nell/mail/.imap
/INBOX/dovecot.index.log) failed: Permission denied (euid=503(nell) egid=1002(ne
ll) missing +x perm: /home/nell/mail/.imap/INBOX, dir owned by 0:0 mode=0700)
#

Checking the permissions and ownership on the referenced mail/.imap/INBOX file for her account and comparing it to other accounts, I saw that root was listed as the owner and the group for the file under her home directory, but for other users the same file under their home directory was owned by the user's account and the group matched the user name for the user.

[ More Info ]

[/network/email/dovecot] permanent link

# Log all the mail messages in one place.
mail.*                                                  -/var/log/maillog

You can find the location of dovecot logs using the doveadm log find command.

# doveadm log find
Looking for log files from /var/log
Debug: /var/log/maillog
Info: /var/log/maillog
Warning: /var/log/maillog
Error: /var/log/maillog
Fatal: /var/log/maillog
#

Since the user had not connected from his PC to check his email account for several days, I looked in a maillog file from several days ago to determine the IP address from which he connected then and saw the following.

# grep benny /var/log/maillog.4 | grep pop3 | grep "rip="
Jun 13 02:57:23 moonpoint dovecot: pop3-login: Login: user=<benny>, method=PLAIN
, rip=172.25.2.7, lip=192.168.0.5, mpid=21212, secured, session=<RDFhZiM1NgBILQJI>
Jun 13 04:59:10 moonpoint dovecot: pop3-login: Login: user=<benny>, method=PLAIN
, rip=172.25.2.7, lip=192.168.0.5, mpid=32662, secured, session=<REgGGiU1CgBILQJI>
Jun 13 17:53:04 moonpoint dovecot: pop3-login: Login: user=<benny>, method=PLAIN
, rip=172.25.2.7, lip=192.168.0.5, mpid=30622, secured, session=<6ka06S81BwBILQJI>
Jun 13 18:23:14 moonpoint dovecot: pop3-login: Login: user=<benny>, method=PLAIN
, rip=172.25.2.7, lip=192.168.0.5, mpid=1243, secured, session=<Gl+PVTA1LABILQJI>
Jun 13 18:53:23 moonpoint dovecot: pop3-login: Login: user=>benny>, method=PLAIN
, rip=172.25.2.7, lip=192.168.0.5, mpid=3769, secured, session=<hqpuwTA1TABILQJI>
#

[ More Info ]

[/network/email/dovecot] permanent link

She told me the password she was using, so I established a telnet connection to port 110, the Post Office Protocol version 3 (POP3) port from another system using PuTTY and entered her userid and password. The email server, which uses Dovecot to provide IMAP and POP3 service, acknowledged that was the correct password.

+OK [XCLIENT] Dovecot ready.
user nell
-ERR Unknown command.
user nell
+OK
pass Rugs1234
+OK Logged in.
stat
+OK 52 483564
quit

If you connect to port 110, the pop3 port, you can enter a user command to provide the userid (I don't know why dovecot always responded to the first submission of that command with -ERR Unknown command, when I used PuTTY to connect, but then accepted it on the second submission) and then a pass command followed by the password. You can then issue a stat or uidl command to check on the number of messages in the inbox and their size. For the stat command, the first number in the response is the number of messages and the second number is their size in bytes. The uidl command shows the unique message id for each message. You can end the session with the quit command.

Since the password seemed to be correct, I had her try again to download her email while I observed what was happening with tcpdump on the mail server by issing the command tcpdump -i enp1s4 'port 110' -A from the root account. I used i enp1s4, because enp1s4 is the network interface on that particular system. The -A at the end instructs tcpdump to print each packet (minus its link level header) in ASCII.

What I observed was her system sending the USER command and her userid. But then Outlook on her system would send the AUTH command and the server would reply ".-ERR [AUTH] Plaintext authentication disallowed on non-secure (SSL/TLS) connections"

10:29:34.219018 IP 10-45-1-012-dhcp.gsv.md.example.com.50990 > 

localhost.localdomain.pop3: Flags [P.], seq 8:19, ack 29, win 16418, length 11
E..3!.@.{...H-.H.......n.....(."P.@"....USER nell

10:29:34.219182 IP localhost.localdomain.pop3 > 10-45-1-012- 
dhcp.gsv.md.example.com.50990: Flags [P.], seq 29:115, ack 19, win 115, length 86
...-ERR [AUTH] Plaintext authentication disallowed on non-secure (SSL/TLS) connections.

The AUTH command indicates an authentication mechanism to the server as noted in Request for Comments (RFC) 1734 POP3 AUTHentication command. RFCs are the mechanism for defining Internet standards.

When I observed what was happening with the same tcpdump command when I connected to the server from another system on its LAN by a telnet connection to port 110, I saw the following:

# tcpdump -i enp1s4 'port 110' -A

10:27:30.475105 IP 192.168.0.6.63448 > localhost.localdomain.pop3: Flags [P.], seq 67:76, 

ack 120, win 256, length 9
E..1.1@...r;...........n......Q.P.......user nell
10:27:30.475211 IP 192.168.0.6.63448 > localhost.localdomain.pop3: Flags [P.], seq 76:78, 

ack 120, win 256, length 2
E..*.2@...rA...........n......Q.P...n...
....
10:27:30.475264 IP localhost.localdomain.pop3 > 192.168.0.6.63448: Flags [.], ack 78, win 

115, length 0
E..(g.@.@.N..........n....Q.....P..s.u..
10:27:30.475319 IP localhost.localdomain.pop3 > 192.168.0.6.63448: Flags [P.], seq 

120:125, ack 78, win 115, length 5
E..-g.@.@.N..........n....Q.....P..s.z..+OK

10:27:30.534264 IP 192.168.0.6.63448 > localhost.localdomain.pop3: Flags [.], ack 125, win 

256, length 0
E..(.6@...r?...........n......Q.P...{.........
10:27:36.602821 IP 192.168.0.6.63448 > localhost.localdomain.pop3: Flags [P.], seq 78:91, 

ack 125, win 256, length 13
E..5.E@...r#...........n......Q.P.../...pass Rugs1234
10:27:36.602938 IP 192.168.0.6.63448 > localhost.localdomain.pop3: Flags [P.], seq 91:93, 

ack 125, win 256, length 2
E..*.F@...r-...........n......Q.P...n...
....
10:27:36.603007 IP localhost.localdomain.pop3 > 192.168.0.6.63448: Flags [.], ack 93, win 

115, length 0
E..(g.@.@.N..........n....Q.....P..s.u..
10:27:36.735972 IP localhost.localdomain.pop3 > 192.168.0.6.63448: Flags [P.], seq 

125:141, ack 93, win 115, length 16
E..8g.@.@.N..........n....Q.....P..s....+OK Logged in.

I.e., the server was accepting a plaintext password, though it wasn't accepting one from her system. When I entered the AUTH command from the telnet session to port 110, it was accepted without that error message.

+OK [XCLIENT] Dovecot ready.
user nell
-ERR Unknown command.
user nell
+OK
AUTH
+OK
PLAIN
.
pass Rugs1234
+OK Logged in.

I then remembered that she had told me her ISP replaced her network equipment recently. She has an IP that remains constant unless the router is replaced at her end in which case the new device has a different media access control (MAC) address and will be assigned a different IP address.

I put the new IP address in the /etc/mail/access file, so that sendmail would allow relaying from that IP address without any authentication. I.e., I added a line with her IP address followed by RELAY.

10.45.1.12                              RELAY

I then ran the makemap hash command to generate a new /etc/mail/access.db file.

# makemap hash /etc/mail/access </etc/mail/access

But that only allowed her to send email via sendmail without authentication. I also had to update dovecot's configuration file at /etc/dovecot/dovecot.conf and change the IP address there for her system so that she could use plaintext authentication, i.e., an unencrypted password (I need to go to her location and change the Outlook configuration there to use other than plaintext authentication). I didn't recall that change was needed until finding a note I had made previously regarding dovecot's logon_trusted_networks setting.

The relevant section of the dovecot.conf file is shown below for cases where plaintext authentication is being allowed.

# Space separated list of trusted network ranges. Connections from these
# IPs are allowed to override their IP addresses and ports (for logging and
# for authentication checks). disable_plaintext_auth is also ignored for
# these networks. Typically you'd specify your IMAP proxy servers here.
login_trusted_networks = 192.168.0.0/24 192.168.7.0/24 10.45.1.12

In this case dovecot was configured to allow plaintext logins from two 192.68 subnets and her specific IP address. But since her IP address had changed to a new one, dovecot was no longer permitting plaintext authentication from her system. After changing the login_trusted_networks line to match her particular IP address, I restarted dovecot.

# service dovecot restart
Redirecting to /bin/systemctl restart  dovecot.service

When I had her try again, she was then able to download her email.

Note: IP addresses, userid, and password are, of course, not the actual ones used.

[/network/email/dovecot] permanent link

Task 'jasmith@example.com - Receiving' reported error (0x800CCC92) : 'Your e-mail server rejected your login. Verify your user name and password for this account in Account Settings. The server responded: -ERR [AUTH] Plaintext authentication disallowed on non-secure (SSL/TLS) connections.'

At first I thought the tech who upgraded the system had made some change to Outlook on the system, but I eventually realized that the email server using dovecot for POP3 email access was denying access, because the system had a new IP address. The user was using POP3, port 110, for downloading email and I had previously added the old IP address to the login_trusted_networks line in /etc/dovecot/dovecot.conf file on the email server. By adding an IP address or IP address range to that line, you can configure dovecot to allow users to login using an unencrypted userid and password, i.e., plaintext authentication, from the specified IP address or range of addresses. The relevant section in dovecot.conf is shown below:

# Space separated list of trusted network ranges. Connections from these
# IPs are allowed to override their IP addresses and ports (for logging and
# for authentication checks). disable_plaintext_auth is also ignored for
# these networks. Typically you'd specify your IMAP proxy servers here.
login_trusted_networks = 192.168.0.0/24 192.168.1.0/24 172.45.55.82

In the case above, the server will accept plaintext passwords from any system in the 192.168.0.0/24 address range, i.e., 192.168.0.0 to 192.168.0.255, the 192.168.1.0/24 address range, and from the specific IP address 172.45.55.82, which was the user's IP address. After updating her IP address in the file, I restarted dovecot with service dovecot restart.

The system uses sendmail for sending email and I also had to update /etc/mail/access to include her IP address, since the change to the dovecot configuration file allowed her to download her email, but sendmail would still not except any email sent from her computer, since relaying was permitted from her old email address, but not her new one. I added her IP address and a comment line to the /etc/mail/access file.

# J. A. Smith
172.45.55.82                           RELAY

I then used makemap hash to generate an updated /etc/mail/access.db file.

# makemap hash /etc/mail/access </etc/mail/access

She was then able to send as well as receive email; I didn't need to restart sendmail.

[/network/email/dovecot] permanent link

# chkconfig --list dovecot
dovecot         0:off   1:off   2:off   3:off   4:off   5:off   6:off

I turned it on so that it would be operational after the next reboot with chkconfig dovecot on.

# chkconfig dovecot on
[root@frostdragon ~]# chkconfig --list dovecot
dovecot         0:off   1:off   2:on    3:on    4:on    5:on    6:off

I then started the service with service dovecot start.

# service dovecot start
Starting Dovecot Imap:                                     [  OK  ]

I could then see that the system was listening on the imap, imaps, pop3, and pop3s ports.

# netstat -a | grep imap
tcp        0      0 *:imaps                     *:*                         LISTEN
tcp        0      0 *:imap                      *:*                         LISTEN
[root@frostdragon archive]# netstat -a | grep pop3
tcp        0      0 *:pop3s                     *:*                         LISTEN
tcp        0      0 *:pop3                      *:*                         LISTEN

Dovecot can be configured to handle mailboxes for system users, i.e. for accounts on the system or for virtual users. Since the majority of people who would be using the server for email would have no need to log into the system and since I wanted to be able to have john@example.com and john@anotherexample.com, I chose to configure Dovecot for virtual users.

The Dovecot Wiki has this to say about usernames and domains:

Usernames and domains

Dovecot doesn't care much about domains in usernames. IMAP and POP3 protocols currently have no concept of "domain", so the username is just something that shows up in your logs and maybe in some configuration, but they have no direct functionality.

So although Dovecot makes it easier to handle "user@domain" style usernames (eg. %n and %d variables), nothing breaks if you use for example "domain%user" style usernames instead. However some authentication mechanisms do have an explicit support for realms (pretty much the same as domains). If those mechanisms are used, the username is changed to be "user@realm".

And of course there's no need to have domains at all in the usernames.

I followed the instructions in Simple Virtual User Installation. I didn't need to create a dovecot user, since one already existed in /etc/passwd. I did need to create a vmail user account and group, which is used to access the mail for all users.

# grep dovecot /etc/passwd
dovecot:x:97:97:dovecot:/usr/libexec/dovecot:/sbin/nologin
# useradd -u 103 -c Dovecot vmail

The above useradd command created the vmail user and group and automatically created a /home/vmail directory owned by vmail:vmail, under which the email for all users is stored. [Note: you may want to use a UID greater than 500 rather than 103 as in the example above to avoid the problem noted below where the dovecot configuration file by default only permits a UID greater than 500]

I created /var/log/dovecot.log and /var/log/dovecot-info.log and changed the owner and group for those files to vmail.

# touch /var/log/dovecot.log /var/log/dovecot-info.log
# chown vmail /var/log/dove*; chgrp vmail /var/log/dove*;

I then edited /etc/dovecot.conf and changed the settings for the log files.

Original

# Use this logfile instead of syslog(). /dev/stderr can be used if you want to
# use stderr for logging (ONLY /dev/stderr - otherwise it is closed).
#log_path =

# For informational messages, use this logfile instead of the default
#info_log_path =

Modified

# Use this logfile instead of syslog(). /dev/stderr can be used if you want to
# use stderr for logging (ONLY /dev/stderr - otherwise it is closed).
log_path =  /var/log/dovecot.log

# For informational messages, use this logfile 
info_log_path = /var/log/dovecot-info.log

The default line in /etc/dovecot.conf for plaintext authentication is as follows:

#disable_plaintext_auth = no

Since disable_plaintext_auth has a default value of "no", I didn't have to uncomment that line.

I created a directory for the dovecot password file with mkdir /etc/dovecot and then set up a password file in /etc/dovecot/passwd. I changed the protection on the file with chmod 600 /etc/dovecot/passwd, so that only root would have access, since I don't want others with accounts on the system to be able to read the contents of the file. I created entries in the passwd file with entries like the following:

jdoe@example.com:{PLAIN}HerPassword

I then modified the checkpassword section of /etc/dovecot.conf

Original

  # checkpassword executable authentication
  # NOTE: You will probably want to use "userdb prefetch" with this.
  # http://wiki.dovecot.org/PasswordDatabase/CheckPassword
  #passdb checkpassword {
    # Path for checkpassword binary
    #args =
  #}

Modified

  # passwd-like file with specified location
  # http://wiki.dovecot.org/AuthDatabase/PasswdFile
  passdb passwd-file {
    # Path for passwd-file
    args = /etc/dovecot/passwd
  }

I then restarted dovecot with service dovecot restart. I then tested dovecot by using telnet to connect to port 110, the pop3 port, on the system. I could connect to port 110, but didn't get any response to the user and pass commands. I looked in /var/log/dovecot and saw the following errors recorded:

dovecot: May 04 13:35:26 Error: Temporary failure in creating login processes, slowing down for now
dovecot: May 04 13:35:26 Error: imap-login: imap-login: error while loading shared libraries: libsepol.so.1: failed to map segment from shared object: Cannot allocate memory
dovecot: May 04 13:35:26 Error: imap-login: imap-login: error while loading shared libraries: libsepol.so.1: failed to map segment from shared object: Cannot allocate memory
dovecot: May 04 13:35:26 Error: pop3-login: pop3-login: error while loading shared libraries: libsepol.so.1: failed to map segment from shared object: Cannot allocate memory
dovecot: May 04 13:35:26 Error: pop3-login: pop3-login: error while loading shared libraries: libsepol.so.1: failed to map segment from shared object: Cannot allocate memory
dovecot: May 04 13:35:26 Error: pop3-login: pop3-login: error while loading shared libraries: libsepol.so.1: failed to map segment from shared object: Cannot allocate memory
dovecot: May 04 13:35:26 Error: child 30454 (login) returned error 127
dovecot: May 04 13:35:26 Error: child 30455 (login) returned error 127

At Redhat Dovecot error while loading shared libraries: libsepol.so.1: failed to map segment from shared object: Cannot allocate memory, I found a suggestion to edit /etc/dovecot.conf and modify the login_processes_size line so that it is login_process_size = 64. The writer states on that webpage that "This error is not related to shared libraries. You need to set maximum process size in megabytes. If you don't use login_process_per_connection you might need to grow this."

When I looked in /etc/dovecot.conf, I saw the following line:

#login_process_size = 32

I removed the "#" and changed the line to login_process_size = 64 . I then restarted dovecot with service dovecot restart. I no longer saw the error messages in the /var/log/dovecot.log file.

When I again checked email for accounts by using telnet 127.0.0.1 110, I was able to check an account, jsmith, listed in /etc/passwd, but not the jdoe@example.com account listed in the /etc/dovecot/passwd file I created.

# telnet 127.0.0.1 110
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
+OK Dovecot ready.
user jdoe@example.com
+OK
pass HerPassword
-ERR [IN-USE] Internal login failure. Refer to server log for more information.
Connection closed by foreign host.
[root@frostdragon log]# telnet 127.0.0.1 110
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
+OK Dovecot ready.
user jsmith
+OK
pass HisPassword
+OK Logged in.
stat
+OK 0 0
quit
+OK Logging out.
Connection closed by foreign host.

When I looked in /etc/dovecot.conf, I saw dovecot: May 04 14:03:20 Error: auth(default): userdb(jdoe@example.com,::ffff:127.0.0.1): user not found from userdb.

I then realized I also needed to modify the "userdb static" section of /etc/dovecot.conf. I made the following changes:

Original

  # static settings generated from template
  # http://wiki.dovecot.org/UserDatabase/Static
  #userdb static {
    # Template for the fields. Can return anything a userdb could normally
    # return. For example:
    #
    #  args = uid=500 gid=500 home=/var/mail/%u
    #
    #args =
  #}

Modified

  # static settings generated from template
  # http://wiki.dovecot.org/UserDatabase/Static
  userdb static {
    # Template for the fields. Can return anything a userdb could normally
    # return. For example:
    #
    #  args = uid=500 gid=500 home=/var/mail/%u
    #
    args = uid=vmail gid=vmail home=/home/vmail/%u
  }

I then restarted dovecot with service dovecot restart. But I still couldn't check email for the virtual user account jdoe@example.com. In the /var/log/dovecot.log file, I saw dovecot: May 04 14:34:19 Error: Logins with UID 103 (user jdoe@example.com) not permitted (see first_valid_uid in config file)

When I checkd the /etc/dovecot.conf, I found the following:

# Valid UID range for users, defaults to 500 and above. This is mostly
# to make sure that users can't log in as daemons or other system users.
# Note that denying root logins is hardcoded to dovecot binary and can't
# be done even if first_valid_uid is set to 0.
#first_valid_uid = 500
#last_valid_uid = 0

I then realized, since I created the vmail account with a UID of 103, that the dovecot configuration file was preventing a login for it, because it was less than 500. I could have changed the first_valid_uid value in dovecot.conf, but I decided to delete the vmail account and its associated home directory and then recreate it with a UID greater than 500. I then restarted dovecot

# userdel vmail
# rm -rf /home/vmail
# useradd -u 502 -c "Dovecot Virtual Users" vmail 
# service dovecot restart

I was then able to check email for both user accounts on the system and virtual user accounts. I saw that dovecot created a /home/vmail/jdoe@example.com directory under /home/vmail.

At this point, though I could login to the POP3 port, port 110, and get dovecot to accept the userid and password for a virtual user, sendmail would return a "user unknow" message, if I tried to send email to a virtual user, because sendmail knew nothing about the dovecot virtual users. So using the instructions in Dovecot LDA with Sendmail as a starting point, I took the steps below.

I created the file /usr/share/sendmail-cf/mailer/dovecot.m4 and put the lines below in it:

######################*****##############
###   DOVECOT Mailer specification                              ###
##################*****##################
Mdovecot,   P=/usr/local/libexec/dovecot/deliver, F=DFMPhnu9,
                 S=EnvFromSMTP/HdrFromSMTP, R=EnvToSMTP/HdrFromSMTP,
                 T=DNS/RFC822/X-Unix,
                 A=deliver -d $u

In /etc/mail/sendmail.mc, I had the following two lines:

MAILER(smtp)dnl
MAILER(procmail)dnl

I added MAILER(dovecot)dnl after those two lines. I then regenerated the sendmail.cf file using the m4 command.

# m4 /etc/mail/sendmail.mc > /etc/mailsendmail.cf

Unfortunately, that did not resolve the issue with virtual users. I still haven't been able to get that working.

References:

1. Chapter 23. Email
   CentOS
2. Basic Configuration
   Dovecot Wiki
3. Virtual Users
   Dovecot Wiki
4. Simple Virtual User Installation
   Dovecot Wiki
5. Passwd-file
   Dovecot Wiki
6. Redhat Dovecot error while loading shared libraries: libsepol.so.1: failed to map segment from shared object: Cannot allocate memory
   nixCraft Insight Into Linux Admin Work
7. Dovecot LDA with Sendmail
   Dovecot Wiki

[/network/email/dovecot] permanent link