I have my doubts about how useful these things would be, but here's a bunch of comments:
In sec 5, it says you can identify the consumer domain by DKIM d=, SMTP bounce address domain, or MTA rDNS. I'm wondering whether it is a problem that they all funnel into _report.<domain> without any way to tell the difference. If it mattered, I'd suggest adding a tag in the record saying which sort of name the record applies to, with multiple records if need be. For feedback generators, I have no idea how I'm supposed to pick a domain name to look up. If, say, I wanted feedback from Gmail, would that be google.com? gmail.com? googlemail.com? The name of one of their MX hosts? Any or all of the bazillion mail domains they host? Something else? In 5.1, I'd delete the rt= and ri= tags since I don't see how they improves interoperability. If someone is inviting me to send them abuse reports, I'm going to send them abuse reports, and the number of reports will be limited by the amount of mail they send. They can always ignore the ones they don't understand. For the r= tag, I don't understand why it's supposed to be able both to accept ARF abuse reports and to respond to a subscription verification request. Presumably the response is automated, since no human is going to be looking through the stream of ARF for subscriptions. Is there some yet to be defined protocol here? Also it might be better to make r= a URI rather than an email address, so it can be a mailto: or an http: allowing POST. Why is there a gp=r policy but no rp=r policy? I accept random mail to my abuse address, but for feedback senders I know, I treat their ARFs differently (basically, I believe all of the latter and treat them as unconditional unsubscribes.) In 5.4, I would suggest specifically limiting the kind of URIs that the fields can include, unless someone is prepared to explain what to do if you see ru=nntp:news.example.com. Sec 9, security, the obvious problem is that a malicious sender can publish "rp=o [email protected]" and indirectly mailbomb people. The mention of subscription verification suggests there's supposed to be some sort of handshake before turning on the cannon, but if it's there, I've missed it. R's, John _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
