Hi Looks as though my server has managed to make the gmail blacklist again, despite no sign of issue from our side. We manage a number of domains and the only thing I can see from the headers is one of the public IPs used to access and send email via our server was blacklisted but I'm still confused as to whether or not this would cause the issue. The message we're getting is: relay=gmail-smtp-in.l.google.com[2a00:1450:4013:c01::1b]:25, delay=1.5, delays=0.06/0/0.13/1.3, dsn=5.7.1, status=bounced (host gmail-smtp-in.l.google.com[2a00:1450:4013:c01::1b] said: 550-5.7.1 [2001:8d8:xxx:yyy::zzz:5104 12] Our system has detected that this 550-5.7.1 message is likely unsolicited mail. To reduce the amount of spam sent 550-5.7.1 to Gmail, this message has been blocked. Please visit 550-5.7.1 http://support.google.com/mail/bin/answer.py?hl=en&answer=188131 for 550 5.7.1 more information. w13si21575990wiv.49 - gsmtp (in reply to end of DATA command)) Anyway, looking at the bounce messages from google they all appear to come from IP6 connections and all IP4 connections don't get bounced. Looking into it further I also found a suggestion that you can overcome the issue by either following googles recomendations (I believe I have done this with spf, dkim and dmarc, hence 3 months without issue...). Alternatively it suggested you could fix the issue by preventing your email from sending as IP6 by simply editing /etc/exim4/exim4.conf.template and adding disable_ipv6 = true. After doing this you then simply restart exim4 by running /etc/init.d/exim4/restart and your exim server should stop using IPv6. What do you think of this as an option and what would be the potential side effects of switching off ip6? My hope if this were a "fix" would be simply to do this at times if we became blocked, whether that be from an account actually spamming resulting in a block after we fix the issue or something similar. Any other thoughts would be greatly appreciated. I'm running Debian wheezy, with courier, postfix and ISPconfig 3.1.5.3. Thanks
I recommend to try to switch off ipv5. In postfix, you do this by adding the line: inet_protocols = ipv4 in the postfix main.cf and then restart postfix. there are currently no negative side effects as I doubt that there are any ipv6 only mail servers out there yet.
Hi Till Many thanks for the clarification, I have put this in place so I guess time will tell if it fixes the issue. Have you any idea why IPV6 would create gmail bounces, perhaps something in my config, ptr is all setup so can't think what else it may be. Rgds James
I did check the DNS but not with intodns.com which I will now add to my list of useful tools. The results I have look ok. There is one main issue highlighted under the SOA section, NSs have same SOA serial and this highlights they don't. I'm assuming this wouldn't cause any issue as long as we update both name servers with the same information or am I missing a simple configuration change that could take care of this for us? Other than that the above it was noted that Glue for NS records wasn't sent and that we only have one MX records. Again I don't see any issue from these two. Basically as a little explanation as to why we are configured in this way, having followed the perfect server guide previously (about 4 years ago) for redundant servers we found we had issues. The main one was due to the mysql master master configuration. The servers would lose connectivity potentially due to one crashing or simply the server farm playing with it's own routing and effectively preventing the two servers from talking for long enough for them to drop out of sync. Effectively this lead to more outages as we then had to re-initiate the master master replication taking both servers out of action. We also had real speed issues with webmail when there was any quantity of mail which I finally traced down to glusterFS, over 60 sec to load larger mail boxes. As a result when we decided to rebuild the mail servers we went for a main server with hot standby. The servers use unison triggered every 5 minutes to keep near real time data files and we simply copy the ispconfig database from the primary server to the hot standby every 24 hours. In the event of a failure on the primary server which can't be fixed by a simple reboot, or something equally quick, we would simply change the mx record in both servers to be the hot standby server whilst we fixed any issues. If you want to comment on this configuration that would also be appreciated. Thanks for your help so far. James
So after looking into IPV6 DNS reports specifically the only errors I have are missing AAAA mx and AAAA www records. At the moment my DNS Zone records look like this: Type Name Data A mail 1.2.3.4 A www 1.2.3.4 A test.com. 1.2.3.4 AAAA test.com. 1111:2222:333:444:555:666 MX test.com. mail.test.com. So in order to pass the IPV6 test I assume I would need to add the following Type Name Data AAAA mail 1111:2222:333:444:555:666 AAAA www 1111:2222:333:444:555:666 So to the questions: 1 - Could this be a reason why sending email via IPV6 would get rejected by gmail as unsolicited mail. 2 - If I do implement the IPV6 changes, would fail2ban cope with this as I believe it only works with iptables not ip6tables. 3 - Do you recommend adding the IPV6 records listed above into my DNS. Apologies for these no doubt naive questions.
Yes. fail2ban will not work for connections on IPv6 addresses. But you can e.g. reconfigure fail2ban to ban with null routes instead of iptables: http://www.faqforge.com/linux/contr...ute-instead-of-iptables-to-block-connections/ The genetal problem is that tools like fail2ban will not be that useful anymore when you switch on IPv6 as there are just too many IPv6 addresses out there. For example, in the datacenter were I have some servers you get 1 ipv4 address with your server for free plus 64 thousand ipv6 addresses. If someone has 64 thousand ipv6 addresses and wants to go around fail2ban, then he can use each of these addresses to try out 2 or 3 passwords. when he is finished with all his addresses, then he can most likely start again as the first attempt is already out of the monitoring or ban time of fail2ban. The same applies to realtime blacklists, with that many IP's, it is useless to blacklist a single IP. Either they blacklist whole subnets or the system wont work anymore. You should add the IPv4 MX records only if you want to turn on IPv6 for email. If you want to turn on ipv6 is up to you, from the standpoint to spread the ipv6 support in the internet and the shortage of ipv4 addresses, you should do that. From a spam defence and security standpoint, it might be less optimal to turn it on.
