SPF, Milter, Message aborted

[Red Paint]

Hello,

One of our domains is having problems receiving email from selected IP's.

This is happening for a selection of domains on our servers but a specific example can be found below:

From the maillog:

May  1 06:23:32 plesk spf filter[25550]: Error code: (26) DNS lookup failure
May  1 06:23:32 plesk spf filter[25550]: SPF result: tempfail
May  1 06:23:32 plesk /usr/lib64/plesk-9.0/psa-pc-remote[13289]: handlers_stderr: DEFER
May  1 06:23:32 plesk /usr/lib64/plesk-9.0/psa-pc-remote[13289]: DEFER during call 'spf' handler
May  1 06:23:32 plesk /usr/lib64/plesk-9.0/psa-pc-remote[13289]: Message aborted.
May  1 06:23:32 plesk postfix/cleanup[23168]: E461A66A71: milter-reject: END-OF-MESSAGE from eu1sys200aog103.obsmtp.com[207.126.144.115]: 4.7.1 Service unavailable - try again later; from=<[email protected]> to=<[email protected]> proto=SMTP helo=<eu1sys200aog103.obsmtp.com>
May  1 06:23:32 plesk postfix/smtpd[10248]: disconnect from eu1sys200aog103.obsmtp.com[207.126.144.115]

I've tried an spf query and it spits back the following:

# /usr/bin/spfquery_static -ip 207.126.144.155 -sender [email protected] -rcpt-to [email protected]
pass
spfquery: domain of newsint.co.uk designates 207.126.144.155 as permitted sender
Received-SPF: pass (spfquery: domain of newsint.co.uk designates 207.126.144.155 as permitted sender) client-ip=207.126.144.155; [email protected];

/etc/postfix/main.cf looks like this:

virtual_mailbox_domains = $virtual_mailbox_maps, hash:/var/spool/postfix/plesk/virtual_domains
virtual_alias_maps = $virtual_maps, hash:/var/spool/postfix/plesk/virtual
virtual_mailbox_maps = hash:/var/spool/postfix/plesk/vmailbox
transport_maps = hash:/var/spool/postfix/plesk/transport
smtpd_tls_cert_file = /etc/postfix/postfix_default.pem
smtpd_tls_key_file = $smtpd_tls_cert_file
smtpd_tls_security_level = may
smtpd_use_tls = yes
smtp_tls_security_level = may
smtp_use_tls = no
smtpd_timeout = 3600s
smtpd_proxy_timeout = 3600s
disable_vrfy_command = yes
mynetworks = 127.0.0.0/8 [::1]/128 ......
smtpd_sender_restrictions = check_sender_access hash:/var/spool/postfix/plesk/blacklists, permit_sasl_authenticated, check_client_access pcre:/var/spool/postfix/plesk/non_auth.re, reject_unknown_sender_domain, warn_if_reject reject_unverified_sender
smtp_send_xforward_command = yes
smtpd_authorized_xforward_hosts = 127.0.0.0/8 [::1]/128
smtpd_sasl_auth_enable = yes
smtpd_recipient_restrictions = permit_mynetworks, check_client_access pcre:/var/spool/postfix/plesk/no_relay.re, permit_sasl_authenticated, reject_unauth_destination
virtual_mailbox_base = /var/qmail/mailnames
virtual_uid_maps = static:110
virtual_gid_maps = static:31
virtual_transport = plesk_virtual
plesk_virtual_destination_recipient_limit = 1
mailman_destination_recipient_limit = 1
smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_rbl_client sbl.spamhaus.org
myhostname = plesk.redpaint.co.uk
message_size_limit = 20480000
smtpd_milters = inet:localhost:12768
non_smtpd_milters = inet:localhost:12768
sender_dependent_default_transport_maps = hash:/var/spool/postfix/plesk/sdd_transport_maps

It's a strange one and I'm not sure what's going on but something is preventing these emails from being delivered.

Any thoughts?

 

[gregconway]

I have the same problem on many servers. The solution for us was to switch off SPF. This is not ideal, but at least mail gets through!

After much searching, this seems to be Parallel's response -

http://kb.parallels.com/114982

Our servers load average is under 1.0 on all affected servers at the time of seeing these problems.

I would also appreciate thoughts on this problem... I'd like to be able to switch SPF back on!

I have recently updated our servers from Plesk 9.5.4 to Plesk 11.0.9, but the problem remains.

 

[Red Paint]

Hello Greg,

Interesting you are having the same problem and I also found the KB but, like you, after reading the KB it doesn't seem relevant to this particular problem.

Parallels can you provide some input:

/usr/bin/spfquery_static is coming back as pass when run manually.

Why is there a DNS failure is this something to do with our local or ISP DNS? It doesn't seem likely. Turning off spf isn't really a viable option for us so it would be useful to have some method of accepting email that returns a tempfail or fixing/working around whatever problem is causing the DNS lookup to fail. Is there a timeout setting somewhere for DNS lookups that we can edit?

 

[gregconway]

Aplogies... this thread!

http://forum.parallels.com/showthre...-4-4-External-emails-not-receiving-mailserver

 

[Red Paint]

Hi Greg,

Thanks for that. I found the following which also appears related:

http://forum.parallels.com/showthre...-clean-ubuntu-12-04-and-plesk-11-installation

We run ASL and were blocking port 12768 which I thought was the problem but unblocking that port made no difference, although it did make me wonder if there may be other ports that might be blocked which milter needs.

/etc/hosts has 127.0.0.1 as #1 on the list so that is not the problem either.

So with reluctance followed the recommendation to comment out the following line from /etc/postfix/main.cnf:

#smtpd_milters = inet:localhost:12768
#non_smtpd_milters = inet:localhost:12768

Surely there is a better solution than this Parallels!?

 

[Onkeltom01]

Hi,
we've the same issue as Red Paint with two Plesk 11.0.9#51 Servers running on CentOS 6.4 x64.

May 18 02:59:52 s16045381 spf filter[27950]: Starting spf filter...
May 18 03:00:05 spf filter[27950]: Error code: (26) DNS lookup failure
May 18 03:00:05 spf filter[27950]: Failed to query MAIL-FROM: Invalid hostname (an IP address?)
May 18 03:00:05 spf filter[27950]: Failed to query MAIL-FROM: Temporary DNS failure for 'spf.trusted-forwarder.org'.
May 18 03:00:05 spf filter[27950]: SPF result: tempfail
May 18 03:00:05 /usr/lib64/plesk-9.0/psa-pc-remote[28220]: handlers_stderr: DEFER
May 18 03:00:05 /usr/lib64/plesk-9.0/psa-pc-remote[28220]: DEFER during call 'spf' handler
May 18 03:00:05 /usr/lib64/plesk-9.0/psa-pc-remote[28220]: Message aborted.

At the moment we disabled SPF to let the eMails pass. Manual checking of SPF with query normally passes but automatic checking with postfix and SPF gives the error above.
We can reproduce the problem since 12th of April, perhaps the Update MU#46 is responsible for that?

any solution?

 

[IgorG]

Have you checked it http://kb.parallels.com/11152 ?

 

[Onkeltom01]

Yes IgorG, the result was "softfailneutral" which is not a reason for discard the email.

softfailneutral
	Please see http://www.openspf.org/Why?id=XYZ%40abc.com&ip=xxx.xxx.xxx.xxx&receiver=spfquery : Reason: default
spfquery: xxx.xxx.xxx.xxx is neither permitted nor denied by domain of abc.com
	Received-SPF: neutral (spfquery: xxx.xxx.xxx.xxx is neither permitted nor denied by domain of abc.com) client-ip=xxx.xxx.xxx.xxx ; [email protected];

 

[Red Paint]

Have you checked it http://kb.parallels.com/11152 ?

Yes Igor,

# /usr/bin/spfquery_static -ip 123.456.789.123 -sender [email protected] -rcpt-to [email protected]
softfailneutral
Please see http://www.openspf.org/[email protected]&ip=123.456.789.123&receiver=spfquery : Reason: default
spfquery: 123.456.789.123 is neither permitted nor denied by domain of SENDER.COM
Received-SPF: neutral (spfquery: 123.456.789.123 is neither permitted nor denied by domain of SENDER.COM) client-ip=123.456.789.123; [email protected];

(I've changed the details above but the message/response is original)

In Plesk we have the following SPF settings:

SPF checking mode: Reject mail when SPF resolves to "fail" (deny)
SPF local rules: include:spf.trusted-forwarder.org
SPF guess rules: v=spf1 +a/24 +mx/24 +ptr ?all

So this email is being rejected even though our system is only configured to reject a fail and not a softfail/neutral.

 

[frg62]

Is your rejection problem not linked to the fact that "spf.trusted-forwarder.org" does not respond anymore?

I found 2 threads that mention related problems:
http://forum.parallels.com/showthread.php?284601-451-qq-trouble-in-home-directory
http://forum.parallels.com/showthread.php?284443-If-your-incoming-mail-has-suddenly-started-failing

Igor, what is your opinion on that matter?

 

[Red Paint]

Is your rejection problem not linked to the fact that "spf.trusted-forwarder.org" does not respond anymore?

I found 2 threads that mention related problems:
http://forum.parallels.com/showthread.php?284601-451-qq-trouble-in-home-directory
http://forum.parallels.com/showthread.php?284443-If-your-incoming-mail-has-suddenly-started-failing

Igor, what is your opinion on that matter?

Very interesting frg62, I've removed spf.trusted-forwarder.org from the email configuration settings. We're currently now sitting with:

SPF checking mode: Only create Received-SPF headers, never block
SPF local rules:
SPF guess rules: v=spf1 +a/24 +mx/24 +ptr ?all

We also still have the following lines from /etc/postfix/main.cnf commented out:

#smtpd_milters = inet:localhost:12768
#non_smtpd_milters = inet:localhost:12768

Is it save to uncomment these lines and change the SPF checking mode back to "Reject mail when SPF resolves to "fail" (deny)"?

Any thoughts?

 

[IgorG]

I have forwarded this problem to developers (#1658687 for your reference). Let's wait results of their investigation.