Re: TMDA backscatter

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]