[ietf-dkim] alternate proposal to draft-ietf-dkim-rfc4871-errata
Jim Fenton
fenton at cisco.com
Wed Feb 11 15:51:56 PST 2009
Jeff Macdonald wrote:
> On Wed, Feb 11, 2009 at 09:01:39AM -0800, Jim Fenton wrote:
>
>>> 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.
I don't know how a signer would obtain such a guarantee. Different
recipients will probably use different reputation algorithms (or
services), and there's no requirement for them to publish the way that
they work.
>
>> 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.
I see nothing in 4871 that prohibits or advises against that usage, and
I have heard others discuss that usage on this list.
>
>> 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".
That might be. I seem to be opacity-challenged.
-Jim
More information about the ietf-dkim
mailing list