From owner-ietf-mxcomp@mail.imc.org Mon Jan 3 15:34:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07376 for ; Mon, 3 Jan 2005 15:34: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 j03JWPAr056177; Mon, 3 Jan 2005 11:32: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 j03JWPTA056174; Mon, 3 Jan 2005 11:32:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.hbinc.com (mail.hbinc.com [63.149.249.2]) by above.proper.com (8.12.11/8.12.9) with SMTP id j03JWNTv055847 for ; Mon, 3 Jan 2005 11:32:24 -0800 (PST) (envelope-from Matthew.van.Eerde@hbinc.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: blowback, was A new SMTP "3821" [Re: FTC stuff...........] Date: Mon, 3 Jan 2005 11:32:23 -0800 Message-ID: <61192FA29C719B469A2B13E57DEDF75B0348A647@mail.hbinc.com> Thread-Topic: blowback, was A new SMTP "3821" [Re: FTC stuff...........] Thread-Index: AcTgrON1pB6egdOcQYWyudV26Dor0QRHbqGA From: To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j03JWOTv056107 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Dean Anderson wrote: > The blowback issue is different from this. Blowback happens whenever > anyone _rejects_ emails based on SPF. Fair enough > A bounce is generated from the relay to the forged sender. Is it? If the receiving MTA issues an SMTP reject command, it does not assume any responsibility for the delivery of the mail. It will therefore not generate a spurious bounce message. If the sending MTA generates a bounce message, then it's likely not a virus or other malware likely to forge a sender address. Matthew.van.Eerde (at) hbinc.com 805.964.4554 x902 Hispanic Business Inc./HireDiversity.com Software Engineer perl -e"map{y/a-z/l-za-k/;print}shift" "Jjhi pcdiwtg Ptga wprztg," From owner-ietf-mxcomp@mail.imc.org Wed Jan 5 11:56:46 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21078 for ; Wed, 5 Jan 2005 11:56:45 -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 j05GCdTm039171; Wed, 5 Jan 2005 08:12: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 j05GCdgY039170; Wed, 5 Jan 2005 08:12:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp.well.com (smtp.well.com [206.14.209.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j05GCcjd038851 for ; Wed, 5 Jan 2005 08:12:39 -0800 (PST) (envelope-from cpm@well.com) X-WELL-Auth: Yes Received: from [192.168.0.9] (orthanc.avwashington.com [199.227.4.34]) by smtp.well.com (8.13.0/8.13.0) with ESMTP id j05GCPUN016423; Wed, 5 Jan 2005 08:12:26 -0800 (PST) Message-ID: <41DC1215.60908@well.com> Date: Wed, 05 Jan 2005 11:13:09 -0500 From: Chip Mefford User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Levine CC: ietf-mxcomp@imc.org Subject: Re: Source routing -- why not? References: <20041130011259.11064.qmail@xuxa.iecc.com> In-Reply-To: <20041130011259.11064.qmail@xuxa.iecc.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/651/Tue Jan 4 23:41:37 2005 clamav-milter version 0.80j on smtp.well.com X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 John Levine wrote: | After further deliberation about source routing and SPF, I have come | around to the conclusion that Frank is to some degree right, and if | you want to use SPF/Sender-ID, you should use source routes. | Why not just go back to bang path? It works. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFB3BIVa44x14FCa6ARArX0AJ92QcPba6HYs8VecFM9QGGMJSJz4wCff+hL 43rAj7nGpWxTl5d6kcC6PIg= =IGRv -----END PGP SIGNATURE----- From owner-ietf-mxcomp@mail.imc.org Fri Jan 7 08:45:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13948 for ; Fri, 7 Jan 2005 08:45: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 j07Cte3e071188; Fri, 7 Jan 2005 04:55: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 j07CteDk071186; Fri, 7 Jan 2005 04:55:40 -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 j07CtcTC071139; Fri, 7 Jan 2005 04:55:39 -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 j07CvPTG023124; Fri, 7 Jan 2005 04:57:25 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id j07CvP98023121; Fri, 7 Jan 2005 04:57:25 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Fri, 7 Jan 2005 04:57:25 -0800 (PST) From: "william(at)elan.net" To: IETF MAILSIG WG cc: asrg@ietf.org, MARID Subject: Email Security Glossary 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: I recently created email security glossary out of the smaller one that was included in mta-signatures paper (its now > 5 times larger with almost 300 terms and abbreviations!), it includes primarily email and cryptography abbreviations but number of related terms are also there (all the ones that we've come to know in the last year dealing with MARID, MASS, etc). This glossary will be shared among several of my projects and websites, but currently its first official location is: http://www.metasignatures.org/glossary.htm -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Sun Jan 9 20:30:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22464 for ; Sun, 9 Jan 2005 20:30: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 j0A0cqZt045264; Sun, 9 Jan 2005 16:38: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 j0A0cqnd045263; Sun, 9 Jan 2005 16:38: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 j0A0clU4045142 for ; Sun, 9 Jan 2005 16:38:48 -0800 (PST) (envelope-from dean@av8.com) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id j0A0cVA2022231 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 9 Jan 2005 19:38:32 -0500 Date: Sun, 9 Jan 2005 19:38:31 -0500 (EST) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: Matthew.van.Eerde@hbinc.com cc: ietf-mxcomp@imc.org Subject: RE: blowback, was A new SMTP "3821" [Re: FTC stuff...........] In-Reply-To: <61192FA29C719B469A2B13E57DEDF75B0348A647@mail.hbinc.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, 3 Jan 2005 Matthew.van.Eerde@hbinc.com wrote: > > Dean Anderson wrote: > > The blowback issue is different from this. Blowback happens whenever > > anyone _rejects_ emails based on SPF. > > Fair enough > > > A bounce is generated from the relay to the forged sender. > > Is it? If the receiving MTA issues an SMTP reject command, it does not > assume any responsibility for the delivery of the mail. It will > therefore not generate a spurious bounce message. This isn't how most current SMTP servers behave. (Sendmail/Qmail/Postfix/Exchange, anyway) If the receiving MTA rejects mail, the sending MTA generates a bounce to the sender. The sender of course, can be forged. > If the sending MTA generates a bounce message, then it's likely not a > virus or other malware likely to forge a sender address. ??? This too is wrong. Many viruses send "forged" bounces containing a virus. One cannot assume that because you opened a bounce, the message will not contain a virus. Further, a genuine bounce with an undelivered message may contain a virus in the undelivered message. > Matthew.van.Eerde (at) hbinc.com 805.964.4554 x902 > Hispanic Business Inc./HireDiversity.com Software Engineer > perl -e"map{y/a-z/l-za-k/;print}shift" "Jjhi pcdiwtg Ptga wprztg," > > > -- 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 Sun Jan 9 21:09:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24506 for ; Sun, 9 Jan 2005 21:09: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 j0A1iM5Y012217; Sun, 9 Jan 2005 17:44: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 j0A1iM0B012216; Sun, 9 Jan 2005 17:44:22 -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 j0A1iLxs012200 for ; Sun, 9 Jan 2005 17:44:21 -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 j0A1wXVI021484; Sun, 9 Jan 2005 20:58:33 -0500 From: To: "'Dean Anderson'" , Cc: Subject: RE: blowback, was A new SMTP "3821" [Re: FTC stuff...........] Date: Sun, 9 Jan 2005 20:43:36 -0500 Message-ID: <00b501c4f6b5$cda9fe80$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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 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 Dean Anderson > Sent: Sunday, January 09, 2005 7:39 PM > To: Matthew.van.Eerde@hbinc.com > Cc: ietf-mxcomp@imc.org > Subject: RE: blowback, was A new SMTP "3821" [Re: FTC > stuff...........] > > > > On Mon, 3 Jan 2005 Matthew.van.Eerde@hbinc.com wrote: > > > > > Dean Anderson wrote: > > > The blowback issue is different from this. Blowback > happens whenever > > > anyone _rejects_ emails based on SPF. > > > > Fair enough > > > > > A bounce is generated from the relay to the forged sender. > > > > Is it? If the receiving MTA issues an SMTP reject command, > it does not > > assume any responsibility for the delivery of the mail. It will > > therefore not generate a spurious bounce message. > > This isn't how most current SMTP servers behave. > (Sendmail/Qmail/Postfix/Exchange, anyway) If the receiving > MTA rejects > mail, the sending MTA generates a bounce to the sender. The > sender of > course, can be forged. Agreed, but near sighted. If the sending MTA had done some sort of validation to ensure the message was not forged when it accepted it, then we wouldn't have a blowback problem. You cannot blame subsequent MTA's in the path for detecting and rejecting bad email when its something the first hop MTA could (and should) have done in the first place! His point I think is that if the virus is trying to send directly to the MTA it would get rejected with no bounce back (because the virus wouldn't process a bounce). If an MTA.1 accepted a virus message, and tried relaying it to MTA.2, when MTA.2 rejects it as forged, and MTA.1 processes a bounce, well, NO SYMPATHY FOR MTA.1, it should have taken steps to prevent the virus/forgery etc from being accepted by itself in the FIRST PLACE. > > > If the sending MTA generates a bounce message, then it's > likely not a > > virus or other malware likely to forge a sender address. > > ??? > > This too is wrong. Many viruses send "forged" bounces > containing a virus. The statement was that virus infected machines don't usually process bounces if an MTA rejects its transmission attempt. And the statement *is* correct. > One cannot assume that because you opened a bounce, the > message will not > contain a virus. Further, a genuine bounce with an > undelivered message > may contain a virus in the undelivered message. True, but what is your point? The question at hand was "If the MTA rejects a message, does this cause a blowback problem": Case 1: Message is arriving from the virus itself: -no blowback, viruses will usually ignore the rejection Case 2: Message is arriving from an MTA that accepted the message from a virus: -no sympathy for the bounce, the MTA should have rejected the virus message in the first place. Is there a real issue with blowback? NO: There are plenty of ways of dealing with blowback until all the MTA's are upgraded to provide some sort of MTA authentication to deal with forgery and reject it at the first hop. (Yes, even silently dropping the bounces, something which large ISP's often do already ANYWAY). Terry Fielder > > > > Matthew.van.Eerde (at) hbinc.com 805.964.4554 x902 > > Hispanic Business Inc./HireDiversity.com Software Engineer > > perl -e"map{y/a-z/l-za-k/;print}shift" "Jjhi pcdiwtg Ptga wprztg," > > > > > > > > -- > 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 Jan 10 15:16:46 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19892 for ; Mon, 10 Jan 2005 15:16: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 j0AJiTZn036194; Mon, 10 Jan 2005 11:44:29 -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 j0AJiT7W036192; Mon, 10 Jan 2005 11:44:29 -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 j0AJiOYG036099 for ; Mon, 10 Jan 2005 11:44:24 -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 j0AJiGkv010932 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 10 Jan 2005 14:44:18 -0500 Date: Mon, 10 Jan 2005 14:44:16 -0500 (EST) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: terry@ashtonwoodshomes.com cc: Matthew.van.Eerde@hbinc.com, Subject: RE: blowback, was A new SMTP "3821" [Re: FTC stuff...........] In-Reply-To: <00b501c4f6b5$cda9fe80$2766f30a@development.greatgulfhomes.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 Sun, 9 Jan 2005 terry@ashtonwoodshomes.com wrote: > > Agreed, but near sighted. If the sending MTA had done some sort of validation to ensure the message > was not forged when it accepted it, then we wouldn't have a blowback problem. You cannot blame > subsequent MTA's in the path for detecting and rejecting bad email when its something the first hop > MTA could (and should) have done in the first place! And just what sort of validation would that be? You are talking about a normal closed relay. It cannot use SPF to validate its own users. > His point I think is that if the virus is trying to send directly to the MTA it would get rejected > with no bounce back (because the virus wouldn't process a bounce). > > If an MTA.1 accepted a virus message, and tried relaying it to MTA.2, when MTA.2 rejects it as > forged, and MTA.1 processes a bounce, well, NO SYMPATHY FOR MTA.1, it should have taken steps to > prevent the virus/forgery etc from being accepted by itself in the FIRST PLACE. Your lack of sympathy for MTA.1 is unfortunate, but unrealistic. Even taking steps to prevent viruses does not catch all virues. Even using SMTP AUTH on a closed relay does not prevent forgery. --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 Jan 10 15:17:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19942 for ; Mon, 10 Jan 2005 15:17: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 j0AJr649043068; Mon, 10 Jan 2005 11:53:06 -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 j0AJr57v043067; Mon, 10 Jan 2005 11:53:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.hbinc.com (mail.hbinc.com [63.149.249.2]) by above.proper.com (8.12.11/8.12.9) with SMTP id j0AJr5Ae043052 for ; Mon, 10 Jan 2005 11:53:05 -0800 (PST) (envelope-from Matthew.van.Eerde@hbinc.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: blowback, was A new SMTP "3821" [Re: FTC stuff...........] Date: Mon, 10 Jan 2005 11:53:06 -0800 Message-ID: <61192FA29C719B469A2B13E57DEDF75B0348A6CA@mail.hbinc.com> Thread-Topic: blowback, was A new SMTP "3821" [Re: FTC stuff...........] Thread-Index: AcT3TMu+qXdlbprCRtGoz3Yq9x7vSAAADtkAAAA5XOA= From: To: , Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j0AJr5Ae043060 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > From: Matthew.van.Eerde > If MTA.2 then turns around and delivers the virus to someone else, that is not my problem. Er, I meant to say, If MTA.1 turns around etc. From owner-ietf-mxcomp@mail.imc.org Mon Jan 10 15:17:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19992 for ; Mon, 10 Jan 2005 15:17: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 j0AJpj4V042163; Mon, 10 Jan 2005 11:51: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 j0AJpjtG042162; Mon, 10 Jan 2005 11:51:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.hbinc.com (mail.hbinc.com [63.149.249.2]) by above.proper.com (8.12.11/8.12.9) with SMTP id j0AJpiqC042134 for ; Mon, 10 Jan 2005 11:51:44 -0800 (PST) (envelope-from Matthew.van.Eerde@hbinc.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: blowback, was A new SMTP "3821" [Re: FTC stuff...........] Date: Mon, 10 Jan 2005 11:51:43 -0800 Message-ID: <61192FA29C719B469A2B13E57DEDF75B0348A6C9@mail.hbinc.com> Thread-Topic: blowback, was A new SMTP "3821" [Re: FTC stuff...........] Thread-Index: AcT3TMu+qXdlbprCRtGoz3Yq9x7vSAAADtkA From: To: , Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j0AJpiqC042155 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > From: Dean Anderson [mailto:dean@av8.com] > On Sun, 9 Jan 2005 terry@ashtonwoodshomes.com wrote: > > > > > Agreed, but near sighted. If the sending MTA had done some > sort of validation to ensure the message > > was not forged when it accepted it, then we wouldn't have a > blowback problem. You cannot blame > > subsequent MTA's in the path for detecting and rejecting > bad email when its something the first hop > > MTA could (and should) have done in the first place! > > And just what sort of validation would that be? Authentication (SMTP AUTH, POP-before-SMTP, etc.), restriction to trusted IP addresses, etc. Basically the sending server is responsible for authorizing its own use, via whatever method is most appropriate. > > His point I think is that if the virus is trying to send > directly to the MTA it would get rejected > > with no bounce back (because the virus wouldn't process a bounce). > > > > If an MTA.1 accepted a virus message, and tried relaying it > to MTA.2, when MTA.2 rejects it as > > forged, and MTA.1 processes a bounce, well, NO SYMPATHY FOR > MTA.1, it should have taken steps to > > prevent the virus/forgery etc from being accepted by itself > in the FIRST PLACE. > > Your lack of sympathy for MTA.1 is unfortunate, but unrealistic. Even > taking steps to prevent viruses does not catch all virues. Even using > SMTP AUTH on a closed relay does not prevent forgery. > > --Dean I have the greatest sympathy for MTA.1 and its users. My sympathy (as MTA.2's admin) does NOT extend to taking responsibility for delivery of the viruses MTA.1 is trying to unload on me. If MTA.2 then turns around and delivers the virus to someone else, that is not my problem. With my particular MTA.2, I reject virii even if they are to valid addresses. If this causes MTA.1 to deliver a bounce message (possibly even including the virus) to the forged sender, then MTA.1 just made a big mistake. I suppose a case could be made that it's "my fault" somehow, but I'm not going to lose any sleep over it. Matthew.van.Eerde (at) hbinc.com 805.964.4554 x902 Hispanic Business Inc./HireDiversity.com Software Engineer perl -e"map{y/a-z/l-za-k/;print}shift" "Jjhi pcdiwtg Ptga wprztg," From owner-ietf-mxcomp@mail.imc.org Mon Jan 10 15:37:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22197 for ; Mon, 10 Jan 2005 15:37:39 -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 j0AK6MGn054493; Mon, 10 Jan 2005 12:06: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 j0AK6MGW054491; Mon, 10 Jan 2005 12:06:22 -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 j0AK6KrC054467 for ; Mon, 10 Jan 2005 12:06:21 -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 j0AKKXpM013004; Mon, 10 Jan 2005 15:20:33 -0500 From: To: , Cc: Subject: RE: blowback, was A new SMTP "3821" [Re: FTC stuff...........] Date: Mon, 10 Jan 2005 15:05:29 -0500 Message-ID: <003001c4f74f$bdc81520$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0031_01C4F725.D4F20D20" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <61192FA29C719B469A2B13E57DEDF75B0348A6C9@mail.hbinc.com> X-MS-TNEF-Correlator: 00000000C8689303D474D71196E900201855F5B344D83003 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0031_01C4F725.D4F20D20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of > Matthew.van.Eerde@hbinc.com > Sent: Monday, January 10, 2005 2:52 PM > To: dean@av8.com; terry@ashtonwoodshomes.com > Cc: ietf-mxcomp@imc.org > Subject: RE: blowback, was A new SMTP "3821" [Re: FTC > stuff...........] > > > > > From: Dean Anderson [mailto:dean@av8.com] > > On Sun, 9 Jan 2005 terry@ashtonwoodshomes.com wrote: > > > > > > > > Agreed, but near sighted. If the sending MTA had done some > > sort of validation to ensure the message > > > was not forged when it accepted it, then we wouldn't have a > > blowback problem. You cannot blame > > > subsequent MTA's in the path for detecting and rejecting > > bad email when its something the first hop > > > MTA could (and should) have done in the first place! > > > > And just what sort of validation would that be? > > Authentication (SMTP AUTH, POP-before-SMTP, etc.), > restriction to trusted IP addresses, etc. Basically the > sending server is responsible for authorizing its own use, > via whatever method is most appropriate. And let's not forget that the authorization can also include SPF-Classic or even Unified SPF (if ot goes anywhere) (or even if you like bad things to happen PRA). That would ensure that authorized clients of the MTA.1 whose machines are infected cannot forge the From address, hence the bounce generated by MTA.1 when MTA.2 rejects the email will go somewhere not forged (i.e. the infected machine or at least someone from that domain). > > > > His point I think is that if the virus is trying to send > > directly to the MTA it would get rejected > > > with no bounce back (because the virus wouldn't process a bounce). > > > > > > If an MTA.1 accepted a virus message, and tried relaying it > > to MTA.2, when MTA.2 rejects it as > > > forged, and MTA.1 processes a bounce, well, NO SYMPATHY FOR > > MTA.1, it should have taken steps to > > > prevent the virus/forgery etc from being accepted by itself > > in the FIRST PLACE. > > > > Your lack of sympathy for MTA.1 is unfortunate, but > unrealistic. Even > > taking steps to prevent viruses does not catch all virues. > Even using > > SMTP AUTH on a closed relay does not prevent forgery. > > > > --Dean > > I have the greatest sympathy for MTA.1 and its users. My > sympathy (as MTA.2's admin) does NOT extend to taking > responsibility for delivery of the viruses MTA.1 is trying to > unload on me. If MTA.1 then turns around and delivers the > virus to someone else, that is not my problem. Exactly. > > With my particular MTA.2, I reject virii even if they are to > valid addresses. Definitely the best course of action. > If this causes MTA.1 to deliver a bounce > message (possibly even including the virus) to the forged > sender, then MTA.1 just made a big mistake. Exactly. > I suppose a case > could be made that it's "my fault" somehow, but I'm not going > to lose any sleep over it. Sorry to say "what he said", but it is *so* important and seems to get overlooked by those rejecting SPF, I felt the need to chime in. Terry Fielder > > Matthew.van.Eerde (at) hbinc.com 805.964.4554 x902 > Hispanic Business Inc./HireDiversity.com Software Engineer > perl -e"map{y/a-z/l-za-k/;print}shift" "Jjhi pcdiwtg Ptga wprztg," > ------=_NextPart_000_0031_01C4F725.D4F20D20 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IiAUAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANUHAQAKAA8ABQAAAAEA/AAB A5AGANwNAAAqAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAALACsAAAAAAAMALgAA AAAAAwA2AAAAAAAeAHAAAQAAADsAAABibG93YmFjaywgd2FzIEEgbmV3IFNNVFAgIjM4MjEiIFtS ZTogRlRDIHN0dWZmLi4uLi4uLi4uLi5dAAACAXEAAQAAABYAAAABxPdPu5/ui0HIrwNK+rhKS1CP ST3iAAACAR0MAQAAAB4AAABTTVRQOlRFUlJZQEdSRUFUR1VMRkhPTUVTLkNPTQAAAAsAAQ4AAAAA QAAGDgC+AqpP98QBAgEKDgEAAAAYAAAAAAAAAMhokwPUdNcRlukAIBhV9bNChQAAAwAUDgEAAAAL AB8OAQAAAAMABhBoNyMGAwAHEMoJAAAeAAgQAQAAAGUAAAAtLS0tLU9SSUdJTkFMTUVTU0FHRS0t LS0tRlJPTTpPV05FUi1JRVRGLU1YQ09NUEBNQUlMSU1DT1JHTUFJTFRPOk9XTkVSLUlFVEYtTVhD T01QQE1BSUxJTUNPUkdPTkJFSEFMAAAAAAIBCRABAAAAEwkAAA8JAAD7DwAATFpGdQV6bQ4DAAoA cmNwZzEyNeIyA0N0ZXgFQQEDAff/CoACpAPkBxMCgA/zAFAEVj8IVQeyESUOUQMBAgBjaOEKwHNl dDIGAAbDESX2MwRGE7cwEiwRMwjvCfe2OxgfDjA1ESIMYGMAULMLCQFkMzYWUAunYwEwUCA+IC0d Uk8FEGcPC4AHQAXQB5BzYWdlLx1TCqIKgB0wRgNhOiBob3duBJAtCJAAMC3EbXgFoG1wQADAAxBS LgdwYy4FsGce9lsxIPJ0bzof3yDrXU8JA6BCZRPgbGYgT1JmHvZNYQJAaAfQLjJ2AHAuRQSQAQBA aP5iC4AhYCOBHvYGYAIwH7ACTQIgZGF5LCBKhQBwdQrAeSAxMCjQKQHQMDUpoDoOQCBQak0e9lQi kCABAABwQEhhdjgnUjsgDrByEylAK3BzaCKAbndvnwRwLIADcAeQJ1pDYx+wwyMaIU1TdWJqBZAo QVxSRR+wAmAisGIA0GttKNB3LHAQwCAi0AfgUwBNVFAgIjM4MiQxIiIgUmUfsEZURkMK4x8yc3R1 ASAuvTRYXR72NR8fBR9WRCtB9xDAKJAEkHMCICInKzo1B9cdMCShMCBuKNA5KOIppN8sHy0nMYAD YA6wOjaYNpiVPixBCcJkKNBidQVANyLQCsEAkGc8EAmALiC8IEklICYRM/AJ8GQLgNpnBdBUMdAT 4GQrIAIg/0HBLTE2iTgwACAfwCUgJmBkbGkooHRpOEEigCD9CfBzCHBBwEGiB4EeYj5K9TGSbj1g IAIQIZAJgDGAmyYgA6BpBUAA0GNlBTDfSCFIoCjQJhEDoHdBwCzQYHVsZG4nBUAT4HbNQcBhNokw 9iBwA2ACYJRlbUFBWQhgIGMAcLtHogJgYQeAPkpFoGIUEO5xClACMEJSJwQgC4BBk/8KsCYQR9Ir IQ6wMHBCIgBw/0LAGCAwUkIiSylCsUygIQE/SEYEIEMyJhBCIkGiZmnzFABKkW9wPkpCYgWgSkHc IChRYi0RSkEpSqRC4+9PxVT0C1FI8CE9rz+SUXH8anVVIUhQJfBEHzhBSiOjQZFbcWJlPzWeQUBQ L0hhRQBNMEUDKDIzQVWEVEgo0FBPUC1dgL9H4R6QMjIo0BQgIWApKND/HvYYIDQABRBRAUUkYpBb EW1IIUkyYEKwZGJhFBBzm2FUQVBCO/BfIWxsKVDvQaIzh0H1FBByStAFwAQAvWJScAIgAJBMgVBz YV7BuQWwaXpCIlPSIrEgWxDaZWHIdgcwW0NlZyJUMs8EcGdSBGBVIWFwTFFMUHsHMA6wLh70HvRa wkyQdP9PkUenBUBdM0GiaJZE9E0x7UjAbDgwT7FjCkABAAYA8FBGLUMLYAQQDeAfwPcFwGshA6BV AwBU8EghcbHPVtAGkB/ABUBnbweRAHBueUhRGCBXkChydnPBeftNAUTAa0HAUuJUUwQgRVGHE+Bs cEhxUFJBKUFB/lRbYlzURYdbcWiWSCFxUJ8IkAIwaXFBhEJhLjFIQX9sIEYRANBUYXRCRcELgGb/ MGF6Ek1ER+NBkx9yY/Yo0P9IYUjwQZMG4Dqgf3EegCLR+2sBQsBiKVB7NkhxezIUQP9RpHbxQbFT JQMQAyB0IEMj93SjR5pzsC5tAEGTfMd79f9yYltxTJA78FuCB4BC8gNS910kQuAg8W534G0qHTA+ O95IZ2FnwAuABUBJdpNMMP9nYV0zc8FBomqgY2GL8ylA/1Rzg7FB8TaJQhAYIDBwZYL/YzF7BEiS XNRu8lGkCYBGq99IoFBgR6B/1kwDKF2ATTD/adGMqUonTFFI8AQRSwB/5P+JFj6vQWIDkXs0SNdL AIz0/0Y1KNBRYmKRSCEYIAtgjaN/SKE2mEVRgdMxcYGfSJNz/5aKR+SaRHs0lWV0Qn/VMXElmxBs KNBOTwYAWU2UUEFgIFkfYE9SNon/ezMo0EihVzRKpAGQdjADoP1jgXB28paKTFByom9kjPP+L0fj KUFhcYgEXYBRI0jmP4DxU9GbECUgNphPxUZJCFJTVCpATEFDRX+WeTaYTPEFwFkxTDBEcXP/BsBQ MilQUIJ7NGdhOqBH4f80EB3wDrBAJB72OqAYIESx9zQADeBBQUVysZvJpRBms/+ldaaXjPMHkULg B5FHol8x/xPQcNEDIIzyLVGKCLISacH/QiE2mF+3H8BwwXoxe7Ga5f+06Kamp8WsLz4DAZG89B1Q /zeSNZ6LgKS0QbEJwWsBh2K/rl9RU1PSadEUAEFBTSlQfzOHwFZW4AQggdNPkUKwbf+I8bTkogCr sA7BjjJjIrME/2HpZ8QDEEigrrQBAETAZyH/KVB6xbR2rxeNiLC4F7BCsf84QQeAQUR7NEmjNBAE oHxi/3/xmTFRccg1gpRqKI0SjfLfh6WbEGnijDRHhG0pUExWeW0qRXgA0I9hiS0e9lf/knLRwgrA XxFKQArBnJWLgPNRpIziaWl1RyYRKVB8gv/KuUSjY/i2hx70N5BU8AMA/w6wZYVdgFUhVoEUAURi 01H/RRGJLUFzZ2GT08mWRVHINf+V1zN3RjVW0GfAciECYKgh/3VjcUNUdozzV5CPpUflZfr/BJBJ hXs0WwMAwHGBleEdwP9GILGRpRHaXdM/vrVFoGxw/3uyuUE78ENoVoRdgOcUjDT1bkIi0cFmaJAi cDLQQzLlLSB3QCRJJz0gR6J0IP9SCkVRuXJ0YjPwTJBJAB/A9WcjdG0bUwWwKUGN8roBziJbU0Gy C3BkIkAkSKH1Z2EqODAqLmAgwBfBAHD3SLFXAgngbXbzbvLxohew/m92MIDTaLF7wVGocbHWkv98 4CJwQZMi0EghRVF8EUNR+wuAbRtUO6IfYAiQSlAEkO/TvyWfJqNW0XRXkScWQVAFAD04KdAuOTY0 LoI0GmA0IHg5MA5Q3x8FiuEKsBOAclBCt4KVotpJJzEviuAYIETOc8ex3//78uAb4DGQRcFFQjB8 MW/8tqaB93EdQGXtoGxgXAB7eS9hLXovbGMIcAhgay87bLEPoFyOfTwAcxDuISJKalRgpUxAY0IQ d3RCQFAKsEtqwUxQegqwLCI1nH0BDKAAAwAQEAEAAAADABEQAQAAAB4AQhABAAAAOgAAADw2MTE5 MkZBMjlDNzE5QjQ2OUEyQjEzRTU3REVERjc1QjAzNDhBNkM5QG1haWwuaGJpbmMuY29tPgAAAAMA AIAIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwApgAggBgAAAAAAwAAAAAAAAEYAAAAAUoUA APATAAAeACqACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA4LjUAHgArgAggBgAAAAAA wAAAAAAAAEYAAAAANoUAAAEAAAABAAAAAAAAAB4ALIAIIAYAAAAAAMAAAAAAAABGAAAAADeFAAAB AAAAAQAAAAAAAAAeAC2ACCAGAAAAAADAAAAAAAAARgAAAAA4hQAAAQAAAAEAAAAAAAAACwAugAgg BgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAC+ACCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAA AAsAMIAIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwAxgAggBgAAAAAAwAAAAAAAAEYAAAAA EYUAAAAAAAADADKACCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAAsAM4AIIAYAAAAAAMAAAAAA AABGAAAAAAaFAAAAAAAACwA0gAsgBgAAAAAAwAAAAAAAAEYAAAAAAIgAAAAAAAALADWACyAGAAAA AADAAAAAAAAARgAAAAAFiAAAAAAAAAIB+A8BAAAAEAAAAMhokwPUdNcRlukAIBhV9bMCAfoPAQAA ABAAAADIaJMD1HTXEZbpACAYVfWzAgH7DwEAAABNAAAAAAAAADihuxAF5RAaobsIACsqVsIAAG1z cHN0LmRsbAAAAAAATklUQfm/uAEAqgA32W4AAABDOlxtYWlsXG91dGxvb2tuZXcyLnBzdAAAAAAD AP4PBQAAAAMADTT9NwAAAgF/AAEAAAAxAAAAMDAwMDAwMDBDODY4OTMwM0Q0NzRENzExOTZFOTAw MjAxODU1RjVCMzQ0RDgzMDAzAAAAAM0y ------=_NextPart_000_0031_01C4F725.D4F20D20-- From owner-ietf-mxcomp@mail.imc.org Mon Jan 10 16:36:17 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03741 for ; Mon, 10 Jan 2005 16:36: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 j0AL8iVO009615; Mon, 10 Jan 2005 13:08:44 -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 j0AL8irq009614; Mon, 10 Jan 2005 13:08:44 -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 j0AL8ikk009599 for ; Mon, 10 Jan 2005 13:08:44 -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 j0AL8Ggb012477 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 10 Jan 2005 16:08:25 -0500 Date: Mon, 10 Jan 2005 16:08:12 -0500 (EST) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: Matthew.van.Eerde@hbinc.com cc: terry@ashtonwoodshomes.com, Subject: RE: blowback, was A new SMTP "3821" [Re: FTC stuff...........] In-Reply-To: <61192FA29C719B469A2B13E57DEDF75B0348A6C9@mail.hbinc.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, 10 Jan 2005 Matthew.van.Eerde@hbinc.com wrote: > > And just what sort of validation would that be? > > Authentication (SMTP AUTH, POP-before-SMTP, etc.), restriction to > trusted IP addresses, etc. Basically the sending server is responsible > for authorizing its own use, via whatever method is most appropriate. And this stops forgery how? I think you're forgeting that _every_ user (including every spammer and forger, and virus-infected computer) has relay services provided by their provider. They have those services right up until they don't. SPF takes for granted that the ISP's users can forge email to the ISPs relay, and doesn't address that problem. This opens the possibility for 100% blowback. > > Your lack of sympathy for MTA.1 is unfortunate, but unrealistic. Even > > taking steps to prevent viruses does not catch all virues. Even using > > SMTP AUTH on a closed relay does not prevent forgery. > > I have the greatest sympathy for MTA.1 and its users. My sympathy (as > MTA.2's admin) does NOT extend to taking responsibility for delivery of > the viruses MTA.1 is trying to unload on me. If MTA.2 then turns around > and delivers the virus to someone else, that is not my problem. > > With my particular MTA.2, I reject virii even if they are to valid > addresses. If this causes MTA.1 to deliver a bounce message (possibly > even including the virus) to the forged sender, then MTA.1 just made a > big mistake. I suppose a case could be made that it's "my fault" > somehow, but I'm not going to lose any sleep over it. You may reject some virii. But I think you don't reject all virii, either because your virus definitions aren't uptodate every second of the day, or because a new virus has emerged which isn't in the detection database. Supposing you say, "I don't accept any attachments", then I'd point out that this is insufficient to prevent infection, since a link to a rogue server is enough to infect a computer. Supposing you say, "I don't allow html email", then I'd point out that abusers can still send a URL in text, an the unsuspecting user might type it into their browser and get infected. Supposing you say, "My users are too smart to fall for that", I'd say: congratulations. But it doesn't scale. --Dean > Matthew.van.Eerde (at) hbinc.com 805.964.4554 x902 > Hispanic Business Inc./HireDiversity.com Software Engineer > perl -e"map{y/a-z/l-za-k/;print}shift" "Jjhi pcdiwtg Ptga wprztg," > > -- 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 Jan 10 16:44:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05135 for ; Mon, 10 Jan 2005 16:44: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 j0ALGQCF018924; Mon, 10 Jan 2005 13:16: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 j0ALGQ2D018919; Mon, 10 Jan 2005 13:16:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.hbinc.com (mail.hbinc.com [63.149.249.2]) by above.proper.com (8.12.11/8.12.9) with SMTP id j0ALGOpH018863 for ; Mon, 10 Jan 2005 13:16:24 -0800 (PST) (envelope-from Matthew.van.Eerde@hbinc.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: blowback, was A new SMTP "3821" [Re: FTC stuff...........] Date: Mon, 10 Jan 2005 13:16:28 -0800 Message-ID: <61192FA29C719B469A2B13E57DEDF75B0348A6CD@mail.hbinc.com> Thread-Topic: blowback, was A new SMTP "3821" [Re: FTC stuff...........] Thread-Index: AcT3WJOSunXVcx4tSySnp2ncqJoWkQAAB13w From: To: Cc: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j0ALGOpH018865 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Dean Anderson wrote: > On Mon, 10 Jan 2005 Matthew.van.Eerde@hbinc.com wrote: > > I think you're forgeting that _every_ user (including every spammer > and forger, and virus-infected computer) has relay services provided > by their provider. They have those services right up until they don't. > > SPF takes for granted that the ISP's users can forge email to the ISPs > relay, and doesn't address that problem. This opens the possibility > for 100% blowback. True. Consider Sammy Spammer using Example ISP. They could send email all day long from innocentbystander@isp.example.com, and if I reject the email on the grounds of being malware, isp.example.com's mail server is going to deluge innocentbystander@isp.example.com with lots of blowback. But surely innocentbystander@isp.example.com can report this to Example ISP, who should have the necessary logs to be able to catch Sammy Spammer, or at least terminate their access. > You may reject some virii. But I think you don't reject all virii Right, I can't catch all virii. But I can reject the ones I do catch. Matthew.van.Eerde (at) hbinc.com 805.964.4554 x902 Hispanic Business Inc./HireDiversity.com Software Engineer perl -e"map{y/a-z/l-za-k/;print}shift" "Jjhi pcdiwtg Ptga wprztg," From owner-ietf-mxcomp@mail.imc.org Tue Jan 11 11:12:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04586 for ; Tue, 11 Jan 2005 11:12:09 -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 j0BFUd1i057147; Tue, 11 Jan 2005 07:30: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 j0BFUdFZ057146; Tue, 11 Jan 2005 07:30:39 -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 j0BFUcUq057116 for ; Tue, 11 Jan 2005 07:30:38 -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 j0BFUfC5000371 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 11 Jan 2005 10:30:46 -0500 Date: Tue, 11 Jan 2005 10:30:39 -0500 (EST) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: ietf-mxcomp@imc.org Subject: Abusive blacklist Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; REPORT-TYPE=delivery-status; BOUNDARY="j0AJiTkt010934.1105386269/cirrus.av8.net" Content-ID: Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --j0AJiTkt010934.1105386269/cirrus.av8.net Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Terry, you are using an abusive "blacklist". SORBS, like ORBS, has no qualms about lying about those they don't like. In our case, they don't like the fact that I revealed their secret spam support operations. (They scan for open relays and then give that information to abusers.) Anyway, one can easilly see that 130.105/16 is not hijacked, nor is 198.3.136/21 hijacked. Neither registrant is out of business. The false claims of hijacking came from Alan Brown (of ORBS infamy) who was found in court to be a liar, engaging in defamation and false statements against ISPs he didn't like, for he personal financial benefit. Alan Brown and Matthew Sullivan are not authoritative for the registrations and have no authority to make any kind of statement about their registration. People who are genuinely interested in anti-spam should shun those who use such tools for personal attacks. (The Judge in one of the ORBS cases noted also that Brown was using false ORBS listings as a personal attack, not based on any genuinely held belief.) --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ---------- Forwarded message ---------- Date: Mon, 10 Jan 2005 14:44:29 -0500 From: Mail Delivery Subsystem To: dean@av8.com Subject: Returned mail: see transcript for details The original message was received at Mon, 10 Jan 2005 14:44:18 -0500 from dakota.av8.net [130.105.19.131] ----- The following addresses had permanent fatal errors ----- (reason: 553 5.3.0 ... Message from 130.105.36.66 rejected - see http://www.dnsbl.us.sorbs.net/cgi-bin/lookup?IP= 130.105.36.66) ----- Transcript of session follows ----- ... while talking to mail.ashtonwoodshomes.com.: >>> DATA <<< 553 5.3.0 ... Message from 130.105.36.66 rejected - see http://www.dnsbl.us.sorbs.net/cgi-bin/lookup?IP= 130.105.36.66 550 5.1.1 ... User unknown <<< 503 5.0.0 Need RCPT (recipient) --j0AJiTkt010934.1105386269/cirrus.av8.net Content-Type: MESSAGE/DELIVERY-STATUS; CHARSET=US-ASCII Content-ID: Content-Description: Reporting-MTA: dns; cirrus.av8.net Received-From-MTA: DNS; dakota.av8.net Arrival-Date: Mon, 10 Jan 2005 14:44:18 -0500 Final-Recipient: RFC822; terry@ashtonwoodshomes.com Action: failed Status: 5.3.0 Remote-MTA: DNS; mail.ashtonwoodshomes.com Diagnostic-Code: SMTP; 553 5.3.0 ... Message from 130.105.36.66 rejected - see http://www.dnsbl.us.sorbs.net/cgi-bin/lookup?IP= 130.105.36.66 Last-Attempt-Date: Mon, 10 Jan 2005 14:44:24 -0500 --j0AJiTkt010934.1105386269/cirrus.av8.net Content-Type: MESSAGE/RFC822; CHARSET=US-ASCII Content-ID: Content-Description: Return-Path: 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 j0AJiGkv010932 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 10 Jan 2005 14:44:18 -0500 Date: Mon, 10 Jan 2005 14:44:16 -0500 (EST) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: terry@ashtonwoodshomes.com cc: Matthew.van.Eerde@hbinc.com, Subject: RE: blowback, was A new SMTP "3821" [Re: FTC stuff...........] In-Reply-To: <00b501c4f6b5$cda9fe80$2766f30a@development.greatgulfhomes.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 9 Jan 2005 terry@ashtonwoodshomes.com wrote: > > Agreed, but near sighted. If the sending MTA had done some sort of validation to ensure the message > was not forged when it accepted it, then we wouldn't have a blowback problem. You cannot blame > subsequent MTA's in the path for detecting and rejecting bad email when its something the first hop > MTA could (and should) have done in the first place! And just what sort of validation would that be? You are talking about a normal closed relay. It cannot use SPF to validate its own users. > His point I think is that if the virus is trying to send directly to the MTA it would get rejected > with no bounce back (because the virus wouldn't process a bounce). > > If an MTA.1 accepted a virus message, and tried relaying it to MTA.2, when MTA.2 rejects it as > forged, and MTA.1 processes a bounce, well, NO SYMPATHY FOR MTA.1, it should have taken steps to > prevent the virus/forgery etc from being accepted by itself in the FIRST PLACE. Your lack of sympathy for MTA.1 is unfortunate, but unrealistic. Even taking steps to prevent viruses does not catch all virues. Even using SMTP AUTH on a closed relay does not prevent forgery. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 --j0AJiTkt010934.1105386269/cirrus.av8.net-- From owner-ietf-mxcomp@mail.imc.org Tue Jan 11 11:12:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04611 for ; Tue, 11 Jan 2005 11:12: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 j0BFaQUR062457; Tue, 11 Jan 2005 07:36: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 j0BFaQOr062456; Tue, 11 Jan 2005 07:36:26 -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 j0BFaPC9062448 for ; Tue, 11 Jan 2005 07:36:26 -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 j0BFaKDq000463 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 11 Jan 2005 10:36:20 -0500 Date: Tue, 11 Jan 2005 10:36:19 -0500 (EST) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: Matthew.van.Eerde@hbinc.com cc: terry@ashtonwoodshomes.com, Subject: RE: blowback, was A new SMTP "3821" [Re: FTC stuff...........] In-Reply-To: <61192FA29C719B469A2B13E57DEDF75B0348A6C9@mail.hbinc.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, 10 Jan 2005 Matthew.van.Eerde@hbinc.com wrote: > > > From: Dean Anderson [mailto:dean@av8.com] > > On Sun, 9 Jan 2005 terry@ashtonwoodshomes.com wrote: > > > > > > > > Agreed, but near sighted. If the sending MTA had done some > > sort of validation to ensure the message > > > was not forged when it accepted it, then we wouldn't have a > > blowback problem. You cannot blame > > > subsequent MTA's in the path for detecting and rejecting > > bad email when its something the first hop > > > MTA could (and should) have done in the first place! > > > > And just what sort of validation would that be? > > Authentication (SMTP AUTH, POP-before-SMTP, etc.), restriction to > trusted IP addresses, etc. Basically the sending server is responsible > for authorizing its own use, via whatever method is most appropriate. None of the things you listed indicate prevent forgery. Server authorization is not related to forgery. As I pointed out, Closed relays are "authorized", but one can still forge emails. SMTP AUTH and Pop-before-SMTP don't prevent forgery, either. As I already pointed you, you keep forgetting that every abuser is someone's customer, and so has access to relay facilities. Those facilities cannot prevent forgery. -- 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 Jan 11 12:04:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09271 for ; Tue, 11 Jan 2005 12:04: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 j0BGbwLD077144; Tue, 11 Jan 2005 08:37: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 j0BGbwnL077143; Tue, 11 Jan 2005 08:37:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [212.125.101.207]) by above.proper.com (8.12.11/8.12.9) with SMTP id j0BGbuW8077114 for ; Tue, 11 Jan 2005 08:37:58 -0800 (PST) (envelope-from arnt@gulbrandsen.priv.no) Received: by kalyani.oryx.com (Postfix, from userid 1005) id 32D3E1BDE94; Tue, 11 Jan 2005 17:30:35 +0100 (CET) Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by kalyani.oryx.com (Postfix) with SMTP id 597EF1BDE88 for ; Tue, 11 Jan 2005 17:30:34 +0100 (CET) Message-Id: <84hoPFgY7UdcujGNVUO6uw.md5@libertango.oryx.com> Date: Tue, 11 Jan 2005 17:35:34 +0100 From: Arnt Gulbrandsen To: ietf-mxcomp@imc.org Subject: Re: Abusive blacklist References: In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dean Anderson schrieb: > Terry, you are using an abusive "blacklist". SORBS, like ORBS, has no > qualms about lying about those they don't like. > > In our case, they don't like the fact that I revealed their secret > spam support operations. (They scan for open relays and then give > that information to abusers.) Do you mean that they give the information to the general public, abusers included, or do you mean something else? Arnt From owner-ietf-mxcomp@mail.imc.org Tue Jan 11 17:55:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12576 for ; Tue, 11 Jan 2005 17:55: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 j0BMOOku069888; Tue, 11 Jan 2005 14:24: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 j0BMOOvt069887; Tue, 11 Jan 2005 14:24:24 -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 j0BMON3X069880 for ; Tue, 11 Jan 2005 14:24:23 -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 j0BMRCLl023608; Tue, 11 Jan 2005 14:27:12 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id j0BMRCYO023605; Tue, 11 Jan 2005 14:27:12 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Tue, 11 Jan 2005 14:27:11 -0800 (PST) From: "william(at)elan.net" To: Arnt Gulbrandsen cc: ietf-mxcomp@imc.org Subject: Re: Abusive blacklist In-Reply-To: <84hoPFgY7UdcujGNVUO6uw.md5@libertango.oryx.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 Tue, 11 Jan 2005, Arnt Gulbrandsen wrote: > Dean Anderson schrieb: > > Terry, you are using an abusive "blacklist". SORBS, like ORBS, has no > > qualms about lying about those they don't like. > > > > In our case, they don't like the fact that I revealed their secret > > spam support operations. (They scan for open relays and then give > > that information to abusers.) > > Do you mean that they give the information to the general public, > abusers included, or do you mean something else? I think Dean meant that they scanned for open relays and compiled blacklist and made that blacklist available for general public including by zone transfer (i.e. abuser could easily get entire list). That is not an issue any more as almost nobody runs open relay any more and abusers have moved to other ways to distribute spam (which are even worth - now instead of simply using somebody elses resources without authorization to relay through they are hacking and taking over somebody elses machine with specialized viruses to do that). -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Wed Jan 19 04:02:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22858 for ; Wed, 19 Jan 2005 04:02: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 j0J8FEOc051361; Wed, 19 Jan 2005 00:15: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 j0J8FExq051360; Wed, 19 Jan 2005 00:15:14 -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 j0J8FDwr051334 for ; Wed, 19 Jan 2005 00:15:13 -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 j0J8JHkB018258 for ; Wed, 19 Jan 2005 00:19:17 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id j0J8JHXQ018255 for ; Wed, 19 Jan 2005 00:19:17 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Wed, 19 Jan 2005 00:19:17 -0800 (PST) From: "william(at)elan.net" To: ietf-mxcomp@imc.org Subject: DEA Directorate 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: As is evident from some recent posts on SPF-discuss list, the new IETF Directorate to consider documents that are related to work of former MARID WG has been formed (DEA Directorate - does it stand for "DNS Email Authentication"?). I would have expected that this directorate would be listed at http://www.apps.ietf.org/ together with all other APPS directorates, but unfortunately I can not find any information there yet. I'm also somewhat surprised that there was no announcement (on ietf main list or on former MARID list) on the formation of the directorate and who is on it, so could we possible get some information about the directorate on this list where its is certainly a relevant topic? -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Thu Jan 27 11:25:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25732 for ; Thu, 27 Jan 2005 11:25: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 j0RFXDfR027033; Thu, 27 Jan 2005 07:33: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 j0RFXDBL027032; Thu, 27 Jan 2005 07:33:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.pan-am.ca (nspublic.pan-am.ca [205.200.6.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0RFXCbx027018 for ; Thu, 27 Jan 2005 07:33:13 -0800 (PST) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: So here it is one year later... Date: Thu, 27 Jan 2005 09:33:08 -0600 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <700EEF5641B7E247AC1C9B82C05D125D055536@srv1.pan-am.ca> Thread-Topic: So here it is one year later... Thread-Index: AcUEhZj7F/gKX7rjTJOWTYJT9vVs4w== From: "Gordon Fecyk" To: "IETF MXCOMP (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j0RFXDbx027024 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit ...since the first rumblings of talking about a working group, and there's been no press on MARID since the breakup of said working group. No press from Microsoft, no press from the SPF crowd, no press from anyone. And no instructions included on how to compile, install, or use what little software is available out there. Except for the few commercial (and expensive) offerings by GFi. What gives? Has the whole world lost complete interest in stopping spam? Is spyware really the next big threat to the Internet that the US Congress is looking at legislation for it but not bothering with spam anymore? -- PGP key (0x0AFA039E): Sometimes it's hard to tell where the game ends and where reality bites, er, begins. From owner-ietf-mxcomp@mail.imc.org Thu Jan 27 13:21:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08817 for ; Thu, 27 Jan 2005 13:21:57 -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 j0RHcUwk037004; Thu, 27 Jan 2005 09:38:30 -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 j0RHcUse037003; Thu, 27 Jan 2005 09:38:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0RHcUL4036992 for ; Thu, 27 Jan 2005 09:38:30 -0800 (PST) (envelope-from dotis@mail-abuse.org) Received: from SJC-Office-DHCP-156.Mail-Abuse.ORG (SJC-Office-DHCP-156.Mail-Abuse.ORG [168.61.10.156]) by harry.mail-abuse.org (Postfix) with ESMTP id 21AAA414EA; Thu, 27 Jan 2005 09:38:24 -0800 (PST) Subject: Re: So here it is one year later... From: Douglas Otis To: Gordon Fecyk Cc: "IETF MXCOMP (E-mail)" In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125D055536@srv1.pan-am.ca> References: <700EEF5641B7E247AC1C9B82C05D125D055536@srv1.pan-am.ca> Content-Type: text/plain Date: Thu, 27 Jan 2005 09:38:11 -0800 Message-Id: <1106847491.8464.22.camel@SJC-Office-DHCP-156.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2005-01-27 at 09:33 -0600, Gordon Fecyk wrote: > > What gives? Has the whole world lost complete interest in stopping spam? Is > spyware really the next big threat to the Internet that the US Congress is > looking at legislation for it but not bothering with spam anymore? There is a signature based effort ongoing with Yahoo and Cisco. http://www.mipassoc.org/mass/ One hopes details of merging strategies is being discussed, as it does not appear to be happening much on the mailing list. The technology looks very promising from the perspective of protecting people. (Assuming there is a means to revoke authorization granted by way of the signature.) http://www.mipassoc.org/clear/ Work is still happening and a new draft is about to be released. This approach is compatible with mass efforts, but offers a means to protect networks with similar name based instrument. The pressure is still very much present. The entire effort is about improving security by way of authentication. The lack of security remains the principle enabler. Security places focus upon the client/server administrator, which is the entity authenticated by way of efforts in MASS and CLEAR. -Doug From owner-ietf-mxcomp@mail.imc.org Thu Jan 27 15:36:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22027 for ; Thu, 27 Jan 2005 15:36: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 j0RJruhh047427; Thu, 27 Jan 2005 11:53: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 j0RJruWQ047425; Thu, 27 Jan 2005 11:53:56 -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 j0RJrtMU047417 for ; Thu, 27 Jan 2005 11:53:55 -0800 (PST) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CuFi8-0004Hf-00 for ; Thu, 27 Jan 2005 20:53:48 +0100 Received: from 212.82.251.137 ([212.82.251.137]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Jan 2005 20:53:48 +0100 Received: from nobody by 212.82.251.137 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Jan 2005 20:53:48 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: So here it is one year later... Date: Thu, 27 Jan 2005 20:37:08 +0100 Organization: Lines: 23 Message-ID: <41F942E4.4E18@xyzzy.claranet.de> References: <700EEF5641B7E247AC1C9B82C05D125D055536@srv1.pan-am.ca> 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.137 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 Gordon Fecyk wrote: > no press from the SPF crowd The "SPF crowd" has a position on Sender-ID (Dec 2004): A council was elected (December 2004): An updated draft was published (January 2005): SpamCop recommends SPF and / or domain keys (yesterday): Other relatively new activities include: Bye, Frank (some remarks about RfC 3865 censored) From owner-ietf-mxcomp@mail.imc.org Thu Jan 27 20:12:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18907 for ; Thu, 27 Jan 2005 20:12: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 j0S0SDsZ071207; Thu, 27 Jan 2005 16:28: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 j0S0SDNp071206; Thu, 27 Jan 2005 16:28:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0S0SCgW071199 for ; Thu, 27 Jan 2005 16:28:12 -0800 (PST) (envelope-from dotis@mail-abuse.org) Received: from SJC-Office-DHCP-156.Mail-Abuse.ORG (SJC-Office-DHCP-156.Mail-Abuse.ORG [168.61.10.156]) by harry.mail-abuse.org (Postfix) with ESMTP id DDD3D414EB; Thu, 27 Jan 2005 16:28:12 -0800 (PST) Subject: Re: So here it is one year later... From: Douglas Otis To: Frank Ellermann Cc: ietf-mxcomp@imc.org In-Reply-To: <41F942E4.4E18@xyzzy.claranet.de> References: <700EEF5641B7E247AC1C9B82C05D125D055536@srv1.pan-am.ca> <41F942E4.4E18@xyzzy.claranet.de> Content-Type: text/plain Date: Thu, 27 Jan 2005 16:28:01 -0800 Message-Id: <1106872082.6443.96.camel@SJC-Office-DHCP-156.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2005-01-27 at 20:37 +0100, Frank Ellermann wrote: > Gordon Fecyk wrote: > > > no press from the SPF crowd pobox.com still has the slogan: Sender Policy Framework, an essential part of Sender ID. And although the link has been modified, it continues to indicate the current SPF draft is: http://www.ozonehouse.com/mark/spf/draft-lentczner-spf-00.txt > The "SPF crowd" has a position on Sender-ID (Dec 2004): Quote from this faction: "Many SPF developers and users consider that Microsoft's SenderID proposal is technically unsound and undermines the progress already begun by SPF. SPF development and deployment predate Microsoft's entry into the field and have achieved significant success to date. SenderID, in its most recent form, appears likely to interfere with the correct function and deployment of SPF." ... "Where SenderID breaks the function of existing v=spf1 records, domain owners will only learn of it when legitimate mail is not delivered. SPF record publishers made their records public with the expectation that they would be used with the SPF algorithm. SenderID puts those records to a different, possibly incompatible use, without any consent from the publishers." Agreed; applying a record against different algorithms than that intended when published is inherently deleterious, even though SPF still prevents delivery of mail from forwarding and some list servers. : ( > An updated draft was published (January 2005): > Once again the algorithm changes and still this draft uses the same labels and record identifiers? Classic. Endorsements from those that block all bounce traffic are not likely concerned about mail lost as a result of forwarding or being from various list servers, so it would seem. Based upon these comments, SPF/Sender-ID reduces mail integrity in the bargain. -Doug From owner-ietf-mxcomp@mail.imc.org Thu Jan 27 21:30:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25305 for ; Thu, 27 Jan 2005 21:30:01 -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 j0S1m0Dr077523; Thu, 27 Jan 2005 17:48: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 j0S1m0hU077522; Thu, 27 Jan 2005 17:48:00 -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 j0S1lwdW077515 for ; Thu, 27 Jan 2005 17:47:59 -0800 (PST) (envelope-from dean@av8.com) Received: from sr22.av8.net (sr22.av8.net [198.3.136.5]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id j0S1lsYj025765 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 27 Jan 2005 20:47:55 -0500 Date: Thu, 27 Jan 2005 20:47:53 -0500 (EST) From: Dean Anderson X-X-Sender: dean@sr22.av8.net To: Gordon Fecyk cc: "IETF MXCOMP (E-mail)" Subject: Re: So here it is one year later... In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125D055536@srv1.pan-am.ca> 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, 27 Jan 2005, Gordon Fecyk wrote: > > ...since the first rumblings of talking about a working group, and there's > been no press on MARID since the breakup of said working group. No press > from Microsoft, no press from the SPF crowd, no press from anyone. The working group broke up because of unresolvable technical problems. > And no instructions included on how to compile, install, or use what little > software is available out there. Except for the few commercial (and > expensive) offerings by GFi. If you aren't a developer of SPF, probably you shouldn't be using SPF. > What gives? Has the whole world lost complete interest in stopping spam? Is > spyware really the next big threat to the Internet that the US Congress is > looking at legislation for it but not bothering with spam anymore? No, the world has just realized that SPF doesn't work, and won't stop spam, nor stop forgery. In its present form, SPF does nothing except create more opportunities for email abuse, and promotes spam and email abuse. Most people are interested in things that work. Fewer are interested in making things worse. --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 Jan 27 21:49:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26624 for ; Thu, 27 Jan 2005 21:49:22 -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 j0S29ANE079295; Thu, 27 Jan 2005 18:09: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 j0S29Avi079294; Thu, 27 Jan 2005 18:09:10 -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 j0S299qd079283 for ; Thu, 27 Jan 2005 18:09:09 -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 j0S2NpHZ024765; Thu, 27 Jan 2005 21:23:51 -0500 From: To: "'Dean Anderson'" , "'Gordon Fecyk'" Cc: "'IETF MXCOMP (E-mail)'" Subject: RE: So here it is one year later... Date: Thu, 27 Jan 2005 21:07:43 -0500 Message-ID: <00cb01c504de$27d8d620$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 Importance: Normal In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 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 Dean Anderson > Sent: Thursday, January 27, 2005 8:48 PM > To: Gordon Fecyk > Cc: IETF MXCOMP (E-mail) > Subject: Re: So here it is one year later... > > > > On Thu, 27 Jan 2005, Gordon Fecyk wrote: > > > > > ...since the first rumblings of talking about a working > group, and there's > > been no press on MARID since the breakup of said working > group. No press > > from Microsoft, no press from the SPF crowd, no press from anyone. > > The working group broke up because of unresolvable technical problems. Get specific Dean, the unresolvable technical issues was the the PRA is broken, NOT SPF. So it is SenderID's PRA component not its SPF component that caused the technical failure. And the senderid venture was doomed to failure anyway because of the M$ IPR crap. > > > And no instructions included on how to compile, install, or > use what little > > software is available out there. Except for the few commercial (and > > expensive) offerings by GFi. > > If you aren't a developer of SPF, probably you shouldn't be using SPF. Wrong again. And the proof is that there are many domains that implement SPF, successfully. > > > What gives? Has the whole world lost complete interest in > stopping spam? Is > > spyware really the next big threat to the Internet that the > US Congress is > > looking at legislation for it but not bothering with spam anymore? > > No, the world has just realized that SPF doesn't work, and won't stop > spam, nor stop forgery. SPF never pretended to stop spam. It does prevent forgery, it does not prevent phishing, but then no technical solution will ever solve phishing as long as MUA's like Outlook show "pretty names" for everything, suppressing the try underlying identities of everything from email addresses to attachment types. > In its present form, SPF does nothing except > create more opportunities for email abuse, and promotes spam and email > abuse. Most people are interested in things that work. Fewer are > interested in making things worse. I cannot see how you come to that conclusion, (especially not on your lack of facts you presented). It does however well illustrate that there was/is an effort to scuttle SPF. Mostly by those with alternative products. Which is interesting, because if SPF was not a threat to the alternative products, they wouldn't try to scuttle SPF. Terry Fielder > > --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 Jan 27 22:45:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00122 for ; Thu, 27 Jan 2005 22:45:01 -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 j0S3Je2o084284; Thu, 27 Jan 2005 19:19: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 j0S3Jef1084283; Thu, 27 Jan 2005 19:19:40 -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 j0S3JdnR084276 for ; Thu, 27 Jan 2005 19:19:39 -0800 (PST) (envelope-from dean@av8.com) Received: from sr22.av8.net (sr22.av8.net [198.3.136.5]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id j0S3Jbhj027493 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 27 Jan 2005 22:19:37 -0500 Date: Thu, 27 Jan 2005 22:19:36 -0500 (EST) From: Dean Anderson X-X-Sender: dean@sr22.av8.net To: terry@ashtonwoodshomes.com cc: "'Gordon Fecyk'" , "'IETF MXCOMP (E-mail)'" Subject: RE: So here it is one year later... In-Reply-To: <00cb01c504de$27d8d620$2766f30a@development.greatgulfhomes.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 Thu, 27 Jan 2005 terry@ashtonwoodshomes.com wrote: > > -----Original Message----- > > From: owner-ietf-mxcomp@mail.imc.org > > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Dean Anderson > > Sent: Thursday, January 27, 2005 8:48 PM > > To: Gordon Fecyk > > Cc: IETF MXCOMP (E-mail) > > Subject: Re: So here it is one year later... > > > > > > > > On Thu, 27 Jan 2005, Gordon Fecyk wrote: > > > > > > > > ...since the first rumblings of talking about a working > > group, and there's > > > been no press on MARID since the breakup of said working > > group. No press > > > from Microsoft, no press from the SPF crowd, no press from anyone. > > > > The working group broke up because of unresolvable technical problems. > > Get specific Dean, the unresolvable technical issues was the the PRA is > broken, NOT SPF. So it is SenderID's PRA component not its SPF > component that caused the technical failure. That was _a_ problem. It wasn't the only problem. > And the senderid venture was doomed to failure anyway because of the M$ IPR crap. I agree the IPR crap was a bad thing. (I am the president of the LPF, after all). However, I don't think it doomed standardization to failure. The IETF has standardized RFCs with patented algorithms before. People made an informed choice, and decided that anti-spam technology is something that needs to be pervasive, free, and unencumbered. This has to be a major concern for the privateers interested "making a fortune in anti-spam" > > > And no instructions included on how to compile, install, or > > use what little > > > software is available out there. Except for the few commercial (and > > > expensive) offerings by GFi. > > > > If you aren't a developer of SPF, probably you shouldn't be using SPF. > > Wrong again. And the proof is that there are many domains that implement SPF, successfully. Most them are spammers. > > > What gives? Has the whole world lost complete interest in > > stopping spam? Is > > > spyware really the next big threat to the Internet that the > > US Congress is > > > looking at legislation for it but not bothering with spam anymore? > > > > No, the world has just realized that SPF doesn't work, and won't stop > > spam, nor stop forgery. > > SPF never pretended to stop spam. That isn't what Meng Weng said it Linux World. He said it would end spam. There are many other similar articles. Indeed, Microsoft also announced it would "end spam". > It does prevent forgery, Demonstrably, it does not. Excluding DNS spoofing, which is also trivial, one only needs an account at the same ISP as the forgery target. Many ISPs will not use SPF because of the DOS vulnerabilities, and unless everyone use SPF, it will not stop forgery, even given an assumption that every domain has a unique IP (which isn't a realistic assumption) > it does not prevent phishing, but then no technical solution will ever > solve phishing as long as MUA's like Outlook show "pretty names" for > everything, suppressing the try underlying identities of everything from > email addresses to attachment types. I didn't hear anyone say it would prevent phishing. Phishing is only tangentially related to forgery, anyway. Even if you could stop forgery, it would not alter phishing. > > In its present form, SPF does nothing except create more opportunities > > for email abuse, and promotes spam and email abuse. Most people are > > interested in things that work. Fewer are interested in making things > > worse. > > I cannot see how you come to that conclusion, (especially not on your > lack of facts you presented). Facts were already presented. The working group dissolved. Look at the IETF-MXCOMP archives. About 15 different critical, insurmountable problems were listed by me and others. > It does however well illustrate that there was/is an effort to scuttle > SPF. Mostly by those with alternative products. Which is interesting, > because if SPF was not a threat to the alternative products, they > wouldn't try to scuttle SPF. None of the people speaking about SPF problems have alternative products. Some of the people in favor of SPF however have significant investments in products, or have interests in its other properties, such as preventing email outsourcing by binding together email and access. AOL, MSN, etc for example, have interests in the latter. The SPF steamroller attempts to move on anyway. -- 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 Jan 27 22:45:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00141 for ; Thu, 27 Jan 2005 22:45: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 j0S2K2Yb080039; Thu, 27 Jan 2005 18:20: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 j0S2K2G2080038; Thu, 27 Jan 2005 18:20:02 -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 j0S2JTIH079991 for ; Thu, 27 Jan 2005 18:19:38 -0800 (PST) (envelope-from dean@av8.com) Received: from sr22.av8.net (sr22.av8.net [198.3.136.5]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id j0S2JHfr026315 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 27 Jan 2005 21:19:18 -0500 Date: Thu, 27 Jan 2005 21:19:17 -0500 (EST) From: Dean Anderson X-X-Sender: dean@sr22.av8.net To: "william(at)elan.net" cc: Arnt Gulbrandsen , Subject: Re: Abusive blacklist In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 11 Jan 2005, william(at)elan.net wrote: > On Tue, 11 Jan 2005, Arnt Gulbrandsen wrote: > > > Dean Anderson schrieb: > > > Terry, you are using an abusive "blacklist". SORBS, like ORBS, has no > > > qualms about lying about those they don't like. > > > > > > In our case, they don't like the fact that I revealed their secret > > > spam support operations. (They scan for open relays and then give > > > that information to abusers.) > > > > Do you mean that they give the information to the general public, > > abusers included, or do you mean something else? > > I think Dean meant that they scanned for open relays and compiled blacklist > and made that blacklist available for general public including by zone > transfer (i.e. abuser could easily get entire list). I thought it might have been unintentional leakage back in 1999. But I don't think it was unintentional anymore, for a number of reasons. On several occassions, open relay abusers were tracked back to open relay "anti-spammers". In one case, a particularly persistent abuser was fired from his job as an abuse desk person at a large ISP. He posted his diatribe to spam-l, blaming me for his termination. Even after pointing out their contibution to open relay abuse, Open relay blacklists made no attempt to limit access to information Also, no genuine commercial spammers were ever found abusing open relays. Open relay abuse was always nonsense: it wasn't genuinely commercial. And the final clincher is that open relay abuse dropped off to almost nothing after the open relay blacklists closed. If people not associated with the blacklists were doing to the abuse, they would have found other sources. The abusers quit the same time the blacklists quit. > That is not an issue any more as almost nobody runs open relay any more > and abusers have moved to other ways to distribute spam Actually, there are just as many or more open relays as there has ever been. The change was that the open relay blacklists have shutdown. The decline of open relay abuse correlates with the shutdown of those blacklists. From owner-ietf-mxcomp@mail.imc.org Thu Jan 27 22:47:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00328 for ; Thu, 27 Jan 2005 22:47:01 -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 j0S3PrRW084870; Thu, 27 Jan 2005 19:25:53 -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 j0S3Prm5084869; Thu, 27 Jan 2005 19:25:53 -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 j0S3PpXp084863 for ; Thu, 27 Jan 2005 19:25:52 -0800 (PST) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CuMlb-0002Zx-00 for ; Fri, 28 Jan 2005 04:25:51 +0100 Received: from 212.82.251.137 ([212.82.251.137]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 28 Jan 2005 04:25:51 +0100 Received: from nobody by 212.82.251.137 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 28 Jan 2005 04:25:51 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: So here it is one year later... Date: Fri, 28 Jan 2005 04:20:50 +0100 Organization: Lines: 59 Message-ID: <41F9AF92.717D@xyzzy.claranet.de> References: <700EEF5641B7E247AC1C9B82C05D125D055536@srv1.pan-am.ca> <41F942E4.4E18@xyzzy.claranet.de> <1106872082.6443.96.camel@SJC-Office-DHCP-156.mail-abuse.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.137 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: > pobox.com still has the slogan: > Sender Policy Framework, an essential part of Sender ID. Yes, the pobox site is not exactly up to date, that's AFAIK on the "todo" list of the new council. The new SPF draft is more important. > it continues to indicate the current SPF draft is: > http://www.ozonehouse.com/mark/spf/draft-lentczner-spf-00.txt Meng is one of the 5 SPF council members, they all agree that the new draft is _the_ draft. He's also one of the 2 authors. Mark had no time for this project after draft-lentczner-spf-00, otherwise there'd be probably three authors of the new draft, if that's allowed by the IETF and supported by xml2rfc. [Sender-ID position] > Quote from this faction: The majority fraction, if you insist on these political terms. counts 129 signatures. The SPF council was elected by 161 voters. Not exactly the same constituency, but roughly the same group of people. Finding a better text supported by almost all SPF "fans" is (or was) also on the "todo" list of the new council. > applying a record against different algorithms than that > intended when published is inherently deleterious Indeed. > Once again the algorithm changes and still this draft uses > the same labels and record identifiers? Classic. This "new" draft is technically nearer to the last pre-MARID "old" draft than draft-lentczner-spf-00 was. The latter was a rather quick hack salvaging all syntax improvements found here (= mxcomp) after MARID was killed and the old draft expired. The "new" draft kept these syntactical improvements, removed some oddities with the handling of errors, and added all things from the old draft forgotten in draft-lentczer-spf-00. There are almost no semantical differences between "old" and "new". Some of the minor differences between lentczner and new / old were simply errors, e.g. lentczer would FAIL for a MAIL FROM domain literal. While that might be seen as a feature it was a case of "receiver policy" and not "sender policy", and the new draft fixed it (back to the state of the old draft). Only side effects of the MARID disaster, no SPF problem, no new algorithm, no differences for existing policies. Only a better error handling and more restrictive limits for DNS queries, no substantial changes. Bye, Frank From owner-ietf-mxcomp@mail.imc.org Fri Jan 28 03:27:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06695 for ; Fri, 28 Jan 2005 03:27: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 j0S7cmkN030321; Thu, 27 Jan 2005 23:38: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 j0S7cmTK030320; Thu, 27 Jan 2005 23:38:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0S7cl1R030311 for ; Thu, 27 Jan 2005 23:38:47 -0800 (PST) (envelope-from dotis@mail-abuse.org) Received: from SJC-Office-DHCP-156.Mail-Abuse.ORG (SJC-Office-DHCP-156.Mail-Abuse.ORG [168.61.10.156]) by harry.mail-abuse.org (Postfix) with ESMTP id D84BA414E2; Thu, 27 Jan 2005 23:11:16 -0800 (PST) Subject: Re: So here it is one year later... From: Douglas Otis To: Frank Ellermann Cc: ietf-mxcomp@imc.org In-Reply-To: <41F9AF92.717D@xyzzy.claranet.de> References: <700EEF5641B7E247AC1C9B82C05D125D055536@srv1.pan-am.ca> <41F942E4.4E18@xyzzy.claranet.de> <1106872082.6443.96.camel@SJC-Office-DHCP-156.mail-abuse.org> <41F9AF92.717D@xyzzy.claranet.de> Content-Type: text/plain Date: Thu, 27 Jan 2005 23:11:05 -0800 Message-Id: <1106896265.11035.66.camel@SJC-Office-DHCP-156.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2005-01-28 at 04:20 +0100, Frank Ellermann wrote: > Douglas Otis wrote: > > applying a record against different algorithms than that > > intended when published is inherently deleterious > > Indeed. > > > Once again the algorithm changes and still this draft uses > > the same labels and record identifiers? Classic. > > This "new" draft is technically nearer to the last pre-MARID > "old" draft than draft-lentczner-spf-00 was. The latter was a > rather quick hack salvaging all syntax improvements found here > (= mxcomp) after MARID was killed and the old draft expired. This draft is attempting to make significant algorithmic changes to the initial draft, as well as how these records are used. Some examples: SPF clients MAY check the "HELO" identity by calling the check_host() function (Section 4) with the "HELO" identity as the . If the HELO test returns a "fail", the overall result for the SMTP session is "fail", and there is no need to test the "MAIL FROM" identity. A test against HELO that goes from unknown, to not tested, to fail? This a change in algorithm, as is the hunt for alternative records, where a pass may not be based upon address compliance. One wonders how macros are applied when the same check_host routine is recycled. An SPF record published at the zone cut for the domain will be used as a default for all subdomains within the zone (See Section 4.5.) Domain owners SHOULD publish SPF records for hosts used for the HELO and MAIL FROM identities instead of using the zone cut default because the fallback requires additional DNS lookups. The zone cut default does reduce the need to publish SPF records for non-email related hosts, such as www.example.com. Again, another change in algorithm. This also means TXT RR placed at the zone apex may now be problematic as how it becomes applied and to which identity. If no matching records are returned for the , the SPF client MUST find the Zone Cut as defined in [RFC2181] section 6 and repeat the above steps. The 's zone origin is then searched for SPF records. If an SPF record is found at the zone origin, the is set to the zone origin as if a "redirect" modifier was executed. If no matching records are returned for either search, an SPF client MUST assume that the domain makes no SPF declarations. SPF processing MUST abort and return "None". Yet again another change in algorithm isn't it? This mechanism matches if is one of the MX hosts for a domain name. MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ] check_host() first performs an MX lookup on the . Then it performs an address lookup on each MX name returned. The is compared to each returned IP address. To prevent DoS attacks, a limit of 10 MX names MUST be enforced (see Section 10). If any address matches, the mechanism matches. A limit change is an algorithmic change that could not be possibly foreseen by earlier publishers. Who is responsible when their mail goes missing? Note regarding implicit MXes: If the has no MX records, check_host() MUST NOT pretend the target is its single MX, and MUST NOT default to an A lookup on the directly. This behavior breaks with the legacy "implicit MX" rule. See [RFC2821] Section 5. If such behavior is desired, the publisher should specify an "a" directive. Would this be yet another algorithm change? In pseudocode: sending-domain_names := ptr_lookup(sending-host_IP); if more than 10 sending-domain_names are found, use at most 10. for each name in (sending-domain_names) { IP_addresses := a_lookup(name); if the sending-domain_IP is one of the IP_addresses { validated-sending-domain_names += name; } } Yet another change to the algorithm that introduces a new limit. Pseudocode: for each name in (validated-sending-domain_names) { if name ends in , return match. if name is , return match. } return no-match. This mechanism matches if the is either an ancestor of a validated domain name, or if the and a validated domain name are the same. For example: "mail.example.com" is within the domain "example.com", but "mail.bad-example.com" is not. Note: Use of this mechanism is discouraged because it is slow, is not as reliable as other mechanisms in cases of DNS errors and it places a large burden on the arpa name servers. If used, proper PTR records must be in place for the domain's hosts and the "ptr" mechanism should be one of the last mechanisms checked. One wonders how this mechanism is to be discouraged? SPF implementations MUST limit the number of mechanism that do DNS lookups to at most 10, if this number is exceeded, a PermError MUST be returned. The mechanisms that count against this limit are "include", "a", "mx", "ptr", "exists" and the "redirect" modifier. The "all", "ip4" and "ip6" mechanisms do not require DNS lookups and therefore do not count against this limit. The "exp" modifier requires a DNS lookup, but it is not counted as it is used only in the case of errors. When evaluating the "mx" and "ptr" mechanisms, or the %{p} macro, there MUST be a limit of no more than 10 MX or PTR RRs looked up and checked. I would also describe this as an algorithmic change that could not have been anticipated by the publishers. And the following regarding forwarding: There are several possible ways that this authorization failure can be ameliorated. If the owner of the external mailbox wishes to trust the forwarding service, they can direct the external mailbox's MTA to skip such tests when the client host belongs to the forwarding service. Tests against some other identity may also be used to override the test against the "MAIL FROM" identity. For larger domains, it may not be possible to have a complete or accurate list of forwarding services used by the owners of the domain's mailboxes. In such cases, white lists of generally recognized forwarding services could be employed. Some other Identity? Generally recognized forwarding services? Would this open the door for abusing the typical alma mater? This is a mess. This draft at long last recognizes wildcard labels are a problem. Why not also recognize a need to _change_ revisions when algorithms change and the need for a standardized prefix rather than a record tag? These are rather significant changes being made, why suggest otherwise? -Doug From owner-ietf-mxcomp@mail.imc.org Fri Jan 28 08:32:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28983 for ; Fri, 28 Jan 2005 08:32: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 j0SBiwsT008968; Fri, 28 Jan 2005 03:44: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 j0SBiwfI008967; Fri, 28 Jan 2005 03:44:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sendmail.metro.cx (sonolo.xs4all.nl [80.126.206.91]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0SBip3b008884 for ; Fri, 28 Jan 2005 03:44:57 -0800 (PST) (envelope-from gmc@metro.cx) Received: from dave.dh.sono (dave.dh.sono [10.1.2.5]) by sendmail.metro.cx (8.13.1/8.13.1) with ESMTP id j0SBi6m1066019; Fri, 28 Jan 2005 11:44:06 GMT Received-SPF: none (sendmail.metro.cx: 10.1.2.5 is neither permitted nor denied by domain of metro.cx>) client-ip=10.1.2.5; envelope-from=; helo=dave.dh.sono; Received: from dave.dh.sono (localhost [127.0.0.1]) by dave.dh.sono (8.13.1/8.12.9) with ESMTP id j0SBi56E004730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Jan 2005 12:44:05 +0100 Received: (from gmc@localhost) by dave.dh.sono (8.13.1/8.13.1/Submit) id j0SBi3BY004729; Fri, 28 Jan 2005 12:44:03 +0100 X-Authentication-Warning: dave.dh.sono: gmc set sender to gmc@metro.cx using -f Date: Fri, 28 Jan 2005 12:44:03 +0100 From: gmc@metro.cx To: Dean Anderson Cc: terry@ashtonwoodshomes.com, "'Gordon Fecyk'" , "'IETF MXCOMP (E-mail)'" Subject: Re: So here it is one year later... Message-ID: <20050128114403.GA4113@metro.cx> References: <00cb01c504de$27d8d620$2766f30a@development.greatgulfhomes.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-Key: http://www.metro.cx/pubkey-gmc.asc User-Agent: Mutt/1.5.6i X-Helo-Milter-Helo: dave.dh.sono X-Helo-Milter-Hostname: dave.dh.sono X-Helo-Milter-Ip: 10.1.2.5 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Jan 27, 2005 at 10:19:36PM -0500, Dean Anderson wrote: > On Thu, 27 Jan 2005 terry@ashtonwoodshomes.com wrote: > > Wrong again. And the proof is that there are many domains that implement SPF, successfully. > > Most them are spammers. May we see some proof of that please? And with proof i don't mean that report that is by now almost a year old and which was found to be incorrect a while ago. I don't have proof of the opposite, but i do seem to experience that many non-spammers are implementing spf (i'm saying this based on the requests the spf 'tech support team' gets in and activity on spf mailing lists). Koen -- K.F.J. Martens, Sonologic, http://www.sonologic.nl/ Networking, embedded systems, unix expertise, artificial intelligence. Public PGP key: http://www.metro.cx/pubkey-gmc.asc Wondering about the funny attachment your mail program can't read? Visit http://www.openpgp.org/ From owner-ietf-mxcomp@mail.imc.org Fri Jan 28 11:10:46 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13446 for ; Fri, 28 Jan 2005 11:10: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 j0SFXqhM061236; Fri, 28 Jan 2005 07:33: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 j0SFXqKs061235; Fri, 28 Jan 2005 07:33:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gfiservers.gfi.com (gfiservers.gfi.com [69.20.55.130]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0SFXojv061216 for ; Fri, 28 Jan 2005 07:33:51 -0800 (PST) (envelope-from gmc@metro.cx) Received: from server7.gfi.com ([10.236.6.9]) by gfiservers.gfi.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Jan 2005 16:37:07 +0100 Received: from mail pickup service by server7.gfi.com with Microsoft SMTPSVC; Fri, 28 Jan 2005 16:18:12 +0100 Received: from above.proper.com ([208.184.76.39]) by server7.gfi.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Jan 2005 14:11:28 +0100 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 j0SBiwsT008968; Fri, 28 Jan 2005 03:44: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 j0SBiwfI008967; Fri, 28 Jan 2005 03:44:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sendmail.metro.cx (sonolo.xs4all.nl [80.126.206.91]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0SBip3b008884 for ; Fri, 28 Jan 2005 03:44:57 -0800 (PST) (envelope-from gmc@metro.cx) Received: from dave.dh.sono (dave.dh.sono [10.1.2.5]) by sendmail.metro.cx (8.13.1/8.13.1) with ESMTP id j0SBi6m1066019; Fri, 28 Jan 2005 11:44:06 GMT Received-SPF: none (sendmail.metro.cx: 10.1.2.5 is neither permitted nor denied by domain of metro.cx>) client-ip=10.1.2.5; envelope-from=; helo=dave.dh.sono; Received: from dave.dh.sono (localhost [127.0.0.1]) by dave.dh.sono (8.13.1/8.12.9) with ESMTP id j0SBi56E004730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Jan 2005 12:44:05 +0100 Received: (from gmc@localhost) by dave.dh.sono (8.13.1/8.13.1/Submit) id j0SBi3BY004729; Fri, 28 Jan 2005 12:44:03 +0100 X-Authentication-Warning: dave.dh.sono: gmc set sender to gmc@metro.cx using -f Date: Fri, 28 Jan 2005 12:44:03 +0100 From: gmc@metro.cx To: Dean Anderson Cc: terry@ashtonwoodshomes.com, "'Gordon Fecyk'" , "'IETF MXCOMP (E-mail)'" Subject: Re: So here it is one year later... Message-ID: <20050128114403.GA4113@metro.cx> References: <00cb01c504de$27d8d620$2766f30a@development.greatgulfhomes.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-Key: http://www.metro.cx/pubkey-gmc.asc User-Agent: Mutt/1.5.6i X-Helo-Milter-Helo: dave.dh.sono X-Helo-Milter-Hostname: dave.dh.sono X-Helo-Milter-Ip: 10.1.2.5 List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 28 Jan 2005 13:11:28.0251 (UTC) FILETIME=[E07DCCB0:01C5053A] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Jan 27, 2005 at 10:19:36PM -0500, Dean Anderson wrote: > On Thu, 27 Jan 2005 terry@ashtonwoodshomes.com wrote: > > Wrong again. And the proof is that there are many domains that implement SPF, successfully. > > Most them are spammers. May we see some proof of that please? And with proof i don't mean that report that is by now almost a year old and which was found to be incorrect a while ago. I don't have proof of the opposite, but i do seem to experience that many non-spammers are implementing spf (i'm saying this based on the requests the spf 'tech support team' gets in and activity on spf mailing lists). Koen -- K.F.J. Martens, Sonologic, http://www.sonologic.nl/ Networking, embedded systems, unix expertise, artificial intelligence. Public PGP key: http://www.metro.cx/pubkey-gmc.asc Wondering about the funny attachment your mail program can't read? Visit http://www.openpgp.org/ From owner-ietf-mxcomp@mail.imc.org Fri Jan 28 12:13:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19723 for ; Fri, 28 Jan 2005 12:13:45 -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 j0SGYkpp065915; Fri, 28 Jan 2005 08:34: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 j0SGYkwv065914; Fri, 28 Jan 2005 08:34: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 j0SGYj1G065907 for ; Fri, 28 Jan 2005 08:34:46 -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 j0SGYeL1009865 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 28 Jan 2005 11:34:43 -0500 Date: Fri, 28 Jan 2005 11:34:39 -0500 (EST) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: gmc@metro.cx cc: terry@ashtonwoodshomes.com, "'Gordon Fecyk'" , "'IETF MXCOMP (E-mail)'" Subject: Re: So here it is one year later... In-Reply-To: <20050128114403.GA4113@metro.cx> 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: I don't do the usage tracking. It was reported on the mxcomp and other lists. I've never heard anyone dispute it before. I'd have to dig through my mail archives to find the reports, but my recollection is that they came from people doing the usage tracking. While I'm not disputing that there are non-spammers using SPF, the spammers rushed to it for fairly obvious reasons. Anything that even suggests that mail might be accepted or subjected to less checks is definitely a big win for spammers. --Dean On Fri, 28 Jan 2005 gmc@metro.cx wrote: > > On Thu, Jan 27, 2005 at 10:19:36PM -0500, Dean Anderson wrote: > > On Thu, 27 Jan 2005 terry@ashtonwoodshomes.com wrote: > > > Wrong again. And the proof is that there are many domains that implement SPF, successfully. > > > > Most them are spammers. > > May we see some proof of that please? And with proof i don't mean that > report that is by now almost a year old and which was found to be > incorrect a while ago. > > I don't have proof of the opposite, but i do seem to experience that > many non-spammers are implementing spf (i'm saying this based on the > requests the spf 'tech support team' gets in and activity on spf mailing > lists). > > Koen > > -- 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 Jan 28 13:43:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28526 for ; Fri, 28 Jan 2005 13:43:31 -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 j0SI1qZs072911; Fri, 28 Jan 2005 10:01: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 j0SI1qb9072910; Fri, 28 Jan 2005 10:01:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from amgod.boxhost.net (dogma.boxhost.net [195.218.96.101]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0SI1o5a072881 for ; Fri, 28 Jan 2005 10:01:50 -0800 (PST) (envelope-from jm@jmason.org) Received: from radish.jmason.org (localhost [127.0.0.1]) by amgod.boxhost.net (Postfix) with ESMTP id E2192310400; Fri, 28 Jan 2005 18:04:28 +0000 (GMT) Received: from jmason.org (localhost [127.0.0.1]) by radish.jmason.org (Postfix) with ESMTP id 9F91159001E; Fri, 28 Jan 2005 10:01:19 -0800 (PST) To: gmc@metro.cx Cc: Dean Anderson , terry@ashtonwoodshomes.com, "'Gordon Fecyk'" , "'IETF MXCOMP (E-mail)'" Subject: Re: So here it is one year later... In-Reply-To: <20050128114403.GA4113@metro.cx> From: jm@jmason.org (Justin Mason) X-Gpg-Key-Fingerprint: 1368 71CE 3627 9CD3 FA1B 0B63 3091 7972 298B C7D0 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 . Date: Fri, 28 Jan 2005 10:01:19 -0800 Message-Id: <20050128180119.9F91159001E@radish.jmason.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 gmc@metro.cx writes: > On Thu, Jan 27, 2005 at 10:19:36PM -0500, Dean Anderson wrote: > > On Thu, 27 Jan 2005 terry@ashtonwoodshomes.com wrote: > > > Wrong again. And the proof is that there are many domains that implement SPF, successfully. > > > > Most them are spammers. > > May we see some proof of that please? And with proof i don't mean that > report that is by now almost a year old and which was found to be > incorrect a while ago. FWIW, here's the results of a check of 54725 spams and 6680 nonspam mails, from SpamAssassin's weekly mass-check of network rules (at http://www.pathname.com/~corpus/NET.age ). All these messages were received less than 1 month ago, and are taken from 5 people's hand-classified corpora. SPF records passing HELO strings: 4.98% of spam, 13.29% of ham SPF records passing the MAIL FROM: 3.72% spam, 18.90% of ham So it certainly looks like that statement is untrue. - --j. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Exmh CVS iD8DBQFB+n3vMJF5cimLx9ARArLTAJ4o+rkTSylsGguBszWvmDvggew+MQCeJFux UwoKM1L2LRp6aQ03oPyLPRI= =GulZ -----END PGP SIGNATURE----- From owner-ietf-mxcomp@mail.imc.org Fri Jan 28 13:44:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28609 for ; Fri, 28 Jan 2005 13:44: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 j0SI4bOF073035; Fri, 28 Jan 2005 10:04: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 j0SI4bTe073034; Fri, 28 Jan 2005 10:04:37 -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 j0SI4bUQ073023 for ; Fri, 28 Jan 2005 10:04:37 -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 j0SI4XJ7011508 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 28 Jan 2005 13:04:34 -0500 Date: Fri, 28 Jan 2005 13:04:33 -0500 (EST) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: ietf-mxcomp@imc.org Subject: Re: Abusive blacklist 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: Well, I see Terry is _still_ using SORBS, despite knowledge that it is a revenge list. I guess that's his choice. But it raises the question of whether his interest in anti-spam is genuine. You can't associate with Court-proven liars using anti-spam for vendettas and remain credible. So, I'm just going to point out a few things. These are mostly things that I've been thinking about recently, relative to abusive blacklists and such. As the Judge said about Alan Brown and ORBS: http://www.iadl.org/ab/AB-Defamation-Domainz.html Indeed, the very same Alan Brown originated the claims that our IP addresses were hijacked on spam-l. This was picked up by Matthew Sullivan of SORBS. Paul Vixie is also discreditably associated with SORBS: he offered them "bulletproof" hosting after SORBS was booted from XO for AUP violations for the defamation of Av8 Internet and for threatening "mail bombing" (IE spamming). In another irony, Vixie doesn't have an AUP. (its ironic because Vixie demands that everyone have AUPs and enforce them. Except Vixie. And he has no problem associating with "mail bombers". Hmm.) Once you really dig into the spam problem, or rather the anti-spam community (certain parts anyway), its very frequently about vendetta's and privateering. One wonders who the spammers really are**. There are precious few people who are actually genuinely interested in spam problems and those people don't associate with the fakes and abusers. Anyway, most people don't want anything to do with SORBS after they find out about SORBS, and look up our listing. And few people use SORBS: Rarely a message blocked despite their attempt at blocking all of a /16 and all of a /21. That's a lot of mail to try to interfere with. Only the (temporarily) misled and the Brown/Sullivan/Vixie crowd use it. Well, Terry clearly has his eyes open about SORBS, and chooses to associate with the disingenuous, the liars*** (Court-proven even), and the dishonest, people who aren't really interested in spam problems. The people who are genuinely interested, don't associate with fakes. --Dean **The real spammers seem to mostly comply with CAN-SPAM. So who are the ones who don't comply with CAN-SPAM? Recall that CAN-SPAM doesn't ban spam, in fact, it explicitly legalizes spam, so long as spammers comply with certain practices. The DMA pushed it through, and its essentially the same as the IEMCC proposal. The spammers love it. The anti-spam community mostly hates it. But a lot of junk in my emailbox doesn't even comply at all. "Could it be ", (said in my best 'Michael-Moore-in-George-Bush-school-scene' voice), "that anti-spammers are sending this non-commercial, non-compliant spam, just like they abused open relays? Damn. It was them." One wonders who the criminally CAN-SPAM non-compliant really are. *** Nick Nicholas (former executive director of MAPS) wrote a manifesto about "The Truth through Lies" http://home.pacbell.net/nicnic/johnson.html Nicholas writes "Johnson's fictional treatment of this historical event suggests that, paradoxically, the road to truth is paved with lies." Uh huh. Right. But it explains a lot about that crowd. ---------- Forwarded message ---------- Date: Thu, 27 Jan 2005 22:19:42 -0500 From: Mail Delivery Subsystem To: dean@av8.com Subject: Returned mail: see transcript for details The original message was received at Thu, 27 Jan 2005 22:19:37 -0500 from sr22.av8.net [198.3.136.5] ----- The following addresses had permanent fatal errors ----- (reason: 553 5.3.0 ... Message from 130.105.36.66 rejected - see http://www.dnsbl.us.sorbs.net/cgi-bin/lookup?IP= 130.105.36.66) ----- Transcript of session follows ----- ... while talking to mail.ashtonwoodshomes.com.: >>> DATA <<< 553 5.3.0 ... Message from 130.105.36.66 rejected - see http://www.dnsbl.us.sorbs.net/cgi-bin/lookup?IP= 130.105.36.66 550 5.1.1 ... User unknown <<< 503 5.0.0 Need RCPT (recipient) From owner-ietf-mxcomp@mail.imc.org Fri Jan 28 14:47:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06425 for ; Fri, 28 Jan 2005 14:47: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 j0SJIHYm081037; Fri, 28 Jan 2005 11:18: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 j0SJIHUC081036; Fri, 28 Jan 2005 11:18:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.pan-am.ca (nspublic.pan-am.ca [205.200.6.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0SJIGY1081022 for ; Fri, 28 Jan 2005 11:18:17 -0800 (PST) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [So... what gives?] RE: So here it is one year later... Date: Fri, 28 Jan 2005 13:18:11 -0600 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <700EEF5641B7E247AC1C9B82C05D125D055537@srv1.pan-am.ca> Thread-Topic: So here it is one year later... Thread-Index: AcUEhZj7F/gKX7rjTJOWTYJT9vVs4wA5vXwA From: "Gordon Fecyk" To: "IETF MXCOMP (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j0SJIHY1081030 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit You've all been soooo busy over at The SPF Council [tm, r, reg, tinc, tinlc, etc] that there's still no published, or working, support for SPF in: Exchange Notes Groupwise Hotmail Yahoo mail Rogers.com (Blackberry) Messagelabs Yes, Exchange. All of the links from The SPF Council [tm, r, reg, tinc, tinlc, etc] home page directing visitors to Exchange implementations are BROKEN. There are no links at all for Notes. None for Groupwise. There's no media announcements (nothing in mainstream IT media anyway, not even Slashdot!) since mid-2004 when the working group dismantled. Not even from Microsoft about their precious Sender ID [tm, r, reg, bg, iluvbunny, etc] released anything - no news, no betas, nothing. As far as Joe Sixpack cares, you all disappeared from the face of the net six months ago. And Joe Sixpack's the one whining about falsified e-mail. And guess what Messagelabs announced: They're turning on MAPS DUL blocking and deleting WITHOUT THEIR CUSTOMERS' PERMSSION. I guess Joe Sixpack really knows what works. Don't ask me either. I'm trying to earn a living helping people with real computing problems - and spam isn't one of them - so, like Joe Sixpack before me, I don't have time to write code. -- PGP key (0x0AFA039E): Sometimes it's hard to tell where the game ends and where reality bites, er, begins. From owner-ietf-mxcomp@mail.imc.org Fri Jan 28 14:51:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06677 for ; Fri, 28 Jan 2005 14:51:09 -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 j0SJLNdD081479; Fri, 28 Jan 2005 11:21: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 j0SJLNF2081478; Fri, 28 Jan 2005 11:21:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (schlitt.net [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0SJLMJu081463 for ; Fri, 28 Jan 2005 11:21:22 -0800 (PST) (envelope-from wayne@schlitt.net) Received: from footbone.schlitt.net ([206.222.212.237] helo=schlitt.net) by backbone.midwestcs.com with esmtp (Exim 4.43) id 1Cubfr-0003tA-Kc for ietf-mxcomp@imc.org; Fri, 28 Jan 2005 13:21:19 -0600 To: "IETF MARID WG" References: <700EEF5641B7E247AC1C9B82C05D125D055536@srv1.pan-am.ca> <41F942E4.4E18@xyzzy.claranet.de> <1106872082.6443.96.camel@SJC-Office-DHCP-156.mail-abuse.org> <41F9AF92.717D@xyzzy.claranet.de> <1106896265.11035.66.camel@SJC-Office-DHCP-156.mail-abuse.org> From: wayne Mail-Copies-To: nobody Reply-To: "IETF MARID WG" Date: Fri, 28 Jan 2005 13:20:51 -0600 In-Reply-To: <1106896265.11035.66.camel@SJC-Office-DHCP-156.mail-abuse.org> (Douglas Otis's message of "Thu, 27 Jan 2005 23:11:05 -0800") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Corporate Culture, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of schlitt.net designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@schlitt.net; helo=schlitt.net; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: So here it is one year later... Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on backbone.midwestcs.com X-Spam-Status: No, score=-5.1 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.1 (built Tue, 17 Aug 2004 11:06:07 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The MARID list has become a cesspool of misinformation and trolls. For that reason, I have not been posting to it and I would encourage others to ignore the "information" posted here. The following post by Doug Otis is an prime example of just how bad most posts here are. In <1106896265.11035.66.camel@SJC-Office-DHCP-156.mail-abuse.org> Douglas Otis writes: > On Fri, 2005-01-28 at 04:20 +0100, Frank Ellermann wrote: >> Douglas Otis wrote: > >> > applying a record against different algorithms than that >> > intended when published is inherently deleterious >> >> Indeed. >> >> > Once again the algorithm changes and still this draft uses >> > the same labels and record identifiers? Classic. >> >> This "new" draft is technically nearer to the last pre-MARID >> "old" draft than draft-lentczner-spf-00 was. The latter was a >> rather quick hack salvaging all syntax improvements found here >> (= mxcomp) after MARID was killed and the old draft expired. > > This draft is attempting to make significant algorithmic changes to the > initial draft, as well as how these records are used. Discussions about the SPF specification are best discussed on the SPF-discuss mailing list. > Some examples: > > SPF clients MAY check the "HELO" identity by calling the check_host() > function (Section 4) with the "HELO" identity as the . If > the HELO test returns a "fail", the overall result for the SMTP > session is "fail", and there is no need to test the "MAIL FROM" > identity. > > A test against HELO that goes from unknown, to not tested, to fail? > This a change in algorithm, as is the hunt for alternative records, > where a pass may not be based upon address compliance. One wonders how > macros are applied when the same check_host routine is recycled. This is not an example of changing semantics and/or algorithms. As pointed out by Frank, this is consistent with the pre-MARID specification of SPF. The problem is not that draft-schlitt-spf-00 changed things back, but that the IETF, via the MARID WG, allowed it to change in the first place. > An SPF record published at the zone cut for the domain will be used > as a default for all subdomains within the zone (See Section 4.5.) > Domain owners SHOULD publish SPF records for hosts used for the HELO > and MAIL FROM identities instead of using the zone cut default > because the fallback requires additional DNS lookups. The zone cut > default does reduce the need to publish SPF records for non-email > related hosts, such as www.example.com. > > Again, another change in algorithm. This also means TXT RR placed at > the zone apex may now be problematic as how it becomes applied and to > which identity. This is not an example of changing semantics and/or algorithms. As pointed out by Frank, this is consistent with the pre-MARID specification of SPF. The problem is not that draft-schlitt-spf-00 changed things back, but that the IETF, via the MARID WG, allowed it to change in the first place. > If no matching records are returned for the , the SPF client > MUST find the Zone Cut as defined in [RFC2181] section 6 and repeat > the above steps. The 's zone origin is then searched for SPF > records. If an SPF record is found at the zone origin, the > is set to the zone origin as if a "redirect" modifier was executed. > > If no matching records are returned for either search, an SPF client > MUST assume that the domain makes no SPF declarations. SPF > processing MUST abort and return "None". > > Yet again another change in algorithm isn't it? This is not an example of changing semantics and/or algorithms. As pointed out by Frank, this is consistent with the pre-MARID specification of SPF. The problem is not that draft-schlitt-spf-00 changed things back, but that the IETF, via the MARID WG, allowed it to change in the first place. > This mechanism matches if is one of the MX hosts for a domain > name. > > MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ] > > check_host() first performs an MX lookup on the . Then > it performs an address lookup on each MX name returned. The is > compared to each returned IP address. To prevent DoS attacks, a > limit of 10 MX names MUST be enforced (see Section 10). If any > address matches, the mechanism matches. > > A limit change is an algorithmic change that could not be possibly > foreseen by earlier publishers. Who is responsible when their mail goes > missing? While this is, indeed, a change from the last pre-MARID SPF spec, this limit has been in place in my libspf2 implemenation since long before MARID existed, and hence is an existing practice. As discussed *many* times on SPF-discuss, I can not find *any* legitimate emailers who have come close to this limit. This change only effects abusers and misconfigured systems. > Note regarding implicit MXes: If the has no MX records, > check_host() MUST NOT pretend the target is its single MX, and MUST > NOT default to an A lookup on the directly. This > behavior breaks with the legacy "implicit MX" rule. See [RFC2821] > Section 5. If such behavior is desired, the publisher should specify > an "a" directive. > > Would this be yet another algorithm change? No. This has *always* been the case. > In pseudocode: > > sending-domain_names := ptr_lookup(sending-host_IP); > if more than 10 sending-domain_names are found, use at most 10. > for each name in (sending-domain_names) { > IP_addresses := a_lookup(name); > if the sending-domain_IP is one of the IP_addresses { > validated-sending-domain_names += name; > } > } > > Yet another change to the algorithm that introduces a new limit. While this is, indeed, a change from the last pre-MARID SPF spec, this limit has been in place in my libspf2 implemenation since long before MARID existed, and hence is an existing practice. As discussed *many* times on SPF-discuss, I can not find *any* legitimate emailers who have come close to this limit. This change only effects abusers and misconfigured systems. > Pseudocode: > > for each name in (validated-sending-domain_names) { > if name ends in , return match. > if name is , return match. > } > return no-match. > > This mechanism matches if the is either an ancestor of > a validated domain name, or if the and a validated > domain name are the same. For example: "mail.example.com" is within > the domain "example.com", but "mail.bad-example.com" is not. > > Note: Use of this mechanism is discouraged because it is slow, is not > as reliable as other mechanisms in cases of DNS errors and it places > a large burden on the arpa name servers. If used, proper PTR records > must be in place for the domain's hosts and the "ptr" mechanism > should be one of the last mechanisms checked. > > One wonders how this mechanism is to be discouraged? By saying, in the spec "this mechanism is discouraged" and by having the various SPF wizards not generate it. > SPF implementations MUST limit the number of mechanism that do DNS > lookups to at most 10, if this number is exceeded, a PermError MUST > be returned. The mechanisms that count against this limit are > "include", "a", "mx", "ptr", "exists" and the "redirect" modifier. > The "all", "ip4" and "ip6" mechanisms do not require DNS lookups and > therefore do not count against this limit. The "exp" modifier > requires a DNS lookup, but it is not counted as it is used only in > the case of errors. > > When evaluating the "mx" and "ptr" mechanisms, or the %{p} macro, > there MUST be a limit of no more than 10 MX or PTR RRs looked up and > checked. > > I would also describe this as an algorithmic change that could not have > been anticipated by the publishers. While this is, indeed, a change from the last pre-MARID SPF spec, this limit has been in place in my libspf2 implemenation since long before MARID existed, and hence is an existing practice. As discussed *many* times on SPF-discuss, I can not find *any* legitimate emailers who have come close to this limit. This change only effects abusers and misconfigured systems. > And the following regarding > forwarding: > > There are several possible ways that this authorization failure can > be ameliorated. If the owner of the external mailbox wishes to trust > the forwarding service, they can direct the external mailbox's MTA to > skip such tests when the client host belongs to the forwarding > service. Tests against some other identity may also be used to > override the test against the "MAIL FROM" identity. > > For larger domains, it may not be possible to have a complete or > accurate list of forwarding services used by the owners of the > domain's mailboxes. In such cases, white lists of generally > recognized forwarding services could be employed. > > Some other Identity? Generally recognized forwarding services? Would > this open the door for abusing the typical alma mater? This is a mess. As noted in Section 9, this is is non-normative. If you don't agree with what is said, you are free to do anything you want. This is just for your information. > This draft at long last recognizes wildcard labels are a problem. Why > not also recognize a need to _change_ revisions when algorithms change > and the need for a standardized prefix rather than a record tag? These > are rather significant changes being made, why suggest otherwise? The section on wildcards was added as part of the MARID process and remained in the draft-schlitt-spf-00 version because it is useful. The changes to the algorithms that were added as part of the MARID process have been removed. Changes to the algorigtms from the pre-MARID SPF specs have all been implemented by at least one system and have been checked, via wide surveys, that they do not conflict the install base of legitimate SPF records. I find it very amusing that you are now complaining about the process limits being a change, since you have long complained about the lack of process limits in previous versions of the SPF spec. -wayne From owner-ietf-mxcomp@mail.imc.org Fri Jan 28 15:18:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09405 for ; Fri, 28 Jan 2005 15:18: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 j0SJs4W2085186; Fri, 28 Jan 2005 11:54: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 j0SJs4kR085185; Fri, 28 Jan 2005 11:54:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by above.proper.com (8.12.11/8.12.9) with SMTP id j0SJs3tk085168 for ; Fri, 28 Jan 2005 11:54:03 -0800 (PST) (envelope-from scott@kitterman.com) Received: (qmail 89073 invoked from network); 28 Jan 2005 19:53:59 -0000 Received: from unknown (HELO wsd865gbf) (unknown) by unknown with SMTP; 28 Jan 2005 19:53:59 -0000 X-pair-Authenticated: 64.32.194.73 From: "Scott Kitterman" To: "IETF MXCOMP \(E-mail\)" Subject: RE: [So... what gives?] RE: So here it is one year later... Date: Fri, 28 Jan 2005 14:54:01 -0500 Message-ID: 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 IMO, Build 9.0.6604 (9.0.2911.0) In-reply-to: <700EEF5641B7E247AC1C9B82C05D125D055537@srv1.pan-am.ca> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 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 Gordon Fecyk >Sent: Friday, January 28, 2005 2:18 PM >To: IETF MXCOMP (E-mail) >Subject: [So... what gives?] RE: So here it is one year later... > > > >You've all been soooo busy over at The SPF Council [tm, r, reg, >tinc, tinlc, >etc] that there's still no published, or working, support for SPF in: > >Exchange >Notes >Groupwise >Hotmail >Yahoo mail >Rogers.com (Blackberry) >Messagelabs > >Yes, Exchange. All of the links from The SPF Council [tm, r, reg, tinc, >tinlc, etc] home page directing visitors to Exchange implementations are >BROKEN. There are no links at all for Notes. None for Groupwise. > ... For Exchange, there is at least one commercial implementation available: http://www.gfi.com/mes/mesfeatures.htm Scott Kitterman From owner-ietf-mxcomp@mail.imc.org Fri Jan 28 15:18:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09474 for ; Fri, 28 Jan 2005 15:18: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 j0SJuqnI085449; Fri, 28 Jan 2005 11:56: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 j0SJuqS4085448; Fri, 28 Jan 2005 11:56: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 j0SJupRj085442 for ; Fri, 28 Jan 2005 11:56: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 j0SJulOI013594 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 28 Jan 2005 14:56:48 -0500 Date: Fri, 28 Jan 2005 14:56:46 -0500 (EST) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: Justin Mason cc: gmc@metro.cx, , "'Gordon Fecyk'" , "'IETF MXCOMP (E-mail)'" Subject: Re: So here it is one year later... In-Reply-To: <20050128180119.9F91159001E@radish.jmason.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, 28 Jan 2005, Justin Mason wrote: > > FWIW, here's the results of a check of 54725 spams and 6680 nonspam mails, > from SpamAssassin's weekly mass-check of network rules (at > http://www.pathname.com/~corpus/NET.age ). > > All these messages were received less than 1 month ago, and are taken from > 5 people's hand-classified corpora. > > SPF records passing HELO strings: 4.98% of spam, 13.29% of ham > SPF records passing the MAIL FROM: 3.72% spam, 18.90% of ham > > So it certainly looks like that statement is untrue. Err, no: OVERALL% SPAM% HAM% S/O RANK SCORE NAME:0-1 OVERALL% SPAM% HAM% S/O RANK SCORE NAME:1-3 OVERALL% SPAM% HAM% S/O RANK SCORE NAME:3-6 5.377 3.7259 18.9072 0.165 0.23 -0.00 SPF_PASS:0-1 1.361 0.9087 3.3508 0.213 0.25 -0.00 SPF_PASS:1-3 1.749 0.5116 18.4304 0.027 0.34 -0.00 SPF_PASS:3-6 As you see, spam + ham does not add up to overall. Its not clear what these statistics mean, nor how they were calculated. But your interpretation is clearly either wrong or at least not supported by the page. FYI, this is the original post: ---------- Forwarded message ---------- Date: Thu, 9 Sep 2004 15:18:42 +0200 From: Markus Stumpf To: ietf-mxcomp@vpnc.org Subject: SPF abused by spammers Justin Murdock posted this link on the qmail list: http://news.bbc.co.uk/1/hi/technology/3631350.stm "CipherTrust [...] found that 34% more spam is passing SPF checks than legitimate e-mail." \Maex -- SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0 Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299 "The security, stability and reliability of a computer system is reciprocally proportional to the amount of vacuity between the ears of the admin" --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 Jan 28 15:39:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11317 for ; Fri, 28 Jan 2005 15:39:57 -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 j0SKBBlK087071; Fri, 28 Jan 2005 12:11: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 j0SKBBln087070; Fri, 28 Jan 2005 12:11:11 -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 j0SKBAv7087064 for ; Fri, 28 Jan 2005 12:11:11 -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 j0SKB3nQ013870 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 28 Jan 2005 15:11:05 -0500 Date: Fri, 28 Jan 2005 15:10:57 -0500 (EST) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: Justin Mason cc: gmc@metro.cx, , "'Gordon Fecyk'" , "'IETF MXCOMP (E-mail)'" Subject: Re: So here it is one year later... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 28 Jan 2005, Dean Anderson wrote: > > As you see, spam + ham does not add up to overall. Its not clear what > these statistics mean, nor how they were calculated. But your > interpretation is clearly either wrong or at least not supported by the > page. Sorry to reply to my own post, but there is another point I forgot: when dealing with a very sample from a very small domain, that deals with a limited part of the internet, E.G. a domain with relatively few people who develop SPF, and who therefore exchange disproportionately more mail with other SPF users, then their email statistics on SPF usage will also be skewed. In other words, this is not a random sample. One needs to get better sample from someplace that doesn't particularly cater to SPF email users, and interacts more broadly with the internet. --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 Jan 28 15:41:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11463 for ; Fri, 28 Jan 2005 15:41: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 j0SKHF3Y087690; Fri, 28 Jan 2005 12:17: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 j0SKHFa8087689; Fri, 28 Jan 2005 12:17:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from amgod.boxhost.net (dogma.boxhost.net [195.218.96.101]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0SKHEVT087683 for ; Fri, 28 Jan 2005 12:17:14 -0800 (PST) (envelope-from jm@jmason.org) Received: from radish.jmason.org (localhost [127.0.0.1]) by amgod.boxhost.net (Postfix) with ESMTP id EC0F03100E6; Fri, 28 Jan 2005 20:20:16 +0000 (GMT) Received: from jmason.org (localhost [127.0.0.1]) by radish.jmason.org (Postfix) with ESMTP id 1121B59001E; Fri, 28 Jan 2005 12:17:07 -0800 (PST) To: Dean Anderson Cc: Justin Mason , gmc@metro.cx, terry@ashtonwoodshomes.com, "'Gordon Fecyk'" , "'IETF MXCOMP (E-mail)'" Subject: Re: So here it is one year later... In-Reply-To: From: jm@jmason.org (Justin Mason) X-Gpg-Key-Fingerprint: 1368 71CE 3627 9CD3 FA1B 0B63 3091 7972 298B C7D0 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 . Date: Fri, 28 Jan 2005 12:17:07 -0800 Message-Id: <20050128201707.1121B59001E@radish.jmason.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dean Anderson writes: > On Fri, 28 Jan 2005, Justin Mason wrote: > > > > > FWIW, here's the results of a check of 54725 spams and 6680 nonspam mails, > > from SpamAssassin's weekly mass-check of network rules (at > > http://www.pathname.com/~corpus/NET.age ). > > > > All these messages were received less than 1 month ago, and are taken from > > 5 people's hand-classified corpora. > > > > SPF records passing HELO strings: 4.98% of spam, 13.29% of ham > > SPF records passing the MAIL FROM: 3.72% spam, 18.90% of ham > > > > So it certainly looks like that statement is untrue. > > Err, no: > > OVERALL% SPAM% HAM% S/O RANK SCORE NAME:0-1 > OVERALL% SPAM% HAM% S/O RANK SCORE NAME:1-3 > OVERALL% SPAM% HAM% S/O RANK SCORE NAME:3-6 > > 5.377 3.7259 18.9072 0.165 0.23 -0.00 SPF_PASS:0-1 > 1.361 0.9087 3.3508 0.213 0.25 -0.00 SPF_PASS:1-3 > 1.749 0.5116 18.4304 0.027 0.34 -0.00 SPF_PASS:3-6 > > As you see, spam + ham does not add up to overall. Its not clear what > these statistics mean, nor how they were calculated. But your > interpretation is clearly either wrong or at least not supported by the > page. Actually, you're wrong there. This is SpamAssassin's "hit-frequencies" tool output. Those are percentages, not message counts, so simply summing SPAM%+HAM% will not add up to OVERALL%. Here's a quick walk through the pertinent parts. (I'm discarding the 1-3 and 3-6 month ranges -- those are old mails so that data isn't very useful for network tests -- and just concentrate on the 0-1 month range.) OVERALL% SPAM% HAM% S/O RANK SCORE NAME:0-1 61405 54725 6680 0.891 0.00 0.00 (all messages):0-1 This means that there were 61405 messages mass-checked in total, with 54725 spams, and 6680 "hams" (non-spam messages). 5.377 3.7259 18.9072 0.165 0.23 -0.00 SPF_PASS:0-1 looking at the SPAM% and HAM% columns, that means that 3.7259% of the spams checked had SPF_PASS, and 18.9072% of the hams. that means ((3.7259 / 100) * 54725) = 2038.998775 I'd suspect that rounding error means that 2039 spam messages passed the SPF check, so round to 2039. ((18.9072 / 100) * 6680) = 1263.00096 and 1263 hams passed SPF. Total those, and you get 3302 messages from the overall corpus passing SPF; to express that as a percentage of the total overall corpus, in other words "OVERALL%", you compute (3302 / 61405) * 100 = 5.377. If you have any more questions on the hit-frequencies format, I'll be happy to fill you in -- I wrote the tool in question ;) > FYI, this is the original post: > > ---------- Forwarded message ---------- > Date: Thu, 9 Sep 2004 15:18:42 +0200 > From: Markus Stumpf > To: ietf-mxcomp@vpnc.org > Subject: SPF abused by spammers > > Justin Murdock posted this link on the qmail list: > http://news.bbc.co.uk/1/hi/technology/3631350.stm > "CipherTrust [...] found that 34% more spam is passing SPF checks than > legitimate e-mail." Sure. But this was guaranteed to change over time, and vary depending on corpus composition. It's pretty radically different now, from where I and the other SpamAssassin corpus contributors are viewing it. - --j. > \Maex > > -- > SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0 > Research & Development | D-80807 Muenchen | Fax: +49 (89) > 32356-299 > "The security, stability and reliability of a computer system is > reciprocally > proportional to the amount of vacuity between the ears of the admin" > > --Dean -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Exmh CVS iD8DBQFB+p3CMJF5cimLx9ARAlLpAKCAOosS1dSm7hjSgzH0dzRTWNsaBwCgpY5Y lLmvE2U+4KdCyOXLXAdgYFY= =HChc -----END PGP SIGNATURE----- From owner-ietf-mxcomp@mail.imc.org Fri Jan 28 15:46:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11727 for ; Fri, 28 Jan 2005 15:46: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 j0SKLvjL088101; Fri, 28 Jan 2005 12:21:57 -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 j0SKLvnT088100; Fri, 28 Jan 2005 12:21:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from amgod.boxhost.net (dogma.boxhost.net [195.218.96.101]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0SKLuBW088094 for ; Fri, 28 Jan 2005 12:21:57 -0800 (PST) (envelope-from jm@jmason.org) Received: from radish.jmason.org (localhost [127.0.0.1]) by amgod.boxhost.net (Postfix) with ESMTP id B30843100E6; Fri, 28 Jan 2005 20:25:02 +0000 (GMT) Received: from jmason.org (localhost [127.0.0.1]) by radish.jmason.org (Postfix) with ESMTP id 13EE759001E; Fri, 28 Jan 2005 12:21:53 -0800 (PST) To: Dean Anderson Cc: Justin Mason , gmc@metro.cx, terry@ashtonwoodshomes.com, "'Gordon Fecyk'" , "'IETF MXCOMP (E-mail)'" Subject: Re: So here it is one year later... In-Reply-To: From: jm@jmason.org (Justin Mason) X-Gpg-Key-Fingerprint: 1368 71CE 3627 9CD3 FA1B 0B63 3091 7972 298B C7D0 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 . Date: Fri, 28 Jan 2005 12:21:53 -0800 Message-Id: <20050128202153.13EE759001E@radish.jmason.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dean Anderson writes: > On Fri, 28 Jan 2005, Dean Anderson wrote: > > > > As you see, spam + ham does not add up to overall. Its not clear what > > these statistics mean, nor how they were calculated. But your > > interpretation is clearly either wrong or at least not supported by the > > page. > > Sorry to reply to my own post, but there is another point I forgot: when > dealing with a very sample from a very small domain, that deals with a > limited part of the internet, E.G. a domain with relatively few people who > develop SPF, and who therefore exchange disproportionately more mail with > other SPF users, then their email statistics on SPF usage will also be > skewed. In other words, this is not a random sample. > > One needs to get better sample from someplace that doesn't particularly > cater to SPF email users, and interacts more broadly with the internet. FWIW, those figures come from contributors at 5 different sites. It's not just one domain. Some are not even spam filter developers. ;) Ciphertrust's figures are also biased -- their customers in turn will be a certain cross-section of email users, rather than "truly representative" of the internet at large. I don't think anyone has yet come up with a way to get a hand-classified sample that can reflect everyone's use of email... - --j. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Exmh CVS iD8DBQFB+p7gMJF5cimLx9ARAsNBAKCvSb2kW7Fp5LXFoAHDvFSrzEe8aACggET/ ycR8T02b8S7yg5zQy6gkil4= =VApu -----END PGP SIGNATURE----- From owner-ietf-mxcomp@mail.imc.org Fri Jan 28 16:32:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18334 for ; Fri, 28 Jan 2005 16:32:26 -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 j0SL7ToI091767; Fri, 28 Jan 2005 13:07:29 -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 j0SL7TQP091766; Fri, 28 Jan 2005 13:07:29 -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 j0SL7SXd091759 for ; Fri, 28 Jan 2005 13:07:29 -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 j0SL7POA014868 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 28 Jan 2005 16:07:26 -0500 Date: Fri, 28 Jan 2005 16:07:25 -0500 (EST) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: Justin Mason cc: gmc@metro.cx, , "'Gordon Fecyk'" , "'IETF MXCOMP (E-mail)'" Subject: Re: So here it is one year later... In-Reply-To: <20050128201707.1121B59001E@radish.jmason.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, 28 Jan 2005, Justin Mason wrote: > Actually, you're wrong there. This is SpamAssassin's "hit-frequencies" > tool output. Those are percentages, not message counts, so simply summing > SPAM%+HAM% will not add up to OVERALL%. > > Here's a quick walk through the pertinent parts. (I'm discarding the 1-3 > and 3-6 month ranges -- those are old mails so that data isn't very useful > for network tests -- and just concentrate on the 0-1 month range.) > > OVERALL% SPAM% HAM% S/O RANK SCORE NAME:0-1 > 61405 54725 6680 0.891 0.00 0.00 (all messages):0-1 > > This means that there were 61405 messages mass-checked in total, > with 54725 spams, and 6680 "hams" (non-spam messages). > > 5.377 3.7259 18.9072 0.165 0.23 -0.00 SPF_PASS:0-1 > > looking at the SPAM% and HAM% columns, that means that 3.7259% of the spams > checked had SPF_PASS, and 18.9072% of the hams. that means > > ((3.7259 / 100) * 54725) = 2038.998775 > > I'd suspect that rounding error means that 2039 spam messages passed the > SPF check, so round to 2039. > > ((18.9072 / 100) * 6680) = 1263.00096 > > and 1263 hams passed SPF. Total those, and you get 3302 messages > from the overall corpus passing SPF; to express that as a percentage > of the total overall corpus, in other words "OVERALL%", you compute > (3302 / 61405) * 100 = 5.377. > > If you have any more questions on the hit-frequencies format, I'll > be happy to fill you in -- I wrote the tool in question ;) Ah. That certainly explains the computation. Thanks. But the particular stats are from only 4 people, who, being spamassassin contributors, probably have more SPF-using friends than most people. > > FYI, this is the original post: > > > > ---------- Forwarded message ---------- > > Date: Thu, 9 Sep 2004 15:18:42 +0200 > > From: Markus Stumpf > > To: ietf-mxcomp@vpnc.org > > Subject: SPF abused by spammers > > > > Justin Murdock posted this link on the qmail list: > > http://news.bbc.co.uk/1/hi/technology/3631350.stm > > "CipherTrust [...] found that 34% more spam is passing SPF checks than > > legitimate e-mail." > > Sure. But this was guaranteed to change over time, and vary depending on > corpus composition. It's pretty radically different now, from where I and > the other SpamAssassin corpus contributors are viewing it. Everything changes over time. -- 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 Jan 28 16:57:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24077 for ; Fri, 28 Jan 2005 16:57:09 -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 j0SLT3la093288; Fri, 28 Jan 2005 13: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 j0SLT3s7093287; Fri, 28 Jan 2005 13:29:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0SLT3eq093277 for ; Fri, 28 Jan 2005 13:29:03 -0800 (PST) (envelope-from dotis@mail-abuse.org) Received: from SJC-Office-DHCP-156.Mail-Abuse.ORG (SJC-Office-DHCP-156.Mail-Abuse.ORG [168.61.10.156]) by harry.mail-abuse.org (Postfix) with ESMTP id A09DC414E2 for ; Fri, 28 Jan 2005 13:28:59 -0800 (PST) Subject: Re: So here it is one year later... From: Douglas Otis To: IETF MARID WG In-Reply-To: References: <700EEF5641B7E247AC1C9B82C05D125D055536@srv1.pan-am.ca> <41F942E4.4E18@xyzzy.claranet.de> <1106872082.6443.96.camel@SJC-Office-DHCP-156.mail-abuse.org> <41F9AF92.717D@xyzzy.claranet.de> <1106896265.11035.66.camel@SJC-Office-DHCP-156.mail-abuse.org> Content-Type: text/plain Date: Fri, 28 Jan 2005 13:28:47 -0800 Message-Id: <1106947728.6505.89.camel@SJC-Office-DHCP-156.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2005-01-28 at 13:20 -0600, wayne wrote: > > On Fri, 2005-01-28 at 04:20 +0100, Frank Ellermann wrote: > >> Douglas Otis wrote: > > > >> > applying a record against different algorithms than that > >> > intended when published is inherently deleterious > >> > >> Indeed. > >> > >> > Once again the algorithm changes and still this draft uses > >> > the same labels and record identifiers? Classic. > >> > >> This "new" draft is technically nearer to the last pre-MARID > >> "old" draft than draft-lentczner-spf-00 was. The latter was a > >> rather quick hack salvaging all syntax improvements found here > >> (= mxcomp) after MARID was killed and the old draft expired. > > > > This draft is attempting to make significant algorithmic changes to the > > initial draft, as well as how these records are used. > > > > Some examples: > > > > SPF clients MAY check the "HELO" identity by calling the check_host() > > function (Section 4) with the "HELO" identity as the . If > > the HELO test returns a "fail", the overall result for the SMTP > > session is "fail", and there is no need to test the "MAIL FROM" > > identity. > > > > A test against HELO that goes from unknown, to not tested, to fail? > > This a change in algorithm, as is the hunt for alternative records, > > where a pass may not be based upon address compliance. One wonders how > > macros are applied when the same check_host routine is recycled. > > This is not an example of changing semantics and/or algorithms. As > pointed out by Frank, this is consistent with the pre-MARID > specification of SPF. The problem is not that draft-schlitt-spf-00 > changed things back, but that the IETF, via the MARID WG, allowed it > to change in the first place. Here is a quote for the pre-MARID draft regarding the specified processing algorithm limits. 6.2 Processing Limits During processing, an SPF client may perform additional SPF subqueries due to the Include mechanism and the Redirect modifier. SPF clients must be prepared to handle records that are set up incorrectly or maliciously. SPF clients MUST perform loop detection, limit SPF recursion, or both. If an SPF client chooses to limit recursion depth, then at least a total of 20 redirects and includes SHOULD be supported. (This number should be enough for even the most complicated configurations.) If a loop is detected, or if more than 20 subqueries are triggered, an SPF client MAY abort the lookup and return the result "unknown". Regular non-recursive lookups due to mechanisms like "a" and "mx" or due to modifiers like "exp" do not count toward this total This new draft is NOT a compatible change. It should also be noted this pre-MARID process could entail orders of magnitude more lookups. > > An SPF record published at the zone cut for the domain will be used > > as a default for all subdomains within the zone (See Section 4.5.) > > Domain owners SHOULD publish SPF records for hosts used for the HELO > > and MAIL FROM identities instead of using the zone cut default > > because the fallback requires additional DNS lookups. The zone cut > > default does reduce the need to publish SPF records for non-email > > related hosts, such as www.example.com. > > > > Again, another change in algorithm. This also means TXT RR placed at > > the zone apex may now be problematic as how it becomes applied and to > > which identity. > > This is not an example of changing semantics and/or algorithms. As > pointed out by Frank, this is consistent with the pre-MARID > specification of SPF. The problem is not that draft-schlitt-spf-00 > changed things back, but that the IETF, via the MARID WG, allowed it > to change in the first place. You should review which records would be used to evaluate the EHLO/HELO. And yet another quote from Pre-MARID. The comes from the domain name of the "MAIL FROM" envelope sender. When the envelope sender has no domain, a client MUST use the HELO domain instead. If the HELO argument does not provide an FQDN, SPF processing terminates with "unknown". Now the record applied against the EHLO/HELO identity could be found at the zone apex AND at the EHLO/HELO. The results of this check have also changed and is not consistent. > > If no matching records are returned for the , the SPF client > > MUST find the Zone Cut as defined in [RFC2181] section 6 and repeat > > the above steps. The 's zone origin is then searched for SPF > > records. If an SPF record is found at the zone origin, the > > is set to the zone origin as if a "redirect" modifier was executed. > > > > If no matching records are returned for either search, an SPF client > > MUST assume that the domain makes no SPF declarations. SPF > > processing MUST abort and return "None". > > > > Yet again another change in algorithm isn't it? > > This is not an example of changing semantics and/or algorithms. As > pointed out by Frank, this is consistent with the pre-MARID > specification of SPF. The problem is not that draft-schlitt-spf-00 > changed things back, but that the IETF, via the MARID WG, allowed it > to change in the first place. This changes the pre-MARID, mid-MARID, and post-MARID algorithms! The publisher can NOT be sure which record will be applied against their HELO. It goes from virtually a don't care to a failure. The fall-back, as it is called, will also likely conflict with records at the zone apex. Complain about mail lost as a result of the algorithms applied by Sender-ID, but show some compunction regarding the effect of these changes. All this could be avoided by changing the record identifier. > > This mechanism matches if is one of the MX hosts for a domain > > name. > > > > MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ] > > > > check_host() first performs an MX lookup on the . Then > > it performs an address lookup on each MX name returned. The is > > compared to each returned IP address. To prevent DoS attacks, a > > limit of 10 MX names MUST be enforced (see Section 10). If any > > address matches, the mechanism matches. > > > > A limit change is an algorithmic change that could not be possibly > > foreseen by earlier publishers. Who is responsible when their mail goes > > missing? > > While this is, indeed, a change from the last pre-MARID SPF spec, this > limit has been in place in my libspf2 implemenation since long before > MARID existed, and hence is an existing practice. As discussed *many* > times on SPF-discuss, I can not find *any* legitimate emailers who > have come close to this limit. This change only effects abusers and > misconfigured systems. I guess those that are affected are therefore illegitimate? To publish, discover the limits in the code being used? Code that did not comply to some or any draft? When are the next changes to the algorithm going to be made? How can a disruption be avoided when there is NO MEANS to introduce a new version without removal of the prior? > > And the following regarding forwarding: > > > > There are several possible ways that this authorization failure can > > be ameliorated. If the owner of the external mailbox wishes to trust > > the forwarding service, they can direct the external mailbox's MTA to > > skip such tests when the client host belongs to the forwarding > > service. Tests against some other identity may also be used to > > override the test against the "MAIL FROM" identity. > > > > For larger domains, it may not be possible to have a complete or > > accurate list of forwarding services used by the owners of the > > domain's mailboxes. In such cases, white lists of generally > > recognized forwarding services could be employed. > > > > Some other Identity? Generally recognized forwarding services? Would > > this open the door for abusing the typical alma mater? This is a mess. > > As noted in Section 9, this is is non-normative. If you don't agree > with what is said, you are free to do anything you want. This is just > for your information. In essence, don't expect forwarding to function. May I comment that this is disruptive and a mess without this comment being called misinformation or myself as being a troll for taking time to read the drafts presented on this reflector. Regarding the debate about who uses SPF, spammers register more domains than legitimate users, but at any instant, individual spammer domains will not likely be used once consistently blocked by filters. Looking at the numbers from the perspective of nominal traffic, versus published domains with a "bad" record, these ratios _should_ be different. > > This draft at long last recognizes wildcard labels are a problem. Why > > not also recognize a need to _change_ revisions when algorithms change > > and the need for a standardized prefix rather than a record tag? These > > are rather significant changes being made, why suggest otherwise? > > The section on wildcards was added as part of the MARID process and > remained in the draft-schlitt-spf-00 version because it is useful. > The changes to the algorithms that were added as part of the MARID > process have been removed. Changes to the algorigtms from the > pre-MARID SPF specs have all been implemented by at least one system > and have been checked, via wide surveys, that they do not conflict > the install base of legitimate SPF records. > > I find it very amusing that you are now complaining about the process > limits being a change, since you have long complained about the lack > of process limits in previous versions of the SPF spec. I have not complained about a reduction in the limits, but rather a change that imperils the publishers. I was complaining this draft still does not allow a reasonable method to change processing algorithms without potentially creating sizeable disruption. This is due, in no small part, from a false expectation that a wildcard label provided some utility and is the reason for usurping the use of the TXT RR. This was wrong and remains wrong. Using a prefix on the record remains a viable method to ensure SPF offers less disruption to users as well as other protocols. If I was right once... -Doug From owner-ietf-mxcomp@mail.imc.org Fri Jan 28 17:53:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29336 for ; Fri, 28 Jan 2005 17:53:33 -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 j0SMPqul096770; Fri, 28 Jan 2005 14:25: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 j0SMPqKR096769; Fri, 28 Jan 2005 14:25: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 j0SMPp1U096763 for ; Fri, 28 Jan 2005 14:25: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 j0SMPmXu016316 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 28 Jan 2005 17:25:49 -0500 Date: Fri, 28 Jan 2005 17:25:47 -0500 (EST) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: Justin Mason cc: gmc@metro.cx, , "'Gordon Fecyk'" , "'IETF MXCOMP (E-mail)'" Subject: Re: So here it is one year later... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 28 Jan 2005, Dean Anderson wrote: > > ((3.7259 / 100) * 54725) = 2038.998775 > > > > I'd suspect that rounding error means that 2039 spam messages passed the > > SPF check, so round to 2039. > > > > ((18.9072 / 100) * 6680) = 1263.00096 > > > > and 1263 hams passed SPF. Total those, and you get 3302 messages > > from the overall corpus passing SPF; to express that as a percentage > > of the total overall corpus, in other words "OVERALL%", you compute > > (3302 / 61405) * 100 = 5.377. BTW, I'd say that 38% of the SPF use was ham, and 62% was spam. 1263 ham / 3302 = ~38% 2039 spam / 3302 = ~62% So, 24% versus the 34% in September. Either slightly better than September, or perhaps the sample is too small and skewed to be useful. Or both. Its still better to block whenever you see SPF. Still, I'd think the 3.7% of total spam using SPF is still fairly significant, and probably reflects the relative proportion of genuine commercial spam to non-commercial spam. It would be interesting to know, of those spams that pass SPF, how many are CAN-SPAM compliant? How many of the non-SPF spams were CAN-SPAM compliant? I'd conjecture a strong correlation. --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 Jan 28 18:47:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04452 for ; Fri, 28 Jan 2005 18:47: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 j0SNEXwU099505; Fri, 28 Jan 2005 15:14: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 j0SNEXM2099504; Fri, 28 Jan 2005 15:14:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from amgod.boxhost.net (dogma.boxhost.net [195.218.96.101]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0SNEWZ2099497 for ; Fri, 28 Jan 2005 15:14:32 -0800 (PST) (envelope-from jm@jmason.org) Received: from radish.jmason.org (localhost [127.0.0.1]) by amgod.boxhost.net (Postfix) with ESMTP id 9D473310250; Fri, 28 Jan 2005 23:17:37 +0000 (GMT) Received: from jmason.org (localhost [127.0.0.1]) by radish.jmason.org (Postfix) with ESMTP id 5837959001E; Fri, 28 Jan 2005 15:14:27 -0800 (PST) To: Dean Anderson Cc: Justin Mason , gmc@metro.cx, terry@ashtonwoodshomes.com, "'Gordon Fecyk'" , "'IETF MXCOMP (E-mail)'" Subject: Re: So here it is one year later... In-Reply-To: From: jm@jmason.org (Justin Mason) X-Gpg-Key-Fingerprint: 1368 71CE 3627 9CD3 FA1B 0B63 3091 7972 298B C7D0 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 . Date: Fri, 28 Jan 2005 15:14:27 -0800 Message-Id: <20050128231427.5837959001E@radish.jmason.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dean Anderson writes: > On Fri, 28 Jan 2005, Dean Anderson wrote: > > > > ((3.7259 / 100) * 54725) = 2038.998775 > > > > > > I'd suspect that rounding error means that 2039 spam messages passed the > > > SPF check, so round to 2039. > > > > > > ((18.9072 / 100) * 6680) = 1263.00096 > > > > > > and 1263 hams passed SPF. Total those, and you get 3302 messages > > > from the overall corpus passing SPF; to express that as a percentage > > > of the total overall corpus, in other words "OVERALL%", you compute > > > (3302 / 61405) * 100 = 5.377. > > BTW, I'd say that 38% of the SPF use was ham, and 62% was spam. > 1263 ham / 3302 = ~38% > 2039 spam / 3302 = ~62% > > So, 24% versus the 34% in September. Either slightly better than > September, or perhaps the sample is too small and skewed to be useful. Or > both. Its still better to block whenever you see SPF. hmm! not sure if that's a good assumption -- it's very much dependent on the comparative ham:spam ratio a domain would see. This set of corpora is heavily skewed towards receiving more spam than ham; 87.8% of our messages being spam. Let's say those corpora were only receiving a third as much spam as they currently do, possibly because they were younger email addresses or whatever. In that case, we'd see 1263 ham, 680 spam (2039/3 ~= 680), in which case the proportion of SPF-using-spam vs SPF-using-ham would be on its head: 34% being spam, 65% being ham. What I'm trying to illustrate here is that it's important to compare figures using figures that compensate for the comparative ham:spam ratio, because that varies wildly. Hence, comparing (SPF-bearing-ham / all-ham) to (SPF-bearing-spam / all-spam) is safer than comparing the message counts of SPF-bearing-ham and SPF-bearing-spam directly. > Still, I'd think the 3.7% of total spam using SPF is still fairly > significant, and probably reflects the relative proportion of genuine > commercial spam to non-commercial spam. It would be interesting to know, > of those spams that pass SPF, how many are CAN-SPAM compliant? How many > of the non-SPF spams were CAN-SPAM compliant? I'd conjecture a strong > correlation. now that's something I don't have time to get into, CAN-SPAM compliance not being something that's easy to automate checking for (more's the pity). - --j. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Exmh CVS iD8DBQFB+sdSMJF5cimLx9ARAhvgAKCdDpROw4/yqVxCwOwMipg46uh/LACbBD/6 HsR9l0+iPdHRG4RDM/zOSmQ= =lLX4 -----END PGP SIGNATURE----- From owner-ietf-mxcomp@mail.imc.org Fri Jan 28 19:30:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07524 for ; Fri, 28 Jan 2005 19:30: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 j0T04JjM003024; Fri, 28 Jan 2005 16:04: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 j0T04J3b003023; Fri, 28 Jan 2005 16:04:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (customer-reverse-entry.64.151.105.12 [64.151.105.12] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0T04Ja9003016 for ; Fri, 28 Jan 2005 16:04:19 -0800 (PST) (envelope-from andy@hxr.us) Received: from [10.131.244.246] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Fri, 28 Jan 2005 19:04:17 -0500 id 0011C0DC.41FAD301.0000476E In-Reply-To: References: <700EEF5641B7E247AC1C9B82C05D125D055536@srv1.pan-am.ca> <41F942E4.4E18@xyzzy.claranet.de> <1106872082.6443.96.camel@SJC-Office-DHCP-156.mail-abuse.org> <41F9AF92.717D@xyzzy.claranet.de> <1106896265.11035.66.camel@SJC-Office-DHCP-156.mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4DD53697-7189-11D9-9CD0-000D9358DFD8@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: So here it is one year later... Date: Fri, 28 Jan 2005 19:04:11 -0500 To: "IETF MARID WG" X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jan 28, 2005, at 2:20 PM, wayne wrote: > The problem is not that draft-schlitt-spf-00 > changed things back, but that the IETF, via the MARID WG, allowed it > to change in the first place. This statement strikes me as particularly offensive. If the intent was to have the IETF simply rubber-stamp SPF, making that clear up front would have saved us all a lot of time. -andy From owner-ietf-mxcomp@mail.imc.org Fri Jan 28 21:46:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15614 for ; Fri, 28 Jan 2005 21:46: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 j0T26nxX009582; Fri, 28 Jan 2005 18:06: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 j0T26nDj009581; Fri, 28 Jan 2005 18:06:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.pan-am.ca (nspublic.pan-am.ca [205.200.6.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0T26kjm009575 for ; Fri, 28 Jan 2005 18:06:48 -0800 (PST) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: So here it is one year later... Date: Fri, 28 Jan 2005 20:06:46 -0600 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <700EEF5641B7E247AC1C9B82C05D125D05553E@srv1.pan-am.ca> Thread-Topic: So here it is one year later... Thread-Index: AcUFmzAFTub6RXtJTZu4rSRlix6gPgAC9qUw From: "Gordon Fecyk" To: "IETF MARID WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j0T26njm009576 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > If the intent was > to have the IETF simply rubber-stamp SPF, making that clear up front > would have saved us all a lot of time. Sokath, his eyes uncovered! And in total fairness, s/SPF/SenderID. -- PGP key (0x0AFA039E): Sometimes it's hard to tell where the game ends and where reality bites, er, begins. From owner-ietf-mxcomp@mail.imc.org Sat Jan 29 01:06:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28811 for ; Sat, 29 Jan 2005 01:06: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 j0T5XAYo023721; Fri, 28 Jan 2005 21:33: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 j0T5XADp023720; Fri, 28 Jan 2005 21:33:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (schlitt.net [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0T5X81n023713 for ; Fri, 28 Jan 2005 21:33:09 -0800 (PST) (envelope-from wayne@schlitt.net) Received: from footbone.schlitt.net ([206.222.212.237] helo=schlitt.net) by backbone.midwestcs.com with esmtp (Exim 4.43) id 1CulE6-0005x6-Sx for ietf-mxcomp@imc.org; Fri, 28 Jan 2005 23:33:08 -0600 To: "IETF MARID WG" References: <700EEF5641B7E247AC1C9B82C05D125D055536@srv1.pan-am.ca> <41F942E4.4E18@xyzzy.claranet.de> <1106872082.6443.96.camel@SJC-Office-DHCP-156.mail-abuse.org> <41F9AF92.717D@xyzzy.claranet.de> <1106896265.11035.66.camel@SJC-Office-DHCP-156.mail-abuse.org> <4DD53697-7189-11D9-9CD0-000D9358DFD8@hxr.us> From: wayne Mail-Copies-To: nobody Reply-To: "IETF MARID WG" Date: Fri, 28 Jan 2005 23:32:54 -0600 In-Reply-To: <4DD53697-7189-11D9-9CD0-000D9358DFD8@hxr.us> (Andrew Newton's message of "Fri, 28 Jan 2005 19:04:11 -0500") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Corporate Culture, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of schlitt.net designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@schlitt.net; helo=schlitt.net; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: So here it is one year later... Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on backbone.midwestcs.com X-Spam-Status: No, score=-6.6 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00, GREYLIST_ISWHITE autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.1 (built Tue, 17 Aug 2004 11:06:07 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <4DD53697-7189-11D9-9CD0-000D9358DFD8@hxr.us> Andrew Newton writes: > On Jan 28, 2005, at 2:20 PM, wayne wrote: > >> The problem is not that draft-schlitt-spf-00 >> changed things back, but that the IETF, via the MARID WG, allowed it >> to change in the first place. > > This statement strikes me as particularly offensive. If the intent > was to have the IETF simply rubber-stamp SPF, making that clear up > front would have saved us all a lot of time. MARID never adopted/considered SPF. When, at the interim meeting, MARID assigned authors to create proposals, it was to create SenderID with the use of the PRA. At that point, all compatibility with SPF-classic was basically thrown out the window. Eventually, enough people decided there were enough incompatibilities that it was decided at the ietf-60(?) session that SenderID should use new records. For some strange reason, the IETF is now considering the SenderID drafts that still use the same records. Go figure. I know of no one who asked or assumed that the IETF would rubber-stamp SPF. I did say, several times, that adopting an existing system would be a much better idea than trying to create something from scratch. Both DMP and RMX, for example, would have been a better choices than SenderID because both had more testing done on them. If MARID had chosen to adopt either DMP or RMX, that would have been fine with me. Now, back to message I was replying to, Doug talked about the SPF-classic spec of draft-lentczner-spf-00. Like all SPF specs, it was never adopted by MARID. The problem here is that Mark took the drafts developed during MARID and tried to back-port them to be SPF-classic drafts. The advantage of doing this is that a great deal of wordsmithing, in particular work done by Mark, had gone into the MARID drafts and they were much better language wise. Unfortunately, they had the many semantic/algorithmic changes that the MARID group made during the development of SenderID. draft-schlitt-spf-classic-00 is an attempt to use the much better language of the MARID drafts, but to restore functionality to match what the install base of SPF systems is. This draft also has removed several features that are unused in the wild, and has more strict error handling/checking added. So, not rubber-stamping SPF wasn't a problem. Creating a new spec that changed the semantics of SPF records was. -wayne From owner-ietf-mxcomp@mail.imc.org Sat Jan 29 01:44:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00892 for ; Sat, 29 Jan 2005 01:44: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 j0T65oDD027199; Fri, 28 Jan 2005 22:05: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 j0T65odU027198; Fri, 28 Jan 2005 22:05:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (schlitt.net [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0T65n2Y027186 for ; Fri, 28 Jan 2005 22:05:49 -0800 (PST) (envelope-from wayne@schlitt.net) Received: from footbone.schlitt.net ([206.222.212.237] helo=schlitt.net) by backbone.midwestcs.com with esmtp (Exim 4.43) id 1Culjg-0006QG-SL for ietf-mxcomp@imc.org; Sat, 29 Jan 2005 00:05:48 -0600 To: "IETF MARID WG" References: <700EEF5641B7E247AC1C9B82C05D125D055536@srv1.pan-am.ca> <41F942E4.4E18@xyzzy.claranet.de> <1106872082.6443.96.camel@SJC-Office-DHCP-156.mail-abuse.org> <41F9AF92.717D@xyzzy.claranet.de> <1106896265.11035.66.camel@SJC-Office-DHCP-156.mail-abuse.org> <1106947728.6505.89.camel@SJC-Office-DHCP-156.mail-abuse.org> From: wayne Mail-Copies-To: nobody Reply-To: "IETF MARID WG" Date: Sat, 29 Jan 2005 00:05:31 -0600 In-Reply-To: <1106947728.6505.89.camel@SJC-Office-DHCP-156.mail-abuse.org> (Douglas Otis's message of "Fri, 28 Jan 2005 13:28:47 -0800") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Corporate Culture, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of schlitt.net designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@schlitt.net; helo=schlitt.net; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: So here it is one year later... Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on backbone.midwestcs.com X-Spam-Status: No, score=-6.6 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00, GREYLIST_ISWHITE autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.1 (built Tue, 17 Aug 2004 11:06:07 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <1106947728.6505.89.camel@SJC-Office-DHCP-156.mail-abuse.org> Douglas Otis writes: > On Fri, 2005-01-28 at 13:20 -0600, wayne wrote: >> > On Fri, 2005-01-28 at 04:20 +0100, Frank Ellermann wrote: >> > >> >> This "new" draft is technically nearer to the last pre-MARID >> >> "old" draft than draft-lentczner-spf-00 was. The latter was a >> >> rather quick hack salvaging all syntax improvements found here >> >> (= mxcomp) after MARID was killed and the old draft expired. > [big snip] > Here is a quote for the pre-MARID draft regarding the specified > processing algorithm limits. > > 6.2 Processing Limits > > [stuff from, I'm pretty sure, spf-draft-200406 snipped] > > This new draft is NOT a compatible change. It should also be noted this > pre-MARID process could entail orders of magnitude more lookups. I disagree. In practice, at least, this is a very compatible change because almost no one runs into the limits. > You should review which records would be used to evaluate the EHLO/HELO. > And yet another quote from Pre-MARID. > > The comes from the domain name of the "MAIL > FROM" envelope sender. When the envelope sender has no domain, a > client MUST use the HELO domain instead. If the HELO argument does > not provide an FQDN, SPF processing terminates with "unknown". > > Now the record applied against the EHLO/HELO identity could be found at > the zone apex AND at the EHLO/HELO. The results of this check have also > changed and is not consistent. Yes, the zone cut stuff, while in spf-draft-200406, is certainly the thing that I'm most willing to remove from draft-schlitt-spf-classic-00. It has some nice properties, but it has some problems also. > [another big snip] > > This changes the pre-MARID, mid-MARID, and post-MARID algorithms! I'm not sure what you mean by this. The zonecut stuff is in spf-draft-200406. >> > [mx processing limit stuff snipped] >> >> While this is, indeed, a change from the last pre-MARID SPF spec, this >> limit has been in place in my libspf2 implemenation since long before >> MARID existed, and hence is an existing practice. As discussed *many* >> times on SPF-discuss, I can not find *any* legitimate emailers who >> have come close to this limit. This change only effects abusers and >> misconfigured systems. > > I guess those that are affected are therefore illegitimate? To publish, > discover the limits in the code being used? Code that did not comply to > some or any draft? When are the next changes to the algorithm going to > be made? How can a disruption be avoided when there is NO MEANS to > introduce a new version without removal of the prior? "A difference that makes no difference is no difference" -- spock Yes, in theory, there are incompatible changes, in practice there aren't. > [yet another big snip] > > In essence, don't expect forwarding to function. Yes, SPF and traditional alias/.forward type forwarding don't work well together. The MAPS DUL list and all end users being able to have their own MTA don't work well together. DomainKeys and mailing lists don't work well together. NAT and many games/vpn/etc. don't work well together. There are *lots* of changes that have happened that cause other problems. That section of the SPF-classic spec explains the situation. As an email receiver, if you don't like it, you don't have to check SPF records, check the MAPS DUL, check domain keys, or use NAT. Your box, your rules. > I have not complained about a reduction in the limits, but rather a > change that imperils the publishers. I was complaining this draft still > does not allow a reasonable method to change processing algorithms > without potentially creating sizeable disruption. This is due, in no > small part, from a false expectation that a wildcard label provided some > utility and is the reason for usurping the use of the TXT RR. This was > wrong and remains wrong. Using a prefix on the record remains a viable > method to ensure SPF offers less disruption to users as well as other > protocols. If I was right once... Lots of stuff here that I guess we will just have to agree to disagree on. I don't agree with all the choices that were made with SPF, some due to hind sight, some due to differening opinions. It still remains far and away the most deployed designated sender system out there. It doesn't appear that we make any fatal mistakes. IMHO, some of the stuff you stuggest would be "better" would, actually, have been a fatal mistake. -wayne From owner-ietf-mxcomp@mail.imc.org Sat Jan 29 07:38:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06205 for ; Sat, 29 Jan 2005 07:38: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 j0TBklNX046367; Sat, 29 Jan 2005 03:46: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 j0TBklR8046366; Sat, 29 Jan 2005 03:46:47 -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 j0TBkjkY046347 for ; Sat, 29 Jan 2005 03:46:45 -0800 (PST) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1Cur3s-0001gd-00 for ; Sat, 29 Jan 2005 12:46:44 +0100 Received: from du-001-176.access.de.clara.net ([212.82.227.176]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 29 Jan 2005 12:46:44 +0100 Received: from nobody by du-001-176.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 29 Jan 2005 12:46:44 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: So here it is one year later... Date: Sat, 29 Jan 2005 12:15:15 +0100 Organization: Lines: 16 Message-ID: <41FB7043.5F74@xyzzy.claranet.de> References: <700EEF5641B7E247AC1C9B82C05D125D055536@srv1.pan-am.ca> <41F942E4.4E18@xyzzy.claranet.de> <1106872082.6443.96.camel@SJC-Office-DHCP-156.mail-abuse.org> <41F9AF92.717D@xyzzy.claranet.de> <1106896265.11035.66.camel@SJC-Office-DHCP-156.mail-abuse.org> <4DD53697-7189-11D9-9CD0-000D9358DFD8@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-176.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Andrew Newton wrote: > If the intent was to have the IETF simply rubber-stamp SPF, > making that clear up front would have saved us all a lot of > time. My intention was always to get a RfC for LMAP (with SPF as the most promising candidate at this time, but also including CSV), i.e. to find and fix all bugs and oddities in these concepts. You never allowed this to happen here. You always pressed for 2822 and the IMHO broken Sender-ID concept, and when that failed you let the A-D close this WG without prior consultation. -- From owner-ietf-mxcomp@mail.imc.org Sat Jan 29 11:54:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23094 for ; Sat, 29 Jan 2005 11:54:04 -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 j0TGGhFb090062; Sat, 29 Jan 2005 08:16: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 j0TGGPcf090023; Sat, 29 Jan 2005 08:16:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (customer-reverse-entry.64.151.105.12 [64.151.105.12] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0TGD2I3089887 for ; Sat, 29 Jan 2005 08:16:05 -0800 (PST) (envelope-from andy@hxr.us) Received: from [10.0.1.5] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Sat, 29 Jan 2005 11:12:13 -0500 id 0011C0CB.41FBB5DE.000033FA Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: <700EEF5641B7E247AC1C9B82C05D125D055536@srv1.pan-am.ca> <41F942E4.4E18@xyzzy.claranet.de> <1106872082.6443.96.camel@SJC-Office-DHCP-156.mail-abuse.org> <41F9AF92.717D@xyzzy.claranet.de> <1106896265.11035.66.camel@SJC-Office-DHCP-156.mail-abuse.org> <4DD53697-7189-11D9-9CD0-000D9358DFD8@hxr.us> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8617533D-7210-11D9-9CD0-000D9358DFD8@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: So here it is one year later... Date: Sat, 29 Jan 2005 11:12:07 -0500 To: "IETF MARID WG" X-Mailer: Apple Mail (2.619) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jan 29, 2005, at 12:32 AM, wayne wrote: > For > some strange reason, the IETF is now considering the SenderID drafts > that still use the same records. Go figure. If by same records, you mean anything TXT then I'm afraid you will have to live with that... and any other new uses for TXT that come along. > So, not rubber-stamping SPF wasn't a problem. Creating a new spec > that changed the semantics of SPF records was. But I suppose you mean the v=spf1 records and agree that you have a point.... which is not what I thought you were saying. Sorry for jumping to conclusions. -andy From owner-ietf-mxcomp@mail.imc.org Sat Jan 29 12:49:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27164 for ; Sat, 29 Jan 2005 12:49: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 j0THIXrN093171; Sat, 29 Jan 2005 09:18: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 j0THIXs2093170; Sat, 29 Jan 2005 09:18:33 -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 j0THIIqJ093152 for ; Sat, 29 Jan 2005 09:18:26 -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 CC20016CC4 for ; Sat, 29 Jan 2005 12:12:45 -0500 (EST) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: So here it is one year later... In-Reply-To: Your message of "Sat, 29 Jan 2005 12:15:15 +0100." <41FB7043.5F74@xyzzy.claranet.de> Date: Sat, 29 Jan 2005 12:12:45 -0500 Message-Id: <20050129171245.CC20016CC4@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Frank Ellermann wrote: > You never allowed this to happen here. You always pressed for > 2822 and the IMHO broken Sender-ID concept, and when that failed > you let the A-D close this WG without prior consultation. The chairs asked for consensus from the group. The consensus was to look at 2822 and Sender-Id. Once that happened, further consensus did not occur. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Sat Jan 29 13:52:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03427 for ; Sat, 29 Jan 2005 13:52:49 -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 j0TIFRkd096112; Sat, 29 Jan 2005 10:15: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 j0TIFPnu096081; Sat, 29 Jan 2005 10:15:26 -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 ([216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0TIChjA095962 for ; Sat, 29 Jan 2005 10:14:28 -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 j0TIHZvC006676; Sat, 29 Jan 2005 10:17:35 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id j0TIHYnG006670; Sat, 29 Jan 2005 10:17:34 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Sat, 29 Jan 2005 10:17:34 -0800 (PST) From: "william(at)elan.net" To: Alan DeKok cc: ietf-mxcomp@imc.org Subject: Re: So here it is one year later... In-Reply-To: <20050129171245.CC20016CC4@mail.nitros9.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, 29 Jan 2005, Alan DeKok wrote: > Frank Ellermann wrote: > > You never allowed this to happen here. You always pressed for > > 2822 and the IMHO broken Sender-ID concept, and when that failed > > you let the A-D close this WG without prior consultation. > > The chairs asked for consensus from the group. The consensus was to > look at 2822 and Sender-Id. That is not exactly true. Prior to May interim meeting there was general consensus that we're going to look and work with RFC2821 identities and RFC2821 MAIL FROM in particular. On that meeting it was announced that Meng & Microsoft agreed to merge into what was essentially CallerID (xml dns record, rfc2822 identities, pra), but its syntax would be closer to supporting spf with clients also support spf1 records. It was presented to the group in the way that left no serious alternative except CSV for checking HELO which was also worked by the WG. There were people on that meeting who did not like the kind of merger between spf and callerid that was announced but we were willing to at least try to see what this would turn out into especially since IETF was willing to put its hand into making it work. Within month however it became clear that XML was not the way to go (not for DNS TXT record at the very least) and within another month it was also seen that RFC2822 identities is really not the right thing to do per-hop authentication of incoming mail server by ip. Besides that Microsoft intentions and its willingness to work every party that had interest in MARID was seriously in question and it was seen that Microsoft and its PRA was more of a burden then help. So by IETF60 there was really no longer consensus, but parties most interested in SID were still trying hard to push it through. The result was not unexpected that when actual poll on consensus (last-call on sid documents) was done it fall miserably. The correct thing to do would have been to re-asses the situation and check for consensus again to see if any alternative solution would be have consensus to go forward and would not have the same technical problems. But it was also from the start felt by many that IETF was under a lot of pressure from corporate interests to standardize CallerID/SenderID and that MARID was nothing but a show to slightly polish it before putting ietf stamp on it and that that abandoning in favor of another alternative would be seen as unacceptable to very very large corporate parties who would take it as a sign that they should not come and work with IETF again. So unfortunately, instead of choosing to clearly disregard what was technically unacceptable proposal that does not have consensus of the community,IETF decided to just disband the WG and make decisions about the same proposal privately at the level of IESG and select group of individuals who we don't even know - DEA Directorate had been formed but its membership seems to be kept private even though Ted Hardie said here in message http://www.imc.org/ietf-mxcomp/mail-archive/msg05054.html that it will be made public. I'm hoping that Ted Hardie and IESG will follow through on its promise and that there is no official information on IETF pages about DEA is just an oversight due to very overworked staff who had not yet had time to create appropriate information page. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Sat Jan 29 14:21:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05076 for ; Sat, 29 Jan 2005 14:21: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 j0TIsSoo098883; Sat, 29 Jan 2005 10:54:28 -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 j0TIsSLY098882; Sat, 29 Jan 2005 10:54:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (schlitt.net [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0TIsRin098862 for ; Sat, 29 Jan 2005 10:54:27 -0800 (PST) (envelope-from wayne@schlitt.net) Received: from footbone.schlitt.net ([206.222.212.237] helo=schlitt.net) by backbone.midwestcs.com with esmtp (Exim 4.43) id 1Cuxjb-000785-TX for ietf-mxcomp@imc.org; Sat, 29 Jan 2005 12:54:26 -0600 To: "IETF MARID WG" References: <20050129171245.CC20016CC4@mail.nitros9.org> From: wayne Mail-Copies-To: nobody Reply-To: "IETF MARID WG" Date: Sat, 29 Jan 2005 12:54:09 -0600 In-Reply-To: <20050129171245.CC20016CC4@mail.nitros9.org> (Alan DeKok's message of "Sat, 29 Jan 2005 12:12:45 -0500") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Corporate Culture, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of schlitt.net designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@schlitt.net; helo=schlitt.net; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: So here it is one year later... Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on backbone.midwestcs.com X-Spam-Status: No, score=-6.6 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00, GREYLIST_ISWHITE autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.1 (built Tue, 17 Aug 2004 11:06:07 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <20050129171245.CC20016CC4@mail.nitros9.org> "Alan DeKok" writes: > Frank Ellermann wrote: >> You never allowed this to happen here. You always pressed for >> 2822 and the IMHO broken Sender-ID concept, and when that failed >> you let the A-D close this WG without prior consultation. > > The chairs asked for consensus from the group. The consensus was to > look at 2822 and Sender-Id. > > Once that happened, further consensus did not occur. No. The chairs/AD asked for consensus from the group. The consensus was to look at the 2821 identities first and then look at the 2822 identities. The charter promised that once this decision was reached, that all further discussions on other identities would be ruled out of scope. This did not happen. The chairs/AD, at the interim meeting, decided to ignore this and switched to 2822 with SenderID and the PRA as the only option. This complete change of direction was never confirmed on the mailing list, despite the IETF rules on the subject. (Ok, CSV was left on the table, to be considered after SenderID. That, however, completely ignored SPF's 2821.HELO checking, and all forms of 2821.MAILFROM checking.) MARID showed just how much more important political considerations are in making decisions than technical considerations. The end run that the IETF is making, right now, around the technical problems with SenderID is just another great example. The SenderID I-Ds have now been sent off to a secret directorate for review, with no place to make public comments. It is not even clear if the IESG will allow an IETF wide last-call for the SenderID I-Ds before they are promoted to being RFCs. But, the people on this MARID mailing list don't even care about that. They would much rather discuss the SPF-classic I-Ds, something that was never adopted by the MARID working group. -wayne From owner-ietf-mxcomp@mail.imc.org Sat Jan 29 14:34:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06018 for ; Sat, 29 Jan 2005 14:34: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 j0TJ3IV6099243; Sat, 29 Jan 2005 11:03: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 j0TJ3IiT099242; Sat, 29 Jan 2005 11:03:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (schlitt.net [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0TJ3HDe099236 for ; Sat, 29 Jan 2005 11:03:17 -0800 (PST) (envelope-from wayne@schlitt.net) Received: from footbone.schlitt.net ([206.222.212.237] helo=schlitt.net) by backbone.midwestcs.com with esmtp (Exim 4.43) id 1CuxsA-0007ic-10 for ietf-mxcomp@imc.org; Sat, 29 Jan 2005 13:03:16 -0600 To: "IETF MARID WG" References: <700EEF5641B7E247AC1C9B82C05D125D055536@srv1.pan-am.ca> <41F942E4.4E18@xyzzy.claranet.de> <1106872082.6443.96.camel@SJC-Office-DHCP-156.mail-abuse.org> <41F9AF92.717D@xyzzy.claranet.de> <1106896265.11035.66.camel@SJC-Office-DHCP-156.mail-abuse.org> <4DD53697-7189-11D9-9CD0-000D9358DFD8@hxr.us> <8617533D-7210-11D9-9CD0-000D9358DFD8@hxr.us> From: wayne Mail-Copies-To: nobody Reply-To: "IETF MARID WG" Date: Sat, 29 Jan 2005 13:03:05 -0600 In-Reply-To: <8617533D-7210-11D9-9CD0-000D9358DFD8@hxr.us> (Andrew Newton's message of "Sat, 29 Jan 2005 11:12:07 -0500") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Corporate Culture, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of schlitt.net designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@schlitt.net; helo=schlitt.net; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: So here it is one year later... Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on backbone.midwestcs.com X-Spam-Status: No, score=-6.6 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00, GREYLIST_ISWHITE autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.1 (built Tue, 17 Aug 2004 11:06:07 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <8617533D-7210-11D9-9CD0-000D9358DFD8@hxr.us> Andrew Newton writes: > On Jan 29, 2005, at 12:32 AM, wayne wrote: >> For >> some strange reason, the IETF is now considering the SenderID drafts >> that still use the same records. Go figure. > > If by same records, you mean anything TXT then I'm afraid you will > have to live with that... and any other new uses for TXT that come > along. Nope, I see no problem with using TXT RRs. (The same goes for CSV's use of SRV records or MAPS's use of A records.) >> So, not rubber-stamping SPF wasn't a problem. Creating a new spec >> that changed the semantics of SPF records was. > > But I suppose you mean the v=spf1 records and agree that you have a > point.... which is not what I thought you were saying. Sorry for > jumping to conclusions. Actually, reviewing things, I shouldn't have jumped so hard on MARID changing things. When MARID decided to do a design-by-committee of a new system, rarely a wise idea, it didn't change the SPF-classic specifications. New systems don't have backward compatibility problems. The real problem was that the draft-lentczner-spf-00 I-D did not eliminate all the incompatibilities that the MARID SenderID I-Ds created. Hence the creation of draft-schlitt-spf-classic-00. -wayne From owner-ietf-mxcomp@mail.imc.org Sat Jan 29 19:04:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26227 for ; Sat, 29 Jan 2005 19:04: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 j0TNUTFj022220; Sat, 29 Jan 2005 15:30:29 -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 j0TNUTW5022219; Sat, 29 Jan 2005 15:30:29 -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 j0TNUSMn022210 for ; Sat, 29 Jan 2005 15:30:28 -0800 (PST) (envelope-from dotis@mail-abuse.org) Received: from 192.168.2.47 (64-142-13-68.dsl.static.sonic.net [64.142.13.68]) (authenticated bits=0) by b.mail.sonic.net (8.13.3/8.13.3) with ESMTP id j0TNUQin014089 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sat, 29 Jan 2005 15:30:26 -0800 Subject: Re: So here it is one year later... From: Douglas Otis To: IETF MARID WG In-Reply-To: References: <700EEF5641B7E247AC1C9B82C05D125D055536@srv1.pan-am.ca> <41F942E4.4E18@xyzzy.claranet.de> <1106872082.6443.96.camel@SJC-Office-DHCP-156.mail-abuse.org> <41F9AF92.717D@xyzzy.claranet.de> <1106896265.11035.66.camel@SJC-Office-DHCP-156.mail-abuse.org> <4DD53697-7189-11D9-9CD0-000D9358DFD8@hxr.us> <8617533D-7210-11D9-9CD0-000D9358DFD8@hxr.us> Content-Type: text/plain Date: Sat, 29 Jan 2005 15:30:13 -0800 Message-Id: <1107041414.7186.122.camel@littlejoy> Mime-Version: 1.0 X-Mailer: Evolution 2.0.1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sat, 2005-01-29 at 13:03 -0600, wayne wrote: > In <8617533D-7210-11D9-9CD0-000D9358DFD8@hxr.us> Andrew Newton writes: > > > On Jan 29, 2005, at 12:32 AM, wayne wrote: > >> For > >> some strange reason, the IETF is now considering the SenderID drafts > >> that still use the same records. Go figure. > > > > If by same records, you mean anything TXT then I'm afraid you will > > have to live with that... and any other new uses for TXT that come > > along. > > Nope, I see no problem with using TXT RRs. (The same goes for CSV's > use of SRV records or MAPS's use of A records.) Those publishing SPF records risk causing their mail being forwarded by various recipients to be blocked or lost, with the same happening to mail sent through some list servers. For network security and to establish accurate reputation, an accountable entity for the mail being sent can be found by way of the HELO domain. SPF however can not indicate which identity checking is desired by the sender. Is it the Sender-ID PRA, the SPF MAILFROM, or now the SPF MAILFROM and HELO in combination? The design choice of SPF to not use a specific label to access a potentially large initial TXT RR record, dedicates this TXT RR for use by one revision of one application. This is wrong. This gets even worse with use of this same TXT RR by more than one faction. A wildcard label can not establish policy, so the reasons for avoiding a prefix proves to have been a major mistake. While commending efforts that attempt to establish reasonable limits for the use of DNS, this effort is like starting with a square block and chipping away at the corners. Eventually, one arrives at the wheel. The new SPF processing limits are stated differently: SPF implementations MUST limit the number of mechanism that do DNS lookups to at most 10, if this number is exceeded, a PermError MUST be returned. The mechanisms that count against this limit are "include", "a", "mx", "ptr", "exists" and the "redirect" modifier. The "all", "ip4" and "ip6" mechanisms do not require DNS lookups and therefore do not count against this limit. The "exp" modifier requires a DNS lookup, but it is not counted as it is used only in the case of errors. When evaluating the "mx" and "ptr" mechanisms, or the %{p} macro, there MUST be a limit of no more than 10 MX or PTR RRs looked up and checked. A limit of 10 mechanism[s] that do DNS lookups? Each mechanism is then allowed 10 lookups? Would that be a total of 101 lookups? Will this prevent attacks? The average number of queries for each lookup could be around 3. The following text and process definitions seem to allow 10 lookups each to resolve the MX, the PTR, and the %{p} macro (reverse DNS comparison to forward DNS). Would 10 %{p} count as 20 DNS lookups? This compares poorly to CSV which uses a single lookup to obtain the CSV-CSA record. This record also limits the scope of the identity being checked to that of the HELO/EHLO. This record also uses a prefix as to not usurp a RR type or interfere with other protocols. CSV makes it clear ONLY the HELO is to be checked, which avoids the conflicts present with Sender-ID and SPF algorithms. Sender-ID and SPF essentially reduce the integrity of mail delivery. The disruption caused by these algorithms is without significant benefit, as path registration authorization does not ensure mail is not being spoofed, nor which identity is being checked at each stage, nor allow accurately assessing reputation. Endorsement of SPF by those that also block bounce messages seems to be indicating a willingness to trade reliability for expediency. In the long run, this approach will be expensive. There are efforts outside of SPF that are focusing on the problem. Mail integrity can be retained, and accountability accurately determined without putting the email and DNS system at risk. May I encourage some of the energy placed upon SPF to focus on the MASS and CLEAR work groups? http://mipassoc.org/mass/ http://mipassoc.org/clear/ -Doug From owner-ietf-mxcomp@mail.imc.org Sat Jan 29 19:04:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26229 for ; Sat, 29 Jan 2005 19:04: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 j0TNYMuO022592; Sat, 29 Jan 2005 15:34: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 j0TNYM0B022591; Sat, 29 Jan 2005 15:34:22 -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 j0TNYJ3T022578 for ; Sat, 29 Jan 2005 15:34:22 -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 549F4170BA for ; Sat, 29 Jan 2005 18:28:59 -0500 (EST) From: "Alan DeKok" To: "IETF MARID WG" Subject: Re: So here it is one year later... In-Reply-To: Your message of "Sat, 29 Jan 2005 12:54:09 CST." Date: Sat, 29 Jan 2005 18:28:59 -0500 Message-Id: <20050129232859.549F4170BA@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: wayne wrote: > The chairs/AD asked for consensus from the group. The consensus was to > look at the 2821 identities first and then look at the 2822 > identities. The charter promised that once this decision was reached, > that all further discussions on other identities would be ruled out of > scope. i.e. http://www.imc.org/ietf-mxcomp/mail-archive/msg01161.html My recollection was that there was a later consensus call, but I can't find the post. The closest is: http://www.imc.org/ietf-mxcomp/mail-archive/msg01864.html Where you note that the consensus of the WG (simple hum, unconfirmed on the list) was changed to RFC 2822. > MARID showed just how much more important political considerations are > in making decisions than technical considerations. Almost all spam/anti-spam discussion is political. We know how to stop all spam: turn off all email. Past that, the "technical" decision to turn off limited portions of email for some reason (e.g. message/host validation) quickly becomes political. Some people will not implement the scheme themselves, and others oppose a scheme in general. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Sun Jan 30 04:36:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15394 for ; Sun, 30 Jan 2005 04:36: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 j0U8anco005354; Sun, 30 Jan 2005 00:36: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 j0U8anBv005353; Sun, 30 Jan 2005 00:36:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0U8alCl005285 for ; Sun, 30 Jan 2005 00:36:47 -0800 (PST) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1CvAZI-0006H5-6X for ietf-mxcomp@imc.org; Sun, 30 Jan 2005 09:36:28 +0100 Received: from 213.191.77.38 ([213.191.77.38]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 30 Jan 2005 09:36:28 +0100 Received: from nobody by 213.191.77.38 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 30 Jan 2005 09:36:28 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: So here it is one year later... Date: Sun, 30 Jan 2005 09:33:38 +0100 Organization: Lines: 73 Message-ID: <41FC9BE2.2A5C@xyzzy.claranet.de> References: <700EEF5641B7E247AC1C9B82C05D125D055536@srv1.pan-am.ca> <41F942E4.4E18@xyzzy.claranet.de> <1106872082.6443.96.camel@SJC-Office-DHCP-156.mail-abuse.org> <41F9AF92.717D@xyzzy.claranet.de> <1106896265.11035.66.camel@SJC-Office-DHCP-156.mail-abuse.org> <4DD53697-7189-11D9-9CD0-000D9358DFD8@hxr.us> <8617533D-7210-11D9-9CD0-000D9358DFD8@hxr.us> <1107041414.7186.122.camel@littlejoy> 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: 213.191.77.38 X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean, Found to be clean X-Gmane-MailScanner-SpamScore: ss X-MailScanner-From: gim-ietf-mxcomp@m.gmane.org Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Douglas Otis wrote: > Those publishing SPF records risk causing their mail being > forwarded by various recipients to be blocked or lost, They don't "risk" this, they _want_ it, it's the idea of RMX or SPF -all that "mail from A" must come from an IP allowed by the sender policy of A. If "mail from A" arrives at C from another IP B, then C would reject it. If B was a spammer or mail worm the spam or worm is in fact "lost", again that's the very idea of RMX or SPF FAIL. If B was a legit MTA it would create a bounce message to A, and the mail is not lost. Either A screwed up, maybe he forgot to include B in his sender policy, or B screwed up, maybe a secondary MX forwarded mail to a primary MX, and the latter tested SPF without white-listing the secondary MX. SPF tests work as expected at the border defined by A, but not later. You can say that you don't like this one and only feature of SPF, but you can't say that it's a bug, because it's the idea. > SPF however can not indicate which identity checking is > desired by the sender. Is it the Sender-ID PRA, the SPF > MAILFROM, or now the SPF MAILFROM and HELO in combination? Not only "now", HELO was "always" mandatory for MAIL FROM:<> and otherwise optional. It's not a new idea. And it's not necessarily a good idea, actually it was one of the things I hoped to solve in the former MARID WG, but unfortunately it wasn't allowed to discuss 2821 and CSV. [The SPF overhead for simple HELO checks is IMHO too big] Sender-ID PRA has nothing to do with classic SPF policies, it only uses a somewhat similar syntax for Sender-ID policies. > This gets even worse with use of this same TXT RR by more > than one faction. If somebody abuses a protocol for a completely different purpose, and it breaks, then he owns the pieces. As far as SPF and I'm concerned the goal is a SPF RR replacing TXT in the future. One of the reasons why I wanted an RfC. The other reason was to get an "official" document which can't be modified only because the authors have a new idea. That's now solved by the formation of the SPF council. > The new SPF processing limits are stated differently They are just clear and better. The handling of all errors is now much more predictable. Minus DNS timeout errors the same policy should now have the same effect with all conforming SPF implementations. > This compares poorly to CSV which uses a single lookup to > obtain the CSV-CSA record. Depends, many policies need only ip4 and all, and that causes no additonal lookup. a, include, exists, and redirect need one lookup. Ignoring the discouraged ptr only mx is "difficult", but OTOH looking up MX is something any MTA knows. Yes, there is a significant potential overhead, that's the price for its great flexibility like per-user policies. s/great/too great/ as you see fit. An SMTP where nothing but the IP is reliable doesn't work. An SMTP where the IP and the MAIL FROM and the HELO make sense again is a huge step forward. Bye. Frank From owner-ietf-mxcomp@mail.imc.org Sun Jan 30 05:43:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20048 for ; Sun, 30 Jan 2005 05:43: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 j0U9vMFP028538; Sun, 30 Jan 2005 01:57: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 j0U9vMkj028537; Sun, 30 Jan 2005 01:57:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0U9vLGH028523 for ; Sun, 30 Jan 2005 01:57:21 -0800 (PST) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1CvBpL-0007lf-Pt for ietf-mxcomp@imc.org; Sun, 30 Jan 2005 10:57:07 +0100 Received: from 213.191.77.38 ([213.191.77.38]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 30 Jan 2005 10:57:07 +0100 Received: from nobody by 213.191.77.38 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 30 Jan 2005 10:57:07 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: So here it is one year later... Date: Sun, 30 Jan 2005 10:53:40 +0100 Organization: Lines: 16 Message-ID: <41FCAEA4.2A4D@xyzzy.claranet.de> References: <41FB7043.5F74@xyzzy.claranet.de> <20050129171245.CC20016CC4@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: 213.191.77.38 X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean, Found to be clean X-Gmane-MailScanner-SpamScore: s X-MailScanner-From: gim-ietf-mxcomp@m.gmane.org Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Alan DeKok wrote: > The consensus was to look at 2822 and Sender-Id. That was a decree and no consensus. CSV was declared off topic until the 2822 discussions were ready, and as a result CSV was never discussed. Same problem for classic SPF, minus the one week when the former WG chair asked for a spf2.0/mfrom draft, and let the WG be closed three (?) days after it was published. There's a serious problem with RfC 3710 (4.3) vs. RfC 2418 (4). It's a bad sign that 3710 and 2418 are now among the relatively few RfCs that I know, thanks but no thanks to MARID. :-( Bye, Frank From owner-ietf-mxcomp@mail.imc.org Sun Jan 30 18:34:05 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13198 for ; Sun, 30 Jan 2005 18:34:04 -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 j0UMihJN086981; Sun, 30 Jan 2005 14:44: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 j0UMihTl086980; Sun, 30 Jan 2005 14:44:43 -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 j0UMihBa086973 for ; Sun, 30 Jan 2005 14:44:43 -0800 (PST) (envelope-from dotis@mail-abuse.org) Received: from 192.168.2.47 (64-142-13-68.dsl.static.sonic.net [64.142.13.68]) (authenticated bits=0) by a.mail.sonic.net (8.13.3/8.13.3) with ESMTP id j0UMie9d001664 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 30 Jan 2005 14:44:40 -0800 Subject: Re: So here it is one year later... From: Douglas Otis To: Frank Ellermann Cc: ietf-mxcomp@imc.org In-Reply-To: <41FC9BE2.2A5C@xyzzy.claranet.de> References: <700EEF5641B7E247AC1C9B82C05D125D055536@srv1.pan-am.ca> <41F942E4.4E18@xyzzy.claranet.de> <1106872082.6443.96.camel@SJC-Office-DHCP-156.mail-abuse.org> <41F9AF92.717D@xyzzy.claranet.de> <1106896265.11035.66.camel@SJC-Office-DHCP-156.mail-abuse.org> <4DD53697-7189-11D9-9CD0-000D9358DFD8@hxr.us> <8617533D-7210-11D9-9CD0-000D9358DFD8@hxr.us> <1107041414.7186.122.camel@littlejoy> <41FC9BE2.2A5C@xyzzy.claranet.de> Content-Type: text/plain Date: Sun, 30 Jan 2005 14:44:27 -0800 Message-Id: <1107125067.7662.123.camel@littlejoy> Mime-Version: 1.0 X-Mailer: Evolution 2.0.1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sun, 2005-01-30 at 09:33 +0100, Frank Ellermann wrote: > Douglas Otis wrote: > > > Those publishing SPF records risk causing their mail being > > forwarded by various recipients to be blocked or lost, > > They don't "risk" this, they _want_ it, it's the idea of RMX > or SPF -all that "mail from A" must come from an IP allowed > by the sender policy of A. If "mail from A" arrives at C > from another IP B, then C would reject it. > > If B was a spammer or mail worm the spam or worm is in fact > "lost", again that's the very idea of RMX or SPF FAIL. If B > was a legit MTA it would create a bounce message to A, and > the mail is not lost. > > Either A screwed up, maybe he forgot to include B in his > sender policy, or B screwed up, maybe a secondary MX forwarded > mail to a primary MX, and the latter tested SPF without > white-listing the secondary MX. SPF tests work as expected > at the border defined by A, but not later. > > You can say that you don't like this one and only feature of > SPF, but you can't say that it's a bug, because it's the idea. Those publishing SPF records want their mail to go missing? There is no means to know which recipient may be using a forwarded account. There is no means to prevent a "screw up" with SPF. Forwarding is a common practice within colleges, societies, and many providers. Validating the legitimacy of an MTA can take place within a single lookup of a small CSV-CSA record. A single lookup does not increase the risk to DoS attacks, and also does not create inadvertent loss of mail, as does SPF. > > SPF however can not indicate which identity checking is > > desired by the sender. Is it the Sender-ID PRA, the SPF > > MAILFROM, or now the SPF MAILFROM and HELO in combination? > > Not only "now", HELO was "always" mandatory for MAIL FROM:<> > and otherwise optional. It's not a new idea. And it's not > necessarily a good idea, actually it was one of the things I > hoped to solve in the former MARID WG, but unfortunately it > wasn't allowed to discuss 2821 and CSV. [The SPF overhead > for simple HELO checks is IMHO too big] The draft just submitted changes both when the HELO is checked and the outcome of this checking. Previously, someone ignoring the use of SPF for HELO would likely find their bounce messages treated as from an "unknown" source. With the change being made, the HELO may now be checked against a record found at the zone apex. This unexpected change could cause their bounces to be rejected AND also their mail to be rejected, as the HELO check is to be done in combination with the MAILFROM rather than as an alternative for handling bounces. These are changes publishers could not anticipate. I agree, the overhead for HELO checking would be unacceptably high with SPF, in addition to the other problems SPF records create. > Sender-ID PRA has nothing to do with classic SPF policies, it > only uses a somewhat similar syntax for Sender-ID policies. Pobox still claims Sender Policy Framework is the essential part of Sender-ID. It matters how the publishers are basing their decisions. I have yet to hear any admonishment by proponents that when publishing SPF, expect some of your mail to be lost or rejected due to problems with either SPF et al or Sender-ID algorithms. This is shameful. > > This gets even worse with use of this same TXT RR by more > > than one faction. > > If somebody abuses a protocol for a completely different > purpose, and it breaks, then he owns the pieces. As far as > SPF and I'm concerned the goal is a SPF RR replacing TXT in > the future. One of the reasons why I wanted an RfC. > > The other reason was to get an "official" document which can't > be modified only because the authors have a new idea. That's > now solved by the formation of the SPF council. A mechanism built upon a strategy that can not support revision does not require a council. Nor would it likely find approval by a standards organization that cares about compatibility and a need to support orderly change. > > The new SPF processing limits are stated differently > > They are just clear and better. The handling of all errors is > now much more predictable. Minus DNS timeout errors the same > policy should now have the same effect with all conforming SPF > implementations. This conclusion is guess work. You could be right, but those that have published what is now considered too many records may find their mail being rejected. The SPF timeout imposed still ignores UDP fallback. Normal exponential fallback ensures congestion avoidance. This oversight for such an intensive use of DNS is a serious concern. > > This compares poorly to CSV which uses a single lookup to > > obtain the CSV-CSA record. > > Depends, many policies need only ip4 and all, and that causes > no additonal lookup. a, include, exists, and redirect need one > lookup. Ignoring the discouraged ptr only mx is "difficult", > but OTOH looking up MX is something any MTA knows. Yes, there > is a significant potential overhead, that's the price for its > great flexibility like per-user policies. Will imposing the task of implementing the sender's per-user policies upon the receiving SMTP server scale? Is it reasonable to expect the receiving SMTP server to perform a hundred lookups per message? I see this "great" flexibility stemming from an overly ambitious marketing effort that continues to ignore serious problems. I agree with you, there is a need to move toward a name basis to establish meaningful feedback to administrators of MTA systems. A name basis would help centralize the effort at getting rid of abuse. This can be safely achieved via the efforts in MASS and CLEAR, but not with SPF. -Doug From owner-ietf-mxcomp@mail.imc.org Mon Jan 31 05:42:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12144 for ; Mon, 31 Jan 2005 05:42:33 -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 j0V7f4NY060943; Sun, 30 Jan 2005 23:41: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 j0V7f4Mn060942; Sun, 30 Jan 2005 23:41:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sendmail.metro.cx (sonolo.xs4all.nl [80.126.206.91]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0V7ewvQ060804 for ; Sun, 30 Jan 2005 23:41:03 -0800 (PST) (envelope-from gmc@metro.cx) Received: from dave.dh.sono (dave.dh.sono [10.1.2.5]) by sendmail.metro.cx (8.13.1/8.13.1) with ESMTP id j0V7einR094265; Mon, 31 Jan 2005 07:40:44 GMT Received-SPF: none (sendmail.metro.cx: 10.1.2.5 is neither permitted nor denied by domain of metro.cx>) client-ip=10.1.2.5; envelope-from=; helo=dave.dh.sono; Received: from dave.dh.sono (localhost [127.0.0.1]) by dave.dh.sono (8.13.1/8.12.9) with ESMTP id j0V7ehxN015869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 Jan 2005 08:40:44 +0100 Received: (from gmc@localhost) by dave.dh.sono (8.13.1/8.13.1/Submit) id j0V7ehbL015868; Mon, 31 Jan 2005 08:40:43 +0100 X-Authentication-Warning: dave.dh.sono: gmc set sender to gmc@metro.cx using -f Date: Mon, 31 Jan 2005 08:40:43 +0100 From: gmc@metro.cx To: Douglas Otis Cc: Frank Ellermann , ietf-mxcomp@imc.org Subject: Re: So here it is one year later... Message-ID: <20050131074042.GA15845@metro.cx> References: <41F9AF92.717D@xyzzy.claranet.de> <1106896265.11035.66.camel@SJC-Office-DHCP-156.mail-abuse.org> <4DD53697-7189-11D9-9CD0-000D9358DFD8@hxr.us> <8617533D-7210-11D9-9CD0-000D9358DFD8@hxr.us> <1107041414.7186.122.camel@littlejoy> <41FC9BE2.2A5C@xyzzy.claranet.de> <1107125067.7662.123.camel@littlejoy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1107125067.7662.123.camel@littlejoy> X-PGP-Key: http://www.metro.cx/pubkey-gmc.asc User-Agent: Mutt/1.5.6i X-Helo-Milter-Helo: dave.dh.sono X-Helo-Milter-Hostname: dave.dh.sono X-Helo-Milter-Ip: 10.1.2.5 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, Jan 30, 2005 at 02:44:27PM -0800, Douglas Otis wrote: > Those publishing SPF records want their mail to go missing? There is no > means to know which recipient may be using a forwarded account. There > is no means to prevent a "screw up" with SPF. Forwarding is a common > practice within colleges, societies, and many providers. Validating the > legitimacy of an MTA can take place within a single lookup of a small > CSV-CSA record. A single lookup does not increase the risk to DoS > attacks, and also does not create inadvertent loss of mail, as does > SPF. The forwarding problem is known and information is on spf.pobox.com (which still is the primary source for information about spf). It's not like it is 'the big secret of spf' that there is a forwarding issue. I suppose people read this site before publishing, so they must know about the forwarding problem. However, people still publish. I'm not going to guess at the motivations of these people, i'm not a pyschologist. Fact is that despite the forwarding issue, people do publish. I can only elaborate a bit on my own motivations: if a message is forwarded and then bounces because of spf, the bounce will contain the actual email address to which the message was forwarded. I can resend, perhaps attaching a small note about the fact that the forwarding did not work. I have never had serious problems with this issue. Koen -- K.F.J. Martens, Sonologic, http://www.sonologic.nl/ Networking, embedded systems, unix expertise, artificial intelligence. Public PGP key: http://www.metro.cx/pubkey-gmc.asc Wondering about the funny attachment your mail program can't read? Visit http://www.openpgp.org/ From owner-ietf-mxcomp@mail.imc.org Mon Jan 31 08:32:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29395 for ; Mon, 31 Jan 2005 08:32: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 j0VA1oms009793; Mon, 31 Jan 2005 02:01: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 j0VA1ojT009790; Mon, 31 Jan 2005 02:01:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0VA1mun009771 for ; Mon, 31 Jan 2005 02:01:48 -0800 (PST) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1CvYNE-0007F9-3q for ietf-mxcomp@imc.org; Mon, 31 Jan 2005 11:01:36 +0100 Received: from c-134-88-186.hh.dial.de.ignite.net ([62.134.88.186]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 31 Jan 2005 11:01:36 +0100 Received: from nobody by c-134-88-186.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 31 Jan 2005 11:01:36 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: So here it is one year later... Date: Mon, 31 Jan 2005 10:56:06 +0100 Organization: Lines: 111 Message-ID: <41FE00B6.470D@xyzzy.claranet.de> References: <700EEF5641B7E247AC1C9B82C05D125D055536@srv1.pan-am.ca> <41F942E4.4E18@xyzzy.claranet.de> <1106872082.6443.96.camel@SJC-Office-DHCP-156.mail-abuse.org> <41F9AF92.717D@xyzzy.claranet.de> <1106896265.11035.66.camel@SJC-Office-DHCP-156.mail-abuse.org> <4DD53697-7189-11D9-9CD0-000D9358DFD8@hxr.us> <8617533D-7210-11D9-9CD0-000D9358DFD8@hxr.us> <1107041414.7186.122.camel@littlejoy> <41FC9BE2.2A5C@xyzzy.claranet.de> <1107125067.7662.123.camel@littlejoy> 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-186.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-MailScanner-From: gim-ietf-mxcomp@m.gmane.org Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Douglas Otis wrote: > There is no means to know which recipient may be using a > forwarded account. Yes, it's a "sender policy", not a "recipient's policy", and not a "mediating source policy" (one of the mail-arch terms). > Forwarding is a common practice within colleges, societies, > and many providers. Sure, there's nothing wrong with forwarding, each and every mail I send is forwarded at least twice, from me to a smart host, from the smart host to an MX of the recipient, or to an MDA in the case of local users. What happens beyond the MX of the recipient is none of my business, as you say there's no way for me to know what the recipient does. My "sender policy" cannot cover forwarding by the recipient. If he wants this for some reason, he has to use his own MAIL FROM and his own "sender policy". > Validating the legitimacy of an MTA can take place within > a single lookup of a small CSV-CSA record. Fine, I've no problem if my mail providers do this for their smart hosts, or if they test it for incoming mails at their MXs. CSV / SPF / SPF+CSV / ... are all okay, as ar as I'm concerned. > With the change being made, the HELO may now be checked > against a record found at the zone apex. The "zone cut" isn't a new feature, it was in the last SPF draft published before MARID. BTW, Tony's blog mentions that CSV now also solved this problem, but I don't find how, it's apparently not in the last (now expired) CSV draft. Here's a summary of my SPF experiences in the last 10 months: Mar 04: some spammer(s) start to abuse "my" vanity domain, I get about 1000 erroneous bounces / vacation mails / challenges / etc. per day. Apr 04: My ISP publishes a sender policy. Intuition or bug, neither my ISP nor me saw the "minor" problem, that this sender policy didn't cover "my" vanity domain. May 04: Wildcard added, now it works even without "zone cut". "Zone cut" also added to the SPF draft replacing an older "match_subdomains" construct. Sep 04: 180,000 bounces etc. so far in my mailbox (JFTR, I'm a modem user) Oct 04: My spammer(s) got the SPF idea, again zero bounces etc. per day Jan 05: So far not a single problem with SPF from my POV, and 4*30*1000 = 120,000 avoided bounces etc. since Oct 04. You can discuss "the better is the enemy of the good" in MASS and CLEAR as long as you like, I have what I wanted, and SPF was good enough for me. Let them all disable SPF as soon as something better exists and works, no problem. > I agree, the overhead for HELO checking would be unacceptably > high with SPF Where that's the case (it depends on the sender policy) the sender could arrange his HELO domains to avoid it. And if CSV has a better solution than SPF's "zone cut" for spoofed HELOs, I'd be interested what it is - I'm always curious. > when publishing SPF, expect some of your mail to be lost or > rejected due to problems with either SPF et al or Sender-ID > algorithms. This is shameful. No legit mail is "lost" with SPF, that's FUD. While MARID was a shameful disaster, one of the few results was, that Sender-ID evaluations of SPF sender policies generally do _not_ work. > those that have published what is now considered too many > records may find their mail being rejected. If an erroneous policy "worked" with old SPF implementations, and new implementations report the error, then it's time to fix the old error. > The SPF timeout imposed still ignores UDP fallback. The overall SPF timeout in old drafts was replaced by clear processing limits, which don't depend on a vague accumulated processing time. | Records that are too long to fit in a single UDP packet MAY | be silently ignored. > Is it reasonable to expect the receiving SMTP server to > perform a hundred lookups per message? No, that's why it's impossible, you have constructed a worst case of 1+10+10*10 = 111 DNS lookups for a sender policy with 10 mx directives, each with 10 MX hosts. The average case is probably more like 1 to 4 lookups, I've no data to support this guess. And not necessarily per message, if you'd use CSV or SPF or an RBL to block an IP or to reject all mails after your HELO-test resulted in a FAIL, then you won't test the individual messages in this SMTP session. > This can be safely achieved via the efforts in MASS and > CLEAR, but not with SPF. Please inform "us" when that's ready and deployed. Bye, Frank From owner-ietf-mxcomp@mail.imc.org Mon Jan 31 09:23:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04831 for ; Mon, 31 Jan 2005 09:23: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 j0VDj8GY082773; Mon, 31 Jan 2005 05:45:08 -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 j0VDj8ui082772; Mon, 31 Jan 2005 05:45:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from b1.iprcom.com (b1.iprcom.com [84.234.16.216]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0VDj7lE082761 for ; Mon, 31 Jan 2005 05:45:08 -0800 (PST) (envelope-from ian@iprcom.com) Received: from iprcom.com (localhost [127.0.0.1]) by b1.iprcom.com (8.12.8/8.12.8) with SMTP id j0VDj0JZ030733 for ; Mon, 31 Jan 2005 13:45:00 GMT Received: from 193.128.25.20 (SquirrelMail authenticated user ian) by iprcom.com with HTTP; Mon, 31 Jan 2005 13:45:00 -0000 (GMT) Message-ID: <29201.193.128.25.20.1107179100.squirrel@iprcom.com> In-Reply-To: <20050131074042.GA15845@metro.cx> References: <41F9AF92.717D@xyzzy.claranet.de> <1106896265.11035.66.camel@SJC-Office-DHCP-156.mail-abuse.org> <4DD53697-7189-11D9-9CD0-000D9358DFD8@hxr.us> <8617533D-7210-11D9-9CD0-000D9358DFD8@hxr.us> <1107041414.7186.122.camel@littlejoy> <41FC9BE2.2A5C@xyzzy.claranet.de> <1107125067.7662.123.camel@littlejoy> <20050131074042.GA15845@metro.cx> Date: Mon, 31 Jan 2005 13:45:00 -0000 (GMT) Subject: Re: So here it is one year later... From: "Ian Rogers" To: ietf-mxcomp@imc.org User-Agent: SquirrelMail/1.4.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > K.F.J. Martens wrote: > On Sun, Jan 30, 2005 at 02:44:27PM -0800, Douglas Otis wrote: >> Those publishing SPF records want their mail to go missing? There is no >> means to know which recipient may be using a forwarded account. There >> is no means to prevent a "screw up" with SPF. Forwarding is a common >> practice within colleges, societies, and many providers. Validating the >> legitimacy of an MTA can take place within a single lookup of a small >> CSV-CSA record. A single lookup does not increase the risk to DoS >> attacks, and also does not create inadvertent loss of mail, as does >> SPF. > > The forwarding problem is known and information is on spf.pobox.com > (which still is the primary source for information about spf). It's not > like it is 'the big secret of spf' that there is a forwarding issue. > [snip] > > I can only elaborate a bit on my own motivations: ... As admin of several dozen domains I publish SPF records to avoid litigation! Considering that sending a virus as an offence against the Computer Misuse Act (in the UK at least) every now and then I get irate messages accusing my servers of sending out spam or viruses. A quick glance through the header of the accused message confirms that it was spoofed and then I'm able to write back saying "no, it wasn't my server that sent it and I've published the SPF records to prove it. Please encourage your ISP to use SPF" and give the pobox URL for good luck :-) I'm happy to take the flack for messages not being delivered due to "anonymous" forwarding. Note there is a difference between a person forwarding a message from their MUA (which is effectively generating a new message with the content of another - which SPF handles fine) and "anonymous remailers" (where a forwarding 'bot effectively spoofs itself as the original sender in order to forward the message on verbatim to the ultimate recipient). In the Good Old Days the anonymous remailer was a useful tool. But in *this* day and age of forged-sender spam, Joe jobs and phishing that functionality must (unfortunately) be considered broken. You (Douglas and other anti-SPF posters) are quite correct in saying that SPF won't stamp all spam (but then SPF never claimed it would) and that it breaks anonymous forwarding (which SPF always acknowledged) but SPF+SRS is the best, current, first-baby-steps solution available for stamping out forged sender - which *is* IMHO the essential first step for eliminating joe-jobs, phishing and a significant subset of spam. Regards, Ian. From owner-ietf-mxcomp@mail.imc.org Mon Jan 31 10:02:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09164 for ; Mon, 31 Jan 2005 10:02: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 j0VEZtfA087536; Mon, 31 Jan 2005 06:35:55 -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 j0VEZtt1087535; Mon, 31 Jan 2005 06:35:55 -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 j0VEZX2t087499 for ; Mon, 31 Jan 2005 06:35:48 -0800 (PST) (envelope-from SRS0+e8f8a98abdfe372b344e+526+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.43 #1 (Red Hat Linux)) id 1Cvce6-00065X-LI; Mon, 31 Jan 2005 09:35:20 -0500 Subject: Re: So here it is one year later... From: David Woodhouse To: gmc@metro.cx Cc: Douglas Otis , Frank Ellermann , ietf-mxcomp@imc.org In-Reply-To: <20050131074042.GA15845@metro.cx> References: <41F9AF92.717D@xyzzy.claranet.de> <1106896265.11035.66.camel@SJC-Office-DHCP-156.mail-abuse.org> <4DD53697-7189-11D9-9CD0-000D9358DFD8@hxr.us> <8617533D-7210-11D9-9CD0-000D9358DFD8@hxr.us> <1107041414.7186.122.camel@littlejoy> <41FC9BE2.2A5C@xyzzy.claranet.de> <1107125067.7662.123.camel@littlejoy> <20050131074042.GA15845@metro.cx> Content-Type: text/plain Date: Mon, 31 Jan 2005 14:35:13 +0000 Message-Id: <1107182113.19262.172.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 Mon, 2005-01-31 at 08:40 +0100, gmc@metro.cx wrote: > The forwarding problem is known and information is on spf.pobox.com > (which still is the primary source for information about spf). It's not > like it is 'the big secret of spf' that there is a forwarding issue. I > suppose people read this site before publishing, so they must know > about the forwarding problem. However, people still publish. I'm not > going to guess at the motivations of these people, i'm not a pyschologist. > Fact is that despite the forwarding issue, people do publish. The forwarding problem isn't exactly shouted from the rooftops on the SPF site, and people rarely actually think things through for themselves, unfortunately. If you point those _same_ people at something like http://david.woodhou.se/why-not-spf.html they often seem to change their mind again and stop publishing records, in my experience. -- dwmw2 From owner-ietf-mxcomp@mail.imc.org Mon Jan 31 10:06:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09644 for ; Mon, 31 Jan 2005 10:06: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 j0VEh2eT088044; Mon, 31 Jan 2005 06:43: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 j0VEh2oK088043; Mon, 31 Jan 2005 06:43:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sendmail.metro.cx (sonolo.xs4all.nl [80.126.206.91]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0VEh0sa088035 for ; Mon, 31 Jan 2005 06:43:01 -0800 (PST) (envelope-from gmc@metro.cx) Received: from dave.dh.sono (dave.dh.sono [10.1.2.5]) by sendmail.metro.cx (8.13.1/8.13.1) with ESMTP id j0VEgts3029720; Mon, 31 Jan 2005 14:42:55 GMT Received-SPF: none (sendmail.metro.cx: 10.1.2.5 is neither permitted nor denied by domain of metro.cx>) client-ip=10.1.2.5; envelope-from=; helo=dave.dh.sono; Received: from dave.dh.sono (localhost [127.0.0.1]) by dave.dh.sono (8.13.1/8.12.9) with ESMTP id j0VEgtE1017379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 Jan 2005 15:42:55 +0100 Received: (from gmc@localhost) by dave.dh.sono (8.13.1/8.13.1/Submit) id j0VEgtKU017378; Mon, 31 Jan 2005 15:42:55 +0100 X-Authentication-Warning: dave.dh.sono: gmc set sender to gmc@metro.cx using -f Date: Mon, 31 Jan 2005 15:42:55 +0100 From: "K.F.J. Martens" To: David Woodhouse Cc: ietf-mxcomp@imc.org Subject: Re: So here it is one year later... Message-ID: <20050131144255.GL16987@metro.cx> References: <4DD53697-7189-11D9-9CD0-000D9358DFD8@hxr.us> <8617533D-7210-11D9-9CD0-000D9358DFD8@hxr.us> <1107041414.7186.122.camel@littlejoy> <41FC9BE2.2A5C@xyzzy.claranet.de> <1107125067.7662.123.camel@littlejoy> <20050131074042.GA15845@metro.cx> <1107182113.19262.172.camel@hades.cambridge.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1107182113.19262.172.camel@hades.cambridge.redhat.com> X-PGP-Key: http://www.metro.cx/pubkey-gmc.asc User-Agent: Mutt/1.5.6i X-Helo-Milter-Helo: dave.dh.sono X-Helo-Milter-Hostname: dave.dh.sono X-Helo-Milter-Ip: 10.1.2.5 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Jan 31, 2005 at 02:35:13PM +0000, David Woodhouse wrote: > On Mon, 2005-01-31 at 08:40 +0100, gmc@metro.cx wrote: > > The forwarding problem is known and information is on spf.pobox.com > > (which still is the primary source for information about spf). It's not > > like it is 'the big secret of spf' that there is a forwarding issue. I > > suppose people read this site before publishing, so they must know > > about the forwarding problem. However, people still publish. I'm not > > going to guess at the motivations of these people, i'm not a pyschologist. > > Fact is that despite the forwarding issue, people do publish. > > The forwarding problem isn't exactly shouted from the rooftops on the > SPF site, and people rarely actually think things through for > themselves, unfortunately. If you point those _same_ people at something > like http://david.woodhou.se/why-not-spf.html they often seem to change > their mind again and stop publishing records, in my experience. Although not correct in some places, it as a funny web page indeed! In my experience, people have read that page and either don't care, don't understand or don't believe what is being presented. And given the incorectness of some of the statements on that page, who can blame them. Anyway, this thread is going nowhere fast, so let's close it allright? Kind regards, Koen Martens -- K.F.J. Martens, Sonologic, http://www.sonologic.nl/ Networking, hosting, embedded systems, unix, artificial intelligence. Public PGP key: http://www.metro.cx/pubkey-gmc.asc Wondering about the funny attachment your mail program can't read? Visit http://www.openpgp.org/ From owner-ietf-mxcomp@mail.imc.org Mon Jan 31 12:24:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26170 for ; Mon, 31 Jan 2005 12:24:26 -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 j0VGou1D000389; Mon, 31 Jan 2005 08:50: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 j0VGou0o000388; Mon, 31 Jan 2005 08:50:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0VGokNN000351 for ; Mon, 31 Jan 2005 08:50:46 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc01.vcorp.ad.vrsn.com (mailer4.verisign.com [65.205.251.53]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id j0VGocN7018426; Mon, 31 Jan 2005 08:50:39 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 31 Jan 2005 08:50:38 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'David Woodhouse'" , gmc@metro.cx Cc: Douglas Otis , Frank Ellermann , ietf-mxcomp@imc.org Subject: RE: So here it is one year later... Date: Mon, 31 Jan 2005 08:50:38 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The main point of the Web page seems to be that Domain Keys/IIM does the whole thing much better. Like we did not know that already, the point of SPF/Sender-Id is that it will be a while yet before we have a merged spec for Domain-Keys/IIM we are still in trial stages. It makes a lot of sense to go forward with the low hanging fruit authentication that SPF provides. SPF now includes the HELO check so CSV is utterly redundant, it is an unhelpful contribution to the debate at this point. The promoters of CSV have not been working to win friends and influence people. 'nuff said. For DK to work we need a policy layer, that will almost certainly be linked to the deployed SPF/Sender-ID standard. > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of David Woodhouse > Sent: Monday, January 31, 2005 9:35 AM > To: gmc@metro.cx > Cc: Douglas Otis; Frank Ellermann; ietf-mxcomp@imc.org > Subject: Re: So here it is one year later... > > > > On Mon, 2005-01-31 at 08:40 +0100, gmc@metro.cx wrote: > > The forwarding problem is known and information is on spf.pobox.com > > (which still is the primary source for information about spf). It's > > not like it is 'the big secret of spf' that there is a forwarding > > issue. I suppose people read this site before publishing, > so they must > > know about the forwarding problem. However, people still > publish. I'm > > not going to guess at the motivations of these people, i'm not a > > pyschologist. Fact is that despite the forwarding issue, people do > > publish. > > The forwarding problem isn't exactly shouted from the > rooftops on the SPF site, and people rarely actually think > things through for themselves, unfortunately. If you point > those _same_ people at something like > http://david.woodhou.se/why-not-spf.html they > often seem to > change their mind again and stop publishing records, in my experience. > > -- > dwmw2 > From owner-ietf-mxcomp@mail.imc.org Mon Jan 31 13:32:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04198 for ; Mon, 31 Jan 2005 13:32:22 -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 j0VHgYii003980; Mon, 31 Jan 2005 09:42: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 j0VHgYub003979; Mon, 31 Jan 2005 09:42:34 -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 j0VHgT03003968 for ; Mon, 31 Jan 2005 09:42:34 -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 8601516CC4 for ; Mon, 31 Jan 2005 12:37:05 -0500 (EST) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: So here it is one year later... In-Reply-To: Your message of "Sun, 30 Jan 2005 14:44:27 PST." <1107125067.7662.123.camel@littlejoy> Date: Mon, 31 Jan 2005 12:37:05 -0500 Message-Id: <20050131173705.8601516CC4@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Douglas Otis wrote: > Those publishing SPF records want their mail to go missing? Any mail they didn't send. > There is no means to know which recipient may be using a forwarded > account. Yup. Likewise, there's no way to know who on the net will be sending spam forged to be "from" your domain. > Forwarding is a common practice within colleges, societies, and many > providers. As is spamming. As is drunk driving. Having something a "common practice" doesn't mean it's right. > Validating the legitimacy of an MTA can take place within a single > lookup of a small CSV-CSA record. Which is a great idea, and has been integrated into SPF. > A single lookup does not increase the risk to DoS attacks, and also > does not create inadvertent loss of mail, as does SPF. No, "intentional" loss of mail. I intend every single spam which uses my domain name to be discarded. I would rather have others discard them than have those people complain to me that I'm spamming them. This is not to say SPF is perfect. Other methods do much of what SPF does, without it's problems. But as a concept, the domain owner should be able to control the use of that name. If we can't agree on that, then the only logical alternative is that third parties can use someones name without their consent, and therefore forged spam is OK. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Mon Jan 31 14:04:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07974 for ; Mon, 31 Jan 2005 14:04: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 j0VIcWkk007918; Mon, 31 Jan 2005 10:38: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 j0VIcUGC007916; Mon, 31 Jan 2005 10:38:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (schlitt.net [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0VIcNlK007898 for ; Mon, 31 Jan 2005 10:38:25 -0800 (PST) (envelope-from wayne@schlitt.net) Received: from footbone.schlitt.net ([206.222.212.237] helo=schlitt.net) by backbone.midwestcs.com with esmtp (Exim 4.43) id 1CvgR8-0001vw-KB for ietf-mxcomp@imc.org; Mon, 31 Jan 2005 12:38:19 -0600 To: "IETF MARID WG" References: From: wayne Mail-Copies-To: nobody Reply-To: "IETF MARID WG" Date: Mon, 31 Jan 2005 12:38:03 -0600 In-Reply-To: (Phillip Hallam-Baker's message of "Mon, 31 Jan 2005 08:50:38 -0800") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Corporate Culture, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of schlitt.net designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@schlitt.net; helo=schlitt.net; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: So here it is one year later... Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on backbone.midwestcs.com X-Spam-Status: No, score=-6.6 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00, GREYLIST_ISWHITE autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.1 (built Tue, 17 Aug 2004 11:06:07 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In "Hallam-Baker, Phillip" writes: > The main point of the Web page seems to be that Domain Keys/IIM does the > whole thing much better. > > Like we did not know that already, [...] Actually, that is something I don't know. Despite asking several times on the MASS mailing list, I have yet to see any data on the false positive rates for DK, IIM, William's DK-IIM merged system, CSV, or SES. So far, all I've seen is people claiming that their systems work better than SPF, with no data to back it up. (Often, there is data to back up the claim that SPF has false positives, but we *do* know that.) SPF breaks forwarding unless the sender uses SES, the forwarder uses SRS, or the receiver uses a whitelist. DK breaks mailing lists, and from what I can tell from reading MASS, the DK folks don't see that as a problem. The other crypto systems at least *try* to not break mailing lists, but it not at all clear how well they do in practice. (SES looks like it will do the best, but it requires some sort of call-back to work.) CSV breaks very little, but no one really seems to care. Despite having *FAR* more publicity in the 9(?) months since it was first announced, far fewer people are using its HELO checking than were using SPF's HELO checking in the first 6 months since it was announced. Of course, the real growth of SPF didn't happen until after 6 months since it took that long to get a slushy spec done. I really like the ideas behind the crypto systems, but they have a bunch of technical problems with them that haven't been figured out yet. Considering that the technical problems with both crypto systems and IP systems have been pretty obvious since the spring of 2003, I'm not sure that good solutions will be found for either type of system. It was based on my analysis of the various technical problems will all systems that I decided that IP based solutions would have the most potential and therefore I started helping out with SPF. 18 months later, it still looks like I made the right choice. So, please, before you go claiming that DK/IIM is "better", provide some data to back up that claim. -wayne From owner-ietf-mxcomp@mail.imc.org Mon Jan 31 14:18:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09186 for ; Mon, 31 Jan 2005 14:18: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 j0VItrpL009518; Mon, 31 Jan 2005 10:55:53 -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 j0VItrR2009517; Mon, 31 Jan 2005 10:55:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (schlitt.net [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0VItqWs009509 for ; Mon, 31 Jan 2005 10:55:52 -0800 (PST) (envelope-from wayne@schlitt.net) Received: from footbone.schlitt.net ([206.222.212.237] helo=schlitt.net) by backbone.midwestcs.com with esmtp (Exim 4.43) id 1Cvgi5-0002DN-Bq for ietf-mxcomp@imc.org; Mon, 31 Jan 2005 12:55:51 -0600 To: "IETF MARID WG" References: <20050131173705.8601516CC4@mail.nitros9.org> From: wayne Mail-Copies-To: nobody Reply-To: "IETF MARID WG" Date: Mon, 31 Jan 2005 12:55:40 -0600 In-Reply-To: <20050131173705.8601516CC4@mail.nitros9.org> (Alan DeKok's message of "Mon, 31 Jan 2005 12:37:05 -0500") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Corporate Culture, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of schlitt.net designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@schlitt.net; helo=schlitt.net; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: So here it is one year later... Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on backbone.midwestcs.com X-Spam-Status: No, score=-6.6 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00, GREYLIST_ISWHITE autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.1 (built Tue, 17 Aug 2004 11:06:07 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <20050131173705.8601516CC4@mail.nitros9.org> "Alan DeKok" writes: > Douglas Otis wrote: > >> There is no means to know which recipient may be using a forwarded >> account. > > Yup. Likewise, there's no way to know who on the net will be > sending spam forged to be "from" your domain. If the sending domain uses SES, then it can detect the forwarder situation and not cause an SPF failure. (This can also be used for roaming users.) The cost is an extra DNS lookup. The receiving MTA can know if email is being sent through a forwarder. For example, the user can tell the system via a whitelist request. Spamassassin's auto-whitelists will automatically help out a great deal because it detects the overall spamminess of the forwarder and that will be enough to override the SPF failures. Better systems could be built to automatically detect forwarders by looking to see source usually fails the 2821.MAILFROM SPF check, but usually passes when the 2822.To: (or cc:) gets an SPF check done on it. > This is not to say SPF is perfect. Other methods do much of what > SPF does, without it's problems. I certainly agree that SPF is not perfect. I am, however, curious which systems you think do much better than SPF and what data you have to back up that opinion. So far, I haven't found any data to back that claim. -wayne From owner-ietf-mxcomp@mail.imc.org Mon Jan 31 15:39:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17869 for ; Mon, 31 Jan 2005 15:39: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 j0VK30mj014349; Mon, 31 Jan 2005 12:03: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 j0VK30E9014348; Mon, 31 Jan 2005 12:03:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0VK2x3q014340 for ; Mon, 31 Jan 2005 12:03:00 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id j0VK2tqd006480 for ; Mon, 31 Jan 2005 12:02:55 -0800 (PST) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 31 Jan 2005 12:02:55 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'IETF MARID WG'" Subject: RE: So here it is one year later... Date: Mon, 31 Jan 2005 12:02:51 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of wayne > Despite asking several times on the MASS mailing list, I have > yet to see any data on the false positive rates for DK, IIM, > William's DK-IIM merged system, CSV, or SES. So far, all > I've seen is people claiming that their systems work better > than SPF, with no data to back it up. (Often, there is data > to back up the claim that SPF has false positives, but we > *do* know that.) They certainly work better in certain circumstances, but at this point I would not want to publish any data because I don't know how typical those circumstances and in any case the issue is irrelevant. DK and SPF have different failure modes. I don't think this is a competition situation. A system with both schemes is much more effective than either on its own. Sure if we started from scratch we would only have one auth scheme. We are retrofitting a legacy system so expect some pain and duplicated effort. Both systems can do much better if we present them as a coherent integrated plan than if we make the mistake of having a standards war. If you think that is a good idea then Jon Callas and I can tell you just how great the PGP/SMIME standards war was for both of our companies. Phill From owner-ietf-mxcomp@mail.imc.org Mon Jan 31 15:54:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19809 for ; Mon, 31 Jan 2005 15:54: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 j0VKJiMU016360; Mon, 31 Jan 2005 12:19: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 j0VKJdRZ016326; Mon, 31 Jan 2005 12:19:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0VKJREO016236 for ; Mon, 31 Jan 2005 12:19:36 -0800 (PST) (envelope-from fenton@cisco.com) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 31 Jan 2005 12:27:49 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0VKIml2018474 for ; Mon, 31 Jan 2005 12:18:49 -0800 (PST) Received: from [128.107.163.248] (dhcp-128-107-163-248.cisco.com [128.107.163.248]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j0VKEgRK031206 for ; Mon, 31 Jan 2005 12:14:42 -0800 Message-ID: <41FE92AD.5090501@cisco.com> Date: Mon, 31 Jan 2005 12:18:53 -0800 From: Jim Fenton User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MARID WG Subject: Re: So here it is one year later... References: In-Reply-To: X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1107202482.524215"; x:"432200"; a:"rsa-sha1"; b:"nofws:1351"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"nhyTvXt67o/i+1ggj0PTtGTyhT4VAdJJG1mc+0uziDdSis6Maqe+gU3HQZPOvmH7O77PNzGc" "KzkYNMaq26MmBij/PZHwF5cTqmVC2Rg3OhklE8YdL1+Pu4BR26OUlRuvh3aG/vnpFLxaM/MdJ1q" "RCDmYhkswd5KLXUEn8+7st9o="; c:"Date: Mon, 31 Jan 2005 12:18:53 -0800"; c:"From: Jim Fenton "; c:"Subject: Re: So here it is one year later..." IIM-VERIFY: s:"y"; v:"y"; r:"-50"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; Home KRS: D72008D63B435A9564100" "322 Query Failure; " Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit wayne wrote: >Despite asking several times on the MASS mailing list, I have yet to >see any data on the false positive rates for DK, IIM, William's DK-IIM >merged system, CSV, or SES. So far, all I've seen is people claiming >that their systems work better than SPF, with no data to back it up. >(Often, there is data to back up the claim that SPF has false >positives, but we *do* know that.) > > We are starting to get some data on false positives (signature breakage) for DK and IIM, but since the number of verifying domains at this point is very small, it would raise more questions than it would answer if we were to publish it. Success rates depend a lot on what the originating and terminating domains' MTAs do with their messages, so having data from a couple of domains is far from representative. It also depends on things like whether the signer, in the case of DK, uses the optional h= parameter to sign specific headers. >SPF breaks forwarding unless the sender uses SES, the forwarder uses >SRS, or the receiver uses a whitelist. > >DK breaks mailing lists, and from what I can tell from reading MASS, >the DK folks don't see that as a problem. The other crypto systems at >least *try* to not break mailing lists, but it not at all clear how >well they do in practice. (SES looks like it will do the best, but it >requires some sort of call-back to work.) > > The real answer is to have mailing lists re-sign their messages. While IIM does try not to break mailing lists, and does in some cases, it's imperfect and intended primarily as a expedient until they do. If you'd like to discuss this more, let's move to the ietf-mailsig list. -Jim From owner-ietf-mxcomp@mail.imc.org Mon Jan 31 16:20:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25273 for ; Mon, 31 Jan 2005 16:20: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 j0VKrNFo020236; Mon, 31 Jan 2005 12:53: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 j0VKrNq8020235; Mon, 31 Jan 2005 12:53:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.midwestcs.com (schlitt.net [206.222.212.234]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0VKrMPl020227 for ; Mon, 31 Jan 2005 12:53:22 -0800 (PST) (envelope-from wayne@schlitt.net) Received: from footbone.schlitt.net ([206.222.212.237] helo=schlitt.net) by backbone.midwestcs.com with esmtp (Exim 4.43) id 1CviXe-00040z-Np for ietf-mxcomp@imc.org; Mon, 31 Jan 2005 14:53:22 -0600 To: "IETF MARID WG" References: From: wayne Mail-Copies-To: nobody Reply-To: "IETF MARID WG" Date: Mon, 31 Jan 2005 14:53:01 -0600 In-Reply-To: (Phillip Hallam-Baker's message of "Mon, 31 Jan 2005 12:02:51 -0800") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Corporate Culture, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of schlitt.net designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@schlitt.net; helo=schlitt.net; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: So here it is one year later... Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on backbone.midwestcs.com X-Spam-Status: No, score=-6.6 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00, GREYLIST_ISWHITE autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.1 (built Tue, 17 Aug 2004 11:06:07 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In "Hallam-Baker, Phillip" writes: >> [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of wayne > >> Despite asking several times on the MASS mailing list, I have >> yet to see any data on the false positive rates for DK, IIM, >> William's DK-IIM merged system, CSV, or SES. [...] > > They certainly work better in certain circumstances, but at this point I > would not want to publish any data because I don't know how typical those > circumstances and in any case the issue is irrelevant. I can certainly believe this. > DK and SPF have different failure modes. I don't think this is a competition > situation. A system with both schemes is much more effective than either on > its own. I completely, 100% agree and I can not emphisized this enough. I see things like SPF and crypto systems as complementary systems, not competing systems. I'm sorry I forgot to mention that. -wayne From owner-ietf-mxcomp@mail.imc.org Mon Jan 31 16:28:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27780 for ; Mon, 31 Jan 2005 16:28: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 j0VKvg6R020518; Mon, 31 Jan 2005 12:57: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 j0VKvgN8020517; Mon, 31 Jan 2005 12:57:42 -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 j0VKvdh7020501 for ; Mon, 31 Jan 2005 12:57:41 -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 A8F8616FCD for ; Mon, 31 Jan 2005 15:52:22 -0500 (EST) From: "Alan DeKok" To: "IETF MARID WG" Subject: Re: So here it is one year later... In-Reply-To: Your message of "Mon, 31 Jan 2005 12:55:40 CST." Date: Mon, 31 Jan 2005 15:52:22 -0500 Message-Id: <20050131205222.A8F8616FCD@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: wayne wrote: > I certainly agree that SPF is not perfect. I am, however, curious > which systems you think do much better than SPF I did not say "better". There are schemes which, individually, do less than what SPF does. As a result, they do not have the issues that SPF has, because SPF has a wider scope and therefore wider side-effects. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Mon Jan 31 16:32:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28852 for ; Mon, 31 Jan 2005 16:32: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 j0VL5WEx020978; Mon, 31 Jan 2005 13:05: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 j0VL5WMA020977; Mon, 31 Jan 2005 13:05:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j0VL5Vjn020964 for ; Mon, 31 Jan 2005 13:05:31 -0800 (PST) (envelope-from dotis@mail-abuse.org) Received: from SJC-Office-DHCP-156.Mail-Abuse.ORG (SJC-Office-DHCP-156.Mail-Abuse.ORG [168.61.10.156]) by harry.mail-abuse.org (Postfix) with ESMTP id C87B5414EB; Mon, 31 Jan 2005 13:05:20 -0800 (PST) Subject: Re: So here it is one year later... From: Douglas Otis To: Frank Ellermann Cc: ietf-mxcomp@imc.org In-Reply-To: <41FE00B6.470D@xyzzy.claranet.de> References: <700EEF5641B7E247AC1C9B82C05D125D055536@srv1.pan-am.ca> <41F942E4.4E18@xyzzy.claranet.de> <1106872082.6443.96.camel@SJC-Office-DHCP-156.mail-abuse.org> <41F9AF92.717D@xyzzy.claranet.de> <1106896265.11035.66.camel@SJC-Office-DHCP-156.mail-abuse.org> <4DD53697-7189-11D9-9CD0-000D9358DFD8@hxr.us> <8617533D-7210-11D9-9CD0-000D9358DFD8@hxr.us> <1107041414.7186.122.camel@littlejoy> <41FC9BE2.2A5C@xyzzy.claranet.de> <1107125067.7662.123.camel@littlejoy> <41FE00B6.470D@xyzzy.claranet.de> Content-Type: text/plain Date: Mon, 31 Jan 2005 13:05:07 -0800 Message-Id: <1107205508.6862.127.camel@SJC-Office-DHCP-156.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 2005-01-31 at 10:56 +0100, Frank Ellermann wrote: > Douglas Otis wrote: > > > Forwarding is a common practice within colleges, societies, > > and many providers. > > Sure, there's nothing wrong with forwarding, each and every > mail I send is forwarded at least twice, from me to a smart > host, from the smart host to an MX of the recipient, or to > an MDA in the case of local users. > > What happens beyond the MX of the recipient is none of my > business, as you say there's no way for me to know what the > recipient does. My "sender policy" cannot cover forwarding > by the recipient. If he wants this for some reason, he has > to use his own MAIL FROM and his own "sender policy". SPF may say, "Here is a comprehensive address list", when in reality it can never be comprehensive. Either the sender policy allows open-ended inclusion of other locations, or such sender policies may cause mail to go missing or be refused. This is a problem created by the sender, and not the many unknown others using forwarded accounts. Use of close-ended SPF records presumes excluding mail on the basis of MAILFROM not matching a sending MTA has value exceeding a disruption it may cause. SPF does not prevent spoofing of the domain, as many share common providers and there is no consensus which identities are checked against such records (when these records are even examined). The high number of potential DNS lookups ~101-201 (requirements based upon Schlitt's draft) ensures SPF can not be used to protect the network. SPF represents an increased risk with respect to network security and protection. Protecting the domain from being spoofed is a feature safely offered by digital signature techniques. I see a real value in this, but yet no signature scheme offers network protection. CSV is intended to protect the network using the same name basis. > > With the change being made, the HELO may now be checked > > against a record found at the zone apex. > > The "zone cut" isn't a new feature, it was in the last SPF > draft published before MARID. BTW, Tony's blog mentions that > CSV now also solved this problem, but I don't find how, it's > apparently not in the last (now expired) CSV draft. There is not a major change being made to CSV. The design team is defining use of the Port field for Domain assertions. Such assertions could include use of signature algorithms, as example. Use of a wildcard label is unsuitable for publishing policy, so the prefix used by the CSV-CSA record is not a deterrent toward establishing domain wide assertions. This domain assertion is not constrained to zone cuts. After lengthy consideration, it was determined this too would be inappropriate. This updated draft should be ready very shortly. > Here's a summary of my SPF experiences in the last 10 months: > > Mar 04: some spammer(s) start to abuse "my" vanity domain, I > get about 1000 erroneous bounces / vacation mails / > challenges / etc. per day. > Apr 04: My ISP publishes a sender policy. Intuition or bug, > neither my ISP nor me saw the "minor" problem, that > this sender policy didn't cover "my" vanity domain. > May 04: Wildcard added, now it works even without "zone cut". > "Zone cut" also added to the SPF draft replacing an > older "match_subdomains" construct. > Sep 04: 180,000 bounces etc. so far in my mailbox (JFTR, I'm > a modem user) > Oct 04: My spammer(s) got the SPF idea, again zero bounces > etc. per day > Jan 05: So far not a single problem with SPF from my POV, and > 4*30*1000 = 120,000 avoided bounces etc. since Oct 04. There needs to be a means to discourage spoofing of domains and the abuse of bounce traffic. The MASS, CLEAR (BATV & CSV) efforts are aimed at achieving those goals without onerous path registration discovery. While a small domain may accommodate such related problems, security considerations dismiss value in path registration and thereby the need to also disrupt forwarding, various list servers, and user's access to mail. CSV looks to the administrators of the domain to control access to their outbound servers, and uses both assertions and reputations to protect the networks. CSV does not require providers to make specific DNS record changes to accommodate their customer's use of independent mailbox domains. > > I agree, the overhead for HELO checking would be unacceptably > > high with SPF > > Where that's the case (it depends on the sender policy) the > sender could arrange his HELO domains to avoid it. And if CSV > has a better solution than SPF's "zone cut" for spoofed HELOs, > I'd be interested what it is - I'm always curious. Good to hear. > > when publishing SPF, expect some of your mail to be lost or > > rejected due to problems with either SPF et al or Sender-ID > > algorithms. This is shameful. > > No legit mail is "lost" with SPF, that's FUD. While MARID was > a shameful disaster, one of the few results was, that Sender-ID > evaluations of SPF sender policies generally do _not_ work. A well understood problem is not FUD! > > those that have published what is now considered too many > > records may find their mail being rejected. > > If an erroneous policy "worked" with old SPF implementations, > and new implementations report the error, then it's time to > fix the old error. With SPF, there is no means to prevent disruption and provide an orderly introduction of newer revisions. A script based language is inherently complex and rarely stable. : ( > > The SPF timeout imposed still ignores UDP fallback. > > The overall SPF timeout in old drafts was replaced by clear > processing limits, which don't depend on a vague accumulated > processing time. >From the Schlitt's draft: MTAs or other processors MAY also impose a limit on the maximum amount of elapsed time to evaluate check_host(). Such a limit SHOULD allow at least 20 seconds. If such a limit is exceeded, the result of authentication SHOULD be "TempError". > > Is it reasonable to expect the receiving SMTP server to > > perform a hundred lookups per message? > > No, that's why it's impossible, you have constructed a worst > case of 1+10+10*10 = 111 DNS lookups for a sender policy with > 10 mx directives, each with 10 MX hosts. The concern is not what most use, the concern is what limits must be permitted. The draft requires these 101 to 201 lookup limits depending upon the mechanisms. > The average case is probably more like 1 to 4 lookups, I've no > data to support this guess. And not necessarily per message, > if you'd use CSV or SPF or an RBL to block an IP or to reject > all mails after your HELO-test resulted in a FAIL, then you > won't test the individual messages in this SMTP session. By checking per HELO, the rate CSV does a lookup is some multiple less than SPF, and constrained to a single lookup and not hundreds of lookups. This aspect is critical. > > This can be safely achieved via the efforts in MASS and > > CLEAR, but not with SPF. > > Please inform "us" when that's ready and deployed. Bye, Frank Gladly. -Doug From owner-ietf-mxcomp@mail.imc.org Mon Jan 31 17:21:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11472 for ; Mon, 31 Jan 2005 17:21: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 j0VLs8i1024360; Mon, 31 Jan 2005 13:54:08 -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 j0VLs8Fa024359; Mon, 31 Jan 2005 13:54: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 (winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id j0VLs7wi024350 for ; Mon, 31 Jan 2005 13:54:07 -0800 (PST) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.3) for ietf-mxcomp@imc.org; Mon, 31 Jan 2005 16:52:56 -0500 Received: from ([68.215.51.253]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.3) with SMTP id 3831704546; Mon, 31 Jan 2005 16:52:55 -0500 Message-ID: <001d01c507de$e4f4cdb0$6401a8c0@hdev1> From: "Hector Santos" To: "Douglas Otis" , "Frank Ellermann" Cc: References: <700EEF5641B7E247AC1C9B82C05D125D055536@srv1.pan-am.ca> <41F942E4.4E18@xyzzy.claranet.de> <1106872082.6443.96.camel@SJC-Office-DHCP-156.mail-abuse.org> <41F9AF92.717D@xyzzy.claranet.de> <1106896265.11035.66.camel@SJC-Office-DHCP-156.mail-abuse.org> <4DD53697-7189-11D9-9CD0-000D9358DFD8@hxr.us> <8617533D-7210-11D9-9CD0-000D9358DFD8@hxr.us> <1107041414.7186.122.camel@littlejoy> <41FC9BE2.2A5C@xyzzy.claranet.de> <1107125067.7662.123.camel@littlejoy> <41FE00B6.470D@xyzzy.claranet.de> <1107205508.6862.127.camel@SJC-Office-DHCP-156.mail-abuse.org> Subject: Re: So here it is one year later... Date: Mon, 31 Jan 2005 16:50:26 -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 Please Doug. You can't guarantee that an immediate router will be CSV compliant. So you have the same heterogeneous/mixed policy issues as SPF and all the rest of the proposals. In addition, you have a MUCH higher overhead than most as you based on state point #1 - HELO/EHLO. Now why would I want to do a HELO CSV check without determining: - Check to see if the sender is valid, - Final vs Route You will say; "Our new MAPS CSV/DNA service will take of this. We will vouch for the transaction." But what if the SMTP operator does not want to use your new MAPS CSV/DNA service? What if you go out of business? What if you get enough support headaches from thousands of smaller systems that you decide to raise the price to filter out these bothersome clientele? Please, again. Give me something technically SOUND before even have to bother with the baloney that will come about with DNA like concepts. Sincerely, Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com 305-431-2846 Cell 305-248-3204 Office ----- Original Message ----- From: "Douglas Otis" To: "Frank Ellermann" Cc: Sent: Monday, January 31, 2005 4:05 PM Subject: Re: So here it is one year later... > > On Mon, 2005-01-31 at 10:56 +0100, Frank Ellermann wrote: > > Douglas Otis wrote: > > > > > Forwarding is a common practice within colleges, societies, > > > and many providers. > > > > Sure, there's nothing wrong with forwarding, each and every > > mail I send is forwarded at least twice, from me to a smart > > host, from the smart host to an MX of the recipient, or to > > an MDA in the case of local users. > > > > What happens beyond the MX of the recipient is none of my > > business, as you say there's no way for me to know what the > > recipient does. My "sender policy" cannot cover forwarding > > by the recipient. If he wants this for some reason, he has > > to use his own MAIL FROM and his own "sender policy". > > SPF may say, "Here is a comprehensive address list", when in reality it > can never be comprehensive. Either the sender policy allows open-ended > inclusion of other locations, or such sender policies may cause mail to > go missing or be refused. This is a problem created by the sender, and > not the many unknown others using forwarded accounts. > > Use of close-ended SPF records presumes excluding mail on the basis of > MAILFROM not matching a sending MTA has value exceeding a disruption it > may cause. SPF does not prevent spoofing of the domain, as many share > common providers and there is no consensus which identities are checked > against such records (when these records are even examined). The high > number of potential DNS lookups ~101-201 (requirements based upon > Schlitt's draft) ensures SPF can not be used to protect the network. > SPF represents an increased risk with respect to network security and > protection. > > Protecting the domain from being spoofed is a feature safely offered by > digital signature techniques. I see a real value in this, but yet no > signature scheme offers network protection. CSV is intended to protect > the network using the same name basis. > > > > With the change being made, the HELO may now be checked > > > against a record found at the zone apex. > > > > The "zone cut" isn't a new feature, it was in the last SPF > > draft published before MARID. BTW, Tony's blog mentions that > > CSV now also solved this problem, but I don't find how, it's > > apparently not in the last (now expired) CSV draft. > > There is not a major change being made to CSV. The design team is > defining use of the Port field for Domain assertions. Such assertions > could include use of signature algorithms, as example. Use of a > wildcard label is unsuitable for publishing policy, so the prefix used > by the CSV-CSA record is not a deterrent toward establishing domain wide > assertions. This domain assertion is not constrained to zone cuts. > After lengthy consideration, it was determined this too would be > inappropriate. This updated draft should be ready very shortly. > > > Here's a summary of my SPF experiences in the last 10 months: > > > > Mar 04: some spammer(s) start to abuse "my" vanity domain, I > > get about 1000 erroneous bounces / vacation mails / > > challenges / etc. per day. > > Apr 04: My ISP publishes a sender policy. Intuition or bug, > > neither my ISP nor me saw the "minor" problem, that > > this sender policy didn't cover "my" vanity domain. > > May 04: Wildcard added, now it works even without "zone cut". > > "Zone cut" also added to the SPF draft replacing an > > older "match_subdomains" construct. > > Sep 04: 180,000 bounces etc. so far in my mailbox (JFTR, I'm > > a modem user) > > Oct 04: My spammer(s) got the SPF idea, again zero bounces > > etc. per day > > Jan 05: So far not a single problem with SPF from my POV, and > > 4*30*1000 = 120,000 avoided bounces etc. since Oct 04. > > There needs to be a means to discourage spoofing of domains and the > abuse of bounce traffic. The MASS, CLEAR (BATV & CSV) efforts are aimed > at achieving those goals without onerous path registration discovery. > While a small domain may accommodate such related problems, security > considerations dismiss value in path registration and thereby the need > to also disrupt forwarding, various list servers, and user's access to > mail. CSV looks to the administrators of the domain to control access > to their outbound servers, and uses both assertions and reputations to > protect the networks. CSV does not require providers to make specific > DNS record changes to accommodate their customer's use of independent > mailbox domains. > > > > I agree, the overhead for HELO checking would be unacceptably > > > high with SPF > > > > Where that's the case (it depends on the sender policy) the > > sender could arrange his HELO domains to avoid it. And if CSV > > has a better solution than SPF's "zone cut" for spoofed HELOs, > > I'd be interested what it is - I'm always curious. > > Good to hear. > > > > when publishing SPF, expect some of your mail to be lost or > > > rejected due to problems with either SPF et al or Sender-ID > > > algorithms. This is shameful. > > > > No legit mail is "lost" with SPF, that's FUD. While MARID was > > a shameful disaster, one of the few results was, that Sender-ID > > evaluations of SPF sender policies generally do _not_ work. > > A well understood problem is not FUD! > > > > those that have published what is now considered too many > > > records may find their mail being rejected. > > > > If an erroneous policy "worked" with old SPF implementations, > > and new implementations report the error, then it's time to > > fix the old error. > > With SPF, there is no means to prevent disruption and provide an orderly > introduction of newer revisions. A script based language is inherently > complex and rarely stable. : ( > > > > The SPF timeout imposed still ignores UDP fallback. > > > > The overall SPF timeout in old drafts was replaced by clear > > processing limits, which don't depend on a vague accumulated > > processing time. > > >From the Schlitt's draft: > MTAs or other processors MAY also impose a limit on the maximum > amount of elapsed time to evaluate check_host(). Such a limit SHOULD > allow at least 20 seconds. If such a limit is exceeded, the result > of authentication SHOULD be "TempError". > > > > Is it reasonable to expect the receiving SMTP server to > > > perform a hundred lookups per message? > > > > No, that's why it's impossible, you have constructed a worst > > case of 1+10+10*10 = 111 DNS lookups for a sender policy with > > 10 mx directives, each with 10 MX hosts. > > The concern is not what most use, the concern is what limits must be > permitted. The draft requires these 101 to 201 lookup limits depending > upon the mechanisms. > > > The average case is probably more like 1 to 4 lookups, I've no > > data to support this guess. And not necessarily per message, > > if you'd use CSV or SPF or an RBL to block an IP or to reject > > all mails after your HELO-test resulted in a FAIL, then you > > won't test the individual messages in this SMTP session. > > By checking per HELO, the rate CSV does a lookup is some multiple less > than SPF, and constrained to a single lookup and not hundreds of > lookups. This aspect is critical. > > > > This can be safely achieved via the efforts in MASS and > > > CLEAR, but not with SPF. > > > > Please inform "us" when that's ready and deployed. Bye, Frank > > Gladly. > > -Doug > > From owner-ietf-mxcomp@mail.imc.org Mon Jan 31 17:21:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11516 for ; Mon, 31 Jan 2005 17:21: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 j0VLf8Wa023301; Mon, 31 Jan 2005 13:41:08 -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 j0VLf8C7023297; Mon, 31 Jan 2005 13:41: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 (ftp.catinthebox.net [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id j0VLf2Mp023270 for ; Mon, 31 Jan 2005 13:41:03 -0800 (PST) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.3) for ietf-mxcomp@imc.org; Mon, 31 Jan 2005 16:39:43 -0500 Received: from ([68.215.51.253]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.3) with SMTP id 3830911921; Mon, 31 Jan 2005 16:39:42 -0500 Message-ID: <000d01c507dd$0c861d90$6401a8c0@hdev1> From: "Hector Santos" To: "Jim Fenton" , "IETF MARID WG" References: <41FE92AD.5090501@cisco.com> Subject: Re: So here it is one year later... Date: Mon, 31 Jan 2005 16:37:18 -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 In order words, SPF and most so with CSV and DK/IIM presume across the board compliance. Thanks for confirming the obvious. The question is, which one is more plausible in addressing the real industry concerns with minimum intrafracture changes? Personally, there are two form of mail integrity concepts: One that remain outside of transports, and one that independently controlled by SMTP with the possibility linkage of the two. The point being is that SMTP (the transport system) should not depend on SPF, CSV or DK/IIM clients. You either do it across the board or you don't because ultimately you have to deal with the questions of compatibility and legacy issues. In layman terms: What if my SMTP mail server detects a non-DK/IIM ready message? You need to answer that question otherwise what is the use of using DK/IIM if a system still needs to work and be ready for non-DK/IIM messages? Now of course, it might work well in an exclusive CISCO corporate/enterprise settings, a big pat on the back, an exciting marketing and promotion largely based on "hope" I can imagine for your big customer base. But this is not a standard across the board. In short, we need to get back to basic and address the real issue - SMTP with Transport Negotiated security and to satisfy CANSPAM - Topic identification. Regardless of the EPV (Endpoint Validation) method used, SMTP "3821" must be remodeled as an advanced secured system with some level of backward compatibility. This will allow for the fastest endorsement and adoption. As a side comment, the failure of MARID was 100% due to the philosophical conflicts between developers and administrators. I had seen it before when the last original big public email network "FIDONET" faced the then new internet migration technical design issues. It is now all deja-vu with the security issues of the internet. Everyone has half-baked ideas. Everyone is protecting their turfs especially with the old school people around here, and not many, except for myself and a few others, are not pointing to the obvious - Where is the IETF-SMTP input in all this? Where is author of 2821? In all honesty, I could only hope that a SMTP, POP, IMAP vendor/developer's working group get together to work out the a Generic/General specifications for the new transport system - independent of any specific SPF, CSV, DK/IIM proposals. This will allow the new system to STILL work when new inventors have new EVP methods. We are doing it backwards based on some half washed "semi-proprietary" ideas and we wonder there isn't censensus. I'm out of here..... Sincerely, Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com 305-431-2846 Cell 305-248-3204 Office ----- Original Message ----- From: "Jim Fenton" To: "IETF MARID WG" Sent: Monday, January 31, 2005 3:18 PM Subject: Re: So here it is one year later... > > wayne wrote: > > >Despite asking several times on the MASS mailing list, I have yet to > >see any data on the false positive rates for DK, IIM, William's DK-IIM > >merged system, CSV, or SES. So far, all I've seen is people claiming > >that their systems work better than SPF, with no data to back it up. > >(Often, there is data to back up the claim that SPF has false > >positives, but we *do* know that.) > > > > > We are starting to get some data on false positives (signature breakage) > for DK and IIM, but since the number of verifying domains at this point > is very small, it would raise more questions than it would answer if we > were to publish it. Success rates depend a lot on what the originating > and terminating domains' MTAs do with their messages, so having data > from a couple of domains is far from representative. It also depends on > things like whether the signer, in the case of DK, uses the optional h= > parameter to sign specific headers. > > >SPF breaks forwarding unless the sender uses SES, the forwarder uses > >SRS, or the receiver uses a whitelist. > > > >DK breaks mailing lists, and from what I can tell from reading MASS, > >the DK folks don't see that as a problem. The other crypto systems at > >least *try* to not break mailing lists, but it not at all clear how > >well they do in practice. (SES looks like it will do the best, but it > >requires some sort of call-back to work.) > > > > > The real answer is to have mailing lists re-sign their messages. While > IIM does try not to break mailing lists, and does in some cases, it's > imperfect and intended primarily as a expedient until they do. > > If you'd like to discuss this more, let's move to the ietf-mailsig list. > > -Jim > > From owner-ietf-mxcomp@mail.imc.org Mon Jan 31 17:23:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12107 for ; Mon, 31 Jan 2005 17:23: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 j0VLkcvu023718; Mon, 31 Jan 2005 13:46: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 j0VLkcc8023717; Mon, 31 Jan 2005 13:46:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (catinthebox.net [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id j0VLkce4023710 for ; Mon, 31 Jan 2005 13:46:38 -0800 (PST) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.3) for ietf-mxcomp@imc.org; Mon, 31 Jan 2005 16:45:21 -0500 Received: from ([68.215.51.253]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.3) with SMTP id 3831249968; Mon, 31 Jan 2005 16:45:20 -0500 Message-ID: <001701c507dd$d603fe80$6401a8c0@hdev1> From: "Hector Santos" To: "IETF MARID WG" References: Subject: Re: So here it is one year later... Date: Mon, 31 Jan 2005 16:42:54 -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: "wayne" To: "IETF MARID WG" Sent: Monday, January 31, 2005 3:53 PM Subject: Re: So here it is one year later... > I completely, 100% agree and I can not emphisized this enough. I see > things like SPF and crypto systems as complementary systems, not > competing systems. I'm sorry I forgot to mention that. Vendors with a suite of solutions know this already. No one system is good enough, especially if its all half-baked into a legacy SMTP system. We made our system "hook" ready at each state of the SMTP state machine. That way, if someone invents something new tomorrow, its plug in plug. MARID should of focused on the generic security aspect of the transport system rather than just to force one or more of the half-based, semi-proprietary proposals down our throats. 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 Jan 31 17:48:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16956 for ; Mon, 31 Jan 2005 17:48: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 j0VMGZtr026715; Mon, 31 Jan 2005 14:16: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 j0VMGZQF026713; Mon, 31 Jan 2005 14:16:35 -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 j0VMGZtk026703 for ; Mon, 31 Jan 2005 14:16:35 -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 j0VMMxvQ028223 for ; Mon, 31 Jan 2005 14:22:59 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id j0VMMxP7028220 for ; Mon, 31 Jan 2005 14:22:59 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Mon, 31 Jan 2005 14:22:59 -0800 (PST) From: "william(at)elan.net" To: IETF MARID WG Subject: Re: So here it is one year later... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 31 Jan 2005, wayne wrote: > > DK and SPF have different failure modes. I don't think this is a > > competition situation. A system with both schemes is much more > > effective than either on its own. > > I completely, 100% agree and I can not emphisized this enough. I see > things like SPF and crypto systems as complementary systems, not > competing systems. I'm sorry I forgot to mention that. The are complimentary but they work and protect different parts of email message. That means each one must be able to work on its own independant of the other one and authentication should work properly on each layer. You can not have failure scenario of one system being depdending on the authentication in another layer - this is just a bad security architecture. That means if we want to use SPF and mail signatures for anything other then whitelisting (i.e. to get rid of actual bad messages and find bad senders), we must find ways to deal with SPF forwarding problems on the SMTP session layer and must have MASS signatures that work with mail lists. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Mon Jan 31 20:21:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03725 for ; Mon, 31 Jan 2005 20:21: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 j110oKIb038669; Mon, 31 Jan 2005 16:50:20 -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 j110oKBg038668; Mon, 31 Jan 2005 16:50:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j110oJGi038659 for ; Mon, 31 Jan 2005 16:50:19 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (mailer5.verisign.com [65.205.251.54]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id j110oDCj020790; Mon, 31 Jan 2005 16:50:13 -0800 (PST) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 31 Jan 2005 16:50:13 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Douglas Otis'" , Frank Ellermann Cc: ietf-mxcomp@imc.org Subject: RE: So here it is one year later... Date: Mon, 31 Jan 2005 16:50:12 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of Douglas Otis > A well understood problem is not FUD! You may believe you understand the problem well. I don't understand any of your explanations and I don't think that is due to a lack of expertise or ability on my part. I remain Sir yours, etc. From owner-ietf-mxcomp@mail.imc.org Mon Jan 31 20:38:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04964 for ; Mon, 31 Jan 2005 20:37: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 j111ArTn039731; Mon, 31 Jan 2005 17:10:53 -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 j111ArgH039730; Mon, 31 Jan 2005 17:10:53 -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 j111AqtR039722 for ; Mon, 31 Jan 2005 17:10:52 -0800 (PST) (envelope-from dean@av8.com) Received: from piper.av8.net (piper.av8.net [130.105.11.2]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id j111Afod010061 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 31 Jan 2005 20:10:46 -0500 Date: Mon, 31 Jan 2005 20:10:41 -0500 (EST) From: Dean Anderson X-X-Sender: dean@piper.av8.net To: Justin Mason cc: gmc@metro.cx, , "'Gordon Fecyk'" , "'IETF MXCOMP (E-mail)'" Subject: Re: So here it is one year later... In-Reply-To: <20050128231427.5837959001E@radish.jmason.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, 28 Jan 2005, Justin Mason wrote: > > > > BTW, I'd say that 38% of the SPF use was ham, and 62% was spam. > > 1263 ham / 3302 = ~38% > > 2039 spam / 3302 = ~62% > > > > So, 24% versus the 34% in September. Either slightly better than > > September, or perhaps the sample is too small and skewed to be useful. Or > > both. Its still better to block whenever you see SPF. > > hmm! not sure if that's a good assumption -- it's very much dependent on > the comparative ham:spam ratio a domain would see. This set of corpora is > heavily skewed towards receiving more spam than ham; 87.8% of our messages > being spam. > > Let's say those corpora were only receiving a third as much spam as they > currently do, possibly because they were younger email addresses or > whatever. In that case, we'd see 1263 ham, 680 spam (2039/3 ~= 680), in > which case the proportion of SPF-using-spam vs SPF-using-ham would be on > its head: 34% being spam, 65% being ham. Err, no. If there was less total spam, then instead of some 60k messages, you might have 50k messages. However, very likely, there would still be 3302 messages that had correct SPF records. Your calculation, while a useful number, adds in all sorts of other noise, not related to SPF. This sort of misunderstanding is unfortunately, all too frequent. If you decrease the number of spams by 10k messages (roughly 15%), and 3.7% of total spam has SPF, and all spammers do the same thing, then the SPF spam number would only decrease by 3.7%. Assuming that, we'd expect our SPF-using spams to drop by 75 messages. (neglecting variance) So now we'd have: 1263 ham / 3227 = ~39% 1964 spam / 3227 = ~61% Barely a difference, yet a roughly 15% change in spam volume. However, the SPF spammers are not doing the same thing as all other spammers. We have no reason to think so. So a change in the behavior of the non-SPF using spammers would _not_ affect the behavior of the SPF-using spammers, so you'd expect the same 3302 messages as before. Of course, virus joe-jobbers probably think that by generating more spam, they alter the statistics of real spammers. That's only true if there is no way to distinguish joe-jobs from real spam. But of course, we can make such distinctions with CAN-SPAM. No doubt, this is precisely why the DMA was behind CAN-SPAM. Fake spam violates CAN-SPAM: no real product or service, etc. Genuine spam MOSTLY doesn't: There is a strong incentive for genuine spammers to comply, and compliance isn't hard for a real company. But it is practically impossible for fake spammers to comply, because if they had real products or services, they'd be real spammers, but of course, they aren't real commercial operations. SPF added another interesting element to all this, in that genuine spammers leapt onto the bandwagon early, and essentially added a label to their spam, a lable that fake spammers can't easilly add at the moment. Eventually, viruses such will be able to start using ISP relays identified by SPF, but for now, they can't do that easily, and so don't have SPF "protection" or labeling. The unexpected segregation created during this transition period should yield a great deal of insight into genuine spam and virus activity. BTW, I noticed that John Levine published a diatribe on the "failure of CAN-SPAM" on circleid a few days ago. He is wrong again, asserting incorrectly that CAN-SPAM was meant to outlaw spam. It legalized spam, and gave a way to distinguish the real (ie DMA member) spammers, from the fake (and I suspect anti-spam radical) abusers. I suspect that if you go back to Congress, the DMA will simply push for enforcement of the criminal provisions of CAN-SPAM, which should reveal the identities of our virus operators. I wonder who that will reveal, and if it will be another ISP abuse admin, or radical anti-spammer. I forsee the end of a certain type of spam, in the same way that open relay abuse ended: The abusers will just give up. It will be nice if this accounts for 96.3% of all spam. But, I've digressed enough. > What I'm trying to illustrate here is that it's important to compare > figures using figures that compensate for the comparative ham:spam ratio, > because that varies wildly. Hence, comparing (SPF-bearing-ham / all-ham) > to (SPF-bearing-spam / all-spam) is safer than comparing the message > counts of SPF-bearing-ham and SPF-bearing-spam directly. Safer? Its different. Safer has some other implication thats not clear. I don't know what "safer" means. It could mean that since 18% of total ham has SPF records, that perhaps deleting based on the roughly 2 to 1 chance that "SPF records mean spam", is an "unsafe" bet. More rules to cover the ham would be important. However, when you ask the question "what is the ratio of SPF use that is spam and SPF use that ham?", the Sum of the percents have to add to 100, otherwise you didn't answer the question. You answered some other question. Possibly, that question is also useful, but it wasn't the question asked. The assertion was the spammers jumped on SPF. The percent SPF use that is spam is 62%. The percent of SPF use that ham is 38%. The total SPF use is composed of spam and ham. Spam SPF use + Ham SPF use must equal 100%. Your corpus supports the Ciphertrust assertion. But you said it didn't. That was incorrect. The mistake was that you answered a different question. > > Still, I'd think the 3.7% of total spam using SPF is still fairly > > significant, and probably reflects the relative proportion of genuine > > commercial spam to non-commercial spam. It would be interesting to know, > > of those spams that pass SPF, how many are CAN-SPAM compliant? How many > > of the non-SPF spams were CAN-SPAM compliant? I'd conjecture a strong > > correlation. > > now that's something I don't have time to get into, CAN-SPAM compliance > not being something that's easy to automate checking for (more's the > pity). You should have accepted the IEMCC proposal back in 1997. Wallace and co. proposed everything that's in CAN-SPAM, with the benefit of a special X-spam header (I think it was called something else, like X-advertisement or some such). That sort of labeling would have made the problem easy. But the radicals didn't want to be reasonable at the time--thought they could end spam by techincal means. --Dean > - --j. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.5 (GNU/Linux) > Comment: Exmh CVS > > iD8DBQFB+sdSMJF5cimLx9ARAhvgAKCdDpROw4/yqVxCwOwMipg46uh/LACbBD/6 > HsR9l0+iPdHRG4RDM/zOSmQ= > =lLX4 > -----END PGP SIGNATURE----- > > > -- 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 Jan 31 21:50:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11011 for ; Mon, 31 Jan 2005 21:50: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 j112NfmN044206; Mon, 31 Jan 2005 18:23:41 -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 j112Nf07044205; Mon, 31 Jan 2005 18:23:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j112NeX2044171 for ; Mon, 31 Jan 2005 18:23:40 -0800 (PST) (envelope-from dotis@mail-abuse.org) Received: from SJC-Office-DHCP-156.Mail-Abuse.ORG (SJC-Office-DHCP-156.Mail-Abuse.ORG [168.61.10.156]) by harry.mail-abuse.org (Postfix) with ESMTP id C3CAF414EA; Mon, 31 Jan 2005 18:23:35 -0800 (PST) Subject: Re: So here it is one year later... From: Douglas Otis To: Hector Santos Cc: ietf-mxcomp@imc.org In-Reply-To: <001d01c507de$e4f4cdb0$6401a8c0@hdev1> References: <700EEF5641B7E247AC1C9B82C05D125D055536@srv1.pan-am.ca> <41F942E4.4E18@xyzzy.claranet.de> <1106872082.6443.96.camel@SJC-Office-DHCP-156.mail-abuse.org> <41F9AF92.717D@xyzzy.claranet.de> <1106896265.11035.66.camel@SJC-Office-DHCP-156.mail-abuse.org> <4DD53697-7189-11D9-9CD0-000D9358DFD8@hxr.us> <8617533D-7210-11D9-9CD0-000D9358DFD8@hxr.us> <1107041414.7186.122.camel@littlejoy> <41FC9BE2.2A5C@xyzzy.claranet.de> <1107125067.7662.123.camel@littlejoy> <41FE00B6.470D@xyzzy.claranet.de> <1107205508.6862.127.camel@SJC-Office-DHCP-156.mail-abuse.org> <001d01c507de$e4f4cdb0$6401a8c0@hdev1> Content-Type: text/plain Date: Mon, 31 Jan 2005 18:23:22 -0800 Message-Id: <1107224602.7320.184.camel@SJC-Office-DHCP-156.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 2005-01-31 at 16:50 -0500, Hector Santos wrote: > Please Doug. > > You can't guarantee that an immediate router will be CSV compliant. So you > have the same heterogeneous/mixed policy issues as SPF and all the rest of > the proposals. If the sending SMTP client publishes a CSV-CSA record, then this client is both authenticated and authorized by the HELO domain. This permits assessment of reputation which may supersede evaluation of the IP address. It also permits direct and meaningful feedback to the accountable administrator, as a means to rapidly respond to abuse. Authorizations offered by SPF path registration is insufficient for reputation assessments, as there is no assurance which administrator is directly accountable for abusive messages. SPF does not authenticate the sending domain, it only confirms authorization. Where many domains have authorized an MTA with SPF, resolving abuse may become an expensive process. CSV allows such assessments to be made safely on an opportunistic basis while not requiring heterogeneous adoption. CSV is also incorporating a means to assert domain wide use of CSV as a means to discourage HELO spoofing. Unlike SPF, CSV does not disrupt the normal use of mail nor depend upon any tests or changes in MTA behavior. > In addition, you have a MUCH higher overhead than most as you based on > state point #1 - HELO/EHLO. Authenticating the HELO is done within a single lookup with CSV. How can this be a higher overhead? SPF provides authorization for the MTA referenced by a sending mailbox domain (without consensus as to which mailbox domain). While SPF could also be extended to examine the HELO domain, those that have previously published SPF records may not have ensured HELO domains resolve to an SPF record. SPF evaluation of HELO was previously applied during the sending of bounce messages, where the outcome would have been "unknown" rather than "fail" without specific records in place. It is also likely that SPF HELO records may require resolving the same large address space as that needed for mailbox domains and is a DoS concern. : ( Changing SPF to apply a record at the zone cut against the HELO, in addition to further increasing overhead, may now put some domains in jeopardy due to a lack of proper record revisioning. Using the same check_host routine and records, as used to examine mailbox domains, may also permit unexpected exploits. Although the number of SPF records could be few on average, the need to register potentially complex paths always requires an excessive limit for the number of lookups. > Now why would I want to do a HELO CSV check without determining: > > - Check to see if the sender is valid, > - Final vs Route MASS is addressing the need to safely authenticate the administrator of originating sender domain. CSV addresses the need to protect the network from abuse, and therefore only considers authenticating the administrator of the immediate sending domain. CSV does not require customers of various mail providers to have their various provider's domains entered into their DNS records. CSV will not inappropriately assess the customers of various providers for a lapse in access control of some provider's server. The administrators of the servers are accountable for security, not customers. > You will say; > > "Our new MAPS CSV/DNA service will take of this. We will vouch > for the transaction." Accurately authenticating the accountable domain's administrator (who is permitting mail access), allows assessing reputation. There is value from this information alone, as it also means the sending MTA has been specifically authorized to send mail. This helps with detection of zombies without the use of a vouching service. Securing the networks will always require a reputation service, whether IP address based or extended to using names. There are advantages using names with respect to ensuring legitimate domains eliminate abusive accounts with the least expenditure. > But what if the SMTP operator does not want to use your new MAPS CSV/DNA > service? What if you go out of business? What if you get enough support > headaches from thousands of smaller systems that you decide to raise the > price to filter out these bothersome clientele? This seems to be putting the cart before the horse. > Please, again. > > Give me something technically SOUND before even have to bother with the > baloney that will come about with DNA like concepts. The CLEAR design team is working diligently at ensuring CSV is sound. There are models where reputation is provided as a service to the SMTP servers. While CSV has made accommodations for a vouching model, it is unknown which model will prevail. While bulk mail providers may favor the vouching approach, a more significant number may rely upon a direct reputation service model. I should also note that BATV does not require any outside service to address abusive bounce messages. Although SES is similar, it introduces some security concerns by way of its syntax. -Doug