In <20040511084251(_dot_)GC4206(_at_)dumbo(_dot_)pobox(_dot_)com> Meng Weng
Wong <mengwong(_at_)dumbo(_dot_)pobox(_dot_)com> writes:
On Tue, May 11, 2004 at 10:15:00AM +0200, Lars Dybdahl wrote:
|
| I totally agree that there should be a limit on the number of DNS
| lookups necessary to look up SPF records, stated in the specification -
| otherwise somebody else might introduce limits in the implementations.
I've updated the draft, please check the latest 200405 --- I believe
it already addresses this problem. You are limited to 20 recursions
total, not a depth of 20. (Recursions mean include/redirect operations.)
I think it is very important to limit the number of DNS lookups, not
the number of include:/redirect= operations. It is the DNS lookups that
take time and bandwidth and an mx: mechanism can easily be more
expensive than an include:.
If you can count include: mechanisms, then it shouldn't be very hard
to count other mechanisms also.
I also think that the processing limits should not be optional. In
order to prevent DoS attacks on third parties, all SPF implementations
*MUST* limit the number of DNS queries. I think it is critical that a
malicious person can't publish an SPF record that allows them to
easily have send SMTP MAIL FROM: commands an MTA that does SPF checks,
and have those MTAs generate a large number of DNS lookups on a third
party victim.
I have done some investigation about the how much bandwidth is used by
sending the SMTP MAIL FROM: commands compared with the amount of
bandwidth that can be generated via SPF checks. As a result of this
investigation, I found that I was a little bit too conservative on the
limits that I have in libspf-alt. I am going to double the processing
limits that I had put in place, but I really think that going beyond
the limits outlined below is asking for trouble.
My suggested text for the Processing Limits section of the spec is:
6.2 Processing Limits
During process, and SPF client may perform DNS lookups and
additional SPF subqueries due to the "include" mechanism and the
"redirect" modifier.
In order to prevent Denial-of-Service attacks, the total number of
DNS lookups must be limited. The subject of a Denial-of-Service
attack can be either the SPF client directly, or some third party
domain that is referenced in the SPF record. For example, a
malicious person could create an SPF record with many references to
a victim domain, send many emails to different SPF clients and the
SPF clients would create a DoS attack. In effect, the SPF clients
are being used to amplify the attacker's bandwidth by using few
bytes to send the email than is generated by the DNS queries.
As a result, limits that may seem reasonable for an individual mail
server can still allow an unreasonable amount of bandwidth
amplification. Therefore the processing limits need to be quite
small.
SPF implementations MUST limit the number of mechanisms that do DNS
lookups to at most 20. For example, the "mx" mechanism requires a
DNS lookup, so will count against this limit, while the "ip4"
mechanism does not require any DNS lookups.
When evaluating the "mx" mechanism, there MUST be a limit of no
more than 10 mail looked up and checked for matching IP addresses.
When evaluating the "ptr" mechanism or the %{p} macro variable,
there MUST be a limit of at most 10 PTR DNS records looked up and
checked for a validated hostname.
SPF implementation SHOULD limit the total amount of data obtained
from the DNS queries. For example, when DNS over TCP is available,
there may need to be an explicit limit to how much data will be
accepted to prevent excessive bandwidth usage or memory usage.
SPF implementation SHOULD impose a walk-clock time limit on the
evaluation of an SPF record in order to prevent problems with DNS
queries from creating excessive delays. The limit SHOULD be allow
the SPF evaluation to last at least 30 seconds.
-wayne