On Thu, 28 Feb 2008, Florian Sager wrote:
> 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).

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

> For this spam mail I'd like to send an abuse report to Yahoo! but 
> "[EMAIL PROTECTED]" 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).

> 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).

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

Reply via email to