ietf-dkim
[Top] [All Lists]

RE: [ietf-dkim] Re: Role of Sender header as signing domain

2006-11-30 08:29:34
I fail to see any relevance here?
Go out to your user pool show them the headers and ask them what they signify. 
Chances are "not much".

From: joe(_at_)foo(_dot_)com
Sender: signer(_at_)bar(_dot_)com
Good DKIM sig from bar.com

Means that bar.com signed on behalf of (purportedly) joe(_at_)foo(_dot_)com and 
when asked will verify that yes indeed we sent that message. It has squat all 
to do whether the letter is a 419er, Viagra or get rich quick pumping stock.

Expecting end users, remember we are an ISP, to understand DKIM + SSP is far 
beyond anything we could imagine.
Thanks,

Bill Oxley
Messaging Engineer
Cox Communications

-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org 
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Charles Lindsey
Sent: Thursday, November 30, 2006 5:55 AM
To: DKIM
Subject: Re: [ietf-dkim] Re: Role of Sender header as signing domain

On Wed, 29 Nov 2006 16:50:24 -0000, william(at)elan.net 
<william(_at_)elan(_dot_)net>  
wrote:

On Wed, 29 Nov 2006, Charles Lindsey wrote:

On Tue, 28 Nov 2006 15:42:11 -0000, Scott Kitterman  
<ietf-dkim(_at_)kitterman(_dot_)com> wrote:


2822.From is the only identity that is reliably displayed to the end  
user.

I utterly fail to see why what is displayed to the user is of the least  
relevance.

Charles is correct. The way protocol is layed down right now what is
displayed to the user is irrelevent to the core. It only becomes relevent
with the the policy part which is supposed to be the one trying to  
protect
against phishing. Also note that any MUA-based anti-spam systems that may
use the core would look at what it says and therefore if other header  
field
like Sender is listed its quite likely to be displayed.


Ah! I think I see now what Scott and Eliot are getting at. Suppose we have:
     From: joe(_at_)foo(_dot_)com
     Sender: joe(_at_)bar(_dot_)com
with good signature by bar.com

The verifier informs the recipient that the message was signed by bar.com,  
and is confused because he sees no header mentioning bar.com. Or it  
reports a failed signature by bar.com, and the user is even more confused.  
I.e., he is supposing that the user is merely informed of what signatures  
are present and it is left to him to inspect the displayed headers to see  
whether he needs to be alarmed.

I find that a very poor way of communicating to the user, as others have  
pointed out (though I don't go along with Doug's expectation that the  
user's MUA will go trawling through his address book). So let us step back  
a moment and see how this communication might take place.

There are two cases:
1. The MUA has been specially adapted to work with DKIM
2. The MUA has not been specially adapted

We are supposed to be designing a system which will work with existing  
MUAs (i.e. case 2), so in that case the verifier's policy module can only  
communicate with the user via the body of the message - rather like those  
irksome systems which add long paragraphs to the end of messages to inform  
you of all the viruses they did or didn't detect.

So in that case it is up to the policy module to describe its suspicions  
in a manner the user can understand whether he can see all the relevant  
headers or not.

So it might say
    "This message was sent by joe(_at_)bar(_dot_)com (good signature by 
bar.com) but  
you
     should notice that the From: address made no mention of bar.com."
or
    "This message was sent by joe(_at_)bar(_dot_)com apparently on behalf of  
joe(_at_)foo(_dot_)com,
     but there is no valid signature from either of them."

OTOH, if one can assume an adapted MUA as in case 1, then presumably the  
communication could be by some other channel (possibly using the headers),  
but such an MUA would, in any case, display all headers relevant for  
understanding the report from the policy module, including the Sender if  
appropriate.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html