Question Outgoing mail mode - ipv6

[leo_1988]

Hi guys

The ipv4 of our mail server frequently ends up in the UCEPROTECTL2 / 3 blacklist which is a subnet blacklist.

Our hosting provider will not pay for delisting and I have to wait for a week, and this goes for some time now.

so, they proposed we sent the emails through ipv6 as they already provide it on the hosting plan.

I looked around and added the ipv6 to plesk

# The loopback network interface

auto lo

iface lo inet loopback



# The primary network interface

auto eth0

allow-hotplug eth0

iface eth0 inet dhcp

iface eth0:1 inet static

address 10.0.2.15

netmask 255.255.255.0

auto eth0:1

iface eth0 inet6 static

address 2001:xxxx:yyy:xxxx::yyyy

netmask 64

gateway 2001: xxxx: yyy: xxxx::1

auto eth0

in dns, I added AAAA record mail.exampledomain.com same as the A record but with the ipv6 provided.

Also changed the spf record adding the ip6: part

In plesk:



Is there anything else I’m missing; my emails are still going out from ipv4 and wont deliver to certain mail providers.

Thanks in advance.

 

[JordanGround]

Hello,

I am in the same situation as you, and unfortunately, I cannot find a solution to send e-mails over IPv6, while leaving the website on IPv4.

If you find a solution, I am interested!

Thank you very much !
Jordan c
(I use Google Translation)

 

[learning_curve]

The ipv4 of our mail server frequently ends up in the UCEPROTECTL2 / 3 blacklist which is a subnet blacklist.
Our hosting provider will not pay for delisting and I have to wait for a week, and this goes for some time now.

The "won't pay for delisting" etc is very evasive and pretty annoying. They should be actively seeking which of their customers has caused the issue and brought about the UCEPROTECTL2 / 3 blacklist on the whole of the IP's CIDR, in which, all of the other 'innocent' IPv4 addresses are then effected - Like you here.

so, they proposed we sent the emails through ipv6 as they already provide it on the hosting plan.

Which, although that's an effective workaround for this issue, it saves them doing any further work!

I looked around and added the ipv6 to plesk

~~

Are you with IONOS? It looks like you might be from that coding.
We are & they are dismissive / evasive with solving things like this - i.e. All of their own problem, caused by not having a proactive blacklisting team...

in dns, I added AAAA record ~~ In Plesk ~~

What happened when you made these changes? It appears from your last note below that this did not work i.e. sent form your IPv6 address NOT IPv4 address.

We deliberately don't use "send from the speciified IP address" option because although this is validated via the MX records etc it has previously caused more rejection issues than the "send from domain IP address and use domain names in SMPT greeting" option, but would still like to have / see a functional option to ONLY use an IPv6 address and NOT an IPv4 address for the Plesk Mail Service.

Is there anything else I’m missing; my emails are still going out from ipv4 and wont deliver to certain mail providers

Yes it's a very sensible option / choice. Maybe somebody like @IgorG might have more details of a different config method than the Plesk GUI?

 

[learning_curve]

This is another recent example of the same question: Question - Send email from a domain's IPv6 with an added cost saving element for that speciifc user

 

[learning_curve]

FWIW and in reference to the previous post ^ The option to remove the IPv4 address from the IP Adressess section of Web Hosting Access does already exist, but that woud apply to all of the domain, not just the mail service.

What is actually being sought by us all, it appears, is the ability for the mail server to be IPv6 only i.e. across all domains.

MX records could / would still contain the IPv4 address in case of any DNS / SPF validation queries say, but the initial handshake would always be via IPv6

 

[weltonw]

UCEPROTECTL2 / 3

Anyone using UCEPROTECT these days is insane. I cannot think of a more ineffective RBL than UCEPROTECT. UCEPROTECT serves more to punish providers than actually moderate spam. It doesn't even do that well.

Is there anything else I’m missing; my emails are still going out from ipv4 and wont deliver to certain mail providers.

Using only IPv6 is not a good idea. There are many servers that don't support connection over IPv6, in which case your email(s) won't be delivered. It can be configured via Postfix: Postfix IPv6 Support

 

[learning_curve]

Anyone using UCEPROTECT these days is insane. I cannot think of a more ineffective RBL than UCEPROTECT. UCEPROTECT serves more to punish providers than actually moderate spam. It doesn't even do that well.

Good point, well made. However, despite this (which we fully agree with) having a CIDR entry in UCEPROTECTL2 / 3 i.e. one which includes your own 'innocent' IPv4 address(es) does cause problems and it does very quickly appear everywhere, like a rash, in many popular RBL consolidated list sites...

Using only IPv6 is not a good idea. There are many servers that don't support connection over IPv6, in which case your email(s) won't be delivered. It can be configured via Postfix: Postfix IPv6 Support

Another very good point, but the consistent failure of people / setups / organisitions to adopt IPv6 is diminshing daily, exacerbated by the eventual nil availability of any more, new IPv4 addresses.

Assuming that use of IPv6 has been setup correctly elsewhere on the server, the Postfix config (within the default Plesk and any given OS and/or partner disk image setup) did take a little bit of detective work on the 'fresh' installed versions of /etc/postfix/main.cf and etc/postfix/master.cf plus any subsequent updates that have been applied since the install. They were definitley not exactly as laid out in the Postfix guide, but in our case, by default, these specific settings, were all setup to enable the mail server to use both IPv4 AND IPv6:
inet_protocols
smtp_bind_address AND smtp_bind_address6
mynetworks - Although we did edit this slightly, even so

However this one:
smtp_address_preference
Was by default, setup to be IPv4 only, so we had to alter this, to include IPv6, as well as IPv4

All of that ^^ means that both IPv4 AND IPv6 have been available to the mail server since we originally set it up, so all things consideed, that's possibily the best compromise in the interim, until the day that IPv4 beocmes the Betamax of IP Adresses and IPv6 claims the VHS title

 

[weltonw]

Good point, well made. However, despite this (which we fully agree with) having a CIDR entry in UCEPROTECTL2 / 3 i.e. one which includes your own 'innocent' IPv4 address(es) does cause problems and it does very quickly appear everywhere, like a rash, in many popular RBL consolidated list sites...

I'm inclined to agree, but if you're on UCEPROTECT 3, it doesn't matter IPv4 or IPv6

 

[learning_curve]

I'm inclined to agree, but if you're on UCEPROTECT 3, it doesn't matter IPv4 or IPv6

Although UCEPROTECT 3 isn't related to IPv6 in anyway (i.e. Neither you, nor they, can currently test a server's IPv6 address on there, as it's IPv4 only) Your IPv4 test does produces the CIDR that includes your own IPv4 address plus... the ASN ID Number of your host. As a result, you could be IPv4 / IPv6 cross-referenced. You need to apply a little time, but you don't have to be Sherlock Holmes, to figure out any affected domain's IPv4 AND IPv6 addresses, merely by alternative lookup & cross-reference options. However IF your server was IPv6 ONLY / NO IPv4 at all, then currently, you cannot appear on UCEPROTECT level 1, 2 or 3 regardless. Hence the OP's hosting company's kind of lazy solution to the problem that they have

 

[weltonw]

Although UCEPROTECT 3 isn't related to IPv6 in anyway (i.e. Neither you, nor they, can currently test a server's IPv6 address on there, as it's IPv4 only) Your IPv4 test does produces the CIDR that includes your own IPv4 address plus... the ASN ID Number of your host. As a result, you could be IPv4 / IPv6 cross-referenced. You need to apply a little time, but you don't have to be Sherlock Holmes, to figure out any affected domain's IPv4 AND IPv6 addresses, merely by alternative lookup & cross-reference options. However IF your server was IPv6 ONLY / NO IPv4 at all, then currently, you cannot appear on UCEPROTECT level 1, 2 or 3 regardless. Hence the OP's hosting company's kind of lazy solution to the problem that they have

Well, OP wants to use IPv6 because his company is currently on IPv6. IPv6 is a ASN blacklist. It depends on the implementation, but in theory, a UCE 3 block means the entire ASN is blacklisted. That happens regardless of IP protocol

 

[learning_curve]

Well, OP wants to use IPv6 because his company is currently on IPv6. IPv6 is a ASN blacklist. It depends on the implementation, but in theory, a UCE 3 block means the entire ASN is blacklisted. That happens regardless of IP protocol

Yep fully agreed about the entire ASN ID in theory being blacklisted by default by UCEPROTECT, but... your words"...in theory..." are the key here.
It's impossible (on the poxy UCEPROTECT site anyway) to identify any IPv6 addresses, hence their ASN ID, hence their blacklisting...

IPv6 blacklisting is nowhere near as well developed as IPv4 anywhere - yet. Here's a couple of examples of our own, back when our hosting provider also had a UCEPROTECT 3 entry that included our server IPs and before it was removed. The IPv6 blacklisting was totally invisible on both MultiRBL.valli.org - Blacklist, Whitelist and FCrDNS check tool and Network Tools: DNS,IP,Email and indeed... everywhere else! We could easily find the IPv4 blacklisting (back to UCEPROTECT...) and even though the server's FQDN was / is exactly the same on both A and AAAA DNS records, that made absolutley no difference whatsoever. That's possibly another reason for the OP's hosting company's proffered solution?

 

[hugosnel]

Hello,

Is there any change in the issue??
I suddenly do not see any more UCEPROTECT3 when I check my OVH IP addresses with MXTOOLBOX !
Hard to grasp...