On 08/Nov/10 15:52, Hector Santos wrote:
Alessandro Vesely wrote:
2. The DKIM spec should probably say that signers need to sign valid
messages, and, therefore, SHOULD NOT sign things like this. Text
along the line of this might work well:
"Signers SHOULD take reasonable steps to ensure
that the messages they're signing are valid according to [RFC 5322,
etc]." Leaving the definition of "reasonable" out allows flexibility. It
may be waffly, but I like the approach in this case.
+1. Enforcing some RFC conformance is a task that many MTAs can
(optionally) do natively.
But DKIM can not make that presumption that is the prevailing nature
of "many" MTAs. At best, it can RECOMMEND that integration DKIM into
a mail system that for BEST results, a general filter would address
this issue.
Yes. If there will ever be an "MTA considerations" appendix, it may
prompt MTA developers to provide for filtering callbacks at the right
points.
But it can't assume that will be possible as it might mean a
software change. Hence the better DKIM software will offer a direct
solution that COULD be turned off when the MTA is capable of doing
the filter itself.
Anything we change in the protocol may imply software changes.
For example, OpenDKIM is a package mainly for the Sendmail MTA. It may
have or will have a MTA milter to check for RFC 5322 compliance.
However, the I believe the software also allows has a DKIM only
component that can be used in other MTAs. You don't know if these
other MTAs will have the same kind of filter DKIM is expecting in
order to have clean results.
Yes, the library component of OpenDKIM provides for just DKIM (well,
it also has some generic utilities, e.g. for parsing mailboxes.) It
works equally well with different MTAs as offline.
Now take Alt-N pure C/C++ DKIM API with no tie-ins to any MTA. It has
an non-overhead DKIM verifier option that deals this multiple
5322.From issue directly and independently from any other layered
requirement.
However, that feature makes for more difficult usage. It tells the
caller that a given signature failed to verify by delivering a status
of DKIM_UNSIGNED_FROM. Now, suppose the caller is a forensic tool,
rather than an MTA filter. The tool is interested in knowing whether
the signature validates, but it cannot be sure that the reported
status was the /only/ problem with that signature. In facts, it'd be
better off disabling such verifier option. (And it can be disabled
because it is not mandated.)
Now for MTA message filters. Why should a DKIM library hide the
simple facts and opt for telling them what to do instead? It is quite
trivial to count the "From" fields in the header. A library can
provide a function that tells whether a given field was signed by a
given signature. Based on such simple facts, a filter may make
various decisions. It may turn out that an unsigned "From" deserves
the same treatment as a failed signature, but are we sure that that is
the only one option whatever the circumstances? Actually, we haven't
observed many occurrences of that attack in the wild.
To me, the latter is the best approach for the specification to take.
Allow Readers of this document to decide how they will implement DKIM
based on the MTA they are using or MTAs they are targeting.
However, if that behavior were mandated, it would affect all compliant
libraries, forensic tools notwithstanding.
I prefer to see a "blackbox" model for DKIM where its interface points
are well defined. Its input was well described with stated boundary
conditions and its output is well defined and described with a view on
being a feed for possible message filters/handlers.
+1.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html