Subject: [dmarc-ietf] service for the dark side? aggregated reports

From: "A. Schulze" <[email-masked]>
Date: Fri, 14 Nov 2014 21:22:45 +0100

Hi,

like just mentioned in jabber I like to know if and how you handle the  
situation
where inbound message should be reported back to the sender
while the sender is clearly not a good guy.

Franck martin suggest to not send every dmarc report by
  - blacklisting
  - report volume
other suggestions?

franck also asked if these aggregate reports are really valuable for spammers.
I'm not sure about yes or no.

currently I generate (but am not allowed to send) reports for ~700  
domains every day.
10 ...30 are for domains in my blocklists.

Andreas

---

From: Todd Herr <[email-masked]>
Date: Fri, 14 Nov 2014 16:51:39 -0500

> while the sender is clearly not a good guy.

​I'm not sure I understand why it might be a problem to send aggregate
reports to domains you're already blocking; to the contrary, there might be
value in doing so, at least from an "enemy of my enemy" standpoint.

If I understand the scenario correctly, there exists one or more domains
that you're refusing mail from, domains which also publish DMARC policies.
For the purposes of this discussion, we'll focus on just one such domain,
wesellstuff.com.

Whether or not you care for a given domain's sending practices, it still
has a right to its identity and brand, assuming it's legally registered by
whatever definition of "legally registered" is applicable. It might even be
a legitimate business, albeit one with bad email sending practices.

You're refusing mail from the domain wesellstuff.com, and they probably
already know that (or should) so your aggregate reports won't tell them
anything they don't already know (assuming that the rejection happens deep
enough into the SMTP transaction that you can generate reports about it).

At the same time, Criminals R Us is sending mail that is attempting to use
wesellstuff.com's brand, but this mail either does or does not pass DMARC
checks; either way, you're reporting the stats to wesellstuff.com. These
reports might give wesellstuff.com enough information to try to take action
to get this illegitimate mail stopped, which would be a win for you, as a
provider who doesn't want mail from either entity.

I guess I could see aggregate reports as a way for a bad guy to test the
waters and see what stuff of his is getting through and what's not, but I'm
not sure that there's any gain there, when you think about the cost of
setting up an infrastructure to process DMARC reports; bounces or "250 ok"
is a much more immediate feedback mechanism than aggregate reports that
might be delayed by up to 24 hours.  It seems to me that the relative
anonymity of not publishing DMARC would be a better way to maximize (at
least in the short term) one's ability to send a ton of crap. If they think
DMARC is the answer to getting their mail accepted, probably the easiest
path there is just publish an SPF record of "+all" and don't worry about
DKIM signing anything.

What am I missing here?​

-- 
Todd

---

From: Steve Atkins <[email-masked]>
Date: Fri, 14 Nov 2014 14:23:33 -0800

On Nov 14, 2014, at 1:51 PM, Todd Herr <[email-masked]> wrote:

> like just mentioned in jabber I like to know if and how you handle the situation
> ​I'm not sure I understand why it might be a problem to send aggregate reports to domains you're already blocking; to the contrary, there might be value in doing so, at least from an "enemy of my enemy" standpoint.
> 
> If I understand the scenario correctly, there exists one or more domains that you're refusing mail from, domains which also publish DMARC policies. For the purposes of this discussion, we'll focus on just one such domain, wesellstuff.com.
> 
> Whether or not you care for a given domain's sending practices, it still has a right to its identity and brand, assuming it's legally registered by whatever definition of "legally registered" is applicable. It might even be a legitimate business, albeit one with bad email sending practices.
> 
> You're refusing mail from the domain wesellstuff.com, and they probably already know that (or should) so your aggregate reports won't tell them anything they don't already know (assuming that the rejection happens deep enough into the SMTP transaction that you can generate reports about it).
> 
> At the same time, Criminals R Us is sending mail that is attempting to use wesellstuff.com's brand, but this mail either does or does not pass DMARC checks; either way, you're reporting the stats to wesellstuff.com. These reports might give wesellstuff.com enough information to try to take action to get this illegitimate mail stopped, which would be a win for you, as a provider who doesn't want mail from either entity.

If "good" and "bad" are complaint driven it's also possible that the blocking of wesellstuff.com is (partially) due to the forgery of their name / brand / content by Criminals R Us. If so, then providing that information to them will help them understand why they're being blocked and allow them to do something about it (benefiting both them and your customers).

It's not entirely theoretical - I've seen a somewhat annoying but not actually evil daily mailer blocked because there were a bunch of people imitating their content, and the overall volume of fake and real content together drove up complaint rates.

> I guess I could see aggregate reports as a way for a bad guy to test the waters and see what stuff of his is getting through and what's not, but I'm not sure that there's any gain there, when you think about the cost of setting up an infrastructure to process DMARC reports; bounces or "250 ok" is a much more immediate feedback mechanism than aggregate reports that might be delayed by up to 24 hours.  It seems to me that the relative anonymity of not publishing DMARC would be a better way to maximize (at least in the short term) one's ability to send a ton of crap. If they think DMARC is the answer to getting their mail accepted, probably the easiest path there is just publish an SPF record of "+all" and don't worry about DKIM signing anything.
> 
> What am I missing here?​

Cheers,
  Steve