On 04/Apr/11 06:09, John Levine wrote:
Another way is to have a dkim tag that specify the header that
indicates the stream classification
Many ways to kill the same bird.
If there is a reason why people aren't able to use a d= domain per
stream, I wish someone would explain in simple terms that even a
dimwit like me can understand.
Attaching multiple meanings to the same datum produces non-orthogonal
structures that may result in idiosyncrasies. (If Joe Marketeer's
address is Joe(_dot_)M(_at_)example(_dot_)com rather than
Joe(_at_)marketing(_dot_)example(_dot_)com, he
may want to sign with d=example.com irrespectively of the message stream.)
As vague as the concept of /message stream/ is, I don't think it is
necessary to invent a new header field for it, since the List-Id
exists already, and "SHOULD be included in the signature" according to
the current spec.
Likewise, there is an auth tag in A-R for the authenticated id. (The
only use of such token for unknown domains seems to be in connection
with _submission._tcp SRV RRs to devise dictionary attacks.)
+1 for softly deprecating the AUID.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html