Hi, Marco,
On 24-11-16 10:51, Marco Davids (IETF IMAP) wrote:
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.
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
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
