MagicSpam Blocks Nextiva Faxes...

Gene Steinberg · Post by **Gene Steinberg** » Sun Apr 10, 2011 7:01 am

I receive my faxes via Nextiva.

Unfortunately, when that service tries to send me an email copy, MagicSpam blocks it:

2011-04-10 06:56:27

SPAM[check_dynamic_reverse_dns]

no

67.106.251.182

67.106.251.182.ptr.us.xo.net

mail.nextiva.com

I have put two combinations of nextiva.com on the whitelist in MagicSpam, and it's still blocked.

So what's the problem and how can it be resolved?

Peace,
Gene

magicspam · Post by **magicspam** » Mon Apr 11, 2011 8:48 am

Hello Gene,

There are a few other posts on these forums related to the check_dynamic_reverse_dns rule, but the short explanation of the rule is that Email Server Operators best practices states that the reverse dns record (or PTR record) for a public facing server should reflect the service and/or operator. In the case of the record you have listed, the PTR of 67.106.251.182.ptr.us.xo.net is a 'generic' style PTR that is normally associated with dynamically allocated ranges such as those seen in use for Home PC assignments (ie: ADSL dialup etc).

Now this said, we realize that you do not have direct control over the DNS records for Nextiva nor its upstream provider. This is why you have the options made available to "exempt" checks based on IP address, recipient, and from. Simply click on 'Exemptions' in the MagicSpam interface and you should be presented with a list editor for the different types that you can add to as required.

We hope this information helps

Gene Steinberg · Post by **Gene Steinberg** » Wed Apr 13, 2011 3:25 pm

I added the IP to the exemption and it appears we're OK.

I'd also like to know what your company feels about SPF records. When I set QMail to reject upon failure, even my son's email from GoDaddy was blocked. I can't imagine they can't figure out how to send a correct SPF (1and1 Internet doesn't support this feature on their email system).

Peace,
Gene

magicspam · Post by **magicspam** » Wed Apr 13, 2011 4:24 pm

We're glad to hear that worked for you!

As to SPF records, we have no set stance on the technology. While it has been around for some time, it still seems to be something that has been slow to adopt - and sadly the risks inherent with adopting partially implemented technology is generally high. This said, if everyone were to start enforcing it perhaps it would force a shift forward for the approach.

As to godaddy, it does appear that their SPF records are correctly set - we would be curious to see the the resulting log entry in your qmail logs for that particular event... perhaps they had recently added a relay and the DNS for the SPF records had not been updated yet?

In either case, we *may* implement SPF checks at some point in the future for our product, but it will, as with all our checks, be up to the end server operator if they wish to implement the check.

Wizard IT Products
Skip to content