DA server IPV4-only and sending to IPV4/IPV6 email servers

[Walther]

I have a DA server, with Exim, and just and only IPV4 network.
Everything works fine, but for sending email to users of a provider that decided to use a very strange configuration for his email servers
email service for example.com will be configured, i.e., as follows:

10 m-53b.th.seeweb.it {No A Record}
10 m-53b.th.seeweb.it 2001:4b78:1001:0:25::530a
20 smtp-avas-th.seeweb.it 217.194.8.27
20 smtp-avas-th.seeweb.it 2001:4b78:1:20::27

So:
- a first MX (priority: 10), that is just and only IPV6
- a secondary MX (priority: 20) that is IPV4 and IPV6

(If you're wondering "why so?", the answer is: they hope that, doing so, "good boys email server" will switch on secondary MX, while "bad boys email server" will try only on main server with IPV4, will got an error, and so they'll win against spammers.)

The result is that my (full legit) email server is not able to send emails to any domain with that configuration, because any send fails with a 5.0.0 error
(I guess that exim look for A record of m-53b.th.seeweb.it and, not finding a valid A record, give up without switching to the secondary server; I read again rfc5321, but found anything useful about this situation...)

So, the question is: is somehow being possible to configure DA in order to switch to secondary server in such a situation (main server that is not unrecheable or give not any error, but has simply no A record defined?)

BTW: do you know any other provider using such a configuration?

 

[factor]

It is called NoListing.

Nolisting - Wikipedia

en.wikipedia.org

Nolisting: Poor Man's Greylisting

nolisting.org

Is it nice?
Nolisting forces legitimate mailers to retry delivery to the secondary MX for every message that is sent. The effect is negligible, and delays are virtually nonexistent, with most clients retrying within the same second when using a firewalled approach or active host with no SMTP listener. In this respect, Nolisting imposes less of a penalty on clients than conventional greylisting, and offers an attractive alternative if greylisting introduces unacceptable delays or maintenance overhead.

If using an IP address with no device attached, a connecting host will wait according to its own timeout values before retrying the secondary MX. This delay is normally acceptable (and even undetectable) by end users, but it can adversely affect content filter chains that attempt to keep original connections open until delivery status is confirmed (with milters, before-queue content filters, or sender address verification, for example). For this reason, it is recommended to use a packet filter rule that immediately returns a TCP RESET, simulating a connected machine that is not listening on port 25.

Greylisting works better. Better yet use Spamd in FreeBSD.

 

[Walther]

If using an IP address with no device attached, a connecting host will wait according to its own timeout values before retrying the secondary MX. This delay is normally acceptable (and even undetectable) by end users, but it can adversely affect content filter chains that attempt to keep original connections open until delivery status is confirmed (with milters, before-queue content filters, or sender address verification, for example). For this reason, it is recommended to use a packet filter rule that immediately returns a TCP RESET, simulating a connected machine that is not listening on port 25.

But in this case there's not an "IP address with no device attached", there's no IP address for primary MX... And this is the reason, I guess, that the sending server does not switch to secondary MX.
Do you know any trick to force Exim to try the secondary server in such a case?