Rolf,
Thank you for your quick and informative reply.
If the return path is not an option for signing, what other fields would
OpenDKIM be able to sign, not including the sender header.
Regards,
Jonathan
On Fri, Aug 12, 2011 at 3:45 PM, Rolf E. Sonneveld <
R.E.Sonneveld_at_sonnection.nl> wrote:
> **
> On 8/12/11 8:07 PM, Jonathan Casco wrote:
>
> Hi,
>
> I was curious as to how, if it is possible, to have OpenDKIM sign for
> multiple address fields. Ideally I would like to be able to have OpenDKIM
> sign both the from address as well as the return address.
>
>
> The return address (envelope From) is not part of the headers and as such
> cannot be part of a DKIM signature. In theory, a representation of the
> return address (Return-Path) could be subject to signing, however, as per
> RFC5321:
>
> When the delivery SMTP server makes the "final delivery" of a
> message, it inserts a return-path line at the beginning of the mail
> data. This use of return-path is required; mail systems MUST support
> it. The return-path line preserves the information in the <reverse-
> path> from the MAIL command. Here, final delivery means the message
> has left the SMTP environment. Normally, this would mean it had been
> delivered to the destination user or an associated mail drop, but in
> some cases it may be further processed and transmitted by another
> mail system.
>
>
> So, normally at the moment of signing there is no Return-Path present and
> if there is one present, it is most probably not the one that will be
> inserted during 'final delivery' by the mail server that drops the message
> into a mailbox. This means that when using a Return-Path if there's one
> present at the moment of signing, there is a fair chance that it will break.
>
> See also par. 5.4 of RFC4871, which does not forbid to use the Return-Path
> but strongly advises not to use it:
>
> 5.4. Determine the Header Fields to Sign
>
> The From header field MUST be signed (that is, included in the "h="
> tag of the resulting DKIM-Signature header field). Signers SHOULD
> NOT sign an existing header field likely to be legitimately modified
> or removed in transit. In particular, [RFC2821 <http://tools.ietf.org/html/rfc2821>] explicitly permits
> modification or removal of the Return-Path header field in transit.
> Signers MAY include any other header fields present at the time of
> signing at the discretion of the signer.
>
>
> Regards,
> /rolf
>
Received on Fri Aug 12 2011 - 20:35:41 PST