Order of Receiver Verify/Greylist

[jlar310]

From reading the forums, I understand that receiver verification comes before greylisting, but I don't understand the reason for this choice.

We used to maintain lists of valid addresses in Proxmox and block all others instead of using receiver verification. This limited virtually all unnecessary internal mail traffic, but we didn't like how mail went into a black hole with no notification to the sender.So we enabled receiver verification on our backend postfix servers and proxmox.

But now, we are seeing a lot of mail traffic across our VPN WAN to each of our 5 internal domain mail servers in order to verify the recipients.

To me, it would make more sense to filter out the garbage with greylisting before employing internal resources to verify receivers. Isn't that the purpose of proxmox? To reduce the load on internal mail servers?

Would it be possible in future version to allow the adminsitrator to assign the order in which the various mechanisms are employed to filter incoming mail? Is there any technical reason that greylisting can not be done before receiver verification?

 

[dietmar]

From reading the forums, I understand that receiver verification comes before greylisting, but I don't understand the reason for this choice.

where did you read that?

Would it be possible in future version to allow the adminsitrator to assign the order in which the various mechanisms are employed to filter incoming mail? Is there any technical reason that greylisting can not be done before receiver verification?

For testing, you can edit the template:

/var/lib/proxmox/templates/main.cf.in

change the order of:

COND:SYSTEM:MAIL:VERIFYRECEIVERS|       reject_unverified_recipient
COND:SYSTEM:MAIL:USEPOLICY|     check_policy_service inet:127.0.0.1:10022

then run:

# proxconfig -s

Does that work?

 

[jlar310]

where did you read that?

Here for one...

http://www.proxmox.com/forum/showpost.php?p=1100&postcount=6

For testing, you can edit the template:

/var/lib/proxmox/templates/main.cf.in

change the order of:

COND:SYSTEM:MAIL:VERIFYRECEIVERS|       reject_unverified_recipient
COND:SYSTEM:MAIL:USEPOLICY|     check_policy_service inet:127.0.0.1:10022

then run:

# proxconfig -s

Does that work?

It's hard to tell right away, but it appears to have made a difference. Looking at the greylist logs, I can see that timestamps before I made the change only had valid recipients. After the change, the greylist log now has many invalid recipients. Still a fair amount of verification rejects in my back-end logs, but I suppose more spammers are employing techniques to work around greylisting these days...

Can I assume that we will have to redeploy this tweak after every hotfix or upgrade?

Thanks for your help.

 

[dietmar]

Can I assume that we will have to redeploy this tweak after every hotfix or upgrade?

If you really weant that behaviour you need to redeploy it after every upgrade/hotfix - yes.

The question is if you need it. The rationale behind that order is that it also shrinks the greylisting database.

But now, we are seeing a lot of mail traffic across our VPN WAN to each of our 5 internal domain mail servers in order to verify the recipients.

The test mails used to do receiver verification are small and not stored at all. So usually that network traffic is low, much less than delivering the original mails.

- Dietmar