On Thu, Nov 24, 2016 at 10:34 AM, Rolf E. Sonneveld < r.e.sonnev...@sonnection.nl> wrote:
> > > 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); > > 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
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
