Mailing List Archive: SPF testing issues

SPF testing issues

Apr 18, 2005, 2:39 AM

Post #1 of 12 (5803 views)

Hello,

I am working on our own SPF (Classic,
http://spf.pobox.com/spf-draft-200406.txt) implementation and while I
was testing it using the SPF test package data (test_live.txt) from
libspf2, I got some odd results. Some tests were not passed and it
appears that it is not our code's fault -- at least it looks we
interpret the "standard" differently or I overlook something (e.g.
local policy, libspf2's implemented standard)

Can you confirm if I am wrong or correct about the issues below?

libspf2 version: 1.2.5

Issue 1)
--------
Command: spfquery -ip=192.0.2.1 -sender=05.spf1-test.mailzone.com
-helo=05.spf1-test.mailzone.com
Expected result: fail
Our result: neutral
SPF record: 05.spf1-test.mailzone.com TXT -> v=spf1 default=deny

As "default=deny" is an unknown modifier, our implementation silently
ignores it (SPF-C "3.2 SPF Directive Evaluation" paragraph 1). Because
no matching mechanism is found and there are no includes/redirectors,
we must return "neutral", according to SPF-C "3.3 Default result".

Issue 2)
--------
Command: spfquery -ip=192.0.2.200 -sender=56.spf1-test.mailzone.com
-helo=56.spf1-test.mailzone.com
Expected result: none
Our result: unknown
SPF record: - (got NXDOMAIN)

SPF-C section "2.2.2 Lookup" paragraph 4 says "If the domain does not
exist (NXDOMAIN), SPF clients MUST return >>unknown<<". There is no
parent domain TXT published, so the processing cannot fall back to the
parent domain (and it is not even supported by our implementation).

Issue 3)
--------
Command: spfquery -ip=64.236.24.4 -sender=80.spf1-test.mailzone.com
-helo=80.spf1-test.mailzone.com
Expected result: fail
Our result: PermError (would map to error/unknown)
SPF record: v=spf1 a mx
exists:%{ir}.%{v}._spf.80.spf1-test.mailzone.com ptr -all

The "a" mechanism does not match (80.spf1-test.mailzone.com A RR ->
208.210.124.180), so our code continues with the "mx" mechanism.
80.spf1-test.mailzone.com does not have an MX, so we terminate the
processing and return with error indicating a DNS problem. We
interpret section "3.2 SPF Directive Evaluation" paragraph "If it
throws an exception, mechanism processing ends and the exception value
is returned (either "error" indicating a temporary failure, usually
DNS-related, or "unknown" indicating a syntax error or other permanent
failure resulting in incomplete processing.)" the way that we should
terminate processing here. This sounds reasonable, because continuing
the evaluation may end up in rejecting email, due to a "-all".

A variation of this issue is "spfquery -ip=192.0.2.80
-sender=80.spf1-test.mailzone.com -helo=80.spf1-test.mailzone.com",
the same problem occurs.

Issue 4)
--------
Command: spfquery -ip=192.0.2.200 -sender=112.spf1-test.mailzone.com
-helo=112.spf1-test.mailzone.com
Expected result: unknown
Our result: pass
SPF record: v=spf1 a mp3 ~all

We get pass on "a" the mechnism, because 112.spf1-test.mailzone.com A
RR -> 192.0.2.200. While SPF-C section "3.2 SPF Directive Evaluation"
says that "Unknown mechanisms cause processing to abort with the
result >>unknown<<. Unknown modifiers are ignored by clients." and
"mp3" is certainly a mechanism, section "6.1 Unrecognized Mechanisms
and Modifiers" paragraph 2 says "Mechanisms listed before the unknown
mechanism MUST, however, be evaluated.".

A variation of this issue is "spfquery -ip=192.0.2.200
-sender=113.spf1-test.mailzone.com -helo=113.spf1-test.mailzone.com".

Issue 5)
--------
Command: spfquery -ip=192.0.2.200 -sender=115.spf1-test.mailzone.com
-helo=115.spf1-test.mailzone.com
Expected result: unknown
Our result: pass
SPF record: v=spf1 a mp3=yes -all

Unknown modifiers must be ignored. 115.spf1-test.mailzone.com A RR =
192.0.2.200, mechanism "a" matches with + implicit prefix, so we have
"pass".

It is the same with "spfquery -ip=1.2.3.4
-sender=115.spf1-test.mailzone.com -helo=115.spf1-test.mailzone.com",
except that we generate "fail" instead of "unknown".

Issue 6)
--------
Command: spfquery -ip=192.0.2.200 -sender=116.spf1-test.mailzone.com
-helo=116.spf1-test.mailzone.com
Expected result: fail
Our result: pass
SPF record: v=spf1 redirect=116rdr.spf1-test.mailzone.com a

"Redirect" is a global and singular modifier, it should be evaluated
after all mechanisms are evaluated without a match, so our code takes
"a" first. 116.spf1-test.mailzone.com A RR -> 192.0.2.200, so there is
no need to evaluate the "redirect" modifier. Section "5.1 redirect:
Redirected Query" says "If all mechanisms fail to match, and a
redirect modifier is present, then processing proceeds as follows.".

Peter

P.S.: Sorry for posting this to spf-devel, but I got no response to my
Libspf2 issue tracker submission (07/04).

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

Re: SPF testing issues [ In reply to ]

spf at metro

Apr 18, 2005, 7:20 AM

Post #2 of 12 (5684 views)

Permalink

Hi there,

You might want to look at this one instead:

http://www.ozonehouse.com/mark/spf/draft-lentczner-spf-00.txt

See also http://spf.pobox.com/rfcs.html

Sorry about not being more specific to your actual request, but you
might want to know that the spf classic draft has been superseded.

Koen

On Mon, Apr 18, 2005 at 11:39:46AM +0200, Peter Karsai wrote:
> Hello,
>
> I am working on our own SPF (Classic,
> http://spf.pobox.com/spf-draft-200406.txt) implementation and while I
> was testing it using the SPF test package data (test_live.txt) from
> libspf2, I got some odd results. Some tests were not passed and it
> appears that it is not our code's fault -- at least it looks we
> interpret the "standard" differently or I overlook something (e.g.
> local policy, libspf2's implemented standard)
>
> Can you confirm if I am wrong or correct about the issues below?
>
> libspf2 version: 1.2.5
>
>
> Issue 1)
> --------
> Command: spfquery -ip=192.0.2.1 -sender=05.spf1-test.mailzone.com
> -helo=05.spf1-test.mailzone.com
> Expected result: fail
> Our result: neutral
> SPF record: 05.spf1-test.mailzone.com TXT -> v=spf1 default=deny
>
> As "default=deny" is an unknown modifier, our implementation silently
> ignores it (SPF-C "3.2 SPF Directive Evaluation" paragraph 1). Because
> no matching mechanism is found and there are no includes/redirectors,
> we must return "neutral", according to SPF-C "3.3 Default result".
>
>
> Issue 2)
> --------
> Command: spfquery -ip=192.0.2.200 -sender=56.spf1-test.mailzone.com
> -helo=56.spf1-test.mailzone.com
> Expected result: none
> Our result: unknown
> SPF record: - (got NXDOMAIN)
>
> SPF-C section "2.2.2 Lookup" paragraph 4 says "If the domain does not
> exist (NXDOMAIN), SPF clients MUST return >>unknown<<". There is no
> parent domain TXT published, so the processing cannot fall back to the
> parent domain (and it is not even supported by our implementation).
>
>
> Issue 3)
> --------
> Command: spfquery -ip=64.236.24.4 -sender=80.spf1-test.mailzone.com
> -helo=80.spf1-test.mailzone.com
> Expected result: fail
> Our result: PermError (would map to error/unknown)
> SPF record: v=spf1 a mx
> exists:%{ir}.%{v}._spf.80.spf1-test.mailzone.com ptr -all
>
> The "a" mechanism does not match (80.spf1-test.mailzone.com A RR ->
> 208.210.124.180), so our code continues with the "mx" mechanism.
> 80.spf1-test.mailzone.com does not have an MX, so we terminate the
> processing and return with error indicating a DNS problem. We
> interpret section "3.2 SPF Directive Evaluation" paragraph "If it
> throws an exception, mechanism processing ends and the exception value
> is returned (either "error" indicating a temporary failure, usually
> DNS-related, or "unknown" indicating a syntax error or other permanent
> failure resulting in incomplete processing.)" the way that we should
> terminate processing here. This sounds reasonable, because continuing
> the evaluation may end up in rejecting email, due to a "-all".
>
> A variation of this issue is "spfquery -ip=192.0.2.80
> -sender=80.spf1-test.mailzone.com -helo=80.spf1-test.mailzone.com",
> the same problem occurs.
>
>
> Issue 4)
> --------
> Command: spfquery -ip=192.0.2.200 -sender=112.spf1-test.mailzone.com
> -helo=112.spf1-test.mailzone.com
> Expected result: unknown
> Our result: pass
> SPF record: v=spf1 a mp3 ~all
>
> We get pass on "a" the mechnism, because 112.spf1-test.mailzone.com A
> RR -> 192.0.2.200. While SPF-C section "3.2 SPF Directive Evaluation"
> says that "Unknown mechanisms cause processing to abort with the
> result >>unknown<<. Unknown modifiers are ignored by clients." and
> "mp3" is certainly a mechanism, section "6.1 Unrecognized Mechanisms
> and Modifiers" paragraph 2 says "Mechanisms listed before the unknown
> mechanism MUST, however, be evaluated.".
>
> A variation of this issue is "spfquery -ip=192.0.2.200
> -sender=113.spf1-test.mailzone.com -helo=113.spf1-test.mailzone.com".
>
>
> Issue 5)
> --------
> Command: spfquery -ip=192.0.2.200 -sender=115.spf1-test.mailzone.com
> -helo=115.spf1-test.mailzone.com
> Expected result: unknown
> Our result: pass
> SPF record: v=spf1 a mp3=yes -all
>
> Unknown modifiers must be ignored. 115.spf1-test.mailzone.com A RR =
> 192.0.2.200, mechanism "a" matches with + implicit prefix, so we have
> "pass".
>
> It is the same with "spfquery -ip=1.2.3.4
> -sender=115.spf1-test.mailzone.com -helo=115.spf1-test.mailzone.com",
> except that we generate "fail" instead of "unknown".
>
>
> Issue 6)
> --------
> Command: spfquery -ip=192.0.2.200 -sender=116.spf1-test.mailzone.com
> -helo=116.spf1-test.mailzone.com
> Expected result: fail
> Our result: pass
> SPF record: v=spf1 redirect=116rdr.spf1-test.mailzone.com a
>
> "Redirect" is a global and singular modifier, it should be evaluated
> after all mechanisms are evaluated without a match, so our code takes
> "a" first. 116.spf1-test.mailzone.com A RR -> 192.0.2.200, so there is
> no need to evaluate the "redirect" modifier. Section "5.1 redirect:
> Redirected Query" says "If all mechanisms fail to match, and a
> redirect modifier is present, then processing proceeds as follows.".
>
>
> Peter
>
> P.S.: Sorry for posting this to spf-devel, but I got no response to my
> Libspf2 issue tracker submission (07/04).
>
> -------
> To unsubscribe, change your address, or temporarily deactivate your subscription,
> please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

--
K.F.J. Martens, Sonologic, http://www.sonologic.nl/
Networking, hosting, embedded systems, unix, artificial intelligence.
Public PGP key: http://www.metro.cx/pubkey-gmc.asc
Wondering about the funny attachment your mail program
can't read? Visit http://www.openpgp.org/

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

Re: SPF testing issues [ In reply to ]

peter.karsai at gmail

Apr 18, 2005, 7:39 AM

Post #3 of 12 (5674 views)

Permalink

Hi Koen,

Thanks, I will review the issues according to your advice. This draft
is also expired by the way on April 12 :)

Any idea when SPF will go to RFC? I started writing our SPF
implementation last summer, with the goal to be compatible with
SPF-Classic and http://spf.pobox.com/draft-ietf-marid-protocol-00.txt.
Then we had to leave this feature out from the planned release,
because it did not seem to be a good idea to work with partially
incompatible standard versions.

From what I see, I expect many troubles with SPF clients, not just
because of the standard-compliance, but due to configuration issues.
If someone with a backup MX incorrectly configures his/her backup MX
list or forgets to update it, he will be subject to SPF fail's. I know
it sounds trivial, but can be expected.

Peter

On 4/18/05, Koen Martens <spf@metro.cx> wrote:
> Hi there,
>
> You might want to look at this one instead:
>
> http://www.ozonehouse.com/mark/spf/draft-lentczner-spf-00.txt
>
> See also http://spf.pobox.com/rfcs.html
>
> Sorry about not being more specific to your actual request, but you
> might want to know that the spf classic draft has been superseded.
>
> Koen
>
> On Mon, Apr 18, 2005 at 11:39:46AM +0200, Peter Karsai wrote:
> > Hello,
> >
> > I am working on our own SPF (Classic,
> > http://spf.pobox.com/spf-draft-200406.txt) implementation and while I
> > was testing it using the SPF test package data (test_live.txt) from
> > libspf2, I got some odd results. Some tests were not passed and it
> > appears that it is not our code's fault -- at least it looks we
> > interpret the "standard" differently or I overlook something (e.g.
> > local policy, libspf2's implemented standard)
> >
> > Can you confirm if I am wrong or correct about the issues below?
> >
> > libspf2 version: 1.2.5
> >
> >
> > Issue 1)
> > --------
> > Command: spfquery -ip=192.0.2.1 -sender=05.spf1-test.mailzone.com
> > -helo=05.spf1-test.mailzone.com
> > Expected result: fail
> > Our result: neutral
> > SPF record: 05.spf1-test.mailzone.com TXT -> v=spf1 default=deny
> >
> > As "default=deny" is an unknown modifier, our implementation silently
> > ignores it (SPF-C "3.2 SPF Directive Evaluation" paragraph 1). Because
> > no matching mechanism is found and there are no includes/redirectors,
> > we must return "neutral", according to SPF-C "3.3 Default result".
> >
> >
> > Issue 2)
> > --------
> > Command: spfquery -ip=192.0.2.200 -sender=56.spf1-test.mailzone.com
> > -helo=56.spf1-test.mailzone.com
> > Expected result: none
> > Our result: unknown
> > SPF record: - (got NXDOMAIN)
> >
> > SPF-C section "2.2.2 Lookup" paragraph 4 says "If the domain does not
> > exist (NXDOMAIN), SPF clients MUST return >>unknown<<". There is no
> > parent domain TXT published, so the processing cannot fall back to the
> > parent domain (and it is not even supported by our implementation).
> >
> >
> > Issue 3)
> > --------
> > Command: spfquery -ip=64.236.24.4 -sender=80.spf1-test.mailzone.com
> > -helo=80.spf1-test.mailzone.com
> > Expected result: fail
> > Our result: PermError (would map to error/unknown)
> > SPF record: v=spf1 a mx
> > exists:%{ir}.%{v}._spf.80.spf1-test.mailzone.com ptr -all
> >
> > The "a" mechanism does not match (80.spf1-test.mailzone.com A RR ->
> > 208.210.124.180), so our code continues with the "mx" mechanism.
> > 80.spf1-test.mailzone.com does not have an MX, so we terminate the
> > processing and return with error indicating a DNS problem. We
> > interpret section "3.2 SPF Directive Evaluation" paragraph "If it
> > throws an exception, mechanism processing ends and the exception value
> > is returned (either "error" indicating a temporary failure, usually
> > DNS-related, or "unknown" indicating a syntax error or other permanent
> > failure resulting in incomplete processing.)" the way that we should
> > terminate processing here. This sounds reasonable, because continuing
> > the evaluation may end up in rejecting email, due to a "-all".
> >
> > A variation of this issue is "spfquery -ip=192.0.2.80
> > -sender=80.spf1-test.mailzone.com -helo=80.spf1-test.mailzone.com",
> > the same problem occurs.
> >
> >
> > Issue 4)
> > --------
> > Command: spfquery -ip=192.0.2.200 -sender=112.spf1-test.mailzone.com
> > -helo=112.spf1-test.mailzone.com
> > Expected result: unknown
> > Our result: pass
> > SPF record: v=spf1 a mp3 ~all
> >
> > We get pass on "a" the mechnism, because 112.spf1-test.mailzone.com A
> > RR -> 192.0.2.200. While SPF-C section "3.2 SPF Directive Evaluation"
> > says that "Unknown mechanisms cause processing to abort with the
> > result >>unknown<<. Unknown modifiers are ignored by clients." and
> > "mp3" is certainly a mechanism, section "6.1 Unrecognized Mechanisms
> > and Modifiers" paragraph 2 says "Mechanisms listed before the unknown
> > mechanism MUST, however, be evaluated.".
> >
> > A variation of this issue is "spfquery -ip=192.0.2.200
> > -sender=113.spf1-test.mailzone.com -helo=113.spf1-test.mailzone.com".
> >
> >
> > Issue 5)
> > --------
> > Command: spfquery -ip=192.0.2.200 -sender=115.spf1-test.mailzone.com
> > -helo=115.spf1-test.mailzone.com
> > Expected result: unknown
> > Our result: pass
> > SPF record: v=spf1 a mp3=yes -all
> >
> > Unknown modifiers must be ignored. 115.spf1-test.mailzone.com A RR =
> > 192.0.2.200, mechanism "a" matches with + implicit prefix, so we have
> > "pass".
> >
> > It is the same with "spfquery -ip=1.2.3.4
> > -sender=115.spf1-test.mailzone.com -helo=115.spf1-test.mailzone.com",
> > except that we generate "fail" instead of "unknown".
> >
> >
> > Issue 6)
> > --------
> > Command: spfquery -ip=192.0.2.200 -sender=116.spf1-test.mailzone.com
> > -helo=116.spf1-test.mailzone.com
> > Expected result: fail
> > Our result: pass
> > SPF record: v=spf1 redirect=116rdr.spf1-test.mailzone.com a
> >
> > "Redirect" is a global and singular modifier, it should be evaluated
> > after all mechanisms are evaluated without a match, so our code takes
> > "a" first. 116.spf1-test.mailzone.com A RR -> 192.0.2.200, so there is
> > no need to evaluate the "redirect" modifier. Section "5.1 redirect:
> > Redirected Query" says "If all mechanisms fail to match, and a
> > redirect modifier is present, then processing proceeds as follows.".
> >
> >
> > Peter
> >
> > P.S.: Sorry for posting this to spf-devel, but I got no response to my
> > Libspf2 issue tracker submission (07/04).
> >
> > -------
> > To unsubscribe, change your address, or temporarily deactivate your subscription,
> > please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com
>
> --
> K.F.J. Martens, Sonologic, http://www.sonologic.nl/
> Networking, hosting, embedded systems, unix, artificial intelligence.
> Public PGP key: http://www.metro.cx/pubkey-gmc.asc
> Wondering about the funny attachment your mail program
> can't read? Visit http://www.openpgp.org/
>
> -------
> To unsubscribe, change your address, or temporarily deactivate your subscription,
> please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com
>

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

Re: SPF testing issues [ In reply to ]

nobody at xyzzy

Apr 18, 2005, 12:54 PM

Post #4 of 12 (5724 views)

Permalink

Koen Martens wrote:

> http://www.ozonehouse.com/mark/spf/draft-lentczner-spf-00.txt

That's expired, the actual (2005) draft is:

http://www.ietf.org/internet-drafts/draft-schlitt-spf-classic-00.txt

It's somewhat clearer than the Lentczner SPF draft in its error
handling - probably easier to implement, just ignore any "zone
cut" in the text, that will be removed in -01. 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

Re: SPF testing issues [ In reply to ]

nobody at xyzzy

Apr 18, 2005, 1:08 PM

Post #5 of 12 (5724 views)

Permalink

Peter Karsai wrote:

> Any idea when SPF will go to RFC?

Unclear, the SPF Council anounced draft -01 for the begin of
January and other dates (one last week), the draft author is
AWOL, the coauthor is MIA, it's a mess. As far as the IESG
is concerned the last state was this:

https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12662

> I know it sounds trivial, but can be expected.

Yes, you'd white list your backup MX, see 9.5 in Wayne's text.

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

Re: Re: SPF testing issues [ In reply to ]

spf at metro

Apr 19, 2005, 12:46 AM

Post #6 of 12 (5713 views)

Permalink

On Mon, Apr 18, 2005 at 09:54:31PM +0200, Frank Ellermann wrote:
> Koen Martens wrote:
>
> > http://www.ozonehouse.com/mark/spf/draft-lentczner-spf-00.txt
>
> That's expired, the actual (2005) draft is:
>
> http://www.ietf.org/internet-drafts/draft-schlitt-spf-classic-00.txt
>
> It's somewhat clearer than the Lentczner SPF draft in its error
> handling - probably easier to implement, just ignore any "zone
> cut" in the text, that will be removed in -01. Bye, Frank

Argh, that's the one i really wanted to mention of course, shows you how
big of a mess it has become with the standard :)

Anyway, http://spf.pobox.com/rfcs.html has the facts straight i
believe.. sort of..

Koen

--
K.F.J. Martens, Sonologic, http://www.sonologic.nl/
Networking, hosting, embedded systems, unix, artificial intelligence.
Public PGP key: http://www.metro.cx/pubkey-gmc.asc
Wondering about the funny attachment your mail program
can't read? Visit http://www.openpgp.org/

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

Re: SPF testing issues [ In reply to ]

nobody at xyzzy

Apr 19, 2005, 8:48 AM

Post #7 of 12 (5708 views)

Permalink

Koen Martens wrote:

> http://spf.pobox.com/rfcs.html has the facts straight i
> believe.. sort of..

I'm absolutely certain that it has the facts wrong, it says:

| Current SPF Protocol Specification:
| http://www.ozonehouse.com/mark/spf/draft-lentczner-spf-00.txt

Later on the same page it talks about "SPF classic" and the

| Schlitt draft of December 2004 updates that pecification. You
| should use that.

There are some real bugs in the expired draft-lentczner-spf-00.

Even if somebody plans to support sp2.0 scopes (s)he better
sticks to the Schlitt draft as amended by the SPF Council,
i.e. no more "zone cut".

The "SHOULD test helo-identity" instead of "MAY" is irrelevant
for spf2.0, neither PRA nor MAIL FROM (mfrom) cover HELO.

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

Re: Re: SPF testing issues [ In reply to ]

spf at metro

Apr 20, 2005, 1:11 AM

Post #8 of 12 (5702 views)

Permalink

Oh how i'd wish that site would be really really thoroughly checked and
updated sometime soon, including the change in
http://spf.pobox.com/contact_us.html i have asked for over and over. I
guess it will never happen, right?

Bit difficult pointing people to resources this way. Saying 'please read
spf.pobox.com and then come back if you have specific questions' as we
often do doesn't seem to be fair to the person requesting help anymore.

Koen

On Tue, Apr 19, 2005 at 05:48:26PM +0200, Frank Ellermann wrote:
> Koen Martens wrote:
>
> > http://spf.pobox.com/rfcs.html has the facts straight i
> > believe.. sort of..
>
> I'm absolutely certain that it has the facts wrong, it says:
>
> | Current SPF Protocol Specification:
> | http://www.ozonehouse.com/mark/spf/draft-lentczner-spf-00.txt
>
> Later on the same page it talks about "SPF classic" and the
>
> | Schlitt draft of December 2004 updates that pecification. You
> | should use that.
>
> There are some real bugs in the expired draft-lentczner-spf-00.
>
> Even if somebody plans to support sp2.0 scopes (s)he better
> sticks to the Schlitt draft as amended by the SPF Council,
> i.e. no more "zone cut".
>
> The "SHOULD test helo-identity" instead of "MAY" is irrelevant
> for spf2.0, neither PRA nor MAIL FROM (mfrom) cover HELO.
>
> 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

--
K.F.J. Martens, Sonologic, http://www.sonologic.nl/
Networking, hosting, embedded systems, unix, artificial intelligence.
Public PGP key: http://www.metro.cx/pubkey-gmc.asc
Wondering about the funny attachment your mail program
can't read? Visit http://www.openpgp.org/

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

Re: Re: SPF testing issues [ In reply to ]

peter.karsai at gmail

Apr 20, 2005, 2:07 AM

Post #9 of 12 (5730 views)

Permalink

Hi Frank,

> > Any idea when SPF will go to RFC?
>
> Unclear, the SPF Council anounced draft -01 for the begin of
> January and other dates (one last week), the draft author is
> AWOL, the coauthor is MIA, it's a mess. As far as the IESG
> is concerned the last state was this:
>
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12662

Thanks, I'll try to keep up with the recent drafts.

> > I know it sounds trivial, but can be expected.
>
> Yes, you'd white list your backup MX, see 9.5 in Wayne's text.

Yeah, but it is not always straightforward to get your backup MX'es
outbound IP addresses. Often the backup MX is the ISP's inbound
server, which relays the email to the primary MX via the ISP's regular
outbound architecture and there may have multiple outbound servers,
maybe on different subnets.

Based on my tech support experience, I expect several problems with
admins who enable SPF testing without a correctly set up exception
list (whitelist).

This is hardly SPF's fault, but I already got a few rejections due to this.

Peter

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

Re: Re: SPF testing issues [ In reply to ]

peter.karsai at gmail

Apr 20, 2005, 3:22 AM

Post #10 of 12 (5709 views)

Permalink

Hi,

I have one more question; are there any known compatibility issues
between draft-schlitt-spf-classic-00 and the original SPF Classic
spf-draft-200406?

The original SPF Classic and Marid-00
(http://spf.pobox.com/draft-ietf-marid-protocol-00.txt) were partially
incompatible with each other and the worst part of the multiple drafts
issue was that it was impossible to distinguish the SPF records
created according to the rules of one or another draft (all v=spf1),
so I had to make significant efforts to get our implementation work.

Peter

On 4/18/05, Frank Ellermann <nobody@xyzzy.claranet.de> wrote:
> Koen Martens wrote:
>
> > http://www.ozonehouse.com/mark/spf/draft-lentczner-spf-00.txt
>
> That's expired, the actual (2005) draft is:
>
> http://www.ietf.org/internet-drafts/draft-schlitt-spf-classic-00.txt
>
> It's somewhat clearer than the Lentczner SPF draft in its error
> handling - probably easier to implement, just ignore any "zone
> cut" in the text, that will be removed in -01. 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
>

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

Re: SPF testing issues [ In reply to ]

nobody at xyzzy

Apr 20, 2005, 7:55 AM

Post #11 of 12 (5700 views)

Permalink

Koen Martens wrote:

> Oh how i'd wish that site would be really really thoroughly
> checked and updated sometime soon, including the change in
> http://spf.pobox.com/contact_us.html i have asked for over
> and over.

The SPF Council also wanted this, at the moment this project
is somewhere in limbo between Meng and Julian.

> Bit difficult pointing people to resources this way.

ACK, the openspf and spf-tools pages are down, that "allowed"
me to reduce my SPF link collection to two XHTML lines below
<http://purl.net/xyzzy/bookmark.htm#Mail>

> Saying 'please read spf.pobox.com and then come back if you
> have specific questions' as we often do doesn't seem to be
> fair to the person requesting help anymore.

Not for implementors like Peter, but for ordinary users trying
to publish a sender policy it's still okay, if they are not
confused by the spf2.0/pra vs. v=spf1 issue.

Dp you still offer a validator ? Adding the limit 10 should
be easy if you don't have it yet.
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

Re: SPF testing issues [ In reply to ]

nobody at xyzzy

Apr 20, 2005, 9:01 AM

Post #12 of 12 (5717 views)

Permalink

Peter Karsai wrote:

> are there any known compatibility issues between
> draft-schlitt-spf-classic-00 and the original SPF Classic
> spf-draft-200406?

I've never done anything with the test suite, but I'd expect
that most unexpected results should be PermError / TempError
("classic") vs. Pass / Unknown / SoftFail / Fail ("original"),
because the "original" error handling was messy.

The "original" idea was to evaluate left to right until you
get a valid result or an error. It even allowed the idea of
"unknown mechanisms" - for obvious reasons a bad idea under
the same version v=spf1 or any spf2.0/xxx

The "original" spec. also had no clear processing limits, it
was more or less the decision of the receiver when to give up.
Messy if the same policy and sender sometimes work, but with
other receivers it would result in an error.

The "classic" limits are straight forward, more than 10 DNS
queries caused by a / mx / ptr / exists / include / redirect=
and you're out (PermError).

"Classic" syntax errors are also straight forward, unknown
modifiers foo=bar are okay, anything else that's unknown is a
PermError (e.g. unknown macros, unknown mechanisms, a missing
FQDN where it's required as in exists / include / redirect=,
etc.)

IMHO the ABNF plus examples are clear, only IPv6-stuff is a bit
obscure from my POV, and "dual-cidr" is also somewhat tricky.

So the main incompatibility will be (in draft -01) that the
"zone cut" stuff will be removed. Nothing changed for valid
working policies. In the worst case it never really worked
for all cases, and a "classic" implementation could return
PermError, see 4.6:

| Implementations MAY choose to parse the entire record first
| and return "PermError" if the record is not syntactically
| well formed. However, in all cases, any syntax errors
| anywhere in the record MUST be detected.

In other words you can still evaluate left-to-right, but you
MUST give up when you find garbage (excl. unknown modifiers).

One subtle difference between the Lentczner and Schlitt drafts
was the processing of a "domain literal" HELO [19.28,37.46] or
similar cases. Mark said "FAIL malformed FQDN" in this case,
which was a bad idea. Wayne uses FAIL strictly for something
in the found sender policy, and domain literals have no sender
policy.

Of course you are still free to reject any HELO [19.28.37.46],
especially if it comes from another IP, but that's then your
decision, a "receiver policy" and no "sender policy". Maybe
CSV has a proper SMTP error code for this case, but not SPF.

As you see the "incompatibilities" are obscure and odd cases.

> the worst part of the multiple drafts issue was that it was
> impossible to distinguish the SPF records created according
> to the rules of one or another draft (all v=spf1),

One very obvious case: spf2.0/pra IsNot v=spf1, for starters
both "PRA" and "IsNot" are pat. pend. MicroSoft "inventions".

spf2.0/mfrom is almost v=spf1, just don't check HELO/EHLO for
spf2.0/mfrom at the moment. But you still need the "classic"
postmaster@HELO trick for spf2.0/mfrom and MAIL FROM:<> cases.

If you plan to support spf2.0/mfrom (for about zero existing
policies of this type worldwide) don't forget spf2.0/pra,mfrom
and spf2.0/mfrom,pra etc.

If you only want v=spf1 you can forget spf2.0/mfrom for this
year (at least, maybe forever). One useful idea only existing
in spf2.0 are "positional modifiers", that's a modifier only
affecting the immediately preceding mechanism.

So far no positional sp2.0 modifiers exist, and of course you
would ignore all unknown modifiers, what- and whereever they
are. That's all about spf2.0, more new tricks would require a
spf2.1 or spf3.0 or v=spf2 or v=spf3. I don't see this in this
decade => forget it.
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