Ian Eiloart wrote:
Sorry, Pareto Efficiency (an economics concept) isn't something that
I was familiar with. I was referring to an analysis Pareto charts
(a quality engineering tool). Same guy, different concept.
Actually, different guys (sciences, engineering disciplines), same
concept. :)
A Pareto chart looks at the different causes of a problem (signature
breakage)
and determines the relative frequency of each cause. This helps you to
determine the benefit (but not the cost) of addressing each cause.
And this provides an optimality. The purpose is to find an "condition"
where it is Pareto Efficient (The best you can do without losing
maximum benefit) because, like most things in life, there are always
imperfections and most factors are interrelated in some fashion. So
while its a tool to help identify problems, benefits, weakest,
critical points, etc, there is a cause and effects and Pareto
Optimality always comes into play. In a closed environment you have
boundary conditions, and how much of one thing is done to correct,
tweak, turn a knob in a process control plant, it can have an effect
the other things and most important, a change which can move you away
from being Pareto Efficient (optimal).
My stats tell me that there's not much benefit in trying to persuade
people to adopt relaxed versus simple.
IMV, the specs should not be persuading other than explain what the
purpose and reason for each one - let the reader decide.
By and large, they're already doing that. For Exim users, that
may be because relaxed is the software default.
Agree, defaults is definitely a contributor especially for new
deployments starting out.
But, they do suggest the header mismatches are 10 times more
common than body mismatches, so it may be worth focussing here.
But in what way? We already have relaxed C14N for headers. I
proposed the STRIP method in 2005 and that resolved the CRLF related
issues I saw back then.
Back in July 2005, I proposed the bh= among other diagnostic items for
a "DKIM-Signature-Debug" debugging header of the header/body C14N thing:
http://www.imc.org/ietf-mailsig/mail-archive/msg01817.html
The bh= was added to the August 2006 base-01 draft. After the bh=
hash is checked, its impossible to tell where the DKIM failure occurs
afterwards (hash wise). The only extra debugging item you have it
adding z= to see if any header value was changed.
Personally, based on what I see, the signer should consider reducing
the headers its signed and focus on the persistent core header never
expected to change and even within the core headers, it definitely
should avoid signing headers that are guarantee to change based on a
known path it will take - like for an MKM, consider not hashing the
5322.Subject tag and use "l=" when the target path is known to be a
list adding a footer.
So with the Pareto Chart, we can include MLM and target/path as two of
the items.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html