Greylisting is on, but virtualmin says off

9 posts / 0 new

Topic locked

#1 Thu, 08/16/2012 - 11:31

warphost

Greylisting is on, but virtualmin says off

hi,

I have a simple problem with Virtualmin & Postgrey. Postgrey is enabled and in use on the server, but Virtualmin offers me the chance to enable it through the control panel (Email Messages > Email Greylisting). The server and the control panel are somehow out of sync.

While I can live with this, to satisfy my OCD I'd like to get this corrected. Is it possible to dip into the Webmin/Virtualmin settings somewhere and tell it what's really happening on the box?

Cheers.

#2 Thu, 08/16/2012 - 12:18

andreychek

Howdy,

How did you initially setup Postgrey, was it via Virtualmin?

Also, what does this command output:

grep smtpd_recipient_restrictions /etc/postfix/main.cf

Thanks,

-Eric

#3 Fri, 08/17/2012 - 03:05

warphost

Hey Eric,

This is becomming almost a daily occurrance isn't it :-)

grep... provides this:

smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination check_policy_service inet:127.0.0.1:10023

I originally set it up through Virtualmin; at first I wasn't sure it was applied properly, so I then disabled it in virtualmin... except I'm not sure it fully unregistered. I couldn't re-enable it through Virtualmin, so I checked the config & logs - it appeared to be working, so I left it at that.

I think that postgrey itself is working fine; there's just a disconnect between its existence and Virtualmin's recognition of its existence.

Thanks, Steve

#4 Sat, 08/18/2012 - 14:48

andreychek

I've been talking to Jamie about what might cause the symptoms you're seeing there... he suggested that one other thing to look into is the running Postgrey process.

What does this command output:

ps auxwwww | grep postgrey

#5 Mon, 08/20/2012 - 06:42

warphost

The output is:

root      2625  0.0  0.0   7548   836 pts/0    R+   12:38   0:00 grep postgrey
postgrey 16010  0.0  0.6  60488 14212 ?        Ss   Jul20   0:55 /usr/sbin/postgrey --pidfile=/var/run/postgrey.pid --daemonize --inet=10023

#6 Sat, 08/25/2012 - 17:53 (Reply to #5)

JamieCameron

That looks OK to me..

Another thing to check is if postgrey is enabled at boot time. To validate this, go to Webmin -> System -> Bootup and Shutdown, find the postgrey action and check if it is enabled at boot.

#7 Tue, 08/28/2012 - 09:54

warphost

Hmm, interesting.

Following your steps, I can see that postgrey is not enabled at boot time. I selected it, then clicked on the "Start On Boot" button.

The page output was then "Enabling action postgrey at boot time.", but when I returned to the list of processes, it was still marked in red as "No" (not enabled at boot time).

I tried disabling/re-enabling postgrey again through this page, but to no avail - it could not be enabled at boot through the script.

After a little digging, I could see that the S (starting) symlink wasn't being created in /etc/rc2.d/ (this is a debian system), but the K symlink is present in /etc/rc1.d. I just tried to delete the K symlink in /etc/rc1.d/ and test the webmin script again - no joy.

Looking deeper into this in the shell, I now get this:

# update-rc.d postgrey enable update-rc.d: using dependency based boot sequencing update-rc.d: error: no runlevel symlinks to modify, aborting!

Hah! - it would seem I need to restore more symlinks first before trying to enable/disable. I guess somehow the symlinks got knocked out with my rapid-fire button clicking.

I just checked through the init.d symlinks:

rc0.d/K02postgrey present
rc1.d/K02postgrey present
rc2.d/S18postgrey absent
rc3.d/S18postgrey absent
rc4.d/S18postgrey absent
rc5.d/S18postgrey absent
rc6.d/K02postgrey present

I recreated these, pointing all of them to /etc/init.d/postgrey, and then did a #update-rc.d postgrey enable, which fixed it.

The postgrey entry in the list in webmin now also says "Yes" (for Start On Boot).

And finally, in Virtualmin > Email Messages > Email Greylisting, I also now see the familar disable button and standard whitelists.

We're there - thanks for the pointers! :-)

#8 Sat, 06/06/2015 - 07:09 (Reply to #7)

snelweg

thank you warphost! This saved my day, everything is running again. But when I disable Postgrey through virtualmin I can start over again making all the symlinks. I wrote a shell program to make all the symlinks :)

Maybe this can be solved bij the nice people at Virtualmin?

cat /etc/debian_version 7.8

#9 Mon, 12/05/2016 - 19:23

vectorsites

I am having this same issue but I am running centos 7 which doesn't have postgrey in /etc/init.d/ and seems to be only run from postgrey.service Do I also need to do symlinks to fix this? Also there are two instances..which one?

/etc/systemd/system/multi-user.target.wants/postgrey.service /usr/lib/systemd/system/postgrey.service

ps axuwww | grep postgrey postgrey 10551 0.0 0.3 171368 14108 ? Ss 19:15 0:00 /usr/sbin/postgrey --unix=/var/spool/postfix/postgrey/socket --pidfile=/var/run/postgrey.pid --group=postgrey --user=postgrey --greylist-text=Greylisted for %s seconds --daemonize --delay=60 root 12935 0.0 0.0 112648 960 pts/0 S+ 19:42 0:00 grep --color=auto postgrey grep "smtpd_recipient_restrictions" /etc/postfix/main.cf smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination check_policy_service unix:private/policy check_policy_service unix:/var/spool/postfix/postgrey/socket check_sender_access hash:/etc/postfix/sender_access reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net, reject_rbl_client cbl.abuseat.org

Operating system CentOS Linux 7.2.1511 Webmin version 1.821 Virtualmin version 5.05

Topic locked