ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] MLMs and the use of multipart/alternative to preserve original DKIM signature and at the same time add a new DKIM signature

2010-08-03 08:00:30
On 08/03/2010 02:02 PM, Hector Santos wrote:
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.
   

My proposal was and is _not_ aimed at ADSP and _not_ at policies in 
general. The proposal only identifies a means to make MLMs (and 
re-signers in general) in a way 'transparant' for receivers of a mail. 
Nothing more, nothing less.

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

<Prev in Thread] Current Thread [Next in Thread>