On 27/Aug/11 05:26, John Levine wrote: > 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.
+1, how about Discovery-Origin? However, I'm skeptical about MTA rDNS. It is not the same level of domain that one would expect in DKIM d= and the domain-part of an address. If we include host-X.example.com as a possible discovery domain, we should also allow helo-names. IME, admins won't bother defining _report.host-X.example.com for each host, so I'd drop them. > 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? Good question. Where did you get "Gmail" from? :-) Perhaps, the following could be added, e.g. as a fourth paragraph, in section 5: A feedback consumer who wishes to receive feedback from a generator, may also query the domains it targets. For example, an MTA sending mail to [email protected] may want to query _report.example.org in order to ascertain under what conditions it can have generated feedback sent back to it. > In 5.1, I'd delete the rt= and ri= tags since I don't see how they > improve 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. Yeah, this conundrum transverses various reporting docs. I don't think we can afford to specify a different behavior for each report type. > 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.) I concur on the former point, but would prefer that r=, if given, be an email address, for ease of use. Perhaps, we could allow rp=r and specify that r= is /Optional, but MUST be defined unless rp=r/. The URI in ru= could provide for communicating a generator-specific email target address. If r is not given, only acknowledged generators can send feedback. > 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. How about fax:+12024562461? Currently, URIs are meant to be used interactively, so users can decide on their own. Perhaps, we might reserve some kind of URIs, e.g. http queries, for automated to-be-defined purposes. > Sec 9, security, the obvious problem is that a malicious sender can > publish "rp=o [email protected]" and indirectly mailbomb people. Should that be equivalent to a redirection? I mean, should _report.example.org. IN TXT "rp=o [email protected]" be considered equivalent to, say, _report.example.org. IN CNAME _report.somewhere.com? > 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. Verifying that somewhere.com wants feedback for example.org's spam looks like one of those automated to-be-defined purposes... jm2c _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
