ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] List Server ADSP Support

2009-10-14 06:55:17


--On 13 October 2009 19:47:53 -0400 hector 
<gmail(_dot_)sant9442(_at_)winserver(_dot_)com> 
wrote:

Ian Eiloart wrote:


So what you are saying is that LIST SERVER developers SHOULD NOT add
ADSP features to restrict signing of ADSP domain nor bother to see if
it should allow these restrictive domains to subscribe?

They should add features. But "DISCARDABLE" ('discard' isn't a value,
and  'discardable' doesn't mean 'discard'), should not be treated the
same as  "ALL". It's reasonable for a list to rejected mail that it is
about to  render discardable, but there's no reason to reject mail with
"ALL".


IMO, as a software developer, it is programmatically inconsistent to
create an potential problem for list distribution when the downlinks can
results in negative results.  As it was outlined in the archives,
discussed and proposed in the DSAP  draft:

     http://tools.ietf.org/html/draft-santos-dkim-dsap-00#page-12

specifically outlining the MLS concerns and considerations, I can not in
good conscious claim or work with the idea of RFC 5617 ignorance knowing
full well there exist an IETF standard that receivers can use to cause
MLS problems.

I think you've misread my message. I'm simply saying that "ALL" doesn't 
mean "DISCARDABLE". As far as I can tell, ADSP gives no guidance to 
recipients about how to treat unsigned messages from the domain at all. 
Recipients need to make their own, intelligent judgements.

As a recipient, I know to treat trusted lists differently that other 
forwarders. And, if I know that they're going to change a DKIM signature, 
then I frankly don't care that ADSP told me that the message should 
originally have carried a good signature. What I care about is the 
reputation of the list. If the sender doesn't want their messages forwarded 
by lists, then can they not use "DISCARDABLE"?




Remember RFC5617 says " 3.2 ... o  If a message has a Valid Signature
other  than an Author Domain Signature, the receiver can use both the
Signature

 > and the ADSP result in its evaluation of the message."

What is most important to receivers is what section 3.2 items 3 says:

    o  All messages from this domain are signed with an Author
       Domain Signature and are discardable, i.e., if a message
       arrives without a valid Author Domain Signature, the
       domain encourages the recipient(s) to discard it.

coupled with section 4.2.1 with direct semantics for exclusive 1st only
signature semantics.

Coupled with the deployment guide sections 6.1, 7.3.1

    http://tools.ietf.org/html/draft-ietf-dkim-deployment-08

I reckon that the guide needs to caution recipients to expect that mailing 
lists might break signatures, and to assess the reputation of the sender, 
not the purported message author. Except where the policy is "discardable", 
of course. In fact, section 5.5 would be the place to insert 
recommendations, would it not?

The alternative, recommending that lists should not pass on messages from 
ADSP domains will simply inhibit domains like mine from publishing ADSP 
records. We're in a position to do that because we already do insist that 
our users send mail through our servers. However, we do make a great deal 
of use of mailing lists, both local and third party.

Specifically, I don't see how ANY organisation can be sure that its email 
won't go through a mailing list.

Coupled with the Threat Analysis RFC 4686 summary recommendation:

   DKIM is effective against the use of specific identities only
   when there is an expectation that such messages will, in fact,
   be signed. The primary means for establishing this is the use
   of Sender Signing Practices (SSP), which will be specified by
   the IETF DKIM Working Group.

All in all, allows for a wide interpretation and implementation for
POLICY to be a natural part of the DKIM total solution.

This issue on the table is whether resigners, a direct threat to DKIM
mail integrity, are obligated to play by the same rules and follow all
the semantics, provisions and recommendations peppered throughout the
documents.

Thanks



-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html