Thank you for your quick response.

As from the wiki: present in r493+ and v2.1.x
But you ship cluebringer 2.0. Have you patched your version?

I have the latest version running but greylisting did not work at all. Would you suggest to install a fresh version of iredmail on a blank server? If this is the way to go what will happen if my license is running on two different servers during the migration?

I have migrated my server to a fresh install and I can definitely say the provided cluebringer package is not ipv6 aware which causes a lot of trouble if you make use of ipv6. Even sending smtp authenticated emails from ipv6 clients (servers and virtual machines in a datacenter) fails with the postfix configuration from iRedMail.

To avoid this trouble you can modify the postfix main.cf file:

1. Add permit_mynetworks and permit_sasl_authenticated to smtpd_end_of_data_restrictions:
smtpd_end_of_data_restrictions = permit_mynetworks,
                        permit_sasl_authenticated,
                        check_policy_service inet:127.0.0.1:10031

2. Move permit_mynetworks and permit_sasl_authenticated above check_policy_service inet:127.0.0.1:10031 in smtpd_recipient_restrictions:
smtpd_recipient_restrictions = ...
                        permit_mynetworks,
                        permit_sasl_authenticated,
                        check_policy_service inet:127.0.0.1:7777,
                        check_policy_service inet:127.0.0.1:10031,
                        ...

This way authenticated clients and members of mynetworks can bypass cluebringer and the missing ipv6 support does not harm your sending process and fallback mx servers. Even if ipv6 would work it is a good idea to bypass smtp authenticated users from cluebringer unless you want to apply quota checks.

I understand you are not the one to blame for features in third party applications like cluebringer. I myself develop software for widely spread applications and in such a case i would either provide a cluebringer 2.1 package with a note to my customers that this is still an unstable branch although it is rock solid (from what people report). Or i would check for other working solutions like sqlgrey (http://sqlgrey.sourceforge.net/) which i use on my fallback mx servers.

Ignoring ipv6 today can be fatal due to the fact many services (e.g. googlemail) have already switched to ipv6 and new ipv4 blocks (at least in the RIPE region) are not available anymore. It is likely more and more providers will migrate to ipv6. As I already mentioned I like iRedMail and value your work (otherwise I would use the free version for my 10 mailboxes). Don't hide behind the development issues others have ;-) Having no full ipv6 support delays the email transport heavily (the time until the sender will fall back to ipv4).

Regards

Michael

I've just checked the policy.org site as well as cluebringer dev mailing list archives and git commits. The project is moving much like a snail. There is so little activity it's not comforting.

The last point releases for STABLE (2.0.x) and 2.1.X branch are over TWO YEARS old.

In May 2015, developer on the dev mailing list said they are reworking a big naming change and would release after it was done.

I'm not excited about this at all. PolicyD v2 doesn't seem to be moving much at all. Mail servers that support IPv6 are either using the 2 yrs old 2.1.X branch or latest from GIT or something else entirely to implement policy checking.

GIT repo has an *open* issue titled "IPv6 support in all modules" https://gitlab.devlabs.linuxassist.net/ … d/issues/8

Can we please, please, get a path forward for iRedmail?
Any suggestions?

everyone can download 2.1.X branch and hammer through trial and error to update database?

What about SPF checks?
Were you only using cluebringer for throttle and greylisting?

I've disabled cluebringer in my install for now so I can receive mail via IPv6. Initial results seem to indicate cluebringer policy was keeping spam with high scores out of my inboxes.