Re: [ietf-dkim] requirements

On Jul 27, 2006, at 5:20 PM, Jim Fenton wrote:

> Douglas Otis wrote:
> > Regardless of the OA, spam will reflect poorly upon the signing  
> > domain.  Reports of abuse and expectations of who will resolve an  
> > abuse issue  always falls to the signing domain.  There will not  
> > be any "spreading" of responsibility.  There is no means to know  
> > whether the OA is even valid!  The identity of the OA depends upon  
> > the assertion made by the signing domain.
> "Spreading" was perhaps not the right word to use.  But the  
> signature is now coming from a different place, so whom it reflects  
> poorly upon is now changing.  That makes it a fundamentally  
> different thing than key delegation.  Allowing a domain to delegate  
> the ability to sign their mail and not holding the delegating  
> domain responsible at all seems undesirable in that it doesn't  
> discourage domains from doing business with dubious mailing services.
There are many organizations that use email-servers to attract users  
and their eyeballs.  Vetting customers is part of their cost of doing  
business.  DKIM makes reporting abuse easier, where then the report  
also has a much greater signal to noise ratio.  DKIM should make this  
domain's life easier, so don't shed any tears or expect anything to  
get worse as a result.
By design, DKIM is not obvious to the recipient without some type of  
annotation.  When just display-names are visible or international  
domain names are used, the recipient may be unable to ferret out  
spoofing attempts based solely upon strict OA policy.  This issue is  
indicated as having both a high impact and high likelihood in the  
Threat draft.  It seems reasonable to assume message annotation  
conveys the signing domain when it does not match the OA.
It seems wrong to suggest a signature is coming from a different  
place.  The signature comes from where the key was obtained.  The OA  
is coming from a different place, but message annotations should make  
this apparent.  While the designation of signing domains by the OA  
could be incorporated into message annotations, this is not really  
required when the signing domain is conveyed.  The signing domain  
should also be annotated when found within a prior correspondence  
list or address book.
As a separate issue from spoofing, message acceptance should improve  
when associations are validated with the DSD list.  It would be  
surprising for Cisco to designate popular mailing list domains,  
however.  It would be likely that Cisco might create a separate  
subdomain in order to establish different policy arrangements.   
Perhaps for staff.cisco.com, the policy would look like:
 staff.cisco.com Policy DSDL: <cisco.com> MODE: Open-ended (allows  
the use of mailing lists)
 cisco.com Policy DSDL: <cisco.com> MODE: Closed-ended (better  
prevents spoofing of transactional messages)
 blue-example.net DSDL: <blue-example.net>, <cisco.com> MODE: Open- 
ended (allows use of companies outbound services and mailing lists)
This may mean that when you want to send messages to a mailing list,  
fenton(_at_)staff(_dot_)cisco(_dot_)com or fenton(_at_)blue-example(_dot_)com would be used,  
instead of fenton(_at_)cisco(_dot_)com(_dot_)  The mode "open-ended" for  
staff.cisco.com and blue-example.com also indicates the OA can be  
signed by any other domain, or even not have a valid signature.   
There does not appear to be a reason to differentiate between being  
signed by some other domain, and not being signed at all.  The  
typical reason for allowing this exception would be to handle  
messages damaged in transit, or messages sent through other outbound  
services such as auction websites and the like.
-Doug








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