Alex van den Bogaerdt wrote:
On Fri, Jan 09, 2004 at 02:56:59PM +0100, Julian Mehnle wrote:
Jim Ramsay [i(_dot_)am(_at_)jimramsay(_dot_)com] wrote:
Here is another updated definition. I was thinking about IPV6
addresses, and decided maybe the ":" delimiter between informational
fields in the comment were not appropriate as IPV6 is commonly notated
using ':'. How do people feel about pipe characters '|'?
'|' is ugly, don't do this. What about ',' or ';'?
It's probably not wise to change ":" into ";". This will cause
confusion (similar to " ` " vs. " ' ").
I personally don't know what the difference really is - it's just an
ascii character used as a delimiter, and the line itself isn't very
human-readable at all - That's what the "comment-string" part is for. I
thought that if this part of the line is going to be machine-parsed, it
doesn't matter what the delimiter is as long as it's not confused with
the content.
Or perhaps it *should* be more human readable, like this:
Received-SPF: pass (h=helo.example.com e(_at_) b\G \¿c?(|?? ip=192.168.0.1
m=ptr:example.net v=1 Site SPF record matched)
That's not bad - not hard to parse and not hard to read.
I suggest one of two options. The first is to take my previous spec,
and then hammer out what ascii character would make a good delimiter.
The other idea is to consider this second option:
header = 'Received-SPF:' result [ FWS '(' [FWS] comment [FWS] ')' ] CRLF
FWS = [*WSP CRLF] 1*WSP
result = 'pass' / 'fail' / 'error' / 'unknown'
/ unknown-declarations
unknown-declarations = 'unknown' *( FWS declaration )
comment = 'h=' smtp-sender-helo FWS 'e=' envelope-sender
FWS 'ip=' current-ip FWS 'm=' match-mechanism
[ FWS 'v=' version-string ] [ FWS comment-string ]
smtp-sender-helo = dot-atom-text
;dot-atom-text is defined in RFC 2822 section 3.2.4
;hostname given by SMTP client at HELO or EHLO command
envelope-sender = dot-atom-text '@' dot-atom-text
;dot-atom-text is defined in RFC 2822 section 3.2.4
;reverse-path given by SMTP client at MAIL FROM command
current-domain = ( IPV4Address / IPV6Address )
;IP address of current SMTP client
IPV4Address = 1*3DIGIT 3( '.' 1*3DIGIT )
IPV6Address = *4HEXDIG 7( ':' *4HEXDIG )
match-mechanism = mechanism / 'none'
;mechanism format specified in section 3.2
;MUST be the mechanism (and argument) record checked which was
; matched to cause the result, copied exactly from the actual
; SPF record.
;MUST be 'none' if no match was made for any reason
; (ie, error, no SPF information given)
version-string = 1*DIGIT *( '.' 1*DIGIT )
;The SPF version from the SPF record.
; I don't know if this is useful, but we can include it, so why not.
comment-string = *( ccontent [FWS] )
;ccontent is defined in RFC 2822 section 3.2.3
;SHOULD include further information not already provided
; (ie, description of error message in the case of errors)
;MAY include a human-readable explanation of why the current result
; was decided
Votes?
I kind of like the second one more myself.
Please note that I don't have any say in what the RFC will look like
anyway, these are just suggestions hopefully reveiwed by Meng :)
--
Jim Ramsay
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡