Mailing List Archive

On Mon, Mar 31, 2008 at 03:55:58PM +0200, Stephan Seitz wrote:
> Hi listmembers,
>
> Recently, I found a few ISPs publishing their SPF records as
> IN TXT "\"v=spf1 .... \"" instead of
> IN TXT "v=spf1 .... "
>
> Currently our spf lib takes these records as invalid.
>
> My question is, should we silently ignore the double quotes?
>
> How would you act?

This, and similar issues, are always under debate.

See RFC 760, section 3.2, 1st paragraph.

I have to say I do disagree with this. Where does it end?
It is certainly possible that malformed input may seem to be
clear to me (my application) but in reality the sender had
something else in mind. Worse: syntactically correct input
may still not be what was intended.

If someone's record doesn't end in <prefix>"all", should I assume
the intention was "-all", or should I assume "?all" ?

If someone's record ends in "+all", should I assume the intention
was to publish "-all", or should I do as I'm asked to do?


How about v=spf1amx-all; should I assume this was intended to be
a valid policy, published as 4 separate parts, instead of one
part with spaces?
(thus: "v=spf1" "a" "mx" "-all" instead of "v=spf1 a mx -all")

Was "v=spf1mxhost=whatever" intended to be
"v=spf1 mx host=whatever" or "v=spf1 mxhost=whatever" ?

If you're going to ignore those quotes, are you also going to
accept stuff like:

"\"v=spf1 a mx:hostnamewhichISanMX; mx:othernamewhichISanMXbutalsoHASanMX; -every\""

and pretend it was:

"v=spf1 a a:hostnamewhichisanmx a:othernamewhichISanMXbutalsoHASanMX -all"

or

"v=spf1 a a:hostnamewhichisanmx mx:othernamewhichISanMXbutalsoHASanMX -all"

? Which one?


In my opinion the best way to help people publishing such records is
to reject mail. They will soon find out, and learn their mistakes.


Alex

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

Alex van den Bogaerdt wrote:

> See RFC 760, section 3.2, 1st paragraph.

Ugh, so far only Bruce Lilly and John Klensin got me with
RFCs older than 821. Have you checked that RFC 760 is the
oldest source for the robustness principle in RFCs ?

> If someone's record doesn't end in <prefix>"all", should
> I assume the intention was "-all", or should I assume
> "?all" ?

In that case RFC 4408 doesn't leave it to your imagnation.

> If someone's record ends in "+all", should I assume the
> intention was to publish "-all", or should I do as I'm
> asked to do?

Ditto, trying to outsmart others is often a recipe for
disaster. Of course there are unspecified special cases
in any non-trivial protocol, and say a gateway operator
not willing to outsmart others could be a public danger.

> How about v=spf1amx-all; should I assume this was
> intended to be a valid policy, published as 4 separate
> parts, instead of one part with spaces?
> (thus: "v=spf1" "a" "mx" "-all" instead of "v=spf1 a mx
> -all")

Explicitly mentioned in the specification, all plausible
trouble we could foresee. One of the points in RFC 4408
we can be proud of, IMO. With a few remaining problems
addressed in the test suite, including a very small set
of issues now noted as errata.

> In my opinion the best way to help people publishing
> such records is to reject mail. They will soon find out,
> and learn their mistakes.

+1 In a way SPF is a meta protocol, it talks about legit
or forged mail. By design SPF must be dangerous. That's
not the point where "be liberal" is a good idea. Legal
enforcement being liberal in whom they shoot would be bad.

Frank

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

On Mon, 31 Mar 2008, Stephan Seitz wrote:

> Recently, I found a few ISPs publishing their SPF records as
> IN TXT "\"v=spf1 .... \"" instead of
> IN TXT "v=spf1 .... "
>
> Currently our spf lib takes these records as invalid.
>
> My question is, should we silently ignore the double quotes?

Those are in fact, invalid records. The correct SPF result is None,
since there is no v=spf1 tag. (It is '"v=spf1' instead.)

> How would you act?

I have various heuristics to extract a "best guess" result from such
situations. Just be careful not to report it as the actual SPF result.
I use an x-bestguess tag in Received-SPF, for example:

2008Mar31 13:14:02 [6010] Received-SPF: None (mail.bmsi.com: 218.83.154.18
is neither permitted nor denied by domain of tastysoft.com)
client-ip=218.83.154.18; envelope-from="pre-alert@tastysoft.com";]
helo=tastysoft.com; receiver=mail.bmsi.com; mechanism=a/24;
x-bestguess=pass; identity=mailfrom

It might be worthwhile to remove the extra quotes to generate such
a bestguess result (for whitelisting and blacklisting by domain).

However, if the admin is so clueless as to leave the SPF record with invalid
quotes, the policy contained is likely to reflect equal cluelessness. So I
would not bother in this case (and just use the standard bestguess policy
of 'v=spf1 a/24 mx/24 ptr'. Unless you find that this kind of thing
is a typo that goes away in a few weeks for a given domain - then it would
be worthwhile to automate a best guess until it is fixed.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

On Mon, Mar 31, 2008 at 07:19:01PM +0200, Frank Ellermann wrote:
> Alex van den Bogaerdt wrote:
>
> > See RFC 760, section 3.2, 1st paragraph.
>
> Ugh, so far only Bruce Lilly and John Klensin got me with
> RFCs older than 821. Have you checked that RFC 760 is the
> oldest source for the robustness principle in RFCs ?

<g>

No, I haven't.

> > If someone's record doesn't end in <prefix>"all", should
> > I assume the intention was "-all", or should I assume
> > "?all" ?
>
> In that case RFC 4408 doesn't leave it to your imagnation.
>
> > If someone's record ends in "+all", should I assume the
> > intention was to publish "-all", or should I do as I'm
> > asked to do?

[snip: defaulting to ?all]
[snip: +all may be used wrong, but do so anyway]

> Ditto, trying to outsmart others is often a recipe for
> disaster.

Then the OP should assume "\"v=spf1 ... was intentional,
and thus not an SPF policy.

> > How about v=spf1amx-all; should I assume this was
> > intended to be a valid policy, published as 4 separate
> > parts, instead of one part with spaces?
> > (thus: "v=spf1" "a" "mx" "-all" instead of "v=spf1 a mx
> > -all")
>
> Explicitly mentioned in the specification, all plausible
> trouble we could foresee.

Is it? Where?

I have seen such a record in the wild, and the intention was to
publish one string with spaces, not four strings without spaces.
Of course the program doing SPF verification doesn't know this,
it just sees one string without spaces (the four concatenated).

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

Alex van den Bogaerdt wrote:

>> Ditto, trying to outsmart others is often a recipe for
>> disaster.

> Then the OP should assume "\"v=spf1 ... was intentional,
> and thus not an SPF policy.

Yep, we agree anyway about the outcome, I just looked which
of your examples are explicitly dealt with in RFC 4408.

>>> (thus: "v=spf1" "a" "mx" "-all" instead of "v=spf1 a mx
>>> -all")

>> Explicitly mentioned in the specification, all plausible
>> trouble we could foresee.

> Is it? Where?

3.1.3, multiple strings in a DNS record:

| IN TXT "v=spf1 .... first" "second string..."
| MUST be treated as equivalent to
| IN TXT "v=spf1 .... firstsecond string..."

Maybe not exactly your case, but close enough for readers to
get the idea.

Frank

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

On Mon, Mar 31, 2008 at 11:34:59PM +0200, Frank Ellermann wrote:

> > Is it? Where?
>
> 3.1.3, multiple strings in a DNS record:
>
> | IN TXT "v=spf1 .... first" "second string..."
> | MUST be treated as equivalent to
> | IN TXT "v=spf1 .... firstsecond string..."
>
> Maybe not exactly your case, but close enough for readers to
> get the idea.

Ah, that's what you ment. FWIW, I think 3.1.3 is written to prevent
the following from happening:

"v=spf1 a m" "x ptr ?all" -> "v=spf1 a m x ptr ?all".


My example, "v=spf1" "a" "mx" "-all", is somewhat different. Most
important is the fact that there's no space between v=spf1 and a.
People believing in the "be liberal in what you accept" filosophy
will still have to pretend they received "v=spf1 a mx -all".

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

On Mon, 31 Mar 2008, Alex van den Bogaerdt wrote:

> My example, "v=spf1" "a" "mx" "-all", is somewhat different. Most
> important is the fact that there's no space between v=spf1 and a.
> People believing in the "be liberal in what you accept" filosophy
> will still have to pretend they received "v=spf1 a mx -all".

You might accept the message to keep mail flowing, but the official
SPF result is still None. I suggest standardizing a Received-SPF tag for
heuristic results (and I have a long and growing list of them). I use
x-bestguess.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

Stuart D. Gathman wrote:

> I suggest standardizing a Received-SPF tag for heuristic
> results (and I have a long and growing list of them).
> I use x-bestguess.

For the Authentication-Results Murray invented a "policy"
flag (don't know his terminology by heart) for DKIM, and
I asked what that is, because there is no "policy" in the
DKIM spec., and if it's a general idea it could also make
sense for SPF among others. If you want it convince him,
so far "policy" is only for DKIM + ADSP, not SPF + PRA.

I've no problem with such ideas - as long as it is clear
downstream what's "guess" and what's "spec".

Frank

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

Hi,

thanks for your detailed discussion about this term.

I think the best way in handling obviously malformed SPF
records is generally to reject (say: ignore) them.
As you mentioned, "\"vspf=1 is NOT "vspf=1 and should not
be guessed to form a syntactical correct record.

I never thought about this earlier, but you're right saying
this could lead away from standards and weaken SPF at all.

Cheers,

Stephan


Frank Ellermann schrieb:
> Stuart D. Gathman wrote:
>
>> I suggest standardizing a Received-SPF tag for heuristic
>> results (and I have a long and growing list of them).
>> I use x-bestguess.
>
> For the Authentication-Results Murray invented a "policy"
> flag (don't know his terminology by heart) for DKIM, and
> I asked what that is, because there is no "policy" in the
> DKIM spec., and if it's a general idea it could also make
> sense for SPF among others. If you want it convince him,
> so far "policy" is only for DKIM + ADSP, not SPF + PRA.
>
> I've no problem with such ideas - as long as it is clear
> downstream what's "guess" and what's "spec".
>
> Frank
>
> -------------------------------------------
> Sender Policy Framework: http://www.openspf.org
> Modify Your Subscription: http://www.listbox.com/member/
> Archives: http://www.listbox.com/member/archive/735/=now
> RSS Feed: http://www.listbox.com/member/archive/rss/735/
> Powered by Listbox: http://www.listbox.com


--
Stephan Seitz
Senior System Administrator

*netz-haut* e.K.
multimediale kommunikation

zweierweg 22
97074 würzburg

fon: +49 931 2876247
fax: +49 931 2876248

web: www.netz-haut.de <http://www.netz-haut.de/>

registriergericht: amtsgericht würzburg, hra 5054

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com