Jeff Macdonald wrote: > > As a signer, I may want to do this: > > i...@transaction.company.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? 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. > 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? It would be equally valid for a signer to apply a different pseudo-subdomain on each message, perhaps for tracking purposes. 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. -Jim _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
