spf-discuss
[Top] [All Lists]

RE: [spf-discuss] Is SenderID supposed to stumble on garbage records?(paging Jim Lyon) C&C

2005-08-27 08:44:43
-----Original Message-----
From: Matthew Elvey [mailto:matthew(_at_)elvey(_dot_)com]
Sent: Friday, August 26, 2005 3:39 AM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] Is SenderID supposed to stumble on garbage
records?(paging Jim Lyon) C&C


P.S.  No need to cc: on list traffic.  I do read the list.
Uh, I explained in the post why I'd cc'd you.  I'm not a newbie.  It
looks like you didn't bother to read half my email - you didn't respond
to several questions I asked you.

I was in a hurry then and yes, missed the note about why you cc:ed me.

The ip4 mechanism won't hit because the mail is forwarded.  (On
non-forwarded I think it should provide a PASS...  I'm cc'ing this to
spf2(_at_)kit(_dot_)(_dot_)(_dot_) as a test; please let me know the results.)

Results:

Mail sent from: 66.111.4.28
Mail from (Sender): matthew(_at_)elvey(_dot_)com

Results - PASS sender SPF authorized


Mail sent from: 66.111.4.28
Mail Server HELO/EHLO identity: out4.smtp.messagingengine.com

HELO/EHLO Results - none

Return-Path: <matthew(_at_)elvey(_dot_)com>
Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com
[66.111.4.28])

elvey.com.              7201    IN      TXT     "v=spf1
exists:%{s}\;%{i}\;%{ir}_spf.nextbus.com a mx ip4:66.111.4.0/24
?include:rr.com ?include:elvey.slow.sp.am include:nextbus.com
include:messagingengine.com ~all"

elvey.com.              7201    IN      A       192.220.116.62

elvey.com.              7201    IN      MX      20
in2.smtp.messagingengine.com.
elvey.com.              7201    IN      MX      10
in1.smtp.messagingengine.com.

in1.smtp.messagingengine.com. 67367 IN  A       66.111.4.73
in1.smtp.messagingengine.com. 67367 IN  A       66.111.4.70
in1.smtp.messagingengine.com. 67367 IN  A       66.111.4.71
in1.smtp.messagingengine.com. 67367 IN  A       66.111.4.72
in2.smtp.messagingengine.com. 67367 IN  A       66.139.75.100

ip4:66.111.4.0/24 = 66.11.4.0 - 66.11.4.255

So it looks like I got through the exists: mess, didn't match a, didn't
match mx, and then matched on ip4:66.111.4.0/24.  So, Pass.

Now it has been pointed out elsewhere in this thread that pySPF should throw
a PermError when it hits the r macro in the exists because that's only
allowed in exp.  So I'll fix that when I have a moment.

So, the result should have been PermError, but I got a Pass because of the
lack of that legality check.

Now on to your other questions....

Actually, the current spec seems CONTRADICTORY.  It says the record
should be evaluated left to right and on a match, processing ends.
It ALSO says that in all cases, any syntax errors anywhere in the record
MUST be detected.  Damn confusing!  IIRC, the latter bit is a recent
addition, which has broken backwards compatibility.  :(  This needs
clarification.

I don't recall how far back that goes, but in pySPF there is a validation
function and a processing function to accomodate this.  Some popular
implementations have always done this and so whether it was explicitly
defined in the spec, it's something receivers have long had to deal with.  I
can't imagine what negative impact it might have.  I think that if anyone
was relying on having a broken record processed in a certain way, they were
on thin ice.

The situation where the HELO check produces one result
and the MFROM check produces another also needs definition. The spec
should not leave this undefined, IMO. These situations result in
incompatibilities that the IETF process is supposed to avoid.

Since, with some very limited exceptions, the current draft doesn't tell the
receiver what to do with results, I don't know why this should be the case.

These situations result in
incompatibilities that the IETF process is supposed to avoid.
I guess your implementation first checks the whole record for syntax
errors and then processes it left to right.  Is that correct?  If so, do
you stop processing on a match?

Yes.  It checks the whole record for a syntax error and then processes left
to right and stops on a match.  Thus the Pass on your message when the whole
record ends up breaking the processing limits.  Just as a point of
clarification, I don't think it's my implemenation.  Terrence Way started
it, Stuart Gathman picked it up, and I help out.

HTH,

Scott K

-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your 
subscription, 
please go to 
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com