やるきなし

2026/11/04 17:38 / Debian OpenARC (experimental) + fetchmail

Debian の OpenARC は https://tracker.debian.org/pkg/openarc のとおり experimental での提供のみで，version は 1.0.0．これは TrustedDomainProjectのものを upstream としているため．archlinuxのページにあるとおり，TrustedDomainProject のものは更新されておらず，https://github.com/flowerysong/OpenARC が archlinux の upstream になっている．

The original software by the TrustedDomainProject has not been updated in years, but is available as openarc-legacyAUR. openarcAUR{.small} follows the maintained fork by flowerysong.

Debian でも https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1126523 のとおり 1.3.0 は https://salsa.debian.org/mjeanson/openarc にあったりする(そちらに移行しようという話になりつつある)．以下 1.0.0 と 1.3.0 の違いと，fetchmail (ARC Sign 後に fetchmail して取り出すこと想定)を合わせて利用する際のメモ．

OpenARC 1.0.0 では以下のような ARC-Message-Signature が生成されることがあった(Header パートが途中で終わってしまう．．．)．流石にこれは．．．と思い，1.3.0 に切り替え(dpkg-buildpackage -b で自前 package 作成)．

ARC-Message-Signature: i=3; a=rsa-sha256; d=example.org;
       s=99999999; t=1792749999; c=relaxed/relaxed;
       bh=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX=;
       h=Received:Received:Delivered-To:Received:Received:
        ARC-Message-Signature:ARC-Authentication-Results:
        ARC-Message-Signature:ARC-Authentication-Results:DKIM-Signature:
        Received:Received:From:To:CC:Subject:Thread-Topic:Thread-Index:
        Date:Message-ID:References:In-Reply-To:Accept-Language:
        Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator:
        x-ms-publictraffictype:x-ms-traffictypediagnostic:
        x-ms-office365-filtering-correlation-id:
        x-ms-exchange-senderadcheck:x-ms-exchange-antispam-relay:
        x-microsoft-antispam:x-microsoft-antispam-message-info:
        x-forefront-antispam-report:
        x-ms-exchange-antispam-messagedata-chunkcount:
        x-ms-exchange-antispam-messagedata-0:Content-Type:
        Content-Transfer-Encoding:MIME-Version:X-OriginatorOrg:
        X-MS-Exchange-CrossTenant-AuthAs:
        X-MS-Exchange-CrossTenant-AuthSource:
        X-MS-Exchange-CrossTenant-Network-Message-Id:
       
ARC-Authentication-Results: i=3; example.org; dmarc=none (p=none dis=none) header.from=example.com; dkim=pass (1024-bit key; unprotected) header.d=officeexample.onmicrosoft.com header.i=@officeexample.onmicrosoft.com header.a=rsa-sha256 header.s=selector2-officeexample-onmicrosoft-com header.b=XXXXXXX4; dkim-atps=neutral

OpenARC 1.3.0 上記問題が生じないことを祈りつつ運用していたが(つまり未検証)，以下のように fetchmail が妙なところに Received: ヘッダを挿入していることを発見．

 ARC-Message-Signature: i=3; d=example.org; s=99999999; a=rsa-sha256;
        c=relaxed/relaxed; t=1792749999;
+Received: from example.org [XX.XX.XX.XX]
+       by myni with POP3 (fetchmail-6.4.39)
+       for <myn@localhost> (single-drop); Wed, 04 Nov 2026 16:46:34 +0900 (JST)
        h=Received:Received:Delivered-To:Received:Received:DKIM-Signature:
         Received:Received:From:To:Subject:Thread-Topic:Thread-Index:Date:
         Message-ID:Accept-Language:Content-Language:X-MS-Has-Attach:

これは fetchmail が Received: を探して，その前の行に Received: を挿入することが原因で，行頭から Received: となっているかを本来はチェックすべき(バグなように思う)．該当箇所以下．

[https://sourceforge.net/p/fetchmail/git/ci/legacy_6x/tree/transact.c]
    if ((rcv = strstr(msgblk.headers, "Received:")) == (char *)NULL)
        rcv = msgblk.headers;
    /* handle ">Received:" lines too */
    while (rcv > msgblk.headers && rcv[-1] != '\n')
        rcv--;

なお，fetchmail --invisible などとして，Received: の挿入自体をしないようにすることもできるが，設定等は触りたくなくて，かつ，fetchmail に patch を送るのもあれなので，しばらく悩んで，そもそも ARC が Sign に利用する Header が多すぎる問題に気づき，そちらで対応することにした．

[/etc/openarc.conf] 追記
SignHeaders From,To,Cc,Reply-To,Subject,Date,Message-ID,MIME-Version,Content-Type,Content-Transfer-Encoding

Default では以下の man openarc.conf のとおり，DKIM specification (RFC 6376) “SHOULD” be signed となっているものを署名することになっているが，実際の実装では全て署名対象にする様子(ひどい)．

SignHeaders (string)

Specifies the set of header fields that should be included when generating signatures. This is expected to be a comma-separated list of header field names, and matching is case-insensitive. If the list omits any header field that is mandated by the ARC specification, those fields are implicitly added. By default, those fields listed in the DKIM specification as “SHOULD” be signed (RFC6376, Section 5.4) will be signed by the filter.

まとめると以下．