spf-discuss
[Top] [All Lists]

Re: Invalid SPF record for seznam.cz

2004-04-04 00:15:00
In <8028679(_at_)pamho(_dot_)net> "Roger Moser" 
<Roger(_dot_)Moser(_at_)pamho(_dot_)net> writes:

seznam.cz has following invalid SPF record: v=spf1 mx a:212.80.76.43 ~all

This type of error is pretty common.

Now should we be tolerant and accept "a:212.80.76.43" as "ip4:212.80.76.43",
or should we reject the whole record and return 'unknown'?

I guess in theory, there isn't anything preventing a "43"
top-level-domain from being created, so this could one day be a valid
host name.

Most SPF implementations that I'm aware of will try to look up the
"hostname" of 212.80.76.43, find it doesn't exist and move on.  This
is just like all other invalid hostnames, such as "a:mail".

Both Wechsler's PHP SPF implementation and libspf-alt v0.3 give a
warning about these constructs.  Libspf-alt will not flag it as an
error though, it will do the lookup as specified by the domain owner.

I, personally, have a lot of qualms about trying to guess what domain
owners really meant when they publish invalid SPF records.  There are
some SPF records which say "ipv4:1.2.3.4", some that say
"ip4=1.2.3.4", some that say "ip4:1.2.3/24" and a lot of others.  Many
SPF implementations try to make guesses about these kinds of things,
but no two SPF implementations make the same guesses about all
situations.  This has lead to the same SPF record meaning very
different things, depending on which SPF implementation is doing the
checking.  I think this makes things very bad and I think that the
domain owners would be better off getting consistant results.


This was discussed recently in the following thread:
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200403/0424.html
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200403/0428.html

I think that trying to silently(!) "do the right thing" leads to the
browser-compatibility-problem, which will require domain owners to
have to test their SPF records against many different implementations
to see how they will react.  I think SPF implementations *MUST* take
the approach of security systems, where strict validiation is done.

If an implementation wants to help the domain owner, I think it should
issue warnings, like the libspf-alt and PHP implementations.

The SPF record validators are a good thing, but most are available
only via web pages.  libspf-alt contains the spftest program that will
do the validiation via the command line, and can easily be extended to
be used in programs.  This kind of checking could be done when by
adding a plugin to bind to check the syntax of the SPF records when
the zone file is loaded.  Similarly, web DNS systems could check for
invalid SPF records.


Here is the result of the spftest program on the above questionable
SPF record:

(wayne(_at_)footbone) $ spftest spf "v=spf1 mx a:212.80.76.43 ~all"
SPF record in:  v=spf1 mx a:212.80.76.43 ~all
Warning: Invalid hostname (possibly an IP address?)
SPF header:  version: 1  mech 3/20  mod 0/0  len=24
SPF record:  v=spf1 mx a:212.80.76.43 ~all


Granted, this is not at all pretty, but the spftest program is really
just designed to test the libspf-alt system.




-wayne


<Prev in Thread] Current Thread [Next in Thread>