Add second IP to PMG

[wwweiss]

Currently I got a problem with Symantec's Blacklist. My IP is listed as bad reputation, but my system did not send Spam. Delisting is not working and it is not possible to get any info from Symantec.
To solve such problems my idea was to add a second IP to PMG. I can add a bond in the GUI with the second IP and then I can connect over this IP. But how can I tell the system to send outgoing mails to special receiver-domains over this second IP.
How should I set the names and reverse DNS?
I have mailgateway.myDomain.de => for the primary domain (with corresponding Revers DNS)
Should I set the same name for the second IP (with RDNS) or would it be better to set mailgateway2.myDomain.de?
It would be great, if someone can point my to the right direction (if possible at all)

 

[treloskilo]

Your PMG is behind NAT or has a public ip?

 

[wwweiss]

it has a public ip.

 

[hata_ph]

Configure your network firewall rule to redirect outgoing SMTP to your secondary public IP.

 

[wwweiss]

Thank you treloskilo and hata_ph. Maybe my question was not exactly enough. I would like to have something like
https://forum.proxmox.com/threads/postfix-mail-rotate-outgoing.53584/#post-247543
just not randomizing but with defined routing for defined domains.
My system is a VM located at a service provider, this means it is only reachable by is public IP-Address. The private mailsystem connects to PMG also on its public IP on port 26.
The reason why a want to have this routing option is the bad reputation list from Symantec. My public IP is listed there and the delisting does not work (don't know why - they give no info). This listing makes problems when PMG sends a mail to a server that is using a Symantec security product. Then this receiving server does not accept the mails from my PMG (typical behavior of DNSBL).
Because I do not succeed in getting delisted, my idea was to switch (temporarily) the sending IP only for those domains that make problems.

Meantime I think I know the problem why I do not get delisted. It is the concept of PMG to accept mails on port 26 without further authentication.
Of course PMG only accepts mails from the IPs I have defined. But the port is open for everyone in the world (if not blocked by a firewall).
This might be a problem if outside runs a check system, checking if my PMG is a open relay.
Looking to the SMTP-dialogue in a normal SMTP session we have mail from:someone, rcpt to:someoneelse. If someoneelse is not a local address the system directly gives the error "relaying" denied.
On port 26 this is not the case. PMG accepts until the data command and then gives the message "not allowed due to policy".
Maybe an open relay checker does not go so far, such a system may assume PMG is an open relay. And if such a checker is part of a DNSBL then PMG never gets delisted, because it seems to be an open relay (of course it is not).

Therefore I know first try to solve the delisting problem, and if this still does not work I will try again this second ip.

 

[hata_ph]

Is your PMG act as your outgoing smtp as well?

 

[wwweiss]

Yes my PMG handles all outgoing mails. I now could get a working solution based on the links posted before.
This is what id did:

1. Got a second IP from my hosting provider routed to the server
2. Added the IP inside PMG GUI Configuration -> Interfaces: Add Bond (I did not add the IP over the normal system way)
3. Checked that the system was anwsering on the new IP.
4. setup DNS and rDNS for the new IP
5. Copied /var/lib/pmg/templates/main.cf.in and /var/lib/pmg/templates/master.cf.in to /etc/pmg/templates (had to create the folder "templates")
6. Made changes (added these lines) in /etc/pmg/templates/master.cf.in

7. relay1     unix  -       -       n       -       -       smtp
     -o smtp_bind_address=my_current_ip4_address
     -o smtp_helo_name=mailgateway.myDomain.tld
     -o syslog_name=relay1
   relay2     unix  -       -       n       -       -       smtp
     -o smtp_bind_address=my_new_ip4_address
     -o smtp_helo_name=mailgateway2.myDomain.tld
     -o syslog_name=relay2

8. Added these lines to /etc/pmg/templates/main.cf.in

9. sender_dependent_default_transport_maps = randmap:{relay1,relay2}
   smtp_connection_cache_on_demand=no

10. Applied the changes by running
    pmgconfig sync --restart 1
    on the console

Now my system is sending out with both IPs in a random way.
I will improve that by changing the sender-map, so that only some receiver-domains will be contacted by the second IP.
With this I can easily switch the IP of my system, if a receiver does not accept mails due to wrong listing in the bad reputation list from symantec.

I know this is no good solution, because both IPs could be listed. But my system does not send spam, so on typical blacklists it is very easy to get delisted. But on the symantec list it is not easy, because you cannot get any info, if the delisting does not work.

 

[hata_ph]

Have you check with your hosting provider regarding the blacklist?
Another option is using smarthost but make sure the public IP is clean too.

 

[wwweiss]

I am very well used to handle the problems with blacklist entries. But there is one blacklist from symantec (broadcom) which is only used inside symantec security solutions: https://ipremoval.sms.symantec.com
This one has the very bad behavior that you do not get any information about the reason why you are listed. There is no option to get in contact to someone. This means, you can request a delisting, but if this is not done you are left alone. As long as you are listed there all receiving mailservers that are using symantecs antivirus software do not accept mails from your system.
I checked my system serveral times and surely it does not send spam, but I am listed and delisting does not work and nobody tells me why it does not work. Because my customers of course complain that they cannot send mails to some addresses, I needed to find a solution to overcome this.
Changing the sending IP to an IP that is not listed was the only quick solution.

One important thing I found in this scenario was PMGs handling of the allowed IPs on port 26. If I do not add an additional firewall in front of PMG then of course port 26 is open to everyone. But PMG only accepts mails from the defined IP-Adresses. This is working and is no problem.
PMGs checking is done AFTER the data command (i tried to describe this in a post above). This might be a problem if those blackist providers run a check against your IP to find out if you system is an open relay. If such a check tool opens a SMTP connection sending "mail from" and "rcpt to" and they expect to get an "authentication required" or something else, then PMGs handling may be a problem.
This can be solved by adding a firewall of course, but then you have two places where you need to add IP addresses.

 

[hata_ph]

Maybe have a look at nftables snat

https://www.linuxbabe.com/mail-server/postfix-multiple-instances-ip-rotation-on-a-single-vps

 

[Stoiko Ivanov]

PMGs checking is done AFTER the data command (i tried to describe this in a post above). This might be a problem if those blackist providers run a check against your IP to find out if you system is an open relay. If such a check tool opens a SMTP connection sending "mail from" and "rcpt to" and they expect to get an "authentication required" or something else, then PMGs handling may be a problem.

Could not reproduce this behavior here:
* while the rule system and some other checks (those that do need the data of the mail run after the data command - PMG itself relies on postfix for the access control (e.g. only trusted networks are allowed to relay on the internal port, only mail to relay domains is accepted on the external port) - and (as explained in http://www.postfix.org/SMTPD_ACCESS_README.html#timing ) the reject happens after the rcpt to

I quickly tried to verify this here (using swaks):

swaks --server [2001:DB8::666]:26 --to localpart@receiver.domain --data testdata.txt                 
=== Trying 2001:DB8::666:26...                                                                      
=== Connected to 2001:DB8::666.                                                                     
<-  220 pmg7.rosa.proxmox.com ESMTP Proxmox                                                         
 -> EHLO sender.domain                                                                              
<-  250-pmg7.rosa.proxmox.com                                                                       
<-  250-PIPELINING                                                                                  
<-  250-SIZE 104857600                                                                              
<-  250-VRFY                                                                                        
<-  250-ETRN                                                                                        
<-  250-STARTTLS                                                                                    
<-  250-ENHANCEDSTATUSCODES                                                                         
<-  250-8BITMIME                                                                                    
<-  250-DSN                                                                                         
<-  250-SMTPUTF8                                                                                    
<-  250 CHUNKING                                                                                    
 -> MAIL FROM:<localpart@sender.domain>                                                             
<-  250 2.1.0 Ok                                                                                    
 -> RCPT TO:<localpart@receiver.domain>                                                             
<** 554 5.7.1 <localpart@receiver.domain>: Relay access denied                                      
 -> QUIT                                                                                            
<-  221 2.0.0 Bye                                                                                   
=== Connection closed with remote host.

If your PMG behaves differently - please share the logs (and if possible the session-transcript) of such a session - as this might be problematic (for the reasons you noted above.

Else - regarding the issue with the intransparent DNSBL and its policies - sadly in my experience there's indeed little you can do - but if you have the time I think it might help - to notify the provider of the list (symantec) - and also the server using their DNSBL (the mailserver you cannot send mails to, maybe through a product of symantec). If enough people complain it might help to convince symantect to make their process more transparent