Frank,

If there is NO SPF Record for schulverwaltung.bremen.de, is shouls not fail because "NO SPF" passes by default.  Can you post a log entry that show a failure?

Frank could have simply added the hostname or IP block to his base DNS and SPF policy and life would have been good.

The question is when is a subdomain a subdomain and when is it merely a host for the base domain.  This is an ongong debate in SPF discussions still.

When you assume every host is a valid subdomain errors occur and spammers can easily insert a bogus hostname along with using your email addresses and pass your SPF policy now.

With SpamFilter, it was decided before to remove the above loophole, thus improving over the old SPF Standard(current SPF or "classic SFP was developed before it was really used much).  Roberto used a check for an NS record to validate the subdomain and this was good until this thread began the backward steps.  I think if the old logic was put back and in addition to NS records qualifying the subdomain that the absense of a host A records also validated a subdomain, that would have solved Frank's problem and kept the superior implementation of SPF that SpamFilter used.

If we're back to assuming that every host name is a subdomain like the old SPF does because it saved an extra query, then build 405 is a serious down grade.

-Matt

In this example there is no A record or host record for bremen.de and there is an MX record for schulverwaltung.bremen.de.  So what really needed to be done was adjust SpamFilter logic to expand on defining a valid subdomain as having an NS Record OR MX record or when not being an A record in the parent domain while having any record when doing an ALL record DNS query.

So my question is are we back to square one where every hostname is assumed to be a subdomain or is SpamFilter more intelligently determining that this host is not part of the bremen.de domain because it has not host A record?

I think in terms of how a common email system usually gets deployed. That's why I thought the "Check for MX record" should actually check the actual subdomain or domain and not assume everything to the right of the @ symbol is a subdomain or domain. 

Originally, SPF and some others thought this was cool because it means less DNS queries, less logic to process and better performance.  I feel, however, that this accuracy is more important than saving one DNS query if needed, when we're talking about rejecting someone's valuable communications. 

The underlying question is: When is a subdomain really a subdomain and when is it a host in a domain or valid subdomain? Or how do we validate a subdomain (in the name of improved accuracy)

Robert, we originally tried to define a domain as having an NS record. So, we would test everything to the right of the @ symbol to see if it had an NS record so we knew it was a domain, if not we dropped the host name and started after the first "." and assumed that was the domain or did the same check to see if it was a domain, until we had a valid domain.  

Here's a better way that seems to have always worked: Do a DNS ALL (ANY RECORD) Query against the substring. If it has ANY record than we can say it is a valid subdomain.  If not we need to drop the host name and either test the remaining string to validate that it's a subdomain or domain or assume that it must be a domain.  Obviously it would be most accurate to continue until we have validated the domain or subdomain and then check for SPF or MX record in the case of MX record checking feature.

OOPS!  CLARIFICATION OF "Here's a better way.."

If DNS ALL query returns an A record then we know it is NOT a subdomain, but a host in a domain so the domain needs to be determined and queried..  For example: http://www.idp.net - www.idp.net returns it's A host record when you do a DNS ALL (ANY) query and schulverwaltung.bremen.de returns an MX record when you do a DNS ALL(ANY) query and is NOT found as a host record, thus proving that it IS a subdomain.

-Matt R.