Subject: [marf] draft-ietf-marf-reporting-discovery-01

From: "John Levine" <[email-masked]>
Date: 27 Aug 2011 03:26:17 -0000

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 r=[email-masked]" 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

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 27 Aug 2011 13:28:02 +0200

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

> their MX hosts?  Any or all of the bazillion mail domains they host?

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-masked] may want to query
  _report.example.org in order to ascertain under what conditions it
  can have generated feedback sent back to it.

> improve interoperability.  If someone is inviting me to send them

Yeah, this conundrum transverses various reporting docs.  I don't
think we can afford to specify a different behavior for each report type.

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

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

> publish "rp=o r=[email-masked]" and indirectly mailbomb people.

Should that be equivalent to a redirection?  I mean, should

   _report.example.org. IN TXT "rp=o r=[email-masked]"

be considered equivalent to, say,

   _report.example.org. IN CNAME _report.somewhere.com?

> be some sort of handshake before turning on the cannon, but if it's

Verifying that somewhere.com wants feedback for example.org's spam
looks like one of those automated to-be-defined purposes...

jm2c

---

From: "John Levine" <[email-masked]>
Date: 27 Aug 2011 14:55:09 -0000

>+1, how about Discovery-Origin?

Seems a bit prolix when the other tags are r= and ru= but whatever

>domain, we should also allow helo-names.

I can tell you from extensive experience that I find host rDNS useful
for identifying the guilty party, and HELO useless since there is no
way to tell whether the HELO has any connection to the actual sender.

>  can have generated feedback sent back to it.

This scales very poorly.  Having set up a variety of people on various
shared commercial mail hosts, I can report that the host tells the
customer what MX records to use, and the customer more or less painfully
configures them into his DNS.  The customers are not going to add _report
records.

I think that the MX is the best of a bad lot for identifying a report
generator.  The MX hosts are under the control of the actual mail
system, and the number of MXes per system is reasonably small, at
least compared to the number of mail domains they might host.

>interactively, so users can decide on their own.

Some URIs are used interactively, some aren't.  I know I would have
very little interest in a feedback system that asked me to fax in
the reports, or do anything other than mail or POST them.

>Should that be equivalent to a redirection?

No, it might be real and it might not be.  The point is that for this
not to be a DDoS vector, there needs to be some way to validate the
address before sending it reports.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 28 Aug 2011 11:09:38 +0200

> Seems a bit prolix when the other tags are r= and ru= but whatever

Oops, sorry John, I don't know why I was thinking of feedback fields.

> address before sending it reports.

Perhaps, storing that in the DNS provides for easier verification
than, say, an HTTP query.  If example.org outsources report handling
to example.com, the latter could publish a confirmation as

  example.org._report.example.com. CNAME _report.example.com.
  _report.example.com. TXT "rp=o r=[email-masked]"

or

  example.org._report.example.com. TXT "r=[email-masked]"
  ; rp= retained from original record, or default.

or

  example.org._report.example.com. CNAME _report.example.org.

This way, a generator can confirm the external domain and fetch any
relevant detail using a single extra query.  In the latter example,
the service accepts whatever settings its customer may define, but it
can always revert to one of the former cases; that is, the real
handler is in control of the target email address.

Just an idea