On Wed, Feb 11, 2009 at 09:01:39AM -0800, Jim Fenton wrote:
Jeff Macdonald wrote:
As a signer, I may want to do this:
i=(_at_)transaction(_dot_)company(_dot_)com d=company.com for transactional
messages and
d=company.com for everything else (yes, there is no i=, but i= defaults
to @d). This is done to emulate separate IP streams by using a DKIM
identifier. ISPs have said 'separate your streams', so this is a
continuation of that.
Does your use of the (pseudo-)subdomain "transaction" have any literal
meaning, or would you accomplish the same thing using the
pseudo-subdomain dfhjkhkjh?
yes, using dfhjkhkh would accomplish the same thing.
If verifier is supposed to take meaning from some specific
pseudo-subdomain name, that would make it decidedly non-opaque (or
words to that effect :-) ) which would run contrary to what many are
suggesting.
transaction was chosen for illustrative purposes.
Assume the messages pass DKIM authentication. Next the "output of DKIM"
is passed to some reputation module. Receiver A decides that is i= and
treats the two types of DKIM messages as the signer intended. Receiver
B decides to use d= and treat the two types of messages as the same.
One day a machine is compromised causing the signer to send spam but
only for those messages with no i=. Receiver A throttles those but not
the messages with i=. Receiver B throttles all the messages.
How does Receiver A know the signer's intent?
I don't see why the receiver would have to know the signers intent, if
by intent you mean what do the various values of i= a signer may
present means. It doesn't matter. All a signer wants is a guarentee of
what identifier (or identifiers) would be used as in input into a DKIM
reputation algorithm.
It would be equally valid for a signer to apply a different
pseudo-subdomain on each message, perhaps for tracking purposes.
I think that is actually a mis-use of DKIM. The message-id field covers
that nicely.
If the value is really intended to be opaque, the verifier shouldn't
even group together like pseudo-subdomains for reputation purposes, in
the absence of out-of-band information describing what the signer
does.
My understanding of opaque allows identical opaque values to identify
the same "something".
--
Jeff Macdonald
jmacdonald(_at_)e-dialog(_dot_)com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html