Mailing List Archive

Darryl L. Miles wrote:
> match_subdomains=yes parse error, spec says unknown keywords should be
> ignored ?
>
> I'm looking into trying to match all my host records and subdomain
> records for a given domain. One document I found said that the
> "match_subdomains=yes" keyword and value is the way to go. However I'm
> getting the impression from other research this WAS the way to go but
> has since been withdrawn.

There is no definite position on whether and how sub-domain
matching/processing/defaulting (whatever you want to call it, it has gone
by many names in the past) will be part of the final SPF specification.

The current preliminary position is that _no_ sub-domain defaulting
whatsoever will be part of the main SPF specification. There may be an
add-on specification that describes a "match_subdomains" or similar
modifier (still unclear).

It is true however that unknown _modifiers_ (as opposed to mechanisms)
should be ignored by the SPF checker.

> However when using SPF2 library I'm getting a library error back due to
> unknown tokens.

This is an error. Please report this as a bug to the makers of the
library.

> Does anyone have a web resourse which is the current definitive guide to
> the position of subdomain matching ? I'm looking for the history about
> the issue, what was tried, what was knocked down and why, and where the
> world currently is with solving this one, i.e. what should I do now ?

Many solutions have been proposed, including an automatic fallback to
parent domains (i.e. check "example.org" if "sub.example.org" does not
have an SPF record). But all of those have been abandoned for purposes of
the main SPF specification.

The long-term vision is for DNS servers to support a kind of advanced
wildcard (instead of the traditional "*" wildcard) that would allow SPF
records to be specified for whole domain hierarchies, and although DNS
experts are already discussing such a thing, this really is independent
from the SPF specification.

What you should do now heavily depends on your situation and your
requirements. If you elaborated on those, perhaps we can give more
specific advice.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Julian Mehnle wrote:

>>However when using SPF2 library I'm getting a library error back due to
>>unknown tokens.
>>
>>
>
>This is an error. Please report this as a bug to the makers of the
>library.
>
>
The URL http://www.libspf2.org/support.html indicates that this list is
the development list for the implementation I am running, I believe the
version I am using is libspf2-1.0.4. I get the following in my SPF headers:

unknown (mail.netbauds.net: error in processing during lookup of domain
of netbauds.net: Invalid character found) client-ip=217.yyy.31.xxx;
envelope-from=darryl@netbauds.net; helo=foobar.com; problem=Invalid
character found near "match" in "match_subdomains=yes";

Maybe its the underscore _ character it does not like ?


>What you should do now heavily depends on your situation and your
>requirements. If you elaborated on those, perhaps we can give more
>specific advice.
>
>
I host mailboxes and supply an authenticated SMTP relay for a number of
domains.


My own opinions on the matter would be summarised below:

* I'd be happy to add a few TXT records for the FQDN of all the inbound
and outbound mail handling machines (anything listed as MX, anything
used customer facing for POP3/IMAP/SMTP, anything used as outbound
client IP for egress mail routing). I have no problem adding TXT
records to FQDN hosts that concern my email intrastructure.

* I would not be happy to have to populate (and polute) all my customers
FQDN hosts, for example customers may have www.their-domain.com, I would
not be happy to add a TXT record just for that. This idea for me
personally is just undesirable, I'd rather live with the idea that SPF
becomes less of a comprehensive solution to the whole problem than deal
with making this aspect managable.

* I would be happy to add a single TXT record at the top of every valid
sub-domain in use, on the basis that a failed TXT lookup when dealing
with email from a ficticious address user@myhost.their-domain.com on
myhost.their-domain.com would then one more lookup for the subdomain it
is in "their-domain.com".

In the situation that host1.subdom1.subdom2.their-domain.com has a valid
record I would have no problem putting in a TXT record at these levels:

subdom1.subdom2.their-domain.com
subdom2.their-domain.com
their-domain.com

But do have a problem adding a record into every FQDN host entry at each
level. I can't see the strain on DNS being that high (when doing the
targets subdomain lookup) since in order to have looked up the TXT
record for host1.subdom1.subdom2.their-domain.com your local cache must
already know the NS record entries for subdom1.subdom2.their-domain.com
to then forward the following TXT record lookup on it. Two DNS queries
instead of one causes far less Internet traffic than a forwarded email.


I'm sure the matters been discussed enough already. Maybe the spf
website could be updated to educate us on the histroical arguments for
(and against) each of major the ideas that have been discussed surround
potentical flaws in the current design. Then maybe go on to include
current best practise to deal with those issues.

--
Darryl L. Miles


-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Darryl L. Miles wrote:
> The URL http://www.libspf2.org/support.html indicates that this list is
> the development list for the implementation I am running, I believe the
> version I am using is libspf2-1.0.4. I get the following in my SPF
> headers:
>
> unknown (mail.netbauds.net: error in processing during lookup of domain
> of netbauds.net: Invalid character found) client-ip=217.yyy.31.xxx;
> envelope-from=darryl@netbauds.net; helo=foobar.com; problem=Invalid
> character found near "match" in "match_subdomains=yes";
>
> Maybe its the underscore _ character it does not like ?

The current SPF specification draft[1] says (extract):

| Appendix A. Collected ABNF
|
| record = version terms *SP
| version = "v=spf1"
| terms = *( 1*SP ( directive / modifier ) )
| modifier = redirect / explanation / unknown-modifier
| unknown-modifier = name "=" macro-string
| macro-string = *( macro-expand / macro-literal )
| macro-literal = %x21-24 / %x26-7E
| ; visible characters except "%"

...which specifically includes the underscore (ASCII 0x5F). So the
underscore is allowed in modifier names, and the library is in error.

However, note that libspf2 1.0.4 has been outdated for quite a while.
Please try a newer version, such as 1.2.5.

> My own opinions on the matter would be summarised below:
> [...]
> * I would not be happy to have to populate (and polute) all my customers
> FQDN hosts, for example customers may have www.their-domain.com, I would
> not be happy to add a TXT record just for that. This idea for me
> personally is just undesirable, I'd rather live with the idea that SPF
> becomes less of a comprehensive solution to the whole problem than deal
> with making this aspect managable.
> [...]

Every domain/host name that has either an MX or an A record (yes, the
"implicit MX" rule sucks, but it is nothing the world can easily get rid
of) should also have an SPF record.

The solution to that is to use a programmable DNS server (e.g. supporting
advanced wildcard/macro mechanisms), or to use an external macro processor
(some have suggested m4) to generate the zone files.

> I'm sure the matters been discussed enough already. Maybe the spf
> website could be updated to educate us on the histroical arguments for
> (and against) each of major the ideas that have been discussed surround
> potentical flaws in the current design. Then maybe go on to include
> current best practise to deal with those issues.

It will; and be assured we are already working on a renewed website.

References:
1. http://www.schlitt.net/spf/spf_classic/draft-schlitt-spf-classic-00.txt

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

>However, note that libspf2 1.0.4 has been outdated for quite a while.
>Please try a newer version, such as 1.2.5.

None of the libspf2 1.2.x releases are functional. Currently the library
to use is libspf v1.0-RC6-pre6 (RC6 pre7-10 are also non-functional for a
variety of reasons). See the chart at http://www.acme.com/software/spfmilter/
which I update whenever a new version comes out.
---
Jef

Jef Poskanzer jef@acme.com http://www.acme.com/jef/

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Julian Mehnle wrote:

> This is an error. Please report this as a bug to the makers
> of the library.

It "should" be an error, if Wayne adopts this proposal:

|| Unrecognized modifiers SHOULD be ignored no matter where in
|| a record, nor how often.
|
| s/SHOULD/MUST/ or what else could be done in this case ?

OTOH I now see why he wrote "SHOULD". Apparently a serious
problem, if some implementations treat unknown modifiers as
error.
Bye, Frank


-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Jef Poskanzer wrote:
> > However, note that libspf2 1.0.4 has been outdated for quite a while.
> > Please try a newer version, such as 1.2.5.
>
> None of the libspf2 1.2.x releases are functional.

After talking to one of the libspf2 developers, I can say with confidence
that this is not true. spfmilter may not yet work with libspf2 1.2.x, but
generally, 1.2.x works ok.

> Currently the library to use is libspf v1.0-RC6-pre6 (RC6 pre7-10 are
> also non-functional for a variety of reasons). See the chart at
> http://www.acme.com/software/spfmilter/ which I update whenever a new
> version comes out.

On your website, it reads:

"libspf2: 1.2.x: No working version yet."

Could you please reword that as...

"libspf2: 1.2.x: Not currently supported by spfmilter."

? The current statement significantly misrepresents the current overall
status of libspf2.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

>After talking to one of the libspf2 developers, I can say with confidence
>that this is not true. spfmilter may not yet work with libspf2 1.2.x, but
>generally, 1.2.x works ok.

No. The problem has nothing to do with spfmilter. libspf2 1.2.x doesn't
even compile.
---
Jef

Jef Poskanzer jef@acme.com http://www.acme.com/jef/

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Jef Poskanzer wrote:
> > After talking to one of the libspf2 developers, I can say with
> > confidence that this is not true. spfmilter may not yet work with
> > libspf2 1.2.x, but generally, 1.2.x works ok.
>
> No. The problem has nothing to do with spfmilter. libspf2 1.2.x
> doesn't even compile.

Well, 1.2.5 does compile on my system.

Perhaps you could specify your problem.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com