Re: TMDA backscatter

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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf