On Saturday 10 October 2009 12:53:14 hector wrote: (cut) > This occurred with the DKIM-DEV list I am subscribed to. I forget the > exact reasons but the end result is that my MDA began to reject my > copy of the DKIM-DEV list distributed mail I thought the sender was > white listed as I receiving mail fine in the past.
> But something changed on either end and I received an automated final > warning notification that my subscription would be moved if I don't > response to the notification (click the url and confirm I am a real > person). It was odd the notification got thru but normal distribution > were rejected. probably sent from the list domain rather than the author domain. > So I fixed that by adding more white listing rules for > this list sender. Whitelisting on the scale of individual receivers is an inhibition to adoption. > That got me thinking about RFC 5617 support as it was being > implementing as part of our SMTP level scripting filter language. > > Out of the box, our inbound MTA will run the "DKIM SCRIPT" at the > SMTP level. > > So imagine, if a resigned mail was received from mipassoc.org for a > author domain that happens to have a ADSP = "DISCARD" or "ALL", then > this would be a failed DKIM/ADSP transaction. > > It was already troubling that a list server would not honor RFC 5617, > but now I saw how the list server can now begin to send notifications > to subscribers for rejected mail. this is useful as at least in this case stuff didn't break silently. lucky I guess. > So I see three possible mitigating options: > > 1) Update RFC 5617 > > 1.a) All DKIM-BASE compliant receivers SHOULD supprt RFC 5617 support: +1 > > 1.b) All DKIM Resigners MUST respect RFC 5617 support: +1 > 1.c) All receivers who support RFC 5617 MUST use post > message acception silent discarding of mail and not use a > SMTP level rejection to avoid bounce issues and mail list > subscription removals. not sure. In addition to subscription list removals this would cause silent failure to ordinary sender to recipient communication that fails because of sender error or intermediary content reformatting when a simple/simple canonicalisation. It seems from your case above that automated removal isn't totally there so perhaps it could be kept as is even if a few people get scared into considering DKIM/list implications fully. other options: Receiver temp fails the messages and tells then recipient with a "whitelist this if you want" option keep as reject but use http://tools.ietf.org/html/draft-kucherawy-dkim- reporting-05 to supplicant processing. 1.d) Standardize http://tools.ietf.org/html/draft-kucherawy-dkim-reporting-05 > 2) Extend RFC 5617 with an explicit 3rd party signing option. 2.a) add a dkim=3p option (which is what I assume you meant from previous messages) informing the recipient that the sender isn't adverse that 3rd party signers be accepted instead of the ADSP. 2.b) Extending RFC 5617 to support Sender: as a author responsible party header header to be checked in same way. Useful as many maillist already do this. This has limited MUA visibility though Outlook does display this in a way to avoid some spoofing attacks. Sender was standardized a long time ago so encouraging MUA developers to make use of this by making this change could be useful and perhaps a path of least resistance/maximum benefit. Perhaps given the recipient filtering options may differ between between a first party and a third party signature perhaps keeping this as a separate RFC (also to be listed in 1.a) is needed like..... 4) DKIM Third-Party Authorization Label pros: * works for a number of explicit authorizations. In conjunction with dkim- reporting could provide an automated way for senders to add third party authorisations with little ambiguity about what the sender intent is. cons: * the scalability on large environments to include all mailing lists that author domain use is a little fragile. 5) List Domain Signing Practices (LDSP) A consideration that email lists, as defined by the domain in the List-ID tag (RFC 2919) could be treated in the same way as ADSP As Stephen Turnbull mentioned on the mailman-developers list recently which was where this was derived from: "Obviously the amount of trust you put in LDSP- authenticated mail is much lower than that you put in ADSP- authenticated mail. Still, in the current environment I'll take any bonuses I can get, and as long as I behave, I suspect the big ISPs would be willing to allow me to build up some cred." pros: * no action required on author domain * promotes DKIM for list operators * less whitelisting for recipients * gives recipients domain reputation as a criteria cons: * acknowledges that List-ID's are spoofable and that 4) is probably an answer to this before reputation is developed or where delivery is really important. > 3) Deprecate RFC 5617 > > If list server developers or operators are not expected to > support or honor RFC 5617, then we SHOULD declare RFC 5617 has > as non interoperable with DKIM-BASE, deprecate it and remove > it from standard track. >From the sympa-dev, dkim-dev and mailman-developers comments I don't think there will be any resistance in list server developers or operators honouring RFC 5617 and will probably drop/reject dkim=all|discardable if signatures fail. > Ideally, I think #1 is required if we are going to keep it. I think > [2a] should also be considered as well. #1 DKIM-BASE strengthen: good enabler for all of the below to work #1d DKIM reporting: to handle incidental failures Resigner/Mail list benefits by Option number: #4 DKIM Third-Party Authorization Label: good for explicit third party senders of importance to the sender #2a ADSP add dkim=3p: middle ground that is easy to deploy as a sender and gives recipients the ability to not be so strict about ADSP filtering dkim=all/discardable filtering #2b ADSP add Sender as author agent: quick gain for list operators that DKIM sign and recipients that choose to implement it. #5 LDSP: quick gain for list operators that DKIM sign and have a domain reputation, easy gain for ISP and large domain verifiers _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
