Mailing List Archive: SPF: Help

mx: mechanism being used like a: mechanism?

1 2

View All

Index | Next | Previous | View Threaded

cfrankb at gmail

Jan 19, 2007, 9:42 AM

Post #1 of 38 (10288 views)
Permalink

mx: mechanism being used like a: mechanism?

In the following spf1 record for concierge3.boomerang.com.

"v=spf1 ptr a:concierge3.boomerang.com mx:mail.boomerang.com
mx:catbert.boomerang.com mx:sally.boomerang.com ip4:199.242.204.0/24
?all"

it appears the mx: mechanism is being used as if it were the a:
mechanism because the three mx: domains specified don't have MX
records.

I let boomerang.com know but they don't see a problem; they replied:

> This should allay your concerns of invalid SPF.
> The following shows no parsing failures at all:
http://www.dnsreport.com/tools/spf.ch?server=xxxxxx%40boomerang.com&ip=199.242.204.96

So I replied:
Try http://www.vamsoft.com/spfcheck.asp
using IP address 199.242.204.96
and email address whatever [at] concierge3
Then click "Check" and "Show/Hide Log"

__

Am I wrong?

Is the DNSReport.com parser wrong by giving a "Pass" instead of "SPF Uknown" ?

Thanks,
Frank

-------
Archives at http://archives.listbox.com/spf-help/current/ or
http://www.gossamer-threads.com/lists/spf/help/ (easier to search)
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?member_id=1311530&user_secret=5f6145ca

Dan_Mitton at Notes

Jan 19, 2007, 10:26 AM

Post #2 of 38 (10157 views)
Permalink

Re: mx: mechanism being used like a: mechanism? [In reply to]

I'm kind of new to this, but it seems to me like pass is correct. If you
use spfquery to check, it returns:

bash-2.03# spfquery --scope mfrom --id foo [at] concierge3 --ip
199.242.204.96
pass
concierge3.boomerang.com: 199.242.204.96 is authorized to use
'foo [at] concierge3' in 'mfrom' identity (mechanism
'ip4:199.242.204.0/24' matched)
concierge3.boomerang.com: 199.242.204.96 is authorized to use
'foo [at] concierge3' in 'mfrom' identity (mechanism
'ip4:199.242.204.0/24' matched)
Received-SPF: pass (concierge3.boomerang.com: 199.242.204.96 is authorized
to use 'foo [at] concierge3' in 'mfrom' identity (mechanism
'ip4:199.242.204.0/24' matched)) receiver=smtp1.ymp.gov; identity=mfrom;
envelope-from="foo [at] concierge3"; client-ip=199.242.204.96

notice that the mechanism that matched is 'ip4:199.242.204.0/24', which is
certainly correct.

Please respond to spf-help [at] v2

To: spf-help [at] v2
cc: (bcc: Dan Mitton/YD/RWDOE)
Subject: [spf-help] mx: mechanism being used like a: mechanism?
LSN: Not Relevant
User Filed as: Not a Record

In the following spf1 record for concierge3.boomerang.com.

"v=spf1 ptr a:concierge3.boomerang.com mx:mail.boomerang.com
mx:catbert.boomerang.com mx:sally.boomerang.com ip4:199.242.204.0/24
?all"

it appears the mx: mechanism is being used as if it were the a:
mechanism because the three mx: domains specified don't have MX
records.

I let boomerang.com know but they don't see a problem; they replied:

> This should allay your concerns of invalid SPF.
> The following shows no parsing failures at all:
http://www.dnsreport.com/tools/spf.ch?server=xxxxxx%40boomerang.com&ip=199.242.204.96

So I replied:
Try http://www.vamsoft.com/spfcheck.asp
using IP address 199.242.204.96
and email address whatever [at] concierge3
Then click "Check" and "Show/Hide Log"

__

Am I wrong?

Is the DNSReport.com parser wrong by giving a "Pass" instead of "SPF
Uknown" ?

Thanks,
Frank

-------
Archives at http://archives.listbox.com/spf-help/current/ or
http://www.gossamer-threads.com/lists/spf/help/ (easier to search)
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?&

-------
Archives at http://archives.listbox.com/spf-help/current/ or
http://www.gossamer-threads.com/lists/spf/help/ (easier to search)
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?member_id=1311530&user_secret=5f6145ca

steve at teamITS

Jan 19, 2007, 10:30 AM

Post #3 of 38 (10164 views)
Permalink

RE: mx: mechanism being used like a: mechanism? [In reply to]

Charles Franklin Bernard <mailto:cfrankb [at] gmail> wrote on Friday,
January 19, 2007 11:43 AM:

> In the following spf1 record for concierge3.boomerang.com.
>
> "v=spf1 ptr a:concierge3.boomerang.com mx:mail.boomerang.com
> mx:catbert.boomerang.com mx:sally.boomerang.com ip4:199.242.204.0/24
> ?all"
>
> it appears the mx: mechanism is being used as if it were the a:
> mechanism because the three mx: domains specified don't have MX
> records.

Your analysis is correct. Also see
http://www.openspf.org/FAQ/Common_mistakes.

>> The following shows no parsing failures at all:
>
http://www.dnsreport.com/tools/spf.ch?server=xxxxxx%40boomerang.com&ip=1
99.242.204.96

Technically here they would pull the record for @boomerang.com
not @concierge3.boomerang.com but the two are identical it looks like.

> So I replied:
> Try http://www.vamsoft.com/spfcheck.asp
> using IP address 199.242.204.96
> and email address whatever [at] concierge3
> Then click "Check" and "Show/Hide Log"

> Is the DNSReport.com parser wrong by giving a "Pass" instead of "SPF
> Uknown" ?

I believe the correct answer is PermError since there is no MX
for those domains, as you said. Perhaps Scott or someone can verify
this...

Interestingly, http://www.openspf.org/Why and Scott's testing
tool http://www.openspf.org/Tools show no syntax errors either? Could
they be resolving the MX for "mail.boomerang.com" etc. down to the MX
for "boomerang.com" ---which IIRC that's how mail to
...@mail.boomerang.com would be (attempted to be) delivered? Or perhaps
on the DNSReport and Why tools the "ptr" mechanism is causing
199.242.204.96 (dumbo.boomerang.com) to be evaluated as a Pass before
the rest are being checked?

-----
SPF FAQ: http://www.openspf.org/FAQ
Common mistakes: http://www.openspf.org/FAQ/Common_mistakes

- Steve Yates
- ITS, Inc.
- BUFFERS=20 FILES=15 2nd down, 4th quarter, 5 yards to go!

~ Taglines by Taglinator - www.srtware.com ~

-------
Archives at http://archives.listbox.com/spf-help/current/ or
http://www.gossamer-threads.com/lists/spf/help/ (easier to search)
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?member_id=1311530&user_secret=5f6145ca

cfrankb at gmail

Jan 19, 2007, 10:40 AM

Post #4 of 38 (10153 views)
Permalink

Re: mx: mechanism being used like a: mechanism? [In reply to]

In what order MUST the spf parsers process the mechanisms (by
mechanism type, or left-to-right, or right-to-left), and can they stop
parsing on a match or MUST they continue trying to parse more
mechanisms?

If the IP address is permitted by one mechanisms but another mechanism
has a syntax error (e.g., references a record that does not exist, or
has a space after the colon), then MUST the spf parsers return "SPF
Unknown"?
And regardless of MUST vs. SHOULD vs. MAY, are there spf parsers
already in widespread use that would return "SPF Unknown" instead of
"Pass" due to a syntax error anywhere in the record?

-------
Archives at http://archives.listbox.com/spf-help/current/ or
http://www.gossamer-threads.com/lists/spf/help/ (easier to search)
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?member_id=1311530&user_secret=5f6145ca

alex at ergens

Jan 19, 2007, 10:50 AM

Post #5 of 38 (10163 views)
Permalink

Re: mx: mechanism being used like a: mechanism? [In reply to]

On Fri, Jan 19, 2007 at 10:40:31AM -0800, Charles Franklin Bernard wrote:
> In what order MUST the spf parsers process the mechanisms (by
> mechanism type, or left-to-right, or right-to-left), and can they stop
> parsing on a match or MUST they continue trying to parse more
> mechanisms?

Always evaluate left to right (start to end).

This is necessary to do for instance:

+ip4:192.0.2.1 -ip4:192.0.2.0/24

If you'd process right to left, you'd find -ip4:192.0.2.0/24 first,
and not authorize 192.0.2.1; this is clearly wrong.

*Can* they stop parsing after a match: yes. This means some parsers
will return "PASS", others may return "HardError".

> If the IP address is permitted by one mechanisms but another mechanism
> has a syntax error (e.g., references a record that does not exist, or
> has a space after the colon), then MUST the spf parsers return "SPF
> Unknown"?

Syntax errors result in an error, not in an unknown !

> And regardless of MUST vs. SHOULD vs. MAY, are there spf parsers
> already in widespread use that would return "SPF Unknown" instead of
> "Pass" due to a syntax error anywhere in the record?

I hope not.

-------
Archives at http://archives.listbox.com/spf-help/current/ or
http://www.gossamer-threads.com/lists/spf/help/ (easier to search)
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?member_id=1311530&user_secret=5f6145ca

cfrankb at gmail

Jan 19, 2007, 10:58 AM

Post #6 of 38 (10138 views)
Permalink

Re: mx: mechanism being used like a: mechanism? [In reply to]

> > And regardless of MUST vs. SHOULD vs. MAY, are there spf parsers
> > already in widespread use that would return "SPF Unknown" instead of
> > "Pass" due to a syntax error anywhere in the record?
>
> I hope not.

And if I wrote "error" instead of "SPF Uknown"?

-------
Archives at http://archives.listbox.com/spf-help/current/ or
http://www.gossamer-threads.com/lists/spf/help/ (easier to search)
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?member_id=1311530&user_secret=5f6145ca

alex at ergens

Jan 19, 2007, 11:17 AM

Post #7 of 38 (10151 views)
Permalink

Re: mx: mechanism being used like a: mechanism? [In reply to]

On Fri, Jan 19, 2007 at 10:58:17AM -0800, Charles Franklin Bernard wrote:
> >> And regardless of MUST vs. SHOULD vs. MAY, are there spf parsers
> >> already in widespread use that would return "SPF Unknown" instead of
> >> "Pass" due to a syntax error anywhere in the record?
> >
> >I hope not.
>
> And if I wrote "error" instead of "SPF Uknown"?

Then I don't know. It is certainly allowed, but I don't know if there
are such parsers actually in use.

-------
Archives at http://archives.listbox.com/spf-help/current/ or
http://www.gossamer-threads.com/lists/spf/help/ (easier to search)
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?member_id=1311530&user_secret=5f6145ca

cfrankb at gmail

Jan 19, 2007, 11:29 AM

Post #8 of 38 (10152 views)
Permalink

Re: mx: mechanism being used like a: mechanism? [In reply to]

> ...I don't know if there are such parsers actually in use.

I use Vamsoft's ORF Enterprise Edition. Their homepage shows ORF has
checked over 377 million messages for customers (those who opted to
send them stats) in the past 24 hours but doesn't indicate how many
had SPF checking enabled.

http://www.vamsoft.com/spfcheck.asp
returns:
SPF policy evaluation finished with SPF Unknown.
The requested A/MX record was not found for "mail.boomerang.com".

I can request Vamsoft change "SPF Unknown" to "error."
Is there a specific error preference such as "PermError" or "HardError"?

-------
Archives at http://archives.listbox.com/spf-help/current/ or
http://www.gossamer-threads.com/lists/spf/help/ (easier to search)
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?member_id=1311530&user_secret=5f6145ca

scott at kitterman

Jan 19, 2007, 11:30 AM

Post #9 of 38 (10161 views)
Permalink

Re: mx: mechanism being used like a: mechanism? [In reply to]

On Friday 19 January 2007 14:17, Alex van den Bogaerdt wrote:
> On Fri, Jan 19, 2007 at 10:58:17AM -0800, Charles Franklin Bernard wrote:
> > >> And regardless of MUST vs. SHOULD vs. MAY, are there spf parsers
> > >> already in widespread use that would return "SPF Unknown" instead of
> > >> "Pass" due to a syntax error anywhere in the record?
> > >
> > >I hope not.
> >
> > And if I wrote "error" instead of "SPF Uknown"?
>
> Then I don't know. It is certainly allowed, but I don't know if there
> are such parsers actually in use.

A couple of points here...

In the pre-IETF specs if there was a syntax error in the record, the result
was called unknown (Mail::SPF::Query and many other implementations still use
this). This is now called permerror (short for permanent error).

The relevant RFC 4408 point is here:

http://www.openspf.org/RFC_4408#evaluation

"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."

Any parser that returned Pass would be wrong.

Scott K

-------
Archives at http://archives.listbox.com/spf-help/current/ or
http://www.gossamer-threads.com/lists/spf/help/ (easier to search)
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?member_id=1311530&user_secret=5f6145ca

scott at kitterman

Jan 19, 2007, 11:31 AM

Post #10 of 38 (10140 views)
Permalink

Re: mx: mechanism being used like a: mechanism? [In reply to]

On Friday 19 January 2007 14:29, Charles Franklin Bernard wrote:

> I can request Vamsoft change "SPF Unknown" to "error."
> Is there a specific error preference such as "PermError" or "HardError"?
>
You really ought to read RFC 4408 I think.

http://www.openspf.org/RFC_4408

Scott K

-------
Archives at http://archives.listbox.com/spf-help/current/ or
http://www.gossamer-threads.com/lists/spf/help/ (easier to search)
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?member_id=1311530&user_secret=5f6145ca

steve at teamITS

Jan 19, 2007, 11:38 AM

Post #11 of 38 (10144 views)
Permalink

RE: mx: mechanism being used like a: mechanism? [In reply to]

Scott Kitterman <mailto:scott [at] kitterman> wrote on Friday, January
19, 2007 1:30 PM:

> "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."
>
> Any parser that returned Pass would be wrong.

I would argue that syntactically "mx:mail.boomerang.com" is
valid (as opposed to, say, "mx:1.2.3.4" or mx:mail"), however logically
there is no MX for mail.boomerang.com. How come your tester doesn't
detect that? :)

-----
SPF FAQ: http://www.openspf.org/FAQ
Common mistakes: http://www.openspf.org/FAQ/Common_mistakes

- Steve Yates
- ITS, Inc.
- "My guitar is broken," Tom fretted.

~ Taglines by Taglinator - www.srtware.com ~

-------
Archives at http://archives.listbox.com/spf-help/current/ or
http://www.gossamer-threads.com/lists/spf/help/ (easier to search)
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?member_id=1311530&user_secret=5f6145ca

alex at ergens

Jan 19, 2007, 11:44 AM

Post #12 of 38 (10158 views)
Permalink

Re: mx: mechanism being used like a: mechanism? [In reply to]

On Fri, Jan 19, 2007 at 02:30:03PM -0500, Scott Kitterman wrote:

> "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."
>
> Any parser that returned Pass would be wrong.

Scott is right; I stand corrected.

-------
Archives at http://archives.listbox.com/spf-help/current/ or
http://www.gossamer-threads.com/lists/spf/help/ (easier to search)
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?member_id=1311530&user_secret=5f6145ca

cfrankb at gmail

Jan 19, 2007, 11:46 AM

Post #13 of 38 (10157 views)
Permalink

Re: mx: mechanism being used like a: mechanism? [In reply to]

> http://www.openspf.org/RFC_4408

OK, PermError should be now be used instead of Unknown or HardFail.

But the other option of TempError:
http://www.openspf.org/RFC_4408#op-result-temperror.

What is a "transient error"? Does that mean the full TXT record was
not returned to be parsed?

-------
Archives at http://archives.listbox.com/spf-help/current/ or
http://www.gossamer-threads.com/lists/spf/help/ (easier to search)
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?member_id=1311530&user_secret=5f6145ca

cfrankb at gmail

Jan 19, 2007, 11:55 AM

Post #14 of 38 (10145 views)
Permalink

Re: mx: mechanism being used like a: mechanism? [In reply to]

> PermError should be now be used instead of Unknown or HardFail.

BTW, I meant HardError, not the -all HardFail.

-------
Archives at http://archives.listbox.com/spf-help/current/ or
http://www.gossamer-threads.com/lists/spf/help/ (easier to search)
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?member_id=1311530&user_secret=5f6145ca

alex at ergens

Jan 19, 2007, 11:59 AM

Post #15 of 38 (10139 views)
Permalink

Re: mx: mechanism being used like a: mechanism? [In reply to]

On Fri, Jan 19, 2007 at 11:29:49AM -0800, Charles Franklin Bernard wrote:

> http://www.vamsoft.com/spfcheck.asp
> returns:
> SPF policy evaluation finished with SPF Unknown.
> The requested A/MX record was not found for "mail.boomerang.com".

The list of MX resource records at domain mail.boomerang.com is empty.
mx:mail.boomerang.com will loop through all of the returned answers
('all' being zero) and thus do nothing.

I don't think this is an error; it's just a waste of resources.

If this is indeed correct, record evaluation should continue with
the next mechanism.

"
Several mechanisms rely on information fetched from DNS. For these
DNS queries, except where noted, if the DNS server returns an error
(RCODE other than 0 or 3) or the query times out, the mechanism
throws the exception "TempError". If the server returns "domain does
not exist" (RCODE 3), then evaluation of the mechanism continues as
if the server returned no error (RCODE 0) and zero answer records.
"

Scott will chime in if I got it wrong again. If that happens, I'll
quit for today :(

Alex

-------
Archives at http://archives.listbox.com/spf-help/current/ or
http://www.gossamer-threads.com/lists/spf/help/ (easier to search)
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?member_id=1311530&user_secret=5f6145ca

cfrankb at gmail

Jan 19, 2007, 12:20 PM

Post #16 of 38 (10153 views)
Permalink

Re: mx: mechanism being used like a: mechanism? [In reply to]

FWIW, every week my log shows yet another domain using the mx:
mechanism to state a domain that has no MX records. Boomerang knows
they have no MX records for those domains and that's the way they want
it. But I think they are expecting the mx: mechanism to act like the
a: mechanism.
I suspect most everyone else wrongly thinks mx: merely denotes the
full names of their Mail eXchangers rather than domains which have MX
records to include.

-------
Archives at http://archives.listbox.com/spf-help/current/ or
http://www.gossamer-threads.com/lists/spf/help/ (easier to search)
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?member_id=1311530&user_secret=5f6145ca

cfrankb at gmail

Jan 19, 2007, 1:22 PM

Post #17 of 38 (10155 views)
Permalink

Re: mx: mechanism being used like a: mechanism? [In reply to]

I forgot to add that Boomerang also replied:

"Please note, I've already consulted Wayne, one of the authors of
RFC4408 (SPF Specification), on this point. If you have issue with
the way these records are implemented, then I suggest you contact
wayne <wayne [at] schlitt> and voice your issue towards the RFC4408
draft as the way they are set up is the only way to set them up based
on that draft."

-------
Archives at http://archives.listbox.com/spf-help/current/ or
http://www.gossamer-threads.com/lists/spf/help/ (easier to search)
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?member_id=1311530&user_secret=5f6145ca

scott at kitterman

Jan 19, 2007, 1:52 PM

Post #18 of 38 (10146 views)
Permalink

Re: mx: mechanism being used like a: mechanism? [In reply to]

On Friday 19 January 2007 16:22, Charles Franklin Bernard wrote:
> I forgot to add that Boomerang also replied:
>
> "Please note, I've already consulted Wayne, one of the authors of
> RFC4408 (SPF Specification), on this point. If you have issue with
> the way these records are implemented, then I suggest you contact
> wayne <wayne [at] schlitt> and voice your issue towards the RFC4408
> draft as the way they are set up is the only way to set them up based
> on that draft."

I agree that mx:mailserver.example.com is not a syntax error. It's just not
going to do what they want. I thought that my validator would warn about
this (it used to). You might see what it says:

http://www.kitterman.com/spf/validate.html

Is it doesn't warn on that (Ambiguity warning is what it should say), let me
know and I'll work on fixing it.

Scott K

-------
Archives at http://archives.listbox.com/spf-help/current/ or
http://www.gossamer-threads.com/lists/spf/help/ (easier to search)
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?member_id=1311530&user_secret=5f6145ca

cfrankb at gmail

Jan 19, 2007, 2:00 PM

Post #19 of 38 (10158 views)
Permalink

Re: mx: mechanism being used like a: mechanism? [In reply to]

> http://www.kitterman.com/spf/validate.html
>
> Is it doesn't warn on that (Ambiguity warning is what it should say),
> let me know and I'll work on fixing it.

"
Input accepted, querying now...
evaluating v=spf1 ptr a:concierge3.boomerang.com mx:mail.boomerang.com
mx:catbert.boomerang.com mx:sally.boomerang.com ip4:199.242.204.0/24
?all ...
Results - record processed without error.

The result of the test (this should be the default result of your
record) was, ambiguous . The explanation returned was, SPF Ambiguity
Warning: No A records found for:
70-91-79-102-washingtondc.hfc.comcastbusiness.net
"

So there is *an* ambiguity warning, but I don't understand it yet.

-------
Archives at http://archives.listbox.com/spf-help/current/ or
http://www.gossamer-threads.com/lists/spf/help/ (easier to search)
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?member_id=1311530&user_secret=5f6145ca

steve at teamITS

Jan 19, 2007, 2:00 PM

Post #20 of 38 (10162 views)
Permalink

RE: mx: mechanism being used like a: mechanism? [In reply to]

Scott Kitterman <mailto:scott [at] kitterman> wrote on Friday, January
19, 2007 3:52 PM:

> I agree that mx:mailserver.example.com is not a syntax error. It's
just not
> going to do what they want. I thought that my validator would warn
about
> this (it used to). You might see what it says:
>
> http://www.kitterman.com/spf/validate.html
>
> Is it doesn't warn on that (Ambiguity warning is what it should say),
let me
> know and I'll work on fixing it.

The tests give different results!

1) (for boomerang.com)
Does my domain already have an SPF record? What is it? Is it valid?
"evaluating...
SPF record passed validation test with pySPF (Python SPF library)!"

2) Is this SPF record valid - syntactically correct?
- boomerang.com
- v=spf1 ptr a:concierge3.boomerang.com mx:mail.boomerang.com
mx:catbert.boomerang.com mx:sally.boomerang.com ip4:199.242.204.0/24
?all

"The result of the test (this should be the default result of your
record) was, ambiguous . The explanation returned was, SPF Ambiguity
Warning: No A records found for:
70-91-79-102-washingtondc.hfc.comcastbusiness.net"
(I'm guessing it didn't get as far as the mx: items? Not sure where the
Comcast address came from as that's not me)

3) Test an SPF record
Mail sent from: 199.242.204.96
Mail from (Sender): xxxx [at] boomerang
Mail checked using this SPF policy: v=spf1 ptr
a:concierge3.boomerang.com mx:mail.boomerang.com
mx:catbert.boomerang.com mx:sally.boomerang.com ip4:199.242.204.0/24
?all
Results - PASS sender SPF authorized

-----
SPF FAQ: http://www.openspf.org/FAQ
Common mistakes: http://www.openspf.org/FAQ/Common_mistakes

- Steve Yates
- ITS, Inc.
- No, really! I watch "Baywatch" for the plot!

~ Taglines by Taglinator - www.srtware.com ~

-------
Archives at http://archives.listbox.com/spf-help/current/ or
http://www.gossamer-threads.com/lists/spf/help/ (easier to search)
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?member_id=1311530&user_secret=5f6145ca

cfrankb at gmail

Jan 19, 2007, 2:19 PM

Post #21 of 38 (10172 views)
Permalink

Re: mx: mechanism being used like a: mechanism? [In reply to]

> http://www.openspf.org/RFC_4408#evaluation
>
> "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."
>
> Any parser that returned Pass would be wrong.
.
.
.
> I agree that mx:mailserver.example.com is not a syntax error.
> It's just not going to do what they want.

I'm confused; are we saying that SPF parsers in this case can legally
return either a PermError or a Pass with a warning?

-------
Archives at http://archives.listbox.com/spf-help/current/ or
http://www.gossamer-threads.com/lists/spf/help/ (easier to search)
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?member_id=1311530&user_secret=5f6145ca

scott at kitterman

Jan 19, 2007, 2:32 PM

Post #22 of 38 (10158 views)
Permalink

Re: mx: mechanism being used like a: mechanism? [In reply to]

On Friday 19 January 2007 17:19, Charles Franklin Bernard wrote:
> > http://www.openspf.org/RFC_4408#evaluation
> >
> > "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."
> >
> > Any parser that returned Pass would be wrong.
>
> .
> .
> .
>
> > I agree that mx:mailserver.example.com is not a syntax error.
> > It's just not going to do what they want.
>
> I'm confused; are we saying that SPF parsers in this case can legally
> return either a PermError or a Pass with a warning?
>
If some uses mx:mumble in their SPF record and mumble has no mx records, the
mechanism can never match, but (as long as mumble is a fully qualified domain
name) it won't raise an error.

If there were a syntax error in the record (e.g. ipv4:1.2.3.4 - note that the
mechanism is ip4, not ipv4) then any record that returned anything other than
permerror (or unknown in the old parlance) would be wrong. MX, but no MX
records is not a syntax error, it'll just never match.

Scott K

-------
Archives at http://archives.listbox.com/spf-help/current/ or
http://www.gossamer-threads.com/lists/spf/help/ (easier to search)
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?member_id=1311530&user_secret=5f6145ca

cfrankb at gmail

Jan 19, 2007, 2:49 PM

Post #23 of 38 (10159 views)
Permalink

Re: mx: mechanism being used like a: mechanism? [In reply to]

> If some uses mx:mumble in their SPF record and mumble has no mx records, the
> mechanism can never match, but (as long as mumble is a fully qualified domain
> name) it won't raise an error.
>
> If there were a syntax error in the record (e.g. ipv4:1.2.3.4 - note that the
> mechanism is ip4, not ipv4) then any record that returned anything other than
> permerror (or unknown in the old parlance) would be wrong. MX, but no MX
> records is not a syntax error, it'll just never match.

I wish it was stated that clearly on the SPF syntax page and in RFC_4088.

I don't see how specifying a non-existant mechanism (e.g., ipv4: and
outmx:) is PermError while stating a reference to non-existant MX
record(s) is not an error of some kind, but a potential PASS? Isn't
there a difference betwen comparing two IP addresses and comparing an
IP address with nothing? It's like encountering a GOTO 4596 and not
having a line 4596. Wouldn't these throw an exception? And since it
"requires manual intervention" to either add an MX record or else
delete the mx: it would be a PermError rather than a TempError, no?

-------
Archives at http://archives.listbox.com/spf-help/current/ or
http://www.gossamer-threads.com/lists/spf/help/ (easier to search)
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?member_id=1311530&user_secret=5f6145ca

cfrankb at gmail

Jan 19, 2007, 2:51 PM

Post #24 of 38 (10138 views)
Permalink

Re: mx: mechanism being used like a: mechanism? [In reply to]

> I wish it was stated that clearly on the SPF syntax page and in RFC_4088.

I meant http://www.openspf.org/RFC_4408

-------
Archives at http://archives.listbox.com/spf-help/current/ or
http://www.gossamer-threads.com/lists/spf/help/ (easier to search)
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?member_id=1311530&user_secret=5f6145ca

steve at teamITS

Jan 19, 2007, 3:03 PM

Post #25 of 38 (10153 views)
Permalink

RE: mx: mechanism being used like a: mechanism? [In reply to]

Charles Franklin Bernard <mailto:cfrankb [at] gmail> wrote on Friday,
January 19, 2007 4:50 PM:

> I don't see how specifying a non-existant mechanism (e.g., ipv4: and
> outmx:) is PermError while stating a reference to non-existant MX
> record(s) is not an error of some kind

"ipv4" has to be an error since it's essentially random text in
the SPF record. More confusing is that include:nonexistent-record *is*
an error.

I updated the Common Mistakes FAQ to indicate the status of
including a non-existent MX.

-----
SPF FAQ: http://www.openspf.org/FAQ
Common mistakes: http://www.openspf.org/FAQ/Common_mistakes

- Steve Yates
- ITS, Inc.
- To find the meaning of life you must be properly installed.

~ Taglines by Taglinator - www.srtware.com ~

-------
Archives at http://archives.listbox.com/spf-help/current/ or
http://www.gossamer-threads.com/lists/spf/help/ (easier to search)
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?member_id=1311530&user_secret=5f6145ca

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads