Steve Atkins wrote:
Hector wrote:
The spec says
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).
That means to me it MUST exist to be signed.
h=From for a message that has no From: header when signed
means that the message must have no From: header when the
signature is validated, I think? And 5.4 just says you must include
From in the h= tag, not that it must exist.
A missing From: field makes the message not a 5322 message,
but I'm not sure what that implies for DKIM.
I see your point.
Since a 5322.From is a required header for a valid RFC5322 message
(From and Date are the two that required by RFC2822 and RFC5322, for
RFC822, it requires the To (or BC) as well), I believe the expectation
that it exist in the message for DKIM to imply it must exist in h=From.
For our MDA/MSA, it will definitely invalidate an incoming message
header but I don't recall the details. From old discussions in
IETF-SMTP, I am pretty sure most MDA/MSA will enforce a 5322.From as
well. I think the exception if when the client is local (internal) or
maybe authenticated.
The Alt-N DKIM API we are using will definitely fail to sign the
message if a From is missing and it will fail to verify as well
because there has to be a h=from and matching 5322.From.
This probably means that it should clarified what that 5.4 sentence
means and also the next section 5.5
5.5. Recommended Signature Content
..
The following header fields SHOULD be included in the signature, if
they are present in the message being signed:
o From (REQUIRED in all signatures)
It reads to me that From is the SHOULD exception to a MUST.
But I can definitely see what you mean, because if it means that you
have to add h=from without a real 5322.From, then a signature might
be signed and be technical DKIM valid but only against those systems
that are not enforcing a 5322.from header.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
