spf-discuss
[Top] [All Lists]

Re: Establishing sanity recommendations for redirect= (related to Managing exploits)

2004-10-20 18:00:02
Alan,

On Wed, 2004-10-20 at 14:57, Commerco WebMaster wrote:

Thank you for your answers, however, I'm not clear in some cases that you 
were addressing the questions I asked.

Ok.

Posted the original "Managing exploits" message last week.  I had sent a 
message regarding some issues and inputs I had with and for spfTools.net a 
while back and received no response, so did not know that you were the 
individual managing that.  Sorry.

Can you re-send this email to me or barring that, perhaps the topic or
original sender's email address so that I may perform a search against
my mail archive.  Regretfully I am unable to find anything even close to
your description thus far.

Actually, the section 5.2 you quote below seems to deal with the issue of 
include, not redirect= - I did not know that we could presume the same 
things for both there.  Perhaps that should be explicitly stated in the 
specification document, if I have not misread the section.

To be fair to you, I only pasted 5.2 because it made reference to
recursion.  The real meat is in section 6.2 (Processing Limits). 
Section 5.2 as you may or may not have derived from the content I
posted, is the 'explanation' section as opposed to the 'include' or
'redirect' sections.

Section 4.2 (include) briefly references recursion in the first
paragraph through disclosure that recursion will occur during an
'include'.  Unfortunately Section 5.1 (redirect) does not similarly
state this even though its blatantly obvious through the very word
attributed to this modifier, I wager it would probably have made things
clearer to have done so.

Did not notice the Redirect modifier mentioned in this section - thank you 
for pointing this out to me.

No problem.  I'm curious which draft you were actually reading as to be
fair to you, its evolved/changed/improved (for better or worse at times)
quite a lot since the original draft.

No.  It should NEVER EVER EVER be up to a publisher.  This is because
the publisher could be an asshat and intentionally publish a broken
record resulting in finite levels of recursive checking.

Agreed, though perhaps we should keep the colorful characterization 
language down when posting to the list.

You would be hard pressed to fathom the unprecedented levels of
ignorance and trollmanship present in these here SPF-DISCUSS forums.  I
generally place feelings after fact because sometimes you have to be
unnecessarily terse to get through to some people and I would much
rather that you (would be reader) got my point and were possibly
offended/hurt/upset then you thinking I'm just some well nice guy and
walk away either not understanding or worse thinking something
different.  

Also, to be perfectly fair its also the byproduct of being involved with
this project for the duration that I have and thus leaves me somewhat
desensitized to the varying levels of ambiguity present previously or
still present in the draft(s) available.  Please accept my apology in
view that I believe you'll understand why my delivery employed
potentially enough capitals to get me kb'd from EFNET channel employing
a title representing anything operating system or major programming
language.   

The message link offered above is a darned good one about the problems a 
publisher had with properly implementing the include mechanism in their SPF 
DNS TXT record.  Now then, do you think that we should publish anything in 
the specification about what I mention above for the redirect modifier?

This does warrant further discussion.  Please see my response to Mark
and perhaps respond appropriately to that and anyone else reading please
do the same.

Cheers,

James

-- 
James Couzens,
Programmer
                        ^                            ( ( (      
      ((__))         __\|/__        __|+|__        '. ___ .'    
       (00)           (o o)          (0~0)        '  (> <) '    
---nn-(o__o)-nn---ooO--(_)--Ooo--ooO--(_)--Ooo---ooO--(_)--Ooo---
http://libspf.org -- ANSI C Sender Policy Framework library
http://libsrs.org -- ANSI C Sender Rewriting Scheme library
-----------------------------------------------------------------
PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7A7C7DCF

-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
http://www.InboxEvent.com/?s=d --- Inbox Event Nov 17-19 in Atlanta features 
SPF and Sender ID.
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

Attachment: signature.asc
Description: This is a digitally signed message part