I think that smtp-receiver-hostname ought to be renamed to smtp-sender-helo
I would like to include the argument to the mechanism (before any macro
expansion).
I think that the whole best_guess thing is a bit of a nightmare -- I
wouldn't want to mention it in the RFC. Otherwise there will be endless
discussions about the precise set of values, yadda yadda yadda.
We probably also ought to take trhe opportunity to make the header
compatible with other SMTP headers in terms of LWSP. It appears (from a
quick look at 2822) that the BNF doesn't mention the WS after the colon
anyway.
I think that comment-string probably ought to be 'ccontent' from rfc2822.
Definitely a move in the right direction.
Philip
Jim Ramsay wrote:
Meng Weng Wong wrote:
I'd like to make the Received-SPF header more structured. Can you guys
suggest a sane format?
Here's one idea:
header = 'Received-SPF:' 1*WSP result [ FWS '(' comment ')' ] CRLF
FWS = ([*WSP CRLF] 1*WSP
result = 'pass' / 'fail' / 'error' / 'unknown'
/ unknown-declarations
unknown-declarations = 'unknown' *( FWS declaration )
comment = smtp-receiver-hostname ':' envelope-sender ':' current-domain
':' match-mechanism [ ':' comment-string ]
smtp-receiver-hostname = 1*VCHAR
;hostname given by SMTP client at HELO or EHLO command
envelope-sender = 1*VCHAR
;reverse-path given by SMTP client at MAIL FROM command
current-domain = IPV4Address / IPV6Address
;IP address of current SMTP client
match-mechanism = mechanism / 'none'
;mechanism format specified in section 3.2
;MUST be the mechanism which was actually matched to cause the
; current result if a mechanism was matched
;MUST be 'none' if no match was made for any reason
; (ie, error, no SPF information given)
comment-string = VCHAR [ 1*( FWS VCHAR ) ]
;SHOULD include further information not already provided
; (ie, description of error message in the case of errors)
;SHOULD mention if the "best_guess" function is used
;MAY include a human-readable explanation of why the current result
; was decided
;MAY in the future include other "important" information such as SPF
; version number, or additional colon-delimited information
I don't think distinguishing between +all and other forms of "pass" will
be useful. Square peg, round hole. Spammers can think of a dozen ways
to fake a +all. Consider "ptr:com ptr:org", or a bunch of ip4:1/2 type
things, etc. Better to leave that stone unturned.
Very true.
-------
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;±¤Ö¤Íµø?¡