MH Michael Hammer (5304) wrote:
> Hector wrote:
>
ASP cracks opens the door to DKIM abuse and your unintentional "typos"
example proves it. Do you think software is going to know the
difference now if your 3rd party signature was a typo,
syntactically valid but unexpected or otherwise?
ASP has removed a 100% ZERO FALSE POSITIVE PROTECTION
mechanism and it will not help DKIM signers if they can buy
into this ASP in its flawed state.
Hector,
Could you elaborate on your comment re false positive protection?
Hi Michael,
Since SSP-00, SSP-01, including DSAP-00, these DKIM Policy drafts all
provides three basic policies which provide a restrictive declaration by
the domain of what it expected or doesn't expected in mail transaction
purported to be from them (their domain is used in the From: header).
In SSP-00, these were:
o=- STRONG (signature required, 1st or 3rd party allowed)
o=! EXCLUSIVE (signature required, no 3rd party)
o=. NEVER (no mail expected)
These are 100% zero false positive because that is what the domain
declared and any rejection based on these are 100% perfectly acceptable.
They do not care if there was an external employee using its domain on
hotels, eCard services, Bulk Mailers services, etc. For them,
Roaming Users is not an issue and they expect receivers to honor the
stated policies by performing policy inconsistency checks and rejecting
the messages conflicting with these policies. No questions asked.
In DSAP, it followed these same concepts.
In SSP-01, these policies were now defined in difference ways:
The SSP-00 NEVER policy was now done in SSP-01 by having a DKIM=STRICT
plus a NULL DKIM domain public key.
The SSP-00 STRONG policy was now done in SSP-01 with a DKIM=ALL (Anyone
can SIGN, but it MUST be signed).
The SSP-00 EXCLUSIVE was now DKIM=STRICT in SSP-01.
Both SSP-00 and SSP-01, offered DKIM signer who wished to operate in
this mode, powerful 100% zero false positive protocol inconsistency and
fraud protection.
With SSP-02/ASP, we lost the powerful SSP-01 DKIM=ALL protection against
3rd party fraud.
The NEVER concept can still be covered using DKIM=DISCARDABLE and a NULL
DKIM public key.
The EXCLUSIVE concept can still be covered using DKIM=DISCARDABLE.
But anything related to 3rd party signers was completely eliminated in
SSP-02/ASP. Even though SSP-02 DKIM=ALL is a "always sign for 1st party
authors" concept, it is basically a DKIM=DISCARDABLE without semantics
on REJECTION. DKIM=DISCARDABLE failures is explicit with the REJECTION
control. DKIM=ALL failures are not.
In short, DKIM=ALL is the SPF version of SOFTFAIL where you can record
it, but you do not take any REJECTION action on it. Just like SPF.
I find this to be a hypocrisy that ASP is repeating the same design and
same negative repercussions in ASP, but in my view in a much more worst
way than SPF.
It will be a worst form of the same SOFTFAIL problem because with SPF it
was a issue of a IP mismatch. It was difficult to make any assessment
on the sender IP not just because of some malicious usage, but because
there were legitimate mail routing issues with SPF that not always in
the form of a single hop MTA to MDA.
But that is not the case with DKIM. Here we have 100% detectable fraud
capabilities that is unrelated to legitimate multiple hope IP issues and
ASP is mandating a flawed inherent policy that RECEIVERS should ignore
certain kinds of obvious fraudulent messages.
--
Sincerely
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