Ralph,
> On 12.09.10 10:46, mouss wrote:
> > Received headers should not be included in the DKIM signature. so
> > removing them won't invalidate DKIM.
>
> If you have a look at my message which you quoted, you'll see
> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=seichter.de; h=
> content-transfer-encoding:content-type:content-type:in-reply-to
> :references:subject:subject:mime-version:user-agent:from:from
> :date:date:message-id:received:received; s=sep2010; t=
> 1284280386; x=1286872386; bh= [...]
> My interpretation of this is that amavisd-new will DKIM-sign "Received:"
> headers if they are present.
Yes, by default Received header fileds are signed by amavisd-new
(it does not violate RFC 4871, it just does not match its suggestion),
but this is configurable.
amavisd-new-2.6.0 release notes
An associative array %signed_header_fields controls which header fields
are to be signed. By default it contains a standard (RFC 4871) set of
header field names, augmented by some additional header field names
considered appropriate at the time of a release (RFC 4021, RFC 3834).
In addition a 'Sender' header field is excluded because it is frequently
replaced by a mailing list, and as the RFC 2821 mandates there can only
be one such header field the original one is dropped, invalidating a
signature. Also the 'To' and 'Cc' are excluded from a default set because
sendmail mailers are known to gratuitously reformat the list, invalidating
a signature. A value in key/value pairs of %signed_header_fields is
currently interpreted as a boolean, but stick to values 0 and 1 for now
to allow for future enhancements.
The default set of header fields to be signed can be controlled
by setting %signed_header_fields elements to true (to sign) or
to false (not to sign). Keys must be in lowercase, e.g.:
$signed_header_fields{'received'} = 0; # turn off signing of Received
$signed_header_fields{'sender'} = 1; # turn on signing of Sender
$signed_header_fields{'to'} = 1; # turn on signing of To
$signed_header_fields{'cc'} = 1; # turn on signing of Cc
> Maybe there's something amiss anyway, because
> "subject:subject" or "date:date" look kind of strange?
This is intentional, but is configurable:
amavisd-new-2.6.4 release notes
- support inclusion of null header field names in an 'h' tag of a DKIM
signature generated by amavisd for specified header field names, thus
preventing third parties from prepending additional occurrences of
these header fields without breaking a signature; useful for example
for protecting a recipient's mail reader or a filter from being tricked
by supplying a duplicate From or Subject header fields; the protection is
requested by specifying a value larger than 1 in %signed_header_fields,
e.g.:
$signed_header_fields{'from'} = 2;
$signed_header_fields{'subject'} = 2;
$signed_header_fields{'message-id'} = 2;
$signed_header_fields{'content-type'} = 2;
Please restrict values used in %signed_header_fields to 0, 1, or 2,
consider other values reserved for future use.
By default the following header fields are protected from duplicates by
a DKIM signature generated by amavisd: From, Date, Subject, Content-Type.
To revert to a classical behaviour, set their value in %signed_header_fields
to 1, e.g.:
$signed_header_fields{lc($_)} = 1 for qw(From Date Subject Content-Type);
Mark
