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

From: Florian Sager <[email-masked]>
Date: Thu, 28 Feb 2008 10:45:46 +0100

Murray S. Kucherawy schrieb:
> That said, originally I had some motivation during the initial 
> interoperability testing of DKIM over a year ago; specifically, it was 
> nice to have someplace to send diagnostic reports (canonicalizations, 
> etc.) when verifications failed.  I still find that practise useful, 
> and that's the motivation for adding something like "report=" 
> (probably just "r=") to key records as well.
Hi,

I just reviewed [ietf-dkim] "Proposal to amend SSP draft with a 
reporting address" --> the responses dealt with using ARF or an own 
abuse report format but they didn't refer to the reporting address. What 
was the result of this discussion? There is no r= property in the ASP 
draft (yet).

This is where I am stuck:

Since a few days I am running a spamtrap collecting DKIM signed spam 
(has to be successfully verified). Yesterday the NiXspam BL project (as 
far as I know this is the biggest BL project in Germany) pleasently 
joined as a feeder for our spamtrap, so I have some more emails to analyze.

Example:
Authentication-Results: mx-border; dkim=pass 
header.i=[email-masked]
(There was no i= property in the DKIM signature, header.i was set by the 
content of From).

For this spam mail I'd like to send an abuse report to Yahoo! but 
"[email-masked]" is not the 
identity responsible for the signature (and therefore an appropriate 
reporting address) but it is very likely the spammer itself (considering 
the content of the mail). As long as ASP will set (simply said) i= to a 
 From address there is once more need for a distinct reporting address 
of the identity responsible for the signature (e.g. as a signature 
property r=, I'd prefer this as a part of the DKIM-Signature).

Second aspect: besides abuse-reporting I'd like to setup a BL containing 
tuples like <alleged sender, signing-domain>. I am hesitating to use 
 From or Sender as <alleged sender>; in my view there would be more 
value if the identity that signs a message adds an own f=<this is what I 
claim to be the alleged sender> to the signature: this could be a 
hash(SMTP AUTH property) or a uid or MAIL FROM or Authenticated-Sender 
(the only thing that matters here is an internal, unique user-level id 
... I am aware of the arbitrary forging of this property, but ISPs 
should profit by this).

Best regards,
Florian

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 28 Feb 2008 11:42:28 -0800 (PST)

> was the result of this discussion? There is no r= property in the ASP 

See https://datatracker.ietf.org/drafts/draft-kucherawy-dkim-reporting/.
It's a draft proposal right now.

> "[email-masked]" is not the identity 
> responsible for the signature (and therefore an appropriate reporting 
> address) but it is very likely the spammer itself (considering the content of 
> the mail). As long as ASP will set (simply said) i= to a From address there 
> is once more need for a distinct reporting address of the identity 
> responsible for the signature (e.g. as a signature property r=, I'd prefer 
> this as a part of the DKIM-Signature).

"i=" is the signing identity.  It's not guaranteed to be a good place to 
which to report abuse if the sender is malicious.  Yahoo would need to 
either explicitly set "i=" to be the abuse address (which they could do) 
or implement the reporting specification (which is still a draft, so it's 
not likely).

> tuples like <alleged sender, signing-domain>. I am hesitating to use From or 
> Sender as <alleged sender>; in my view there would be more value if the 
> identity that signs a message adds an own f=<this is what I claim to be the 
> alleged sender> to the signature: this could be a hash(SMTP AUTH property) or 
> a uid or MAIL FROM or Authenticated-Sender (the only thing that matters here 
> is an internal, unique user-level id ... I am aware of the arbitrary forging 
> of this property, but ISPs should profit by this).

Why can't you use "i=" for that?
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Florian Sager <[email-masked]>
Date: Thu, 28 Feb 2008 23:10:47 +0100

Murray S. Kucherawy schrieb:
>> abuse report format but they didn't refer to the reporting address. 
>> What was the result of this discussion? There is no r= property in 
>> the ASP draft (yet).
Thanks for this reminder, I forgot about this draft: maybe section 4.1 
can be extended by s.th. like "a  Reports are requested for passed 
signatures inside mails with suspicious content". The same intent may 
already be included in 4.2 "s ... signed and Suspicious".

>
>> For this spam mail I'd like to send an abuse report to Yahoo! ...
> "i=" is the signing identity.  It's not guaranteed to be a good place 
> to which to report abuse if the sender is malicious.  Yahoo would need 
> to either explicitly set "i=" to be the abuse address (which they 
> could do) or implement the reporting specification (which is still a 
> draft, so it's not likely).
>
>> Second aspect: besides abuse-reporting I'd like to setup a BL 
>> containing tuples like <alleged sender, signing-domain>. I am 
>> hesitating to use From or Sender as <alleged sender>;
After all i= should be usable: I worried about the fact i= can be omitted and another header address has to be guessed to be the alleged sender. This address might be more random/less confident than i= with a local part added by the signer of an ISP (regarding repuation filters,
I think this problem will be self-regulating).

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 28 Feb 2008 14:15:29 -0800 (PST)

> already be included in 4.2 "s ... signed and Suspicious".

Not a bad idea.  Any comments from others?
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html