Aditya Divekar writes:

According to the draft, here <https://tools.ietf.org/html/draft-andersen-arc-00#section-5.2>, the ARC-Seal header is constructed from the referenced message signatures given by the "k" tag. I didn't understand this part clearly.

The "k" tag has been removed from the most recent version 02 (2016/02/08). Note: although I-Ds expire automatically after 6 months, they can be superseded by new versions at any time. Always check for a more recent version. The tools.ietf.org site is very nice because you can also get diffs to see what you missed (note that many URLs reference less fancy archives, so if you bookmark one of those it's useful to edit it to refer to a full-service site such as tools).

Do we need to specify the headers (i.e. the ARC-Message signature and ARC-authentication results) that we want to seal in the "k" tag just how we would use the "h" tag in the DKIM signature?

Earlier drafts of the I-D were more than a little confusing here. I think it's much better now, but feel free to ask questions. The fields added by a particular mediator will be linked by the "i" tag, see I-D sec. 5.1.1.1.1, 5.1.2.2.3, and 5.1.3.1.

Also, ARC signatures use the "h" tag in the same way as DKIM, except that the requirements for exactly which headers are are different. (This is intended to ensure that ARC headers, which by definition are *not* authorized by the sending domain, are not mistakenly used as DKIM signatures, which by definition *are* authorized by the sending domain. I'm not sure whether this makes sense, but OTOH I don't see how it can hurt.) Exactly which headers are signed in an ARC-Seal are fully specified by the protocol.

(The usage of the "k" tag isn't clear to me.)

Mostly the protocol syntax and semantics of ARC are specified in RFC 6376 (see section 5.4 of the I-D). Selectors are defined in section 3.1. In the I-D, only the new ARC-Seal field is described in full. ARC-Message-Signature and ARC-Authentication-Results are described in terms of differences from the normative RFCs (RFC 6376 for signatures and RFC 7601 for authentication results).

By the way, top-posting (especially without trimming) should be avoided in technical discussion. See http://turnbull.sk.tsukuba.ac.jp/Teach/ESES/socsys-1.html for the technical advantages and disadvantages of top-posting and interlinear styles. Also, note that in mature projects (and specifically Mailman and Python) most of the senior developers will be old enough to have been trained in and developed a preference for interlinear posting, and especially trimming. Nowadays untrimmed top-posts are hard to avoid so people are building up tolerance for them, but you can make friends by taking care with your posting style.

Steve