From owner-ietf-mxcomp@mail.imc.org Wed Dec 1 14:07:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10367 for ; Wed, 1 Dec 2004 14:07:10 -0500 (EST) 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 iB1IImO6000476; Wed, 1 Dec 2004 10:18:48 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB1IIm3p000473; Wed, 1 Dec 2004 10:18:48 -0800 (PST) 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 iB1IIkRm000352 for ; Wed, 1 Dec 2004 10:18:47 -0800 (PST) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 8091416CC3 for ; Wed, 1 Dec 2004 13:30:25 -0500 (EST) From: "Alan DeKok" To: MXCOMP Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] In-Reply-To: Your message of "Mon, 29 Nov 2004 13:40:06 EST." <20041129184006.GA28045@dumbo.pobox.com> Date: Wed, 01 Dec 2004 13:30:25 -0500 Message-Id: <20041201183025.8091416CC3@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Meng Weng Wong wrote: > BTW, verbatim forwarding is practiced not just by unixheads > with .forward files, but also by hosted domains, of which > there are millions in existence, and alumni / lifetime email > services like alumni.*.edu and acm.org. Which have well-known names and IP addresses, unlike "hit and run" spammers. > The hosting providers can implement workarounds, and > forwarding service providers can implement workarounds. > >From the receiver end, trusted-forwarder.org lets receivers > whitelist forwarding hosts. Exactly. There are multiple ways possible to get to a widely deployed system of checking return paths. The deployment can be gradual, with well-understood incremental benefits at each stage. > That leaves only the ad-hoc forwarding setups. For those > cases, I would like to be able to tell them "just upgrade". I agree. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Wed Dec 1 18:38:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10833 for ; Wed, 1 Dec 2004 18:38:14 -0500 (EST) 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 iB1MxAp4006306; Wed, 1 Dec 2004 14:59:10 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB1MxAeY006302; Wed, 1 Dec 2004 14:59:10 -0800 (PST) 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 iB1Mx9pn005955 for ; Wed, 1 Dec 2004 14:59:09 -0800 (PST) (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 iB1Mx2xL007440 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 1 Dec 2004 17:59:03 -0500 Date: Wed, 1 Dec 2004 17:59:01 -0500 (EST) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: ietf-mxcomp@imc.org Subject: Re: Complaint on personal attack by Matthew Elvey by Dean Anderson of av8. (fwd) 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: This is pretty typical---they launch some unjustified personal attacks; Then they don't want to talk anymore. Accountability is a bitch. --Dean ---------- Forwarded message ---------- Date: Tue, 30 Nov 2004 18:46:05 -0500 From: Matthew Elvey To: Dean Anderson Subject: Re: Complaint on personal attack by Matthew Elvey by Dean Anderson of av8. DO NOT EMAIL ME EVER AGAIN. DO NOT EMAIL ME EVER AGAIN. DO NOT EMAIL ME EVER AGAIN. On 11/29/2004 6:19 PM, Dean Anderson sent forth electrons to convey: >It is interesting that there is still no explanation of what the attack on >me has to do with the FTC. > > Nothing. It was apropos to your comments regarding possible solutions to the spam problem. >I think its more appropriate to ignore someone who claimed that GNU emacs >contained much pirated code (Elvey, 2000). > > > You incorrectly inferred that I claimed there was. DO NOT EMAIL ME EVER AGAIN. From owner-ietf-mxcomp@mail.imc.org Wed Dec 1 20:53:28 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21495 for ; Wed, 1 Dec 2004 20:53:28 -0500 (EST) 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 iB21DJhB044780; Wed, 1 Dec 2004 17:13:19 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB21DJHU044777; Wed, 1 Dec 2004 17:13:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from canuck.infradead.org (canuck.infradead.org [205.233.218.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB21DG3t044757 for ; Wed, 1 Dec 2004 17:13:17 -0800 (PST) (envelope-from SRS0+7f9332568ccea2205738+466+infradead.org+dwmw2@canuck.srs.infradead.org) Received: from shinybook.infradead.org ([81.187.226.99]) by canuck.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1CZfX4-0000ji-AY; Wed, 01 Dec 2004 20:13:20 -0500 Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] From: David Woodhouse To: Chris Haynes Cc: MXCOMP In-Reply-To: <042d01c4d398$9ca78310$0200000a@ringo> References: <20041120231821.120205@bbfujip> <006101c4d170$336eac90$6401a8c0@hdev1> <80E256FA-3D72-11D9-92D5-000A95B3BA44@hxr.us> <1101398831.8191.9383.camel@hades.cambridge.redhat.com> <042d01c4d398$9ca78310$0200000a@ringo> Content-Type: text/plain; charset=UTF-8 Date: Thu, 02 Dec 2004 01:13:00 +0000 Message-Id: <1101949980.4642.34.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3.dwmw2.1) Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-SRS-Rewrite: SMTP reverse-path rewritten from by canuck.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Fri, 2004-11-26 at 09:16 +0000, Chris Haynes wrote: > Let me focus on the heart of the debate, and I'm doing my best to be fair to > both sides here, and to use neutral language. I think this is very useful; thanks. But I think you've slightly misrepresented the 'conservative' position. > Still in the spirit of 'neutral language' , let me use the terms 'conservative' > and 'progressive' for the two positions I am aware of. > > The conservatives look at the above example and say > "SPF is breaking the mail system. Forwarding has worked perfectly well in the > past; it is SPF which is changing; it is SPF which is wrong. SPF should not be > deployed". That's not quite how I'd phrase it. I'd say it was more like this: "SPF is breaking the mail system for no good reason. Forwarding has worked perfectly well in the past; it is SPF which is changing; it is SPF which is wrong. SPF should not be deployed because there are better ways of achieving the same thing, without the need for such changes." > Now, continuing in my attempt to be fair, let me withdraw any implication that > the conservatives are against any change whatsoever. I'm using 'progressive' > and 'conservative' purely in the context of this one topic. Indeed. If a change is absolutely necessary to make progress, I don't think many people would be arguing against it. See the fairly widespread support for closing open relays, for example. The problem in this particular case is that the 'progressives' are trying to enforce change while the 'conservatives' see ways that the same goals can be achieved without it. In particular, it's much easier to justify changes which can be limited to participating endpoints, rather than changes which affect uninterested third parties who may encounter the mail in transit. > How, and from where, would one get an 'authoritative' ruling about the > conformance or non-conformance of forwarding (using the origin's MAIL FROM with > a new RCPT TO) to the extant SMTP architecture? Actually, I don't think we need such an answer. We know the extent of existing practice; what was intended in 1982 isn't really relevant any more. The important question, in my mind, is 'Do we _need_ to change it?'. And unless all the alternative schemes like CSV/DK/SES are shown to be unworkable, I cannot really see how anyone could answer 'yes' to that question. Meng Weng Wong has previously said, "When banks start DomainKeys or S/MIME signing all outbound mail, I promise to give up SPF and Sender ID".¹ I'll follow that with my own promise: When everyone has given up on DomainKeys, IIM, SES, CSV, BATV and the similar proposals which don't need to change the world, I promise to publish an SPF record and make my forwarding hosts cope with the new requirements of SPF. -- dwmw2 ¹ http://www.imc.org/ietf-mxcomp/mail-archive/msg04998.html From owner-ietf-mxcomp@mail.imc.org Thu Dec 2 16:36:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01556 for ; Thu, 2 Dec 2004 16:36:34 -0500 (EST) 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 iB2KrXc2038375; Thu, 2 Dec 2004 12:53:33 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB2KrWjG038373; Thu, 2 Dec 2004 12:53:32 -0800 (PST) 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 iB2KrOq5038121 for ; Thu, 2 Dec 2004 12:53:25 -0800 (PST) (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 iB2KqYtb031650 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 2 Dec 2004 15:52:35 -0500 Date: Thu, 2 Dec 2004 15:52:33 -0500 (EST) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: David Woodhouse cc: Chris Haynes , MXCOMP Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] In-Reply-To: <1101949980.4642.34.camel@localhost.localdomain> 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 Thu, 2 Dec 2004, David Woodhouse wrote: > > On Fri, 2004-11-26 at 09:16 +0000, Chris Haynes wrote: > > Let me focus on the heart of the debate, and I'm doing my best to be fair to > > both sides here, and to use neutral language. > > I think this is very useful; thanks. But I think you've slightly > misrepresented the 'conservative' position. > > > Still in the spirit of 'neutral language' , let me use the terms 'conservative' > > and 'progressive' for the two positions I am aware of. > > > > The conservatives look at the above example and say > > "SPF is breaking the mail system. Forwarding has worked perfectly well in the > > past; it is SPF which is changing; it is SPF which is wrong. SPF should not be > > deployed". > > That's not quite how I'd phrase it. I'd say it was more like this: > > "SPF is breaking the mail system for no good reason. Forwarding has > worked perfectly well in the past; it is SPF which is changing; it is > SPF which is wrong. SPF should not be deployed because there are better > ways of achieving the same thing, without the need for such changes." I think there was more to it than this: 1) Abuser can forge addresses at domain 2) Abuser can use stolen credential 3) DNS cache problems (more records per domain, same cache size) 4) DNS load (more records per domain) 5) Ongoing Maintenance issues 6) Migration issues 7) IP Renumbering issues 8) Lost non-spam emails 9) Lack of universal compliance.* 10) Not a basis for trust/reduced filtering 11) Makes forgery blowback problem _much_ worse 12) Patent issues 13) spam-profiteering / charges for SPF services I think I left some things off that list. I'd say that "After more than a year of intense technical analysis by 2 IETF working groups, in then end, SPF didn't achieve any of the stated goals, and made some problems such as 'blowback' much worse." Perhaps this is aptly summarized as "SPF is breaking the mail system for no good reason." I guess I'd take that as an executive summary. Also, I've been following the source routing discussion, and would note that there were good reasons to have source routing (interaction between incompatible networks), and good reasons not to have source routing and use direct connection instead. These haven't changed. Source routing really implies the attempt to partition the internet into a spam/abuse part and a non-spam part. Such a partition is unrealistic. I found it mildly ironic that the same people who said open relays were bad and that source routing _MUST_ be disabled, are now advocating source routing as a necessary solution. Anticipating that they next require SMTP AUTH as mandatory, that will also not reduce spam, because EVERY spammer is authorized via SMTP AUTH, either by a stolen credential or by a disposable account. So the situation is still unchanged. To use a farm-colloquialism: "You can't dam a river with a wire fence" Painting the fence a different color won't help. Nor will changing from wood fenceposts to steel fenceposts. A fence just won't work, and a solid wall is impossible (wrt spam), and wouldn't work either, because unlike water, a spammer can choose to cross the solid wall. --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 Thu Dec 2 19:27:57 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18943 for ; Thu, 2 Dec 2004 19:27:56 -0500 (EST) 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 iB2NmVSX088511; Thu, 2 Dec 2004 15:48:31 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB2NmU5w088510; Thu, 2 Dec 2004 15:48:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from canuck.infradead.org (canuck.infradead.org [205.233.218.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB2NmHVC088022 for ; Thu, 2 Dec 2004 15:48:23 -0800 (PST) (envelope-from SRS0+7f9332568ccea2205738+466+infradead.org+dwmw2@canuck.srs.infradead.org) Received: from shinybook.infradead.org ([81.187.226.99]) by canuck.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1Ca0gJ-0003gx-6w; Thu, 02 Dec 2004 18:48:16 -0500 Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] From: David Woodhouse To: Dean Anderson Cc: Chris Haynes , MXCOMP In-Reply-To: References: Content-Type: text/plain Date: Thu, 02 Dec 2004 23:47:49 +0000 Message-Id: <1102031269.18830.1.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3.dwmw2.1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-SRS-Rewrite: SMTP reverse-path rewritten from by canuck.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2004-12-02 at 15:52 -0500, Dean Anderson wrote: > > "SPF is breaking the mail system for no good reason. Forwarding has > > worked perfectly well in the past; it is SPF which is changing; it is > > SPF which is wrong. SPF should not be deployed because there are better > > ways of achieving the same thing, without the need for such changes." > > I think there was more to it than this: <...> > I'd say that "After more than a year of intense technical analysis by 2 > IETF working groups, in then end, SPF didn't achieve any of the stated > goals, and made some problems such as 'blowback' much worse." Perhaps > this is aptly summarized as "SPF is breaking the mail system for no > good reason." I guess I'd take that as an executive summary. Well yes, but I was trying to follow Chris' lead -- be fair to both sides, and use neutral language :) -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Thu Dec 2 20:04:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22621 for ; Thu, 2 Dec 2004 20:04:43 -0500 (EST) 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 iB30Zj6K031662; Thu, 2 Dec 2004 16:35:45 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB30ZjqF031661; Thu, 2 Dec 2004 16:35:45 -0800 (PST) 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 iB30ZilJ031606 for ; Thu, 2 Dec 2004 16:35:44 -0800 (PST) (envelope-from dean@av8.com) Received: from antigua.nuspex.com (citation2.av8.net [130.105.19.2]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id iB30ZNDK003342 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 2 Dec 2004 19:35:34 -0500 Date: Thu, 2 Dec 2004 19:35:22 -0500 (EST) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: David Woodhouse cc: Chris Haynes , MXCOMP Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] In-Reply-To: <1102031269.18830.1.camel@localhost.localdomain> 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 Thu, 2 Dec 2004, David Woodhouse wrote: > On Thu, 2004-12-02 at 15:52 -0500, Dean Anderson wrote: > > > "SPF is breaking the mail system for no good reason. Forwarding has > > > worked perfectly well in the past; it is SPF which is changing; it is > > > SPF which is wrong. SPF should not be deployed because there are better > > > ways of achieving the same thing, without the need for such changes." > > > > I think there was more to it than this: > <...> > > I'd say that "After more than a year of intense technical analysis by 2 > > IETF working groups, in then end, SPF didn't achieve any of the stated > > goals, and made some problems such as 'blowback' much worse." Perhaps > > this is aptly summarized as "SPF is breaking the mail system for no > > good reason." I guess I'd take that as an executive summary. > > Well yes, but I was trying to follow Chris' lead -- be fair to both > sides, and use neutral language :) How about something like: A large and diverse group of people came together through two IETF working groups and together put in a tremendous amount of work on the problem for more than a year. Unfortunately, their best efforts were unable to overcome a dozen or so critical problems. The effort should not be viewed as a complete loss. Thomas Edison is reported to have said, when asked about the large number of failures in trying invent the lightbulb, that he didn't fail at all, but just discovered a lot of ways not to make a lightbulb. So, to take the most positive view: "We've just found another way that won't help with the spam problem" --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From owner-ietf-mxcomp@mail.imc.org Fri Dec 3 05:15:39 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18602 for ; Fri, 3 Dec 2004 05:15:38 -0500 (EST) 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 iB39b4TS072086; Fri, 3 Dec 2004 01:37:04 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB39b46c072085; Fri, 3 Dec 2004 01:37:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost1.mail.uk.easynet.net (smarthost1.mail.uk.easynet.net [212.135.6.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB39b0TW071637 for ; Fri, 3 Dec 2004 01:37:01 -0800 (PST) (envelope-from chris@harvington.org.uk) Received: from [62.53.0.15] (helo=ringo) by smarthost1.mail.uk.easynet.net with smtp (Exim 4.10) id 1Ca9rR-000Kd4-00; Fri, 03 Dec 2004 09:36:21 +0000 Message-ID: <0a2e01c4d91a$c7c01d50$0200000a@ringo> From: "Chris Haynes" To: "Dean Anderson" , "David Woodhouse" Cc: "MXCOMP" References: Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] Date: Fri, 3 Dec 2004 09:30:44 -0000 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.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit "Dean Anderson" enumerated: > > On Thu, 2 Dec 2004, David Woodhouse wrote: > > > > > On Fri, 2004-11-26 at 09:16 +0000, Chris Haynes wrote: > > > Let me focus on the heart of the debate, and I'm doing my best to be fair to > > > both sides here, and to use neutral language. > > > > I think this is very useful; thanks. But I think you've slightly > > misrepresented the 'conservative' position. > > > > > Still in the spirit of 'neutral language' , let me use the terms 'conservative' > > > and 'progressive' for the two positions I am aware of. > > > > > > The conservatives look at the above example and say > > > "SPF is breaking the mail system. Forwarding has worked perfectly well in the > > > past; it is SPF which is changing; it is SPF which is wrong. SPF should not be > > > deployed". > > > > That's not quite how I'd phrase it. I'd say it was more like this: > > > > "SPF is breaking the mail system for no good reason. Forwarding has > > worked perfectly well in the past; it is SPF which is changing; it is > > SPF which is wrong. SPF should not be deployed because there are better > > ways of achieving the same thing, without the need for such changes." > > I think there was more to it than this: > > 1) Abuser can forge addresses at domain > 2) Abuser can use stolen credential > 3) DNS cache problems (more records per domain, same cache size) > 4) DNS load (more records per domain) > 5) Ongoing Maintenance issues > 6) Migration issues > 7) IP Renumbering issues > 8) Lost non-spam emails > 9) Lack of universal compliance.* > 10) Not a basis for trust/reduced filtering > 11) Makes forgery blowback problem _much_ worse > 12) Patent issues > 13) spam-profiteering / charges for SPF services I've been trying to act as a neutral observer, collating lists of strengths and weaknesses of all the offerings in the anti-spam, anti-forgery space in as neutral and fair a way as I can. Once again, in the spirit of attempting to be 'fair' to all, can I just please ask for clarification of the above list of concerns. When this thread started we were referring to the problems related to forwarding which are inherent in (the original) SPF(-Classic). For the benenfit of other readers, may I just remind people that there have been three proposals in the "SPF" space, but only one was formally submitted to MARID: the Sender-ID one containing an amalgum of SPF and Sender-ID/PRA. The above list looks to me like a list of the concerns with that combined effort - and I'm concerned that problems with Sender_ID may here be unreasonably associated with SPF-Classic. The concerns I have previously seen associated with SPF-Classic, and are also present in Sender-ID are: 3) DNS cache problems (more records per domain, same cache size) 4) DNS load (more records per domain) 7) IP Renumbering issues 8) Lost non-spam emails 10) Not a basis for trust/reduced filtering It is my understanding that only the above concerns should be associated with "SPF". The ones which appear to me to have been added by PRA (derived from Caller-ID) in Sender-ID are: 1) Abuser can forge addresses at domain 11) Makes forgery blowback problem _much_ worse 12) Patent issues 13) spam-profiteering / charges for SPF services And ones which probably represent universal engineering concerns: 2) Abuser can use stolen credential 5) Ongoing Maintenance issues 6) Migration issues 9) Lack of universal compliance. although of course the way and degree to which these concerns mainifest depends on the exact scheme in question. Chris Haynes From owner-ietf-mxcomp@mail.imc.org Fri Dec 3 06:58:12 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26702 for ; Fri, 3 Dec 2004 06:58:11 -0500 (EST) 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 iB3BJwRU011123; Fri, 3 Dec 2004 03:19:58 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB3BJwBn011120; Fri, 3 Dec 2004 03:19:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from canuck.infradead.org (canuck.infradead.org [205.233.218.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB3BJp5s010915 for ; Fri, 3 Dec 2004 03:19:58 -0800 (PST) (envelope-from SRS0+9b082ad5cc14a0b71746+467+infradead.org+dwmw2@canuck.srs.infradead.org) Received: from shinybook.infradead.org ([81.187.226.99]) by canuck.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1CaBTV-0005CN-95; Fri, 03 Dec 2004 06:19:46 -0500 Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] From: David Woodhouse To: Chris Haynes Cc: Dean Anderson , MXCOMP In-Reply-To: <0a2e01c4d91a$c7c01d50$0200000a@ringo> References: <0a2e01c4d91a$c7c01d50$0200000a@ringo> Content-Type: text/plain Date: Fri, 03 Dec 2004 11:19:11 +0000 Message-Id: <1102072751.18942.8.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3.dwmw2.1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-SRS-Rewrite: SMTP reverse-path rewritten from by canuck.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2004-12-03 at 09:30 +0000, Chris Haynes wrote: > The ones which appear to me to have been added by PRA (derived from Caller-ID) > in Sender-ID are: > > 1) Abuser can forge addresses at domain This is common to PRA and SPF. Anyone with an account on one of the 'authorised' boxes (or subnets, if dynamic IP is in play) can sand mail which passes. There isn't even an option to require that the mail comes from a port < 1024, which is odd. > 11) Makes forgery blowback problem _much_ worse Not sure about this one. I don't actually see why this is the case. > 12) Patent issues > 13) spam-profiteering / charges for SPF services I don't understand this one either, but I don't think it's specific to PRA. > And ones which probably represent universal engineering concerns: > > 2) Abuser can use stolen credential > 5) Ongoing Maintenance issues > 6) Migration issues > 9) Lack of universal compliance. > > although of course the way and degree to which these concerns mainifest depends > on the exact scheme in question. In particular, number nine does vary to a vast degree; so much so that it should be considered a separate problem for some of them. There's a big difference between a scheme which requires _universal_ compliance, and a scheme which requires only the sending and receiving parties to participate, without any need for the rest of the world to change. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Fri Dec 3 16:19:09 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07218 for ; Fri, 3 Dec 2004 16:19:08 -0500 (EST) 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 iB3KnJWV044768; Fri, 3 Dec 2004 12:49:19 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB3KnJEI044767; Fri, 3 Dec 2004 12:49:19 -0800 (PST) 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 iB3KnIqb044712 for ; Fri, 3 Dec 2004 12:49:19 -0800 (PST) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 78E1C170D7 for ; Fri, 3 Dec 2004 16:01:02 -0500 (EST) From: "Alan DeKok" To: MXCOMP Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] In-Reply-To: Your message of "Thu, 25 Nov 2004 16:18:03 PST." Date: Fri, 03 Dec 2004 16:01:02 -0500 Message-Id: <20041203210102.78E1C170D7@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "william(at)elan.net" wrote: > I've argued and will be happy to argue again that SMTP needs to be > replaced with new protocol entirely instead of putting more and more > band-aids on 20 year old protocol that was designed for "simple" mail > transactions. I'd bet that at least 1/3 of SMTP implementations in existence don't need anything more than "simple" mail transactions. e.g. internal corporate mail systems. They're protected by physical and network security, where there's no need for additional SMTP-layer security. As for the other 2/3, any new email protocol will end up looking a whole lot like SMTP. > But creating new mail protocol to replace SMTP would take long time > (both in terms of IETF process to create this new protocol and process > for it to achieve wide-spread adaption) You don't need the support of the IETF to design and implement a protocol which is widely deployed. Witness bittorrent. If someone designs a new SMTP-style protocol, write an implementation, and make it reasonably backwards compatible with SMTP, people will test it out. If it's they like it, they'll deploy it, independent of what the IETF thinks. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Fri Dec 3 16:24:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07950 for ; Fri, 3 Dec 2004 16:24:37 -0500 (EST) 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 iB3KfDIR038761; Fri, 3 Dec 2004 12:41:13 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB3KfDp1038760; Fri, 3 Dec 2004 12:41:13 -0800 (PST) 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 iB3Kf70n038707 for ; Fri, 3 Dec 2004 12:41:10 -0800 (PST) (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 iB3Ke32x025641 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 3 Dec 2004 15:40:05 -0500 Date: Fri, 3 Dec 2004 15:40:03 -0500 (EST) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: David Woodhouse cc: Chris Haynes , MXCOMP Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] In-Reply-To: <1102072751.18942.8.camel@localhost.localdomain> 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 Dec 2004, David Woodhouse wrote: > On Fri, 2004-12-03 at 09:30 +0000, Chris Haynes wrote: > > The ones which appear to me to have been added by PRA (derived from Caller-ID) > > in Sender-ID are: > > > > 1) Abuser can forge addresses at domain > > This is common to PRA and SPF. Anyone with an account on one of the > 'authorised' boxes (or subnets, if dynamic IP is in play) can sand mail > which passes. There isn't even an option to require that the mail comes > from a port < 1024, which is odd. Agree with all except the "port < 1024" part. Back in the old days, when computers were significant resources, this was probably implied a person (eg system admin with root) responsible for a valuable asset. But today it can be assumed that "port < 1024" does not imply anything. > > 11) Makes forgery blowback problem _much_ worse > > Not sure about this one. I don't actually see why this is the case. "Blowback" is the bounces that you get when a spammer forges your address as the From: address. Much of the spam run will be delivered, but what isn't, will be bounced. ISP customer Spammer posts mail to that ISP's relay with a forged return address. The recipients reject the message due to SPF. Now the relay sends a bounce to the "from: address". This message is from the Relay, which will be valid. So now instead of a a few bounced messages, you get a bounce for every message blocked. Of course, if the target is harrassment, the spammer can just exchange the to: address and the from: address and use some ISPs relay. You can't block the ISP's relay without affecting the rest of the email. This is no difference than a reverse synflood DDOS attack using a wellknown router. Syns are sent to your upstream router, with your IP address as the source. The router responds with a SYN ack. This can easily be made to saturate a customer link. The customer can't block the upstream router. > > 12) Patent issues > > 13) spam-profiteering / charges for SPF services > > I don't understand this one either, but I don't think it's specific to > PRA. Patent issues item refers to the patents that apply to SPF and Sender-ID. Several organziations said they won't deploy anything that is patented. Spam-profiteering was tangentially discussed. Basically, an ISP such as AOL or MSN can charge fees or prevent altogether the unbunding of IP access and email services. > > And ones which probably represent universal engineering concerns: > > > > 2) Abuser can use stolen credential > > 5) Ongoing Maintenance issues > > 6) Migration issues > > 9) Lack of universal compliance. > > > > although of course the way and degree to which these concerns mainifest depends > > on the exact scheme in question. > > In particular, number nine does vary to a vast degree; so much so that > it should be considered a separate problem for some of them. There's a > big difference between a scheme which requires _universal_ compliance, > and a scheme which requires only the sending and receiving parties to > participate, without any need for the rest of the world to change. Right. Except that there is typically 3 or more parties to email: The sender, the relay operator, the mailbox operator, and the recipient. Secondly, if only a subset of the net deploys SPF, one cannot block mail based on the lack of an SPF record. And one cannot simply perform less testing if an SPF record exists since that would encourage spammers to use SPF-using ISPs (and in fact, it was found that most of the early deployers of SPF were spammers). One can only do blocking if SPF deployment is universal, and that is unlikely. It is not the case that SPF can be deployed merely with respect to the sender and recipient. There was significant discussion on this point with Alan Dekok. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From owner-ietf-mxcomp@mail.imc.org Fri Dec 3 21:17:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02050 for ; Fri, 3 Dec 2004 21:17:07 -0500 (EST) 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 iB41Sdqg058519; Fri, 3 Dec 2004 17:28:39 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB41SdQe058518; Fri, 3 Dec 2004 17:28:39 -0800 (PST) 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 iB41ScdS058339 for ; Fri, 3 Dec 2004 17:28:38 -0800 (PST) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 28FF716F4C for ; Fri, 3 Dec 2004 20:40:29 -0500 (EST) From: "Alan DeKok" To: MXCOMP Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] In-Reply-To: Your message of "Fri, 03 Dec 2004 15:40:03 EST." Date: Fri, 03 Dec 2004 20:40:29 -0500 Message-Id: <20041204014029.28FF716F4C@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dean Anderson wrote: > ISP customer Spammer posts mail to that ISP's relay with a forged return > address. The recipients reject the message due to SPF. Now the relay sends > a bounce to the "from: address". This message is from the Relay, which > will be valid. So now instead of a a few bounced messages, you get a > bounce for every message blocked. Is this a *new* attack, or is it an old attack with changed cost? So far as I can see, this exact same attack can happen when a server rejects messages from such a relay, independent of SPF. Maybe there are other methods of MAIL FROM validation which don't have this "blow-back" property. But I have a hard time seeing how any of them solve the problem of relays which accept mail that they cannot deliver, and that they cannot bounce to the correct entity. > It is not the case that SPF can be deployed merely with respect to the > sender and recipient. There was significant discussion on this point with > Alan Dekok. It can be deployed any way anyone wants. Whether there will be side effects is another story. Yes, doing MAIL FROM validation will have side effects on relays and others who use "MAIL FROM foo@example.com" without example.com knowing. But to be pedantic, that's the whole *point* of MAIL FROM checking: to know who is using your domain name in MAIL FROM, and to control their use of that name. If MAIL FROM validation doesn't allow the domain to control the use of it's name by an MTA, then MAIL FROM validation is not taking place. EHLO validation is orthogonal to MAIL FROM validation, for the simple reason that they're separate fields, and there's not requirement for the same domain name to appear in both. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Sat Dec 4 02:53:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07951 for ; Sat, 4 Dec 2004 02:53:42 -0500 (EST) 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 iB477seZ037073; Fri, 3 Dec 2004 23:07:54 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB477sDc037072; Fri, 3 Dec 2004 23:07:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB477olq036804 for ; Fri, 3 Dec 2004 23:07:51 -0800 (PST) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CaU1F-0003Ae-00 for ; Sat, 04 Dec 2004 08:07:49 +0100 Received: from 62.80.58.197 ([62.80.58.197]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 04 Dec 2004 08:07:48 +0100 Received: from nobody by 62.80.58.197 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 04 Dec 2004 08:07:48 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: A new SMTP "3821" Date: Sat, 04 Dec 2004 08:00:03 +0100 Organization: Lines: 74 Message-ID: <41B16073.14E5@xyzzy.claranet.de> References: <20041204014029.28FF716F4C@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: 62.80.58.197 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: > I have a hard time seeing how any of them solve the problem > of relays which accept mail that they cannot deliver, and > that they cannot bounce to the correct entity. SPF does this either directly or indirectly: If a zombie uses a forged MAIL FROM protected by SPF, and the receiver checks the sender policy, then it rejects this spam. The zombie won't create a bounce, it's a minimal SMTP script. If the zombie sends to an old-style forwarder (= no SPF check), and the spam is rejected by the next hop, then this old-style forwarder creates a bounce. But that's the same what happens if the real MAIL FROM sends mail to this forwarder, and the next hop rejects it, because the IP of the forwarder is not listed in the sender policy. The old-style forwarder is out of business as soon as the real sender and the next hop do SPF -all : _all_ mails are rejected by the next hop, and the sender will stop to send any further mail to the corresponding forwarded address, until the receiver has fixed his mail setup. Therefore all further bounces from this "forwarded address" are caused by forgeries. They go to nanas and abuse@forwarder, it is his problem, if he refuses to fix it he will be blacklisted. And if the forwarder supports SPF we're back at square one, the zombie can't send mail to the forwarded address, no bounce, no problem. Of course the zombie can use its own throw-away domain with a sender policy resulting in +all. But then a potential bounce won't hit any innocent bystander. > It can be deployed any way anyone wants. Whether there will > be side effects is another story. "SPF breaks forwarding to third parties" is only the executive summary. The truth is that a sender policy simply lists IPs of border MTAs used for HELO domain resp. MAIL FROM:. It's IMHO obvious that the receiver can check these IPs only at one of his border MXs, not later in his routing. "Forwarding to third parties" is only one special case of any "later in his routing". The essence of SPF is KISS. > to be pedantic, that's the whole *point* of MAIL FROM > checking: to know who is using your domain name in MAIL FROM, > and to control their use of that name. Ideed. And it's the receiver who can control it, if he wishes to control it. But he can only control it at his border, not somewhere else in his routing (= later in his forwarding). > EHLO validation is orthogonal to MAIL FROM validation, for > the simple reason that they're separate fields, and there's > not requirement for the same domain name to appear in both. If the HELO domain is also used in a MAIL FROM: - not necessarily by the same MTAs - then it makes sense to join the sets of corresponding IPs in one SPF sender policy for all receivers using SPF to control their borders. You could also combine it with other schemes, and if the other scheme says "bad HELO" skip all SPF tests and reject all mails. If the other scheme says "good HELO" you could skip SPF HELO tests (that's not explained in the SPF draft, it's obvious ;-) but still do SPF MAIL FROM tests. Bye, Frank From owner-ietf-mxcomp@mail.imc.org Sat Dec 4 07:00:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22754 for ; Sat, 4 Dec 2004 07:00:23 -0500 (EST) 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 iB4BIbJL065650; Sat, 4 Dec 2004 03:18:37 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB4BIbOp065649; Sat, 4 Dec 2004 03:18:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from baythorne.infradead.org (baythorne.infradead.org [81.187.226.107]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB4BIDhG064410 for ; Sat, 4 Dec 2004 03:18:30 -0800 (PST) (envelope-from SRS0+440cc78439a31f336a94+468+infradead.org+dwmw2@baythorne.srs.infradead.org) Received: from localhost ([127.0.0.1]) by baythorne.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1CaXtC-00019N-LO; Sat, 04 Dec 2004 11:15:46 +0000 Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] From: David Woodhouse To: Dean Anderson Cc: Chris Haynes , MXCOMP In-Reply-To: References: Content-Type: text/plain Message-Id: <1102158945.12133.17.camel@baythorne.infradead.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2.dwmw2.1) Date: Sat, 04 Dec 2004 11:15:46 +0000 Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by baythorne.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2004-12-03 at 15:40 -0500, Dean Anderson wrote: > Agree with all except the "port < 1024" part. Back in the old days, when > computers were significant resources, this was probably implied a person > (eg system admin with root) responsible for a valuable asset. But today it > can be assumed that "port < 1024" does not imply anything. Still it can be assumed that "port < 1024" implies a user with admin rights for the machine with that IP address. So if an IP address of a server which also has user accounts is listed, it would make some sense to indicate that connections should come from a privileged port. > "Blowback" is the bounces that you get when a spammer forges your address > as the From: address. Much of the spam run will be delivered, but what > isn't, will be bounced. Generally, what isn't delivered should be rejected by the first recipient it's offered to. It never leaves the spammer's machine and there's no bounce. > ISP customer Spammer posts mail to that ISP's relay with a forged return > address. The recipients reject the message due to SPF. Now the relay sends > a bounce to the "from: address". This message is from the Relay, which > will be valid. So now instead of a a few bounced messages, you get a > bounce for every message blocked. When spammers abuse open relays or ISPs run without any form of antispam measures, allowing similar abuse of their own relays, this is indeed possible. It's not caused by SPF alone though -- many forms of spam checking may cause it, and even the rejection of mail to unknown addresses at the destination site. This is a problem with any system which attempts to store-and-forward without an authenticated source address, and without knowing that its anti-spam policies are at least as strict as the next recipient. This is why you should always have MX backups which are capable of rejecting mail to unknown users at the domain, for example. It's also a problem which, at the victim's side, is trivially fixed by implementing SES -- you instantly stop accepting the bounces to mail you didn't send. > > > 9) Lack of universal compliance. > > > > > > although of course the way and degree to which these concerns mainifest depends > > > on the exact scheme in question. > > > > In particular, number nine does vary to a vast degree; so much so that > > it should be considered a separate problem for some of them. There's a > > big difference between a scheme which requires _universal_ compliance, > > and a scheme which requires only the sending and receiving parties to > > participate, without any need for the rest of the world to change. > > Right. Except that there is typically 3 or more parties to email: The > sender, the relay operator, the mailbox operator, and the recipient. Yes, that was precisely my point. A useful scheme would be one which works properly when it is implemented only by the sender and the recipient, and nobody in between. In fact SES goes one better than that -- it actually works to a large extent, allowing you to reject bounces to mail you didn't send, when implemented solely at the 'sender' site. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Sat Dec 4 10:52:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08044 for ; Sat, 4 Dec 2004 10:52:32 -0500 (EST) 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 iB4F9Lf0042163; Sat, 4 Dec 2004 07:09:21 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB4F9L7P042161; Sat, 4 Dec 2004 07:09:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (mail.santronics.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id iB4F9JHp042022 for ; Sat, 4 Dec 2004 07:09:20 -0800 (PST) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.3) for ietf-mxcomp@imc.org; Sat, 04 Dec 2004 10:15:26 -0500 Received: from ([65.10.113.141]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.3) with SMTP id 634630937; Sat, 04 Dec 2004 10:15:24 -0500 Message-ID: <002b01c4da13$24129d50$6401a8c0@hdev1> From: "Hector Santos" To: "IETF-MXCOMP" , "Frank Ellermann" References: <20041204014029.28FF716F4C@mail.nitros9.org> <41B16073.14E5@xyzzy.claranet.de> Subject: Re: A new SMTP "3821" Date: Sat, 4 Dec 2004 10:08:32 -0500 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: "Frank Ellermann" To: Sent: Saturday, December 04, 2004 2:00 AM Subject: Re: A new SMTP "3821" > It's IMHO obvious that the receiver can check these IPs only at > one of his border MXs, not later in his routing. "Forwarding > to third parties" is only one special case of any "later in his > routing". The essence of SPF is KISS. This is where possibly a HELO checking methodology works best because at the transition/route, it is presumed it be trusted by the local network chain. > > EHLO validation is orthogonal to MAIL FROM validation, for > > the simple reason that they're separate fields, and there's > > not requirement for the same domain name to appear in both. > > If the HELO domain is also used in a MAIL FROM: - > not necessarily by the same MTAs - then it makes sense to join > the sets of corresponding IPs in one SPF sender policy for all > receivers using SPF to control their borders. > > You could also combine it with other schemes, and if the other > scheme says "bad HELO" skip all SPF tests and reject all mails. > > If the other scheme says "good HELO" you could skip SPF HELO > tests (that's not explained in the SPF draft, it's obvious ;-) > but still do SPF MAIL FROM tests. Good point on mixed policies. I'll repost my link to my early work on LMAP validation and trust analysis. It became the basis for our current SMTP design: http://www.winserver.com/public/antispam/lmap/draft-lmapanalysis1-2.htm -- Hector From owner-ietf-mxcomp@mail.imc.org Sat Dec 4 14:00:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16611 for ; Sat, 4 Dec 2004 14:00:10 -0500 (EST) 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 iB4IT3SW054874; Sat, 4 Dec 2004 10:29:03 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB4IT3gn054873; Sat, 4 Dec 2004 10:29:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from orb.pobox.com (orb.pobox.com [207.8.226.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB4IT1HA054709 for ; Sat, 4 Dec 2004 10:29:01 -0800 (PST) (envelope-from McQuilWP@pobox.com) Received: from orb (localhost [127.0.0.1]) by orb.pobox.com (Postfix) with ESMTP id 8B9862F8CC3; Sat, 4 Dec 2004 13:29:01 -0500 (EST) Received: from MCQWP2 (ip68-7-159-196.sd.sd.cox.net [68.7.159.196]) by orb.sasl.smtp.pobox.com (Postfix) with ESMTP id 383262F8C9C; Sat, 4 Dec 2004 13:29:00 -0500 (EST) Date: Sat, 4 Dec 2004 10:28:54 -0800 From: Bill McQuillan X-Priority: 3 (Normal) Message-ID: <759372726.20041204102854@pobox.com> To: MARID Subject: Re: A new SMTP "3821" In-Reply-To: <41B16073.14E5@xyzzy.claranet.de> References: <20041204014029.28FF716F4C@mail.nitros9.org> <41B16073.14E5@xyzzy.claranet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Okay, I give up! At the risk of appearing illiterate, I have to ask. On Fri, 2004-12-03, Frank Ellermann wrote: > border MTAs used for HELO domain resp. MAIL FROM:. ^^^^^ What do you mean by this abbreviation? You seem to use it frequently and I have been unable to deduce its meaning from context. Please keep the derision to a minimum. :-) -- Bill McQuillan From owner-ietf-mxcomp@mail.imc.org Sat Dec 4 23:01:22 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14489 for ; Sat, 4 Dec 2004 23:01:21 -0500 (EST) 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 iB53EB0R067048; Sat, 4 Dec 2004 19:14:11 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB53EB2n067046; Sat, 4 Dec 2004 19:14:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (mail.winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id iB53E2pN066624 for ; Sat, 4 Dec 2004 19:14:03 -0800 (PST) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.3) for ietf-mxcomp@imc.org; Sat, 04 Dec 2004 22:20:12 -0500 Received: from ([65.10.113.141]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.3) with SMTP id 678117734; Sat, 04 Dec 2004 22:20:11 -0500 Message-ID: <003701c4da78$634ae580$6401a8c0@hdev1> From: "Hector Santos" To: "IETF-MXCOMP" Cc: "Matthew Elvey" References: <20041125231151.9B4D516F4C@mail.nitros9.org> <1101456711.19141.57.camel@localhost.localdomain> <004a01c4d411$ada15320$6401a8c0@hdev1> <41B273B6.2040502@elvey.com> Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] Date: Sat, 4 Dec 2004 22:13:20 -0500 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" 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: "Matthew Elvey" To: "Hector Santos" Sent: Saturday, December 04, 2004 9:34 PM Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] > >1) EHLO/HELO validation > >2) MAIL FROM validation > >3) RCPT TO validation > >4) DATA validation, if any > >5) Mixed Validation > > > > > What is this? What are mixed validation or Mixed Policies? In short, it is coupling the validation logic of lets say what a MAIL FROM validation will produce vs a HELO validation will produce. It is illogical to have a "valid" result where another data point is invalid, vice versa. There are many other examples of mix policies. > >CSV concentrates on #1, gets lost on SMTP AUTH issues, > > > I 'm pretty sure you're confused. Can you point to what part of the > spec you're referring to, so we can make it clearer? > Legit MUAs only send mail to MTAs they authenticate to. This is the > only hop in which CSV suggests SMTP AUTH as *A* solution (not the solution) The above was an example of a MIX policy. CSV presumes to validate the client domain name when it is possible there is an incoming ESMTP AUTH session, in which case, in my technical opinion, CSV does not apply. A pending mix policy may also exist at MAIL FROM and certainly at RCPT TO. Hope this helps. Sincerely, Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com 305-431-2846 Cell 305-248-3204 Office From owner-ietf-mxcomp@mail.imc.org Sun Dec 5 17:31:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14801 for ; Sun, 5 Dec 2004 17:31:15 -0500 (EST) 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 iB5Lo8XS065010; Sun, 5 Dec 2004 13:50:09 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB5Lo7PY065003; Sun, 5 Dec 2004 13:50:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (mail.catinthebox.net [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id iB5Lnwc5064404 for ; Sun, 5 Dec 2004 13:50:03 -0800 (PST) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.3) for ietf-mxcomp@imc.org; Sun, 05 Dec 2004 16:56:07 -0500 Received: from ([65.10.113.141]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.3) with SMTP id 745072062; Sun, 05 Dec 2004 16:56:06 -0500 Message-ID: <00e301c4db14$45c1bc90$6401a8c0@hdev1> From: "Hector Santos" To: "IETF-MXCOMP" , "Matthew Elvey" References: <20041125231151.9B4D516F4C@mail.nitros9.org> <1101456711.19141.57.camel@localhost.localdomain> <004a01c4d411$ada15320$6401a8c0@hdev1> <41B273B6.2040502@elvey.com> <003701c4da78$634ae580$6401a8c0@hdev1> <41B34AD1.2040107@elvey.com> Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] Date: Sun, 5 Dec 2004 16:48:36 -0500 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" 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: "Matthew Elvey" To: "Hector Santos" Sent: Sunday, December 05, 2004 12:52 PM Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] > >The above was an example of a MIX policy. > > > >CSV presumes to validate the client domain name when it is possible there is > >an incoming ESMTP AUTH session > > > That is false, to my reading of the specs: > "To validate an SMTP session from an unknown sending SMTP client" is > from the fourth line of the main spec. > If there's an incoming ESMTP AUTH session, then there is no "unknown > sending SMTP client", only a "known sending SMTP client". > > What language would you suggest since this isn't clear enough? The language is fine. The point is in order to accomplish this, the CSV (and others) state machine must be based on a delay design mechanism. Do I need to explain this? From owner-ietf-mxcomp@mail.imc.org Sun Dec 5 18:40:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19444 for ; Sun, 5 Dec 2004 18:40:17 -0500 (EST) 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 iB5NA0k7015764; Sun, 5 Dec 2004 15:10:00 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB5NA0vE015763; Sun, 5 Dec 2004 15:10:00 -0800 (PST) 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 iB5N9o3c015282 for ; Sun, 5 Dec 2004 15:09:53 -0800 (PST) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id D564C16CC3 for ; Sun, 5 Dec 2004 18:21:38 -0500 (EST) From: "Alan DeKok" To: MXCOMP Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] In-Reply-To: Your message of "Sat, 04 Dec 2004 11:15:46 GMT." <1102158945.12133.17.camel@baythorne.infradead.org> Date: Sun, 05 Dec 2004 18:21:38 -0500 Message-Id: <20041205232138.D564C16CC3@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Woodhouse wrote: > Generally, what isn't delivered should be rejected by the first > recipient it's offered to. It never leaves the spammer's machine and > there's no bounce. As has been pointed out repeatedly, this won't work in the existing SMTP system, due to certain design and implementation decisions. Whether this means the current design is incorrect, or your idea is incorrect is an argument which will never end. For related questions, what happens when I forward email manually, and it bounces back to me? Is it legal for me to delete it, or should I in turn bounce it to the originator who sent it to me? How does this scenario differ from the automated forwarding process? Is it legal, ever, for a part of the email system to discard a message? If so, why? If not, why not? > This is why you should always have MX backups which are capable of > rejecting mail to unknown users at the domain, for example. Ideally, yes. This can be difficult to do in practice. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Sun Dec 5 19:44:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23411 for ; Sun, 5 Dec 2004 19:44:20 -0500 (EST) 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 iB60CZsb035826; Sun, 5 Dec 2004 16:12:36 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB60CZe3035825; Sun, 5 Dec 2004 16:12:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB60CVH7035439 for ; Sun, 5 Dec 2004 16:12:32 -0800 (PST) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1Cb6UP-0005bp-00 for ; Mon, 06 Dec 2004 01:12:29 +0100 Received: from 212.82.251.208 ([212.82.251.208]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 06 Dec 2004 01:12:29 +0100 Received: from nobody by 212.82.251.208 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 06 Dec 2004 01:12:29 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: A new SMTP "3821" Date: Mon, 06 Dec 2004 01:11:21 +0100 Organization: Lines: 14 Message-ID: <41B3A3A9.6456@xyzzy.claranet.de> References: <20041204014029.28FF716F4C@mail.nitros9.org> <41B16073.14E5@xyzzy.claranet.de> <759372726.20041204102854@pobox.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: 212.82.251.208 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 Bill McQuillan wrote: > Okay, I give up! That's the first case where my "DEnglish" forced somebody to give up, :-( > What do you mean by this abbreviation? "respectively", Google found a link explaining why that's a bad idea: Maybe I should try "or" in these cases, it's shorter ;-) Bye. From owner-ietf-mxcomp@mail.imc.org Sun Dec 5 22:12:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03330 for ; Sun, 5 Dec 2004 22:12:35 -0500 (EST) 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 iB62cWa9063170; Sun, 5 Dec 2004 18:38:32 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB62cWRE063169; Sun, 5 Dec 2004 18:38:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (ntbbs.santronics.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id iB62cRlf063044 for ; Sun, 5 Dec 2004 18:38:27 -0800 (PST) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.3) for ietf-mxcomp@imc.org; Sun, 05 Dec 2004 21:44:44 -0500 Received: from ([65.10.113.141]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.3) with SMTP id 762389234; Sun, 05 Dec 2004 21:44:43 -0500 Message-ID: <001101c4db3c$9749bf90$6401a8c0@hdev1> From: "Hector Santos" To: "IETF-MXCOMP" , "Matthew Elvey" References: <20041125231151.9B4D516F4C@mail.nitros9.org> <1101456711.19141.57.camel@localhost.localdomain> <004a01c4d411$ada15320$6401a8c0@hdev1> <41B273B6.2040502@elvey.com> <003701c4da78$634ae580$6401a8c0@hdev1> <41B34AD1.2040107@elvey.com> <00e301c4db14$45c1bc90$6401a8c0@hdev1> <41B393C0.3000407@elvey.com> Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] Date: Sun, 5 Dec 2004 21:37:49 -0500 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" 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: "Matthew Elvey" To: "Hector Santos" Sent: Sunday, December 05, 2004 6:03 PM Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] > On 12/5/2004 1:48 PM, Hector Santos sent forth electrons to convey: > > >----- Original Message ----- > >From: "Matthew Elvey" > >To: "Hector Santos" > >Sent: Sunday, December 05, 2004 12:52 PM > >Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] > > > >The point is in order to accomplish this, the CSV (and others) state machine > >must be based on a delay design mechanism. > > > >Do I need to explain this? > > > > > Yes. I don't know the term and > http://www.google.com/search?q=%22delay+design+mechanism%22 > brings up no hits. Ok, fair enough, I will explain it (see below) but keep in mind, a little more elbow grease in your googling. i.e, using words like "SMTP DELAY VALIDATION", etc, would of produced some hits. This is certainly not the first time this discussion or related concepts were discussed at some level. > The only relation of > "delay" to CSV is that there's a delay when a domain with a good > reputation goes bad and that info needs to be discovered and propagated. No, no relationship to mixed validation ideas and issues. I will try to give you an example. I will do so with specific CVS examples, but keep in mind the same or related issues applies to all the proposals. Keep in mind we are a product developer and the implementation of any new idea into the system goes thru a very thorough "Software Walkthrough" review process with many issues to be considered. In regards to SMTP, the following top design goals were sought: - Maximum SMTP Compatibility, - Maximum Spoof protection/Validation at the transaction level, - Maximum Efficiency and Scalability. - Minimal to no interference with 2822 mail interpretation. The last one is based on our long history on online hosting product experience (second to none) in dealing with US ECPA legal and related issues. In short, we don't concern concerns with the administrative or end-user level mail interpretation issues. Any new security ideas that will stop the 'flow" of mail must be maintained at the transaction level for product liability reasons. PS: I don't wish to go into this with anyone. Of course, it should go without saying that any new SMTP concepts should deal with compatibility issues as well. Like any other vendor, we don't wish to "break" their operations. However, this is very important in the area I feel is very important in distinguishing problem we are trying to address. In short, our design philosophy from the git-go has been the Spoof Problem is one that is a based on an "Anonymous Final Destination Transaction" (AFDT). The reason is straight forward: The world wide SMTP internet email network is predominately based on the following fundamental principle: - Trust is required for Relay or Routed transactions, - No Trust is required for final destination transactions. In other words, for relay or routed transactions, the client/server transaction has already negotiated a "trust" relationship. In practice, this is traditional done using one or more of the following: - IP Relay Tables - ESMTP AUTH - POP3 BEFORE SMTP However, for a AFDT the "network" has worked because the above trust relationship is not required. Yet, this is where the exploitation of SMTP begins and it is the essence of the Spoof Problem that exist today. So for lack of a better term, "Anonymous Final Destination Transactions' is where SMTP lacks strength and hence needs new ideas to help protect against the abuse of the system. If you don't agree, you might as well stop here. But if you want to understand what is meant by delay or mixed policies, then continue reading. Now, lets review the SMTP state machine: o connection state o HELO/EHLO state o MAIL FROM state o RCPT TO state: o DATA state: Since we are attempting to solve this problem in non-2822 terms, only in 2821 terms, the data points for a transaction are: CIP - Client IP address (at the socket accept level) CDN - Client Domain Name (issued at HELO/EHLO) RP - Sender Return Path (MAIL FROM) FP - Forwarding Path (RCPT TO) Using the following functional model to depict old (current) vs. new end point validation concepts: result = EPV_OLD(cip, cpn, rp, fp) result = EPV_NEW(cip, cpn, rp, fp) We can now begin to show how all the data points are related and/or mix policies analysis is required to be considered. Given what was stated above about AFDT, no "new SMTP validation logic" is required until it is known whether the transaction is a route or a final destination. Therefore, one SMTP implementation would to delay all validations until FP is provided at RCPT TO: if FP = Route then Result = EPV_OLD(cip, cpn, rp,fp) else Result = EPV_NEW(cip, cpn, rp,fp) This says that if the forwarding path is for a route, then we only need to use traditional, backward compatible SMTP authentication/validation trust negotiation ideas that already exist and are standards in the market place. It also says that if FP is not a route but for a final destination, then this is where we need to apply new validation ideas that are not currently a standard. What does this all mean? Well, from a design standpoint, you have two options: - An open-ended check for each data point as they are provided, or - A more efficient check based on one or more of all the possible data points. Lets use CSV examples: Example 1 is the IDEAL "Good Transaction. All data points are valid. connection ip: 64.234.45.8 HELO mail.elvey.com MAIL FROM: matt@elvey.com RCPT TO: hector@winserver.com In this case, you are connecting to our MX server at winserver.com, from your own valid IP machine, issuing a valid client domain name and a non-spoofed valid return address. Its all good. Example 2 is the bad transaction where you trying not authorized to route via our server: connection ip: 64.234.45.8 HELO mail.elvey.com MAIL FROM: matt@elvey.com RCPT TO: bill.gate@microsoft.com A few questions now come to mind: a) At which point do we apply CSV? b) Can we use CSV to authenticate the route? If you had follow this so far, CSV is only needed at example #1 for a AFDT. In example #2, you need to follow standard SMTP authentication on our system in order to route. You have to have a prior relationship, either as a MUA user or another trusted router. So unless you apply a delay validation technique, you are forced to use a open-ended check prior to the FP is known. This is a very inefficient mode of operations which has been proven to be the case in practice that require DNS overhead just like CSV does. Lets look at Mixed Policies now. A new example #1.1 is similar to example #1 as a final destination transaction but with a different sender, not you. I could of used your address, but I wanted to highlight the difference. connection ip: 64.234.45.8 HELO mail.elvey.com MAIL FROM: user@somewhere.com RCPT TO: hector@winserver.com It is an anonymous final destination and a transaction where additional validation is required. We are using CSV here and lets assume you are a member of Doug's new CSV/DNA authentication database. Lets also assume that the efficient delay validation is used so that CSV is applied after RCPT TO is provided. The validation is delayed. No overhead in this system. According to CSV specs, since you are authenticated via CSV/DNA based on the CDN (HELO client domain) and CIP (client IP address), then we should "trust" this transaction, however, the CSV does state that additional validation may apply depending on the implementation. Since we have very suspicious sysops and since CSV does not address RP (return path) validation, a system may which to add additional logic such as SPF1 or SENDER ID to validate the return path domain. Keep in mind that SPF1/SENDER ID or LMAP in general validates just the domain part of the return path. Not the complete address. In any case, for the sake of the example, a SPF1/SENDER ID check results as a FAIL. You know have a mix policy: The questions are: What does it mean? What validation prevails? What are the validations weights, if any? Can the mix policy be use to trump one validation over the other? Lets look at some of these questions: Does this mean the CVS authenticated ELVEY.COM has a spammer user on this system? Does this mean the CVS authenticated ELVEY.COM has a DNA attribute that says: "[X] Reject if the Sender Path is invalid" Could it mean that CSV says a validated machine trump any other validation? Lets go a step further with another mix policy situation: Lets assume the sysop has implement a CBV (Call back Verifier) instead of SPF. The CBV is designed to perform a callback to the return path MX domain to validate the return address. Lets assume the CBV returns "550 Unknown user: user@somewhere.com" What does this say about the trust of an CVS authenticated ELVEY.COM system? Should ELVEY.COM get blacklisted? or should a report be sent? So on, and so on. The point in all this is that NONE of the proposals have taken a very thorough "Software Walkthrough" and look at all the possibilities. Delay validation is a requirement in my book. Not only do you achieve higher compatibility, you can save a very significant 35-60% in validation overhead. No one proposal can be used unless it covers all bases. Thus unless someone comes up with a merger of all the proposals, the advanced SMTP system today will need a suite and they will have to deal with the mix policy issues at some level. I hope this is sufficient Matthew. Sincerely, Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com 305-431-2846 Cell 305-248-3204 Office From owner-ietf-mxcomp@mail.imc.org Mon Dec 6 05:00:27 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19263 for ; Mon, 6 Dec 2004 05:00:27 -0500 (EST) 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 iB69LXDV071812; Mon, 6 Dec 2004 01:21:33 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB69LXpK071811; Mon, 6 Dec 2004 01:21:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from orb.pobox.com (orb.pobox.com [207.8.226.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB69LWFg071720 for ; Mon, 6 Dec 2004 01:21:32 -0800 (PST) (envelope-from McQuilWP@pobox.com) Received: from orb (localhost [127.0.0.1]) by orb.pobox.com (Postfix) with ESMTP id 85B962FAD14; Mon, 6 Dec 2004 04:21:29 -0500 (EST) Received: from MCQWP2 (ip68-7-159-196.sd.sd.cox.net [68.7.159.196]) by orb.sasl.smtp.pobox.com (Postfix) with ESMTP id 324CD2FAE49; Mon, 6 Dec 2004 04:21:28 -0500 (EST) Date: Mon, 6 Dec 2004 01:21:26 -0800 From: Bill McQuillan X-Priority: 3 (Normal) Message-ID: <1111908014.20041206012126@pobox.com> To: MARID Subject: Re: A new SMTP "3821" In-Reply-To: <41B3A3A9.6456@xyzzy.claranet.de> References: <20041204014029.28FF716F4C@mail.nitros9.org> <41B16073.14E5@xyzzy.claranet.de> <759372726.20041204102854@pobox.com> <41B3A3A9.6456@xyzzy.claranet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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, 2004-12-05, Frank Ellermann wrote: > Bill McQuillan wrote: >> Okay, I give up! > That's the first case where my "DEnglish" forced somebody to > give up, :-( >> What do you mean by this abbreviation? > "respectively", Google found a link explaining why that's > a bad idea: > Maybe I should try "or" in these cases, it's shorter ;-) Bye. Thanks for the explanation! I expected to slap my forehead and say "I should have known that"! But this is much more interesting. Thanks also for the LanguageHat reference, I may spend a bit of time there. -- Bill McQuillan From owner-ietf-mxcomp@mail.imc.org Mon Dec 6 11:13:12 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26210 for ; Mon, 6 Dec 2004 11:13:12 -0500 (EST) 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 iB6FXIv1041687; Mon, 6 Dec 2004 07:33:18 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB6FXIqq041686; Mon, 6 Dec 2004 07:33:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from canuck.infradead.org (canuck.infradead.org [205.233.218.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB6FXH9o041652 for ; Mon, 6 Dec 2004 07:33:17 -0800 (PST) (envelope-from SRS0+1291072450f0ba5de6a4+470+infradead.org+dwmw2@canuck.srs.infradead.org) Received: from shinybook.infradead.org ([81.187.226.99]) by canuck.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1CbKrN-0002yT-Fo; Mon, 06 Dec 2004 10:33:12 -0500 Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] From: David Woodhouse To: Alan DeKok Cc: MXCOMP In-Reply-To: <20041205232138.D564C16CC3@mail.nitros9.org> References: <20041205232138.D564C16CC3@mail.nitros9.org> Content-Type: text/plain Date: Mon, 06 Dec 2004 15:32:46 +0000 Message-Id: <1102347166.5122.29.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3.dwmw2.1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-SRS-Rewrite: SMTP reverse-path rewritten from by canuck.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sun, 2004-12-05 at 18:21 -0500, Alan DeKok wrote: > David Woodhouse wrote: > > Generally, what isn't delivered should be rejected by the first > > recipient it's offered to. It never leaves the spammer's machine and > > there's no bounce. > > As has been pointed out repeatedly, this won't work in the existing > SMTP system, due to certain design and implementation decisions. > > Whether this means the current design is incorrect, or your idea is > incorrect is an argument which will never end. There's no problem with the current design. In general it's not hard. Either the spammer is sending mail via the ISP of the zombie machine, which ought to be doing some kind of check on outgoing mail from their customers, or often they try to connect directly to an MX host of the domain to which they're trying to send, which ought to reject anything the primary MX would reject. > > This is why you should always have MX backups which are capable of > > rejecting mail to unknown users at the domain, for example. > > Ideally, yes. This can be difficult to do in practice. Anything _can_ be difficult to do in practice, if you make enough stupid decisions along the way. Setting up an MX backup competently can be _trivial_ to do in practice too. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Mon Dec 6 11:22:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26841 for ; Mon, 6 Dec 2004 11:22:50 -0500 (EST) 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 iB6Fu0g0060767; Mon, 6 Dec 2004 07:56:00 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB6Fu0ni060766; Mon, 6 Dec 2004 07:56:00 -0800 (PST) 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 iB6Ftxfv060748 for ; Mon, 6 Dec 2004 07:55:59 -0800 (PST) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 ([216.191.52.74]) by mail.greatgulfhomes.com (8.12.8/8.12.8) with SMTP id iB6G96aK007260; Mon, 6 Dec 2004 11:09:06 -0500 From: To: "'Alan DeKok'" , "'MXCOMP'" Subject: RE: A new SMTP "3821" [Re: FTC stuff...........] Date: Mon, 6 Dec 2004 10:56:05 -0500 Message-ID: <011101c4dbac$18a2d940$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <20041205232138.D564C16CC3@mail.nitros9.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal 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 Alan DeKok > Sent: Sunday, December 05, 2004 6:22 PM > To: MXCOMP > Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] > > > > David Woodhouse wrote: > > Generally, what isn't delivered should be rejected by the first > > recipient it's offered to. It never leaves the spammer's machine and > > there's no bounce. > > As has been pointed out repeatedly, this won't work in the existing > SMTP system, due to certain design and implementation decisions. > > Whether this means the current design is incorrect, or your idea is > incorrect is an argument which will never end. > > For related questions, what happens when I forward email manually, > and it bounces back to me? Is it legal for me to delete it, or should > I in turn bounce it to the originator who sent it to me? How does > this scenario differ from the automated forwarding process? Is it > legal, ever, for a part of the email system to discard a message? If > so, why? If not, why not? > > > This is why you should always have MX backups which are capable of > > rejecting mail to unknown users at the domain, for example. > > Ideally, yes. This can be difficult to do in practice. Indeed, near impossible: There are more then just "invalid recipient" as rejection reason. Consider the popular "mailbox full" error. Terry Fielder Manager Software Development and Deployment Great Gulf Homes / Ashton Woods Homes terry@greatgulfhomes.com Fax: (416) 441-9085 > > Alan DeKok. > From owner-ietf-mxcomp@mail.imc.org Mon Dec 6 13:30:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08205 for ; Mon, 6 Dec 2004 13:30:52 -0500 (EST) 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 iB6I021A059955; Mon, 6 Dec 2004 10:00:02 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB6I02Wx059952; Mon, 6 Dec 2004 10:00:02 -0800 (PST) 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 iB6Hxxf9059777 for ; Mon, 6 Dec 2004 10:00:01 -0800 (PST) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id E9E7316CC3 for ; Mon, 6 Dec 2004 13:11:52 -0500 (EST) From: "Alan DeKok" To: MXCOMP Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] In-Reply-To: Your message of "Mon, 06 Dec 2004 15:32:46 GMT." <1102347166.5122.29.camel@localhost.localdomain> Date: Mon, 06 Dec 2004 13:11:52 -0500 Message-Id: <20041206181152.E9E7316CC3@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Woodhouse wrote: > There's no problem with the current design. In general it's not hard. > Either the spammer is sending mail via the ISP of the zombie machine, > which ought ... to do a lot of things, but often doesn't. > to be doing some kind of check on outgoing mail from their > customers, or often they try to connect directly to an MX host of the > domain to which they're trying to send, which ought to reject anything > the primary MX would reject. And what about relays? Forwarders? You're assuming that messages go from source to destination in one hop. While this is nice, the current design allows a message to traverse multiple independent hops, all the while using the same "MAIL FROM". This has a serious impact on the "blowback" problem, and any possible solution. > > > This is why you should always have MX backups which are capable of > > > rejecting mail to unknown users at the domain, for example. > > > > Ideally, yes. This can be difficult to do in practice. > > Anything _can_ be difficult to do in practice, if you make enough stupid > decisions along the way. Setting up an MX backup competently can be > _trivial_ to do in practice too. Yes, but sharing live information about all of your users with a backup MX is difficult to do in practice. Spammers leverage the fact that backup & primary MX's have different pools of information to convince the backup MX to deliver messages that the primary might have rejected. If nothing else, the spammers are offloading some of their work onto the backup MX, and using it to attack the primary. This attack has serious consequences for the robustness of the email transport layer. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Mon Dec 6 13:30:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08252 for ; Mon, 6 Dec 2004 13:30:55 -0500 (EST) 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 iB6I1kKK062024; Mon, 6 Dec 2004 10:01:46 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB6I1kl4062023; Mon, 6 Dec 2004 10:01:46 -0800 (PST) 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 iB6I1j7I062004 for ; Mon, 6 Dec 2004 10:01:45 -0800 (PST) (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 iB6I1eTf013729 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 6 Dec 2004 13:01:46 -0500 Date: Mon, 6 Dec 2004 13:01:39 -0500 (EST) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: Alan DeKok cc: MXCOMP Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] In-Reply-To: <20041204014029.28FF716F4C@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 Dec 2004, Alan DeKok wrote: > > Dean Anderson wrote: > > ISP customer Spammer posts mail to that ISP's relay with a forged return > > address. The recipients reject the message due to SPF. Now the relay sends > > a bounce to the "from: address". This message is from the Relay, which > > will be valid. So now instead of a a few bounced messages, you get a > > bounce for every message blocked. > > Is this a *new* attack, or is it an old attack with changed cost? > > So far as I can see, this exact same attack can happen when a server > rejects messages from such a relay, independent of SPF. I think it is an old attack, as described when all mail from a relay is rejected. Cost is the same as before. Possibly cheaper, since it is easier for the abuser to arrange the case where all email will be rejected by recipient, but not by forged sender. > > It is not the case that SPF can be deployed merely with respect to the > > sender and recipient. There was significant discussion on this point with > > Alan Dekok. > > It can be deployed any way anyone wants. Whether there will be side > effects is another story. Err, no. What is meant is that "sender and recipient" is an oversimplication. There are more parties than just the "sender and recipient". > Yes, doing MAIL FROM validation will have side effects on relays and > others who use "MAIL FROM foo@example.com" without example.com > knowing. But to be pedantic, that's the whole *point* of MAIL FROM > checking: to know who is using your domain name in MAIL FROM, and to > control their use of that name. Yes, I know that is "the point". However, this isn't possible. Hence the conclusion that "SPF is breaking the mail system for no good reason". > If MAIL FROM validation doesn't allow the domain to control the use > of it's name by an MTA, then MAIL FROM validation is not taking place. That is correct. MAIL From validation isn't taking place. --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 Mon Dec 6 13:54:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11554 for ; Mon, 6 Dec 2004 13:54:32 -0500 (EST) 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 iB6ISq4o084292; Mon, 6 Dec 2004 10:28:52 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB6ISqIQ084291; Mon, 6 Dec 2004 10:28:52 -0800 (PST) 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 iB6ISpcV084268 for ; Mon, 6 Dec 2004 10:28:52 -0800 (PST) (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 iB6ISche014179 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 6 Dec 2004 13:28:41 -0500 Date: Mon, 6 Dec 2004 13:28:36 -0500 (EST) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: David Woodhouse cc: Chris Haynes , MXCOMP Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] In-Reply-To: <1102158945.12133.17.camel@baythorne.infradead.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 Dec 2004, David Woodhouse wrote: > > On Fri, 2004-12-03 at 15:40 -0500, Dean Anderson wrote: > > Agree with all except the "port < 1024" part. Back in the old days, when > > computers were significant resources, this was probably implied a person > > (eg system admin with root) responsible for a valuable asset. But today it > > can be assumed that "port < 1024" does not imply anything. > > Still it can be assumed that "port < 1024" implies a user with admin > rights for the machine with that IP address. So if an IP address of a > server which also has user accounts is listed, it would make some sense > to indicate that connections should come from a privileged port. Just about everyone has admin rights over a machine these days. Some few machines have such rights limited. But even then, that's no indication that the admin is responsible or trustworthy. Not that I guess I feel very strongly about it either way. But, certainly, spammers can get port < 1024 if they want. Mainly, I'd prefer not to have to remember that IMAP is port 52345. So, I'd prefer that protocols be assigned low ports. But this is the "listen" port. I'm not terribly concerned about what port numbers clients connect from. > > "Blowback" is the bounces that you get when a spammer forges your address > > as the From: address. Much of the spam run will be delivered, but what > > isn't, will be bounced. > > Generally, what isn't delivered should be rejected by the first > recipient it's offered to. It never leaves the spammer's machine and > there's no bounce. This is only true if no relay is involved. Every spammer has the right (at least until their account is terminated) to use their ISP's relay, if the choose. I think at present spammers and viruses send directly because it easier than figuring out the right relay to use at the ISP. The relay information is something that customer gets along with their account information, and while not secret, its location on a compromised machine depends on the mail software being used. In other words, the spammer/virus/worm operator has to search for it. Much easier to send directly. Ironically, SPF makes this problem much easier for the virus operator, by identifying the outgoing relays in DNS. These are the same relays that will accept outgoing customer email. > > ISP customer Spammer posts mail to that ISP's relay with a forged return > > address. The recipients reject the message due to SPF. Now the relay sends > > a bounce to the "from: address". This message is from the Relay, which > > will be valid. So now instead of a a few bounced messages, you get a > > bounce for every message blocked. > > When spammers abuse open relays or ISPs run without any form of antispam > measures, allowing similar abuse of their own relays, this is indeed > possible. It's not caused by SPF alone though -- many forms of spam > checking may cause it, and even the rejection of mail to unknown > addresses at the destination site. This is a problem with any system > which attempts to store-and-forward without an authenticated source > address, and without knowing that its anti-spam policies are at least as > strict as the next recipient. Yes, this is true of traditional address forgery. People forget that there is no difference between open relays and closed relays, except that closed relays only accept email from a particular address range. Spammer always has a relay available if they choose. But with ordinary (non-SPF enhanced) forgery, the forged recipient usually only gets _SOME_ bounces. With SPF, they get _ALL_ messages sent by the spammer/abuser. This was one of the problems stated as to be solved by SPF. SPF doesn't solve it, but makes it worse. > This is why you should always have MX backups which are capable of > rejecting mail to unknown users at the domain, for example. This doesn't help with forged mail targeted at an existing address, which I think is the goal of SPF/Sender-ID. Rejecting mail to unknown users is implemented without SPF/Sender-ID. Its the forged mail to real users that causes the subject problem. > It's also a problem which, at the victim's side, is trivially fixed by > implementing SES -- you instantly stop accepting the bounces to mail you > didn't send. > > Right. Except that there is typically 3 or more parties to email: The > > sender, the relay operator, the mailbox operator, and the recipient. > > Yes, that was precisely my point. A useful scheme would be one which > works properly when it is implemented only by the sender and the > recipient, and nobody in between. In fact SES goes one better than that > -- it actually works to a large extent, allowing you to reject bounces > to mail you didn't send, when implemented solely at the 'sender' site. I'm not familiar enough with SES to comment. Sounds like I should spend some time on it, though. -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From owner-ietf-mxcomp@mail.imc.org Mon Dec 6 19:30:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11098 for ; Mon, 6 Dec 2004 19:30:00 -0500 (EST) 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 iB701Emr056430; Mon, 6 Dec 2004 16:01:14 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB701EDS056429; Mon, 6 Dec 2004 16:01:14 -0800 (PST) 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 iB7019hA056417 for ; Mon, 6 Dec 2004 16:01:14 -0800 (PST) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id E0B4016CC3 for ; Mon, 6 Dec 2004 19:13:04 -0500 (EST) From: "Alan DeKok" To: MXCOMP Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] In-Reply-To: Your message of "Mon, 06 Dec 2004 13:01:39 EST." Date: Mon, 06 Dec 2004 19:13:04 -0500 Message-Id: <20041207001304.E0B4016CC3@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dean Anderson wrote: > > But to be pedantic, that's the whole *point* of MAIL FROM > > checking: to know who is using your domain name in MAIL FROM, and to > > control their use of that name. > > Yes, I know that is "the point". However, this isn't possible. In theory or in practice? If it's possible in theory, it's possible in practice. The only question then is whether the cost is acceptable. If it's not possible in theory, I'm curious to know why. > Hence the conclusion that "SPF is breaking the mail system for no > good reason". So... am I to be permitted to control the use of my own domain name? If not, why not? If so, then I'm free to implement SPF, or anything other scheme I like. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Mon Dec 6 19:30:12 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11130 for ; Mon, 6 Dec 2004 19:30:11 -0500 (EST) 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 iB6NiFpn052010; Mon, 6 Dec 2004 15:44:15 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB6NiFnE052009; Mon, 6 Dec 2004 15:44:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pentafluge.infradead.org ([213.146.154.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB6Nhtf6051791 for ; Mon, 6 Dec 2004 15:44:14 -0800 (PST) (envelope-from SRS0+311f5be1b0cbda9dcab2+470+infradead.org+dwmw2@pentafluge.srs.infradead.org) Received: from shinybook.infradead.org ([81.187.226.99]) by pentafluge.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1CbSWC-0002Bo-11; Mon, 06 Dec 2004 23:43:49 +0000 Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] From: David Woodhouse To: Dean Anderson Cc: Chris Haynes , MXCOMP In-Reply-To: References: Content-Type: text/plain Date: Mon, 06 Dec 2004 23:34:35 +0000 Message-Id: <1102376075.5122.56.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3.dwmw2.1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 2004-12-06 at 13:28 -0500, Dean Anderson wrote: > Just about everyone has admin rights over a machine these days. Some few > machines have such rights limited. But even then, that's no indication > that the admin is responsible or trustworthy. Not that I guess I feel > very strongly about it either way. But, certainly, spammers can get port > < 1024 if they want. I think we're talking at cross purposes here. I'm suggesting that one of the flaws in the SPF draft -- that anyone with an account on a machine which is listed can send 'authorised' mail -- could be alleviated by having an _option_ to say that mail is only authorised if it comes from a privileged port. I'm not suggesting that one should trust all mail from a port < 1024 and not accept any from unprivileged ports, because those with admin rights are 'responsible for a valuable asset' (to use your terminology). > This is only true if no relay is involved. Every spammer has the right > (at least until their account is terminated) to use their ISP's relay, if > the choose. I think at present spammers and viruses send directly because > it easier than figuring out the right relay to use at the ISP. And also because ISPs do rate limiting and spam checking on outgoing mail. > Ironically, SPF makes this problem much easier for the virus operator, by > identifying the outgoing relays in DNS. These are the same relays that > will accept outgoing customer email. Not necessarily. You may need SMTP AUTH and there's no guarantee that the _incoming_ addresses of the cluster are the same as the outgoing addresses. > Yes, this is true of traditional address forgery. People forget that there > is no difference between open relays and closed relays, except that closed > relays only accept email from a particular address range. Spammer always > has a relay available if they choose. > > But with ordinary (non-SPF enhanced) forgery, the forged recipient > usually only gets _SOME_ bounces. With SPF, they get _ALL_ messages sent > by the spammer/abuser. This was one of the problems stated as to be > solved by SPF. SPF doesn't solve it, but makes it worse. Not really. Hardly anybody actually rejects for an SPF failure anyway. You can't -- you'd throw away too much valid mail. But you could say the same for _any_ spam filtering. SpamAssassin makes it worse far more than SPF does, because _far_ more people will reject for having a high SA score than they will for SPF. You're right, but I think it's a red herring. It's going to be the case for _any_ scheme which causes mail to be rejected by the ultimate recipient, when the relay may have accepted it. > > This is why you should always have MX backups which are capable of > > rejecting mail to unknown users at the domain, for example. > > This doesn't help with forged mail targeted at an existing address, which > I think is the goal of SPF/Sender-ID. Rejecting mail to unknown users is > implemented without SPF/Sender-ID. Its the forged mail to real users that > causes the subject problem. It's just another example of the general case -- anything the primary will reject, the backup should reject too. That's why you should be running identical spam and virus checking, for example. You're right, but it's still not specific to SPF; that's all I'm saying. Give me a break here -- it's rare that I defend SPF, utterly broken as it is :) > I'm not familiar enough with SES to comment. Sounds like I should spend > some time on it, though. Agreed. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Mon Dec 6 19:44:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12464 for ; Mon, 6 Dec 2004 19:44:32 -0500 (EST) 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 iB70I9HI057924; Mon, 6 Dec 2004 16:18:09 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB70I9G2057923; Mon, 6 Dec 2004 16:18:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pentafluge.infradead.org ([213.146.154.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB70I8Td057917 for ; Mon, 6 Dec 2004 16:18:09 -0800 (PST) (envelope-from SRS0+96e76b1feb5eb4f35618+471+infradead.org+dwmw2@pentafluge.srs.infradead.org) Received: from shinybook.infradead.org ([81.187.226.99]) by pentafluge.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1CbT3L-0002Iy-RM; Tue, 07 Dec 2004 00:18:04 +0000 Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] From: David Woodhouse To: Alan DeKok Cc: MXCOMP In-Reply-To: <20041206181152.E9E7316CC3@mail.nitros9.org> References: <20041206181152.E9E7316CC3@mail.nitros9.org> Content-Type: text/plain Date: Tue, 07 Dec 2004 00:17:38 +0000 Message-Id: <1102378658.5122.78.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3.dwmw2.1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 2004-12-06 at 13:11 -0500, Alan DeKok wrote: > You're assuming that messages go from source to destination in one > hop. While this is nice, the current design allows a message to > traverse multiple independent hops, all the while using the same "MAIL > FROM". This has a serious impact on the "blowback" problem, and any > possible solution. I'm not assuming that. I'm saying that SPF doesn't make the problem any worse than _other_ schemes will, if they cause the ultimate recipient to reject mail which the {backup MX, relay, forwarder} does not reject. SPF and SenderID have many flaws. This one isn't specific to SPF and SenderID. > Yes, but sharing live information about all of your users with a > backup MX is difficult to do in practice. That may be your experience; it's not mine. > If nothing else, the spammers are offloading some of their work onto > the backup MX, and using it to attack the primary. This attack has > serious consequences for the robustness of the email transport layer. Even to the extent that's true, it's not specific to SPF. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Mon Dec 6 19:44:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12482 for ; Mon, 6 Dec 2004 19:44:36 -0500 (EST) 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 iB70KNcU058302; Mon, 6 Dec 2004 16:20:23 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB70KNI7058301; Mon, 6 Dec 2004 16:20:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (ntbbs.winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id iB70KMjY058286 for ; Mon, 6 Dec 2004 16:20:22 -0800 (PST) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.3) for ietf-mxcomp@imc.org; Mon, 06 Dec 2004 19:26:36 -0500 Received: from ([65.10.113.141]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.3) with SMTP id 840500578; Mon, 06 Dec 2004 19:26:34 -0500 Message-ID: <008701c4dbf2$739771d0$6401a8c0@hdev1> From: "Hector Santos" To: "IETF-MXCOMP" , "Matthew Elvey" References: <20041125231151.9B4D516F4C@mail.nitros9.org> <1101456711.19141.57.camel@localhost.localdomain> <004a01c4d411$ada15320$6401a8c0@hdev1> <41B273B6.2040502@elvey.com> <003701c4da78$634ae580$6401a8c0@hdev1> <41B34AD1.2040107@elvey.com> <00e301c4db14$45c1bc90$6401a8c0@hdev1> <41B393C0.3000407@elvey.com> <001101c4db3c$9749bf90$6401a8c0@hdev1> Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] Date: Mon, 6 Dec 2004 19:19:33 -0500 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" 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 Matthew, is a good example of a mix policy with SPF and CBV. This is just one of the thousands logged by our system called WCSAP (Wildcat! Sender Authentication Protocol) which is a suite of many methods configurable by the admin. WCSAP is called by our WCSMTP server once the final destination user is established at RCTP TO: A number of parameters are passed, but the main ones are the CIP, CDN, RP (MAILFROM) and FP (RCPTTO) 18:25:01 version : 2.01 / 1.61 18:25:01 calltype : SMTP 18:25:01 state : rcpt 18:25:01 srvdom : winserver.com 18:25:01 srvip : 208.247.131.9 18:25:01 cip : 68.237.236.230 18:25:01 cdn : josiah 18:25:01 from : 18:25:01 rcpt : Data passed and logged 18:25:01 testorder : FLT RBL SPF CEP CBV Admin had internal white/black rule based filtering enabled, RBL, SPF, CEP (Microsoft Caller ID) and CBV (CallBack Verifier) 18:25:01 sapfilter : pass (time:63) It pass the FLT test (time is milliseconds) 18:25:01 saprbl : testing 230.236.237.68.sbl.spamhaus.org 18:25:01 saprbl : testing 230.236.237.68.list.dsbl.org 18:25:01 saprbl : testing 230.236.237.68.bl.spamcop.net 18:25:01 saprbl : pass (time:15) It pass the RBL test. 18:25:01 sapspf : v=spf1 mx ip4:212.80.76.43 ~all 18:25:01 sapspf : softfail (time:0) A test for SPF results in a SOFTFAIL. Admin as setup to continue testing. 18:25:01 sapcep : test from=seznam.cz 18:25:01 sapcep : test cdn=josiah 18:25:01 sapcep : none (time:16) A test for CEP is done with no result. Now the final CBV is done with is a call back to the return address: 18:25:01 sapcbv : total mx records: 2 18:25:01 try mx : mx1.seznam.cz ip: 212.80.76.44 18:25:01 # connecting to 212.80.76.44 18:25:02 S: 220 email.seznam.cz - Email zdarma na cely zivot ESMTP 18:25:02 C: NOOP WCSAP v2.01 Wildcat! Sender Authentication Protocol http://www.santronics.com 18:25:02 S: 250 ok 18:25:02 C: HELO mail.winserver.com 18:25:02 S: 250 email.seznam.cz - Email zdarma na cely zivot 18:25:02 C: MAIL FROM: <> 18:25:02 S: 250 ok 18:25:02 C: RCPT TO: 18:25:02 S: 553 sorry, no mailbox here by that name. (#5.1.1) 18:25:02 C: QUIT 18:25:02 sapcbv : 553 18:25:02 result : reject (0) 18:25:02 smtp code : 550 18:25:02 reason : Rejected by WCSAP CBV 18:25:02 wcsap finish (1110 msecs) The address is rejected and the 550 result code is returned to WCSMTP to be used as part of its response to the RCPT TO command. The total process took 1.1 secs. This is a good example of the exploitaiton that has and will continue to take place of the what I call the "relaxed policies" of SPF1 with its SOFTFAIL and NEUTRAL result possibilities. Sincerely, Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com 305-431-2846 Cell 305-248-3204 Office ----- Original Message ----- From: "Hector Santos" To: "IETF-MXCOMP" ; "Matthew Elvey" Sent: Sunday, December 05, 2004 9:37 PM Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] > > ----- Original Message ----- > From: "Matthew Elvey" > To: "Hector Santos" > Sent: Sunday, December 05, 2004 6:03 PM > Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] > > > > On 12/5/2004 1:48 PM, Hector Santos sent forth electrons to convey: > > > > >----- Original Message ----- > > >From: "Matthew Elvey" > > >To: "Hector Santos" > > >Sent: Sunday, December 05, 2004 12:52 PM > > >Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] > > > > > >The point is in order to accomplish this, the CSV (and others) state > machine > > >must be based on a delay design mechanism. > > > > > >Do I need to explain this? > > > > > > > > Yes. I don't know the term and > > http://www.google.com/search?q=%22delay+design+mechanism%22 > > brings up no hits. > > Ok, fair enough, I will explain it (see below) but keep in mind, a little > more elbow grease in your googling. i.e, using words like "SMTP DELAY > VALIDATION", etc, would of produced some hits. > > This is certainly not the first time this discussion or related concepts > were discussed at some level. > > > The only relation of > > "delay" to CSV is that there's a delay when a domain with a good > > reputation goes bad and that info needs to be discovered and propagated. > > No, no relationship to mixed validation ideas and issues. > > I will try to give you an example. I will do so with specific CVS examples, > but keep in mind the same or related issues applies to all the proposals. > > Keep in mind we are a product developer and the implementation of any new > idea into the system goes thru a very thorough "Software Walkthrough" review > process with many issues to be considered. > > In regards to SMTP, the following top design goals were sought: > > - Maximum SMTP Compatibility, > - Maximum Spoof protection/Validation at the transaction level, > - Maximum Efficiency and Scalability. > - Minimal to no interference with 2822 mail interpretation. > > The last one is based on our long history on online hosting product > experience (second to none) in dealing with US ECPA legal and related > issues. In short, we don't concern concerns with the administrative or > end-user level mail interpretation issues. Any new security ideas that will > stop the 'flow" of mail must be maintained at the transaction level for > product liability reasons. PS: I don't wish to go into this with anyone. > > Of course, it should go without saying that any new SMTP concepts should > deal with compatibility issues as well. Like any other vendor, we don't > wish to "break" their operations. > > However, this is very important in the area I feel is very important in > distinguishing problem we are trying to address. In short, our design > philosophy from the git-go has been the Spoof Problem is one that is a based > on an "Anonymous Final Destination Transaction" (AFDT). > > The reason is straight forward: > > The world wide SMTP internet email network is predominately based on the > following fundamental principle: > > - Trust is required for Relay or Routed transactions, > - No Trust is required for final destination transactions. > > In other words, for relay or routed transactions, the client/server > transaction has already negotiated a "trust" relationship. In practice, > this is traditional done using one or more of the following: > > - IP Relay Tables > - ESMTP AUTH > - POP3 BEFORE SMTP > > However, for a AFDT the "network" has worked because the above trust > relationship is not required. Yet, this is where the exploitation of SMTP > begins and it is the essence of the Spoof Problem that exist today. > > So for lack of a better term, "Anonymous Final Destination Transactions' is > where SMTP lacks strength and hence needs new ideas to help protect against > the abuse of the system. > > If you don't agree, you might as well stop here. But if you want to > understand what is meant by delay or mixed policies, then continue reading. > > Now, lets review the SMTP state machine: > > o connection state > o HELO/EHLO state > o MAIL FROM state > o RCPT TO state: > o DATA state: > > Since we are attempting to solve this problem in non-2822 terms, only in > 2821 terms, the data points for a transaction are: > > CIP - Client IP address (at the socket accept level) > CDN - Client Domain Name (issued at HELO/EHLO) > RP - Sender Return Path (MAIL FROM) > FP - Forwarding Path (RCPT TO) > > Using the following functional model to depict old (current) vs. new end > point validation concepts: > > result = EPV_OLD(cip, cpn, rp, fp) > result = EPV_NEW(cip, cpn, rp, fp) > > We can now begin to show how all the data points are related and/or mix > policies analysis is required to be considered. > > Given what was stated above about AFDT, no "new SMTP validation logic" is > required until it is known whether the transaction is a route or a final > destination. > > Therefore, one SMTP implementation would to delay all validations until FP > is provided at RCPT TO: > > if FP = Route then > Result = EPV_OLD(cip, cpn, rp,fp) > else > Result = EPV_NEW(cip, cpn, rp,fp) > > This says that if the forwarding path is for a route, then we only need to > use traditional, backward compatible SMTP authentication/validation trust > negotiation ideas that already exist and are standards in the market place. > > It also says that if FP is not a route but for a final destination, then > this is where we need to apply new validation ideas that are not currently a > standard. > > What does this all mean? > > Well, from a design standpoint, you have two options: > > - An open-ended check for each data point as they are provided, or > - A more efficient check based on one or more of all the possible data > points. > > Lets use CSV examples: > > Example 1 is the IDEAL "Good Transaction. All data points are valid. > > connection ip: 64.234.45.8 > HELO mail.elvey.com > MAIL FROM: matt@elvey.com > RCPT TO: hector@winserver.com > > In this case, you are connecting to our MX server at winserver.com, from > your own valid IP machine, issuing a valid client domain name and a > non-spoofed valid return address. Its all good. > > Example 2 is the bad transaction where you trying not authorized to route > via our server: > > connection ip: 64.234.45.8 > HELO mail.elvey.com > MAIL FROM: matt@elvey.com > RCPT TO: bill.gate@microsoft.com > > A few questions now come to mind: > > a) At which point do we apply CSV? > b) Can we use CSV to authenticate the route? > > If you had follow this so far, CSV is only needed at example #1 for a > AFDT. > > In example #2, you need to follow standard SMTP authentication on our > system in order to route. You have to have a prior relationship, either as > a MUA user or another trusted router. > > So unless you apply a delay validation technique, you are forced to use a > open-ended check prior to the FP is known. This is a very inefficient mode > of operations which has been proven to be the case in practice that require > DNS overhead just like CSV does. > > Lets look at Mixed Policies now. > > A new example #1.1 is similar to example #1 as a final destination > transaction but with a different sender, not you. I could of used your > address, but I wanted to highlight the difference. > > connection ip: 64.234.45.8 > HELO mail.elvey.com > MAIL FROM: user@somewhere.com > RCPT TO: hector@winserver.com > > It is an anonymous final destination and a transaction where additional > validation is required. We are using CSV here and lets assume you are a > member of Doug's new CSV/DNA authentication database. > > Lets also assume that the efficient delay validation is used so that CSV is > applied after RCPT TO is provided. The validation is delayed. No overhead > in this system. > > According to CSV specs, since you are authenticated via CSV/DNA based on the > CDN (HELO client domain) and CIP (client IP address), then we should "trust" > this transaction, however, the CSV does state that additional validation > may apply depending on the implementation. > > Since we have very suspicious sysops and since CSV does not address RP > (return path) validation, a system may which to add additional logic such > as SPF1 or SENDER ID to validate the return path domain. Keep in mind that > SPF1/SENDER ID or LMAP in general validates just the domain part of the > return path. Not the complete address. > > In any case, for the sake of the example, a SPF1/SENDER ID check results as > a FAIL. > > You know have a mix policy: > > The questions are: > > What does it mean? > What validation prevails? > What are the validations weights, if any? > Can the mix policy be use to trump one validation over the other? > > Lets look at some of these questions: > > Does this mean the CVS authenticated ELVEY.COM has a spammer user on this > system? > > Does this mean the CVS authenticated ELVEY.COM has a DNA attribute that > says: > > "[X] Reject if the Sender Path is invalid" > > Could it mean that CSV says a validated machine trump any other validation? > > Lets go a step further with another mix policy situation: > > Lets assume the sysop has implement a CBV (Call back Verifier) instead of > SPF. The CBV is designed to perform a callback to the return path MX domain > to validate the return address. > > Lets assume the CBV returns > > "550 Unknown user: user@somewhere.com" > > What does this say about the trust of an CVS authenticated ELVEY.COM system? > > Should ELVEY.COM get blacklisted? or should a report be sent? > > So on, and so on. > > The point in all this is that NONE of the proposals have taken a very > thorough "Software Walkthrough" and look at all the possibilities. > > Delay validation is a requirement in my book. Not only do you achieve > higher compatibility, you can save a very significant 35-60% in validation > overhead. > > No one proposal can be used unless it covers all bases. Thus unless someone > comes up with a merger of all the proposals, the advanced SMTP system today > will need a suite and they will have to deal with the mix policy issues at > some level. > > I hope this is sufficient Matthew. > > Sincerely, > > Hector Santos, CTO > Santronics Software, Inc. > http://www.santronics.com > 305-431-2846 Cell > 305-248-3204 Office > > > > > > > > > > From owner-ietf-mxcomp@mail.imc.org Mon Dec 6 19:59:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13937 for ; Mon, 6 Dec 2004 19:59:02 -0500 (EST) 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 iB70YHS8073263; Mon, 6 Dec 2004 16:34:17 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB70YHkC073262; Mon, 6 Dec 2004 16:34:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pentafluge.infradead.org ([213.146.154.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB70YGiT073235 for ; Mon, 6 Dec 2004 16:34:16 -0800 (PST) (envelope-from SRS0+96e76b1feb5eb4f35618+471+infradead.org+dwmw2@pentafluge.srs.infradead.org) Received: from shinybook.infradead.org ([81.187.226.99]) by pentafluge.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1CbTJ6-0002ND-Ec; Tue, 07 Dec 2004 00:34:21 +0000 Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] From: David Woodhouse To: Alan DeKok Cc: MXCOMP In-Reply-To: <20041207001304.E0B4016CC3@mail.nitros9.org> References: <20041207001304.E0B4016CC3@mail.nitros9.org> Content-Type: text/plain Date: Tue, 07 Dec 2004 00:33:55 +0000 Message-Id: <1102379635.5122.83.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3.dwmw2.1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 2004-12-06 at 19:13 -0500, Alan DeKok wrote: > Dean Anderson wrote: > > > But to be pedantic, that's the whole *point* of MAIL FROM > > > checking: to know who is using your domain name in MAIL FROM, and to > > > control their use of that name. > > > > Yes, I know that is "the point". However, this isn't possible. > > In theory or in practice? If it's possible in theory, it's possible > in practice. The only question then is whether the cost is acceptable. Anything's possible in theory, yes. In practice it requires a lot of the rest of the world co-operating, but yeah, it _could_ happen. Unless SES and DK and IIM and all the rest are shown not to be workable, I don't think anyone could claim that the cost is acceptable. > So... am I to be permitted to control the use of my own domain name? > If not, why not? If so, then I'm free to implement SPF, or anything > other scheme I like. In theory of course you can control the use of your own domain name. In theory you can also control the use of your own IP addresses. You can suddenly declare that the core routers may no longer use it on the packets they forward; that they must use their _own_ IP addresses and all else is 'forgery'. Good luck in getting them all to implement NAT for you. :) There is a difference between theory and practice. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Mon Dec 6 20:25:18 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15255 for ; Mon, 6 Dec 2004 20:25:18 -0500 (EST) 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 iB710Vgr002983; Mon, 6 Dec 2004 17:00:31 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB710VoH002982; Mon, 6 Dec 2004 17:00:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pentafluge.infradead.org ([213.146.154.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB710UAl002943 for ; Mon, 6 Dec 2004 17:00:31 -0800 (PST) (envelope-from SRS0+96e76b1feb5eb4f35618+471+infradead.org+dwmw2@pentafluge.srs.infradead.org) Received: from shinybook.infradead.org ([81.187.226.99]) by pentafluge.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1CbTiG-0002SJ-OE; Tue, 07 Dec 2004 01:00:21 +0000 Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] From: David Woodhouse To: Hector Santos Cc: Chris Haynes , MXCOMP In-Reply-To: <00a801c4dbf7$7f17fca0$6401a8c0@hdev1> References: <1102376075.5122.56.camel@localhost.localdomain> <00a801c4dbf7$7f17fca0$6401a8c0@hdev1> Content-Type: text/plain Date: Tue, 07 Dec 2004 00:59:54 +0000 Message-Id: <1102381195.5122.85.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3.dwmw2.1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 2004-12-06 at 19:55 -0500, Hector Santos wrote: > If you are using a SPF domain, then you either have your network correctly > setup for outbound mail or you dont. The network in which I participate is known as "the Internet". It is not 'correctly' setup for outbound mail, by the definition you're using. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Mon Dec 6 20:25:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15269 for ; Mon, 6 Dec 2004 20:25:19 -0500 (EST) 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 iB70uZnZ098365; Mon, 6 Dec 2004 16:56:35 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB70uZQf098364; Mon, 6 Dec 2004 16:56:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (mail.santronics.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id iB70uX97098309 for ; Mon, 6 Dec 2004 16:56:34 -0800 (PST) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.3) for ietf-mxcomp@imc.org; Mon, 06 Dec 2004 20:02:43 -0500 Received: from ([65.10.113.141]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.3) with SMTP id 842667437; Mon, 06 Dec 2004 20:02:41 -0500 Message-ID: <00a801c4dbf7$7f17fca0$6401a8c0@hdev1> From: "Hector Santos" To: "David Woodhouse" Cc: "Chris Haynes" , "MXCOMP" References: <1102376075.5122.56.camel@localhost.localdomain> Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] Date: Mon, 6 Dec 2004 19:55:44 -0500 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: "David Woodhouse" To: "Dean Anderson" Cc: "Chris Haynes" ; "MXCOMP" Sent: Monday, December 06, 2004 6:34 PM Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] > Not really. Hardly anybody actually rejects for an SPF failure anyway. > You can't -- you'd throw away too much valid mail. Not according to our 1 year plus of real production in thousands of sites. One thing is for sure to come to learn: Spammers don't complain. If there are FALSE positives for legit systems, you will quickly get reports or compliants. The one segment that are not complaining is the problem senders/spammers/spoofers. The reality is the former is extremely rare and when it is reported, it is all usually due to getting a network correctly configured which should of been the case in the first place. Our view is this: If you are using a SPF domain, then you either have your network correctly setup for outbound mail or you dont. The alternative is to use the relaxed provisions (softfail and neutral) in which case, it allows for a Receiver to perform further testing as I illustrated in my previous post regarding the mix policy. The main problem I see is that the "advertisement" the SPF people to tell all people to go ahead and publish a SPF DOMAIN in DNS even if your own servers are not SPF ready. That is half the problem as I see it today as evident with my own private email account with FastAccess Bellsouth. They added an SPF domain which brings the usage of legitimate users usage of Alias Addresses when the mail hits a SPF server downlink This is where the SUBMITTER proposal had some promise to assist. But it assumes the BellSouth Server was SPF/SUBMITTER ready (as well as downlinks) and its not. :-) Sincerely, Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com 305-431-2846 Cell 305-248-3204 Office From owner-ietf-mxcomp@mail.imc.org Mon Dec 6 20:37:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16325 for ; Mon, 6 Dec 2004 20:37:07 -0500 (EST) 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 iB718bEI010911; Mon, 6 Dec 2004 17:08:37 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB718bFG010910; Mon, 6 Dec 2004 17:08:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (mail.santronics.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id iB718ZxA010863 for ; Mon, 6 Dec 2004 17:08:36 -0800 (PST) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.3) for ietf-mxcomp@imc.org; Mon, 06 Dec 2004 20:14:54 -0500 Received: from ([65.10.113.141]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.3) with SMTP id 843398640; Mon, 06 Dec 2004 20:14:52 -0500 Message-ID: <00c201c4dbf9$32e7fae0$6401a8c0@hdev1> From: "Hector Santos" To: "David Woodhouse" Cc: "Chris Haynes" , "MXCOMP" References: <1102376075.5122.56.camel@localhost.localdomain> <00a801c4dbf7$7f17fca0$6401a8c0@hdev1> <1102381195.5122.85.camel@localhost.localdomain> Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] Date: Mon, 6 Dec 2004 20:07:41 -0500 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: "David Woodhouse" To: "Hector Santos" Cc: "Chris Haynes" ; "MXCOMP" Sent: Monday, December 06, 2004 7:59 PM Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] > On Mon, 2004-12-06 at 19:55 -0500, Hector Santos wrote: > > If you are using a SPF domain, then you either have your network correctly > > setup for outbound mail or you dont. > > The network in which I participate is known as "the Internet". It is not > 'correctly' setup for outbound mail, by the definition you're using. > Good point. However, by my definition, if you wish to use SPF by exposing your domain or network of domains to the SPF ready world, then you better be ready for it. My point is that you shouldn't use SPF if you don't have your network of outbound mail machines under its umbrella. Don't you agree? Sincerely, Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com 305-431-2846 Cell 305-248-3204 Office From owner-ietf-mxcomp@mail.imc.org Mon Dec 6 21:53:49 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21621 for ; Mon, 6 Dec 2004 21:53:48 -0500 (EST) 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 iB72N9xB092822; Mon, 6 Dec 2004 18:23:09 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB72N9XC092819; Mon, 6 Dec 2004 18:23:09 -0800 (PST) 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 iB72N9L3092800 for ; Mon, 6 Dec 2004 18:23:09 -0800 (PST) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 371B516CC3 for ; Mon, 6 Dec 2004 21:35:10 -0500 (EST) From: "Alan DeKok" To: MXCOMP Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] In-Reply-To: Your message of "Tue, 07 Dec 2004 00:33:55 GMT." <1102379635.5122.83.camel@localhost.localdomain> Date: Mon, 06 Dec 2004 21:35:10 -0500 Message-Id: <20041207023510.371B516CC3@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Woodhouse wrote: > Anything's possible in theory, yes. That's the problem, there are things which *are* impossible in theory. So if something is impossible in theory, there's no point in talking about it. If it's possible in theory, the discussion should then be cost of implementation. > In theory of course you can control the use of your own domain name. If I can't control the use in practice, then what value is there in the domain name? I've registered it and paid for it, but others are free to use it almost any way they want, without my knowledge or consent. Nice. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Mon Dec 6 22:03:18 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22023 for ; Mon, 6 Dec 2004 22:03:18 -0500 (EST) 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 iB72cEFg012286; Mon, 6 Dec 2004 18:38:14 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB72cEb9012282; Mon, 6 Dec 2004 18:38:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (news.winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id iB72cCmT012213 for ; Mon, 6 Dec 2004 18:38:12 -0800 (PST) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.3) for ietf-mxcomp@imc.org; Mon, 06 Dec 2004 21:44:25 -0500 Received: from ([65.10.113.141]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.3) with SMTP id 848769796; Mon, 06 Dec 2004 21:44:23 -0500 Message-ID: <012c01c4dc05$b4431960$6401a8c0@hdev1> From: "Hector Santos" To: "David Woodhouse" Cc: "MXCOMP" Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] Date: Mon, 6 Dec 2004 21:37:08 -0500 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 I wish to clarify my response David using a real-life (customer) example. >> ----- Original Message ----- >> From: "David Woodhouse" >> >> The network in which I participate is known as "the Internet". It is not >> 'correctly' setup for outbound mail, by the definition you're using. >> > My point is that you shouldn't use SPF if you don't have your network of > outbound mail machines under its umbrella. > > Don't you agree? In our experience, there are two key issues to contend with SPF domains: 1) Relaxed Provisions, 2) Heterogeneous Systems Relaxed Provisions: As I pointed out in one of my messages, I personally feel part of the problem with the SPF forwarding issue is the SPF web site marketing and promotion for Ntwork Amins to begin getting ready for SPF by first publishing SPF domains. This is recommended even if the server software is not SPF ready themselves. This has produced much of the forwarding issues that came about. The proposed recommendation, which in my view is a terrible recommendation, is to use a relaxed SPF provision called SOFTFAIL and NEUTRAL results. I say it is terrible because in my view, SPF attempts to to address a security problem yet introducing new ones. In addition, in our R&D, this has greatly increased the complexity of the software logic. Although, my research has shown that relaxed provisions can be used in analyzing mix policies in some cases, it has clearly shown that the permutations of trust states grows to levels that simple make the whole idea of SOFTFAIL and NEUTRAL unacceptable to deal with. I can show proof of this if any one is interested. Heterogeneous systems: In short, this means a MIX of compliant and non-compliant "Spoof Protection" systems within a company's network. As we quickly discovered when our system was official released to our customer base, some of the high end corporate systems who have invested thousands if not millions in corporate AVS frameworks, wanted to see how the new Wildcat! SMTP server SMTP level "Spoof Protector" can fit into their network. In short, to use but one example, we have a customer with the "Barracuda" ??? AVS system. Since we do not offer AVS solution directly (only integrated via a sysop definable programmable DATA hook) they wanted to continue using its AVS stuff, so they setup two MX: MX1 mail.Wildcat.Server MX2 mail.Barracuda.Server And they setup Barracuda.Server to route mail to Wildcat.Server, thus the forwarding problem begins. When mail hit Wildcat.Server, there are no issues. However, when hit mail hit Barracuda.Server there were issues. In essence, Barracuda is not SPF ready. It does its AVS checking and then routes the mail to Wildcat which performs the SPF check and thus fails for published SPF domains - the classic forwarding problem. So there are two issues here: The first one is the most likely realistic migration path many companies will take. An exploration of a solution within their current non-compliant framework. This is a factor all vendors must anticipate. The second, is the realization is that its a "all or nothing" solution. As I explained to the customer, they solutions were: 1) Wait until Barracuda added SPF and/or SUBMITTER support 2) Make MX2 a Wildcat! Server host with Barracuda as the AVS backend 3) If possible, program barracuda with sender-rewriting methods, 4) White list the Barracuda host. However, with the last option by white listing barracuda, the SPOOF protection was bypassed which defeated the purpose. Finally, I should note that in our experience this far, this was a very low support issue. Most Network admins are sharp enough to understand whats going on and will do what is takes to make it work or realize they are not ready to use this. Most similar incidents were with integrating enterprise Norton or McAfee systems as proxies. But this Barracuda incident was a good classic example of a heterogeneous network where someone invested in an expensive home security system with cameras, motion detections, guard dogs, etc, yet, they leave the front door key under the poach potted plant. To implement non-standard advanced SMTP stuff, you need to address and implement all "considerations" across the board. Sincerely, Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com 305-431-2846 Cell 305-248-3204 Office From owner-ietf-mxcomp@mail.imc.org Tue Dec 7 03:26:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01090 for ; Tue, 7 Dec 2004 03:26:36 -0500 (EST) 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 iB77gh5k051474; Mon, 6 Dec 2004 23:42:43 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB77ghlH051473; Mon, 6 Dec 2004 23:42:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from canuck.infradead.org (canuck.infradead.org [205.233.218.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB77gV5s050990 for ; Mon, 6 Dec 2004 23:42:36 -0800 (PST) (envelope-from SRS0+3d3dcfba1ddabaeb0f90+471+infradead.org+dwmw2@canuck.srs.infradead.org) Received: from shinybook.infradead.org ([81.187.226.99]) by canuck.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1CbZzM-0001N3-FY; Tue, 07 Dec 2004 02:42:25 -0500 Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] From: David Woodhouse To: Alan DeKok Cc: MXCOMP In-Reply-To: <20041207023510.371B516CC3@mail.nitros9.org> References: <20041207023510.371B516CC3@mail.nitros9.org> Content-Type: text/plain Date: Tue, 07 Dec 2004 07:41:53 +0000 Message-Id: <1102405313.5122.109.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3.dwmw2.1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-SRS-Rewrite: SMTP reverse-path rewritten from by canuck.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 2004-12-06 at 21:35 -0500, Alan DeKok wrote: > David Woodhouse wrote: > > Anything's possible in theory, yes. > > That's the problem, there are things which *are* impossible in > theory. So if something is impossible in theory, there's no point in > talking about it. If it's possible in theory, the discussion should > then be cost of implementation. Well yes, this is true; I had assumed we were speaking of things which may be achieved by a Turing Machine. But yes, the discussion should be about the cost of implementation. In this case there are options which are far cheaper in terms of interoperability, which I believe should be one of our primary 'cost' criteria. > > In theory of course you can control the use of your own domain name. > > If I can't control the use in practice, then what value is there in > the domain name? I've registered it and paid for it, but others are > free to use it almost any way they want, without my knowledge or > consent. No, not in _any_ way they want. They can't publish web pages in your domain, they can't run incoming mail servers for your domains, they can't publish your DK/IIM/MS keys and they can't run your SES message&address validation server. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Tue Dec 7 12:54:09 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29461 for ; Tue, 7 Dec 2004 12:54:07 -0500 (EST) 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 iB7HRHN8051248; Tue, 7 Dec 2004 09:27:17 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB7HRHxn051247; Tue, 7 Dec 2004 09:27:17 -0800 (PST) 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 iB7HRH8t051241 for ; Tue, 7 Dec 2004 09:27:17 -0800 (PST) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 60B5D16CC3 for ; Tue, 7 Dec 2004 12:39:16 -0500 (EST) From: "Alan DeKok" To: MXCOMP Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] In-Reply-To: Your message of "Tue, 07 Dec 2004 07:41:53 GMT." <1102405313.5122.109.camel@localhost.localdomain> Date: Tue, 07 Dec 2004 12:39:16 -0500 Message-Id: <20041207173916.60B5D16CC3@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Woodhouse wrote: > Well yes, this is true; I had assumed we were speaking of things which > may be achieved by a Turing Machine. Which cannot, in theory, perform certain calculations. My background is physics, and there's a well-known saying in that community, which is "if you give us infinite amounts of computing power, we will need more." > In this case there are options which are far cheaper in terms of > interoperability, which I believe should be one of our primary > 'cost' criteria. But do they do the same thing? I keep seeing statements like "proposal X doesn't break forwarding like SPF breaks it". But when I look at proposal X, most of the time, it doesn't do MAIL FROM checking, but something else. So the comparison is unwarranted. > [ re: using my domain name ] > > No, not in _any_ way they want. They can't publish web pages in your ^^ "almost" is the qualification I used. > domain, they can't run incoming mail servers for your domains, they > can't publish your DK/IIM/MS keys and they can't run your SES > message&address validation server. I understand. Systems use DNS domain names as a way of determining where to send traffic TO that domain. But there are no restrictions on the use of a domain name when traffic is allegedly being sent FROM that domain. For me, that's the crux of the problem. And it's a hard problem to solve in the physical world, too. If you look up the cable company's address in the phone book and visit there in person, you're pretty sure it really is the cable company you're talking to. But if someone comes to your door and claims to be the cable repair guy, you have few ways to verify he's really from the cable company. In the physical world, these problems are solved by calling the cable company, and asking them if they send a 6' 250lb guy named "bob". If they say yes, then you're likely to let him in. Similar approaches should be workable on the net. e.g. asking a domain via DNS whether it is really responsible for certain traffic which is using it's name. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Tue Dec 7 13:41:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29457 for ; Tue, 7 Dec 2004 12:54:06 -0500 (EST) 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 iB7HBa7l048754; Tue, 7 Dec 2004 09:11:36 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB7HBaDR048753; Tue, 7 Dec 2004 09:11:36 -0800 (PST) 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 iB7HBZis048747 for ; Tue, 7 Dec 2004 09:11:36 -0800 (PST) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 234E516E2A for ; Tue, 7 Dec 2004 12:23:35 -0500 (EST) From: "Alan DeKok" To: "MXCOMP" Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] In-Reply-To: Your message of "Mon, 06 Dec 2004 21:37:08 EST." <012c01c4dc05$b4431960$6401a8c0@hdev1> Date: Tue, 07 Dec 2004 12:23:35 -0500 Message-Id: <20041207172335.234E516E2A@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Hector Santos" wrote: > MX1 mail.Wildcat.Server > MX2 mail.Barracuda.Server ... > In essence, Barracuda is not SPF ready. It does its AVS checking and then > routes the mail to Wildcat which performs the SPF check and thus fails for > published SPF domains - the classic forwarding problem. Why are you having an MTA you control do SPF checks against another MTA you control? Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Tue Dec 7 14:37:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11024 for ; Tue, 7 Dec 2004 14:37:05 -0500 (EST) 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 iB7IxFOT087040; Tue, 7 Dec 2004 10:59:15 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB7IxEn7087035; Tue, 7 Dec 2004 10:59:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from canuck.infradead.org (canuck.infradead.org [205.233.218.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB7IwwGr086417 for ; Tue, 7 Dec 2004 10:59:07 -0800 (PST) (envelope-from SRS0+3d3dcfba1ddabaeb0f90+471+infradead.org+dwmw2@canuck.srs.infradead.org) Received: from [213.86.99.236] (helo=hades.cambridge.redhat.com) by canuck.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1CbkY2-00036P-Q6; Tue, 07 Dec 2004 13:58:56 -0500 Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] From: David Woodhouse To: Alan DeKok Cc: MXCOMP In-Reply-To: <20041207173916.60B5D16CC3@mail.nitros9.org> References: <20041207173916.60B5D16CC3@mail.nitros9.org> Content-Type: text/plain Date: Tue, 07 Dec 2004 18:58:51 +0000 Message-Id: <1102445932.11355.51.camel@hades.cambridge.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3.dwmw2.1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-SRS-Rewrite: SMTP reverse-path rewritten from by canuck.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 2004-12-07 at 12:39 -0500, Alan DeKok wrote: > But do they do the same thing? I keep seeing statements like > "proposal X doesn't break forwarding like SPF breaks it". But when I > look at proposal X, most of the time, it doesn't do MAIL FROM > checking, but something else. So the comparison is unwarranted. All proposals are different in their details; the important thing is what they can _achieve_. Take CSV and SPF, for example. Of course the details vary, but in practice they do exactly the same thing. Consider: MAIL FROM: From: aland@ox.org Precisely because SPF validates only one hop, it's achieving no more than CSV is. The recipient can look up how much they should trust 'forwarder.org' but you can't really tell if the message _really_ came from you. DK is similar but it uses the RFC2822 address of the most recent sender. It's still achieving basically the same thing -- a validated name of some kind, which you're expected to look up in your reputation database. SES does actually validate the MAIL FROM: address, and it survives traditional forwarding. > In the physical world, these problems are solved by calling the > cable company, and asking them if they send a 6' 250lb guy named > "bob". If they say yes, then you're likely to let him in. That sounds like a description of SES. You try to send mail from me to somewhere like sourceforge.net, and they'll call _my_ servers and ask if I send MAIL FROM:. When I say no, they'll reject the mail you're offering. Try it. The similar description of SPF would be more along the lines of "you call the cable company and ask them if the engineer they send will be coming from the northwest and enter through your rear gate". > Similar approaches should be workable on the net. e.g. asking a > domain via DNS whether it is really responsible for certain traffic > which is using it's name. "its name". But yes. The question is how you identify that traffic. In the case of mail, we all agree it would be stupid to identify the traffic by the MAC address on the packets. Many of us think it's similarly stupid to use the IP address on the packets. Many of us are offering other ways you could identify it. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Tue Dec 7 17:00:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03996 for ; Tue, 7 Dec 2004 17:00:18 -0500 (EST) 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 iB7LM19t024257; Tue, 7 Dec 2004 13:22:01 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB7LM1SQ024256; Tue, 7 Dec 2004 13:22:01 -0800 (PST) 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 iB7LLxqV024193 for ; Tue, 7 Dec 2004 13:21:59 -0800 (PST) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 8BB5C16CC3 for ; Tue, 7 Dec 2004 16:34:00 -0500 (EST) From: "Alan DeKok" To: MXCOMP Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] In-Reply-To: Your message of "Tue, 07 Dec 2004 18:58:51 GMT." <1102445932.11355.51.camel@hades.cambridge.redhat.com> Date: Tue, 07 Dec 2004 16:34:00 -0500 Message-Id: <20041207213400.8BB5C16CC3@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Woodhouse wrote: > Take CSV and SPF, for example. Of course the details vary, but in > practice they do exactly the same thing. They're looking at different fields in the SMTP header, so they're doing *something* different. > Precisely because SPF validates only one hop, it's achieving no more > than CSV is. I disagree. SPF validates the use of a name in MAIL FROM for *any* hop. CSV validates that an SMTP client is affiliated with a domain name it's using in EHLO. The validations are orthogonal, because they are validating different fields which do not have to be correlated. > That sounds like a description of SES. You try to send mail from me to > somewhere like sourceforge.net, and they'll call _my_ servers and ask if > I send MAIL FROM:. When I say no, they'll reject > the mail you're offering. Try it. There are multiple ways of doing this kind of check. The original one was RMX, which had it's benefits and limitations. SES looks to be a little more general, in that it doesn't have the IP address restrictions that RMX has. The issue SES has that RMX doesn't is that the cryptographic tokens it uses can be copied. e.g. Grab tokens from somewhere, and for a short period of time, use them to send spam to third parties. While there are ways to fix this issue, most involve a re-thinking of what we mean by "sending email". > "its name". But yes. The question is how you identify that traffic. Use of the name in a field in a protocol. e.g. EHLO or MAIL FROM. > In the case of mail, we all agree it would be stupid to identify > the traffic by the MAC address on the packets. Many of us think it's > similarly stupid to use the IP address on the packets. Many of us > are offering other ways you could identify it. Cryptographic approaches solve a lot of problems inherent in IP-based approaches, because they tie authentication to identity, and not to location. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Tue Dec 7 17:00:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04023 for ; Tue, 7 Dec 2004 17:00:20 -0500 (EST) 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 iB7LQHKq028695; Tue, 7 Dec 2004 13:26:17 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB7LQHwe028692; Tue, 7 Dec 2004 13:26:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB7LQCjF028560 for ; Tue, 7 Dec 2004 13:26:12 -0800 (PST) (envelope-from dotis@mail-abuse.org) Received: from [168.61.10.136] (SJC-Office-DHCP-136.Mail-Abuse.ORG [168.61.10.136]) (authenticated bits=0) by a.mail.sonic.net (8.12.11/8.12.11) with ESMTP id iB7LQFxj014031 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 7 Dec 2004 13:26:16 -0800 Subject: CSV BATV (CLEAR) DK IIM (MASS) From: Douglas Otis To: David Woodhouse Cc: MXCOMP In-Reply-To: <1102445932.11355.51.camel@hades.cambridge.redhat.com> References: <20041207173916.60B5D16CC3@mail.nitros9.org> <1102445932.11355.51.camel@hades.cambridge.redhat.com> Content-Type: text/plain Message-Id: <1102454584.2915.160.camel@littlejoy> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 07 Dec 2004 13:23:04 -0800 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, 2004-12-07 at 10:58, David Woodhouse wrote: > On Tue, 2004-12-07 at 12:39 -0500, Alan DeKok wrote: > > But do they do the same thing? I keep seeing statements like > > "proposal X doesn't break forwarding like SPF breaks it". But when I > > look at proposal X, most of the time, it doesn't do MAIL FROM > > checking, but something else. So the comparison is unwarranted. > > All proposals are different in their details; the important thing is > what they can _achieve_. Take CSV and SPF, for example. Of course the > details vary, but in practice they do exactly the same thing. Consider: > MAIL FROM: > From: aland@ox.org > > Precisely because SPF validates only one hop, it's achieving no more > than CSV is. The recipient can look up how much they should trust > 'forwarder.org' but you can't really tell if the message _really_ came > from you. > > DK is similar but it uses the RFC2822 address of the most recent sender. > It's still achieving basically the same thing -- a validated name of > some kind, which you're expected to look up in your reputation database. > > SES does actually validate the MAIL FROM: address, and it survives > traditional forwarding. A reference for SES is at http://ses.codeshare.ca/files/ses_proposal.pdf The CLEAR wg http://www.mipassoc.org/clear/ Are proposing use of BATV that uses a slightly different encapsulation of this extended information. Standardizing on this encapsulation is desired. A reference for BATV is at http://mipassoc.org/batv/index.html This different syntax (SES like), as proposed by William Leibzon for BATV, was addressed by Tony Finch and extracted as follows from the CLEAR archive: > Consider a site that does thorough verification of email addresses, > such that all BATV addresses are known to be valid and only appear on > messages sent by the address's owner. Say that whether BATV is used is > configurable per user. (This is similar to the deployment I am working > on.) The victim has BATV turned on and the attacker has it turned off, > so the attacker can use untagged return paths. The recipient knows a > bit about BATV and assumes that a message with a return-path address > that is tagged is actually from the apparent sender. > > So if the recipient gets a message starting > > Return-Path: > > they correctly infer that the message was sent by victim. > > However if they get a message starting > > Return-Path: > > and carelessly fail to eyeball the start of the address, they might > not notice that the message was from attacker not victim. > > This is a minor human factors problem, but it's still a security > consideration. As an additional note- Due to wildcard problems, SPF is unable to defend a domain as an abuser could exploit existing records to defeat policy statements asserted within SPF. With there also being a lack of agreement which domain referenced within a message should be checked, even assuming a check is made at every MTA node, there can be no assurance the domain asserted by the recipient as definitive is valid. Should SPF ever be used as a basis for reputation, there will be a great deal of effort needed to sort out the resulting confusion and damage. http://mipassoc.org/clear http://mipassoc.org/mass CLEAR and MASS are attempting to create relatively safe and less disruptive solutions for the immediate need to authenticate an accountable name for the mail channel. SPF only offers authorization (unfortunately easily spoofed or defeated), but never could it be said that such domain has been authenticated as actually sourcing the abuse detected through the results of SPF. Although a provider may offer to authorize their servers for a domain with SPF, the risks associated with respect to miss-applied reputation will be endured by the domain owner. The machine that has been compromised by a security breach is not located by such an SPF based reputation service. The name that is important is the name of the administering domain when dealing with security. The provider instead should be offering to implement BATV as an immediate solution for the spam bounce traffic that is really the driving motivation for SPF I suspect. This is relatively low risk for the domain owner. A few adjustments are still needed for this scheme to prevent a few glitches. Hence the need to standardize on the encapsulating syntax. -Doug From owner-ietf-mxcomp@mail.imc.org Tue Dec 7 18:27:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14176 for ; Tue, 7 Dec 2004 18:27:41 -0500 (EST) 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 iB7MpltU029158; Tue, 7 Dec 2004 14:51:47 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB7MplvQ029156; Tue, 7 Dec 2004 14:51:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sb7.songbird.com (sb7.songbird.com [208.184.79.137]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB7Mpg8f029029 for ; Tue, 7 Dec 2004 14:51:46 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11/8.12.11) with SMTP id iB7Mpi66030712 for ; Tue, 7 Dec 2004 14:51:45 -0800 From: Dave Crocker To: MXCOMP X-Mailer: PocoMail 3.2 (2004) - Licensed Version X-URL: brandenburg.com Reply-To: Dave Crocker Date: Tue, 7 Dec 2004 14:51:43 -0800 Message-ID: <2004127145143.967572@bbprime> In-Reply-To: <1102454584.2915.160.camel@littlejoy> Subject: Re: CSV BATV (CLEAR) DK IIM (MASS) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >  > All proposals are different in their details; the important thing is >  > what they can _achieve_. Take CSV and SPF, for example. Of course the >  > details vary, but in practice they do exactly the same thing. Consider: >  >         MAIL FROM: >  >         From: aland@ox.org >  >  >  > Precisely because SPF validates only one hop, it's achieving no more >  > than CSV is. The recipient can look up how much they should trust >  > 'forwarder.org' but you can't really tell if the message _really_ came >  > from you. SPF uses per-message validation. It can be viewed as validating the latest-hop sending MTA, but the validation is provided by the originating sender. Hence, SPF requires route registration. In truth it is validating the originating sender, where the latest-hop MTA is merely a way into that information. SPF uses per-session validation. Its validation is based on the latest-hop sender's administration, rather than stretching back to the origin. These are not small differences. In fact their semantics, administration and use are entirely different. d/ -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker  a t ... www.brandenburg.com From owner-ietf-mxcomp@mail.imc.org Tue Dec 7 18:34:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14690 for ; Tue, 7 Dec 2004 18:34:34 -0500 (EST) 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 iB7MxoYp037257; Tue, 7 Dec 2004 14:59:50 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB7MxoMd037256; Tue, 7 Dec 2004 14:59:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from canuck.infradead.org (canuck.infradead.org [205.233.218.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB7Mxffm036977 for ; Tue, 7 Dec 2004 14:59:50 -0800 (PST) (envelope-from SRS0+3d3dcfba1ddabaeb0f90+471+infradead.org+dwmw2@canuck.srs.infradead.org) Received: from shinybook.infradead.org ([81.187.226.99]) by canuck.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1CboJ1-0003sJ-BQ; Tue, 07 Dec 2004 17:59:40 -0500 Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] From: David Woodhouse To: Alan DeKok Cc: MXCOMP In-Reply-To: <20041207213400.8BB5C16CC3@mail.nitros9.org> References: <20041207213400.8BB5C16CC3@mail.nitros9.org> Content-Type: text/plain Date: Tue, 07 Dec 2004 22:59:02 +0000 Message-Id: <1102460342.5122.128.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3.dwmw2.1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-SRS-Rewrite: SMTP reverse-path rewritten from by canuck.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 2004-12-07 at 16:34 -0500, Alan DeKok wrote: > SPF validates the use of a name in MAIL FROM for *any* > hop. CSV validates that an SMTP client is affiliated with a domain > name it's using in EHLO. > > The validations are orthogonal, because they are validating > different fields which do not have to be correlated. In the SPF advocates' imaginary world where SRS is common, there's a _much_ stronger correlation between the two validations than there is in the real world today. > The issue SES has that RMX doesn't is that the cryptographic tokens > it uses can be copied. e.g. Grab tokens from somewhere, and for a > short period of time, use them to send spam to third parties. While > there are ways to fix this issue, most involve a re-thinking of what > we mean by "sending email". Some do. SES allows the sender to encode a message-digest in the reverse-path to prevent the replay attack. I probably wouldn't describe that option as 're-thinking' but I've entertained too many pointless debates on terminology (in particular 'forgery') to bother to try to ask precisely what you mean by that word. > > "its name". But yes. The question is how you identify that traffic. > > Use of the name in a field in a protocol. e.g. EHLO or MAIL FROM. Right. And it doesn't necessarily matter _which_ name as long as you can be sure the sending party is really supposed to be using that name. Which is why I don't agree with you that they're entirely orthogonal. They're different, it's true; but what they achieve in the long run is basically the same. > Cryptographic approaches solve a lot of problems inherent in > IP-based approaches, because they tie authentication to identity, and > not to location. Right. The cryptographic approaches make a lot more sense, as far as I can tell. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Tue Dec 7 19:17:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19200 for ; Tue, 7 Dec 2004 19:17:21 -0500 (EST) 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 iB7NhLat093836; Tue, 7 Dec 2004 15:43:21 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB7NhLTA093835; Tue, 7 Dec 2004 15:43:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from canuck.infradead.org (canuck.infradead.org [205.233.218.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB7NhK60093760 for ; Tue, 7 Dec 2004 15:43:20 -0800 (PST) (envelope-from SRS0+3d3dcfba1ddabaeb0f90+471+infradead.org+dwmw2@canuck.srs.infradead.org) Received: from shinybook.infradead.org ([81.187.226.99]) by canuck.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1CbozJ-00041b-7g; Tue, 07 Dec 2004 18:43:22 -0500 Subject: Re: CSV BATV (CLEAR) DK IIM (MASS) From: David Woodhouse To: Dave Crocker Cc: MXCOMP In-Reply-To: <2004127145143.967572@bbprime> References: <2004127145143.967572@bbprime> Content-Type: text/plain; charset=UTF-8 Date: Tue, 07 Dec 2004 23:42:44 +0000 Message-Id: <1102462964.5122.160.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3.dwmw2.1) Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-SRS-Rewrite: SMTP reverse-path rewritten from by canuck.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Tue, 2004-12-07 at 14:51 -0800, Dave Crocker wrote: > > > MAIL FROM: > > > From: aland@ox.org > > SPF uses per-message validation. It can be viewed as validating the > latest-hop sending MTA, but the validation is provided by the > originating sender. Hence, SPF requires route registration. In truth > it is validating the originating sender, where the latest-hop MTA is > merely a way into that information. > > [CSV]¹ uses per-session validation. Its validation is based on the > latest-hop sender's administration, rather than stretching back to the > origin. You're missing the point of the example you quoted. Look at it again. If you're receiving that mail from mailhost.forwarder.org to one of your thousands of users, you have to accept it because it may well be valid. All you can do is look up 'forwarder.org' or 'mailhost.forwarder.org' depending on whether it's SPF or CSV you're using. Either way, you only get to validate the "latest-hop sender's administration". -- dwmw2 ¹ Assumed correction -- you actually said 'SPF' again. From owner-ietf-mxcomp@mail.imc.org Tue Dec 7 20:06:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24423 for ; Tue, 7 Dec 2004 20:06:23 -0500 (EST) 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 iB80WCcm049722; Tue, 7 Dec 2004 16:32:12 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB80WCiE049721; Tue, 7 Dec 2004 16:32:12 -0800 (PST) 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 iB80WAix049631 for ; Tue, 7 Dec 2004 16:32:12 -0800 (PST) (envelope-from dotis@mail-abuse.org) Received: from [168.61.10.136] (SJC-Office-DHCP-136.Mail-Abuse.ORG [168.61.10.136]) (authenticated bits=0) by b.mail.sonic.net (8.12.11/8.12.11) with ESMTP id iB80WDUt012104 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 7 Dec 2004 16:32:13 -0800 Subject: Re: CSV BATV (CLEAR) DK IIM (MASS) From: Douglas Otis To: Dave Crocker Cc: MXCOMP In-Reply-To: <2004127145143.967572@bbprime> References: <2004127145143.967572@bbprime> Content-Type: text/plain Message-Id: <1102465741.2915.239.camel@littlejoy> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 07 Dec 2004 16:29:01 -0800 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, 2004-12-07 at 14:51, Dave Crocker wrote: > > > All proposals are different in their details; the important thing is > > > what they can _achieve_. Take CSV and SPF, for example. Of course the > > > details vary, but in practice they do exactly the same thing. Consider: > > > MAIL FROM: > > > From: aland@ox.org > > > > > > Precisely because SPF validates only one hop, it's achieving no more > > > than CSV is. The recipient can look up how much they should trust > > > 'forwarder.org' but you can't really tell if the message _really_ came > > > from you. > > SPF uses per-message validation. It can be viewed as validating the > latest-hop sending MTA, but the validation is provided by the > originating sender. Hence, SPF requires route registration. In truth > it is validating the originating sender, where the latest-hop MTA is > merely a way into that information. The word validation with respect to SPF is a bit vague. A more accurate term would be authorization. The lack of assurance of intervening nodes making a consistent check or their security removes assurances as to the originating sender. It would be better said that SPF validates the authorizations provided by the originating sender. Although authorization may be sufficient to assert favorable accreditations, authentication is required to hold a domain accountable for abuse. > [CSV] uses per-session validation. Its validation is based on the > latest-hop sender's administration, rather than stretching back to the > origin. More specifically, there is no assumption regarding intervening nodes making specific checks nor assumed security. CSV authenticates the domain administering the sending of the mail within the strength of the underlying IP infrastructure. This strength permits holding the domain administering the sending of mail accountable. The fact that both schemes form a response based upon the last hop misses two important points. One, the strength of any assertion with respect to accountability. Two, who is expected to respond to any problem. > These are not small differences. In fact their semantics, > administration and use are entirely different. Agreed. -Doug From owner-ietf-mxcomp@mail.imc.org Tue Dec 7 20:32:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26535 for ; Tue, 7 Dec 2004 20:32:23 -0500 (EST) 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 iB813OFj076069; Tue, 7 Dec 2004 17:03:24 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB813Oim076067; Tue, 7 Dec 2004 17:03:24 -0800 (PST) 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 iB813F6I075881 for ; Tue, 7 Dec 2004 17:03:17 -0800 (PST) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 313EE16CC3 for ; Tue, 7 Dec 2004 20:15:06 -0500 (EST) From: "Alan DeKok" To: MXCOMP Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] In-Reply-To: Your message of "Tue, 07 Dec 2004 22:59:02 GMT." <1102460342.5122.128.camel@localhost.localdomain> Date: Tue, 07 Dec 2004 20:15:06 -0500 Message-Id: <20041208011506.313EE16CC3@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Woodhouse wrote: > ... it doesn't necessarily matter _which_ name as long as you can > be sure the sending party is really supposed to be using that name. > Which is why I don't agree with you that they're entirely orthogonal. > They're different, it's true; but what they achieve in the long run is > basically the same. What I mean by "orthogonal" is that SMTP makes no requirements on the relationship between the values given in EHLO and MAIL FROM. They may use similar domain names, or they may use completely different domain names. So the fields are "orthogonal", because there is no dependency relationship between them. Now, *validation* of those fields can use correlations between their values to make decisions: e.g. EHLO mta.example.com MAIL FROM Since the recipient discovers for himself that the values of the two fields are correlated, he may choose to "merge" the field validation. e.g. "example.com says this IP really is mta.example.com, and is permitted to act as an SMTP client, so I'll assume that I don't have to ask example.com again about the use of it's name in the MAIL FROM field" If the two fields had different domain names, then the validation of those fields would have to be independent. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Tue Dec 7 22:22:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06608 for ; Tue, 7 Dec 2004 22:21:59 -0500 (EST) 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 iB82lqkd005028; Tue, 7 Dec 2004 18:47:52 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB82lqUM005027; Tue, 7 Dec 2004 18:47:52 -0800 (PST) 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 iB82lq34005011 for ; Tue, 7 Dec 2004 18:47:52 -0800 (PST) (envelope-from dotis@mail-abuse.org) Received: from [168.61.10.136] (SJC-Office-DHCP-136.Mail-Abuse.ORG [168.61.10.136]) (authenticated bits=0) by b.mail.sonic.net (8.12.11/8.12.11) with ESMTP id iB82lwso011417 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 7 Dec 2004 18:47:58 -0800 Subject: Re: CSV BATV (CLEAR) DK IIM (MASS) From: Douglas Otis To: MARID In-Reply-To: <1102465741.2915.239.camel@littlejoy> References: <2004127145143.967572@bbprime> <1102465741.2915.239.camel@littlejoy> Content-Type: text/plain Message-Id: <1102473886.5244.63.camel@littlejoy> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 07 Dec 2004 18:44:46 -0800 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, 2004-12-07 at 16:29, Douglas Otis wrote: Clarification of a clarification... > The word validation with respect to SPF is a bit vague. A more accurate > term would be authorization. The lack of assurance of intervening nodes > making a consistent check or their security removes assurances as to the > originating sender. It would be better said that SPF validates the > authorizations provided by the [purported] originating sender. Although > authorization may be sufficient to assert favorable accreditations, > authentication is required to hold a domain accountable for abuse. -Doug From owner-ietf-mxcomp@mail.imc.org Tue Dec 7 22:51:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09189 for ; Tue, 7 Dec 2004 22:51:53 -0500 (EST) 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 iB83Ku2j012447; Tue, 7 Dec 2004 19:20:56 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB83KtGs012446; Tue, 7 Dec 2004 19:20:55 -0800 (PST) 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 iB83Ktdm012437 for ; Tue, 7 Dec 2004 19:20:55 -0800 (PST) (envelope-from dean@av8.com) Received: from antigua.nuspex.com (citation2.av8.net [130.105.19.2]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id iB83KdK0018304 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 7 Dec 2004 22:20:45 -0500 Date: Tue, 7 Dec 2004 22:20:39 -0500 (EST) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: David Woodhouse cc: Chris Haynes , MXCOMP Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] In-Reply-To: <1102376075.5122.56.camel@localhost.localdomain> 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 Dec 2004, David Woodhouse wrote: > On Mon, 2004-12-06 at 13:28 -0500, Dean Anderson wrote: > > Just about everyone has admin rights over a machine these days. Some few > > machines have such rights limited. But even then, that's no indication > > that the admin is responsible or trustworthy. Not that I guess I feel > > very strongly about it either way. But, certainly, spammers can get port > > < 1024 if they want. > > I think we're talking at cross purposes here. I'm suggesting that one of > the flaws in the SPF draft -- that anyone with an account on a machine > which is listed can send 'authorised' mail -- could be alleviated by > having an _option_ to say that mail is only authorised if it comes from > a privileged port. I'm not suggesting that one should trust all mail > from a port < 1024 and not accept any from unprivileged ports, because > those with admin rights are 'responsible for a valuable asset' (to use > your terminology). Not at cross purposes. I understand exactly what you mean. However, for all practical purposes _anyone_ who wants to send mail has already or can obtain administrative control over their machine. Put another way, nearly all mail is sent from PC's or some sort of appliance-like machine. The sender and the "administrator" are the same person. They can send from any port they want. Sending from a port < 1024 means nothing. Last night, though, I did think of one reason this isn't such a good idea: Most unix/linux machines still enforce a requirement that to open a port less 1024 one must be root. This is a remnant of the days when machines were expensive, and it was thought that having "privileged" ports was a security feature. Presently, many mail systems give up root privilege as soon as possible to reduce root exploits, and so that mail queueing on such machines is performed by unprivileged processes. Putting your requirement into SPF would necessitate either removing the ancient "privileged ports" enforcement from the Linux/Unix kernel altogether, or reducing the security of the system. Non-linux/unix systems usually don't implement any notion of "priviledged ports". Even on Unix/Linux systems, its generatlly been more of security flaw than a feature. > > This is only true if no relay is involved. Every spammer has the right > > (at least until their account is terminated) to use their ISP's relay, if > > the choose. I think at present spammers and viruses send directly because > > it easier than figuring out the right relay to use at the ISP. > > And also because ISPs do rate limiting and spam checking on outgoing > mail. This is another myth. It is extremely difficult (to the point of practically impossible) to do rate limiting on outbound email for mail systems of any size. There was a rate-limiting freeware posted on the net some time ago, but it didn't work. I know of no ISPs that do Spam checking on outbound email, either. The notion of 'what is spam' depends on the recipient, not on the sender. > > Ironically, SPF makes this problem much easier for the virus operator, by > > identifying the outgoing relays in DNS. These are the same relays that > > will accept outgoing customer email. > > Not necessarily. You may need SMTP AUTH and SMTP AUTH does not help. That information is already on the compromised machine. Or if its a disposable account, then it was given to the spammer. The spammer/abuser has _ALL_ the privileges and capabilities of the user of the ISP. > there's no guarantee that the _incoming_ addresses of the cluster are > the same as the outgoing addresses. There is no guarrentee other than the economics that ISPs don't buy unnecessary mail servers. Mail servers are expensive, and cost money to operate and maintain. Separating inbound from outbound mail servers makes sense becaue the inbound mailservers have extra load of the mailboxes, and creating a separate set of outbound mailservers conveniently helps distribute load. But one would be unlikely to put in additional unnecessary layers. Economics would soon reverse such a decision. > > Yes, this is true of traditional address forgery. People forget that there > > is no difference between open relays and closed relays, except that closed > > relays only accept email from a particular address range. Spammer always > > has a relay available if they choose. > > > > But with ordinary (non-SPF enhanced) forgery, the forged recipient > > usually only gets _SOME_ bounces. With SPF, they get _ALL_ messages sent > > by the spammer/abuser. This was one of the problems stated as to be > > solved by SPF. SPF doesn't solve it, but makes it worse. > > Not really. Hardly anybody actually rejects for an SPF failure anyway. > You can't -- you'd throw away too much valid mail. But you could say > the same for _any_ spam filtering. SpamAssassin makes it worse far more > than SPF does, because _far_ more people will reject for having a high > SA score than they will for SPF. You're right, but I think it's a red > herring. It's going to be the case for _any_ scheme which causes mail to > be rejected by the ultimate recipient, when the relay may have accepted > it. Yes: You can't reject bcause not everyone uses SPF. But the _goal_ of SPF is to /reject/ forged mail, and thereby prevent forgery. SPF rejects forged mail We can't use SPF to reject email thereore, we have no rejection problem. This is only true as long as no one uses SPF to reject mail. But if no one uses SPF to reject forged mail, then it didn't prevent forgery. If you use SPF to reject forged email, it is now trivial for the abuser to arrange for 100% of the bounces to hit the forged sender's mailbox. That makes the problem _much_ worse. Spamassasin doesn't do anything like that. Its only "not worse" if SPF isn't used. And to the extent that SPF is used, its made worse. Suppose yokel.com starts rejecting mail based on SPF records. Now, abusers can forge mail to to yokel.com. Yokel.com rejects the mail, and the target gets 100% of the email. I saw exactly this sort of abuse of open relays. Abusers would queue up mail to a domain that blocked open relays. The relay then bounced every message. Through testing with different IP addresses and detailed logging, I found that the abuse was usually performed by people associated with open relay blacklists. I've learned a lot over the years about open relay abuse and abuse detection. I'll just summarize that the most effective tool was to block the open relay blacklists. They were the only ones scanning for open relays. Abuse only happened after the blacklists successfully scanned a relay. Preventing the scans prevented the abuse. Finally, the blacklists shut down, and abuse dropped off almost completely. SPF basically turns every relay into an open relay, and allows the same sort of abuse, only worse, but without the need to scan for open relays. If one were to determine authorship of SPF by its effects, one would think that open relay abusers wrote SPF. > > > This is why you should always have MX backups which are capable of > > > rejecting mail to unknown users at the domain, for example. > > > > This doesn't help with forged mail targeted at an existing address, which > > I think is the goal of SPF/Sender-ID. Rejecting mail to unknown users is > > implemented without SPF/Sender-ID. Its the forged mail to real users that > > causes the subject problem. > > It's just another example of the general case -- anything the primary > will reject, the backup should reject too. That's why you should be > running identical spam and virus checking, for example. I agree that its not necessarily specific to SPF. > You're right, but it's still not specific to SPF; that's all I'm saying. > Give me a break here -- it's rare that I defend SPF, utterly broken as > it 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 Tue Dec 7 23:16:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11249 for ; Tue, 7 Dec 2004 23:16:42 -0500 (EST) 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 iB83jPTI016902; Tue, 7 Dec 2004 19:45:25 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB83jP8S016901; Tue, 7 Dec 2004 19:45:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from primefactor.com (root@primefactor.com [65.104.206.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB83jOPZ016877 for ; Tue, 7 Dec 2004 19:45:24 -0800 (PST) (envelope-from mark@primefactor.com) Received: from [192.168.1.41] (user-206-158-52-64.postridge0.noment.net [206.158.52.64]) (authenticated bits=0) by primefactor.com (8.12.3/8.12.3/Debian-7.1) with ESMTP id iB83jRNN018633 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 7 Dec 2004 22:45:28 -0500 Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] From: Mark Shewmaker To: MXCOMP In-Reply-To: <1102376075.5122.56.camel@localhost.localdomain> References: <1102376075.5122.56.camel@localhost.localdomain> Content-Type: text/plain Message-Id: <1102477713.23350.403.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 07 Dec 2004 22:48:34 -0500 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/588/Sun Nov 14 19:06:21 2004 clamav-milter version 0.80j on primefactor.com X-Virus-Status: Clean X-Authenticated-Sender: user mark from 206.158.52.64 X-Scanned-By: milter-sender/0.55.730 (primefactor.com [65.104.206.80]); Tue, 07 Dec 2004 22:45:28 -0500 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 2004-12-06 at 18:34, David Woodhouse wrote: > I'm suggesting that one of > the flaws in the SPF draft -- that anyone with an account on a machine > which is listed can send 'authorised' mail -- could be alleviated by > having an _option_ to say that mail is only authorised if it comes from > a privileged port. I see three types of solutions: 1. Publish valid outgoing ports that sending servers will use, and make sure that your sending mail server users, and only your sending mail server users (or programs), use those ports. 2. Publish lists of user IDs that may send mail from your machine, (or publish a mapping of user IDs and valid user names), and set up your identd server to answer queries about outgoing smtp servers appropriately. But in both the above cases, you're configuring ports and user id's that are allowed to do something, publishing a ruleset, and asking *someone else* to check the ruleset. Since you have all the information available yourself, why not just do egress checking yourself, and not burden the receiver? To me that's the more reasonable solution, (and it doesn't require you to expose your internal policies to the outside world): 3. Make sure that no mail *can* leave your machine that violates your policies. This means doing egress checking to prevent cross-customer forgeries, for example, as well as spf egress checks, to make sure that mail is never sent from your machine that would result in an spf fail at the destination. The simplest way of doing #3 is to firewall outgoing connections to remote port 25's, requiring all code that makes such connections to go through trusted code instead. (This assumes that your trusted mail submission code follows your policies.) Untrusted code that attempts to make outgoing port 25 connections directly would then fail, or perhaps you could set up a local transparent proxy through which trusted code would do the necessary egress checking. (I think this makes the most sense, and I expect it to become easier to do over time.) Note that if you publish your "port from" rules, you're going to have to make the same sort of decisions about the above, making sure that activities that violate your policies are detectable by others, so others can act upon them. But if those policy violations made within your own machine are detectable by others, instead of asking others to enforce your internal policies, to me it makes more sense to just detect these violations and enforce them yourself. -- Mark Shewmaker mark@primefactor.com From owner-ietf-mxcomp@mail.imc.org Wed Dec 8 00:48:03 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18996 for ; Wed, 8 Dec 2004 00:48:02 -0500 (EST) 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 iB858JmP018375; Tue, 7 Dec 2004 21:08:19 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB858Jh9018372; Tue, 7 Dec 2004 21:08:19 -0800 (PST) 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 iB858CQd018258 for ; Tue, 7 Dec 2004 21:08:12 -0800 (PST) (envelope-from dean@av8.com) Received: from antigua.nuspex.com (citation2.av8.net [130.105.19.2]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id iB858Ga3020298 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 8 Dec 2004 00:08:18 -0500 Date: Wed, 8 Dec 2004 00:08:16 -0500 (EST) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Alan DeKok cc: MXCOMP Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] In-Reply-To: <20041207001304.E0B4016CC3@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 Dec 2004, Alan DeKok wrote: > > Dean Anderson wrote: > > > But to be pedantic, that's the whole *point* of MAIL FROM > > > checking: to know who is using your domain name in MAIL FROM, and to > > > control their use of that name. > > > > Yes, I know that is "the point". However, this isn't possible. > > In theory or in practice? If it's possible in theory, it's possible > in practice. The only question then is whether the cost is acceptable. Its not possible in theory with SPF. In theory, SPF can't achieve the goal it set out to achieve. > If it's not possible in theory, I'm curious to know why. We're just going over the reasons, for purposes of summarizing them. > > Hence the conclusion that "SPF is breaking the mail system for no > > good reason". > > So... am I to be permitted to control the use of my own domain name? > If not, why not? Its not a matter of "permit". Its a matter of "is it possible to control abuse of your domain", and more specifically, its a matter of "does SPF enable control over your domain". SPF offers no control for about 13+ reasons. Of course you are permitted to control your domain. You can sue anyone you want to. But there is no technical way to make it impossible for someone to forge your address using the tools proposed by SPF. > If so, then I'm free to implement SPF, or anything other scheme I like. You are always free to shoot yourself in the foot. We can't stop you from doing so; we can only explain that you are about to do so, before you do so. -- 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 Dec 8 00:49:44 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19119 for ; Wed, 8 Dec 2004 00:49:44 -0500 (EST) 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 iB85I4M7032167; Tue, 7 Dec 2004 21:18:04 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB85I4ft032166; Tue, 7 Dec 2004 21:18:04 -0800 (PST) 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 iB85I4Gb032149 for ; Tue, 7 Dec 2004 21:18:04 -0800 (PST) (envelope-from dean@av8.com) Received: from antigua.nuspex.com (citation2.av8.net [130.105.19.2]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id iB85IArZ020480 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 8 Dec 2004 00:18:10 -0500 Date: Wed, 8 Dec 2004 00:18:09 -0500 (EST) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: David Woodhouse cc: Alan DeKok , MXCOMP Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] In-Reply-To: <1102378658.5122.78.camel@localhost.localdomain> 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 Dec 2004, David Woodhouse wrote: > > On Mon, 2004-12-06 at 13:11 -0500, Alan DeKok wrote: > > You're assuming that messages go from source to destination in one > > hop. While this is nice, the current design allows a message to > > traverse multiple independent hops, all the while using the same "MAIL > > FROM". This has a serious impact on the "blowback" problem, and any > > possible solution. > > I'm not assuming that. I'm saying that SPF doesn't make the problem any > worse than _other_ schemes will, if they cause the ultimate recipient to > reject mail which the {backup MX, relay, forwarder} does not reject. Err, no. SPF does make the blowback problem much worse. Other schemes create a few percent blowback. SPF enables 100% blowback. Thats much worse. > > Yes, but sharing live information about all of your users with a > > backup MX is difficult to do in practice. > > That may be your experience; it's not mine. That's a general experience with any large mail system. Its also a problem where different vendors provide backup mail services. Its only not a problem on simple, small single server systems. -- 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 Dec 8 00:55:29 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19488 for ; Wed, 8 Dec 2004 00:55:29 -0500 (EST) 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 iB85QRuO044330; Tue, 7 Dec 2004 21:26:27 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB85QRiG044329; Tue, 7 Dec 2004 21:26:27 -0800 (PST) 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 iB85QRwM044310 for ; Tue, 7 Dec 2004 21:26:27 -0800 (PST) (envelope-from dean@av8.com) Received: from antigua.nuspex.com (citation2.av8.net [130.105.19.2]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id iB85QKvM020662 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 8 Dec 2004 00:26:20 -0500 Date: Wed, 8 Dec 2004 00:26:19 -0500 (EST) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Hector Santos cc: David Woodhouse , Chris Haynes , MXCOMP Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] In-Reply-To: <00a801c4dbf7$7f17fca0$6401a8c0@hdev1> 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 Dec 2004, Hector Santos wrote: > One thing is for sure to come to learn: > > Spammers don't complain. If there are FALSE positives for legit systems, That's because spammer's rushed to install SPF records. Of _course_ they don't complain. That ought to be a signal right there. That's rather like saying the insurgents don't complain about soldiers roughing people up, or leaving the WMD sites with the very high explosives unguarded. --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 Dec 8 05:14:48 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09396 for ; Wed, 8 Dec 2004 05:14:48 -0500 (EST) 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 iB89OA6W027526; Wed, 8 Dec 2004 01:24:11 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB89OAjZ027519; Wed, 8 Dec 2004 01:24:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost0.mail.uk.easynet.net (smarthost0.mail.uk.easynet.net [212.135.6.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB89O9Zc026996 for ; Wed, 8 Dec 2004 01:24:10 -0800 (PST) (envelope-from chris@harvington.org.uk) Received: from [62.53.0.15] (helo=ringo) by smarthost0.mail.uk.easynet.net with smtp (Exim 4.10) id 1Cby39-000NU6-00 for ietf-mxcomp@imc.org; Wed, 08 Dec 2004 09:23:55 +0000 Message-ID: <04a601c4dd06$de9c3d20$0200000a@ringo> From: "Chris Haynes" To: "MXCOMP" References: Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] Date: Wed, 8 Dec 2004 09:18:17 -0000 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.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On December 08, 2004 5:18 AM +00 "Dean Anderson" sent: > Err, no. SPF does make the blowback problem much worse. Other schemes > create a few percent blowback. SPF enables 100% blowback. Thats much > worse. I hesitate to (re-)enter this thread, and, once again, I'm trying to be fair and understand the substantive basis for concerns.. It has been argued in SPF circles, that if you receive a message which the (purported) sender's policy declares to be a hard failure (-), the message is _proven_ to be a forgery, an unauthorised re-transmission, or whatever. Since the purported sender has repudiated the message, the argument goes, the original SMTP 'contract' to "deliver or bounce" is null-and-void, since whoever actually injected the message did so without the authority of the domain they cited. Therefore it is acceptable to 'silently discard' such messages, and not send bounces. Do you have any sympathy with that reasoning, and would it change your view about 100% blowback? Or is there some other mechanism within SPF which accounts for your '100% blowback' concern? Chris Haynes From owner-ietf-mxcomp@mail.imc.org Wed Dec 8 08:08:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20350 for ; Wed, 8 Dec 2004 08:08:54 -0500 (EST) 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 iB8CYQTh020898; Wed, 8 Dec 2004 04:34:26 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB8CYQLb020886; Wed, 8 Dec 2004 04:34:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from canuck.infradead.org (canuck.infradead.org [205.233.218.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB8CYAcG020128 for ; Wed, 8 Dec 2004 04:34:19 -0800 (PST) (envelope-from SRS0+0105bb8cd289da57b0d9+472+infradead.org+dwmw2@canuck.srs.infradead.org) Received: from shinybook.infradead.org ([81.187.226.99]) by canuck.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1Cc118-0007dH-LR; Wed, 08 Dec 2004 07:34:04 -0500 Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] From: David Woodhouse To: Chris Haynes Cc: MXCOMP In-Reply-To: <04a601c4dd06$de9c3d20$0200000a@ringo> References: <04a601c4dd06$de9c3d20$0200000a@ringo> Content-Type: text/plain Date: Wed, 08 Dec 2004 12:33:19 +0000 Message-Id: <1102509199.5122.198.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3.dwmw2.1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-SRS-Rewrite: SMTP reverse-path rewritten from by canuck.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-12-08 at 09:18 +0000, Chris Haynes wrote: > I hesitate to (re-)enter this thread, and, once again, I'm trying to be fair and > understand the substantive basis for concerns.. _You're_ trying to be fair? I actually found myself defending SPF slightly :) > Since the purported sender has repudiated the message, the argument goes, the > original SMTP 'contract' to "deliver or bounce" is null-and-void, since whoever > actually injected the message did so without the authority of the domain they > cited. Therefore it is acceptable to 'silently discard' such messages, and not > send bounces. If SPF (or indeed anything) is checked by a receiving site, it should cause a _rejection_. Neither 'silently discard' nor 'send bounces' is acceptable behaviour. If the recipient doesn't like the mail, it shouldn't accept it in the first place. Sending bounces is obviously bogus, if you think it didn't come from that reverse-path in the first place. Silently discarding it is also bogus since SPF has too many false negatives and you'd be throwing away valid mail without even letting the sender know you did so. By rejecting mail at SMTP time, you cause the majority of the spammer zombies to move on to the next address without comment, and the genuine forwarder to send a bounce. > Or is there some other mechanism within SPF which accounts for your '100% > blowback' concern? Personally I don't agree with Dean's 'blowback' concerns; I don't see that SPF makes it any worse than any other scheme which would reject the same mail. But I'm not going to argue any more in favour of SPF :) -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Wed Dec 8 11:27:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11583 for ; Wed, 8 Dec 2004 11:27:58 -0500 (EST) 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 iB8FpcGa045970; Wed, 8 Dec 2004 07:51:38 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB8FpcKh045969; Wed, 8 Dec 2004 07:51:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smarthost2.mail.uk.easynet.net (smarthost2.mail.uk.easynet.net [212.135.6.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB8FpXIL045914 for ; Wed, 8 Dec 2004 07:51:33 -0800 (PST) (envelope-from chris@harvington.org.uk) Received: from [62.53.0.15] (helo=ringo) by smarthost2.mail.uk.easynet.net with smtp (Exim 4.10) id 1Cc46G-0007o1-00; Wed, 08 Dec 2004 15:51:32 +0000 Message-ID: <051801c4dd3d$06166110$0200000a@ringo> From: "Chris Haynes" To: "David Woodhouse" Cc: "MXCOMP" References: <04a601c4dd06$de9c3d20$0200000a@ringo> <1102509199.5122.198.camel@localhost.localdomain> Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] Date: Wed, 8 Dec 2004 15:45:53 -0000 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.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit "David Woodhouse" responded: > On Wed, 2004-12-08 at 09:18 +0000, Chris Haynes wrote: > > I hesitate to (re-)enter this thread, and, once again, I'm trying to be fair and > > understand the substantive basis for concerns.. > > _You're_ trying to be fair? I actually found myself defending SPF > slightly :) > Yes, I noticed - a fascinating spectator-sport! I was interested to seek Dean's extended views on blowback. Chris From owner-ietf-mxcomp@mail.imc.org Wed Dec 8 13:52:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23590 for ; Wed, 8 Dec 2004 13:52:58 -0500 (EST) 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 iB8IC5es048509; Wed, 8 Dec 2004 10:12:05 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB8IC5eT048508; Wed, 8 Dec 2004 10:12:05 -0800 (PST) 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 iB8IBus2048184 for ; Wed, 8 Dec 2004 10:11:58 -0800 (PST) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id BABD916CC3 for ; Wed, 8 Dec 2004 13:23:46 -0500 (EST) From: "Alan DeKok" To: "MXCOMP" Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] In-Reply-To: Your message of "Wed, 08 Dec 2004 09:18:17 GMT." <04a601c4dd06$de9c3d20$0200000a@ringo> Date: Wed, 08 Dec 2004 13:23:46 -0500 Message-Id: <20041208182346.BABD916CC3@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Chris Haynes" wrote: > It has been argued in SPF circles, that if you receive a message > which the (purported) sender's policy declares to be a hard failure > (-), the message is _proven_ to be a forgery, an unauthorised > re-transmission, or whatever. i.e. in SPF, the argument is that the discard "should" be done during message delivery phase, by the sender. This requires non-SPF-aware senders to change their behaviour when they interact with SPF-aware receipients. That won't work. In other MAIL FROM validation schemes (SES, BATV), the MAIL FROM can be rewritten so that the forwarder implementing the scheme also accepts responsibility for the bounces. This means that any "discard" decision will be made by the sender, when the recipient rejects the message. This may change they way senders work, but that's OK, because the sender has already changed to implement SES. Or, the discard decision is made by the receiver, during the "bounce" phase, when the sender refuses to accept the bounce. This requires no changes on non-SES-aware senders, as it's already a known failure mode of message delivery. > Since the purported sender has repudiated the message, the argument > goes, the original SMTP 'contract' to "deliver or bounce" is > null-and-void, since whoever actually injected the message did so > without the authority of the domain they cited. Therefore it is > acceptable to 'silently discard' such messages, and not send > bounces. If attackers discover MAIL FROM values which temporarily pass SES checks, they can re-use them to send messages through non-SES-aware senders. When SES-aware recipients discover that the alleged originating site has repudiated the MAIL FROM value, they will reject the message, and the sender may bounce it back to the alleged originating site. This failure mode is the same as Dean's "blow-back" argument for SPF. (Assuming I've described SES correctly, based on my quick skimming of the documents.) It's also a attack mode of *any* system doing MAIL FROM validation. Until all sites implement the validation, the attack mode will exist. It can be mitigated with SES-like schemes, but it's more difficult to mitigate it with SPF. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Wed Dec 8 14:14:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25422 for ; Wed, 8 Dec 2004 14:14:53 -0500 (EST) 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 iB8IlpbB082720; Wed, 8 Dec 2004 10:47:51 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB8Ilp8S082719; Wed, 8 Dec 2004 10:47:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from xuxa.iecc.com (xuxa.iecc.com [208.31.42.42]) by above.proper.com (8.12.11/8.12.9) with SMTP id iB8IlnMT082694 for ; Wed, 8 Dec 2004 10:47:50 -0800 (PST) (envelope-from prvs=johnl/076070aa94@iecc.com) Received: (qmail 24760 invoked by uid 100); 8 Dec 2004 18:47:51 -0000 Date: 8 Dec 2004 18:47:51 -0000 Message-ID: <20041208184751.24759.qmail@xuxa.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: Re: blowback, was A new SMTP "3821" [Re: FTC stuff...........] In-Reply-To: <04a601c4dd06$de9c3d20$0200000a@ringo> Organization: I.E.C.C., Trumansburg NY USA Cc: chris@harvington.org.uk Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >It has been argued in SPF circles, that if you receive a message >which the (purported) sender's policy declares to be a hard failure >(-), the message is _proven_ to be a forgery, an unauthorised >re-transmission, or whatever. If the policy is only "-all", i.e., this domain sends no mail at all, then the policy is credible. If the policy is anything else followed by -all, it's not. One of SPF's many problems is that it posits a model of the e-mail world that is a lot simpler than the real world. In the real world, there are whole lot of remailers and forwarders, and no matter how desperately some domains might want to argue that nobody's allowed to forward, etc., those arguments are about as persuasive as the boilerplate likely found at the bottom of their mail that says "if we sent you this mail by mistake you must hand deliver it back to us or go to jail." People want their bank statements or whatever, even if the address they give to the bank is their permanent forwarding address from their alma mater. I do agree that bounces vs. rejects are an increasing problem, and I'm having trouble figuring out if there's any way I can do bounces reasonably for the fraction of the mail here for which I can't tell if it's deliverable at SMTP time. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY http://www.taugh.com From owner-ietf-mxcomp@mail.imc.org Wed Dec 8 14:50:44 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27710 for ; Wed, 8 Dec 2004 14:50:44 -0500 (EST) 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 iB8JKnbi001071; Wed, 8 Dec 2004 11:20:49 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB8JKn18001070; Wed, 8 Dec 2004 11:20:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from canuck.infradead.org (canuck.infradead.org [205.233.218.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB8JKWS4001003 for ; Wed, 8 Dec 2004 11:20:45 -0800 (PST) (envelope-from SRS0+0105bb8cd289da57b0d9+472+infradead.org+dwmw2@canuck.srs.infradead.org) Received: from [213.86.99.236] (helo=hades.cambridge.redhat.com) by canuck.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1Cc7MU-0001XC-FD; Wed, 08 Dec 2004 14:20:31 -0500 Subject: Re: blowback, was A new SMTP "3821" [Re: FTC stuff...........] From: David Woodhouse To: John Levine Cc: ietf-mxcomp@imc.org, chris@harvington.org.uk In-Reply-To: <20041208184751.24759.qmail@xuxa.iecc.com> References: <20041208184751.24759.qmail@xuxa.iecc.com> Content-Type: text/plain Date: Wed, 08 Dec 2004 19:20:27 +0000 Message-Id: <1102533627.13753.41.camel@hades.cambridge.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3.dwmw2.1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-SRS-Rewrite: SMTP reverse-path rewritten from by canuck.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-12-08 at 18:47 +0000, John Levine wrote: > I do agree that bounces vs. rejects are an increasing problem, and > I'm having trouble figuring out if there's any way I can do bounces > reasonably for the fraction of the mail here for which I can't tell > if it's deliverable at SMTP time. The only real answer I've found is to make sure that during _normal_ operation, there isn't actually any mail in that category ("can't tell if it's deliverable at SMTP time"). I do recipient verification callouts (with caching, of course) for the domains for which I am MX backup (and in some cases, also for mail I'm forwarding). Obviously it's pointless being an MX backup unless you actually accept the mail while the primary is down; but that's not normal operation. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Wed Dec 8 16:28:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04749 for ; Wed, 8 Dec 2004 16:28:51 -0500 (EST) 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 iB8KvG3E072256; Wed, 8 Dec 2004 12:57:16 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB8KvGPR072255; Wed, 8 Dec 2004 12:57:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB8Kv44Y072005 for ; Wed, 8 Dec 2004 12:57:11 -0800 (PST) (envelope-from matthew@elvey.com) Received: from frontend3.messagingengine.com (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 31D1DC40971; Wed, 8 Dec 2004 15:57:01 -0500 (EST) X-Sasl-enc: IBWl5uyaotoWTP2zFIdUEA 1102539421 Received: from [192.168.1.141] (ns.nextbus.com [64.164.28.194]) by frontend3.messagingengine.com (Postfix) with ESMTP id 79474247F3; Wed, 8 Dec 2004 15:57:00 -0500 (EST) Message-ID: <41B76A9C.4020906@elvey.com> Date: Wed, 08 Dec 2004 12:57:00 -0800 From: Matthew Elvey User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hector Santos Cc: MXCOMP Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] References: <20041125231151.9B4D516F4C@mail.nitros9.org> <1101456711.19141.57.camel@localhost.localdomain> <004a01c4d411$ada15320$6401a8c0@hdev1> <41B273B6.2040502@elvey.com> <003701c4da78$634ae580$6401a8c0@hdev1> <41B34AD1.2040107@elvey.com> <00e301c4db14$45c1bc90$6401a8c0@hdev1> <41B393C0.3000407@elvey.com> <001101c4db3c$9749bf90$6401a8c0@hdev1> <008701c4dbf2$739771d0$6401a8c0@hdev1> In-Reply-To: <008701c4dbf2$739771d0$6401a8c0@hdev1> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=UTF-8; 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 You had claimed: > The point is in order to accomplish this, the CSV (and others) state > machine must be based on a delay design mechanism. This is totally false, and is not supported at all by your 15K post, which I have slogged through. I am familiar with your claim that one MUST wait 'till RCPT TO: to do any validation. It's a false claim. Certainly doing so might be more efficient. That's not a false claim. Re. Mixed policies discussion: 1)It's CSV, not CVS. 2)What part of > This is out of scope for CSV. IIRC, you've produced a doc that > addresses this scope (or "presumes to", to use your own words) for a > certain set of policies; it could could be revised to encompass CSV. > CSV does not purport to do the coupling you claim it does not do > properly. do you not understand? We are in what's called 'violent agreement'. We AGREE: CSV must be considered in the reality of mixed policies. CSV *ITSELF* does not do so, however. We AGREE: doing the checks that are least costly first (which MAY mean delaying validation) is a good idea! In terms of the specific mixed policy issues you raised: One only trusts Accredidation and Reputation services that one feels are Reputable! If the USA's DMA runs such a service, I doubt many folks will trust it! >> Should ELVEY.COM get blacklisted? or should a report be sent? > IMO, a blacklist that blacklists based on a delivery attempt *without having seen the content of the email, and therefore having no good way to know whether it was UBE* should not be trusted; there are legitimate reasons for CBV failures, IMO. So IMO, no. But again, let me re-emphasise, this is not part of the CSV protocol, and does not belong in it. It probably belongs in a BCP around usage. If a Accredidation and Reputation services maintainer feels that there are no legitimate reasons for CBV failures, ever, then Yes, the maintainer should ding elvey.com in the scenario you describe. I believe there is consensus among abuse desks that email abuse reports that don't include the header and body of the email are unlikely to be given much, if any weight. From owner-ietf-mxcomp@mail.imc.org Wed Dec 8 17:31:03 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17167 for ; Wed, 8 Dec 2004 17:31:03 -0500 (EST) 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 iB8M1eEU032894; Wed, 8 Dec 2004 14:01:40 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB8M1eLm032893; Wed, 8 Dec 2004 14:01:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB8M1d4r032865 for ; Wed, 8 Dec 2004 14:01:39 -0800 (PST) (envelope-from dotis@mail-abuse.org) Received: from [168.61.10.136] (SJC-Office-DHCP-136.Mail-Abuse.ORG [168.61.10.136]) (authenticated bits=0) by a.mail.sonic.net (8.12.11/8.12.11) with ESMTP id iB8M1hdb019062 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 8 Dec 2004 14:01:44 -0800 Subject: Bounce handling From: Douglas Otis To: David Woodhouse Cc: MARID In-Reply-To: <1102533627.13753.41.camel@hades.cambridge.redhat.com> References: <20041208184751.24759.qmail@xuxa.iecc.com> <1102533627.13753.41.camel@hades.cambridge.redhat.com> Content-Type: text/plain Message-Id: <1102543111.2881.30.camel@littlejoy> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 08 Dec 2004 13:58:32 -0800 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, 2004-12-08 at 11:20, David Woodhouse wrote: > On Wed, 2004-12-08 at 18:47 +0000, John Levine wrote: > > I do agree that bounces vs. rejects are an increasing problem, and > > I'm having trouble figuring out if there's any way I can do bounces > > reasonably for the fraction of the mail here for which I can't tell > > if it's deliverable at SMTP time. > > The only real answer I've found is to make sure that during _normal_ > operation, there isn't actually any mail in that category ("can't tell > if it's deliverable at SMTP time"). > > I do recipient verification callouts (with caching, of course) for the > domains for which I am MX backup (and in some cases, also for mail I'm > forwarding). Obviously it's pointless being an MX backup unless you > actually accept the mail while the primary is down; but that's not > normal operation. The spammer often ignores MX priorities specifically to discover SMTP servers that accept mail for a particular domain without respect to valid users. There is still an advantage using BATV even in the case where there is a bounce generated in this scenario. The receiving MTA, if using BATV, should be able to reject a bounce when the MAILFROM is NULL. This is the reason for BATV. It seems the proper etiquette for a bounce would be to ensure a NULL MAILFROM when issuing a bounce. This behavior should include virus detection, vacation notices, and other message related events generated as a result of a message being rejected and returned. Unfortunately, the setting of MAILFROM for a bounce is optional. : ( -Doug From owner-ietf-mxcomp@mail.imc.org Wed Dec 8 18:02:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21047 for ; Wed, 8 Dec 2004 18:02:58 -0500 (EST) 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 iB8MSNv3064801; Wed, 8 Dec 2004 14:28:23 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB8MSNIq064789; Wed, 8 Dec 2004 14:28:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from canuck.infradead.org (canuck.infradead.org [205.233.218.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB8MS9Xk064551 for ; Wed, 8 Dec 2004 14:28:22 -0800 (PST) (envelope-from SRS0+0105bb8cd289da57b0d9+472+infradead.org+dwmw2@canuck.srs.infradead.org) Received: from shinybook.infradead.org ([81.187.226.99]) by canuck.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1CcAI6-0002L3-6X; Wed, 08 Dec 2004 17:28:11 -0500 Subject: Re: Bounce handling From: David Woodhouse To: Douglas Otis Cc: MARID In-Reply-To: <1102543111.2881.30.camel@littlejoy> References: <20041208184751.24759.qmail@xuxa.iecc.com> <1102533627.13753.41.camel@hades.cambridge.redhat.com> <1102543111.2881.30.camel@littlejoy> Content-Type: text/plain Date: Wed, 08 Dec 2004 22:27:22 +0000 Message-Id: <1102544842.22606.13.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3.dwmw2.1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-SRS-Rewrite: SMTP reverse-path rewritten from by canuck.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-12-08 at 13:58 -0800, Douglas Otis wrote: > The spammer often ignores MX priorities specifically to discover SMTP > servers that accept mail for a particular domain without respect to > valid users. There is still an advantage using BATV even in the case > where there is a bounce generated in this scenario. The receiving MTA, > if using BATV, should be able to reject a bounce when the MAILFROM is > NULL. This is the reason for BATV. Yes. That's precisely why I'm _slightly_ less concerned about avoiding bounces nowadays, since SES and BATV allow the 'victim' of bogus bounces to reject them. SES just takes it a little further than BATV, by offering simple ways for the (potential) recipient to verify the source address too. > It seems the proper etiquette for a bounce would be to ensure a NULL > MAILFROM when issuing a bounce. This behavior should include virus > detection, vacation notices, and other message related events > generated as a result of a message being rejected and returned. > Unfortunately, the setting of MAILFROM for a bounce is optional. :( For a bounce as defined by RFC2821 it's _not_ optional to use an empty reverse-path; it's mandatory. For vacation messages it is optional -- in fact I was utterly dismayed to see that RFC3834 said that an autoresponse 'MAY' have an empty reverse-path, rather than 'MUST' or at least 'SHOULD'. I consider autoreplies (and especially bounces) with non-empty reverse- path to be an attempted denial of service attack, because of the mail loop they threaten. I tend to report them to the upstream network provider of the offender as such, in the strongest possible language. Especially if they're "responses" to viruses which are known to fake their sender. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Wed Dec 8 18:19:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23316 for ; Wed, 8 Dec 2004 18:19:50 -0500 (EST) 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 iB8MibR8083116; Wed, 8 Dec 2004 14:44:37 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB8MibSR083115; Wed, 8 Dec 2004 14:44:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from slot.hollandcasino.net (slot.hollandcasino.net [193.172.40.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB8MiatB083002 for ; Wed, 8 Dec 2004 14:44:36 -0800 (PST) (envelope-from alex@slot.hollandcasino.net) Received: by slot.hollandcasino.net (Postfix, from userid 500) id 97362600B9; Wed, 8 Dec 2004 23:44:32 +0100 (CET) Date: Wed, 8 Dec 2004 23:44:32 +0100 From: Alex van den Bogaerdt To: ietf-mxcomp@imc.org Subject: Re: blowback, was A new SMTP "3821" [Re: FTC stuff...........] Message-ID: <20041208224432.GA12927@slot.hollandcasino.net> Mail-Followup-To: ietf-mxcomp@imc.org References: <04a601c4dd06$de9c3d20$0200000a@ringo> <20041208184751.24759.qmail@xuxa.iecc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041208184751.24759.qmail@xuxa.iecc.com> User-Agent: Mutt/1.4.1i X-Legal-Note: ---------------------------------------------- Everything I write or say expresses my opinion only! Unless otherwise stated, I do not represent my employer or anyone else for that matter. ---------------------------------------------------- Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Dec 08, 2004 at 06:47:51PM -0000, John Levine wrote: > If the policy is only "-all", i.e., this domain sends no mail at all, > then the policy is credible. If the policy is anything else followed > by -all, it's not. One of SPF's many problems is that it posits a > model of the e-mail world that is a lot simpler than the real world. > > In the real world, there are whole lot of remailers and forwarders, > and no matter how desperately some domains might want to argue that > nobody's allowed to forward, etc., [snip] This is bogus. Forwarding does not have to stop. SPF by itself does not make a distinction between forgeries as a result of "old-style forwarding" and spam, virus, etc. People claming that the SPF community wants to ban forwarding are spreading fud, no matter their reputation. Alex From owner-ietf-mxcomp@mail.imc.org Wed Dec 8 20:15:41 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02589 for ; Wed, 8 Dec 2004 20:15:40 -0500 (EST) 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 iB90hIBo021215; Wed, 8 Dec 2004 16:43:18 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB90hIUI021214; Wed, 8 Dec 2004 16:43:18 -0800 (PST) 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 iB90hHBW021173 for ; Wed, 8 Dec 2004 16:43:17 -0800 (PST) (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 iB90garA009557 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 8 Dec 2004 19:42:38 -0500 Date: Wed, 8 Dec 2004 19:42:36 -0500 (EST) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: Chris Haynes cc: MXCOMP Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] In-Reply-To: <04a601c4dd06$de9c3d20$0200000a@ringo> 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 Dec 2004, Chris Haynes wrote: > > On December 08, 2004 5:18 AM +00 "Dean Anderson" sent: > > > Err, no. SPF does make the blowback problem much worse. Other schemes > > create a few percent blowback. SPF enables 100% blowback. Thats much > > worse. > > I hesitate to (re-)enter this thread, and, once again, I'm trying to be fair and > understand the substantive basis for concerns.. > > It has been argued in SPF circles, that if you receive a message which the > (purported) sender's policy declares to be a hard failure (-), the message is > _proven_ to be a forgery, an unauthorised re-transmission, or whatever. > > Since the purported sender has repudiated the message, the argument goes, the > original SMTP 'contract' to "deliver or bounce" is null-and-void, The mailserver getting the rejection code and generating the bounce may not participate in the SPF "contract modification". One would also have to create a special 5xx code to indicate "reject, but don't bounce", and then upgrade all mailservers everywhere. And I suspect some people might not accept silent rejection in principle, and send bounces anyway. It is probably easier for the recipient mailer to receive but not deliver (silent discard) But silent discards are also particularly difficult to debug. And you wouldn't want to do this unless everyone on the planet had SPF records. > since whoever actually injected the message did so without the authority > of the domain they cited. Therefore it is acceptable to 'silently > discard' such messages, and not send bounces. It isn't necessarilly the case that SPF-rejected email is forged or unauthorized. It might just be the hosting company isn't allowing outsourcing of the domain. (or is doing "unreliable" name service to harm the other company and gain back the outsourced business). It would not be acceptable to silently discard these messages, since one would never know why the message wasn't received. Silent rejection seems to be a bad approach. And of course, SPF rejections might happen simply because the IP addresses of the authorized servers changed, but the TTLs on the SPF records haven't expired. This would be new blowback on otherwise good email. This could go for weeks or months after an IP address is changed. IP Addresses are frequently changed unexpectedly as a result of abusive blacklists that can't be taken to court. Since you can't sue anonymous blacklists like SPEWS, when they block legitimate business, the only alternative is to get a new IP address. This, of course, is unplanned. No doubt the abusive blacklist would appreciate the ability to create additional interference. That should probably be #14 on the list. > Do you have any sympathy with that reasoning, and would it change your view > about 100% blowback? Ignoring the just-described problems with silent rejection, silent rejection could reduce blowback, but it still requires replacement of all current mailserver software. That would take many years to achieve. In the meantime, there is 100% blowback. I note that recent documents from Comcast show that it would cost $58 million just to tell their users to change relays, at $9 per support call. Upgrading all the mailserver software on the planet must be fairly expensive. And it might never be really finished. And whatever system you put into place will still be abused, perhaps differently, but still abused just the same. --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 Dec 8 20:46:57 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05577 for ; Wed, 8 Dec 2004 20:46:56 -0500 (EST) 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 iB91EEX2066401; Wed, 8 Dec 2004 17:14:14 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB91EEOh066398; Wed, 8 Dec 2004 17:14:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from canuck.infradead.org (canuck.infradead.org [205.233.218.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB91E58Y066089 for ; Wed, 8 Dec 2004 17:14:12 -0800 (PST) (envelope-from SRS0+ef7f10539f1579274c16+473+infradead.org+dwmw2@canuck.srs.infradead.org) Received: from shinybook.infradead.org ([81.187.226.99]) by canuck.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1CcCsa-00035r-Qk; Wed, 08 Dec 2004 20:14:02 -0500 Subject: Re: Bounce handling From: David Woodhouse To: kent crispin Cc: Douglas Otis , MARID In-Reply-To: <20041209004838.GC2568@raven.songbird.com> References: <20041208184751.24759.qmail@xuxa.iecc.com> <1102533627.13753.41.camel@hades.cambridge.redhat.com> <1102543111.2881.30.camel@littlejoy> <1102544842.22606.13.camel@localhost.localdomain> <20041209004838.GC2568@raven.songbird.com> Content-Type: text/plain Date: Thu, 09 Dec 2004 01:13:12 +0000 Message-Id: <1102554792.22606.56.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3.dwmw2.1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-SRS-Rewrite: SMTP reverse-path rewritten from by canuck.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-12-08 at 16:48 -0800, kent crispin wrote: > On Wed, Dec 08, 2004 at 10:27:22PM +0000, David Woodhouse wrote: > > I consider autoreplies (and especially bounces) with non-empty reverse- > > path to be an attempted denial of service attack, because of the mail > > loop they threaten. > > How about an autoreply from majordomo, asking you to confirm your > subscription request? I'd probably include that, yes -- if responding to a request made by email, it should go to the reverse-path of the incoming subscription request, and should have an empty reverse-path if its own. This would would prevent the autoreplies from being accepted (and broadcasted) by other mailing lists. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Wed Dec 8 20:49:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05808 for ; Wed, 8 Dec 2004 20:48:59 -0500 (EST) 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 iB91JNvE074170; Wed, 8 Dec 2004 17:19:23 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB91JNcd074169; Wed, 8 Dec 2004 17:19:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from canuck.infradead.org (canuck.infradead.org [205.233.218.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB91JMkq074108 for ; Wed, 8 Dec 2004 17:19:23 -0800 (PST) (envelope-from SRS0+ef7f10539f1579274c16+473+infradead.org+dwmw2@canuck.srs.infradead.org) Received: from shinybook.infradead.org ([81.187.226.99]) by canuck.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1CcCxq-00036J-Hf; Wed, 08 Dec 2004 20:19:27 -0500 Subject: Re: blowback, was A new SMTP "3821" [Re: FTC stuff...........] From: David Woodhouse To: Alex van den Bogaerdt Cc: ietf-mxcomp@imc.org In-Reply-To: <20041208224432.GA12927@slot.hollandcasino.net> References: <04a601c4dd06$de9c3d20$0200000a@ringo> <20041208184751.24759.qmail@xuxa.iecc.com> <20041208224432.GA12927@slot.hollandcasino.net> Content-Type: text/plain Date: Thu, 09 Dec 2004 01:18:38 +0000 Message-Id: <1102555118.22606.61.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3.dwmw2.1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-SRS-Rewrite: SMTP reverse-path rewritten from by canuck.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-12-08 at 23:44 +0100, Alex van den Bogaerdt wrote: > SPF by itself does not make a distinction between forgeries as a result > of "old-style forwarding" and spam, virus, etc. Your references to 'old-style' forwarding and 'forgery' will be a lot more credible when RFC4822 comes out and indicates that forwarding sites SHOULD NOT behave in the way they've always done by preserving the reverse-path. I consider that a prerequisite for any standardisation of SPF; to do it in the other order is putting the cart before the horse. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Wed Dec 8 21:05:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08931 for ; Wed, 8 Dec 2004 21:05:16 -0500 (EST) 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 iB91bVF3099525; Wed, 8 Dec 2004 17:37:31 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB91bVSK099520; Wed, 8 Dec 2004 17:37:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from xuxa.iecc.com (xuxa.iecc.com [208.31.42.42]) by above.proper.com (8.12.11/8.12.9) with SMTP id iB91bP4S099394 for ; Wed, 8 Dec 2004 17:37:25 -0800 (PST) (envelope-from prvs=johnl/076134140c@iecc.com) Received: (qmail 1385 invoked by uid 100); 9 Dec 2004 01:37:29 -0000 Date: 9 Dec 2004 01:37:29 -0000 Message-ID: <20041209013729.1384.qmail@xuxa.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: Re: blowback, was A new SMTP "3821" [Re: FTC stuff...........] In-Reply-To: <20041208224432.GA12927@slot.hollandcasino.net> Organization: I.E.C.C., Trumansburg NY USA Cc: alex@slot.hollandcasino.net Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >> In the real world, there are whole lot of remailers and forwarders, >> and no matter how desperately some domains might want to argue that >> nobody's allowed to forward, etc., [snip] > >This is bogus. Forwarding does not have to stop. Hmmn. I'm not sure how to respond to someone who seems to think that I wrote the exact opposite of what I did. I said that forwarding happens, and that SPF records saying "no forwarding" aren't going to stop it. Recipients can believe -all at the time when every forwarder has implemented SRS, that is to say, never. Until then, if you actually want to accept the legitimate mail that people are sending you, SPF is only useful for whitelisting domains you already know you like. >People claming that the SPF community wants to ban forwarding are >spreading fud, no matter their reputation. Tendentious non-sequiturs don't advance your argument very effectively. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY http://www.taugh.com From owner-ietf-mxcomp@mail.imc.org Thu Dec 9 05:25:44 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09106 for ; Thu, 9 Dec 2004 05:25:43 -0500 (EST) 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 iB99eMlc065588; Thu, 9 Dec 2004 01:40:22 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB99eMTr065587; Thu, 9 Dec 2004 01:40:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from slot.hollandcasino.net (slot.hollandcasino.net [193.172.40.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB99eL5u065494 for ; Thu, 9 Dec 2004 01:40:21 -0800 (PST) (envelope-from alex@slot.hollandcasino.net) Received: by slot.hollandcasino.net (Postfix, from userid 500) id 4F7F1600B9; Thu, 9 Dec 2004 10:40:17 +0100 (CET) Date: Thu, 9 Dec 2004 10:40:17 +0100 From: Alex van den Bogaerdt To: ietf-mxcomp@imc.org Subject: Re: blowback, was A new SMTP "3821" [Re: FTC stuff...........] Message-ID: <20041209094016.GA15915@slot.hollandcasino.net> Mail-Followup-To: ietf-mxcomp@imc.org References: <20041208224432.GA12927@slot.hollandcasino.net> <20041209013729.1384.qmail@xuxa.iecc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041209013729.1384.qmail@xuxa.iecc.com> User-Agent: Mutt/1.4.1i X-Legal-Note: ---------------------------------------------- Everything I write or say expresses my opinion only! Unless otherwise stated, I do not represent my employer or anyone else for that matter. ---------------------------------------------------- Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Dec 09, 2004 at 01:37:29AM -0000, John Levine wrote: > >> In the real world, there are whole lot of remailers and forwarders, > >> and no matter how desperately some domains might want to argue that > >> nobody's allowed to forward, etc., [snip] > > > >This is bogus. Forwarding does not have to stop. > > Hmmn. I'm not sure how to respond to someone who seems to think that > I wrote the exact opposite of what I did. I think you wrote: "Some domains argue that nobody is allowed to forward". I respond that this is not the case, in other words I don't think it's true that SPF wants to stop forwarding. > I said that forwarding happens, and that SPF records saying "no > forwarding" aren't going to stop it. Recipients can believe -all at Here you say it again. SPF does NOT say "no forwarding". SPF _does_ say: "No spoofing my name". If you want to forward then that's fine. Just don't use my name as the _sender_ of _your_ message. > >People claming that the SPF community wants to ban forwarding are > >spreading fud, no matter their reputation. > > Tendentious non-sequiturs don't advance your argument very effectively. I needed to look this ("non-sequiturs") up and I don't see why you want to choose this word. Alex From owner-ietf-mxcomp@mail.imc.org Thu Dec 9 06:30:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14026 for ; Thu, 9 Dec 2004 06:30:13 -0500 (EST) 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 iB9AqdFq046423; Thu, 9 Dec 2004 02:52:39 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB9Aqd62046421; Thu, 9 Dec 2004 02:52:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB9AqYOs046214 for ; Thu, 9 Dec 2004 02:52:34 -0800 (PST) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CcLuU-00042j-00 for ; Thu, 09 Dec 2004 11:52:34 +0100 Received: from c-134-88-49.hh.dial.de.ignite.net ([62.134.88.49]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 09 Dec 2004 11:52:34 +0100 Received: from nobody by c-134-88-49.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 09 Dec 2004 11:52:34 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: blowback Date: Thu, 09 Dec 2004 11:48:07 +0100 Organization: Lines: 51 Message-ID: <41B82D67.73F1@xyzzy.claranet.de> References: <04a601c4dd06$de9c3d20$0200000a@ringo> <20041208184751.24759.qmail@xuxa.iecc.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-134-88-49.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 John Levine wrote: > One of SPF's many problems is that it posits a model of the > e-mail world that is a lot simpler than the real world. KISS is a feature and no problem. > In the real world, there are whole lot of remailers and > forwarders, Remailers (like real mailing lists) have no problem at all with SPF. Some arguments "against" SPF from say the EFF are far beyond surreal. Any anonymous remailer is by its own definition automatically "SPF ready". > no matter how desperately some domains might want to argue > that nobody's allowed to forward, etc. These arguments are nonsense, you can forward as much as you like. You only have a problem if you check SPF behind your "border MTA", but the good news is, this is _your_ problem. > People want their bank statements or whatever, even if the > address they give to the bank is their permanent forwarding > address from their alma mater. Something on their side has to give. It's not a problem of the senders, they only publish which MTAs send their mail to third parties, that's their border. > bounces vs. rejects are an increasing problem, and I'm having > trouble figuring out if there's any way I can do bounces > reasonably You could try SPF, if the HELO resp. MAIL FROM sender policy results in a FAIL simply reject the mail. You're only forced to bounce if you forward mail and the next hop rejects it. Otherwise it should be possible to come to a decision about "reject" vs. "accept" during the SMTP dialogue. In theory. BTW, something I've seen in MASS, you said that "most" mail today contains HTML. Is that incl. or excl. UBE / UCE ? If 4 of 5 mails are spam and other unsolicited stuff today, and 4 of 5 spam mails contain HTML, then 64% of all mail are both unsolicited and contain HTML. But it's not clear how often HTML is used in solicited mail, I doubt that the majority contains HTML. Bye, Frank From owner-ietf-mxcomp@mail.imc.org Thu Dec 9 07:37:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17521 for ; Thu, 9 Dec 2004 07:37:14 -0500 (EST) 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 iB9C6a1I002677; Thu, 9 Dec 2004 04:06:36 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB9C6aW0002676; Thu, 9 Dec 2004 04:06:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from canuck.infradead.org (canuck.infradead.org [205.233.218.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB9C6L9g002323 for ; Thu, 9 Dec 2004 04:06:30 -0800 (PST) (envelope-from SRS0+ef7f10539f1579274c16+473+infradead.org+dwmw2@canuck.srs.infradead.org) Received: from [213.86.99.236] (helo=hades.cambridge.redhat.com) by canuck.infradead.org with esmtpsa (Exim 4.42 #1 (Red Hat Linux)) id 1CcN3o-0007Jr-L6; Thu, 09 Dec 2004 07:06:19 -0500 Subject: Re: blowback, was A new SMTP "3821" [Re: FTC stuff...........] From: David Woodhouse To: Alex van den Bogaerdt Cc: ietf-mxcomp@imc.org In-Reply-To: <20041209094016.GA15915@slot.hollandcasino.net> References: <20041208224432.GA12927@slot.hollandcasino.net> <20041209013729.1384.qmail@xuxa.iecc.com> <20041209094016.GA15915@slot.hollandcasino.net> Content-Type: text/plain Date: Thu, 09 Dec 2004 12:06:13 +0000 Message-Id: <1102593973.6694.2.camel@hades.cambridge.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3.dwmw2.1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-SRS-Rewrite: SMTP reverse-path rewritten from by canuck.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2004-12-09 at 10:40 +0100, Alex van den Bogaerdt wrote: > Here you say it again. SPF does NOT say "no forwarding". > SPF _does_ say: "No spoofing my name". You're arguing over nomenclature, which is pointless. Alex, you're right then SPF advocates do indeed phrase it as "No spoofing my name". But John is also right because what they _mean_ by that is "no forwarding", since normal forwarding does involve, and always has involved, the behaviour which SPF advocates now want to call "spoofing". The SPF advocates are suggesting that people do something else instead of normal forwarding, but they haven't really got a coherent and deployable answer yet as to _what_ else should be done. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Thu Dec 9 08:39:27 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21435 for ; Thu, 9 Dec 2004 08:39:27 -0500 (EST) 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 iB9D5fAk000672; Thu, 9 Dec 2004 05:05:42 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB9D5fnZ000671; Thu, 9 Dec 2004 05:05:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from slot.hollandcasino.net (slot.hollandcasino.net [193.172.40.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB9D5fnO000655 for ; Thu, 9 Dec 2004 05:05:41 -0800 (PST) (envelope-from alex@slot.hollandcasino.net) Received: by slot.hollandcasino.net (Postfix, from userid 500) id 82915600B9; Thu, 9 Dec 2004 14:05:42 +0100 (CET) Date: Thu, 9 Dec 2004 14:05:42 +0100 From: Alex van den Bogaerdt To: ietf-mxcomp@imc.org Subject: Re: blowback, was A new SMTP "3821" [Re: FTC stuff...........] Message-ID: <20041209130542.GA16698@slot.hollandcasino.net> Mail-Followup-To: ietf-mxcomp@imc.org References: <20041208224432.GA12927@slot.hollandcasino.net> <20041209013729.1384.qmail@xuxa.iecc.com> <20041209094016.GA15915@slot.hollandcasino.net> <1102593973.6694.2.camel@hades.cambridge.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1102593973.6694.2.camel@hades.cambridge.redhat.com> User-Agent: Mutt/1.4.1i X-Legal-Note: ---------------------------------------------- Everything I write or say expresses my opinion only! Unless otherwise stated, I do not represent my employer or anyone else for that matter. ---------------------------------------------------- Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Dec 09, 2004 at 12:06:13PM +0000, David Woodhouse wrote: > > On Thu, 2004-12-09 at 10:40 +0100, Alex van den Bogaerdt wrote: > > Here you say it again. SPF does NOT say "no forwarding". > > SPF _does_ say: "No spoofing my name". > > You're arguing over nomenclature, which is pointless. That is your opinion. For me, the difference is quite relevant. > Alex, you're right then SPF advocates do indeed phrase it as "No > spoofing my name". But John is also right because what they _mean_ by > that is "no forwarding", since normal forwarding does involve, and > always has involved, the behaviour which SPF advocates now want to call > "spoofing". If you know what "SPF advocates" mean to say, why do most (if not all) disagree with your opinion? Could it be that you are spreading your opinion, disguised as theirs? I think that the SPF community is well aware of the fact that there is a number of people using a way of forwarding that will become impossible in the future (if and when SPF is deployed). I don't think all of them consider this way of forwarding "normal". Perhaps most of them agree on this method being "in use", but that doesn't mean it is THE right way. There are alternatives. You just don't want to accept them because YOU think they are unnecessary alternatives. Newsflash: Others have opinions to and they may not agree with yours. Alex From owner-ietf-mxcomp@mail.imc.org Thu Dec 9 14:40:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25583 for ; Thu, 9 Dec 2004 14:40:46 -0500 (EST) 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 iB9J3uje021884; Thu, 9 Dec 2004 11:03:56 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB9J3upF021883; Thu, 9 Dec 2004 11:03:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB9J3tfd021853 for ; Thu, 9 Dec 2004 11:03:56 -0800 (PST) (envelope-from dotis@mail-abuse.org) Received: from [168.61.10.136] (SJC-Office-DHCP-136.Mail-Abuse.ORG [168.61.10.136]) (authenticated bits=0) by a.mail.sonic.net (8.12.11/8.12.11) with ESMTP id iB9J3xs5012075 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 9 Dec 2004 11:03:59 -0800 Subject: Do not spoof me From: Douglas Otis To: Alex van den Bogaerdt Cc: MARID In-Reply-To: <20041209130542.GA16698@slot.hollandcasino.net> References: <20041208224432.GA12927@slot.hollandcasino.net> <20041209013729.1384.qmail@xuxa.iecc.com> <20041209094016.GA15915@slot.hollandcasino.net> <1102593973.6694.2.camel@hades.cambridge.redhat.com> <20041209130542.GA16698@slot.hollandcasino.net> Content-Type: text/plain Message-Id: <1102618847.2880.82.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 09 Dec 2004 11:00:47 -0800 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, 2004-12-09 at 05:05, Alex van den Bogaerdt wrote: > On Thu, Dec 09, 2004 at 12:06:13PM +0000, David Woodhouse wrote: > > > > On Thu, 2004-12-09 at 10:40 +0100, Alex van den Bogaerdt wrote: > > > Here you say it again. SPF does NOT say "no forwarding". > > > SPF _does_ say: "No spoofing my name". > > > > You're arguing over nomenclature, which is pointless. > > That is your opinion. For me, the difference is quite relevant. > > > Alex, you're right then SPF advocates do indeed phrase it as "No > > spoofing my name". But John is also right because what they _mean_ by > > that is "no forwarding", since normal forwarding does involve, and > > always has involved, the behaviour which SPF advocates now want to call > > "spoofing". > > If you know what "SPF advocates" mean to say, why do most (if not > all) disagree with your opinion? > > Could it be that you are spreading your opinion, disguised as theirs? > > > I think that the SPF community is well aware of the fact that there > is a number of people using a way of forwarding that will become > impossible in the future (if and when SPF is deployed). I don't > think all of them consider this way of forwarding "normal". Perhaps > most of them agree on this method being "in use", but that doesn't > mean it is THE right way. > > There are alternatives. You just don't want to accept them because > YOU think they are unnecessary alternatives. Newsflash: Others > have opinions to and they may not agree with yours. There are two flaws with respect to this "do not spoof me" assertion. One, there are ways to prevent the SPF record from being discovered from sub-domains negating supposed spoof protections. Two, there is no way to know if the recipient of a message from such an SPF-domain will be forwarding the message. These forwarded accounts are utilized by a high enough percentage of the populous as to cause inordinate support issues should this mail become categorically rejected and perhaps lost. One of the alternatives offered by SPF for this problem is the use of the '?all' statement. In other words, SPF becomes a scheme of graduated levels of authorization and, of course, with the continuation of spoofing. This also means any shared MTA authorized by the SPF record also allows the SPF-domain to now be spoofed where the message obtains the highest level of authorization. Deployable "do not spoof me" solutions that also have a chance of actually working are being developed within the MASS wg. http://mipassoc.org/mass/ -Doug From owner-ietf-mxcomp@mail.imc.org Thu Dec 9 17:49:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24193 for ; Thu, 9 Dec 2004 17:49:18 -0500 (EST) 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 iB9MCRrp016341; Thu, 9 Dec 2004 14:12:27 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB9MCRjI016337; Thu, 9 Dec 2004 14:12:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB9MCOJR016266 for ; Thu, 9 Dec 2004 14:12:25 -0800 (PST) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CcWWS-0001FN-00 for ; Thu, 09 Dec 2004 23:12:28 +0100 Received: from 62.80.58.25 ([62.80.58.25]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 09 Dec 2004 23:12:28 +0100 Received: from nobody by 62.80.58.25 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 09 Dec 2004 23:12:28 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: Do not spoof me Date: Thu, 09 Dec 2004 23:10:47 +0100 Organization: Lines: 24 Message-ID: <41B8CD67.49F3@xyzzy.claranet.de> References: <20041208224432.GA12927@slot.hollandcasino.net> <20041209013729.1384.qmail@xuxa.iecc.com> <20041209094016.GA15915@slot.hollandcasino.net> <1102593973.6694.2.camel@hades.cambridge.redhat.com> <20041209130542.GA16698@slot.hollandcasino.net> <1102618847.2880.82.camel@localhost.localdomain> 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.25 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: > there are ways to prevent the SPF record from being > discovered from sub-domains negating supposed spoof > protections. What are you talking about ? If your domain is an.example, and your users use MAIL FROM: via your MSA, which says HELO msa.an.example, and if you have SPF sender policies "v=spf1 a:msa.an.example -all" for an.example and "v=spf1 a -all" for msa.an.example, where's the problem ? > there is no way to know if the recipient of a message from > such an SPF-domain will be forwarding the message. Yes, the "S" in SPF stands for "sender policy". As soon as the receiver does interesting things they are his business. If the receiver checks SPF at the wrong place resulting in a FAIL and reject, then he should fix his routing, or find any other solution for his problems, the sender didn't cause it. Bye, Frank From owner-ietf-mxcomp@mail.imc.org Thu Dec 9 19:32:27 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02938 for ; Thu, 9 Dec 2004 19:32:27 -0500 (EST) 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 iB9Nwl0M045402; Thu, 9 Dec 2004 15:58:47 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB9Nwlm5045401; Thu, 9 Dec 2004 15:58:47 -0800 (PST) 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 iB9NwkIv045391 for ; Thu, 9 Dec 2004 15:58:46 -0800 (PST) (envelope-from dotis@mail-abuse.org) Received: from [168.61.10.136] (SJC-Office-DHCP-136.Mail-Abuse.ORG [168.61.10.136]) (authenticated bits=0) by b.mail.sonic.net (8.12.11/8.12.11) with ESMTP id iB9NwpjO008063 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 9 Dec 2004 15:58:52 -0800 Subject: Re: Do not spoof me From: Douglas Otis To: Frank Ellermann Cc: MARID In-Reply-To: <41B8CD67.49F3@xyzzy.claranet.de> References: <20041208224432.GA12927@slot.hollandcasino.net> <20041209013729.1384.qmail@xuxa.iecc.com> <20041209094016.GA15915@slot.hollandcasino.net> <1102593973.6694.2.camel@hades.cambridge.redhat.com> <20041209130542.GA16698@slot.hollandcasino.net> <1102618847.2880.82.camel@localhost.localdomain> <41B8CD67.49F3@xyzzy.claranet.de> Content-Type: text/plain Message-Id: <1102636539.3727.56.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 09 Dec 2004 15:55:39 -0800 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, 2004-12-09 at 14:10, Frank Ellermann wrote: > Douglas Otis wrote: > > > there are ways to prevent the SPF record from being > > discovered from sub-domains negating supposed spoof > > protections. > > What are you talking about ? If your domain is an.example, > and your users use MAIL FROM: via your MSA, > which says HELO msa.an.example, and if you have SPF sender > policies "v=spf1 a:msa.an.example -all" for an.example and > "v=spf1 a -all" for msa.an.example, where's the problem ? Those wishing to spoof a domain could add a label that already has a record such as- MAILFROM:. The query for the SPF TXT RR at name_of_inbound_smtp_server.an.example will fail. They may even HELO some_existing_record.an.example. The fact that IP addresses do not match will not be a problem. No SPF TXT records will have been found however. > > there is no way to know if the recipient of a message from > > such an SPF-domain will be forwarding the message. > > Yes, the "S" in SPF stands for "sender policy". As soon as > the receiver does interesting things they are his business. > > If the receiver checks SPF at the wrong place resulting in a > FAIL and reject, then he should fix his routing, or find any > other solution for his problems, the sender didn't cause it. The "all authorized senders are listed" policy causes the problem! There is no way to know in advance which recipient forwards mail so, in essence, this is a false claim that damages the integrity of the mail. Unless this damage is intentional with the belief mail forwarding, as it exists today, should not be used, no SPF record should claim "-all". There is no right place for these records. -Doug From owner-ietf-mxcomp@mail.imc.org Fri Dec 10 05:13:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29737 for ; Fri, 10 Dec 2004 05:13:24 -0500 (EST) 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 iBA9X2U9005071; Fri, 10 Dec 2004 01:33:02 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBA9X2s5005070; Fri, 10 Dec 2004 01:33:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from baythorne.infradead.org (IDENT:U2FsdGVkX1+YxvF08rQfL7LiFD35G/Y6la4METVZQ/A@baythorne.infradead.org [81.187.226.107]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBA9WiIo004608 for ; Fri, 10 Dec 2004 01:32:55 -0800 (PST) (envelope-from SRS0+92f843d10f4532a99c7e+474+infradead.org+dwmw2@baythorne.srs.infradead.org) Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by baythorne.infradead.org with esmtpsa (Exim 4.43 #1 (Red Hat Linux)) id 1Cch5K-00033z-3o; Fri, 10 Dec 2004 09:29:10 +0000 Subject: Re: Do not spoof me From: David Woodhouse To: Douglas Otis Cc: Frank Ellermann , MARID In-Reply-To: <1102636539.3727.56.camel@localhost.localdomain> References: <20041208224432.GA12927@slot.hollandcasino.net> <20041209013729.1384.qmail@xuxa.iecc.com> <20041209094016.GA15915@slot.hollandcasino.net> <1102593973.6694.2.camel@hades.cambridge.redhat.com> <20041209130542.GA16698@slot.hollandcasino.net> <1102618847.2880.82.camel@localhost.localdomain> <41B8CD67.49F3@xyzzy.claranet.de> <1102636539.3727.56.camel@localhost.localdomain> Content-Type: text/plain Date: Fri, 10 Dec 2004 09:29:09 +0000 Message-Id: <1102670949.11421.31.camel@baythorne.infradead.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3.dwmw2.1) Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by baythorne.infradead.org See http://www.infradead.org/rpr.html Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2004-12-09 at 15:55 -0800, Douglas Otis wrote: > Those wishing to spoof a domain could add a label that already has a > record such as- > > MAILFROM:. Or even MAIL FROM: SPF is by its very nature a hop-by-hop mechanism; it cannot give a true end-to-end indication of forgery. The problem is that we need to know with high accuracy which mails are _spoofed_. SPF can only tell us for sure which mails are _not_ spoofed. We want a blacklist; we have a whitelist. To go from one to the other is not a simple negation. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Sun Dec 12 20:02:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20926 for ; Sun, 12 Dec 2004 20:02:19 -0500 (EST) 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 iBD00Yjn093526; Sun, 12 Dec 2004 16:00:34 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBD00YVG093525; Sun, 12 Dec 2004 16:00:34 -0800 (PST) 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 iBD00O8s093511 for ; Sun, 12 Dec 2004 16:00:24 -0800 (PST) (envelope-from dean@av8.com) Received: from antigua.nuspex.com (citation2.av8.net [130.105.19.2]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id iBD00IFD026100 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 12 Dec 2004 19:00:18 -0500 Date: Sun, 12 Dec 2004 19:00:17 -0500 (EST) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Alex van den Bogaerdt cc: ietf-mxcomp@imc.org Subject: Re: blowback, was A new SMTP "3821" [Re: FTC stuff...........] In-Reply-To: <20041208224432.GA12927@slot.hollandcasino.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 8 Dec 2004, Alex van den Bogaerdt wrote: > People claming that the SPF community wants to ban forwarding are > spreading fud, no matter their reputation. No one is saying the SPF community wants to _ban_ forwarding. At least, I've not heard anyone say that. Rather, they want to extort^H^H^Hract money for the ability to outsource or separate parts of the mail system. They can also mess with the service level of the other provider in ways that aren't easily detectable by the user. The blowback issue is different from this. Blowback happens whenever anyone _rejects_ emails based on SPF. A bounce is generated from the relay to the forged sender. This enables abusers to arrange 100% blowback as the abuse vector. So, SPF rejection can't be allowed. --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 Mon Dec 13 07:58:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01756 for ; Mon, 13 Dec 2004 07:58:02 -0500 (EST) 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 iBDCCWou013103; Mon, 13 Dec 2004 04:12:32 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBDCCWAm013102; Mon, 13 Dec 2004 04:12:32 -0800 (PST) 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 iBDCCOhN013030 for ; Mon, 13 Dec 2004 04:12:26 -0800 (PST) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id iBDCeUgk018525; Mon, 13 Dec 2004 04:40:30 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id iBDCeU8C018522; Mon, 13 Dec 2004 04:40:30 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Mon, 13 Dec 2004 04:40:30 -0800 (PST) From: "william(at)elan.net" To: spf-discuss@v2.listbox.com cc: MARID Subject: Approaches to system design - Marketing vs Security and why MASG should not be standards group (was: [spf-discuss] Re: MAAWG whitepaper draft) In-Reply-To: <1491523720.20041213141715@pobox.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 13 Dec 2004, Chris Drake wrote: > On a different note: It's amusing to see other people starting to cry > foul now that the lack of integrity and honesty of people involved in > "white paper writing" is getting more overt. I urge all of you to not > accept this blatant dishonesty: if something's broken in > SPF/DK/SID/etc, state so honestly and upfront and stop sweeping all > the nasties under the carpet. Since I never could keep my mouth shot when I see that there is a problem, I certainly was quite clear that both SPF and DK have serious issues and SID even more so then the rest. Meng's point of view however seems to be if we put it all down its one big melting pot, maybe it'll work out for the good (and in the mean time by appeasing everyone, it makes everyone happy) and that result would be easier to market no matter what one's needs are and lead to faster adaption. Security guy's point of view is that you have to get it done right at each layer so it could work on its own because melting pots have high chance of having not immediately seen security problems (not only problems for each layer become global ones but some problems are result of such melting of of multiple layers) that are later exploited and result is that entire system is likely to be vulnerable and not easily fixable. A practical example of the "melting pot" approach is the one Microsoft takes with its products, the result is that they can quickly create a product that can appease to large audience and that is easy to market, but later those who use it are faced with serious security issues in such a product that takes long time to get fixed (if at all possible without complete redesign) and you all can guess that widespread of viruses and zombies is the direct result of that. Now because of the above issues and because we're after all dealing directly with email security (and not with some general new protocol or system), the 2nd approach of making sure each layer is secure just on its own is the best one (even if it takes longer to produce results) and I do still believe we can do both session authentication and cryptography so it works on their own - obviously that means more technical work and not ignoring the issues and replacing it with politics and marketing tricks to make it appear that all is good. Also for those interested you might notice that melting pots is always the approach those in the marketing would take while per-layer security is approach taken by the technical people. IETF is up until now been controlled by technical community and so IAB and IESG were probably not super favorite of the MARID and also had been slow to decide if they want to work on MASS which potentially has the same problems. Its not surprising that seeing that SID and similar marketing-driven approaches are not being seen favorably by IETF, some are now starting to talk about creating new "Messaging Accountability Standards Group" (MASG) to push such designs through on their own ignoring technical and security flows of the melting pot system. I urge such people who favor new standards group as next step for SPF to reconsider your views and listen to the advise given in good faith by the experienced technical community and work on fixing current problems instead. And I believe strongest would be a combination of skills found in each group - that means SPF should continue to be focused on experimenting and initial design and then finishing touches and technical review for those designs before becoming standard should be done by IETF (which is strongest there as it has good understanding of many issues involved including not only email but dns and others). Then it goes back to SPF which has understanding that design is not only about creating standards but marketing this standards and supporting its initial deployment (this IETF always failed to do for its standards and leaves this part up to companies that worked on such a standard). As such my view is that MASG should stand for "Messaging Accountability Solutions Group" it should NOT be a standard creating body but a something that helps in the R&D and marketing for FOSS driven initiatives where there is no direct corporate support to do either. --- William Leibzon, Elan Networks: mailto: william@elan.net Anti-Spam and Email Security Research Worksite: http://www.elan.net/~william/emailsecurity/