On Dec 11, 2007, at 9:36 AM, Michael Thomas wrote:
Well I for one think that many of these issues can be resolved on
the list. For example, I don't see much if any support for changing
the valid first party signature consensus from rfc 5016, and I've
seen a whole lot of -1's.
Definitions used in SSP should not be limited to only those found in
RFC5016. This is important when following such definitions disrupt
email services, and creates a series of false-positive detections of a
non-existent misbehaviour.
RFC5016:
,---
|3.1. Problem Scenario 1: Is All Mail Signed with DKIM?
|
|After auditing their outgoing mail and deploying DKIM signing for all
|of their legitimate outgoing mail, a domain could be said to be DKIM
|signing complete. That is, the domain has, to the best of its
|ability, ensured that all legitimate mail purporting to have come
|from that domain contains a valid DKIM signature.
'---
The description of the problem does not lead to only the From being
signed "on-behalf-of" as per the definition found for a first party
signature. A first party signature is only one of many possible valid
signatures being added by by a domain. Limiting the consideration of
valid signatures to only those "on-behalf-of" the From domain is
clearly a mistake.
A domain that adds a signature to a message where the Sender header is
indicated as being signed "on-behalf-of" while the signing domain is
also valid for the From would be an indication of what type of
misbehaviour? What problem is prevented by requiring all signatures
be signed "on-behalf-of" the From header? Such a requirement will
mean the signing domain is REQUIRED to lie about which header the
message is being signed "on-behalf-of". Twisted logic based upon a
requirement for "on-behalf-of" From (first-party) breaks messages
signed per DKIM base and does not prevent any abuse not already within
the control of the signing domain. The only possible exception would
be for restricted keys.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html