From owner-ietf-mxcomp@mail.imc.org Wed Jun 1 01:04:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27910 for ; Wed, 1 Jun 2005 01:04:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j514cWFt044998; Tue, 31 May 2005 21:38:32 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j514cWj4044997; Tue, 31 May 2005 21:38:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (ftp.catinthebox.net [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id j514cV4U044990 for ; Tue, 31 May 2005 21:38:31 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.1.451.4) for ietf-mxcomp@imc.org; Wed, 01 Jun 2005 00:39:28 -0400 Received: from ([68.215.118.148]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.1.451.4) with SMTP id 1352800828; Wed, 01 Jun 2005 00:39:27 -0400 Message-ID: <003a01c56663$77c853e0$6401a8c0@hdev1> From: "Hector Santos" To: "Douglas Otis" Cc: References: <1117137745.7537.157.camel@SJC-Office-DHCP-156.mail-abuse.org> <200505262318.03899.bulk@mehnle.net> <1117166528.30777.16.camel@SJC-Office-DHCP-156.mail-abuse.org> <42971610.7090603@ashtonwoodshomes.com> <1117229806.10255.266.camel@SJC-Office-DHCP-156.mail-abuse.org> <4297D265.3030307@ashtonwoodshomes.com> <1117400274.9146.152.camel@littlejoy> <87sm03zpwz.fsf@gmdev.webwayone.co.uk> <1117566434.7521.132.camel@SJC-Office-DHCP-156.mail-abuse.org> Subject: Re: draft-schlitt-spf-classic-01.txt Date: Wed, 1 Jun 2005 00:36:20 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Douglas Otis" To: "Graham Murray" Cc: Sent: Tuesday, May 31, 2005 3:07 PM Subject: Re: draft-schlitt-spf-classic-01.txt > While > possible, with add restrictions imposed by the email provider, the > domain owner remains completely at the mercy of an email provider's > diligence at _every_ MTA involved in the transport of the message, and > not just those MTAs that have been directly authorized by the SPF > record. A mistake on the part of an email provider, such as > misconfiguration of a firewall, and the domain owner's reputation > suffers. And how is CSV immuned from these same set of possible routing scenarioes? Are you saying that once CSV authorizes a submission at the MSA, then there is no need to further perform CSV during the route and only at the MDA? What if you have this topology? MUA ---> MSA1/MTA1 -----> MTA2 ----> MDA3 MSA1 and MDA3 is CVS ready. MTA2 is not. How does MDA3 handle this using CSV? What is the policy here? -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Wed Jun 1 04:10:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04197 for ; Wed, 1 Jun 2005 04:10:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j517huuM012827; Wed, 1 Jun 2005 00:43:56 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j517huVX012825; Wed, 1 Jun 2005 00:43:56 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j517htDU012810 for ; Wed, 1 Jun 2005 00:43:55 -0700 (PDT) (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 j517hscO010387; Wed, 1 Jun 2005 00:43:54 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id j517hs6I010384; Wed, 1 Jun 2005 00:43:54 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Wed, 1 Jun 2005 00:43:53 -0700 (PDT) From: "william(at)elan.net" To: Douglas Otis cc: Hector Santos , ietf-mxcomp@imc.org Subject: Re: draft-schlitt-spf-classic-01.txt In-Reply-To: <1117605924.2710.114.camel@bash.adsl-64-142-13-68> Message-ID: References: <1117137745.7537.157.camel@SJC-Office-DHCP-156.mail-abuse.org> <200505262318.03899.bulk@mehnle.net> <1117166528.30777.16.camel@SJC-Office-DHCP-156.mail-abuse.org> <42971610.7090603@ashtonwoodshomes.com> <1117229806.10255.266.camel@SJC-Office-DHCP-156.mail-abuse.org> <4297D265.3030307@ashtonwoodshomes.com> <1117400274.9146.152.camel@littlejoy> <87sm03zpwz.fsf@gmdev.webwayone.co.uk> <1117566434.7521.132.camel@SJC-Office-DHCP-156.mail-abuse.org> <003a01c56663$77c853e0$6401a8c0@hdev1> <1117605924.2710.114.camel@bash.adsl-64-142-13-68> 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: On Tue, 31 May 2005, Douglas Otis wrote: > The HELO name would be indicative of the domain administrator running > the MTA, irrespective of the mailbox-domains contained in messages sent > by the MTA. If the MTA is not properly administered, it would be this > MTA and the administrator of this MTA identified by a reputation scheme > that rates HELO names. Doug, People here are not saying that being able to tag responsiblity to MTA is a bad idea. People are just saying that there are also other ways it can be done and that MTA responsiblity is one thing while domain owner responsiblity is another and that both are usefull when making decisions. > Those that would normally send messages over a HELO blocked MTA would be > free to look elsewhere to obtain email services. If the mailbox-domains > were rated and blocked instead, as with SPF, a poorly maintained MTA > could continue to send abusive and even forged emails, but then the > domain owners would find use of their domains blocked, no matter which > other provider they tried. I think what you're trying to argue here that when domain owner is using shared MTA that does not have strong policies in regards to its network than it may become target of abuse and abusers may choose to use other domains maintained by that MTA at random, i.e. its the case of large dsl provider and user having to use that provider's MTA and is subject to the MTA being used by zombies located on the provier's networ and zombies choosing domains of various users (that come through that mta) at random. Is that what you're worried about? -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Wed Jun 1 14:44:25 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14411 for ; Wed, 1 Jun 2005 14:44:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j51IL8So058034; Wed, 1 Jun 2005 11:21:08 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j51IL8ac058033; Wed, 1 Jun 2005 11:21:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j51IL7ul058025 for ; Wed, 1 Jun 2005 11:21:07 -0700 (PDT) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 3CD6416E17 for ; Wed, 1 Jun 2005 14:19:34 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: draft-schlitt-spf-classic-01.txt In-Reply-To: Your message of "Wed, 01 Jun 2005 00:43:53 PDT." Date: Wed, 01 Jun 2005 14:19:34 -0400 Message-Id: <20050601181934.3CD6416E17@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "william(at)elan.net" wrote: > I think what you're trying to argue here that when domain owner is using > shared MTA that does not have strong policies in regards to its network > than it may become target of abuse and abusers may choose to use other > domains maintained by that MTA at random, If an MTA is shared, the reputation would seem to be shared, too. That's life. We could require that abuse of a shared MTA by one domain not affect the reputation of another domain also at that MTA. But we can't use the HELO field as part of a solution to meet that requirement, as the only information it presents is the name of the shared MTA. If the *message* is authenticated, and not the *transport* layer, then it doesn't matter how the message is transported. But that's another issue... Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Wed Jun 1 15:26:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18864 for ; Wed, 1 Jun 2005 15:26:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j51J2I4g060831; Wed, 1 Jun 2005 12:02:18 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j51J2Iwr060830; Wed, 1 Jun 2005 12:02:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org ([168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j51J2HaR060770 for ; Wed, 1 Jun 2005 12:02:17 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from SJC-Office-DHCP-156.Mail-Abuse.ORG (SJC-Office-DHCP-156.Mail-Abuse.ORG [168.61.10.156]) by harry.mail-abuse.org (Postfix) with ESMTP id 5DFEA414F0; Wed, 1 Jun 2005 12:01:42 -0700 (PDT) Subject: Re: draft-schlitt-spf-classic-01.txt From: Douglas Otis To: "william(at)elan.net" Cc: Hector Santos , ietf-mxcomp@imc.org In-Reply-To: References: <1117137745.7537.157.camel@SJC-Office-DHCP-156.mail-abuse.org> <200505262318.03899.bulk@mehnle.net> <1117166528.30777.16.camel@SJC-Office-DHCP-156.mail-abuse.org> <42971610.7090603@ashtonwoodshomes.com> <1117229806.10255.266.camel@SJC-Office-DHCP-156.mail-abuse.org> <4297D265.3030307@ashtonwoodshomes.com> <1117400274.9146.152.camel@littlejoy> <87sm03zpwz.fsf@gmdev.webwayone.co.uk> <1117566434.7521.132.camel@SJC-Office-DHCP-156.mail-abuse.org> <003a01c56663$77c853e0$6401a8c0@hdev1> <1117605924.2710.114.camel@bash.adsl-64-142-13-68> Content-Type: text/plain Date: Wed, 01 Jun 2005 12:01:40 -0700 Message-Id: <1117652500.7537.148.camel@SJC-Office-DHCP-156.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2005-06-01 at 00:43 -0700, william(at)elan.net wrote: > On Tue, 31 May 2005, Douglas Otis wrote: > > > The HELO name would be indicative of the domain administrator running > > the MTA, irrespective of the mailbox-domains contained in messages sent > > by the MTA. If the MTA is not properly administered, it would be this > > MTA and the administrator of this MTA identified by a reputation scheme > > that rates HELO names. > > People here are not saying that being able to tag responsibility to MTA is > a bad idea. People are just saying that there are also other ways it > can be done and that MTA responsibility is one thing while domain owner > responsibility is another and that both are useful when making decisions. To authenticate the mailbox-domain, use a signature. It is unfair to hold the mailbox-domain owner accountable, when there remains doubt about who actually initiated the message, as with SPF. Dunning the mailbox-domain owner for abuse can not be effective, when the source of the problem is a mystery to them. The only avenue available to the mailbox-domain owner would involve a discovery process in an expensive litigation, to force the MTA administrator to produce requisite transaction logs. Otherwise, the MTA administrator would be obligated to keep these logs private, and may not be cooperative when the logs indicate they were negligent in some fashion. > > Those that would normally send messages over a HELO blocked MTA would be > > free to look elsewhere to obtain email services. If the mailbox-domains > > were rated and blocked instead, as with SPF, a poorly maintained MTA > > could continue to send abusive and even forged emails, but then the > > domain owners would find use of their domains blocked, no matter which > > other provider they tried. > > I think what you're trying to argue here that when domain owner is using > shared MTA that does not have strong policies in regards to its network > than it may become target of abuse and abusers may choose to use other > domains maintained by that MTA at random, i.e. its the case of large dsl > provider and user having to use that provider's MTA and is subject to > the MTA being used by zombies located on the provider's network and zombies > choosing domains of various users (that come through that mta) at random. > Is that what you're worried about? Only by naming the actual source of abuse, not just finding a name to blame, would reputation provide a means to ensure the MTA administrator remains diligent. Only a diligent MTA administrator can be effective at squelching abuse. The number of techniques used to circumvent security is many. Two rather obvious concerns would be open-proxy or open-relay, which have specific dedicated black-hole lists for just these possible administrative errors. Some of these errors require third-party real-time verification to isolate the source. Hardly a legitimate duty to be expected of the mailbox-domain owner. In addition to normal security concerns, with SPF/Sender-ID, the MTA administrator MUST apply mailbox-domain limitations based upon permissions for either authenticated users or an MTA being relayed. This will cost the MTA administrator support calls. Because SPF depends upon ambiguous defaults defining which identities are assured within a message, SPF records may be used as a basis for applying the PRA or the bounce-address. Therefore, any MTA administrator failing to make the same limitations for the PRA, as for the bounce-address, place the mailbox-domain owner's reputation at risk. The only safe option presently available for the mailbox-domain owner would be to NOT publish SPF records. Otherwise, the mailbox-domain owner runs a serious risk of being assumed culpable for any forged abusive messages that may appear. With these SPF records being very public, an already far too common nefarious abuser employing the use of Zombied systems, will also know who they should try to forge. Abusers may be successful due to an MTA administrator's lapse in applying either some or all of the expensive mailbox-domain restrictions. Even if the Zombied system were owned by the actual domain owner, the MTA administrator is best able to detect abuse to alert the domain owner. On a per-MTA basis, CSV ensures the administrator is held accountable for the operation of the server. It is foolish to hold a feckless mailbox-domain owner accountable. Signatures, while not providing any network resource protection, do offer a fair and safe method to hold the administrator accountable from where the message originated. Signatures can track the mailbox-domain and offer real anti-phishing protections as well. While there have been some to suggest Sender-ID offers anti-phishing protection, it is not safe due to reliance on hidden headers and server authorizations. To increase the integrity and safety of email delivery, an identification and reputation scheme needs to be as close to go/no-go as possible. Otherwise, the junk folder becomes the nemesis of a large number of gray transactions. It is unfortunate that SPF has four levels of server authorization. This multilevel aspect has a multiplicative affect on reputation assessments, as there may be a desire to track each level separately to form some kind of proprietary fuzzy-logic aggregate. As I said when I started my comments, SPF is fundamentally flawed. SPF and Sender-ID in combination is a disaster. The filtering paradigm used by SPF to handle its many shades of gray will ensure the problems created will be intractable. The only means I see to extricate SPF from making things far far worse, would be to depreciate the use of version 1 SPF records. Recommend that they be removed. For those that don't want to be trusting an MTA provider to assure their reputation, offer a new scope called 'ADMIN' to allow SPF to be used for white-listing purposes only. Should SPF/Sender-ID reputation schemes become used as promised, there will be a new industry servicing email forensics to assist a booming civil discovery process. The harm created will be intractable and extremely damaging. Domain constraints will cause a loss of customers and enumerable support calls. SPF/Sender-ID provides two very difficult paths to choose, when attempting to avoid administrative accountability. Adjust your budget accordingly, there is no free lunch. CSV, on the other hand, indicates that you accept administrative accountability without unfairly foisting this onto your customers. Only signatures offer an alternative that can safely apply accountability from where the message initiated. -Doug From owner-ietf-mxcomp@mail.imc.org Thu Jun 2 04:48:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18319 for ; Thu, 2 Jun 2005 04:48:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j528Grn9082437; Thu, 2 Jun 2005 01:16:53 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j528GrRI082436; Thu, 2 Jun 2005 01:16:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from procserver.webwayone.co.uk (webway-one-02.hiway.co.uk [62.8.115.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j528GqAV082409 for ; Thu, 2 Jun 2005 01:16:53 -0700 (PDT) (envelope-from SRS0=/t1qijTs=UI=webwayone.co.uk=graham@webwayone.co.uk) DomainKey-Signature: a=rsa-sha1; s=procserver; d=webwayone.co.uk; c=nofws; q=dns; h=from:to:subject:references:date:in-reply-to:message-id: user-agent:mime-version:content-type; b=NyvPEspKcYQJtRBO7/lS3YAk/s8B+h6DLwmAGERBw+zHLSr1TDJO3OAKx7S9SqQ6u Uq19VgtlktVb4caUupHrA== Received-SPF: none (procserver.webwayone.co.uk: domain of graham@webwayone.co.uk does not designate permitted sender hosts) receiver=procserver.webwayone.co.uk; client-ip=192.168.50.45; envelope-from=; helo=gmdev.webwayone.co.uk; Received: from gmdev.webwayone.co.uk (graham@gmdev.webwayone.co.uk [192.168.50.45]) by procserver.webwayone.co.uk (8.13.4/8.13.4) with ESMTP id j528HZ9Z025155 for ; Thu, 2 Jun 2005 09:17:40 +0100 From: Graham Murray To: ietf-mxcomp@imc.org Subject: Re: draft-schlitt-spf-classic-01.txt References: <20050601181934.3CD6416E17@mail.nitros9.org> Date: Thu, 02 Jun 2005 08:16:45 +0000 In-Reply-To: <20050601181934.3CD6416E17@mail.nitros9.org> (Alan DeKok's message of "Wed, 01 Jun 2005 14:19:34 -0400") Message-ID: <87y89tnpg2.fsf@gmdev.webwayone.co.uk> User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.3 (i586-suse-linux) 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: "Alan DeKok" writes: > If an MTA is shared, the reputation would seem to be shared, too. > That's life. If reputation is that important for a domain owner then they can always run their own mail server(s) and not use a shared MTA. From owner-ietf-mxcomp@mail.imc.org Thu Jun 2 05:05:05 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19300 for ; Thu, 2 Jun 2005 05:05:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j528jjmc092211; Thu, 2 Jun 2005 01:45:45 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j528jjFq092210; Thu, 2 Jun 2005 01:45:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from miranda.server-plant.co.uk (miranda.server-plant.co.uk [193.110.88.60]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j528jhGZ092191 for ; Thu, 2 Jun 2005 01:45:44 -0700 (PDT) (envelope-from johnp@idimo.com) Received: from [83.230.186.205] ([83.230.186.205]) (authenticated) by miranda.server-plant.co.uk (8.11.6/8.11.2) with ESMTP id j528jgw31081 for ; Thu, 2 Jun 2005 09:45:42 +0100 Message-ID: <429EC730.2070709@idimo.com> Date: Thu, 02 Jun 2005 10:45:36 +0200 From: johnp User-Agent: Debian Thunderbird 1.0.2 (X11/20050331) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: ietf-mxcomp@imc.org Subject: Re: draft-schlitt-spf-classic-01.txt References: <20050601181934.3CD6416E17@mail.nitros9.org> <87y89tnpg2.fsf@gmdev.webwayone.co.uk> In-Reply-To: <87y89tnpg2.fsf@gmdev.webwayone.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I run Postfix on a server, and anyone who wants a seperate MTA can have a seperate instance of Postfix running just for themselves, with a seperate IP. The rest of the server facilities are shared. I'm not sure if sendmail allows seperate instances to run similtaneously like this. Graham Murray wrote: > "Alan DeKok" writes: > > >> If an MTA is shared, the reputation would seem to be shared, too. >>That's life. > > > If reputation is that important for a domain owner then they can always run > their own mail server(s) and not use a shared MTA. > From owner-ietf-mxcomp@mail.imc.org Thu Jun 2 23:17:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23422 for ; Thu, 2 Jun 2005 23:17:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j532ra19055092; Thu, 2 Jun 2005 19:53:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j532raUL055091; Thu, 2 Jun 2005 19:53:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j532rZai055082 for ; Thu, 2 Jun 2005 19:53:35 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from SJC-Office-DHCP-156.Mail-Abuse.ORG (SJC-Office-DHCP-156.Mail-Abuse.ORG [168.61.10.156]) by harry.mail-abuse.org (Postfix) with ESMTP id 7A129414EE; Thu, 2 Jun 2005 19:53:32 -0700 (PDT) Subject: Re: draft-schlitt-spf-classic-01.txt From: Douglas Otis To: Alan DeKok Cc: ietf-mxcomp@imc.org In-Reply-To: <20050601181934.3CD6416E17@mail.nitros9.org> References: <20050601181934.3CD6416E17@mail.nitros9.org> Content-Type: text/plain Date: Thu, 02 Jun 2005 19:53:31 -0700 Message-Id: <1117767211.7614.106.camel@SJC-Office-DHCP-156.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2005-06-01 at 14:19 -0400, Alan DeKok wrote: > "william(at)elan.net" wrote: > > I think what you're trying to argue here that when domain owner is using > > shared MTA that does not have strong policies in regards to its network > > than it may become target of abuse and abusers may choose to use other > > domains maintained by that MTA at random, > > If an MTA is shared, the reputation would seem to be shared, too. > That's life. I agree with William's statement. With SPF or Sender-ID, reputation accrual would damage a mailbox-domain owner, and not the MTA administrator. The mailbox-domain owner may have been singled-out and forged by some zombied customer, until the victim's reputation is thoroughly destroyed. The administrator of a shared MTA must apply mailbox-domain constraints on both the bounce-address and the PRA for each and every message. This constraint must limit the domains permitted for the authenticated users or relayed MTAs. Lack of this domain constraint operation imperils their customer's domain reputation. I doubt many email providers would provide a virtual MTA with an isolated IP addresses, just to avoid the need to assure this mailbox-domain constraint. I have little doubt the MTA administrator would do nothing, and consider this as not their problem. IP address space pressures has caused much of the sharing of IP addresses for both MTAs and Web servers. One reason to deploy a name based reputation system, is to overcome the problem of IP address aggregation affecting so many different domains. The application of reputation makes domain/user isolation critical for the domain owner. > We could require that abuse of a shared MTA by one domain not affect > the reputation of another domain also at that MTA. But we can't use > the HELO field as part of a solution to meet that requirement, as the > only information it presents is the name of the shared MTA. The lack of HELO validation would not be considered a reason to reject the message, based on either SPF or Sender-ID validation. Had just the MTA identifiers, IP address or HELO, been solely utilized as a basis for accruing reputation, then indeed reputations would be shared by every domain using the MTA. Then the domain owner could recover use of their domain by employing a different MTA. Relying upon the MTA identifiers for reputation accrual provides the MTA administrator an incentive to aggressively disable abusive accounts. They would maintain diligence by either monitoring logs for volumes and errors, or by checking abuse reports. This incentive is real and valuable. Once an MTA administrator buys the notion that SPF/Sender-ID takes care of abuse, where reputation no longer affects them directly, they have less incentive to do the real job of abating abuse before it is sent. While this may be seen as a great feature by email providers, it should cause network providers and any domain owner great concern. Abusers controlling millions of zombies will jump on this weakness, much to the detriment of mailbox-domain owners sharing an MTA, and that have also published SPF records. Unless you run your own MTA and are willing to allow some mail to be lost by those that have forwarding accounts, do not publish SPF! Consider DomainKeys for now, and then upgrade to DKIM. > If the *message* is authenticated, and not the *transport* layer, > then it doesn't matter how the message is transported. But that's > another issue... Yes it is. That is the reason DKIM is so desperately needed. -Doug From owner-ietf-mxcomp@mail.imc.org Fri Jun 3 13:13:14 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15392 for ; Fri, 3 Jun 2005 13:13:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j53GmUpv068229; Fri, 3 Jun 2005 09:48:30 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j53GmUYC068228; Fri, 3 Jun 2005 09:48:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j53GmTYc068221 for ; Fri, 3 Jun 2005 09:48:29 -0700 (PDT) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id B52D916FAB for ; Fri, 3 Jun 2005 12:47:04 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: draft-schlitt-spf-classic-01.txt In-Reply-To: Your message of "Thu, 02 Jun 2005 19:53:31 PDT." <1117767211.7614.106.camel@SJC-Office-DHCP-156.mail-abuse.org> Date: Fri, 03 Jun 2005 12:47:04 -0400 Message-Id: <20050603164704.B52D916FAB@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Douglas Otis wrote: > IP address space pressures has caused much of the sharing of IP > addresses for both MTAs and Web servers. What's up with 29/8 & 30/8? There are 50M addresses unused. > One reason to deploy a name based reputation system, is to overcome > the problem of IP address aggregation affecting so many different > domains. The application of reputation makes domain/user isolation > critical for the domain owner. In the absence of DNSSec, using DNS names for reputation is a bit problematic. You're never completely sure that the domain is currently being controlled by it's owner. > Once an MTA administrator buys the notion that SPF/Sender-ID takes care > of abuse, where reputation no longer affects them directly, they have > less incentive to do the real job of abating abuse before it is sent. I'm not sure there's any technical solution to that problem. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Fri Jun 3 15:21:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26083 for ; Fri, 3 Jun 2005 15:21:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j53ItutK078215; Fri, 3 Jun 2005 11:55:56 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j53ItuFE078214; Fri, 3 Jun 2005 11:55:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j53Itt5Z078197 for ; Fri, 3 Jun 2005 11:55:55 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from SJC-Office-DHCP-156.Mail-Abuse.ORG (SJC-Office-DHCP-156.Mail-Abuse.ORG [168.61.10.156]) by harry.mail-abuse.org (Postfix) with ESMTP id 9EAAA414EF; Fri, 3 Jun 2005 11:55:50 -0700 (PDT) Subject: Re: draft-schlitt-spf-classic-01.txt From: Douglas Otis To: Alan DeKok Cc: ietf-mxcomp@imc.org In-Reply-To: <20050603164704.B52D916FAB@mail.nitros9.org> References: <20050603164704.B52D916FAB@mail.nitros9.org> Content-Type: text/plain Date: Fri, 03 Jun 2005 11:55:50 -0700 Message-Id: <1117824950.7562.94.camel@SJC-Office-DHCP-156.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2005-06-03 at 12:47 -0400, Alan DeKok wrote: > Douglas Otis wrote: > > IP address space pressures has caused much of the sharing of IP > > addresses for both MTAs and Web servers. > > What's up with 29/8 & 30/8? There are 50M addresses unused. IP address conservation has slowed the rate of consumption. Once these addresses are fully assigned, reliance upon IPv6 becomes required. As with many things, preparation requires time to phase-in full support. In the meantime, to allow communities early in their Internet deployment a reasonable number of IP addresses, some addresses need to be reserved. If each domain name required a unique address, this reserve would be quickly exhausted. > > One reason to deploy a name based reputation system, is to overcome > > the problem of IP address aggregation affecting so many different > > domains. The application of reputation makes domain/user isolation > > critical for the domain owner. > > In the absence of DNSSec, using DNS names for reputation is a bit > problematic. You're never completely sure that the domain is > currently being controlled by it's owner. DKIM creates far fewer DNS security concerns compared to SPF which reduces some of these potential DNS problems, rather than adding to it. For reasons actually unrelated to DNS, DNSsec should be deployed. While even DNSsec will not prevent every attack vector, it will expose more attack efforts. Hopefully, diligence and cooperation prevail in cutting-off network providers that permit the coordination such activities. There is a need to establish a re-assignable ID number to identify those that trade or use stolen identifiers. By requiring a timestamped query to a clearinghouse, to return to the requester a relevant static index (pseudo SSN), would make this information far more risky for the criminals. The query may also identify abuse attempts. There could be many re-assignable ID clearinghouses used for various purposes. > > Once an MTA administrator buys the notion that SPF/Sender-ID takes care > > of abuse, where reputation no longer affects them directly, they have > > less incentive to do the real job of abating abuse before it is sent. > > I'm not sure there's any technical solution to that problem. The simple technical solution would be to _always_ base reputation accrual upon "Authenticated Senders" and _never_ "Server Authorization." Going down the list of identifies available that could isolate security and abuse issues to the accountable administrator, it would be: - IP Address - Authenticated HELO Name - Validated Signatures You will notice that the mailbox-domain is not in this list. This mailbox-domain identity is passed from MTA to MTA, and is unrelated to an accountable administrator. SPF or Sender-ID also makes a false assumption that the MTA is not shared, or that the MTA administrator ensures user/mailbox-domain relationships are protected. I have yet to hear anyone caution domain-owners they should first become indemnified in their provider's SLA, and be assured only their messages are permitted to use their domain in the bounce-address or the Purported Responsible Addresses, as defined in Microsoft's proprietary algorithm. The penalties should be sufficient to cover loss of the use of the domain. This SLA should provide a means to verify any allegations of negligence on the part of the provider. Without this agreement, the domain owner would be placing their domain's reputation in extreme peril. -Doug From owner-ietf-mxcomp@mail.imc.org Fri Jun 3 17:52:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17517 for ; Fri, 3 Jun 2005 17:52:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j53LSJi3007829; Fri, 3 Jun 2005 14:28:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j53LSJUc007828; Fri, 3 Jun 2005 14:28:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j53LSIbm007820 for ; Fri, 3 Jun 2005 14:28:18 -0700 (PDT) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 7FB8216DD6 for ; Fri, 3 Jun 2005 17:26:54 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: draft-schlitt-spf-classic-01.txt In-Reply-To: Your message of "Fri, 03 Jun 2005 11:55:50 PDT." <1117824950.7562.94.camel@SJC-Office-DHCP-156.mail-abuse.org> Date: Fri, 03 Jun 2005 17:26:54 -0400 Message-Id: <20050603212654.7FB8216DD6@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Douglas Otis wrote: > Going down the list of identifies available that could isolate security > and abuse issues to the accountable administrator, it would be: > - IP Address > - Authenticated HELO Name > - Validated Signatures > > You will notice that the mailbox-domain is not in this list. s/this/your/. Not everyone agrees. I have vanity domains where I'm the only person with mailboxes at the domain. I *am* the accountable administrator for that domain, and I would like to be able to state so. I would like to be able to say publicly that any message not from me, using mailboxes at my domain, is forged. Some proposals allow me to do that. The original purpose behind RMX was exactly that: Hadmut had a vanity domain, and couldn't stop people from forging messages using that name. Hadmut was also very clear that not everyone would want to use RMX, but the people who would use it could protect themselves. The response then, as now, is that there is absolute opposition to such proposals. The requirement that we permit ".forward" style MTA's to use third-party domain names is a requirement that people like Hadmut and myself cannot prevent others from forging spam using our names. > This mailbox-domain identity is passed from MTA to MTA, and is > unrelated to an accountable administrator. Ah, yes. If we assume the current behavior is desired, then the conclusions are foregone. If, on the other had, we have the temerity to question the existing assumptions, then the conclusions are questionable, too. > SPF or Sender-ID also makes a false assumption that the MTA is not > shared, or that the MTA administrator ensures user/mailbox-domain > relationships are protected. SPF and related proposals allow the DNS administrator to claim that the MTA satisfies certain criteria. But this benefit is being turned around, and claimed to be an accidental, and negative side-effect. > I have yet to hear anyone caution domain-owners they should first become > indemnified in their provider's SLA, and be assured only their messages > are permitted to use their domain in the bounce-address For me, it isn't so much about permission as audit trail. If I can't prove a particular message using a mailbox address is actually associated with that address, then I have no idea if the message is forged or not. Signatures don't help, as anyone can create a certificate or key for any identity they want. What matters is the "web of trust", or the relationship. Signatures *can* help if the certificate for "user@example.com" is signed by the key for "example.com", and the key for "example.com" is signed by a known CA. In that case, the signatures are a means to an end, not a solution in themselves. They make the relationship management easy and reliable, nothing more. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Fri Jun 3 21:30:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02482 for ; Fri, 3 Jun 2005 21:30:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5417XLO021811; Fri, 3 Jun 2005 18:07:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5417XEg021810; Fri, 3 Jun 2005 18:07:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5417XJd021798 for ; Fri, 3 Jun 2005 18:07:33 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from SJC-Office-DHCP-156.Mail-Abuse.ORG (SJC-Office-DHCP-156.Mail-Abuse.ORG [168.61.10.156]) by harry.mail-abuse.org (Postfix) with ESMTP id 1BF59414EE; Fri, 3 Jun 2005 18:07:28 -0700 (PDT) Subject: Re: draft-schlitt-spf-classic-01.txt From: Douglas Otis To: Alan DeKok Cc: ietf-mxcomp@imc.org In-Reply-To: <20050603212654.7FB8216DD6@mail.nitros9.org> References: <20050603212654.7FB8216DD6@mail.nitros9.org> Content-Type: text/plain Date: Fri, 03 Jun 2005 18:07:27 -0700 Message-Id: <1117847247.7562.239.camel@SJC-Office-DHCP-156.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2005-06-03 at 17:26 -0400, Alan DeKok wrote: > Douglas Otis wrote: > > Going down the list of identifies available that could isolate security > > and abuse issues to the accountable administrator, it would be: > > - IP Address > > - Authenticated HELO Name > > - Validated Signatures > > > > You will notice that the mailbox-domain is not in this list. > > Not everyone agrees. > > I have vanity domains where I'm the only person with mailboxes at > the domain. I *am* the accountable administrator for that domain, and > I would like to be able to state so. I would like to be able to say > publicly that any message not from me, using mailboxes at my domain, > is forged. > > Some proposals allow me to do that. The original purpose behind RMX > was exactly that: Hadmut had a vanity domain, and couldn't stop people > from forging messages using that name. Hadmut was also very clear > that not everyone would want to use RMX, but the people who would use > it could protect themselves. > > The response then, as now, is that there is absolute opposition to > such proposals. The requirement that we permit ".forward" style MTA's > to use third-party domain names is a requirement that people like > Hadmut and myself cannot prevent others from forging spam using our > names. Those accruing reputations based upon evidence of abuse, have no way to know whether the message was carried over a shared MTA or not, and in the case of SPF version 1, whether the sender expected the bounce-address or the PRA be used as a basis for acceptance. If SPF were used just to reject messages from unauthorized servers, which is rarely the case due to path registration problems, indeed there would be far less risk involved when publishing SPF records. While some domain owners may run their own MTA and permit just their domain to utilize the MTAs that carry their outbound messages, this would not represent a typical case. The outright blocking of messages from unauthorized servers is often not practical either. There will always be cases where email is lost or refused, when attempting to create such strict path registrations. Lost messages can be problematic whether for financial institutions or large network providers. Recipients are left using a filtering paradigm that attempts to establish acceptance thresholds for the multiple levels of authorization presented by SPF. The additional lowered levels of authorization attempt to convey the likelihood a sender conforms to path registration. Of course, there is no way to accommodate any forwarding that may process their message. While not everyone may agree, strict server authorizations and exclusive MTAs represent special cases. Even these special cases offer little benefit in terms of phishing prevention. The recipients willing to dredge through often extensive path registrations, would be hard pressed to realize a benefit, when the majority of messages reference open-ended records, and no reputation is accrued. There is the danger. With SPF, corner cases will likely find themselves in the junk folder, and those that permit exceptions with open-ended records, may also find their reputation damaged. Those that share an MTA may also find their reputation damaged and should demand indemnification from their provider. > > This mailbox-domain identity is passed from MTA to MTA, and is > > unrelated to an accountable administrator. > > Ah, yes. If we assume the current behavior is desired, then the > conclusions are foregone. > > If, on the other had, we have the temerity to question the existing > assumptions, then the conclusions are questionable, too. When today's systems are able to digitally sign messages without requiring additional hardware, and can do so in the time needed to dredge through path registrations, you should question schemes that require wrenching changes to decades old and highly pervasive architectures. With signatures, you do not need your email provider to swear they make mailbox-domain restrictions. Path registration and mailbox-domain restrictions create a very bad premise for basing a new reputation scheme. This premise suffers two very serious flaws. It often fails to identify the accountable administrator, while at the same time expects the administrator to impose additional expensive limitations on the use of mailbox-domains. At least warn the domain owner to ensure domain restrictions are in place by the provider before publishing SPF records. > > SPF or Sender-ID also makes a false assumption that the MTA is not > > shared, or that the MTA administrator ensures user/mailbox-domain > > relationships are protected. > > SPF and related proposals allow the DNS administrator to claim that > the MTA satisfies certain criteria. But this benefit is being turned > around, and claimed to be an accidental, and negative side-effect. There is nothing provided by SPF that indicates whether 1 or 1000 domains use an MTA or whether any mailbox-domain was initially checked for that matter. > > I have yet to hear anyone caution domain-owners they should first become > > indemnified in their provider's SLA, and be assured only their messages > > are permitted to use their domain in the bounce-address > > For me, it isn't so much about permission as audit trail. If I > can't prove a particular message using a mailbox address is actually > associated with that address, then I have no idea if the message is > forged or not. Signatures don't help, as anyone can create a > certificate or key for any identity they want. Either path registration or a key from DNS do not add any new identity abstractions. Not just anyone can create the path registration for the domain. Not just anyone can create a key for the domain. Signatures, unlike path registration, do not depend upon knowing beforehand the path a message eventually takes, and hence will not break current email architectures. Unlike path registration, the private portion of the key is not exposed, which provides the possibility for a stronger audit trail, than that available with path registration. The key itself could be used to sign prior keys, as example. Of course, this is similar to DNSsec. > What matters is the "web of trust", or the relationship. Signatures > *can* help if the certificate for "user@example.com" is signed by the > key for "example.com", and the key for "example.com" is signed by a > known CA. In that case, the signatures are a means to an end, not a > solution in themselves. They make the relationship management easy > and reliable, nothing more. While a CA would offer improved security, as would DNSsec for that matter, DKIM relies upon the security of DNS the same as SPF does. I attempted to illustrate how doing non-recursive key lookups could be used to establish a key audit, as an interim solution for DNSsec. I doubt such scheme will be employed, unless some exploit makes such auditing required. I described it in the draft-otis-mass-reputation-01.txt draft to improve the chances this concept would be available if needed. -Doug From owner-ietf-mxcomp@mail.imc.org Sat Jun 4 00:10:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10651 for ; Sat, 4 Jun 2005 00:10:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j543ax8G030618; Fri, 3 Jun 2005 20:36:59 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j543axX6030617; Fri, 3 Jun 2005 20:36:59 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j543avgZ030610 for ; Fri, 3 Jun 2005 20:36:58 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DePPS-0001fk-Ea for ietf-mxcomp@imc.org; Sat, 04 Jun 2005 05:33:18 +0200 Received: from 62.80.58.82 ([62.80.58.82]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 04 Jun 2005 05:33:18 +0200 Received: from nobody by 62.80.58.82 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 04 Jun 2005 05:33:18 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: draft-schlitt-spf-classic-01.txt Date: Sat, 04 Jun 2005 05:34:27 +0200 Organization: Lines: 27 Message-ID: <42A12143.6E2@xyzzy.claranet.de> References: <20050603212654.7FB8216DD6@mail.nitros9.org> <1117847247.7562.239.camel@SJC-Office-DHCP-156.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: 62.80.58.82 X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Douglas Otis wrote: > in the case of SPF version 1, whether the sender expected the > bounce-address or the PRA be used as a basis for acceptance __ / \ | | |\____/| ( ) | | | | | | __ ( (--) ) __ / -- \ | |/ -- \ _ | \| | \/ - \ | | | | \ / | | | | | / | | ( \ | \ \ | / | \ \ | / | \ | / | | \ / | | | | From owner-ietf-mxcomp@mail.imc.org Sat Jun 4 09:33:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01807 for ; Sat, 4 Jun 2005 09:33:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j54D9ZZ5012866; Sat, 4 Jun 2005 06:09:35 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j54D9Zwu012865; Sat, 4 Jun 2005 06:09:35 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j54D9ZHo012855 for ; Sat, 4 Jun 2005 06:09:35 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from [192.168.2.11] (64-142-13-68.dsl.static.sonic.net [64.142.13.68]) (authenticated bits=0) by b.mail.sonic.net (8.13.3/8.13.3) with ESMTP id j54D9X7t012560 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 4 Jun 2005 06:09:34 -0700 Subject: Re: draft-schlitt-spf-classic-01.txt From: Douglas Otis To: Frank Ellermann Cc: ietf-mxcomp@imc.org In-Reply-To: <42A12143.6E2@xyzzy.claranet.de> References: <20050603212654.7FB8216DD6@mail.nitros9.org> <1117847247.7562.239.camel@SJC-Office-DHCP-156.mail-abuse.org> <42A12143.6E2@xyzzy.claranet.de> Content-Type: text/plain Date: Sat, 04 Jun 2005 06:09:33 -0700 Message-Id: <1117890573.4942.61.camel@bash.adsl-64-142-13-68> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sat, 2005-06-04 at 05:34 +0200, Frank Ellermann wrote: > Douglas Otis wrote: > > > in the case of SPF version 1, whether the sender expected the > > bounce-address or the PRA be used as a basis for acceptance Who is really most deserving of this eloquent message? Care to comment on this message? http://www.imc.org/ietf-mxcomp/mail-archive/msg05502.html Or, how about this message? http://www.imc.org/ietf-mxcomp/mail-archive/msg05572.html You are ignoring a reality that Microsoft has usurped the definition of the v=spf1 record and clearly has this record in their pocket. This is evidenced by their clout at various email conferences. The "bounce- address" and not "PRA" version of SPF must be defined by the version 2 record. The sooner SPF advocates accept this, the greater the chances SPF will not morph into Sender-ID by way of a reputation trap. -Doug From owner-ietf-mxcomp@mail.imc.org Sat Jun 4 11:57:25 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12591 for ; Sat, 4 Jun 2005 11:57:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j54FZdDF022790; Sat, 4 Jun 2005 08:35:39 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j54FZdpj022789; Sat, 4 Jun 2005 08:35:39 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j54FZaSs022778 for ; Sat, 4 Jun 2005 08:35:38 -0700 (PDT) (envelope-from dean@av8.com) Received: from dakota.av8.net (dakota.av8.net [130.105.19.131]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id j54FZV72023149 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 4 Jun 2005 11:35:35 -0400 Date: Sat, 4 Jun 2005 11:35:30 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: Alan DeKok cc: ietf-mxcomp@imc.org Subject: Re: draft-schlitt-spf-classic-01.txt In-Reply-To: <20050603212654.7FB8216DD6@mail.nitros9.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: On Fri, 3 Jun 2005, Alan DeKok wrote: > I have vanity domains where I'm the only person with mailboxes at > the domain. I *am* the accountable administrator for that domain, and > I would like to be able to state so. I would like to be able to say > publicly that any message not from me, using mailboxes at my domain, > is forged. And just what benefit is there to being able to do this? I too, have pet peevs: I would like cats to use the toilet--I am sure there is benefit to that. But I am not so sure it would be worth millions of dollars and the significant additional harms such as are involved with SPF. Abuse targeted at one particular domain is enabled by SPF in spades---its called 100% blowback. Alan, you've been subjected to significant mail abuse in the past. I understand that you'd like to prevent mail abuse. But this abuse isn't spam, and SPF won't solve the problem of people trying to mailbomb you: SPF makes it worse. You will get mailbombed by 's mail servers sending you bounces. This is called blowback. It happens a little bit whenever mail is forged. SPF can make it happen 100%. It would be impractical to block 's mailservers, so the SPF blowback problem is much worse. In your case (and in many cases of email forgery), the mail is forged in order to generate hate mail and otherwise annoy you. __You__ are the target. __You__ are being harrassed. Unfortunately, there is no technical way for you to stop your harrasser's from harrassing you. It you take away one toy, they will use another. In this case, you are giving them a new toy that is much worse because it is easier to abuse, generates more abuse per message, and is harder to prevent abuse. I am writing a paper on why SPF is fatally flawed, since its proponents haven't yet addressed or even acknowledged the analysis and flaws previously raised on IETF MARID working group---and since I've also recently learned that they have been spreading false rumors about 'why things did not progress at the IETF MARID working group.' They've been apparently been telling people that there aren't any technical problems with SPF, and that things did not progress at the IETF for 'non-technical' reasons. --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 Sat Jun 4 13:20:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18267 for ; Sat, 4 Jun 2005 13:20:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j54GuuVJ028235; Sat, 4 Jun 2005 09:56:56 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j54Guu0v028234; Sat, 4 Jun 2005 09:56:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j54GutTP028225 for ; Sat, 4 Jun 2005 09:56:55 -0700 (PDT) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id F3CA316DD6 for ; Sat, 4 Jun 2005 12:55:32 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: draft-schlitt-spf-classic-01.txt In-Reply-To: Your message of "Sat, 04 Jun 2005 11:35:30 EDT." Date: Sat, 04 Jun 2005 12:55:32 -0400 Message-Id: <20050604165533.F3CA316DD6@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dean Anderson wrote: > > I would like to be able to say > > publicly that any message not from me, using mailboxes at my domain, > > is forged. > > And just what benefit is there to being able to do this? I thought I had explained. What part of my message was unclear? > Alan, you've been subjected to significant mail abuse in the past. I > understand that you'd like to prevent mail abuse. But this abuse isn't > spam, You've been saying that for a number of years now, and during that time, have had access to zero pieces of data from my domain. I've had others[1] look at the evidence, and I've looked at it myself. No one agrees with your assertions. Not one. Your position is based on something called "faith", not "reality". I'm not saying this to convince you, because I know I can't. I'm saying it to explain to everyone else reading this that your position is not one to be taken seriously. > In your case (and in many cases of email forgery), the mail is > forged in order to generate hate mail and otherwise annoy you. How do you know the mind of the spammers? Are you in contact with them? Alan DeKok. [1] i.e. multiple people with long-term experience in the anti-spam community, who've looked at 10^4 source IP's, 10^5 fake addresses "at" my domain on spam CD's, 10^6 connection attempts, and/or 10^8 delivered messages. No one agrees with you. Not one. Most do agree, however, that I probably have the worst spam problem in the world. From owner-ietf-mxcomp@mail.imc.org Mon Jun 6 15:36:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02143 for ; Mon, 6 Jun 2005 15:36:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j56J0uON059576; Mon, 6 Jun 2005 12:00:56 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j56J0urM059574; Mon, 6 Jun 2005 12:00:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j56J0rnw059559 for ; Mon, 6 Jun 2005 12:00:55 -0700 (PDT) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id C268E16DD6 for ; Mon, 6 Jun 2005 14:59:29 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: draft-schlitt-spf-classic-01.txt In-Reply-To: Your message of "Fri, 03 Jun 2005 18:07:27 PDT." <1117847247.7562.239.camel@SJC-Office-DHCP-156.mail-abuse.org> Date: Mon, 06 Jun 2005 14:59:29 -0400 Message-Id: <20050606185929.C268E16DD6@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Douglas Otis wrote: > If SPF were used just to reject messages from unauthorized servers, > which is rarely the case due to path registration problems, indeed > there would be far less risk involved when publishing SPF records. So... why do "path registration" at all? I'm still confused as to why it's OK for people I've never heard of to send messages using my mailbox address. When I send messages, my outgoing MTA looks up the MX record for the domain of the destination mailbox, and sends the message to the specified MTA. Where's the path? If we had provable senders, and signed messages, then the path problem would disappear. If the transport layer, and application message layer are both signed and accountable, then any MTA should be able to transfer messages for any other MTA, and path problems become moot. > There is nothing provided by SPF that indicates whether 1 or 1000 > domains use an MTA or whether any mailbox-domain was initially checked > for that matter. Is that a problem? Publishing SPF records indicates that the domain owner accepts accountabilty for the behavior of the MTA. Who cares if the MTA has another 10^6 domains, or is run by a , or by a convict, or is in Iraq? The domain owner states the MTA is accountable, so therefore it is. This objection to SPF looks a lot like an objection to *permitting* the domain owner to make such statements. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Mon Jun 6 22:12:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15313 for ; Mon, 6 Jun 2005 22:12:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j571irXd090706; Mon, 6 Jun 2005 18:44:53 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j571ir8K090705; Mon, 6 Jun 2005 18:44:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j571irZX090696 for ; Mon, 6 Jun 2005 18:44:53 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from SJC-Office-DHCP-156.Mail-Abuse.ORG (SJC-Office-DHCP-156.Mail-Abuse.ORG [168.61.10.156]) by harry.mail-abuse.org (Postfix) with ESMTP id 6A424414F3; Mon, 6 Jun 2005 18:44:51 -0700 (PDT) Subject: Re: draft-schlitt-spf-classic-01.txt From: Douglas Otis To: Alan DeKok Cc: ietf-mxcomp@imc.org In-Reply-To: <20050606185929.C268E16DD6@mail.nitros9.org> References: <20050606185929.C268E16DD6@mail.nitros9.org> Content-Type: text/plain Date: Mon, 06 Jun 2005 18:44:51 -0700 Message-Id: <1118108691.29088.49.camel@SJC-Office-DHCP-156.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 2005-06-06 at 14:59 -0400, Alan DeKok wrote: > Douglas Otis wrote: > > If SPF were used just to reject messages from unauthorized servers, > > which is rarely the case due to path registration problems, indeed > > there would be far less risk involved when publishing SPF records. > > So... why do "path registration" at all? I'm still confused as to > why it's OK for people I've never heard of to send messages using my > mailbox address. Excellent questions. > When I send messages, my outgoing MTA looks up the MX record for the > domain of the destination mailbox, and sends the message to the > specified MTA. Where's the path? The possible network addresses of where a message can be delivered for a specific domain may only be partially resolved in an MX lookup process. Once a valid network address has been discovered, immediate delivery would normally be to that network address. Once delivered, the message may then be passed on to several other locations, before arriving at a mailbox destination. Often you can not know this path, nor would you normally care. For some organizations, the outbound network address used to send addresses may be unknown, which is the portion of the path that SPF attempts to register. Organization may sub-contract services, and these often evolve frequently. For some organizations, the complexity of their email infrastructure is not readily accommodated in the 100+ DNS records allotted by SPF. > If we had provable senders, and signed messages, then the path > problem would disappear. If the transport layer, and application > message layer are both signed and accountable, then any MTA should be > able to transfer messages for any other MTA, and path problems become > moot. To some extent you would be correct. There is still a need to protect network resources, and this entails something other than a signature. Protection requires authentication, or the integrity of the network resource protection scheme would prove unsafe and unfair. With email, only the remote IP address or the HELO offers specific confirmation of an actual source of a message. Authorization can not be safely used to infer the source of the message. > > There is nothing provided by SPF that indicates whether 1 or 1000 > > domains use an MTA or whether any mailbox-domain was initially checked > > for that matter. > > Is that a problem? Publishing SPF records indicates that the domain > owner accepts accountability for the behavior of the MTA. Who cares if > the MTA has another 10^6 domains, or is run by a > , or by a convict, or is in Iraq? The domain > owner states the MTA is accountable, so therefore it is. While the domain owner will surely suffer the results of an MTA administrator's lack of diligence, I would not expect any domain owner has accepted this accountability. I have heard time and time again, admonishments that domain owners should ignore concerns in this regard. SPF somehow magically protects them. A shamefully false statement of course. There is even the matter of defining what being diligent entails. Should the MTA administrator ensure exclusive use of the bounce-address or does this also include the PRA. There is no warning about publishing an SPF record that includes the PRA scope. The suggested dummy PRA record by Sender-ID has already been declared to have limited value in the future. What then? > This objection to SPF looks a lot like an objection to *permitting* > the domain owner to make such statements. The publishing of these records should include a disclosure as to the potential negative impact this record may have with the domain's reputation. It should describe what actions are needed by the provider, to ensure the domain owner's protection in the all to common case of shared MTAs. Importantly, there should be a way to use the SPF record that clearly indicates what is being assured by the domain owner. The lack of consensus regarding the version 1 record makes excluding the use PRA impossible. Depreciate the use of Version 1 and express the scopes found in version 2. This would permit a means to positively exclude the use of the PRA. I also see value in being able to exclude the use of any scope, to permit this record be used for white-listing only, for example. -Doug From owner-ietf-mxcomp@mail.imc.org Tue Jun 7 12:21:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07426 for ; Tue, 7 Jun 2005 12:21:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j57FtgpN006472; Tue, 7 Jun 2005 08:55:42 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j57FtfZi006471; Tue, 7 Jun 2005 08:55:41 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j57Ftcjr006461 for ; Tue, 7 Jun 2005 08:55:38 -0700 (PDT) (envelope-from dean@av8.com) Received: from dakota.av8.net (dakota.av8.net [130.105.19.131]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id j57FtTx7013714 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 7 Jun 2005 11:55:36 -0400 Date: Tue, 7 Jun 2005 11:55:27 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: Alan DeKok cc: ietf-mxcomp@imc.org Subject: Re: draft-schlitt-spf-classic-01.txt In-Reply-To: <20050606185929.C268E16DD6@mail.nitros9.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: On Mon, 6 Jun 2005, Alan DeKok wrote: > I'm still confused as to why it's OK for people I've never heard of to > send messages using my mailbox address. This is a fallacy of false choice. Its the equivalent of asking if you've stopped beating your wife yet. The question seems to permit two choices (yes, you have, and implies you did before; or no, you haven't yet stopped beating your wife) Its a fallacy because there are additional possibilities. The false choice here is that if we don't approve SPF, we choose to permit people you've never heard of send messages using your mailbox address. There is no such choice: SPF doesn't prevent anyone from doing that. Lets try non-fallacy arguments. --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 Tue Jun 7 12:27:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08009 for ; Tue, 7 Jun 2005 12:27:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j57G2F4E006994; Tue, 7 Jun 2005 09:02:15 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j57G2FE6006993; Tue, 7 Jun 2005 09:02:15 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j57G2B0o006985 for ; Tue, 7 Jun 2005 09:02:12 -0700 (PDT) (envelope-from dean@av8.com) Received: from dakota.av8.net (dakota.av8.net [130.105.19.131]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id j57G23eX013811 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 7 Jun 2005 12:02:09 -0400 Date: Tue, 7 Jun 2005 12:02:00 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: Alan DeKok cc: ietf-mxcomp@imc.org Subject: Re: draft-schlitt-spf-classic-01.txt In-Reply-To: <20050604165533.F3CA316DD6@mail.nitros9.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: On Sat, 4 Jun 2005, Alan DeKok wrote: > > Dean Anderson wrote: > > > I would like to be able to say > > > publicly that any message not from me, using mailboxes at my domain, > > > is forged. > > > > And just what benefit is there to being able to do this? > > I thought I had explained. What part of my message was unclear? > > > Alan, you've been subjected to significant mail abuse in the past. I > > understand that you'd like to prevent mail abuse. But this abuse isn't > > spam, > > You've been saying that for a number of years now, and during that > time, have had access to zero pieces of data from my domain. Partly true. I have seen your mail statistics that you posted to the freeradius list. However, you did not take me up on my offer to assist you with those attacks, which included setting up an MX forwarder to screen (and analyze) abuse. > I've had others[1] look at the evidence, and I've looked at it > myself. No one agrees with your assertions. > > Not one. Its not credible to claim that a 10Mbs ethernet connection would be saturated with email (as you reported), to a one-person domain, and that this volume not be abuse. Its a common pattern of mailbombing. > Your position is based on something called "faith", not "reality". I think your position is based on something called "willful exaggeration" and its a well documented problem amoung anti-spam zealots. I know some of the "experts" that looked at your abuse, and they have been known previously to be anti-spam zealots, one of which is known to conducted (or supported) abuse of our relays. --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 Tue Jun 7 14:51:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21285 for ; Tue, 7 Jun 2005 14:51:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j57IStQW023923; Tue, 7 Jun 2005 11:28:55 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j57IStHj023922; Tue, 7 Jun 2005 11:28:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j57ISqvO023913 for ; Tue, 7 Jun 2005 11:28:55 -0700 (PDT) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id C0667170A2 for ; Tue, 7 Jun 2005 14:27:36 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: draft-schlitt-spf-classic-01.txt In-Reply-To: Your message of "Tue, 07 Jun 2005 12:02:00 EDT." Date: Tue, 07 Jun 2005 14:27:36 -0400 Message-Id: <20050607182736.C0667170A2@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dean Anderson wrote: > Its not credible to claim that a 10Mbs ethernet connection would be > saturated with email (as you reported) My machine has never had had a 10Mbs connection to the net. > to a one-person domain, and that this volume not be abuse. You're assuming that the people buying the "100 million email" spam CD's know it's a one-person domain. > I think your position is based on something called "willful exaggeration" You haven't seen the data, so I must be exaggerating. > I know some of the "experts" that looked at your abuse, and they have been > known previously to be anti-spam zealots, one of which is known to > conducted (or supported) abuse of our relays. I've never made that list public, and to the best of my knowledge, neither have they. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Tue Jun 7 14:56:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21654 for ; Tue, 7 Jun 2005 14:56:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j57IUIES024103; Tue, 7 Jun 2005 11:30:18 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j57IUIes024102; Tue, 7 Jun 2005 11:30:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j57IUIQC024096 for ; Tue, 7 Jun 2005 11:30:18 -0700 (PDT) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 87E2716D00 for ; Tue, 7 Jun 2005 14:29:02 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: draft-schlitt-spf-classic-01.txt In-Reply-To: Your message of "Tue, 07 Jun 2005 11:55:27 EDT." Date: Tue, 07 Jun 2005 14:29:02 -0400 Message-Id: <20050607182902.87E2716D00@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dean Anderson wrote: > The false choice here is that if we don't approve SPF, we choose to permit > people you've never heard of send messages using your mailbox address. > There is no such choice: SPF doesn't prevent anyone from doing that. > > Lets try non-fallacy arguments. Where in the question you quoted did I mention SPF? I've looked, and for the life of me, I can't find it. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Tue Jun 7 18:52:14 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21874 for ; Tue, 7 Jun 2005 18:52:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j57MMIH8042991; Tue, 7 Jun 2005 15:22:18 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j57MMIuO042990; Tue, 7 Jun 2005 15:22:18 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j57MMER7042980 for ; Tue, 7 Jun 2005 15:22:15 -0700 (PDT) (envelope-from dean@av8.com) Received: from dakota.av8.net (dakota.av8.net [130.105.19.131]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id j57MM7sq020664 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 7 Jun 2005 18:22:13 -0400 Date: Tue, 7 Jun 2005 18:22:06 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: Alan DeKok cc: ietf-mxcomp@imc.org Subject: Re: draft-schlitt-spf-classic-01.txt In-Reply-To: <20050607182736.C0667170A2@mail.nitros9.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: On Tue, 7 Jun 2005, Alan DeKok wrote: > > Dean Anderson wrote: > > Its not credible to claim that a 10Mbs ethernet connection would be > > saturated with email (as you reported) > > My machine has never had had a 10Mbs connection to the net. Your attempts at being coy are rather unbecoming. Please be honest. You rported on freeradius that your machine used to have colo'd ethernet connection. You reported on freeradius that your colo ISP asked you to find service elsewhere because of your spam volume was saturating the ethernet. [BTW, that alone should tell you that it isn't "normal" spam volume] > > to a one-person domain, and that this volume not be abuse. > > You're assuming that the people buying the "100 million email" spam > CD's know it's a one-person domain. The addresses have to find their way onto such cd's. If you start getting mail like you have a million subscribers, then probably something is wrong, because that doesn't usually happen. The cd creators would seem to have no interest in putting fake addresses on the CD. [They would plainly have interest in harvesting addresses, but that doesn't usually result in thousands or millions of fake recipient addresses to a one person domain] So either someone must have somehow fooled them into thinking you have millions of subscribers, or perhaps _they_ have something against you. But you (and your "experts") are the _only_ case of a one-person domain that I've ever heard of, that gets this much email and subsequently argues that it was somehow "normal". What I _suspect_ is that one of the following is the truth: you were either playing with harvesting, and got burned, or someone else was playing with harvesting to burn you, or someone used a list of open relays or proxies to mailbomb you. What I _know_ [from your posted statistics and reported info] is that it was not an ordinary sort of spam load, as you (and your "experts") have claimed. And I _know_ that some of your "experts" were either involved with, or at least supportive of those who abused open relays. Further, as I recall, it stopped eventually, and was intermittent. > > I think your position is based on something called "willful exaggeration" > > You haven't seen the data, so I must be exaggerating. I have some of the statistics, so yes. it is quite possible to draw conclusions without the raw data. [that is why they call it data reduction] Unless, of course, you lied in the statistics you reported. But if you want to send me the raw data, I'll still take a look... You shared it with others, and it is all yours, so its up to you. This isn't the first time for such a statisical surprise. Operators have previously been surprised before what can be inferred with indirect, remote telemetry and statistics. The distance to a star, for example. And no one has ever seen an atom, either. All surprises. Indeed, A certain network operator I know (Nathan Mehl) is _still_ stunned about an incident that happened way back in _1994_, where I determined his news server was overloaded by looking at the times on packets. He had first denied it was overloaded, and blamed the problem on our connection. He was quite stunned when I showed him statistics on the connection and timings on the news packets that indicated his server was overloaded. Only then did he finally admit that it was overloaded. And others were also complaining about their servers being overloaded. The problem was solved by adding additional new server. [though he leaves that final admission out of his recent retellings, I have most of the email from 1994, as well as the load statistics. Tapes of home directories are indeed wonderful devices, and properly stored, hold data for a long time. [BTW this will go up on www.iadl.org sometime as an example of selective memory vs defamation: Nathan Mehl was the engineer at BBN Planet. I think it will go under the section on Chris Neill, it compares and contrasts with Chris: Nathan can be somewhat forgiven for misremembering facts from 1994 many years later. In contrast, Chris was reporting right after the event. But neither admits being wrong. [anti-spammers never admit being wrong even conducting abuse like mailbombing] To summarize: Chris Neill was a abuse admin with Verio who abused our relays from his desktop. He was finally fired for this. He wasn't the only abuse admin fired for abuse, but so far as I know, he is the only one who posted a diatribe describing what happened to a public mailing list. But like many, rather than accept responsibility for doing a "bad thing", he blames others (me) for reporting his abuse. They never "remember" being wrong. And indeed, no anti-spammer has ever rebuked him for his abuse. Most are sympathetic: Abuse is OK, so long as its "for the cause". Anti-spammer generated junk mail is euphemistically called "mailbombing"] > > I know some of the "experts" that looked at your abuse, and they have been > > known previously to be anti-spam zealots, one of which is known to > > conducted (or supported) abuse of our relays. > > I've never made that list public, and to the best of my knowledge, > neither have they. I'm sure I don't have the _entire_ list. But Chris Parker of Starnet/Megapop and company seem to be among the ones who said I was wrong on freeradius. Our relays were subsequently abused by hundreds of IPs from Starnet, and when I complained, Parker indicated that he would not act on our complaints because he didn't consider open relay abuse to be abuse. [which is actually consistent with what he told you about your incident] It shows their support for abuse. I think we had to block port 25 from all of starnet's blocks. [And in 2003, when the open relay blacklists shutdown, open relay abuse also stopped. It restarted in March of this, but very, very lamely.] --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 Tue Jun 7 18:52:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21910 for ; Tue, 7 Jun 2005 18:52:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j57MVjFo043596; Tue, 7 Jun 2005 15:31:45 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j57MVj5s043595; Tue, 7 Jun 2005 15:31:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j57MViIp043587 for ; Tue, 7 Jun 2005 15:31:44 -0700 (PDT) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 18FA516DD6 for ; Tue, 7 Jun 2005 18:30:26 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: draft-schlitt-spf-classic-01.txt In-Reply-To: Your message of "Tue, 07 Jun 2005 18:22:06 EDT." Date: Tue, 07 Jun 2005 18:30:26 -0400 Message-Id: <20050607223026.18FA516DD6@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dean Anderson wrote: > You rported on freeradius that your machine used to have colo'd > ethernet connection. You reported on freeradius that your colo ISP > asked you to find service elsewhere because of your spam volume was > saturating the ethernet. You recall incorrectly. > But you (and your "experts") are the _only_ case of a one-person domain > that I've ever heard of, that gets this much email and subsequently argues > that it was somehow "normal". I've never said it was "normal". > What I _know_ [from your posted statistics and reported info] is that it > was not an ordinary sort of spam load, as you (and your "experts") have > claimed. I've never said it was ordinary, and neither have any experts I've talked to. The description I recall is "Holy f*ck!". > Further, as I recall, it stopped eventually, and was intermittent. You recall incorrectly. It was never intermittent, and it hasn't stopped. > [Re: list of anti-spam people who've seen data from my domain ] > > I'm sure I don't have the _entire_ list. But Chris Parker of > Starnet/Megapop and company seem to be among the ones who said I was wrong > on freeradius. Chris Parker has never analyzed spam for my domain. This is fun! Let's do it again. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Tue Jun 7 19:27:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24321 for ; Tue, 7 Jun 2005 19:27:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j57N2Gvd045098; Tue, 7 Jun 2005 16:02:16 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j57N2GU1045097; Tue, 7 Jun 2005 16:02:16 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j57N2FN1045089 for ; Tue, 7 Jun 2005 16:02:15 -0700 (PDT) (envelope-from dean@av8.com) Received: from dakota.av8.net (dakota.av8.net [130.105.19.131]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id j57N2EAB021390 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 7 Jun 2005 19:02:15 -0400 Date: Tue, 7 Jun 2005 19:02:13 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: Alan DeKok cc: ietf-mxcomp@imc.org Subject: Re: draft-schlitt-spf-classic-01.txt In-Reply-To: <20050607182902.87E2716D00@mail.nitros9.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: On Tue, 7 Jun 2005, Alan DeKok wrote: > > Dean Anderson wrote: > > The false choice here is that if we don't approve SPF, we choose to permit > > people you've never heard of send messages using your mailbox address. > > There is no such choice: SPF doesn't prevent anyone from doing that. > > > > Lets try non-fallacy arguments. > > Where in the question you quoted did I mention SPF? I've looked, > and for the life of me, I can't find it. Maybe you missed the title: Re: draft-schlitt-spf-classic-01.txt -- 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 Tue Jun 7 19:29:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24464 for ; Tue, 7 Jun 2005 19:29:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j57N1prV045063; Tue, 7 Jun 2005 16:01:51 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j57N1pUl045062; Tue, 7 Jun 2005 16:01:51 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j57N1nI4045056 for ; Tue, 7 Jun 2005 16:01:50 -0700 (PDT) (envelope-from dean@av8.com) Received: from dakota.av8.net (dakota.av8.net [130.105.19.131]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id j57N1mhr021387 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 7 Jun 2005 19:01:49 -0400 Date: Tue, 7 Jun 2005 19:01:47 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: Alan DeKok cc: ietf-mxcomp@imc.org Subject: Re: draft-schlitt-spf-classic-01.txt In-Reply-To: <20050604165533.F3CA316DD6@mail.nitros9.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: On Sat, 4 Jun 2005, Alan DeKok wrote: > > > In your case (and in many cases of email forgery), the mail is > > forged in order to generate hate mail and otherwise annoy you. > > How do you know the mind of the spammers? Are you in contact with them? How do economists figure out the purposes and principles of business? Observation and analysis. It doesn't take rocket science to figure it out. http://www.av8.net/SpamTypes.txt Your spam isn't type 1. It isn't type 2. Wait, Type 3 seems to fit pretty well. Type 1 Commercial spammers have anonymous .be or .nu domains, which prevent return mailbombing. Or they use their own domain. They don't need to forge your address in the "From:" field. They want you to buy their product. They comply with CAN-SPAM and don't forge addresses. Type 2 Fraudsters want people to respond so they can conduct the fraud. They don't need to forge your address, that would hurt the fraud. They send out messages, hoping for response. The from address is real. It may be stolen, but its real, until, perhaps it is turned off in response. Type 3 abusers are trying to conduct some type of annoyance or extortion or infection. They want you to get hate mail, they want to annoy you. Or they want to infect people you know with viruses. They want people to think the mail came from you or at least from your domain. That is the point. They can't comply with CAN-SPAM, as they aren't real businesses. This distinguishes pure abusers from commercial bulk emailers, which is what the DMA set out to do with CAN-SPAM. And CAN-SPAM has been very successful at demonstrating that. --Dean [and yes, I'm aware that many anti-spammers think that CAN-SPAM has been a dismal failure. And it has certainly been a blow to their claims and their world view. But its been a success for the DMA. The anti-spammers were wrong when they rejected the IEMCC proposal in 1997. Probably, it is anti-spammers that are generating much of the type 3 abuse---anti-spammers were generating the open relay abuse, and that was very similar in characteristic to the current type 3 abuse.] -- 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 Tue Jun 7 19:57:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29347 for ; Tue, 7 Jun 2005 19:57:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j57NQAKm047160; Tue, 7 Jun 2005 16:26:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j57NQAHB047159; Tue, 7 Jun 2005 16:26:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j57NQ9Eb047153 for ; Tue, 7 Jun 2005 16:26:09 -0700 (PDT) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 6FEC116D00 for ; Tue, 7 Jun 2005 19:24:53 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Philosophical discussions (was Re: draft-schlitt-spf-classic-01.txt ) In-Reply-To: Your message of "Mon, 06 Jun 2005 18:44:51 PDT." <1118108691.29088.49.camel@SJC-Office-DHCP-156.mail-abuse.org> Date: Tue, 07 Jun 2005 19:24:53 -0400 Message-Id: <20050607232453.6FEC116D00@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Douglas Otis wrote: > The possible network addresses of where a message can be delivered for a > specific domain may only be partially resolved in an MX lookup process. > Once a valid network address has been discovered, immediate delivery > would normally be to that network address. Once delivered, the message > may then be passed on to several other locations, before arriving at a > mailbox destination. Often you can not know this path, nor would you > normally care. But if I deliver a message to the MX that is authoritative for the domain of the mailbox, the message is *delivered*. It's *done*. You're assuming that *my* message gets forwarded *from* the domain I sent it to, and that it's still marked as *my* message. If it does, I don't see why it's labelled as "my" message. The historical approach to label it that way is nice historically, but there appear to be some kind of abuse issues associated with it... > While the domain owner will surely suffer the results of an MTA > administrator's lack of diligence, I would not expect any domain owner > has accepted this accountability. I have heard time and time again, > admonishments that domain owners should ignore concerns in this regard. > SPF somehow magically protects them. A shamefully false statement of > course. Sure. But if they choose to accept that accountability, isn't that their choice? > The suggested dummy PRA record by Sender-ID has already been > declared to have limited value in the future. What then? They can use a proposal that doesn't have problems. > The publishing of these records should include a disclosure as to the > potential negative impact this record may have with the domain's > reputation. It should describe what actions are needed by the provider, > to ensure the domain owner's protection in the all to common case of > shared MTAs. That's a matter for the documentation of the proposal, not for it's implementation. > Importantly, there should be a way to use the SPF record that clearly > indicates what is being assured by the domain owner. Of course. Any similar system should have similar assurances. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Tue Jun 7 21:52:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07560 for ; Tue, 7 Jun 2005 21:52:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j581N68S054708; Tue, 7 Jun 2005 18:23:06 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j581N6xe054707; Tue, 7 Jun 2005 18:23:06 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j581N3lF054688 for ; Tue, 7 Jun 2005 18:23:04 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DfpDI-0004vB-Ec for ietf-mxcomp@imc.org; Wed, 08 Jun 2005 03:18:36 +0200 Received: from du-001-163.access.de.clara.net ([212.82.227.163]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 08 Jun 2005 03:18:36 +0200 Received: from nobody by du-001-163.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 08 Jun 2005 03:18:36 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: Philosophical discussions Date: Wed, 08 Jun 2005 03:18:16 +0200 Organization: Lines: 58 Message-ID: <42A64758.6379@xyzzy.claranet.de> References: <1118108691.29088.49.camel@SJC-Office-DHCP-156.mail-abuse.org> <20050607232453.6FEC116D00@mail.nitros9.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-163.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: Content-Transfer-Encoding: 7bit Alan DeKok wrote: > if I deliver a message to the MX that is authoritative for > the domain of the mailbox, the message is *delivered*. It's > *done*. "Final delivery" is something different, I'd say "sent" where you say "delivered". > You're assuming that *my* message gets forwarded *from* the > domain I sent it to, and that it's still marked as *my* > message. There's no problem, the MX can be a gateway to some fascinating UUCP forwarding, or forward your mail to an MDA, with several hops, it's all fine and still MAIL FROM you RCPT TO recipient. > If it does, I don't see why it's labelled as "my" message. Here you're talking about a _new_ recipient with _another_ MX. That's of course not more your responsibility, and if there is a technical problem it's definitely not your problem. As soon as another MX of a third party is involved it's the problem of the "original" recipient. He could adjust the MAIL FROM - one of the many ways to deal with his responsibility. > The historical approach to label it that way is nice > historically It is _not_ the historical approach, that's only a legend of the "bounces-to" camp. Historically each forwarding host added its name to the reverse path, MAIL FROM @mx3,@mx2,@mx1:you For obvious reasons that design worked against forged addresses, mx2 and mx1 were not interested to forward any MAIL FROM you if they would have to deal with later bounces to you. That's also the reason why there's a 551 "user not local" code. When they killed the source routes in 1123 they simply "forgot" that this is a security loophole for the 251 alias-style of forwarding - RfC 1123 is 16 years old, nobody could foresee the disastrous effects of this security loophole in SMTP today. But when you said (in your LMAP memo) that some LMAP proposals _change_ the original _semantics_ of the MAIL FROM this is NOT, repeat NOT, repeat NOT, true. The MAIL FROM _semantics_ is as it always was since STD 10. And SPF simply uses it to fix this security loophole in SMTP today, for those who want it. > if they choose to accept that accountability, isn't that > their choice? Of course. Bye, Frank From owner-ietf-mxcomp@mail.imc.org Tue Jun 7 22:06:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08287 for ; Tue, 7 Jun 2005 22:06:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j581ijJ2056589; Tue, 7 Jun 2005 18:44:45 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j581ijuU056588; Tue, 7 Jun 2005 18:44:45 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j581iiW9056581 for ; Tue, 7 Jun 2005 18:44:44 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DfpYL-0007Mv-95 for ietf-mxcomp@imc.org; Wed, 08 Jun 2005 03:40:21 +0200 Received: from du-001-163.access.de.clara.net ([212.82.227.163]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 08 Jun 2005 03:40:21 +0200 Received: from nobody by du-001-163.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 08 Jun 2005 03:40:21 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: draft-schlitt-spf-classic-02 (was: draft-schlitt-spf-classic-01.txt) Date: Wed, 08 Jun 2005 03:39:42 +0200 Organization: Lines: 65 Message-ID: <42A64C5E.5456@xyzzy.claranet.de> References: <20050603212654.7FB8216DD6@mail.nitros9.org> <1117847247.7562.239.camel@SJC-Office-DHCP-156.mail-abuse.org> <42A12143.6E2@xyzzy.claranet.de> <1117890573.4942.61.camel@bash.adsl-64-142-13-68> 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-163.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: Content-Transfer-Encoding: 7bit Douglas Otis wrote: > Who is really most deserving of this eloquent message? The verbose variant wasn't suited for a mailing list open for the public includinng children. > Care to comment on this message? > http://www.imc.org/ietf-mxcomp/mail-archive/msg05502.html When you say that PRA is incompatible with v=spf1 policies you're right. That is _old_ news, see also Meng's article: Or Wayne's comment about it: > You are ignoring a reality that Microsoft has usurped the > definition of the v=spf1 record and clearly has this record > in their pocket. This is not the case. See below what I'e written to two IESG members, as far as I'm concerned everybody can read it. Some days old, the new draft is now -02 and not more -01, bye, Frank [does draft-lyon-senderid-core-00 obsolete SPF version 1 ?] No, it is only trying to use several hundred thousands published v=spf1 policies for the similar spf2.0 scheme. These schemes are partially incompatible. The PRA is not necessarily related to the MAIL FROm, that's why MARID first decided to introduce spf2.0/pra, later adding spf2.0/mfrom - the latter is compatible with v=spf1. After MARID was closed the SPF community resumed its work on v=spf1, resulting in the drafts from Mark Lentczner and later Wayne Schlitt. The Schlitt drafts clearly say that testing v=spf1 policies with something they were never designed for (like the PRA algorithm) is NOT RECOMMENDED. It can result in loss of legit mail. This issue has been discussed on many lists (spf-discuss, MARID, IETF general, etc.). The new Schlitt draft -01 (published yesterday) explains the issue with the NOT RECOMMENDED better. The new wording should make it clear that of course using the PRA algorithm with any spf2.0/pra policy is no problem - actually almost nobody in the SPF community cares about the PRA. But using PRA with v=spf1 will cause havoc. I'm surprised why there was a note to the RfC editor proposing to remove the old NOT RECOMMENDED from the old Schlitt draft -00, while there was no note to remove the SHOULD from draft Lyon -00: | SHOULD interpret the version prefix "v=spf1" as equivalent to | "spf2.0/mfrom,pra" This is plain wrong. No v=spf1 policy was designed to survive a PRA test. Many v=spf1 policies were published long before MARID, when Sender-ID was still Caller-ID. A v=spf1 policy is _almost_ equivalent to spf2.0/mfrom (the latter has no HELO check, but it checks MAIL FROM), but it is incompatible with spf2.0/pra. The new draft Lyon -01 still has the same serious technical problem. Bye, Frank From owner-ietf-mxcomp@mail.imc.org Tue Jun 7 22:19:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09714 for ; Tue, 7 Jun 2005 22:19:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j581tIJd057336; Tue, 7 Jun 2005 18:55:18 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j581tItB057335; Tue, 7 Jun 2005 18:55:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j581tImo057329 for ; Tue, 7 Jun 2005 18:55:18 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from SJC-Office-DHCP-156.Mail-Abuse.ORG (SJC-Office-DHCP-156.Mail-Abuse.ORG [168.61.10.156]) by harry.mail-abuse.org (Postfix) with ESMTP id DE18F414F0; Tue, 7 Jun 2005 18:55:17 -0700 (PDT) Subject: Re: Philosophical discussions (was Re: draft-schlitt-spf-classic-01.txt ) From: Douglas Otis To: Alan DeKok Cc: ietf-mxcomp@imc.org In-Reply-To: <20050607232453.6FEC116D00@mail.nitros9.org> References: <20050607232453.6FEC116D00@mail.nitros9.org> Content-Type: text/plain Date: Tue, 07 Jun 2005 18:55:17 -0700 Message-Id: <1118195717.7607.97.camel@SJC-Office-DHCP-156.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 2005-06-07 at 19:24 -0400, Alan DeKok wrote: > Douglas Otis wrote: > > The possible network addresses of where a message can be delivered for a > > specific domain may only be partially resolved in an MX lookup process. > > Once a valid network address has been discovered, immediate delivery > > would normally be to that network address. Once delivered, the message > > may then be passed on to several other locations, before arriving at a > > mailbox destination. Often you can not know this path, nor would you > > normally care. > > But if I deliver a message to the MX that is authoritative for the > domain of the mailbox, the message is *delivered*. It's *done*. > You're assuming that *my* message gets forwarded *from* the domain I > sent it to, and that it's still marked as *my* message. > > If it does, I don't see why it's labeled as "my" message. The > historical approach to label it that way is nice historically, but > there appear to be some kind of abuse issues associated with it... Assume you sent a message to a simple exploding list for example. While you could conclude that once the list server accepted your message, it now becomes the list server's message. From a reputation standpoint, this is not desirable from the perspective of the list operator, who would like any abuse to directly impact those they see as accountable. The abuse that concerns you has to do with how the accountable entity is determined. If the accountable entity is determined by some mailbox-domain having authorized a sending server, then indeed this can lead to failure or abuse, especially when many domains authorize the same sending servers. On the other hand, if the accountable entity is determined by validating a signature using a key published by the sending domain, then any opportunity for this to be abused is dramatically reduced. Assume you send a message to a forwarding account that acts as an alias for the recipient. You consider the message being forwarded, by having the recipient altered on the envelope, to be technically a modified version of your message. Nevertheless, the content of your message remains unaltered. Where a delivery failure notice must be sent also remains unchanged to provide the eventual recipient this essential information. It makes no sense to alter the information that normally gets forwarded to satisfy a flawed scheme that infers the source of a message through server authorization. This is where abuse may occur, as server-authorization being considered equivalent to sender-authentication is a scheme that unfairly makes assumptions of origin. I see no problem having high thresholds on the HELO or IP address of the sending server to form a basis for network protection. I see no problem allowing forwarding or list servers (leaving mail unaltered), and relying upon signature validation to determine accountable entities as a basis for recipient protection. However, there is no reasonable method to base accountability of a message upon the server having been authorized. > > While the domain owner will surely suffer the results of an MTA > > administrator's lack of diligence, I would not expect any domain owner > > has accepted this accountability. I have heard time and time again, > > admonishments that domain owners should ignore concerns in this regard. > > SPF somehow magically protects them. A shamefully false statement of > > course. > > Sure. But if they choose to accept that accountability, isn't that > their choice? In the many presentations I have attended, I have yet to hear any warnings that by publishing an SPF record, the domain owner's reputation may become damaged beyond their control, regardless of the type of list published. I have not heard anything beyond a warning there may be some reputation risk related to publishing an "open-ended" list. Seldom is this explained to mean either risk some messages being lost when forwarded in some fashion, or risk readily obtaining a bad reputation. Of course, even a "close-ended" list can not offer substantial protection from forgery when the MTA is shared. > > The suggested dummy PRA record by Sender-ID has already been > > declared to have limited value in the future. What then? > > They can use a proposal that doesn't have problems. Which proposal is that? It is not draft-schlitt-spf-classic-01, or draft-lyon-senderid-core-01. These two drafts are in serious conflict, and the Sender-ID draft claims that server authorization is equivalent to sender authentication, whether for the bounce-address or the PRA. Do you really think it is safe to ignore the intentions of Microsoft? > > The publishing of these records should include a disclosure as to the > > potential negative impact this record may have with the domain's > > reputation. It should describe what actions are needed by the provider, > > to ensure the domain owner's protection in the all to common case of > > shared MTAs. > > That's a matter for the documentation of the proposal, not for it's > implementation. I hope they consider the outcome of having withheld this information. Class-actions love deep pockets. : ) > > Importantly, there should be a way to use the SPF record that clearly > > indicates what is being assured by the domain owner. > > Of course. Any similar system should have similar assurances. Even by obtaining the record's scope, SPF/Sender-ID assumes email providers are perfect at assuring exclusive use of a mailbox-domain within this scope. Have you seen any indemnification making this claim? This scheme is filled with assumptions and false assurances. If you do not run your own MTA and can assure exclusive access, SPF/Sender-ID is an extremely risky choice. Unless you are willing to have some messages go missing, SPF/Sender-ID is an extremely risky choice. The safer choice is DomainKeys upgraded to DKIM. : ) -Doug From owner-ietf-mxcomp@mail.imc.org Tue Jun 7 22:22:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10001 for ; Tue, 7 Jun 2005 22:22:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j581xuK0057598; Tue, 7 Jun 2005 18:59:56 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j581xudf057597; Tue, 7 Jun 2005 18:59:56 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j581xthI057588 for ; Tue, 7 Jun 2005 18:59:56 -0700 (PDT) (envelope-from dean@av8.com) Received: from dakota.av8.net (dakota.av8.net [130.105.19.131]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id j581xkuM024555 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 7 Jun 2005 21:59:54 -0400 Date: Tue, 7 Jun 2005 21:59:45 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: ietf-mxcomp@imc.org Subject: Re: draft-schlitt-spf-classic-01.txt 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: Alan, I think you misrember. And looking at www.striker.ottawa.on.ca just now, I see you've been subject to reverse ping floods as well. The reverse attacks you describe are most telling. These happen when people send pings with your IP address as the ICMP source IP address. That's why you get people calling up and saying "your machine is attacking me". They just see the source IP address in the ICMP packets. But in fact, those packets originate from the botnet machines. The same ones attacking your SMTP port. Thats what botnets do. Your "spam" problem was first reported in January 2002: +++++++++++++++++++++++++++++++++++++++++++++++++++++++ Date: Wed, 30 Jan 2002 10:53:15 +0000 (UTC) From: Miquel van Smoorenburg Reply-To: freeradius-devel@lists.cistron.nl To: freeradius-devel@lists.cistron.nl, freeradius-users@lists.cistron.nl Subject: Re: Private email to me [ The following text is in the "iso8859-15" character set. ] [ Your display is set for the "ISO-8859-1" character set. ] [ Some characters may be displayed incorrectly. ] In article , wrote: > I am no longer accepting private email to my 'striker.ottawa.on.ca' >domain. For reasons why, see: > > http://www.striker.ottawa.on.ca/ > > The domain is on *all* of the spam lists from what I can tell, and >is receiving 400K+ spam emails a day. Even dropping the connection >after the "RCTP TO", and not accepting the message body, it's still >too much. The spam is using 10Mbytes per HOUR of bandwidth, which I >can't afford. [...] +++++++++++++++++++++++++++++++++++++++++++++++++++++++ This early exchange was significant: +++++++++++++++++++++++++++++++++++++++++++++++++++++++ > So, Alan: Who have you annoyed? Lots of people, I think. I've had the domain since 1996, or so. I've always been vocal and opinionated. +++++++++++++++++++++++++++++++++++++++++++++++++++++++ See http://www.striker.ottawa.on.ca/ Other messages of the time noted that back then this IP was hosted with Ottawa Carleton Unix Corp (AS26227). I see its currently with UUnet. BTW, A medium sized ISP with perhaps 20,000 users receives about 400,000 messages per day (spam and ham). Probably should have a T3 or OC3 for that kind of volume. A medium sized colo center would host several hundred such domains as striker.ottawa.on.ca. A virtual host center would probably have several dozen to perhaps a hundred+ domains on a single machine. Plainly, neither a colo nor virtual host datacenter going to be able to handle 400K PER DAY, PER obscure DOMAIN. It is simply not credible to say that 400K messages per day is normal for an obscure (no offense) one-person domain: Its an attack. There are other ICMP-based attacks on your your personal domain as well. In other messages you describe hundreds or perhaps thousands of hosts doing this. You aren't the first person to experience such attacks. You're just the first person to claim (rather obstinately) that they aren't one (or a few users with a botnet) as this quote of shows: +++++++++++++++++++++++++++++++++++++++++++++++++++++++ And the IP address of *my* machine has changed, along with all of it's upstream providers. The issue *is* really that there are lots of different spammers attacking me. +++++++++++++++++++++++++++++++++++++++++++++++++++++++ While you _insist_ that spammers are just routinely spamming you with an aggregate 400K messages per day, there is no credible reason to think that. Instead, you are tangling with a botnet. See http://grc.com/dos/grcdos.htm for an interesting read on botnet attacks. And yes, they do "spam"/"mailbomb" you. There are successful strategies for dealing with botnet attacks. GRC is one interesting way, reporting abuse is another. Reporting abuse eventually causes them bots, and that causes them to risk getting caught, and causes them to lose resources (in the form of bots). Your way, of trying to pursue anti-spam techniques isn't one of the successful strategies. There is no help for you in SPF. If you get 400K messages per second without SPF, you will still get 400K with SPF. As you pointed out in November, 2002: +++++++++++++++++++++++++++++++++++++++++++++++++++++++ The bandwidth number I quoted in my previous email worked out to ~2-5 gigabytes a month, for: EHLO . . . MAIL FROM: spammer RCTP TO: no-such-user@striker.ottawa.on.ca If the messages had been delivered, the total data transferred would go up by a factor of 10-100 times. +++++++++++++++++++++++++++++++++++++++++++++++++++++++ SPF isn't going to reduce that. Banning spam isn't even going to reduce that: It isn't commercial spammers doing this. In fact, __nothing__ other than tracking down the botnets will reduce that. --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 Tue Jun 7 23:08:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13550 for ; Tue, 7 Jun 2005 23:08:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j582ebnl062295; Tue, 7 Jun 2005 19:40:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j582ebqI062294; Tue, 7 Jun 2005 19:40:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from aismt07p.bellsouth.com (aismt07p.bellsouth.com [139.76.165.213]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j582eaVM062279 for ; Tue, 7 Jun 2005 19:40:36 -0700 (PDT) (envelope-from dean@av8.com) Received: from ([90.152.53.181]) by aismt07p.bellsouth.com with SMTP id KP-AXPTB.43243176; Tue, 07 Jun 2005 22:35:19 -0400 Received: from mail pickup service by 01AL10015010162.ad.bls.com with Microsoft SMTPSVC; Tue, 7 Jun 2005 21:35:18 -0500 Received: from 01al10015010026.ad.bls.com ([90.152.5.102]) by 01AL10015010162.ad.bls.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 7 Jun 2005 21:04:48 -0500 Received: from aismt03p.bellsouth.com ([139.76.165.205]) by 01al10015010026.ad.bls.com (SAVSMTP 3.1.7.47) with SMTP id M2005060721044700684 for ; Tue, 07 Jun 2005 21:04:47 -0500 Received: from ([208.184.76.39]) by aismt03p.bellsouth.com with ESMTP with TLS id KP-AXPNT.58613485; Tue, 07 Jun 2005 22:04:19 -0400 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j581xuK0057598; Tue, 7 Jun 2005 18:59:56 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j581xudf057597; Tue, 7 Jun 2005 18:59:56 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j581xthI057588 for ; Tue, 7 Jun 2005 18:59:56 -0700 (PDT) (envelope-from dean@av8.com) Received: from dakota.av8.net (dakota.av8.net [130.105.19.131]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id j581xkuM024555 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 7 Jun 2005 21:59:54 -0400 Date: Tue, 7 Jun 2005 21:59:45 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: ietf-mxcomp@imc.org Subject: Re: draft-schlitt-spf-classic-01.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Archive: List-Unsubscribe: List-ID: X-esp: ESP<26>=RBL:<0> RDNS:<0> SHA:<26> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> NigeriaScam Dictionary (TRU7):<0> Obscenities Dictionary (TRU7):<0> BellSouth Spam SS:<0> URL Dictionary (TRU7):<0> Embed HTML Dictionary (TRU7):<0> CAN-SPAM Compliance Dictionary (TRU7):<0> Porn Dictionary (TRU7):<0> Spam Dictionary (TRU7):<0> HTML Dictionary (TRU7):<0> X-OriginalArrivalTime: 08 Jun 2005 02:04:48.0039 (UTC) FILETIME=[729F1370:01C56BCE] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Alan, I think you misrember. And looking at www.striker.ottawa.on.ca just now, I see you've been subject to reverse ping floods as well. The reverse attacks you describe are most telling. These happen when people send pings with your IP address as the ICMP source IP address. That's why you get people calling up and saying "your machine is attacking me". They just see the source IP address in the ICMP packets. But in fact, those packets originate from the botnet machines. The same ones attacking your SMTP port. Thats what botnets do. Your "spam" problem was first reported in January 2002: +++++++++++++++++++++++++++++++++++++++++++++++++++++++ Date: Wed, 30 Jan 2002 10:53:15 +0000 (UTC) From: Miquel van Smoorenburg Reply-To: freeradius-devel@lists.cistron.nl To: freeradius-devel@lists.cistron.nl, freeradius-users@lists.cistron.nl Subject: Re: Private email to me [ The following text is in the "iso8859-15" character set. ] [ Your display is set for the "ISO-8859-1" character set. ] [ Some characters may be displayed incorrectly. ] In article , wrote: > I am no longer accepting private email to my 'striker.ottawa.on.ca' >domain. For reasons why, see: > > http://www.striker.ottawa.on.ca/ > > The domain is on *all* of the spam lists from what I can tell, and >is receiving 400K+ spam emails a day. Even dropping the connection >after the "RCTP TO", and not accepting the message body, it's still >too much. The spam is using 10Mbytes per HOUR of bandwidth, which I >can't afford. [...] +++++++++++++++++++++++++++++++++++++++++++++++++++++++ This early exchange was significant: +++++++++++++++++++++++++++++++++++++++++++++++++++++++ > So, Alan: Who have you annoyed? Lots of people, I think. I've had the domain since 1996, or so. I've always been vocal and opinionated. +++++++++++++++++++++++++++++++++++++++++++++++++++++++ See http://www.striker.ottawa.on.ca/ Other messages of the time noted that back then this IP was hosted with Ottawa Carleton Unix Corp (AS26227). I see its currently with UUnet. BTW, A medium sized ISP with perhaps 20,000 users receives about 400,000 messages per day (spam and ham). Probably should have a T3 or OC3 for that kind of volume. A medium sized colo center would host several hundred such domains as striker.ottawa.on.ca. A virtual host center would probably have several dozen to perhaps a hundred+ domains on a single machine. Plainly, neither a colo nor virtual host datacenter going to be able to handle 400K PER DAY, PER obscure DOMAIN. It is simply not credible to say that 400K messages per day is normal for an obscure (no offense) one-person domain: Its an attack. There are other ICMP-based attacks on your your personal domain as well. In other messages you describe hundreds or perhaps thousands of hosts doing this. You aren't the first person to experience such attacks. You're just the first person to claim (rather obstinately) that they aren't one (or a few users with a botnet) as this quote of shows: +++++++++++++++++++++++++++++++++++++++++++++++++++++++ And the IP address of *my* machine has changed, along with all of it's upstream providers. The issue *is* really that there are lots of different spammers attacking me. +++++++++++++++++++++++++++++++++++++++++++++++++++++++ While you _insist_ that spammers are just routinely spamming you with an aggregate 400K messages per day, there is no credible reason to think that. Instead, you are tangling with a botnet. See http://grc.com/dos/grcdos.htm for an interesting read on botnet attacks. And yes, they do "spam"/"mailbomb" you. There are successful strategies for dealing with botnet attacks. GRC is one interesting way, reporting abuse is another. Reporting abuse eventually causes them bots, and that causes them to risk getting caught, and causes them to lose resources (in the form of bots). Your way, of trying to pursue anti-spam techniques isn't one of the successful strategies. There is no help for you in SPF. If you get 400K messages per second without SPF, you will still get 400K with SPF. As you pointed out in November, 2002: +++++++++++++++++++++++++++++++++++++++++++++++++++++++ The bandwidth number I quoted in my previous email worked out to ~2-5 gigabytes a month, for: EHLO . . . MAIL FROM: spammer RCTP TO: no-such-user@striker.ottawa.on.ca If the messages had been delivered, the total data transferred would go up by a factor of 10-100 times. +++++++++++++++++++++++++++++++++++++++++++++++++++++++ SPF isn't going to reduce that. Banning spam isn't even going to reduce that: It isn't commercial spammers doing this. In fact, __nothing__ other than tracking down the botnets will reduce that. --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 Wed Jun 8 13:44:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20455 for ; Wed, 8 Jun 2005 13:44:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j58HFbSo082495; Wed, 8 Jun 2005 10:15:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j58HFbdm082494; Wed, 8 Jun 2005 10:15:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j58HFZUV082484 for ; Wed, 8 Jun 2005 10:15:36 -0700 (PDT) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 3364C16D00 for ; Wed, 8 Jun 2005 13:14:21 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: draft-schlitt-spf-classic-01.txt In-Reply-To: Your message of "Tue, 07 Jun 2005 21:59:45 EDT." Date: Wed, 08 Jun 2005 13:14:21 -0400 Message-Id: <20050608171421.3364C16D00@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dean Anderson wrote: > Alan, I think you misrember. And looking at www.striker.ottawa.on.ca just > now, I see you've been subject to reverse ping floods as well. Not surprisingly, you're missing a key point of information. This leads you to erroneous conclusions. FYI: At one point, I added FW rules to the box so that port 25 was open for 5 of my closest friends, and would send ICMP Port unreachables to everyone else. While this may not have been the best thing to do, it caught many idiots. "port unreachable" != "reverse ping flood" > These happen when people send pings with your IP address as the ICMP > source IP address. That's why you get people calling up and saying > "your machine is attacking me". Port unreachables are sent when their SMTP server tries to connect to mine. The flood of SMTP sessions from compromised boxes leads to floods of returning "go away" messages from my box. If they're idiots, they quickly conclude that I'm attacking them. This has happened not once, not twice, but multiple times. In every case, I was in contact with the admins of the compromised box, and once I convinced them to turn off SMTP, the spam delivery attempt stopped, and therefore the ICMP messages from my box stopped. And once they fixed the problem, it didn't re-occur from their site. > But in fact, those packets originate from the botnet machines. In fact, you're wrong. The packets in question originated from MY machine. I know this, you don't. Please stop, Dean. It's embarrassing. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Wed Jun 8 15:39:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29806 for ; Wed, 8 Jun 2005 15:39:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j58JFJmf094124; Wed, 8 Jun 2005 12:15:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j58JFJkq094122; Wed, 8 Jun 2005 12:15:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j58JFIUp094106 for ; Wed, 8 Jun 2005 12:15:18 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from SJC-Office-DHCP-156.Mail-Abuse.ORG (SJC-Office-DHCP-156.Mail-Abuse.ORG [168.61.10.156]) by harry.mail-abuse.org (Postfix) with ESMTP id A4DE1414F0 for ; Wed, 8 Jun 2005 12:15:13 -0700 (PDT) Subject: draft-schlitt-spf-classic-02.txt From: Douglas Otis To: MARID Content-Type: text/plain Date: Wed, 08 Jun 2005 12:15:12 -0700 Message-Id: <1118258112.7583.68.camel@SJC-Office-DHCP-156.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit 1. Introduction ... ,---- | An additional benefit to mail receivers is that after the use of an | identity is verified, local policy decisions about the mail can be | made based on the sender's domain, rather than the host's IP address. | This is advantageous because reputation of domain names is likely to | be more accurate than reputation of host IP addresses. Furthermore, | if a claimed identity fails verification, local policy can take | stronger action against such e-mail, such as rejecting it. `---- 2.5.3. Pass ,---- | A "Pass" result means that the client is authorized to inject mail | with the given identity. The domain can now, in the sense of | reputation, be considered responsible for sending the message. | Further policy checks can now proceed with confidence in the | legitimate use of the identity. `---- This is where SPF and Sender-ID make a very serious mistake. This assumes "server authorization" is equivalent to "sender authentication." It would be like me making a declaration that the postal service is authorized to deliver my letters, where recipients are then claiming any letter received from the postal service bearing my name is authentically or genuinely from me. Of course that would be a false assumption, yet this draft describes the sender as "considered responsible for sending the message." Review the many assumptions being made before arriving at this conclusion. This false assumption is also why publishing SPF records is unwise for the majority of domain owners. 2.1. The HELO Identity ,---- | The "HELO" identity derives from either the SMTP HELO or EHLO command | (see [RFC2821]). These commands supply the SMTP client (sending | host) for the SMTP session. Note that requirements for the domain | presented in the EHLO or HELO command are not always clear to the | sending party, and SPF clients must be prepared for the "HELO" | identity to be malformed or an IP address literal. At the time of | this writing, many legitimate e-mails are delivered with invalid HELO | domains. | | It is RECOMMENDED that SPF clients check not only the "MAIL FROM" | identity, but also separately check the "HELO" identity by applying | the check_host() function (Section 4) to the "HELO" identity as the | . `---- There is an expression, when your only tool is a hammer, everything looks like a nail. While checking the HELO may extend the use of name reputation into the initial exchange, the use of SPF to confirm the HELO is using a rather heavy hammer. The need for checking the HELO would be to protect network resources using a unified name reputation service. The potential for hundreds of DNS queries to resolve something as simple as HELO means this scheme has a rather basic flaw. While there is no reason for SPF to define how results are tallied, effectively this check could double an already sizeable overhead. Would the HELO override the MAILFROM? With respect to finding a means to stop abuse at the source, the HELO would prove more useful. However, SPF is poorly suited to fulfill this function. The prior justification for attempting to resolve the HELO was limited to the handling of a DSN message with a null MAILFROM. With SPF failure expected in this case, wouldn't something like BATV be more effective in this situation? 2.4. Checking Authorization ... ,---- | Without explicit approval of the domain owner, checking other | identities against SPF version 1 records is NOT RECOMMENDED because | there are cases that are known to give incorrect results. `---- Do you really think this sentence will cause a company to change their released version of Sender-ID? Sender-ID advocates will be quick to indicate they use both methods looking for any authorization. This becomes potentially a disaster when reputation is then misapplied, due to there being a lack of sender assurances. If you insist at retaining the v=spf1 record, providers should expect needing a license to assure the PRA. I fail to see the justification for not offering a positive means to express the scope of the record. Depreciate the version 1 record. Both SPF "new classic" and Sender-ID may continue to utilize these older records. Moving forward, a scoped version of the record offers a safer approach. It would also permit SPF records to be used for white-listing only. There have been many technologies thwarted by a large company's ability to dictate the definitions they promulgate. A large company may not be right or fair about their selection. Something as simple as data compression caused sizeable losses by a last minute imposition, even when eventually adjudicated as unfair. Accept this banal reality. -Doug From owner-ietf-mxcomp@mail.imc.org Wed Jun 8 16:49:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16845 for ; Wed, 8 Jun 2005 16:49:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j58KSK8C099727; Wed, 8 Jun 2005 13:28:20 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j58KSKWi099726; Wed, 8 Jun 2005 13:28:20 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j58KSFdv099713 for ; Wed, 8 Jun 2005 13:28:18 -0700 (PDT) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id j58KSANO012634 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 8 Jun 2005 16:28:14 -0400 Date: Wed, 8 Jun 2005 16:28:10 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: Alan DeKok cc: ietf-mxcomp@imc.org Subject: Re: draft-schlitt-spf-classic-01.txt In-Reply-To: <20050608171421.3364C16D00@mail.nitros9.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: On Wed, 8 Jun 2005, Alan DeKok wrote: > > Dean Anderson wrote: > > Alan, I think you misrember. And looking at www.striker.ottawa.on.ca just > > now, I see you've been subject to reverse ping floods as well. > > Not surprisingly, you're missing a key point of information. This > leads you to erroneous conclusions. > > FYI: At one point, I added FW rules to the box so that port 25 was > open for 5 of my closest friends, and would send ICMP Port > unreachables to everyone else. While this may not have been the best > thing to do, it caught many idiots. > > "port unreachable" != "reverse ping flood" You have no basis for concluding that their recieving "ICMP port unreachable" means that they actually tried connecting to you. This packet is easily forged. So there is no reason to think they are trying to send you spam. I did see that you thought they were, __based on their logs__ (_Their_ logs have no relevance to your claim) Plainly, __their logs__ of ICMP unreachables don't mean they sent you connections. You can't be that stupid. This is obstinancy. If __they__ were sending you thousands of spam connections, and getting thousands of port unreachables back, they would first notice the additional CPU load on their server due to the many processes attempting to connect to you. They would next notice the equally large number of TCP SYN packets coming from their server. Apparently, they didn't find this, and so the contacted you. Now possibly one person would notice Unreachables, and not look to see if they were sending SYNs. But you indicated that not just a few, but _MANY_ people made this same "mistake". The law of numbers suggests that many people would not make such a simple mistake. Further, To prove your claim, __you__ would need logs indicating that they actually tried connecting. Where are the SYNs from their server? But you have no such specific logs, or don't claim you do in those cases. Just another demonstration of bad logic and irrationality. But once again, you are ___still___ getting ___ABUSE___ This is not routine spam, as you keep insisting. Anti-spam techniques will not stop people whose goal is abuse. Spammers aren't calling you complaining that you should not to send them ICMP unreachables. What lunacy --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 Wed Jun 8 17:14:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18395 for ; Wed, 8 Jun 2005 17:14:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j58KmvFa000941; Wed, 8 Jun 2005 13:48:57 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j58KmvQJ000940; Wed, 8 Jun 2005 13:48:57 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j58KmvOl000934 for ; Wed, 8 Jun 2005 13:48:57 -0700 (PDT) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id j58Kmti9012995 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 8 Jun 2005 16:48:56 -0400 Date: Wed, 8 Jun 2005 16:48:54 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: Alan DeKok cc: ietf-mxcomp@imc.org Subject: Re: draft-schlitt-spf-classic-01.txt In-Reply-To: <20050608171421.3364C16D00@mail.nitros9.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: On Wed, 8 Jun 2005, Alan DeKok wrote: > In fact, you're wrong. The packets in question originated from MY > machine. I know this, you don't. Lets stick to the facts that were posted in 2002, so that you don't change the facts as we go along. If your description of facts in 2002 was insufficient, then I am fully justified in not believing you, and drawing conclusions from the facts you presented, regardless of what the actual god-known truth of the matter is. You didn't indicate that your machine was sending this traffic on your web page, in 2002. You just indicated that they claimed to have received packets, and that you convinced them to send logs. That fact that you would need to convince them to send logs suggests you denied their claims that you were sending these packets. Otherwise, why would you want their logs? Your logic fails: Recieving an ICMP port unreachable doesn't imply the four things you listed: ================================================================= Even worse, there have been a consistent trickle of complete shithead messages from alleged "sysadmins", saying "Your machine is attacking me!" When they're convinced to send firewall logs, they send logs which show them receiving 1000's of ICMP port unreachable messages. This says a few things: 1. Their firewall is misconfigured. (Blocking ICMP's is wrong.) 2. They're trying to send me spam, and complaining when they can't. 3. They don't understand how networks work, or how to set up their machines. 4. Words cannot describe their incompetence. In short, if you see your machine getting hammered by ICMP packets from this IP, it means you have to fix your system. Don't call me. Don't call my ISP. Don't make stupid threats about me trying to "hack" into your machines. If you do, then I will call the FBI (or whatever government body is intimidating to you), and inform them that you are a criminal hacker. They will believe me, not you. ================================================================= None of what you claim follows from the fact they got ICMP unreachables. You'll tell the FBI they are criminal hackers? The FBI will believe you, not them? --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 Wed Jun 8 17:28:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19164 for ; Wed, 8 Jun 2005 17:28:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j58LAQNe003476; Wed, 8 Jun 2005 14:10:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j58LAQlv003475; Wed, 8 Jun 2005 14:10:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j58LAPoV003469 for ; Wed, 8 Jun 2005 14:10:26 -0700 (PDT) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 9DAF316D00 for ; Wed, 8 Jun 2005 17:09:11 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: draft-schlitt-spf-classic-01.txt In-Reply-To: Your message of "Wed, 08 Jun 2005 16:28:10 EDT." Date: Wed, 08 Jun 2005 17:09:11 -0400 Message-Id: <20050608210911.9DAF316D00@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dean Anderson wrote: > You have no basis for concluding that their recieving "ICMP port > unreachable" means that they actually tried connecting to you. As I said, how about watching the packets go out of my box? > So there is no reason to think they are trying to send you spam. Other than the umpteen connections/s to port 25 on my machine. No, no reason to think they're trying to send me spam. > If __they__ were sending you thousands of spam connections, and getting > thousands of port unreachables back, they would first notice the > additional CPU load on their server due to the many processes attempting > to connect to you. They would next notice the equally large number of TCP > SYN packets coming from their server. Apparently, they didn't find this, > and so the contacted you. I count at least 3 assumptions in that paragraph. > Now possibly one person would notice Unreachables, and not look to see if > they were sending SYNs. But you indicated that not just a few, but _MANY_ > people made this same "mistake". Read the web page. It's "a steady trickle". More than one, and less than 10. > Further, To prove your claim, __you__ would need logs indicating that they > actually tried connecting. Where are the SYNs from their server? But you > have no such specific logs, or don't claim you do in those cases. I have the data, you don't. I'm sorry that this upsets you. > Spammers aren't calling you complaining that you should not to send them > ICMP unreachables. What lunacy Exactly. I never claimed that. At this point, I have to ask: Are you for real, Dean? Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Wed Jun 8 17:59:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21917 for ; Wed, 8 Jun 2005 17:59:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j58LejqV005627; Wed, 8 Jun 2005 14:40:45 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j58LejMQ005626; Wed, 8 Jun 2005 14:40:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j58LeixE005620 for ; Wed, 8 Jun 2005 14:40:44 -0700 (PDT) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id A0D5616D00 for ; Wed, 8 Jun 2005 17:39:30 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Philosophical discussions In-Reply-To: Your message of "Wed, 08 Jun 2005 03:18:16 +0200." <42A64758.6379@xyzzy.claranet.de> Date: Wed, 08 Jun 2005 17:39:30 -0400 Message-Id: <20050608213930.A0D5616D00@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Frank Ellermann wrote: > "Final delivery" is something different, I'd say "sent" where > you say "delivered". Which is part of the confusion. The Simple Mail Transport Protocol transported the message from origin to destination. That's "delivery", by at least one standard. When a FedEx guy hands my receptionist a package, he's "delivered" it, for all intents and purposes. The receptionist may, in turn, deliver it to me, but that's a different kind of delivery. Much of the confusion around these discussions has been a result of the terms being overloaded, and the participants not qualifying the context in which they use the terms. > There's no problem, the MX can be a gateway to some fascinating > UUCP forwarding, or forward your mail to an MDA, with several > hops, it's all fine and still MAIL FROM you RCPT TO recipient. Once the MX for your domain gets the message, any final steps to get it to your physical mailbox is *internal* to your site. It varies from site to site in a way that SMTP does not. > It is _not_ the historical approach, that's only a legend of > the "bounces-to" camp. For me, it's all "he said, she said". > The MAIL FROM _semantics_ is as it always was since STD 10. And > SPF simply uses it to fix this security loophole in SMTP today, > for those who want it. And there's the sticking point: "those who want it". It's about consent. Two adults consenting to do stupid things is not something anyone can control or prevent. Yet there's been significant effort in the SMTP community to do just that. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Wed Jun 8 20:43:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07822 for ; Wed, 8 Jun 2005 20:43:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j590KiL3016401; Wed, 8 Jun 2005 17:20:44 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j590Kius016399; Wed, 8 Jun 2005 17:20:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from polis.nbtsc.org (polis.nbtsc.org [204.10.124.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j590KfGt016389 for ; Wed, 8 Jun 2005 17:20:43 -0700 (PDT) (envelope-from aredridel@nbtsc.org) Received: from betelgeuse.theinternetco.net ([2001:470:1f01:301:201:29ff:fe87:11e8]) by polis.nbtsc.org with esmtpa (Exim 4.51) id 1DgAmn-0002Es-1o; Wed, 08 Jun 2005 18:20:41 -0600 Subject: Re: draft-schlitt-spf-classic-02.txt From: Aredridel To: Douglas Otis Cc: MARID In-Reply-To: <1118258112.7583.68.camel@SJC-Office-DHCP-156.mail-abuse.org> References: <1118258112.7583.68.camel@SJC-Office-DHCP-156.mail-abuse.org> Content-Type: text/plain Date: Wed, 08 Jun 2005 18:20:40 -0600 Message-Id: <1118276440.23392.5.camel@betelgeuse.theinternetco.net> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 Content-Transfer-Encoding: 7bit X-Scan-Signature: 997709c3786f5213d45cf416491fb5f0 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > This is where SPF and Sender-ID make a very serious mistake. This > assumes "server authorization" is equivalent to "sender authentication." > It would be like me making a declaration that the postal service is > authorized to deliver my letters, where recipients are then claiming any > letter received from the postal service bearing my name is authentically > or genuinely from me. Of course that would be a false assumption, yet > this draft describes the sender as "considered responsible for sending > the message." Review the many assumptions being made before arriving at > this conclusion. This false assumption is also why publishing SPF > records is unwise for the majority of domain owners. If there were only one post office, not many millions, the analogy might be more accurate. It's not entirely firm authentication, but it's sure better than having no information at all. . . But would you take less than fully secured crypto, or is the perfect the enemy of the good in this case? Ari From owner-ietf-mxcomp@mail.imc.org Wed Jun 8 22:29:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02711 for ; Wed, 8 Jun 2005 22:29:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5922XO2022315; Wed, 8 Jun 2005 19:02:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5922XYZ022314; Wed, 8 Jun 2005 19:02:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5922UMJ022296 for ; Wed, 8 Jun 2005 19:02:30 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from SJC-Office-DHCP-156.Mail-Abuse.ORG (SJC-Office-DHCP-156.Mail-Abuse.ORG [168.61.10.156]) by harry.mail-abuse.org (Postfix) with ESMTP id A7023414F0; Wed, 8 Jun 2005 19:02:25 -0700 (PDT) Subject: Re: draft-schlitt-spf-classic-02.txt From: Douglas Otis To: Aredridel Cc: MARID In-Reply-To: <1118276440.23392.5.camel@betelgeuse.theinternetco.net> References: <1118258112.7583.68.camel@SJC-Office-DHCP-156.mail-abuse.org> <1118276440.23392.5.camel@betelgeuse.theinternetco.net> Content-Type: text/plain Date: Wed, 08 Jun 2005 19:02:25 -0700 Message-Id: <1118282545.22619.57.camel@SJC-Office-DHCP-156.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2005-06-08 at 18:20 -0600, Aredridel wrote: > > This is where SPF and Sender-ID make a very serious mistake. This > > assumes "server authorization" is equivalent to "sender authentication." > > It would be like me making a declaration that the postal service is > > authorized to deliver my letters, where recipients are then claiming any > > letter received from the postal service bearing my name is authentically > > or genuinely from me. Of course that would be a false assumption, yet > > this draft describes the sender as "considered responsible for sending > > the message." Review the many assumptions being made before arriving at > > this conclusion. This false assumption is also why publishing SPF > > records is unwise for the majority of domain owners. > > If there were only one post office, not many millions, the analogy might > be more accurate. There is certainly more domains than mail servers. If the average server were to handle just two domains, this still leaves considerable room for disputes to arise. From the perspective of a reputation service, it is impossible to know either the number of domains sharing the server, or what identifiers were assured. Reputation can be very destructive when attributing abuse to the wrong entity. > It's not entirely firm authentication, but it's sure better than having > no information at all. . . But would you take less than fully secured > crypto, or is the perfect the enemy of the good in this case? SPF does not offer authentication. Publishing this SPF authorization record can be much worse than not publishing, when used beyond just white-listing. With spammers and phishers already among the first to offer SPF records, SPF authorization alone provides no protection. When reputation is applied to authorization, disaster! SPF/Sender-ID is server authorization. Because it is untrustworthy, (it causes email to be lost or refused) SPF/Sender-ID has extremely little value. It can not be applied in any strict manner reliably. The high overhead associated with resolving the path registered by SPF, means this mechanism can not offer network protection. Nor can SPF reliably offer recipient protection either. Phishing and spamming is sure to continue with SPF/Sender-ID. I know there are some that dream of the day when "-all" does not cause mail to be lost, and when everyone knows which identifier to check. SPF demands additional diligence by providers, while also leaving the providers unscathed when they are negligent. SPF may cause a behavior change in some cases, but this change is almost certain to create even greater damage for domain owners. Something like DomainKeys, that will eventually be upgraded to DKIM, does offer an alternative that is both safe and fair _authentication_. This alternative to just _authorization_ uses less overhead than SPF/Sender-ID. In the case of SPF versus DomainKeys, the bad is the enemy of the good, safe, and fair. : ) -Doug From owner-ietf-mxcomp@mail.imc.org Wed Jun 8 22:33:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05138 for ; Wed, 8 Jun 2005 22:33:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j592D23h022876; Wed, 8 Jun 2005 19:13:02 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j592D2OW022875; Wed, 8 Jun 2005 19:13:02 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j592D16a022869 for ; Wed, 8 Jun 2005 19:13:01 -0700 (PDT) (envelope-from wayne@schlitt.net) Received: from footbone.schlitt.net ([67.52.51.37] helo=schlitt.net) by backbone.schlitt.net with esmtp (Exim 4.50) id 1DgCXL-0002yv-C8 for ietf-mxcomp@imc.org; Wed, 08 Jun 2005 21:13:01 -0500 To: "IETF MARID WG" References: <1118258112.7583.68.camel@SJC-Office-DHCP-156.mail-abuse.org> From: wayne Mail-Copies-To: nobody Reply-To: "IETF MARID WG" Content-Type: text/plain; charset=US-ASCII Date: Wed, 08 Jun 2005 21:12:50 -0500 In-Reply-To: <1118258112.7583.68.camel@SJC-Office-DHCP-156.mail-abuse.org> (Douglas Otis's message of "Wed, 08 Jun 2005 12:15:12 -0700") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.schlitt.net: domain of schlitt.net designates 67.52.51.37 as permitted sender) client-ip=67.52.51.37; envelope-from=wayne@schlitt.net; helo=schlitt.net; X-SA-Exim-Connect-IP: 67.52.51.37 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: draft-schlitt-spf-classic-02.txt X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on backbone.schlitt.net X-Spam-Status: No, score=-6.8 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00, GREYLIST_ISWHITE autolearn=ham version=3.0.2 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: In <1118258112.7583.68.camel@SJC-Office-DHCP-156.mail-abuse.org> Douglas Otis writes: > 1. Introduction > ... > ,---- > | An additional benefit to mail receivers is that after the use of an > | identity is verified, local policy decisions about the mail can be > | made based on the sender's domain, rather than the host's IP address. > | This is advantageous because reputation of domain names is likely to > | be more accurate than reputation of host IP addresses. Furthermore, > | if a claimed identity fails verification, local policy can take > | stronger action against such e-mail, such as rejecting it. > `---- > > 2.5.3. Pass > ,---- > | A "Pass" result means that the client is authorized to inject mail > | with the given identity. The domain can now, in the sense of > | reputation, be considered responsible for sending the message. > | Further policy checks can now proceed with confidence in the > | legitimate use of the identity. > `---- > > This is where SPF and Sender-ID make a very serious mistake. This > assumes "server authorization" is equivalent to "sender authentication." This has been discussed many times on the spf-discuss list. The general consensus is that "server authorization" is *NOT* equivalent to "sender authentication" and that is why the SPF-classic I-D uses authorization throughout. > It would be like me making a declaration that the postal service is > authorized to deliver my letters, where recipients are then claiming any > letter received from the postal service bearing my name is authentically > or genuinely from me. Of course that would be a false assumption, yet > this draft describes the sender as "considered responsible for sending > the message." Review the many assumptions being made before arriving at > this conclusion. This false assumption is also why publishing SPF > records is unwise for the majority of domain owners. The above language for "Pass" is actually somewhat less strict than the responsibilities assinged in the draft-mengwong-spf-* drafts. > 2.1. The HELO Identity > > There is an expression, when your only tool is a hammer, everything > looks like a nail. While checking the HELO may extend the use of name > reputation into the initial exchange, the use of SPF to confirm the HELO > is using a rather heavy hammer. Indeed it is a rather heavy hammer. No question about that. If you could loan me a time machine, I would be quite willing to go back to the fall of 2003 when this was first set up. Unfortunately, this kind of HELO checking has been in place for a year and a half now, there are lots of people who have published SPF records under their HELO domains, and there are lots of people who are checking these HELO domain SPF records even when the MAIL FROM is not null. (i.e. SpamAssassin) The draft-schlitt-spf-classic-* series of I-Ds is an attempt to document what is, not what should or could be. > The need for checking the HELO would be > to protect network resources using a unified name reputation service. > The potential for hundreds of DNS queries to resolve something as simple > as HELO means this scheme has a rather basic flaw. In theory, SPF HELO checking is far less than optimal, but in practice it isn't that bad. Since you should publish SPF records at your HELO domain if you publish SPF records at your MAIL FROM domain, a lot of people are going to be publishing them. It is not clear to me that any other system is enough better to motivate people to switch. > The prior justification for attempting to resolve the HELO was limited > to the handling of a DSN message with a null MAILFROM. With SPF failure > expected in this case, wouldn't something like BATV be more effective in > this situation? Why would SPF failure be expected in this case? There are several reasons why people like SPF, limiting blowback is just one reason. > 2.4. Checking Authorization > ... > ,---- > | Without explicit approval of the domain owner, checking other > | identities against SPF version 1 records is NOT RECOMMENDED because > | there are cases that are known to give incorrect results. > `---- > > Do you really think this sentence will cause a company to change their > released version of Sender-ID? I don't know, but I do think that it is important to let people know about the dangers. I think it is likely that developers will need to update their MARID protocol implementations anyway. Instead of using the marid-protocol document, they are now using the spf-classic document, and these two documents are not completely compatible. > I fail to see the justification for not offering a positive means to > express the scope of the record. Mark Lentczner was the one who convinced Meng to remove the scope= modifier from the SPF spec in the fall of 2003. Hindsight is 20/20. > Depreciate the version 1 record. Both > SPF "new classic" and Sender-ID may continue to utilize these older > records. I see no particular reason why SPFv1 records should be depreciated. They are well defined for the MAIL FROM and HELO identities which they were published for. > There have been many technologies thwarted by a large company's ability > to dictate the definitions they promulgate. A large company may not be > right or fair about their selection. Something as simple as data > compression caused sizeable losses by a last minute imposition, even > when eventually adjudicated as unfair. Accept this banal reality. Yes, that is possible. My admittedly limited data shows that almost no one is checking things for the MARID protocol. At this time, it doesn't seem to be a problem. -wayne From owner-ietf-mxcomp@mail.imc.org Wed Jun 8 23:40:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24670 for ; Wed, 8 Jun 2005 23:40:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j593IPSa028326; Wed, 8 Jun 2005 20:18:25 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j593IPMp028325; Wed, 8 Jun 2005 20:18:25 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j593ILRa028316 for ; Wed, 8 Jun 2005 20:18:24 -0700 (PDT) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id j593IFGW020115 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 8 Jun 2005 23:18:21 -0400 Date: Wed, 8 Jun 2005 23:18:15 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: Alan DeKok cc: ietf-mxcomp@imc.org Subject: Re: draft-schlitt-spf-classic-01.txt In-Reply-To: <20050608210911.9DAF316D00@mail.nitros9.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: On Wed, 8 Jun 2005, Alan DeKok wrote: > > Dean Anderson wrote: > > You have no basis for concluding that their recieving "ICMP port > > unreachable" means that they actually tried connecting to you. > > As I said, how about watching the packets go out of my box? 1) Having an outbound packet rate, as you describe, doesn't indicate that they sent you SYN packets. It is possible that your machine is compromised, and that it really is attacking them. 2) It is possible that you received SYN packeets that weren't from them. Forged SYN packets are common type of attack. 3) Merely having an outbound ICMP packet rate doesn't mean that the packets they got came from your system. 4) It is possible that their system is compromised. All of these are more likely than your insistence that they are spammers asking you not to send them ICMP packets. With this in mind, lete look again at your claims: (from www.striker.ottawa.on.ca) **1. Their firewall is misconfigured. (Blocking ICMP's is wrong.) Blocking __all__ ICMP is probably wrong. There is only one ICMP packet that shouldn't be blocked, and there is currently an attack which makes it reasonable to block even that turn. So blocking the ICMP port unreachable packet type is not wrong. http://www.av8.net/ICMPTypes.txt **2. They're trying to send me spam, and complaining when they can't. This is just irrational. **3. They don't understand how networks work, or how to set up their machines. Their machines are probably set up correctly. But if they aren't, you haven't shown any reason that they aren't. **4. Words cannot describe their incompetence. The acts you attribute to them are entirely rational and show no incompetence on _their_ part. Competence is the ability to solve common problems in your field of work. A common problem for an IT professional might have to solve is analyzing an attack. What should a competent professional have done in Alan's situation? Lets look at what should happen: Sysadmin calls Alan, and says: "Your system is attacking me" Alan should say: "What makes you think that?" Sysadmin says: "I'm getting loads of ICMP messages from your IP." Alan should say: "What's your IP? I'll take a look" Sysadmin tells him IP. Alan grabs packets to and from that IP [now we have some options, depending on what Alan finds] Option 1: Alan found packets to/from that IP Option 1A: Alan found SYN Packets from their IP and ICMP packets to it Alan says: "I'm seeing SYN packets from your IP. Do you see that?" Option 1A1: Sysadmin sees it Sysadmin says: "Yes. Hmm. That's weird" Alan: "OK. Could you block SYNS to my IP until you fix it?" Sysadmin: "Sure". Option 1A2: Sysadmin doesn't see anything Sysadmin says: "No SYN packets here." Alan says: "Hmm. Somebody may be forging SYN packets from your IP. I'll contact my ISP and see if we can trace it down. In the meantime, I'll block ICMP going to your IP. Sysadmin says: "Thanks for taking care of the problem" Option 1B: Alan found ICMP but no SYN Packets Alan says: "I'm just seeing ICMP packets to your IP. But that's strange; I don't see any SYN packets. Hmm. I seem to have a compromise on my box. I'll block ICMP to your IP until I get it fixed." Sysadmin says: "Thanks for taking care of the problem" Option 2: Alan didn't find packets to or from that IP Alan says: "I don't see anything to or from your IP. It seems that our IP has been forged in the ICMP packet." Sysadmin says: "Ok, thanks. I'll contact our upstreams to trace the traffic. Thanks for you help." So now we know what should have happened, lets postmotem what happened: Alan said that no one should contact him because they are reciving ICMP from his IP. Alan says on his page that anyone contacting him about this is incompetent. Alan says they are spammers complaining about his ICMP. Alan says he convinced some to send him _their_ logs. Their logs don't prove Alan's claims. Indeed, none of Alan's claims are supportable. Alan didn't go through any of the steps listed above; He didn't document them. To demonstrate his own due diligence, he would need to report what he found. So, it Alan's competence that's in question. Not the competence of the people who called him to complain about the ICMP packets apparently coming from his IP address. And as already shown, his claims about blocking ICMP are also incorrect. Alans failure to understand common practice reflects badly on competence as an IT Professional. > > Further, To prove your claim, __you__ would need logs indicating that they > > actually tried connecting. Where are the SYNs from their server? But you > > have no such specific logs, or don't claim you do in those cases. > > I have the data, you don't. I'm sorry that this upsets you. You don't make any claim that you gave them your logs. So I don't think you did. Whether or not you actually have that data is irrelevant. You didn't use it to make your case to them, and you can't make a rational case without it. I don't need to see your data to conclude that your argument is unsupported. I'm not upset to not have your data. You just seem to be stretching the assertion that nobody can make any conclusions without it. But that's just wrong. Deductions can be made, given what you have revealed. > > Spammers aren't calling you complaining that you should not to send them > > ICMP unreachables. What lunacy > > Exactly. I never claimed that. You did, and you have been: Point 2 on your list: 2. They're trying to send me spam, and complaining when they can't Further, you also keep asserting that spammers are routinely spamming you, and you deny my assertion that you are being abused by people who seek to annoy you. My assertion (since 2002) has been that this is an attack. It is not "spam". It is meant to annoy you. > At this point, I have to ask: Are you for real, Dean? You are the one pursuing an irrational position well beyond the point of making a credible claim. It is no longer credible to think that you belive what you say. -- 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 Thu Jun 9 03:20:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29233 for ; Thu, 9 Jun 2005 03:20:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j596vKKt095091; Wed, 8 Jun 2005 23:57:20 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j596vKVf095090; Wed, 8 Jun 2005 23:57:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.asarian-host.net (mail.asarian-host.net [194.109.160.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j596vJqx095070 for ; Wed, 8 Jun 2005 23:57:20 -0700 (PDT) (envelope-from SRS0=mBEKSbAZ=UP=asarian-host.net=admin@asarian-host.net) Received: from anonymizer.asarian-host.net (localhost [127.0.0.1]) (authenticated bits=0) by mail.asarian-host.net (8.13.4/8.13.4) with ESMTP id j596vH00056589 for ; Thu, 9 Jun 2005 08:57:18 +0200 (CEST) (envelope-from admin@asarian-host.net) From: Mark Received-SPF: pass (asarian-host.net: sender IP is authenticated by a trusted mechanism) receiver=asarian-host.net; client-ip=sender IP; envelope-from=; helo=asarian-host; Message-Id: <200506090657.j596vH6e056579@asarian-host.net> Date: Thu, 09 Jun 2005 06:57:17 GMT X-Authenticated-Sender: admin@asarian-host.net Subject: RE: draft-schlitt-spf-classic-02.txt X-Trace: /PoNySg3c0BwYrz9FBzxwHXKNIez8X6pDpVXQqTZ873OWxNwAywRwbF5r0rqiTY3Pqt4FhDz9FbO3rkBu3DbOw== X-Complaints-To: abuse@asarian-host.net X-Abuse-Info: Please be sure to forward a copy of ALL headers, otherwise we are unable to process your complaint Organization: Asarian-host To: "'MARID'" MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In-Reply-To: <1118258112.7583.68.camel@SJC-Office-DHCP-156.mail-abuse.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Auth: Asarian-host PGP signature iQEVAwUAQqfoTTFqW1BleBN9AQGNMwf/Zof8SAWdzl0V7MGuW8yjon9E6izKdBf2 kWmTOUqQ5OcgBVI9GaL65+Po9nsf98AaYAjXy3pAnpsTclTbPj1ZfzrV5TaY1xdm UMYV3CL8Bg9actnNzupgZqsL042HtHeNp4GznN63y289z0R0Y8/EgCS5WEY9O7vN mRBECWm0/+JUCQJQflHW5ll8gCNbXzKU8TK7tUPKXK4oZpBtuWivTVHBV2XpP12C e0fv3WmO+Ok8uQIOKP75G1zVGdTDZBpMwlNPGJV9ETyvFUT74CIxZNVi182dHEe7 p/SWJaXCSkzW0bMsB5sHUS/Va2l4P+SdevfxPtinpXPPRnYwVv1Btg== =51zF Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of Douglas Otis > Sent: woensdag 8 juni 2005 21:20 > To: MARID > Subject: draft-schlitt-spf-classic-02.txt > > > This is where SPF and Sender-ID make a very serious mistake. This > assumes "server authorization" is equivalent to "sender > authentication." It would be like me making a declaration that the > postal service is authorized to deliver my letters, where recipients > are then claiming any letter received from the postal service bearing > my name is authentically or genuinely from me. Your argument is essentially correct. Which is why I lobbied, successfully, to change the wording "can now proceed with confidence in the identity" to "can now proceed with confidence in the legitimate use of the identity" (by the connecting client). There is still a gap left between being "authorized" and being able to say the return address is "authentic". From the perspective of a reputation service, however, things are not as bleak as you portray. Because "pass" is not just saying this or that IP is authorized, but is also, effectively, an expression of trust. Trust that the MTA you authorized will, itself, prevent abuse of its services (when perpetrated by its own customers). Otherwise you would not continue to trust that MTA. And such expressed trust, if shamed, can be withdrawn. And, if not withdrawn over time, the meaning of your expressed trust, with "pass", can be said to increase accordingly. So that is why we, in the SPF Council, after heated debate, at long last agreed on a compromise. We would state, that, after a "pass", one could only "proceed with confidence in the legitimate use of the identity" (and nothing more); but, that in the case of reputation, receivers could take this expressed trust in the MTA to mean, especially when seen over a prolonged period (and reputation is typically built up over time anyway) that the domain takes responsibility for the reputation it builds up. All-in-all, I think the resulting wording for "pass" was as even-handed as we could make it. - Mark System Administrator Asarian-host.org --- "If you were supposed to understand it, we wouldn't call it code." - FedEx From owner-ietf-mxcomp@mail.imc.org Thu Jun 9 07:46:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17113 for ; Thu, 9 Jun 2005 07:46:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j59BOItX093440; Thu, 9 Jun 2005 04:24:18 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j59BOIMb093439; Thu, 9 Jun 2005 04:24:18 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j59BOGj2093403 for ; Thu, 9 Jun 2005 04:24:17 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DgKW5-0001fr-Dm for ietf-mxcomp@imc.org; Thu, 09 Jun 2005 12:44:05 +0200 Received: from c-134-88-110.hh.dial.de.ignite.net ([62.134.88.110]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 09 Jun 2005 12:44:05 +0200 Received: from nobody by c-134-88-110.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 09 Jun 2005 12:44:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: Philosophical discussions Date: Thu, 09 Jun 2005 12:13:13 +0200 Organization: Lines: 57 Message-ID: <42A81639.831@xyzzy.claranet.de> References: <42A64758.6379@xyzzy.claranet.de> <20050608213930.A0D5616D00@mail.nitros9.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: c-134-88-110.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Alan DeKok wrote: > Much of the confusion around these discussions has been a > result of the terms being overloaded, and the participants > not qualifying the context in which they use the terms. Yes, but in essence it's still "simple", and claims that SPF "breaks forwarding" are an over-simplification, like your statement "when the MX has the mail it's delivered". My point is that it can be "forwarded" behind this MX without "breaking". Only in one special case the receiver would be in trouble, if he arranges his "delivery" in a way including an SPF-test behind the first MX. > Once the MX for your domain gets the message, any final steps > to get it to your physical mailbox is *internal* to your site Even in that simple and normal case I have a chance to get it wrong, secondary MX forwards to primary MX, primary MX tests SPF, FAIL => your sender policy does of course not permit the IP of my secondary MX, I forgot to white list this beast. That's not necessarily "internal", but it's certainly my fault. You'll get a bounce, and maybe you inform my postmaster@ that I screwed up. No real problem, shit happens, I'd simply fix it. BTW, in practice I had this problem only once since April 2004, apparently receivers testing SPF normally get it right. After all it's no rocket science, "test a.s.a.p. or don't test it". >> It is _not_ the historical approach, that's only a legend of >> the "bounces-to" camp. > For me, it's all "he said, she said". The "he" was Jon Postel in STD 10, the "she" are later texts. And "her" claim is that "MAIL FROM" was an error and actually means "BOUNCES TO" - "history" as you find it in Orwell's 1984. >> The MAIL FROM _semantics_ is as it always was since STD 10. >> And SPF simply uses it to fix this security loophole in SMTP >> today, for those who want it. > And there's the sticking point: "those who want it". > It's about consent. Two adults consenting to do stupid > things is not something anyone can control or prevent. Yet > there's been significant effort in the SMTP community to do > just that. "Philosophical discussions" about design flaws 16 years after the fact are difficult - with Wayne's time machine I wouldn't go back to 2003, but jump directly on the desktop of the 1123 editors. With a loaded gun... ;-) Bye, Frank From owner-ietf-mxcomp@mail.imc.org Thu Jun 9 12:56:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21015 for ; Thu, 9 Jun 2005 12:56:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j59GW91L047979; Thu, 9 Jun 2005 09:32:09 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j59GW9EG047978; Thu, 9 Jun 2005 09:32:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j59GW72Q047969 for ; Thu, 9 Jun 2005 09:32:08 -0700 (PDT) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 5976A16D00 for ; Thu, 9 Jun 2005 12:30:52 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: draft-schlitt-spf-classic-01.txt In-Reply-To: Your message of "Wed, 08 Jun 2005 23:18:15 EDT." Date: Thu, 09 Jun 2005 12:30:52 -0400 Message-Id: <20050609163052.5976A16D00@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dean Anderson wrote: > 4) It is possible that their system is compromised. When I talked with these people, the SYN's & ICMP's all stopped after they claimed to have fixed their systems. This would lead any reasonable person to conclude that their system was compromised (as I said), that the source and destination of SYN's & ICMP's was exactly what they appeared to be (as I said), and that no botnet was involved (as I said). > [now we have some options, depending on what Alan finds] In those options, you leave out the one option I've been telling you repeatedly is what happened: their machine really was compromised, and all of the traffic was exactly as it appeared, with no botnets or forgeries. > To demonstrate his own due diligence, he would need to report what > he found. I have no responsibility to show my logs to you, or to anyone else on the planet. > Whether or not you actually have that data is irrelevant. You > didn't use it to make your case to them, I didn't need to. They could independently verify for themselves that their machine was compromised, was sending spam, and that their machine was sending loads of TCP SYN's to my machine. They aren't spammers because they aren't *intending* to send spam, it's a side-effect of their network misconfiguration. I'm surprised that the one realistic interpretation of the events is the only one you cannot admit might have happened. I won't respond to the rest of your comments about competence and credibility. The evidence speaks for itself. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Thu Jun 9 13:57:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29168 for ; Thu, 9 Jun 2005 13:57:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j59HVv86054170; Thu, 9 Jun 2005 10:31:57 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j59HVvLm054169; Thu, 9 Jun 2005 10:31:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j59HVuE4054163 for ; Thu, 9 Jun 2005 10:31:57 -0700 (PDT) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 4838D16D00 for ; Thu, 9 Jun 2005 13:30:44 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Philosophical discussions In-Reply-To: Your message of "Thu, 09 Jun 2005 12:13:13 +0200." <42A81639.831@xyzzy.claranet.de> Date: Thu, 09 Jun 2005 13:30:44 -0400 Message-Id: <20050609173044.4838D16D00@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Frank Ellermann wrote: > Even in that simple and normal case I have a chance to get it > wrong, secondary MX forwards to primary MX, primary MX tests > SPF, FAIL => your sender policy does of course not permit the > IP of my secondary MX, I forgot to white list this beast. > > That's not necessarily "internal", It's internal to the trust boundary of your domain. I have no way of knowing that it's a secondary, and you do. > "Philosophical discussions" about design flaws 16 years after > the fact are difficult - with Wayne's time machine I wouldn't > go back to 2003, but jump directly on the desktop of the 1123 > editors. With a loaded gun... ;-) The purpose of philosophical discussions are to obtain a common agreement as to the intent of the system. If no one can agree on *why* the system exists, or *what* it's supposed to be doing, then talking about *how* is a waste of time. But the discussions I've seen have focussed on "how", and have steadfastly avoided the "why". The existence proof of the email system is nice, but a collection of patches over time can result in a system that no one intended to build. Proof: the spam problem. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Thu Jun 9 16:19:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16935 for ; Thu, 9 Jun 2005 16:19:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j59Jr7Af066393; Thu, 9 Jun 2005 12:53:07 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j59Jr7fl066391; Thu, 9 Jun 2005 12:53:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j59Jr6nb066378 for ; Thu, 9 Jun 2005 12:53:06 -0700 (PDT) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 648B216D00 for ; Thu, 9 Jun 2005 15:51:51 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Philosophical discussions (was Re: draft-schlitt-spf-classic-01.txt ) In-Reply-To: Your message of "Tue, 07 Jun 2005 18:55:17 PDT." <1118195717.7607.97.camel@SJC-Office-DHCP-156.mail-abuse.org> Date: Thu, 09 Jun 2005 15:51:51 -0400 Message-Id: <20050609195151.648B216D00@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Douglas Otis wrote: > Assume you sent a message to a simple exploding list for example. While > you could conclude that once the list server accepted your message, it > now becomes the list server's message. I think the word we're missing here is "anthology". Anthologies are collections of copyrighted works by individual authors, along with an editor who has a "collection copyright" on the sum total of the work. One email message, therefore, is an anthology with multiple authors. One person wrote the text, another person wrote the quoted text (if any), the mailer wrote some of the headers (message-id, etc), and so on. Reputation for the collected work impacts all of the authors in that collection, to varying degrees. > From a reputation standpoint, this is not desirable from the > perspective of the list operator, who would like any abuse to > directly impact those they see as accountable. If I send a copy of a DVD to this list, and this list re-distributes it, the list owner may be responsible for "contributoy infringement". Reputation affects both me as author of the message, and the list owner as distributor. If we were to require that list owners *not* have their reputation affected by messages they re-send, then spammers can hide behind lists. > The abuse that concerns you has to do with how the accountable entity is > determined. s/entity/entities/ That's really the crux of my argument. > > They can use a proposal that doesn't have problems. > > Which proposal is that? It is not draft-schlitt-spf-classic-01, or > draft-lyon-senderid-core-01. These two drafts are in serious conflict, > and the Sender-ID draft claims that server authorization is equivalent > to sender authentication, whether for the bounce-address or the PRA. Do > you really think it is safe to ignore the intentions of Microsoft? Nope. And if all of the proposals re so terrible, we should see if we can come up with another proposal that isn't so bad. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Thu Jun 9 16:19:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16956 for ; Thu, 9 Jun 2005 16:19:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j59JrmAa066507; Thu, 9 Jun 2005 12:53:48 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j59JrmKg066505; Thu, 9 Jun 2005 12:53:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j59JrkEj066493 for ; Thu, 9 Jun 2005 12:53:48 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from SJC-Office-DHCP-156.Mail-Abuse.ORG (SJC-Office-DHCP-156.Mail-Abuse.ORG [168.61.10.156]) by harry.mail-abuse.org (Postfix) with ESMTP id D213A414F2 for ; Thu, 9 Jun 2005 12:53:40 -0700 (PDT) Subject: Re: draft-schlitt-spf-classic-02.txt From: Douglas Otis To: IETF MARID WG In-Reply-To: References: <1118258112.7583.68.camel@SJC-Office-DHCP-156.mail-abuse.org> Content-Type: text/plain Date: Thu, 09 Jun 2005 12:53:40 -0700 Message-Id: <1118346820.7571.140.camel@SJC-Office-DHCP-156.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2005-06-08 at 21:12 -0500, wayne wrote: > Douglas Otis writes: > > > 1. Introduction > > ... > > ,---- > > | An additional benefit to mail receivers is that after the use of an > > | identity is verified, local policy decisions about the mail can be > > | made based on the sender's domain, rather than the host's IP address. > > | This is advantageous because reputation of domain names is likely to > > | be more accurate than reputation of host IP addresses. Furthermore, > > | if a claimed identity fails verification, local policy can take > > | stronger action against such e-mail, such as rejecting it. > > `---- > > > > 2.5.3. Pass > > ,---- > > | A "Pass" result means that the client is authorized to inject mail > > | with the given identity. The domain can now, in the sense of > > | reputation, be considered responsible for sending the message. > > | Further policy checks can now proceed with confidence in the > > | legitimate use of the identity. > > `---- > > > > This is where SPF and Sender-ID make a very serious mistake. This > > assumes "server authorization" is equivalent to "sender authentication." > > This has been discussed many times on the spf-discuss list. The > general consensus is that "server authorization" is *NOT* equivalent > to "sender authentication" and that is why the SPF-classic I-D uses > authorization throughout. This draft still insists that by providing authorization for the server, the mailbox-domain owner is "responsible for having sent the message." How can you arrive at this conclusion without considering "authorization" equivalent to "authentication?" How do you know the use of the mailbox-domain is "legitimate?" You are assuming exclusive use of the mailbox-domain is assured by the email provider. This introductory paragraph must include a dire warning there will be those that consider "authorization" equivalent to "authentication." To protect the reputation of your domain, establish service level agreements with your provider that indemnifies you, as the domain owner, from the provider allowing non-exclusive use of your mailbox-domain, whether for the bounce-address or the purported responsible address. Those, in control of millions of zombies, will have at their disposal a matrix of all possible mailbox-domains that authorize the outbound server, detected by issuing a single message. Those servers shared by many domains will be an exploit bonanza. This false assumption, which goes well beyond what may be safely deduced from server authorization, place a majority of mailbox-domain owner's reputation in peril. > > It would be like me making a declaration that the postal service is > > authorized to deliver my letters, where recipients are then claiming any > > letter received from the postal service bearing my name is authentically > > or genuinely from me. Of course that would be a false assumption, yet > > this draft describes the sender as "considered responsible for sending > > the message." Review the many assumptions being made before arriving at > > this conclusion. This false assumption is also why publishing SPF > > records is unwise for the majority of domain owners. > > The above language for "Pass" is actually somewhat less strict than > the responsibilities assigned in the draft-mengwong-spf-* drafts. The results remain unchanged. "Considered responsible for sending the message" represents an irresponsible conclusion. What assumptions permit this conclusion? Is it the domain owner that should know better than to trust their email provider? Or is it the recipient that should know better than trust the mailbox-domain to be legitimate? The statements in the introduction and what is implied by a Pass condition will result in considerable harm. > The draft-schlitt-spf-classic-* series of I-Ds is an attempt to > document what is, not what should or could be. This is not entirely true. This draft can still recommend deprecating the use of version 1 records, and document how version 2 records ARE being used. > > The need for checking the HELO would be to protect network resources > > using a unified name reputation service. The potential for hundreds > > of DNS queries to resolve something as simple as HELO means this > > scheme has a rather basic flaw. > > In theory, SPF HELO checking is far less than optimal, but in practice > it isn't that bad. Since you should publish SPF records at your HELO > domain if you publish SPF records at your MAIL FROM domain, a lot of > people are going to be publishing them. It is not clear to me that > any other system is enough better to motivate people to switch. The inordinate number of DNS lookups mandated by SPF to resolve a sizeable address list, when just a single host is being sought, pose serious indefensible risk. Motivation to change this practice will likely become a matter of necessity at some point. > > The prior justification for attempting to resolve the HELO was limited > > to the handling of a DSN message with a null MAILFROM. With SPF failure > > expected in this case, wouldn't something like BATV be more effective in > > this situation? > > Why would SPF failure be expected in this case? 2.1. The HELO Identity ... ,---- | Note that requirements for the domain presented in the EHLO or HELO | command are not always clear to the sending party, and SPF clients | must be prepared for the "HELO" identity to be malformed or an IP | address literal. At the time of this writing, many legitimate e-mails | are delivered with invalid HELO domains. `---- > There are several reasons why people like SPF, limiting blowback is > just one reason. Wouldn't BATV provide superior blow-back (DSN notifications sent to a spoofed bounce-address) protection? Unlike SPF, BATV achieves results when implemented unilaterally. Just removing original message content in the DSN would also deprecate spoofing the bounce-address as a delivery ploy for spam or viruses. > > 2.4. Checking Authorization > > ... > > ,---- > > | Without explicit approval of the domain owner, checking other > > | identities against SPF version 1 records is NOT RECOMMENDED because > > | there are cases that are known to give incorrect results. > > `---- > > > > Do you really think this sentence will cause a company to change their > > released version of Sender-ID? > > I don't know, but I do think that it is important to let people know > about the dangers. > > I think it is likely that developers will need to update their MARID > protocol implementations anyway. Instead of using the marid-protocol > document, they are now using the spf-classic document, and these two > documents are not completely compatible. When you say MARID, do you mean Sender-ID? It is unrealistic to expect Sender-ID will change. There are real and inexcusable dangers created by how the scope-less version 1 SPF record is interpreted. To insist that documented methods in the use of SPF records must exclude the scoped version of the record is nonsensical. This abstinence from scope enables a Sender-ID reputation trap. > > I fail to see the justification for not offering a positive means to > > express the scope of the record. > > Mark Lentczner was the one who convinced Meng to remove the scope= > modifier from the SPF spec in the fall of 2003. Hindsight is 20/20. The time lines of these decisions should not preclude becoming aware of a problem created by a competing draft. Once aware of the results of this capricious dismissal of a previously considered essential element, act to reintroduce scope. You should understand that publishing SPF records are not free from risk, even without errors. Much of the risk occurs as a result of those that mistake authorization for authentication. The domain supported by server authorization can not safely be assumed to have originated the message. While it could be possible to refuse messages that are not authorized by an SPF record demanding strict compliance, this is really not practical either. The real use for SPF is to offer greater protection for bulk email distributors by way of white-listing implemented by major providers. I would even recommend that there be a scope devised, such as admin, to specially limit the SPF record to this use. This would mean there are NO assurances being made for any mailbox-domain anywhere within the message. The domain owner simply wants to be trusted to do the right thing and does not want to risk any contained mailbox-domain becoming a victim of authorization-reputation. > > Depreciate the version 1 record. Both SPF "new classic" and > > Sender-ID may continue to utilize these older records. > > I see no particular reason why SPFv1 records should be depreciated. > They are well defined for the MAIL FROM and HELO identities which they > were published for. This version of the SPF record is also seen as applicable for the PRA. For a brief period of time it was. The draft that includes this scope for this early record also shares a common author. You are really in a weak position to insist they are wrong and you are right. You will not win this argument and harm those that believe otherwise. > > There have been many technologies thwarted by a large company's ability > > to dictate the definitions they promulgate. A large company may not be > > right or fair about their selection. Something as simple as data > > compression caused sizeable losses by a last minute imposition, even > > when eventually adjudicated as unfair. Accept this banal reality. > > Yes, that is possible. > > My admittedly limited data shows that almost no one is checking things > for the MARID protocol. At this time, it doesn't seem to be a > problem. Once insidious applications creep in that base reputations upon PRA authorizations, while using the Machiavellian user feedback, this will become a very real problem. I can imagine it now. "We supply the tools. These tools don't give mailbox-domains a bad reputation, people give mailbox-domains a bad reputation." -Doug From owner-ietf-mxcomp@mail.imc.org Thu Jun 9 20:51:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03895 for ; Thu, 9 Jun 2005 20:51:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5A0OQ0H089915; Thu, 9 Jun 2005 17:24:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5A0OQsc089914; Thu, 9 Jun 2005 17:24:26 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j5A0OOXV089908 for ; Thu, 9 Jun 2005 17:24:25 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DgXFV-0008Bf-PV for ietf-mxcomp@imc.org; Fri, 10 Jun 2005 02:19:50 +0200 Received: from du-001-066.access.de.clara.net ([212.82.227.66]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 10 Jun 2005 02:19:49 +0200 Received: from nobody by du-001-066.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 10 Jun 2005 02:19:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: Philosophical discussions Date: Fri, 10 Jun 2005 02:23:12 +0200 Organization: Lines: 23 Message-ID: <42A8DD70.4CCC@xyzzy.claranet.de> References: <42A81639.831@xyzzy.claranet.de> <20050609173044.4838D16D00@mail.nitros9.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-066.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: Content-Transfer-Encoding: 7bit Alan DeKok wrote: >> That's not necessarily "internal", > It's internal to the trust boundary of your domain. Yes, in that sense it's "internal" from your POV. > The purpose of philosophical discussions are to obtain a > common agreement as to the intent of the system. If no > one can agree on *why* the system exists, or *what* it's > supposed to be doing, then talking about *how* is a waste > of time. It's a bit like Euclidian geometry (maybe s/Euclid/Postel/) - and the bounces-to universe is the non-Euclidian geometry. You can't say that non-Euclidian geometry is "wrong". It's perfect, parallel lines cross each other, MAIL FROM actually means BOUNCES TO, the sum of degrees in a triangle isn't 180, and the responsible party is not the Return-Path, but hey, how about fixing it with a PRA ? Bye, Frank From owner-ietf-mxcomp@mail.imc.org Thu Jun 9 21:09:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07115 for ; Thu, 9 Jun 2005 21:09:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5A0jwoa091418; Thu, 9 Jun 2005 17:45:58 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5A0jwZD091417; Thu, 9 Jun 2005 17:45:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5A0jwrv091404 for ; Thu, 9 Jun 2005 17:45:58 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from SJC-Office-DHCP-156.Mail-Abuse.ORG (SJC-Office-DHCP-156.Mail-Abuse.ORG [168.61.10.156]) by harry.mail-abuse.org (Postfix) with ESMTP id 489E5414F1; Thu, 9 Jun 2005 17:45:51 -0700 (PDT) Subject: Re: Philosophical discussions (was Re: draft-schlitt-spf-classic-01.txt ) From: Douglas Otis To: Alan DeKok Cc: ietf-mxcomp@imc.org In-Reply-To: <20050609195151.648B216D00@mail.nitros9.org> References: <20050609195151.648B216D00@mail.nitros9.org> Content-Type: text/plain Date: Thu, 09 Jun 2005 17:45:50 -0700 Message-Id: <1118364351.7571.227.camel@SJC-Office-DHCP-156.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2005-06-09 at 15:51 -0400, Alan DeKok wrote: > Douglas Otis wrote: > > > From a reputation standpoint, this is not desirable from the > > perspective of the list operator, who would like any abuse to > > directly impact those they see as accountable. > > If I send a copy of a DVD to this list, and this list re-distributes > it, the list owner may be responsible for "contributory infringement". > Reputation affects both me as author of the message, and the list > owner as distributor. > > If we were to require that list owners *not* have their reputation > affected by messages they re-send, then spammers can hide behind lists. This would be a valid concern. On the other hand, if the original sender could be authenticated, and there was some breach of conduct, then seeking redress from this original sender would provide a fair method to deal with such offenses, without directly impacting the list server. This would also assume the list server would disable access when warranted. Authentication of the original sender would also inhibit spoofed messages from invoking errant retribution. > > Which proposal is that? It is not draft-schlitt-spf-classic-01, or > > draft-lyon-senderid-core-01. These two drafts are in serious conflict, > > and the Sender-ID draft claims that server authorization is equivalent > > to sender authentication, whether for the bounce-address or the PRA. Do > > you really think it is safe to ignore the intentions of Microsoft? > > Nope. And if all of the proposals are so terrible, we should see if > we can come up with another proposal that isn't so bad. I see DomainKeys, soon upgrade to DKIM, as a step in the right direction. Until I see the details regarding DKIM, I am unable to comment what remains to be done. I will speculate there is a need to introduce a somewhat independent layer of network resource protection in addition to a signature scheme. This will be especially important in areas where network connectivity is limited. It is yet to be seen whether signatures, by themselves, will be enough of a deterrent. My fear is when they become more effective following wide spread adoption, signatures will need to be aggressively defended. -Doug From owner-ietf-mxcomp@mail.imc.org Thu Jun 9 22:05:46 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10012 for ; Thu, 9 Jun 2005 22:05:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5A1YR59001919; Thu, 9 Jun 2005 18:34:27 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5A1YRdT001918; Thu, 9 Jun 2005 18:34:27 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j5A1YQoB001912 for ; Thu, 9 Jun 2005 18:34:26 -0700 (PDT) (envelope-from wayne@schlitt.net) Received: from footbone.schlitt.net ([67.52.51.37] helo=schlitt.net) by backbone.schlitt.net with esmtp (Exim 4.50) id 1DgYPZ-000213-KV for ietf-mxcomp@imc.org; Thu, 09 Jun 2005 20:34:25 -0500 To: "IETF MARID WG" References: <1118258112.7583.68.camel@SJC-Office-DHCP-156.mail-abuse.org> <1118346820.7571.140.camel@SJC-Office-DHCP-156.mail-abuse.org> From: wayne Mail-Copies-To: nobody Reply-To: "IETF MARID WG" Content-Type: text/plain; charset=US-ASCII Date: Thu, 09 Jun 2005 20:34:17 -0500 In-Reply-To: <1118346820.7571.140.camel@SJC-Office-DHCP-156.mail-abuse.org> (Douglas Otis's message of "Thu, 09 Jun 2005 12:53:40 -0700") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.schlitt.net: domain of schlitt.net designates 67.52.51.37 as permitted sender) client-ip=67.52.51.37; envelope-from=wayne@schlitt.net; helo=schlitt.net; problem=; X-SA-Exim-Connect-IP: 67.52.51.37 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: draft-schlitt-spf-classic-02.txt X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on backbone.schlitt.net X-Spam-Status: No, score=-6.7 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00, GREYLIST_ISWHITE autolearn=ham version=3.0.2 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: In <1118346820.7571.140.camel@SJC-Office-DHCP-156.mail-abuse.org> Douglas Otis writes: > On Wed, 2005-06-08 at 21:12 -0500, wayne wrote: >> Douglas Otis writes: >> >> The above language for "Pass" is actually somewhat less strict than >> the responsibilities assigned in the draft-mengwong-spf-* drafts. > > The results remain unchanged. "Considered responsible for sending the > message" represents an irresponsible conclusion. What assumptions > permit this conclusion? Is it the domain owner that should know better > than to trust their email provider? Or is it the recipient that should > know better than trust the mailbox-domain to be legitimate? The > statements in the introduction and what is implied by a Pass condition > will result in considerable harm. Well, SPFv1 has been deployed by thousands of domain owners since early 2004. After a year and a half of experience, only a very few people seem to think this risk is significant. I'm not going to debate this issue with you since we have done so in the past and I see no productive result of debating it again. >> The draft-schlitt-spf-classic-* series of I-Ds is an attempt to >> document what is, not what should or could be. > > This is not entirely true. This draft can still recommend deprecating > the use of version 1 records, and document how version 2 records ARE > being used. The whole point of spf-classic-* is to document how SPFv1 is being used. From what I can tell, version 2 records *aren't* being used, and therefore the MARID protocol *isn't* being used. >> > The need for checking the HELO would be to protect network resources >> > using a unified name reputation service. The potential for hundreds >> > of DNS queries to resolve something as simple as HELO means this >> > scheme has a rather basic flaw. >> >> In theory, SPF HELO checking is far less than optimal, but in practice >> it isn't that bad. [...] > > The inordinate number of DNS lookups mandated by SPF to resolve a > sizeable address list, when just a single host is being sought, pose > serious indefensible risk. Motivation to change this practice will > likely become a matter of necessity at some point. Ok. I disagree, but I'll grant you an "I told you so!" if it ever happens. >> There are several reasons why people like SPF, limiting blowback is >> just one reason. > > Wouldn't BATV provide superior blow-back (DSN notifications sent to a > spoofed bounce-address) protection? Unlike SPF, BATV achieves results > when implemented unilaterally. Just removing original message content > in the DSN would also deprecate spoofing the bounce-address as a > delivery ploy for spam or viruses. You can use BATV if you want. Personally, I think it is a poor re-invention of the ABBS/SES wheel, but YMMV. The point remains that limiting blowback is not the only reason people like SPF. >> > 2.4. Checking Authorization >> > ... >> > ,---- >> > | Without explicit approval of the domain owner, checking other >> > | identities against SPF version 1 records is NOT RECOMMENDED because >> > | there are cases that are known to give incorrect results. >> > `---- >> > >> > Do you really think this sentence will cause a company to change their >> > released version of Sender-ID? >> >> I don't know, but I do think that it is important to let people know >> about the dangers. >> >> I think it is likely that developers will need to update their MARID >> protocol implementations anyway. Instead of using the marid-protocol >> document, they are now using the spf-classic document, and these two >> documents are not completely compatible. > > When you say MARID, do you mean Sender-ID? Yes, when I say "the MARID protocol", I mean what was one called Sender-ID on this list. Andy checked with the powers that be within the IETF and they said that another name should be chosen due to the trademark conflicts with Sender ID. I am simply trying to follow that request. I'm going to skip the rest of your message. Again, these are old issues that I don't agree with your assessment and I have better things to do with my time than to repeat myself. -wayne From owner-ietf-mxcomp@mail.imc.org Fri Jun 10 11:31:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01196 for ; Fri, 10 Jun 2005 11:31:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5AF8IpB019442; Fri, 10 Jun 2005 08:08:18 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5AF8Ivh019441; Fri, 10 Jun 2005 08:08:18 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j5AF8GQj019434 for ; Fri, 10 Jun 2005 08:08:17 -0700 (PDT) (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 j5AF8F3u026561 for ; Fri, 10 Jun 2005 08:08:15 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id j5AF8Fhr026558 for ; Fri, 10 Jun 2005 08:08:15 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Fri, 10 Jun 2005 08:08:15 -0700 (PDT) From: "william(at)elan.net" To: ietf-mxcomp@imc.org Subject: Paper on Path and Cryptographic Authentication Technologies Message-ID: 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: Hi, I've finished and now making available full version of the paper on Email Security with Path and Cryptographic Authentication Methods - http://www.metasignatures.org/path_and_cryptographic_authentication.htm Printable PDF version of the paper (21 pages) is also available - http://www.metasignatures.org/Path_And_Cryptographic_Authentication.pdf About 3/4 of the paper is an overview of the various email anti-spoofing technology proposals that were/are discussed at MARID and MASS. Even though many people already know about these topics I think it'll be worth it for you to read (or at least glance through) anyway, parts on the overview and how its structured are unique as it has number of tables and focuses on how the technologies protect various email identities and these interactions and differences. There are also chapters on Accreditation and Reputation (including section on spamhaus .mail) and "authorization vs authenticity" question that has been raised by some when criticizing path authentication technologies - I explain that is really problem for both path and cryptographic proposals and its tied to question on if mail servers are "enforcing submission rights" at mail origin. The reminder 1/4 (chapter 6) of the paper is my proposal on how different path and cryptographic technologies can compliment each other. In particular I propose that cryptographic mail signature when added by MTA include "hostname" of the system adding the signature and this be considered an identity and be verifiable as being correct host that added the signature. After that path authentication technology can use verified hostname as the source for say SPF authorization (in place of where SMTP Client IP would normally be used), this allows to effectively bypass "forwarding problem" as SPF would now be able to directly verify if original source mail server that mail came though (before forwarding) is on list of mail systems authorized to be source of messages with given email address in MAILFROM or some other identity. Having bypassed forwarding problem this makes it possible to actually reject safely using SPF, although it requires number of additional policy records, including info that all source systems are adding signatures. ------------------------------------------------------------------------ IPR Disclosure: Algorithm I described above for doing path authorization after forwarding based on hostname from crypto signatures is patent pending. License is expected to be compatible with GPL programs. ----------------------------------------------------------------------- There is a public comment section open on website also where you can post your comments on the paper and its content and I'll gladly take those on the mail list or privately. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Fri Jun 10 15:33:17 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24129 for ; Fri, 10 Jun 2005 15:33:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5AJBvpI040392; Fri, 10 Jun 2005 12:11:57 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5AJBvrB040391; Fri, 10 Jun 2005 12:11:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5AJBvNg040381 for ; Fri, 10 Jun 2005 12:11:57 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from SJC-Office-DHCP-156.Mail-Abuse.ORG (SJC-Office-DHCP-156.Mail-Abuse.ORG [168.61.10.156]) by harry.mail-abuse.org (Postfix) with ESMTP id D44E5414F2 for ; Fri, 10 Jun 2005 12:11:36 -0700 (PDT) Subject: Re: draft-schlitt-spf-classic-02.txt From: Douglas Otis To: IETF MARID WG In-Reply-To: References: <1118258112.7583.68.camel@SJC-Office-DHCP-156.mail-abuse.org> <1118346820.7571.140.camel@SJC-Office-DHCP-156.mail-abuse.org> Content-Type: text/plain Date: Fri, 10 Jun 2005 12:11:35 -0700 Message-Id: <1118430695.8892.115.camel@SJC-Office-DHCP-156.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2005-06-09 at 20:34 -0500, wayne wrote: > Douglas Otis writes: > > > On Wed, 2005-06-08 at 21:12 -0500, wayne wrote: > >> Douglas Otis writes: > >> > >> The above language for "Pass" is actually somewhat less strict than > >> the responsibilities assigned in the draft-mengwong-spf-* drafts. > > > > The results remain unchanged. "Considered responsible for sending the > > message" represents an irresponsible conclusion. What assumptions > > permit this conclusion? Is it the domain owner that should know better > > than to trust their email provider? Or is it the recipient that should > > know better than trust the mailbox-domain to be legitimate? The > > statements in the introduction and what is implied by a Pass condition > > will result in considerable harm. > > Well, SPFv1 has been deployed by thousands of domain owners since > early 2004. After a year and a half of experience, only a very few > people seem to think this risk is significant. I'm not going to > debate this issue with you since we have done so in the past and I see > no productive result of debating it again. While you may have an opinion that risks of being mistakenly attributed for abuse is small, you should still offer a warning. Unfortunately your Introduction and description of PASS contributes to this risk, rather than providing requisite cautions. I doubt those finding themselves blocked will be comforted by claims their situation is not significant, nor worthy of consideration. Due to this lack of concern, their provider was not made aware of the added requirement of assuring mailbox-domain exclusivity to guard domain owner's reputations. You should also be aware of programs being announced that will increase the level of risk that continued spoofing may cause. I am not asking you to anticipate the actions of an abuser, but rather read announcements of major vendors. Consider where this is headed. Unlike IP address reputations, domain names may be treated on a more permanent basis, perhaps waiting for evidence of ownership change. A reputation based upon the domain name also provides no alternatives. Unlike a bad reputation for an IP address, a bad reputation for a domain name, even for a brief period, could be extremely damaging. In addition, there is no practical method for restitution, as these authorization/reputation systems will likely be processing the SPF record's multi-level results using a filtering-paradigm. This strategy may route a large number of messages into a never visited junk folder. : ( > >> The draft-schlitt-spf-classic-* series of I-Ds is an attempt to > >> document what is, not what should or could be. > > > > This is not entirely true. This draft can still recommend deprecating > > the use of version 1 records, and document how version 2 records ARE > > being used. > > The whole point of spf-classic-* is to document how SPFv1 is being > used. From what I can tell, version 2 records *aren't* being used, > and therefore the MARID protocol *isn't* being used. Does this change you mind? http://informationweek.com/story/showArticle.jhtml?articleID=164301210 While I am pleased to see the majority of major providers avoided publishing either version of an SPF record, there is always the possibility some provider will attempt to assert influence by way of acceptance criteria, perhaps found in some setup menu. Review AOL, ReturnPath, DoubleClick, or Skylist for examples of spf2.0/pra records. Hotmail only publishes v=spf1 records, by the way. Consider the impact the announced program will have. It is irresponsible to ignore this. While you may espouse some ideal for what is contained within spf-classic-*, there have been extensive efforts to re-engineer SPF within this document's many iterations. Dropping version 2 records from the start, redefining record limits, depreciating the wildcard, adding zone-cuts, removing zone-cuts, changing HELO handling, and then changing HELO handling again. Documenting version 2 of the SPF record may diminish an illusory claim of greater acceptance. However, when Sender-ID uses v=spf1 records, these claims reveal only wishful thinking. A claim of SPF versus Sender-ID acceptance would be possible, only by allowing the scope of the record to be explicitly declared. Once it becomes understood that providers must assure mailbox-domain exclusivity, and unless there is a means to ensure the PRA is not assumed, a responsible provider has the option of licensing the PRA algorithm or not publishing SPF records. Perhaps I should recommend an spf2.0/admin white-listing record. In my view, the only safe use of SPF would be for white-listing, where this should also have an explicit scope for this use as well. Such a white-listing scope may in effect say "Do not base my customer's reputation upon any server authorization, as mailbox-domain exclusivity is not assured." > >> > 2.4. Checking Authorization > >> > ... > >> > ,---- > >> > | Without explicit approval of the domain owner, checking other > >> > | identities against SPF version 1 records is NOT RECOMMENDED because > >> > | there are cases that are known to give incorrect results. > >> > `---- > >> > > >> > Do you really think this sentence will cause a company to change their > >> > released version of Sender-ID? > >> > >> I don't know, but I do think that it is important to let people know > >> about the dangers. > >> > >> I think it is likely that developers will need to update their MARID > >> protocol implementations anyway. Instead of using the marid-protocol > >> document, they are now using the spf-classic document, and these two > >> documents are not completely compatible. > > > > When you say MARID, do you mean Sender-ID? > > Yes, when I say "the MARID protocol", I mean what was one called > Sender-ID on this list. Andy checked with the powers that be within > the IETF and they said that another name should be chosen due to the > trademark conflicts with Sender ID. I am simply trying to follow > that request. I'll refer to the draft-lyon-senderid-core as Sender-ID to avoid confusion. I am not writing a spec using this term, nor making claims of use or ownership. -Doug From owner-ietf-mxcomp@mail.imc.org Fri Jun 10 16:38:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10548 for ; Fri, 10 Jun 2005 16:38:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5AKHCdN045667; Fri, 10 Jun 2005 13:17:12 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5AKHCrn045666; Fri, 10 Jun 2005 13:17:12 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j5AKHBUI045660 for ; Fri, 10 Jun 2005 13:17:11 -0700 (PDT) (envelope-from wayne@schlitt.net) Received: from footbone.schlitt.net ([67.52.51.37] helo=schlitt.net) by backbone.schlitt.net with esmtp (Exim 4.50) id 1Dgpw3-000820-El for ietf-mxcomp@imc.org; Fri, 10 Jun 2005 15:17:10 -0500 To: "IETF MARID WG" References: <1118258112.7583.68.camel@SJC-Office-DHCP-156.mail-abuse.org> <1118346820.7571.140.camel@SJC-Office-DHCP-156.mail-abuse.org> <1118430695.8892.115.camel@SJC-Office-DHCP-156.mail-abuse.org> From: wayne Mail-Copies-To: nobody Reply-To: "IETF MARID WG" Content-Type: text/plain; charset=US-ASCII Date: Fri, 10 Jun 2005 15:16:57 -0500 In-Reply-To: <1118430695.8892.115.camel@SJC-Office-DHCP-156.mail-abuse.org> (Douglas Otis's message of "Fri, 10 Jun 2005 12:11:35 -0700") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.schlitt.net: domain of schlitt.net designates 67.52.51.37 as permitted sender) client-ip=67.52.51.37; envelope-from=wayne@schlitt.net; helo=schlitt.net; X-SA-Exim-Connect-IP: 67.52.51.37 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: draft-schlitt-spf-classic-02.txt X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on backbone.schlitt.net X-Spam-Status: No, score=-6.7 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00, GREYLIST_ISWHITE autolearn=ham version=3.0.2 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: In <1118430695.8892.115.camel@SJC-Office-DHCP-156.mail-abuse.org> Douglas Otis writes: >> >> The draft-schlitt-spf-classic-* series of I-Ds is an attempt to >> >> document what is, not what should or could be. >> > >> > This is not entirely true. This draft can still recommend deprecating >> > the use of version 1 records, and document how version 2 records ARE >> > being used. >> >> The whole point of spf-classic-* is to document how SPFv1 is being >> used. From what I can tell, version 2 records *aren't* being used, >> and therefore the MARID protocol *isn't* being used. > > Does this change you mind? > http://informationweek.com/story/showArticle.jhtml?articleID=164301210 Considering that I posted a link to a similar story on the spf-discuss list when the MS PR went out, no, of course it doesn't change my mind. Note that I when I said "from what I can tell ... the MARID protocol *isn't* being used", I used the present tense, while that article talks about the future. > Hotmail only publishes v=spf1 records, by the way. Consider the impact > the announced program will have. It is irresponsible to ignore this. I have not ignored this. You may have already seen this, but it looks to me like the MARID protocol has a little ways to go before it accepted even as an experiemental standard. See: https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1573&filename=draft-lyon-senderid-core While it is quite possible that Microsoft will release Exchange 2003 SP2 with the MARID protocol despite "the conflicting use of the spf1 records between this proposal and the SPF proposal is harmful to the Internet." Microsoft is not immune to PR. > While you may espouse some ideal for what is contained within > spf-classic-*, there have been extensive efforts to re-engineer SPF > within this document's many iterations. Dropping version 2 records from > the start, Version 2 records were never part of SPFv1, they were never discussed in SPFv1 specifications, and so they were never dropped. > redefining record limits, The record limits have existed in the libspf2 implementation (the one I wrote) since Feb 2004, long before MARID was even opened. It is my understanding that some other SPF implementations have also implemented these limits. This is an existing practice, and a change to the spec that I feel is needed in order to make sure that SPF can not be used as an effective DoS amplifier. Yes, I did studies of the actual packets when I came up with these limits. Unfortunately, that study was done a year and a half ago, and don't have all the results now, just the conclusion. > depreciating the wildcard, I'm not sure what you mean here. SPF doesn't use wildcard DNS records. > , adding > zone-cuts, removing zone-cuts, Zone cuts were indeed added to the mengwong-spf-01 draft a over a year ago, and they were indeed removed from the schlitt-spf-classic-02 draft because they were not widely implemented and they were not popular with the folks on namedroppers. Several other unused features have been dropped from the schlitt-spf-classic-02 I-D. I think this is a good thing, YMMV. > changing HELO handling, and then changing > HELO handling again. Since the Dec 2003 "frozen" spec of SPF, the HELO handling has been changed from "when MAIL FROM is null", to "MAY be done always" in mengwong-spf-01, to "RECOMMENDED to be done always" in schlitt-spf-classic-02. SPF implementations that follow the Dec 2003 spec are still compliant today. > Documenting version 2 of the SPF record may > diminish an illusory claim of greater acceptance. However, when > Sender-ID uses v=spf1 records, these claims reveal only wishful > thinking. I'm not involved in the documenting of the spf2.0 records. > Perhaps I should recommend an spf2.0/admin white-listing record. In my > view, the only safe use of SPF would be for white-listing, where this > should also have an explicit scope for this use as well. Such a > white-listing scope may in effect say "Do not base my customer's > reputation upon any server authorization, as mailbox-domain exclusivity > is not assured." Feel free to write up an I-D saying so. -wayne From owner-ietf-mxcomp@mail.imc.org Fri Jun 10 17:34:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15097 for ; Fri, 10 Jun 2005 17:34:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5ALD3fV049696; Fri, 10 Jun 2005 14:13:03 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5ALD3F1049695; Fri, 10 Jun 2005 14:13:03 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j5ALD1EY049687 for ; Fri, 10 Jun 2005 14:13:02 -0700 (PDT) (envelope-from dean@av8.com) Received: from dakota.av8.net (dakota.av8.net [130.105.19.131]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id j5ALCukH001642 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 10 Jun 2005 17:13:00 -0400 Date: Fri, 10 Jun 2005 17:12:56 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: Alan DeKok cc: ietf-mxcomp@imc.org Subject: Re: draft-schlitt-spf-classic-01.txt In-Reply-To: <20050609163052.5976A16D00@mail.nitros9.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: It is interesting what you skipped. I didn't say you needed to show logs, but your coyness with the logs is, well, interesting. But you do need to describe what happened, and what steps you took. And you did describe it. However, the description isn't sufficient to justify any of the conclusions you assert. None of your 4 assertions hold water. Whether you _talked_ to a few or not makes no difference. A few might have been compromised. They all _might_ have been compromised. So what. That a few are compromised doesn't mean _all_ were compromised. Each has to be handled separately. It is quite reasonable for them to call you. Yet you assert it was unreasonable, and proof of their incompetence. And I _doubt_ very much that you were pleasant or reasonable with any of them: You think they are spammers complaining about getting ICMP unreachables. If you thought they were compromised, there would be no point in asking them for logs. You would simply ask them to check to see if they are sending you SYNs. But you didn't do that. No, you asked them to see their logs: "what? I can't possibly be sending you unreachables. Send me your logs." Helpful? Hardly. But you wouldn't want to be helpful to a spammer complaining about getting unreachables, now, would you? No. And if several _were_ compromised and attacking the same machine (it would take more than a few to generate the traffic you describe), it suggests that they were exploited by a botnet. When multiple sites are exploited, and all attack the same host, that's a good sign of a botnet operation. So your assertions that no botnet was involved is just completely, willfully, obstinately unsupportable. Botnet's change tactics once in while. That's one reason you have to treat case separately. It may send SYNs today, and forged packets tomorrow. And there is _still_ no evidence that any of the people that contacted you had any network misconfiguration. To the contrary, your assertion that blocking ICMP Unreachables means network misconfiguration is untrue. Your railing against them is simply unreasonable and irrational. But, of course, there is no way that you can be convinced you are wrong. Just like Chris Neill and many other ultra-radical extremists: You never admit wrongness, no matter how overwhelming the evidence. Even when Chris Neill was FIRED for his abuse and investigated by the FBI as a result, Neill __still__ didn't think he was wrong. Evidence of wrongness doesn't get much more overwhelming than that. So, there is little point in further discussion: You aren't or willing to rationally address any issues. That's fine: Think what you want. But I have to jump in once in a while to debunk such claims. --Dean On Thu, 9 Jun 2005, Alan DeKok wrote: > > Dean Anderson wrote: > > 4) It is possible that their system is compromised. > > When I talked with these people, the SYN's & ICMP's all stopped > after they claimed to have fixed their systems. > > This would lead any reasonable person to conclude that their system > was compromised (as I said), that the source and destination of SYN's > & ICMP's was exactly what they appeared to be (as I said), and that no > botnet was involved (as I said). > > > [now we have some options, depending on what Alan finds] > > In those options, you leave out the one option I've been telling you > repeatedly is what happened: their machine really was compromised, and > all of the traffic was exactly as it appeared, with no botnets or > forgeries. > > > To demonstrate his own due diligence, he would need to report what > > he found. > > I have no responsibility to show my logs to you, or to anyone else > on the planet. > > > Whether or not you actually have that data is irrelevant. You > > didn't use it to make your case to them, > > I didn't need to. They could independently verify for themselves > that their machine was compromised, was sending spam, and that their > machine was sending loads of TCP SYN's to my machine. They aren't > spammers because they aren't *intending* to send spam, it's a > side-effect of their network misconfiguration. > > I'm surprised that the one realistic interpretation of the events is > the only one you cannot admit might have happened. > > I won't respond to the rest of your comments about competence and > credibility. The evidence speaks for itself. > > Alan DeKok. > > > -- 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 Jun 10 20:20:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27138 for ; Fri, 10 Jun 2005 20:20:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5ANv9IN060738; Fri, 10 Jun 2005 16:57:09 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5ANv907060737; Fri, 10 Jun 2005 16:57:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5ANv9gY060710 for ; Fri, 10 Jun 2005 16:57:09 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from SJC-Office-DHCP-156.Mail-Abuse.ORG (SJC-Office-DHCP-156.Mail-Abuse.ORG [168.61.10.156]) by harry.mail-abuse.org (Postfix) with ESMTP id 4EE47414F2 for ; Fri, 10 Jun 2005 16:57:04 -0700 (PDT) Subject: Re: draft-schlitt-spf-classic-02.txt From: Douglas Otis To: IETF MARID WG In-Reply-To: References: <1118258112.7583.68.camel@SJC-Office-DHCP-156.mail-abuse.org> <1118346820.7571.140.camel@SJC-Office-DHCP-156.mail-abuse.org> <1118430695.8892.115.camel@SJC-Office-DHCP-156.mail-abuse.org> Content-Type: text/plain Date: Fri, 10 Jun 2005 16:57:03 -0700 Message-Id: <1118447823.8892.205.camel@SJC-Office-DHCP-156.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2005-06-10 at 15:16 -0500, wayne wrote: > Douglas Otis writes: > > You may have already seen this, but it looks to me like the MARID > protocol has a little ways to go before it accepted even as an > experimental standard. See: > > https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1573&filename=draft-lyon-senderid-core > > While it is quite possible that Microsoft will release Exchange 2003 > SP2 with the MARID protocol despite "the conflicting use of the spf1 > records between this proposal and the SPF proposal is harmful to the > Internet." Microsoft is not immune to PR. SPF defines DNS record handling and syntax, but oddly was not included in the list of I-Ds considered. It will fall upon spf-classic to resolve remaining record scoping conflicts. Perhaps the next time this comes up, there will be umpteen million copies of Sender-ID distributed. Surely you are not surprised by this? Do not depend upon anyone understanding the "scope" issue, when even the SPF draft gives this subject such short shrift. The average person will trust the system based upon misleading claims made in either draft, without becoming aware of the factors that may place them in peril. Explain the dependency on the provider making requisite exclusivity assurances of determinate mailbox-domains. As painful as this seems, plan on requesting the v=spf1 records be removed and replaced with "spf2.0/mfrom". (Perhaps you could see fit to define "spf2.0/".) > Version 2 records were never part of SPFv1, they were never discussed > in SPFv1 specifications, and so they were never dropped. These newer records preceded the spf-classic documentation effort, which is what I meant by dropped at the start. Do you remember why the newer scoped record was created? It seems an understandably hostile decision to exclude documenting use of this newer record. Had this scoped record been defined initially in this series of drafts, it would have been more widely employed. You want Sender-ID to be unable to utilize existing records, and don't want a method to define the scope. This needs to change. -Doug From owner-ietf-mxcomp@mail.imc.org Wed Jun 15 05:19:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25202 for ; Wed, 15 Jun 2005 05:19:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5F8oXZU090760; Wed, 15 Jun 2005 01:50:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5F8oXsB090758; Wed, 15 Jun 2005 01:50:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from arsenet.es (post.arsenet.com [212.85.33.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5F8oUWx090731 for ; Wed, 15 Jun 2005 01:50:31 -0700 (PDT) (envelope-from owner-spf-help@v2.listbox.com) Received: from arsenet-princip.ArSeNet-LasRozas.local ([212.85.32.32]:38039) by arsenet.es with [XMail 1.21 ESMTP Server] id for from ; Wed, 15 Jun 2005 10:48:57 +0200 Received: from mail pickup service by arsenet-princip.ArSeNet-LasRozas.local with Microsoft SMTPSVC; Wed, 15 Jun 2005 10:41:18 +0200 Delivered-To: juan@equinoccio.com X-AV-Scanned: yes 77ab56480df00addd1e8a37850f4ad81 thread-index: AcVl74b1K05nHmD7TEK4eiCRdtcIvw== Delivered-To: juan@equinoccio.com X-AV-Scanned: yes 8f2d524c56d70c3f5ae998356bda52c5 X-Injected-Via-Gmane: http://gmane.org/ To: , "IMB Recipient 1" From: "Frank Ellermann" Message-ID: <000d01c57185$ffda8ff0$fa01a8c0@ArSeNetLasRozas.local> Subject: [spf-help] Re: SPF and SenderID Date: Wed, 15 Jun 2005 10:41:18 +0200 Organization: Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 References: <4295C2D0.1000801@234.cx> 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-212.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Cc: Reply-To: List-ID: List-Software: listbox.com v2.0 List-Help: List-Subscribe: , List-Unsubscribe: , X-OriginalArrivalTime: 31 May 2005 14:46:32.0500 (UTC) FILETIME=[894C5F40:01C565EF] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Pete Chown wrote in spf-help: > What should I do now? Is there a way of supporting SPF > without helping to get a patented technology established > on the Internet? Sure. MS pretends to control spf2.0/pra to a certain degree, as defined in draft-lyon-senderid-pra-01 They certainly don't control all of spf2.0, as defined in draft-lyon-senderid-core-01 They never controlled a single bit of v=spf1 as defined in draft-schlitt-spf-classic-01 As long as you don't want PRA this doesn't affect you, v=spf1 is an open standard (wannabe from the IETF's POV, there's yet no RfC for it). MS tried to pull the stunt that v=spf1 is by default a part of PRA. This is a lie, the IESG knows that it's a lie, so senderid-lyon-core-01 can never pass as an RfC. Bye, Frank (Cc: mxcomp) ------- Archives at http://archives.listbox.com/spf-help/current/ Donate! http://spf.pobox.com/donations.html To unsubscribe, change your address, or temporarily deactivate your subscription, please go to http://v2.listbox.com/member/?member_id=1449865&user_secret=615bee79 ------- Archives at http://archives.listbox.com/spf-help/current/ Donate! http://spf.pobox.com/donations.html To unsubscribe, change your address, or temporarily deactivate your subscription, please go to http://v2.listbox.com/member/?member_id=1449865&user_secret=615bee79 From owner-ietf-mxcomp@mail.imc.org Wed Jun 15 10:53:46 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24097 for ; Wed, 15 Jun 2005 10:53:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5FETs4I088557; Wed, 15 Jun 2005 07:29:54 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5FETsrE088556; Wed, 15 Jun 2005 07:29:54 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j5FETrr9088550 for ; Wed, 15 Jun 2005 07:29:53 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from [192.168.2.11] (64-142-13-68.dsl.static.sonic.net [64.142.13.68]) (authenticated bits=0) by b.mail.sonic.net (8.13.3/8.13.3) with ESMTP id j5FETnf3005155 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 15 Jun 2005 07:29:50 -0700 Subject: Re: [spf-help] Re: SPF and SenderID From: Douglas Otis To: spf-help@v2.listbox.com Cc: IMB Recipient 1 , ietf-mxcomp@imc.org In-Reply-To: <000d01c57185$ffda8ff0$fa01a8c0@ArSeNetLasRozas.local> References: <4295C2D0.1000801@234.cx> <000d01c57185$ffda8ff0$fa01a8c0@ArSeNetLasRozas.local> Content-Type: text/plain Date: Wed, 15 Jun 2005 07:29:49 -0700 Message-Id: <1118845789.10007.17.camel@bash.adsl-64-142-13-68> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2005-06-15 at 10:41 +0200, Frank Ellermann wrote: > Pete Chown wrote in spf-help: > > > What should I do now? Is there a way of supporting SPF > > without helping to get a patented technology established > > on the Internet? > > Sure. > > MS pretends to control spf2.0/pra to a certain degree, as > defined in draft-lyon-senderid-pra-01 > > They certainly don't control all of spf2.0, as defined in > draft-lyon-senderid-core-01 > > They never controlled a single bit of v=spf1 as defined > in draft-schlitt-spf-classic-01 > > As long as you don't want PRA this doesn't affect you, > v=spf1 is an open standard (wannabe from the IETF's POV, > there's yet no RfC for it). > > MS tried to pull the stunt that v=spf1 is by default a > part of PRA. This is a lie, the IESG knows that it's a > lie, so senderid-lyon-core-01 can never pass as an RfC. > > Bye, Frank (Cc: mxcomp) This advice is based upon a false impression that Microsoft waits for an RFC before producing product. Recall draft-leach-cifs-v1-spec-02.txt? Consider spf2.0/mfrom and _removing_ v=spf1 as the safe reaction to Sender-ID. -Doug From owner-ietf-mxcomp@mail.imc.org Wed Jun 15 11:42:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27393 for ; Wed, 15 Jun 2005 11:42:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5FFBixS093494; Wed, 15 Jun 2005 08:11:44 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5FFBiwb093493; Wed, 15 Jun 2005 08:11:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5FFBho0093479 for ; Wed, 15 Jun 2005 08:11:43 -0700 (PDT) (envelope-from dotzero@gmail.com) Received: by rproxy.gmail.com with SMTP id f1so1305372rne for ; Wed, 15 Jun 2005 08:11:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WaWsQVCVRnAJO5uxwKMXpjHgkMVlBQodW9E8P8cNSwuYMAVA0gsTIv2QoMVtmj2YDAyUVy2XJRKzvHZIHJYZ6Kqa+d1hDexMvQRTzzrUwYh4h+hcd14QXAXezgO+JaSTjv/vRzEzz4+aTEogP3rY4GnsVD5yIac3HR0W5wktnU4= Received: by 10.38.98.13 with SMTP id v13mr2076716rnb; Wed, 15 Jun 2005 08:11:42 -0700 (PDT) Received: by 10.39.1.65 with HTTP; Wed, 15 Jun 2005 08:11:42 -0700 (PDT) Message-ID: <7ae58c220506150811272e8b73@mail.gmail.com> Date: Wed, 15 Jun 2005 11:11:42 -0400 From: Michael Hammer Reply-To: Michael Hammer To: Douglas Otis Subject: Re: [spf-help] Re: SPF and SenderID Cc: spf-help@v2.listbox.com, IMB Recipient 1 , ietf-mxcomp@imc.org In-Reply-To: <1118845789.10007.17.camel@bash.adsl-64-142-13-68> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <4295C2D0.1000801@234.cx> <000d01c57185$ffda8ff0$fa01a8c0@ArSeNetLasRozas.local> <1118845789.10007.17.camel@bash.adsl-64-142-13-68> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j5FFBho0093488 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 6/15/05, Douglas Otis wrote: > This advice is based upon a false impression that Microsoft waits for an > RFC before producing product. Recall draft-leach-cifs-v1-spec-02.txt? > Consider spf2.0/mfrom and _removing_ v=spf1 as the safe reaction to > Sender-ID. > Doug, This is exactly what Microsoft wants people to do. The correct action is for someone to force MS to back off (SPF Council, FTC, IETF,EU...anyone listening) from what is essentially a move to squash SPF. This could certainly be construed as an anti-competitive action. spf2.0/PRA lost in the marketplace. People simply weren't publishing the records. People were publishing spf1 records at a significant rate given that it wasn't even an "approved" standard. So, what better way to cause problems for SPF AND co-opt the spf1 records that people were publishing. You don't resolve an issue of someone doing a wrong thing by giving in through a work around that gives validation to the publication of "their" (SPF2.0) record. This also begs the question of who controls the SPF record format. Can anyone come up with their own mechanisms willy-nilly? Does the SPF Council control SPF? If not, who does? What about spf3.x and forward? As usual, just my 2 cents. Mike From owner-ietf-mxcomp@mail.imc.org Wed Jun 15 12:31:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01040 for ; Wed, 15 Jun 2005 12:31:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5FG4E5M001860; Wed, 15 Jun 2005 09:04:14 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5FG4EIM001859; Wed, 15 Jun 2005 09:04:14 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j5FG4DaO001851 for ; Wed, 15 Jun 2005 09:04:13 -0700 (PDT) (envelope-from wayne@schlitt.net) Received: from footbone.schlitt.net ([67.52.51.37] helo=schlitt.net) by backbone.schlitt.net with esmtp (Exim 4.50) id 1DiaN3-0005SD-MF for ietf-mxcomp@imc.org; Wed, 15 Jun 2005 11:04:12 -0500 To: "IETF MARID WG" References: <4295C2D0.1000801@234.cx> <000d01c57185$ffda8ff0$fa01a8c0@ArSeNetLasRozas.local> <1118845789.10007.17.camel@bash.adsl-64-142-13-68> <7ae58c220506150811272e8b73@mail.gmail.com> From: wayne Mail-Copies-To: nobody Reply-To: "IETF MARID WG" Content-Type: text/plain; charset=US-ASCII Date: Wed, 15 Jun 2005 11:04:04 -0500 In-Reply-To: <7ae58c220506150811272e8b73@mail.gmail.com> (Michael Hammer's message of "Wed, 15 Jun 2005 11:11:42 -0400") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.schlitt.net: domain of schlitt.net designates 67.52.51.37 as permitted sender) client-ip=67.52.51.37; envelope-from=wayne@schlitt.net; helo=schlitt.net; problem=; X-SA-Exim-Connect-IP: 67.52.51.37 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: [spf-help] Re: SPF and SenderID X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on backbone.schlitt.net X-Spam-Status: No, score=-6.7 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00, GREYLIST_ISWHITE autolearn=ham version=3.0.2 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: In <7ae58c220506150811272e8b73@mail.gmail.com> Michael Hammer writes: > This also begs the question of who controls the SPF record format. Can > anyone come up with their own mechanisms willy-nilly? Does the SPF > Council control SPF? If not, who does? What about spf3.x and forward? By submitting the SPF and SID drafts to the IETF, all of us have accepted that the IETF has a great deal of control over the spec. The IESG has said that, in order to be fair to SID and not show favoritism to SPF, both the SPF and SID drafts can say whatever they want about the use of SPFv1 records and that the SPF draft will be held back until the SID drafts are ready. Also, in order to be fair to SID, the IESG is discounting the 1.5 years of deployment experience with SPF so that both SPF and SID can start collecting deployment information now. OK, I can't start collecting data now, because the IESG refuses to tell me what kind of data they want to see. I'm sure this is to be fair to SID. Yes, the IESG is being very even handed and fair. For a slightly more realistic/accurate view of what the IESG actually said, see: http://thread.gmane.org/gmane.mail.spam.spf.council/312 -wayne From owner-ietf-mxcomp@mail.imc.org Wed Jun 15 13:06:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03878 for ; Wed, 15 Jun 2005 13:06:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5FGefcp011202; Wed, 15 Jun 2005 09:40:41 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5FGefNP011201; Wed, 15 Jun 2005 09:40:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (ftp.catinthebox.net [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id j5FGeexL011194 for ; Wed, 15 Jun 2005 09:40:40 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.1.451.4) for ietf-mxcomp@imc.org; Wed, 15 Jun 2005 12:41:54 -0400 Received: from ([68.223.217.251]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.1.451.4) with SMTP id 2605745671; Wed, 15 Jun 2005 12:41:52 -0400 Message-ID: <010201c571c8$e35d5630$6401a8c0@hdev1> From: "Hector Santos" To: "Douglas Otis" , Cc: References: <4295C2D0.1000801@234.cx> <000d01c57185$ffda8ff0$fa01a8c0@ArSeNetLasRozas.local> <1118845789.10007.17.camel@bash.adsl-64-142-13-68> Subject: Re: [spf-help] Re: SPF and SenderID Date: Wed, 15 Jun 2005 12:40:03 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Douglas Otis" To: Cc: "IMB Recipient 1" ; Sent: Wednesday, June 15, 2005 10:29 AM Subject: Re: [spf-help] Re: SPF and SenderID > > MS tried to pull the stunt that v=spf1 is by default a > > part of PRA. This is a lie, the IESG knows that it's a > > lie, so senderid-lyon-core-01 can never pass as an RfC. > > > > Bye, Frank (Cc: mxcomp) > > This advice is based upon a false impression that Microsoft waits for an > RFC before producing product. Recall draft-leach-cifs-v1-spec-02.txt? > Consider spf2.0/mfrom and _removing_ v=spf1 as the safe reaction to > Sender-ID. > > -Doug First, thanks for not writing a thesis on the subject. Second.................. Oh stop it Doug. Sender-ID will go down in the annals of computer history as yet another PAYLOAD "Get Pass the Door" security exploit that Microsoft pushes upon the industry in the name of non-existence "virtual email security innovation." It does not qualify as part of the "Trust Worthy Initiative" and Gates will put another foot in his mouth if he claims it is. Sender-ID is an unreliable PAYLOAD protocol and this is NOT want the industry is looking for. So you can keep down this ad-nausem path of knocking SPF every which way but loose, those who support Sender-ID will suffer scalarbility consequences of getting killed with higher bandwidth payloads. Hackers will BLAST away higher payloads just to help create the scale issues. Customers who "just do it" because its part of the MS package will then begin to blame MS as to why they didn't concentrate on a TRANSPORT solution BEFORE THE JUNK is transferred I predict corporate mal-practice and negligence suits because MS was very aware of the consequences. If our customers want it, they will have to add it via MAIL FILTER hooks. We will not take responsibility for fuzzy 2822 mail analysis technique and we will NOT de-emphasize the R&D required for 2821 methods. Our system is nearly 90-98% spam proof purely based on 2821 transactions. Do you really understand the issue? I really don't think you do. It is quite simple. A SPF FAIL is a FAIL. PERIOD. SENDER-ID is saying to NOT accept this response and to ACCEPT the PAYLOAD to do more checking on INFORMATION that MAY NOT be there and if was, the end results can just be as POOR in trust. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Wed Jun 15 14:04:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10310 for ; Wed, 15 Jun 2005 14:04:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5FHaHeo021895; Wed, 15 Jun 2005 10:36:17 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5FHaHOu021894; Wed, 15 Jun 2005 10:36:17 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j5FHaEQB021884 for ; Wed, 15 Jun 2005 10:36:15 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DibjD-0008Aq-Ok for ietf-mxcomp@imc.org; Wed, 15 Jun 2005 19:31:03 +0200 Received: from c-180-160-188.hh.dial.de.ignite.net ([62.180.160.188]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 15 Jun 2005 19:31:03 +0200 Received: from nobody by c-180-160-188.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 15 Jun 2005 19:31:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: [spf-help] Re: SPF and SenderID Date: Wed, 15 Jun 2005 19:34:49 +0200 Organization: Lines: 10 Message-ID: <42B066B9.2B20@xyzzy.claranet.de> References: <4295C2D0.1000801@234.cx> <000d01c57185$ffda8ff0$fa01a8c0@ArSeNetLasRozas.local> <1118845789.10007.17.camel@bash.adsl-64-142-13-68> <7ae58c220506150811272e8b73@mail.gmail.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: c-180-160-188.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit wayne wrote: > Yes, the IESG is being very even handed and fair. > This case of excessive technical incomptence or outright corruption is so far limited to _one_ member of the IESG. Bye, Frank From owner-ietf-mxcomp@mail.imc.org Wed Jun 15 14:49:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14236 for ; Wed, 15 Jun 2005 14:49:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5FIHxJa034633; Wed, 15 Jun 2005 11:17:59 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5FIHxsI034632; Wed, 15 Jun 2005 11:17:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id j5FIHwMo034622 for ; Wed, 15 Jun 2005 11:17:59 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id 3C4651A715; Wed, 15 Jun 2005 20:17:55 +0200 (CEST) Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) by bra.gulbrandsen.priv.no (Postfix) with SMTP id 4BA391A69D; Wed, 15 Jun 2005 20:17:30 +0200 (CEST) Message-Id: Date: Wed, 15 Jun 2005 20:17:15 +0200 From: Arnt Gulbrandsen To: ietf-mxcomp@imc.org Subject: Re: [spf-help] Re: SPF and SenderID Cc: Frank Ellermann References: <4295C2D0.1000801@234.cx> <000d01c57185$ffda8ff0$fa01a8c0@ArSeNetLasRozas.local> <1118845789.10007.17.camel@bash.adsl-64-142-13-68> <7ae58c220506150811272e8b73@mail.gmail.com> <42B066B9.2B20@xyzzy.claranet.de> In-Reply-To: <42B066B9.2B20@xyzzy.claranet.de> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Frank Ellermann writes: > This case of excessive technical incomptence or outright corruption is > so far limited to _one_ member of the IESG. Just a question: Does that IESG member happen to think that SPF suffers from poor workmanship? Arnt From owner-ietf-mxcomp@mail.imc.org Wed Jun 15 15:40:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20368 for ; Wed, 15 Jun 2005 15:40:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5FJEwYB050760; Wed, 15 Jun 2005 12:14:58 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5FJEv9p050758; Wed, 15 Jun 2005 12:14:57 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j5FJEuvj050744 for ; Wed, 15 Jun 2005 12:14:56 -0700 (PDT) (envelope-from wayne@schlitt.net) Received: from footbone.schlitt.net ([67.52.51.37] helo=schlitt.net) by backbone.schlitt.net with esmtp (Exim 4.50) id 1DidLc-00011a-7z for ietf-mxcomp@imc.org; Wed, 15 Jun 2005 14:14:55 -0500 To: "IETF MARID WG" References: <4295C2D0.1000801@234.cx> <000d01c57185$ffda8ff0$fa01a8c0@ArSeNetLasRozas.local> <1118845789.10007.17.camel@bash.adsl-64-142-13-68> <7ae58c220506150811272e8b73@mail.gmail.com> <42B066B9.2B20@xyzzy.claranet.de> From: wayne Mail-Copies-To: nobody Reply-To: "IETF MARID WG" Content-Type: text/plain; charset=US-ASCII Date: Wed, 15 Jun 2005 14:14:47 -0500 In-Reply-To: (Arnt Gulbrandsen's message of "Wed, 15 Jun 2005 20:17:15 +0200") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.schlitt.net: domain of schlitt.net designates 67.52.51.37 as permitted sender) client-ip=67.52.51.37; envelope-from=wayne@schlitt.net; helo=schlitt.net; problem=; X-SA-Exim-Connect-IP: 67.52.51.37 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: [spf-help] Re: SPF and SenderID X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on backbone.schlitt.net X-Spam-Status: No, score=-6.7 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00, GREYLIST_ISWHITE autolearn=ham version=3.0.2 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: In Arnt Gulbrandsen writes: > Just a question: Does that IESG member happen to think that SPF > suffers from poor workmanship? I have heard no such direct comment on the "workmanship". I suspect that many people in the IESG, like many others outside, find the subject of MTA Authorization Records In DNS (MARID) to be a controversial subject. I think David Kessens comments indicate that he doesn't particularly like SPF: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_comment&id=30894 Russ Housley echos those concerns: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_comment&id=31013 Harald Alvestrand seems to think that the wordsmithing, at least, is pretty good: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_comment&id=30972 It might be best to look at the entire datatracker for SPF: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12662&rfc_flag=0 -wayne From owner-ietf-mxcomp@mail.imc.org Wed Jun 15 17:12:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07215 for ; Wed, 15 Jun 2005 17:12:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5FKm8gb075808; Wed, 15 Jun 2005 13:48:08 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5FKm8wi075807; Wed, 15 Jun 2005 13:48:08 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j5FKm6cO075801 for ; Wed, 15 Jun 2005 13:48:06 -0700 (PDT) (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 j5FKm2Po005233; Wed, 15 Jun 2005 13:48:03 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id j5FKlrk5005230; Wed, 15 Jun 2005 13:47:57 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Wed, 15 Jun 2005 13:47:53 -0700 (PDT) From: "william(at)elan.net" To: Arnt Gulbrandsen cc: ietf-mxcomp@imc.org, Frank Ellermann Subject: Re: [spf-help] Re: SPF and SenderID In-Reply-To: Message-ID: References: <4295C2D0.1000801@234.cx> <000d01c57185$ffda8ff0$fa01a8c0@ArSeNetLasRozas.local> <1118845789.10007.17.camel@bash.adsl-64-142-13-68> <7ae58c220506150811272e8b73@mail.gmail.com> <42B066B9.2B20@xyzzy.claranet.de> 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: On Wed, 15 Jun 2005, Arnt Gulbrandsen wrote: > > Frank Ellermann writes: >> This case of excessive technical incomptence or outright corruption is so >> far limited to _one_ member of the IESG. > > Just a question: Does that IESG member happen to think that SPF suffers from > poor workmanship? I think it was quite clear that IESG wording had nothing to do with technical merits of the proposal(s) and was due to political pressure. And that is what worries me that IETF/IESG could be manipulated like that. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Wed Jun 15 19:30:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16200 for ; Wed, 15 Jun 2005 19:30:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5FN5cK0007657; Wed, 15 Jun 2005 16:05:38 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5FN5bQ4007656; Wed, 15 Jun 2005 16:05:37 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j5FN5WjX007617 for ; Wed, 15 Jun 2005 16:05:34 -0700 (PDT) (envelope-from dean@av8.com) Received: from dakota.av8.net (dakota.av8.net [130.105.19.131]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id j5FN5QKA015194 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 15 Jun 2005 19:05:28 -0400 Date: Wed, 15 Jun 2005 19:05:25 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: spf-help@v2.listbox.com cc: IMB Recipient 1 , Subject: Re: [spf-help] Re: SPF and SenderID In-Reply-To: <000d01c57185$ffda8ff0$fa01a8c0@ArSeNetLasRozas.local> 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: On Wed, 15 Jun 2005, Frank Ellermann wrote: > > Pete Chown wrote in spf-help: > > > What should I do now? Is there a way of supporting SPF > > without helping to get a patented technology established > > on the Internet? > > Sure. > > MS pretends to control spf2.0/pra to a certain degree, as > defined in draft-lyon-senderid-pra-01 I don't think you can conclude this. The patent claims haven't been released. All that happened is that MS identified that it has patent interests in the draft proposed by MS. That doesn't mean it doesn't have patent interests in other drafts proposed by non-MS personnel. Until the patent issues, and the patent claims are known, you can't say just how broad the patent is. -- 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 Jun 15 21:52:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28273 for ; Wed, 15 Jun 2005 21:52:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5G1T91U033752; Wed, 15 Jun 2005 18:29:09 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5G1T9q4033751; Wed, 15 Jun 2005 18:29:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5G1T87R033737 for ; Wed, 15 Jun 2005 18:29:08 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from SJC-Office-DHCP-156.Mail-Abuse.ORG (SJC-Office-DHCP-156.Mail-Abuse.ORG [168.61.10.156]) by harry.mail-abuse.org (Postfix) with ESMTP id BC2FA41502; Wed, 15 Jun 2005 18:29:05 -0700 (PDT) Subject: Re: [spf-help] Re: SPF and SenderID From: Douglas Otis To: Michael Hammer Cc: spf-help@v2.listbox.com, IMB Recipient 1 , ietf-mxcomp@imc.org In-Reply-To: <7ae58c220506150811272e8b73@mail.gmail.com> References: <4295C2D0.1000801@234.cx> <000d01c57185$ffda8ff0$fa01a8c0@ArSeNetLasRozas.local> <1118845789.10007.17.camel@bash.adsl-64-142-13-68> <7ae58c220506150811272e8b73@mail.gmail.com> Content-Type: text/plain Date: Wed, 15 Jun 2005 18:29:02 -0700 Message-Id: <1118885342.7565.91.camel@SJC-Office-DHCP-156.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2005-06-15 at 11:11 -0400, Michael Hammer wrote: > You don't resolve an issue of someone doing a wrong thing by giving in > through a work around that gives validation to the publication of > "their" (SPF2.0) record. For "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-MAIL, version 1", the listed authors are M. Wong, and W. Schlitt. For "Sender ID: Authenticating E-Mail" the listed authors are J. Lyon, and M. Wong. The "spf2.0/" record syntax was a product of the MARID WG specifically addressing this very issue. As all the authors participated in the MARID WG that identified this scope related problem, and as both of these drafts also credit common authorship, it would be impossible to say which draft is now authoritative for the "v=spf1" record. By excluding a solution for a known problem, how can it be said the draft for SPF based upon the bounce-address made any attempt to avoid this situation? At least Sender-ID accommodates use of the SPF2.0 record. On April 13, 2004 Wayne, in response to Harry Katz talked about the use of SPF2. By August 13, Mark Lentczner announced adoption of the "spf2.0/" instead of the "v=spf2" by the design team for the draft-ietf-marid-protocol-01. Checking the archive, around August 19, my email warns of the problem of assuming the PRA as a scope for the v=spf1 record. On August 25, Meng Wong introduced the "mfrom" scope as a solution. This was done amid growing concerns of the licensing required by Microsoft. It has been nearly a year to consider the impact of this problem. Only those that don't care about the scope of the record should publish "v=spf1". Those that care, should publish "spf2.0" records that declare the assured scope. -Doug From owner-ietf-mxcomp@mail.imc.org Wed Jun 15 22:56:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04713 for ; Wed, 15 Jun 2005 22:56:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5G2XGYs065186; Wed, 15 Jun 2005 19:33:16 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5G2XGnh065185; Wed, 15 Jun 2005 19:33:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5G2XD78065177 for ; Wed, 15 Jun 2005 19:33:16 -0700 (PDT) (envelope-from terry@ashtonwoodshomes.com) Received: from [10.243.102.72] ([216.191.52.74]) (authenticated bits=0) by mail.greatgulfhomes.com (8.12.8/8.12.8) with ESMTP id j5G2YZnM032738; Wed, 15 Jun 2005 22:34:35 -0400 Message-ID: <42B0E518.6010207@ashtonwoodshomes.com> Date: Wed, 15 Jun 2005 22:34:00 -0400 From: Terry Fielder User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Douglas Otis CC: Michael Hammer , spf-help@v2.listbox.com, IMB Recipient 1 , ietf-mxcomp@imc.org Subject: Re: [spf-help] Re: SPF and SenderID References: <4295C2D0.1000801@234.cx> <000d01c57185$ffda8ff0$fa01a8c0@ArSeNetLasRozas.local> <1118845789.10007.17.camel@bash.adsl-64-142-13-68> <7ae58c220506150811272e8b73@mail.gmail.com> <1118885342.7565.91.camel@SJC-Office-DHCP-156.mail-abuse.org> In-Reply-To: <1118885342.7565.91.camel@SJC-Office-DHCP-156.mail-abuse.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Douglas Otis wrote: > On Wed, 2005-06-15 at 11:11 -0400, Michael Hammer wrote: > > >>You don't resolve an issue of someone doing a wrong thing by giving in >>through a work around that gives validation to the publication of >>"their" (SPF2.0) record. > > > For "Sender Policy Framework (SPF) for Authorizing Use of Domains in > E-MAIL, version 1", the listed authors are M. Wong, and W. Schlitt. For > "Sender ID: Authenticating E-Mail" the listed authors are J. Lyon, and > M. Wong. The "spf2.0/" record syntax was a product of the MARID WG > specifically addressing this very issue. As all the authors > participated in the MARID WG that identified this scope related problem, Point 1: agreed > and as both of these drafts also credit common authorship, Point 2 (Meng): agreed > it would be > impossible to say which draft is now authoritative for the "v=spf1" > record. Point 3: Wrong, (Point 1 and point 2 do *not* add up to point 3, but good wordsmithing) > > By excluding a solution for a known problem, Wrong again, SID is not a solution for *anything*. > how can it be said the > draft for SPF based upon the bounce-address made any attempt to avoid > this situation? At least Sender-ID accommodates use of the SPF2.0 > record. On April 13, 2004 Wayne, in response to Harry Katz talked about > the use of SPF2. By August 13, Mark Lentczner announced adoption of the > "spf2.0/" instead of the "v=spf2" by the design team for the > draft-ietf-marid-protocol-01. Checking the archive, around August 19, > my email warns of the problem of assuming the PRA as a scope for the > v=spf1 record. On August 25, Meng Wong introduced the "mfrom" scope as > a solution. This was done amid growing concerns of the licensing > required by Microsoft. > > It has been nearly a year to consider the impact of this problem. Only > those that don't care about the scope of the record should publish > "v=spf1". Those that care, should publish "spf2.0" records that declare > the assured scope. You are entitled to your (albeit misguided) opinion. Terry > > -Doug > > > > -- Terry Fielder terry@greatgulfhomes.com Associate Director Software Development and Deployment Great Gulf Homes / Ashton Woods Homes Fax: (416) 441-9085 From owner-ietf-mxcomp@mail.imc.org Wed Jun 15 23:44:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12255 for ; Wed, 15 Jun 2005 23:44:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5G3HUDx085436; Wed, 15 Jun 2005 20:17:30 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5G3HUks085432; Wed, 15 Jun 2005 20:17:30 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j5G3HSau085408 for ; Wed, 15 Jun 2005 20:17:29 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Dikna-0006OG-DM for ietf-mxcomp@imc.org; Thu, 16 Jun 2005 05:12:10 +0200 Received: from 212.82.251.169 ([212.82.251.169]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 16 Jun 2005 05:12:10 +0200 Received: from nobody by 212.82.251.169 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 16 Jun 2005 05:12:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: SPF and SenderID Date: Thu, 16 Jun 2005 05:15:27 +0200 Organization: Lines: 12 Message-ID: <42B0EECF.41EC@xyzzy.claranet.de> References: <4295C2D0.1000801@234.cx> <000d01c57185$ffda8ff0$fa01a8c0@ArSeNetLasRozas.local> <1118845789.10007.17.camel@bash.adsl-64-142-13-68> <7ae58c220506150811272e8b73@mail.gmail.com> <42B066B9.2B20@xyzzy.claranet.de> 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: 212.82.251.169 X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Arnt Gulbrandsen wrote: > Does that IESG member happen to think that SPF suffers from > poor workmanship? That person changed [yes] to [discuss] after he found out that his removal of one critical "NOT RECOMMENDED" against the PRA- abuse doesn't fly with the SPF community. That person did not propose to remove the offending "SHOULD abuse v=spf1" from PRA. Bye, Frank From owner-ietf-mxcomp@mail.imc.org Thu Jun 16 16:14:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06150 for ; Thu, 16 Jun 2005 16:14:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5GJlcl6005028; Thu, 16 Jun 2005 12:47:38 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5GJlcmv005026; Thu, 16 Jun 2005 12:47:38 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j5GJla2q005007 for ; Thu, 16 Jun 2005 12:47:37 -0700 (PDT) (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 j5GJlX7p028848; Thu, 16 Jun 2005 12:47:33 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id j5GJlRhq028844; Thu, 16 Jun 2005 12:47:32 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 16 Jun 2005 12:47:27 -0700 (PDT) From: "william(at)elan.net" To: Ted Hardie cc: ietf-mxcomp@imc.org Subject: Re: SPF and SenderID In-Reply-To: Message-ID: References: <4295C2D0.1000801@234.cx> <000d01c57185$ffda8ff0$fa01a8c0@ArSeNetLasRozas.local> <1118845789.10007.17.camel@bash.adsl-64-142-13-68> <7ae58c220506150811272e8b73@mail.gmail.com> <42B066B9.2B20@xyzzy.claranet.de> <42B0EECF.41EC@xyzzy.claranet.de> 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: On Thu, 16 Jun 2005, Ted Hardie wrote: > A sponsoring AD always has a ballot position of YES when they bring > a document to the IESG. I don't think it is always. I will check datatracker more but I've definitely seen no objections from everyone including sponsoring AD for some documents (especially individual submissions for information or experimental track). > As was documented on the IETF list response to Wayne, there was no support > for at this time for publishing the spf draft as a Proposed Standard (to > be clear: the IESG was asked this question at a telechat, and no AD > thought it was appropriate). Could you be more specific on which day this telechat happened and if the logs/brief summary for it are available? > The IESG is currently considering moving forward on the basis of an IESG note > suggested by David Kessens. Once the IESG agrees that the document set > is ready, the sponsoring AD position will go back to YES. ... >> The IESG takes no position about which approach is to be preferred and >> cautions the reader that there are serious open issues for each approach I'd appreciate if you discussed more rational that went behind your note and its text. I do understand that IETF does not wish to take position on if authenticating PRA or MAILFROM identities is better choice for email. This is not new and its one of the reason that MARID probably failed as such decision may not have been something that we could easily find consensus on. But it seems to me taking not position on above is different then the note that you propose to add to the drafts. Also it appears to me the IESG criteria for when evaluating documents (especially for experimental status) is not necessarily to see if certain approach is good or bad for internet future but more importantly to make sure that proposal would not directly create problems for something else being done at IETF and most important to make sure that the proposal does not cause people to violate existing standards. So is my understanding about this being part of IESG evaluation wrong? > There has been a lot of discussion of this draft, and this short summary no > doubt misses some points, but I hope it clarifies the current state at > least somewhat It clarified some things but as often fr short summaries it raised more questions. I'd appreciate if you could find more time to discuss the drafts and how IESG evaluation of them went. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Thu Jun 16 16:45:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13973 for ; Thu, 16 Jun 2005 16:45:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5GKObHR045955; Thu, 16 Jun 2005 13:24:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5GKOb6e045954; Thu, 16 Jun 2005 13:24:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from miranda.server-plant.co.uk (miranda.server-plant.co.uk [193.110.88.60]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5GKOZRj045885 for ; Thu, 16 Jun 2005 13:24:36 -0700 (PDT) (envelope-from johnp@idimo.com) Received: from [83.230.186.233] ([83.230.186.233]) (authenticated) by miranda.server-plant.co.uk (8.11.6/8.11.2) with ESMTP id j5GKOIw08908; Thu, 16 Jun 2005 21:24:19 +0100 Message-ID: <42B1DFE7.7000204@idimo.com> Date: Thu, 16 Jun 2005 22:24:07 +0200 From: johnp User-Agent: Debian Thunderbird 1.0.2 (X11/20050331) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hardie@qualcomm.com CC: ietf-mxcomp@imc.org, spf-discuss@v2.listbox.com Subject: Re: SPF and SenderID - for your comments Chuck References: <4295C2D0.1000801@234.cx> <000d01c57185$ffda8ff0$fa01a8c0@ArSeNetLasRozas.local> <1118845789.10007.17.camel@bash.adsl-64-142-13-68> <7ae58c220506150811272e8b73@mail.gmail.com> <42B066B9.2B20@xyzzy.claranet.de> <42B0EECF.41EC@xyzzy.claranet.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit This is the relevant extract from the note suggested by David Kessens: https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1599&filename=draft-schlitt-spf-classic " I would have much preferred a solution that would be an extension to SMTP that simply checks back with one of the official MTA machines as listed in the 'mx' records for the domain whether the sending machine can be accepted, or just one simple DNS record with the name of the machine which is capable of doing the verification. The resulting protocol would be much simpler as all the configuration of the MTA doesn't need standarization as this information would not need to be published since it is not needed by any other than the 'mx' domain. From an operational perspective, the DNS solution also has issues since the DNS administrator is not necessarily the same as the mail administrator. " ------ Taking these points in turn - Unfortunately a domain does not have to have an MX record for it to be used for e-mail. If an A record exists, this is sufficient. Should the IETF/IESG choose to rectify that situation, the world of e-mail would already become an easier place to work in. SPF does have the ability to use a simple DNS record entry which can include the relevant detailed record from another zonefile, perhaps the zonefile of a subdomain. This would probably be the method of choice for large users of SPF, since it eliminates the necessity of maintaining a lot of records in each individual domain's zonefile. Operationally, any specialist DNS administrator will be able to accomodate his Mail administrator counter-part by allowing access to add, edit or remove the relevant DNS records required by SPF. Kind regards, John Pinkerton Ted Hardie wrote: > > At 5:15 AM +0200 6/16/05, Frank Ellermann wrote: > >> Arnt Gulbrandsen wrote: >> >>> Does that IESG member happen to think that SPF suffers from >>> poor workmanship? >> >> >> That person changed [yes] to [discuss] after he found out that >> his removal of one critical "NOT RECOMMENDED" against the PRA- >> abuse doesn't fly with the SPF community. That person did not >> propose to remove the offending "SHOULD abuse v=spf1" from PRA. >> >> Bye, Frank > > > All changes to the state of document are noted in a public ID tracker. > The URL for the tracker details for the SPF document is: > > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12662&rfc_flag=0 > > > A sponsoring AD always has a ballot position of YES when they bring > a document to the IESG. Sponsoring ADs often put in what are called > "placeholder DISCUSS" comments when there are issues raised outside > of the IESG (since those would otherwise not be tracked). Those > should have explanatory text. In this case,the explanatory text is: > > "Further discussion on the intended status and relationship to > MARID working group needed." > > This was entered to track the fact that the IESG needed to discuss > Wayne's comments > on the disconnect between his intentions as author and the original > draft solicited > after MARID closed (draft-lentczner). This discussion has continued > through Wayne's > request that the spf draft be considered for Proposed Standard, rather > than Experimental. > It also encompasses the problems raised by forwarding both documents; these > were raised both within and outside the IESG, and the IESG had discussed > them > at great length. > > As was documented on the IETF list response to Wayne, there was no > support for > at this time for publishing the spf draft as a Proposed Standard (to be > clear: the > IESG was asked this question at a telechat, and no AD thought it was > appropriate). > The IESG is currently considering moving forward on the basis of an IESG > note > suggested by David Kessens. Once the IESG agrees that the document set > is ready, the sponsoring AD position will go back to YES. For those who > find > navigating the tracker hard (and it can be non-intuitive), here's the text: > >> The following documents (draft-schlitt-spf-classic, >> draft-katz-submitter, >> draft-lyon-senderid-core, draft-lyon-senderid-pra) are published >> simultaneously >> as Experimental RFCs, although there is no general technical >> consensus and efforts to reconcile the two approaches >> have failed. As such these documents have not received full IETF review >> and are published "AS-IS" to document the different approaches as >> they were considered in the MARID working group. >> >> The IESG takes no position about which approach is to be preferred and >> cautions the reader that there are serious open issues for each approach >> and concerns about using them in tandem. The IESG >> believes that documenting the different approaches does less harm >> than not documenting them. >> >> The community is invited to observe the success or failure of the >> two approaches during the two years following publication, in >> order that a community consensus can be reached in the future. > > > The document names would be replaced by RFC numbers by the RFC Editor. > All other instructions to the RFC Editor (that is, all the text trying > to reconcile > the two) has been removed. > There has been a lot of discussion of this draft, and this short summary > no doubt > misses some points, but I hope it clarifies the current state at least > somewhat. > regards, > Ted Hardie > > > > From owner-ietf-mxcomp@mail.imc.org Thu Jun 16 17:54:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18546 for ; Thu, 16 Jun 2005 17:54:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5GLS2Hk018322; Thu, 16 Jun 2005 14:28:02 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5GLS2JJ018321; Thu, 16 Jun 2005 14:28:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5GLS296018203 for ; Thu, 16 Jun 2005 14:28:02 -0700 (PDT) (envelope-from hardie@qualcomm.com) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5GLRkdv011343; Thu, 16 Jun 2005 14:27:46 -0700 (PDT) Received: from [192.168.1.4] (vpn-10-50-0-91.qualcomm.com [10.50.0.91]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5GLRhuR026997; Thu, 16 Jun 2005 14:27:44 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4295C2D0.1000801@234.cx> <000d01c57185$ffda8ff0$fa01a8c0@ArSeNetLasRozas.local> <1118845789.10007.17.camel@bash.adsl-64-142-13-68> <7ae58c220506150811272e8b73@mail.gmail.com> <42B066B9.2B20@xyzzy.claranet.de> <42B0EECF.41EC@xyzzy.claranet.de> Date: Thu, 16 Jun 2005 14:27:42 -0700 To: "william(at)elan.net" From: Ted Hardie Subject: Re: SPF and SenderID Cc: ietf-mxcomp@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 12:47 PM -0700 6/16/05, william(at)elan.net wrote: >On Thu, 16 Jun 2005, Ted Hardie wrote: > >>A sponsoring AD always has a ballot position of YES when they bring >>a document to the IESG. > >I don't think it is always. I will check datatracker more but I've >definitely seen no objections from everyone including sponsoring AD >for some documents (especially individual submissions for information >or experimental track). There are two types of Information and Experimental documents; those which are sponsored by an AD and those which come from the RFC Editor to be checked for conflict with IETF work. In the latter case, you may well see blank spaces, all no-objections, or similar. In the former case, it might happen that something does not have a Yes because of something like a Last Call comment to be resolved simultaneously with IESG review, but it is unusual and considered as a "yes-->placeholder" collapsed. The IESG also asks different questions for the two tracks, because there is a set of IESG Notes automatically added to RFC Editor-sponsored documents. The review instructions for AD sponsored Informational and Experimentals is: > >Reviews should focus on these questions: "Is this document a reasonable >contribution to the area of Internet engineering which it covers? If >not, what changes would make it so?" The review instructions for RFC Editor-sponsored Informational and Experimentals is: > >The IESG will use RFC 3932 responses: 1) The IESG has not >found any conflict between this document and IETF work; 2) The >IESG thinks that this work is related to IETF work done in WG >, but this does not prevent publishing; 3) The IESG thinks >that publication is harmful to work in WG and recommends >not publishing at this time; 4) The IESG thinks that this >document violates the IETF procedures for and should >therefore not be published without IETF review and IESG >approval; 5) The IESG thinks that this document extends an >IETF protocol in a way that requires IETF review and should >therefore not be published without IETF review and IESG approval. > >Other matters may be recorded in comments to be passed on >to the RFC Editor as community review of the document. >>As was documented on the IETF list response to Wayne, there was no >>support for at this time for publishing the spf draft as a Proposed >>Standard (to be clear: the IESG was asked this question at a >>telechat, and no AD thought it was appropriate). > >Could you be more specific on which day this telechat happened and if >the logs/brief summary for it are available? It was the June 9th telechat; the minutes get approved at the following telechat (a week from today), and they'll be public then. The response to Wayne contains all the data, though: the IESG considered it, but did not find support for it. >>The IESG is currently considering moving forward on the basis of an IESG note >>suggested by David Kessens. Once the IESG agrees that the document set >>is ready, the sponsoring AD position will go back to YES. >... >>>The IESG takes no position about which approach is to be preferred and >>>cautions the reader that there are serious open issues for each approach > >I'd appreciate if you discussed more rational that went behind your note >and its text. I do understand that IETF does not wish to take position on >if authenticating PRA or MAILFROM identities is better choice for email. >This is not new and its one of the reason that MARID probably failed as >such decision may not have been something that we could easily find >consensus on. But it seems to me taking not position on above is >different then the note that you propose to add to the drafts. Just to be clear, David Kessens proposed the note; there has been some wordsmithing by others, but he was the person who brought it forward. I believe David has some basic concerns about the usability of either approach as well as concerns about using them in tandem. I don't want to speak for David, but I think these were not limited to the question of which identity is at issue. >Also it appears to me the IESG criteria for when evaluating >documents (especially for experimental status) is not necessarily to >see if certain approach is good or bad for internet future but more >importantly to make sure that proposal would not directly create >problems for something else being done at IETF and most important to >make sure that the proposal does not cause people to violate >existing standards. So is my understanding about this being part of >IESG evaluation wrong? See above for the evaluation instructions. regards, Ted Hardie From owner-ietf-mxcomp@mail.imc.org Thu Jun 16 18:18:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21004 for ; Thu, 16 Jun 2005 18:18:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5GHe47t061794; Thu, 16 Jun 2005 10:40:04 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5GHe3RM061792; Thu, 16 Jun 2005 10:40:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5GHe3NU061681 for ; Thu, 16 Jun 2005 10:40:03 -0700 (PDT) (envelope-from hardie@qualcomm.com) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5GHdudv017494 for ; Thu, 16 Jun 2005 10:39:56 -0700 (PDT) Received: from [192.168.1.4] (vpn-10-50-16-6.qualcomm.com [10.50.16.6]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j5GHdruR021994 for ; Thu, 16 Jun 2005 10:39:54 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <42B0EECF.41EC@xyzzy.claranet.de> References: <4295C2D0.1000801@234.cx> <000d01c57185$ffda8ff0$fa01a8c0@ArSeNetLasRozas.local> <1118845789.10007.17.camel@bash.adsl-64-142-13-68> <7ae58c220506150811272e8b73@mail.gmail.com> <42B066B9.2B20@xyzzy.claranet.de> <42B0EECF.41EC@xyzzy.claranet.de> Date: Thu, 16 Jun 2005 10:39:52 -0700 To: ietf-mxcomp@imc.org From: Ted Hardie Subject: Re: SPF and SenderID Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 5:15 AM +0200 6/16/05, Frank Ellermann wrote: >Arnt Gulbrandsen wrote: > >> Does that IESG member happen to think that SPF suffers from >> poor workmanship? > >That person changed [yes] to [discuss] after he found out that >his removal of one critical "NOT RECOMMENDED" against the PRA- >abuse doesn't fly with the SPF community. That person did not >propose to remove the offending "SHOULD abuse v=spf1" from PRA. > > Bye, Frank All changes to the state of document are noted in a public ID tracker. The URL for the tracker details for the SPF document is: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12662&rfc_flag=0 A sponsoring AD always has a ballot position of YES when they bring a document to the IESG. Sponsoring ADs often put in what are called "placeholder DISCUSS" comments when there are issues raised outside of the IESG (since those would otherwise not be tracked). Those should have explanatory text. In this case,the explanatory text is: "Further discussion on the intended status and relationship to MARID working group needed." This was entered to track the fact that the IESG needed to discuss Wayne's comments on the disconnect between his intentions as author and the original draft solicited after MARID closed (draft-lentczner). This discussion has continued through Wayne's request that the spf draft be considered for Proposed Standard, rather than Experimental. It also encompasses the problems raised by forwarding both documents; these were raised both within and outside the IESG, and the IESG had discussed them at great length. As was documented on the IETF list response to Wayne, there was no support for at this time for publishing the spf draft as a Proposed Standard (to be clear: the IESG was asked this question at a telechat, and no AD thought it was appropriate). The IESG is currently considering moving forward on the basis of an IESG note suggested by David Kessens. Once the IESG agrees that the document set is ready, the sponsoring AD position will go back to YES. For those who find navigating the tracker hard (and it can be non-intuitive), here's the text: >The following documents (draft-schlitt-spf-classic, draft-katz-submitter, >draft-lyon-senderid-core, draft-lyon-senderid-pra) are published >simultaneously >as Experimental RFCs, although there is no general technical >consensus and efforts to reconcile the two approaches >have failed. As such these documents have not received full IETF review >and are published "AS-IS" to document the different approaches as >they were considered in the MARID working group. > >The IESG takes no position about which approach is to be preferred and >cautions the reader that there are serious open issues for each approach >and concerns about using them in tandem. The IESG >believes that documenting the different approaches does less harm >than not documenting them. > >The community is invited to observe the success or failure of the >two approaches during the two years following publication, in >order that a community consensus can be reached in the future. The document names would be replaced by RFC numbers by the RFC Editor. All other instructions to the RFC Editor (that is, all the text trying to reconcile the two) has been removed. There has been a lot of discussion of this draft, and this short summary no doubt misses some points, but I hope it clarifies the current state at least somewhat. regards, Ted Hardie From owner-ietf-mxcomp@mail.imc.org Thu Jun 16 21:29:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03460 for ; Thu, 16 Jun 2005 21:29:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5H12iCf020482; Thu, 16 Jun 2005 18:02:44 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5H12iG4020481; Thu, 16 Jun 2005 18:02:44 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j5H12hDH020474 for ; Thu, 16 Jun 2005 18:02:43 -0700 (PDT) (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 j5H12ggH032563; Thu, 16 Jun 2005 18:02:42 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id j5H12ckU032560; Thu, 16 Jun 2005 18:02:42 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 16 Jun 2005 18:02:38 -0700 (PDT) From: "william(at)elan.net" To: Ted Hardie cc: ietf-mxcomp@imc.org Subject: Re: SPF and SenderID In-Reply-To: Message-ID: References: <4295C2D0.1000801@234.cx> <000d01c57185$ffda8ff0$fa01a8c0@ArSeNetLasRozas.local> <1118845789.10007.17.camel@bash.adsl-64-142-13-68> <7ae58c220506150811272e8b73@mail.gmail.com> <42B066B9.2B20@xyzzy.claranet.de> <42B0EECF.41EC@xyzzy.claranet.de> 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: On Thu, 16 Jun 2005, Ted Hardie wrote: > There are two types of Information and Experimental documents; those > which are sponsored by an AD and those which come from the RFC Editor > to be checked for conflict with IETF work. In the latter case, you may > well see blank spaces, all no-objections, or similar. In the former case, > it might happen that something does not have a Yes because of something > like a Last Call comment to be resolved simultaneously with IESG review, > but it is unusual and considered as a "yes-->placeholder" collapsed. Thank you for your explanation. > The IESG also asks different questions for the two tracks, because there > is a set of IESG Notes automatically added to RFC Editor-sponsored documents. > The review instructions for AD sponsored Informational and Experimentals is: >> >> Reviews should focus on these questions: "Is this document a reasonable >> contribution to the area of Internet engineering which it covers? If >> not, what changes would make it so?" If I understand based on IESG notes, it appears you're unable to answer the above question clearly. In particular that you say: "As such these documents have not received full IETF review and are published "AS-IS" to document the different approaches" and: "The IESG takes no position about which approach is to be preferred and cautions the reader that there are serious open issues for each approach and concerns about using them in tandem" > The review instructions for RFC Editor-sponsored Informational and > Experimentals is: >> >> The IESG will use RFC 3932 responses: 1) The IESG has not >> found any conflict between this document and IETF work; 2) The >> IESG thinks that this work is related to IETF work done in WG >> , but this does not prevent publishing; 3) The IESG thinks >> that publication is harmful to work in WG and recommends >> not publishing at this time; 4) The IESG thinks that this >> document violates the IETF procedures for and should >> therefore not be published without IETF review and IESG >> approval; 5) The IESG thinks that this document extends an >> IETF protocol in a way that requires IETF review and should >> therefore not be published without IETF review and IESG approval. So with RFC-Editor drafts, IESG is asked to evaluate the draft for conflict with other standards and IETF work, but not necessarily say that it agrees with it. That is good explanation, thank you. Nevertheless it is unclear to me why the above points would in the same way not apply to AD-sponsored drafts. If anything it would indicate that as initial criteria for being "sponsored" the draft would already have to have passed all above evaluation items and is now being considered by IETF not just as individual contribution for documentation of existing work but as something IETF is expected to provide some kind of approval on (even if its just for experiment). And overall (especially after reading your new note) the situation seems to be that SPF & SID drafts can not find approval of IESG so while they started as sponsored work, perhaps the situation right now (with IESG note saying that you just want it documented) is closer to the kind of documentation one would expect with draft being submitted through RFC-Editor. So I think it maybe more appropriately for IESG to directly reexamine evaluation criteria for the drafts and work with them in the say way you would work as if it were drafts coming from RFC-Editor. > Just to be clear, David Kessens proposed the note; there has been some > wordsmithing by others, but he was the person who brought it forward. > I believe David has some basic concerns about the usability of either > approach as well as concerns about using them in tandem. The problem is not just using them "in tandem", using in tandem would mean somebody doing both SPF and SID check on his/her system. The problem we have is different in that both drafts attempt to rely on the same record but use it differently, this is collision of namespaces for different experiments and it does seem like its something that IESG should be seriously concerned with. > I don't want to speak for David, but I think > these were not limited to the question of which identity is at issue. Is it possible to ask David to come to this list and explain more about his concerns? -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Fri Jun 17 10:19:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22058 for ; Fri, 17 Jun 2005 10:19:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5HDlktW049897; Fri, 17 Jun 2005 06:47:46 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5HDlkEe049877; Fri, 17 Jun 2005 06:47:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (ftp.catinthebox.net [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id j5HDlihT049686 for ; Fri, 17 Jun 2005 06:47:45 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.1.451.4) for ietf-mxcomp@imc.org; Fri, 17 Jun 2005 09:48:53 -0400 Received: from ([68.223.217.251]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.1.451.4) with SMTP id 2768164859; Fri, 17 Jun 2005 09:48:51 -0400 Message-ID: <006a01c57343$09834c90$6401a8c0@hdev1> From: "Hector Santos" To: "IETF-SMTP" , "IETF-MXCOMP" Subject: FYI: Interesting CAM SPAM court case as it relates to 2821 vs 2822 Date: Fri, 17 Jun 2005 09:46:56 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit CT. RULES FALSE CLAIMS IN EMAIL BODY FALLS OUTSIDE CAN-SPAM BNA's Electronic Commerce & Law Report reports that a federal court in Idaho has ruled that the CAN-SPAM Act does not supply a cause of action for false information included in the body of an allegedly unsolicited e-mail message. The court concluded that the anti-spam law only covers false information in email headers, not the text of the email. Case name is Internet Access Service Providers LLC v. Real Networks Inc. Article at For a free trial to the source of this story, visit http://www.bna.com/prodcuts/ip/eplr.htm From owner-ietf-mxcomp@mail.imc.org Fri Jun 17 15:35:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16751 for ; Fri, 17 Jun 2005 15:35:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5HJ90CX099063; Fri, 17 Jun 2005 12:09:00 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5HJ90Go099062; Fri, 17 Jun 2005 12:09:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5HJ8xci099050 for ; Fri, 17 Jun 2005 12:08:59 -0700 (PDT) (envelope-from dotzero@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so347156rng for ; Fri, 17 Jun 2005 12:08:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=OPp6QydIBQcro3N+kucwocOHI5gSLjcPWsS0ynTtFuhcLiQH5f/68ROgpzkPJnpsnm6WrZDxki5TdiKTUO1zZasyZgGddgYZzKTB6qEJSdN0hPWB8I7WOHdtAXzQnzPtdXwF0MWliAR4wTJWQ6cabOlLBM0wyO7dPH+qqJakhtE= Received: by 10.38.161.29 with SMTP id j29mr995947rne; Fri, 17 Jun 2005 12:08:59 -0700 (PDT) Received: by 10.39.1.65 with HTTP; Fri, 17 Jun 2005 12:08:59 -0700 (PDT) Message-ID: <7ae58c22050617120837c870e@mail.gmail.com> Date: Fri, 17 Jun 2005 15:08:59 -0400 From: Michael Hammer Reply-To: Michael Hammer To: Hector Santos Subject: Re: FYI: Interesting CAM SPAM court case as it relates to 2821 vs 2822 Cc: IETF-SMTP , IETF-MXCOMP In-Reply-To: <006a01c57343$09834c90$6401a8c0@hdev1> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <006a01c57343$09834c90$6401a8c0@hdev1> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j5HJ8xci099052 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Another link which provides a few more details: http://www.internetcases.com/archives/2005/06/no_spam_with_th_1.html From owner-ietf-mxcomp@mail.imc.org Fri Jun 17 16:13:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18903 for ; Fri, 17 Jun 2005 16:13:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5HJum2h050974; Fri, 17 Jun 2005 12:56:48 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5HJumtQ050973; Fri, 17 Jun 2005 12:56:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5HJul60050955 for ; Fri, 17 Jun 2005 12:56:47 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from SJC-Office-DHCP-156.Mail-Abuse.ORG (SJC-Office-DHCP-156.Mail-Abuse.ORG [168.61.10.156]) by harry.mail-abuse.org (Postfix) with ESMTP id 9562441502; Fri, 17 Jun 2005 12:56:42 -0700 (PDT) Subject: Re: [spf-help] Re: SPF and SenderID From: Douglas Otis To: Michael Hammer Cc: MARID , spf-help@v2.listbox.com In-Reply-To: <7ae58c2205061711276fdb8936@mail.gmail.com> References: <4295C2D0.1000801@234.cx> <000d01c57185$ffda8ff0$fa01a8c0@ArSeNetLasRozas.local> <1118845789.10007.17.camel@bash.adsl-64-142-13-68> <7ae58c220506150811272e8b73@mail.gmail.com> <1118885342.7565.91.camel@SJC-Office-DHCP-156.mail-abuse.org> <7ae58c2205061711276fdb8936@mail.gmail.com> Content-Type: text/plain Date: Fri, 17 Jun 2005 12:56:33 -0700 Message-Id: <1119038194.7574.180.camel@SJC-Office-DHCP-156.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2005-06-17 at 14:27 -0400, Michael Hammer wrote: > On 6/15/05, Douglas Otis wrote: > > > For "Sender Policy Framework (SPF) for Authorizing Use of Domains in > > E-MAIL, version 1", the listed authors are M. Wong, and W. Schlitt. For > > "Sender ID: Authenticating E-Mail" the listed authors are J. Lyon, and > > M. Wong. The "spf2.0/" record syntax was a product of the MARID WG > > specifically addressing this very issue. As all the authors > > participated in the MARID WG that identified this scope related problem, > > and as both of these drafts also credit common authorship, it would be > > impossible to say which draft is now authoritative for the "v=spf1" > > record. > > I would certainly agree with you that the waters have been muddied. I > have stated my opinion on that in other threads/locations so I won't > go there. The issue at hand though is whether IETF/IESG should accept > an ID (even experimental) which proposes to break the implementation > (existing) of a competing ID where the purported reason for doing so > comes down to "people won't publish the record we want (and > participate in our experiment) so we will force them to publish our > record, suffer bad outcomes or remove existing (SPF1) records all > together. >From the day of the SPF/Sender-ID merger in the interim meeting at Qualcomm, it has been clear the SPF record would be utilized to evaluate the PRA. Microsoft wanted to use their XML record, but the WG convinced them to use the existing record syntax. This is why Meng Wong eventually suggested the use of the "spf2.0/mfrom ..." record once the licensing issue became a concern. This is history that can not be changed. Especially by a third-party like IETF/IESG. You want the IESG to say who made the mistake? There were so many in sequence. > > It has been nearly a year to consider the impact of this problem. Only > > those that don't care about the scope of the record should publish > > "v=spf1". Those that care, should publish "spf2.0" records that declare > > the assured scope. > > I'm not sure how you can logically assert this Doug. People who > published v-=spf1 records didn't need to specify a scope because it > only applied to Mail From (and of course in the case of <> to HELO). This depends upon which era is considered, and which draft the publisher may have been reading. Meng's white-paper on the spf.pobox.com website: ,---- | Sender ID was recently resubmitted to the IETF. It now specifies that | both the return-path and the PRA may be used. Software that implements | only SPF Classic can therefore be called Sender ID compliant. In | practice, most people associate Sender ID with the PRA, and SPF | Classic with the mail from, or return-path. | | The author recommends that MUA software implement Sender ID with PRA | checking. The author recommends that MTA software implement Sender ID | with mail from checking, aka SPF Classic. '---- ,---- | One half of Sender ID is SPF Classic. The original SPF Classic | specification was frozen in early January 2004. It has evolved in only | minor details since then. It was submitted to the IETF in October 2004 | and is expected to be published as an experimental RFC. When it is | published, MTA vendors are encouraged to update their implementations | to match it. Vendors who implement SPF Classic can indicate that they | are Sender ID compliant. | | The other half of Sender ID is the PRA check. MTA vendors may also | wish to implement that half. Specifications describing the PRA and how | it fits into Sender ID were submitted to the IETF in October 2004 as | well. '---- The SPF spec is frozen, which is why it does not offer a solution to your dilemma. You would need to thaw it out before you could use the new and scope-safe record. According to Meng, both the bounce-address and the PRA SHOULD be used. Obviously, there is little concern regarding a reputation assessment described in a diagram on Page 11 of this paper. > To make a leap from there to "don't care" is quite a stretch. To Ex > Post Facto apply new logic and claim that to know the "new" intent of > the publisher of the record (published prior to the claim that the new > logic should be applied) can have no basis in fact or logic. You should review the histories of these two drafts. It is clear to me the authors of the "frozen in time" draft have not allowed themselves to deal with this conflict, as the PRA did not exist back then. This draft is just to document a distant point in history, nothing more. Reading the white paper, you would be hard pressed to even discern there was a problem. > It is certainly ironic that you are posting from @mail-abuse.org. > Could the action being discussed be called anything than mail (related > record) abuse? I am posting to the MARID reflector in order to express my views concerning the two drafts published. Your view of history is simply biased. What is preventing the use of "spf2.0/mform"? Why battle when there is a solution? You are talking about a mistake made by the group as a whole. We all make mistakes. Watch for the camel's nose next time. -Doug From owner-ietf-mxcomp@mail.imc.org Fri Jun 17 16:52:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21134 for ; Fri, 17 Jun 2005 16:52:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5HKRqKL085202; Fri, 17 Jun 2005 13:27:52 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5HKRqdd085197; Fri, 17 Jun 2005 13:27:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tomts36-srv.bellnexxia.net (tomts36.bellnexxia.net [209.226.175.93]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5HKRpnc085153 for ; Fri, 17 Jun 2005 13:27:51 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([70.50.109.221]) by tomts36-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050617202749.DSXY16985.tomts36-srv.bellnexxia.net@ibmrkydk2ufvdd> for ; Fri, 17 Jun 2005 16:27:49 -0400 X-IMBH: Yes From: "John Glube" To: "'IETF-MXCOMP'" Subject: RE: Interesting CAM SPAM court case as it relates to 2821 vs 2822 Date: Fri, 17 Jun 2005 16:27:40 -0400 Message-ID: <00df01c5737b$03478e80$6c62fea9@ibmrkydk2ufvdd> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <006a01c57343$09834c90$6401a8c0@hdev1> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j5HKRpnc085169 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit |-----Original Message----- |From: owner-ietf-mxcomp@mail.imc.org [mailto:owner-ietf-|mxcomp@mail.imc.org] On Behalf Of Hector Santos |Sent: June 17, 2005 9:47 AM |To: IETF-SMTP; IETF-MXCOMP |Subject: FYI: Interesting CAM SPAM court case as it relates to |2821 vs 2822 | | |CT. RULES FALSE CLAIMS IN EMAIL BODY FALLS OUTSIDE CAN-SPAM |BNA's Electronic Commerce & Law Report reports that a |federal court in Idaho has ruled that the CAN-SPAM Act does |not supply a cause of action for false information included |in the body of an allegedly unsolicited e-mail message. The |court concluded that the anti-spam law only covers false |information in email headers, not the text of the email. |Case name is Internet Access Service Providers LLC v. Real |Networks Inc. Article at | |For a free trial to the source of this story, visit |http://www.bna.com/prodcuts/ip/eplr.htm Internet access services were given a private right of action under section 7 of the Act: |A provider of Internet access service adversely affected by a |violation of section 5(a)(1), 5(b), or 5(d), or a pattern or |practice that violates paragraph (2), (3), (4), or (5) of |section 5(a), may bring a civil action in any district court of |the United States with jurisdiction over the defendant. My understanding is that in this case the Internet access service did not plead the case properly. The plaintiff failed to claim: |* It was adversely affected by a violation of section 5 (a) 1 |[False header information which includes the from address]; 5 |(b) [Aggravated Violations arising when commercial mail sent |with false header information]; 5(d), or |* It was adversely affected by a pattern or practice that |violates paragraph (2) [Deceptive subject headings]; (3) [Not |including return address or functioning mechanism to allow |recipient to "opt-out"]; (4) [Sending commercial email after |recipient "objects"] (5) [Not including 'identifier, opt-out and |physical address' in commercial email]. As a result the case was dismissed upon the defendant's motion. However, it is not correct to make the bald statement: |"The court concluded that the anti-spam law only covers false |information in email headers, not the text of the email." The Act not only regulates the subject heading, but also mandates certain inclusions in the text and regulates the text content when determining the message primary purpose in accordance with the rules published by the FTC. As an aside, in my view, the Act is fundamentally flawed as it imposes no obligations on volume control of UBCE. On this point, it is interesting to see how the FTC's counsel summarizes the FTC's consumer protection mission under the Act: |Controlling the Assault of Non-Solicited Pornography and |Marketing Act of 2003 |(CAN-SPAM Act) (15 U.S.C §§ 7701-7713) |This Act establishes requirements for those who send unsolicited |commercial email. The Act bans false or misleading header |information and prohibits deceptive subject lines. It also |requires that unsolicited commercial email provide recipients |with a method for opting out of receiving such email and must be |identified as an advertisement. In addition to enforcing the |statute, the FTC must issue rules involving the required |labeling of sexually explicit commercial email and the criteria |for determining the primary purpose of a commercial email. The |Act also instructs the Commission to report to Congress on the |feasibility of a National Do-Not-E-Mail Registry, as well as |requiring reports on the labeling of all unsolicited commercial |email, the creation of a “bounty system” to promote enforcement |of the law, and the effectiveness and enforcement of the |statute. Of course this is a separate discussion, so I will stop here. John Glube Toronto, Canada From owner-ietf-mxcomp@mail.imc.org Fri Jun 17 18:28:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28212 for ; Fri, 17 Jun 2005 18:28:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5HM3aW5093815; Fri, 17 Jun 2005 15:03:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5HM3aK4093814; Fri, 17 Jun 2005 15:03:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (ftp.catinthebox.net [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id j5HM3Zxm093781 for ; Fri, 17 Jun 2005 15:03:35 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.1.451.4) for ietf-mxcomp@imc.org; Fri, 17 Jun 2005 18:04:53 -0400 Received: from ([68.223.217.251]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.1.451.4) with SMTP id 2797925562; Fri, 17 Jun 2005 18:04:52 -0400 Message-ID: <013d01c57388$53ad9b00$6401a8c0@hdev1> From: "Hector Santos" To: "IETF-MXCOMP" References: <00df01c5737b$03478e80$6c62fea9@ibmrkydk2ufvdd> Subject: Re: Interesting CAM SPAM court case as it relates to 2821 vs 2822 Date: Fri, 17 Jun 2005 18:02:57 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "John Glube" To: "'IETF-MXCOMP'" Sent: Friday, June 17, 2005 4:27 PM Subject: RE: Interesting CAM SPAM court case as it relates to 2821 vs 2822 > However, it is not correct to make the bald statement: > > |"The court concluded that the anti-spam law only covers false > |information in email headers, not the text of the email." > The Act not only regulates the subject heading, but also mandates > certain inclusions in the text and regulates the text content > when determining the message primary purpose in accordance with > the rules published by the FTC. My fundamental intepretation of the CAN-SPAM that it was a compromise to allow SPAM as long as the SPAMMER did not lie about: - Who Sent it (Sender) - Topic Identification (Subject) and it gave the IETF 18 months to define how SPAMMERS will do it. What I found interesting is that it held with my belief that we do have the law (atleast in the US) behind us when it comes to making sure the 2821 and 2822 entities are valid. We always did, but much less with 2822 because it has been relaxed over the years. Original 822 required: Date: From, To 2822 relaxed this to: Date: From: and now we have a draft from Bruce Lilly that wants to relax it move by removing From requirement. > As an aside, in my view, the Act is fundamentally flawed as it > imposes no obligations on volume control of UBCE. This is already covered by other provisions of US federal laws - property harm basically. AOL used this against many. > John Glube > Toronto, Canada You know Canada has some agressive and interesting email related bills. I recall one article from the BNA newsletters I received (a great collection of IP/High Tech and the law related news events), about a bill in Canada that will make it manatory for all ISPs to have AVS Software installed. Not having it could result in a mal-practice claim. I don't know it that ever passed or not. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Sun Jun 19 08:55:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02514 for ; Sun, 19 Jun 2005 08:55:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5JCC6DY018163; Sun, 19 Jun 2005 05:12:06 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5JCC6Of018162; Sun, 19 Jun 2005 05:12:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5JCC3NK018100 for ; Sun, 19 Jun 2005 05:12:05 -0700 (PDT) (envelope-from terry@ashtonwoodshomes.com) Received: from [10.243.102.72] ([216.191.52.74]) (authenticated bits=0) by mail.greatgulfhomes.com (8.12.8/8.12.8) with ESMTP id j5JCDd6E015462; Sun, 19 Jun 2005 08:13:40 -0400 Message-ID: <42B56149.8080707@ashtonwoodshomes.com> Date: Sun, 19 Jun 2005 08:12:57 -0400 From: Terry Fielder User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Douglas Otis CC: Michael Hammer , MARID , spf-help@v2.listbox.com Subject: Re: [spf-help] Re: SPF and SenderID References: <4295C2D0.1000801@234.cx> <000d01c57185$ffda8ff0$fa01a8c0@ArSeNetLasRozas.local> <1118845789.10007.17.camel@bash.adsl-64-142-13-68> <7ae58c220506150811272e8b73@mail.gmail.com> <1118885342.7565.91.camel@SJC-Office-DHCP-156.mail-abuse.org> <7ae58c2205061711276fdb8936@mail.gmail.com> <1119038194.7574.180.camel@SJC-Office-DHCP-156.mail-abuse.org> In-Reply-To: <1119038194.7574.180.camel@SJC-Office-DHCP-156.mail-abuse.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Douglas Otis wrote: > On Fri, 2005-06-17 at 14:27 -0400, Michael Hammer wrote: > >>On 6/15/05, Douglas Otis wrote: >> >> >>>For "Sender Policy Framework (SPF) for Authorizing Use of Domains in >>>E-MAIL, version 1", the listed authors are M. Wong, and W. Schlitt. For >>>"Sender ID: Authenticating E-Mail" the listed authors are J. Lyon, and >>>M. Wong. The "spf2.0/" record syntax was a product of the MARID WG >>>specifically addressing this very issue. As all the authors >>>participated in the MARID WG that identified this scope related problem, >>>and as both of these drafts also credit common authorship, it would be >>>impossible to say which draft is now authoritative for the "v=spf1" >>>record. >> >>I would certainly agree with you that the waters have been muddied. I >>have stated my opinion on that in other threads/locations so I won't >>go there. The issue at hand though is whether IETF/IESG should accept >>an ID (even experimental) which proposes to break the implementation >>(existing) of a competing ID where the purported reason for doing so >>comes down to "people won't publish the record we want (and >>participate in our experiment) so we will force them to publish our >>record, suffer bad outcomes or remove existing (SPF1) records all >>together. > > >>From the day of the SPF/Sender-ID merger in the interim meeting at > Qualcomm, it has been clear the SPF record would be utilized to evaluate > the PRA. Microsoft wanted to use their XML record, but the WG convinced > them to use the existing record syntax. Inaccurate at best, the working group convinced MS not to put bloated inefficient unnecessary XML records in DNS. It had nothing to do with "convincing MS to use their syntax", it had to do with "don't make SPF have to use an XML format" Terry > This is why Meng Wong > eventually suggested the use of the "spf2.0/mfrom ..." record once the > licensing issue became a concern. This is history that can not be > changed. Especially by a third-party like IETF/IESG. You want the IESG > to say who made the mistake? There were so many in sequence. > > >>>It has been nearly a year to consider the impact of this problem. Only >>>those that don't care about the scope of the record should publish >>>"v=spf1". Those that care, should publish "spf2.0" records that declare >>>the assured scope. >> >>I'm not sure how you can logically assert this Doug. People who >>published v-=spf1 records didn't need to specify a scope because it >>only applied to Mail From (and of course in the case of <> to HELO). > > > This depends upon which era is considered, and which draft the publisher > may have been reading. > > Meng's white-paper on the spf.pobox.com website: > ,---- > | Sender ID was recently resubmitted to the IETF. It now specifies that > | both the return-path and the PRA may be used. Software that implements > | only SPF Classic can therefore be called Sender ID compliant. In > | practice, most people associate Sender ID with the PRA, and SPF > | Classic with the mail from, or return-path. > | > | The author recommends that MUA software implement Sender ID with PRA > | checking. The author recommends that MTA software implement Sender ID > | with mail from checking, aka SPF Classic. > '---- > ,---- > | One half of Sender ID is SPF Classic. The original SPF Classic > | specification was frozen in early January 2004. It has evolved in only > | minor details since then. It was submitted to the IETF in October 2004 > | and is expected to be published as an experimental RFC. When it is > | published, MTA vendors are encouraged to update their implementations > | to match it. Vendors who implement SPF Classic can indicate that they > | are Sender ID compliant. > | > | The other half of Sender ID is the PRA check. MTA vendors may also > | wish to implement that half. Specifications describing the PRA and how > | it fits into Sender ID were submitted to the IETF in October 2004 as > | well. > '---- > > The SPF spec is frozen, which is why it does not offer a solution to > your dilemma. You would need to thaw it out before you could use the > new and scope-safe record. According to Meng, both the bounce-address > and the PRA SHOULD be used. Obviously, there is little concern > regarding a reputation assessment described in a diagram on Page 11 of > this paper. > > >>To make a leap from there to "don't care" is quite a stretch. To Ex >>Post Facto apply new logic and claim that to know the "new" intent of >>the publisher of the record (published prior to the claim that the new >>logic should be applied) can have no basis in fact or logic. > > > You should review the histories of these two drafts. It is clear to me > the authors of the "frozen in time" draft have not allowed themselves to > deal with this conflict, as the PRA did not exist back then. This draft > is just to document a distant point in history, nothing more. Reading > the white paper, you would be hard pressed to even discern there was a > problem. > > >>It is certainly ironic that you are posting from @mail-abuse.org. >>Could the action being discussed be called anything than mail (related >>record) abuse? > > > I am posting to the MARID reflector in order to express my views > concerning the two drafts published. Your view of history is simply > biased. What is preventing the use of "spf2.0/mform"? Why battle when > there is a solution? You are talking about a mistake made by the group > as a whole. We all make mistakes. Watch for the camel's nose next > time. > > -Doug > > > > -- Terry Fielder terry@greatgulfhomes.com Associate Director Software Development and Deployment Great Gulf Homes / Ashton Woods Homes Fax: (416) 441-9085 From owner-ietf-mxcomp@mail.imc.org Mon Jun 20 07:59:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19052 for ; Mon, 20 Jun 2005 07:59:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5KBbPST037781; Mon, 20 Jun 2005 04:37:25 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5KBbPnV037776; Mon, 20 Jun 2005 04:37:25 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j5KBbOvx037712 for ; Mon, 20 Jun 2005 04:37:24 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from [62.138.102.6] ([62.138.102.6]) (authenticated bits=0) by b.mail.sonic.net (8.13.3/8.13.3) with ESMTP id j5KBXDw5008212 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 20 Jun 2005 04:33:15 -0700 Subject: Re: [spf-help] Re: SPF and SenderID From: Douglas Otis To: Terry Fielder Cc: Michael Hammer , MARID , spf-help@v2.listbox.com In-Reply-To: <42B56149.8080707@ashtonwoodshomes.com> References: <4295C2D0.1000801@234.cx> <000d01c57185$ffda8ff0$fa01a8c0@ArSeNetLasRozas.local> <1118845789.10007.17.camel@bash.adsl-64-142-13-68> <7ae58c220506150811272e8b73@mail.gmail.com> <1118885342.7565.91.camel@SJC-Office-DHCP-156.mail-abuse.org> <7ae58c2205061711276fdb8936@mail.gmail.com> <1119038194.7574.180.camel@SJC-Office-DHCP-156.mail-abuse.org> <42B56149.8080707@ashtonwoodshomes.com> Content-Type: text/plain Date: Mon, 20 Jun 2005 04:33:12 -0700 Message-Id: <1119267192.8517.102.camel@littlejoy> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sun, 2005-06-19 at 08:12 -0400, Terry Fielder wrote: > Douglas Otis wrote: > > > > From the day of the SPF/Sender-ID merger in the interim meeting at > > Qualcomm, it has been clear the SPF record would be utilized to evaluate > > the PRA. Microsoft wanted to use their XML record, but the WG convinced > > them to use the existing record syntax. > > Inaccurate at best, the working group convinced MS not to put bloated > inefficient unnecessary XML records in DNS. It had nothing to do with > "convincing MS to use their syntax", it had to do with "don't make SPF > have to use an XML format" Part of the pitch for the SPF syntax, during the transition from the bounce-address to the PRA, included using the _exact_ syntax to avoid causing a change to the existing record. It has become obvious, this was a mistake from the point of view of the bounce-address-only proponents. It is also clear from the onset of the requests to publish SPF records, little consideration has been given to the potential outcome when reputation is applied. Although I repeatedly warned SPF does NOT prevent spoofing and that this assumption is dangerous for those that share outbound MTA servers, this caution was never heeded. The typical response from various proponents has been, "It is the publisher's fault for not considering these potential problems." It is also the proponent's fault for failing to provide _any_ warning regarding these concerns. It is rather outrageous to see statements like "Everyone and their dog should publish SPF records." This advice should include, "provided you and your dog control exclusive access to the authorized outbound MTA." If the MTA is being shared, then you and your dog should be indemnified by your outbound service provider against their not maintaining your exclusive use of both the bounce-address and the PRA. It is not surprising that SPF promoters don't care what problems they may cause the average mailbox-domain owner. Often these promoters are bulk email service providers or network service providers looking to escape accountability when one of their customers abuses email. An understandable goal and one safely achieved using email signatures, rather than SPF. With signatures, the providers would not alter signed messages nor attempt to evaluate SPF. With SPF, providers would need to evaluate user/mailbox-domain permissions for the bounce-address and the PRA, or place their customers in serious peril. Signatures expect nothing from the providers. Whereas, SPF expects much more from providers, without providing any ramification when they fail these added duties. Sender-ID wants to change Sender-Header handling in conflict with the much safer signature scheme. SPF wants to change the bounce-address handling and place providers at risk with its poor level of security. The risk and incompatibility created by either SPF or Sender-ID is without merit, when there is a much better and safer alternative possible. Remember, SPF is simply an historical document that attempts to capture SPF as it was before Sender-ID had been adopted, according to Meng. Sender-ID is the only active document relevant to the application of the SPF record, in his view. Sender-ID now permits evaluation of both the bounce-address and the PRA. It seems that the SPF classic group are confused about the current relevance of their document. The problem of requiring assurances for the PRA or publishing a record destined to be refused seems of little concern. To get a better understanding why SPF is historical, and that only Sender-ID defines use of the SPF record read: http://spf.pobox.com/whitepaper.pdf -Doug From owner-ietf-mxcomp@mail.imc.org Mon Jun 20 08:07:25 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20385 for ; Mon, 20 Jun 2005 08:07:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5KBbQvf037797; Mon, 20 Jun 2005 04:37:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5KBbQDM037795; Mon, 20 Jun 2005 04:37:26 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j5KBbPQa037770 for ; Mon, 20 Jun 2005 04:37:25 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from [62.138.102.6] ([62.138.102.6]) (authenticated bits=0) by b.mail.sonic.net (8.13.3/8.13.3) with ESMTP id j5KBbHiV008591 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 20 Jun 2005 04:37:19 -0700 Subject: Re: [spf-help] Re: SPF and SenderID From: Douglas Otis To: Terry Fielder Cc: Michael Hammer , MARID , spf-help@v2.listbox.com In-Reply-To: <42B56149.8080707@ashtonwoodshomes.com> References: <4295C2D0.1000801@234.cx> <000d01c57185$ffda8ff0$fa01a8c0@ArSeNetLasRozas.local> <1118845789.10007.17.camel@bash.adsl-64-142-13-68> <7ae58c220506150811272e8b73@mail.gmail.com> <1118885342.7565.91.camel@SJC-Office-DHCP-156.mail-abuse.org> <7ae58c2205061711276fdb8936@mail.gmail.com> <1119038194.7574.180.camel@SJC-Office-DHCP-156.mail-abuse.org> <42B56149.8080707@ashtonwoodshomes.com> Content-Type: text/plain Date: Mon, 20 Jun 2005 04:35:04 -0700 Message-Id: <1119267304.8517.104.camel@littlejoy> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sun, 2005-06-19 at 08:12 -0400, Terry Fielder wrote: > Douglas Otis wrote: > > > > From the day of the SPF/Sender-ID merger in the interim meeting at > > Qualcomm, it has been clear the SPF record would be utilized to evaluate > > the PRA. Microsoft wanted to use their XML record, but the WG convinced > > them to use the existing record syntax. > > Inaccurate at best, the working group convinced MS not to put bloated > inefficient unnecessary XML records in DNS. It had nothing to do with > "convincing MS to use their syntax", it had to do with "don't make SPF > have to use an XML format" Part of the pitch for the SPF syntax, during the transition from the bounce-address to the PRA, included using the _exact_ syntax to avoid causing a change to the existing record. It has become obvious, this was a mistake from the point of view of the bounce-address-only proponents. It is also clear from the onset of the requests to publish SPF records, little consideration has been given to the potential outcome when reputation is applied. Although I repeatedly warned SPF does NOT prevent spoofing and that this assumption is dangerous for those that share outbound MTA servers, this caution was never heeded. The typical response from various proponents has been, "It is the publisher's fault for not considering these potential problems." It is also the proponent's fault for failing to provide _any_ warning regarding these concerns. It is rather outrageous to see statements like "Everyone and their dog should publish SPF records." This advice should include, "provided you and your dog control exclusive access to the authorized outbound MTA." If the MTA is being shared, then you and your dog should be indemnified by your outbound service provider against their not maintaining your exclusive use of both the bounce-address and the PRA. It is not surprising that SPF promoters don't care what problems they may cause the average mailbox-domain owner. Often these promoters are bulk email service providers or network service providers looking to escape accountability when one of their customers abuses email. An understandable goal and one safely achieved using email signatures, rather than SPF. With signatures, the providers would not alter signed messages nor attempt to evaluate SPF. With SPF, providers would need to evaluate user/mailbox-domain permissions for the bounce-address and the PRA, or place their customers in serious peril. Signatures expect nothing from the providers. Whereas, SPF expects much more from providers, without providing any ramification when they fail these added duties. Sender-ID wants to change Sender-Header handling in conflict with the much safer signature scheme. SPF wants to change the bounce-address handling and place providers at risk with its poor level of security. The risk and incompatibility created by either SPF or Sender-ID is without merit, when there is a much better and safer alternative possible. Remember, SPF is simply an historical document that attempts to capture SPF as it was before Sender-ID had been adopted, according to Meng. Sender-ID is the only active document relevant to the application of the SPF record, in his view. Sender-ID now permits evaluation of both the bounce-address and the PRA. It seems that the SPF classic group are confused about the current relevance of their document. The problem of requiring assurances for the PRA or publishing a record destined to be refused seems of little concern. To get a better understanding why SPF is historical, and that only Sender-ID defines use of the SPF record read: http://spf.pobox.com/whitepaper.pdf -Doug