On Fri, 24 Nov 2006, Jim Fenton wrote:
william(at)elan.net wrote:
Neither one the designers of DK[IM] are particularly interested in dealing
with as is evident in previous discussions in regards to "3rd-party" policy
considerations or 3rd-party signers.
Your use of "neither one" in this context rather than "none of" implies there
are only two designers, when in fact there are quite a few more.
'Neither one' means neither 'Mail List' nor 'Newsgroup' scenarios which
is what the subject of my previous sentence was.
SSP and DKIM itself are under control of the Working Group. If there is
consensus to do things differently, as there was with the body hash mechanism
in -base, the original designers are likely to contribute their comments, but
it is the WG consensus that rules.
Workgroup often means people in support of the original idea who are
willing to work on it further. However in cases when WG charter is
limited in scope and with specific drafts in mind, the participation
narrows down to largely only those supporting those drafts or their
authors.
I gather you are advocating a requirement that SSP queries be made
for other addresses in addition to the From address.
As I said many times the identity should in itself be a scope - in
case of SSP that would mean that lookup should be for "_from._policy."
prefix to allow for future expansion. However I'm not actually advocating
working on identity other then "From" header field at this time although
I think that current definition and especially due to "From" being able
to consist of multiple addresses would lead to you seeing "From" address
changed by intermediate agents which has not been case in email so far.
That said I was referring to WG not being interested in working out
mail list cases (which was always the DK's problem) which would
involve signature that is more likely to path through (and still
be verifiable after) mail lists and similar redirectors and working
out policy system that takes existence for such redirectors and
that some domain users often use them into account.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html