Dovecot/Postfix mail sent but not received

Afternoon.

I have just setup Webmin/Virtualmin via the script on a CentOS 7 box. Everything has gone smoothly so far but I have ran into problems with the mail.

So basically, I can send email out (although it’s spammed but I’m looking into SPF records) but no mail is received at all. I setup the email addresses using ‘add user’ under my domain name.

I can retrieve the mail via an external client no problem and I can even send mail out (in roundcube as well). I have checked the mailboxes are updated by deleting a message and checking the ‘deleted’ folders in my external client. So all of this seems good.

Now, I have been looking at the logs (/var/logs/maillog) and can see it being filled with connections, etc.
The wierd thing is, I tested first by sending mail from my Google mail account and I could see attempts of the mail to come in and get passed to the ‘queue’. However, no mail was being put in the ‘milbox’. I checked the queue in ‘Postfix’ module and it is empty.

After awhile, no mail is being received by Google mail, despite how many times I send it. Odd.
So I have tried sending email from the account directly. I can see the below in the logs:

(example.com is my domain)
(example_virtualmin_user is the virtualmin username NOT the sales@example.com username)

Nov 16 11:23:40 vps219251 postfix/smtpd[4817]: connect from localhost[127.0.0.1] Nov 16 11:23:40 vps219251 postfix/smtpd[4817]: CD67C882AF: client=localhost[127.0.0.1] Nov 16 11:23:40 vps219251 postfix/cleanup[4820]: CD67C882AF: message-id= Nov 16 11:23:40 vps219251 postfix/qmgr[23613]: CD67C882AF: from=, size=587, nrcpt=1 (queue active) Nov 16 11:23:40 vps219251 dovecot: imap-login: Login: user=, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, mpid=4824, secured, session= Nov 16 11:23:40 vps219251 postfix/local[4822]: CD67C882AF: to=, orig_to=, relay=local, delay=0.09, delays=0.05/0.03/0/0.01, dsn=2.0.0, status=sent (delivered to command: /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME) Nov 16 11:23:40 vps219251 postfix/qmgr[23613]: CD67C882AF: removed Nov 16 11:23:40 vps219251 postfix/smtpd[4817]: disconnect from localhost[127.0.0.1]

I am not really sure where to start diagnosing and hope someone could help me?
I have searched online and within the forums for a few days but I am at a dead end here!

ANY help is appreciated!

After further investigation, I can see what’s happening.

Basically, DoveCot using the folders generated by Virtualmin in ‘/home/example_virtualmin_user/homes/sales/Maildir’ (which you can be set when adding a new user under ‘Email Settings’).
RoundCube and my external mail client (via IMAP4) are also obtaining the mail from this directory, via Dovecot I presume.

I logged into Webmin and found the ‘sales’ user in Virtualmin under my domain. i then clicked ‘Login to Usermin’ for that particular user and I can see all the mail that has been sent to the address. Of course this doesn’t contain any email from the folders Dovecot is using.

So it looks like when the emails were ‘queued’ and passed to procmail (it looks like); it is storing inbox mails in ‘/var/spool/mail/sales.example_virtualmin_user’.
I can actually see text files of the inbox stored in that folder.

The weird thing is the sent emails are actually stored in ‘/home/example_virtualmin_user/homes/sales/mail/sentmail’.

I know you can’t copy from the ‘spool’ (which I believe is mbox format) to ‘Maildir’ but I don’t need to recover any emails from the inbox since my mail has been down anyway.
So my predicament is how to change the mail delivered in to point to my ‘Maildir’ folder?

Under ‘Dovecot IMAP/POP3 Server’ > Mail Files, I tried to save the config and the error ‘Failed to save mail file options : Missing or invalid UIDL format’ was given.

It looks like that has not been ‘UIDL format’. I set this to ‘courier 2’ after a brief Google search. I suggest you look up, which is best for you by doing a lookup. I would usually do a thorough analysis but I needed mail up quickly.

Changed ‘Mail file location’ to ‘Inbox and folders in ~/Maildir’. Although it did detect the mail correctly. Hence my external client was downloading the correct mail box (and roundcube).

/etc/postfix/main.cf file changes:
# DELIVERY TO MAILBOX

The home_mailbox parameter specifies the optional pathname of a

mailbox file relative to a user’s home directory. The default

mailbox file is /var/spool/mail/user or /var/mail/user. Specify

“Maildir/” for qmail-style delivery (the / is required).

#home_mailbox = Mailbox
home_mailbox = Maildir/

/etc/usermin/mailbox/config
server_attach=1
no_crlf=0
perpage=20
mail_system=0
shortindex=0
folder_types=local,ext,pop3,imap
from_map=/etc/mail/virtusertable
mail_file=
noindex_hostname=0
mail_dir=
spam_report=
show_to=0
spam_always=0
wrap_width=80
smtp_ssl=0
from_format=1
pop_locks=1
folder_virts=virt,comp
mail_style=0
sendmail_path=/usr/lib/sendmail
html_base64=0
top_buttons=1
nologout=0
no_mailer=0
edit_from=1
mail_dir_qmail=Maildir
no_orig_ip=1

I’m stuck! Still no emails coming into the correct Maildir.

Howdy,

Hmm, that’s unusual! It shouldn’t be storing email there.

Can you paste in the contents of your /etc/procmailrc file?

It’s possible that there is a problem with that which is causing the issue you’re describing.

-Eric

Hello Eric,

That file doesn’t actually exist. The procmail binary exists in ‘/usr/bin’.

Am I missing something? Can’t find anything obvious that would relate to procmail neither.

Thanks,
Changos

Howdy,

Ah, that’s a problem then! That file should exist, with the following contents:

LOGFILE=/var/log/procmail.log TRAP=/etc/webmin/virtual-server/procmail-logger.pl :0wi VIRTUALMIN=|/etc/webmin/virtual-server/lookup-domain.pl $LOGNAME EXITCODE=$? :0 * ?/bin/test "$EXITCODE" = "73" /dev/null EXITCODE=0 :0 * ?/bin/test "$VIRTUALMIN" != "" { INCLUDERC=/etc/webmin/virtual-server/procmail/$VIRTUALMIN } ORGMAIL=$HOME/Maildir/ DEFAULT=$HOME/Maildir/ DROPPRIVS=yes :0 $DEFAULT

Eric… you are the man! That indeed worked.

I will try to look into why that file seems to be missing from mu build and revert any files I have changes 00!

Thanks again!

changos

A fresh install on an new box made everything work perfectly. I just needed to let the install run it’s course. Re-running a broken install (via script) does not work.

Thanks for your help.