Re: [Ietf-dkim] DKIM-Signature: r=y and MLM

Dilyan Palauzov <Dilyan.Palauzov@aegee.org> Fri, 17 August 2018 21:48 UTC

Return-Path: <Dilyan.Palauzov@aegee.org>
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 46B04130FCE for <ietf-dkim@ietfa.amsl.com>; Fri, 17 Aug 2018 14:48:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org
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 IHphwCQdFOFb for <ietf-dkim@ietfa.amsl.com>; Fri, 17 Aug 2018 14:48:39 -0700 (PDT)
Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A950130FCA for <Ietf-dkim@ietf.org>; Fri, 17 Aug 2018 14:48:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1534542515; i=dkim+sm-localhost@aegee.org; r=y; bh=wGx7tsPRYf7zSl9uSbyTpfz/DCtSQdozaqwa1kyN738=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=mGkbFH6g0Iy14af1YLpcx4jmYQRAB4yifRdvSDW/XkYRlywEvXqmxKQ+tmlSFu1Jr OsEge/cTboeKaQc4u47tnxD9iUkKjp6ux3A5KEF1Ti7wFBt8j64SnsMr0HbD8qXjhy 0sE7SYtNMrgrU8rVEEbA6BVe5Y7/nZ3GEhuOCwUUTyrnVKcVSidNTg7e4uohu4VYnz bU32LjSxgWMSLpS/8kRWCDhRCtwlqC5fOr1R4PL1RYU/x7aiHz56EYYABfIC08tS9+ w/V5Lw6Z7YVUBFEhxsb+ZETO69HBRSc10lYnAMPcySRKTxYe9wQVDbgX72bhGDqKAM QHqbXSzCk5k0AfPNQ6EPXlAPpb4uoXAdb8+D9drnBo8oASuBCmx+EaQ7eDxG8g+W7D HBJz3Rl007Ch+eaoDEYgRgjiVsD0LhkI0Y0S8YTrRSX+xvX1A7WjAaveSRGzt3ZCzd OsS2GQ1hz8YBrur9iTkzpyN2yh3boi+b519hOmVK0aEPD4SoKUsU09T8AGNzcagOK7 Rk17FM1F+1ApGluA6zAE8wLZRj5U50oqfbrm1hyMuoM3x2zuZA5qR0D6x0YRTfRykv RKVo7v9YU8XkekbOKR5ONFPsYFN10Z7YPUQVpVvBNLh/N41PrmtqyRqDFYIw2XDzbU y6RQItPzT1EVAl3IMEEJwB0U=
Authentication-Results: mail.aegee.org/w7HLmY9B007878; dkim=none
Received: from mail.aegee.org (localhost [127.0.0.1]) by mail.aegee.org (8.15.2/8.15.2) with ESMTP id w7HLmY9B007878; Fri, 17 Aug 2018 21:48:34 GMT
Received: from c-76-102-151-26.hsd1.ca.comcast.net (c-76-102-151-26.hsd1.ca.comcast.net [76.102.151.26]) by webmail.aegee.org (Horde Framework) with HTTPS; Fri, 17 Aug 2018 21:48:34 +0000
Date: Fri, 17 Aug 2018 21:48:34 +0000
Message-ID: <20180817214834.Horde.DNYi60aPTo_sOKr7o3ilPra@webmail.aegee.org>
From: Dilyan Palauzov <Dilyan.Palauzov@aegee.org>
To: Alessandro Vesely <vesely@tana.it>
Cc: Ietf-dkim@ietf.org
References: <20180811033840.Horde.i6llD-AtvgzyNIjbhTs-nkS@webmail.aegee.org> <98aff90a-2198-854f-f1e6-85fd704cb7d1@tana.it>
In-Reply-To: <98aff90a-2198-854f-f1e6-85fd704cb7d1@tana.it>
User-Agent: Horde Application Framework 5
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
MIME-Version: 1.0
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.100.1 at mail.aegee.org
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-dkim/r2c77skNNFH7vPVlNAqfM76dQ8U>
Subject: Re: [Ietf-dkim] DKIM-Signature: r=y and MLM
X-BeenThere: ietf-dkim@ietf.org
X-Mailman-Version: 2.1.27
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: Fri, 17 Aug 2018 21:48:43 -0000

Hello,

I cannot provide very useful experience:

- On r=y almost nobody sends such reports, except very tiny  
one-man-and-for-fun providers.
- The server I run is used primary for incoming emails, users send  
mails From: the managed domain using other servers, and these emails  
do not have DKIM-Signature: r=y from my domain.  So my conslusions are  
mainly about emails I send myself.  It is about 3-10 emails per month.
- The reports I get are sent either because the report-evaluator has  
bugs, because some MTA does illegal rewritings (like inserting newline  
in "From: me <1@example.org>,you <2@example.int>"; between >, and you)  
, or because the mail was modified by a MLM.  But checking each single  
report for the failure reason is too much time, and I prefer not get  
such reports, when the mails were intentionally modified.
- The server manages mailing lists in a sub-domain, where all emails  
are signed, but it turns out that email addresses subscribed to a  
mailing list are not mailing list on their own hosted somewhere else.   
Emails running over the mailing lists, do not generate reports on r=y,  
partially because the signatures are not broken and partially because  
almost all providers ignore r=y.

I repeat my self, but the problem was, that I used software for  
attaching DKIM-Signature to the emails, and the aggregate reports  
showed that this does not work 100% reliably.  I started inserting r=y  
with the hope, that I will get reports on broken emails, but nearly  
nobody sends such reports, so r=y has not helped to fix the software i  
use.

fo=d is independent of r=y.

The reason to raise the topic, is that mailman developers will not  
remove r=y, unless there is a formal recommentation.

I wanted to deploy DMARC policy reject (or quarantine) once I am sure,  
that the DKIM signature are 100% correct.  I thought there is only one  
way to get report per failed DKIM signature and this way was to use r=y.

I do not sign all emails that come from my domain, as users can use  
any servers, to send mail from the domain.  But if an email is signed  
by me, I want to be notified when the signature is considered for some  
reason invalid, in order to ensure that the signing software works  
correct.  fo=d would generate reports for all emails without  
DKIM-Signature, that is not what I want.

ARC. ARF, DMARC, DKIM, Mailing lists... this thread it about DKIM,  
ARF-reports and recommendations about mailing lists.  For this reason  
I have not contacted the DMARC WG, most of the subscribers are anyway  
likely to be the same of both ietf mailing lists.

Rewriting From: by the MLM does not help with r=y.

If r=y / RFC6651 is moved to historic, then RFC6652 is also historic.

Do you suggest to:
   - ignore r=y, move RFC6651 to historic
   - state explicitly that providers who want reports about mismatched  
DKIM-Signature have to use p=reject;pct=0;fo=d;ruf=...
   - hint that fo=1 is not superset of fo=d
   - do something similar with RFC6652 and SPF

Why shall software that knows r=y is old-fashion not remove it from  
DKIM-Signature:, in order to ensure that r=y is not interepreted later  
by software, that doesn't know r=y was moved to historic?

Greetings
   Дилян

----- Message from Alessandro Vesely <vesely@tana.it>; ---------
    Date: Fri, 17 Aug 2018 13:15:48 +0200
    From: Alessandro Vesely <vesely@tana.it>;
Subject: Re: [Ietf-dkim] DKIM-Signature: r=y and MLM
      To: Dilyan Palauzov <Dilyan.Palauzov@aegee.org>;, Ietf-dkim@ietf.org


> Hi all!
>
> On Sat 11/Aug/2018 05:38:40 +0200 Dilyan Palauzov wrote:
>>
>> RFC6651 (Extensions to DomainKeys Identified Mail (DKIM) for  
>> Failure Reporting)
>> adds to DKIM-Signature the couple r=y - when an existing DKIM-Signature does
>> not validate, the signing server is notified that something went
>> (unintentionally) wrong.
>
> Interesting.  I knew about rfc6651, but never cared to implement it.  
>  Would you
> write for those like me a short overview of your experience with your
> arf+dkim-report mailbox, mentioning e.g. how long have you  
> implemented it for,
> the rough amount of reports / reporting domains that hit it, and the  
> like, please?
>
>> The DKIM aggregate reports show whether a server signs correctly  
>> all mails or
>> not.  If the aggregate reports show that this is sometimes (let's say in 1%)
>> not done correctly, the signer has no way to find for which email  
>> the signing
>> has not worked and cannot fix the signing software, unless a report for the
>> failing mail is sent with r=y.
>
> Well, nope.  Aggregate reports belong to DMARC.  Consider adding a  
> rua= address
> to your DMARC record.  Sometimes aggregate reports allow a postmaster to pin
> which message triggered it.  If you also set a ruf= address, you  
> might receive
> ARF reports as well.
>
> Perhaps, rfc7489 is not very clear in the explanation of dmarc-fo.  Does fo=d
> provide for sending a report irrespectively of r=y?  MDaemon's  
> implementation,
> for one, interprets the reference to rfc6651 as a requirement for  
> requesters to
> set r=y in their DKIM signatures:
>
>    When the DMARC "fo=" tag requests reporting of DKIM related failures,
>    MDaemon sends DKIM failure reports according to RFC 6651. Therefore, that
>    specification's extensions must be present in the DKIM-Signature header
>    field, and the domain must publish a valid DKIM reporting TXT  
> record in DNS.
>    DKIM failure reports are not sent independent of DMARC processing  
> or in the
>    absence of RFC 6651 extensions.
>                   
> http://help.altn.com/mdaemon/en/security--dmarc_reporting.htm
>
>> RFC6377 (DomainKeys Identified Mail (DKIM) and Mailing Lists) suggests in
>> section 5.7 to remove the invalidated DKIM-Signagures, if the mailing list
>> software has changed the email.
>>
>> I have not read ARC, but I have the impression that it says to keep the
>> invalidated DKIM-Signatures.
>>
>> When an email with DKIM-Signagure: r=y is sent to a mailing list,  
>> the email is
>> modified, and a final recipient following r=y sends a report.  The  
>> problem is
>> that this report is useless and distracting - it does not indicate, that the
>> signer-MTA or validator-MTA are implemented in wrong way.
>
> Correct.  MLMs affect DMARC too.
>
>> I suggest here in to suggest in a more formal manner, that MLMs modifying a
>> message are supposed to remove the r=y part of just invalidated  
>> DKIM-Signature
>> and this logic is also applied for ARC, if relevant (I don't know  
>> ARC).  Fixing
>> only ARC will not help, as there is software that follows DKIM, but  
>> has no idea
>> about ARC.
>
> AFAIK, ARC is not involved in reporting.  My feeling is that the whole topic
> now belongs to DMARC's territory.  Let me skip the long winded story of the
> ideas for solving the MLMs problem of DMARC.  Suffice it to say that  
> there is a
> dmarc WG[*], which is where ARC comes from.
>
> Meanwhile, the MLMs problem is being solved by rewriting From:.  This doesn't
> help r=y.  However, I'm reluctant to elect to rewrite DKIM signatures.  A
> broken signature can still be recovered by manually undoing the obvious
> modifications applied by MLMs, see attached screenshot.
>
> As for rfc6651, it also specifies how to obtain reports for ADSP, which was
> moved to Historical status.  Unless your experience testifies to a relevant
> community traction, I'd propose rfc6651 be moved to Historical  
> status too, and
> its format description be moved to rfc7489bis, whenever it comes about.
>
>
> Best
> Ale
> --
>
> [*] https://datatracker.ietf.org/wg/dmarc/about/


----- End message from Alessandro Vesely <vesely@tana.it>; -----