On Wed, Jun 23, 2004 at 12:46:02PM -0500, Eric A. Hall wrote:
What is the possibility that an attacker could list a (SID|SPF) record
with references to ~thousands of domains, forcing my SMTP server to spend
large amounts of time and/or processing power validating the junk data?
What other similar kinds of attacks are enabled by infinite extensibility?
There is also still the argument that 513-byte records affect a DDoS
attack against my domain.
The more I think about this, the less I think that extensibility is a good
idea in general.
No. This is not a problem of extensibility.
This is an attack outside the threat model.
All these caller authorization methods are designed against
an attacker who does not want to reveal his identity (=domain).
An attacker who attacks you while not hiding his own domain is
a different kind of attack. Such an attacker could also simply
allow mail from 0.0.0.0/0, thus authorizing all IP addresses in
order to allow spam.
This has already been discussed more than a year ago in ASRG and
addressed in RMX and other proposals. It is up to you to define
a policy about domains you're willing to accept mail from.
E.g. you could choose to not accept mail from domains authorizing
more than 50 IP addresses. Thus the interpreter could reject messages
from domains with such a record with thousands of references without
performing a single query. And you should do it.
Imagin this attack: An attacker is sending millions of spam with
his own sender address @attacker.tld
His MARID record is generated dynamically with thousand references
of the type randomnumber.victim.tld
Thus the victim's DNS server will have to serve billions of queries.
You need limits.
But, if this happens, you know at least the domain the attacks came
from. It is similar to the case where the spammer simply used his
own domain as a sender address (=does not fake). Fake protection is
useless against attackers who do not fake. You still need
blacklisting, but now blacklisting is possible. And you need
whois entries which allow to identify the person responsible for
the domain.
regards
Hadmut