Subject: Re: [ietf-dkim] incremental vs. infrastructure adoption

From: Dave Crocker <[email-masked]>
Date: Sat, 09 Dec 2006 12:48:21 -0800

Charles Lindsey wrote:
>>>>> You can't do it in the headers, because Bad Guys can write headers 
>>>>> too.
>>>>
>>>> Not when the headers are signed.  (eg, <http://goodmailsystems.com>.)
>>>  And there you gave a good answer (and it also brings the thread back 
>>> on topic :-). OK, such schemes are possible. But the Bad Guy can 
>>> still insert the "SAFE" header and sign it, so there is still work 
>>> for the verifying agent to do by way of spotting such already present 
>>> headers and acting accordingly. .
>>
>> Typical discussions, about such indications of safety, distinguish 
>> between what is carried in the message, across the Internet, versus 
>> what is generated within the trusted Administrative Management Domain 
>> (ADMD) of the recipient.
> 
> If you are wanting that "SAFE" logo to appear on your MUA when a 
> whitelisted email is received, then that information has to be 
> communicated somehow from the site that checked the whitelist (which is 
> usually in a diferent ADMD to yourself). That means it must be possible 
> to communicate it by SMTP (you cannot assume that everybody uses POP3 or 
> IMAP to access their mail, and even there it would need upgrades to 
> those protocols).

There is very little real-world experience with Internet-scale mechanisms 
within-message carriage of safety indicators to the end users.

So we should be cautious about assuming exactly how it is going to be done or 
how it will work.

You are postulating carriage between two ADMDs.  From the discussions about 
indicators I've seen over the last year or two, I believe it is expected that 
the special header field being explored is intended for use only within a single 
ADMD.

That does not mean that inter-ADMD signaling of safety isn't possible, but 
merely that it is a significant extension and, as you note, carries added trust 
challenges.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html