Password reset emails from https://www.calltrunk.com/us/en/sign-in.html never come through. Having trouble with many other online services on signup where welcome/confirmation emails take forever to come through.
I would prefer to disable grey listing altogether as many users are getting very frustrated.
Hello. No thereās no way to disable it, sorry. To whitelist you can add the IP address or hostname of the sending mail server in /etc/postgrey/whitelist_clients. Note that itās the sending mail server and not the domain in the From/envelope header.
Actually you could probably whitelist all senders to effectively disable postgrey entirely.
How do I whitelist all? Add a * entry?
/.*/
Will probably do it. (Thatās a regular expression.) Havenāt tried it though.
Thanks Josh for the RegEx, but unfortunately it doesnāt work. Every e-mail still gets grey listed.
Iām trying to minimize the impact of greylisting. On a server with 1 user, greylisting can be annoying. It has been more then once that Iām waiting on an e-mail that should have arrived sooner, for example: the security code of Facebook, an order on Steam during a LAN, waiting in a store waiting for a coupon code to arrive. This is more annoying then letting a e-mail hit the SpamAssassin and probably be filtered out.
Josh, any idea why greylisting is still active after the RegEx? I have restarted Postgrey. I donāt see any reason why it should, as the config file of postgrey gets loaded with the /etc/init.d/postgrey. I even set the whitelist-clients=/etc/defaults/postgrey/ā¦ manually.
About small volume e-mail server (like mine): It would be nice to set some postgrey parameters to minimize the annoyance in long term use of postgrey:
āauto-whitelist-clients=1 (whitelist host after first successful delivery. Default = 5)
āmax-age=365 (number of days the whitelist senders are kept. Default = 35)
Sorry to ask you this. I know itās not in your goal to make it configurable.
I had this same desire myself and I made a small edit to fix it to work as I want.
The change will likely be overwritten the next time the postgrey package is updated, but you can hack it by editing /usr/sbin/postgrey and making the following edits at approximately line 338. You need to add the code shown between the # greylist modifications begin/end lines:
sub smtpd_access_policy($$)
{
my ($self, $now, $attr) = @_;
my $db = $self->{postgrey}{db};
# This attribute occurs in connections from the policy-test script,
# not in a regular postfix query connection
if(defined $attr->{policy_test_time}) { $now = $attr->{policy_test_time} }
# greylist modifications begin 2014-05-25
if (lc $attr->{recipient} ne 'user1@mydomain.com' &&
lc $attr->{recipient} ne 'user2@mydomain.com') {
$self->mylog_action($attr, 'pass', 'non-targeted greylisting user');
return 'DUNNO';
}
# greylist modifications end 2014-05-25
# whitelists
for my $w (@{$self->{postgrey}{whitelist_clients}}) {
if($attr->{client_name} =~ $w) {
$self->mylog_action($attr, 'pass', 'client whitelist');
[...]
In specific, this disables greylisting for everyone except the named users. This means that user1@mydomain.com and user2@mydomain.com will still have their mail greylisted, but everyone else will have their mail delivered immediately without greylisting.
(I first tried to do this with regexes in the whitelist_recipients file, but I could never get the ānotā syntax to work, so I gave up and just edited the postgrey script instead.)
I can confirm that the regular expression /.*/ works. I am now receiving spam again 
+1 here
Just donāt forget to restart postgrey and postfix after:
service postgrey restart
service postfix restart
Editing /etc/postgrey/whitelist_clients works fine until the system cron scripts download a new whitelist_clients and any local changes are whipped out. Is there a better place to add local white_list clients? I second adding an option to disable grey listing.
@phildar This is exactly what /etc/postgrey/whitelist_clients.local is for. Just create a new file and put your regex in, it will stay there forever.
Until MiaB is upgraded and overwrites the directory as the previous poster indicated.
@alento Not quite what the previous poster meant. Nonetheless, perhaps you will find some further reassurance here showing that .local file, or indeed the whole directory, is not overwritten on reinstall, update or during a cron check.
After a year of using cPanel for email hosting [along with web hosting] I gave up and went back to MiaB. The only thing that I remember being a nuisance in MiaB was greylisting, but using the method suggested by @dustypants fixed this and greylisting seems disabled / or rather everything is whitelisted. Thanks! 
Maybe there should be an option to disable gray listing in the admin panel
grey listing is a highly efficient way to fight spam. Many times if you donāt see any spam in your mailbox, itās because of grey listing.
Yeah but it can sometimes cause emails not to be delivered or severely delay them
I find the greylisting annoying when I am registering an account on a website and it emails me a confirmation code. Since new, it is greylisted and I need to wait a while before continuing with the registration flow. It was so disruptive that I ended up using the workaround shown above.
Most site registrations have a ādidnāt receive mail - send againā link.
If you wait a minute and then hit that the second mail normally arrives straight away.
I just had a scenario where my brother couldnāt get a particular email to me, and his rejection message said it was greylisted. Yet he could craft a new email and send it straight through. After seeing that email come through OK, he tried to resend the original, and it still got rejected. I agree that in theory, greylisting can be good, but Iāve seen where itās also problematic for legit email.