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

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

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.

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
      Bastien-Filiatrault)
    - 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)

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

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?

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.

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 :)