-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Alessandro
Vesely
Sent: Monday, November 08, 2010 9:28 AM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Getting resolution on the "double header" 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.
Two points about that:
1) The proposed 8.14 does bring up some MTA considerations relevant to the
issue we've been discussing.
2) I just introduced a draft intended to become a place to collect discussion
about how best to handle common malformations, and this could include the case
we've been discussing. It's intended to get BCP status, but I don't think we
want to work on it in this working group. (draft-kucherawy-mta-malformed if
anyone wants to provide feedback.)
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.
Just to be precise: OpenDKIM includes a filter that uses the milter protocol
to talk to MTAs, but is not "mainly for" any one MTA. Postfix and Oracle's MTA
(formerly Sun JMS) can both use it as well since they have adopted milter.
But it also includes a library that is completely MTA agnostic, and in fact is
in use in production at AOL and Yahoo with whatever MTAs they're using there.
The filter already does the RFC5322 checking, but the library currently doesn't
(apart from erroring out if the input message doesn't contain a From field,
since RFC4871 needs that). It's deliberately a pretty pure partition wherever
possible. However, I have opened an RFE to add the more thorough checking as
an option to the library in case a filter developer doesn't want to bother but
is concerned about this issue.
-MSK
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html