Subject: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag

From: "Marco Davids (IETF IMAP)" <[email-masked]>
Date: Thu, 24 Nov 2016 10:51:39 +0100

Dear community,

I hereby request feedback and support for draft-davids-dmarc-fi-tag.

Problem:

Per-message failure reports as requested by the "ruf" tag are a useful
source of information when debugging deployments or in analyzing attacks.

However, under certain circumstances this property can potentially lead
to an undesirably high volume of reports.  Especially when a Domain
Owner's name is spoofed and abused in a large-scale phishing or other
impersonation attack.

RFC7489 offers only a very limited solution to this problem (in section
7.3).

The lack of a mechanism for a Domain Owner to influence the volume of
reports constitutes an obstacle to deployment of the "ruf" tag feature.

Solution:

In draft-davids-dmarc-fi-tag I propose a new DMARC tag, the "fi" tag. It
provides a Domain Owner with a simple way of requesting limitation of
the rate at which such reports are sent.

Please let me know what you think of it. I'm looking forward to a
fruitful discussion on the design choices I made and I also hope for
support of the idea.

Thanks.

The draft can be found here:

https://datatracker.ietf.org/doc/draft-davids-dmarc-fi-tag/

-- 
Marco Davids
SIDN Labs

---

From: Steven M Jones <[email-masked]>
Date: Thu, 24 Nov 2016 19:57:15 +0900

Hello Marco,

Interesting proposal, from a five minute skim via cell phone. Have any mailbox providers or report generators shared their views on the incremental overhead of having to track this kind if interval timer for each sending domain that experiences an authentication failure, versus what may currently be a "fire and forget" arrangement now?

I look forward to a longer review on a larger screen. :)

--Steve. 

Sent from my iPhone

> On Nov 24, 2016, at 18:51, Marco Davids (IETF IMAP) <[email-masked]> wrote:
> 
> Dear community,
> 
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc

---

From: "Marco Davids (IETF IMAP)" <[email-masked]>
Date: Thu, 24 Nov 2016 13:48:45 +0100

On 24/11/2016 11:57, Steven M Jones wrote:

> Have any mailbox providers or report generators shared their views on
> the incremental overhead of having to track this kind if interval
> timer for each sending domain that experiences an authentication
> failure, versus what may currently be a "fire and forget" arrangement
> now?

And "fire and forget" it seems to be (in at least one case), according
to a recent experience I had with a large mailbox provider. In fact, it
was that event that inspired me to write this draft (after having spend
a great part of the morning cleaning up flooded mail queues here at the
office).

--
Marco

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Thu, 24 Nov 2016 19:34:11 +0100

Hi, Marco,

> fruitful discussion on the design choices I made and I also hope for

two things, after having had a quick look at the draft:

 1. it seems to me that, with this proposal, you move the burden of
    implementing a rate limiting function from the domain owner to the
    reporting organization. This seems not right to me, as it's
    primarily in the interest of the sending domain to receive feedback
    via these reports, not the reporting domains interest. For the large
    ESPs this may be no big deal, they may have means to implement such
    a reporting interval without much pain, but for smaller
    organizations this may cause problems (in terms of resources that
    must be allocated for queuing these reports). To exaggerate a bit:
    the attack vector introduced with 'ruf' is now more or less moved
    from the sending to the reporting domain. Furthermore, most modern
    mail systems have rate limiting technology on board, which can be
    deployed by the sending domain to protect against floodings with
    reports (granted, this shifts the burden also in the direction of
    the reporting domain);
 2. I wonder why you have chosen a 32-bit integer, when the unit of
    interval is 'second'. On one hand this provides not enough
    granularity, as the shortest interval (apart from zero) is 1 report
    per second, which may cause significant queues on the side of the
    reporting domain. On the other hand, a 32-bit integer means reports
    can be sent up to 136 years after the moment of an DMARC
    authentication failure, which is way too long to be useful. So I'd
    suggest you make the unit milliseconds, to make it better fit for
    its intended use?

Regards,
/rolf

---

From: "John Levine" <[email-masked]>
Date: 24 Nov 2016 17:35:39 -0000

>Owner's name is spoofed and abused in a large-scale phishing or other

I gather that this was inspired by some sort of phish or spoof that
caused people to send you a lot of failure reports.  Can you give us
an idea of the report volume and rate that raised the concern?

R's,
John

---

From: "Marco Davids (IETF IMAP)" <[email-masked]>
Date: Thu, 24 Nov 2016 21:07:41 +0100

Hi Rolf,

Thank you for taking the time to respond. Allow me to elaborate a little.

On 24/11/2016 19:34, Rolf E. Sonneveld wrote:

>     reporting organization. 

True, but it doesn't have to be that much of a burden in practice, as is
explained in section 5 of the draft:

"A report generator in this example would typically honour the "fi" tag
by sending out a report, storing a 'last report sent' timestamp for
example.com in memory and maintaining it as a 'do not sent' flag for a
minimum of $interval seconds during which period no consecutive reports
are to be sent.  After the flag has cleared, a report may again be sent.
 The cycle then repeats."

Also, please note: intermediate reports are not generated and not
queued. They only add to the statistics of aggregated "rua" reports.

Compared to the kind of housekeeping a report generator already has to
do for sending "rua" aggregated reports, this minor extra step of
maintaing a simple timestamp flag seems very lightweight to me.

Also, the draft is lenient on the intervals. It is all pretty loosely
defined as: "approximately the requested number of seconds". The example
in section 5 defines it a bit more precise by suggesting to at least
maintain a minimum of $fi-interval seconds between reports. But a bit
longer is certainly acceptable as well. No microseconds granularity as
far as I am concerned.

I also would like to draw your attention of section 7.3 of RFC7489, the
DMARC RFC:

"An obvious consideration is the denial-of-service attack that can be
perpetrated by an attacker who sends numerous messages purporting to
be from the intended victim Domain Owner but that fail both SPF and
DKIM; this would cause participating Mail Receivers to send failure
reports to the Domain Owner or its delegate in potentially huge
volumes."

So, the potential problem was already identified in the DMARC RFC7489.
But it leaves it to the discretion of the report generator to do
something about is, or not. That's a somewhat debatable, maybe even
unfair approach, since it might be possible that the report generator
can produce much bigger volumes than the Domain Owner at the receiving
end can ever handle. My draft intends to give the receiving end of
ruf-reports some means to restrict the volume from their perspective.

> For the large ESPs this may be no big deal, they may have means to
> implement such a reporting interval without much pain, but for
> smaller organizations this may cause problems (in terms of resources
> that must be allocated for queuing these reports).

Let me emphasize this important aspect once more: reports SHOULD NOT be
queued, but discarded instead. The draft is very explicit in this (or at
least it should be). So yes, every intermediate report is skipped (not
even generated) for as long as the fi-interval has not passed. No
queuing please. ;-) This is also in the interest of the report
generator, because the advantage of skipping reports probably outweighs
the suggested 'burden' of maintaining some 'timestamp state'.

>     interval is 'second'.

Simple: I wanted to have at least room for one day of seconds (86400),
and that number does not fit in a 16 bit integer ;-)

> On the other hand, a 32-bit integer means reports
> authentication failure, which is way too long to be useful.

Fully agree! That is why the draft states:

"Report generators that implement this feature MUST be able to support
 the entire interval range from 0-86400 and MAY support longer
 intervals."

I expect nobody to ever support a 136 years of interval ;-)

> So I'd suggest you make the unit milliseconds, to make it better fit
> for its intended use?

I am not really in favor of that kind of granularity, but maybe things
are more clear now with my explanation above.

Thank you once more for your valued feedback. Let me know what you think
after reading this reply.

Cheers,

-- 
Marco

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 24 Nov 2016 12:32:26 -0800

On Thu, Nov 24, 2016 at 10:34 AM, Rolf E. Sonneveld <
[email-masked]> wrote:

>    reporting organization. This seems not right to me, as it's primarily in
>    the interest of the sending domain to receive feedback via these reports,
>    not the reporting domains interest. For the large ESPs this may be no big
>    deal, they may have means to implement such a reporting interval without
>    much pain, but for smaller organizations this may cause problems (in terms
>    of resources that must be allocated for queuing these reports). To
>    exaggerate a bit: the attack vector introduced with 'ruf' is now more or
>    less moved from the sending to the reporting domain. Furthermore, most
>    modern mail systems have rate limiting technology on board, which can be
>    deployed by the sending domain to protect against floodings with reports
>    (granted, this shifts the burden also in the direction of the reporting
>    domain);
>
>
I'm not sure there's another way.  If the domain receiving the reports were
to be burdened with imposing the limit, it has only a few choices:

* size up to withstand whatever load the greater Internet will throw at it
(expensive);
* build queueing infrastructure to accept anything the greater Internet
throws at it so it can be processed as quickly as possible (also requires
infrastructure);
* return 4xx error codes when you're at capacity (which means pushing it
back on senders or intermediaries anyway).

Am I missing something?

>
>    1. I wonder why you have chosen a 32-bit integer, when the unit of
>    interval is 'second'. On one hand this provides not enough granularity, as
>    the shortest interval (apart from zero) is 1 report per second, which may
>    cause significant queues on the side of the reporting domain. On the other
>    hand, a 32-bit integer means reports can be sent up to 136 years after the
>    moment of an DMARC authentication failure, which is way too long to be
>    useful. So I'd suggest you make the unit milliseconds, to make it better
>    fit for its intended use?
>
>
32-bit integers make sense to me here.  A 16-bit integer is the only other
size that makes sense, which limits one to saying something under a day.

Is the suggested time granularity useful?

-MSK

---

From: "Marco Davids (IETF IMAP)" <[email-masked]>
Date: Thu, 24 Nov 2016 21:32:36 +0100

On 24/11/2016 18:35, John Levine wrote:

>> However, under certain circumstances this property can potentially
>> lead to an undesirably high volume of reports. Especially when a
>> Domain Owner's name is spoofed and abused in a large-scale phishing >> or other impersonation attack.
> 
> caused people to send you a lot of failure reports.

That's correct John. Some malicious party abused our domain name in a
phishing campaign.

Which is by the way precisely why we appreciate and configured the "ruf"
tag; to discover this kind of abuse the moment it happens.

> Can you give us an idea of the report volume and rate that raised the
> concern?

And that is the downside of the nice "ruf" option: we were informed of
an attack just a little too often... We received roughly 275.000
per-message "ruf" reports of the same incident in less than a day.
Comeing from one (large) ESP. That filled some queues here and there in
our modest office environment and slowed down the e-mail for almost the
entire day. Pretty frustrating. Almost made me want to turn of the "ruf"
option.

-- 
Marco

---

From: Terry Zink <[email-masked]>
Date: Thu, 24 Nov 2016 20:33:48 +0000

As a representative of a large email receiver, here's what I think:

1. This is basically an attempt to solve the capacity problem - a burst of email can overwhelm a DMARC reporting mechanism, and therefore proposes a way to tell the DMARC-report generator to "wait a few seconds, minutes, or hours." Yet dealing with capacity issues is something that email receivers have been dealing with for years, and not just DMARC-related. A spam run generated by a spammer can overwhelm capacity; an on-prem mail server gone wild can overwhelm capacity; a burst of large attachments can overwhelm capacity; and so forth. To account for that, email receivers use load balancers, have rate limiting and throttling, segregate customers into different partitions, and build out capacity such that the average load is only 40% of network capacity (to handle failover in case one data center goes out). We don't put the responsibility on the sender other than for them to handle 4xx level errors when we start throttling them.

2. From the draft:

The request implies that the Domain Owner is willing to accept no
   more than one message-specific failure report every 5 minutes from
   any report generator.  A report generator in this example would
   typically honour the "fi" tag by sending out a report, storing a
   'last report sent' timestamp for example.com in memory and
   maintaining it as a 'do not sent' flag for a minimum of 300 seconds
   during which period no consecutive reports are to be sent.  After the
   flag has cleared, a report may again be sent.  The cycle then
   repeats.
<<<

This won't work as well as you hope. Modern day large email receivers are globally load-balanced with hundreds or thousands of mail servers. If a spammer sends a massive spam run spoofing your domain, and each of those servers (e.g., 1000 of them) get one of those messages and sends a DMARC report, you're still overwhelmed with volume because each one of those mail servers has to know that the other one just sent a DMARC report back. The "fix" for this is - "Well, each of those mail servers in the network should share that that 'last DMARC report time' with everyone else", which means that we have to build infrastructure to send that information across to all servers in real time, perhaps on the order of seconds (after all, the fi may be as small as 1 second).

Why would a large email receiver build out its infrastructure this way to support DMARC, when the DMARC-requester could build out *their* email infrastructure to support bursts of email, which they need anyway per my first point?

-- Terry

-----Original Message-----
From: dmarc [mailto:[email-masked]] On Behalf Of Marco Davids (IETF IMAP)
Sent: Thursday, November 24, 2016 1:52 AM
To: [email-masked]
Subject: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag

Dear community,

Problem:

Per-message failure reports as requested by the "ruf" tag are a useful source of information when debugging deployments or in analyzing attacks.

However, under certain circumstances this property can potentially lead to an undesirably high volume of reports.  Especially when a Domain Owner's name is spoofed and abused in a large-scale phishing or other impersonation attack.

RFC7489 offers only a very limited solution to this problem (in section 7.3).

The lack of a mechanism for a Domain Owner to influence the volume of reports constitutes an obstacle to deployment of the "ruf" tag feature.

Solution:

In draft-davids-dmarc-fi-tag I propose a new DMARC tag, the "fi" tag. It provides a Domain Owner with a simple way of requesting limitation of the rate at which such reports are sent.

Please let me know what you think of it. I'm looking forward to a fruitful discussion on the design choices I made and I also hope for support of the idea.

Thanks.

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-davids-dmarc-fi-tag%2F&data=02%7C01%7Ctzink%40exchange.microsoft.com%7Cd61a1490f62e42ac435208d4144f8675%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636155779175120151&sdata=t92Zw9m%2BCkqcY7%2B2mgY5%2BvuzGd2zN6OUwyoRiq7L%2F10%3D&reserved=0

--
Marco Davids
SIDN Labs

_______________________________________________
dmarc mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmarc&data=02%7C01%7Ctzink%40exchange.microsoft.com%7Cd61a1490f62e42ac435208d4144f8675%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636155779175120151&sdata=ucH%2B%2BjwgdOlAuOJdh5z47x%2Bu%2BDVP2%2FZR5H0W7YTqU7w%3D&reserved=0

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 24 Nov 2016 12:40:13 -0800

+1 to Terry's points.  On the other hand, "fi" is described mainly as a
request (modulo the SHOULD NOT, which is debatable in my opinion) which
means DMARC verifiers are free to ignore it.

On Thu, Nov 24, 2016 at 12:33 PM, Terry Zink <[email-masked]>
wrote:

> Why would a large email receiver build out its infrastructure this way to
> support DMARC, when the DMARC-requester could build out *their* email
> infrastructure to support bursts of email, which they need anyway per my
> first point?
>

Terry: Would it be helpful at all for a large operator to get signal that
this small operator will be easily overwhelmed, or does it really make a
difference?

Marco: I don't agree with the use of ARF's "Incidents" count in this way,
because that field is intended to indicate the number of identical
incidents that were aggregated into a single report.  If you want to use
that mechanism, it should be clear that only identical attack incidents
should be reported that way.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 24 Nov 2016 12:47:11 -0800

On Thu, Nov 24, 2016 at 1:51 AM, Marco Davids (IETF IMAP) <
[email-masked]> wrote:

> [...]

I seem to recall debating this idea during the pre-IETF work on DMARC.  I
also seem to recall it being removed from what became the final
specification, probably for reasons already mentioned on this thread.

Another point is that this will only help an overwhelmed receiver if the
DMARC failures are all being reported by one source or a small number of
sources.  The reports generated by a highly distributed phishing campaign,
for example, will not be seriously controlled by this feature.

-MSK

---

From: "Marco Davids (IETF IMAP)" <[email-masked]>
Date: Thu, 24 Nov 2016 22:01:13 +0100

Hi Terry,

> As a representative of a large email receiver, here's what I think:

Much appreciated.

> 2. From the draft:

<SNIP>

> The cycle then repeats.

> This won't work as well as you hope. Modern day large email receivers
> are globally load-balanced with hundreds or thousands of mail servers.

I realized and tried to address it with this part in the security
considerations section:

"Mail Receivers with a farm or cluster of several report generators
might choose to synchronise the 'last sent' timestamp value accross
their machines in order to better comply with the wishes of Domain
Owners and to reduce the risk described above."

Even if this goal is only partly achieved, it is still better then
nothing not having rate limiting at all.

> Why would a large email receiver build out its infrastructure this way
> to support DMARC, when the DMARC-requester could build out *their*
> email infrastructure to support bursts of email, which they need
> anyway per my first point?

Certainly a valid question. My answer would be: Huge amounts of spam
towards our domain are dealt with quite nicely nowadays, by simply
blocking the e-mail at our front door with the well known means.
However, the per-message "ruf" reports is no spam and was qualified as
legitimate e-mail. So that makes it a bit of a different story.

Now, I see three possible solutions:

- Disable the "ruf" tag altogether, in our DMARC record,
- Invest in more e-mail capacity, basically only for these rare events
of "ruf" mailbombs,
- Come up with a solution like the one I proposed.

Now, my proposed solution is not anywhere near a complete 'holy grail'
kind of solution for everything. But it seemed like the most pragmatic
option of all the above.

--
Marco

---

From: "Marco Davids (IETF IMAP)" <[email-masked]>
Date: Thu, 24 Nov 2016 22:14:39 +0100

On 24/11/2016 21:40, Murray S. Kucherawy wrote:
> +1 to Terry's points.  On the other hand, "fi" is described mainly as > a request (modulo the SHOULD NOT, which is debatable in my opinion)
> which means DMARC verifiers are free to ignore it.

It's a request, but my intend was it MUST be supported when the "ruf"
tag is honored. Only if there is no "ruf", or a report generator ignores
the "ruf", than the "fi" may be ignored. (I know some report generators
don't implement "ruf", for reasons of privacy).

But it's a draft, so everything is debatable as far as I am concerned. I
welcome any suggestion.

> Terry: Would it be helpful at all for a large operator to get signal
> that this small operator will be easily overwhelmed, or does it really
> make a difference?

That's what is is: nothing more than a signal and/or a request? Just
like the "ri" tag, basically.

> Marco: I don't agree with the use of ARF's "Incidents" count in this
> way, because that field is intended to indicate the number of
> identical incidents that were aggregated into a single report.  If you
> want to use that mechanism, it should be clear that only identical
> attack incidents should be reported that way.

Good point. It's probably gonna be hard to define what exactly an
identical incident is. Does an identical 'from', identical 'subject' but
different 'to' count as the same incident for example? If this is
getting too complicated, I don't mind leaving this part out of the draft
altogether. What do you think? Shall I leave it out? Or do you like to
propose some alternative text?

-- 
Marco

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 24 Nov 2016 18:02:51 -0800

On Thu, Nov 24, 2016 at 1:14 PM, Marco Davids (IETF IMAP) <
[email-masked]> wrote:

> > +1 to Terry's points.  On the other hand, "fi" is described mainly as >
> a request (modulo the SHOULD NOT, which is debatable in my opinion)

Making it a MUST imposes infrastructure costs on report generators, as
we've been describing.  There's not much incentive for them to comply, and
I imagine you'd have a hard time reaching consensus to support such a
change.

> propose some alternative text?

Actually now that I re-read it, the ARF RFCs you cite just say "similar"
without specifying what that means exactly, so I guess that means it's up
to report generators to decide what sort of grouping they want to use with
"Incidents", understanding that any imprecise grouping is inherently lossy
and the receiver of such a report is free to infer what it actually means.

I suggest you take a crack at defining what you have in mind for
"identical" here.  How would you use it?

-MSK

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Fri, 25 Nov 2016 08:35:39 +0100 (CET)

Hi, Marco,

> queued. They only add to the statistics of aggregated "rua" reports.

I'm sorry, missed that one (just scanned (too) quickly through the draft). As it's pretty essential to the draft you may want to add one line to the end of section 1 on this.

/rolf

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Fri, 25 Nov 2016 08:44:14 +0100 (CET)

[...]
> like the "ri" tag, basically.

Rate limiting on the sender domain side, providing an SMTP 4.x.y response when the server is overwhelmed solves this problem in a natural way.

/rolf

---

From: "Marco Davids (IETF IMAP)" <[email-masked]>
Date: Fri, 25 Nov 2016 10:09:32 +0100

On 25/11/2016 03:02, Murray S. Kucherawy wrote:

>> my intend was it MUST be supported when the "ruf" tag is honored.
> 
> we've been describing.  There's not much incentive for them to comply,
> and I imagine you'd have a hard time reaching consensus to support
> such a change.

I prefer a more positive approach: implementing support for the "fi" tag
is a concrete and well defined way of doing some rate limiting as was
already more vaguely suggested in the last paragraph of RFC7489 section
7.3, third and possibly even second bullet.

Sending only a sample of per-message reports, instead of all of them
might be in the benefit of report generators as well. That is also why I
considered to set the default value for the "fi" tag to for example
something like 10 seconds (a value of 0 would than mean: send all
reports, do not rate limit). With a value of 10 (or 30 or even 60),
report generators can save resources. That is why it is also in their
interest. The default is now: '0'. But thinking of this, maybe '60'
would be a better default?

>> I don't agree with the use of ARF's "Incidents" count in this
>> way, 

> Actually now that I re-read it, the ARF RFCs you cite just say
> "similar" without specifying what that means exactly

<SNIP>

> "identical" here.  How would you use it?

Let me think about that. I'll make a note and draw up some text.

Thanks!

-- 
Marco

---

From: "Marco Davids (IETF IMAP)" <[email-masked]>
Date: Fri, 25 Nov 2016 10:15:10 +0100

On 25/11/2016 08:35, Rolf E. Sonneveld wrote:

> I'm sorry, missed that one (just scanned (too) quickly through the
> draft). As it's pretty essential to the draft you may want to add one
> line to the end of section 1 on this.

Done. Thanks.

-- 
Marco

---

From: "Marco Davids (IETF IMAP)" <[email-masked]>
Date: Fri, 25 Nov 2016 10:33:19 +0100

On 25/11/2016 08:44, Rolf E. Sonneveld wrote:
>>> that this small operator will be easily overwhelmed, or does it
>>> really make a difference?
>>
>> That's what is is: nothing more than a signal and/or a request. Just
> Rate limiting on the sender domain side, providing an SMTP 4.x.y
> response when the server is overwhelmed solves this problem in a
> natural way.

Not really; there is a significant difference. Pushing back mailbombs
with a temporary 4.xxx.yyy code will still cause the per-message reports
being delivered at long last, it will simply take more time. And that
would only solve part of the problem. What I perhaps should I mentioned
earlier: the biggest problem wasn't our mail servers being overwhelmed,
but rather some underlying IPS-kind of devices and, ultimately, the
e-mail client on my laptop that didn't handle the amount of 275,000
e-mails very well. Probably because of antivirus software kicking in.

And a permanent 5.xxx.yyy isn't an option either. We cannot expect a
mail environment to do that for something that looks like a perfectly
legitimate e-mail. There may easily be situations where you do want to
receive 275,000 e-mails regarding X (unless X is: 'per-message ruf
reports'). Hard to define that at the receiving end. For example: you
only find out that you received 275,000 mails that you didn't really
wanted... after you have received them...

At least that's my take on this matter.

-- 
Marco

---

From: "John Levine" <[email-masked]>
Date: 25 Nov 2016 15:19:40 -0000

>back on senders or intermediaries anyway).

If you're worried about capacity problems from DMARC reports, use a
separate subdomain and a separate MTA so if it gets overwhelmed, the
rest of your mail isn't affected.  If you really want to isolate
it, spin it up in a VPS of the $10/mo variety.

On today's Internet, 275K messages/day is not a lot, and should not
need a lot of infrastructure to handle or discard.  If the reports all
come from the same place, it is not rocket science to block the
source.  As you note, if the junk comes from all over the place,
you'll need to deal with it all anyway, so a limit in ruf wouldn't
help.

Also, if you use a separate MTA, you can skip all the content based
spam filtering since it's easier to look and see if a message contains
the failure ARF report or the summary XML attachment and throw it away
otherwise than to see if it looks spammy.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 25 Nov 2016 15:21:04 -0000

>don't implement "ruf", for reasons of privacy).

Remember that MUST only means "do this if you want to interoperate
reliably."  This is the Internet, where anyone can do anything,
including ignoring rate limits.

R's,
John

---

From: Terry Zink <[email-masked]>
Date: Fri, 25 Nov 2016 17:53:36 +0000

> Terry: Would it be helpful at all for a large operator to get signal that this
> small operator will be easily overwhelmed, or does it really make a difference?
I don’t think it would make a difference, although it’s hard to say. We’ve had problems delivering DMARC reports to DMARC aggregators before; the queues build up on our side and generate alerts. We try hard to deliver every email, but in this case we would delete the email and not retry.

Delivery problems are nothing new, we have to deal with them all the time. What we likely wouldn’t do is respect the fi= tag the way it’s written in the spec.

From: Murray S. Kucherawy [mailto:[email-masked]]
Sent: Thursday, November 24, 2016 12:40 PM
To: Terry Zink <[email-masked]>
Cc: [email-masked]
Subject: Re: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag

+1 to Terry's points.  On the other hand, "fi" is described mainly as a request (modulo the SHOULD NOT, which is debatable in my opinion) which means DMARC verifiers are free to ignore it.
On Thu, Nov 24, 2016 at 12:33 PM, Terry Zink <[email-masked]<mailto:[email-masked]>> wrote:
Why would a large email receiver build out its infrastructure this way to support DMARC, when the DMARC-requester could build out *their* email infrastructure to support bursts of email, which they need anyway per my first point?

Terry: Would it be helpful at all for a large operator to get signal that this small operator will be easily overwhelmed, or does it really make a difference?
Marco: I don't agree with the use of ARF's "Incidents" count in this way, because that field is intended to indicate the number of identical incidents that were aggregated into a single report.  If you want to use that mechanism, it should be clear that only identical attack incidents should be reported that way.
-MSK

---

From: Hector Santos <[email-masked]>
Date: Fri, 25 Nov 2016 13:20:55 -0500

My comments.

First, DMARC (RFC7489) is not a standard. Its an informational 
document. This needs to change. In my view, DMARC is far from 
complete. There are a number of unsolved issues that are forcing less 
than adequate "kludges" to be done.   The fact this new proposal 
illustrates yet another "kludge" to fix a non-IETF standard, is 
testament of my point.

Second, DMARC "should" not required any reporting to be done by 
implementors. It is wasted, redundant overhead that was well known to 
be an exploitable concept. (Reporting was rejected ny earlier DKIM WG 
POLICY proposals). It should be an option and not a protocol mandate. 
  The proof of concept was well long established that exclusive 
policies are very possible for the purpose of deterministic 
rejections.   Perhaps, DMARC should be split into two protocols.

Overall, Lets not create additional kludges for what still remains as 
an "informational" IETF document.  We might call it a 
"pseudo-standard" because of wide usage but in reality it is an 
informational status document -- not officially a standard.  I support 
an IETF standardization effort of DMARC with a charter that includes 
development of additional options we need in order to support 3rd 
party Authorization method, expansion of policy options and plus 
relaxation of any reporting requirement.

-- 
HLS

---

From: "Marco Davids (IETF IMAP)" <[email-masked]>
Date: Fri, 25 Nov 2016 20:30:26 +0100

Hi Terry,

On 25/11/2016 18:53, Terry Zink wrote:

> We’ve had problems delivering DMARC reports to DMARC aggregators
> before; the queues build up on our side and generate alerts. We try
> hard to deliver every email, but in this case we would delete the 
> email and not retry.
> 
> What we likely wouldn’t do is respect the fi= tag the way it’s
> written in the spec.

Let me see if I get this right:

You are pushing the limits of the receiving end of DMARC reports to the
point where queues start building up on your side and then delete within
your discretion?

While at the same time you would renounce a kind request from the
receiving end that could have prevented you from sending that excess of
reports in the first place?

Dunno but...

--
Marco