Rolf, It seems much easier for MLS (Mail List Servers) to preempt restrictive ADSP Domains from subscribing and from submitting mail to the list enabled with DKIM resigning.
Follow the specification and apply it accordingly using engineering sense. No Subjective concepts. We need persistent expectations across the board. The problem here is that list managers what to sign everything with disregard to policy. There is no way you going to get DKIM+POLICY+MLS correct. Something has to give. Support policy is an answer, getting rid of it is another so that at least everyone can work under the same plane. It would easy to add new common sense options to our list server such: List DKIM/ADSP options: [X] DKIM Sign this list [CLICK FOR DKIM SIGNING OPTIONS] [X] Disallow ADSP DISCARDABLE domains from subscribing. [X] Disallow ADSP DISCARDABLE domain list submissions. [X] Send Notification to domain for ADSP=DISCARD Policy restricted subscription or submissions. [EDIT NO-ASDP-ALLOW-SUBSCRIPTION TEMPLATE] [EDIT NO-ASDP-DISCARD-SUBMISSIONS TEMPLATE] The template #1 would probably say: Dear {MSG.FROM} Sorry, but you can not subscribe to this list using a restricted ADSP DKIM=DISCARDABLE policy for your domain. If we had accept your subscription, there is risk of harming the subscription status of other members already on the list. We don't wish to do that. Remedies: 1) Remove the DKIM=DISCARDABLE ADSP policy or change ADSP policy to DKIM=ALL and reapply to subscribe to the list. 2) Use another domain that isn't ADSP restricted. The template #2 would probably say: Dear {MSG.FROM} Sorry, message submission to this list is restricted to domains with non-ADSP DISCARDABLE policies only. If we had accepted it, there is risk of harming the subscription status of other members of the list. We don't wish to do that. Remedies: 1) Remove the DKIM=DISCARDABLE ADSP policy or change ADSP policy to DKIM=ALL and resubmit your message. 2) Use another domain that isn't ADSP restricted. I can't remove popular features even if I wanted to and I seriously doubt any RFC will change this for most systems: [X] Add [LIST] Tag to Subject Line [X] Add Footer [EDIT FOOTER TEMPLE] [X] Set Reply-To to List address [_] Strip HTML [_] Strip Attachments and all other inherent integrity breaking ideas in MLS software and used by MLM (Mail List Managers). We need to fit DKIM/POLICY into the system. Not fit the SYSTEM into DKIM/POLICY. -1 towards ideas of altering 5322.From lines which will only open a nasty can of worms. We would be breaking all kinds of Authorship From expectations, including touching base with copyright related issues. Or get rid of POLICY if its hurting DKIM implementation for list servers. Working it to standardization yet list managers with DKIM resigners intentionally ignoring it is not going to work very well. Not supporting it is one thing, yet allowing ADSP domains to submit mail is another thing. It doesn't mix well. If this becomes the behavior what will happen is SMTP systems will be force to accept mail to discard it. They won't be be able to reject mail at the transport level because that will promote a bounce towards the list server and this will hurt members of the list. We can't dictate to SMTP developer and operators not to employ session level rejections. -- HLS Rolf E. Sonneveld wrote: > On 08/03/2010 02:36 AM, John Levine wrote: >>> The proposal is to preserve the original message + DKIM signature and to >>> add the new (probably partially rewritten) output message, combined into >>> a multipart/alternative structure. The combined message is sent by the >>> MLM to the recipient. >>> >> Once again, I can only see this as screwing up the 99+% of users for >> whom the lists work just fine for the<1% who consider themselves so >> important that they need to mark their list mail with ADSP. >> > > I did not have ADSP in mind when writing this proposal. Let me be clear > about ADSP: IMO domains that publish adsp=discardable and yet send mail > with that domain via mailing lists, get what they deserve: problems. > >> Imagine you're a list manager. Your list has 1000 subscribers. Two >> of them demand that you do something to prevent address forgery due to >> forged unsigned messages, a problem that you have never observed to >> happen on your lists. What do you do? I know what I'd do. >> > > In a nutshell the problem of the combination DKIM + MLM can be > summarized (and simplified) as follows. > > On the plus side: > > 1. the mail that is received by a subscriber to a mailing list carries > (most of the time) the original From. > 2. the original DKIM signature can still be present in the message (if > we recommend the MLM authors to not remove DKIM-Signatures) > > However... > > 3. the MLM rewrites the Subject (in many cases) > 4. the MLM adds a footer (many cases) > 5. see par. 3.3 of Murrays draft for more things MLMs do to messages > > That means, we have a signature + From, but we no longer have a reliable > copy of the message to verify them. > > 6. we can tell the MLM authors to change their code to no longer do 3., > 4. and 5. but, as Murray describes in par. 3.4: > > <quote> > However, the practice of applying headers and footers to message > bodies is common and not expected to fade regardless of what > documents this or any standards body might produce. > </quote> > > With this situation in mind, I wrote my proposal, to provide the > verifier on the receiving side with a means to verify the original DKIM > signature. > > /rolf > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html > > _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html