Alessandro Vesely wrote:
On 25/May/11 20:23, Dave CROCKER wrote:
That's not likely to be the goal of this sort of exercise. Rather, it
will be to choose a set of particular types of breakage, ignoring others.
For an effort like that, it is not meaningful to come up with additional
types of breakage, since there is no attempt to cover such additional
examples.
Of course, a signature cannot survive a deliberate attempt at breaking
it. However, earlier analysis considered man-in-the-middle attacks
like changing, e.g., "Amoeba yeast" into "Amo ebay east" [Bryan
Costales, Thu, 04 Aug 2005]. We don't know how likely such kind of
attacks may be, since only tight canonicalizations were standardized.
By introducing a loose canonicalization we may learn whether signature
survivability affects DKIM adoption. If wider usage introduces
attacks, we can switch back to current canonicalizations --in case
downgrades will have gone away-- or design yet another one,
approaching just the tightness we need. My appeal is for not imposing
monotonicity to successive approximations, and allow erring on the
too-lose side as well.
It seems the DKIMnomics are proving not to be there. It's like beating
a dead horse dealing with the inconsistent considerations. With so
much failure with your own domain usages, it has become a big concern.
Its not a big deal when your own domain failures come back into your
own system (via list distribution) because you can make the
exceptions. But that knowledge is not known by others seeing the same
message. Its not like the world has "SPF-like" exposed information or
3rd party vouching information for DKIM receivers, or users to at
least to get a clue.
The irony is the seeing a high validation success among the unknown
spammers w/o using unknown list to distribute their junk. Since we
separated the "question" between the resigner and the purported
author, where are the benefits? Your own domains are lost on list
that resign as well on those that don't resign.
Seeing the following does not give one much hope:
+-----------------------------------------------------------------------+
| LIST-ID SIGNER % FAIL |
|-----------------------------------------------------------------------|
| 6522.31.email.enviomasivoempresarial.com esp2.it 0 |
|-----------------------------------------------------------------------|
| 8388.19.h3h8.s05.it emailingtools.it 0 |
| 8388.23.h3h8.s05.it emailingtools.it 0 |
| 8388.40.h3h8.s05.it emailingtools.it 0 |
| 8388.51.h3h8.s05.it emailingtools.it 0 |
| 8974.19.h9g4.s06.it emailingtools.it 0 |
|-----------------------------------------------------------------------|
| Developers.winserver.com mapurdy.com.au 100 |
|-----------------------------------------------------------------------|
| dkim-ops.mipassoc.org mipassoc.org 0 |
|-----------------------------------------------------------------------|
| ietf-822.imc.org cybernothing.org 100 |
| ietf-822.imc.org tana.it 100 |
| ietf-822.imc.org mrochek.com 100 |
| ietf-822.imc.org isdg.net 100 |
| ietf-822.imc.org messagingengine.com 100 |
|-----------------------------------------------------------------------|
| ietf-dkim.mipassoc.org mipassoc.org 0.2 |
|-----------------------------------------------------------------------|
| ietf-pop3ext.imc.org gmail.com 100 |
|-----------------------------------------------------------------------|
| ietf-smtp.imc.org santronics.com 100 |
| ietf-smtp.imc.org tana.it 100 |
| ietf-smtp.imc.org gmail.com 100 |
| ietf-smtp.imc.org sonnection.nl 100 |
| ietf-smtp.imc.org taugh.com 100 |
| ietf-smtp.imc.org resistor.net 100 |
| ietf-smtp.imc.org mrochek.com 100 |
| ietf-smtp.imc.org messagingengine.com 100 |
|-----------------------------------------------------------------------|
| ietf.ietf.org resistor.net 100 |
| ietf.ietf.org cybernothing.org 100 |
| ietf.ietf.org cisco.com 100 |
| ietf.ietf.org mrochek.com 100 |
| ietf.ietf.org iecc.com 100 |
| ietf.ietf.org isdg.net 100 |
| ietf.ietf.org gmail.com 100 |
|-----------------------------------------------------------------------|
| pak-business-26.googlegroups.com googlegroups.com 0 |
| pak-business-29.googlegroups.com googlegroups.com 0 |
| pak-business-60.googlegroups.com googlegroups.com 0 |
|-----------------------------------------------------------------------|
| rss-public.yahoogroups.com yahoogroups.com 0 |
|-----------------------------------------------------------------------|
| spf-discuss(_at_)listbox(_dot_)com talamasca.ocis.net
100 |
| spf-discuss(_at_)listbox(_dot_)com gmail.com
100 |
| spf-discuss(_at_)listbox(_dot_)com listbox.com
0 |
|-----------------------------------------------------------------------|
| spf-help(_at_)listbox(_dot_)com gmail.com
100 |
| spf-help(_at_)listbox(_dot_)com listbox.com
0 |
|-----------------------------------------------------------------------|
| WINServer.santronics.com megabytecoffee.com 100 |
| WINServer.santronics.com mapurdy.com.au 100 |
| WINServer.winserver.com megabytecoffee.com 100 |
| WINServer.winserver.com gmail.com 100 |
| WINServer.winserver.com mapurdy.com.au 100 |
+-----------------------------------------------------------------------+
All my signing domain, isdg.net, fails on all the above list and you
can see others in the same list. Its interesting to note, like on
the spf-discuss and spf-help list, only its own signature survive, but
not others. For our winserver.com and santronics.com list, everyone
else signature fails.
Overall, its not about just how it all looks on your own system or
MUA, but how it looks at other systems.
So what is DKIM for? For the unknown? Giving these Valid Signature
SPAMMERS some sort of seal of approval? I don't think so.
+-----------------------------------------------------------------------+
| LIST-ID SIGNER % FAIL |
|-----------------------------------------------------------------------|
| 6522.31.email.enviomasivoempresarial.com esp2.it 0 |
|-----------------------------------------------------------------------|
| 8388.19.h3h8.s05.it emailingtools.it 0 |
| 8388.23.h3h8.s05.it emailingtools.it 0 |
| 8388.40.h3h8.s05.it emailingtools.it 0 |
| 8388.51.h3h8.s05.it emailingtools.it 0 |
| 8974.19.h9g4.s06.it emailingtools.it 0 |
|-----------------------------------------------------------------------|
| pak-business-26.googlegroups.com googlegroups.com 0 |
| pak-business-29.googlegroups.com googlegroups.com 0 |
| pak-business-60.googlegroups.com googlegroups.com 0 |
|-----------------------------------------------------------------------|
| rss-public.yahoogroups.com yahoogroups.com 0 |
+-----------------------------------------------------------------------+
As far as I am concern the highest benefit DKIM can provide is an
explicit POLICY of failure protection. That is where the benefits
comes - when there is a violation of a given practice. But MLM doesn't
work with DKIM with or without policy. So where is the DKIMnomics?
--
HLS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html