I think most people understand this:
- DKIM "SHOULD" be checking its input,
- With increase awareness, the backend MTA receivers "SHOULD"
checking for these "Special RFC5322" multiple header issues.
Whether SHOULD should be changed to MUST is not a concern to me,
either way, there is guidelines the DKIM component and the system it
is integrated into needs to address as a new consideration to lock
down related implementation requirements.
How this is done (written) in 4871bis, I leave the RFC doc experts to
do this and if they need to "write" it in a way that will not slow
down DKIM to draft standard, as long as the above semantics are
provided, I think the job is done.
The h=from:from "kludge" I see as a temporary solution for engines
that are able to work with that preparation and I am on the fence if
this should be added to the 4871bis. I see it as a short term note
because ultimately, even will be on the same plane to understand the
RFC 5322 mail bots need to do this, especially on the receiver side.
But more important, I think it does require code change and its not
just an Operator DKIM options.
SSI and ALT-N has agreed that SSI can enhance the library for general
purpose usage with the updated DKIM flexibility needs, especially on
the ADSP extension side as it was hard coded for ADSP as it is written
today with a subjective but hard coded rule on how DKIM=ALL is
interpreted.
The changes have not be submitted to the version control system yet
and won't be until Alt-N final approval.
I changed ALT-N DKIM API (LIBDKIM) and it would able to now offer the
h=from:from kludge but this was not the reason for the change.
I can't say how OpenDKIM does it, but the LIBDKIM default minimum API
usage behavior is to sign all the headers and it is hard coded to skip
these headers only:
X-*
Authentication-Result
Return-Path
Howwer, the LIBDKIM API provides two application level methods on what
headers to sign or skip:
1) Call Back per Header with a boolean result.
return true - sign it
return false - skip it (don't sign it)
2) optional string szRequiredHeaders
For general purpose usage of the API, the callback method will not be
possible for embedded p-code server side languages, so the only other
way is to pass the optional szRequiredHeaders string.
However, szRequiredHeaders only allows you to set the headers to
include it might have skipped. It is not a way to define the
exclusive specific headers to sign only.
So I added a logical flag option:
int nUseRequiredHeadersOnly; // 1 - used szRequireHeaders and
// exclude the rest. 0 - fallback
// to default sign all headers
// behavior
that allows you use szRequiredHeader as the only headers to sign.
I did this because it was signing headers I didn't think it sign
including Received: which 4871 recommends as a SHOULD NOT.
I wanted operator defined local policy options to specified headers it
wanted to sign on a per DKIM author/signer domain setup basis. From
an product engineering standpoint, it needs this flexibility.
But the current open source version is not capable of using this
h=from:from kludge and that probably means any implementation of this
API can't do it as well unless it has altered it to do something like
we did.
Anyway, my main point is that I don't think we will cover all possible
methods to resolves without deeper working group analysis and hence
delays. But we can say the basic ideas as above:
- DKIM SHOULD|MUST checks it main inputs
- Receiver MTA SHOULD|MUST check RFC5322 more strongly with
a specific guidance on what it should focus on in order for
DKIM to be protected.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Murray S. Kucherawy wrote:
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Douglas Otis
Sent: Monday, October 18, 2010 3:33 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Data integrity claims
Should the charter of a security related protocol need to anticipate
minor modifications to a verification process, that appears essential
for ensuring a DKIM signature is not inappropriately associated with an
incorrect From header field?
Any effort, security or otherwise, needs to scope itself correctly. We, for
very good reasons, chartered ourselves originally to come up with a system
that requires minimal infrastructure changes.
I claim that inserting an Authentication-Results field is minimal, as it is
incremental. But if we also claim MUAs and users pretty much ignore that,
which is the case today, then it (or any solution that is strictly an
annotation of some kind) fails to have the protective impact you're seeking.
The only option then is to obstruct delivery in some way, and that is not
incremental and thus not minimal, and certainly pushes the boundaries of our
charter (e.g. [1]).
Rather than expecting changes to a plethora of consumers of DKIM
results, which might be used for sorting or display, ensuring PERMFAIL
occurs whenever replicate From header fields are detected ensures DKIM
will not be complicit in deceiving consumers of its results.
This, again, fails to deliver on your stated goal since the PERMFAIL result
is almost completely invisible. On the other hand, if you claim MUAs will
adapt to DKIM to show what parts of a message were covered by a validated
signature, then we don't really need to provide any normative requirements
because MUAs have already figured out what they need to do.
[1] http://tools.ietf.org/wg/dkim/charters?item=charter-dkim-2006-07-03.txt
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html