[ietf-dkim] draft-ietf-dkim-mailinglists-02 review
hsantos at isdg.net
Wed Sep 15 04:45:45 PDT 2010
Charles Lindsey wrote:
> On Mon, 13 Sep 2010 15:19:05 +0100, MH Michael Hammer (5304)
>> If a domain publishing ADSP discardable has not gotten control of their
>> mailstreams then all I can say is "Darwin was right".
> Darwin was indeed right. But an organism that is not fit to survive may
> struggle on for millions of years before it finally becomes extinct.
> Agreed that domains that asserts discardable SHOULD should have separate
> non-discardable mailstreams more suited to MLMs. But what incentive do
> they have to make this change? So far just some "advice" in Murray's
> draft. Yes, eventually they will all do it right, but "eventually" can be
> an awful long time. In the meantime, MLMs will have to cope.
Darwin's main point is that in chaos there is an infinity towards
equilibrium through adaptation. Its not just about the fittest but who
can capacity to adapt to their environment.
The WG dearth is that we have dampers that restricts adaptation to
occur towards equilibrium.
Things do not have to be negative. We just need to adjust the
specifications. IMV, problem solving is considering is what is more
feasible to change vs what to add. I don't think adding is helping.
For example, adding a proposal to 5322.From, in my view is a show
stopper. It is too drastic and it is only considered because of other
So look at the existing problems and see how they can be fixed so you
don't need to change the 5322.From.
Implementation adaptation has already occurred with a major MTA vendor
DKIM API library:
Adaptation #1: Option to ignore the RFC 4871 5322.From binding
Adaptation #2: interpretation the ADSP=ALL policy as an always
sign by author domain or (any) 3rd party domain.
These adaptations by the major MTA vendor DKIM API is exactly what we
are looking for. They learned what needs to be done to better
implement DKIM and ADSP support. I believe they resolve most of the
issues we been talking about regarding MLMs.
Hector Santos, CTO
More information about the ietf-dkim