Re: [Ietf-dkim] DKIM-Signature: r=y and MLM
Hector Santos <hsantos@isdg.net> Mon, 15 October 2018 14:30 UTC
Return-Path: <hsantos@isdg.net>
X-Original-To: ietf-dkim@ietfa.amsl.com
Delivered-To: ietf-dkim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A782130E08 for <ietf-dkim@ietfa.amsl.com>; Mon, 15 Oct 2018 07:30:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=DHs7agIl; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=gHwj8zG/
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMyaQoIuzxl2 for <ietf-dkim@ietfa.amsl.com>; Mon, 15 Oct 2018 07:30:47 -0700 (PDT)
Received: from ftp.catinthebox.net (secure.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5506F130E7E for <ietf-dkim@ietf.org>; Mon, 15 Oct 2018 07:30:44 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=6727; t=1539613838; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=7cVOFgPyqWO+vHyk5h9Xc495rTc=; b=DHs7agIlyL6B4o5iFOhGsjco9RdbkYUrvfhBpyh2MKoMTAyhPRiRFq+0j3W+OV hoq4bGAJ3Cv66z61s6VQcREbkJmvFESxI6UQAUxaKpEFL4vHSDUgjoI59BPV8Wh5 n7KVGmH0hGHYuKimPoWs4hiQPzsZ6KfP+G8e5NjOFYf7g=
Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for ietf-dkim@ietf.org; Mon, 15 Oct 2018 10:30:38 -0400
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer);
Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 3712445628.50760.4784; Mon, 15 Oct 2018 10:30:37 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=6727; t=1539613077; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=xYQTMpi D3ShJA0WuxTN+Wn010Tztg2xlKxwlFQ9Icuc=; b=gHwj8zG/L7+EHl0F/UP97Oh /RVj4T3uz5hyQS3Sb74+6b+njOuMZeF12GmUCw/Dcrw53rm5syQEF7w4LbTVKzJk tr0zZvqDTRWMMzgA0VzgEKD1np5jEG6oWC9EwZ7klHnr4Wotpg7XkePnhXtTCkK0 ESIQlbY5jasFMr/QpPCo=
Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for ietf-dkim@ietf.org; Mon, 15 Oct 2018 10:17:57 -0400
Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 3453806312.9.167724; Mon, 15 Oct 2018 10:17:56 -0400
Message-ID: <5BC4A48C.3080302@isdg.net>
Date: Mon, 15 Oct 2018 10:30:36 -0400
From: Hector Santos <hsantos@isdg.net>
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: ietf-dkim@ietf.org, Dilyan Palauzov <Dilyan.Palauzov@aegee.org>
References: <20180811033840.Horde.i6llD-AtvgzyNIjbhTs-nkS@webmail.aegee.org> <98aff90a-2198-854f-f1e6-85fd704cb7d1@tana.it> <20180817214834.Horde.DNYi60aPTo_sOKr7o3ilPra@webmail.aegee.org> <2c60b8bf-fec7-3a72-4bcc-3f2416e6f8b1@tana.it> <20180820193206.Horde.U24zQJh_TH-uC-4hxrcs2fw@webmail.aegee.org> <6e31890d3b63091a1d731fd70c2bfc217dc4f45b.camel@aegee.org>
In-Reply-To: <6e31890d3b63091a1d731fd70c2bfc217dc4f45b.camel@aegee.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-dkim/H6-e436Yh-tYC5ASEJkSmNjlSL8>
Subject: Re: [Ietf-dkim] DKIM-Signature: r=y and MLM
X-BeenThere: ietf-dkim@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DKIM List <ietf-dkim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-dkim>, <mailto:ietf-dkim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-dkim/>
List-Post: <mailto:ietf-dkim@ietf.org>
List-Help: <mailto:ietf-dkim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Oct 2018 14:30:50 -0000
On 10/10/2018 5:11 AM, Дилян Палаузов wrote: > Hello, > > no feedbach means either everyboby agrees, nobody understands, or > nobody cares. Generally, a bit of everything. I'm providing some comments because I am currently updating my DKIM ADSP/ATPS/DMARC implementation and need to take into account the MLM rewrite issue. > I suggested introducing > * fo=da in DMARC’s TXT [https://tools.ietf.org/html/rfc7489#section-6.3 > ] for sending reports on failed DKIM-Signatures, only when they align, > and > * introducing r=a in DKIM-Signature [ > https://tools.ietf.org/html/rfc6651#section-3.2] that only sends > reports, when From: aligns. > > This way, once an email is intenionally modifed, the modifying software > is aware that DMARC will trigger and rewrite From: so no distracting > reports will be sent. I don't think we need a new DKIM-BASE DKIM-signature tag for what you want. This all starts with DKIM Policy (ADSP/DMARC) restrictive policies and receivers finally honoring them. This could be better done as a DMARC tag extension where it provides the MLM more DMARC mail handling information. For example, new DMARC tag extensions "rewrite=" and "fo=" rewrite=no default, rewriting SHOULD be avoided. rewrite=allow allow rewriting by domain with a p=none or no policy rewrite=strict allow rewriting by domain with a p=reject|quarantine policy fo=da send reports when rewriting is done Keep in mind that not every system will send reports. It is considered a high overhead with a high redundancy. Our implementation does not generate reports. Reporting adds a high barrier and technical implementation requirement. Reporting should be optional for implementation. Also keep in mind that the idea of "Rewriting" is not a "standard" concept. It is actually a long time mail engineering taboo to be destroying the originating author field for any mail platform, including RFC5322. Its a very sensitive design idea. Our MLM package does not rewrite. However, I am considering it now as a means to resolve the problem of errant DMARC/ADSP domains submitting public mailings using restrictive policies. I personally believe the DMARC/ADSP receiver can implement ATPS "Authorized Third-Party Signers" (RFC6541) but that didn't gain traction, so rewrite appears to be the only recourse. With more receivers now honoring the policies, it can cause a major havoc in a list subscription group. Since there are more MLM systems performing DMARC-based rewrites, I believe a better way to deal with this is for the MLM to reject the restrictive domain submission with an email response: "Sorry, your submission was prohibited due to a protected domain restrictive DMARC|ADSP policy." In fact, the MLM should stop all new subscriptions from domains using a restrictive policy. The rewrite should be the last thing to consider, and if it does rewrite, it should replace the original author domain strong policy with its own strong policy. For example, the ietf.org mailing list has begun to rewrite and it replaces the 5322.From with a dmarc.ietf.org domain, adds a new X-Original-From header and resigns the message using an ietf.org signer domain: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1537415189; bh=TJWGUVdPL8OTY+HJnUzpBRd52OaKfWjFqS68Cby0s/M=; h=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From; b=..... X-Original-From: Hector Santos <hsantos@isdg.net> From: Hector Santos <hsantos=40isdg.net@dmarc.ietf.org> What it should do is: 1) It should use a 1st party signature using d=dmarc.ietf.org to match the new author domain dmarc.ietf.org. 2) It should has hash bind the X-Original-From header to the signature. Since DKIM recommends not to bind "X-" headers, a non "X-" header should be used, i.e. "Original-From:". This means adding the header to the 'h=" field to avoid potential mail resend exploits using different unprotected Original-from: fields. 3) and finally, the dmarc.ietf.org domain should have its own DMARC p=reject policy to effectively replace the one it circumvented with the submission. With these measures, the original author domain will still be protected with a DMARC policy when the MLM rewrites. That's my idea of a better approach to it as oppose to a blind, unprotected rewrite. >> I am looking for a way to get reports only when somebody >> unintentionally modifies an email. The reason for this is >> to have a system without unexplainable failures that makes it >> easy to fix broken DKIM signing/validating software. Remember, not all systems will send a report. I personally think a MLM should be playing an more active role to protect against DMARC -- who can subscribe, who can submit mail. If the domain is restrictive, it is possible to maybe only allow READ-ONLY mode and/or add a user subscriber option that says: [_] Rewrite the From address is allowed Although, it could just use the DMARC record to see if there is a "rewrite=no|allow|strict" option. The MLM is now doing the DMARC lookup, so its possible now to add this logic. if rewrite=no then send submission/subscription prohibited message if rewrite=strict then if the mlm has no dmarc policy, then send submission/subscription prohibited message else do rewrite with new matching signer and author if rewrite=allow then do rewrite with new signer and author if rewrite= then // no tag follow local mlm policy setup >> How about introducing fo=da for sending reports on failed >> DKIM-Signatures, only when they align? This is much like having r=a >> in DKIM-Signature that only sends reports, when From: aligns. This >> way, once an email is intenionally modifed, the modifying software is >> aware that DMARC will trigger and rewrite From: so no distracting >> reports will be sent. I'm currently updating my DKIM implementation with DMARC ADSP/ATPS/DMARC, which basically means adding the local policy switches to finally honor the p=reject/quarantine policies. This means that our MLM needs to do much of the above which is basically: 1) During new subscriptions, check for restrictive domain. 2) During list submissions, check for restrictive domain. (_) Don't allow, send notification (_) Allow rewrite with address ________________________ [_] Optional check for DMARC 'rewrite=" extension The main design consideration is to make sure the list submission is either prohibited or corrected before the distribution and reaches DMARC receivers. -- HLS
- [Ietf-dkim] DKIM-Signature: r=y and MLM Dilyan Palauzov
- Re: [Ietf-dkim] DKIM-Signature: r=y and MLM Alessandro Vesely
- Re: [Ietf-dkim] DKIM-Signature: r=y and MLM Dilyan Palauzov
- Re: [Ietf-dkim] DKIM-Signature: r=y and MLM Murray S. Kucherawy
- Re: [Ietf-dkim] DKIM-Signature: r=y and MLM Murray S. Kucherawy
- Re: [Ietf-dkim] DKIM-Signature: r=y and MLM Murray S. Kucherawy
- Re: [Ietf-dkim] DKIM-Signature: r=y and MLM Dilyan Palauzov
- Re: [Ietf-dkim] DKIM-Signature: r=y and MLM Murray S. Kucherawy
- Re: [Ietf-dkim] DKIM-Signature: r=y and MLM Dilyan Palauzov
- Re: [Ietf-dkim] DKIM-Signature: r=y and MLM Murray S. Kucherawy
- Re: [Ietf-dkim] DKIM-Signature: r=y and MLM Brandon Long
- Re: [Ietf-dkim] DKIM-Signature: r=y and MLM Alessandro Vesely
- Re: [Ietf-dkim] DKIM-Signature: r=y and MLM Alessandro Vesely
- Re: [Ietf-dkim] DKIM-Signature: r=y and MLM Dilyan Palauzov
- Re: [Ietf-dkim] DKIM-Signature: r=y and MLM Дилян Палаузов
- Re: [Ietf-dkim] DKIM-Signature: r=y and MLM Hector Santos
- Re: [Ietf-dkim] DKIM-Signature: r=y and MLM Дилян Палаузов
- Re: [Ietf-dkim] DKIM-Signature: r=y and MLM Дилян Палаузов
- Re: [Ietf-dkim] [dmarc-ietf] DKIM-Signature: r=y … Hector Santos
- Re: [Ietf-dkim] DKIM-Signature: r=y and MLM Hector Santos