FQDN Error and Pass - ORF Forums

FQDN Error and Pass RSS Back to forum

1

The system notified the following just before passing a spam message which on a number of levels would not normally pass.

Error checking the SPF policy of domain "ezwsisolutions.com": The expanded domain for the "INCLUDE" mechanism is not an FQDN.

It looks like it hit this error and then just passed the email bypassing all it's other tests.

Concerned it may be a bug in version ORF 4.4

by Steven Richards 7 years ago
2

@Steven Richards: The error message indicates that the SPF policy of the sender domain includes a domain which is not an FQDN (fully qualified domain name), so the SPF test stops with this error. Their SPF record is

v=spf1 include:_spf.google.com include:spf.postini.com include:spf-a.ezwsisolutions.com. ~all

As you can see, they included the SPF policies of Google (http://support.google.com/a/bin/answer.py?hl=en&answer=178723), but underscore is not permitted in FQDNs according to the RFC (http://tools.ietf.org/html/rfc5321#section-2.3.5, page 42)

"To promote interoperability and consistent with long-standing guidance about conservative use of the DNS in naming and applications (e.g., see Section 2.3.1 of the base DNS document, RFC 1035 [2]), characters outside the set of alphabetic characters, digits, and hyphen MUST NOT appear in domain name labels for SMTP clients or servers. In particular, the underscore character is not permitted."

So Google screwed this one up... If they want others to include their policy, they should use an FQDN to promote it.

When such error occurs, ORF skips the SPF test and proceeds with the rest, so it will neither cause the email to be dropped, nor it will ensure its delivery.

by Krisztian Fekete 7 years ago
(in reply to this post)

3

Sorry for my delay in replying. I have been caught up in other projects unexpectedly. Thank you for confirming the issue over the underscore as not being a permitted SPF command.

I'm not sure if other SPF issues relate to a database issue (e.g. expiring of cache not taking place) or if there are a lot of SPF command issues around. The following SPF record keeps failing too:

"v=spf1 include:dns-solutions.net ip4:194.200.176.133 ip4:194.200.176.137 mx ~all"

If there is no known issues with that command then maybe our issues is more to do with the database issues. This is probably why I mentioned them together as I had a strange feeling to what our issue was.

Most error messages are "timeout expired" errors as below:

Error EOleException cleaning up expired database items. Database: Auto Sender Whitelist. Error: "Timeout expired".

Error EOleException cleaning up expired database items. Database: Greylisting. Error: "Timeout expired".

However we have had the following on SPF record tests:

Unexpected SPF Test error. EAssertionFailed "Invalid network IP for the CIDR test. (C:\projects\ORF\Source\ORFEnterprise\CoreService\tests\spf\SPFCommon_un.pas, line 145)".

Let me know if you need further details.

by Steven Richards 7 years ago
4

@Steven Richards: The SPF error is caused by a syntactically incorrect SPF record, see http://blog.vamsoft.com/2011/09/29/eassertionfailed-errors-on-the-spf-test/ for details.

The "Timeout expired" messages are independent from the SPF test: it most likely indicates that the SQL server you specified in the connection string is was not available when ORF tried to query it (or when it tried to write the database).

I recommend reviewing your connection parameters (Administration Tool: Configuration / Tests / Auto Sender Whitelist, Database button, Configure and Configuration / Filtering - Before Arrival / Database button, Configure).

by Krisztian Fekete (Vamsoft) 7 years ago
(in reply to this post)

5

@Krisztian Fekete (Vamsoft): Just as feedback I've redone the link with the SQL server and reduced the messages to taking place the same time each day. The result is that this coincides now with a backup process, so will either ignore or find solution for that issue :-)

Thank you again for your help.

by Steven Richards 7 years ago
(in reply to this post)

6

@Steven Richards: ah, so the backup process prevented wrinting the database, hence the errors. That makes sense :) I'd try excluding the tables ORF uses from the periodic backup.

by Krisztian Fekete 7 years ago
(in reply to this post)

New comment

Fill in the form below to add a new comment. All fields are required. If you are a registered user on our site, please sign in first.

It will not be published.
hnp1 | hnp2