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