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(_dot_)i=Fully-Supported-Home-Employment-owner(_at_)yahoogroups(_dot_)com
(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
"Fully-Supported-Home-Employment-owner(_at_)yahoogroups(_dot_)com" 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