"no AR headers found, chain terminated" on Arc.sign

Bug #1808301 reported by Cyril N. on 2018-12-13
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Scott Kitterman

Bug Description


I'm re-opening the issue #1748146 as it is not closed.

I'm trying to SIGN a message, not verifying it, but it appears it's not possible using dkimpy.

I've simply downloaded a basic email from GMail, which contains some AR headers, that are not from me (but from GMail), and we I run the following:

    dkim.arc_sign(data, b'arc-20171221', b'improvmx.com', open('./certs/id_rsa', "rb").read(), b"improvmx.com")

I get the following message in the logs:

> "no AR headers found, chain terminated"

It's normal that there no AR headers for MY domain since I want to sign this email, not verifying it.

I have attached the headers from the email I try to sign. I changed the critial information with "redacted", so all the current signatures/seal won't work, but the issue remains.

Cyril N. (cnicodeme) wrote :
Cyril N. (cnicodeme) wrote :

Any news about this?

On Monday, January 07, 2019 10:29:39 AM you wrote:
> Any news about this?

I have not had time to try to replicate it, but I haven't forgotten about it.

Scott K

Scott Kitterman (kitterman) wrote :

I have looked into this a bit. I'm not yet convinced everything is working 100%, but this particular bit is. It's looking for the Authentication-Results header field added by your domain when you received the message. In particular, the authserv-id in the A-R field in message must match the srv_id value passed to the function (the last parameter you pass in dkim.arc_sign in your example).

This makes sense for ARC because an ARC signature is meant to seal your local A-R results (as well as preserving a previous chain if one exists). It starts with your local A-R. Starting an ARC chain based on someone else's authentication verification would be a violation of the protocol.

Clearly this needs to be better documented, so leaving the bug open for better documentation.

Changed in dkimpy:
importance: Undecided → Medium
assignee: nobody → Scott Kitterman (kitterman)
status: New → In Progress
milestone: none → 0.9.2
Changed in dkimpy:
status: In Progress → Fix Committed
Scott Kitterman (kitterman) wrote :

2019-04-14 Version 0.9.2
    - Fix the arcsign script so it works with the current API (Note: the new
      srv_id option is the authserv_id to use in the ARC signatures - Only AR
      fields with an authserv-id that matches srv_id will be considered for
      ARC signing)
    - Fix cv=none processing for initial signature in chain
    - Add additional text documenting use of srv_id for ARC signing to
      docstrings and man 1 arcsign (LP: #1808301)
    - Use same line seperator for output as input in dkimsign/arcsign
      (LP: #1808686)
    - Refactor canonicalization.py strip_trailing_lines to avoid using re for
      more consistent processing across python versions (Thanks to Jonathan
      Bastien-Filiatrault for the change)
    - Refactor header folding for more consistent results, including reduced
      stray whitespace (Also Jonathan Bastien-Filiatrault)
    - Don't log message headers and body unless explicitely requested. This
      should also reduce memory usage on large messages. (Jonathan
    - Clarify the crlf does not count towards line length in fold
    - Adjust fold maxlen to one shorter for lines after the first, since they
      already have a leading space (LP: #1823008)

Changed in dkimpy:
status: Fix Committed → Fix Released

In dkimpy 0.9.2 I also fixed the arcsign script that's shipped with the
package so it works. If you still can't get your code to work, try that. If
that works, you can look at it's code (which is very simple) for an example.

Scott K

Cyril N. (cnicodeme) wrote :

Hi! Finally following up on this issue.

I discovered the issue was that the email I was trying to sign didn't contain any AR headers (Authentication-Results). I thought these would be generated when signing the document but it appears that it's not the case.

Does DkimPy provide a way to generate AR headers? Does it do this when signing with DKIM?

Scott Kitterman (kitterman) wrote :

AR header fields are generated on receipt, not transmission. All dkimpy does for this case is provide information to the calling application about if the signature verifies or not. It's not very complex to do. Look around line 320 in https://git.launchpad.net/dkimpy-milter/tree/dkimpy_milter/__init__.py for an example.

ARC though is looking for the previous recipient's AR fields, so you adding one isn't what it's looking for. As I said last time, I'd look at arcsign for a working example.

Cyril N. (cnicodeme) wrote :

What I had missed was the fact that my emails didn't necessarily have AR header set (I forward emails and some of them don't have these). I was expecting your library to make one, because of my lack of knowledge about AR/ARC at the time.

It all makes sense now, thanks for your time and your help :)

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments