From owner-ietf-mxcomp@mail.imc.org Thu Nov 02 11:58:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfftE-0002Yr-4L for marid-archive@lists.ietf.org; Thu, 02 Nov 2006 11:58:04 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfftA-0006hU-Kl for marid-archive@lists.ietf.org; Thu, 02 Nov 2006 11:58:04 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA2GCG4u055696; Thu, 2 Nov 2006 09:12:16 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA2GCG7E055695; Thu, 2 Nov 2006 09:12:16 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost1.mail.uk.easynet.net (smarthost1.mail.uk.easynet.net [212.135.6.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA2GCF8L055689 for ; Thu, 2 Nov 2006 09:12:16 -0700 (MST) (envelope-from ietf-mxcomp.lists@instabook.com) Received: from bb-87-80-252-9.ukonline.co.uk ([87.80.252.9]) by smarthost1.mail.uk.easynet.net with esmtp (Exim 4.10) id 1GffAs-000OIz-00 for ietf-mxcomp@imc.org; Thu, 02 Nov 2006 16:12:14 +0000 From: "K.J. Petrie" To: ietf-mxcomp@imc.org Subject: Trouble with Sender Authentication Date: Thu, 2 Nov 2006 16:12:13 +0000 User-Agent: KMail/1.9.4 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611021612.13627.ietf-mxcomp.lists@instabook.com> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe I hate to spoil a good party, but it seems to me there are several minor flaws and one major flaw with all the proposed methods of reducing spam through authenticating senders, which will either prevent their adoption or render them useless once widely adopted. SPF, for instance, breaks forwarding. This will stop it catching on widely, because domain owners are likely to use forwarding for their incoming mail. If their ISP adopts SPF they could lose all incoming mail from domains with an SPF record. To prevent this, the forwarding company, over which the domain owner may have no control, must take action. So we have a proposed system which requires unrelated entities to take co-ordinated action if it is not to disrupt mail delivery to the very people responsible for enabling it. This could be fixed by adding a Recipient Protocol Framework (my name - apologies if something called this already exists) to the standard, specifying servers which were to PASS all mail addressed To: (or Cc: Envelope-To: etc) the domain without checking the sender's domain. The RPF record could then be set up by the domain owner, either as a separate string or an entry in the same string, at the same time as the SPF record, and so forwarding could be enabled by the person who should control it- the domain owner, without worrying about whether one company or another had implemented the checks. However, this is only a minor flaw. Much more significant is the fact that all these systems depend on publishing information. What is published for the use of the good guys is also available to the baddies, and that's the real problem. For among the hundreds (or, more likely thousands) of requests for SPF records name servers would receive from MTA's every second could be hundreds of identical requests from a data-mining program seeking to build a reverse-lookup database. Once the spammers have such a database it will be relatively simple for them to write software which spoofs credible domains for every spam injection point they use. And where will that leave us? Back where we started, but with increased network traffic and DNS load doing useless checks. Certainly, my experience with spam is that, wherever it appears to come from, there are only five or six basic variants being sent repeatedly at any one time. Therefore, it is likely all this mail is coming from only five or six real sources which have managed to infiltrate the Internet at a large number of points. Do we really imagine people who do that will be put off by the need to run a little more automated research? Identifying spammers (or, more likely, trojanised mailers) and their reply websites (or, again more likely, trojanised proxies) is only as good as the abuse desks which take action, and overstretched resources take time to close down these gateways. The spammers know this, and presumably make their profit in the intervening interval, and are always ready to move on. They are the Internet's suitcase boys, standing on a street corner and ready to run when a police officer comes within sight. To make spamming and the associated activities unprofitable requires an automated system which either cannot be abused, or which punishes abuse so rapidly it cannot be worthwhile. I don't want to be negative, but it seems evident that a lot of highly talented effort is being directed at something which is not a solution, and that effort could be better used devising something more radical and effective. I realise such a solution might be off-topic for this list. I have no ideas at present, I'm afraid. I was directed to this list by the spf-discuss sign-up response. Best wishes, K.J. Petrie. From owner-ietf-mxcomp@mail.imc.org Thu Nov 02 13:52:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfhgM-0006zs-IE for marid-archive@lists.ietf.org; Thu, 02 Nov 2006 13:52:54 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gfhg9-00048W-7f for marid-archive@lists.ietf.org; Thu, 02 Nov 2006 13:52:54 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA2IMS4t068327; Thu, 2 Nov 2006 11:22:28 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA2IMSwa068326; Thu, 2 Nov 2006 11:22:28 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA2IMQtg068319 for ; Thu, 2 Nov 2006 11:22:27 -0700 (MST) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GfhCd-0007If-Ht for ietf-mxcomp@imc.org; Thu, 02 Nov 2006 19:22:11 +0100 Received: from du-001-227.access.de.clara.net ([212.82.227.227]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Nov 2006 19:22:11 +0100 Received: from nobody by du-001-227.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Nov 2006 19:22:11 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: Trouble with Sender Authentication Date: Thu, 02 Nov 2006 19:18:13 +0100 Organization: Lines: 75 Message-ID: <454A3665.236C@xyzzy.claranet.de> References: <200611021612.13627.ietf-mxcomp.lists@instabook.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-227.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Cc: spf-discuss@v2.listbox.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac K.J. Petrie wrote: > I hate to spoil a good party The party was closed more than two years ago. You're a bit late... :-) This is a historic battle field. > SPF, for instance, breaks forwarding. The variant explained in RFC 1123 5.3.6(a) or RFC 2821 3.10.1 doesn't work directly if it's checked "again", yes. Actually SPF works only at the first MX of the receiver, and not (without tricks) behind it. Working as designed (back in 2003, before this list existed). > the forwarding company, over which the domain owner may have no > control, must take action. Nope, they can ignore it. The mail FAILs, they bounce it, and the "sender can make other plans" (quote stolen from an unrelated draft). A perfectly sound situation, if you grep for "551" in RFC 821. > This could be fixed by adding a Recipient Protocol Framework (my > name - apologies if something called this already exists) Other names for ideas to arrange things on the side of the receiver are SRS (sender rewriting system), and various "forward plans", the next hop can white-list known "good" forwarders (saving the time for pointless SPF checks resulting in predictable FAIL rejects). There are many ways to solve this, some are mentioned in RFC 4408. > However, this is only a minor flaw. ACK, actually it's the design, SPF enumerates IPs allowed to send mail from the domain in question. For obvious reasons it cannot enumerate IPs somewhere on the side of the various receivers. One of the predecessors was "RMX", like what we know as MX today (for receivers), only "reverse", the IPs of the sender. > What is published for the use of the good guys is also available > to the baddies, and that's the real problem. If a spammer comes to the conclusion that forging my address isn't in the interest of his "business" it's no problem, it's good for me. > Once the spammers have such a database it will be relatively > simple for them to write software which spoofs credible domains > for every spam injection point they use. "Relatively". How ISPs arrange mail submission is a separate issue, they should use SMTP AUTH and enforce submission rights. If I can get a PASS, then I could still get it if I'm a zombie sending spam. A PASS from unknown strangers has a very limited value, wrt SPF it only means that a bounce won't hit innocent bystanders. If it's a PASS from me and you know me I could still be a fresh zombie. But you'd think twice if somebody claiming to be me with SPF PASS etc. suddenly talks about phar*aceu*ical*. For more serious PASS senders like PayPal I'd hope that they limit the zombies sending from within their "borders". So far it works :-) > Do we really imagine people who do that will be put off by the > need to run a little more automated research? No, it's okay if they just stay away from protected addresses. SPF is about avoiding bogus bounces, and encouraging legit bounces, not a magic wand to eliminatie all spam. > I was directed to this list by the spf-discuss sign-up response. Oops, that's wrong, I'll post my reply there too, let the old mxcomp rest in peace, it's dead. Frank From owner-ietf-mxcomp@mail.imc.org Thu Nov 02 14:01:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfhoN-0005I5-N1 for marid-archive@lists.ietf.org; Thu, 02 Nov 2006 14:01:11 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfhoK-00059W-9l for marid-archive@lists.ietf.org; Thu, 02 Nov 2006 14:01:11 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA2IXVCO069171; Thu, 2 Nov 2006 11:33:31 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA2IXV8M069170; Thu, 2 Nov 2006 11:33:31 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.schlitt.net (schlitt.net [67.52.51.34]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA2IXTtq069164 for ; Thu, 2 Nov 2006 11:33:30 -0700 (MST) (envelope-from wayne@schlitt.net) Received: from wayne by backbone.schlitt.net with local (Exim 4.52) id 1GfhNQ-0003N2-8Y; Thu, 02 Nov 2006 12:33:28 -0600 From: wayne To: "K.J. Petrie" Cc: ietf-mxcomp@imc.org References: <200611021612.13627.ietf-mxcomp.lists@instabook.com> Content-Type: text/plain; charset=US-ASCII Date: Thu, 02 Nov 2006 12:33:19 -0600 In-Reply-To: <200611021612.13627.ietf-mxcomp.lists@instabook.com> (K. J. Petrie's message of "Thu, 2 Nov 2006 16:12:13 +0000") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.19 (linux) MIME-Version: 1.0 X-SA-Exim-Connect-IP: X-SA-Exim-Rcpt-To: ietf-mxcomp.lists@instabook.com, ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: Trouble with Sender Authentication X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on backbone.schlitt.net X-Spam-Level: X-Spam-Status: No, score=-4.6 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.4 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on backbone.schlitt.net) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa In <200611021612.13627.ietf-mxcomp.lists@instabook.com> "K.J. Petrie" writes: > I hate to spoil a good party, Hi. I'm afraid there isn't much of a party here, good or otherwise. Yours is the first post to this list since May, and there hasn't been any serious discussion on this list since the MARID working group was shut down. > SPF, for instance, breaks forwarding. [snip] > > [...] What is published for the use of the good guys is also available > to the baddies, [...] Once the spammers have > such a database it will be relatively simple for them to write software which > spoofs credible domains for every spam injection point they use. Both of these points that you raised are very old arguments that have been discussed to death many times over the last 3-4 years. See the archives of the ASRG, spf-discuss, and this MARID mailing lists. None of the things you said haven't been discussed before. Some of the points have been well rebutted by various people, others see these as points where reasonable people can disagree on. I think it is unlikely that you will change many minds, and, since this mailing list is pretty dead, it is probably not a very good place to try discussing it any more. > I was directed to this list by the spf-discuss sign-up response. Thanks for pointing that out. It looks like the spf-discuss "welcome" message has not really been updated since this working group was closed down. I have edited it to bring things up to date. In particular, it no longer says that if you think SPF is fundamentally flawed, you should take your discussions here. That was reasonable advice back when the MARID WG was trying to create something better, but I don't think it is a reasonable request any longer. -wayne From owner-ietf-mxcomp@mail.imc.org Thu Nov 02 17:38:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GflCB-0003ur-GM for marid-archive@lists.ietf.org; Thu, 02 Nov 2006 17:38:00 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GflC8-0001a3-W5 for marid-archive@lists.ietf.org; Thu, 02 Nov 2006 17:37:59 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA2M85RZ087974; Thu, 2 Nov 2006 15:08:05 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA2M85HI087973; Thu, 2 Nov 2006 15:08:05 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA2M84DU087967 for ; Thu, 2 Nov 2006 15:08:04 -0700 (MST) (envelope-from dotis@mail-abuse.org) Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG [168.61.10.151]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id kA2M83ES008533 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 2 Nov 2006 14:08:04 -0800 In-Reply-To: <200611021612.13627.ietf-mxcomp.lists@instabook.com> References: <200611021612.13627.ietf-mxcomp.lists@instabook.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <58CA41E0-1708-41A8-BE6B-7EBB343479A9@mail-abuse.org> Cc: ietf-mxcomp@imc.org Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: Trouble with Sender Authentication Date: Thu, 2 Nov 2006 14:08:42 -0800 To: "K.J. Petrie" X-Mailer: Apple Mail (2.752.2) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b On Nov 2, 2006, at 8:12 AM, K.J. Petrie wrote: > SPF, for instance, breaks forwarding. This will stop it catching on > widely, because domain owners are likely to use forwarding for > their incoming mail. Forwarding is a problem in any address-path registration scheme. Sender-ID alters rfc2822 by asking for a Resent-From header, superseding either Sender or From headers, to be added by forwarding agents. Those advocating SPF-Classic want the MailFrom altered by the forwarding agent where the original domain is folded into the local-part along with a hash and a time-stamp. DSNs are relayed through the last forwarding agent. There is an alternative to SPF-Classic that uses DKIM signed messages. An association of the Mail-From domain with that of the signing-domain can validate the DSN address through an association scheme. An association could look something like: ._DKIM-M. TXT "d=signing- domain" See: http://tools.ietf.org/wg/dkim/draft-otis-dkim-dosp-02.txt This scheme assures the DSN address in one reliable and small DNS transaction. There would not be any concerns related to forwarding breaking an address path registration scheme. An association scheme works without the cooperation of forwarding agents as well. > And where will that leave us? Back where we started, but with > increased network traffic and DNS load doing useless checks. It is much worse actually. SPF scripts allow each spam to generate hundreds of targeted DNS transactions using the resources of those recipients foolish enough to run these scripts. Poorly conceived timeouts in SPF libraries compounds the problem, as this also removes congestion avoidance. SpamAssassin's default timeout is 5 seconds, for example. Any SPF domain can target any other domain with 100 DNS transactions per instance, name, and recipient. See: http://www.ietf.org/internet-drafts/draft-otis-spf-dos-exploit-01.txt or http://www.sonic.net/~dougotis/maawg/SPF%20Exploit%20Concerns-maawg.pdf > Certainly, my experience with spam is that, wherever it appears to > come from, there are only five or six basic variants being sent > repeatedly at any one time. Therefore, it is likely all this mail > is coming from only five or six real sources which have managed to > infiltrate the Internet at a large number of points. Do we really > imagine people who do that will be put off by the need to run a > little more automated research? More than 70% of these messages are introduced from compromised systems, often in concert in the tens of thousands. SPF allows for exploits far more nefarious than research. > Identifying spammers (or, more likely, trojanised mailers) and > their reply websites (or, again more likely, trojanised proxies) is > only as good as the abuse desks which take action, and > overstretched resources take time to close down these gateways. The > spammers know this, and presumably make their profit in the > intervening interval, and are always ready to move on. They are the > Internet's suitcase boys, standing on a street corner and ready to > run when a police officer comes within sight. To make spamming and > the associated activities unprofitable requires an automated > system which either cannot be abused, or which punishes abuse so > rapidly it cannot be worthwhile. DKIM always signed by the transmitting entity in conjunction with standardized opaque identifiers and an opaque-identifier revocation scheme would be a solution that could streamline abuse reporting aimed at eliminating much of the spam. See: http://tools.ietf.org/wg/dkim/draft-otis-dkim-security-concerns-01.txt This list remains available for continued discussions of any MARID related issues. The spf-discuss reflector required participants to first agree with the promotion of SPF. An insurmountable barrier for some. : ) A primary use of SPF is for white-listing bulk senders (otherwise frequently being block-listed). DKIM in conjunction with an SMTP Client association scheme more reliably fulfills that purpose, where the DNS transactions are significantly reduced as well. When validating the EHLO is first, a DDoS attack is rather improbable. -Doug From owner-ietf-mxcomp@mail.imc.org Thu Nov 02 21:40:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfowt-0006sN-R0 for marid-archive@lists.ietf.org; Thu, 02 Nov 2006 21:38:27 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfolP-0001II-7u for marid-archive@lists.ietf.org; Thu, 02 Nov 2006 21:26:36 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA31utGp005227; Thu, 2 Nov 2006 18:56:55 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA31utIq005226; Thu, 2 Nov 2006 18:56:55 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.schlitt.net (schlitt.net [67.52.51.34]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA31urYH005219 for ; Thu, 2 Nov 2006 18:56:54 -0700 (MST) (envelope-from wayne@schlitt.net) Received: from wayne by backbone.schlitt.net with local (Exim 4.52) id 1GfoIW-00055w-1n for ietf-mxcomp@imc.org; Thu, 02 Nov 2006 19:56:53 -0600 From: wayne To: ietf-mxcomp@imc.org References: <200611021612.13627.ietf-mxcomp.lists@instabook.com> <58CA41E0-1708-41A8-BE6B-7EBB343479A9@mail-abuse.org> Content-Type: text/plain; charset=US-ASCII Date: Thu, 02 Nov 2006 19:56:43 -0600 In-Reply-To: <58CA41E0-1708-41A8-BE6B-7EBB343479A9@mail-abuse.org> (Douglas Otis's message of "Thu, 2 Nov 2006 14:08:42 -0800") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.19 (linux) MIME-Version: 1.0 X-SA-Exim-Connect-IP: X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: Trouble with Sender Authentication X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on backbone.schlitt.net X-Spam-Level: X-Spam-Status: No, score=-6.1 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00, GREYLIST_ISWHITE autolearn=ham version=3.0.4 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on backbone.schlitt.net) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 In <58CA41E0-1708-41A8-BE6B-7EBB343479A9@mail-abuse.org> Douglas Otis writes: > [long rant that DougO has repeatedly given over the last 3 years snipped] > This list remains available for continued discussions of any MARID > related issues. The spf-discuss reflector required participants to > first agree with the promotion of SPF. An insurmountable barrier for > some. : ) The SPF-discuss mailing list has never required you to agree with the promotion of SPF. Promotion of SPF is one of the on-topic discussions for the list, as is *constructive* discussions. There have been *lots* of people who have talked about lots of different problems with SPF on the SPF-discuss list. I've asked several times now if any of the other list moderators have ever thrown anyone off, and so far we can't come up with one case. Doug, I've read a lot of your postings about SPF over the last several years, and I can't say I can recall you ever trying to make a *constructive* suggestion on how to improve SPF, other than to throw it out. If the requirement that you need to be constructive has kept you off the spf-discuss list, I can't say I'm sorry about it. As far as the SPF DoS stuff goes, I was the first to really raise the issue of the DoS potential of SPF back in 2003. The constructs that you have mentioned in your I-D were analyzed by me before you first wrote a post about SPF. The lack of sufficient process limits was one of the major reasons why I split with Mark Lentczner on the SPF-classic draft and started my own, which eventually became RFC4408. I have discussed this at length on the SPF list. The difference between you and me is that I offered *constructive* ways to change SPF so that the DoS potential is greatly reduced. I really think your huge exaggerations and running around like chicken-little claiming that the sky will fall if SPF is adopted has done more to hurt my push to take SPF DoS potentials seriously than anything else. I've read your draft. Your numbers don't make sense. You spend way too much time promoting yourself and ranting, and far too little time actually presenting data. It wasn't until your -01 version of your draft that you actually presented hard data in your Appendix A. Your data doesn't back up your 1000x claims. As I said, I've done this analysis before. I actually *tried* to set something up that would DoS Meng's box and tested it, but it turns out that this is *MUCH* harder in practice than your theoretical hand-waving analysis makes it seem. People *don't* have the MTAs set up in stupid ways that make it easy. I'm tired of your rants Doug. I'm tired of your rants making reasonable discussions on this subject harder. And, yes, I realize I'm probably burning a bridge here. -wayne From owner-ietf-mxcomp@mail.imc.org Fri Nov 03 14:38:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg4sG-0003RB-Iw for marid-archive@lists.ietf.org; Fri, 03 Nov 2006 14:38:44 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg4sC-00064p-OF for marid-archive@lists.ietf.org; Fri, 03 Nov 2006 14:38:44 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA3J7mbf002757; Fri, 3 Nov 2006 12:07:48 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA3J7mq0002756; Fri, 3 Nov 2006 12:07:48 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA3J7kkp002749 for ; Fri, 3 Nov 2006 12:07:46 -0700 (MST) (envelope-from dotis@mail-abuse.org) Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG [168.61.10.151]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id kA3J7jqk032579 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 3 Nov 2006 11:07:45 -0800 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: <200611021612.13627.ietf-mxcomp.lists@instabook.com> <58CA41E0-1708-41A8-BE6B-7EBB343479A9@mail-abuse.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: Trouble with Sender Authentication Date: Fri, 3 Nov 2006 11:08:24 -0800 To: IETF MARID WG X-Mailer: Apple Mail (2.752.2) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 On Nov 2, 2006, at 5:56 PM, wayne wrote: > In <58CA41E0-1708-41A8-BE6B-7EBB343479A9@mail-abuse.org> Douglas > Otis writes: > >> This list remains available for continued discussions of any MARID >> related issues. The spf-discuss reflector required participants to >> first agree with the promotion of SPF. An insurmountable barrier >> for some. : ) > > The SPF-discuss mailing list has never required you to agree with > the promotion of SPF. Review the archive and you'll find a posting of the agreement initially required before subscribing to spf-discuss. While it may have changed, this was the reason for not participating on that list. The MARID list is still functional. More than 70% of emails are spam, of which more than 70% are sent from compromised systems. SPF offers powerful tools to these senders. Consuming disproportionate amounts of a recipient's resource remains a philosophical barrier preventing support for an SPF scheme that expects large, powerful, and dangerous scripts be executed by recipients at every stage of delivery. : ( > Doug, I've read a lot of your postings about SPF over the last > several years, and I can't say I can recall you ever trying to make > a *constructive* suggestion on how to improve SPF, other than to > throw it out. In Dusseldorf, Julian and Ming received *constructive* recommendations to allow record scoping, but this was ignored and became the basis for Julian's ignored complaint made to the IESG. Macros contained within SPF scripts require separate transaction sets per each possible and undefined scope, even when the same domain is resolved. : ( > As far as the SPF DoS stuff goes, I was the first to really raise > the issue of the DoS potential of SPF back in 2003. The constructs > that > you have mentioned in your I-D were analyzed by me before you first > wrote a post about SPF. The lack of sufficient process limits was > one of the major reasons why I split with Mark Lentczner on the SPF- > classic draft and started my own, which eventually became RFC4408. The solution adopted in your libraries harms domains by randomizing results of those that utilize more than 5 targets in their MX records. : ( > I have discussed this at length on the SPF list. The difference > between you and me is that I offered *constructive* ways to change > SPF so that the DoS potential is greatly reduced. The design of SPF as a massive script forecloses meaningful solutions. You have yet to recognize SPF creates an impossible situation. : ( > I really think your huge exaggerations and running around like > chicken-little claiming that the sky will fall if SPF is adopted > has done more to hurt my push to take SPF DoS potentials seriously > than anything else. I've read your draft. Your numbers don't make > sense. You spend way too much time promoting yourself and ranting, > and far too little time actually presenting data. You are free to ask questions regarding figures not understood. Several proposals are solutions that avoid threats created by SPF (while also improving email integrity). This is thinking outside the SPF box. No personal gains are achieved by offering IETF drafts or fundamentally opposing SPF. Let's stick to the merits of the concerns. > It wasn't until your -01 version of your draft that you actually > presented hard data in your Appendix A. Your data doesn't back up > your 1000x claims. 45 pages in the addendum trace SPF resolving a single name at about 64:1 increase in traffic. Consider the distribution methods used by spammers. Messages come from tens of thousands of systems at slow rates to avoid detection. This is an ideal platform to leverage SPF for a number of very bad things. Gains stated in the SPF-DoS draft underestimate the risk. Bad actors are sending spam where the possible attack is a gift provided by SPF. Email as well as a long lived SPF records should be excluded from the attack overhead. The same SPF record can utilize components of a local-part to produce infinitely variable transaction sets. Only in rare cases is the intended scope of SPF defined, which means the executions per message, per MHS, and per recipient is unknown. Both the MTAs and MUAs execute SPF scripts. Bad actors have no difficulty using SPF to canvass recipients to determine who is receiving and executing SPF scripts. There has been some rather scary discussions suggesting SPF might control DKIM replay abuse. Such would add any number of new names resolved using SPF. : O > As I said, I've done this analysis before. I actually *tried* to > set something up that would DoS Meng's box and tested it, but it > turns out that this is *MUCH* harder in practice than your > theoretical hand-waving analysis makes it seem. People *don't* > have the MTAs set up in stupid ways that make it easy. Consider how spam is currently being distributed. The attack scenario does not require anything more than executing SPF scripts referenced from the spam received. > I'm tired of your rants Doug. I'm tired of your rants making > reasonable discussions on this subject harder. And, yes, I realize > I'm probably burning a bridge here. Your frustration is appreciated and no bridge is burned. However, please no not dismiss these concerns as rants. -Doug From owner-ietf-mxcomp@mail.imc.org Mon Nov 06 15:11:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhAoR-0001tW-On for marid-archive@lists.ietf.org; Mon, 06 Nov 2006 15:11:19 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhAoQ-0001MB-9R for marid-archive@lists.ietf.org; Mon, 06 Nov 2006 15:11:19 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA6JYbEU064569; Mon, 6 Nov 2006 12:34:37 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA6JYbUW064568; Mon, 6 Nov 2006 12:34:37 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA6JYaxG064562 for ; Mon, 6 Nov 2006 12:34:37 -0700 (MST) (envelope-from dean@av8.com) Received: from piper.av8.net (piper.av8.net [130.105.11.2]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id kA6JYT44010625 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 6 Nov 2006 14:34:35 -0500 Date: Mon, 6 Nov 2006 14:34:29 -0500 (EST) From: Dean Anderson X-X-Sender: dean@piper.av8.net To: IETF MARID WG Subject: Re: Trouble with Sender Authentication In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.8 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 On Fri, 3 Nov 2006, Douglas Otis wrote: > > More than 70% of emails are spam, of which more than 70% are sent > from compromised systems. Most of this isn't commercial, either. Commercial bulk email is no longer a problem. > > Doug, I've read a lot of your postings about SPF over the last > > several years, and I can't say I can recall you ever trying to make > > a *constructive* suggestion on how to improve SPF, other than to > > throw it out. "Throwing it out" is a constructive suggestion. Wasting time on schemes that can't succeed is, well, a waste of time and resources. This is how perpetual motion schemes motivated the development of thermodynamics. SPF is just another perpetual motion scheme which is shown impossible by information theory. The promoters of perpetual motion was similarly "urgently" interested in spending money to build their machines. Thermodynamics demonstrated the scam. Likewise, certain people seem to be making a lot of money consulting on such anti-spam schemes. Or making money on blacklists, and other schemes. In my view, those people aren't solving spam problems. It is questionable what interests those people have in solving spam problems, given that a 'solution' would mean an end to their financial prosperity. It is very odd that non-commercial abuse continues to grow. Who benefits from that? The following may be helpful: -------------- Subject: Re: spam content filtering Queueing and information theory is your friend. Blacklists are generally not your friends, even if well intentioned, DHCP changes virus-infected IP addresses far faster than a human oriented blacklist could keep up. The ones that do keep up tend to be connected to the abuse, and often those are also defamatory of someone. I worked out several years ago, using information theory, that one cannot stop spam with any technical means. The info. theory argument is easy to follow, if you have some little background. It is a known result that one cannot prove the non-existance of a covert channel in a communications system. It is easy to establish that email is a communications channel for information theory. It is also easy to establish that spam is an unwanted communication channel use, equivalent to a covert channel. It then follows that one can't stop spam since that would be the equivalent of proving that a covert channel couldn't exist, which is a contradiction of a known result. One can of course discover spamming, and temporarily stop it on some parameter (e.g. IP address), but this is always a "whack-a-mole" operation. You can never fundamentally improve upon whack-a-mole. [Same is true of spying] What now? Quit? Not at all: Queues are your friend. Place messages from previously known senders in faster queues, while unknown messages are in slower queues. "known senders" can be identified in a variety of ways: email addresses, smtp server IP addresses, etc. Everyone actually gets their spam, and can search it for previously unknown good senders. It just doesn't show up so directly. It just winds up in a slower queue and a different mailbox. These messages can be expired, and/or used to to identify bad senders, and make complaints as you like... Known bad-senders can be expired quicker, etc. One of the good things to happen was the CAN-SPAM Act. Genuine commercial bulk emailers (CBE) are not the cause of abuse, and don't need to be blocked. Genuine CBE's don't abuse open proxies, nor abuse open relays, nor forge headers, nor use viruses to install proxies, etc. This leaves one to wonder who is doing those things. And that brings us back to the certain of the blacklists who were previously found to be doing that sort of thing. It is telling that those same people really, really hate CAN-SPAM, and really, really hate any distinction between genuine CBE and abuse that isn't actually commercial. -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From owner-ietf-mxcomp@mail.imc.org Mon Nov 06 16:09:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhBis-0003wE-SG for marid-archive@lists.ietf.org; Mon, 06 Nov 2006 16:09:38 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhBio-0001g2-Gi for marid-archive@lists.ietf.org; Mon, 06 Nov 2006 16:09:38 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA6Kfkvc071968; Mon, 6 Nov 2006 13:41:46 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA6KfkFR071967; Mon, 6 Nov 2006 13:41:46 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from occam.hewgill.net (occam.hewgill.net [69.41.174.196]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA6KfjXT071961 for ; Mon, 6 Nov 2006 13:41:45 -0700 (MST) (envelope-from greg-bounce@hewgill.net) Received: by occam.hewgill.net (Postfix, from userid 1002) id C052722DF35; Mon, 6 Nov 2006 20:41:44 +0000 (GMT) DomainKey-Signature: a=rsa-sha1; s=greg; d=hewgill.com; q=dns; c=simple; b=sCuPufH4JGV4DA36bZzpw4gwx3jmLzri+1nzHQ/Ijq2M0z1eT2XVKsKXzDU+Ba/pD0L23 l4zx/FJ5uZ3803+MEdanqLVklygNziSYWEW2S6Ump3GrftFhW+ip8iY6LeC9UB3Y3+VJgfTW hLehQoJcOUXLIRenyGZHqgKriGHI5w= Date: Mon, 6 Nov 2006 20:41:44 +0000 From: Greg Hewgill To: ietf-mxcomp@imc.org Subject: Re: Trouble with Sender Authentication Message-ID: <20061106204144.GA77028@occam.hewgill.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-PGP-Fingerprint: 862C 894D 4908 0240 FEEE 6D1F FA34 8460 74E0 2115 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad On Mon, Nov 06, 2006 at 02:34:29PM -0500, Dean Anderson wrote: > Most of this isn't commercial, either. Commercial bulk email is no > longer a problem. Is that right? Virtually all the spam I see relates to pharmacy, stock, mortgage, pirated software, or are email worms. The whole idea of each of those are to make money for somebody. I don't even know what "non-commercial spam" would look like today. Greg Hewgill http://hewgill.com From owner-ietf-mxcomp@mail.imc.org Mon Nov 06 17:35:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhD3o-00069m-6X for marid-archive@lists.ietf.org; Mon, 06 Nov 2006 17:35:20 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhD3l-0007Dz-Pu for marid-archive@lists.ietf.org; Mon, 06 Nov 2006 17:35:20 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA6M6wRm080675; Mon, 6 Nov 2006 15:06:58 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA6M6w6N080674; Mon, 6 Nov 2006 15:06:58 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.schlitt.net (schlitt.net [67.52.51.34]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA6M6sCb080664 for ; Mon, 6 Nov 2006 15:06:57 -0700 (MST) (envelope-from wayne@schlitt.net) Received: from wayne by backbone.schlitt.net with local (Exim 4.52) id 1GhCc9-0000Ul-RY; Mon, 06 Nov 2006 16:06:53 -0600 From: wayne To: Douglas Otis Cc: IETF MARID WG References: <200611021612.13627.ietf-mxcomp.lists@instabook.com> <58CA41E0-1708-41A8-BE6B-7EBB343479A9@mail-abuse.org> Content-Type: text/plain; charset=US-ASCII Date: Mon, 06 Nov 2006 16:06:45 -0600 In-Reply-To: (Douglas Otis's message of "Fri, 3 Nov 2006 11:08:24 -0800") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.19 (linux) MIME-Version: 1.0 X-SA-Exim-Connect-IP: X-SA-Exim-Rcpt-To: dotis@mail-abuse.org, ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: Trouble with Sender Authentication X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on backbone.schlitt.net X-Spam-Level: X-Spam-Status: No, score=-6.1 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00, GREYLIST_ISWHITE autolearn=ham version=3.0.4 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on backbone.schlitt.net) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 In Douglas Otis writes: > On Nov 2, 2006, at 5:56 PM, wayne wrote: > >> In <58CA41E0-1708-41A8-BE6B-7EBB343479A9@mail-abuse.org> Douglas >> Otis writes: >> >>> This list remains available for continued discussions of any MARID >>> related issues. The spf-discuss reflector required participants to >>> first agree with the promotion of SPF. An insurmountable barrier >>> for some. : ) >> >> The SPF-discuss mailing list has never required you to agree with >> the promotion of SPF. > > Review the archive and you'll find a posting of the agreement > initially required before subscribing to spf-discuss. While it may > have changed, this was the reason for not participating on that list. > The MARID list is still functional. Yes, I saw your post. People pointed out to you that you were wrong back then, and you are still wrong today. Constructive critisism is on-topic for the spf-discuss list. So is the promotion of SPF. I have removed the suggestion that if you think SPF is fundementally flawed that you should come here instead. >> It wasn't until your -01 version of your draft that you actually >> presented hard data in your Appendix A. Your data doesn't back up >> your 1000x claims. > > 45 pages in the addendum trace SPF resolving a single name at about > 64:1 increase in traffic. Nice to see that you agree that your data doesn't back up your claims, but even your 64:1 number is bogus. -wayne From owner-ietf-mxcomp@mail.imc.org Mon Nov 06 17:35:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhD3p-0006A9-Ca for marid-archive@lists.ietf.org; Mon, 06 Nov 2006 17:35:21 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhD3n-0007Ej-4k for marid-archive@lists.ietf.org; Mon, 06 Nov 2006 17:35:21 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA6MAShg081096; Mon, 6 Nov 2006 15:10:28 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA6MASqL081095; Mon, 6 Nov 2006 15:10:28 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.schlitt.net (schlitt.net [67.52.51.34]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA6MARqE081086 for ; Mon, 6 Nov 2006 15:10:27 -0700 (MST) (envelope-from wayne@schlitt.net) Received: from wayne by backbone.schlitt.net with local (Exim 4.52) id 1GhCfa-0000Y7-2S for ietf-mxcomp@imc.org; Mon, 06 Nov 2006 16:10:26 -0600 From: wayne To: ietf-mxcomp@imc.org References: <20061106204144.GA77028@occam.hewgill.net> Content-Type: text/plain; charset=US-ASCII Date: Mon, 06 Nov 2006 16:10:15 -0600 In-Reply-To: <20061106204144.GA77028@occam.hewgill.net> (Greg Hewgill's message of "Mon, 6 Nov 2006 20:41:44 +0000") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.19 (linux) MIME-Version: 1.0 X-SA-Exim-Connect-IP: X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: Trouble with Sender Authentication X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on backbone.schlitt.net X-Spam-Level: X-Spam-Status: No, score=-6.1 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00, GREYLIST_ISWHITE autolearn=ham version=3.0.4 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on backbone.schlitt.net) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 In <20061106204144.GA77028@occam.hewgill.net> Greg Hewgill writes: > On Mon, Nov 06, 2006 at 02:34:29PM -0500, Dean Anderson wrote: >> Most of this isn't commercial, either. Commercial bulk email is no >> longer a problem. > > Is that right? That has been Dean's position for many years now. Before trying to debate him on the issue, I strongly suggest you search some of his previous rants on the issue of spam. Like Doug Otis, Dean has some, uh, unusual ideas. -wayne From owner-ietf-mxcomp@mail.imc.org Mon Nov 06 18:48:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhECd-0007np-16 for marid-archive@lists.ietf.org; Mon, 06 Nov 2006 18:48:31 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhECb-0008L7-Jh for marid-archive@lists.ietf.org; Mon, 06 Nov 2006 18:48:31 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA6NCvws087519; Mon, 6 Nov 2006 16:12:57 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA6NCvua087518; Mon, 6 Nov 2006 16:12:57 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from io.link-m.de (daemon@io.link-m.de [89.250.128.34]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA6NCtXa087509 for ; Mon, 6 Nov 2006 16:12:56 -0700 (MST) (envelope-from julian@mehnle.net) Received: from cl-40.muc-02.de.sixxs.net (cl-40.muc-02.de.sixxs.net [2001:a60:f000:27::2]) (AUTH: PLAIN julian@mehnle.net, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by io.link-m.de with esmtp; Mon, 06 Nov 2006 23:12:53 +0000 id 0008C022.454FC175.00003033 From: Julian Mehnle To: IETF MARID WG Subject: Re: Trouble with Sender Authentication Date: Mon, 6 Nov 2006 23:12:49 +0000 User-Agent: KMail/1.9.4 References: <200611021612.13627.ietf-mxcomp.lists@instabook.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1586324.igG0JjTTqU"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200611062312.50190.julian@mehnle.net> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 --nextPart1586324.igG0JjTTqU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Douglas Otis wrote: > In Dusseldorf, Julian and Ming received *constructive* recommendations to > allow record scoping, but this was ignored and became the basis for > Julian's ignored complaint made to the IESG. Sorry to barge in on this particular topic (which is mostly unrelated to=20 the issues raised by K.J. Petrie or the alleged DoS issue), but this ain't= =20 correct. The v=3Dspf1/pra re-use issue was indeed discussed at the MAAWG=20 meeting in D=C3=BCsseldorf. I'm not sure what you mean when you say that "allowing record scoping" was proposed, but what was actually proposed were= =20 two different things (depending on whom I talked to): A. Accept the v=3Dspf1/pra re-use and start promoting v=3Dspf1 as having a different meaning than what had been defined back in 2003. B. Abandon v=3Dspf1 entirely in favor of spf2.0 (or some completely different) scheme in order to avoid the misinterpretation of v=3Dspf1 records for PRA purposes. At that point (2005-06), materially changing the definition of v=3Dspf1 was= =20 out of the question as SPFv1 (and many, many records) had existed=20 essentially unchanged since at least early 2004. And agreeing to jump=20 ship towards spf2.0 (Microsoft's Sender ID) was out of the question, too,=20 due to the idiotic patent issue which many just could not simply ignore. (Now Microsoft seems to have seen the light after all and has subjected=20 their patent to their Open Specification Promise, which might make the=20 issue go away. I'll leave it up to Debian, the ASF, or others to decide=20 whether spf2.0 AKA Sender ID is now free-software compatible.) And finally, the appeal to the IESG was not "ignored". It was rejected. =20 The reason being that the IESG did not want to take sides in the conflict=20 and change the Sender ID I-D or even bar it from publication as an RFC. On a technical level, the IESG even confirmed in their response[1] to the=20 appeal that they "have found merit in [the] technical concerns". When people discuss past matters as delicate as those above, I do expect=20 some accuracy. Otherwise the truth will fall through the cracks and=20 disappear all too easily.=20 References: 1. http://www.ietf.org/IESG/APPEALS/appeal-response-julian-mehnle.txt --nextPart1586324.igG0JjTTqU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBFT8FywL7PKlBZWjsRAuJCAKCqXXfZSnHx5if/B0qR2Y3+F52UOgCgn+1J nuowrA4kKgqeczLPjlMckU0= =DkNm -----END PGP SIGNATURE----- --nextPart1586324.igG0JjTTqU-- From owner-ietf-mxcomp@mail.imc.org Mon Nov 06 20:48:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhG4I-0002Vw-58 for marid-archive@lists.ietf.org; Mon, 06 Nov 2006 20:48:02 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhG4F-0003nA-NQ for marid-archive@lists.ietf.org; Mon, 06 Nov 2006 20:48:02 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA71LOnO002245; Mon, 6 Nov 2006 18:21:24 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA71LOww002244; Mon, 6 Nov 2006 18:21:24 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA71LNTd002238 for ; Mon, 6 Nov 2006 18:21:24 -0700 (MST) (envelope-from dotis@mail-abuse.org) Received: from [130.129.65.101] (dhcp65-101.ietf67.org [130.129.65.101]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id kA71LKko019888 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 6 Nov 2006 17:21:20 -0800 In-Reply-To: References: <200611021612.13627.ietf-mxcomp.lists@instabook.com> <58CA41E0-1708-41A8-BE6B-7EBB343479A9@mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: IETF MARID WG Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: Trouble with Sender Authentication Date: Mon, 6 Nov 2006 17:22:05 -0800 To: wayne X-Mailer: Apple Mail (2.752.2) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 On Nov 6, 2006, at 2:06 PM, wayne wrote: > In Douglas > Otis writes: > >> Review the archive and you'll find a posting of the agreement >> initially required before subscribing to spf-discuss. While it >> may have changed, this was the reason for not participating on >> that list. The MARID list is still functional. > > Yes, I saw your post. People pointed out to you that you were > wrong back then, and you are still wrong today. > > Constructive critisism is on-topic for the spf-discuss list. So is > the promotion of SPF. I have removed the suggestion that if you > think SPF is fundementally flawed that you should come here instead. It seems this suggestion is still remembered, judging by advice given K.J. There is not much point arguing about which list. Something other than SPF must be considered as a solution. Promotion of SPF effectively thwarts any consideration of alternatives on spf- discuss. : ( >>> It wasn't until your -01 version of your draft that you actually >>> presented hard data in your Appendix A. Your data doesn't back >>> up your 1000x claims. >> >> 45 pages in the addendum trace SPF resolving a single name at >> about 64:1 increase in traffic. > > Nice to see that you agree that your data doesn't back up your > claims, but even your 64:1 number is bogus. How so? The number assumes a local DNS resolver is seeded with attacking SPF script and MX records. The same SPF script can use local-part macros to generate any number of attack queries. The MX records can repeat following a negative caching interval. The 64:1 gain is based upon the email itself and just _one_ instance of SPF being executed. The message overhead likely represents spam that would have been sent anyway. The entire SPF related traffic represents a gift given an attacker by those executing SPF script. : ( The higher gains noted recognize compromised systems might utilize a provider's SMTP server. The message can include a number of recipients as yet another multiplier. In addition, each message might be assessed at multiple locations. Each instance represents a multiplier of network network traffic generated by SPF script. Just 8 recipients evaluated at the MTA and MUA reach the gain of 1000:1. The local-part macro also facilitates canvassing recipients that make use of SPF, and those that do so twice. : ( -Doug From owner-ietf-mxcomp@mail.imc.org Mon Nov 06 20:55:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhGBF-0007Ot-EL for marid-archive@lists.ietf.org; Mon, 06 Nov 2006 20:55:13 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhGBE-0004Ve-1R for marid-archive@lists.ietf.org; Mon, 06 Nov 2006 20:55:13 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA71SvoQ002897; Mon, 6 Nov 2006 18:28:57 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA71Sven002896; Mon, 6 Nov 2006 18:28:57 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA71Stt8002889 for ; Mon, 6 Nov 2006 18:28:57 -0700 (MST) (envelope-from dotis@mail-abuse.org) Received: from [130.129.65.101] (dhcp65-101.ietf67.org [130.129.65.101]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id kA71SsuV022944 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 6 Nov 2006 17:28:55 -0800 In-Reply-To: <200611062312.50190.julian@mehnle.net> References: <200611021612.13627.ietf-mxcomp.lists@instabook.com> <200611062312.50190.julian@mehnle.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Cc: IETF MARID WG From: Douglas Otis Subject: Re: Trouble with Sender Authentication Date: Mon, 6 Nov 2006 17:29:40 -0800 To: Julian Mehnle X-Mailer: Apple Mail (2.752.2) X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kA71Svt8002891 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id kA71SvoQ002897 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 On Nov 6, 2006, at 3:12 PM, Julian Mehnle wrote: > Douglas Otis wrote: >> In Dusseldorf, Julian and Ming received *constructive* =20 >> recommendations to allow record scoping, but this was ignored and =20 >> became the basis for Julian's ignored complaint made to the IESG. > > Sorry to barge in on this particular topic (which is mostly =20 > unrelated to the issues raised by K.J. Petrie or the alleged DoS =20 > issue), but this ain't correct. The v=3Dspf1/pra re-use issue was =20 > indeed discussed at the MAAWG meeting in D=FCsseldorf. I'm not sure =20 > what you mean when you say that "allowing record scoping" was =20 > proposed, but what was actually proposed were two different things =20 > (depending on whom I talked to): > > A. Accept the v=3Dspf1/pra re-use and start promoting v=3Dspf1 as =20 > having a > different meaning than what had been defined back in 2003. > > B. Abandon v=3Dspf1 entirely in favor of spf2.0 (or some completely > different) scheme in order to avoid the misinterpretation of =20 > v=3Dspf1 > records for PRA purposes. It seems v=3Dspf1/pra will be more disruptive than spf2.0/mailfrom? =20 What is your view about forcing use of different scripts? -Doug From owner-ietf-mxcomp@mail.imc.org Tue Nov 07 15:16:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhXMn-0002JA-8X for marid-archive@lists.ietf.org; Tue, 07 Nov 2006 15:16:17 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhXMk-0006r5-CH for marid-archive@lists.ietf.org; Tue, 07 Nov 2006 15:16:16 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA7JiUmo054746; Tue, 7 Nov 2006 12:44:30 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA7JiUie054745; Tue, 7 Nov 2006 12:44:30 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA7JiSAh054738 for ; Tue, 7 Nov 2006 12:44:29 -0700 (MST) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GhWrv-0008So-Ol for ietf-mxcomp@imc.org; Tue, 07 Nov 2006 20:44:23 +0100 Received: from d254085.dialin.hansenet.de ([80.171.254.85]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 07 Nov 2006 20:44:23 +0100 Received: from nobody by d254085.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 07 Nov 2006 20:44:23 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: Trouble with Sender Authentication Date: Tue, 07 Nov 2006 20:42:24 +0100 Organization: Lines: 43 Message-ID: <4550E1A0.E20@xyzzy.claranet.de> References: <200611021612.13627.ietf-mxcomp.lists@instabook.com> <58CA41E0-1708-41A8-BE6B-7EBB343479A9@mail-abuse.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d254085.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Douglas Otis wrote: > Promotion of SPF effectively thwarts any consideration of alternatives > on spf- discuss. You'll tell us when you've found a better way to partition all IPs into three sets PASS, FAIL, or DUNNO (with as many variants of DUNNO as you need). >>> 45 pages in the addendum trace SPF resolving a single name at >>> about 64:1 increase in traffic. >> Nice to see that you agree that your data doesn't back up your >> claims, but even your 64:1 number is bogus. > How so? Because 100/11 is a bit more than 9, and 100/12 is a bit less than 9. > a gift given an attacker by those executing SPF script. The stuff is called "SPF policy" or "SPF record", not "SPF script". It's a simple sequence of mechanisms telling receivers to which of the three sets PASS, FAIL, or DUNNO a given IP belongs. Three of the mechanisms (ip4, ip6, all) need zero DNS queries. Two of the mechanisms (a, exists) need one additional DNS query. One mechanism (include) needs two DNS queries (TXT + SPF). One modifier (redirect=) behaves like include wrt DNS queries. One mechanism (ptr) needs up to 10 DNS queries per connecting IP, no matter how often it's used in various SPF policies evaluated during that SMTP session. One mechanism (mx) needs up to 10 queries. There can be at most 10 mechanisms causing any additional DNS query at all per policy. 10+1 is 11, 10+2 is 12, 10*10 is 100, and 100/11 is about 9, not 64, 1000, or other random numbers you care to name. Frank From owner-ietf-mxcomp@mail.imc.org Tue Nov 07 15:34:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhXeq-0006Hd-8A for marid-archive@lists.ietf.org; Tue, 07 Nov 2006 15:34:56 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhXen-0000k2-RS for marid-archive@lists.ietf.org; Tue, 07 Nov 2006 15:34:56 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA7K2hQ3057206; Tue, 7 Nov 2006 13:02:43 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA7K2hWS057205; Tue, 7 Nov 2006 13:02:43 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from io.link-m.de (daemon@io.link-m.de [89.250.128.34]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA7K2f1U057197 for ; Tue, 7 Nov 2006 13:02:42 -0700 (MST) (envelope-from julian@mehnle.net) Received: from cl-40.muc-02.de.sixxs.net (cl-40.muc-02.de.sixxs.net [2001:a60:f000:27::2]) (AUTH: PLAIN julian@mehnle.net, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by io.link-m.de with esmtp; Tue, 07 Nov 2006 20:02:38 +0000 id 0008C01F.4550E65E.00000603 From: Julian Mehnle To: IETF MARID WG Subject: Re: Trouble with Sender Authentication Date: Tue, 7 Nov 2006 20:02:35 +0000 User-Agent: KMail/1.9.4 References: <200611021612.13627.ietf-mxcomp.lists@instabook.com> <200611062312.50190.julian@mehnle.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3016901.vpxvcZr6IP"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200611072002.35727.julian@mehnle.net> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 --nextPart3016901.vpxvcZr6IP Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Douglas Otis wrote: > On Nov 6, 2006, at 3:12 PM, Julian Mehnle wrote: > > Douglas Otis wrote: > > > In Dusseldorf, Julian and Ming received *constructive* > > > recommendations to allow record scoping, but this was ignored and > > > became the basis for Julian's ignored complaint made to the IESG. > > > > Sorry to barge in on this particular topic (which is mostly > > unrelated to the issues raised by K.J. Petrie or the alleged DoS > > issue), but this ain't correct. The v=3Dspf1/pra re-use issue was > > indeed discussed at the MAAWG meeting in D=C3=BCsseldorf. I'm not sure > > what you mean when you say that "allowing record scoping" was > > proposed, but what was actually proposed were two different things > > (depending on whom I talked to): > > > > A. Accept the v=3Dspf1/pra re-use and start promoting v=3Dspf1 as > > having a different meaning than what had been defined back in 2003. > > > > B. Abandon v=3Dspf1 entirely in favor of spf2.0 (or some completely > > different) scheme in order to avoid the misinterpretation of > > v=3Dspf1 records for PRA purposes. > > It seems v=3Dspf1/pra will be more disruptive than spf2.0/mailfrom? If you mean that the interpretation of v=3Dspf1 for the PRA scope would be= =20 more disruptive than recommending that everyone publish spf2.0 (essen-=20 tially what B says) instead of v=3Dspf1, then, yes, I'd agree. > What is your view about forcing use of different scripts? I don't understand what you're suggesting here. What do you mean by "forcing use of different scripts"? --nextPart3016901.vpxvcZr6IP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBFUOZbwL7PKlBZWjsRAmdvAKCh1YnSBx8UjwN6KvRRLejTcBEyhQCfXTcb 1SwX01gV6tafOOYf/0+XQpo= =zbEU -----END PGP SIGNATURE----- --nextPart3016901.vpxvcZr6IP-- From owner-ietf-mxcomp@mail.imc.org Tue Nov 07 18:35:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhaTs-000290-6V for marid-archive@lists.ietf.org; Tue, 07 Nov 2006 18:35:48 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhaTp-0008RP-OT for marid-archive@lists.ietf.org; Tue, 07 Nov 2006 18:35:48 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA7N134q071427; Tue, 7 Nov 2006 16:01:03 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA7N137u071426; Tue, 7 Nov 2006 16:01:03 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA7N12UW071420 for ; Tue, 7 Nov 2006 16:01:03 -0700 (MST) (envelope-from dotis@mail-abuse.org) Received: from [130.129.65.101] (dhcp65-101.ietf67.org [130.129.65.101]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id kA7N11mm004219 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 7 Nov 2006 15:01:02 -0800 In-Reply-To: <4550E1A0.E20@xyzzy.claranet.de> References: <200611021612.13627.ietf-mxcomp.lists@instabook.com> <58CA41E0-1708-41A8-BE6B-7EBB343479A9@mail-abuse.org> <4550E1A0.E20@xyzzy.claranet.de> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7837BDED-56B7-4B6F-B628-931A7BC060BB@mail-abuse.org> Cc: ietf-mxcomp@imc.org Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: Trouble with Sender Authentication Date: Tue, 7 Nov 2006 15:01:48 -0800 To: Frank Ellermann X-Mailer: Apple Mail (2.752.2) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 On Nov 7, 2006, at 11:42 AM, Frank Ellermann wrote: > > Douglas Otis wrote: > >> Promotion of SPF effectively thwarts any consideration of >> alternatives on spf- discuss. > > You'll tell us when you've found a better way to partition all IPs > into three sets PASS, FAIL, or DUNNO (with as many variants of > DUNNO as you need). The RFC3123 permits more than 50 CIDRs per transaction when address registration is desired. A better choice would be to authenticate the EHLO as an address literal or host name. The EHLO in any form can then be associated with an originating domain. Any number of flags may then indicate the nature of the association and the level of assurance offered. With this technique only _one_ small transaction is made against a message targeted resource and is much safer from a DDoS concern. For examples of such a scheme see: http://www.sonic.net/~dougotis/id/draft-otis-dkim-dosp-02.html >>> Nice to see that you agree that your data doesn't back up your >>> claims, but even your 64:1 number is bogus. >> >> How so? > > Because 100/11 is a bit more than 9, and 100/12 is a bit less than 9. There is about 640 bytes of traffic for each of the 100 transactions representing 64,000 bytes of generated traffic. When a message is about 1000 bytes, the ratio of SPF traffic per message is then 64:1 or 64K bytes of DNS traffic per message. >> a gift given an attacker by those executing SPF script. > > The stuff is called "SPF policy" or "SPF record", not "SPF script". A possible >6K bytes of SPF script (a series of instructions carried out in a specific order) must be executed to obtain an answer. The answer might involve the comparison of multi faceted PTR transactions, two stage MX transactions within CDIRs, and/or direct addresses transactions within CIDRs at macro generated locations compared against SMTP client addresses. There is also checks for any answer from address transactions at macro constructed locations. No answer is assured without executing the instructed transactions and applying the indicated Boolean logic. This script also contains includes, redirects and default statements. SPF is the epitome of a script. In contrast, APL does not involve subsequent instructed transactions to obtain an answer and would not be described as a script. -Doug From owner-ietf-mxcomp@mail.imc.org Tue Nov 07 19:09:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghb0W-0003Eh-DY for marid-archive@lists.ietf.org; Tue, 07 Nov 2006 19:09:32 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghb0T-0004Pl-Sn for marid-archive@lists.ietf.org; Tue, 07 Nov 2006 19:09:32 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA7Neo9X074575; Tue, 7 Nov 2006 16:40:50 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA7Neoxt074574; Tue, 7 Nov 2006 16:40:50 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA7Nenmw074567 for ; Tue, 7 Nov 2006 16:40:50 -0700 (MST) (envelope-from dotis@mail-abuse.org) Received: from [130.129.65.101] (dhcp65-101.ietf67.org [130.129.65.101]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id kA7Nemwb020696 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 7 Nov 2006 15:40:48 -0800 In-Reply-To: <200611072002.35727.julian@mehnle.net> References: <200611021612.13627.ietf-mxcomp.lists@instabook.com> <200611062312.50190.julian@mehnle.net> <200611072002.35727.julian@mehnle.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <91F4A2C0-3CF9-4875-86D3-9E2E5BC1192C@mail-abuse.org> Cc: IETF MARID WG Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: Trouble with Sender Authentication Date: Tue, 7 Nov 2006 15:41:34 -0800 To: Julian Mehnle X-Mailer: Apple Mail (2.752.2) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 On Nov 7, 2006, at 12:02 PM, Julian Mehnle wrote: >> What is your view about forcing use of different scripts? > > I don't understand what you're suggesting here. What do you mean > by "forcing use of different scripts"? Obsoleting existing libraries and related scripts as needed due to the DDoS potential. -Doug From owner-ietf-mxcomp@mail.imc.org Tue Nov 07 19:56:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghbji-0003ag-MT for marid-archive@lists.ietf.org; Tue, 07 Nov 2006 19:56:14 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghbjh-0001jo-AC for marid-archive@lists.ietf.org; Tue, 07 Nov 2006 19:56:14 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA80RRiA079047; Tue, 7 Nov 2006 17:27:27 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA80RRpv079046; Tue, 7 Nov 2006 17:27:27 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from io.link-m.de (daemon@io.link-m.de [89.250.128.34]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA80RPTP079038 for ; Tue, 7 Nov 2006 17:27:26 -0700 (MST) (envelope-from julian@mehnle.net) Received: from cl-40.muc-02.de.sixxs.net (cl-40.muc-02.de.sixxs.net [2001:a60:f000:27::2]) (AUTH: PLAIN julian@mehnle.net, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by io.link-m.de with esmtp; Wed, 08 Nov 2006 00:27:23 +0000 id 0008C022.4551246B.00001776 From: Julian Mehnle To: IETF MARID WG Subject: Re: Trouble with Sender Authentication Date: Wed, 8 Nov 2006 00:27:14 +0000 User-Agent: KMail/1.9.4 References: <200611021612.13627.ietf-mxcomp.lists@instabook.com> <200611072002.35727.julian@mehnle.net> <91F4A2C0-3CF9-4875-86D3-9E2E5BC1192C@mail-abuse.org> In-Reply-To: <91F4A2C0-3CF9-4875-86D3-9E2E5BC1192C@mail-abuse.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1847150.btYbBVM9Pr"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200611080027.20769.julian@mehnle.net> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 --nextPart1847150.btYbBVM9Pr Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Douglas Otis wrote: > On Nov 7, 2006, at 12:02 PM, Julian Mehnle wrote: > >> What is your view about forcing use of different scripts? > > > > I don't understand what you're suggesting here. What do you mean > > by "forcing use of different scripts"? > > Obsoleting existing libraries and related scripts as needed due to > the DDoS potential. The SPF project isn't convinced just yet that there is significant=20 potential for a DoS attack, and if there's any, how real it is, so any=20 statements on consequences would be hypothetical at this time. But trust=20 us, we are taking this seriously. However, we consider it unlikely that=20 obsoleting v=3Dspf1 and the existing libraries would be necessary to=20 mitigate any serious DoS potential. Tightening the limits, perhaps. The problem with your analysis, Doug, is that (1) it attributes several=20 attack vectors to SPF which are really orthogonal, like SMTP's multi-=20 recipient feature or the use of many compromised systems for sending mail,= =20 and (2) with a high probability it overrates both the negative effects=20 (like the victim/attacker traffic ratio) of an attack staged as described,= =20 and the net incentive for doing so in the first place. We are currently investigating the issue further, so expect a thorough=20 analysis from us within the coming weeks. --nextPart1847150.btYbBVM9Pr Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBFUSRowL7PKlBZWjsRAkFVAKCoBctjwZZsPeFIRdFzDssz39mXqgCgi0ul fd5EBs1EhR8E8v6atY/IqQw= =RDzr -----END PGP SIGNATURE----- --nextPart1847150.btYbBVM9Pr-- From owner-ietf-mxcomp@mail.imc.org Tue Nov 07 21:49:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhdUx-0001As-GJ for marid-archive@lists.ietf.org; Tue, 07 Nov 2006 21:49:07 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhdNk-00061C-7Y for marid-archive@lists.ietf.org; Tue, 07 Nov 2006 21:41:42 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA82Aj80088336; Tue, 7 Nov 2006 19:10:45 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA82AjBU088335; Tue, 7 Nov 2006 19:10:45 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA82AiNJ088329 for ; Tue, 7 Nov 2006 19:10:45 -0700 (MST) (envelope-from scott@kitterman.com) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id 08BA65CC0AB for ; Wed, 8 Nov 2006 02:10:35 +0000 (UTC) Received: from [192.168.111.103] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout00.controlledmail.com (Postfix) with ESMTP id E86A35CC08E for ; Wed, 8 Nov 2006 02:10:34 +0000 (UTC) From: Scott Kitterman Organization: Kitterman Technical Services To: IETF MARID WG Subject: Re: Trouble with Sender Authentication Date: Tue, 7 Nov 2006 21:10:40 -0500 User-Agent: KMail/1.9.5 References: <200611021612.13627.ietf-mxcomp.lists@instabook.com> <200611072002.35727.julian@mehnle.net> <91F4A2C0-3CF9-4875-86D3-9E2E5BC1192C@mail-abuse.org> In-Reply-To: <91F4A2C0-3CF9-4875-86D3-9E2E5BC1192C@mail-abuse.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611072110.41216.scott@kitterman.com> X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 On Tuesday 07 November 2006 18:41, Douglas Otis wrote: > Obsoleting existing libraries and related scripts as needed due to > the DDoS potential. When you say the word script, do you mean SPF records (Please, this is meant to be a yes/no question, there's no need to write a dissertation that repeats the arguements made earlier in the thread. I read those already.)? If no, then please explain what you mean by a script. Scott K From owner-ietf-mxcomp@mail.imc.org Wed Nov 08 12:46:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhrVR-0008T1-Kt for marid-archive@lists.ietf.org; Wed, 08 Nov 2006 12:46:33 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhrVQ-0007TY-91 for marid-archive@lists.ietf.org; Wed, 08 Nov 2006 12:46:33 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA8HEhdT076638; Wed, 8 Nov 2006 10:14:43 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA8HEhY2076637; Wed, 8 Nov 2006 10:14:43 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA8HEgFW076631 for ; Wed, 8 Nov 2006 10:14:43 -0700 (MST) (envelope-from dotis@mail-abuse.org) Received: from [130.129.65.101] (dhcp65-101.ietf67.org [130.129.65.101]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id kA8HEfsd025770 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Nov 2006 09:14:42 -0800 In-Reply-To: <200611072110.41216.scott@kitterman.com> References: <200611021612.13627.ietf-mxcomp.lists@instabook.com> <200611072002.35727.julian@mehnle.net> <91F4A2C0-3CF9-4875-86D3-9E2E5BC1192C@mail-abuse.org> <200611072110.41216.scott@kitterman.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: IETF MARID WG Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: Trouble with Sender Authentication Date: Wed, 8 Nov 2006 09:15:29 -0800 To: Scott Kitterman X-Mailer: Apple Mail (2.752.2) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 On Nov 7, 2006, at 6:10 PM, Scott Kitterman wrote: > > On Tuesday 07 November 2006 18:41, Douglas Otis wrote: > >> Obsoleting existing libraries and related scripts as needed due to >> the DDoS potential. > > When you say the word script, do you mean SPF records (Please, this > is meant to be a yes/no question, there's no need to write a > dissertation that repeats the arguements made earlier in the > thread. I read those already.)? The concern is with libraries that execute scripts labeled as SPF 1 or 2 contained within DNS resource records. A potential attack utilizing just the access of these resources records has not been described. -Doug From owner-ietf-mxcomp@mail.imc.org Wed Nov 08 13:40:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhsLv-0002Du-Al for marid-archive@lists.ietf.org; Wed, 08 Nov 2006 13:40:47 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhsLt-0007Om-Uq for marid-archive@lists.ietf.org; Wed, 08 Nov 2006 13:40:47 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA8IArj6084108; Wed, 8 Nov 2006 11:10:53 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA8IArmR084107; Wed, 8 Nov 2006 11:10:53 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA8IAqWo084101 for ; Wed, 8 Nov 2006 11:10:52 -0700 (MST) (envelope-from scott@kitterman.com) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id 534195CC061; Wed, 8 Nov 2006 18:10:43 +0000 (UTC) Received: from [75.194.207.161] (161.sub-75-194-207.myvzw.com [75.194.207.161]) (using SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mailout00.controlledmail.com (Postfix) with ESMTP id A6A165CC01E; Wed, 8 Nov 2006 18:10:38 +0000 (UTC) Mime-Version: 1.0 X-Mailer: SnapperMail 1.9.5.01 by Snapperfish, www.snappermail.com To: IETF MARID WG Subject: Re: Trouble with Sender Authentication From: Scott Kitterman Date: Wed, 08 Nov 2006 13:10 -0500 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Message-Id: <20061108181038.A6A165CC01E@mailout00.controlledmail.com> X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 On Wed, 8 Nov 2006 09:15:29 -0800 Douglas Otis wrote: > > >On Nov 7, 2006, at 6:10 PM, Scott Kitterman wrote: > >> >> On Tuesday 07 November 2006 18:41, Douglas Otis wrote: >> >>> Obsoleting existing libraries and related scripts as needed due to >>> the DDoS potential. >> >> When you say the word script, do you mean SPF records (Please, this >> is meant to be a yes/no question, there's no need to write a >> dissertation that repeats the arguements made earlier in the >> thread. I read those already.)? > >The concern is with libraries that execute scripts labeled as SPF 1 >or 2 contained within DNS resource records. A potential attack >utilizing just the access of these resources records has not been >described. Is that a Yes? Scott K From owner-ietf-mxcomp@mail.imc.org Wed Nov 08 14:50:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhtRE-0005DD-D2 for marid-archive@lists.ietf.org; Wed, 08 Nov 2006 14:50:20 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhtRD-0007xK-0e for marid-archive@lists.ietf.org; Wed, 08 Nov 2006 14:50:20 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA8JMSpw091962; Wed, 8 Nov 2006 12:22:28 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA8JMSbi091961; Wed, 8 Nov 2006 12:22:28 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA8JMRjD091955 for ; Wed, 8 Nov 2006 12:22:27 -0700 (MST) (envelope-from dotis@mail-abuse.org) Received: from [130.129.65.101] (dhcp65-101.ietf67.org [130.129.65.101]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id kA8JMPsN015691 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Nov 2006 11:22:25 -0800 In-Reply-To: <200611080027.20769.julian@mehnle.net> References: <200611021612.13627.ietf-mxcomp.lists@instabook.com> <200611072002.35727.julian@mehnle.net> <91F4A2C0-3CF9-4875-86D3-9E2E5BC1192C@mail-abuse.org> <200611080027.20769.julian@mehnle.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3AB770EA-0A3D-43C9-87BB-8B22EE1683B7@mail-abuse.org> Cc: IETF MARID WG Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: Trouble with Sender Authentication Date: Wed, 8 Nov 2006 11:23:12 -0800 To: Julian Mehnle X-Mailer: Apple Mail (2.752.2) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 On Nov 7, 2006, at 4:27 PM, Julian Mehnle wrote: > > The problem with your analysis, Doug, is that (1) it attributes > several attack vectors to SPF which are really orthogonal, like > SMTP's multi-recipient feature or the use of many compromised > systems for sending mail, and (2) with a high probability it > overrates both the negative effects (like the victim/attacker > traffic ratio) of an attack staged as described, and the net > incentive for doing so in the first place. Execution of SPF script is not orthogonal to SMTP's current use (or abuse). An SPF script exploit requiring little (if any) resources of the attacker offers an incentive. Difficult forensics offers an incentive. Acceptance of responsibility and subsequent changes to infrastructure requires time. The delay for an effective response offers an incentive. These incentives and risks grow as SPF script execution increases. Protection necessitates the general removal of the related scripts. Malicious script detection at each DNS is not reasonable. -Doug From owner-ietf-mxcomp@mail.imc.org Wed Nov 08 15:01:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghtbt-0001v2-FV for marid-archive@lists.ietf.org; Wed, 08 Nov 2006 15:01:21 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghtbr-0000jJ-1j for marid-archive@lists.ietf.org; Wed, 08 Nov 2006 15:01:21 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA8JZW4G093373; Wed, 8 Nov 2006 12:35:32 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA8JZWaO093372; Wed, 8 Nov 2006 12:35:32 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA8JZWou093366 for ; Wed, 8 Nov 2006 12:35:32 -0700 (MST) (envelope-from dotis@mail-abuse.org) Received: from [130.129.65.101] (dhcp65-101.ietf67.org [130.129.65.101]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id kA8JZV1X006057 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Nov 2006 11:35:31 -0800 In-Reply-To: <20061108181038.A6A165CC01E@mailout00.controlledmail.com> References: <20061108181038.A6A165CC01E@mailout00.controlledmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <24200D2D-5669-47F0-9BCD-6F0CE88877EC@mail-abuse.org> Cc: IETF MARID WG Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: Trouble with Sender Authentication Date: Wed, 8 Nov 2006 11:36:19 -0800 To: Scott Kitterman X-Mailer: Apple Mail (2.752.2) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 On Nov 8, 2006, at 10:10 AM, Scott Kitterman wrote: > On Wed, 8 Nov 2006 09:15:29 -0800 Douglas Otis abuse.org> wrote: >> >>> When you say the word script, do you mean SPF records (Please, >>> this is meant to be a yes/no question, there's no need to write a >>> dissertation that repeats the arguements made earlier in the >>> thread. I read those already.)? >> >> The concern is with libraries that execute scripts labeled as SPF >> 1 or 2 contained within DNS resource records. A potential attack >> utilizing just the access of these resources records has not been >> described. > > Is that a Yes? This has been succinctly answered. Record is _not_ synonymous with script. -Doug From owner-ietf-mxcomp@mail.imc.org Wed Nov 08 16:30:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghv0E-0007Hb-2A for marid-archive@lists.ietf.org; Wed, 08 Nov 2006 16:30:34 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghv07-00070h-6H for marid-archive@lists.ietf.org; Wed, 08 Nov 2006 16:30:34 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA8KuJrU001294; Wed, 8 Nov 2006 13:56:19 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA8KuJhP001293; Wed, 8 Nov 2006 13:56:19 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA8KuElA001284 for ; Wed, 8 Nov 2006 13:56:18 -0700 (MST) (envelope-from dean@av8.com) Received: from [130.105.12.10] ([130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id kA8Ku5Tf014663 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 8 Nov 2006 15:56:06 -0500 Date: Wed, 8 Nov 2006 15:56:05 -0500 (EST) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Greg Hewgill cc: ietf-mxcomp@imc.org Subject: Re: Trouble with Sender Authentication In-Reply-To: <20061106204144.GA77028@occam.hewgill.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.8 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 I don't recognize Greg Hewgill, so I presume he has a genuine question. On Mon, 6 Nov 2006, Greg Hewgill wrote: > On Mon, Nov 06, 2006 at 02:34:29PM -0500, Dean Anderson wrote: > > Most of this isn't commercial, either. Commercial bulk email is no > > longer a problem. > > Is that right? Virtually all the spam I see relates to pharmacy, stock, > mortgage, pirated software, or are email worms. The whole idea of each > of those are to make money for somebody. I don't even know what > "non-commercial spam" would look like today. Tried purchasing anything? I have. I opened a bank account just for a special credit card. But it was never charged. If money changed hands, I figured it would be easy to find them. No money ever changed hands, even though, ostensibly, the spam _looks_ commercial. But wait, if no money changes hands, it isn't commercial, no matter what it _looks_ like. I also found a few blacklists abusing open relays. I did this by creating non-production relays, logging TCP connections to them, and then submitting them to the blacklist for scanning. After only scanning by the blacklist, they started getting abused. There's more, but you get the idea. And now, the abusers are easily distinguished from the genuine mailers by CAN-SPAM---this is why "anti-spam" people hate CAN-SPAM so much. (quotes because they really aren't anti-spam people) By contrast, the genuine commercial bulk emailers never use proxies, never use viruses, nor other abuse tactics. The genuine commercial bulk emailers comply with CAN-SPAM, and rarely violate the law. Some time ago, I created a classification of spam types. http://www.av8.net/SpamTypes.txt Certain people have tried to discredit this for a long time. Usually, they try to confuse CAN-SPAM compliant mailers with non-compliant abusers by lumping them all together. They realy, really, really hate the notion that there might be a distinction. The reason why is plain. The very same people also tried to claim that the ECPA didn't apply to ISPs. (I said it did, and cited the law and a number of court cases, but to no avail.) Then there was U.S. V Councilman, a criminal case. People don't dispute me on this anymore, but no one has actually admitted to being wrong. I suppose I shouldn't be too surprised by that. But it discredits them, and credits me. And about 10 years ago, the same people disputed that anti-trust law would apply to blacklists-- again, with no basis in law or fact. Exactis V. MAPS proved me right. Trolls still dispute this, however, but still have no basis for their claims. They typically assert that Exactis V. MAPS isn't a "precedent". Literally, that is true: Exactis V. MAPS was settled out of court. However, one doesn't need a court precedent before the law will apply. The law is clear; the constitutionality of the law is clear; and there is no reasonable dispute on the law to take to court. Hence, MAPS lawyer was chastised by the Judge. BTW, this may be interesting: Subject: Re: SPF [WAS: Best practices for hosting web but NOT email?] Hmm. Ehlke...sounds familiar. So familiar, I think you already know the answer to your question. This is a response to a known troll, so hit delete now, unless you like history. Exactis V. MAPS. Exactis sued for anti-trust violation, just as I predicted would happen about 10+ years ago. I made that assertion from information based on queries I made around 1990 to the LPF attorneys regarding the operation of boycotts. The script-kiddie trolls have long disputed this---of course, with no basis for their claims. They assert there is a first amendment right to operate a blacklist. There isn't. They assert sometimes that there are no laws without court cases (e.g. the federal register reference below). That isn't true either, but it hasn't stopped them. Of course, they lie about lots things--Just look up 130.105/16 in SORBS. But MAPS countered the suit with a First Amendment assertion, just as trolls asserted who disputed my reports. The constitutional legal argument against anti-trust that was tossed about a century back. Indeed, the MAPS lawyer was chastisted for this frivolous defense, and the Judge recessed. MAPS settled during recess, giving Exactis everything it demanded. This suit should never have reached court. The court papers are interesting, though. A good read is the memoranda in support of the TRO by Exactis. This is at http://www.dotcomeon.com/exactis1.html. It gives a good look at the MAPS true nature. Compare what you read in the Memo with page 254 of Brian McWilliams book "Spam Kings", where MAPS employees are working for _spammers_, "washing" their lists from spam-trap addresses. Then compare with additional information on http://www.iadl.org. I'm surprised you didn't dispute the ECPA assertions, too. Or has U.S. V. Councilman finally convinced you that I was right about that, too? It is always interesting how you tend to never admit your past mistakes. --Dean On Tue, 7 Nov 2006, Pete Ehlke wrote: > On Mon Nov 06, 2006 at 15:16:42 -0500, Dean Anderson wrote: > > > >Blocking non-spam email is a violation of federal anti-trust law > >(participation in unlawful group boycott) and also state and federal > >electronic privacy laws (no authorization to block non-spam email). > >Some letters to Verizon may be necessary. > > > ( Just can't resist tossing a cookie to the troll... ) > > And your citations in the Federal Reporter for the decisions that support > these contentions are exactly what? > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From owner-ietf-mxcomp@mail.imc.org Wed Nov 08 22:10:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi0Im-0007Hi-4z for marid-archive@lists.ietf.org; Wed, 08 Nov 2006 22:10:04 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi0Ik-00016D-Oj for marid-archive@lists.ietf.org; Wed, 08 Nov 2006 22:10:04 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA92bhOW032714; Wed, 8 Nov 2006 19:37:43 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA92bhVY032713; Wed, 8 Nov 2006 19:37:43 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA92bgqc032706 for ; Wed, 8 Nov 2006 19:37:43 -0700 (MST) (envelope-from dotis@mail-abuse.org) Received: from [130.129.65.101] (dhcp65-101.ietf67.org [130.129.65.101]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id kA92bAXZ012202 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Nov 2006 18:37:10 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <35FBA648-9101-43DE-86C7-02AB48348010@mail-abuse.org> Cc: Greg Hewgill , ietf-mxcomp@imc.org Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: Trouble with Sender Authentication Date: Wed, 8 Nov 2006 18:37:58 -0800 To: Dean Anderson X-Mailer: Apple Mail (2.752.2) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 On Nov 8, 2006, at 12:56 PM, Dean Anderson wrote: > I also found a few blacklists abusing open relays. I did this by > creating non-production relays, logging TCP connections to them, > and then submitting them to the blacklist for scanning. After only > scanning by the blacklist, they started getting abused. There's > more, but you get the idea. And now, the abusers are easily > distinguished from the genuine mailers by CAN-SPAM---this is why > "anti-spam" people hate CAN-SPAM so much. (quotes because they > really aren't anti-spam people) It is not surprising that listing an open-relay exposes such services defeating a security through obscurity scheme. While the CAN-SPAM act is not entirely bad, the greatest harm was from over-riding reasonable State Opt-in requirements. This act still allows acceptable use policies. Neither this act nor the suit you mention changed these acceptable use policies, and there is a growing adoption of these policies worldwide. Opt-in use policies continue despite CAN-SPAM requirements established for Opt-out. In general, it remains a bad idea for a recipient to Opt-out unless they are sure of the sender. Just as it remains a bad idea for recipients to run scripts in messages or obtain photos when they are unsure. It also remains a bad idea for the sender to post bulk email unless their mailing lists have been confirmed by the recipients. -Doug From owner-ietf-mxcomp@mail.imc.org Wed Nov 08 23:57:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi1ym-0001L4-U1 for marid-archive@lists.ietf.org; Wed, 08 Nov 2006 23:57:32 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi1yl-0005bZ-Hr for marid-archive@lists.ietf.org; Wed, 08 Nov 2006 23:57:32 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA94UqKK043441; Wed, 8 Nov 2006 21:30:52 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA94Uqls043440; Wed, 8 Nov 2006 21:30:52 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA94UpLF043433 for ; Wed, 8 Nov 2006 21:30:52 -0700 (MST) (envelope-from scott@kitterman.com) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id 7A9925CC061 for ; Thu, 9 Nov 2006 04:30:42 +0000 (UTC) Received: from [192.168.111.103] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout00.controlledmail.com (Postfix) with ESMTP id 64AEB5CC01E for ; Thu, 9 Nov 2006 04:30:42 +0000 (UTC) From: Scott Kitterman Organization: Kitterman Technical Services To: IETF MARID WG Subject: Re: Trouble with Sender Authentication Date: Wed, 8 Nov 2006 23:30:47 -0500 User-Agent: KMail/1.9.5 References: <20061108181038.A6A165CC01E@mailout00.controlledmail.com> <24200D2D-5669-47F0-9BCD-6F0CE88877EC@mail-abuse.org> In-Reply-To: <24200D2D-5669-47F0-9BCD-6F0CE88877EC@mail-abuse.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611082330.47971.scott@kitterman.com> X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 On Wednesday 08 November 2006 14:36, Douglas Otis wrote: > On Nov 8, 2006, at 10:10 AM, Scott Kitterman wrote: > > On Wed, 8 Nov 2006 09:15:29 -0800 Douglas Otis > > > abuse.org> wrote: > >>> When you say the word script, do you mean SPF records (Please, > >>> this is meant to be a yes/no question, there's no need to write a > >>> dissertation that repeats the arguements made earlier in the > >>> thread. I read those already.)? > >> > >> The concern is with libraries that execute scripts labeled as SPF > >> 1 or 2 contained within DNS resource records. A potential attack > >> utilizing just the access of these resources records has not been > >> described. > > > > Is that a Yes? > > This has been succinctly answered. Record is _not_ synonymous with > script. > OK, then I guess that's no. Record != Script. I see from the above that in your view libraries execute scripts, so SPF checking library != Script. I'm not sure what is left. Rather that rehash your 'succinct' answer, please point me to the page and line number(s) of your draft that either is a script or describes what it is and I'll look it up there. Scott K From owner-ietf-mxcomp@mail.imc.org Thu Nov 09 14:36:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiFh5-0003Zi-6m for marid-archive@lists.ietf.org; Thu, 09 Nov 2006 14:36:11 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiFh3-0004Lm-Ew for marid-archive@lists.ietf.org; Thu, 09 Nov 2006 14:36:11 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA9Iw6vT084761; Thu, 9 Nov 2006 11:58:07 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA9Iw6td084760; Thu, 9 Nov 2006 11:58:06 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA9Iw6wW084746 for ; Thu, 9 Nov 2006 11:58:06 -0700 (MST) (envelope-from dotis@mail-abuse.org) Received: from [130.129.65.101] (dhcp65-101.ietf67.org [130.129.65.101]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id kA9Iw5In016067 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Nov 2006 10:58:05 -0800 In-Reply-To: <200611082330.47971.scott@kitterman.com> References: <20061108181038.A6A165CC01E@mailout00.controlledmail.com> <24200D2D-5669-47F0-9BCD-6F0CE88877EC@mail-abuse.org> <200611082330.47971.scott@kitterman.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2DADCC01-CB88-4168-8621-1997BBDA1B75@mail-abuse.org> Cc: IETF MARID WG Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: Trouble with Sender Authentication Date: Thu, 9 Nov 2006 10:58:54 -0800 To: Scott Kitterman X-Mailer: Apple Mail (2.752.2) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 On Nov 8, 2006, at 8:30 PM, Scott Kitterman wrote: > > On Wednesday 08 November 2006 14:36, Douglas Otis wrote: >> On Nov 8, 2006, at 10:10 AM, Scott Kitterman wrote: >>> On Wed, 8 Nov 2006 09:15:29 -0800 Douglas Otis >> >>> abuse.org> wrote: >>>>> When you say the word script, do you mean SPF records (Please, >>>>> this is meant to be a yes/no question, there's no need to write a >>>>> dissertation that repeats the arguements made earlier in the >>>>> thread. I read those already.)? >>>> >>>> The concern is with libraries that execute scripts labeled as SPF >>>> 1 or 2 contained within DNS resource records. A potential attack >>>> utilizing just the access of these resources records has not been >>>> described. >>> >>> Is that a Yes? >> >> This has been succinctly answered. Record is _not_ synonymous with >> script. >> > OK, then I guess that's no. > > Record != Script. I see from the above that in your view libraries > execute > scripts, so SPF checking library != Script. I'm not sure what is > left. > > Rather that rehash your 'succinct' answer, please point me to the > page and > line number(s) of your draft that either is a script or describes > what it is > and I'll look it up there. Page 11 would be a place to start. Results vary depending upon the library used to execute this script and the starting parameters. A script may invoke other records. In this case, this script invokes 10 MX mechanisms defined by a macro with follow-on transactions for address records that are perhaps limited by the script processing library. Other scripts, such as in the case of paypal.com invokes 10 other SPF TXT resource records. The SPF script defines subsequent record transactions. In this case, the %{l} macro is used to select an array of MX RR sets. The script defines the record set, but in converse a record does not define the set comprising the script. Processing the script includes initial parameters not found in any SPF record as well. It seems best not to confuse the term script with that of record. They are truly different elements. cert-test.mail-abuse.org. IN TXT "v=spf1 mx:0.%{l}.%{d} mx:1.%{l}.%{d} mx:2.%{l}.%{d} mx:3.%{l}.%{d} mx:4.%{l}.%{d} mx:5.%{l}.%{d} mx:6.%{l}.%{d} mx:7.%{l}.%{d} mx:8.%{l}.%{d} mx:9.%{l}.%{d} ?all" -Doug From owner-ietf-mxcomp@mail.imc.org Thu Nov 09 16:29:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiHSL-0007QH-6Y for marid-archive@lists.ietf.org; Thu, 09 Nov 2006 16:29:05 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiHSI-0006f6-Pj for marid-archive@lists.ietf.org; Thu, 09 Nov 2006 16:29:05 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA9Kr0aJ014576; Thu, 9 Nov 2006 13:53:00 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA9Kr0eT014575; Thu, 9 Nov 2006 13:53:00 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA9KqwQ5014499 for ; Thu, 9 Nov 2006 13:52:59 -0700 (MST) (envelope-from william@elan.net) Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id kA9KqphE016205; Thu, 9 Nov 2006 12:52:51 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id kA9KqoeC016202; Thu, 9 Nov 2006 12:52:50 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 9 Nov 2006 12:52:50 -0800 (PST) From: "william(at)elan.net" To: Douglas Otis cc: Scott Kitterman , IETF MARID WG Subject: Re: Trouble with Sender Authentication In-Reply-To: <2DADCC01-CB88-4168-8621-1997BBDA1B75@mail-abuse.org> Message-ID: References: <20061108181038.A6A165CC01E@mailout00.controlledmail.com> <24200D2D-5669-47F0-9BCD-6F0CE88877EC@mail-abuse.org> <200611082330.47971.scott@kitterman.com> <2DADCC01-CB88-4168-8621-1997BBDA1B75@mail-abuse.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 On Thu, 9 Nov 2006, Douglas Otis wrote: > to select an array of MX RR sets. The script defines the record set, but in > converse a record does not define the set comprising the script. Processing > the script includes initial parameters not found in any SPF record as well. I've examined this issue over last few days. This all has nothing to do with SPF but with DNS in general in which Doug's SPF use is just an example of range of similar attacks. The underlying problem is really that if spammers have large collection of zombies under their control they can either use them either directly to launch an attack (and spam is form of DoS too!) or indirectly to get others to to do something simiar with some additinal level or amplification (about 1-20 depending on complexity of DNS scheme). They don't really need SPF for that at all. I need to work more on the numbers and examples and also unlke Doug I've an issue with just publicly saying how to do all that - this would be just way too useful for bad guys. > It seems best not to confuse the term script with that of record. They are > truly different elements. > > cert-test.mail-abuse.org. IN TXT "v=spf1 > mx:0.%{l}.%{d} mx:1.%{l}.%{d} mx:2.%{l}.%{d} > mx:3.%{l}.%{d} mx:4.%{l}.%{d} mx:5.%{l}.%{d} > mx:6.%{l}.%{d} mx:7.%{l}.%{d} mx:8.%{l}.%{d} > mx:9.%{l}.%{d} ?all" Could someone kindly point me to workable CSV library so that I could provide Doug with an example of using CSV to generate highier amount of amplificatin then his assertions about SPF? -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Thu Nov 09 18:27:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiJIw-0006l5-Fp for marid-archive@lists.ietf.org; Thu, 09 Nov 2006 18:27:30 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiJIv-0005Dw-26 for marid-archive@lists.ietf.org; Thu, 09 Nov 2006 18:27:30 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA9Mo3gN043739; Thu, 9 Nov 2006 15:50:03 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA9Mo3Vd043738; Thu, 9 Nov 2006 15:50:03 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA9Mo2BP043724 for ; Thu, 9 Nov 2006 15:50:03 -0700 (MST) (envelope-from dotis@mail-abuse.org) Received: from [130.129.65.101] (dhcp65-101.ietf67.org [130.129.65.101]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id kA9MVt7P029643 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Nov 2006 14:31:55 -0800 In-Reply-To: References: <20061108181038.A6A165CC01E@mailout00.controlledmail.com> <24200D2D-5669-47F0-9BCD-6F0CE88877EC@mail-abuse.org> <200611082330.47971.scott@kitterman.com> <2DADCC01-CB88-4168-8621-1997BBDA1B75@mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2A2F5D7E-084E-4810-969B-A107D6C3207A@mail-abuse.org> Cc: Scott Kitterman , IETF MARID WG Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: Trouble with Sender Authentication Date: Thu, 9 Nov 2006 14:32:44 -0800 To: "william(at)elan.net" X-Mailer: Apple Mail (2.752.2) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 On Nov 9, 2006, at 12:52 PM, william(at)elan.net wrote: > > On Thu, 9 Nov 2006, Douglas Otis wrote: > >> to select an array of MX RR sets. The script defines the record >> set, but in converse a record does not define the set comprising >> the script. Processing the script includes initial parameters not >> found in any SPF record as well. > > I've examined this issue over last few days. This all has nothing > to do with SPF but with DNS in general in which Doug's SPF use is > just an example of range of similar attacks. SPF script is able to target many DNS transactions per each distributed message. The number of executions depends upon the number of names being resolved, recipients, and instances within the path where an evaluation is performed. > The underlying problem is really that if spammers have large > collection of zombies under their control they can either use them > either directly to launch an attack (and spam is form of DoS too!) > or indirectly to get others to to do something similar with some > additional level or amplification (about 1-20 depending on > complexity of DNS scheme). One execution of the SPF script can generate 64 kbytes of DNS traffic without consuming the resources of an attacker. Few attack strategies offer a scenario that is totally free to the attacker who is also interested in sending spam. : ( > They don't really need SPF for that at all. When ACL restrictions on DNS and BCP38 becomes common, SPF still defeats these protective strategies. : ( > I need to work more on the numbers and examples and also unlike > Doug I've an issue with just publicly saying how to do all that - > this would be just way too useful for bad guys. Providing details was done by request as there remained a lack of understanding of the concern. Don't underestimate the sophistication of those creating the Bot-nets now responsible for the major portion of the current spam. A DDoS attack only needs to be done for a brief period of time to enable yet other exploits. >> It seems best not to confuse the term script with that of record. >> They are truly different elements. >> >> cert-test.mail-abuse.org. IN TXT "v=spf1 >> mx:0.%{l}.%{d} mx:1.%{l}.%{d} mx:2.%{l}.%{d} >> mx:3.%{l}.%{d} mx:4.%{l}.%{d} mx:5.%{l}.%{d} >> mx:6.%{l}.%{d} mx:7.%{l}.%{d} mx:8.%{l}.%{d} >> mx:9.%{l}.%{d} ?all" > > Could someone kindly point me to workable CSV library so that I > could provide Doug with an example of using CSV to generate higher > amount of amplification then his assertions about SPF? An SMTP client is unique at each stage of delivery. Validating SMTP clients requires one small DNS transaction using either A or CSV records. While each recipient might perform this transaction, gain is less than 1. SMTP client validation transactions can not be redirected to a victim and still offer validation as can SPF. In addition, subsequent stages of delivery will not provide amplification as it will for SPF evaluations, which precludes gain related to multiple recipients. Multiple recipient gain remains a concern for SPF. -Doug From owner-ietf-mxcomp@mail.imc.org Thu Nov 09 18:56:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiJl1-0002de-DX for marid-archive@lists.ietf.org; Thu, 09 Nov 2006 18:56:31 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiJkx-0000Dk-GT for marid-archive@lists.ietf.org; Thu, 09 Nov 2006 18:56:31 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA9NFFqf049888; Thu, 9 Nov 2006 16:15:15 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA9NFFHi049887; Thu, 9 Nov 2006 16:15:15 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA9NFCHo049850 for ; Thu, 9 Nov 2006 16:15:13 -0700 (MST) (envelope-from william@elan.net) Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id kA9NF72k021706; Thu, 9 Nov 2006 15:15:07 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id kA9NF6ZB021701; Thu, 9 Nov 2006 15:15:07 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 9 Nov 2006 15:15:06 -0800 (PST) From: "william(at)elan.net" To: Douglas Otis cc: Scott Kitterman , IETF MARID WG Subject: Re: Trouble with Sender Authentication In-Reply-To: <2A2F5D7E-084E-4810-969B-A107D6C3207A@mail-abuse.org> Message-ID: References: <20061108181038.A6A165CC01E@mailout00.controlledmail.com> <24200D2D-5669-47F0-9BCD-6F0CE88877EC@mail-abuse.org> <200611082330.47971.scott@kitterman.com> <2DADCC01-CB88-4168-8621-1997BBDA1B75@mail-abuse.org> <2A2F5D7E-084E-4810-969B-A107D6C3207A@mail-abuse.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Doug, I don't have time for long discussion. But I'm telling you that SPF has nothing to do with it and I can use either of "MX", "SRV" or "NS" to generate similar amplification scenarios as you've done with SPF using the same method. In fact CSV (as far as I remember it) would cause highier amount of amplification then SPF when bad guy controls domain put in EHLO and decides to play special dns games with that name. And in exactly the same way as you did it would generate 10:1 DNS traffic amplification (SPF scenarios are basicly 10:1 amplification after throwing away all the extras). On Thu, 9 Nov 2006, Douglas Otis wrote: > On Nov 9, 2006, at 12:52 PM, william(at)elan.net wrote: > >> On Thu, 9 Nov 2006, Douglas Otis wrote: >> >>> to select an array of MX RR sets. The script defines the record set, but >>> in converse a record does not define the set comprising the script. >>> Processing the script includes initial parameters not found in any SPF >>> record as well. >> >> I've examined this issue over last few days. This all has nothing to do >> with SPF but with DNS in general in which Doug's SPF use is just an >> example of range of similar attacks. > > SPF script is able to target many DNS transactions per each distributed > message. The number of executions depends upon the number of names being > resolved, recipients, and instances within the path where an evaluation is > performed. > >> The underlying problem is really that if spammers have large collection of >> zombies under their control they can either use them either directly to >> launch an attack (and spam is form of DoS too!) or indirectly to get >> others to to do something similar with some additional level or >> amplification (about 1-20 depending on complexity of DNS scheme). > > One execution of the SPF script can generate 64 kbytes of DNS traffic > without consuming the resources of an attacker. Few attack strategies offer > a scenario that is totally free to the attacker who is also interested in > sending spam. : ( > >> They don't really need SPF for that at all. > > When ACL restrictions on DNS and BCP38 becomes common, SPF still defeats > these protective strategies. : ( > >> I need to work more on the numbers and examples and also unlike Doug I've >> an issue with just publicly saying how to do all that - this would be just >> way too useful for bad guys. > > Providing details was done by request as there remained a lack of > understanding of the concern. Don't underestimate the sophistication of > those creating the Bot-nets now responsible for the major portion of the > current spam. A DDoS attack only needs to be done for a brief period of > time to enable yet other exploits. > >>> It seems best not to confuse the term script with that of record. They >>> are truly different elements. >>> >>> cert-test.mail-abuse.org. IN TXT "v=spf1 >>> mx:0.%{l}.%{d} mx:1.%{l}.%{d} mx:2.%{l}.%{d} >>> mx:3.%{l}.%{d} mx:4.%{l}.%{d} mx:5.%{l}.%{d} >>> mx:6.%{l}.%{d} mx:7.%{l}.%{d} mx:8.%{l}.%{d} >>> mx:9.%{l}.%{d} ?all" >> >> Could someone kindly point me to workable CSV library so that I could >> provide Doug with an example of using CSV to generate higher amount of >> amplification then his assertions about SPF? > > An SMTP client is unique at each stage of delivery. Validating SMTP clients > requires one small DNS transaction using either A or CSV records. While > each recipient might perform this transaction, gain is less than 1. SMTP > client validation transactions can not be redirected to a victim and still > offer validation as can SPF. In addition, subsequent stages of delivery > will not provide amplification as it will for SPF evaluations, which > precludes gain related to multiple recipients. Multiple recipient gain > remains a concern for SPF. From owner-ietf-mxcomp@mail.imc.org Thu Nov 09 19:50:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiKbM-0007iM-67 for marid-archive@lists.ietf.org; Thu, 09 Nov 2006 19:50:36 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiKbK-0008NB-Oj for marid-archive@lists.ietf.org; Thu, 09 Nov 2006 19:50:36 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAA0Avg5064153; Thu, 9 Nov 2006 17:10:57 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAA0AvoC064152; Thu, 9 Nov 2006 17:10:57 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAA0Autn064144 for ; Thu, 9 Nov 2006 17:10:57 -0700 (MST) (envelope-from dotis@mail-abuse.org) Received: from [130.129.65.101] (dhcp65-101.ietf67.org [130.129.65.101]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id kAA0Atlf008866 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Nov 2006 16:10:56 -0800 In-Reply-To: References: <20061108181038.A6A165CC01E@mailout00.controlledmail.com> <24200D2D-5669-47F0-9BCD-6F0CE88877EC@mail-abuse.org> <200611082330.47971.scott@kitterman.com> <2DADCC01-CB88-4168-8621-1997BBDA1B75@mail-abuse.org> <2A2F5D7E-084E-4810-969B-A107D6C3207A@mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Scott Kitterman , IETF MARID WG Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: Trouble with Sender Authentication Date: Thu, 9 Nov 2006 16:11:45 -0800 To: "william(at)elan.net" X-Mailer: Apple Mail (2.752.2) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb On Nov 9, 2006, at 3:15 PM, william(at)elan.net wrote: > Doug, I don't have time for long discussion. But I'm telling you > that SPF has nothing to do with it and I can use either of "MX", > "SRV" or "NS" to generate similar amplification scenarios as you've > done with SPF using the same method. Multiples of 100s of crafted DNS transactions directed toward a victim by each message can not be compared against transactions needed to obtain an MX, SRV, or NS resource record. The MX, SRV, or NS resource records provide access to a service prompted by the client and not an attacker. SPF scripts allow an attacker to orchestrate hundreds of transactions at millions of recipients. The gain of this exploit is large and essentially free for an attacker also wanting to spam. For what other exploit would is be true? > In fact CSV (as far as I remember it) would cause highier amount of > amplification then SPF when bad guy controls domain put in EHLO and > decides to play special dns games with that name. CSV specified that a single target be used. When associated with DKIM per DOSP, an address literal or a single A record offers sufficient validation. Validating the EHLO simply does not offer any gain; nor is this gain is not multiplied by subsequent stages or multiple recipients. SPF script transaction amplification is not 10:1 but more than 100:1. The gain executing SPF script is multiplied by recipients and stages of delivery, such as MTAs and MUAs. > And in exactly the same way as you did it would generate 10:1 DNS > traffic amplification (SPF scenarios are basicly 10:1 amplification > after throwing away all the extras). Some SPF scenarios are much larger than 10:1. SPF scripts can cause havoc by additional 10 or 11 TXT wildcard resource record transactions, but I'll leave that to your imagination. Any SPF script exploit bypasses protections offered by DNS ACLs and BCP38. : ( -Doug From owner-ietf-mxcomp@mail.imc.org Thu Nov 09 20:32:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiLGD-0003XH-AD for marid-archive@lists.ietf.org; Thu, 09 Nov 2006 20:32:49 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiLGA-0004im-TZ for marid-archive@lists.ietf.org; Thu, 09 Nov 2006 20:32:49 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAA0lq01073087; Thu, 9 Nov 2006 17:47:52 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAA0lqnj073086; Thu, 9 Nov 2006 17:47:52 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from io.link-m.de (daemon@io.link-m.de [89.250.128.34]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAA0loSr073070 for ; Thu, 9 Nov 2006 17:47:51 -0700 (MST) (envelope-from julian@mehnle.net) Received: from cl-40.muc-02.de.sixxs.net (cl-40.muc-02.de.sixxs.net [2001:a60:f000:27::2]) (AUTH: PLAIN julian@mehnle.net, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by io.link-m.de with esmtp; Fri, 10 Nov 2006 00:47:48 +0000 id 0008C00E.4553CC34.00005EF7 From: Julian Mehnle To: ietf-mxcomp@imc.org Subject: Re: Trouble with Sender Authentication Date: Fri, 10 Nov 2006 00:47:36 +0000 User-Agent: KMail/1.9.4 References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2154089.dXXMN4boX6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200611100047.42068.julian@mehnle.net> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe --nextPart2154089.dXXMN4boX6 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Dean Anderson wrote: > On Mon, 6 Nov 2006, Greg Hewgill wrote: > > On Mon, Nov 06, 2006 at 02:34:29PM -0500, Dean Anderson wrote: > > > Most of this isn't commercial, either. Commercial bulk email is no > > > longer a problem. > > > > Is that right? Virtually all the spam I see relates to pharmacy, > > stock, mortgage, pirated software, or are email worms. The whole idea > > of each of those are to make money for somebody. I don't even know > > what "non-commercial spam" would look like today. > > Tried purchasing anything? I have. I opened a bank account just for a > special credit card. But it was never charged. If money changed hands, > I figured it would be easy to find them. No money ever changed hands, > even though, ostensibly, the spam _looks_ commercial. But wait, if no > money changes hands, it isn't commercial, no matter what it _looks_ > like. And this specific experiment of yours is representative exactly _how_? If money never changes hands, how come the SPF support team gets support=20 requests like the following? | Topic: Support request | Name: M* P* |=20 | My e-mail at Mp*@*.net is not compatible somehow with you recieving | messages. Please use my alternate e-mail address at m*p*@yahoo.com. My= =20 | question is-where are the meds I ordered? Payment has been deducted from | my bank account, but I have recieved no meds. Thankyou for your | help..................MP* (Yes, I had a good laugh when reading that.) Oh, right, next you're going to claim that this was a legitimate buying=20 transaction with a non-spammer, not some poor bastard falling for a=20 spamming fraudster (before then also tripping over an SPF policy=20 violation). Sorry for having barged in once more, but I found your argument too funny=20 not to comment on it... --nextPart2154089.dXXMN4boX6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBFU8wtwL7PKlBZWjsRAs7sAKC8oGRsx8T+t0U0jDdsVK7ZwIqv+QCg6EQG ca0+UZ95OBS/5UUK5v8Nt+k= =YevT -----END PGP SIGNATURE----- --nextPart2154089.dXXMN4boX6-- From owner-ietf-mxcomp@mail.imc.org Thu Nov 09 20:38:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiLLy-0007Cl-O2 for marid-archive@lists.ietf.org; Thu, 09 Nov 2006 20:38:46 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiLLx-0005RX-A2 for marid-archive@lists.ietf.org; Thu, 09 Nov 2006 20:38:46 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAA0vPfg075832; Thu, 9 Nov 2006 17:57:25 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAA0vPHx075831; Thu, 9 Nov 2006 17:57:25 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAA0vOTi075798 for ; Thu, 9 Nov 2006 17:57:24 -0700 (MST) (envelope-from william@elan.net) Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id kAA0vJNY024532; Thu, 9 Nov 2006 16:57:19 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id kAA0vIWc024529; Thu, 9 Nov 2006 16:57:18 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 9 Nov 2006 16:57:18 -0800 (PST) From: "william(at)elan.net" To: Douglas Otis cc: Scott Kitterman , IETF MARID WG Subject: Re: Trouble with Sender Authentication In-Reply-To: Message-ID: References: <20061108181038.A6A165CC01E@mailout00.controlledmail.com> <24200D2D-5669-47F0-9BCD-6F0CE88877EC@mail-abuse.org> <200611082330.47971.scott@kitterman.com> <2DADCC01-CB88-4168-8621-1997BBDA1B75@mail-abuse.org> <2A2F5D7E-084E-4810-969B-A107D6C3207A@mail-abuse.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 > CSV specified that a single target be used. When associated with DKIM per > DOSP, an address literal or a single A record offers sufficient validation. > Validating the EHLO simply does not offer any gain; nor is this gain is not > multiplied by subsequent stages or multiple recipients. I'll post tomorrow example of how to do exactly the same attack as Doug discribed using different record type (and it would also bypass DNS ACLs & BCP38), specially for Doug I'll use EHLO in that example although in practice it does not matter (it does not even need to be email). --- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Thu Nov 09 22:24:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiN0Y-0007ij-9r for marid-archive@lists.ietf.org; Thu, 09 Nov 2006 22:24:46 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiMxO-0001Wq-Uq for marid-archive@lists.ietf.org; Thu, 09 Nov 2006 22:21:33 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAA2jHcG001716; Thu, 9 Nov 2006 19:45:17 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAA2jHXu001715; Thu, 9 Nov 2006 19:45:17 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAA2jGE3001709 for ; Thu, 9 Nov 2006 19:45:17 -0700 (MST) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id 8C9834AC64; Thu, 9 Nov 2006 21:45:16 -0500 (EST) Date: Thu, 9 Nov 2006 21:45:16 -0500 From: John Leslie To: "william(at)elan.net" Cc: IETF MARID WG Subject: Re: Trouble with Sender Authentication Message-ID: <20061110024516.GC21864@verdi> References: <20061108181038.A6A165CC01E@mailout00.controlledmail.com> <24200D2D-5669-47F0-9BCD-6F0CE88877EC@mail-abuse.org> <200611082330.47971.scott@kitterman.com> <2DADCC01-CB88-4168-8621-1997BBDA1B75@mail-abuse.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 william(at)elan.net wrote: > > Could someone kindly point me to workable CSV library so that I could > provide Doug with an example of using CSV to generate highier amount > of amplification than his assertions about SPF? http://www.mipassoc.org/csv/ If you're looking for implementations, I can vouch for the ones at http://www.mipassoc.org/csv/deploy/exim.txt and http://www.mipassoc.org/csv/deploy/JLC.txt -- John Leslie From owner-ietf-mxcomp@mail.imc.org Fri Nov 10 01:05:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiPW8-0008DR-Vu for marid-archive@lists.ietf.org; Fri, 10 Nov 2006 01:05:32 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiPW7-0004Dk-KT for marid-archive@lists.ietf.org; Fri, 10 Nov 2006 01:05:32 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAA5OBex038211; Thu, 9 Nov 2006 22:24:11 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAA5OBtS038210; Thu, 9 Nov 2006 22:24:11 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tom.iecc.com (tom.iecc.com [208.31.42.38]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id kAA5O9wU038200 for ; Thu, 9 Nov 2006 22:24:10 -0700 (MST) (envelope-from prvs=johnl=0462ba0632@iecc.com) Received: (qmail 1744 invoked from network); 10 Nov 2006 05:24:08 -0000 Received: from mail.iecc.com (208.31.42.99) by mail.iecc.com with QMQP; 10 Nov 2006 05:24:08 -0000 Date: 10 Nov 2006 05:24:08 -0000 Message-ID: <20061110052408.5482.qmail@simone.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: Re: Trouble with Sender Authentication In-Reply-To: <20061110024516.GC21864@verdi> Organization: Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: -0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 >> Could someone kindly point me to workable CSV library so that I >> could provide Doug with an example of using CSV to generate highier >> amount of amplification than his assertions about SPF? It'll be a challenge. CSV is a single DNS query per message, so the only things you get to use for amplification are delegation and CNAMEs. I do agree that the DNS threat from SPF is not qualitatively worse than what we already put up with for CNAMEs. R's, John From owner-ietf-mxcomp@mail.imc.org Fri Nov 10 09:50:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiXhk-00014l-34 for marid-archive@lists.ietf.org; Fri, 10 Nov 2006 09:50:04 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiXck-0004qe-En for marid-archive@lists.ietf.org; Fri, 10 Nov 2006 09:44:56 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAAE64va069341; Fri, 10 Nov 2006 07:06:04 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAAE64Xt069340; Fri, 10 Nov 2006 07:06:04 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAAE62DA069325 for ; Fri, 10 Nov 2006 07:06:02 -0700 (MST) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GiWy2-0004vU-Ee for ietf-mxcomp@imc.org; Fri, 10 Nov 2006 15:02:50 +0100 Received: from du-001-122.access.de.clara.net ([212.82.227.122]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 10 Nov 2006 15:02:50 +0100 Received: from nobody by du-001-122.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 10 Nov 2006 15:02:50 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Interesting (ab)uses of DNS (was: Trouble with Sender Authentication) Date: Fri, 10 Nov 2006 15:00:34 +0100 Organization: Lines: 9 Message-ID: <45548602.50C1@xyzzy.claranet.de> References: <20061108181038.A6A165CC01E@mailout00.controlledmail.com> <24200D2D-5669-47F0-9BCD-6F0CE88877EC@mail-abuse.org> <200611082330.47971.scott@kitterman.com> <2DADCC01-CB88-4168-8621-1997BBDA1B75@mail-abuse.org> <2A2F5D7E-084E-4810-969B-A107D6C3207A@mail-abuse.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-122.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 william(at)elan.net wrote: > SPF has nothing to do with it and I can use either of "MX", "SRV" or > "NS" to generate similar amplification scenarios Maybe add NAPTR to the mix. Frank From owner-ietf-mxcomp@mail.imc.org Fri Nov 10 12:40:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiaMO-0000qS-3t for marid-archive@lists.ietf.org; Fri, 10 Nov 2006 12:40:12 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiaMM-0004nH-My for marid-archive@lists.ietf.org; Fri, 10 Nov 2006 12:40:12 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAAGwdGR010821; Fri, 10 Nov 2006 09:58:39 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAAGwdQK010818; Fri, 10 Nov 2006 09:58:39 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAAGwcbg010800 for ; Fri, 10 Nov 2006 09:58:38 -0700 (MST) (envelope-from dotis@mail-abuse.org) Received: from [130.129.65.101] (dhcp65-101.ietf67.org [130.129.65.101]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id kAAGwYFw027084 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 10 Nov 2006 08:58:35 -0800 In-Reply-To: <20061110052408.5482.qmail@simone.iecc.com> References: <20061110052408.5482.qmail@simone.iecc.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: ietf-mxcomp@imc.org Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: Trouble with Sender Authentication Date: Fri, 10 Nov 2006 08:58:33 -0800 To: John Levine X-Mailer: Apple Mail (2.752.2) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 On Nov 9, 2006, at 9:24 PM, John Levine wrote: > >>> Could someone kindly point me to workable CSV library so that I >>> could provide Doug with an example of using CSV to generate >>> highier amount of amplification than his assertions about SPF? > > It'll be a challenge. CSV is a single DNS query per message, so > the only things you get to use for amplification are delegation and > CNAMEs. > > I do agree that the DNS threat from SPF is not qualitatively worse > than what we already put up with for CNAMEs. Chaining CNAMEs does not offer the same distributed attack. CNAME chaining uses resources of the attacker. While CNAMEs can be a problem, they represent a threat than can be identified and handled by the affected party. The SPF attack can not be identified and there is no defense possible. I would call that a qualitative difference. -Doug From owner-ietf-mxcomp@mail.imc.org Fri Nov 10 12:42:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiaOM-0001zb-FW for marid-archive@lists.ietf.org; Fri, 10 Nov 2006 12:42:14 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiaOL-0005Ap-34 for marid-archive@lists.ietf.org; Fri, 10 Nov 2006 12:42:14 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAAH8B7s013683; Fri, 10 Nov 2006 10:08:11 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAAH8BmE013682; Fri, 10 Nov 2006 10:08:11 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAAH8AjG013672 for ; Fri, 10 Nov 2006 10:08:11 -0700 (MST) (envelope-from dean@av8.com) Received: from piper.av8.net (piper.av8.net [130.105.11.2]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id kAAH7xMr019067 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 10 Nov 2006 12:08:00 -0500 Date: Fri, 10 Nov 2006 12:07:59 -0500 (EST) From: Dean Anderson X-X-Sender: dean@piper.av8.net To: John Levine cc: ietf-mxcomp@imc.org Subject: Re: Trouble with Sender Authentication In-Reply-To: <20061110052408.5482.qmail@simone.iecc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.8 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d On 10 Nov 2006, John Levine wrote: > I do agree that the DNS threat from SPF is not qualitatively worse > than what we already put up with for CNAMEs. Actually, the top candidates for DNS amplification abuse are large SPF records, followed by large collections IN-ADDR records for a single IP, as is the case for large virtual hosting sites. Both practices are advocated by anti-spammers. I recently saw a ~4k byte SPF record, published by an anti-spam site. DNSSEC signed SPF records will probably break the 8K limit. Thats about a 90 to 1 amplification factor. You can get some amplification with any record type. You can only get the high amplification with certain types and certain practices. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From owner-ietf-mxcomp@mail.imc.org Fri Nov 10 12:42:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiaOP-0001zw-2q for marid-archive@lists.ietf.org; Fri, 10 Nov 2006 12:42:17 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiaON-0005BH-LU for marid-archive@lists.ietf.org; Fri, 10 Nov 2006 12:42:17 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAAH0pkl011771; Fri, 10 Nov 2006 10:00:51 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAAH0pMd011770; Fri, 10 Nov 2006 10:00:51 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAAH0oCn011755 for ; Fri, 10 Nov 2006 10:00:50 -0700 (MST) (envelope-from dean@av8.com) Received: from piper.av8.net (piper.av8.net [130.105.11.2]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id kAAH0bga019051 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 10 Nov 2006 12:00:43 -0500 Date: Fri, 10 Nov 2006 12:00:37 -0500 (EST) From: Dean Anderson X-X-Sender: dean@piper.av8.net To: Julian Mehnle cc: ietf-mxcomp@imc.org Subject: Re: Trouble with Sender Authentication In-Reply-To: <200611100047.42068.julian@mehnle.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.8 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab On Fri, 10 Nov 2006, Julian Mehnle wrote: > If money never changes hands, how come the SPF support team gets support > requests like the following? > > | Topic: Support request > | Name: M* P* > | > | My e-mail at Mp*@*.net is not compatible somehow with you recieving > | messages. Please use my alternate e-mail address at m*p*@yahoo.com. My > | question is-where are the meds I ordered? Payment has been deducted from > | my bank account, but I have recieved no meds. Thankyou for your > | help..................MP* These questions happen to real businesses all the time, and don't usually represent frauds, but rather honest mistakes; mistakes that the business corrects promptly. You example doen't show any evidence that the person in that case was defrauded. > (Yes, I had a good laugh when reading that.) Too bad. I'm sure your job isn't for your amusement. Wait.... You are handling support for a pharmacy? A genuine commerical bulk-emailing pharmacy? > Oh, right, next you're going to claim that this was a legitimate > buying transaction with a non-spammer, not some poor bastard falling > for a spamming fraudster (before then also tripping over an SPF policy > violation). Yes, you forgot to mention whether the person bought a product from a CAN-SPAM compliant emailer, or using a web site not involved in bulk email, and then just had a problem with email, later. Funny that, huh? But it seems to have come from your company.... But you do have a point about there existing real frauds. However, real frauds are already crimes. SPF is not going to stop real frauds, nor real criminals. Criminals will put up SPF records. Spammers were in fact the early SPF adopters. Criminal con-artists used to (probably still do) rent storefronts, too, to appear legitimate during the con. The notion that SPF records somehow prove email legitimacy just helps promote frauds by confusing users about what defines legitimacy. I'm not saying that there aren't real frauds out there. But I am saying that the 600 spams I recieve a day mostly do not represent real frauds. Only about 70 of them represent genuine commercial bulk emailers. Practically all of the ~70 are CAN-SPAM compliant That leaves an awful lot that are neither real frauds, nor genuinely commercial. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From owner-ietf-mxcomp@mail.imc.org Fri Nov 10 15:11:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gicj2-0003Fm-S0 for marid-archive@lists.ietf.org; Fri, 10 Nov 2006 15:11:44 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Giciz-0003R4-Gb for marid-archive@lists.ietf.org; Fri, 10 Nov 2006 15:11:44 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAAJYPWS051867; Fri, 10 Nov 2006 12:34:25 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAAJYPkp051866; Fri, 10 Nov 2006 12:34:25 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAAJYMmK051846 for ; Fri, 10 Nov 2006 12:34:23 -0700 (MST) (envelope-from leibzon@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so1081206nfe for ; Fri, 10 Nov 2006 11:34:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=PH/UvgfZU0CZ6pGtKJWjDcW0FECcOuHvdRYKwByc/mzj/S38kKB+1emalwqPukA9ydWrlanOFQ/cFrMBbAtSx5KrZ91hRM5FPvg57lU4umAW2q6RKw6BTQk6dJfp+wITyHPnzS4G39cJVc9bJ7Ht395R0nDDrU5julyjKGYEM+U= Received: by 10.49.34.3 with SMTP id m3mr3367174nfj.1163187261109; Fri, 10 Nov 2006 11:34:21 -0800 (PST) Received: by 10.49.28.2 with HTTP; Fri, 10 Nov 2006 11:34:20 -0800 (PST) Message-ID: Date: Fri, 10 Nov 2006 11:34:20 -0800 From: "William Leibzon" To: ietf-mxcomp@imc.org Subject: Doug attack scenarios without SPF MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_87700_4088226.1163187260966" X-Google-Sender-Auth: 84d1a7f4a3a26153 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.3 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 ------=_Part_87700_4088226.1163187260966 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, While Doug has particular issue with SPF, the problem he points to has little to do with SPF. In fact the attack is general dns attack that will work with several other records (MX, SRV, NS, most likely PTR and NAPTR and possibly CNAME [John Levine suggested it, but I don't immediately see using it by itself]). The issue that certain applications (including DNS resolver itself) by means of special DNS records can be directed to do several additional lookups. The idea of the attack is to direct those lookups to somebody else who would have to answer that it does not know about this name. Those answers if original name is large can themselves be quite large so you get amplification even though the answer i NXDOMAIN. So specially for Doug I'm going to give example of using NS and EHLO for this attack [note that my regular mail server and system with actual data is currently down, so I'm trying to give an example from head; I tested this yesterday], at the end I'll also explain why CSV is even better case for launching this attack. Lets assume that an attacker controls some domain big.bad.domain.example.net (for good amplification the name needs to be pretty long; for better view in email I'm not doing it). He sends email with SMTP session starting as EHLO big.bad.example.net and he previously set up the following in DNS: $ORIGIN bad.example.net big IN NS victim-dns1.example.com big IN NS victim-dns2.example.com big IN NS victim-dns3.example.com big IN NS victim-dns4.example.com big IN NS victim-dns5.example.com big IN NS victim-dns6.example.com big IN NS victim-dns7.example.com big IN NS victim-dns8.example.com If victim does not have enough dns servers, it can actually be done so as to direct attack againt the same server - its more complex and I don't want to go into it right now. Now lets assume that as per Doug's scenario the email is sent using botnet to many mail servers and we'll assume that those email servers are going to try to resolve EHLO name (some would some would not - both CSV and SPF would require it but many others do it anyway too). Now what happens is that each mail server that received the email would try to resolve big.bad.domain.example.net and as part of that would come to bad.domain.example.net and would be by means of NS directed to victim DNS. Victim servers would each answer that they are non-authoritive but would have to include large domain (i.e. imagine big.bad.example.com being close to maximum DNS label size) and that is where amplification comes from, i.e. the attacker only responded with one packet which include big.bad.example.com once in that packet and smaller size victim-dns (which since NS supports label compression can be even smaller) where as the response include that entire large name and comes from each and every NS server listed. The above attack can be architect ed to be more then 10:1 with certain additional tricks. Now I promised to explain why CSV makes it easy and is worse then SPF. That is due to the suggestion of having to walk the dns tree which as far as I remember it CSV specification has. Lets imagine that EHLO name is actually bad1.bad2.bad3.bad4.example.com. What happens is that CSV specifies to do lookups first to _client._smtp.bad1.bad2.bad3.bad4.example.com. Using above system you cause multiple lookups due to lame delegation at bad1.bad2.bad3.bad4.example.com that cause victims to respond they don't know how to find _client._smtp.bad1.bad2.bad3.bad4.example.com. Next per CSV (as far as I understood it), the application would have to try _client._smtp.bad2.bad3.bad4.example.com and similarly attacker can setup lame delegation but this time at bad2.bad3.bad4.example.com zone. And so this way you can easily cause many lookups for the same email session from the same system - that is why it is worse then with SPF. But in reality if you look into it deeper, the actual amplification factor would be the same as in all those cases you do one lookup for bad?.example.com and cause to do 10x responses. It is exactly the same with SPF but in that case Doug has used mx operator - he causes requests for MX hosted at attacker side and several requests from victim for addresses pointed out but MX. This all comes down to something like 10 amplification factor and not like 100 or more like Doug says. Again this is general issue that can be replicated using different DNS records - its cause is that several DNS record types cause application (or dns resolver) to do additional lookups to list of names specified in that record [and SPF is not something new to this field, nor is it some type of script like Doug says]. Another example of the same issue is when you send email such that it would bounce (you can do it although now days email systems are smarter) and you setup bad MX (like Doug did) which would cause lookups to victim. It would be the same type of attack and amplification. I can provide several more examples (email offers great choices since anti-spam systems do a lot of lookups when trying to decide if its good or bad email and if you use lots of domains for various victims like in URL then you often cause some type of lookup to find if that name exists) as well as examples in non-SMTP field (SNMP for example). I hope this helped you all to understand it. Note that I'll probably not be able to respond for a while (not only due to mail server problem which should get fixed later today hopefully but largely because I'm still going to in San Diego and expect not to spend my weekend connected to Internet and answering emails). William ------=_Part_87700_4088226.1163187260966 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

While Doug has particular issue with SPF, the problem he points to has little to do with SPF. In fact the attack is general dns attack that will work with several other records (MX, SRV, NS, most likely PTR and NAPTR and possibly CNAME [John Levine suggested it, but I don't immediately see using it by itself]). The issue that certain applications (including DNS resolver itself) by means of special DNS records can be directed to do several additional lookups. The idea of the attack is to direct those lookups to somebody else who would have to answer that it does not know about this name. Those answers if original name is large can themselves be quite large so you get amplification even though the answer i NXDOMAIN.

So specially for Doug I'm going to give example of using NS and EHLO for this attack [note that my regular mail server and system with actual data is currently down, so I'm trying to give an example from head; I tested this yesterday], at the end I'll also explain why CSV is even better case for launching this attack.

Lets assume that an attacker controls some domain  big.bad.domain.example.net  (for good amplification the name needs to be pretty long; for better view in email I'm not doing it). He sends email with SMTP session starting as
  EHLO big.bad.example.net
and he previously set up the following in DNS:
 $ORIGIN bad.example.net
   big IN NS victim-dns1.example.com
   big IN NS victim-dns2.example.com
   big IN NS victim-dns3.example.com
   big IN NS victim-dns4.example.com
   big IN NS victim-dns5.example.com
   big IN NS victim-dns6.example.com
   big IN NS victim-dns7.example.com
   big IN NS victim-dns8.example.com
If victim does not have enough dns servers, it can actually be done so as to direct attack againt the same server - its more complex and I don't want to go into it right now.

Now lets assume that as per Doug's scenario the email is sent using botnet to many mail servers and we'll assume that those email servers are going to try to resolve EHLO name (some would some would not - both CSV and SPF would require it but many others do it anyway too). Now what happens is that each mail server that received the email would try to resolve big.bad.domain.example.net and as part of that would come to bad.domain.example.net and would be by means of NS directed to victim DNS. Victim servers would each answer that they are non-authoritive but would have to include large domain (i.e. imagine big.bad.example.com being close to maximum DNS label size) and that is where amplification comes from, i.e. the attacker only responded with one packet which include big.bad.example.com once in that packet and smaller size victim-dns (which since NS supports label compression can be even smaller) where as the response include that entire large name and comes from each and every NS server listed. The above attack can be architect ed to be more then 10:1 with certain additional tricks.

Now I promised to explain why CSV makes it easy and is worse then SPF. That is due to the suggestion of having to walk the dns tree which as far as I remember it CSV specification has. Lets imagine that EHLO name is actually bad1.bad2.bad3.bad4.example.com. What happens is that CSV specifies to do lookups first to _client._smtp.bad1.bad2.bad3.bad4.example.com. Using above system you cause multiple lookups due to lame delegation at bad1.bad2.bad3.bad4.example.com that cause victims to respond they don't know how to find _client._smtp.bad1.bad2.bad3.bad4.example.com. Next per CSV (as far as I understood it), the application would have to try _client._smtp.bad2.bad3.bad4.example.com and similarly attacker can setup lame delegation but this time at bad2.bad3.bad4.example.com zone.

And so this way you can easily cause many lookups for the same email session from the same system  - that is why it is worse then with SPF. But in reality if you look into it deeper, the actual amplification factor would be the same as in all those cases you do one lookup for bad?.example.com and cause to do 10x responses. It is exactly the same with SPF but in that case Doug has used mx operator - he causes requests for MX hosted at attacker side and several requests from victim for addresses pointed out but MX. This all comes down to something like 10 amplification factor and not like 100 or more like Doug says.

Again this is general issue that can be replicated using different DNS records - its cause is that several DNS record types cause application (or dns resolver) to do additional lookups to list of names specified in that record [and SPF is not something new to this field, nor is it some type of script like Doug says]. Another example of the same issue is when you send email such that it would bounce (you can do it although now days email systems are smarter) and you setup bad MX (like Doug did) which would cause lookups to victim. It would be the same type of attack and amplification. I can provide several more examples (email offers great choices since anti-spam systems do a lot of lookups when trying to decide if its good or bad email and if you use lots of domains for various victims like in URL then you often cause some type of lookup to find if that name exists) as well as examples in non-SMTP field (SNMP for example).

I hope this helped you all to understand it. Note that I'll probably not be able to respond for a while (not only due to mail server problem which should get fixed later today hopefully but largely because I'm still going to in San Diego and expect not to spend my weekend connected to Internet and answering emails).

William
------=_Part_87700_4088226.1163187260966-- From owner-ietf-mxcomp@mail.imc.org Fri Nov 10 17:24:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GienJ-0000Zk-0Z for marid-archive@lists.ietf.org; Fri, 10 Nov 2006 17:24:17 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GienH-0000sn-Jh for marid-archive@lists.ietf.org; Fri, 10 Nov 2006 17:24:16 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAALdGYJ075968; Fri, 10 Nov 2006 14:39:16 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAALdGVn075967; Fri, 10 Nov 2006 14:39:16 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAALdCrj075958 for ; Fri, 10 Nov 2006 14:39:15 -0700 (MST) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id 95CC74AC7A; Fri, 10 Nov 2006 16:39:12 -0500 (EST) Date: Fri, 10 Nov 2006 16:39:12 -0500 From: John Leslie To: William Leibzon Cc: ietf-mxcomp@imc.org Subject: Re: Doug attack scenarios without SPF Message-ID: <20061110213912.GI73049@verdi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca ... clarifying one small portion... William Leibzon wrote: > > Now I promised to explain why CSV makes it easy and is worse then SPF. That > is due to the suggestion of having to walk the dns tree which as far as I > remember it CSV specification has. Lets imagine that EHLO name is actually > bad1.bad2.bad3.bad4.example.com. What happens is that CSV specifies to do > lookups first to _client._smtp.bad1.bad2.bad3.bad4.example.com. Using above > system you cause multiple lookups due to lame delegation at > bad1.bad2.bad3.bad4.example.com that cause victims to respond they don't > know how to find _client._smtp.bad1.bad2.bad3.bad4.example.com. Next per CSV > (as far as I understood it), the application would have to try > _client._smtp.bad2.bad3.bad4.example.com and similarly attacker can setup > lame delegation but this time at bad2.bad3.bad4.example.com zone. This deserves some explanation. The CSV design team considered it important to have a way to specify that any subdomains which send mail will have explicit CSV records. (Or, more commonly, that _no_ subdomains should be sending mail.) It is quite specifically intended that the bit which specifies this will be queried and cached by other players than the receiving SMTP server. Thus, you will find in section 7 of the CSA spec: ] ] A receiving SMTP server MAY discover domain assertion information ] (after finding no record for the specific domain in the EHLO string) ] by searching for CSV-CSA records in parent nodes of the EHLO string, ] within the DNS hierarchy. Such a search MUST NOT query a top-level ] domain (such as COM, NET, or UK), and SHOULD NOT query deeper than a ] sixth-level domain. We quite clearly intended that implementors would provide a way to disable these extra queries if they ever prove to be a problem. Speaking for myself only, I expected that reputation services would perform these queries as new EHLO domains come to their attention and periodically thereafter; and that their reputation reports would reflect the domain owners' intent that subdomain EHLOs are not authorized. I was not able to get agreement of the design team to say this in as many words in the spec. Nonetheless, the spec _is_ clear that any reputation service would be entitled to do this. Thus, IMHO, it is likely that this feature would not be available to be abused; and that at worst it might allow five extra queries. -- John Leslie From owner-ietf-mxcomp@mail.imc.org Sat Nov 18 22:24:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GldHl-0004KJ-JE for marid-archive@lists.ietf.org; Sat, 18 Nov 2006 22:24:01 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GldHj-0004Wi-6U for marid-archive@lists.ietf.org; Sat, 18 Nov 2006 22:24:01 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAJ2euVN030606; Sat, 18 Nov 2006 19:40:56 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAJ2eub1030605; Sat, 18 Nov 2006 19:40:56 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tortuga.leo.org (tortuga.leo.org [83.220.155.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAJ2esks030589 for ; Sat, 18 Nov 2006 19:40:55 -0700 (MST) (envelope-from maex@leo.org) Received: by tortuga.leo.org (Postfix, from userid 207) id C4531B3964; Sun, 19 Nov 2006 03:40:48 +0100 (CET) Date: Sun, 19 Nov 2006 03:40:48 +0100 From: "Markus Stumpf" To: "William Leibzon" Cc: ietf-mxcomp@imc.org Subject: Re: Doug attack scenarios without SPF Message-ID: <20061119024048.GF27919@leo.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: LEO - Link Everything Online, Munich, Germany X-PGP-Fingerprint: 66 F3 75 79 01 D0 B8 5F 1A C7 77 88 4A B6 70 DF User-Agent: Mutt/1.5.12-2006-07-14 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Hoi, On Fri, Nov 10, 2006 at 11:34:20AM -0800, William Leibzon wrote: > Now lets assume that as per Doug's scenario the email is sent using botnet > to many mail servers [ ... ] while I agree that there is some potential for a attack I don't see it as a really big problem. 1) AFAIK no caching DNS server sends out to *all* servers in NS records immediately. Some are rather clever in detecting identical DNS servers. 2) Caching helps even against lame delegations (ok - the botnet may use random subdomains) 3) Neither for the sender nor for the receiver does it make a real difference how large the hostname in the query is as long as it fits in one UDP packet. It's a packet on the wire. Compared to web traffic hammering against busy webservers it is still peanuts. 4) It is easy for the MTA to check for the length of the EHLO argument and ensure that it fits in one UDP packet 5) It is easy for the MTA to immediately establish temp. blocks for IPs sending EHLO arguments that lead to errors 6) A lot of MTAs already now checks the domain of the 2821.MAILFROM so it is already now possible to start that kind of attack. This is nothing newly introduced. 7) LHS wildcard blocks for abusive domains will also fix the problem rather fast and can be automated. For the attack to work the attacker must own the SLD (or sometimes 3rdLD) to be able to introduce lame delegations. Also the DNS servers for those domains can be automatically isolated or blocked. As I said - there is a potential for attacks but no new one. \Maex From owner-ietf-mxcomp@mail.imc.org Mon Nov 20 14:44:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmF4O-0003M9-F7 for marid-archive@lists.ietf.org; Mon, 20 Nov 2006 14:44:44 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmF4M-00005V-2F for marid-archive@lists.ietf.org; Mon, 20 Nov 2006 14:44:44 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAKJ4cWq069457; Mon, 20 Nov 2006 12:04:38 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAKJ4c9S069456; Mon, 20 Nov 2006 12:04:38 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAKJ4YYY069445 for ; Mon, 20 Nov 2006 12:04:37 -0700 (MST) (envelope-from dean@av8.com) Received: from piper.av8.net (piper.av8.net [130.105.11.2]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id kAKJ4RBm018612 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 20 Nov 2006 14:04:33 -0500 Date: Mon, 20 Nov 2006 14:04:27 -0500 (EST) From: Dean Anderson X-X-Sender: dean@piper.av8.net To: Markus Stumpf cc: William Leibzon , Subject: Re: Doug attack scenarios without SPF In-Reply-To: <20061119024048.GF27919@leo.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.8 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 On Sun, 19 Nov 2006, Markus Stumpf wrote: > while I agree that there is some potential for a attack I don't see > it as a really big problem. I agree. > 4) It is easy for the MTA to check for the length of the EHLO argument > and ensure that it fits in one UDP packet The SMTP server should not try to resolve the EHLO/HELO argument. There is nothing to learn from by resolving this argument. It just adds to the DNS load, and it increases the time to handle a signle message. This then reduces the rate at which the mail server can process messages, and increases the resources consumed by the email server. (gun-foot-fire-aim) -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From owner-ietf-mxcomp@mail.imc.org Mon Nov 20 14:45:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmF5O-0004k1-Qi for marid-archive@lists.ietf.org; Mon, 20 Nov 2006 14:45:46 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmF5N-0000BV-A4 for marid-archive@lists.ietf.org; Mon, 20 Nov 2006 14:45:46 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAKJF4ZK070261; Mon, 20 Nov 2006 12:15:04 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAKJF4pc070260; Mon, 20 Nov 2006 12:15:04 -0700 (MST) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAKJF0Qq070250 for ; Mon, 20 Nov 2006 12:15:01 -0700 (MST) (envelope-from dotis@mail-abuse.org) Received: from [10.2.164.130] (SJC-Office-NAT-216.Mail-Abuse.ORG [168.61.10.216]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id kAKJEtDp006715 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 20 Nov 2006 11:14:57 -0800 In-Reply-To: <20061119024048.GF27919@leo.org> References: <20061119024048.GF27919@leo.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <02AE0E68-9F52-46B9-8FFB-A8A8CDC38EE8@mail-abuse.org> Cc: "William Leibzon" , ietf-mxcomp@imc.org Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: Doug attack scenarios without SPF Date: Mon, 20 Nov 2006 11:14:53 -0800 To: Markus Stumpf X-Mailer: Apple Mail (2.752.2) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 On Nov 18, 2006, at 6:40 PM, Markus Stumpf wrote: > On Fri, Nov 10, 2006 at 11:34:20AM -0800, William Leibzon wrote: >> >> Now lets assume that as per Doug's scenario the email is sent >> using botnet to many mail servers [ ... ] > > while I agree that there is some potential for a attack I don't see > it as a really big problem. When domains routinely process SPF scripts for accepted messages (not stopped by their block-lists), the potential impact of this operation might be extremely high. There would be little a victim could do to remedy the situation, which makes this a really big problem for them. > 1) AFAIK no caching DNS server sends out to *all* servers in NS > records immediately. Some are rather clever in detecting identical > DNS servers. The NS record technique amplifies effects of an SPF script resolving addresses within 100 different domains executed for each email- address evaluated. The evaluation process may occur for both the PRA and the Mail_From, for example. This would then mean 200 domains times some number of errant and targeted DNSs contacted within a recursion process. The spf-dos-exploit even excluded recursion overhead from the example attack gain calculations. Without this overhead, the example SPF script generates 64 kbytes of DNS traffic per execution! > 2) Caching helps even against lame delegations (ok - the botnet may > use random subdomains) This random domain selection is facilitated by the SPF script (without changing the script itself) as illustrated in the example attack. > 3) Neither for the sender nor for the receiver does it make a real > difference how large the hostname in the query is as long as it > fits in one UDP packet. It's a packet on the wire. Compared to web > traffic hammering against busy webservers it is still peanuts. There is a big difference. UDP does not provide congestion avoidance. SPF routines abruptly timeout execution of a script, where a new script is then started. The prior script may have encountered exponential back-off by DNS. Running another script without waiting defeats congestion avoidance of DNS. The problem described is an exploit made virtually free to attackers using a bot- net where complete flooding of a network backbone is made all too possible. > 4) It is easy for the MTA to check for the length of the EHLO > argument and ensure that it fits in one UDP packet An EHLO lookup would be for 1 host-name, and not the 10 host-names resolved within an SPF MX mechanism. SPF also allows 10 MX mechanisms, which means SPF expects 100 times the number of DNS transactions (ignoring the transactions for the SPF TXT or RR 99 records and that this might be done more than once per message). > 5) It is easy for the MTA to immediately establish temp. blocks for > IPs sending EHLO arguments that lead to errors Exactly. But the same is not true for SMTP clients offering SPF scripts resulting in passing or neutral results. : ( > 6) A lot of MTAs already now checks the domain of the 2821.MAILFROM > so it is already now possible to start that kind of attack. This > is nothing newly introduced. If there are MailFrom of the SMPT client checks made against a receiving MX record (which seems silly as this must be allowed to fail), then SPF would still increase the impact of this checking by an order of magnitude! > 7) LHS wildcard blocks for abusive domains will also fix the > problem rather fast and can be automated. For the attack to work > the attacker must own the SLD (or sometimes 3rdLD) to be able to > introduce lame delegations. Also the DNS servers for those domains > can be automatically isolated or blocked. No. The victim can do nothing to prevent this attack, and there is nothing that those cooperating in the attack will notice. The domains within the message can be completely different from the domains being attacked in the malicious SPF scripts. It is rather common for bot-nets to use hundreds of throw-away domains each day (often at no cost to them). Worse still the SPF results might be providing a PASS for all attacking messages referencing the malicious SPF scripts. > As I said - there is a potential for attacks but no new one. While a DNS based attack is not new, the level of obtained by this attack would be, and by a sizable amount. -Doug