Subject: [ietf-dkim] Draft agenda for Chicago...

From: Stephen Farrell <[email-masked]>
Date: Tue, 03 Jul 2007 14:31:56 +0100

Hi All,

Our current agenda for Chicago looks like:

1. agenda bash (2)
2. document status (2)
3. ssp reqs (depends on IETF list activity, if any)
4. ssp (50)
5. overview (30)
6. AOB (some)

Can you let Barry and I know if you'd like a slot (for what,
how long), or have any other comments on this.

Regards,
Stephen.

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

---

From: Douglas Otis <[email-masked]>
Date: Thu, 5 Jul 2007 12:04:47 -0700

SSP & Authorization?

Wide deployment of DKIM would be highly desired, but the transparent  
authorization scheme as currently envisioned limits where DKIM might  
prove useful.  Will transparent authorization produce more more junk  
for SMTP to handle?  Will replay abuse cause DKIM to devolve into  
feckless and wasteful per-user-keys?

Some providers may expect that by restricting the methods to  
authorize DKIM signing domains, higher premiums can be charged.  This  
authorization impediment will result in DKIM being used less and  
having less relevance.  Another driving motivation might be that  
transparent authorization shifts accountability away from the  
provider.  Unfortunately, the only anti-replay assurance possible is  
when the SMTP client introducing the message to a public SMTP server  
happens to be within the signing domain.  In most cases, without SMTP  
client being within the signing domain, there will not be a safe  
basis to accept a message based upon the signing domain, even when  
the signing domain might be otherwise trustworthy.  Improving  
delivery acceptance is desired by a majority of email uses.  Domain  
delegation or key exchanges for transparent DKIM authorization  
defeats DKIM based acceptance.

Dealing with spam must be done as close to the source as possible.   
DKIM could help by confirming who is introducing the message into the  
public SMTP server.  A simplified means to authorize who is providing  
this service allows DKIM signing domains to normally correlate with  
the provider's SMTP clients.  When the message is authorized AND the  
SMTP client and signing domain correlate, there would be far less  
concern of replay attack.  If there was a problem, the domain signing  
the message should be held accountable, as they should also be  
closest to the problem.  Domain delegation or key exchanges for  
transparent DKIM authorization defeats the assumption as to who is  
closest to the problem.

No one should be visually examining DKIM signatures to deduce  
signature validity.  Whatever annotation ultimately devised to convey  
signature validations and identity compliance, it will hide an  
equally ugly but highly useful hash based authorization scheme.  Such  
an authorization scheme also makes it clear who actually signed the  
message.  Ultimately, knowing who actually signed the message  
provides an essential piece of information needed to detect and  
curtail fraud.   Domain delegation or key exchanges for a transparent  
DKIM authorization defeats an ability to detect fraud.

-Doug