On Wednesday 26 July 2006 23:54, Hallam-Baker, Phillip wrote: > > [mailto:[EMAIL PROTECTED] On Behalf Of Scott Kitterman > > > > It might be useful (later, after the requirements discussion > > is complete) to explore the feasibility of a common policy > > record for the two for future revisions. The risk associated > > with complexity and the possibility of contradictory policy > > statements may make the associated up front pain worthwhile. > > > > I would imagine that 'the market' is looking for simplicity > > in a holistic approach. The more that these technologies can > > be effectively integrated, the better off the average mail > > admin will be. > > The question in my mind is who builds a road towards whom. > There is enough overlap in participation that I think this solves itself by just moving forward.
> One way forward is to start with SPF and have a statement 'there is a DKIM > record'. > > Pro: Already some base > Con: The decision to use a raw unprefixed TXT record does not play > nice with other systems. > Con: SPF politics. > Con: Leaves a standard track WG dependent on an RFC parked at experimental > Another PRO is that since the envelope comes first, by the time the receiver goes to DATA, the record will already be in the local cache if Mail From == From. As I understand it, that's roughly 80% of the time, so as an optimization, it's non-trivial. If one defines a modifier for the SPF record that gives a pointer to the DKIM policy/practice statement, but it's not the only way to discover it, then this can be utilized by the receiver without becoming dependent on an experimental RFC. If pieces of RFC 4408 are needed, they can be copied into a new document that updates 4408 to avoid the dependency. > Another is to make the dkim policy language powerful enough to support the > statement 'there is also an SPF record' > > Pro: Least work for us > Pro: Aligns with standards > Pro: Uses a prefixed record > Con: Lose the SPF base > Yes, but even if you leverage the SPF record format and location, you've already lost the base since records would have to be modified to support any option we pick. The other CON is that SPF can be done before DATA, so a DKIM policy record announcing SPF support is out of sequence for SMTP. > A third option is to introduce a super-policy record that lists the > authentication mechanisms in use > > Pro: Is clean > Pro: Puts DKIM, SMIME, PGP, SPF on equal footing > Con: Yet another policy descriptor > Yes, but we are going to need some method of combining these different technologies. I would prefer to see at least the protocol aspects of that standardized. That gives us some hope for interoperability as the synergies between these approaches are developed. Another CON - Probably out of scope for this group and I don't think it can wait for the time needed to spin up another WG. Scott K _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
