Feature Request: New Action: Reject 450/550

[jlar310]

Our implementation of recipient verification is working nicely with one exception. Certain mail aliases are intended for internal use only, yet they successfully pass receiver verification because they are deliverable on the back-end mail servers. So we created a Who list and a Block/Notify Sender Rule to block them from the outside with Proxmox. Of course, the Notify Sender generates a fair amount of back-scatter messages to postmaster. Yet we don't like to block without notification.

A simple fix would be to have a Proxmox action that mimics the behavior or a failed recipient verification, returning either 450 or 550.

 

[tom]

Our implementation of recipient verification is working nicely with one exception. Certain mail aliases are intended for internal use only, yet they successfully pass receiver verification because they are deliverable on the back-end mail servers. So we created a Who list and a Block/Notify Sender Rule to block them from the outside with Proxmox. Of course, the Notify Sender generates a fair amount of back-scatter messages to postmaster. Yet we don't like to block without notification.

A simple fix would be to have a Proxmox action that mimics the behavior or a failed recipient verification, returning either 450 or 550.

If you run MS ADS with Exchange you can define email addresses for internal use only (in the ADS). means the Exchange is only accepting incoming emails from internal ADS users and is sending a 550 to others. is this the wanted behavior?

 

[jlar310]

Not Exchange: Linux

No MS Exchange here. Linux postfix/cyrus-imapd on the back-end.

We have built-in linux aliases in /etc/aliases as well as some distribution lists stored in AD that we do NOT want to be deliverable from outside sources.

In postfix we have:

alias_maps = hash:/etc/aliases # built-in linux aliases
virtual_alias_maps = ldap:/etc/postfix/ldap-aliases.cf # AD distribution lists
local_recipient_maps = $alias_maps, $virtual_alias_maps ldap:/etc/postfix/ldap-users.cf # aliases and real AD users
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, reject_unverified_recipient
unknown_local_recipient_reject_code = 550

I don't know how to tell postfix to differentiate between internal mail traffic and proxmox when it comes to recipient verification. The only way I can think of to block private aliases from outside sources is to make proxmox do it.

We are doing that now with Block/Notify Sender, but having proxmox generate a 450 or 550 based on membership or lack of membership in a Who list would be more graceful. And in general, I think it would be a useful feature for many proxmox users that want to do recipient verification at the SMTP level without having to mess around with their back end systems. For small/medium companies, it might just be easier to maintain a user-list in proxmox than to reconfigure production mail servers. In our case with multiple domains across a VPN WAN, it could be used to cut down on WAN traffic for recipient verification checks. It seems like a simple enhancement that could solve many problems.

Enough about feature suggestions. Back to solving the problem at hand with the available tools...

If I could configure postfix to use different recipient verification sources based on the the relaying mail server, I could get the job done. Should I take this to the postfix mail-list to see if that is possible? I don't necessarily expect to be given postfix advice in this forum, but I will certainly accept it if someone has an idea.

Another option, though somewhat high-maintenance, would be to create a new relay server between proxmox and my internal servers to perform recipient verification for outside mail. This relay could have different verification sources than the back-end servers.

If I purchased the LDAP option for proxmox, could that be used a source for recipient verification? Or does it still have to check with the back-end mail servers?