[ietf-dkim] Proposal to amend SSP draft with a reporting address (fwd)

[Murray S. Kucherawy]

This time with feeling!  (and the attachment)

---------- Forwarded message ----------
Date: Thu, 8 Nov 2007 16:13:41 -0800 (PST)
From: Murray S. Kucherawy <msk at sendmail.com>
To: ietf-dkim at mipassoc.org
Subject: Proposal to amend SSP draft with a reporting address

At MAAWG someone pointed out that a sender might be interested in knowing when 
his/her domain is being abused, i.e. if something appears to be Suspicious.

In line with this and having talked to Jim about it, attached is some proposed 
amended text versus the ssp-01 draft which adds an optional reporting address 
to be used when the SSP algorithm results in something being labeled 
Suspicious.

I intend to come up with a subsequent draft that has two purposes:

a) add something similar to DKIM key records;

b) define a format for such reports (i.e. ARF or something similar)

Comments welcome.

--
Murray S. Kucherawy ========================================= msk at sendmail.com
Principal Engineer           Sendmail, Inc.                Emeryville, CA, USA
(510) 594-5400                                         http://www.sendmail.com
-------------- next part --------------
Index: draft-ietf-dkim-ssp-01.txt
===================================================================
RCS file: /cvs/DKIMFilter/draft-ietf-dkim-ssp-01.txt,v
retrieving revision 1.1
diff -u -r1.1 draft-ietf-dkim-ssp-01.txt
--- draft-ietf-dkim-ssp-01.txt	20 Sep 2007 21:36:04 -0000	1.1
+++ draft-ietf-dkim-ssp-01.txt	8 Nov 2007 23:26:12 -0000
@@ -631,6 +631,20 @@
 
       Unrecognized flags MUST be ignored.
 
+   report=  A reporting address (OPTIONAL; no default).  When a Verifier
+      determines that a message is Suspicious according to the procedure
+      described in Section 4.4, the Verifier MAY generate a message to this
+      reporting address containing a report about the candidate message and
+      indicating what part of the evaluation failed.  The format of this
+      report is not defined in this specification but is expected in a
+      subsequent one.
+
+      ABNF:
+
+        report-address = local-part "@" domain-name
+
+      "local-part" and "domain-name" are as defined in RFC2822.
+
 4.4.  Sender Signing Practices Check Procedure
 
    Verifiers MUST produce a result that is semantically equivalent to