----- Original Message -----
From: "Barry Leiba" <leiba(_at_)watson(_dot_)ibm(_dot_)com>
To: <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Wednesday, November 02, 2005 10:30 AM
Subject: [ietf-dkim] DKIM proposed charter tweak
------------------------------------------------
While the techniques specified by the DKIM working group will not
prevent fraud or spam, they will provide a tool for defense against
them by allowing receiving domains to detect spoofing of known domains.
The standards-track specifications will not mandate any particular
action by the receiving domain when spoofing is detected. That said,
with the understanding that guidance is necessary for implementers, the
threat summary should document a reasonable set of possible actions and
strategies, and analyze their likely effects on attacks and on normal
email delivery. The DKIM working group will not attempt to establish
requirements for trust relationships between domains or to specify
reputation or accreditation systems.
------------------------------------------------
Comments ASAP, please.
I'm all for it. That is why I put this table together to help
see the logic of it all:
Legend:
SSP Policies:
NONE (no policy [1])
o=? WEAK (signature optional, no third party, see [2])
o=~ NEUTRAL (signature optional, 3rd party allowed)
o=- STRONG (signature required, 3rd party allowed)
o=! EXCLUSIVE (signature required, no 3rd party)
o=. NEVER (no mail expected)
o=^ USER
[1} a NONE policy is possible where there is no declaration for a SSP.
[2] Arvel suggested another policy called WEAK which satisfies a
signature optional but not allowing 3rd party signers.
Verify Results:
NONE - No signature in mail
PASS - Good Signature, Original Address Signer
PASS 3P3 - Good Signature, 3rd party Signer
FAIL - Bad Signature, Original Address Signer
FAIL 3P3 - Bad Signature, 3rd party Signer
Table 1.0 - DKIM Verification States illustrates all possible
outcomes for signature verification against SSP.
+------------------------------------------------------+
| Sender Signing Policy Result |
+-----------+----------------------------------------------+-------|
| result | WEAK | NEUTRAL | STRONG | EXCLU | NEVER | NONE |
| verify | OPT | OPT/3PS | REQ/3PS | REQ | | |
+-----------+--------+---------+---------+--------+--------+-------|
| NONE | accept | accept | reject | reject | reject | accept|
|-----------+--------+---------+---------+--------+--------+-------|
| PASS | accept | accept | accept | accept | reject | warn |
|-----------+--------+---------+---------+--------+--------+-------|
| PASS 3PS | reject | warn | accept | reject | reject | warn |
|-----------+--------+---------+---------+--------+--------+-------|
| FAIL | warn | warn | warn | warn | reject | warn |
|-----------+--------+---------+---------+--------+--------+-------|
| FAIL 3PS | reject | warn | warn | reject | reject | warn |
+------------------------------------------------------------------+
How a system reacts is implementation and local policy based.
In my opinion, we have some hard decisions that can be taken by the
transport system at the DATA sink with 45x or 55x negative response which to
me is ideal because it provide instant notification and feedback. With post
SMTP DKIM verifiers, this will be a tougher issue to debate in regards to
the merits of rejection without notification vs the issues of possible
bounce attacks.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
ietf-dkim mailing list
http://dkim.org