Most of the time FreeBSD documentation is complete and more than anyone could ask for. With the release of Postgrey 1.34_7 this was not the case. I’ve been running some form of greylisting on my mail servers for almost a decade now, and while fast and simple in what greylisting does, there is virtually no error handling built into it. While commendable that the maintainers have opted to move the startup script into a more conventional framework, the manual changes required to get this program to run were mostly undocumented and led to hours of trial and error and searching the internet for a solution. Hoping this post will help some sysadmin somewhere until the problem is addressed by the FreeBSD package maintainers.
20130525:
AFFECTS: users of mail/postgreyThe RC script for postgrey has been modified. If you use the default value for postgrey_flags this does not affect you.
If you have postgrey listening on a Unix socket or set any optional values, please read the comments in the RC scripts and check your settings in rc.conf prior to restarting postgrey.
I’ve been using the same procedure for several years and I use the default values, or so I thought. No matter what I tried, postgrey would fail to start with various warnings but no direct clue as to what was wrong:
> service postgrey start
> Starting postgrey.
> Pid_file “/var/run/postgrey.pid” already exists. Overwriting!
Checking the processes with ps -waux |grep postgrey made it clear nothing was running in spite of the message above.
Reading the comments in the new startup script in /usr/local/etc/rc.d/postgrey made it pretty clear what needed to happen:
# Add the following lines to /etc/rc.conf to enable postgrey:
# postgrey_enable (bool) Set to ‘YES’ to enable
# Default: NO
# postgrey_dbdir (path) Location of postgrey database files.
# Default: /var/db/postgrey
# postgrey_flags (extra args) Additional command-line parameters.
# Default: –inet=10023
The value command_args in the postgrey startup script contained values which seemed redundant to what was already in postgrey_flags in /etc/rc.conf. Indeed, adding these values to postgrey_flags /etc/rc.conf caused duplicate parameters to appear in the process. The startup script would fail for want of params in the rc.conf, but adding them to rc.conf caused redundancies.
>ps -waux |grep postgrey
>postgrey 9278 0.5 0.3 22088 11204 ?? SsJ 12:05PM 0:00.02 /usr/local/sbin/postgrey –pidfile=/var/run/postgrey.pid –inet=127.0.0.1:10023 -d –x-greylist-header=X-Greylist: delayed %t seconds by postgrey-%v at %h; %d -d –pidfile= –dbdir=/var/db/postgrey.pid
The solution was to add all the parameters to rc.conf and comment them out of the startup script like so:
Add to /etc/rc.conf so postgrey will run:
postgrey_enable=”YES”
postgrey_greylist_header=${postgrey_greylist_header:-“X-Greylist: delayed %t seconds by postgrey-%v at %h\; %d”}
postgrey_pidfile=”/var/run/postgrey.pid”
postgrey_flags=”–pidfile=${postgrey_pidfile} –inet=127.0.0.1:10023 -d –x-greylist-header=${postgrey_greylist_header}”
Comment out the following lines in /usr/local/etc/rc.d/postgrey to prevent redundancies:
#pidfile=/var/run/postgrey.pid
required_dirs=${postgrey_dbdir}
#command_args=”-d –pidfile=${pidfile} –dbdir=${postgrey_dbdir}”
stop_postcmd=”rm -f ${pidfile}”
run_rc_command “$1”
Bingo. Finally a running postgrey process!
postgrey 9278 0.5 0.3 22088 11204 ?? SsJ 12:05PM 0:00.02 /usr/local/sbin/postgrey –pidfile=/var/run/postgrey.pid –inet=127.0.0.1:10023 -d –x-greylist-header=X-Greylist: delayed %t seconds by postgrey-%v at %h; %d -d –pidfile= –dbdir=/var/db/po