On Wednesday 03 December 2008 20:13, Douglas Otis wrote:
Stating Sender-ID or SPF as the method applied does not sufficiently
define the scope of the path registration. There was never an
agreement reached as to the scope of the SPF record. The
authentication-results header fails to return an implied or expressed
scope statement that may have been deduced from the path registration
records, or that remains in an unknown state. Without an implied or
expressed scope, a process can not know what an authorizing domain
intended to ensure, the MailFrom or the PRA.
Just in case anyone else is confused by this (I was the first several times I
read it), this is not about anything in the draft.
+------------+----------+--------+----------------+--------------------+
| Method | Defined | ptype | property | value |
+------------+----------+--------+----------------+--------------------+
| senderid | RFC4406 | header | name of header | value of header |
| | | | field used by | field used by PRA |
| | | | PRA | with comments and |
| | | | | local-part removed |
+------------+----------+--------+----------------+--------------------+
| spf | RFC4408 | smtp | mailfrom | envelope sender |
| | | | | with local-part |
| | | | | removed |
| | +--------+----------------+--------------------+
| | | smtp | helo | HELO/EHLO value |
+------------+----------+--------+----------------+--------------------+
The relevant scopes used for obtaining the result are included in the
auth-result header. I was afraid he was saying they were not (and that would
be a significant problem, IMO).
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html