ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Lists "BCP" draft available

2010-05-17 15:00:44
On 5/17/10 2:47 AM, Serge Aumont wrote:
On 05/11/2010 07:48 PM, Douglas Otis wrote:
   
On 5/11/10 7:37 AM, Serge Aumont wrote:
Serge,

     
   -Sympa include DKIM signature verification and use DKIM signature
status in the process of message submission and email commands
   -it remove broken pre-existing DKIM signature and keep others as is
(not all messages are processed in way that brake signature)
   -it reject message comming from  author ADSP record is discardable
and if the process of message by the MLM brakes signature. This
prevent brodcasting of a message that should be discarded by final
recipients.
   -it add it's own signature (on per list configuration parameter)
   -it sign MLM services messages and digest.
   - etc

       
Why limit rejection to ADSP "discardable" and not include ADSP "all"?
     
"ADSP = discardable" means  : "the domain encourages the recipient(s) to
discard it.". So a pretty MLM should discard thoses messages unless it
is able to brodcast it to subscribers without DKIM signature alteration.
"ADSP = all" does not recommend to drop thoses messages.
   
ADSP  "discardable" modifies SMTP acceptance assurances by encouraging 
ADSP evaluation failures be discarded rather than generate rejections or 
DSNs.  The lack of an Author Domain signature in conjunction with "all" 
assertions still represents an ADSP evaluation failure!  Invalidation of 
Author Domain signatures will result in subsequent ADSP evaluation 
failures.   ADSP "discardable" is not the only actionable assertion 
since "all" may also cause invalid Author Domain signatures to not be 
delivered.
If think it would be an error to recommend that MLM handles  "ADSP =
all" in the same way as they handle email with "discardable" domain. If
so "ADSP = all" will have a very poor difference with  "ADSP =
discardable" a very very low number of domaines will use such ADSP policy.
   
The difference between "all" and "discardable" is whether a rejection or 
DSN is expected when a message is not delivered.  That represents a 
sizable difference!

A mailing list that accepts messages containing From domains asserting 
"all" or "discardable" will not be in compliance when Author Domain 
signatures are made invalid by message modifications.   Interpretations 
that suggest only "discardable" provides actionable assertions leaves 
DKIM as offering protection only in conjunction with inherently 
unreliable services.  :^(
Why would it be okay to accept messages having ADSP "all" that lack a
valid Author Domain Signature?

BTW, ADSP "discardable" does not imply the desire to have messages
rejected, especially from a MLM application running post acceptance.
     
Should any invalid Author Domain signature for domains asserting "all" 
or "discardable" cause mailing lists to not distribute the message?

Discarding a message is limited to domains asserting "discardable", but 
ADSP "all" failures may also result in messages not being delivered!   
Under what conditions is it safe to accept ADSP "all" failures?  It 
would be much safer to allow domains seeking ADSP protection to 
determine specific exceptions.
In respect to Auth-Results, when is it safe to assume MLM applications
ensure compliance with ADSP?
     
It can be useful to add an header that prove the MLM [has] verified the
DKIM signature and ADSP compliance of the incomming message. This can be
done in a safe way adding an [AUTH-RESULT] header included in the new
DKIM signature.
   
Should receiving MTAs know whether mailing list applications:
  a) remove spoofed Authentication-Results headers,
  b) make reasonable modifications to messages,
  c) and properly evaluate Author-Domain signatures?

What grace period should MTAs allot for new mailing lists?

Is ADSP "all" protection a function based upon interactions between 
users and MUAs?  When would a user or MUA know whether it is safe to 
make ADSP failure exceptions for messages from unknown mailing lists?

An authorization scheme would allow domains seeking protection to 
indicate in each case whether they deem it safe to accept messages not 
compliant with "all" or "discardable" assertions.
The "l=" tag is one of the worth idea of DKIM if introduced because of
message body footer added by some MLM. MLM must not add anything after
the end of a message because this break Mime content. When adding a
footer, MLM should add an extra mime part, and this often require to
modify mime headers. So "l=" tag should not ne considered as an
efficient way to protect DKIM signature.

I known that the problem is comming from rfc-4871 but I  propose to
remove this sentence from this draft.

       
Would you also suggest a practice of not altering the Subject line, or
of not providing uniform message formats?

It seems unlikely there is a desire to have these features removed from
most mailing-lists.

Would you be interested in an alternative mechanism requiring the same
overhead as for ADSP, that eliminates a need to change any MLM handling?

If ADSP is worth doing, why is it not worth doing in a way that
increases security?

     
The "l=" seems to be ignored by every DKIM users. It's interest is
really limited. My opinion is that we should not recommend its usage
because it is not MIME compatible. MIME is an very old standard
implemented by almost every mail products. "l=" tag is an hack in DKIM
introduced only for dirty MLM software that still ignore MIME and will
probably ignore DKIM for a long time ;-). It should be forgotten !
   
Agreed.

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