Arvel Hathcock wrote:
4) Make the headerspec value a mailbox, domain or token. Which it is
would also to be specified in the authentication method specific
registration for a given method.
Would either of those options mean an update to (for example) the [AUTH]
spec would be required to add this text? Could we define something to
use in the interim?
This document can certainly provide an initial registration for specific
authentication mechanisms already published as RFCs and deployed. So it
can and probably should provide a registration for SMTP AUTH. I guess it
could/should also define them for mechanisms that are in the
rfc-editor's queue, so that covers SPF and SenderID.
We could also consider this spec to be the place where the DKIM method
should be defined, but that's unclear. I don't know at this point
*where* the DKIM method will be defined otherwise.
All of this would be in the IANA Considerations section.
2) Make the headerspec ptype a list of "smtp", "header" and "body".
How would you do PRA?
something like: spf2/pra: pass header=foo(_at_)bar(_dot_)com (Comments);
Other than "spf2/pra" being an illegal token? :-) It would need to be
something like "spf2.pra" or "sidf" or whatever.
Since PRA will use one of four headers as the one whose identify was
used, I would expect the headerspec to be one of
header.resent-sender
header.resent-from
header.sender
header.from
followed by the identity that came out of that header.
For example:
spf2.pra=pass header(_dot_)resent-from=user(_at_)example(_dot_)org
(Comments)
Make sense?
Tony Hansen
tony(_at_)att(_dot_)com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html