[ietf-dkim] Whither 4871bis?
dotis at mail-abuse.org
Mon May 11 11:17:39 PDT 2009
On May 9, 2009, at 11:06 PM, Eliot Lear wrote:
> On 5/9/09 2:01 AM, John Levine wrote:
>>> with some editorial changes I guess. I've not seen anyone suggest
>>> that we add features or remove a raft of features or make other
>>> substantial changes.
>> I'm with Steve, I'd like to deprecate the useless stuff.
> I like deprecating useless stuff, but before we do that I would like
> to see broader implementation, and again, specifically in mailing
> list managers, before we decide what is useless.
Agreed. It appears merging errata now means explaining once again why
features were included and why their possible use should be supported,
even if only to generate clueful error messages. It may takes years
before issues being addressed by some feature becomes apparent. This
may occur only after greater adoption and MUA integration where
reliance and annotations make their impact perhaps several years from
For example, providers may insist upon adding a disclosure
notifications at the end of emails. The l=value, when used
appropriately and is properly supported, could ensure a message
remains in an state that will not prohibit non-repudiation, by being
explicit about the body length. This feature may also allow providers
a means to escape the hashing large attachments, for example.
DKIM is too new. Anything looks complex until people get used to it.
I also fear there are those with conflicted interests which might wish
to emasculate DKIM to better enable competing strategies. DKIM needs
to be better protected from change based upon one's perception of
More information about the ietf-dkim