SPF test with ISP DHCP ranges - ORF Forums

@daniel.helgenberger: Hello,

The 188.79.210.239 IP address is listed on both Spamcop and CBL -- you may want to give a try to these DNSBLs.

As for the SPF policy, I'm afraid jazztel.es has a flawed policy and that's why the SPF check fails. The SPF policy for jazztel.es is:

v=spf1 redirect=_spf.jazztel.es

This instructs the SPF client in ORF to evaluate the policy of _spf.jazztel.es instead. It looks like this:

v=spf1 mx ip4:62.14.3.170/30 ip4:62.14.3.174 ip4:62.14.3.191 ip4:62.14.3.192 ip4:62.14.3.193 ip4:62.14.3.194 ip4:62.14.3.195 ip4:62.14.3.196 ip4:62.14.3.197 ip4:62.14.3.198 ip4:212.106.192.69 ip4:212.106.192.72 ?all

It starts with an "MX" mechanism right away. When "MX" stands alone with no arguments, it means the mechanism will match if the MX record of the _SPF domain being tested_ contains the IP address being verified.

The issue is with the "SPF domain being tested" part here, because the "redirect" modifier from the original policy changes that to _spf.jazztel.es. Due to this, ORF will attempt to look up the MX record of _spf.jazztel.es, which does not exist and in turn this causes the SPF evaluation to fail.

@daniel.helgenberger: Hi Daniel,

Some of the DNSBLs (for instance, Spamhaus PBL, part of Spamhaus ZEN) blacklist dynamic IP addresses if they were specifically declared by their owners (i.e. the ISP) as unauthorized for direct email delivery. Unfortunately, not all ISPs make such declaration, out of ignorance or sometimes with malicious intent -- there're are tons of spammer-friendly ISPs out there. I've seen some of our clients experimenting with PTR blacklists for dynamic-looking reverse names, but I suppose with varying luck (this be something like enabling the Sender IP Reverse Name validation under Reverse DNS in ORF, then setting up a name pattern regex that matches anything that looks like an IP address, followed by the word "dynamic", "dyna", etc.). I think the link is too weak here and paying attention to other tests in ORF (specifically, the content-based tests like SURBLs) may result in better gains with less false positives.

I am not sure if I understand your proposal about SPF -- can you please elaborate? In any case, you should know that an error during the SPF evaluation will not cause the email to be whitelisted or blacklisted. All ORF does is to give up the SPF test in particular and proceed with the next test. In this sense, a flawed SPF policy like that of jazztel.es is neither a good thing, nor a good one -- ORF wastes a little time trying to evaluate the policy, but that's all.

Also, the SPF standard is very clear about how errors must be treated and with a few exceptions, the SPF evaluation must stop with an error (TempError or PermError). This is a sensible approach, because the SPF client (ORF) cannot make any reliable decision in this scenario. Judging from the amount of flawed SPF policies we see on a daily basis I'd suspect there are SPF clients are more allowing in this regard, but I don't think they are right about that: any attempt to second-guessing the publisher's intentions will inevitably fail due to lack of information.

@daniel.helgenberger: Hello Daniel,

No problem, I was just trying to give some insight into why ORF does things in a particular way :)

"If a test is positive before arrival and the mail gets rejected, how and when is this test applied on arrival?"

Once the email is rejected at Before Arrival, On Arrival tests will not run on that email, because the delivery stops right at Before Arrival. Although there are exceptions to this (see http://vamsoft.com/support/docs/orf-help/5.2/fltrpointconcept to see how that is possible), it has limited relevance. Otherwise, the two filtering points are entirely independent from each other.

"Why can I enable it on both? Can you supply an example where this makes sense?"

Sure, they come handy in a number of situations, but the most typical is when you have a secondary MX. In this scenario, some email is received directly by your email server (running ORF), but some emails will be routed through the secondary MX. This setup requires adding the secondary MX IP to the Intermediate Host List of ORF [1]. However, emails from Intermediate Hosts get whitelisted automatically at Before Arrival [2]. If you assign all tests to Before Arrival, emails arriving via your secondary will bypass all checks. If you assign all tests to On Arrival, that's fine, but then some things like Recipient Validation, etc. are better done at Before Arrival. When assigning tests to both filtering points, you can give some email the Before Arrival treatment and the rest the On Arrival one.

[1] Many ORF tests work with the original source IP of the email. For instance, the SPF test evaluates the original source IP against the SPF policy of the sender. Running the SPF test against your secondary MX IP would cause a false positive, but the Intermediate Host List tells ORF not to do that.

[2] Some of those IP-based tests mentioned in [1] are whitelists (e.g. the IP Whitelist). ORF rather opts to whitelist the email at Before Arrival just to make sure it can enforce your IP Whitelist at On Arrival.

***

From what I have gathered, you would need more granularity with actions, is that correct? For instance, you would trust some tests more and let them reject the email. Less trusted tests would get to e.g. tag the email only. In a sense, Before Arrival and On Arrival definitely enables that, but you could achieve the same by switching most/all tests to On Arrival and using a more granular action control than currently available. If that is the case, please vote the feature requests http://vamsoft.com/support/feature-requests/per-test-actions and http://vamsoft.com/support/feature-requests/per-item-actions -- it's the best way to add your voice.

@daniel.helgenberger: "Would it make sense to extend the SPF check by a feature like "Unresolvable SPF Policy"."

No: as Peter pointed out, blacklisting emails whenever an error occurs (e.g., due to faulty SPF records) is a very bad idea and would definitely cause a high number of false hits. Having a syntactically incorrect SPF policy published under no circumstances means that the sender host is a spammer and should be treated so.

@daniel.helgenberger: "I know - this is not RFC; but you also implemented such an option for 'SPF neutral'. IMHO it should be up to the user to decide what to do with it, as I can decide on SOFTFAIL and Neutral."

Neutral is different, as a domain may report SPF Neutral on possible forgery attempts. SPF Neutral states that the policy publisher neither permits, nor denies the sender as legitimate for the domain. Yet, you can expect SPF Pass result from legitimate senders. By enabling that option you can still blacklist on SPF Neutral on a per domain basis.

But if the SPF record is syntactically incorrect, it is impossible to tell whether the sender is authorized to send in the name of the domain or not.