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: [email protected] [mailto:[email protected]]
>> On Behalf Of Douglas Otis
>> Sent: Monday, October 18, 2010 3:33 PM
>> To: [email protected]
>> 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
