Douglas Otis wrote:
On Feb 5, 2008, at 10:46 PM, Hector Santos wrote:
With SSP-02/ASP, we lost the powerful SSP-01 DKIM=ALL protection
against 3rd party fraud.
An "all" assertion never implied all unsigned messages should be
rejected.
Not in SSP-02, but it was implied in all other previous drafts.
This assertion also never ensured receivers that third-party
handling was avoided.
Sure it did, in SSP-00, SSP-01, it was very clear. We had policies that
either expected it or did not expect it.
This was removed in SSP-02, *intentionally neglectful* of the security
issues this removal creates.
Any damaged signature must be handled as if not
signed.
SSP-02 removes all semantics for REJECTION in policies other than
DKIM=DISCARDABLE where there is a explicit statement for REJECTION. The
implication is sure the DISCARDABLE has clear instructions for REJECTION
and all others do not.
When signature fails and the only different is the policy and one
implies to receivers "These Failure is rejectable" for DKIM=DISCARDABLE
and "The same failures are not rejectable" in DKIM=ALL, not only does
this lack common sense, it is foolish to believe that this inconsistency
will be tolerated by the general case receivers, thus making it much
more difficult to consider DKIM in general.
I am not guessing here, I have a hard time accepting the idea of adding
DKIM to our package because of this. Its going to make life more
difficult, not less, for my customers, I would be irresponsible to add
something filled with flaws, false hope and high potential for more
support issues than less. ASP is not helping the ANTI-SPAM problem, it
is adding to it.
Otherwise, spoofed signatures permit a means to thwart policies
that give credit for invalid signatures.
Exactly, that is what SSP-02 now provides!
The NEVER concept can still be covered using DKIM=DISCARDABLE and a
NULL DKIM public key.
Disagree. This is attempting once again at establishing that no email
is sent by the domain.
No, it is establishing the reality in the world where real companies and
people who have domains which are never meant and used for email but it
is forged, exploited and abused by bad guys, bulk mailers, spammers
anyway. Is this not a reality?
The rub being that this assertion does not
require DKIM to be involved.
If this was a Return-Path domain for which there is an STANDARD
ASSERTION of MX involvement, I can see your point. But we are not
talking about the Return Paths, but From: header domains and in this
case, it is a DKIM involvement to consider the From: domain for MX
correctness.
> If done, this assertion should be made
directly rather than requiring still more DNS transactions.
Two things:
First, I believe you were one of the principles in getting the
questionable MX lookup within the SSP-01/SSP-02 steps. It isn't even
optional (SHOULD or MAY), but a MUST requirement. You shouldn't be
surprise if RECEIVER ignore this MUST for the same conflictive reason
you stated above that it is could be done as a separate protocol or
procedure outside of DKIM/SSP.
Second, how can you disagree with what is obviously possible where you
have no control or ignoring the fact you accessed a PUBLIC key?
If th public key is NULL, the DKIM signature is automatically invalid
and if an ASP DISCARDABLE policy is used, it means REJECTION.
The EXCLUSIVE concept can still be covered using DKIM=DISCARDABLE.
Disagree.
But it is written in stone:
discardable
All mail from the domain is signed with an Author
Signature. Furthermore, if a message arrives without a valid
Author Signature due to modification in transit, submission via
a path without access to a signing key, or other reason, the
domain encourages the recipient(s) to discard it.
Does it not mean what it says? I never was for explicit statements like
this and I don't think most WG participants ever was. All previous
documents provided guidelines as either being "Suspicious" or
"non-compliant" which for the most part is essentially code for
"rejection" but IMV, its not normally good practice to be so direct
with REJECTION statements in email.
Domains wishing to protect important transactional or
commerce related messages are unlikely to consider their messages
"discardable".
Exactly, which in the end of the day, we all know that ASP is just a
white wash attempt to kill the entire idea of SSP.
When was changing the assertion from "strict" discussed?
Other than the ASP group attempt to get rid of it, it never happen here
openly in the WG.
When would discarding a message be a recommended action?
When it is consistent with what was declared by the domain as unexpected.
Why is SSP attempting to define receiver actions?
It not about telling the receiver what to do but to HELP the receiver
determine with zero false positive factors of what is expected and not
expected - its about protocol consistency.
If the DOMAIN says it doesn't expect 3rd party signatures, it would be
incredibly dumb for a Receiver to ignore those factors, not just for the
good of the domain which has implicitly stated it would not take
responsibility for a message it did not write or sign, but for the
receiver and its users as well to not use this unique detections to get
rid of something that is clearly fraud or unauthorized or unexpected by
the domain.
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.
Disagree.
Doug, you were militantly vocal against SPF for the same SOFTFAIL
reasons. As sure as the New York Giants are Super Bowl Champions, then
you will be having belated recognized issues with ASP::DKIM=ALL failures
as well. :-)
--
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