On Oct 9, 2007, at 3:59 AM, Frank Ellermann wrote:
Douglas Otis wrote:
There is a real risk SPF might be used as basis for acceptance
You can combine white lists with SPF PASS as with DKIM "PASS", the
risk is very similar.
Due to the macro nature of SPF, full processing is required for each
name evaluated. With SPF, the recipient might be interested in the
PRA, or MAIL FROM. Of course DKIM now adds d= or i= identities.
Since DKIM is prone to replay abuse, when an SPF hammer is the only
tool, more names are likely to be added to the evaluation. These
additional evaluations are intended to reduce the number of messages
lost since neither the PRA and MAIL FROM are limited to the path
registered by an SPF address list. Now imagine an iterative process
of developing comprehensive lists of all addresses used on behalf of
a domain which attempts to embrace IPv6. : (
Much of the danger of auto responses has to do with DDoS concerns.
It depends on the definition of "DDoS". From my POV as POP3 user
over a V.90 connection 10,000 unsolicited mails are just bad, no
matter what it is (spam, worm, DSN, or auto-response).
Perhaps IANA should allow ISPs to register their dynamic address
space. Greater protection is afforded when excluding dynamic address
space. Nevertheless, more protection would be afforded by a
convention that excludes message content within a DSN. For each
directly addressed spam source, there are 3 DSN sources that include
spam message content. Cleaning up how DSNs are constructed would be
_far_ more effective than asking that all DSNs be dropped when SPF
does not produce a PASS. Perhaps that is why Bell Canada ensures all
addresses achieve a PASS. : (
It's not really a "DDoS". SPF at least helped me to get rid of the
bogus DSNs and other auto-responses since three years, smart
spammers are not interested to forge SPF FAIL protected addresses.
Spammers are equally uninterested in abusing MTAs that produce DSNs
compliant to RFC3464 where message content has been removed. This
strategy also avoids the SPF overhead and related risks. : )
BTW, I think the definition of "Joe job" in the sieve EREJECT draft
is obsolete, the mere abuse of "plausible" addresses is no "Joe
job" and IMO also not a real DDoS. But it's certainly bad for the
victims, it can be bad enough to make a mailbox unusable for some
victims.
Yes, DSNs that include content are a problem. Dropping NDN or DSN
that indicate a failure of some sort also makes email less reliable.
Email has become far less reliable as a result. The TPA-SSP scheme
for DKIM allows a return path to authorize the DKIM signature only to
encourage the issue of DSNs. Again, those DSNs should still exclude
original message content.
A safer approach would be to format all DSNs per RFC3464 and
remove original message content.
I'd hope that a majority of receivers already does this, that's
state of the art for some years now. Or rather "truncate" is state
of the art, not complete removal of the body.
It would be rather tempting to make this mode of DSN operation a
requirement. At any point of time, we see some 20 million different
MTAs which do not remove message content are currently being
exploited. Perhaps we should add a new list that indicates which
MTAs do not remove content on DSNs? We could then let our customers
decide whether they want traffic from these MTAs as well. Not all
that different from open-proxies and aimed at restoring DSN integrity.
Mailman made a mistake where an error caused a DSN that returned
original content without first verifying the validity of the
return path.
Auto responders aren't in a good position to verify the validity of
the return path. Good positions to do this are the MSA based on
RFC 4409 and later the MX based on RFC 4408.
RFC4408 did not mitigate a potential DDoS exploit. This exploit
exists when recipients attempt to process SPF as specified. There
are several SPF parsing libraries that lack even suggested limits on
subsequent address resolutions for MX records, for example. There
are some libraries that restrict the number of MX targets and cause
some domains to not be fully resolved at times. Even this reduction
in possible MX targets will not make these libraries much safer.
The SPF DoS draft example clearly illustrates an SPF process (current
open source compliant with RFC4408) might generate more than 50 to
100 DNS transactions per name evaluated. The level of this risk
depends upon the negative caching of recipients and how frequently
the local-part of the spam campaign repeats. The latter only needs
to be a bit longer than the former. The evaluation process may still
result in an SPF PASS. Any reliance upon SPF is likely to cause a
list of names being evaluated to grow. An SPF iterative process also
means poisoning DNS is made far easier. Keep in mind there are now
plug-ins for web-clients and MUAs.
As it is now, those clever enough to manipulate SPF libraries are
also able to instigate a reflected attack on par with leveraging
large RRs against a phalanx of open recursive servers. SPF however
makes this attack free for those that also wish to spam. SPF would
also obscure the origin of the attack. The source might not be found
in mail logs either. : (
-Doug
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf