Wizard IT Products

Hi There

Reverse DNS checks generally seem to fail, even though if i check the ip on a couple of other checkers, it successfully reverses back.

any ideas

Thanks

What do you mean when you say they "seem to fail"? Is there a certain IP address which is having trouble? Could you provide the IP address? Also, it could be that the DNS was recently changed for the IP address, and the changes have not propagated to the DNS server which your server is using.

Thanks.

We are an ISP. Our problem is that besides the current best practices we need absolutely th SPF control on the sender domain, so that if a server is declared as legitimate to relay for that domain no other checks must be performed and the host granted to relay.

We do not (yet) have SPF support built in to MagicSpam though this is on our future release feature board. It should be noted that this is primarily due to the various methods that email servers handle SPF.

For example - if one configures SPF checks in Postfix, then the policy can be configured as an 'authorized' check which actually takes place before MagicSpam can check anything. There are similar configurations for Qmail as well.

This being said, we do hope to have SPF support available early next year.

Thank you for the prompt replay. I have enabled SPF check on Plesk. How can I however configure the mailserver so that SPF check comes first with respect to MagicSpam, or, in other words, that SPF is negatively decisive for spam attribute? Thank you again

This may depend on your version of Plesk...

This being said, we are not certain at this time at which layer Plesk handles SPF checks - if it is handling this in the Queue layer then the simple answer is 'you can't since MagicSpam operates before Queuing can take place (NOTE: this is to ensure your server does not generate backscatter).

We are aware of methods in standard Postfix to make this happen, which may be transferable to Plesk 9.x with Postfix set as the MTA, but we can't guarantee it as active development for SPF support in MagicSpam has not yet begun.

You may wish to direct your query to the Parallels forums to find out at what level in their various versions of Plesk Panel the SPF checks take place. Just so you are aware, MagicSpam checks take place within the SMTP layer immediately after the RCPT TO: command.

On a side note - it appears that the SPF configuration for Plesk Panel is primarily for 'deny' behavior - not permit...

Is this particular case you are reporting also related to SPF records not being honored?

We should point out that the check_dynamic_reverse_dns rule is agnostic of that aspect - this IP address shows a PTR record that falls within the 'dynamic' style pattern normally associated with non server addresses - it is not a case of forward to reverse matching, but a case of Best Practice standards whereby a public server IP should have a proper FQDN indicative of the host and service - such as:

mail.telstra.net

or similar.