Tsuneki Ohnishi wrote:
So, my point is that what do you think of the idea to have
an new entry in ADSP "discard-if-no-sig", which allows
senders to declare messages without DKIM signature should
be discarded?
If that's possible, it makes our job a lot easier and faster.
Hi.
You are basically asking to make a distinct difference between:
1) a real no signature message versus
2) a message who's signature is broken (invalid).
The DKIM specification says that a broken signature is the same as no
signature message.
It is important to know the difference because if you are concern
about a Real No-Sig versus a Broken one where a Real No-SIG is
discarded but a Broken one is not, then whats to stop the Bad Guy from
adding a broken signature by design and for the sole purpose of making
sure the message is now indeterminate and you don't filter it?
The problem with DKIM is the is the "stuff in the middle" - A real
no-sig message can be made to work, as well as when there is a valid
signature.
It the faults of the system that is challenging - what do you do with
failures and what makes it even more difficult is the specifications
has evolved to one where where any system, middle-ware or hop, can
break or remove an author domain signature without restrictions. This
was done to appease the LIST managers, 3rd party signer and the
reputation market.
IMO, I think DISCARD should cover what you want, but you have to view
it as a strong policy with no exceptions, i.e., a broken signature is
just as bad as no-signature and more importantly, no interference or
3rd party signers can override the message author domain security
expectations.
If you allow for broken signatures to be "acceptable" partially or
otherwise in an ADSP setup, then it just confuses the intent and it
potentially feeds bad guys to give you broken signatures because that
is "OK" by you.
Right now, there is no incentive for bad guys to adapt or change. They
can remain in legacy operations (no signature) because there is no
wide adoption or foundation for DKIM policies or the handling of
policy faults.
Having a "MUST SIGN" policy widely adopted (and supported) would begin
to make a change in legacy operations. They will most likely avoid
your POLICY protected domain. But if you allow for broken ones, then
they can adapt by adding a spoofed but broken signature.
--
Hector Santos, CTO
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html