On Wed, Feb 11, 2009 at 12:03:40PM +0100, Eliot Lear wrote:
On 2/11/09 10:50 AM, Murray S. Kucherawy wrote:
Or, alternately, perhaps you're suggesting that's not an issue that
really needs to be solved? (That's not sarcastic; I don't have
experience yet to suggest this is a fire that needs to be put out, so
I'm genuinely wondering.)
I do not think this problem should be solved by the errata. I do not see
an actual interoperability problem stemming from this issue, beyond the
clarification of i=, and even there I don't actually know of any
implementations that have run into problems (some references to such would
be very nice).
As a signer, I may want to do this:
i=(_at_)transaction(_dot_)company(_dot_)com d=company.com for transactional
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.
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.
The errata doesn't actually fix this issue. It can still happen. What
it does try to prevent is the decomposition (if that is the right word)
of any value of d or i. For example:
(subdomain,domain)=find_domain(fqdn); # the million dollar function! :)
it does hopefully* allow this:
is certainly allows this:
* I say hopefully because I haven't read the latest errata.
NOTE WELL: This list operates according to