• Please be aware: Kaspersky Anti-Virus has been deprecated
    With the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Problem with SPF and DNS resolution

X

Xsigns

Guest
I try to forward me an email from another server. Since a few days (maybe after upgrading to 9.5.3) I get the following error in the maillog on the receiving server:

Dec 1 10:20:39 h1600221 /var/qmail/bin/relaylock[30536]: /var/qmail/bin/relaylock: mail from 85.214.72.251:33540 (server03-xsigns.de)
Dec 1 10:20:39 h1600221 qmail-queue-handlers[30540]: Handlers Filter before-queue for qmail started ...
Dec 1 10:20:39 h1600221 qmail-queue-handlers[30540]: [email protected]
Dec 1 10:20:39 h1600221 qmail-queue-handlers[30540]: [email protected]
Dec 1 10:20:39 h1600221 qmail-queue-handlers[30540]: hook_dir = '/usr/local/psa/handlers/before-queue'
Dec 1 10:20:39 h1600221 qmail-queue-handlers[30540]: call_handlers: call executable = '/usr/local/psa/handlers/info/05-grey-yoeV2a/executable'
Dec 1 10:20:39 h1600221 greylisting filter[30541]: Starting greylisting filter...
Dec 1 10:20:39 h1600221 greylisting filter[30541]: list type: white, from: [email protected], match string: .*@xsigns\.de
Dec 1 10:20:39 h1600221 qmail-queue-handlers[30540]: handlers_stderr: SKIP
Dec 1 10:20:39 h1600221 qmail-queue-handlers[30540]: call_handlers: SKIP during call '/usr/local/psa/handlers/info/05-grey-yoeV2a/executable' handler
Dec 1 10:20:39 h1600221 qmail-queue-handlers[30540]: call_handlers: call executable = '/usr/local/psa/handlers/info/10-spf-nmz8CQ/executable'
Dec 1 10:20:39 h1600221 spf filter[30544]: Starting spf filter...
Dec 1 10:20:40 h1600221 spf filter[30544]: Error code: (26) DNS lookup failure
Dec 1 10:20:40 h1600221 spf filter[30544]: Failed to query MAIL-FROM: Temporary DNS failure for 'xsigns.de'.
Dec 1 10:20:40 h1600221 spf filter[30544]: SPF result: tempfail
Dec 1 10:20:40 h1600221 qmail-queue-handlers[30540]: handlers_stderr: DEFER
Dec 1 10:20:40 h1600221 qmail-queue-handlers[30540]: call_handlers: DEFER during call '/usr/local/psa/handlers/info/10-spf-nmz8CQ/executable' handler
Dec 1 10:20:40 h1600221 qmail-queue-handlers[30540]: call_handlers: stop call handlers from dir '/usr/local/psa/handlers/before-queue/global'

Problem is this

Dec 1 10:20:39 h1600221 spf filter[30544]: Starting spf filter...
Dec 1 10:20:40 h1600221 spf filter[30544]: Error code: (26) DNS lookup failure
Dec 1 10:20:40 h1600221 spf filter[30544]: Failed to query MAIL-FROM: Temporary DNS failure for 'xsigns.de'.
Dec 1 10:20:40 h1600221 spf filter[30544]: SPF result: tempfail

But:

~# host xsigns.de
xsigns.de has address 85.214.99.174
xsigns.de mail is handled by 10 mail.xsigns.de.

- correct I think.
And:
SPF is set to "reject if SPF-Query returns 'fail'"

but result is 'tempfail'?

Where is my mistake?
 
Seems like that tempfail is considered by SPF as fail too.
 
You can try to define more reliable nameservers in /etc/resolv.conf
 
We are seeing the same error as above "Error code: (26) DNS lookup failure" for some senders of emails.

We are running Plesk 9.5.4 and I can perform an nslookup and a dig on the server and view the domains TXT records with no issues.

Has anybody identified the cause of this, and more importantly a resolution?

Many thanks,
Paul
 
We are seeing a lot of this as well. A lot of "Error code: (26) DNS lookup failure" in /usr/local/psa/var/log/maillog. Plesk 9.5.4 here too. The domains can be looked up in DNS on the server just fine (using dig or nslookup).

Anyone have any suggestions?

Thanks,
Chris
 
Hi Igor,

We checked and everything works fine with DNS on our server - the 'host amazon.com' lookup runs fine, as well as for the domains that SPF is failing for. It seems that SPF 'tempfail' is being processed as a 'fail', whereas it should really be processed as a 'softfail', ie the messages should not be rejected when a 'tempfail' occurs.

To work around this issue we have set SPF to allow all messages regardless of SPF status - this is the only way we have been able to get the messages which were failing to deliver successfully. Not ideal but our only choice to get mail delivering reliably.

Any suggestions Igor?

Thanks,
Chris
 
Chris,

We also have no issues with DNS - so I raised a ticket with support who confirmed this.

They have advised that the senders SPF record starts "v=spf" which is incorrect - it should be "v=spf1" and that is the cause of the issue.

I'm still waiting for our client to get this updated, but hopefully that should resolve the issue, any possibly yours.

Paul
 
Hi Paul,

Thanks for your reply.

Interestingly enough our sender's domain does not have an SPF record configured, so that doesn't tie up with the information you've been provided by support (or we're seeing a different issue).

Strangely the sender (remote user not hosted by us) was receiving a bounce with the message "553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1)" which is very weird as they weren't trying to relay through our server. That same sender was able to send mail to a different user at the same domain though. In other words [email protected] could email [email protected] but not [email protected].

In both cases (successful and unsuccessful) the "Error code: (26) DNS lookup failure" was logged in /usr/local/psa/var/log/maillog.

It was only this one sender's domain and all other mail is being delivered properly so it's not a critical issue for us, but it would be nice to know from Parallels what causes this and if it's a fault on our end or the sender's.

Thanks,
Chris
 
I have forwarded it to developers. Let's wait their answer.
 
Chris,

The "rcpthosts" error you mentioned is an odd one - that file lists all domains hosted on the server, so both users should have bounced with the same message!

It may be an issue with the version you are running, but we are running a different version of the SPF checking - are you running Plesk 9.5.4?

Paul
 
Guys, I have received following reply from developers:

I've skimmed over the thread:

I could not reproduce the original poster's problem - it passes SPF at the moment.
/usr/bin/spfquery_static -ip 85.214.99.174 -sender [email protected] -rcpt-to [email protected]
pass
spfquery: domain of xsigns.de designates 85.214.99.174 as permitted sender
Received-SPF: pass (spfquery: domain of xsigns.de designates 85.214.99.174 as permitted sender) client-ip=85.214.99.174; [email protected];

PaulC, who admits having and invalid SPF record in DNS should have the issue resolve itself once the record is fixed.

As for other posters, I need IP, from/to emails to be able to investigate.
 
Sorry to bump this old thread, but I guess this bug is the cause for the problems.

Compare the output of dig for TXT and SPF:

~# dig TXT wilson-house.co.uk
(snip)
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44916

~# dig SPF wilson-house.co.uk
(snip)
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 57920

~# /usr/bin/spfquery_static -ip 109.200.22.12 -sender [email protected] -rcpt-to [email protected]
StartError
Context: Failed to query MAIL-FROM
ErrorCode: (26) DNS lookup failure
Error: Temporary DNS failure for 'wilson-house.co.uk'.
EndError
(invalid)neutral

As you can see by the output of "dig TXT", it´s not a DNS problem. Mails from this domain are rejected when I set Plesk to "reject mail when SPF resolves to fail". Though, IMHO a temporary failure should be softfail and not fail. Running Plesk 9.5.4

@Igor: Will there be a fix for this problem?


Lars
 
Back
Top