Can't receive mails


I wouldn’t think that an ISP issue would prevent mail being sent internally on the box, right?


Te results of the command are the following.

marcosms@boxcorreo:~$ postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
bounce_queue_lifetime = 1d
compatibility_level = 2
delay_warning_time = 3h
inet_interfaces = all
inet_protocols = all
local_recipient_maps = $virtual_mailbox_maps
mailbox_size_limit = 0
maximal_queue_lifetime = 2d
message_size_limit = 134217728
milter_default_action = accept
mydestination = localhost
myhostname =
mynetworks = [::ffff:]/104 [::1]/128
myorigin = /etc/mailname
non_smtpd_milters = $smtpd_milters
readme_directory = no
recipient_delimiter = +
relayhost =
smtp_bind_address =
smtp_bind_address6 =
smtp_dns_support_level = dnssec
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtp_tls_ciphers = medium
smtp_tls_exclude_ciphers = aNULL,RC4
smtp_tls_loglevel = 2
smtp_tls_mandatory_protocols = !SSLv2,!SSLv3
smtp_tls_protocols = !SSLv2,!SSLv3
smtp_tls_security_level = dane
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP Hi, I'm a Mail-in-a-Box (Ubuntu/Postfix; see
smtpd_milters = inet: inet:
smtpd_recipient_restrictions = permit_sasl_authenticated,permit_mynetworks,reject_rbl_client,reject_unlisted_recipient,check_policy_service inet:
smtpd_relay_restrictions = permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination
smtpd_sasl_auth_enable = no
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot
smtpd_sender_login_maps = sqlite:/etc/postfix/
smtpd_sender_restrictions = reject_non_fqdn_sender,reject_unknown_sender_domain,reject_authenticated_sender_login_mismatch,reject_rhsbl_sender
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /home/user-data/ssl/ssl_certificate.pem
smtpd_tls_ciphers = medium
smtpd_tls_dh1024_param_file = /home/user-data/ssl/dh2048.pem
smtpd_tls_exclude_ciphers = aNULL,RC4
smtpd_tls_key_file = /home/user-data/ssl/ssl_private_key.pem
smtpd_tls_protocols = !SSLv2,!SSLv3
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
virtual_alias_maps = sqlite:/etc/postfix/
virtual_mailbox_domains = sqlite:/etc/postfix/
virtual_mailbox_maps = sqlite:/etc/postfix/
virtual_transport = lmtp:[]:10025

I tryed to open port 10025 with the commands that you post, but the problem continues.

A person who wants to send me a mail, has received the following mail

550 5.1.1 <>: Recipient address rejected: User unknown in virtual mailbox table


No MX records found for .

You were NOT having a problem with the install under Ubuntu 14? Was the hostname the same at that time, or have you changed hostnames?


Under ubuntu 14 we were using this subdomain as long as… about 4 years ago. We can receive mails until we change to ubuntu 18.04. This night we receive a lot of mails, but during the day we not receive anything. The hostname is the same. We are not interested in send mails with this domain (but allways we could send mails). We need to receive (now we can send mail but cannot receive)


Do you still have the Ubuntu 14 VM? Spin it up and do the same
postconf -n



I think this graph may be the key. ¿Are the incoming mails in a queue or something? (notice that we don’t send mails)

I will see the old machine in a while.


Look and see what is in the mail queue:


It looks like mail IS being received and being queued. I successfully sent a mail to at 17:10 UTC.

I really do not have an idea why you are receiving mail and it is being queued rather than being delivered.


postmaster account is an alias of my account and i don’t receive any mail. The queue (mailq) is full of mails. I tried to use sendmail -q but the mails didn’t disappear of the queue (it says that there are 311 Requests). We have about 120 accounts. I was trying to use sendmail -q and it seems that there are same number of requests.

All lines of mailq says this:

(delivery temporarily suspended: lost connection with[] while sending end of data – message may be sent more than once)


Eh, i’m using ubuntu 18.04.2, not 18.04. It’s the version that ubuntu deploys. I hope that it don’t be the reason of this troubles.


A college send me this mail that the system returned.

550 5.1.1 <>: Recipient address rejected: User unknown in virtual mailbox table



It shouldn’t be … 18.04.2 was released last week. One other person had an issue with it, but I do believe it was unrelated to this.

Is the email address correct??? Possibly they entered a typo and sent it to the wrong address.


The address is correct.

Now in mailq i see this

39D31144177E*    4711 Tue Feb 19 21:14:31

I sended a mail from one account in other server to my account. I can see the mail in mailq, but the mail don’t enter in my mailbox. There is no error in mailq with this mail. It seems that the queue is not proccessing the mails (or it’s doing it very slowly)


You referenced some sendmail commands in an earlier post … MiaB uses Postfix, not Sendmail…

Are there any interesting entries in the syslog file?


In syslog i have a lot of messages sayin:

(delivery temporarily suspended: conversation with [] timed out while receiving the initial server greeting)

I try to stop fail2ban but the problem still continues.


I find a thing. If i make

sudo service postfix restart

it begins to work. It proccesses some mensajes in the queue (not all) but i have to restart again and again the service to make it work.

I maked a cron job restarting service all minutes (as workaround), but there must be anoter way to solve it.


Look for clues in the log files as to why Postfix is shutting down …


Port 10025 is for spamassassin. Could it be down?


I think that this is the real trouble. I think that the mails are in the queue because spamassasin retains them. I’m trying to fix it, but if anybody knows how…

I readed than spamassasin uses the first line of dns located in /etc/resolv.conf instead of the dns of the machine. In /etc/resolv.conf i only can see this


So i edited the file to put the following.


I will wait if this solve anything. Maybe it’s the dns server that does not work and that makes spamassasin retain the emails. Now i have 13 mails retained in queue and if i don’t do a “sudo service postfix restart” they don’t be sended.


resolv.conf pointing to localhost is normal. Check if the spamassassin daemon is running.

sudo systemctl status spampd


I got this

● spampd.service - Spam Proxy Daemon
   Loaded: loaded (/lib/systemd/system/spampd.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2019-02-20 16:36:00 CET; 21min ago
  Process: 1300 ExecStartPre=/usr/share/spampd/ (code=exited, status=0/SUCCESS)
 Main PID: 2285 (spampd)
    Tasks: 4 (limit: 4662)
   CGroup: /system.slice/spampd.service
           ├─2285 /usr/bin/perl -T /usr/sbin/spampd --pid=/var/run/spampd/ --tagall --port=10025 --host= --relayport=10026 --relayhost= --children=3 --logsock=unix --maxsize=2000 --user=spampd --group=spampd
           ├─8590 /usr/bin/perl -T /usr/sbin/spampd --pid=/var/run/spampd/ --tagall --port=10025 --host= --relayport=10026 --relayhost= --children=3 --logsock=unix --maxsize=2000 --user=spampd --group=spampd
           ├─9146 /usr/bin/perl -T /usr/sbin/spampd --pid=/var/run/spampd/ --tagall --port=10025 --host= --relayport=10026 --relayhost= --children=3 --logsock=unix --maxsize=2000 --user=spampd --group=spampd
           └─9328 /usr/bin/perl -T /usr/sbin/spampd --pid=/var/run/spampd/ --tagall --port=10025 --host= --relayport=10026 --relayhost= --children=3 --logsock=unix --maxsize=2000 --user=spampd --group=spampd

and then 10 lines like this

feb 20 16:57:02 boxcorreo spampd[9146]: processing message <019b01d4c92e$9ad00670$d0701350$> for <>,<>,<>,<dddd@tabi
feb 20 16:57:02 boxcorreo spampd[8590]: processing message <018a01d4c92c$6ff7c5c0$4fe75140$> for <>,<>,<>,<iiiii@tabigal.dy
feb 20 16:57:04 boxcorreo spampd[8590]: clean message <018a01d4c92c$6ff7c5c0$4fe75140$> (-1.89/5.00) from <> for <>,<>,<llll@tabigal

(I deleted the name of the mails). I think that this 10 lines are the mail that remains in queue