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
