Open gizahNL opened 6 years ago
On Wed, Oct 11, 2017 at 3:28 PM, gizahNL notifications@github.com wrote:
Wanted to write on mailing lists, unfortunately they are non-existent? (as per: http://www.trusteddomain.org/mailman/listinfo/ )
Using your sample message and running it through dkimpy shows that the signatures do not validate:
DEBUG:dkimpy:ams sig[1]: {'a': 'rsa-sha256', 'c': 'relaxed/simple', 'b':
'TRFkzksm2fVytyzdFNm4Up78OtNBDPf0sgNWo1pgkZECKwH+tsAXuj730I4ghUVEAv7WkTpV7BQBI3PoQqLwiX9ljUJOHDMcYFR+AQAxxE4+MHPVHV/xzyqWwzXxIH2TafWEYqVN9Wbcq3lk/Bmru+JG1SAhqefhh4w1U5OHeiM=',
'd': 'heteigenwijsje.nl', 'i': '1', 'h':
'DKIM-Signature:X-Virus-Scanned:Received:Received:To:From:Subject:
Message-ID:Date:User-Agent:MIME-Version:Content-Type:
Content-Transfer-Encoding:Content-Language', 'bh':
'g3zLYH4xKxcPrHOD18z9YfpQcnk/GaJedfustWU5uGs=', 's': 'dkim', 't':
'1507734160'}
DEBUG:dkimpy:body hashed: 'test\r\n'
DEBUG:dkimpy:bh: g3zLYH4xKxcPrHOD18z9YfpQcnk/GaJedfustWU5uGs=
DEBUG:dkimpy:signed for ARC-Message-Signature: 'dkim-signature:v=1;
a=rsa-sha256; c=simple/simple; d=heteigenwijsje.nl; s=dkim; t=1507734160;
bh=g3zLYH4xKxcPrHOD18z9YfpQcnk/GaJedfustWU5uGs=; h=To:From:Subject:Date;
b=o/sOgCmPW6NaUTLVY7GV1AD6+hT4PNzeSWU6piwJJBEcD242lA0VAHBkvPwoa0kMK
N8DIWqhmiO9X7wWdespboQi8nzRFVZ6mYybDecWeR/SIg0cls7bZYzjYl8yAKOXxso
WnoKzyGThXM+tiexss4HEkHTSXtl4Yo9OuDRYsHY=\r\nx-virus-scanned:amavisd-new at
mailserv.heteigenwijsje.nl\r\nreceived:from
[IPv6:2001:984:a1fc:1:bc4f:29a2:28ba:ef40] (unknown
[IPv6:2001:984:a1fc:1:bc4f:29a2:28ba:ef40]) by smtp.heteigenwijsje.nl
(Postfix) with ESMTPSA id 742DB34789 for <PRIVATE>@gmail.com; Wed, 11 Oct
2017 17:02:30 +0200 (CEST)\r\nreceived:from smtp.heteigenwijsje.nl
([127.0.0.1]) by mailserv.heteigenwijsje.nl (mailserv.heteigenwijsje.nl
[127.0.0.1]) (amavisd-new, port 10026) with ESMTP id N7iioL2bFyX7 for <
zzzomeone@gmail.com>; Wed, 11 Oct 2017 17:02:30 +0200
(CEST)\r\nto:
--Kurt
You're right and I've been quite the idiot... Included an outdated file into the config because I copied from an outdated config....
Can confirm that using the right file now leads to correct validation by google if this is of any value ;)
there /are/ mailing-lists: https://openarc.org
I wasn't aware, guess the README is outdated then ;)
Mailing lists discussing and supporting the ARC software found in this
package are maintained via a list server at trusteddomain.org. Visit
http://www.trusteddomain.org to subscribe or browse archives. The available
lists are:
<PRIVATE>@gmail.com hmm imho valid email, but possible not your own :(
use example.org domain, not just random gmail.com
I had to use this in my openarc.conf file: SignHeaders to,subject,message-id,date,from,mime-version,dkim-signature,arc-authentication-results
so that only those headers were included in the signature calculation. Then gmail validates the arc signature properly.
+Brandon
That's good info but not a bug in openARC 😀
--Kurt
On Sun, Aug 19, 2018, 22:00 Matt Domsch notifications@github.com wrote:
I had to use this in my openarc.conf file: SignHeaders to,subject,message-id,date,from,mime-version,dkim-signature,arc-authentication-results
so that only those headers were included in the signature calculation. Then gmail validates the arc signature properly.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/trusteddomainproject/OpenARC/issues/66#issuecomment-414197777, or mute the thread https://github.com/notifications/unsubscribe-auth/AA1NyWxq3LuO-IXqF-enrNQZyybS8XOpks5uSkJ8gaJpZM4P1rR2 .
Another user signing on origination, also he posted on arc-discuss. openarc shouldn't allow arc-auth-res to be signed on the ams.
it would be good to know which header being signed breaks things on the Gmail side.
Running through dkimpy or anything isn't going to help if you redact data that's in the signature.
The openarc.conf manpage says it will add all SHOULD headers per the RFC. Without a SignHeaders config line, it does not. Either the manpage is wrong or the code is wrong.
On Tue, Aug 21, 2018, 7:48 PM kurta notifications@github.com wrote:
+Brandon
That's good info but not a bug in openARC 😀
--Kurt
On Sun, Aug 19, 2018, 22:00 Matt Domsch notifications@github.com wrote:
I had to use this in my openarc.conf file: SignHeaders
to,subject,message-id,date,from,mime-version,dkim-signature,arc-authentication-results
so that only those headers were included in the signature calculation. Then gmail validates the arc signature properly.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/trusteddomainproject/OpenARC/issues/66#issuecomment-414197777 , or mute the thread < https://github.com/notifications/unsubscribe-auth/AA1NyWxq3LuO-IXqF-enrNQZyybS8XOpks5uSkJ8gaJpZM4P1rR2
.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/trusteddomainproject/OpenARC/issues/66#issuecomment-414868703, or mute the thread https://github.com/notifications/unsubscribe-auth/AAqDqrLYx4ly88GhY57rdzBnvnwUhy5xks5uTKokgaJpZM4P1rR2 .
If it is signing Received headers (as implied in the arc-discuss thread) then I would suggest that the bug is how it behaves in the absence of explicit header signing configuration.
I'm not aware of anyone or any spec that suggests such behavior to be advisable.
--Kurt
On Tue, Aug 21, 2018, 18:04 Matt Domsch notifications@github.com wrote:
The openarc.conf manpage says it will add all SHOULD headers per the RFC. Without a SignHeaders config line, it does not. Either the manpage is wrong or the code is wrong.
On Tue, Aug 21, 2018, 7:48 PM kurta notifications@github.com wrote:
+Brandon
That's good info but not a bug in openARC 😀
--Kurt
On Sun, Aug 19, 2018, 22:00 Matt Domsch notifications@github.com wrote:
I had to use this in my openarc.conf file: SignHeaders
to,subject,message-id,date,from,mime-version,dkim-signature,arc-authentication-results
so that only those headers were included in the signature calculation. Then gmail validates the arc signature properly.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub <
https://github.com/trusteddomainproject/OpenARC/issues/66#issuecomment-414197777
, or mute the thread <
.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/trusteddomainproject/OpenARC/issues/66#issuecomment-414868703 , or mute the thread < https://github.com/notifications/unsubscribe-auth/AAqDqrLYx4ly88GhY57rdzBnvnwUhy5xks5uTKokgaJpZM4P1rR2
.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/trusteddomainproject/OpenARC/issues/66#issuecomment-414871753, or mute the thread https://github.com/notifications/unsubscribe-auth/AA1NycBv10i_6rA47FEqYu5PPVxRthg9ks5uTK4MgaJpZM4P1rR2 .
The code should follow the RFC, and I'll fix that, but that doesn't mean this should be failing. The same header field canonicalization code is applied regardless of which specific headers are being covered.
I'm going to see if I can work with our contact at Gmail to figure out which side has something wrong.
Just to be clear: The code that does selection of header fields to sign should follow the RFC, but currently doesn't. I'll fix that. But apart from that, it shouldn't matter what header fields are getting signed, because they all get handled the same way.
@mdomsch: Can you still reproduce this problem with Beta1? I sent a sample message, key, and signed message to a contact inside GMail and he said his results matched ours.
Beta1 lacks the patch from PR#100 and it's not a clean cherry-pick. Can I use develop HEAD at 824f49bf558f1f34712217a6687fc9e82c0938a5 instead?
On Fri, Sep 28, 2018 at 11:58 AM Murray S. Kucherawy < notifications@github.com> wrote:
@mdomsch https://github.com/mdomsch: Can you still reproduce this problem with Beta1? I sent a sample message, key, and signed message to a contact inside GMail and he said his results matched ours.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/trusteddomainproject/OpenARC/issues/66#issuecomment-425499899, or mute the thread https://github.com/notifications/unsubscribe-auth/AAqDqqvmnkeDi7jWR12VZ08eSPZ6rePUks5uflTwgaJpZM4P1rR2 .
Just to be clear: The code that does selection of header fields to sign should follow the RFC, but currently doesn't. I'll fix that. But apart from that, it shouldn't matter what header fields are getting signed, because they all get handled the same way.
I'm still seeing this problem with Google Failing ARC while echo@openarc.org says all is fine.
Code Used: Develop branch 20190808 commit 56b22d8 Problem persists with or without SigningHeaders in config file (as above) - headers which get signed are actually same either way.
Google Header has: Authentication-Results: mx.google.com; ... arc=fail (test pass); ..
dkim, dmarc and spf all pass ok according to google. Just ARC has the fail.
User error - google does this in test mode - removing test mode and works fine.
Wanted to write on mailing lists, unfortunately they are non-existent? (as per: http://www.trusteddomain.org/mailman/listinfo/ )
Using same key to sign as used to sign dkim headers google fails signature verification.
Build on FreeBSD 10.3:
Using postfix, milters after Amavisd.
OpenARC config used:
E-mail headers (replace with zzzomeone in case of gmail and gijsje in heteigenwijsje case):