I've had a Postfix server running for a very short amount of time, and it worked, but I had to restart the server today, and I'm no longer receiving e-mails from external sources:

Jan 23 01:34:44 myservername postfix/smtpd[1055]: connect from db3ehsobe006.messaging.microsoft.com[]
Jan 23 01:34:45 myservername postfix/smtpd[1055]: warning: connect to Connection refused
Jan 23 01:34:45 myservername postfix/smtpd[1055]: warning: problem talking to server Connection refused
Jan 23 01:34:46 myservername postfix/smtpd[1055]: warning: connect to Connection refused
Jan 23 01:34:46 myservername postfix/smtpd[1055]: warning: problem talking to server Connection refused
Jan 23 01:34:46 myservername postfix/smtpd[1055]: NOQUEUE: reject: RCPT from db3ehsobe006.messaging.microsoft.com[]: 451 4.3.5 Server configuration problem; from=<MyKnownWorking@EmailAccountOutside> to=<MyAccount@MyDomain.com> proto=ESMTP helo=<db3outboundpool.messaging.microsoft.com>

The server is listening on port 10023, but I noticed it's only listening via IPv6:

> sudo netstat -a | grep 10023
tcp6       0      0 ip6-localhost:10023     [::]:*                  LISTEN

I have no firewall rules in place that would deny that would specific port, hell, I went ahead and flushed the rule set just to confirm it. Here's the output of my postconf -n (I edited out my domain name in place of "mydomain.com":

> sudo postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
    append_dot_mydomain = no
biff = no
broken_sasl_auth_clients = yes
config_directory = /etc/postfix
content_filter = amavis:[]:10024
disable_vrfy_command = yes
inet_interfaces = all
inet_protocols = ipv4
mailbox_size_limit = 0
message_size_limit = 0
mydestination = localhost.$mydomain, localhost, mail.mydomain.com, servername.mydomain.com
mynetworks = [::ffff:]/104 [::1]/128
mynetworks_style = host
myorigin = /etc/mailname
readme_directory = no
receive_override_options = no_address_mappings
recipient_delimiter = +
relayhost =
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_use_tls = yes
smtpd_banner = mail.mydomain.com ESMTP $mail_name
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_recipient_restrictions = reject_unauth_pipelining, permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_recipient, reject_unknown_recipient_domain, reject_unauth_destination, check_policy_service inet:, permit
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain =
smtpd_sasl_security_options = noanonymous
smtpd_sender_restrictions = permit_sasl_authenticated, permit_mynetworks, warn_if_reject reject_non_fqdn_sender, reject_unknown_sender_domain, reject_unauth_pipelining, permit
smtpd_tls_cert_file = /etc/ssl/private/mail.mydomain.com.crt
smtpd_tls_key_file = /etc/ssl/private/mail.mydomain.com.key
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
virtual_alias_maps = mysql:/etc/postfix/maps/alias.cf
virtual_gid_maps = static:5000
virtual_mailbox_base = /var/spool/mail/virtual
virtual_mailbox_domains = mysql:/etc/postfix/maps/domain.cf
virtual_mailbox_limit = 0
virtual_mailbox_maps = mysql:/etc/postfix/maps/user.cf
virtual_uid_maps = static:5000

As you can see, I'm even trying to specify via inet_protocols that it listens on ipv4 connections. I've tried it with and without that command.

Any help in troubleshooting would be greatly appreciated! And of course, if you see anything in my configuration is glaringly stupid, I am not above advice or criticism.


Your last check on smtpd_recipient_restrictions uses a policy service to verify the recipient. Typically this is a postgrey service and appears to have some problems with Postfix connecting to it.

smtpd_recipient_restrictions = ...,check_policy_service inet:, permit

If you remove check_policy_service inet: from the smtpd_recipient_restrictions, you should eliminate the error, but you still should determine what happen to your postgrey or other service that would be running here.

Checking for Postgrey on an Unbuntu System

Typically a postgrey default config will listen on port 10023 for connections and determine if they should be allowed or rejected. Some pieces on an Unbutu server that you can check for to see if this is installed are...

  • Do you have a /etc/default/postgrey file? This is the basic config file.
  • Do you have a /etc/postgrey folder? This is where you can whitelist elements.
  • When you run > which postgrey does it find a binary? Mine is found in /usr/sbin/postgrey.
  • Do you have a /etc/init.d/postgrey script for starting it up on boot up? This is the typical location for Ubuntu daemons.

These will only give you some clues as to if this server may have had postgrey configured at one time. You will need to look further for troubleshooting if the process is not running properly on your server.

  • It's interesting, in the postconf -n it shows, however, in my my.cnf it shows as commented out: #smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject Edit: Never mind, I'm dumb. Earlier version commented out.
    – DavisTasar
    Jan 23 '13 at 2:04
  • I also should add that, that change did work and I am receiving mail now. Would you have any recommendations as to how to determine what about this check_policy_service is having issues with?
    – DavisTasar
    Jan 23 '13 at 2:08
  • Typically this is a postgrey service integrated with Postfix that will run on this port. You can look for some clues to see if this is installed. Up above is some guidance on checking for Postgrey. Jan 23 '13 at 21:42
  • Tim, sir, you are the man. I'll be looking into everything. Postgrey is definitely installed, I ran into a locking issue with it earlier today.
    – DavisTasar
    Jan 24 '13 at 1:58
  • In my case, I followed a guide that installed the kitchen sink but I only installed the essentials but this was left in .. removed it and all good. Thanks!!
    – Nimbuz
    Sep 20 '16 at 23:19

Faced with same problem, tried many ways such as proposed by bshea, googling and trying.
Base: Ubuntu 14.04.2 LTS, postgrey service starts, but doesn't appear in process list, i.e. service starts but quietly drops out.

Found solution to change line in /etc/default/postgrey:

Change this line:


To this


No need to play with ports, protocols, neither version-of-something downgrade. Can not explain why, but service is in ps -aux and all works.

  • I cannot emphasize it more how this answer was helpful. I was about to start trying everything, including disabling the firewall etc., but luckily I found this answer before trying anything else. The symptoms are the same: the service starts without any errors or warnings, but ps aux does not list it, but after this change it does.
    – Vadim
    Oct 7 '16 at 19:01
  • I've just encountered the same problem on Debian 8 and Postfix 2.11.3: reject: RCPT from smtp04.xxxxxxx.xx: 451 4.3.5 Server configuration problem; postgrey service was running but not listening on port 10023 (netstat -a | grep 10023 not showing anything) This little piece of configuration saved my day! after restarting postgrey service, i can see it now listening on 10023. Thank you very much for this tip!
    – Anybug
    Jun 28 '18 at 9:08

Actually, you are not forced to use ipv6, you may set Postgrey and Postfix to ipv4. The problem is, Postgrey (probably version 1.33 and newer) refuse to start on ipv4 localhost ip, so you may use your ethX ip address.

In /etc/postfix/main.cf change this:

check_policy_service inet:


check_policy_service inet:<your_ipv4_address>:10023

Then restart Postfix:

sudo service postfix restart

In /etc/default/postgrey change this:

POSTGREY_OPTS="--inet=10023 --delay=60"


POSTGREY_OPTS="--inet=<your_ipv4_address>:10023 --delay=60"

Then restart Postgrey:

sudo service postgrey restart

Very userful was this Debian mail list message:



Davis - you're right, postgrey was changed in 12.04LTS to work in IPv6. Upgrade doesn't change it for postfix and doesn't alert you to make a change.

So you have to do it yourself. Change this:

check_policy_service inet:


check_policy_service inet:::1:10023

in your /etc/postfix/master.cf file, then restart postfix:

sudo service postfix restart

It will allow postfix to talk IPv6 to postgrey.


The IP:PORT issue isn't/wasn't an issue for me (Ubuntu 14.04.2 LTS). It can be misleading to assume postgrey is breaking/exiting on local port attach/execution failure.

First check to see if daemon is recognized as running :

sudo service postgrey status

If it is not running/recognized, you will still see :

warning: problem talking to server [::1]:10023: Connection refused

in your mail log. Postgrey simply isn't attached/running. If you find it running (may be more than once) and cannot service stop or status it, you probably have a pid/truncate issue. If so, do :

ps a | grep postgrey

Kill (each) process manually. Remove any postgrey.pid files from /var/run (/run).

Assuming all your postgrey files are default and it is trying to start, but failing on reboots/restarts/stops (after checking 'sudo service postgrey status'), you probably have issues with lockfile and named process for stop-start-daemon.

POSTGREY has a VERY basic init.d script which does not do much checking before/after it executes things. The maintainers really need to work on this.

Main problem is start-stop-daemon looking for truncated named file :

( https://bugs.launchpad.net/ubuntu/+source/postgrey/+bug/1289424 )

The script as installed checks for $NAME = "postgrey".
( "--name $NAME" )
Unfortunately, what it needs to use (Ubuntu/Debian) is : '/usr/sbin/postg'
(only 15 chars and is part of path - which doesn't exist obviously.)

The fix (add variable PROCNAME with truncated version including path):

PROCNAME=`echo $DAEMON | cut -c -15`

(Will then check for '/usr/sbin/postg' instead)

and will go under "--name" :

        log_daemon_msg "Stopping $DESC" "$NAME"
        if start-stop-daemon --stop --oknodo --quiet \
                --pidfile $PIDFILE --name $PROCNAME


        log_action_begin_msg "Reloading $DESC configuration..."
        if start-stop-daemon --stop --signal 1 --quiet \
                --pidfile $PIDFILE --name $PROCNAME

While I was at it I put the lock file inside it's own directory: '/run/postgrey/postgrey.pid'.

If you prefer it in it's own directory, you need to add this bit to recreate the folder each time:


Check for existing dir/folder:

check_pid_dir() {
  if [ ! -d $PIDFOLDER ]; then
    mkdir $PIDFOLDER
    chmod 0755 $PIDFOLDER

and add function to "Start":

case "$1" in
        log_daemon_msg "Starting $DESC" "$NAME"

My full init.d script is here: https://gist.github.com/bmatthewshea/50e2038563b103e466ea
I have not tested this much - but it is certainly working better than default so far. :)


This will also break if you've configured Postfix to talk IPv4 only (As I have to due to my ISP still not doing IPv6, and my IPv6 HE tunnel being tagged by services like Netflix, and thus breaking Netflix...)

adding the local host to the INET command flag for postgrey does fix it not binding to IPv4.

I don't get why it can't just bind to BOTH IPv4 AND IPv6 though...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.