[ietf-dkim] over-the-wire (in)compatibility between pre-IETF DKIMand (eventual) IETF DKIM

[Douglas Otis]

On Oct 19, 2005, at 2:22 PM, Earl Hood wrote:

> On October 19, 2005 at 10:29, Douglas Otis wrote:
>
>
>> This opportunistic approach can be improved by specifying the role of
>> the signer, such as:
>>
>>   - Originating
>>   - Resending (remailing)
>>   - Verifying
>>
>
> Is "Resending" only for entities that "re-submit" a message into
> the transit system?  Would pass-thru forwarders be under
> "Resending"?

Assuming that replay must be dealt with, then it would be valuable to  
have a signature added when the MTA changes channel characteristics  
perhaps as noted by the EHLO name or perhaps your RCPT TO hash  
technique.

I'll even assume replay becomes a real problem.  Imagine several  
flags returned from a reputation query.  One may be not to trust the  
IP address at all.  Another may be the domain can be trusted to sign  
for other domains as a remailing signer.  The default may be to limit  
the trust to their own domain.  Imagine that a list-server will sign  
in the role of remailing signer, and may nullify the Originating  
signature after verifying it was valid.  The accountability baton is  
thus passed, and the list server also retains a reputation for  
protecting signatures.

Perhaps all large providers will resign with a Verifying signature  
when accepting messages for delivery to the mailbox and nullify all  
other signatures that verify.  If they do not verify, the signature  
header is removed and replaced with some diagnostic header.  Perhaps  
signature parameters are simply replaced with "*verified*...  " or  
"*invalid*...  "

While there may be a day when third-party signing is not allowed,  
unless what is considered an originator is also compliant with  
RFC-2822, that day may be many more years way, if ever.

-Doug