Subject: Re: [marf] Revisiting reporting addresses

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 9 Sep 2011 10:54:26 -0700

Hello?  Anyone out there?

From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Thursday, August 18, 2011 2:15 PM
To: [email-masked]
Subject: [marf] Revisiting reporting addresses

Referring to draft-ietf-marf-dkim-reporting...

The current document says the reporting address is either a local-part (a userid) or a full address.  If it's a local-part, then "@" followed by the relevant domain is used to compose the full reporting address; for an ADSP report, that's the From: domain, and for a DKIM failure report that's the "d=" domain.  So there are reasonable defaults, but it does allow one to stick any address at all there.  I seem to recall it started out that way, then switch to local-part-only, then back to where it is now.  Does everyone concur that we want to allow that?

If we do, I think this warrants text in Security Considerations acknowledging the attacks this enables, and talking about why we think that's okay.  Could someone that remembers this discussion better than me propose some text along those lines?

This too has been implemented in OpenDKIM and its antecedent for a long time.

Thanks,
-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 10 Sep 2011 17:54:27 +0200

> Hello?  Anyone out there?

This was discussed in a different thread...

> The current document says the reporting address is either a local-part
> (a userid) or a full address.  If it’s a local-part, then “@” followed
> by the relevant domain is used to compose the full reporting address;
> for an ADSP report, that’s the From: domain, and for a DKIM failure
> report that’s the “d=” domain.  So there are reasonable defaults, but
> it does allow one to stick any address at all there.  I seem to recall
> it started out that way, then switch to local-part-only, then back to
> where it is now.  Does everyone concur that we want to allow that?

I agree with what John said,

  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.
      http://www.ietf.org/mail-archive/web/marf/current/msg01273.html

I proposed a DNS-based validation, replying to his message.

> If we do, I think this warrants text in Security Considerations
> acknowledging the attacks this enables, and talking about why we think
> that’s okay.

I don't think it's okay.  Without validation one cannot lightheartedly
use discovered addresses in different domains, IMHO.

---

From: "John Levine" <[email-masked]>
Date: 10 Sep 2011 17:12:15 -0000

>> acknowledging the attacks this enables, and talking about why we
>> think that’s okay.

I have to say I don't think it's OK either.  This sort of thing is
only worth standardizing if we think people are likely to use it, and
if they're likely to use it, the reverse DDoS attack is an obvious one.

The simplest fix would be to require that the reporting address is in
the same domain.  If someone has so little control over their domain
that they can't set up an abuse address, I have limited sympathy.

R's,
John

---

From: SM <[email-masked]>
Date: Sat, 10 Sep 2011 15:30:40 -0700

>the same domain.  If someone has so little control over their domain

A similar problem was discussed a few years back and that was the conclusion.

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 10 Sep 2011 22:25:55 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of SM
> Sent: Saturday, September 10, 2011 3:31 PM
> To: [email-masked]
> Subject: Re: [marf] Revisiting reporting addresses
> 

The DKIM reporting document has been updated accordingly.  (Fortunately, I didn't have to change my implementation at all, since it already truncated at the "@" if any was found.)

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 12 Sep 2011 12:36:34 +0200

On 11/Sep/11 07:25, Murray S. Kucherawy wrote:
>> From: ietf.org On Behalf Of SM
> The DKIM reporting document has been updated accordingly.
> (Fortunately, I didn't have to change my implementation at all,
> since it already truncated at the "@" if any was found.)

IMHO, that -03 change makes perfectly sense for dkim-reporting, since
we can assume the feedback generator is willing to report a technical
shortcoming to whoever is applying those signatures.

For /abuse/ reporting, however, the domain-part of the discovered
address could make a difference when a feedback generator is about to
choose among this and, say, abuse POCs found in whois databases.  If
the discovered domain is well known, feedback generators may trust it.
 Hence, allowing for a different domain makes sense in this case, and
could open up new avenues of abuse reporting practices.  Consider

  _report.myunknowndomain.name. TXT "r=[email-masked]"

Confirming that the original domain has indeed outsourced abuse
reporting to a renown organization is similar to vouching for that
domain, but limited to abuse reporting.  Also the syntax can be
similar to VBR's:

  myunknowndomain.name._report.abuse.net. TXT "r=[email-masked]"

---

From: "John Levine" <[email-masked]>
Date: 12 Sep 2011 14:28:20 -0000

You seem to be confusing two things.

>choose among this and, say, abuse POCs found in whois databases.

Well, sure.  If you find an address you trust some other way, send
reports to it.

> Consider

Speaking both in general, and specifically as Mr. abuse.net, this is
precisely what I want to forbid.  I cannot tell you how many lazy or
incompetent ISPs have foisted off some problem by telling their users
to report it to abuse.net, which is of course completely useless and
a waste of both the user's time and mine.

I realize that we could invent some DNS thing with extra text records
that are supposed to cross reference in some way, but I see no reason
to invent yet more mechanism.  If you've outsourced your abuse
handling to someone else, we already know how to add a single line in
your mail config to forward your abuse address to them.  At last that
way when some bozo forwards his complaints to me without asking, I
only have one address to blacklist.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 12 Sep 2011 20:51:38 +0200

> a waste of both the user's time and mine.

OTOH, such attitude proves that there is a market for that.

According to plan "A", users should send complaints to their Mailbox
Providers.  It is the MP's abuse team who may opt for forwarding to
abuse.net: they should be smart enough to understand a clause such as
"do so only for domains that (a) are authenticated by dkim or spf, and
(b) explicitly authorized by abuse.net".  Possibly, abuse.net has a
contract with such domains, e.g. providing for higher prices according
to the number of complaints.

NB:  I'm not implying Mr. abuse.net has to be happy of doing such
business.  It is just a possibility that you and/or someone else might
put to work.

> only have one address to blacklist.

The point is that the feedback generator has to be aware of that
forwarding, in order to trust sending reports there.

As an alternative to inventing more mechanisms, we could tweak VBR.
Assume myunknowndomain is vouched for by abuse.net.  Then one'd expect
abuse.net to accept complaints for abuse originating there, but to
what local part should they be addressed to?  The reporting-discovery
could say that an external domain is acceptable if and only if the
latter vouches for myunknowndomain.  Or it could modify VBR so as to
allow, e.g., "all r=bofh".  These two are more or less equivalent
variations, even if they may seem to avoid inventing one more mechanism.

---

From: "John Levine" <[email-masked]>
Date: 12 Sep 2011 19:34:45 -0000

>business.  It is just a possibility that you and/or someone else
>might put to work.

Sigh.  I understand this to mean that you're volunteering to deal with
all of the random support requests to abuse.net.

>forwarding, in order to trust sending reports there.

Sorry, that's 100% totally wrong.  The feedback generator sends
reports related to example.com to [email-masked] or
[email-masked] or some other example.com address.  Then
example.com forwards the reports somewhere, perhaps to an internal
ticketing system or to an outsourced abuse desk, or whatever.  That's
invisible to the people sending the reports.

There's a whole separate issue of how much you trust a domain in
various ways, perhaps including how much you trust them to handle
abuse reports, but we have a separate WG down the virtual hall for
that.

>As an alternative to inventing more mechanisms, we could tweak VBR.

tweak VBR == inventing more mechanisms.  Please, no.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 13 Sep 2011 09:59:52 +0200

> all of the random support requests to abuse.net.

Hm... not in my current situation.  But I think I could have liked to
run a business of that kind, in some life.

> [email-masked] or some other example.com address.

I mostly agree.  However, there are exceptions.  In the words of
abuse.net:

   Some particularly unpleasant domains ignore all their mail;
   when we're aware of that we use the address for their
   next-level-up provider.

There are two questions about such position.  First, how do you get
aware of that?  Second, is that provider willing to cooperate?  It
goes without saying that taking care of abuse reports involves some
costs, so the second question entails how network providers should
charge such costs if they want to offer competitive rates also to
sites that do no email at all.  It can be run as a different business.

I'm not holding that ISPs never want to do such job, but since some of
them are reluctant, cooperating ISPs need some means to confirm they
/do/ take care of complaints.  Can reporting-discovery solve this issue?

> Then example.com forwards the reports somewhere, perhaps to an
> internal ticketing system or to an outsourced abuse desk, or
> whatever.  That's invisible to the people sending the reports.

Right.  Within the domain, they may check users are not 0wned,  or
illegally sending bulk email.  This seems to be yet another activity.

> abuse reports, but we have a separate WG down the virtual hall for

Possibly, that will eventually answer the first question above.  For
the reporting address, we need a working alternative to next-level-up
providers.

---

From: Dotzero <[email-masked]>
Date: Tue, 13 Sep 2011 09:18:50 -0400

On Tue, Sep 13, 2011 at 3:59 AM, Alessandro Vesely <[email-masked]> wrote:

<snip>
> the reporting address, we need a working alternative to next-level-up

Why?

If reporting abuse directly to the domain admin or the abuse contact
for the ASN indicated by whois doesn't work, I've found that
contacting the upstream works in most cases.

---

From: "John Levine" <[email-masked]>
Date: 13 Sep 2011 15:07:08 -0000

>run a business of that kind, in some life.

You're missing the point -- you don't get to charge, they just send
you the complaints without asking.  I'll forward them as they come in.

>aware of that?  Second, is that provider willing to cooperate? 

At abuse.net, that's handled completely manually, both the evaluation
and the selection of addresses.  This is policy stuff that is utterly
outside the scope of a fricking reporting format.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 13 Sep 2011 18:57:37 +0200

> you the complaints without asking.  I'll forward them as they come in.

I see, they probably think abuse.net is an abuse reporting hub like
SpamCop.

> outside the scope of a fricking reporting format.

I only send abuse reports for a minimal part of the spam I get.  This
is not a policy, it is because I haven't yet managed to automate spam
reporting.  By "automate" I mean that clicking the spam button should
result in having a report sent out, with minimal manual intervention
on the server side.  Then, I'll be able to offer the same service to
my few users, and possibly contribute to an RFC about that.

I don't think I'd be able to manually send reports (and monitor their
effect) for a significant part of the spammy messages in my own inbox,
let alone doing so for my users, however few.  If we conclude that it
is not worth/feasible to automate complaining, how would we
characterize that minuscule part of abusive messages that deserve
being reported?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 13 Sep 2011 10:03:37 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of John Levine
> Sent: Tuesday, September 13, 2011 8:07 AM
> To: [email-masked]
> Cc: [email-masked]

I agree that what's being discussed isn't a protocol matter, but it's not impossible for material like this to be in a BCP or other advisory document.  The question is really whether or not this is stuff we want or need to say beyond the BCP we're already producing.

I don't think we could codify, in protocol at least, anything at all about WHOIS.  In its current form it isn't a reliable source of any kind of information.  Sometimes what you need is there, sometimes it's not; sometimes it's there but not in a form an automated system can extract.  This might be helpful to include in advice someplace though if we can find text on which we can agree.  All of that might change if the WEIRDS effort is successful, but for now WHOIS is a wild west.

I think it's clear we want not to include domain names in any reporting addresses for the reasons John stated.  The dkim-reporting document has already been updated to say so, and in my opinion the spf-reporting and reporting-discovery documents should follow.

This all leads into the issue of whether or not we want to do some advisory text about FBLs outside of the context of private agreements.  I'll comment about that on a separate thread.

-MSK, as participant

---

From: "John Levine" <[email-masked]>
Date: 13 Sep 2011 19:01:45 -0000

>reporting.

I do send out reports automatically, for stuff that hits some of my
spamtraps, and stuff that lands in my spam folder.  It currently uses
very conservative rules about where to report; abuse.net if the
sending IP has valid rDNS, and a manually maintained list of IP range
contacts.

If something like MARF reporting becomes popular, I would retrieve the
addresses, but only if I were confident that I wasn't going to annoy a
lot of unrelated people by doing so.

I think we have rough consensus here, so I'll stop now.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 14 Sep 2011 10:31:12 +0200

> I think we have rough consensus here, so I'll stop now.

Yup, you an Murray in for domain-less r= is the double of me for the
domain-part.  Easy arithmetic :-/