From owner-ietf-mxcomp Thu Jan 29 11:05:35 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TJ5ZiG039452; Thu, 29 Jan 2004 11:05: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 i0TJ5Z5Q039451; Thu, 29 Jan 2004 11:05:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from dedicated60-bos.wh.sprintip.net (smtp.sprintpcs.com [63.167.114.16]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TJ5Xba039427 for ; Thu, 29 Jan 2004 11:05:33 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from solidmatrix.com (000-389-336.area3.spcsdns.net [68.29.234.239]) by dedicated60-bos.wh.sprintip.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPA id <0HS900GMZMAZ0G@dedicated60-bos.wh.sprintip.net> for ietf-mxcomp@imc.org; Thu, 29 Jan 2004 19:04:18 +0000 (GMT) Date: Thu, 29 Jan 2004 14:04:07 -0500 From: Yakov Shafranovich Subject: Reading list To: ietf-mxcomp@imc.org Message-id: <40195927.6090306@solidmatrix.com> Organization: SolidMatrix Technologies, Inc. MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en, he, ru User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Enigmail-Version: 0.82.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Here is a reading list of some relevant materials for the BOF: 0. Copy of the agenda (probably will be updated): https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg09082.html 1. LMAP Discussion document - goes through concept itself and some of the issues surrounding storing MTA authorization records in DNS. It is currently being heavily edited and will be submited as an ID before the cut-off date. http://asrg.kavi.com/apps/group_public/download.php/18/draft-irtf-asrg-lmap-discussion-00.txt 2. RMX proposal - this proposal was published back in March of 2003. http://www.ietf.org/internet-drafts/draft-danisch-dns-rr-smtp-03.txt 3. DMP proposal - this proposal was published in the early summer of 2003. It also incorporated the DRIP proposal for HELO checking. http://www.ietf.org/internet-drafts/draft-fecyk-dsprotocol-04.txt http://www.ietf.org/internet-drafts/draft-brand-drip-02.txt 4. SPF proposal - this is the most active currently and incorporates the other two. The author is currently working on a draft to be submitted as an Internet Draft. http://spf.pobox.com/ http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt http://spf.pobox.com/draft-mengwong-spf-02.9.5.txt http://archives.listbox.com/spf-discuss@v2.listbox.com/ 5. Mike Rubel's discussion document - this page discusses some of the issues that have to do with these type of proposals http://www.mikerubel.org/computers/rmx_records/ 6. Older drafts - some of the older Internet drafts, published and unpublished, that show some of the early ideas. The earliest one is by Paul Vixie, who claims that the idea originated with Jim Miller back in 1998. http://asrg.sp.am/about/old_site/draft-vixie-repudiating-mail-from.txt http://nospam.couchpotato.net/ 7. MTA MARK - a related proposal that wants to mark IPs in reverse DNS as "MTA" or "non-MTA". This has not been submitted as an ID, we have been trying to get in touch with the author. http://asrg.kavi.com/apps/group_public/download.php/26/draft-irtf-asrg-mtamark-00.txt 8. Some other related proposals with similar ideas: http://www.potaroo.net/ietf/old-ids/draft-haas-smtp-check-mail-00.txt http://www.ietf.org/internet-drafts/draft-laforet-deasey-imxrecords-00.txt There is also a wealth of information in the ASRG list archives, but due to the large size of the archive, it might not be realistic for anyone without sufficient time to plow through everything. For the people who want to do it anyway, list info is here: http://asrg.sp.am/about/lists.shtml Yakov ------- Yakov Shafranovich / asrg shaftek.org SolidMatrix Technologies, Inc. / research solidmatrix.com "Be liberal in what you accept, and conservative in what you send" (Jon Postel) ------- From owner-ietf-mxcomp Thu Jan 29 22:34:25 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0U6YOKZ081323; Thu, 29 Jan 2004 22:34: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 i0U6YOwB081322; Thu, 29 Jan 2004 22:34:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.74.5]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0U6YMQ5081247 for ; Thu, 29 Jan 2004 22:34:23 -0800 (PST) (envelope-from paf@cisco.com) Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 30 Jan 2004 07:35:01 +0100 Received: from xbe-ams-312.cisco.com (xbe-ams-312.cisco.com [144.254.228.202]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i0U6XoeJ025843; Fri, 30 Jan 2004 07:33:57 +0100 (MET) Received: from xfe-ams-312.cisco.com ([144.254.228.205]) by xbe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 30 Jan 2004 07:34:11 +0100 Received: from [127.0.0.1] ([144.254.74.55]) by xfe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 30 Jan 2004 07:26:04 +0100 In-Reply-To: <40195927.6090306@solidmatrix.com> References: <40195927.6090306@solidmatrix.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2DC4D732-52ED-11D8-8D05-000A959CF516@cisco.com> Content-Transfer-Encoding: 7bit Cc: ietf-mxcomp@imc.org From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: Reading list Date: Fri, 30 Jan 2004 07:26:03 +0100 To: Yakov Shafranovich X-Mailer: Apple Mail (2.612) X-OriginalArrivalTime: 30 Jan 2004 06:26:04.0287 (UTC) FILETIME=[EFEA70F0:01C3E6F9] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Documents should be internet-drafts for the BOF, especially if the name looks like an I-D. Can you make sure this happens? paf On 2004-01-29, at 20.04, Yakov Shafranovich wrote: > > Here is a reading list of some relevant materials for the BOF: > > 0. Copy of the agenda (probably will be updated): > https://www1.ietf.org/mail-archive/working-groups/asrg/current/ > msg09082.html > > 1. LMAP Discussion document - goes through concept itself and some of > the issues surrounding storing MTA authorization records in DNS. It is > currently being heavily edited and will be submited as an ID before > the cut-off date. > http://asrg.kavi.com/apps/group_public/download.php/18/draft-irtf- > asrg-lmap-discussion-00.txt > > 2. RMX proposal - this proposal was published back in March of 2003. > http://www.ietf.org/internet-drafts/draft-danisch-dns-rr-smtp-03.txt > > 3. DMP proposal - this proposal was published in the early summer of > 2003. It also incorporated the DRIP proposal for HELO checking. > http://www.ietf.org/internet-drafts/draft-fecyk-dsprotocol-04.txt > http://www.ietf.org/internet-drafts/draft-brand-drip-02.txt > > 4. SPF proposal - this is the most active currently and incorporates > the other two. The author is currently working on a draft to be > submitted as an Internet Draft. > http://spf.pobox.com/ > http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt > http://spf.pobox.com/draft-mengwong-spf-02.9.5.txt > http://archives.listbox.com/spf-discuss@v2.listbox.com/ > > 5. Mike Rubel's discussion document - this page discusses some of the > issues that have to do with these type of proposals > http://www.mikerubel.org/computers/rmx_records/ > > 6. Older drafts - some of the older Internet drafts, published and > unpublished, that show some of the early ideas. The earliest one is by > Paul Vixie, who claims that the idea originated with Jim Miller back > in 1998. > http://asrg.sp.am/about/old_site/draft-vixie-repudiating-mail-from.txt > http://nospam.couchpotato.net/ > > 7. MTA MARK - a related proposal that wants to mark IPs in reverse DNS > as "MTA" or "non-MTA". This has not been submitted as an ID, we have > been trying to get in touch with the author. > http://asrg.kavi.com/apps/group_public/download.php/26/draft-irtf- > asrg-mtamark-00.txt > > 8. Some other related proposals with similar ideas: > http://www.potaroo.net/ietf/old-ids/draft-haas-smtp-check-mail-00.txt > http://www.ietf.org/internet-drafts/draft-laforet-deasey-imxrecords > -00.txt > > There is also a wealth of information in the ASRG list archives, but > due to the large size of the archive, it might not be realistic for > anyone without sufficient time to plow through everything. For the > people who want to do it anyway, list info is here: > > http://asrg.sp.am/about/lists.shtml > > Yakov > > ------- > Yakov Shafranovich / asrg shaftek.org > SolidMatrix Technologies, Inc. / research solidmatrix.com > "Be liberal in what you accept, and conservative in what you send" > (Jon Postel) > ------- > From owner-ietf-mxcomp Fri Jan 30 10:59:36 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UIxaDt013112; Fri, 30 Jan 2004 10:59:36 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0UIxa1i013111; Fri, 30 Jan 2004 10:59:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from dedicated59-bos.wh.sprintip.net (smtp.sprintpcs.com [63.167.114.16]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UIxYPh013097 for ; Fri, 30 Jan 2004 10:59:35 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from solidmatrix.com (000-362-127.area3.spcsdns.net [68.29.129.15]) by dedicated59-bos.wh.sprintip.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPA id <0HSB00C4PGR0DL@dedicated59-bos.wh.sprintip.net> for ietf-mxcomp@imc.org; Fri, 30 Jan 2004 18:59:30 +0000 (GMT) Date: Fri, 30 Jan 2004 13:59:22 -0500 From: Yakov Shafranovich Subject: Re: Reading list In-reply-to: <2DC4D732-52ED-11D8-8D05-000A959CF516@cisco.com> To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: ietf-mxcomp@imc.org Message-id: <401AA98A.7000501@solidmatrix.com> Organization: SolidMatrix Technologies, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 8BIT X-Accept-Language: en-us, en, he, ru User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Enigmail-Version: 0.82.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime References: <40195927.6090306@solidmatrix.com> <2DC4D732-52ED-11D8-8D05-000A959CF516@cisco.com> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Patrik Fältström wrote: > > Documents should be internet-drafts for the BOF, especially if the name > looks like an I-D. > Ok, then the current related IDs are: draft-danisch-dns-rr-smtp-03.txt draft-fecyk-dsprotocol-04.txt draft-brand-drip-02.txt > Can you make sure this happens? > Yes, two more IDs should be on their way pretty soon. Thanks for pointing this out. Yakov From owner-ietf-mxcomp Fri Jan 30 14:35:09 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UMZ9aD026896; Fri, 30 Jan 2004 14:35:09 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0UMZ99A026895; Fri, 30 Jan 2004 14:35:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.74.5]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UMZ7bb026885 for ; Fri, 30 Jan 2004 14:35:07 -0800 (PST) (envelope-from paf@cisco.com) Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 30 Jan 2004 23:35:41 +0100 Received: from xbe-ams-312.cisco.com (xbe-ams-312.cisco.com [144.254.228.202]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i0UMYbnu004976; Fri, 30 Jan 2004 23:34:38 +0100 (MET) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by xbe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 30 Jan 2004 23:34:59 +0100 Received: from [127.0.0.1] ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 30 Jan 2004 23:34:59 +0100 In-Reply-To: <401AA98A.7000501@solidmatrix.com> References: <40195927.6090306@solidmatrix.com> <2DC4D732-52ED-11D8-8D05-000A959CF516@cisco.com> <401AA98A.7000501@solidmatrix.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <8A094EF6-5374-11D8-8D05-000A959CF516@cisco.com> Cc: ietf-mxcomp@imc.org From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: Reading list Date: Fri, 30 Jan 2004 23:35:00 +0100 To: Yakov Shafranovich X-Mailer: Apple Mail (2.612) X-OriginalArrivalTime: 30 Jan 2004 22:34:59.0172 (UTC) FILETIME=[4B01EA40:01C3E781] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i0UMZ8bb026890 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2004-01-30, at 19.59, Yakov Shafranovich wrote: > Patrik Fältström wrote: >> >> Documents should be internet-drafts for the BOF, especially if the >> name looks like an I-D. >> > > Ok, then the current related IDs are: > > draft-danisch-dns-rr-smtp-03.txt > draft-fecyk-dsprotocol-04.txt > draft-brand-drip-02.txt > >> Can you make sure this happens? >> > > Yes, two more IDs should be on their way pretty soon. Thanks for > pointing this out. Perfect, thank you very much! paf From owner-ietf-mxcomp Sun Feb 1 17:41:04 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i121f4dr073726; Sun, 1 Feb 2004 17: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 i121f4Se073725; Sun, 1 Feb 2004 17:41:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gctc-sbs2000.gctc-mst.com (a-54-128-biz2.mts.net [209.202.54.128]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i121f2is073715 for ; Sun, 1 Feb 2004 17:41:03 -0800 (PST) (envelope-from gordonf@pan-am.ca) Subject: (take 2) draft-fecyk-dmp-01.txt Date: Sun, 1 Feb 2004 19:40:59 -0600 Message-ID: <05D35E1950E75B4C83E25A4BA890D027568FD0@gctc-sbs2000.gctc-mst.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: (take 2) draft-fecyk-dmp-01.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 thread-index: AcPpLZwY+8FHPWK7QHqPt34MD9YRjA== Content-Class: urn:content-classes:message From: "Gordon Fecyk - Pan-Am" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i121f3is073720 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I subscribed but for some reason my first post didn't get through. And my last one won't go through because my from line was incorrect. draft-fecyk-dsprotocol-04 was mentioned in the archive of this list. That draft was obsoleted some time ago by draft-fecyk-dmp-01.txt. -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Wed Feb 4 14:30:13 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i14MUDmv083719; Wed, 4 Feb 2004 14:30: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 i14MUDrr083718; Wed, 4 Feb 2004 14:30:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from srv1.fecyk.ca (srv1.fecyk.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with SMTP id i14MUBLp083710 for ; Wed, 4 Feb 2004 14:30:12 -0800 (PST) (envelope-from gordonf@pan-am.ca) Received: from gordshome (wnpgmb11dc1-167-232.dynamic.mts.net [142.161.167.232]) by srv1.fecyk.ca (SMTPRCV 0.48) with SMTP id ; Wed, 04 Feb 2004 16:30:19 -0600 From: "Gordon Fecyk - Home" To: Subject: A specific day chosen? Date: Wed, 4 Feb 2004 16:32:06 -0600 Message-ID: <002301c3eb6e$b83be9d0$6701a8c0@fecyk.ca> 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 CWS, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Was a specific day of the meeting week chosen to discuss the MXcomp BOF? Or is this to be discussed over several days? I want to make sure I'm available on those days. -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Thu Feb 5 11:19:58 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i15JJwvu045303; Thu, 5 Feb 2004 11:19:58 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i15JJwkh045302; Thu, 5 Feb 2004 11:19:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i15JJv6E045293 for ; Thu, 5 Feb 2004 11:19:57 -0800 (PST) (envelope-from hadmut@danisch.de) Received: from andromeda (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i15JK7Z5032168 for ietf-mxcomp@imc.org; Thu, 5 Feb 2004 20:20:07 +0100 Received: (from hadmut@localhost) by andromeda.dresden.danisch.de (8.12.10/8.12.10/Debian-5) id i15JGbRP012474 for ietf-mxcomp@imc.org; Thu, 5 Feb 2004 20:16:37 +0100 From: Hadmut Danisch Date: Thu, 5 Feb 2004 20:16:37 +0100 To: ietf-mxcomp@imc.org Subject: Hi Message-ID: <20040205191637.GA12341@danisch.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, I just joined the list and I'm happy to see this working group. Unfortunately I won't be able to attend the next IETF. Will there be a webcast or something like that? I've just released another draft, http://www.ietf.org/internet-drafts/draft-danisch-scaf-00.txt which is about the generalization of RMX and similar proposals to other network services and directory services. I do understand that this working group is intended to focus on Mail and DNS (as it's name says), but such a mechanism is quite powerful and should not be limited to E-Mail only. Services like Chat and News do have a Spam problem as well. Don't lock them out from a solution. I do not ask you to give up focussing on Mail. That's important to get good results soon. All I ask you is to keep the idea silently in mind and when the search path in DNS space is to be defined just have a path element included specifying that this information is for Mail sender information only, and that similar information for other services could be stored in the very same way and used with the very same software by replacing this particular element with a different one. (Just a correction for Yakov's list for the BOF: RMX was first published in Dec 02. It is derived from my security research in 1992-98 at the European Institute for System Security and my work as a Security Consultant since 1998). regards Hadmut From owner-ietf-mxcomp Sun Feb 8 14:26:54 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i18MQsKR077007; Sun, 8 Feb 2004 14:26:54 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i18MQsNQ077006; Sun, 8 Feb 2004 14:26:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.41]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i18MQqbV076997 for ; Sun, 8 Feb 2004 14:26:53 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.51] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1ApxOL-0006W6-00 for ietf-mxcomp@imc.org; Sun, 08 Feb 2004 17:27:05 -0500 Received: from [68.29.150.141] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1ApxOJ-0007tZ-00 for ietf-mxcomp@imc.org; Sun, 08 Feb 2004 17:27:05 -0500 Message-ID: <4026B7AC.2030901@solidmatrix.com> Date: Sun, 08 Feb 2004 17:26:52 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: ietf-mxcomp@imc.org Subject: ASRG's Discussion document on LMAP X-Enigmail-Version: 0.82.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: We submitted the ASRG discussion document on LMAP as an Internet draft. It will probably take some time for it to get posted due to the ID backlog. You can find a copy of it here before it gets posted to the IETF ID archive: http://asrg.kavi.com/apps/group_public/download.php/31/draft-irtf-asrg-lmap-discussion-00.txt We will probably submit a follow up -01 draft before the February 16th deadline. Yakov ------- Yakov Shafranovich / asrg shaftek.org SolidMatrix Technologies, Inc. / research solidmatrix.com "Be liberal in what you accept, and conservative in what you send" (Jon Postel) ------- From owner-ietf-mxcomp Mon Feb 9 08:50:18 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i19GoI1I043924; Mon, 9 Feb 2004 08:50: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 i19GoIcT043923; Mon, 9 Feb 2004 08:50:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i19GoDEA043899 for ; Mon, 9 Feb 2004 08:50:14 -0800 (PST) (envelope-from hadmut@danisch.de) Received: from andromeda (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i19GoEeP029416; Mon, 9 Feb 2004 17:50:14 +0100 Received: (from hadmut@localhost) by andromeda.dresden.danisch.de (8.12.10/8.12.10/Debian-5) id i19Go4ox013063; Mon, 9 Feb 2004 17:50:04 +0100 From: Hadmut Danisch Date: Mon, 9 Feb 2004 17:50:04 +0100 To: smtp-verify@asrg.sp.am, ietf-mxcomp@imc.org, asrg@ietf.org Subject: Devilish: Forget about DNS Message-ID: <20040209165004.GA12761@danisch.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Folks, there has been a lot of discussion about how to cope with the limitations of stone age service DNS. DNS is difficult to extend for new record types, which makes it expensive to introduce a new record type like RMX RR. The currently existing record types make it difficult to store the relevant information, as has been seen by many of the proposals so far, e.g. when people need to store boolen values or integer numbers in A records. When you need to store more information, you need to perform special tricks to store them, like Microsoft's CallerID proposal, which assembles the information from several TXT entries. And - last not least - we are struggling with the packet size limitations and the dualism of UDP and TCP. I'd like to initiate a new discussion thread with this proposal: Forget about DNS (except to use it for what it was built for). We could use a much more modern and robust protocol, the famous and ubiquous HTTP. When we do receive a message from a domain somedomain.com sent from IP address a.b.c.d then we could simple contact the host _lmap.somedomain.com port 80 or - even better - get the SRV entry for _tcp._lmap.somedomain.com which would allow multiple servers, fallback servers, and arbitrary ports. At this port we could fetch from URL /_lmap/somedomain.com (to allow the same server to serve several domains, and receive whatever record format we're going to define, like simple entry lines, XML, ASN.1 or whatever. Need Caching? Just use any HTTP Cache. HTTP pretty well supports transmission of expiry information. Even better: The record could contain a directive to do dynamic queries. In this case we could query /_lmap/somedomain.com.query?ipv4=a.b.c.d or /_lmap/query?domain=somedomain.com&ipv4=a.b.c.d Where the query could be virtually anything if describing it with SPF's macro expansion (maybe include the receiving MTA's country, the MessageID, the size,...). This would allow to easily offer dynamic services as described in http://www.ietf.org/internet-drafts/draft-danisch-scaf-00.txt Additionally, could optionally provide some kind of security with HTTPS. This is robust, easy to maintain, no need for large scale software replacement, in simple cases it's just a file to be put on a webserver, or people can write CGI scripts for any special case. And today, virtually every domain owner should be able to have a file placed somewere on any web server. And updating the file is easier than with DNS's expiry mechanisms. So all we need bloody DNS for is the A and maybe the SRV record to find the server. No tricks, no record type abuse, no hunting for lost TXT records. Just normal use of existing protocols exactly for what they have been designed for. :-) Hadmut (I was too busy to follow all mailing lists within the last months. Would anyone gimme a hint if this has been proposed already?) From owner-ietf-mxcomp Mon Feb 9 09:12:16 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i19HCF20045532; Mon, 9 Feb 2004 09:12:16 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i19HCF1D045527; Mon, 9 Feb 2004 09:12:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from paf.se (argv.paf.se [195.66.31.72]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i19HCDEZ045423 for ; Mon, 9 Feb 2004 09:12:13 -0800 (PST) (envelope-from paf@cisco.com) Received: from [195.66.31.70] (account paf [195.66.31.70] verified) by paf.se (CommuniGate Pro SMTP 4.1.8) with ESMTP id 1421675; Mon, 09 Feb 2004 18:11:34 +0100 In-Reply-To: <20040209165004.GA12761@danisch.de> References: <20040209165004.GA12761@danisch.de> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1141F1C8-5B23-11D8-B0AE-000A959CF516@cisco.com> Content-Transfer-Encoding: 7bit Cc: ietf-mxcomp@imc.org, asrg@ietf.org, smtp-verify@asrg.sp.am From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: Devilish: Forget about DNS Date: Mon, 9 Feb 2004 18:11:57 +0100 To: Hadmut Danisch X-Mailer: Apple Mail (2.612) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2004-02-09, at 17.50, Hadmut Danisch wrote: > DNS is difficult to extend for new record types, which makes > it expensive to introduce a new record type like RMX RR. I don't agree with this. I think we should start the discussion right here. What do you base this information on? (I had this view some 5 years ago, but was convinced I was wrong...and now I am on the other side ;-) paf From owner-ietf-mxcomp Mon Feb 9 09:14:01 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i19HE13p045858; Mon, 9 Feb 2004 09:14:01 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i19HE1gC045856; Mon, 9 Feb 2004 09:14:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i19HE0LY045844 for ; Mon, 9 Feb 2004 09:14:00 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.10/) with ESMTP id i19HE9lG002451; Mon, 9 Feb 2004 09:14:09 -0800 (PST) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2653.19) id <13JX706B>; Mon, 9 Feb 2004 09:14:09 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Hadmut Danisch'" , smtp-verify@asrg.sp.am, ietf-mxcomp@imc.org, asrg@ietf.org Subject: RE: [Asrg] Devilish: Forget about DNS Date: Mon, 9 Feb 2004 09:14:00 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > there has been a lot of discussion about how to cope with the > limitations of stone age service DNS. > > DNS is difficult to extend for new record types, which makes > it expensive to introduce a new record type like RMX RR. It is also deployed and it works. The problems with the extension mechanism are in my view dealt with by the _protocol mechanism introduced in SRV and used in NAPTR as well as many of the proposals on the table. > And - last not least - we are struggling with the packet size > limitations and the dualism of UDP and TCP. The proposal to introduce XML into SPF makes a lot of sense if you expect the DNS itself to be replaced at some point in the near future with something XML based. I would not recommend going to HTTP or TCP here, I would look at using something like DIME over UDP with a lightweight session layer - TCP is not designed well for transactions of one to four packets. Then we get into the usual issues, this has been proposed so often in the past that there are strong immune responses tuned to reject anything like it on sight in the IETF. From owner-ietf-mxcomp Mon Feb 9 09:30:01 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i19HU004046882; Mon, 9 Feb 2004 09:30: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 i19HU0rh046878; Mon, 9 Feb 2004 09:30:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i19HTxtx046872 for ; Mon, 9 Feb 2004 09:29:59 -0800 (PST) (envelope-from hadmut@danisch.de) Received: from andromeda (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i19HU7Jc030871; Mon, 9 Feb 2004 18:30:07 +0100 Received: (from hadmut@localhost) by andromeda.dresden.danisch.de (8.12.10/8.12.10/Debian-5) id i19HRLeg013450; Mon, 9 Feb 2004 18:27:21 +0100 From: Hadmut Danisch Date: Mon, 9 Feb 2004 18:27:20 +0100 To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= Cc: ietf-mxcomp@imc.org, asrg@ietf.org, smtp-verify@asrg.sp.am Subject: Re: Devilish: Forget about DNS Message-ID: <20040209172720.GA13347@danisch.de> References: <20040209165004.GA12761@danisch.de> <1141F1C8-5B23-11D8-B0AE-000A959CF516@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1141F1C8-5B23-11D8-B0AE-000A959CF516@cisco.com> User-Agent: Mutt/1.5.5.1+cvs20040105i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Feb 09, 2004 at 06:11:57PM +0100, Patrik Fältström wrote: > On 2004-02-09, at 17.50, Hadmut Danisch wrote: > > >DNS is difficult to extend for new record types, which makes > >it expensive to introduce a new record type like RMX RR. > > I don't agree with this. > > I think we should start the discussion right here. What do you base > this information on? I proposed to introduce a new RR with the first version of the RMX draft in December 2002. Since then I'm drowning in mails like "How can you dare...", "We don't want...", "Too many old DNS servers, which can't be replaced...", "Too expensive...", "Too much overhead...", "Will take 10-20 years...", "We don't support this...", "Proprietary DNS server, can't be extended...", "Needs to replace billions of DNS client softare..." and much, much more of that. The other problem is that many, many people complained that they would need to change the firewall or even network structure because records would grow beyond 512 bytes and require TCP queries. As if many of today's DNS records wouldn't be longer than 512 bytes anyway. But if we accept to query DNS records with TCP, why, after all, should we bother to fetch all entries and to stitch information together from differen TXT and A records or a new record type? HTTP is just perfect for fetching a record of any data type and any length. And it exists. No need to replace or update HTTP servers. All we need is to find the HTTP server which is competent to give the answer. Finding the HTTP server is a DNS task, that's what DNS is designed to do. And a HTTP query is imho significantly better than trying to fetch several records throuth DNS/TCP and trying to stitch them together (and no way to trigger the DNS server to refetch missing records). Hadmut From owner-ietf-mxcomp Mon Feb 9 09:34:53 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i19HYr12047191; Mon, 9 Feb 2004 09:34: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 i19HYr4Q047190; Mon, 9 Feb 2004 09:34:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i19HYqBh047181 for ; Mon, 9 Feb 2004 09:34:52 -0800 (PST) (envelope-from hadmut@danisch.de) Received: from andromeda (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i19HZ7nF031094; Mon, 9 Feb 2004 18:35:07 +0100 Received: (from hadmut@localhost) by andromeda.dresden.danisch.de (8.12.10/8.12.10/Debian-5) id i19HUO8K013493; Mon, 9 Feb 2004 18:30:24 +0100 From: Hadmut Danisch Date: Mon, 9 Feb 2004 18:30:24 +0100 To: "Hallam-Baker, Phillip" Cc: smtp-verify@asrg.sp.am, ietf-mxcomp@imc.org, asrg@ietf.org Subject: Re: [Asrg] Devilish: Forget about DNS Message-ID: <20040209173024.GB13347@danisch.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1+cvs20040105i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Feb 09, 2004 at 09:14:00AM -0800, Hallam-Baker, Phillip wrote: > > I would not recommend going to HTTP or TCP here, I would look at using > something like DIME over UDP with a lightweight session layer - TCP is not > designed well for transactions of one to four packets. On the contrary: While I agree with you on one hand, the network carries tons of HTTP queries which are answered with one to four packets, and nobody cares about. So why should it be worse to fetch RMX/LMAP/whatever records the same way? The TCP with few packets proplem is a separate problem. Let someone else improve HTTP and benefit once this will be done in future. Hadmut From owner-ietf-mxcomp Mon Feb 9 09:37:47 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i19Hbk8a047356; Mon, 9 Feb 2004 09:37: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 i19HbkJ4047355; Mon, 9 Feb 2004 09:37:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i19HbjVi047346 for ; Mon, 9 Feb 2004 09:37:45 -0800 (PST) (envelope-from hadmut@danisch.de) Received: from andromeda (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i19Hc0RE031203; Mon, 9 Feb 2004 18:38:00 +0100 Received: (from hadmut@localhost) by andromeda.dresden.danisch.de (8.12.10/8.12.10/Debian-5) id i19Hbjjw013568; Mon, 9 Feb 2004 18:37:45 +0100 From: Hadmut Danisch Date: Mon, 9 Feb 2004 18:37:45 +0100 To: smtp-verify@asrg.sp.am, ietf-mxcomp@imc.org, asrg@ietf.org Subject: Re: Devilish: Forget about DNS Message-ID: <20040209173745.GA13511@danisch.de> References: <20040209165004.GA12761@danisch.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040209165004.GA12761@danisch.de> User-Agent: Mutt/1.5.5.1+cvs20040105i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: After spending 20 more minutes to think about I'd go somewhat more into detail: If wanting to fetch the record for somedomain.com do a DNS query for A, SRV and TXT record (or ANY) on _lmap.somedomain.com (violates the SRV RFC a little bit, but for sake of efficiency) If a SRV record is found then try the servers as described in the SRV records elsif A records are found then try on of them or one after another, Port 80 else error, no record available. end If TXT record available then run it through maxcro expansion for sender name, IP address, MessageID,... and take this as the URL to query. (if macro after first '?' then protect special characters as usual in URL query parameters) else use default URL /_lmap/somedomain.com end -> Fetch record and evaluate Hadmut From owner-ietf-mxcomp Mon Feb 9 10:06:22 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i19I6MkJ049004; Mon, 9 Feb 2004 10: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 i19I6MD0049003; Mon, 9 Feb 2004 10:06:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i19I6LBF048997 for ; Mon, 9 Feb 2004 10:06:21 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i19IEpd24168; Mon, 9 Feb 2004 10:14:51 -0800 Date: Mon, 9 Feb 2004 10:06:21 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1527804864.20040209100621@brandenburg.com> To: Hadmut Danisch CC: smtp-verify@asrg.sp.am, ietf-mxcomp@imc.org, asrg@ietf.org Subject: Re: [Asrg] Devilish: Forget about DNS In-Reply-To: <20040209165004.GA12761@danisch.de> References: <20040209165004.GA12761@danisch.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hadmut, HD> We could use a much more modern and robust protocol, the HD> famous and ubiquous HTTP. Let's see if I understand your proposal: You want to stop using a distributed lookup service that has worked well for 15 years, and you want to replace it with a point-to-point document retrieval service? Oh, no. That's wrong. You want to continue using DNS 'for what it was built' which is mapping between names and addresses. You just don't want to use it for this particular, new name/address mapping. And, by the way, most of the difficulties making changes that you cite have to do with implementation and operation, not protocol. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Mon Feb 9 10:24:56 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i19IOuto050272; Mon, 9 Feb 2004 10:24: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 i19IOu7d050271; Mon, 9 Feb 2004 10:24:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i19IOs17050265 for ; Mon, 9 Feb 2004 10:24:55 -0800 (PST) (envelope-from hadmut@danisch.de) Received: from andromeda (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i19IP6ZX000434; Mon, 9 Feb 2004 19:25:06 +0100 Received: (from hadmut@localhost) by andromeda.dresden.danisch.de (8.12.10/8.12.10/Debian-5) id i19IL9m3014125; Mon, 9 Feb 2004 19:21:09 +0100 From: Hadmut Danisch Date: Mon, 9 Feb 2004 19:21:09 +0100 To: Dave Crocker Cc: smtp-verify@asrg.sp.am, ietf-mxcomp@imc.org, asrg@ietf.org Subject: Re: [Asrg] Devilish: Forget about DNS Message-ID: <20040209182109.GB13974@danisch.de> References: <20040209165004.GA12761@danisch.de> <1527804864.20040209100621@brandenburg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1527804864.20040209100621@brandenburg.com> User-Agent: Mutt/1.5.5.1+cvs20040105i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Feb 09, 2004 at 10:06:21AM -0800, Dave Crocker wrote: > Hadmut, > > HD> We could use a much more modern and robust protocol, the > HD> famous and ubiquous HTTP. > > Let's see if I understand your proposal: > > You want to stop using a distributed lookup service that has worked well > for 15 years, and you want to replace it with a point-to-point document > retrieval service? No. You don't understand my proposal. > Oh, no. That's wrong. You want to continue using DNS 'for what it was > built' which is mapping between names and addresses. You just don't want > to use it for this particular, new name/address mapping. No. Again, you don't understand my proposal. I just don't want to use DNS to this particular, new name -> lmap record mapping, where the record is some arbitrary octet sequence of maybe several kilobytes. DNS has never been built oder designed for that purpose. So how could it be wrong to not use DNS for something it has not been made for? And, furthermore, analysis of all the comments I received for my RMX drafts and recent discussions showed that some domains would need to dynamically generate the records depending on the query (see the hotmail example in http://www.ietf.org/internet-drafts/draft-danisch-scaf-00.txt DNS is currently completely unable to provide dynamically generated replies. HTTP servers can easily do that (CGI). Again: I don't want to replace DNS in any way. I just don't want to invent a new use for DNS which DNS can't do properly. That's all. regards Hadmut From owner-ietf-mxcomp Mon Feb 9 11:27:09 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i19JR936053954; Mon, 9 Feb 2004 11:27:09 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i19JR9U5053949; Mon, 9 Feb 2004 11:27:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.41]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i19JR7N1053938 for ; Mon, 9 Feb 2004 11:27:07 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.51] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1AqH3z-0008Rm-00; Mon, 09 Feb 2004 14:27:23 -0500 Received: from [68.29.206.45] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1AqH3y-0001tn-00; Mon, 09 Feb 2004 14:27:23 -0500 Message-ID: <4027DF0B.5010501@solidmatrix.com> Date: Mon, 09 Feb 2004 14:27:07 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Dave Crocker CC: Hadmut Danisch , smtp-verify@asrg.sp.am, ietf-mxcomp@imc.org, asrg@ietf.org Subject: Re: [Asrg] Devilish: Forget about DNS References: <20040209165004.GA12761@danisch.de> <1527804864.20040209100621@brandenburg.com> In-Reply-To: <1527804864.20040209100621@brandenburg.com> X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dave Crocker wrote: > Oh, no. That's wrong. You want to continue using DNS 'for what it was > built' which is mapping between names and addresses. You just don't want > to use it for this particular, new name/address mapping. > RMX/LMAP drafts address the question of relationships between a given domain and a given MTA's IP address. There is nothing wrong with using DNS for this purpose and as a matter of fact, the XMPP draft uses a very similar mechanism via DNS. HOWEVER, if you want to store sender's identity in DNS that is a different question. Then, I would agree with Hadmut that DNS was not designed to store information about specific email accounts. Yakov ------- Yakov Shafranovich / asrg shaftek.org SolidMatrix Technologies, Inc. / research solidmatrix.com "Why are both drug addicts and computer aficionados both called users?" (Clifford Stoll) ------- From owner-ietf-mxcomp Mon Feb 9 11:57:28 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i19JvRcF055625; Mon, 9 Feb 2004 11:57:27 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i19JvRtw055624; Mon, 9 Feb 2004 11:57:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.74.5]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i19JvPLQ055615 for ; Mon, 9 Feb 2004 11:57:26 -0800 (PST) (envelope-from paf@cisco.com) Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 09 Feb 2004 20:58:15 +0100 Received: from XBE-AMS-302.cisco.com (xbe-ams-302.cisco.com [144.254.75.92]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i19JvCL3006807; Mon, 9 Feb 2004 20:57:14 +0100 (MET) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by XBE-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 9 Feb 2004 20:57:04 +0100 Received: from [127.0.0.1] ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 9 Feb 2004 20:57:35 +0100 In-Reply-To: <20040209172720.GA13347@danisch.de> References: <20040209165004.GA12761@danisch.de> <1141F1C8-5B23-11D8-B0AE-000A959CF516@cisco.com> <20040209172720.GA13347@danisch.de> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4366695D-5B3A-11D8-ABA0-000A959CF516@cisco.com> Content-Transfer-Encoding: 7bit Cc: ietf-mxcomp@imc.org, asrg@ietf.org, smtp-verify@asrg.sp.am From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: Devilish: Forget about DNS Date: Mon, 9 Feb 2004 20:58:00 +0100 To: Hadmut Danisch X-Mailer: Apple Mail (2.612) X-OriginalArrivalTime: 09 Feb 2004 19:57:35.0613 (UTC) FILETIME=[F656AAD0:01C3EF46] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I see several issues here: > I proposed to introduce a new RR with the first version of the > RMX draft in December 2002. Since then I'm drowning in mails like > "How can you dare...", "We don't want...", "Too many old DNS > servers, which can't be replaced..." Three problems here: (1) The zone file syntax might not be able to handle a new RR _name_ because of parser issues (2) The zone file syntax might not be able to handle a numeric RR type (3) A caching resolver might not be able to cache an unknown RR Out of these (3) is broken software. (2) is problematic and (1) is something users have to manage. > , "Too expensive...", Expensive? > "Too > much overhead...", ??? > "Will take 10-20 years...", "We don't support > this...", "Proprietary DNS server, can't be extended...", Well, NAPTR and SRV took not so many years, and in reality a new round of patches for Bind. Remember that we talk about something which is to be visible in the global DNS, which normally public DNS software is in use. The proprietary stuff is normally hidden inside enterprises (or should be replaced anyway). > "Needs to > replace billions of DNS client softare..." No. This I do not agree with. I have not seen any library which can not query for random RR types. Of course, programmers might be lazy and can not write their own code which parse a new RR type, but this is not an argument for me. For example (good or bad example, you decide...) implementing ENUM using NAPTR as part of IOS in Cisco Routers was not a big deal from a DNS point of view. > and much, much more of > that. Yes, a lot of people say these things....but I have not heard for example people in the DNSEXT wg say such things. They instead say things like "don't overload RR type values in the names (like SRV)" and "don't overload use in RR types (like TXT and NAPTR)". > The other problem is that many, many people complained that they > would need to change the firewall or even network structure because > records would grow beyond 512 bytes and require TCP queries. > As if many of today's DNS records wouldn't be longer than 512 bytes > anyway. Correct. Two issues here: (1) I see a larger risk the rr set expands above 512 bytes if we do NOT use a specialized RR type which minimize the size of the data, and the size of the RR set when sending a query. (2) If they have a firewall which doesn't allow DNS over TCP, they have other problems already. > But if we accept to query DNS records with TCP, why, after all, should > we bother to fetch all entries and to stitch information together from > differen TXT and A records or a new record type? We don't want to use TCP. > HTTP is just perfect > for fetching a record of any data type and any length. And it exists. > No need to replace or update HTTP servers. No, HTTP is not fun. Any implementation of HTTP is multiple degrees harder to implement that DNS. Have you read the spec? > All we need is to find the HTTP server which is competent to give the > answer. Finding the HTTP server is a DNS task, that's what DNS is > designed to do. > > And a HTTP query is imho significantly better than trying to fetch > several records throuth DNS/TCP and trying to stitch them together > (and no way to trigger the DNS server to refetch missing records). If you need to first use DNS, and then some other protocol, then this other protocol should be defined so it solves the problem which is to be solved. We should not get a bulldozer to try to catch flies. See for example RFC 3205. paf From owner-ietf-mxcomp Mon Feb 9 12:09:25 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i19K9PHb056147; Mon, 9 Feb 2004 12:09: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 i19K9PSu056146; Mon, 9 Feb 2004 12:09:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.41]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i19K9N7v056140 for ; Mon, 9 Feb 2004 12:09:23 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.51] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1AqHie-0007qq-00; Mon, 09 Feb 2004 15:09:24 -0500 Received: from [68.29.206.45] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1AqHic-0002hW-00; Mon, 09 Feb 2004 15:09:24 -0500 Message-ID: <4027E8E8.3040404@solidmatrix.com> Date: Mon, 09 Feb 2004 15:09:12 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= CC: Hadmut Danisch , ietf-mxcomp@imc.org, asrg@ietf.org Subject: Re: Devilish: Forget about DNS References: <20040209165004.GA12761@danisch.de> <1141F1C8-5B23-11D8-B0AE-000A959CF516@cisco.com> <20040209172720.GA13347@danisch.de> <4366695D-5B3A-11D8-ABA0-000A959CF516@cisco.com> In-Reply-To: <4366695D-5B3A-11D8-ABA0-000A959CF516@cisco.com> X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Patrik Fältström wrote: > I see several issues here: > >> I proposed to introduce a new RR with the first version of the >> RMX draft in December 2002. Since then I'm drowning in mails like >> "How can you dare...", "We don't want...", "Too many old DNS >> servers, which can't be replaced..." > > > Three problems here: > > (1) The zone file syntax might not be able to handle a new RR _name_ > because of parser issues > (2) The zone file syntax might not be able to handle a numeric RR type > (3) A caching resolver might not be able to cache an unknown RR > > Out of these (3) is broken software. (2) is problematic and (1) is > something users have to manage. > I would like to add to this that XMPP uses SRV records to verify the domain name/server IP relationship. See http://www.ietf.org/internet-drafts/draft-ietf-xmpp-core-22.txt, section 14.3. Yakov ------- Yakov Shafranovich / asrg shaftek.org SolidMatrix Technologies, Inc. / research solidmatrix.com "But in this world nothing can be said to be certain, except death and taxes" (Benjamin Franklin) ------- From owner-ietf-mxcomp Mon Feb 9 12:47:41 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i19Klfm3058369; Mon, 9 Feb 2004 12:47: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 i19KlfrU058368; Mon, 9 Feb 2004 12:47:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.41]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i19KldjM058362 for ; Mon, 9 Feb 2004 12:47:39 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.51] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1AqIJx-0004Me-00 for ietf-mxcomp@imc.org; Mon, 09 Feb 2004 15:47:57 -0500 Received: from [68.29.206.45] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1AqIJw-0003Su-00 for ietf-mxcomp@imc.org; Mon, 09 Feb 2004 15:47:57 -0500 Message-ID: <4027F1F4.4040505@solidmatrix.com> Date: Mon, 09 Feb 2004 15:47:48 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: ietf-mxcomp@imc.org Subject: SPF Draft submitted as an Internet draft X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: SPF has been submitted as an Internet draft. A copy of it can be found here until its get posted by the ID admin: http://spf.pobox.com/draft-mengwong-spf-00.txt Yakov ------- Yakov Shafranovich / asrg shaftek.org SolidMatrix Technologies, Inc. / research solidmatrix.com "Among all our enemies / The ones to be most feared are often the smallest" (Jean de la Fontaine) ------- From owner-ietf-mxcomp Mon Feb 9 15:06:46 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i19N6kNU066779; Mon, 9 Feb 2004 15:06: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 i19N6kic066778; Mon, 9 Feb 2004 15:06:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.41]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i19N6jQ7066771 for ; Mon, 9 Feb 2004 15:06:45 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.50] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1AqKUX-00036p-00 for ietf-mxcomp@imc.org; Mon, 09 Feb 2004 18:07:01 -0500 Received: from [68.29.206.45] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1AqKUW-0003zh-00 for ietf-mxcomp@imc.org; Mon, 09 Feb 2004 18:07:01 -0500 Message-ID: <4028128B.9010201@solidmatrix.com> Date: Mon, 09 Feb 2004 18:06:51 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: ietf-mxcomp@imc.org Subject: MTA MARK draft on "Marking MTAs in rDNS" has posted X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: MTA MARK draft has been posted to the ID archive: http://www.ietf.org/internet-drafts/draft-stumpf-dns-mtamark-00.txt Abstract: " In contrast to other more extensive approaches to deal with unsolicited email, commonly called "spam", this memo discusses a very simple authentication scheme. It uses marking of hosts in reverse DNS (in-addr.arpa zone) to allow the receiving mail transfer agents to decide whether the connecting (sending) host is a designated mail transfer agent (MTA) or not. Despite being a weaker scheme than most of the other proposals currently discussed, it can reduce the amount of spam and viruses/ worms significantly and has the advantage that it can be implemented based on existing and well-established Internet technology like DNS without any changes to that technology. " Yakov ------- Yakov Shafranovich / asrg shaftek.org SolidMatrix Technologies, Inc. / research solidmatrix.com "I ate your Web page. / Forgive me. It was juicy / And tart on my tongue." (MIT's 404 Message) ------- From owner-ietf-mxcomp Tue Feb 10 11:17:29 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1AJHTft007944; Tue, 10 Feb 2004 11:17: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 i1AJHT4b007943; Tue, 10 Feb 2004 11:17:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.41]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1AJHRLt007932 for ; Tue, 10 Feb 2004 11:17:27 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.52] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1AqdO0-0001AJ-00 for ietf-mxcomp@imc.org; Tue, 10 Feb 2004 14:17:32 -0500 Received: from [68.29.152.163] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1AqdNz-0002UV-00 for ietf-mxcomp@imc.org; Tue, 10 Feb 2004 14:17:32 -0500 Message-ID: <40292E44.3080200@solidmatrix.com> Date: Tue, 10 Feb 2004 14:17:24 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: ietf-mxcomp@imc.org Subject: Updated reading list for the BOF X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: LMAP Discussion document from the ASRG: draft-irtf-asrg-lmap-discussion Proposals: draft-stumpf-dns-mtamark draft-brand-drip draft-danisch-dns-rr-smtp draft-fecyk-dmp draft-mengwong-spf draft-levine-fsv Yakov ------- Yakov Shafranovich / asrg shaftek.org SolidMatrix Technologies, Inc. / research solidmatrix.com "I ate your Web page. / Forgive me. It was juicy / And tart on my tongue." (MIT's 404 Message) ------- From owner-ietf-mxcomp Tue Feb 10 11:22:55 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1AJMtG9008620; Tue, 10 Feb 2004 11:22: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 i1AJMt2A008619; Tue, 10 Feb 2004 11:22:55 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from www.pan-am.ca ([209.82.56.246]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1AJMsSl008491 for ; Tue, 10 Feb 2004 11:22:54 -0800 (PST) (envelope-from gordonf@pan-am.ca) Subject: RE: Updated reading list for the BOF Date: Tue, 10 Feb 2004 13:21:50 -0600 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA754@srv1.pan-am.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Updated reading list for the BOF content-class: urn:content-classes:message Thread-Index: AcPwCsZ+9ggW/kNiQvGokqvxAe8FewAAB+5Q From: "Gordon Fecyk" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i1AJMsSl008614 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: What was the document for Microsoft's "caller-id" draft? Or was this going to be discussed? -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Tue Feb 10 11:26:22 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1AJQMfw008849; Tue, 10 Feb 2004 11:26: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 i1AJQMqk008848; Tue, 10 Feb 2004 11:26:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.41]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1AJQKED008841 for ; Tue, 10 Feb 2004 11:26:20 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.52] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1AqdWe-0001xs-00; Tue, 10 Feb 2004 14:26:28 -0500 Received: from [68.29.152.163] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1AqdWd-0002gf-00; Tue, 10 Feb 2004 14:26:28 -0500 Message-ID: <40293058.6090507@solidmatrix.com> Date: Tue, 10 Feb 2004 14:26:16 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Gordon Fecyk CC: ietf-mxcomp@imc.org Subject: Re: Updated reading list for the BOF References: <700EEF5641B7E247AC1C9B82C05D125DA754@srv1.pan-am.ca> In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125DA754@srv1.pan-am.ca> X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Gordon Fecyk wrote: > What was the document for Microsoft's "caller-id" draft? Or was this going > to be discussed? > As per the rules set down by the BOF chairs, only documents submitted as Internet drafts will be discussed. Microsoft declined to submit one, ergo they will not be discussed [although the bar BOF will probably mention them :) ]. Yakov ------- Yakov Shafranovich / asrg shaftek.org SolidMatrix Technologies, Inc. / research solidmatrix.com "All that is gold does not glitter" (LOTR) ------- From owner-ietf-mxcomp Tue Feb 10 11:51:10 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1AJpAsk010596; Tue, 10 Feb 2004 11:51: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 i1AJpAcV010595; Tue, 10 Feb 2004 11:51:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.74.5]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1AJp8f6010576 for ; Tue, 10 Feb 2004 11:51:08 -0800 (PST) (envelope-from paf@cisco.com) Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 10 Feb 2004 20:51:51 +0100 Received: from XBE-AMS-302.cisco.com (xbe-ams-302.cisco.com [144.254.75.92]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1AJomL1027506; Tue, 10 Feb 2004 20:50:49 +0100 (MET) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by XBE-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 10 Feb 2004 20:50:39 +0100 Received: from [127.0.0.1] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 10 Feb 2004 20:51:12 +0100 In-Reply-To: <40293058.6090507@solidmatrix.com> References: <700EEF5641B7E247AC1C9B82C05D125DA754@srv1.pan-am.ca> <40293058.6090507@solidmatrix.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <98029F96-5C02-11D8-B4E7-000A959CF516@cisco.com> Content-Transfer-Encoding: 7bit Cc: Gordon Fecyk , ietf-mxcomp@imc.org From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: Updated reading list for the BOF Date: Tue, 10 Feb 2004 20:52:01 +0100 To: Yakov Shafranovich X-Mailer: Apple Mail (2.612) X-OriginalArrivalTime: 10 Feb 2004 19:51:12.0080 (UTC) FILETIME=[3C25ED00:01C3F00F] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2004-02-10, at 20.26, Yakov Shafranovich wrote: > Gordon Fecyk wrote: >> What was the document for Microsoft's "caller-id" draft? Or was this >> going >> to be discussed? > > As per the rules set down by the BOF chairs, only documents submitted > as Internet drafts will be discussed. Microsoft declined to submit > one, ergo they will not be discussed [although the bar BOF will > probably mention them :) ]. This is correct. Only documents existing in the I-D repository at the time of the meeting will be discussed. And the fact some bar-discussions might talk about whatever they want is also correct. But, the requirement for an I-D is needed so everyone is really on the same page... paf -- one of the co-chairs From owner-ietf-mxcomp Tue Feb 10 14:09:38 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1AM9bmB019298; Tue, 10 Feb 2004 14:09: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 i1AM9bda019294; Tue, 10 Feb 2004 14:09:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.41]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1AM9ZX0019280 for ; Tue, 10 Feb 2004 14:09:35 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.50] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1Aqg4h-0000ZK-00 for ietf-mxcomp@imc.org; Tue, 10 Feb 2004 17:09:47 -0500 Received: from [68.29.247.203] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1Aqg4g-0002AC-00 for ietf-mxcomp@imc.org; Tue, 10 Feb 2004 17:09:47 -0500 Message-ID: <402956A0.3010500@solidmatrix.com> Date: Tue, 10 Feb 2004 17:09:36 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: ietf-mxcomp@imc.org Subject: BOF Scheduled Time posted X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Looks like the BOF has been scheduled for Thursday morning: http://www.ietf.org/meetings/agenda_59.txt Yakov ------- Yakov Shafranovich / asrg shaftek.org SolidMatrix Technologies, Inc. / research solidmatrix.com "Power tends to corrupt, and absolute power corrupts absolutely" (Lord Acton) ------- From owner-ietf-mxcomp Tue Feb 10 14:21:11 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1AMLB0S020206; Tue, 10 Feb 2004 14:21: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 i1AMLBeC020205; Tue, 10 Feb 2004 14:21:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.74.5]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1AML9hJ020190 for ; Tue, 10 Feb 2004 14:21:10 -0800 (PST) (envelope-from paf@cisco.com) Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 10 Feb 2004 23:21:51 +0100 Received: from xbe-ams-312.cisco.com (xbe-ams-312.cisco.com [144.254.228.202]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1AMKnL3000174; Tue, 10 Feb 2004 23:20:51 +0100 (MET) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by xbe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 10 Feb 2004 23:21:14 +0100 Received: from [127.0.0.1] ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 10 Feb 2004 23:21:14 +0100 In-Reply-To: <402956A0.3010500@solidmatrix.com> References: <402956A0.3010500@solidmatrix.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8F881662-5C17-11D8-B1DB-000A959CF516@cisco.com> Content-Transfer-Encoding: 7bit Cc: ietf-mxcomp@imc.org From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: BOF Scheduled Time posted Date: Tue, 10 Feb 2004 23:22:06 +0100 To: Yakov Shafranovich X-Mailer: Apple Mail (2.612) X-OriginalArrivalTime: 10 Feb 2004 22:21:14.0168 (UTC) FILETIME=[31CF8B80:01C3F024] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2004-02-10, at 23.09, Yakov Shafranovich wrote: > Looks like the BOF has been scheduled for Thursday morning: > > http://www.ietf.org/meetings/agenda_59.txt Just remember this agenda is only very preliminary. The agenda is still changed. paf From owner-ietf-mxcomp Tue Feb 10 14:24:20 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1AMOKGx020407; Tue, 10 Feb 2004 14:24: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 i1AMOKjo020406; Tue, 10 Feb 2004 14:24:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.41]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1AMOIK6020400 for ; Tue, 10 Feb 2004 14:24:19 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.50] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1AqgIt-0002nB-00; Tue, 10 Feb 2004 17:24:27 -0500 Received: from [68.29.247.203] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1AqgIr-0002UA-00; Tue, 10 Feb 2004 17:24:27 -0500 Message-ID: <40295A09.4040909@solidmatrix.com> Date: Tue, 10 Feb 2004 17:24:09 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= CC: ietf-mxcomp@imc.org Subject: Re: BOF Scheduled Time posted References: <402956A0.3010500@solidmatrix.com> <8F881662-5C17-11D8-B1DB-000A959CF516@cisco.com> In-Reply-To: <8F881662-5C17-11D8-B1DB-000A959CF516@cisco.com> X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Patrik Fältström wrote: > > On 2004-02-10, at 23.09, Yakov Shafranovich wrote: > >> Looks like the BOF has been scheduled for Thursday morning: >> >> http://www.ietf.org/meetings/agenda_59.txt > > > Just remember this agenda is only very preliminary. The agenda is still > changed. > Yep, I realize that. As a matter of fact, we might want to take MS off the agenda, and perhaps discuss MTA MARK? Yakov ------- Yakov Shafranovich / asrg shaftek.org SolidMatrix Technologies, Inc. / research solidmatrix.com "Among all our enemies / The ones to be most feared are often the smallest" (Jean de la Fontaine) ------- From owner-ietf-mxcomp Tue Feb 10 15:05:33 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1AN5X0x022779; Tue, 10 Feb 2004 15:05: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 i1AN5XqA022778; Tue, 10 Feb 2004 15:05:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from www.pan-am.ca ([209.82.56.246]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1AN5WJX022769 for ; Tue, 10 Feb 2004 15:05:32 -0800 (PST) (envelope-from gordonf@pan-am.ca) Subject: RE: BOF Scheduled Time posted Date: Tue, 10 Feb 2004 17:05:43 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA758@srv1.pan-am.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: BOF Scheduled Time posted content-class: urn:content-classes:message Thread-Index: AcPwIqtfWuID5iIjQjqRIDQD3fhBDQABhijw From: "Gordon Fecyk" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i1AN5WJX022773 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Looks like the BOF has been scheduled for Thursday morning: > > http://www.ietf.org/meetings/agenda_59.txt As long as that's Thursday morning Seoul time, I'm happy. I have to leave at 15:00 on Thursday to catch my plane home (departure time is 18:00). Usually airlines want you there two hours before an international departure. If schedule changes make it impossible for me to attend the BOF, may I leave materials and questions with another attendee? It was either that, or wait until the following Tuesday to go home, and I can't afford that. :-) I plan on getting as familiar as I can in the preceding days - this is new to me, and I'm glad this BOF is later than most. -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Wed Feb 25 11:28:18 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PJSI0U028047; Wed, 25 Feb 2004 11:28: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 i1PJSIeo028045; Wed, 25 Feb 2004 11:28:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1PJSHT3028039 for ; Wed, 25 Feb 2004 11:28:17 -0800 (PST) (envelope-from hardie@qualcomm.com) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i1PJSHvf019942; Wed, 25 Feb 2004 11:28:17 -0800 (PST) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i1PJSFVK027366; Wed, 25 Feb 2004 11:28:16 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: Date: Wed, 25 Feb 2004 11:28:14 -0800 To: ietf-mxcomp@imc.org From: Ted Hardie Subject: Fwd: Updated agenda for MARID Cc: paf@cisco.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: [What has been updated is the list of I-D's so it matches what actually has been sent to the I-D archive. Thanks to Yakov for keeping track of the list of documents. /paf] MTA Authorization Records in DNS (marid) Thursday, March 4 at 0900-1130 ============================== CHAIRS: Patrik Faltstrom Ted Hardie DESCRIPTION: This meeting will review a set of related proposals for the DNS publication of data which authorizes SMTP senders within a specific domain. The proposals to be discussed vary in the proposed resource record type, syntax, and operation, but all include DNS publication of data intended to allow validation of IP address, envelope, or originator header data for SMTP MTAs. This BoF will be strictly limited to measures related to MTA authentication; no other anti-spam measures or topics will be considered. The BoF will explicitly consider how DNS-based MTA authentication mechanisms would be implemented and deployed, and it will consider the impact on the overall DNS infrastructure of this deployment. This meeting will discuss whether or not an IETF working group is needed to continue work on this topic. AGENDA: Agenda Bashing 5 Problem Overview 35 Taking draft-irtf-asrg-lmap-discussion-01.txt as a starting point, this discussion will focus on the problem these proposals attempt to solve, the broad outlines of the solution space proposed, and the constraints implied by that solution space. Current Proposals (1 hour together) MTAMARK - draft-stumpf-dns-mtamark-01.txt DRIP - draft-brand-drip-02.txt RMX - draft-danisch-dns-rr-smtp-03.txt DMP - draft-fecyk-dmp-01.txt SPF - draft-mengwong-spf-00.txt FSV - draft-levine-fsv-00.txt Implications for the DNS 15 Based on the current proposals, the BoF will discuss how this approach generally and each proposal specifically interacts with the DNS. Implications for SMTP 15 Based on the current proposals, the BoF will discuss how this approach generally and each proposal specifically interacts with existing and proposed mechanisms for mail transfer. Discussion of scope for IETF work 20 From owner-ietf-mxcomp Sat Feb 28 21:19:56 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1T5JtVY029154; Sat, 28 Feb 2004 21:19: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 i1T5JtUm029153; Sat, 28 Feb 2004 21:19:55 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.41]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1T5JsI0029146 for ; Sat, 28 Feb 2004 21:19:55 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.50] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1AxJMt-0004h9-00 for ietf-mxcomp@imc.org; Sun, 29 Feb 2004 00:19:59 -0500 Received: from [68.244.239.148] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1AxJMs-0001EQ-00 for ietf-mxcomp@imc.org; Sun, 29 Feb 2004 00:19:59 -0500 Message-ID: <40417676.6050207@solidmatrix.com> Date: Sun, 29 Feb 2004 00:19:50 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: ietf-mxcomp@imc.org Subject: Passing authentication information via SMTP X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: One of the concerns raised with LMAP proposals is the fact that they overload the MAIL FROM command. The following proposal passes such information via an ESMTP extension: http://www.ietf.org/internet-drafts/draft-pelletier-smtp-trust-01.txt This is might be something to consider in the long run. Yakov From owner-ietf-mxcomp Sat Feb 28 23:45:59 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1T7jwQM071417; Sat, 28 Feb 2004 23:45: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 i1T7jw4F071415; Sat, 28 Feb 2004 23:45:58 -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 (srv1.fecyk.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1T7juQS071398 for ; Sat, 28 Feb 2004 23:45:57 -0800 (PST) (envelope-from gordonf@pan-am.ca) Received: from termroompc03 ([218.37.216.103] unverified) by mail.pan-am.ca over TLS secured channel with Microsoft SMTPSVC(5.0.2195.6713); Sun, 29 Feb 2004 01:45:55 -0600 From: "Gordon Fecyk" To: Subject: RE: Passing authentication information via SMTP Date: Sun, 29 Feb 2004 16:45:49 +0900 Message-ID: <007701c3fe98$118663d0$67d825da@ietf59.or.kr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <40417676.6050207@solidmatrix.com> X-OriginalArrivalTime: 29 Feb 2004 07:45:55.0884 (UTC) FILETIME=[10529EC0:01C3FE98] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > One of the concerns raised with LMAP proposals is the fact that they > overload the MAIL FROM command. Isn't that the intent? I understand overloading a DNS record type - giving more meaning to a record type than originally intended. I'm not as clear on "overloading" a SMTP command, especially this one as MAIL FROM is supposed to tell us who the mail is from and we're only verifying that - at least as far as the domain part for most. From owner-ietf-mxcomp Sat Feb 28 23:52:42 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1T7qfvj073519; Sat, 28 Feb 2004 23:52: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 i1T7qfEv073516; Sat, 28 Feb 2004 23:52:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.40]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1T7qeOf073503 for ; Sat, 28 Feb 2004 23:52:41 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.50] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1AxLkd-0007uu-00; Sun, 29 Feb 2004 02:52:39 -0500 Received: from [68.244.239.148] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1AxLkb-00050l-00; Sun, 29 Feb 2004 02:52:39 -0500 Message-ID: <40419A38.4000100@solidmatrix.com> Date: Sun, 29 Feb 2004 02:52:24 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Gordon Fecyk CC: ietf-mxcomp@imc.org Subject: Re: Passing authentication information via SMTP References: <007701c3fe98$118663d0$67d825da@ietf59.or.kr> In-Reply-To: <007701c3fe98$118663d0$67d825da@ietf59.or.kr> X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Gordon Fecyk wrote: >>One of the concerns raised with LMAP proposals is the fact that they >>overload the MAIL FROM command. > > Isn't that the intent? > > I understand overloading a DNS record type - giving more meaning to a > record type than originally intended. > > I'm not as clear on "overloading" a SMTP command, especially this one as > MAIL FROM is supposed to tell us who the mail is from and we're only > verifying that - at least as far as the domain part for most. > The MAIL FROM parameter does not tell us where the mail is from, only the bounce address for that email. The assumption is that whoever is the bounce address is, is probably the sender, but in many cases especially mailing lists, that is not true. As a matter of fact in some protocols such as SMTP AUTH, the sender's identity is passed in an SMTP extension separate from the bounce address. This of course depends on what the LMAP proposals are designed to do. If they are designed to give domain owners ability to state which MTAs can use their domains in the bounce addresses, that's fine but it should be clearly stated as such and not be confused with the sender of the email, which is unknown during the SMTP transaction. Yakov From owner-ietf-mxcomp Sun Feb 29 01:30:02 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1T9U2oa004461; Sun, 29 Feb 2004 01:30: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 i1T9U2CI004459; Sun, 29 Feb 2004 01:30:02 -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 (srv1.fecyk.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1T9U0vd004445 for ; Sun, 29 Feb 2004 01:30:01 -0800 (PST) (envelope-from gordonf@pan-am.ca) Received: from termroompc03 ([218.37.216.103] unverified) by mail.pan-am.ca over TLS secured channel with Microsoft SMTPSVC(5.0.2195.6713); Sun, 29 Feb 2004 03:30:00 -0600 From: "Gordon Fecyk" To: Subject: RE: Passing authentication information via SMTP Date: Sun, 29 Feb 2004 18:29:54 +0900 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_01C3FEF2.0BACA370" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-MS-TNEF-Correlator: 00000000E2970D018E9A0740A1EBD1B2AF2FD16124052000 In-Reply-To: <40419A38.4000100@solidmatrix.com> Importance: Normal X-OriginalArrivalTime: 29 Feb 2004 09:30:01.0084 (UTC) FILETIME=[9AC083C0:01C3FEA6] 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_0000_01C3FEF2.0BACA370 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable > The MAIL FROM parameter does not tell us where the mail is from, only=20 > the bounce address for that email. The assumption is that whoever is = the=20 > bounce address is, is probably the sender, but in many cases = especially=20 > mailing lists, that is not true. As a matter of fact in some protocols = > such as SMTP AUTH, the sender's identity is passed in an SMTP = extension=20 > separate from the bounce address. The only other problem I have with the idea of overloading, then, is = support of non-ESMTP clients and servers. The ESMTP extension proposed has a prerequisite of ESMTP, and there are still many upgradable traditional = SMTP systems in use. All the *ix crowd can jeer if they want, but I'm interested in seeing ancient things like EMWAC IMS supporting a LMAP-type system. The = venerable IMS is still supported by a grassroots movement who've gone and = rewritten components of IMS to modernize it. To keep the project lightweight I = think they'd rather not have to parse ESMTP. Requiring ESMTP of a verification system but still requiring to support non-ESMTP also leaves a hole big enough for a spam truck to drive = through. Spammers could just revert to traditional SMTP to avoid this particular ESMTP extension, and (unless the server overloads an existing SMTP = command) the ESMTP server still has to accept mail from the non-ESMTP client by = ESMTP defenition. (RFC 2821 2.2.1 to start with). Aren't most virus SMTP = engines using traditional SMTP rather than ESMTP to keep the code small? ------=_NextPart_000_0000_01C3FEF2.0BACA370 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IgIJAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGAAcAAQAAAAAAAAEGgAMADgAAANQHAgAd ABIAHQAAAAAAKQEBA5AGALgJAAAtAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAAD AC4AAAAAAAIBMQABAAAAGAAAAAAAAADilw0BjpoHQKHr0bKvL9Fh5AQgAAMANgAAAAAAHgBwAAEA AAAsAAAAUGFzc2luZyBhdXRoZW50aWNhdGlvbiBpbmZvcm1hdGlvbiB2aWEgU01UUAACAXEAAQAA ABYAAAABw/6mgNTiR8dxQXxB/IrnQUT6osDeAAACAR0MAQAAABcAAABTTVRQOkdPUkRPTkZAUEFO LUFNLkNBAAALAAEOAAAAAEAABg4A1ld2pv7DAQIBCg4BAAAAGAAAAAAAAADilw0BjpoHQKHr0bKv L9FhwoAAAAMAFA4AAAAACwAfDgEAAAAeACgOAQAAACoAAAAwMDAwMDAwNwFnb3Jkb25mQHBhbi1h bS5jYQFtYWlsLnBhbi1hbS5jYQAAAB4AKQ4BAAAAKgAAADAwMDAwMDA3AWdvcmRvbmZAcGFuLWFt LmNhAW1haWwucGFuLWFtLmNhAAAAAgEJEAEAAACrBAAApwQAABkHAABMWkZ1MbJ9rwMACgByY3Bn MTI14jIDQ3RleAVBAQMB9/8KgAKkA+QHEwKAD/MAUARWPwhVB7IRJQ5RAwECAGNo4QrAc2V0MgYA BsMRJfYzBEYTtzASLBEzCO8J97Y7GB8OMDURIgxgYwBQMwsJAWQzNhZQC6YgPhAgVGhlBdBBSUxA IEZST00gCrFhJweADrAFwGRvB5Fub6sFQA6wbAMgdQQgdx0gvxggHxAdIQDAAxEEACADUuQsIAIg bHkK4wqAHPAjIAIG4HVuYx0wYWS+ZBggBBECEAXAIABhBUAqZSBCLh0DYQQQdW19BTBpAiAggiNj H6AeoHb/EoElEx0wIXYiPQQAIQAgkXpwA2BiAaAhQSACFBBucwSBIQBidQVAC4AgMW7dIVBjJGAH kQeQcAWQBzEnIUkgQguAZyAsMHN0bygBI2MgkR7jcgpQJABBnQQgYSAxAkASgW9mILA7ANAp03MD cB0wKGF0b38XkQQhIYUkgBPQJFEGAE3EVFAQwFVUSCzSKRbOJyfRAQACMGl0IVAoMv8kYQmAKeID kTFzDsEJ8ACQ+yThMHdlHfIOsCCzIe8EEP4uIXQhdB0SISMe8B+xKFPibCOwIEkgE+Al0B+QvzNA MSAgAjLxLkAu0W8l0W8XsCKgLEEyA24oEySAcI5wF8Euwh7gbi1FMXO+YywwMxEuISlQKSFyJdH9 N+AgHQM+BDTYKGE9QDPizxPgLiIoYB/BcXUEADNA/zjhLuA+AyEAPuI5YiKBH9H/LKADEAMgKiM9 IAnAIqAooT8f4UUhM0Ak0QdAMWRzeX8soCOwJ9EDoB9wLeA4CkFjH0EgAippeCpgA2B39zQAKnAD oGoJ4CXxLuAgAZUhUHcAcHQplEknNrC/C4AeUQeQDrA0AxQQZSxCfwBwKxAzER/xLEEEICwwa+E/ 4U1XQUM6IAXhPRXJTIMgTB1QUC0zUCrw90alP5Ul0G4EkEVTTmI84vdEUz0VM/FiIVAuQEURBBD/ A2Ae8AQgBGAl0AeATRElkXonOnFnAiAigT7xGCB3/wUQLoEDoAWgJKBVAT6iLtFPTmIwAFPhBIJp ejsRdP8/kldQTdA2AB/zKGFJwC8h4SwwZ2h0d0xwWcE6IfVNQmtKMydVYSOAOXIe4r86U1dBCrEU ED/0N/tSQjL/BRAsUT4ELtEuQCXRBpAN4P8jgCTSRrQpo0REQiNeU1dB/z0WPcgHQC+ALHA7UCXQ LiK7JaBFcWJZsCOgHuB1WcDfIxMuQCrgHiAtomNawVdQdSLAaVwiaANgZME/kVNPZXEHgBQAVhF1 bDQAav8fcAVAGCAl0R8BV1BFr1dBvTpgbzLwTTIzkk7xY2fw9wrBQA1DRCgiUDnwBBEo9P8/Qjun PsI0wSyRLEI+FANw+QOBZCkf8z4EbdVEREGS/WoyYyJwBTEgQzaHPc5S4h8+BAEBCfBF4yQAKFJG oU5AMjgyMXZQLnaw33aQYdIBkD1hOqIpP5EHEN0J8CdysUFABUB2XkAfcf80hCxQC4AHkR9wYZNF vltV/yNhA6A+BFdBWJcFoAEAKSArAMAfQD8hdH1+gAAeAEIQAQAAACMAAAA8NDA0MTlBMzguNDAw MDEwMEBzb2xpZG1hdHJpeC5jb20+AAADAJIQAAAAAAIBFDoBAAAAEAAAAGV9ccu7AgRBjeK5tD3P l6kDAN4/n04AAAMACVkBAAAAAwBAZQAAAAALABOACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAA AAMAJ4AIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAAAwA1gAggBgAAAAAAwAAAAAAAAEYAAAAA EIUAAAAAAAADADqACCAGAAAAAADAAAAAAAAARgAAAABShQAA45ABAB4AO4AIIAYAAAAAAMAAAAAA AABGAAAAAFSFAAABAAAABQAAADEwLjAAAAAACwA8gAggBgAAAAAAwAAAAAAAAEYAAAAABoUAAAAA AAALAECACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMARIAIIAYAAAAAAMAAAAAAAABGAAAA ABiFAAAAAAAACwBagAggBgAAAAAAwAAAAAAAAEYAAAAAgoUAAAEAAAACAfgPAQAAABAAAADilw0B jpoHQKHr0bKvL9FhAgH6DwEAAAAQAAAA4pcNAY6aB0Ch69Gyry/RYQIB+w8BAAAAlAAAAAAAAAA4 obsQBeUQGqG7CAArKlbCAABtc3BzdC5kbGwAAAAAAE5JVEH5v7gBAKoAN9luAAAAQzpcRG9jdW1l bnRzIGFuZCBTZXR0aW5nc1xpZXRmNTlcTG9jYWwgU2V0dGluZ3NcQXBwbGljYXRpb24gRGF0YVxN aWNyb3NvZnRcT3V0bG9va1xPdXRsb29rLnBzdAADAP4PBQAAAAMADTT9NwIAAgEUNAEAAAAQAAAA TklUQfm/uAEAqgA32W4AAAIBfwABAAAAMQAAADAwMDAwMDAwRTI5NzBEMDE4RTlBMDc0MEExRUJE MUIyQUYyRkQxNjEyNDA1MjAwMAAAAAADAAYQQLglngMABxC2BAAAAwAQEAEAAAADABEQAAAAAB4A CBABAAAAZQAAAFRIRU1BSUxGUk9NUEFSQU1FVEVSRE9FU05PVFRFTExVU1dIRVJFVEhFTUFJTElT RlJPTSxPTkxZVEhFQk9VTkNFQUREUkVTU0ZPUlRIQVRFTUFJTFRIRUFTU1VNUFRJT05JU1QAAAAA koc= ------=_NextPart_000_0000_01C3FEF2.0BACA370-- From owner-ietf-mxcomp Sun Feb 29 11:11:06 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1TJB5JU046476; Sun, 29 Feb 2004 11:11: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 i1TJB5kj046475; Sun, 29 Feb 2004 11:11:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.41]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1TJB4Lf046469 for ; Sun, 29 Feb 2004 11:11:04 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.50] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1AxWLC-0005G7-00; Sun, 29 Feb 2004 14:11:06 -0500 Received: from [68.244.153.112] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1AxWLB-0003rG-00; Sun, 29 Feb 2004 14:11:06 -0500 Message-ID: <4042393C.4000309@solidmatrix.com> Date: Sun, 29 Feb 2004 14:10:52 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Gordon Fecyk CC: ietf-mxcomp@imc.org Subject: Re: Passing authentication information via SMTP References: In-Reply-To: X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Gordon Fecyk wrote: >>The MAIL FROM parameter does not tell us where the mail is from, only >>the bounce address for that email. The assumption is that whoever is the >>bounce address is, is probably the sender, but in many cases especially >>mailing lists, that is not true. As a matter of fact in some protocols >>such as SMTP AUTH, the sender's identity is passed in an SMTP extension >>separate from the bounce address. > > > The only other problem I have with the idea of overloading, then, is support > of non-ESMTP clients and servers. The ESMTP extension proposed has a > prerequisite of ESMTP, and there are still many upgradable traditional SMTP > systems in use. > That is correct. With LMAP you have to change the receiver's MTA software and the sender's DNS records. With this SMTP extension, you also have to change the sender's SMTP software. It does impose a higher burden which might or might not be justified. This might be one of the things we will end up discussing here. > Requiring ESMTP of a verification system but still requiring to support > non-ESMTP also leaves a hole big enough for a spam truck to drive through. > Spammers could just revert to traditional SMTP to avoid this particular > ESMTP extension, and (unless the server overloads an existing SMTP command) > the ESMTP server still has to accept mail from the non-ESMTP client by ESMTP > defenition. (RFC 2821 2.2.1 to start with). Aren't most virus SMTP engines > using traditional SMTP rather than ESMTP to keep the code small? Even with regular LMAP, spammers that do not publish LMAP records are essentially doing the same thing, and you have a range of ways to deal with it. Yakov From owner-ietf-mxcomp Sun Feb 29 11:16:04 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1TJG4lY046756; Sun, 29 Feb 2004 11:16: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 i1TJG47j046755; Sun, 29 Feb 2004 11:16:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.41]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1TJG3aO046749 for ; Sun, 29 Feb 2004 11:16:03 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.50] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1AxWQ0-0006Mm-00; Sun, 29 Feb 2004 14:16:04 -0500 Received: from [68.244.153.112] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1AxWPz-00042C-00; Sun, 29 Feb 2004 14:16:04 -0500 Message-ID: <40423A67.5020600@solidmatrix.com> Date: Sun, 29 Feb 2004 14:15:51 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= CC: ietf-mxcomp@imc.org Subject: Jabber channel for the BoF? X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Is there going to be a chat channel for the BoF so those who cannot attend in person can ask? Or is the multicast being used for that? Yakov From owner-ietf-mxcomp Sun Feb 29 12:13:26 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1TKDQVe050278; Sun, 29 Feb 2004 12:13: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 i1TKDQ3C050277; Sun, 29 Feb 2004 12:13:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1TKDPNU050271 for ; Sun, 29 Feb 2004 12:13:25 -0800 (PST) (envelope-from paf@cisco.com) Received: from XBE-AMS-302.cisco.com (xbe-ams-302.cisco.com [144.254.75.92]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1TKCg0c028953; Sun, 29 Feb 2004 21:12:51 +0100 (MET) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by XBE-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 29 Feb 2004 21:12:09 +0100 Received: from [127.0.0.1] ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 29 Feb 2004 21:13:09 +0100 In-Reply-To: <40423A67.5020600@solidmatrix.com> References: <40423A67.5020600@solidmatrix.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: ietf-mxcomp@imc.org From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: Jabber channel for the BoF? Date: Mon, 1 Mar 2004 05:12:59 +0900 To: Yakov Shafranovich X-Mailer: Apple Mail (2.612) X-OriginalArrivalTime: 29 Feb 2004 20:13:10.0201 (UTC) FILETIME=[73A87A90:01C3FF00] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2004-03-01, at 04.15, Yakov Shafranovich wrote: > Is there going to be a chat channel for the BoF so those who cannot > attend in person can ask? Or is the multicast being used for that? Jabber channel will be used for input/output. Multicast I see as a broadcast medium of the video and audio (only) in one direction. Ted and I will try to see we have a Jabber scribe which reads what "external people write" plus of course write what happens at the meeting. paf From owner-ietf-mxcomp Sun Feb 29 21:15:51 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i215FoFN087899; Sun, 29 Feb 2004 21:15: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 i215Fo95087898; Sun, 29 Feb 2004 21:15:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail-dark.research.att.com (mail-dark.research.att.com [192.20.225.112]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i215Fns0087892 for ; Sun, 29 Feb 2004 21:15:49 -0800 (PST) (envelope-from smb@research.att.com) Received: from mail-blue.research.att.com (H-135-207-30-102.research.att.com [135.207.30.102]) by mail-dark.research.att.com (Postfix) with ESMTP id B19ADE81B7 for ; Mon, 1 Mar 2004 00:16:45 -0500 (EST) Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id 6C806F3AFF for ; Mon, 1 Mar 2004 00:08:58 -0500 (EST) Received: from berkshire.research.att.com (guard.research.att.com [135.207.1.20]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id i215FtZ01270 for ; Mon, 1 Mar 2004 00:15:55 -0500 (EST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 181D97B43 for ; Mon, 1 Mar 2004 14:15:54 +0900 (KST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: Steve Bellovin To: ietf-mxcomp@imc.org Subject: we made CNN.... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 01 Mar 2004 14:15:54 +0900 Message-Id: <20040301051554.181D97B43@berkshire.research.att.com> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: http://www.cnn.com/2004/TECH/internet/02/27/email.origins.ap/index.html --Steve Bellovin, http://www.research.att.com/~smb From owner-ietf-mxcomp Sun Feb 29 21:34:05 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i215Y52D088841; Sun, 29 Feb 2004 21:34:05 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i215Y5Lq088840; Sun, 29 Feb 2004 21:34:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.40]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i215Y3HV088833 for ; Sun, 29 Feb 2004 21:34:04 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.50] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1Axg4B-0003I9-00; Mon, 01 Mar 2004 00:34:11 -0500 Received: from [68.244.153.112] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1Axg49-0001pK-00; Mon, 01 Mar 2004 00:34:11 -0500 Message-ID: <4042CB43.8070507@solidmatrix.com> Date: Mon, 01 Mar 2004 00:33:55 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Steve Bellovin CC: ietf-mxcomp@imc.org Subject: Re: we made CNN.... References: <20040301051554.181D97B43@berkshire.research.att.com> In-Reply-To: <20040301051554.181D97B43@berkshire.research.att.com> X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Steve Bellovin wrote: > http://www.cnn.com/2004/TECH/internet/02/27/email.origins.ap/index.html > > --Steve Bellovin, http://www.research.att.com/~smb > > And BBC (http://news.bbc.co.uk/1/hi/technology/3492354.stm), in particular I like this quote: "The internet's engineering body has set up an emergency meeting to sift through the different proposals and draw up a network-wide solution." Yakov From owner-ietf-mxcomp Sun Feb 29 22:03:16 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2163GjU092428; Sun, 29 Feb 2004 22:03:16 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2163GxL092425; Sun, 29 Feb 2004 22:03:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2163EDD092412 for ; Sun, 29 Feb 2004 22:03:15 -0800 (PST) (envelope-from harald@alvestrand.no) Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A057761C0C; Mon, 1 Mar 2004 07:03:20 +0100 (CET) Date: Mon, 01 Mar 2004 14:58:28 +0900 From: Harald Tveit Alvestrand To: Yakov Shafranovich , =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: ietf-mxcomp@imc.org Subject: Re: Jabber channel for the BoF? Message-ID: <1005966.1078153108@localhost> In-Reply-To: <40423A67.5020600@solidmatrix.com> References: <40423A67.5020600@solidmatrix.com> X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Yes. marid@ietf.xmpp.org. --On 29. februar 2004 14:15 -0500 Yakov Shafranovich wrote: > > Is there going to be a chat channel for the BoF so those who cannot > attend in person can ask? Or is the multicast being used for that? > > Yakov > > > From owner-ietf-mxcomp Mon Mar 1 06:14:41 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i21EEfa4015759; Mon, 1 Mar 2004 06:14: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 i21EEfPZ015758; Mon, 1 Mar 2004 06:14:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i21EEdlp015748 for ; Mon, 1 Mar 2004 06:14:39 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.11/) with ESMTP id i21EEfWK026136; Mon, 1 Mar 2004 06:14:41 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 1 Mar 2004 06:14:41 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Yakov Shafranovich'" , Steve Bellovin Cc: ietf-mxcomp@imc.org Subject: RE: we made CNN.... Date: Mon, 1 Mar 2004 06:14:38 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >And BBC (http://news.bbc.co.uk/1/hi/technology/3492354.stm), in >particular I like this quote: >"The internet's engineering body has set up an emergency meeting to sift >through the different proposals and draw up a network-wide solution." This is not good. The world has been set expectations for the meeting that are unlikely to be met. Only one of the industry backed proposals will even be represented at the meeting. It is clear from the statements being made that the IETF has little institutional understanding of the seriousness with which the spam problem is now considered by the ISPs and end users. Fortunately it is unlikely that any press will attend the meeting given the location. From owner-ietf-mxcomp Mon Mar 1 15:30:44 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i21NUh8Y056492; Mon, 1 Mar 2004 15:30: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 i21NUhPw056491; Mon, 1 Mar 2004 15:30:43 -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 (srv1.fecyk.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i21NUgnq056485 for ; Mon, 1 Mar 2004 15:30:43 -0800 (PST) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: we made CNN.... MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Mon, 1 Mar 2004 17:30:47 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA783@srv1.fecyk.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: we made CNN.... Thread-Index: AcP/l7jz+klwr+OxRcuGrU4jb+nghQATT5LQ From: "Gordon Fecyk" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i21NUhnq056486 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > It is clear from the statements being > made that the IETF has little institutional understanding of > the seriousness > with which the spam problem is now considered by the ISPs and > end users. More like the press has little understanding of the IETF. From what I've read to date, that seems to be the norm. And it is too bad none of the press are here. I'd like to deliver some Clue to them. -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Mon Mar 1 16:01:41 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2201fSo057964; Mon, 1 Mar 2004 16:01: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 i2201euE057963; Mon, 1 Mar 2004 16:01:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail-white.research.att.com (mail-red.research.att.com [192.20.225.110]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2201b4f057954 for ; Mon, 1 Mar 2004 16:01:39 -0800 (PST) (envelope-from smb@research.att.com) Received: from mail-blue.research.att.com (H-135-207-30-102.research.att.com [135.207.30.102]) by mail-white.research.att.com (Postfix) with ESMTP id D2D7F66404B; Mon, 1 Mar 2004 19:00:10 -0500 (EST) Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id F0663F3B06; Mon, 1 Mar 2004 18:54:40 -0500 (EST) Received: from berkshire.research.att.com (guard.research.att.com [135.207.1.20]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id i2201eZ12851; Mon, 1 Mar 2004 19:01:41 -0500 (EST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id BCEB67B43; Tue, 2 Mar 2004 09:01:36 +0900 (KST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: "Gordon Fecyk" Cc: ietf-mxcomp@imc.org Subject: Re: we made CNN.... In-Reply-To: Your message of "Mon, 01 Mar 2004 17:30:47 CST." <700EEF5641B7E247AC1C9B82C05D125DA783@srv1.fecyk.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 02 Mar 2004 09:01:36 +0900 Message-Id: <20040302000136.BCEB67B43@berkshire.research.att.com> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In message <700EEF5641B7E247AC1C9B82C05D125DA783@srv1.fecyk.ca>, "Gordon Fecyk" writes: > >> It is clear from the statements being >> made that the IETF has little institutional understanding of >> the seriousness >> with which the spam problem is now considered by the ISPs and >> end users. > >More like the press has little understanding of the IETF. From what I've >read to date, that seems to be the norm. > >And it is too bad none of the press are here. I'd like to deliver some Clue >to them. In fact, there are at least three reporters registered for the IETF, one of whom works for a major international publication. --Steve Bellovin, http://www.research.att.com/~smb From owner-ietf-mxcomp Mon Mar 1 16:09:18 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2209IbY058525; Mon, 1 Mar 2004 16:09: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 i2209Huq058523; Mon, 1 Mar 2004 16:09:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2209EqT058512 for ; Mon, 1 Mar 2004 16:09:16 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i2209Kj2017214; Mon, 1 Mar 2004 16:09:20 -0800 (PST) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 1 Mar 2004 16:09:20 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Gordon Fecyk'" , ietf-mxcomp@imc.org Subject: RE: we made CNN.... Date: Mon, 1 Mar 2004 16:09:17 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > It is clear from the statements being > > made that the IETF has little institutional understanding of > > the seriousness > > with which the spam problem is now considered by the ISPs and > > end users. > > More like the press has little understanding of the IETF. > From what I've > read to date, that seems to be the norm. If the IETF does not want to be organizing the response to spam then it should just tell everyone and it will be left alone. The press believes that the IETF is in charge of the Internet, the IETf has not exactly tried to discourage this view. Consensus does not mean that everyone gets a veto power on change. If the proposers of SPF, caller ID etc. do not believe that they advance in this forum they will choose another. What the proponents of change want is an expedited process to agree on a standard to solve a very urgent problem. They would also like the imprimatur and endorsement that the IETF provides, although that is of dubious value if it will take more than a year to obtain. What I or anyone else in my position is looking for from a standards process is a means to help generate the critical mass necessary to drive deployment, the reason for a consensus process is to get buy in from the core stakeholders. We are NOT looking for technical expertise, or a committee of the great and the good to show how important they are by taking over a year to read drafts. Phill From owner-ietf-mxcomp Mon Mar 1 16:10:49 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i220AnNa058668; Mon, 1 Mar 2004 16:10: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 i220Amvl058667; Mon, 1 Mar 2004 16:10:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i220Am64058644 for ; Mon, 1 Mar 2004 16:10:48 -0800 (PST) (envelope-from paf@cisco.com) Received: from ams-msg-core-1.cisco.com (144.254.74.60) by sj-iport-5.cisco.com with ESMTP; 01 Mar 2004 16:10:49 -0800 Received: from xbe-ams-312.cisco.com (xbe-ams-312.cisco.com [144.254.228.202]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i220AI0a027545; Tue, 2 Mar 2004 01:10:18 +0100 (MET) Received: from xfe-ams-311.cisco.com ([144.254.228.204]) by xbe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 2 Mar 2004 01:10:43 +0100 Received: from [127.0.0.1] ([144.254.74.55]) by xfe-ams-311.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 2 Mar 2004 01:10:42 +0100 In-Reply-To: <20040302000136.BCEB67B43@berkshire.research.att.com> References: <20040302000136.BCEB67B43@berkshire.research.att.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <09772396-6BDE-11D8-874A-000A959CF516@cisco.com> Content-Transfer-Encoding: 7bit Cc: ietf-mxcomp@imc.org, "Gordon Fecyk" From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: we made CNN.... Date: Tue, 2 Mar 2004 09:10:39 +0900 To: "Steven M. Bellovin" X-Mailer: Apple Mail (2.612) X-OriginalArrivalTime: 02 Mar 2004 00:10:43.0113 (UTC) FILETIME=[CD780190:01C3FFEA] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: See for example the following: > 59TH IETF meeting showcases latest broadband technology > Korea Herald - Seoul,South Korea > IETF Meeting kicked off its week-long schedule at Lotte Hotel in > downtown > Seoul Sunday, with attendees setting the standards for various > Internet-related > ... > 200403020029.asp> paf On 2004-03-02, at 09.01, Steven M. Bellovin wrote: > > In message <700EEF5641B7E247AC1C9B82C05D125DA783@srv1.fecyk.ca>, > "Gordon Fecyk" > writes: >> >>> It is clear from the statements being >>> made that the IETF has little institutional understanding of >>> the seriousness >>> with which the spam problem is now considered by the ISPs and >>> end users. >> >> More like the press has little understanding of the IETF. From what >> I've >> read to date, that seems to be the norm. >> >> And it is too bad none of the press are here. I'd like to deliver >> some Clue >> to them. > > In fact, there are at least three reporters registered for the IETF, > one of whom works for a major international publication. > > --Steve Bellovin, http://www.research.att.com/~smb > > From owner-ietf-mxcomp Mon Mar 1 16:25:18 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i220PISU059648; Mon, 1 Mar 2004 16:25: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 i220PIlg059647; Mon, 1 Mar 2004 16:25:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i220PHUF059641 for ; Mon, 1 Mar 2004 16:25:17 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.11/) with ESMTP id i220PKvS025747; Mon, 1 Mar 2004 16:25:20 -0800 (PST) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 1 Mar 2004 16:25:20 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= , "Steven M. Bellovin" Cc: ietf-mxcomp@imc.org, Gordon Fecyk Subject: RE: we made CNN.... Date: Mon, 1 Mar 2004 16:25:19 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i220PHUF059642 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Complete with picture of Patrik eating canapes > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Patrik Fältström > Sent: Monday, March 01, 2004 7:11 PM > To: Steven M. Bellovin > Cc: ietf-mxcomp@imc.org; Gordon Fecyk > Subject: Re: we made CNN.... > > > > See for example the following: > > > 59TH IETF meeting showcases latest broadband technology > > Korea Herald - Seoul,South Korea > > IETF Meeting kicked off its week-long schedule at Lotte Hotel in > > downtown > > Seoul Sunday, with attendees setting the standards for various > > Internet-related > > ... > > > 200403020029.asp> > > paf > > On 2004-03-02, at 09.01, Steven M. Bellovin wrote: > > > > > In message <700EEF5641B7E247AC1C9B82C05D125DA783@srv1.fecyk.ca>, > > "Gordon Fecyk" > > writes: > >> > >>> It is clear from the statements being > >>> made that the IETF has little institutional understanding of > >>> the seriousness > >>> with which the spam problem is now considered by the ISPs and > >>> end users. > >> > >> More like the press has little understanding of the IETF. > From what > >> I've > >> read to date, that seems to be the norm. > >> > >> And it is too bad none of the press are here. I'd like to > deliver > >> some Clue > >> to them. > > > > In fact, there are at least three reporters registered for the IETF, > > one of whom works for a major international publication. > > > > --Steve Bellovin, http://www.research.att.com/~smb > > > > > From owner-ietf-mxcomp Mon Mar 1 16:30:38 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i220UcNo059944; Mon, 1 Mar 2004 16:30: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 i220UcYF059943; Mon, 1 Mar 2004 16:30:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i220UZsj059932 for ; Mon, 1 Mar 2004 16:30:37 -0800 (PST) (envelope-from paf@cisco.com) Received: from ams-msg-core-1.cisco.com (144.254.74.60) by sj-iport-5.cisco.com with ESMTP; 01 Mar 2004 16:30:36 -0800 Received: from XBE-AMS-302.cisco.com (xbe-ams-302.cisco.com [144.254.75.92]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i220U50a002919; Tue, 2 Mar 2004 01:30:06 +0100 (MET) Received: from xfe-ams-311.cisco.com ([144.254.228.204]) by XBE-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 2 Mar 2004 01:29:28 +0100 Received: from [127.0.0.1] ([144.254.74.55]) by xfe-ams-311.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 2 Mar 2004 01:30:31 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Cc: Gordon Fecyk , ietf-mxcomp@imc.org, "Steven M. Bellovin" From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: we made CNN.... Date: Tue, 2 Mar 2004 09:30:28 +0900 To: "Hallam-Baker, Phillip" X-Mailer: Apple Mail (2.612) X-OriginalArrivalTime: 02 Mar 2004 00:30:32.0128 (UTC) FILETIME=[922D4C00:01C3FFED] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i220Ubsj059938 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Oh, true, I didn't see that myself... paf On 2004-03-02, at 09.25, Hallam-Baker, Phillip wrote: > Complete with picture of Patrik eating canapes > > >> -----Original Message----- >> From: owner-ietf-mxcomp@mail.imc.org >> [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Patrik Fältström >> Sent: Monday, March 01, 2004 7:11 PM >> To: Steven M. Bellovin >> Cc: ietf-mxcomp@imc.org; Gordon Fecyk >> Subject: Re: we made CNN.... >> >> >> >> See for example the following: >> >>> 59TH IETF meeting showcases latest broadband technology >>> Korea Herald - Seoul,South Korea >>> IETF Meeting kicked off its week-long schedule at Lotte Hotel in >>> downtown >>> Seoul Sunday, with attendees setting the standards for various >>> Internet-related >>> ... >>> >> 200403020029.asp> >> >> paf >> >> On 2004-03-02, at 09.01, Steven M. Bellovin wrote: >> >>> >>> In message <700EEF5641B7E247AC1C9B82C05D125DA783@srv1.fecyk.ca>, >>> "Gordon Fecyk" >>> writes: >>>> >>>>> It is clear from the statements being >>>>> made that the IETF has little institutional understanding of >>>>> the seriousness >>>>> with which the spam problem is now considered by the ISPs and >>>>> end users. >>>> >>>> More like the press has little understanding of the IETF. >> From what >>>> I've >>>> read to date, that seems to be the norm. >>>> >>>> And it is too bad none of the press are here. I'd like to >> deliver >>>> some Clue >>>> to them. >>> >>> In fact, there are at least three reporters registered for the IETF, >>> one of whom works for a major international publication. >>> >>> --Steve Bellovin, http://www.research.att.com/~smb >>> >>> >> From owner-ietf-mxcomp Mon Mar 1 17:34:34 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i221YY0Z064235; Mon, 1 Mar 2004 17:34: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 i221YXVg064234; Mon, 1 Mar 2004 17:34:33 -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 (srv1.fecyk.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i221YWgf064224 for ; Mon, 1 Mar 2004 17:34:33 -0800 (PST) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: we made CNN.... MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Mon, 1 Mar 2004 19:34:38 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA784@srv1.fecyk.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: we made CNN.... Thread-Index: AcP/6p5xbLq1KssXSUWgookVXs9jowACwIqg From: "Gordon Fecyk" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i221YXgf064229 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > If the IETF does not want to be organizing the response to > spam then it should just tell everyone and it will be left alone. At the very least I'd want reporters covering this little corner of the IETF to read this: -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Tue Mar 2 05:01:59 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i22D1wER081848; Tue, 2 Mar 2004 05:01: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 i22D1wpl081847; Tue, 2 Mar 2004 05:01:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from argon.connect.org.uk (argon.connectinternetsolutions.com [193.110.243.33]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i22D1vTo081837 for ; Tue, 2 Mar 2004 05:01:57 -0800 (PST) (envelope-from jrk@merseymail.com) Received: from mmail by argon.connect.org.uk with local (connectmail/exim) id 1Ay9X4-0003Ff-TC for ietf-mxcomp@imc.org; Tue, 02 Mar 2004 13:01:58 +0000 Subject: Re: Passing authentication information via SMTP To: From: "Jon Kyme" X-Mailer: [ConnectMail 3.12.1] X-connectmail-Originating-IP: 172.25.243.3 Message-Id: Date: Tue, 02 Mar 2004 13:01:58 +0000 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Y.S. wrote: > The MAIL FROM parameter does not tell us where the mail is from, > only the bounce address for that email. The assumption is that > whoever is the bounce address is, is probably the sender, > but in many cases especially mailing lists, that is not true. > As a matter of fact in some protocols such as SMTP AUTH, > the sender's identity is passed in an SMTP extension separate > from the bounce address. Or the other way up: The assumption is that the address given as the sender in the MAIL FROM is useful as the bounce address. The MAIL FROM argument is *used* for bounces, but it's use in LMAP doesn't seem to be contrary to its purpose of specifying the "sender" mailbox: rfc821 3.1. The transaction is started with a MAIL command which gives the sender identification rfc2821 section 3.3 The transaction starts MAIL command which gives the sender identification. 4.1.1.2 The reverse-path consists of the sender mailbox. We've got only one kind of data which can be used for any number of puposes. LMAPs are authenticators using this data. This can't fairly be called overloading, since the argument is always of the same type. -- From owner-ietf-mxcomp Wed Mar 3 00:07:47 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2387kOx005792; Wed, 3 Mar 2004 00:07: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 i2387keF005790; Wed, 3 Mar 2004 00:07:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2387jVc005777 for ; Wed, 3 Mar 2004 00:07:46 -0800 (PST) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id 36B30E0D02; Wed, 3 Mar 2004 03:07:45 -0500 (EST) Date: Wed, 3 Mar 2004 03:07:45 -0500 From: John Leslie To: ietf-mxcomp@imc.org Subject: Principles of Spam Abatement Message-ID: <20040303080745.GA99659@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On the mailing list there has been discussion of Principles of Spam Abatement. This is a brief summary of principles which _may_ have consensus of that list. I accept full responsibility for editing errors and misunderstandings. - All communications must be by mutual consent. - The spam problem starts with freely accepting mail from strangers. - Spam is and will remain a long-term battleground and it needs serious effort to counter. - Every mail message carries a practically unforgeable token: the IP address of the SMTP client. - It is pointless to erect some expensive Maginot Line and pretend it will solve the problem. - There is not and can never be a hoop low enough to pass all human strangers but exclude spammers' computers. - If you want more of something, subsidize it; if you want less, tax it. - Spammers need scale because they get a very low return. Therefore, part of the solution should be to deny scalability to spammers. - If we can communicate to the sender (without adverse side effects) that a message is discarded, then occasional false positives aren't as much of a problem. - If you reject the message during the SMTP session you don't need to generate a bounce message, the other side will do this. - Errors returned after the close of the SMTP transaction are likely to go to an innocent party; and should be deprecated for any email identified as spam. I also recommend perusing the summary of principles expressed on the Next-Generation Mail list at: http://www.cs.utk.edu/~moore/opinions/user-visible-email-ng-goals.html -- John Leslie From owner-ietf-mxcomp Wed Mar 3 02:30:14 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i23AUEh3047048; Wed, 3 Mar 2004 02:30: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 i23AUDBm047047; Wed, 3 Mar 2004 02:30:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i23AU9uL047038 for ; Wed, 3 Mar 2004 02:30:13 -0800 (PST) (envelope-from hadmut@danisch.de) Received: from www.rackland.de (localhost [127.0.0.1]) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with SMTP id i23AU359005163; Wed, 3 Mar 2004 11:30:03 +0100 Received: from 192.109.50.40 (SquirrelMail authenticated user hadmut) by www.rackland.de with HTTP; Wed, 3 Mar 2004 11:30:03 +0100 (CET) Message-ID: <65125.192.109.50.40.1078309803.squirrel@www.rackland.de> In-Reply-To: <20040303080745.GA99659@verdi> References: <20040303080745.GA99659@verdi> Date: Wed, 3 Mar 2004 11:30:03 +0100 (CET) Subject: Re: Principles of Spam Abatement From: "Hadmut Danisch" To: "John Leslie" Cc: 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: Hi, > On the mailing list there has been discussion of > Principles of Spam Abatement. This is a brief summary of principles > which _may_ have consensus of that list. I accept full responsibility > for editing errors and misunderstandings. I highly agree with this list, and like to see it on the charta of the upcoming working group, except for one thing: > - If you want more of something, subsidize it; if you want less, tax it. Sorry, that's too american and doesn't work on an international base. An american spammer can easily afford billions of mail, while citizen of poor countries can't afford their normal mail if we do something like this. Economy isn't the magic bullet to solve all problems. regards Hadmut From owner-ietf-mxcomp Wed Mar 3 03:02:57 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i23B2uPA049411; Wed, 3 Mar 2004 03:02: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 i23B2uTl049402; Wed, 3 Mar 2004 03:02:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i23B2sw0049390 for ; Wed, 3 Mar 2004 03:02:55 -0800 (PST) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id A2ED6E0527; Wed, 3 Mar 2004 06:02:55 -0500 (EST) Date: Wed, 3 Mar 2004 06:02:55 -0500 From: John Leslie To: Hadmut Danisch Cc: John Leslie , ietf-mxcomp@imc.org Subject: Re: Principles of Spam Abatement Message-ID: <20040303110255.GK47473@verdi> References: <20040303080745.GA99659@verdi> <65125.192.109.50.40.1078309803.squirrel@www.rackland.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <65125.192.109.50.40.1078309803.squirrel@www.rackland.de> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hadmut Danisch wrote: > >> On the mailing list there has been discussion of >> Principles of Spam Abatement. This is a brief summary of principles >> which _may_ have consensus of that list. I accept full responsibility >> for editing errors and misunderstandings. > > > I highly agree with this list, and like to see it on the charta > of the upcoming working group, except for one thing: > >> - If you want more of something, subsidize it; if you want less, tax it. > > Sorry, that's too american and doesn't work on an international base. > An american spammer can easily afford billions of mail, while citizen > of poor countries can't afford their normal mail if we do something like > this. Economy isn't the magic bullet to solve all problems. Let's just scrap that one -- I don't think anyone will object. I think there is a point to be made that currently we _are_ subsidizing spam; but I'm not aware of any proposal to "tax" it that doesn't endager the free flow of ideas. -- John Leslie From owner-ietf-mxcomp Wed Mar 3 09:09:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i23H9XZ6078207; Wed, 3 Mar 2004 09:09: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 i23H9XYd078205; Wed, 3 Mar 2004 09:09:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from newgiles.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i23H9NPU078193 for ; Wed, 3 Mar 2004 09:09:26 -0800 (PST) (envelope-from aland@newgiles.nitros9.org) Received: (from aland@localhost) by newgiles.nitros9.org (8.11.6/8.11.6) id i23HCUU05322; Wed, 3 Mar 2004 12:12:30 -0500 (EST) Date: Wed, 3 Mar 2004 12:12:30 -0500 (EST) Message-Id: <200403031712.i23HCUU05322@newgiles.nitros9.org> From: "Alan DeKok" To: ietf-mxcomp@imc.org cc: Subject: Deficiencies in LMAP Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: One of the biggest objections to LMAP is that spammers can register domains, and publish fake LMAP information for "owned" machines. In this situation, LMAP does nothing to stop, or even slow down, the flood of spam. I've posted this summary previously on ASRG, and the smtp-verify sub-list, but I thought I should post it here, too. The idea is to (ab)use rDNS, and to publish LMAP records there, too. One of the key records to publish is which domains are permitted to publish LMAP records for this IP. Or, the information could be which DNS servers are allowed to publish LMAP records for this IP. e.g. Once it has an SMTP connection, the recipient may then decide to query LMAP for a domain: example.com. The steps it goes through are now: LMAP query : reverse_ip._lmap_.example.com -> pass/fail If pass, look get hostname for rDNS of the IP (a.b.c.d.example.net), and do an LMAP query: example.com._lmap_.a.b.c.d.example.net If this query fails, it can look up the IP of the DNS server(s) for example.com, in _lmap_.a.b.c.d.example.net. I vaguely recall something similar being discussed months ago on ASRG, but I don't remember if it was this method, or something different. Pro's: solves the largest complaint against LMAP. Con's: requires more information to be in DNS, and more DNS lookups. There is a simple argument against this addition to LMAP, and LMAP in general: This method helps only if all domains participate in it. I don't see that argument as holding much water, as the same argument applies to *any* system which may be deployed. If the potential participants see a benefit to deploying this solution, then they have incentive to do so. If there is no benefit, then the solution is a bad one, and will be rejected by most participants, independently of what we decide here. Alan DeKok. From owner-ietf-mxcomp Wed Mar 3 11:38:42 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i23Jcfw1090125; Wed, 3 Mar 2004 11:38: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 i23Jcfvj090124; Wed, 3 Mar 2004 11:38:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i23JcbGx090118 for ; Wed, 3 Mar 2004 11:38:40 -0800 (PST) (envelope-from hadmut@danisch.de) Received: from andromeda (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i23JcYY3018046; Wed, 3 Mar 2004 20:38:34 +0100 Received: (from hadmut@localhost) by andromeda.dresden.danisch.de (8.12.10/8.12.10/Debian-5) id i23Jc6Yg002496; Wed, 3 Mar 2004 20:38:06 +0100 From: Hadmut Danisch Date: Wed, 3 Mar 2004 20:38:06 +0100 To: ietf@ietf.org, ietf-mxcomp@imc.org Subject: MBONE access? Message-ID: <20040303193806.GA2487@danisch.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, I'd like to watch the MARID BOF on mbone, but unfortunately my IP provider does not support multicast. Can anyone give me a hint about where to get an mbone tunneling access point? regards Hadmut From owner-ietf-mxcomp Wed Mar 3 12:20:05 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i23KK5J1093216; Wed, 3 Mar 2004 12:20:05 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i23KK458093215; Wed, 3 Mar 2004 12:20:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.41]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i23KK3CV093202 for ; Wed, 3 Mar 2004 12:20:04 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.50] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1AycqV-0006cY-00; Wed, 03 Mar 2004 15:19:59 -0500 Received: from [68.24.225.2] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1AycqS-0006Vt-00; Wed, 03 Mar 2004 15:19:58 -0500 Message-ID: <40463DE5.1090009@solidmatrix.com> Date: Wed, 03 Mar 2004 15:19:49 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: John Leslie CC: ietf-mxcomp@imc.org Subject: Re: Principles of Spam Abatement References: <20040303080745.GA99659@verdi> In-Reply-To: <20040303080745.GA99659@verdi> X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: John Leslie wrote: > On the mailing list there has been discussion of > Principles of Spam Abatement. This is a brief summary of principles > which _may_ have consensus of that list. I accept full responsibility > for editing errors and misunderstandings. > John, Many of these principles have been well argued over many times. Can you clarify where you want to go with this? > - All communications must be by mutual consent. > > - The spam problem starts with freely accepting mail from strangers. > The main value that the Internet brings to the world is a cheap pervasive communications medium. This is the basic underlying principle that makes all of the Internet services and applications so great. Spammers, hackers, DDOS attackers, etc, all utilize the same three properties to do the bad stuff. Our goal is to stop the bad guys while keeping the Internet cheap and pervasive. Restricting communications except by consent reduces the value of the Internet as a communications medium. What I do not like about these two statements is the fact that today you can accept email from a stranger and you are implying that it should not be so. What you need to clarify here is whether "all communications must be by mutual PRIOR consent" or even "post-facto" consent. > - Spam is and will remain a long-term battleground and it needs serious > effort to counter. > I agreee. This has also been pointed out in Dave Crocker's draft as well which also lists 17 points for spam solutions (see http://brandenburg.com/specifications/draft-crocker-spam-techconsider-02.txt). > - Every mail message carries a practically unforgeable token: the IP > address of the SMTP client. > I would clarify this more. The IP address is known at the time the SMTP transaction takes place. However, by the time the messsage gets to the MUA or relayed inside the organization, the "Received" headers cannot be fully trusted since they can be forge. "Fully trusted" - they *can* be trusted but not fully. > - It is pointless to erect some expensive Maginot Line and pretend it > will solve the problem. > Not sure what you mean here, perhaps you can elaborate? Are you refering to propopals that propose a new separate email system which is trackable, something like "fedex" for email? > - There is not and can never be a hoop low enough to pass all human > strangers but exclude spammers' computers. > I am assuming you are refering to pseudo-Turing tests. At the ASRG there was also some debate on whether spammers can use real humans for such tests via porn sites and such, and the conclusion was that very possibly for Turing tests on email registrations but not on email by email basis. > - Spammers need scale because they get a very low return. Therefore, > part of the solution should be to deny scalability to spammers. > At the same time the email infrastructure of the Internet scales as well and we must make sure that if we want to deny scalability to spammers, we need to make sure everyone else does not lose it. If you can, please elaborate on this point, since I am not getting it 100%. > - If we can communicate to the sender (without adverse side effects) > that a message is discarded, then occasional false positives aren't > as much of a problem. > I agree but I am not sure how you can do that to senders and not spammers, especially in today's world where hijacked machines are often used to send spam and no real difference may exist between spammers and senders. > - If you reject the message during the SMTP session you don't need to > generate a bounce message, the other side will do this. > I agree with the underlying drive BUT this really goes against the next statement. Email operates as a store and forward system, if during hop A email goes through and fails on hop C, than hop C needs to send back a bounce message. You are not suggesting that all three hops should stay open? Perhaps you can clarify? > - Errors returned after the close of the SMTP transaction are likely > to go to an innocent party; and should be deprecated for any email > identified as spam. > I disagree. Many type of errors occur after the SMTP transaction is closed, especially in situtations where internal relaying is done, or the external SMTP gateway has no knowledge of internal systems. Additionally, *if* the bounce address was authentication such as in any LMAP proposal, this is not necessary. Yakov Yakov From owner-ietf-mxcomp Wed Mar 3 13:30:05 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i23LU4GR097790; Wed, 3 Mar 2004 13:30: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 i23LU4Hi097789; Wed, 3 Mar 2004 13:30:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i23LU3ZO097781 for ; Wed, 3 Mar 2004 13:30:03 -0800 (PST) (envelope-from hadmut@danisch.de) Received: from andromeda (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i23LU5kE021632; Wed, 3 Mar 2004 22:30:05 +0100 Received: (from hadmut@localhost) by andromeda.dresden.danisch.de (8.12.10/8.12.10/Debian-5) id i23LTXCc004373; Wed, 3 Mar 2004 22:29:33 +0100 From: Hadmut Danisch Date: Wed, 3 Mar 2004 22:29:33 +0100 To: Joe Abley Cc: ietf-mxcomp@imc.org, ietf@ietf.org Subject: Re: MBONE access? Message-ID: <20040303212933.GA4349@danisch.de> References: <20040303193806.GA2487@danisch.de> <59164458-6D58-11D8-A1AA-00039312C852@isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <59164458-6D58-11D8-A1AA-00039312C852@isc.org> User-Agent: Mutt/1.5.5.1+cvs20040105i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Mar 03, 2004 at 04:18:42PM -0500, Joe Abley wrote: > > If you find an answer, telling this list would be good. > > In the past the answer has been "you don't", often coupled with > enthusiastic statements about the mbone being in full production, and > tunnels no longer being necessary. Please tell me you're kidding... I just phoned the hotline of my provider T-DSL/T-Online. They didn't even know what I was talking about. All they said is that they can't help if I'm using Linux, because that operating system is not supported. I'd have to call a 0190 number (62ct / min), which I did. Listening to the wait queue music for about 1,5 minutes. Then there was a Lady who also hasn't ever heard about this and couldn't imagine what I was talking about... Hadmut From owner-ietf-mxcomp Wed Mar 3 14:02:49 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i23M2na6099846; Wed, 3 Mar 2004 14:02: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 i23M2nng099845; Wed, 3 Mar 2004 14:02:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i23M2lbR099839 for ; Wed, 3 Mar 2004 14:02:48 -0800 (PST) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id 849FEE055C; Wed, 3 Mar 2004 17:02:51 -0500 (EST) Date: Wed, 3 Mar 2004 17:02:51 -0500 From: John Leslie To: Yakov Shafranovich Cc: ietf-mxcomp@imc.org Subject: Re: Principles of Spam Abatement Message-ID: <20040303220251.GN47473@verdi> References: <20040303080745.GA99659@verdi> <40463DE5.1090009@solidmatrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40463DE5.1090009@solidmatrix.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Yakov Shafranovich wrote: > > Many of these principles have been well argued over many times. Can you > clarify where you want to go with this? In my experience, discussion of spam-abatement always gets engulfed in flame-wars between people who know the "one-true-spam-solution" and feel obliged to correct others whose "one-true-spam-solution" differs in the slightest detail. Some shared basis is needed to get past the initial flame-wars. I don't honestly know whether working up consensus on principles is the best way to accomplish that, but it seems like a relatively easy way. In any case, I _don't_ intend that such a discussion should happen _during_ the BoF. The principles I posted represent a first pass at consensus on the (IETF General) mailing list: thus they _might_ be a good starting point for such a discussion when a WG forms. > John Leslie wrote: >> - All communications must be by mutual consent. >> >> - The spam problem starts with freely accepting mail from strangers. > > The main value that the Internet brings to the world is a cheap > pervasive communications medium. This is the basic underlying principle > that makes all of the Internet services and applications so great. Quite possibly that needs to be listed as a principle. > Spammers, hackers, DDOS attackers, etc, all utilize the same three > properties to do the bad stuff. Our goal is to stop the bad guys while > keeping the Internet cheap and pervasive. I'm not sure that's even a reasonable goal -- least of all attainable. First of all, we're addressing an extremely small slice of the Internet: SMTP traffic; and considering a very small subset of issues within it. At most, we'll be weakly authenticating the source/sender envelope-style information. The Internet will stay cheap and pervasive regardless of what we do; and nothing we could possibly do will "stop" "bad guys" from abusing it. > Restricting communications except by consent reduces the value of the > Internet as a communications medium. Agreed. But in the absence of good information to inform that consent, its value will be reduced even more. Maybe we need to state a principle that no human being can effectively read more than a thousand (e.g.) emails per day... > What I do not like about these two statements is the fact that today you > can accept email from a stranger and you are implying that it should not > be so. I don't read it that way at all. Whatever you read today, you read because you consent to reading it. People are beginning to withhold their consent, however. We need to encourage them to feel more comfortable about consenting. > What you need to clarify here is whether "all communications must > be by mutual PRIOR consent" or even "post-facto" consent. I welcome any discussion of changing the wording. (If you're asking my personal opinion, I see no reason consent cannot be delayed.) >> - Spam is and will remain a long-term battleground and it needs serious >> effort to counter. > > I agreee. This has also been pointed out in Dave Crocker's draft as well > which also lists 17 points for spam solutions (see > http://brandenburg.com/specifications/draft-crocker-spam-techconsider-02.txt). Dave's draft is excellent, but gets into implementation details, which I'd rather not do before we reach some consensus on what piece of the problem we're hoping to solve. >> - Every mail message carries a practically unforgeable token: the IP >> address of the SMTP client. > > I would clarify this more. The IP address is known at the time the SMTP > transaction takes place. However, by the time the messsage gets to the > MUA or relayed inside the organization, the "Received" headers cannot be > fully trusted since they can be forge. "Fully trusted" - they *can* be > trusted but not fully. I'm hoping we can concentrate on the IP address during the connection, and avoid pointless arguments about which "headers" are trustworthy. >> - It is pointless to erect some expensive Maginot Line and pretend it >> will solve the problem. > > Not sure what you mean here, perhaps you can elaborate? Are you refering > to propopals that propose a new separate email system which is > trackable, something like "fedex" for email? I take this to mean we should resist throwing inordinate amounts of effort into any "solution" in the (false) belief that it will "stop" the spam. History is quite clear: it won't. We should instead tackle simple things which we can specify well enough to be deployed quickly. >> - There is not and can never be a hoop low enough to pass all human >> strangers but exclude spammers' computers. > > I am assuming you are refering to pseudo-Turing tests. At the ASRG there > was also some debate on whether spammers can use real humans for such > tests via porn sites and such, and the conclusion was that very possibly > for Turing tests on email registrations but not on email by email basis. This really didn't arise in that context; though we'd probably stick by it even in that context: spammers' computers could "increment by one and test", bringing receivers' systems to their knees. The context of this is that many humans will resist "Turing tests"; and that others will fail them, perhaps due to handicaps. >> - Spammers need scale because they get a very low return. Therefore, >> part of the solution should be to deny scalability to spammers. > > At the same time the email infrastructure of the Internet scales as well > and we must make sure that if we want to deny scalability to spammers, > we need to make sure everyone else does not lose it. If you can, please > elaborate on this point, since I am not getting it 100%. I'd have to go back to the original poster. My recollection is that he went on to talk about imposing (increasing) delays on SMTP sessions containing suspected spam. >> - If we can communicate to the sender (without adverse side effects) >> that a message is discarded, then occasional false positives aren't >> as much of a problem. > > I agree but I am not sure how you can do that to senders and not > spammers, especially in today's world where hijacked machines are often > used to send spam and no real difference may exist between spammers and > senders. This was originally stated as communicating "discarded as spam", but revised to simply "discarded". IMHO, there's no harm in letting a spammer know the message was discarded -- the harm's in letting him know that there's a real human who would have read it if it weren't discarded. I believe we reached consensus that the benefit to the honest sender of a false-positive greatly exceeded the harm of letting a spammer know the message was discarded. >> - If you reject the message during the SMTP session you don't need to >> generate a bounce message, the other side will do this. > > I agree with the underlying drive BUT this really goes against the next > statement. Email operates as a store and forward system, if during hop A > email goes through and fails on hop C, than hop C needs to send back a > bounce message. You are not suggesting that all three hops should stay > open? Perhaps you can clarify? This, I believe (I didn't write it), meant to say that any problems of determining the appropriate recipient of a bounce message disappear if the error is given _during_ the SMTP session. >> - Errors returned after the close of the SMTP transaction are likely >> to go to an innocent party; and should be deprecated for any email >> identified as spam. I did write that one. > I disagree. Many type of errors occur after the SMTP transaction is > closed, especially in situtations where internal relaying is done, or > the external SMTP gateway has no knowledge of internal systems. I stand by the principle, though I'm willing to reword it a bit to allow generating a bounce if the SMTP server has somehow authenticated the address to which the bounce is sent. I believe there is consensus that most spam and virtually all viruses forge the sender email addresses; and that the harm of returning bounces to these forged addresses greatly exceeds the benefit if they _happen_ to be valid. If I may elaborate about store-and-forward: the final recipient knows the least about the validity of email addresses and SHOULD NOT return bounces to dubious addresses, except as errors _during_ the SMTP session; any prior SMTP server in the chain SHOULD have some authentication and MAY return bounces to dubious addresses; but we're presumably talking about messages which are spam-like under any evaluation, and the RFC requirements to return bounce messages need to be reconsidered. (IMHO, that is...) > Additionally, *if* the bounce address was authentication such as in any > LMAP proposal, this is not necessary. There may well be cases where the sender is sufficiently authenticated to justify a post-SMTP-session error emailed to that address; but the bounces to wrong addresses are _so_ common today, and _so_ confusing to many end-users, that we should err on the side of not reporting whenever the address is dubious. ==== BTW: I have no desire to start a long-winded discussion on this list; but I'm replying to Yakov, who evidently felt it was important to ask on-list. -- John Leslie From owner-ietf-mxcomp Wed Mar 3 14:16:28 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i23MGRcM001813; Wed, 3 Mar 2004 14:16: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 i23MGRTZ001812; Wed, 3 Mar 2004 14:16:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.40]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i23MGQ1S001806 for ; Wed, 3 Mar 2004 14:16:26 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.52] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1AyefG-0006s5-00; Wed, 03 Mar 2004 17:16:30 -0500 Received: from [68.24.225.2] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1AyefF-0004WF-00; Wed, 03 Mar 2004 17:16:30 -0500 Message-ID: <40465937.2060401@solidmatrix.com> Date: Wed, 03 Mar 2004 17:16:23 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: John Leslie CC: ietf-mxcomp@imc.org Subject: Re: Principles of Spam Abatement References: <20040303080745.GA99659@verdi> <40463DE5.1090009@solidmatrix.com> <20040303220251.GN47473@verdi> In-Reply-To: <20040303220251.GN47473@verdi> X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: John Leslie wrote: > Yakov Shafranovich wrote: > >>Many of these principles have been well argued over many times. Can you >>clarify where you want to go with this? > > In my experience, discussion of spam-abatement always gets engulfed > in flame-wars between people who know the "one-true-spam-solution" and > feel obliged to correct others whose "one-true-spam-solution" differs > in the slightest detail. > > Some shared basis is needed to get past the initial flame-wars. > I don't honestly know whether working up consensus on principles is the > best way to accomplish that, but it seems like a relatively easy way. > > In any case, I _don't_ intend that such a discussion should happen > _during_ the BoF. The principles I posted represent a first pass at > consensus on the (IETF General) mailing list: thus > they _might_ be a good starting point for such a discussion when a WG > forms. > Such list would be very useful although I am not 100% certain you can get everyone to agree. My only concern here is that the scope of the WG if there is going to be one, might be too limited for this discussion. > BTW: I have no desire to start a long-winded discussion on this list; > but I'm replying to Yakov, who evidently felt it was important to ask > on-list. I am replying to the rest of this off-list, thanks for the hint :) Yakov From owner-ietf-mxcomp Wed Mar 3 14:26:27 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i23MQRfa002677; Wed, 3 Mar 2004 14:26:27 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i23MQRZs002676; Wed, 3 Mar 2004 14:26:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.41]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i23MQQ5q002670 for ; Wed, 3 Mar 2004 14:26:26 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.50] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1Ayeou-0007Vv-00; Wed, 03 Mar 2004 17:26:28 -0500 Received: from [68.24.225.2] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1Ayeos-0002kd-00; Wed, 03 Mar 2004 17:26:28 -0500 Message-ID: <40465B8A.4020207@solidmatrix.com> Date: Wed, 03 Mar 2004 17:26:18 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Jon Kyme CC: ietf-mxcomp@imc.org Subject: Re: Passing authentication information via SMTP References: In-Reply-To: X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Kyme wrote: > Y.S. wrote: > >>The MAIL FROM parameter does not tell us where the mail is from, >>only the bounce address for that email. The assumption is that >>whoever is the bounce address is, is probably the sender, >>but in many cases especially mailing lists, that is not true. >>As a matter of fact in some protocols such as SMTP AUTH, >>the sender's identity is passed in an SMTP extension separate >>from the bounce address. > > > Or the other way up: > The assumption is that the address given as the sender in the MAIL FROM is > useful as the bounce address. > > The MAIL FROM argument is *used* for bounces, but it's use in LMAP > doesn't seem to be contrary to its purpose of specifying the > "sender" mailbox: > Please understand that I am not against using the envelope from, but the fact that its meant for something else needs to be stated. If my consent is required in order to use my address as a bounce address, that's a useful addition for the mail system. But if we want to do that, AND pass authentication information on the original sender, that's two different purposes. In my understanding the RFC appears to be ambigious since it does state that the sender's address is only used for error reporting. My understanding of the RFC that its only meant for error reporting is based on a conversation with Pete Resnick who edited it. Additionally, the analogy on which its based is the real world postal system where the sender's address on the envelope indicates the return address but not necessarily the person that send it. Also, RFC 2554 defines an additional parameter in MAIL FROM: "5. The AUTH parameter to the MAIL FROM command AUTH=addr-spec Arguments: An addr-spec containing the identity which submitted the message to the delivery system, or the two character sequence "<>" indicating such an identity is unknown or insufficiently authenticated. " Apparently the MAIL FROM command was not sufficient for this purpose since it indicates the bounce address. This parameter was added in order to pass authentication information. Yakov P.S. The description from RFC 2554 eerily reminds me of some of the text describing LMAP. From owner-ietf-mxcomp Wed Mar 3 14:32:36 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i23MWaCw003007; Wed, 3 Mar 2004 14:32:36 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i23MWaEH003006; Wed, 3 Mar 2004 14:32:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mauve.mrochek.com ([209.55.107.55]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i23MWZxX003000 for ; Wed, 3 Mar 2004 14:32:35 -0800 (PST) (envelope-from ned.freed@mrochek.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01L7AKBHVH3K000051@mauve.mrochek.com> for ietf-mxcomp@imc.org; Wed, 03 Mar 2004 14:32:38 -0800 (PST) Date: Wed, 03 Mar 2004 14:24:23 -0800 (PST) From: ned.freed@mrochek.com Subject: Re: MBONE access? In-reply-to: "Your message dated Wed, 03 Mar 2004 22:29:33 +0100" <20040303212933.GA4349@danisch.de> To: Hadmut Danisch Cc: Joe Abley , ietf-mxcomp@imc.org, ietf@ietf.org Message-id: <01L7AL6ZI7UQ000051@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <20040303193806.GA2487@danisch.de> <59164458-6D58-11D8-A1AA-00039312C852@isc.org> <20040303212933.GA4349@danisch.de> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > On Wed, Mar 03, 2004 at 04:18:42PM -0500, Joe Abley wrote: > > > > If you find an answer, telling this list would be good. > > > > In the past the answer has been "you don't", often coupled with > > enthusiastic statements about the mbone being in full production, and > > tunnels no longer being necessary. > Please tell me you're kidding... I doubt it. If you'll pardon the pun, there's a fairly major disconnect here. > I just phoned the hotline of my provider T-DSL/T-Online. > They didn't even know what I was talking about. All they > said is that they can't help if I'm using Linux, because that > operating system is not supported. I'd have to call a > 0190 number (62ct / min), which I did. Listening to the > wait queue music for about 1,5 minutes. Then there was a Lady > who also hasn't ever heard about this and couldn't imagine > what I was talking about... This sort of response is pretty typical, as is simply being ignored. In the past I've been able to access the mbone from Harvey Mudd College down the street from where I live. However, each time I've done this the networking staff there has had to struggle to get it working. And this time I didn't ask until it was too late - a recent change to some upstream router has broken things and it probably won't be fixed until sometime next week. I'm all for eating our own dog food, but IMO workable remote access is more important. Ned From owner-ietf-mxcomp Wed Mar 3 15:05:22 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i23N5M1k004556; Wed, 3 Mar 2004 15:05: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 i23N5MS1004555; Wed, 3 Mar 2004 15:05:22 -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 (srv1.fecyk.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i23N5LK0004548 for ; Wed, 3 Mar 2004 15:05:21 -0800 (PST) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: Deficiencies in LMAP MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Wed, 3 Mar 2004 17:05:25 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA791@srv1.fecyk.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Deficiencies in LMAP Thread-Index: AcQBQ00SuRdF0QWOQQ2oDJXd5J0JJQAL8G6w From: "Gordon Fecyk" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i23N5LK0004550 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > One of the biggest objections to LMAP is that spammers can register > domains, and publish fake LMAP information for "owned" machines. In > this situation, LMAP does nothing to stop, or even slow down, the > flood of spam. This was acknowledged a long time ago. What LMAP does in this case is demonstrate who's accountable. If a spammer wants to register a domain under increasingly strict identification rules and risk being held accountable, let him. We can then blacklist the domains. > The idea is to (ab)use rDNS, and to publish LMAP records there, > too. One of the key records to publish is which domains are permitted > to publish LMAP records for this IP. Or, the information could be > which DNS servers are allowed to publish LMAP records for this IP. MTAMARK does this. Problem: Small ISPs and small to medium enterprises don't control rDNS. North American ISPs are LAZY in this regard. [1] They won't use RFC 2317 and in many cases won't bother changing PTR records for you, never mind add new records to their rDNS zones. [1] This comes from ten years consulting experience. Experiences on non-North-American ISPs, anyone? -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Wed Mar 3 15:24:05 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i23NO4TY005433; Wed, 3 Mar 2004 15:24: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 i23NO4EL005432; Wed, 3 Mar 2004 15:24:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i23NO3P1005426 for ; Wed, 3 Mar 2004 15:24:03 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i23NNv5C013613; Wed, 3 Mar 2004 15:23:57 -0800 (PST) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 3 Mar 2004 15:23:58 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'ned.freed@mrochek.com'" , Hadmut Danisch Cc: Joe Abley , ietf-mxcomp@imc.org, ietf@ietf.org Subject: RE: MBONE access? Date: Wed, 3 Mar 2004 15:23:49 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > I'm all for eating our own dog food, but IMO workable remote > access is more > important. The point about eating the dog food is so that you improve it to the point where it is acceptable. I think it is time to accept that the MBONE technology is fatally flawed and is not going to be deployable. Equally flawed and useless are the H.323 protocols that do not tunnel through NAT or even work with a firewall in a remotely acceptable fashion. This thing is not rocket science. There are lots of folk with the little cameras and the ISPs do not want to have their bandwidth wasted needlessly. But trying to do multicast in the network layer has failed. The Internet considers complexity in the network to be stupidity and does not route it. Phill From owner-ietf-mxcomp Wed Mar 3 15:29:14 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i23NTDra005626; Wed, 3 Mar 2004 15:29: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 i23NTDXd005624; Wed, 3 Mar 2004 15:29:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i23NTCf6005615 for ; Wed, 3 Mar 2004 15:29:12 -0800 (PST) (envelope-from millenix@zemos.net) Received: from fda.zemos.net ([68.38.12.170]) by comcast.net (rwcrmhc12) with ESMTP id <200403032329120140087sape>; Wed, 3 Mar 2004 23:29:12 +0000 Received: from zemos.net (phil [10.0.0.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fda.zemos.net (Postfix) with ESMTP id B983A186A3; Wed, 3 Mar 2004 18:29:10 -0500 (EST) Message-ID: <40466A45.7010802@zemos.net> Date: Wed, 03 Mar 2004 18:29:09 -0500 From: Philip Miller User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040122 Debian/1.6-1 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Gordon Fecyk Cc: ietf-mxcomp@imc.org Subject: Re: Deficiencies in LMAP References: <700EEF5641B7E247AC1C9B82C05D125DA791@srv1.fecyk.ca> In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125DA791@srv1.fecyk.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Gordon Fecyk wrote: >> One of the biggest objections to LMAP is that spammers can register >>domains, and publish fake LMAP information for "owned" machines. In >>this situation, LMAP does nothing to stop, or even slow down, the >>flood of spam. > > This was acknowledged a long time ago. What LMAP does in this case is > demonstrate who's accountable. If a spammer wants to register a domain under > increasingly strict identification rules and risk being held accountable, let > him. We can then blacklist the domains. > >> The idea is to (ab)use rDNS, and to publish LMAP records there, >>too. One of the key records to publish is which domains are permitted >>to publish LMAP records for this IP. Or, the information could be >>which DNS servers are allowed to publish LMAP records for this IP. > > MTAMARK does this. > > Problem: Small ISPs and small to medium enterprises don't control rDNS. > North American ISPs are LAZY in this regard. [1] They won't use RFC 2317 and > in many cases won't bother changing PTR records for you, never mind add new > records to their rDNS zones. I'm sure it's bad enough for high-cost commercial customers, such as you mentioned, but consider the more extreme case of MTAs running on home cable/DSL lines. My MTA is such a system, and it is set up to relay everything through my provider's 'smarthost'. However, I don't want any other customer of my provider to be able to forge my domain. I've still not seen any design that handles this. If someone could enlighten me, I would greatly appreciate it. > [1] This comes from ten years consulting experience. Experiences on > non-North-American ISPs, anyone? From what I've heard, RIPE is slow in even properly assigning the namespace to the current owner, let alone the owners keeping it up to date. Philip Miller From owner-ietf-mxcomp Wed Mar 3 16:03:51 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2403pbn008303; Wed, 3 Mar 2004 16:03:51 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2403o03008301; Wed, 3 Mar 2004 16:03:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2403lAe008288 for ; Wed, 3 Mar 2004 16:03:50 -0800 (PST) (envelope-from hadmut@danisch.de) Received: from andromeda (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i2403nuq000998 for ietf-mxcomp@imc.org; Thu, 4 Mar 2004 01:03:49 +0100 Received: (from hadmut@localhost) by andromeda.dresden.danisch.de (8.12.10/8.12.10/Debian-5) id i2403dR6006861 for ietf-mxcomp@imc.org; Thu, 4 Mar 2004 01:03:39 +0100 From: Hadmut Danisch Date: Thu, 4 Mar 2004 01:03:39 +0100 To: ietf-mxcomp@imc.org Subject: RMX++ slides Message-ID: <20040304000339.GA6848@danisch.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, I tried to follow the meeting through video, but unfortunately I couldn't find any provider supporting mcast or anyone giving me a tunnel. The RMX++ slides are available at http://www.danisch.de/work/security/antispam.html regards Hadmut From owner-ietf-mxcomp Wed Mar 3 17:10:04 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i241A3qb012301; Wed, 3 Mar 2004 17:10: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 i241A3j8012300; Wed, 3 Mar 2004 17:10:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from purgatory.unfix.org (postfix@cust.92.136.adsl.cistron.nl [195.64.92.136]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i241A2bt012293 for ; Wed, 3 Mar 2004 17:10:03 -0800 (PST) (envelope-from jeroen@unfix.org) Received: from limbo (limbo.unfix.org [3ffe:8114:2000:240:200:39ff:fe77:1f3f]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 844748318; Thu, 4 Mar 2004 02:10:30 +0100 (CET) From: "Jeroen Massar" To: "'Hallam-Baker, Phillip'" Cc: , Subject: RE: MBONE access? Date: Thu, 4 Mar 2004 02:08:48 +0100 Organization: Unfix Message-ID: <001d01c40185$404b4790$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hallam-Baker, Phillip wrote: > > I'm all for eating our own dog food, but IMO workable remote > > access is more > > important. > > The point about eating the dog food is so that you improve it > to the point where it is acceptable. > > I think it is time to accept that the MBONE technology is > fatally flawed and is not going to be deployable. > > Equally flawed and useless are the H.323 protocols that do not > tunnel through NAT or even work with a firewall in a remotely > acceptable fashion. NAT is the big bad dog here, that is what breaks the end to end connectivity. > This thing is not rocket science. There are lots of folk > with the little cameras and the ISPs do not want to have > their bandwidth wasted needlessly. But trying to do multicast > in the network layer has failed. The Internet considers > complexity in the network to be stupidity and does not route > it. Simple solution: IPv6 tunnelbrokers that provide multicast connectivity. 2 bonuses in one go: - IPv6 connectivity, thus anything becomes end-2-end. - IPv6 Multicast connectivity, also to IPv4 using the gateway. Then ISP's only need to upgrade their core network and can leave the access part as what it is. But fortunatly that is not protocol and thus has nothing to do with ietf ;) Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / http://unfix.org/~jeroen iQA/AwUBQEaBlymqKFIzPnwjEQLmKwCgrRhtO1VEZ4cLnk8+LSZRw4BwAUEAniem UJqwMRsNdlHmTgHoHmJf2FCp =jN+y -----END PGP SIGNATURE----- From owner-ietf-mxcomp Wed Mar 3 17:44:31 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i241iU4i014413; Wed, 3 Mar 2004 17:44: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 i241iUtJ014412; Wed, 3 Mar 2004 17:44:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i241iTK4014406 for ; Wed, 3 Mar 2004 17:44:29 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.11/) with ESMTP id i241iWe9024663; Wed, 3 Mar 2004 17:44:32 -0800 (PST) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 3 Mar 2004 17:44:32 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Jeroen Massar'" , "Hallam-Baker, Phillip" Cc: ietf-mxcomp@imc.org, ietf@ietf.org Subject: RE: MBONE access? Date: Wed, 3 Mar 2004 17:44:29 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > Equally flawed and useless are the H.323 protocols that do not > > tunnel through NAT or even work with a firewall in a remotely > > acceptable fashion. > > NAT is the big bad dog here, that is what breaks the > end to end connectivity. In case you had not noticed there are now tens of millions of NAT devices in use. End users are not going to pay $10 per month for an extra IP address when they can connect unlimited numbers of devices to the net using a $40 NAT box. The NAT war has been over for years, NAT won. The problem is that the IETF still has not come to terms with that fact. The Internet was designed to be a network of networks. The core architecture is NOT end-to-end, that is a political shiboleth that has been imposed later. The features of the Internet that work are the ones that work within the end-to-end model. The features that are failures are the ones where the end-to-end model is bogus. The security world has long since realised that exclusive relianance on end-to-end security is bogus. I don't know of any serious security professionals who now claim that firewalls are bogus or that they will go away as the myth has it. Perimeter security is here to stay. In the case of H323 the problem is not just NAT, it is the derranged protocol which uses a block of 3000 odd TCP/IP ports to receive messages on. there is no way that this is consistent with good firewall management - unless you go to some pretty sophisticated additional control to open up and shut down the ports as required. As for IPv6, the only feasible way to deploy it is by co-opting those NAT boxes. Phill From owner-ietf-mxcomp Wed Mar 3 19:26:59 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i243QwhC021362; Wed, 3 Mar 2004 19:26:59 -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 i243QwLk021361; Wed, 3 Mar 2004 19:26:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.40]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i243QvqB021355 for ; Wed, 3 Mar 2004 19:26:57 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.50] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1AyjVn-0007u4-00 for ietf-mxcomp@imc.org; Wed, 03 Mar 2004 22:27:03 -0500 Received: from [68.24.225.2] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1AyjVm-0007iM-00 for ietf-mxcomp@imc.org; Wed, 03 Mar 2004 22:27:03 -0500 Message-ID: <4046A1FA.10602@solidmatrix.com> Date: Wed, 03 Mar 2004 22:26:50 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: ietf-mxcomp@imc.org Subject: BOF Jabber Logs X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The BoF took place this morning (or evening in US). The Jabber log is available here: http://www.xmpp.org/ietf-logs/marid@ietf.xmpp.org/2004-03-03.html Yakov From owner-ietf-mxcomp Wed Mar 3 20:08:28 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2448SZ7024549; Wed, 3 Mar 2004 20:08: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 i2448SkF024548; Wed, 3 Mar 2004 20:08:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2448OhG024541 for ; Wed, 3 Mar 2004 20:08:24 -0800 (PST) (envelope-from paf@cisco.com) Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 03 Mar 2004 20:15:23 +0000 Received: from xbe-ams-312.cisco.com (xbe-ams-312.cisco.com [144.254.228.202]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2447u1v020632; Thu, 4 Mar 2004 05:07:57 +0100 (MET) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by xbe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 4 Mar 2004 05:08:24 +0100 Received: from [127.0.0.1] ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 4 Mar 2004 05:08:22 +0100 Mime-Version: 1.0 (Apple Message framework v612) To: ietf-mxcomp@imc.org Message-Id: <906E396F-6D91-11D8-A5F4-000A959CF516@cisco.com> Content-Type: multipart/mixed; boundary=Apple-Mail-9--865634582 Cc: Spencer Dawkins Subject: Preliminary minutes from the meeting this morning From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Date: Thu, 4 Mar 2004 13:08:16 +0900 X-Mailer: Apple Mail (2.612) X-OriginalArrivalTime: 04 Mar 2004 04:08:23.0175 (UTC) FILETIME=[55F44970:01C4019E] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-9--865634582 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed If you have comments, let me and Ted know. paf --Apple-Mail-9--865634582 Content-Transfer-Encoding: 7bit Content-Type: text/html; x-unix-mode=0444; name="Marid_BoF_Notes.html" Content-Disposition: attachment; filename=Marid_BoF_Notes.html Marid BoF Notes Marid BoF

Scribes include Spencer Dawkins <spencer@mcsr-labs.org>...

Patrik and Ted co-chairing, with a really tight leash...

Topic is MTA authentication, period. Behave in the BoF if you want to move to a working group.

BoF chartered out of ASRG in IRTF - we think this is what is ready for IETF now.

Patrik - we're working on this wrong - solutions driving search for problems instead of the other way around.
    Need to agree on the problem we're solving, and need to do that up front.

    SMTP used in many ways, between many entities, with spam, worms and trojans injected in a proper mail flow
    These injections look like any other mail until they get to the end user
    Patrik displayed a lovely work of modern art showing mail flows between MUAs using a variety of paths
    Things start fairly simply, but get complicated pretty quickly with relays, mailing lists, etc.
    Open questions - will verification of SMTP peer help? what transition strategies are going to work?
       What will spammers do in response?
       Not everyone uses the same SMTP relay (some belonging to ISP, some belonging to domain)
       Is SMTP-AUTH/port 576 the right answer?
       Are increased restrictions on relay rewriting going to be deployed?
       What DNS RRs should be used?
    Patrik has a summary comparison of proposals, but we're not talking about "which one is best"

Q: How many MTAs are there? at least one per e-mail domain? Raising concern about database size requirements...
A: Problem is that attack vectors are constantly changing - who is a zombie this week?

Q: Need to look at whether DNS record use is forward-tree, reverse-tree, or something else - this determines also DNS impact

Q: We can't answer "will this stop spam" with our current problem statement?
A: You're right. We're asking if it's worth putting engineering effort into this work.
Q: Are the social engineering impacts of zombie creation in scope?
A: Fraudulent domain aspect is in scope

Q: Original problem statement was whether these proposals impact the DNS. But what spammers do should be in scope (the cure could be worse)

Q: We're talking about implications, and a lot of people are motivated to look at spam. But we need to look at longer-term effects, including e-mail use and users.

Q: What SMTP domain name useage forgery are we talking about? There are three.
Q: Domain names change for "roaming MTAs" and we'll have problems verifying them.
A: Probably need to be clear on which identity is being authorized at any given point in time and make sure mechanisms that do this work
A: There are proposals on the table for using specific identities - need to focus proposals on which identity is being used and what problem is being solved
       MTAs are becoming MSAs, and that's different

Q: Verification of SMTP peers will help, but will only help a little

Q: Reduce the number of permissible channels so necessary audit process is more approachable

Gordon - DMP
    shooting for lightest load on DNS
    queries both network address and domain at once
    queries DNS on every SMTP transaction (MAIL FROM)
    works better for roaming users
    does not require changes to DNS
    deals with ISPs that won't let us insert stuff in DNS
    demonstrating 20% decrease in SMTP volumes
    DMP requires more individual records in the DNS zone, and more work for DNS administrator (although some of this can be automated)
    No way to point to another domain as authoritative
    Overloads TXT RR, but could use another RR if that's better
    Does define another namespace

Q: Problem statement should include performance impacts of various approaches

Patrik, channeling Hadmut Danisch - RMX ++
    DNS is not a good choice for a variety of reasons

Q: if we're not using DNS, how are we looking up the server? Only to find a non-DNS service - may have DNS impact anyway
A: records would have TTLs, so could be cached
A: no policies stored in DNS

    Lots of reasons to use HTTP/HTTPS
    Policy flexiblity with Dynamic/Auth
    Fraud/spoofing not limited to e-mail

Q: Not happy because BoF is on DNS and proposal is not - not good use of IETF time, no way to prepare

Meng - SPF
    Came from RMX and DMP
    DMP lookups are simple, RMX can define everything in a single record you can cache
    macro that expands to DMP records
    includes "soft fail" capability in grammar to allow testing of policies
    looks at both return path and HELO (if no return path is available), or either taken separately
    but there is a tradeoff here
   
Q: Which identities are you authenticating?
A: Return path domain, unless it's null, and there are seven response codes providing flexible policy statement
Q: How did the macro language come about? Macro language seems to extend SMTP, not replace it

    Authentication could be per-user, or lots of other things

Q: Are we doing authentication, authorization, or policies?
A: Simplest answer is "authenticated senders are authorized", but complexity rises from there

Q: do you have way to tell policy writer what policy is evaluating to? how to debug this language?
A: probably based on user complaints...
Q: what about inserting notification as part of the macro? Of course, this is an invitation to DoS attacks...
A: "dig altavista.com" - they send no e-mail, but want to see who is forging mail

Q: concerned about arbitrarily complicated policy languages - wannabe senders don't know what to do when mail acceptance rule is arbitrarily complex
A: senders write policy, not receivers
Q: but rules are too complex to debug

Q: don't exceptions that you can see in the DNS, like per-user exceptions, invite attacks?
A: yes, they do, but some customers want the exceptions anyway...

Q: why does SPF go into policies?
A: because we don't all run PGP yet...
Q: please think about trust paths for deployability

Dave Crocker - Role of authentication
    need to add "who does what" to our list
    need to be clear about identify vs authentication vs authorization
    remember that Mail-From: is a Bounces address, not an identity
    some schemes validate authors, others validate provider network
    concerns about "author-based" MTA registration schemes - administration and scaling, kiosks/greeting card services
       not authentication schemes and not useful beyond spam
       redefining long-standing e-mail semantics
       removes store-and-forward on the internet
       policy implications

Q: redefining core e-mail semantics include semantics that spammers exploit

Q: Harald thinks Dave can't be wrong all the time - checking Mail-From could prevent bounces from ending up in the wrong place is a good thing
   
Q: XMPP uses an SRV scheme to link IPs with domains - useful there, why not here?
    Pete Resnick (XMPP chair) - XMPP uses SRV to find destination, I think we're trying to use to find the source, but we can follow up offline

General Discussion

C: use of reverse tree is decreasing, not increasing - IPv6 is clouded, but IPv4 is clear and big
C: we have a delegation issue in the root - 20-percent of reverse tree is broken

C: DNS follows administrative lines, but the lines are different in forward and reverse trees - organization/forward vs topology/reverse
    not clear that reverse is all that helpful
    want to use existing records and overload them weirdly. this is not good. TXT is too overloaded now, it's all freeform, interactions are problems
    need to use specific resource records, not overload randomly
    there is an upgrade problem, but it's not upgrading the world - no stubs, etc. interative resolvers need to be upgraded, that's all
    we're putting spammer/attack targets in DNS, and DNS is fragile - need DNSSEC up front, and this requires upgrades anyway - new RR is minor problem

C: RFC 2929 allows new RR type creation pretty easily

C: even from operator perspective, it's easy to get confused
    would like to support ten-year-old implementations, with no more pain than a service pack upgrade
    is DNS really that fragile? can we lean on it a little longer?
    Rob Austein has DNS threats draft in front of the IESG now (draft-ietf-dnsrext-threats-06.txt)

C: adding an RR has OS implications, too, and GUI implications
    can do your own socket call to get unknown DNS RRs without OS implications

C: we're not just changing the basics of SMTP, we're changing the basics of DNS as well - need to watch this carefully
    never seen an application try to put configuration data in DNS before

C: distinction between DNS operators and SMTP operators - dynamic DNS update had the same implications

C: too easy to forge sub-domains of protected domains, behavior forced by RFC 1034 section 4.3.2
A: this is the way DNS wildcards work. Using them is a mistake. That's why they are optional.

C: where is the increased query load going to land? RIRs? somewhere else?

C: also a tree-walking issue, because eventually you have to specify tree-walking in the general case, and that's not easy

C: bounces that don't go anywhere have impacts on systems trying to send bounces - if destination has no mailer, MTA will retry for days

C: doesn't the DNS load call on the sender?
A: depends on TTL values - can't answer in the general case.
    need to be aware of impacts of deployed mistakes in resolvers as we do this stuff

Impacts on SMTP

C: need a list of operators and administrators as part of proposal evaluation
    who updates what? when?
    all proposals have serious administrative overhead, some more than others
    inertia of 0.5B e-mail users is immense - easier to add behavior than to change behavior
    removing capability for store-and-forward - implications are huge
    third-party mail handling creates a lot of additional considerations
    altering the human uses of e-mail, and this gets ignored - too many ways people use e-mail in too many ways
       cannot send mail except from a computer you've previously registered
C: tried to design around these considerations - sending bounces to somewhere else for e-greeting card sites, etc.
    maybe store and forward is too abusable to save
C: but the current mail situation cannot continue - AOL blocked 4B pieces of e-mail in three days this month
C: I heard you say this ... need to avoid hysteria in engineering analysis and tradeoffs
C: DNSSEC, early on, focused more on putting security into DNS than looking at how DNS really worked.
    learn from this example or you'll spend time fixing stuff you've broken
C: need to take a stand on what we're willing/not willing to lose
    store and forward could go away if we support disconnected clients with authenticated dropoff protocols
C: fundamental design of e-mail is a many-to-many mesh. spammers take advantage of this fundamental fact
    everything we do to abate the problem changes the fundamental design of e-mail
    how far can we go in changing the fundamental design of e-mail?
    what can we change that spammers won't fight?
C: we need to be constructive - saying "this breaks e-mail" isn't constructive
    saying this breaks a feature, but the cost of forgery is higher than the value of the feature is also constructive.
C: maybe the many-to-many mesh is already gone.
C: reminded me of a bit of hysteria over "raw sockets" previously
C: many-to-many mesh is already breaking - people are afraid to open e-mail, entire domains being blacklisted
C: spammer cost isn't the point - almost nothing we can do will kill e-mail completely
       <ruled out of scope>

Is there IETF work in this arena - developing an MTA authorization DNS resource record for MTAs checking Mail-From/HELO to signal to peer MTAs that it is authorized to send mail?
    Actual text from Patrik
C: Some proposals are anti-spam, others are just plain good ideas - need to keep this distinction in mind
    believe that the question as stated is a plain good idea and should be done whether there was spam or not
C: some of the 4B mail messages are forged, some are not, some are bounces, some are not, not sure what the percentage we'll fix is
    people who need to solve the problem quickly are throwing out solutions
    maybe we can come up with a good idea that these people haven't thought of
    don't overload TXT records, for instance
    do good work, and see if it helps - existing proposals all need work
C: resounding yes, including technical and political aspects, because people are going to implement something, and "something" could be worse
C: haven't established that DNS record is the best approach
C: do you intend that the authorization be binary?
Ted: that's a tradeoff - "yes/no" might deploy faster than something policy-based
C: Harald thinks this the right thing to do, Pete is long, the love fest is over
    we've built the entire Internet as a debugging exercise, take the chance and get somewhere
C: really want to see this work come through the IETF just to scrub proposals for bad effects
C: the work is useful, how long to deploy? how snappy will the spammer response be?
C: something like this will get done whether we do it or not
    limit the scope to authorization, not policy - need a clear target and tractable problem
    not clear that DNS is the right answer/only answer, need more discussion before we know this
C: concerned about doing this work in an open forum, especially if we bring in the current proposals
    not everyone with a proposal is interested in consensus
    lots of people will be participating
Harald: there's more than one way to run a working group
C: what about a next-generation protocol?
    shouldn't bog this down for short-term issues
C: WG should concentrate on semantics, not the representation - we have plenty of DNS geeks who will figure this out if you know the semantics
C: There are people in the IETF with agendas, this shouldn't bother us
    concerns may be warranted, but this session proves it can be done - with a lot of overhead, but it can be done
    this goal would be worth doing if there were no spam
    we don't have to ignore existing proposals, there are issues about bringing them in (IPR, etc), but we should move forward
C: need good model of how mail works today

Hummms

Chartered working group in 4-6 weeks - would you participate 5 hours/week or more? Stand up ... there is a core of active participants

If we deploy an experimental answer early, is transition to final answer in six months too painful?
C: we're not going to get this right the first time, so this is acceptable
Looks like this is also good enough to go forward
--Apple-Mail-9--865634582 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed --Apple-Mail-9--865634582-- From owner-ietf-mxcomp Wed Mar 3 20:35:41 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i244Zens026261; Wed, 3 Mar 2004 20:35: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 i244ZeN5026260; Wed, 3 Mar 2004 20:35:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i244ZdrV026250 for ; Wed, 3 Mar 2004 20:35:39 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i244ZdEj001167; Wed, 3 Mar 2004 20:35:39 -0800 (PST) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 3 Mar 2004 20:35:39 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Dean Anderson'" Cc: "'ned.freed@mrochek.com'" , Hadmut Danisch , Joe Abley , ietf-mxcomp@imc.org, ietf@ietf.org Subject: FW: MBONE access? Date: Wed, 3 Mar 2004 20:35:33 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >> I think it is time to accept that the MBONE technology is >> fatally flawed and is not going to be deployable. >There is nothing wrong with Mbone, per se--though, as someone mentioned, >it might be nice to have better codecs. The problem is that multicast is >flawed, and not going to be globally deployable. Well that was my real point, it is a bogus concept. The fact it still does not work for all but a tiny fraction of the net shows that. If the IETF put a tenth the effort that has gone into multicast into fixing the spam problem, or something the end users (not geeks) care about... >> Equally flawed and useless are the H.323 protocols that do not >> tunnel through NAT or even work with a firewall in a remotely >> acceptable fashion. >There is nothing wrong with h323. There are good reasons for the IP >address of the client to be embedded in some h323 control messages. In >most cases, this is a good thing, and an advantage for call control and >call routing systems. Indeed, this is what gives h323 its scalability and >ability to compete and work in tandem with the PSTN. This design feature seems to be a work arround the rule that reserved ports can only be accessed with system privileges. There are much better work arrounds. If you think about it the port number is utterly irrelevant bandwidth wise. > But when passing >through a NAT, those addresses and port numbers have to be properly and >statefully translated---That's what a proxy does. The problem is that >your NAT doesn't (or most likely, /didn't/ until the last year or two or >three) support h323 proxy. You need h323 proxy support just like you need >proxy support for many non-trivial protocols. Either upgrade your NAT >software, or if you run linux/bsd/etc, install an open source h323 proxy >on your NAT gateway. Schemes that require NAT boxes to implement ad hoc kludges for each protocol are not a good plan. I would much rather have one protocol that gives my machine to request a port be opened on the NAT box. The problem with NAT is the need for ad hoc kludges. Deal with the fact that NAT is here to stay and the problems can be eliminated trivially. This could be done with a trivial mod to DHCP (hey buddy, this IP address I just gave you is behind a NAT) and a very simple UDP request/response protocol (give me an external port in the range 3000 to 3050) (OK you have 3002, the IP address is 10.2.2.2). There was a group looking at this type of idea, seems that it is a feature that is going to be deliberately withheld to make sure that the incentive to upgrade to IPv6 does not get lost accidentally. So the current state of play is that this is proposed for the IPv6 NAT boxes. Phill From owner-ietf-mxcomp Wed Mar 3 23:00:04 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i24704Qp059589; Wed, 3 Mar 2004 23:00: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 i24704dN059586; Wed, 3 Mar 2004 23:00:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i247021Z059545 for ; Wed, 3 Mar 2004 23:00:03 -0800 (PST) (envelope-from hadmut@danisch.de) Received: from andromeda (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i247062P008870 for ietf-mxcomp@imc.org; Thu, 4 Mar 2004 08:00:06 +0100 Received: (from hadmut@localhost) by andromeda.dresden.danisch.de (8.12.10/8.12.10/Debian-5) id i246obGP012800 for ietf-mxcomp@imc.org; Thu, 4 Mar 2004 07:50:37 +0100 From: Hadmut Danisch Date: Thu, 4 Mar 2004 07:50:36 +0100 To: ietf-mxcomp@imc.org Subject: Sorry Message-ID: <20040304065036.GA12753@danisch.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, (good morning) I apologize for not being online at the session. First, it was (nearly) impossible to get mcast access since most providers here don't support it and nobody provides mcast tunnels anymore (because they say it's available everywhere). Second, even those who had mcast access in Germany told me that they could not receive the IETF streams. Third, about 10 minutes after the session started my DSL line broke down. As far as I know the Provider (T-Online/T-DSL) had some kind of problem and many DSL lines were out of order. So I couldn't even follow on Jabber. :-( Maybe multicast distribution is not the best choice as long as this is unavailable for most IP users... Hadmut From owner-ietf-mxcomp Thu Mar 4 02:06:18 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i24A6HeQ020273; Thu, 4 Mar 2004 02:06: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 i24A6HJc020272; Thu, 4 Mar 2004 02:06:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from argon.connect.org.uk (argon.connectinternetsolutions.com [193.110.243.33]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i24A6FNL020264 for ; Thu, 4 Mar 2004 02:06:16 -0800 (PST) (envelope-from jrk@merseymail.com) Received: from mmail by argon.connect.org.uk with local (connectmail/exim) id 1Aypk8-0008Qy-2L; Thu, 04 Mar 2004 10:06:16 +0000 Subject: Re: Passing authentication information via SMTP To: "Yakov Shafranovich" From: "Jon Kyme" Cc: X-Mailer: [ConnectMail 3.12.1] X-connectmail-Originating-IP: 172.25.243.3 Message-Id: Date: Thu, 04 Mar 2004 10:06:16 +0000 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Yakov Shafranovich writ: > > > Please understand that I am not against using the envelope from, but the > fact that its meant for something else needs to be stated. If my consent > is required in order to use my address as a bounce address, that's a > useful addition for the mail system. But if we want to do that, AND pass > authentication information on the original sender, that's two different > purposes. > The MAIL FROM argument is a sender identifier. I don't believe that the RFC is in any way ambiguous on this point. > In my understanding the RFC appears to be ambigious since it does state > that the sender's address is only used for error reporting. the source mailbox (between "<" and ">" brackets), which can be used to report errors That's "can". > My > understanding of the RFC that its only meant for error reporting is > based on a conversation with Pete Resnick who edited it. > I appreciate that you may have extra knowledge, but unfortunately, the rest of us have only got the RFCs / standards to go on. If you think it would be useful to clarify the intention of the published specs then you should go ahead :-) > Additionally, the analogy on which its based is the real world postal > system where the sender's address on the envelope indicates the return > address but not necessarily the person that send it. > And yet we call it "sender" - but that's just an analogy. > Also, RFC 2554 defines an additional parameter in MAIL FROM: > > "5. The AUTH parameter to the MAIL FROM command > > AUTH=addr-spec > > Arguments: > An addr-spec containing the identity which submitted the message > to the delivery system, or the two character sequence "<>" > indicating such an identity is unknown or insufficiently > authenticated. > " > > Apparently the MAIL FROM command was not sufficient for this purpose > since it indicates the bounce address. This parameter was added in order > to pass authentication information. > No, not really. This parameter provides for passing on the "authenticated identity". i.e. not information that a subsequent agent will use to authenticate, but rather the identity that this agent has *already* authenticated. This might be a suitable way of passing on an authenticated sender identifier, but it doesn't seem to be intended for carrying an unauthenticated identifier. That *would* be overloading. > Yakov > > P.S. The description from RFC 2554 eerily reminds me of some of the text > describing LMAP. > > Neccessarily, I guess. It's a similar problem. LMAP via an extension certainly seems "cleaner" and avoids arguments about MAIL FROM "overloading" - but use of the MAIL arg has a lower deployment hurdle. An realistic position would be to acknowledge MAIL as useable, but perhaps recommend transition to an extension. Of course a lot of this hangs on the fuzzy definition of a sender. If I inject a message to the MTS, I'm the sender... but if the messages passes through a forwarder / exploder, am I the sender of the message received at the far end? The message can have the same body, but will have a new envelope. For me, the entity that constructed the envelope is the sender. This is why I don't have a problem with some requrement for a forwarder to supply a new sender address. I think this is a clarification. Others differ. Regards, JK -- From owner-ietf-mxcomp Thu Mar 4 03:11:00 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i24BAxM1025652; Thu, 4 Mar 2004 03:10:59 -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 i24BAxh5025651; Thu, 4 Mar 2004 03:10:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [208.210.125.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i24BAwAS025645 for ; Thu, 4 Mar 2004 03:10:58 -0800 (PST) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [208.210.125.24]) by emerald.pobox.com (Postfix) with ESMTP id 21EFE134B92; Thu, 4 Mar 2004 06:10:58 -0500 (EST) Received: by dumbo.pobox.com (Postfix, from userid 505) id 0688D5AC; Thu, 4 Mar 2004 06:10:58 -0500 (EST) Date: Thu, 4 Mar 2004 06:10:58 -0500 From: Meng Weng Wong To: ietf-mxcomp@imc.org, Spencer Dawkins Subject: Some slides from the meeting this morning Message-ID: <20040304111057.GB21481@dumbo.pobox.com> References: <906E396F-6D91-11D8-A5F4-000A959CF516@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <906E396F-6D91-11D8-A5F4-000A959CF516@cisco.com> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Mar 04, 2004 at 01:08:16PM +0900, Patrik F?ltstr?m wrote: | If you have comments, let me and Ted know. A number of diagrams went up on the screen. People might find useful: http://spf.pobox.com/mailflows.html http://dumbo.pobox.com/~mengwong/tmp/comparisons/buildyourown.png http://dumbo.pobox.com/~mengwong/tmp/comparisons/familytree.png s/html|png/pdf/ for pdf versions. "Build your own" argues that these proposals are really just riffs on the same theme, and "Family tree" elaborates on some of the major tradeoffs and shows how different design decisions result in different proposals. cheers meng From owner-ietf-mxcomp Thu Mar 4 03:15:35 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i24BFZ3T025935; Thu, 4 Mar 2004 03:15: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 i24BFY5d025934; Thu, 4 Mar 2004 03:15:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i24BFXvC025914 for ; Thu, 4 Mar 2004 03:15:33 -0800 (PST) (envelope-from paf@cisco.com) Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 04 Mar 2004 03:22:31 +0000 Received: from xbe-ams-312.cisco.com (xbe-ams-312.cisco.com [144.254.228.202]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i24BEx1v020060; Thu, 4 Mar 2004 12:15:00 +0100 (MET) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 4 Mar 2004 12:15:27 +0100 Received: from [127.0.0.1] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 4 Mar 2004 12:15:26 +0100 In-Reply-To: <20040304111057.GB21481@dumbo.pobox.com> References: <906E396F-6D91-11D8-A5F4-000A959CF516@cisco.com> <20040304111057.GB21481@dumbo.pobox.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3A510419-6DCD-11D8-A5F4-000A959CF516@cisco.com> Content-Transfer-Encoding: 7bit Cc: ietf-mxcomp@imc.org, Spencer Dawkins From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: Some slides from the meeting this morning Date: Thu, 4 Mar 2004 20:15:22 +0900 To: Meng Weng Wong X-Mailer: Apple Mail (2.612) X-OriginalArrivalTime: 04 Mar 2004 11:15:26.0755 (UTC) FILETIME=[FECC4F30:01C401D9] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Paul and I are working on getting things up on the IMC webserver. I tried to send the package to this list, but the whole zip-file (540k) was too large for the list policy. Stand by and you will get it. They will also end up in the proceedings of course. paf On 2004-03-04, at 20.10, Meng Weng Wong wrote: > > On Thu, Mar 04, 2004 at 01:08:16PM +0900, Patrik F?ltstr?m wrote: > | If you have comments, let me and Ted know. > > A number of diagrams went up on the screen. People might find useful: > > http://spf.pobox.com/mailflows.html > http://dumbo.pobox.com/~mengwong/tmp/comparisons/buildyourown.png > http://dumbo.pobox.com/~mengwong/tmp/comparisons/familytree.png > > s/html|png/pdf/ for pdf versions. > > "Build your own" argues that these proposals are really just riffs on > the same theme, and "Family tree" elaborates on some of the major > tradeoffs and shows how different design decisions result in different > proposals. > > cheers > meng > From owner-ietf-mxcomp Thu Mar 4 07:35:45 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i24FZjEp046894; Thu, 4 Mar 2004 07:35:45 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i24FZj3t046893; Thu, 4 Mar 2004 07:35:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i24FZhfg046875 for ; Thu, 4 Mar 2004 07:35:43 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.11/) with ESMTP id i24FZfBS010070; Thu, 4 Mar 2004 07:35:41 -0800 (PST) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 4 Mar 2004 07:35:41 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'jnc@mercury.lcs.mit.edu'" , ietf-mxcomp@imc.org, ietf@ietf.org Subject: RE: Perimeter security (was: MBONE access?) Date: Thu, 4 Mar 2004 07:35:35 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Perimeter security is brittle, inflexible, complex security. > You have to have > understanding of the semantics of an application at the > perimeter to check > whether the operation is allowed - which is bad so many ways > I don't feel > like listing them all. It is only useful in my view if you have a human expert monitoring the firewall 24x365. That is what we do as a managed service. But you also need all the intrusion detection, patch management etc. I would like to go deeper into the corporate nets, but the customers rarely let this happen. > Generalize to all security > problems caused by bugs in applications. And there are lots > and lots and lots > of lines of code to find bugs in.... Yes, the bad guys aren't > using that > technique at the moment - because they don't have to. When > the easier holes > get plugged, they will.) In a conventional installation there are twin firewalls and the mail server along with all the other external services is situated in the DMZ in between. It is not proof perfect of course, people keep knocking holes in the perimeter, and don't get me started on viruses. But we can usually detect when a machine on the internal network has been zombiefied and shut it down. To make it work well you need to have network wide information. We combine information from all our NOCs and SOCs so that we can be pro-active. The firewall by itself does not provide much value. > The CS community *was* on the right track for the real > solution - about > thirty years ago, with Multics' AIM boxes. We made a bad > mistake when we saw > workstations as "personal machines, so we don't need any of > that security > stuff". I would like to put protocol enforcement modules into hubs. I like the idea of separating network security into a different device to the workstation - gives a much more secure trusted computing base. > As soon as you connect your "personal" machine up to a > network, and start > interacting in any but the most basic ways, it's not > "personal" any more. > Hell, we should have learned that lesson from floppy viruses. Yep, it is really funny hearing the Mac guys smuggly saying that there are no viruses on Mac... > And don't get me started on the > ignorance/cupidity/stupidity/arrogance/etc of > certain software companies who distributed applications which > basically > downloaded arbitary chunks of code from the network and ran it... Hey they were signed chunks of code! Actually the problems we have had from ActiveX and Java are considerably less than from Javascript and worst of all click to execute malicious code in email. If you are going to launch applications Windows had all the machinery built in from day one to do it safely. You create a subprocess and remove the privs necessary to attack the host machine. And just why do we allow untrusted code to modify the O/S boot path? The spammers are not sending out viruses, they are blasting out spam that contains a trojan. No need to bother reading address books any more! Phill From owner-ietf-mxcomp Thu Mar 4 08:55:27 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i24GtQKC052571; Thu, 4 Mar 2004 08:55:27 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i24GtQvt052570; Thu, 4 Mar 2004 08:55:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from moebius2.Space.Net (moebius2.Space.Net [195.30.1.100]) by above.proper.com (8.12.11/8.12.8) with SMTP id i24GtP7F052555 for ; Thu, 4 Mar 2004 08:55:25 -0800 (PST) (envelope-from maex@Space.Net) Received: (qmail 10569 invoked by uid 1013); 4 Mar 2004 16:55:21 -0000 Date: Thu, 4 Mar 2004 17:55:21 +0100 From: Markus Stumpf To: ietf-mxcomp@imc.org Subject: Re: Deficiencies in LMAP Message-ID: <20040304165521.GD94703@Space.Net> References: <700EEF5641B7E247AC1C9B82C05D125DA791@srv1.fecyk.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125DA791@srv1.fecyk.ca> User-Agent: Mutt/1.4.1i Organization: SpaceNet AG, Muenchen, Germany X-PGP-Fingerprint: 66 F3 75 79 01 D0 B8 5F 1A C7 77 88 4A B6 70 DF Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Mar 03, 2004 at 05:05:25PM -0600, Gordon Fecyk wrote: > MTAMARK does this. > > Problem: Small ISPs and small to medium enterprises don't control rDNS. > North American ISPs are LAZY in this regard. [1] They won't use RFC 2317 and > in many cases won't bother changing PTR records for you, never mind add new > records to their rDNS zones. Something has to be changed if we want to get the spam problem under control. So with everyone running around saying "but this has to be changed" will not change something especially not the spam problem ;-))) DNS maintenance is something that is there for years. All you have to do is revive it a bit for the rDNS tree and as soon as their customer will not be able to send out email any longer all the lazy ISPs will either get things going fast or they will loose their customers. It's as easy as that. And how often do you change your mailserver? The addresses of our mailservers (and most of our customers) haven't changed in years. Another IMHO more grave problem with solutions like e.g. SPF is that they are too complicated. I'd bet that about 2 percent of our domain customers will manage it to add correct SPF records to their domains or even provide relevant information so that we could add it for them and I don't think this percentage will be much different with other ISPs. So nothing will change. The big companies that also have possibilities now to deal with forgeries will be more save and the small/private customers will suffer from forgeries and as the number of domains with SPF records will be small none can block non-SPF aware domains without blocking 99% of legitimate traffic. > [1] This comes from ten years consulting experience. Experiences on > non-North-American ISPs, anyone? We try to keep our rDNS as accurate as possible. But in Germany there are a lot of ISPs that think rDNS is kinda obsolete and nobody cares anyway. So all they come up with is - like in most of North-America and the rest of the world - they use some fumbled IP address as name in hex, arabic and some also in latin numbers like 200-232-12-133.hsm.com.br:200.232.12.133 ip-111.net-81-220-35.lyon.rev.numericable.fr:81.220.35.111 adsl-64-109-109-201.dsl.gdrpmi.ameritech.net:64.109.109.201 ip503cd44b.speed.planet.nl:80.60.212.75 dcxxv.pdyn.saunalahti.fi:62.142.69.226 ymccliii.dsl.saunalahti.fi:62.142.153.153 >From our experience the statement of Philip Miller (other reply to the same message) about RIPE is not true. \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" From owner-ietf-mxcomp Thu Mar 4 09:48:52 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i24HmqJA055201; Thu, 4 Mar 2004 09:48: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 i24Hmquv055200; Thu, 4 Mar 2004 09:48:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i24HmpWt055193 for ; Thu, 4 Mar 2004 09:48:51 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i24Hmp1i021717; Thu, 4 Mar 2004 09:48:51 -0800 (PST) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 4 Mar 2004 09:48:51 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Markus Stumpf'" , ietf-mxcomp@imc.org Subject: RE: Deficiencies in LMAP Date: Thu, 4 Mar 2004 09:48:46 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > We try to keep our rDNS as accurate as possible. But in Germany there > are a lot of ISPs that think rDNS is kinda obsolete and nobody cares > anyway. So all they come up with is - like in most of > North-America and > the rest of the world - they use some fumbled IP address as > name in hex, arabic and some also in latin numbers like The fact that the rDNS is in the state it is in is probably symptomatic of the fact it was never given a clear and useful purpose. Give the rDNS a clear and useful purpose and it is likely that it will be managed in a more reliable fashion. One nit. The big weakness I see in MTAMARK is that the idea is proscriptive, these IP addresses are not allowed to send email. I think that is completely inappropriate. Don't tell the receiver what to do, don't even try. Just give tell the facts and let others make what use of them they may. If ISPs want to disable SMTP from an address they should simply block port 25. The point of MTAMARK is that this is not an appropriate response. If someone does not want to receive email from residential DSL the solution is NOT to stop all email access from residential DSL. If an ISP does not want to be held responsible for the email comming from an IP address then just make a note of the fact and recipients will look for other ways of holding them accountable. Phill From owner-ietf-mxcomp Thu Mar 4 10:01:32 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i24I1VoJ055702; Thu, 4 Mar 2004 10:01:31 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i24I1VIb055701; Thu, 4 Mar 2004 10:01:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.41]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i24I1Uwd055695 for ; Thu, 4 Mar 2004 10:01:30 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.50] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1AyxA0-000364-00; Thu, 04 Mar 2004 13:01:28 -0500 Received: from [68.244.134.55] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1Ayx9y-00039M-00; Thu, 04 Mar 2004 13:01:28 -0500 Message-ID: <40476EBF.3010400@solidmatrix.com> Date: Thu, 04 Mar 2004 13:00:31 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: "Hallam-Baker, Phillip" CC: "'Markus Stumpf'" , ietf-mxcomp@imc.org Subject: Re: Deficiencies in LMAP References: In-Reply-To: X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hallam-Baker, Phillip wrote: > One nit. The big weakness I see in MTAMARK is that the idea > is proscriptive, these IP addresses are not allowed to send email. > I think that is completely inappropriate. Don't tell the > receiver what to do, don't even try. Just give tell the facts > and let others make what use of them they may. > > If ISPs want to disable SMTP from an address they should simply > block port 25. The point of MTAMARK is that this is not an > appropriate response. If someone does not want to receive email > from residential DSL the solution is NOT to stop all email > access from residential DSL. > > If an ISP does not want to be held responsible for the email > comming from an IP address then just make a note of the fact > and recipients will look for other ways of holding them > accountable. > How would you do that? Just state "IP xxxxx is a dynamic"? Yakov From owner-ietf-mxcomp Thu Mar 4 10:08:15 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i24I8Ev5055875; Thu, 4 Mar 2004 10:08: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 i24I8ENJ055874; Thu, 4 Mar 2004 10:08:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from moebius2.Space.Net (moebius2.Space.Net [195.30.1.100]) by above.proper.com (8.12.11/8.12.8) with SMTP id i24I8D6X055867 for ; Thu, 4 Mar 2004 10:08:13 -0800 (PST) (envelope-from maex@Space.Net) Received: (qmail 14280 invoked by uid 1013); 4 Mar 2004 18:08:15 -0000 Date: Thu, 4 Mar 2004 19:08:15 +0100 From: Markus Stumpf To: "Hallam-Baker, Phillip" Cc: ietf-mxcomp@imc.org Subject: Re: Deficiencies in LMAP Message-ID: <20040304180815.GA13559@Space.Net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Organization: SpaceNet AG, Muenchen, Germany X-PGP-Fingerprint: 66 F3 75 79 01 D0 B8 5F 1A C7 77 88 4A B6 70 DF Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Mar 04, 2004 at 09:48:46AM -0800, Hallam-Baker, Phillip wrote: > One nit. The big weakness I see in MTAMARK is that the idea > is proscriptive, these IP addresses are not allowed to send email. > I think that is completely inappropriate. Don't tell the > receiver what to do, don't even try. Just give tell the facts > and let others make what use of them they may. MTAMARK is not telling anyone what they have to do. It's a way for admins that control an IP range to tell others: this IP /is not/ intended to run a sending MTA or this IP /is/ intended to run a sending MTA The "controlling" authority can either be an ISP or a customer of an ISP to whom the block was allocated. When doing abuse management and phoning with customers I often hear "this host should not send messages out, it's a workstation of a secretary". Now these customers have a way to tell this fact to all MTAs in the world. What these MTAs do with this information is up to them. With the current MTA proposal it is not possible to use wildcard DNS entries for marking so we propose that the MTA=no records should not be needed in the long term but only MTA=yes records would be needed and so the default for "no record" should be "MTA=no". If all ISPs in the world would prefix their dummy rDNS entries for dialup customers with dialup-1.2.3.4.* or would even use some CIDR notation like dialup-125.13/24.1.10.isp thus telling others that 10.1.13/24 is a dialup net classification would even be more easy and less error prone than DUL DNSBLs. \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" From owner-ietf-mxcomp Thu Mar 4 10:09:57 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i24I9uKD055952; Thu, 4 Mar 2004 10:09: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 i24I9u6k055950; Thu, 4 Mar 2004 10:09:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.40]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i24I9tRT055942 for ; Thu, 4 Mar 2004 10:09:55 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.50] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1AyxIB-0003AU-00; Thu, 04 Mar 2004 13:09:55 -0500 Received: from [68.244.134.55] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1AyxIA-0003Ze-00; Thu, 04 Mar 2004 13:09:55 -0500 Message-ID: <404770E8.9050602@solidmatrix.com> Date: Thu, 04 Mar 2004 13:09:44 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Jon Kyme CC: ietf-mxcomp@imc.org Subject: Re: Passing authentication information via SMTP References: In-Reply-To: X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Kyme wrote: > Of course a lot of this hangs on the fuzzy definition of a sender. > If I inject a message to the MTS, I'm the sender... but if the messages > passes through a forwarder / exploder, am I the sender of the message > received at the far end? The message can have the same body, > but will have a new envelope. For me, the entity that constructed the > envelope is the sender. This is why I don't have a problem with some > requrement for a forwarder to supply a new sender address. I think this is > a clarification. Others differ. I agree with the fact that the definitions are fuzzy. There are at least four different mail headers: "From", "Sender", "Reply-To" and "Return-Path" for this type of information. According to RFC 2822: "From" is "the author(s) of the message ... responsible for the writing of the message" "Sender" is "specifies the mailbox of the agent responsible for the actual transmission of the message" "Reply-To" "indicates the mailbox(es) to which the author of the message suggests that replies be sent" And "return path" is the error bounce address as stated in RFC 2821, section 4.4: "The primary purpose of the Return-path is to designate the address to which messages indicating non-delivery or other mail system failures are to be sent." My reading of the entire section 4.4 implies that the MAIL FROM parameter which the "Return-path" headers preserves as stated, is specifically for the purpose of the bounces. Yakov From owner-ietf-mxcomp Thu Mar 4 10:10:12 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i24IACdO055996; Thu, 4 Mar 2004 10:10:12 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i24IABUs055994; Thu, 4 Mar 2004 10:10:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i24IAAZA055966 for ; Thu, 4 Mar 2004 10:10:11 -0800 (PST) (envelope-from hadmut@danisch.de) Received: from andromeda (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i24IA7LO025112 for ietf-mxcomp@imc.org; Thu, 4 Mar 2004 19:10:07 +0100 Received: (from hadmut@localhost) by andromeda.dresden.danisch.de (8.12.10/8.12.10/Debian-5) id i24I941e017646 for ietf-mxcomp@imc.org; Thu, 4 Mar 2004 19:09:04 +0100 From: Hadmut Danisch Date: Thu, 4 Mar 2004 19:09:04 +0100 To: ietf-mxcomp@imc.org Subject: Simple Policy Control Protocol Message-ID: <20040304180904.GA17568@danisch.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, as a response to the BOF I received a hint to draft-hedberg-spocp-00.txt draft-hedberg-spocp-tcp-00.txt draft-hedberg-spocp-sexp-00.txt The last one might be the most interesting one. regards Hadmut From owner-ietf-mxcomp Thu Mar 4 10:15:23 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i24IFNNs057176; Thu, 4 Mar 2004 10:15: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 i24IFMoX057174; Thu, 4 Mar 2004 10:15:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.41]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i24IFLMl057168 for ; Thu, 4 Mar 2004 10:15:22 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.52] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1AyxNU-0004NI-00; Thu, 04 Mar 2004 13:15:24 -0500 Received: from [68.244.134.55] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1AyxNT-0004fO-00; Thu, 04 Mar 2004 13:15:24 -0500 Message-ID: <4047721E.3090006@solidmatrix.com> Date: Thu, 04 Mar 2004 13:14:54 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Hadmut Danisch CC: ietf-mxcomp@imc.org Subject: Re: Simple Policy Control Protocol References: <20040304180904.GA17568@danisch.de> In-Reply-To: <20040304180904.GA17568@danisch.de> X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hadmut Danisch wrote: > Hi, > > as a response to the BOF I received a hint > to > > draft-hedberg-spocp-00.txt > draft-hedberg-spocp-tcp-00.txt > draft-hedberg-spocp-sexp-00.txt > > The last one might be the most interesting one. > People also suggested to look at RESCAP, in particular these three drafts: draft-ietf-rescap-req-01.txt draft-ietf-rescap-scenarios-01.txt http://www.ietf.org/proceedings/03mar/I-D/draft-ietf-rescap-mua-00.txt Yakov From owner-ietf-mxcomp Thu Mar 4 10:27:13 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i24IRCw6057785; Thu, 4 Mar 2004 10:27: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 i24IRCio057784; Thu, 4 Mar 2004 10:27:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i24IRBcf057778 for ; Thu, 4 Mar 2004 10:27:11 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.11/) with ESMTP id i24IRFf9012703; Thu, 4 Mar 2004 10:27:15 -0800 (PST) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 4 Mar 2004 10:27:15 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Yakov Shafranovich'" , "Hallam-Baker, Phillip" Cc: "'Markus Stumpf'" , ietf-mxcomp@imc.org Subject: RE: Deficiencies in LMAP Date: Thu, 4 Mar 2004 10:27:12 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > How would you do that? Just state "IP xxxxx is a dynamic"? First, I am not just focused on the Spam issue. Important though that is I think we have to look to the general problem of trojaned machines, hackers etc. In my proposal I considered the following issues: 1) Is the IP address pooled, semi-static or entirely static? This is very important when dealing with a hacker. A DHCP address like my cable and DSL connections is static for weeks or months at a time. 2) The bandwidth available to the port. This does not need to be more than order of magnitude. If I am getting 1Mb/sec of data from an IP port listed as a 28.8K dialup I should probably consider the posibility of spoofing. 3) Is the port connected to the PSTN or other network gateway? An attack from a residential cable connection is almost certainly going to be a trojan. An attack from a dialup is more likely to connect to the perpetrator. 4) What is the accountability relationship? In the case of an enterprise that is managing their machines directly we have a direct accountability relationship. In many other cases such as an ISP or a university the relationship is indirect. 5) Is the address meant to be in service? 6) How to make contact in case of a security incident? From owner-ietf-mxcomp Thu Mar 4 10:31:39 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i24IVcEp058014; Thu, 4 Mar 2004 10:31: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 i24IVctL058013; Thu, 4 Mar 2004 10:31:38 -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.8) with ESMTP id i24IVXTB058003 for ; Thu, 4 Mar 2004 10:31:38 -0800 (PST) (envelope-from aland@newgiles.nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id CCF5816FDF for ; Thu, 4 Mar 2004 13:34:48 -0500 (EST) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Deficiencies in LMAP In-Reply-To: Your message of "Wed, 03 Mar 2004 17:05:25 CST." <700EEF5641B7E247AC1C9B82C05D125DA791@srv1.fecyk.ca> Date: Thu, 04 Mar 2004 13:34:48 -0500 Message-Id: <20040304183448.CCF5816FDF@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Gordon Fecyk" wrote: > > The idea is to (ab)use rDNS, and to publish LMAP records there, > > too. ... > > MTAMARK does this. Almost. MTAMARK publishes one piece of information: MTA, or not MTA. The LMAP variants publish more information. So it would be beneficial to publish LMAP information in rDNS. > Problem: Small ISPs and small to medium enterprises don't control rDNS. > North American ISPs are LAZY in this regard. [1] They won't use RFC 2317 and > in many cases won't bother changing PTR records for you, never mind add new > records to their rDNS zones. If they realize that doing so would result in less work and money spent fighting spam, they might change their behaviour. The problem is that this is a political/marketing problem, and one which we can't solve via technical means. We can design a perfect anti-spam system, and it may be useless in practice, because no one with the power to make a decision understands it, or cares. Alan DeKok. From owner-ietf-mxcomp Thu Mar 4 10:50:05 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i24Io5qR059031; Thu, 4 Mar 2004 10:50:05 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i24Io52x059030; Thu, 4 Mar 2004 10:50:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i24Io3it059021 for ; Thu, 4 Mar 2004 10:50:04 -0800 (PST) (envelope-from hadmut@danisch.de) Received: from andromeda (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i24Io6pS026567; Thu, 4 Mar 2004 19:50:06 +0100 Received: (from hadmut@localhost) by andromeda.dresden.danisch.de (8.12.10/8.12.10/Debian-5) id i24Ilems018012; Thu, 4 Mar 2004 19:47:40 +0100 From: Hadmut Danisch Date: Thu, 4 Mar 2004 19:47:40 +0100 To: Yakov Shafranovich Cc: ietf-mxcomp@imc.org Subject: Re: Simple Policy Control Protocol Message-ID: <20040304184740.GA17752@danisch.de> References: <20040304180904.GA17568@danisch.de> <4047721E.3090006@solidmatrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4047721E.3090006@solidmatrix.com> User-Agent: Mutt/1.5.5.1+cvs20040105i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Mar 04, 2004 at 01:14:54PM -0500, Yakov Shafranovich wrote: > http://www.ietf.org/proceedings/03mar/I-D/draft-ietf-rescap-mua-00.txt Hey, that's interesting as well. This and RMX++ would melt together quite well. regards Hadmut From owner-ietf-mxcomp Thu Mar 4 11:03:23 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i24J3NN2060042; Thu, 4 Mar 2004 11:03: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 i24J3NFF060041; Thu, 4 Mar 2004 11:03:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i24J3LSZ060035 for ; Thu, 4 Mar 2004 11:03:22 -0800 (PST) (envelope-from hadmut@danisch.de) Received: from andromeda (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i24J3P0x026907 for ietf-mxcomp@imc.org; Thu, 4 Mar 2004 20:03:25 +0100 Received: (from hadmut@localhost) by andromeda.dresden.danisch.de (8.12.10/8.12.10/Debian-5) id i24J3ATF018181 for ietf-mxcomp@imc.org; Thu, 4 Mar 2004 20:03:10 +0100 From: Hadmut Danisch Date: Thu, 4 Mar 2004 20:03:10 +0100 To: ietf-mxcomp@imc.org Subject: Giving it some structure Message-ID: <20040304190309.GA18051@danisch.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, I was thinking about a structure where the different proposals fit in an which allows to separate the differences. In common, we are playing the authorization game. Someone with some identity is trying to do something/make use of some resource. Is he allowed to do? - What kind of identity? How is it determined? How is authentication done? * All proposals so far use the IP address + most of them simply use the peer address of the running SMTP connection (getpeername()) + Microsoft CallerID proposes a method of delayed determination by analyzing Received-Lines in MUA. - Determining the resource/mail address for authorization: * Some use the HELO parameter * Some use the Envelope sender address * Some (MS CallerID) analyze the header - Localizing the authorization record/server * Most proposals have an implicit method to simply build the DNS suffix from the mail address domain part, e.g. _lmap.somedomain.... * RMX++ has an explicit DNS query step (A/SRV/opt. TXT) - Fetching the Auth Record / querying the Auth server * RMX, SPF, CallerID,... download authorization record from DNS * RMX++ downloads record from HTTP/HTTPS * RMX++ passes parameters up to the auth server. Those proposals mapping the sender's IP address into the DNS and look for existing A or TXT records can be considered as similar (= passing params as part of the query) - Encoding of the Auth Record/Statement * special RR Type (RMX) * TXT record * A, PTR, MX records * XML (MS CallerID, RMX++) * simple text, ASN.1,... (RMX++) * "Yes"/"No" (RMX++) - Nature of record/statement * static * dynamic * auth server side evaluation Please comment if anything is missing. regards Hadmut From owner-ietf-mxcomp Thu Mar 4 11:30:42 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i24JUgZV063076; Thu, 4 Mar 2004 11:30: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 i24JUgN8063075; Thu, 4 Mar 2004 11:30:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from moebius2.Space.Net (moebius2.Space.Net [195.30.1.100]) by above.proper.com (8.12.11/8.12.8) with SMTP id i24JUeee063069 for ; Thu, 4 Mar 2004 11:30:41 -0800 (PST) (envelope-from maex@Space.Net) Received: (qmail 18514 invoked by uid 1013); 4 Mar 2004 19:30:43 -0000 Date: Thu, 4 Mar 2004 20:30:43 +0100 From: Markus Stumpf To: Hadmut Danisch Cc: ietf-mxcomp@imc.org Subject: Re: Giving it some structure Message-ID: <20040304193043.GD13559@Space.Net> References: <20040304190309.GA18051@danisch.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040304190309.GA18051@danisch.de> User-Agent: Mutt/1.4.1i Organization: SpaceNet AG, Muenchen, Germany X-PGP-Fingerprint: 66 F3 75 79 01 D0 B8 5F 1A C7 77 88 4A B6 70 DF Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Mar 04, 2004 at 08:03:10PM +0100, Hadmut Danisch wrote: > Please comment if anything is missing. I don't know where this would fit exactly, but IMHO it would help a lot if we could also tighten some wordings in existing RFCs, like in RFC2821: 4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO) These commands are used to identify the SMTP client to the SMTP server. The argument field contains the fully-qualified domain name of the SMTP client if one is available. In situations in which the [ ... ] As it is now only about 10-20% of all SMTP connections have a HELO field that really contains any FQDN, most send nonsense like mailgate.haughton.com:62.49.147.138 HELO server.iaf.local smtp1.smartiq.com:209.218.85.79 HELO w2kbulksmtp01 unknown:62.251.186.34 HELO SERVEURW or even pa65.sliwice.sdi.tpnet.pl:217.97.113.65 HELO petste3 pa65.sliwice.sdi.tpnet.pl:217.97.113.65 HELO p.martich pa65.sliwice.sdi.tpnet.pl:217.97.113.65 HELO p.never Maybe a first step could be to make little updates to existing RFCs and rephrase sections like above to The argument field MUST contain the fully-qualified domain name of the SMTP client. Maybe also extending it to It MUST match the reverse DNS entry of the connecting IP address. So, with a lot of little, but easy and fast to walk steps we could prepare for the final proposal and goal we want to accomplish. We would also give people something to point at when they try to install some harder policies for MTAs connecting to their servers. It may be to high-piled a goal to try to accomplish all with one big step in a close timeframe. \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" From owner-ietf-mxcomp Fri Mar 5 10:40:52 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i25Ieq0t024107; Fri, 5 Mar 2004 10:40: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 i25IepgI024106; Fri, 5 Mar 2004 10:40:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.40]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i25IeoLM024100 for ; Fri, 5 Mar 2004 10:40:51 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.50] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1AzKFf-00079l-00 for ietf-mxcomp@imc.org; Fri, 05 Mar 2004 13:40:51 -0500 Received: from [68.244.181.67] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1AzKFe-0002Qz-00 for ietf-mxcomp@imc.org; Fri, 05 Mar 2004 13:40:51 -0500 Message-ID: <4048C9A8.9010303@solidmatrix.com> Date: Fri, 05 Mar 2004 13:40:40 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: ietf-mxcomp@imc.org Subject: [Fwd: [Asrg] videos of the IETF BoF] X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -------- Original Message -------- Subject: [Asrg] videos of the IETF BoF Date: Fri, 05 Mar 2004 09:57:03 -0600 From: wayne To: asrg@ietf.org Hi. There has been some discussion on the SPF-discuss mailing list about the recent BoF on anti-spam systems. I thought you folks might be interested in it also. For those that want to see this session, you can download an mpeg from: ftp://limestone.uoregon.edu/pub/videolab/video/ietf59/ietf59-ch1-thur-am_040304_0845_5.mpg Note that this mpeg is 1.2GB of nice high res pictures of people talking in stereo sound at 192kbps. I have created a smaller file (over a factor of 6 smaller) that has almost the same quality. The bad news is that this mpeg does not seem to run on Windows. It appears to work fine on Linux and *BSD using mplayer and xine, but no one has found any program to display it on Windows. I'm not a video geek and I know just enough about this stuff to be dangerous. :-< Sorry Windows people. If some kind person with a clue would help me out, or do the conversion themselves, that would be great. The Unix mpeg is available via bittorrent at: http://www.midwestcs.com/IETF_videos/ietf_marid.mpg.torrent I need bittorrent users to keep their torrents up, I can not provide that much bandwidth. BitTorrent plugins can ben found at: http://bitconjurer.org/BitTorrent/ There are rumors that this video works under Win2K using the Videolan client. http://www.videolan.org/vlc/ They have a MacOSX port to. I also suspect it will work fine under Mac OS X, with the mplayerOSX binaries. See: http://mplayerosx.sourceforge.net/ -wayne _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From owner-ietf-mxcomp Fri Mar 5 11:03:15 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i25J3Fwb025721; Fri, 5 Mar 2004 11:03: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 i25J3F8f025720; Fri, 5 Mar 2004 11:03:15 -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 (srv1.fecyk.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i25J3DFm025712 for ; Fri, 5 Mar 2004 11:03:14 -0800 (PST) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: [Fwd: [Asrg] videos of the IETF BoF] MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 5 Mar 2004 13:03:17 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA79B@srv1.fecyk.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: [Asrg] videos of the IETF BoF] Thread-Index: AcQC4cfuPdbGczjoSu6NtjhZ/RvVjgAApPhw From: "Gordon Fecyk" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i25J3EFm025715 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > There has been some discussion on the SPF-discuss mailing list about > the recent BoF on anti-spam systems. I can imagine that, given many of the comments expressed at the BOF. > ftp://limestone.uoregon.edu/pub/videolab/video/ietf59/ietf59-c > h1-thur-am_040304_0845_5.mpg Downloading now and will look at converting to WM9 or something low-bandwidth. -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Fri Mar 5 11:08:43 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i25J8hnZ025946; Fri, 5 Mar 2004 11:08: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 i25J8h7B025944; Fri, 5 Mar 2004 11:08:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.41]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i25J8gX6025938 for ; Fri, 5 Mar 2004 11:08:42 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.52] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1AzKge-0002fE-00; Fri, 05 Mar 2004 14:08:44 -0500 Received: from [68.244.181.67] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1AzKgc-0000dD-00; Fri, 05 Mar 2004 14:08:44 -0500 Message-ID: <4048D030.7080608@solidmatrix.com> Date: Fri, 05 Mar 2004 14:08:32 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Gordon Fecyk CC: ietf-mxcomp@imc.org Subject: Re: [Fwd: [Asrg] videos of the IETF BoF] References: <700EEF5641B7E247AC1C9B82C05D125DA79B@srv1.fecyk.ca> In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125DA79B@srv1.fecyk.ca> X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Gordon Fecyk wrote: >>ftp://limestone.uoregon.edu/pub/videolab/video/ietf59/ietf59-c >>h1-thur-am_040304_0845_5.mpg > > > Downloading now and will look at converting to WM9 or something > low-bandwidth. > If you can look into extracting the sound track alone and re-encoding it into a low-quality OGG or MP3 file that would help also. Yakov From owner-ietf-mxcomp Fri Mar 5 11:13:31 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i25JDVL8026116; Fri, 5 Mar 2004 11:13:31 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i25JDVH4026115; Fri, 5 Mar 2004 11:13:31 -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 (srv1.fecyk.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i25JDTS1026103 for ; Fri, 5 Mar 2004 11:13:30 -0800 (PST) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: [META] Replies to the list MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 5 Mar 2004 13:13:33 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA79F@srv1.fecyk.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [META] Replies to the list Thread-Index: AcQC5gQOKGaU1YUMTV61Vs9/E1qAyw== From: "Gordon Fecyk" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i25JDUS1026110 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: A lot of folks reply to both the sender and to the list when they want to send to the list. The usual thing to do is to hit "Reply to All". If that's going to be the norm for talking on this list, could we change the default reply-to setting in the list's properties? -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Fri Mar 5 16:43:38 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i260hcRR043614; Fri, 5 Mar 2004 16:43: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 i260hcvt043613; Fri, 5 Mar 2004 16:43:38 -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 (srv1.fecyk.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i260hato043606 for ; Fri, 5 Mar 2004 16:43:37 -0800 (PST) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: [Fwd: [Asrg] videos of the IETF BoF] MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 5 Mar 2004 18:43:42 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA7A9@srv1.fecyk.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: [Asrg] videos of the IETF BoF] Thread-Index: AcQC4cfuPdbGczjoSu6NtjhZ/RvVjgAL6VLA From: "Gordon Fecyk" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i260hbto043608 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > For those that want to see this session, you can download an > mpeg from: > > ftp://limestone.uoregon.edu/pub/videolab/video/ietf59/ietf59-c > h1-thur-am_040304_0845_5.mpg I have the audio from this recompressed as MP3 or Ogg. Grab them from the same place I put up my DMP slides: http://www.pan-am.ca/lmapbof/ My Copying indicator still says 57 minutes, as of when I posted this. So wait at least that long before trying to copy the files. The MP3 is 64 kb/sec mono. The OGG is 30 kb/sec mono. Oddly enough the Ogg file isn't that much smaller even though I specified less than half the bit-rate. Also, please MIRROR those audio files. I only have 320 kb/sec upstream. I am embarrassed at myself - that background noise at the beginning is me chastising someone for operating an unpatched Win2K laptop on the wireless LAN. And running some worm. The company that owns that unpatched laptop should be embarrassed by now, too. [1] [1] Hey ******* (company name deleted), I do desktop security work for C$30.00/hour and I do house calls. Yes, even to ****** (location deleted). :-) -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Sat Mar 6 11:06:57 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i26J6vnZ072952; Sat, 6 Mar 2004 11:06: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 i26J6uK3072951; Sat, 6 Mar 2004 11:06:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sender2.jprs.co.jp (sender2.nic.ad.jp [61.120.151.69]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i26J6t8i072942 for ; Sat, 6 Mar 2004 11:06:56 -0800 (PST) (envelope-from fujiwara@jprs.co.jp) Received: from alias.jprs.co.jp (alias.jprs.co.jp [192.168.102.41]) by sender2.jprs.co.jp (8.11.6/8.11.6) with ESMTP id i26IjbL29868 for ; Sun, 7 Mar 2004 03:45:37 +0900 Received: from unix01.jprs.co.jp (unix01.jprs.co.jp [192.168.118.11]) by alias.jprs.co.jp (8.11.7p1+Sun/8.11.7) with ESMTP id i26J67302973 for ; Sun, 7 Mar 2004 04:06:07 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by unix01.jprs.co.jp (8.11.6/8.11.6) with ESMTP id i26J66505050 for ; Sun, 7 Mar 2004 04:06:06 +0900 Date: Sun, 07 Mar 2004 04:06:06 +0900 (JST) Message-Id: <20040307.040606.41633892.fujiwara@jprs.co.jp> To: ietf-mxcomp@imc.org Subject: another protocol like sip From: fujiwara@jprs.co.jp X-Mailer: Mew version 4.0.64 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello, I'm Kazunori Fujiwara, JPRS. I was in MARID bof in Seoul, IETF59. I wondered why only smtp was considered in this BOF. (But I could not comment because my English problem.) Because I got many SPAM SIP calls. I set SIP resource record in DNS. and I made a presentation with this SIP URI as a example for ENUM in JAPAN. then, some person's mistake or DoS caused many SPAM calls. /* sorry, I'm SIP newbie. But current SIP implementations (or SIP protocol) have no protection mechanism without SIPS or IP address restriction, I think. */ So, I think we need rough protection mechanism for any protocols. My idea is - Service origin addresses is small number and finite. - SRV resource record is a good idea. /* MX RR may equal to _smtp._tcp.DOMAIN SRV 0 0 25 MXhost. */ - I propose SRVORIGIN resource record for any protocols. _smtp._tcp.DOMAIN IN SRVORIGIN hostname. hostname. IN A .... hostname. IN AAAA .... If we have 130 service origin IPv4 addresses, we write 10 SRVORIGIN RRs and each hostname has 13 A RRs. Is such idea OK? Regards, -- Fujiwara, Kazunori JPRS From owner-ietf-mxcomp Sat Mar 6 11:40:12 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i26JeCga075032; Sat, 6 Mar 2004 11:40:12 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i26JeCxB075031; Sat, 6 Mar 2004 11:40:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i26JeAXF075023 for ; Sat, 6 Mar 2004 11:40:11 -0800 (PST) (envelope-from hadmut@danisch.de) Received: from andromeda (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i26Je7PK019696; Sat, 6 Mar 2004 20:40:07 +0100 Received: (from hadmut@localhost) by andromeda.dresden.danisch.de (8.12.10/8.12.10/Debian-5) id i26JdBSL019507; Sat, 6 Mar 2004 20:39:11 +0100 From: Hadmut Danisch Date: Sat, 6 Mar 2004 20:39:11 +0100 To: fujiwara@jprs.co.jp Cc: ietf-mxcomp@imc.org Subject: Re: another protocol like sip Message-ID: <20040306193911.GA19475@danisch.de> References: <20040307.040606.41633892.fujiwara@jprs.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040307.040606.41633892.fujiwara@jprs.co.jp> User-Agent: Mutt/1.5.5.1+cvs20040105i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, On Sun, Mar 07, 2004 at 04:06:06AM +0900, fujiwara@jprs.co.jp wrote: > > Hello, I'm Kazunori Fujiwara, JPRS. > I was in MARID bof in Seoul, IETF59. > I wondered why only smtp was considered in this BOF. > (But I could not comment because my English problem.) > > Because I got many SPAM SIP calls. See http://www.ietf.org/internet-drafts/draft-danisch-scaf-00.txt a proposal to use those mechanism as a general caller authorization scheme. regards Hadmut From owner-ietf-mxcomp Sat Mar 6 17:54:03 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i271s3Uw093985; Sat, 6 Mar 2004 17:54: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 i271s3Yf093984; Sat, 6 Mar 2004 17:54:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.40]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i271s1aE093977 for ; Sat, 6 Mar 2004 17:54:02 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.50] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1AznUQ-0006lj-00; Sat, 06 Mar 2004 20:54:02 -0500 Received: from [68.244.154.14] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1AznUP-0003Md-00; Sat, 06 Mar 2004 20:54:02 -0500 Message-ID: <404A80B0.7080309@solidmatrix.com> Date: Sat, 06 Mar 2004 20:53:52 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: fujiwara@jprs.co.jp CC: ietf-mxcomp@imc.org Subject: Re: another protocol like sip References: <20040307.040606.41633892.fujiwara@jprs.co.jp> In-Reply-To: <20040307.040606.41633892.fujiwara@jprs.co.jp> X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: fujiwara@jprs.co.jp wrote: > Hello, I'm Kazunori Fujiwara, JPRS. > I was in MARID bof in Seoul, IETF59. > I wondered why only smtp was considered in this BOF. > (But I could not comment because my English problem.) > > Because I got many SPAM SIP calls. > I set SIP resource record in DNS. > and I made a presentation > with this SIP URI as a example for ENUM in JAPAN. > then, some person's mistake or DoS caused many SPAM calls. > Can you provide some more information on this? What kind of call were they? Did they have an origin number? Were they recorded or computer generated? > /* > sorry, I'm SIP newbie. > But current SIP implementations (or SIP protocol) have no protection > mechanism without SIPS or IP address restriction, I think. > */ > > So, I think we need rough protection mechanism for any protocols. > > My idea is > > - Service origin addresses is small number and finite. > - SRV resource record is a good idea. > /* MX RR may equal to _smtp._tcp.DOMAIN SRV 0 0 25 MXhost. */ > > - I propose SRVORIGIN resource record for any protocols. > > _smtp._tcp.DOMAIN IN SRVORIGIN hostname. > hostname. IN A .... > hostname. IN AAAA .... > > If we have 130 service origin IPv4 addresses, > we write 10 SRVORIGIN RRs and each hostname has 13 A RRs. > > Is such idea OK? I am not a SIP expert, but you might want to run this by the SIP groups also. Yakov From owner-ietf-mxcomp Mon Mar 8 20:15:24 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i294FOTg027538; Mon, 8 Mar 2004 20:15: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 i294FOwo027537; Mon, 8 Mar 2004 20:15:24 -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 (srv1.fecyk.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i294FLQ8027529 for ; Mon, 8 Mar 2004 20:15:23 -0800 (PST) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: Everyone back from Seoul yet? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 8 Mar 2004 22:15:27 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA7AF@srv1.fecyk.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Everyone back from Seoul yet? Thread-Index: AcQFjTnrawZ3cqxjSNuNFzxyBVKgLw== 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 i294FOQ8027532 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'm anxious to get started. So where to go from here? -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Tue Mar 9 05:04:26 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i29D4Q0Z032556; Tue, 9 Mar 2004 05:04: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 i29D4Q5M032555; Tue, 9 Mar 2004 05:04:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i29D4O7u032548 for ; Tue, 9 Mar 2004 05:04:25 -0800 (PST) (envelope-from paf@cisco.com) Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 09 Mar 2004 05:12:59 +0000 Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i29D3mgA022679; Tue, 9 Mar 2004 14:03:51 +0100 (MET) Received: from xfe-lon-301.cisco.com ([64.103.98.17]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 9 Mar 2004 13:04:17 +0000 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-lon-301.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 9 Mar 2004 13:04:11 +0000 In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125DA7AF@srv1.fecyk.ca> References: <700EEF5641B7E247AC1C9B82C05D125DA7AF@srv1.fecyk.ca> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "IETF MXCOMP (E-mail)" From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: Everyone back from Seoul yet? Date: Tue, 9 Mar 2004 21:02:11 +0800 To: "Gordon Fecyk" X-Mailer: Apple Mail (2.612) X-OriginalArrivalTime: 09 Mar 2004 13:04:17.0147 (UTC) FILETIME=[0747CCB0:01C405D7] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2004-03-09, at 12.15, Gordon Fecyk wrote: > I'm anxious to get started. > > So where to go from here? Unfortunately I am not back before March 14. paf From owner-ietf-mxcomp Tue Mar 9 10:04:58 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i29I4wYH054391; Tue, 9 Mar 2004 10:04: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 i29I4w46054390; Tue, 9 Mar 2004 10:04:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i29I4vVl054384 for ; Tue, 9 Mar 2004 10:04:57 -0800 (PST) (envelope-from hardie@qualcomm.com) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i29I4wvf012429; Tue, 9 Mar 2004 10:04:58 -0800 (PST) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i29I4tVK027453; Tue, 9 Mar 2004 10:04:56 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125DA7AF@srv1.fecyk.ca> References: <700EEF5641B7E247AC1C9B82C05D125DA7AF@srv1.fecyk.ca> Date: Tue, 9 Mar 2004 10:04:53 -0800 To: "Gordon Fecyk" , "IETF MXCOMP (E-mail)" From: Ted Hardie Subject: Re: Everyone back from Seoul yet? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 10:15 PM -0600 03/08/2004, Gordon Fecyk wrote: >I'm anxious to get started. > >So where to go from here? I'm currently working on a charter, based on the BoF; the charter is focused on a single deliverable: Develop an MTA authorization DNS resource record to signal to peer MTAs that an MTA is authorized to send mail. *Don't Wait* for a charter, though; please continue to work on the ideas that were discussed. There are a couple key issues that need to be hashed out, and having agreement (or at least good discussion) now will be a good thing for keeping the speed up as we move forward. I'd say the broad question is "What are the semantics that this record needs to convey" and the first key question is "What *identity* is it that needs to be authorized". Don't get too caught up in how to represent that set of semantics in the DNS, or even how that identity is represented in SMTP--get the semantics agreed to and the other details will fall out pretty easily. I hope to have a charter before the IESG at the March 18th teleconference, just to give a first milestone--but again, *don't wait* on the charter. thanks and regards, Ted From owner-ietf-mxcomp Tue Mar 9 10:30:11 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i29IUBKq056266; Tue, 9 Mar 2004 10:30: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 i29IUBGr056265; Tue, 9 Mar 2004 10:30:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i29IU9uH056250 for ; Tue, 9 Mar 2004 10:30:10 -0800 (PST) (envelope-from hadmut@danisch.de) Received: from andromeda (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i29IU6ha005163 for ietf-mxcomp@imc.org; Tue, 9 Mar 2004 19:30:06 +0100 Received: (from hadmut@localhost) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-3) id i29IRnB2006382 for ietf-mxcomp@imc.org; Tue, 9 Mar 2004 19:27:49 +0100 From: Hadmut Danisch Date: Tue, 9 Mar 2004 19:27:49 +0100 To: ietf-mxcomp@imc.org Subject: Re: Everyone back from Seoul yet? Message-ID: <20040309182749.GA6319@danisch.de> References: <700EEF5641B7E247AC1C9B82C05D125DA7AF@srv1.fecyk.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1+cvs20040105i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Mar 09, 2004 at 10:04:53AM -0800, Ted Hardie wrote: > "What *identity* is it that needs to be authorized". At a first glance I thought pretty good question. At a second glance I thought ambiguous question (or maybe my english is not good enough). What does *identity* mean? Whom to authorize or the mail address someone needs to be authorized to use? In case of the "whom": - IPv4 address of SMTP peer - IPv6 address of SMTP peer - Any IPv4 wrap into IPv6 address? - Certificate contents if SMTP over TLS? - Phone number when using mobile in connect mode - MAC address? - Cryptographic challenge-response? regards Hadmut From owner-ietf-mxcomp Tue Mar 9 10:43:01 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i29Ih07O056960; Tue, 9 Mar 2004 10:43: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 i29Ih02S056959; Tue, 9 Mar 2004 10:43:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from scale01.mcom.com (h-64-236-139-249.aoltw.net [64.236.139.249]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i29Ih0u7056941 for ; Tue, 9 Mar 2004 10:43:00 -0800 (PST) (envelope-from aoki@aol.net) Received: from aol.net ([10.169.158.59]) by scale01.nscp.aoltw.net (Netscape Messaging Server 6.1 (built Oct 3 2002)) with ESMTP id <0HUB00A6QNYLX8@scale01.nscp.aoltw.net> for ietf-mxcomp@imc.org; Tue, 09 Mar 2004 10:42:21 -0800 (PST) Date: Tue, 09 Mar 2004 10:43:01 -0800 From: Edwin Aoki Subject: Re: Everyone back from Seoul yet? In-reply-to: <20040309182749.GA6319@danisch.de> To: Hadmut Danisch Cc: ietf-mxcomp@imc.org Message-id: <404E1035.3010007@aol.net> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031007 References: <700EEF5641B7E247AC1C9B82C05D125DA7AF@srv1.fecyk.ca> <20040309182749.GA6319@danisch.de> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I think that the proposals listed below are a good stab at the question of how one derives the identity, but I think it still skips the step of what the specific identity is that needs to be authorized. Given the proposed scope of this group - to verify that an MTA is authorized to send mail - the identity we need to validate would seem to be that of the sending MTA. Depending on which of the approaches we take, once we obtain the identity of the sending MTA, we can make additional assertsions: - The MTA with this identity is authorized to send mail (of any sort) - The MTA with this identity is authorized to send mail on behalf of users at a specified domain But this latter choice would seem to be more of a policy question rather than the identity question. -Edwin Aoki -Chief Architect, America Online Hadmut Danisch wrote: >On Tue, Mar 09, 2004 at 10:04:53AM -0800, Ted Hardie wrote: > > > >>"What *identity* is it that needs to be authorized". >> >> > >At a first glance I thought pretty good question. > >At a second glance I thought ambiguous question (or maybe my >english is not good enough). > >What does *identity* mean? Whom to authorize or the mail address >someone needs to be authorized to use? > > > >In case of the "whom": > >- IPv4 address of SMTP peer >- IPv6 address of SMTP peer >- Any IPv4 wrap into IPv6 address? >- Certificate contents if SMTP over TLS? >- Phone number when using mobile in connect mode >- MAC address? >- Cryptographic challenge-response? > > >regards >Hadmut > > > From owner-ietf-mxcomp Tue Mar 9 10:44:44 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i29IiiJe057151; Tue, 9 Mar 2004 10:44: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 i29IiisE057150; Tue, 9 Mar 2004 10:44:44 -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.8) with ESMTP id i29Iiglv057142 for ; Tue, 9 Mar 2004 10:44:44 -0800 (PST) (envelope-from aland@newgiles.nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id F0A1816FDF for ; Tue, 9 Mar 2004 13:48:01 -0500 (EST) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Everyone back from Seoul yet? In-Reply-To: Your message of "Tue, 09 Mar 2004 10:04:53 PST." Date: Tue, 09 Mar 2004 13:48:01 -0500 Message-Id: <20040309184801.F0A1816FDF@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ted Hardie wrote: > I'd say the broad question is "What are the semantics that this record > needs to convey" and the first key question is "What *identity* is it > that needs to be authorized". Would the LMAP discussion document be acceptable as a WG item? It's a start at this process, and contains a summary of nearly a year of dicussion on this topic. Alan DeKok. From owner-ietf-mxcomp Tue Mar 9 11:17:22 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i29JHMSn059506; Tue, 9 Mar 2004 11:17: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 i29JHMjR059505; Tue, 9 Mar 2004 11:17: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.8) with ESMTP id i29JHDv4059473 for ; Tue, 9 Mar 2004 11:17:13 -0800 (PST) (envelope-from aland@newgiles.nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 3CEAD170BB for ; Tue, 9 Mar 2004 14:20:43 -0500 (EST) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: What semantics are conveyed (was Re: Everyone back from Seoul yet? ) In-Reply-To: Your message of "Tue, 09 Mar 2004 10:04:53 PST." Date: Tue, 09 Mar 2004 14:20:43 -0500 Message-Id: <20040309192043.3CEAD170BB@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: (replying again, with a little more background) Ted Hardie wrote: > I'd say the broad question is "What are the semantics that this record > needs to convey" and the first key question is "What *identity* is it > that needs to be authorized". From the LMAP discussion document: http://www.ietf.org/internet-drafts/draft-irtf-asrg-lmap-discussion-00.txt To answer what identity is it that needs to be authorized: #--- LMAP is based on two concepts: publication of authentication data by a domain, and application of that data by a recipient MTA. The combination of these concepts permits SMTP recipients to establish more reliably whether mail putatively from a domain is actually from that domain and that there is a responsible contact in case of questions or problems with the domain's mail. The data published by a domain includes statements as to which IP's are permitted to originate mail from the domain in SMTP EHLO/HELO and MAIL FROM. #--- The identity which needs to be authorized is an MTAs self-proclaimed association with a domain. That is, the MTA is claiming that it has an identity which is rooted in a domain. We can therefore ask the domain if that statement is true. If the identity appears to be valid, then we can assume that the claim of identity is true, and that MTA is authorized to claim that relationship. I believe that the LMAP discussion document would be appropriate as a WG item, because it summarises many of the issues surrounding the proposed authorization process. These issues should be documented as part of the WG process, but the issues are independent of the technical specification of the protocols, or the syntax of the records. Instead, the document explains in detail why the protocol choice was made, and it's benefits and limitations. I'm prepared to update the document to address any WG concerns, and to submit it for consideration as a WG item. Alan DeKok. From owner-ietf-mxcomp Tue Mar 9 11:20:06 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i29JK6MC059799; Tue, 9 Mar 2004 11:20: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 i29JK6FY059798; Tue, 9 Mar 2004 11:20:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i29JK5Fm059792 for ; Tue, 9 Mar 2004 11:20:05 -0800 (PST) (envelope-from hadmut@danisch.de) Received: from andromeda (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i29JK6M0006421; Tue, 9 Mar 2004 20:20:06 +0100 Received: (from hadmut@localhost) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-3) id i29JJmvF006657; Tue, 9 Mar 2004 20:19:48 +0100 From: Hadmut Danisch Date: Tue, 9 Mar 2004 20:19:48 +0100 To: Edwin Aoki Cc: ietf-mxcomp@imc.org Subject: Re: Everyone back from Seoul yet? Message-ID: <20040309191948.GA6554@danisch.de> References: <700EEF5641B7E247AC1C9B82C05D125DA7AF@srv1.fecyk.ca> <20040309182749.GA6319@danisch.de> <404E1035.3010007@aol.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <404E1035.3010007@aol.net> User-Agent: Mutt/1.5.5.1+cvs20040105i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Mar 09, 2004 at 10:43:01AM -0800, Edwin Aoki wrote: > I think that the proposals listed below are a good stab at the question > of how one derives the identity, but I think it still skips the step of > what the specific identity is that needs to be authorized. Given the > proposed scope of this group - to verify that an MTA is authorized to > send mail - the identity we need to validate would seem to be that of > the sending MTA. Yeah, but the reason is not the scope of this group, it's a matter of designing security protocols. If you want to do message based security, you can use digital signatures. If you want to do communication based security, you need to authorize and thus identify whom you are talking with, which is always an interactive step. As long as you limit the scope to a single SMTP connection only (in contrast to sending a cookie in a prior e-mail), the sending MTA is currently the only one you can interactively talk with (here: TCP seq number). You simply have no option than authorizing the sending MTA (if you don't want to redesign mail transfer). regards Hadmut From owner-ietf-mxcomp Tue Mar 9 11:25:06 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i29JP68b060138; Tue, 9 Mar 2004 11:25: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 i29JP6qg060137; Tue, 9 Mar 2004 11:25:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i29JP41H060131 for ; Tue, 9 Mar 2004 11:25:05 -0800 (PST) (envelope-from hadmut@danisch.de) Received: from andromeda (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i29JP7DU006549; Tue, 9 Mar 2004 20:25:07 +0100 Received: (from hadmut@localhost) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-3) id i29JMQ6Y006699; Tue, 9 Mar 2004 20:22:26 +0100 From: Hadmut Danisch Date: Tue, 9 Mar 2004 20:22:26 +0100 To: =?iso-8859-1?B?WuFtYm9yaSwgWm9sdOFu?= Cc: ietf-mxcomp@imc.org Subject: Re: Everyone back from Seoul yet? Message-ID: <20040309192226.GB6554@danisch.de> References: <700EEF5641B7E247AC1C9B82C05D125DA7AF@srv1.fecyk.ca> <20040309182749.GA6319@danisch.de> <404E166B.5080308@axelero.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <404E166B.5080308@axelero.hu> User-Agent: Mutt/1.5.5.1+cvs20040105i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Mar 09, 2004 at 08:09:31PM +0100, "Zámbori, Zoltán" wrote: > Hadmut Danisch wrote: > >- IPv4 address of SMTP peer > > I think IP+time would be better because of dial-up addresses. Good point. Should we authorize during the open SMTP connection only or also delayed (e.g. like in Microsoft's CallerID)? regards Hadmut From owner-ietf-mxcomp Tue Mar 9 11:35:05 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i29JZ5Wt061435; Tue, 9 Mar 2004 11:35:05 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i29JZ5Um061434; Tue, 9 Mar 2004 11:35:05 -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 (srv1.fecyk.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i29JZ44o061428 for ; Tue, 9 Mar 2004 11:35:04 -0800 (PST) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: Everyone back from Seoul yet? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 9 Mar 2004 13:35:07 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA7B0@srv1.fecyk.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Everyone back from Seoul yet? Thread-Index: AcQGBLeBPj9eX/rYR5WwGEkJ+Gf1uAABpicA From: "Gordon Fecyk" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i29JZ54o061429 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > "What *identity* is it that needs to be authorized". > > At a first glance I thought pretty good question. > > At a second glance I thought ambiguous question (or maybe my > english is not good enough). First off I understood the problem statement was about authentication, not authorization. There's a difference: authentication is who you are or who you represent, authorization is what you're allowed to do. In SMTP I'd still want everyone to be allowed to send me mail, I just want to know who they are or who they represent first. This is a simplified explanation but it works. I like the KISS principle myself. It was enough for me to know who they represent (the domain) as I can complain to, or refuse mail from, who they represent. > What does *identity* mean? 1. identity, personal identity, individuality -- the distinct personality of an individual regarded as a persisting entity; "you can lose your identity when you join the army" 2. identity -- the individual characteristics by which a thing or person is recognized or known; "geneticists only recently discovered the identity of the gene that causes it"; "it was too dark to determine his identity"; "she guessed the identity of his lover" 3. identity, identity element, identity operator -- an operator that leaves unchanged the element on which it operates; "the identity under numerical multiplication is 1" 4. identity, identicalness, indistinguishability -- exact sameness; "they shared an identity of interests" I guess I'm interested in the 4th definition, an identity of interests (in this case the domain represents the interest). It simplifies the problem. > In case of the "whom": > > - IPv4 address of SMTP peer > - IPv6 address of SMTP peer > - Any IPv4 wrap into IPv6 address? > - Certificate contents if SMTP over TLS? > - Phone number when using mobile in connect mode > - MAC address? All of these could be associated with whom the sender represents (the domain), and in some cases be associated with the sender directly. Some of the proposals dealt with authenticating the sender directly, as well as or instead of whom the sender represents. The only problem I have with this is spammers can use this to obtain valid e-mail addresses, much like address-mining through rapid RCPT TO: commands and stripping the 5xx responses. This is why many mailers will now accept all mail for their domain on a RCPT TO and send a NDR after the fact. I think authenticating the domain only avoids this problem for the same reason. > - Cryptographic challenge-response? I won't go there - patented, for one thing. -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Tue Mar 9 11:42:34 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i29JgYNv061903; Tue, 9 Mar 2004 11: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 i29JgYsI061902; Tue, 9 Mar 2004 11:42:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i29JgWsH061895 for ; Tue, 9 Mar 2004 11:42:33 -0800 (PST) (envelope-from hadmut@danisch.de) Received: from andromeda (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i29Jgave006959; Tue, 9 Mar 2004 20:42:36 +0100 Received: (from hadmut@localhost) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-3) id i29JgQ96006903; Tue, 9 Mar 2004 20:42:26 +0100 From: Hadmut Danisch Date: Tue, 9 Mar 2004 20:42:26 +0100 To: Gordon Fecyk Cc: ietf-mxcomp@imc.org Subject: Re: Everyone back from Seoul yet? Message-ID: <20040309194226.GA6890@danisch.de> References: <700EEF5641B7E247AC1C9B82C05D125DA7B0@srv1.fecyk.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125DA7B0@srv1.fecyk.ca> User-Agent: Mutt/1.5.5.1+cvs20040105i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Mar 09, 2004 at 01:35:07PM -0600, Gordon Fecyk wrote: > > > > "What *identity* is it that needs to be authorized". > > First off I understood the problem statement was about authentication, not > authorization. There's a difference: authentication is who you are or who > you represent, authorization is what you're allowed to do. In SMTP I'd still > want everyone to be allowed to send me mail, I just want to know who they are > or who they represent first. Exactly, authentication is about who you are (here: IP address), and authorization is what you're allowed to do (here: use e-mail address). But many people use "identity" for the e-mail address. So my question was whether he was talking about the IP address or the e-mail address when talking about "identity". regards Hadmut From owner-ietf-mxcomp Tue Mar 9 11:51:53 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i29Jprth062331; Tue, 9 Mar 2004 11:51: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 i29JpqDq062330; Tue, 9 Mar 2004 11:51:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from scale01.mcom.com (h-64-236-139-249.aoltw.net [64.236.139.249]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i29Jpq73062319 for ; Tue, 9 Mar 2004 11:51:52 -0800 (PST) (envelope-from aoki@aol.net) Received: from aol.net ([10.169.158.59]) by scale01.nscp.aoltw.net (Netscape Messaging Server 6.1 (built Oct 3 2002)) with ESMTP id <0HUB00A91R5FX8@scale01.nscp.aoltw.net> for ietf-mxcomp@imc.org; Tue, 09 Mar 2004 11:51:15 -0800 (PST) Date: Tue, 09 Mar 2004 11:51:55 -0800 From: Edwin Aoki Subject: Re: Everyone back from Seoul yet? In-reply-to: <20040309194226.GA6890@danisch.de> To: Hadmut Danisch Cc: Gordon Fecyk , ietf-mxcomp@imc.org Message-id: <404E205B.2070901@aol.net> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031007 References: <700EEF5641B7E247AC1C9B82C05D125DA7B0@srv1.fecyk.ca> <20040309194226.GA6890@danisch.de> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I don't believe the scope of this working group covers individual identity, although some of the proposals within it do cover the notion of domain identity (e.g., domain name, not IP address). That's why I believe that there is a single identity (the IP address), that can map to one or more policies. Policies that soley list which IP addresses are authorized to send mail need worry only about the identity which is the sending MTA's email address. Policies which go a step further and try to assert that mail from a given IP address is being sent on behalf of a particular domain need to worry about two pieces of information: the identity for authentication (IP address) and an identity for authorization (that IP address' mapping to a domain contained within the sender's email address). Of course in this scenario, this in turn leads to the question of which email address you're referring to: envelope address, From line, etc, Cheers, -Edwin Aoki -Chief Architect, America Online Hadmut Danisch wrote: >On Tue, Mar 09, 2004 at 01:35:07PM -0600, Gordon Fecyk wrote: > > >>>>"What *identity* is it that needs to be authorized". >>>> >>>> >>First off I understood the problem statement was about authentication, not >>authorization. There's a difference: authentication is who you are or who >>you represent, authorization is what you're allowed to do. In SMTP I'd still >>want everyone to be allowed to send me mail, I just want to know who they are >>or who they represent first. >> >> > > > >Exactly, authentication is about who you are (here: IP address), >and authorization is what you're allowed to do (here: use e-mail >address). > >But many people use "identity" for the e-mail address. > >So my question was whether he was talking about the IP address >or the e-mail address when talking about "identity". > >regards >Hadmut > > > From owner-ietf-mxcomp Tue Mar 9 12:08:25 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i29K8PkN063138; Tue, 9 Mar 2004 12:08: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 i29K8Plm063137; Tue, 9 Mar 2004 12:08:25 -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 (srv1.fecyk.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i29K8Oo2063131 for ; Tue, 9 Mar 2004 12:08:25 -0800 (PST) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: Everyone back from Seoul yet? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 9 Mar 2004 14:08:28 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA7B2@srv1.fecyk.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Everyone back from Seoul yet? Thread-Index: AcQGDq7g5/tStfAFRuCZdQz51Dz+AgAACM7g From: "Gordon Fecyk" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i29K8Po2063132 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Exactly, authentication is about who you are ... > But many people use "identity" for the e-mail address. > > So my question was whether he was talking about the IP address > or the e-mail address when talking about "identity". I believe we're talking about the e-mail address when we talk about identity. It's the most visible and identifiable item. The existing proposals use records in a de-centralized database to verify a portion or all of this identity. We happen to use the message envelope's e-mail address (MAIL FROM) so we have a chance to refuse the message without receiving all of it. The records themselves can reference IP addresses, MAC addresses, certificates, phone numbers or anything else that could be stored in the database. It just happens the IP address is one of the most readily available bits of information to reference. There are others. As for using DNS vs other databases, I just think if DNS is already being used (if we look at a database server by name, we're using DNS) we should bypass the middleman and save some bandwidth. Other databases could work, ie: LDAP, and still be de-centralized (each domain running their own LDAP server - and many do even if they don't know it). There's another whole argument over how vulnerabilities in DNS could affect any other database system referenced by name just as easily as DNS itself, but that's not in scope here. -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Tue Mar 9 14:34:20 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i29MYJrm073017; Tue, 9 Mar 2004 14:34: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 i29MYJq6073016; Tue, 9 Mar 2004 14:34:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from moebius2.Space.Net (moebius2.Space.Net [195.30.1.100]) by above.proper.com (8.12.11/8.12.8) with SMTP id i29MYGoR072966 for ; Tue, 9 Mar 2004 14:34:18 -0800 (PST) (envelope-from maex@Space.Net) Received: (qmail 92874 invoked by uid 1013); 9 Mar 2004 22:34:11 -0000 Date: Tue, 9 Mar 2004 23:34:11 +0100 From: Markus Stumpf To: ietf-mxcomp@imc.org Subject: Re: Everyone back from Seoul yet? Message-ID: <20040309223411.GG63765@Space.Net> References: <700EEF5641B7E247AC1C9B82C05D125DA7B2@srv1.fecyk.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125DA7B2@srv1.fecyk.ca> User-Agent: Mutt/1.4.1i Organization: SpaceNet AG, Muenchen, Germany X-PGP-Fingerprint: 66 F3 75 79 01 D0 B8 5F 1A C7 77 88 4A B6 70 DF Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Mar 09, 2004 at 02:08:28PM -0600, Gordon Fecyk wrote: > I believe we're talking about the e-mail address when we talk about identity. > It's the most visible and identifiable item. The correctness of eMail addresses is identified with things like PGP/GPG. Not even SPF or RMX(++) identifies addresses, but the domain that is associated with a sending MTA and that is only part of the email address. Identifying eMail addresses (even more with DNS) is a large hole as it would require to have a list of valid email addresses in DNS in a form that a receiving MTA could validate them and that would make these lists target to e.g. dictionary attacks helping the spammers to clean up and fill up their lists. > Other databases could work, > ie: LDAP, and still be de-centralized (each domain running their own LDAP > server - and many do even if they don't know it). But they don't run it publicly accessible (as least those who know what they are doing) and they have reasons for it - see above. \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" From owner-ietf-mxcomp Tue Mar 9 14:48:08 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i29Mm8an074141; Tue, 9 Mar 2004 14:48: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 i29Mm8Jq074140; Tue, 9 Mar 2004 14:48:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from moebius2.Space.Net (moebius2.Space.Net [195.30.1.100]) by above.proper.com (8.12.11/8.12.8) with SMTP id i29Mm6aX074132 for ; Tue, 9 Mar 2004 14:48:07 -0800 (PST) (envelope-from maex@Space.Net) Received: (qmail 93403 invoked by uid 1013); 9 Mar 2004 22:48:11 -0000 Date: Tue, 9 Mar 2004 23:48:11 +0100 From: Markus Stumpf To: ietf-mxcomp@imc.org Subject: Re: Everyone back from Seoul yet? Message-ID: <20040309224811.GH63765@Space.Net> References: <700EEF5641B7E247AC1C9B82C05D125DA7AF@srv1.fecyk.ca> <20040309182749.GA6319@danisch.de> <404E1035.3010007@aol.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <404E1035.3010007@aol.net> User-Agent: Mutt/1.4.1i Organization: SpaceNet AG, Muenchen, Germany X-PGP-Fingerprint: 66 F3 75 79 01 D0 B8 5F 1A C7 77 88 4A B6 70 DF Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Mar 09, 2004 at 10:43:01AM -0800, Edwin Aoki wrote: > - The MTA with this identity is authorized to send mail on behalf of > users at a specified domain If we want this kind of information widely deployed it has to be EASY to be added. I'd take any bet that only a really small percentage of our customers will be able to add correct XYZ records to their domains even with help from our tech support: - what do you mean with IP address? www.example.com is mine I think - I am using a lot of dialin providers and their mailservers, I don't know the IP addesses/names these mailservers use to the outside. While these may be ok for those who are able to add XYZ records, because they will be protected it makes it worse for those without XYZ records and if we don't reach a critical mass of supporters nobody will implement/use it aka "it is useless because only n precent of incoming emails are from domains that have XYZ records at all". \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" From owner-ietf-mxcomp Tue Mar 9 15:20:04 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i29NK4DI076438; Tue, 9 Mar 2004 15:20: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 i29NK4d1076437; Tue, 9 Mar 2004 15:20:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i29NK39d076431 for ; Tue, 9 Mar 2004 15:20:03 -0800 (PST) (envelope-from hadmut@danisch.de) Received: from andromeda (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i29NK6Kv012851; Wed, 10 Mar 2004 00:20:06 +0100 Received: (from hadmut@localhost) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-3) id i29NFH0t008348; Wed, 10 Mar 2004 00:15:17 +0100 From: Hadmut Danisch Date: Wed, 10 Mar 2004 00:15:17 +0100 To: Gordon Fecyk Cc: ietf-mxcomp@imc.org Subject: Re: Everyone back from Seoul yet? Message-ID: <20040309231517.GA8331@danisch.de> References: <700EEF5641B7E247AC1C9B82C05D125DA7B2@srv1.fecyk.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125DA7B2@srv1.fecyk.ca> User-Agent: Mutt/1.5.5.1+cvs20040105i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Mar 09, 2004 at 02:08:28PM -0600, Gordon Fecyk wrote: > > > But many people use "identity" for the e-mail address. > > > > So my question was whether he was talking about the IP address > > or the e-mail address when talking about "identity". > > I believe we're talking about the e-mail address when we talk about identity. > It's the most visible and identifiable item. That's exactly the confusion I was trying to point out. >From a security point of view the IP address is the identity. The e-mail address is the ressource to grant access to based on authorization. regards Hadmut From owner-ietf-mxcomp Tue Mar 9 18:46:34 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2A2kYoA088442; Tue, 9 Mar 2004 18:46: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 i2A2kYJu088441; Tue, 9 Mar 2004 18:46:34 -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 (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2A2kWF0088431 for ; Tue, 9 Mar 2004 18:46:33 -0800 (PST) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.30) id 1B0tjx-0005hh-M2; Tue, 09 Mar 2004 20:46:37 -0600 To: "Alan DeKok" Cc: ietf-mxcomp@imc.org Subject: Re: What semantics are conveyed References: <20040309192043.3CEAD170BB@mail.nitros9.org> From: wayne Content-Type: text/plain; charset=US-ASCII Date: Tue, 09 Mar 2004 20:46:37 -0600 In-Reply-To: <20040309192043.3CEAD170BB@mail.nitros9.org> (Alan DeKok's message of "Tue, 09 Mar 2004 14:20:43 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (spfd: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <20040309192043.3CEAD170BB@mail.nitros9.org> "Alan DeKok" writes: > Ted Hardie wrote: >> I'd say the broad question is "What are the semantics that this record >> needs to convey" and the first key question is "What *identity* is it >> that needs to be authorized". > > From the LMAP discussion document: > > http://www.ietf.org/internet-drafts/draft-irtf-asrg-lmap-discussion-00.txt > > [snip] > > I believe that the LMAP discussion document would be appropriate as > a WG item, because it summarises many of the issues surrounding the > proposed authorization process. These issues should be documented as > part of the WG process, but the issues are independent of the > technical specification of the protocols, or the syntax of the > records. Instead, the document explains in detail why the protocol > choice was made, and it's benefits and limitations. It has been several months since I last heavily skimmed any of the LMAP drafts, but tonight I sat down and read it. I like it. I think it *does* do a good job of summarizing much of the discussions that have taken place on various mailing lists (ASRG, SPF-discuss, SPAM-L, NANAE, etc.) I think it provides a good common base for people to work from. I do *not* agree with all that is said in it, but most of those points are things that I think that reasonable people can disagree on. The one major objection I had to what was said in the LMAP document is all the vague references to "changing semantics". I don't see how any of the LMAP proposals seriously change any semantics, and this phrase seems to have been latched onto and blown out of proportion by various people. (Mostly people I don't recognize being involved discussions on SPAM-L, NANAE, ASRG, SPF-discuss, etc.) What the LMAP systems generally do is give the owners of something (domain name, IP space) a voice. They can say "I authorize/don't authorize the following IP addresses to do send email using the domain I own or IP space I control." These LMAP proposals then give email receivers an easy way to listen to what the domain/ip-space owners are saying. Giving a voice does not change the semantics of anything. The HELO string/MAIL FROM/From:/whatever still means whatever it is that you think it means. You many not be able to do everything you used to be able to do when domain/ip-space owners had no voice, but such is life. -wayne From owner-ietf-mxcomp Tue Mar 9 19:10:02 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2A3A2sP090044; Tue, 9 Mar 2004 19:10: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 i2A3A2FP090043; Tue, 9 Mar 2004 19:10:02 -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 (srv1.fecyk.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2A3A1kB090036 for ; Tue, 9 Mar 2004 19:10:02 -0800 (PST) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: Everyone back from Seoul yet? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 9 Mar 2004 21:10:08 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA7B4@srv1.fecyk.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Everyone back from Seoul yet? Thread-Index: AcQGKMt82/l6P0pkQJ2Jd81kldaB/AAIu+iA From: "Gordon Fecyk" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2A3A2kB090037 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > I'd take any bet that only a really small percentage of our > customers will > be able to add correct XYZ records to their domains even with > help from our tech support: > - what do you mean with IP address? www.example.com is mine I think I'd like to think said customer needs a clue about who really owns domain names. But aside from that, the ISP could demonstrate some actual customer service and take care of this for them.[1] Ie: "Dear customer, please put 'mail.example.com' in your mail program and use these other settings[2] like our documentation says." The ISP can handle everything else on the back end.[3] > - I am using a lot of dialin providers and their mailservers, I don't > know the IP addesses/names these mailservers use to the outside. Isn't this what AUTH, SUBMIT, Webmail, and so on are about? Maybe not AUTH because some ISPs block or redirect SMTP to their own servers, but SUBMIT (SMTP on a different port) addresses this, or if not SUBMIT, just SMTP AUTH on port 587(?). This is also an ISP customer service problem. [1] My understanding is Internet Provider Customer Service is in short supply. This is a rant I'll leave for another forum. [2] Port number and AUTH settings exist in modern mail programs, even modern versions of old mail programs like Eudora. I can enable this functionality on my domain and that of my clients' with only a few mouse clicks - no config files. [3] I can demonstrate using pan-am.ca if you wish. -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Tue Mar 9 19:10:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2A3AWgi090072; Tue, 9 Mar 2004 19:10: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 i2A3AWFo090071; Tue, 9 Mar 2004 19:10:32 -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 (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2A3AVrd090065 for ; Tue, 9 Mar 2004 19:10:31 -0800 (PST) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.30) id 1B0u7C-0005xt-BO for ietf-mxcomp@imc.org; Tue, 09 Mar 2004 21:10:38 -0600 To: "IETF MXCOMP (E-mail)" Subject: Re: Everyone back from Seoul yet? References: <700EEF5641B7E247AC1C9B82C05D125DA7AF@srv1.fecyk.ca> From: wayne Content-Type: text/plain; charset=US-ASCII Date: Tue, 09 Mar 2004 21:10:37 -0600 In-Reply-To: (Ted Hardie's message of "Tue, 9 Mar 2004 10:04:53 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (spfd: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In Ted Hardie writes: > I'm currently working on a charter, based on the BoF; the charter > is focused on a single deliverable: Develop an MTA authorization DNS > resource record > to signal to peer MTAs that an MTA is authorized to send mail. I may be reading more than I should into what Ted has said here, but I am concerned about this. First, I don't think there is going to be a "single deliverable". There are several identities that need to be authenticated and/or authorized. These different identities have different properties and need different methods to solve the problem. I think it is likely that there will need to be completely separate proposals for: 1) The "is this IP address authorized to be an MTA?" question. (e.g., MTA-Mark, SS, DUL lists, etc.) 2) The "is this IP address authorized to use a given domain name in the MAIL FROM (and HELO) address?" (e.g. RMX, SPF, DMP, etc.) 3) The "is this From: header from who it claims to be from?" (GPG, S/MIME, DomainKeys, Caller-ID, etc.) There may well be more related problems to solve, and some of these may be subdivided. Is there going to be a more detailed description of what is going to be done here? In particular, I think a list of "requirements"/"should haves"/"it would be nice ifs" can be fairly quickly drawn up for each of those three areas. Doing so would likely make the process go much faster. > *Don't Wait* for a charter, though; please continue to work on the > ideas that were discussed. I understand this, but it somewhat bothers me that it appears that we will be going back to square one and ignoring the discussions that have taken place elsewhere, and what has been learned by actual deployment of actual systems. If you are planning to open everything up again for discussion, expect things to take a very long time to come to a rough consensus. One of the comments that Ted made at the opening to the BOF was something along the lines of "can the IETF put together something useful in a timeframe that is needed?" I think this is a *very* important point. The IETF is coming into this very late and runs the risk of producing an irrelevant document if it moves too slowly. Both Yahoo and MicroSoft are already well along on their *development* and *testing* tracks for their proposals and they are large enough to make an impact on the email world all by themselves. SPF is rapidly approaching 10,000 published domains on their adoption roll and there are probably 100,000-500,000 domains that have SPF records. (Most of these are parked domains, but that still means that SPF is blocking spam claiming to be from these bogus domains.) > I'd say the broad question is "What are the semantics that this record > needs to convey" and the first key question is "What *identity* is it > that needs to be authorized". To be honest, I think those questions are well answered in the LMAP document. While I could see a review of the contents of the LMAP document for people who aren't as familiar with the subject, I think this review should be brief. -wayne From owner-ietf-mxcomp Tue Mar 9 19:41:49 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2A3fnYc091609; Tue, 9 Mar 2004 19:41: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 i2A3fnTn091608; Tue, 9 Mar 2004 19:41:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (mail.winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2A3fmhQ091602 for ; Tue, 9 Mar 2004 19:41:48 -0800 (PST) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v5.7.450.9b13) for ietf-mxcomp@imc.org; Tue, 09 Mar 2004 22:43:50 -0500 Received: from ([68.215.115.72]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v5.7.450.9b13) with SMTP id 3342800406; Tue, 09 Mar 2004 22:43:49 -0500 Message-ID: <00c201c40651$ac9acbc0$6401a8c0@hdev1> From: "Hector Santos" To: Cc: "Alan DeKok" Subject: LMAP Validation Analysis Date: Tue, 9 Mar 2004 22:41:59 -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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Alan, I did this analysis awhile back when I first started to add some of the various LMAP-based proposals in our smtp server. I just finished up the document. I think it may help show how LMAP and dynamic vs. post RCPT validations plays a key role in LMAP results and usage. "The Association of the Sender IP and SMTP Envelope Domains: LMAP Validation and Trust Analysis" http://www.winserver.com/public/antispam/lmap/draft-lmapanalysis1.htm -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp Tue Mar 9 19:50:05 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2A3o5i3091958; Tue, 9 Mar 2004 19:50:05 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2A3o5dk091957; Tue, 9 Mar 2004 19:50:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (ntbbs.winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2A3nxSp091947 for ; Tue, 9 Mar 2004 19:50:00 -0800 (PST) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v5.7.450.9b13) for ietf-mxcomp@imc.org; Tue, 09 Mar 2004 22:52:05 -0500 Received: from ([68.215.115.72]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v5.7.450.9b13) with SMTP id 3343295843; Tue, 09 Mar 2004 22:52:04 -0500 Message-ID: <00d201c40652$d3edf9d0$6401a8c0@hdev1> From: "Hector Santos" To: Cc: "Alan DeKok" References: <00c201c40651$ac9acbc0$6401a8c0@hdev1> Subject: Re: LMAP Validation Analysis Date: Tue, 9 Mar 2004 22:50: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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I forgot to add that I would like comments and input, review of the tables, missing conditions, flaw logic, explanations, etc. It is a draft document and hopefully, in the end, if deemed useful, it can be used by new LMAP implementators to understand better the envelope entities relationships. Thanks -- Hector Santos, Santronics Software, Inc. http://www.santronics.com ----- Original Message ----- From: "Hector Santos" To: Cc: "Alan DeKok" Sent: Tuesday, March 09, 2004 10:41 PM Subject: LMAP Validation Analysis > > Alan, > > I did this analysis awhile back when I first started to add some of the > various LMAP-based proposals in our smtp server. I just finished up the > document. I think it may help show how LMAP and dynamic vs. post RCPT > validations plays a key role in LMAP results and usage. > > "The Association of the Sender IP and SMTP Envelope Domains: > LMAP Validation and Trust Analysis" > > http://www.winserver.com/public/antispam/lmap/draft-lmapanalysis1.htm > > -- > Hector Santos, Santronics Software, Inc. > http://www.santronics.com > > > > From owner-ietf-mxcomp Tue Mar 9 20:15:47 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2A4Fl3i093017; Tue, 9 Mar 2004 20:15: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 i2A4FlCY093016; Tue, 9 Mar 2004 20:15:47 -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 (srv1.fecyk.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2A4FkCE093010 for ; Tue, 9 Mar 2004 20:15:46 -0800 (PST) (envelope-from gordonf@pan-am.ca) Received: from gordshome ([142.161.168.175] RDNS failed) by mail.pan-am.ca over TLS secured channel with Microsoft SMTPSVC(5.0.2195.6713); Tue, 9 Mar 2004 22:15:52 -0600 Message-ID: <000801c40656$7411bc50$6601a8c0@gordshome> From: "Gordon Fecyk" To: "IETF MXCOMP \(E-mail\)" References: <700EEF5641B7E247AC1C9B82C05D125DA7AF@srv1.fecyk.ca> Subject: Re: Not ignoring previous research Date: Tue, 9 Mar 2004 22:16:25 -0600 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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 10 Mar 2004 04:15:52.0476 (UTC) FILETIME=[603CADC0:01C40656] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > *Don't Wait* for a charter, though; please continue to work on the > > ideas that were discussed. > > I understand this, but it somewhat bothers me that it appears that we > will be going back to square one and ignoring the discussions that > have taken place elsewhere, and what has been learned by actual > deployment of actual systems. Looks like that's going to happen because there were strong objections to the semantics of each approach. But ignoring the research already completed is a mistake, indeed. I, for one, am interested in inventing [1] a new DNS record type and DNS record class to replace the abuse of TXT records and hard-wired name spaces, respectively, while keeping the concepts of DMP in tact as long as those concepts aren't way off base. [1] "Stealing" was the word used at the BOF, but it was a DNS WG member's idea. Speaking of which, any DNS WG members present? -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Tue Mar 9 21:33:30 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2A5XU62097136; Tue, 9 Mar 2004 21:33: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 i2A5XUHZ097135; Tue, 9 Mar 2004 21:33:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.41]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2A5XRSb097125 for ; Tue, 9 Mar 2004 21:33:28 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.52] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1B0wLE-0000da-00; Wed, 10 Mar 2004 00:33:16 -0500 Received: from [68.244.154.76] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1B0wLC-0002qV-00; Wed, 10 Mar 2004 00:33:16 -0500 Message-ID: <404EA88F.4080403@solidmatrix.com> Date: Wed, 10 Mar 2004 00:33:03 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: wayne CC: Alan DeKok , ietf-mxcomp@imc.org Subject: Re: What semantics are conveyed References: <20040309192043.3CEAD170BB@mail.nitros9.org> In-Reply-To: X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: wayne wrote: > > The one major objection I had to what was said in the LMAP document is > all the vague references to "changing semantics". I don't see how any > of the LMAP proposals seriously change any semantics, and this phrase > seems to have been latched onto and blown out of proportion by various > people. (Mostly people I don't recognize being involved discussions > on SPAM-L, NANAE, ASRG, SPF-discuss, etc.) > I believe that your refering to the following quotes: Section 1: "This document contains minor updates to the semantics of parts of RFC 2821" Section 1.1: " These proposals change the semantics of the MAIL FROM command as defined in RFC 2821, section 3.3. to imply that the domain in the source mailbox is also the responsible party for sending the message, and thus must be verified. " Section 3.1: "LMAP does not change SMTP, except for changing the semantics of the mailbox used in MAIL FROM command." I suggested to add those comments originally based on something Pete Resnick brought up. In particular, I am basing this on section 4.4 of RFC 2821: " The primary purpose of the Return-path is to designate the address to which messages indicating non-delivery or other mail system failures are to be sent. " Yakov From owner-ietf-mxcomp Wed Mar 10 03:41:59 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2ABfxoi091295; Wed, 10 Mar 2004 03:41:59 -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 i2ABfxDe091294; Wed, 10 Mar 2004 03:41:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from argon.connect.org.uk (argon.connectinternetsolutions.com [193.110.243.33]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2ABfv31091288 for ; Wed, 10 Mar 2004 03:41:58 -0800 (PST) (envelope-from jrk@merseymail.com) Received: from mmail by argon.connect.org.uk with local (connectmail/exim) id 1B1260-0004Rd-P6; Wed, 10 Mar 2004 11:41:56 +0000 Subject: Re: What semantics are conveyed To: "wayne" From: "Jon Kyme" Cc: "Alan DeKok" , X-Mailer: [ConnectMail 3.13.0] X-connectmail-Originating-IP: 172.25.243.3 Message-Id: Date: Wed, 10 Mar 2004 11:41:56 +0000 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > The one major objection I had to what was said in the LMAP document is > all the vague references to "changing semantics". I don't see how any > of the LMAP proposals seriously change any semantics, and this phrase > seems to have been latched onto and blown out of proportion by various > people. (Mostly people I don't recognize being involved discussions > on SPAM-L, NANAE, ASRG, SPF-discuss, etc.) > There are those who hold that MAIL FROM data is sender identification (claiming support from RFCs 2821, 821, 788). There seems to be a school of thought that holds that *use* of MAIL FROM data for anything other than (more than) return-path is a change of semantics. Some adherents hold that the RFCs are just plain wrong. There's a pragmatic position - "I can, and am going to, use MAIL FROM data as a basis for policy enforcement. So live with it." If you can characterise other camps that I've missed, I'd be interested to hear. -- He who is determined not to be satisfied with anything short of perfection will never do any-thing to please himself or others. William Hazlitt (1778-1830) From owner-ietf-mxcomp Wed Mar 10 04:22:37 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2ACMbMV093765; Wed, 10 Mar 2004 04:22: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 i2ACMbrt093764; Wed, 10 Mar 2004 04:22:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [208.210.125.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2ACMZsl093753 for ; Wed, 10 Mar 2004 04:22:36 -0800 (PST) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [208.210.125.24]) by emerald.pobox.com (Postfix) with ESMTP id ECFFA132CFC for ; Wed, 10 Mar 2004 07:22:30 -0500 (EST) Received: by dumbo.pobox.com (Postfix, from userid 505) id BCD7B716; Wed, 10 Mar 2004 07:22:30 -0500 (EST) Date: Wed, 10 Mar 2004 07:22:30 -0500 From: Meng Weng Wong To: "IETF MXCOMP (E-mail)" Subject: Three major areas of concentration Message-ID: <20040310122230.GA8016@dumbo.pobox.com> References: <700EEF5641B7E247AC1C9B82C05D125DA7AF@srv1.fecyk.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Mar 09, 2004 at 09:10:37PM -0600, wayne wrote: | | I think it is likely that there will need to be completely separate | proposals for: | | 1) The "is this IP address authorized to be an MTA?" question. | (e.g., MTA-Mark, SS, DUL lists, etc.) | | 2) The "is this IP address authorized to use a given domain name in | the MAIL FROM (and HELO) address?" (e.g. RMX, SPF, DMP, etc.) | | 3) The "is this From: header from who it claims to be from?" (GPG, | S/MIME, DomainKeys, Caller-ID, etc.) I agree that these are three related but distinct areas; each deserves consideration. (1) has one dimension: is an IP address allowed to send mail? (2) has two dimensions: is an IP address allowed to send mail *for a given domain?* I prepared two documents for the Seoul BOF in which I tried to emphasize the distinction between (1) and (2) above. http://dumbo.pobox.com/~mengwong/tmp/comparisons/buildyourown.png http://dumbo.pobox.com/~mengwong/tmp/comparisons/familytree.png This little diagram may help illustrate the differences visually. http://dumbo.pobox.com/~mengwong/tmp/comparisons/2dimensions.gif Today, DNSBLs filter along the IP dimension only. In the future, with wide deployment of an SPF-like system, I hope that accreditation and reputation services can help filter on the second dimension as well. cheers meng From owner-ietf-mxcomp Wed Mar 10 04:41:01 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2ACf11r094397; Wed, 10 Mar 2004 04:41:01 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2ACf1UK094396; Wed, 10 Mar 2004 04:41:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.41]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2ACf0t7094389 for ; Wed, 10 Mar 2004 04:41:00 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.50] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1B130u-0005wR-00; Wed, 10 Mar 2004 07:40:44 -0500 Received: from [68.244.223.82] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1B130s-0000XC-00; Wed, 10 Mar 2004 07:40:44 -0500 Message-ID: <404F0CBF.2060100@solidmatrix.com> Date: Wed, 10 Mar 2004 07:40:31 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Jon Kyme CC: wayne , Alan DeKok , ietf-mxcomp@imc.org Subject: Re: What semantics are conveyed References: In-Reply-To: X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Kyme wrote: >>The one major objection I had to what was said in the LMAP document is >>all the vague references to "changing semantics". I don't see how any >>of the LMAP proposals seriously change any semantics, and this phrase >>seems to have been latched onto and blown out of proportion by various >>people. (Mostly people I don't recognize being involved discussions >>on SPAM-L, NANAE, ASRG, SPF-discuss, etc.) >> > > > There are those who hold that MAIL FROM data is sender identification > (claiming support from RFCs 2821, 821, 788). > > There seems to be a school of thought that holds that *use* of > MAIL FROM data for anything other than (more than) return-path is a change > of semantics. Some adherents hold that the RFCs are just plain wrong. > > There's a pragmatic position - "I can, and am going to, use MAIL FROM data > as a basis for policy enforcement. So live with it." > > If you can characterise other camps that I've missed, I'd be interested to > hear. > I think that the important point is, no matter which school you belong to, with the existing proposals (except Caller ID), the data in the MAIL FROM command becomes tied in to the domain data. You can either look at it as a way to identify the sender, or as a way to give the domain owners ability to consent for their domain to be used as bounce address in MAIL FROM; BUT either way it will become verifiable unless some other way is proposed to pass the information. It is also important to note, that there are two different parts to all proposals: publishing the data and using the data. Yakov From owner-ietf-mxcomp Wed Mar 10 05:07:14 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2AD7El8095924; Wed, 10 Mar 2004 05:07: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 i2AD7ETx095923; Wed, 10 Mar 2004 05:07:14 -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 (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2AD7D1L095916 for ; Wed, 10 Mar 2004 05:07:13 -0800 (PST) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.30) id 1B13QZ-0001o0-6k for ietf-mxcomp@imc.org; Wed, 10 Mar 2004 07:07:15 -0600 To: ietf-mxcomp@imc.org Subject: Re: What semantics are conveyed References: <20040309192043.3CEAD170BB@mail.nitros9.org> <404EA88F.4080403@solidmatrix.com> From: wayne Content-Type: text/plain; charset=US-ASCII Date: Wed, 10 Mar 2004 07:07:14 -0600 In-Reply-To: <404EA88F.4080403@solidmatrix.com> (Yakov Shafranovich's message of "Wed, 10 Mar 2004 00:33:03 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (spfd: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <404EA88F.4080403@solidmatrix.com> Yakov Shafranovich writes: > wayne wrote: > >> The one major objection I had to what was said in the LMAP document >> is all the vague references to "changing semantics". I don't see >> how any of the LMAP proposals seriously change any semantics, and >> this phrase seems to have been latched onto and blown out of >> proportion by various people. > > I believe that your refering to the following quotes: > > [snip] yes. > I suggested to add those comments originally based on something Pete > Resnick brought up. In particular, I am basing this on section 4.4 of > RFC 2821: > > " The primary purpose of the Return-path is to designate the address to > which messages indicating non-delivery or other mail system failures > are to be sent. > " I still don't see a change in semantics of the return-path. The primary purpose remains as the location to send DSNs. In addition, as Hector Santos recently pointed out on the SPF-discuss mailing list, section 3.3 of RFC is quite relevant: 3.3 Mail Transactions [snip] The first step in the procedure is the MAIL command. MAIL FROM: [SP ] [...] The portion of the first or only argument contains the source mailbox (between "<" and ">" brackets), which can be used to report errors (see section 4.2 for a discussion of error reporting). If accepted, the SMTP server returns a 250 OK reply. If the mailbox specification is not acceptable for some reason, the server MUST return a reply indicating whether the failure is permanent (i.e., will occur again if the client tries to send the same address again) or temporary (i.e., the address might be accepted if the client tries again later). Despite the apparent scope of this requirement, there are circumstances in which the acceptability of the reverse-path may not be determined until one or more forward-paths (in RCPT commands) can be examined. In those cases, the server MAY reasonably accept the reverse-path (with a 250 reply) and then report problems after the forward-paths are received and examined. Normally, failures produce 550 or 553 replies. This is quite clear that the reverse-path can be validated and rejected if the receiving MTA doesn't like it. Validating the envelope-from via callbacks has been around for years and has been used by a non-trivial number of MTAs. Again, any "changed semantics" is both minor and irrelevant. -wayne From owner-ietf-mxcomp Wed Mar 10 05:33:46 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2ADXkrK097014; Wed, 10 Mar 2004 05:33: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 i2ADXkgT097013; Wed, 10 Mar 2004 05:33:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.41]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2ADXjbJ097007 for ; Wed, 10 Mar 2004 05:33:45 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.52] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1B13qD-0000du-00; Wed, 10 Mar 2004 08:33:45 -0500 Received: from [68.244.223.82] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1B13qB-000233-00; Wed, 10 Mar 2004 08:33:45 -0500 Message-ID: <404F1928.7010707@solidmatrix.com> Date: Wed, 10 Mar 2004 08:33:28 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: wayne CC: ietf-mxcomp@imc.org Subject: Re: What semantics are conveyed References: <20040309192043.3CEAD170BB@mail.nitros9.org> <404EA88F.4080403@solidmatrix.com> In-Reply-To: X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: wayne wrote: > > Again, any "changed semantics" is both minor and irrelevant. > While I agree with this statement I still feel that this fact was worthwhile to have been mentioned so anyone who thinks that the semantics are being changed, knows that we are aware of his opinion. Yakov From owner-ietf-mxcomp Wed Mar 10 07:39:15 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2AFdENl006057; Wed, 10 Mar 2004 07:39: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 i2AFdEwI006056; Wed, 10 Mar 2004 07:39:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from moebius2.Space.Net (moebius2.Space.Net [195.30.1.100]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2AFdDqN006041 for ; Wed, 10 Mar 2004 07:39:13 -0800 (PST) (envelope-from maex@Space.Net) Received: (qmail 8450 invoked by uid 1013); 10 Mar 2004 15:39:08 -0000 Date: Wed, 10 Mar 2004 16:39:08 +0100 From: Markus Stumpf To: Meng Weng Wong Cc: "IETF MXCOMP \(E-mail\)" Subject: Re: Three major areas of concentration Message-ID: <20040310153908.GK63765@Space.Net> References: <700EEF5641B7E247AC1C9B82C05D125DA7AF@srv1.fecyk.ca> <20040310122230.GA8016@dumbo.pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040310122230.GA8016@dumbo.pobox.com> User-Agent: Mutt/1.4.1i Organization: SpaceNet AG, Muenchen, Germany X-PGP-Fingerprint: 66 F3 75 79 01 D0 B8 5F 1A C7 77 88 4A B6 70 DF Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Mar 10, 2004 at 07:22:30AM -0500, Meng Weng Wong wrote: > (1) has one dimension: is an IP address allowed to send mail? Sorry, but not really. IMHO it is important to understand that at least MTAMARK does not talk about allowing something. It is about giving an admin a chance to provide hints about an IP address. In the case of roaming users, local (to the user) mailservers it is very important that the IP is still allowed to send mail even if it is labelled as "not running a public mailserver". However some additional authorization/authentification may be required (e.g. SMTP AUTH). > (2) has two dimensions: is an IP address allowed to send mail *for a > given domain?* > > I prepared two documents for the Seoul BOF in which I tried to emphasize > the distinction between (1) and (2) above. > > http://dumbo.pobox.com/~mengwong/tmp/comparisons/buildyourown.png Hmmm ... in-addr is not a record type, it is a zone, "in-addr.arpa". MTAMRK populates this zone with TXT records. In an earlier proposal we used TXT records acccording to RFC1464 like 8.0.30.195.in-addr.arpa. IN TXT "ASRG.MTA=yes" 1.0.30.195.in-addr.arpa. IN TXT "ASRG.MTA=no" However this has the big disadvantage (like it is now again used by John in the SS proposal) that you have to parse the TXT records, which provides for a lot of errors like not ignoring case mixed or whitespace problems like in "ASRG.mta = No". Another disadvantage is that you have to single out the record you are looking for amongst a lot of others that could be present also having the pitfall of the 512 byte packet size. That's why we chose (after some great talk to Arnt Gulbrandsen, thanks!) to change it to _perm._smtp._srv.8.0.30.195.in-addr.arpa. IN TXT "1" With my initial statement about giving a hint and leaving it up to receiving MTA the keyword "_perm" (derived from permission) is unluckily chosen and should be replaced by something more appropriate like e.g. "_mta". Now one can have a specific query and will receive one answer which is easy to parse, i.e. "1" or "0". > http://dumbo.pobox.com/~mengwong/tmp/comparisons/familytree.png This is a great overview, thanks. \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" From owner-ietf-mxcomp Wed Mar 10 08:09:10 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2AG9AP8007862; Wed, 10 Mar 2004 08: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 i2AG9AXu007861; Wed, 10 Mar 2004 08:09:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from moebius2.Space.Net (moebius2.Space.Net [195.30.1.100]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2AG98bU007855 for ; Wed, 10 Mar 2004 08:09:09 -0800 (PST) (envelope-from maex@Space.Net) Received: (qmail 43852 invoked by uid 1013); 10 Mar 2004 16:09:10 -0000 Date: Wed, 10 Mar 2004 17:09:10 +0100 From: Markus Stumpf To: ietf-mxcomp@imc.org Subject: Re: Everyone back from Seoul yet? Message-ID: <20040310160910.GL63765@Space.Net> References: <700EEF5641B7E247AC1C9B82C05D125DA7B4@srv1.fecyk.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125DA7B4@srv1.fecyk.ca> User-Agent: Mutt/1.4.1i Organization: SpaceNet AG, Muenchen, Germany X-PGP-Fingerprint: 66 F3 75 79 01 D0 B8 5F 1A C7 77 88 4A B6 70 DF Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Mar 09, 2004 at 09:10:08PM -0600, Gordon Fecyk wrote: > I'd like to think said customer needs a clue about who really owns domain > names. But aside from that, the ISP could demonstrate some actual customer > service and take care of this for them.[1] Ie: "Dear customer, please put > 'mail.example.com' in your mail program and use these other settings[2] like > our documentation says." The ISP can handle everything else on the back > end.[3] Surely there is /a/ solution. But this is mainly a 2822-From vs. 2821-MAIL issue. Most users (and IMHO quite some browsers) do not really support setting this explicitely and to different values. And even if they do e.g. roaming users want to use their business address and set it in 2822-From. But if they use local ISPs address in the 2821-MAIL they probably never get anything like errors, as they will not check their boxes. We have customers that have the mailbox for 5-6 years and they use it to send email via SMTP AUTH for quite some time but they do not check their box any longer (which they did "by "accident" when they used SMTP after POP). We use SMTP AUTH but we do not change e.g. envelopes, so if a user can SMTP AUTH as "joe@example.com" he still can use "jack@example.net" as an envelope sender. > [1] My understanding is Internet Provider Customer Service is in short > supply. This is a rant I'll leave for another forum. Win margings in the ISP business are quite small. And giving 2 hours of telephone support to a customers that pays about 1 USD per month for DNS service for his domain simply doesn't pay out, but the vast majority of customers are not willing to pay more. In Germany we have some major hosters that provide Webspace and domains for 0.99 EUR per month and that maintain (like they say) more than 1 million domains. Business customers with leased lines are /not/ the problem. This is from the last hostcount from RIPE: CY SOA COUNTED DUPL REAL CHANGE ============================================================== de 3942843 14609703 12006696 2603007 78711 Background information and more statistics are available at http://www.ripe.net/hostcount/ The number of "joe-user.de" domains is outnumbering the business domains by far and most of them simply have their domain because it is as cheap as 1 EUR/month. Some just know enough about the Internet to connect and start their preferred chat system (and the configuration was done by a friend of a friend). Trying to help them set up something like SPF is simply without any chance. \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" From owner-ietf-mxcomp Wed Mar 10 08:13:30 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2AGDTth008509; Wed, 10 Mar 2004 08:13: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 i2AGDTJh008508; Wed, 10 Mar 2004 08:13:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [208.210.125.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2AGDSud008467 for ; Wed, 10 Mar 2004 08:13:29 -0800 (PST) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [208.210.125.24]) by emerald.pobox.com (Postfix) with ESMTP id 7CA4C132CF9; Wed, 10 Mar 2004 11:13:29 -0500 (EST) Received: by dumbo.pobox.com (Postfix, from userid 505) id 60D705C1; Wed, 10 Mar 2004 11:13:29 -0500 (EST) Date: Wed, 10 Mar 2004 11:13:29 -0500 From: Meng Weng Wong To: Markus Stumpf Cc: ietf-mxcomp@imc.org Subject: Re: Everyone back from Seoul yet? Message-ID: <20040310161329.GB8016@dumbo.pobox.com> References: <700EEF5641B7E247AC1C9B82C05D125DA7B4@srv1.fecyk.ca> <20040310160910.GL63765@Space.Net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040310160910.GL63765@Space.Net> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Mar 10, 2004 at 05:09:10PM +0100, Markus Stumpf wrote: | The number of "joe-user.de" domains is outnumbering the business domains | by far and most of them simply have their domain because it is as cheap | as 1 EUR/month. Some just know enough about the Internet to connect | and start their preferred chat system (and the configuration was done | by a friend of a friend). Trying to help them set up something like SPF | is simply without any chance. In economic terms, I see this part of the war on spam as an inevitable cost-shifting from the antispam community to other sectors of the Net. Ultimately it may be more efficient for these vanity domain owners to pay 2 EUR/month instead of 1 EUR/month if that means that the rest of the Internet can stop spending an estimated $1,000,000,000 per year on fighting spam. From owner-ietf-mxcomp Wed Mar 10 08:48:09 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2AGm9KO010421; Wed, 10 Mar 2004 08:48:09 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2AGm9l7010420; Wed, 10 Mar 2004 08:48:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2AGlwo9010399 for ; Wed, 10 Mar 2004 08:48:00 -0800 (PST) (envelope-from aland@newgiles.nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 41A2216D00 for ; Wed, 10 Mar 2004 11:51:26 -0500 (EST) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: What semantics are conveyed In-Reply-To: Your message of "Wed, 10 Mar 2004 00:33:03 EST." <404EA88F.4080403@solidmatrix.com> Date: Wed, 10 Mar 2004 11:51:26 -0500 Message-Id: <20040310165126.41A2216D00@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Yakov Shafranovich wrote: > I believe that your refering to the following quotes: > > Section 1: > "This document contains minor updates to the semantics of parts of RFC 2821" Which is not the same as the original text in that section of the document. I specifically chose to say it does NOT change the semantics of RFC 2821, because I truly believe it does not. (Subject to certain caveats.) > Section 1.1: > " These proposals change the semantics of the MAIL FROM command > as defined in RFC 2821, section 3.3. to imply that the domain > in the source mailbox is also the responsible party for > sending the message, and thus must be verified. > " This text is wrong. See the rest of the LMAP discussion document for explanations why. A better phrasing is: "... the recipient MAY CHOOSE to ask the domain in the source mailbox if they accept responsibility for the message. If the domain does not accept responsibility, then no bounce path exists, and by other recommendations of RFC 2821 [ref], the message should not be delivered." > I suggested to add those comments originally based on something Pete > Resnick brought up. In particular, I am basing this on section 4.4 > of RFC 2821: > > " The primary purpose of the Return-path is to designate the address to > which messages indicating non-delivery or other mail system failures > are to be sent. > " So we have some choices: a) ignore any secondary purposes of the Return-path, which appear to be permitted by the above text b) Add secondary purposes to the Return-path c) Pretend that SMTP was handed down by god and is written in stone, and that as mere mortals, there's nothing we can do to change it d) Realize that people wrote SMTP, and people can change SMTP. It's nice that SMTP is implemented and widely deployed, but if it's time to change it, then let's talk about changing it. The Internet has changed, and RFC 2821 hasn't. People are abusing the flaws of RFC 2821 to send spam. So let's stop pretending it's perfect, and just fix it. Refusing to address the issues in SMTP because of appeals to dated standards is a cop-out. As for Section 4.4 of RFC 2821, the fact that I rejected a message as spam would appear to fall into the "mail system failures" category. I determined that you failed to satisfy my criteria for accepting messages. If I can't bounce the message back to you, then I should never have accepted it in the first place. Alan DeKok. From owner-ietf-mxcomp Wed Mar 10 09:28:14 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2AHSELH012647; Wed, 10 Mar 2004 09:28: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 i2AHSEFG012646; Wed, 10 Mar 2004 09:28:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2AHSDVn012640 for ; Wed, 10 Mar 2004 09:28:13 -0800 (PST) (envelope-from aland@newgiles.nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 4355616D00 for ; Wed, 10 Mar 2004 12:31:44 -0500 (EST) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: What semantics are conveyed In-Reply-To: Your message of "Tue, 09 Mar 2004 20:46:37 CST." Date: Wed, 10 Mar 2004 12:31:44 -0500 Message-Id: <20040310173144.4355616D00@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: wayne wrote: > The one major objection I had to what was said in the LMAP document is > all the vague references to "changing semantics". I don't see how any > of the LMAP proposals seriously change any semantics, They don't. The text in the original discussion paper said that no semantics were changed. I will update the next version of the document to explain why. Have two parties: originator "O" and recipient "R". They each can either use LMAP "+", or not "-". Let's work through these combinations: O- R- : no one uses LMAP: no change to anything O+ R- : originator publishes data no one looks at: no change to anything O- R+ : Recipient looks for LMAP data, which doesn't exist. The recipient SHOULD inter-operate with non-implementors: no change to anything. If the recipient doesn't interoperate, that's his choice. O+ R+ : both agree to use the new "changed" semantics: no problem. The ONLY problematic situation is the third one. The LMAP discussion document makes this clear, and describes in detail the choices available, and their costs and benefits. > and this phrase seems to have been latched onto and blown out of > proportion by various people. (Mostly people I don't recognize > being involved discussions on SPAM-L, NANAE, ASRG, SPF-discuss, > etc.) Who don't want to change anything, or who are unable to work through a simple 4-step analysis of the effects of the proposal. Alan DeKok. From owner-ietf-mxcomp Wed Mar 10 10:52:30 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2AIqUjT018086; Wed, 10 Mar 2004 10:52: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 i2AIqUt8018085; Wed, 10 Mar 2004 10:52:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2AIqT9k018079 for ; Wed, 10 Mar 2004 10:52:29 -0800 (PST) (envelope-from millenix@zemos.net) Received: from fda.zemos.net ([68.38.12.170]) by comcast.net (sccrmhc13) with ESMTP id <2004031018522701600ha53ne>; Wed, 10 Mar 2004 18:52:27 +0000 Received: from fda.zemos.net (fda [127.0.0.1]) by fda.zemos.net (Postfix) with ESMTP id E1B0318680; Wed, 10 Mar 2004 13:52:26 -0500 (EST) Received: from 66.114.246.101 (proxying for unknown) (SquirrelMail authenticated user millenix); by fda.zemos.net with HTTP; Wed, 10 Mar 2004 13:52:26 -0500 (EST) Message-ID: <3166.66.114.246.101.1078944746.squirrel@66.114.246.101> In-Reply-To: <00d201c40652$d3edf9d0$6401a8c0@hdev1> References: <00c201c40651$ac9acbc0$6401a8c0@hdev1> <00d201c40652$d3edf9d0$6401a8c0@hdev1> Date: Wed, 10 Mar 2004 13:52:26 -0500 (EST) Subject: Re: LMAP Validation Analysis From: "Philip Miller" To: "Hector Santos" Cc: ietf-mxcomp@imc.org Reply-To: millenix@zemos.net User-Agent: SquirrelMail/1.5.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > The following IP/Domain association assertions are made: > > LMAP = IP :: HELO domain > LMAP = IP :: MAIL FROM domain Most proposals make it possible to assert one, the other, or both, while this text makes it appear that both must be asserted. > These LMAP associations is established by adding a domain DNS TXT record > defining a domain mail policy describing which machines are authorized by > the domain as authorized send mail machines. Not necessarily TXT records. I think you should replace the phrase "domain DNS TXT record" with "DNS record". Other than the above, this looks good, although it could use a bit more bulk. -- Philip Miller millenix@zemos.net "Only two things are infinite, the universe and human stupidity, and I'm not sure about the former" -- Albert Einstein From owner-ietf-mxcomp Wed Mar 10 11:06:21 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2AJ6LtD019112; Wed, 10 Mar 2004 11:06:21 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2AJ6Lxv019111; Wed, 10 Mar 2004 11:06:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2AJ6K04019099 for ; Wed, 10 Mar 2004 11:06:20 -0800 (PST) (envelope-from millenix@zemos.net) Received: from fda.zemos.net ([68.38.12.170]) by comcast.net (rwcrmhc12) with ESMTP id <2004031019061401400i8t0ve>; Wed, 10 Mar 2004 19:06:15 +0000 Received: from fda.zemos.net (fda [127.0.0.1]) by fda.zemos.net (Postfix) with ESMTP id 941BB18680; Wed, 10 Mar 2004 14:06:05 -0500 (EST) Received: from 66.114.246.101 (proxying for unknown) (SquirrelMail authenticated user millenix); by fda.zemos.net with HTTP; Wed, 10 Mar 2004 14:06:05 -0500 (EST) Message-ID: <4242.66.114.246.101.1078945565.squirrel@66.114.246.101> In-Reply-To: <20040310161329.GB8016@dumbo.pobox.com> References: <700EEF5641B7E247AC1C9B82C05D125DA7B4@srv1.fecyk.ca> <20040310160910.GL63765@Space.Net> <20040310161329.GB8016@dumbo.pobox.com> Date: Wed, 10 Mar 2004 14:06:05 -0500 (EST) Subject: Re: Everyone back from Seoul yet? From: "Philip Miller" To: "Meng Weng Wong" Cc: ietf-mxcomp@imc.org Reply-To: millenix@zemos.net User-Agent: SquirrelMail/1.5.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Meng Weng Wong said: > On Wed, Mar 10, 2004 at 05:09:10PM +0100, Markus Stumpf wrote: > | The number of "joe-user.de" domains is outnumbering the business domains > | by far and most of them simply have their domain because it is as cheap > | as 1 EUR/month. Some just know enough about the Internet to connect > | and start their preferred chat system (and the configuration was done > | by a friend of a friend). Trying to help them set up something like SPF > | is simply without any chance. > > In economic terms, I see this part of the war on spam as an inevitable > cost-shifting from the antispam community to other sectors of the Net. > > Ultimately it may be more efficient for these vanity domain owners to > pay 2 EUR/month instead of 1 EUR/month if that means that the rest of > the Internet can stop spending an estimated $1,000,000,000 per year on > fighting spam. No matter how much we wish, the Internet economy will not become efficient for the sake of stopping spam. That price increase will never occur, because there won't be upstream price increases in the domain registration and web-hosting businesses. The solution to this is to ignore the issue for now. Once deployment of LMAP has begun, the working group responsible can pick a flag-day sufficiently far in the future on which it becomes acceptable for SMTP servers to 55x mail from domains not advertising LMAP records. -- Philip Miller millenix@zemos.net "Only two things are infinite, the universe and human stupidity, and I'm not sure about the former" -- Albert Einstein From owner-ietf-mxcomp Wed Mar 10 11:13:15 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2AJDFs7019697; Wed, 10 Mar 2004 11:13: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 i2AJDFHk019696; Wed, 10 Mar 2004 11:13:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2AJDFug019690 for ; Wed, 10 Mar 2004 11:13:15 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2AJMId17809; Wed, 10 Mar 2004 11:22:18 -0800 Date: Wed, 10 Mar 2004 11:13:16 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <118760362.20040310111316@brandenburg.com> To: Yakov Shafranovich CC: ietf-mxcomp@imc.org Subject: Re: Passing authentication information via SMTP In-Reply-To: <404770E8.9050602@solidmatrix.com> References: <404770E8.9050602@solidmatrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Yakov, YS> My reading of the entire section 4.4 implies that the MAIL FROM YS> parameter which the "Return-path" headers preserves as stated, is YS> specifically for the purpose of the bounces. It would be wonderful to have specifications that were perfectly clear and precise for all readers. No one has figured out how to produce one. This makes focusing on small segments of specification out of context a bit dangerous. Worse, usage changes over time, so a specification must be taken in the context of current usage. The exercise you have demonstrated, in reviewing some context, for determining a particular protocol feature, is something we all need to do. It leads to interpretations that are more robust and usually more accurate. d/ ps. In the U.S., the postal equivalent to SMTP's "mail from" is called "return address", because that's what it is used for. The fact that it has a high correlation with the sender/author is nice, but ancillary. -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Wed Mar 10 12:00:19 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2AK0JJ7022624; Wed, 10 Mar 2004 12:00: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 i2AK0Jm8022623; Wed, 10 Mar 2004 12:00:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2AK0Jhu022617 for ; Wed, 10 Mar 2004 12:00:19 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2AK9Dd21209; Wed, 10 Mar 2004 12:09:13 -0800 Date: Wed, 10 Mar 2004 12:00:12 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1717523559.20040310120012@brandenburg.com> To: Markus Stumpf CC: Meng Weng Wong , "IETF MXCOMP (E-mail)" Subject: Re: Three major areas of concentration In-Reply-To: <20040310153908.GK63765@Space.Net> References: <700EEF5641B7E247AC1C9B82C05D125DA7AF@srv1.fecyk.ca> <20040310122230.GA8016@dumbo.pobox.com> <20040310153908.GK63765@Space.Net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Markus, MS> On Wed, Mar 10, 2004 at 07:22:30AM -0500, Meng Weng Wong wrote: >> (1) has one dimension: is an IP address allowed to send mail? MS> Sorry, but not really. IMHO it is important to understand that at MS> least MTAMARK does not talk about allowing something. It is about MS> giving an admin a chance to provide hints about an IP address. Thanks for bringing this up. The difference in semantics is important. It is one thing to say "I know that this particular IP Address is (or is not) authorized to be an MTA" and quite another to say "I know the _complete_ set of authorized MTA's." In particular, what is the meaning of having no record for an IP address? Does it mean that it is not authorized or does it mean that we do not know? For example, an ISP or enterprise could register it's own MTAs and, therefore, vouch for their accountability, but say nothing at all about any of its customer's addresses. A receiving MTA might treat the former with less caution and the latter with more. Neither, however, gets automatic trust, because registration as an MTA does not guarantee that the operator of the MTA is not a spammer... MS> In the case of roaming users, local (to the user) mailservers it is MS> very important that the IP is still allowed to send mail even if it is MS> labelled as "not running a public mailserver". However some additional MS> authorization/authentification may be required (e.g. SMTP AUTH). exactly! d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Wed Mar 10 12:17:50 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2AKHnIC023844; Wed, 10 Mar 2004 12:17: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 i2AKHniq023843; Wed, 10 Mar 2004 12:17:49 -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.8) with ESMTP id i2AKHl9P023835 for ; Wed, 10 Mar 2004 12:17:49 -0800 (PST) (envelope-from aland@newgiles.nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 48DDD16D00 for ; Wed, 10 Mar 2004 15:21:14 -0500 (EST) From: "Alan DeKok" To: "IETF MXCOMP (E-mail)" Subject: Re: Three major areas of concentration In-Reply-To: Your message of "Wed, 10 Mar 2004 12:00:12 PST." <1717523559.20040310120012@brandenburg.com> Date: Wed, 10 Mar 2004 15:21:14 -0500 Message-Id: <20040310202114.48DDD16D00@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dave Crocker wrote: > In particular, what is the meaning of having no record for an IP > address? Does it mean that it is not authorized or does it mean that we > do not know? http://www.ietf.org/internet-drafts/draft-irtf-asrg-lmap-discussion-00.txt #--- 1.2. Interpretation of LMAP Data Recipient MTAs are free to interpret LMAP data as they wish. Possibilities range from rejecting email with a 550 error code to using LMAP data as one input to a multi-criterion filter. Domains may also optionally use LMAP data to whitelist or give higher passing values for email in their filters. E-mail from LMAP domains that do not publish LMAP data should NOT be rejected ... #--- That text could be clearer. Any future revision of the document will discuss the issues you have raised, hopefully in a more understandable fashion. > A receiving MTA might treat the former with less caution and the latter > with more. Neither, however, gets automatic trust, because registration > as an MTA does not guarantee that the operator of the MTA is not a > spammer... Exactly. I will be adding text similar to the above comments in future versions of the document. Alan DeKok. From owner-ietf-mxcomp Wed Mar 10 12:23:01 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2AKN1Z5024128; Wed, 10 Mar 2004 12:23:01 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2AKN1A3024127; Wed, 10 Mar 2004 12:23:01 -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.8) with SMTP id i2AKN03Z024115 for ; Wed, 10 Mar 2004 12:23:01 -0800 (PST) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v5.7.450.9b13) for ietf-mxcomp@imc.org; Wed, 10 Mar 2004 15:25:01 -0500 Received: from ([68.215.115.72]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v5.7.450.9b13) with SMTP id 3402871046; Wed, 10 Mar 2004 15:25:00 -0500 Message-ID: <018c01c406dd$8ba964d0$6401a8c0@hdev1> From: "Hector Santos" To: References: <00c201c40651$ac9acbc0$6401a8c0@hdev1> <00d201c40652$d3edf9d0$6401a8c0@hdev1> <3166.66.114.246.101.1078944746.squirrel@66.114.246.101> Subject: Re: LMAP Validation Analysis Date: Wed, 10 Mar 2004 15:22:44 -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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----- Original Message ----- From: "Philip Miller" To: "Hector Santos" Cc: Sent: Wednesday, March 10, 2004 1:52 PM Subject: Re: LMAP Validation Analysis >> The following IP/Domain association assertions are made: >> >> LMAP = IP :: HELO domain >> LMAP = IP :: MAIL FROM domain > Most proposals make it possible to assert one, the other, or both, while > this text makes it appear that both must be asserted. Ok. I'll clear that up. > Not necessarily TXT records. I think you should replace the phrase "domain > DNS TXT record" with "DNS record". Ok. > Other than the above, this looks good, although it could use a bit more bulk. More discussion, explanations? I did start out as a comparison showing DMP vs SPF showing how SPF lacked a provision for HELO spoofing, but now that Meng has added a new provision to address this, I wanted to now generalized it as much as I can showing how all envelope entities can help define the scope of the LMAP methodology. The idea is to look at the entire picture first, then we see how each proposal fits in the generalized model. I still need to finish the "trush" analysis for all the possibility scenarioes in the group DL. For example in Group item DL12 where each entity is remote, for a pure NONE/PASS/FAIL system (like DMP), you have 8 expanded states. With SPF, it expands to 55 possible states! I'll show you what I mean when I'm done. I appreciate your input. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp Wed Mar 10 12:40:34 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2AKeYLM024913; Wed, 10 Mar 2004 12:40: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 i2AKeYF4024912; Wed, 10 Mar 2004 12:40:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.40]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2AKeXS0024906 for ; Wed, 10 Mar 2004 12:40:33 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.50] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1B1AV5-0005bi-00; Wed, 10 Mar 2004 15:40:23 -0500 Received: from [68.244.245.11] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1B1AV3-0005Ex-00; Wed, 10 Mar 2004 15:40:23 -0500 Message-ID: <404F7D26.5090702@solidmatrix.com> Date: Wed, 10 Mar 2004 15:40:06 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Hector Santos CC: ietf-mxcomp@imc.org Subject: Re: LMAP Validation Analysis References: <00c201c40651$ac9acbc0$6401a8c0@hdev1> <00d201c40652$d3edf9d0$6401a8c0@hdev1> <3166.66.114.246.101.1078944746.squirrel@66.114.246.101> <018c01c406dd$8ba964d0$6401a8c0@hdev1> In-Reply-To: <018c01c406dd$8ba964d0$6401a8c0@hdev1> X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hector Santos wrote: > > ----- Original Message ----- > From: "Philip Miller" > To: "Hector Santos" > Cc: > Sent: Wednesday, March 10, 2004 1:52 PM > Subject: Re: LMAP Validation Analysis > >>>The following IP/Domain association assertions are made: >>> >>>LMAP = IP :: HELO domain >>>LMAP = IP :: MAIL FROM domain > >>Most proposals make it possible to assert one, the other, or both, while >>this text makes it appear that both must be asserted. > > Ok. I'll clear that up. > To make life more interesting, MS's Caller ID is based on IP/"From" header relationship, with the IP address taken from the "Received headers". It is different from the MAIL FROM domain which is stored in the message as a "Return-Path" header. If we consider MTA MARK as part of LMAP, then there is also an IP/rDNS tree relationship at connect time before the HELO stage. A side thought: all of these proposals seek to connect the forward DNS tree of a domain with the IP (or in MTA MARK, rDNS with IP). There are two parts to this - publishing the data in DNS, and the second part involves actually applying the data (MAIL FROM, HELO, etc.). This distinction might or might be important to the future. Yakov From owner-ietf-mxcomp Wed Mar 10 14:23:41 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2AMNfh0031441; Wed, 10 Mar 2004 14: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 i2AMNfCp031440; Wed, 10 Mar 2004 14:23:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2AMNfGl031434 for ; Wed, 10 Mar 2004 14:23:41 -0800 (PST) (envelope-from hardie@qualcomm.com) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i2AMNivf001857 for ; Wed, 10 Mar 2004 14:23:45 -0800 (PST) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i2AMNglH021594 for ; Wed, 10 Mar 2004 14:23:43 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: Date: Wed, 10 Mar 2004 14:23:40 -0800 To: ietf-mxcomp@imc.org From: Ted Hardie Subject: Input documents vs. work items. Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, Apparently my previous message was not clear on the difference between input documents and work items. As I'm currently seeing things, the LMAP document (and to a lesser extent the mailing list discussion) are input documents to the working group being proposed; they're not, however, work items for it. The ASRG would continue to work on that document, and I would expect it to be an Informational RFC documenting the work done there (but that should confirmed with the ASRG chairs). No one is interested in discarding any of the work done to date; we're simply interested in narrowing the field of work to be done here to something which can be in a timely way. regards, Ted Hardie From owner-ietf-mxcomp Wed Mar 10 14:59:20 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2AMxKek032879; Wed, 10 Mar 2004 14:59: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 i2AMxKLE032878; Wed, 10 Mar 2004 14:59:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2AMxJlM032872 for ; Wed, 10 Mar 2004 14:59:19 -0800 (PST) (envelope-from hardie@qualcomm.com) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i2AMxNnp018777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 10 Mar 2004 14:59:23 -0800 (PST) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i2AMxLlH028844 for ; Wed, 10 Mar 2004 14:59:22 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: Date: Wed, 10 Mar 2004 14:59:19 -0800 To: ietf-mxcomp@imc.org From: Ted Hardie Subject: Administrative roles connecting to assertions of identity Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: One of the things I tried to get at during the BoF was that using the DNS to distribute data implies that the entity asserting that the data is correct is the DNS zone maintainer. In DNSSEC, for example, you can read the cryptographic work as assuring that "data which passes this validation is the same data that was placed in the zone by the zone maintainer". As we move forward, we have to recognize that the connection between the zone maintainer and the other entities involved will be critical; we also have to recognize that the connections are fundamentally different in the forward and reverse zones (in-addr.arpa or ip6.arpa). Essentially, the forward zones (domain.tld) follow lines of administrative responsibility, where the reverse zones follow lines of network topology. As we have this discussion, we have to consider how communications about the assertions that should be made will follow those lines. Speaking personally, I am concerned about the ways in which structuring this communication will interact with the policies for allocation. This is perhaps most obvious in the reverse zone, where a delegation of responsibility of a specific network prefix by an RIR to an ISP does not currently carry the responsibility that the ISP maintain information at this level of detail about the uses of the address space. If it had to maintain that data, new tools might well be needed to pass the data from the customer to the ISP, and that might have an effect of deployment. Not that this is the only way it could work; indeed, it is common for an ISP to delegate the space it has received to the organizations for which it carries traffic, so they can maintain their own zones (see the data ARIN's SWIP project, http://www.arin.net/library/guidelines/swip.html, for an example). There seems to me a risk, though, that the practical need for a certain level of assurance about the assertions being made might have an impact on the assignment/reassignment policies. If a reassignment involves an end-user customer, there may also be privacy regulations about revealing data about that customer which would hinder easy association of customer data with the assertion. To go back to the main point, though, I think we need to consider how the connection fits between "the person who knows that $FOO may assert an identity" and "the person who maintains the DNS entries associated with the MTA". If they are the same person or in the same organization this is relatively easy; if they need to be in different organizations for some proposals (in a common case, anyway), then discussion of that relationship seems to me in order. Speaking personally, regards, Ted Hardi From owner-ietf-mxcomp Wed Mar 10 15:03:45 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2AN3jGo033061; Wed, 10 Mar 2004 15:03: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 i2AN3jg3033060; Wed, 10 Mar 2004 15:03:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2AN3fMc033053 for ; Wed, 10 Mar 2004 15:03:44 -0800 (PST) (envelope-from hardie@qualcomm.com) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i2AN3jvf004338 for ; Wed, 10 Mar 2004 15:03:45 -0800 (PST) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i2AN3hVK000627 for ; Wed, 10 Mar 2004 15:03:43 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: References: Date: Wed, 10 Mar 2004 15:03:41 -0800 To: ietf-mxcomp@imc.org From: Ted Hardie Subject: Re: Input documents vs. work items. Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 2:23 PM -0800 03/10/2004, Ted Hardie wrote: >Hi, > Apparently my previous message was not clear >on the difference between input documents and work items. >As I'm currently seeing things, the LMAP document (and to >a lesser extent the mailing list discussion) are input documents Sigh. Not clear yet, eh? I meant "mailing list discussion on ASRG's list". regards, Ted Hardie From owner-ietf-mxcomp Wed Mar 10 15:19:43 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2ANJhSY033934; Wed, 10 Mar 2004 15:19: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 i2ANJhkI033933; Wed, 10 Mar 2004 15:19:43 -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 (srv1.fecyk.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2ANJgZX033927 for ; Wed, 10 Mar 2004 15:19:43 -0800 (PST) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: [Back to Normal] RE: Three major areas of concentration MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 10 Mar 2004 17:19:47 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA7B5@srv1.fecyk.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Three major areas of concentration Thread-Index: AcQGmo56E+wKgjl5R3uMzsLBLK+E6AAWvQ+A 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 i2ANJhZX033928 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Meng Weng Wong > Sent: Wednesday, March 10, 2004 06:23 > To: IETF MXCOMP (E-mail) > Subject: Three major areas of concentration > > In the future, with wide deployment of an SPF-like Nice to know some things don't change. Before this turns into a problem that split the ASRG-RMX mailing list a few months ago, let's all watch the video from last week again. And again. Until all egos are sufficiently deflated.[1] [1] Before anyone cites Pot, Kettle, Black, know that this includes me, too. If I can do it, so can you. -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Wed Mar 10 16:13:46 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B0DkRu038358; Wed, 10 Mar 2004 16:13: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 i2B0DkBv038357; Wed, 10 Mar 2004 16:13:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B0Djca038350 for ; Wed, 10 Mar 2004 16:13:45 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.11/) with ESMTP id i2B0DoAb007866; Wed, 10 Mar 2004 16:13:51 -0800 (PST) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 10 Mar 2004 16:13:50 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Gordon Fecyk'" , "IETF MXCOMP (E-mail)" Subject: RE: [Back to Normal] RE: Three major areas of concentration Date: Wed, 10 Mar 2004 16:13:37 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a political issue, not a technical one. Politics matter, this is all about deployment, the only reason I care about a standards imprimatur is to the extent it helps to drive deployment. My advice here is the same I am giving to the RSS/Atom group. Look to your strongest brands. RSS is a significant brand, but it does need standards support to improve the spec. It makes sense to borrow as much as you can from the Atom specsmanship and the RSS legacy base, but keep the RSS brand. At this point SPF has established a brand. So has CallerID. Don't try to remake those brands unless you really have to. Last time I saw the IETF trying to change a name was SSL to TLS. And its still SSL as far as everyone is concerned. Phill > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Gordon Fecyk > Sent: Wednesday, March 10, 2004 6:20 PM > To: IETF MXCOMP (E-mail) > Subject: [Back to Normal] RE: Three major areas of concentration > > > > > -----Original Message----- > > From: owner-ietf-mxcomp@mail.imc.org > > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Meng Weng Wong > > Sent: Wednesday, March 10, 2004 06:23 > > To: IETF MXCOMP (E-mail) > > Subject: Three major areas of concentration > > > > In the future, with wide deployment of an SPF-like > > Nice to know some things don't change. > > Before this turns into a problem that split the ASRG-RMX > mailing list a few > months ago, let's all watch the video from last week again. > And again. > Until all egos are sufficiently deflated.[1] > > [1] Before anyone cites Pot, Kettle, Black, know that this > includes me, too. > If I can do it, so can you. > > -- > PGP key (0x0AFA039E): > What's a PGP Key? See > GOD BLESS AMER, er, THE INTERNET. > > From owner-ietf-mxcomp Wed Mar 10 16:28:08 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B0S8k2039085; Wed, 10 Mar 2004 16:28: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 i2B0S8GE039084; Wed, 10 Mar 2004 16:28:08 -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 (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B0S7ik039078 for ; Wed, 10 Mar 2004 16:28:07 -0800 (PST) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.30) id 1B1E3Z-0002CZ-3d for ietf-mxcomp@imc.org; Wed, 10 Mar 2004 18:28:13 -0600 To: ietf-mxcomp@imc.org Subject: Questions about DNS lookups in DMP and FSV From: wayne Content-Type: text/plain; charset=US-ASCII Date: Wed, 10 Mar 2004 18:28:12 -0600 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (spfd: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Yesterday, when I re-read the LMAP document, I noticed that section 4.6 "Number of queries", it says that DMP and FSV both say they fetch their DNS data in one query. This doesn't seem quite right to me. It is my understanding that DMP requires you to fetch a TXT record from _smtp-client.$FQDN and also an A record at $REV-ADDRESS.$ADDRESS-TYPE._smtp-client.$FQDN. Similarly, FSV appears to need to fetch either an A record at _fsv.$FQDN and either a TXT record from the same location, or another A record $REV-ADDRESS._fsv.$FQDN. Doesn't this mean that DMP and FSV require a minimum of 2 DNS queries? -wayne From owner-ietf-mxcomp Wed Mar 10 16:31:17 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B0VHgo039299; Wed, 10 Mar 2004 16:31: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 i2B0VHtb039298; Wed, 10 Mar 2004 16:31:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from scale01.mcom.com (h-64-236-139-249.aoltw.net [64.236.139.249]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B0VHvX039283 for ; Wed, 10 Mar 2004 16:31:17 -0800 (PST) (envelope-from aoki@aol.net) Received: from aol.net ([10.169.158.80]) by scale01.nscp.aoltw.net (Netscape Messaging Server 6.1 (built Oct 3 2002)) with ESMTP id <0HUD00D05YR0GV@scale01.nscp.aoltw.net> for ietf-mxcomp@imc.org; Wed, 10 Mar 2004 16:30:36 -0800 (PST) Date: Wed, 10 Mar 2004 16:31:20 -0800 From: Edwin Aoki Subject: Re: [Back to Normal] RE: Three major areas of concentration In-reply-to: To: "Hallam-Baker, Phillip" Cc: "'Gordon Fecyk'" , "IETF MXCOMP (E-mail)" Message-id: <404FB358.6010409@aol.net> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031007 References: Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Folks, Before this thread spirals too far out of control, let me offer the following: 1) The IETF will charter a working group to work on this problem. The working group will have some name. 2) The working group will author some number (hopefully at least 1) of RFCs that implement various technologies to address the MTA authorization problem(s). Each of these technologies will likely have a "short" or common name. As a general practice, let's not get too caught up in naming at the moment. I'm sure some people will see bias, intended or not, with a phrase like "SPF-like" or "RMX-based" or "MTAMark-derived." But hopefully as engineers on this list, we'll be able to look past that for this interim period. We should probably pick a non-controversial phrase and forgive people who don't. How's that? -Edwin Hallam-Baker, Phillip wrote: >This is a political issue, not a technical one. > >Politics matter, this is all about deployment, the only reason I >care about a standards imprimatur is to the extent it helps to >drive deployment. > >My advice here is the same I am giving to the RSS/Atom group. Look >to your strongest brands. RSS is a significant brand, but it does >need standards support to improve the spec. It makes sense to borrow >as much as you can from the Atom specsmanship and the RSS legacy >base, but keep the RSS brand. > >At this point SPF has established a brand. So has CallerID. Don't >try to remake those brands unless you really have to. > >Last time I saw the IETF trying to change a name was SSL to TLS. And >its still SSL as far as everyone is concerned. > > Phill > > > >>-----Original Message----- >>From: owner-ietf-mxcomp@mail.imc.org >>[mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Gordon Fecyk >>Sent: Wednesday, March 10, 2004 6:20 PM >>To: IETF MXCOMP (E-mail) >>Subject: [Back to Normal] RE: Three major areas of concentration >> >> >> >> >> >>>-----Original Message----- >>>From: owner-ietf-mxcomp@mail.imc.org >>>[mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Meng Weng Wong >>>Sent: Wednesday, March 10, 2004 06:23 >>>To: IETF MXCOMP (E-mail) >>>Subject: Three major areas of concentration >>> >>>In the future, with wide deployment of an SPF-like >>> >>> >>Nice to know some things don't change. >> >>Before this turns into a problem that split the ASRG-RMX >>mailing list a few >>months ago, let's all watch the video from last week again. >>And again. >>Until all egos are sufficiently deflated.[1] >> >>[1] Before anyone cites Pot, Kettle, Black, know that this >>includes me, too. >>If I can do it, so can you. >> >>-- >>PGP key (0x0AFA039E): >>What's a PGP Key? See >>GOD BLESS AMER, er, THE INTERNET. >> >> >> >> > > > From owner-ietf-mxcomp Wed Mar 10 17:24:19 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B1OJJO042521; Wed, 10 Mar 2004 17:24: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 i2B1OJk6042520; Wed, 10 Mar 2004 17:24:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B1OJLQ042514 for ; Wed, 10 Mar 2004 17:24:19 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2B1XRd10102 for ; Wed, 10 Mar 2004 17:33:27 -0800 Date: Wed, 10 Mar 2004 17:24:24 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1194379365.20040310172424@brandenburg.com> To: "IETF MXCOMP (E-mail)" Subject: Re: [Back to Normal] RE: Three major areas of concentration In-Reply-To: <404FB358.6010409@aol.net> References: <404FB358.6010409@aol.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Edwin, EA> As a general practice, let's not get too caught up in naming at the EA> moment. I'm sure some people will see bias, intended or not, with a EA> phrase like "SPF-like" or "RMX-based" or "MTAMark-derived." But EA> hopefully as engineers on this list, we'll be able to look past that for EA> this interim period. We should probably pick a non-controversial phrase EA> and forgive people who don't. In fact, it would probably help quite a lot for us to develop some generic labels, that distinguish classes of mechanism. At the moment, I think there are two classes. One attempts to certify a relationship between an MTA and a message author. The other attempts to certify a relationship between an MTA and the network that that MTA operates in. I'll refrain from formulating labels, for the moment. Let's see if we can get some agreement about basic descriptions of the solution classes. What will probably help the most is having people agree with my descriptions, offer refinements to them, or offer an alternative of descriptions. The only requirement is that none of the proffered text refer to any existing scheme by name. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Wed Mar 10 17:36:19 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B1aJWY043148; Wed, 10 Mar 2004 17:36: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 i2B1aJOJ043147; Wed, 10 Mar 2004 17:36:19 -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 (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B1aIlE043141 for ; Wed, 10 Mar 2004 17:36:18 -0800 (PST) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.30) id 1B1F7Y-0003L1-LK for ietf-mxcomp@imc.org; Wed, 10 Mar 2004 19:36:24 -0600 To: ietf-mxcomp@imc.org Subject: Re: Three major areas of concentration References: <404FB358.6010409@aol.net> <1194379365.20040310172424@brandenburg.com> From: wayne Content-Type: text/plain; charset=US-ASCII Date: Wed, 10 Mar 2004 19:36:24 -0600 In-Reply-To: <1194379365.20040310172424@brandenburg.com> (Dave Crocker's message of "Wed, 10 Mar 2004 17:24:24 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (spfd: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <1194379365.20040310172424@brandenburg.com> Dave Crocker writes: > In fact, it would probably help quite a lot for us to develop some > generic labels, that distinguish classes of mechanism. > > At the moment, I think there are two classes. As the subject of this thread says, I think there are *three* major areas. > One attempts to certify a relationship between an MTA and a message > author. I'm not sure what you mean by "author", but I'm guessing you are talking about the From: and/or Sender: headers in the mail body. When you get to the point of identifying a particular author, I'm not sure that it is so important to worry about the MTA that the email was sent from. > The other attempts to certify a relationship between an MTA and the > network that that MTA operates in. You left out the relationship between the sending MTA and the domain used in the HELO and/or MAIL FROM commands. -wayne From owner-ietf-mxcomp Wed Mar 10 17:51:32 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B1pW8m044154; Wed, 10 Mar 2004 17:51: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 i2B1pW9Y044153; Wed, 10 Mar 2004 17:51:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B1pVpR044147 for ; Wed, 10 Mar 2004 17:51:32 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.11/) with ESMTP id i2B1pa5Q029311; Wed, 10 Mar 2004 17:51:36 -0800 (PST) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 10 Mar 2004 17:51:36 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Edwin Aoki'" , "Hallam-Baker, Phillip" Cc: "'Gordon Fecyk'" , "IETF MXCOMP (E-mail)" Subject: RE: [Back to Normal] RE: Three major areas of concentration Date: Wed, 10 Mar 2004 17:51:28 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > As a general practice, let's not get too caught up in naming at the > moment. I'm sure some people will see bias, intended or not, with a > phrase like "SPF-like" or "RMX-based" or "MTAMark-derived." But > hopefully as engineers on this list, we'll be able to look > past that for this interim period. We should probably pick a > non-controversial phrase and forgive people who don't. The issue is not a trivial one. As you know I am in favor of using Roberts rules of order, democracy and votes in working groups, like we do in OASIS. Fact is that most times that we have a contested vote it is on a naming issue, and yes they do matter. I spent perhaps 200 hours working to get 'Assertion' into the name of SAML. today people understand why. There are two issues that have to be addressed here: 1) Marketting of the specification. 2) Credit for the people who contributed to the design. Hadmut, Alan and others have a very legitimate complaint here. The reason I took such offense at the earlier publicity strategy of ASRG was that the effect it would have on the group was very clear. The best way to address (2) is if we work together offline. Earlier I asked from certain individuals to give me soundbite quotes that I or anyone else who is being interviewed by a journalist can pass on. I often (usually) get called up by a journalist with less than six hours before their deadline comes up. That means I have less than an hour to get my PR person online, discuss the talking points and return the call. I could try to give a direction to someone else but the probability of the journalist bothering is small. It is really easy though for me to say, 'off the record, we have a credit issue here, I'll email you some quotes from some key contributors.' Phill From owner-ietf-mxcomp Wed Mar 10 17:59:22 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B1xMRa044705; Wed, 10 Mar 2004 17:59: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 i2B1xM4j044704; Wed, 10 Mar 2004 17:59:22 -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 (srv1.fecyk.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B1xLbU044698 for ; Wed, 10 Mar 2004 17:59:22 -0800 (PST) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: [Back to Normal] RE: Three major areas of concentration MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 10 Mar 2004 19:59:27 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA7B6@srv1.fecyk.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Back to Normal] RE: Three major areas of concentration Thread-Index: AcQHACnNnmWjzQohRVaERmLZ8WhvIAADATwA From: "Gordon Fecyk" Cc: "IETF MXCOMP (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2B1xMbU044699 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > As a general practice, let's not get too caught up in naming at the > moment. "What's in a name" and all that. There's some old animosity amongst the "early adopters." I imagine this is seen all the time when new groups start around emerging technology but anti-spammers are an especially passionate lot. It might be more pronounced around here. -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Wed Mar 10 18:10:27 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B2ARu7045326; Wed, 10 Mar 2004 18:10:27 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2B2AR1Y045325; Wed, 10 Mar 2004 18:10:27 -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 (srv1.fecyk.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B2AQW9045319 for ; Wed, 10 Mar 2004 18:10:26 -0800 (PST) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: Questions about DNS lookups in DMP and FSV MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 10 Mar 2004 20:10:32 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA7B7@srv1.fecyk.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Questions about DNS lookups in DMP and FSV Thread-Index: AcQG//NNO0vIpZ6kRGaN4x5XCBHakwADKYFg From: "Gordon Fecyk" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2B2ARW9045320 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > their DNS data in one query. This doesn't seem quite right to me. DMP tried to make things easier for domains publishing data and only to dig deeper when there's uncertainty. As I had it described once: "Front-load the pain now, and it'll ease up as it's adopted." I didn't see a way around it when the argument around wildcard records came about. Sure an unusual implementation of DNS could synthesise records in a new way to avoid the second lookup, but I didn't want to count on that. > It is my understanding that DMP requires you to fetch a TXT record > from _smtp-client.$FQDN and also an A record at > $REV-ADDRESS.$ADDRESS-TYPE._smtp-client.$FQDN. Similarly, FSV appears > to need to fetch either an A record at _fsv.$FQDN and either a TXT > record from the same location, or another A record > $REV-ADDRESS._fsv.$FQDN. > > Doesn't this mean that DMP and FSV require a minimum of 2 DNS queries? More like a maximum of two, minimum of one[1]. DMP got a little worse, with a maximum of four queries, when a receiver queries for hostnames as well as domain names. If a receiver were prepared to sacrifice Store and Forward, that got back down to a maximum of two. I want to know if there's a better way to check if a domain publishes LMAP-type data when the first query returns NXDOMAIN, so we are back down to a maximum of one query per e-mail. FSV sticks with domains instead of hosts, from what I read, so it looks like it has a maximum of two regardless. [1] Subject to DNS caching. -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Wed Mar 10 18:19:11 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B2JBmU046076; Wed, 10 Mar 2004 18:19: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 i2B2JB1q046075; Wed, 10 Mar 2004 18:19:11 -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 (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B2JA81046067 for ; Wed, 10 Mar 2004 18:19:11 -0800 (PST) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.30) id 1B1Fn3-0003wN-3r for ietf-mxcomp@imc.org; Wed, 10 Mar 2004 20:19:17 -0600 To: Subject: Re: Questions about DNS lookups in DMP and FSV References: <700EEF5641B7E247AC1C9B82C05D125DA7B7@srv1.fecyk.ca> From: wayne Content-Type: text/plain; charset=US-ASCII Date: Wed, 10 Mar 2004 20:19:16 -0600 In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125DA7B7@srv1.fecyk.ca> (Gordon Fecyk's message of "Wed, 10 Mar 2004 20:10:32 -0600") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (spfd: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <700EEF5641B7E247AC1C9B82C05D125DA7B7@srv1.fecyk.ca> "Gordon Fecyk" writes: >> It is my understanding that DMP requires you to fetch a TXT record >> from _smtp-client.$FQDN and also an A record at >> $REV-ADDRESS.$ADDRESS-TYPE._smtp-client.$FQDN. [...] >> >> Doesn't this mean that DMP [...] require a minimum of 2 DNS queries? > > More like a maximum of two, minimum of one[1]. Ok, so DMP doesn't require you to fetch *both* the TXT record and the A record? Doesn't the TXT just say that "yes, this domain uses DMP"? Don't you have to look up the A record also to see if the IP address is allowed or not? > DMP got a little worse, with > a maximum of four queries, when a receiver queries for hostnames as well as > domain names. If a receiver were prepared to sacrifice Store and Forward, > that got back down to a maximum of two. Hmmm... I don't understand this part, but maybe I just need to read the DMP spec closer. -wayne From owner-ietf-mxcomp Wed Mar 10 18:33:00 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B2X0cl046935; Wed, 10 Mar 2004 18:33: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 i2B2X0n5046934; Wed, 10 Mar 2004 18:33:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B2X025046928 for ; Wed, 10 Mar 2004 18:33:00 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2B2g5d14248; Wed, 10 Mar 2004 18:42:05 -0800 Date: Wed, 10 Mar 2004 18:33:02 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <561568912.20040310183302@brandenburg.com> To: wayne CC: ietf-mxcomp@imc.org Subject: Re: Three major areas of concentration In-Reply-To: References: <404FB358.6010409@aol.net> <1194379365.20040310172424@brandenburg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: wayne, >> One attempts to certify a relationship between an MTA and a message >> author. w> I'm not sure what you mean by "author", but I'm guessing you are w> talking about the From: and/or Sender: I mean From. Sender is the agent that posts it, not necessarily the agent that wrote the content. w> When w> you get to the point of identifying a particular author, I'm not sure w> that it is so important to worry about the MTA that the email was sent w> from. My reading of the majority of the MTA Authentication schemes is that they purport to validate authorship (and, therefore, really are making statements about the From field) based on having the message transit authorized MTAs. >> The other attempts to certify a relationship between an MTA and the >> network that that MTA operates in. w> You left out the relationship between the sending MTA and the domain w> used in the HELO and/or MAIL FROM commands. What relationship do folks think this is (or should be) between the EHLO domain name and the network the MTA operates in? As for Mail From, that is a bounces address, and is not required to have anything at all to do with authorship. There are entirely legitimate uses that set the Mail From to an address that is entirely different from the From field. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Wed Mar 10 18:34:52 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B2YqZg047015; Wed, 10 Mar 2004 18:34: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 i2B2Yqie047014; Wed, 10 Mar 2004 18:34:52 -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 (srv1.fecyk.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B2YpFP047008 for ; Wed, 10 Mar 2004 18:34:51 -0800 (PST) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: Questions about DNS lookups in DMP and FSV MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 10 Mar 2004 20:34:57 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA7B8@srv1.fecyk.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Questions about DNS lookups in DMP and FSV Thread-Index: AcQHD2mchAgpGJRMTPG5w7STSZL6VgAAB1zg From: "Gordon Fecyk" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2B2YqFP047009 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > >> Doesn't this mean that DMP [...] require a minimum of 2 > DNS queries? > > > > More like a maximum of two, minimum of one[1]. > > Ok, so DMP doesn't require you to fetch *both* the TXT record and the > A record? Doesn't the TXT just say that "yes, this domain uses DMP"? There's no A RR used at all in DMP. There's a TXT record for each host (or a wildcard if ye be so brave enough to use one for a /24 or /16) and one for the domain itself, to check if the domain publishes records. So a receiver queries the IP+domain first, and if it gives NXDOMAIN only then does it query the domain itself. The sender would see more dual queries if a forgery was in progress, and if any wildcard records didn't synthesise "dmp=deny" answers. The flowchart in draft-fecyk-dmp section 5 explains the lookup and response steps better than I can here. Actually, I've asked about this before (yeah I'm stroking my own ego here - give me hell as you see fit). What of the practicality of IP+domain queries, where each e-mail causes a query, vs domain-only queries where maybe the domain's queried once in a while with larger responses? Or perhaps there's a better alternative to both of these. DNS Folks: Assume for a moment that we're using a new record type or class (or both) and imagine it's not called TXT or A or whatever existing types or classes are called. Also assume that hard-defined name spaces weren't needed because they aren't, really. -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Wed Mar 10 18:37:41 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B2bfEl047154; Wed, 10 Mar 2004 18:37: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 i2B2bfnD047153; Wed, 10 Mar 2004 18:37:41 -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 (srv1.fecyk.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B2beS9047147 for ; Wed, 10 Mar 2004 18:37:41 -0800 (PST) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: Potential Work Item: New DNS resource records MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 10 Mar 2004 20:37:47 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA7B9@srv1.fecyk.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Potential Work Item: New DNS resource records Thread-Index: AcQHEesnbzVzgd6/SWKtoFErPf3Fyw== 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 i2B2bfS9047148 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I realize this item, if it happens, would happen AFTER working through the semantics of retreiving data, but could this be a work item even if it can only be addressed later? The DNS folks made it clear that (ab)using existing record types would be unacceptable. So whatever data we want stored in the DNS cannot use existing record types and, ideally, not be stored in hard-defined name spaces like _vsf or _smtp-client or whatever. Wildcards were also generally a Bad Idea[tm]. -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Wed Mar 10 18:44:05 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B2i50R047543; Wed, 10 Mar 2004 18:44:05 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2B2i5LO047542; Wed, 10 Mar 2004 18:44:05 -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 (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B2i4lc047536 for ; Wed, 10 Mar 2004 18:44:04 -0800 (PST) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.30) id 1B1GB9-0004HF-21; Wed, 10 Mar 2004 20:44:11 -0600 To: Dave Crocker Cc: ietf-mxcomp@imc.org Subject: Re: Three major areas of concentration References: <404FB358.6010409@aol.net> <1194379365.20040310172424@brandenburg.com> <561568912.20040310183302@brandenburg.com> From: wayne Content-Type: text/plain; charset=US-ASCII Date: Wed, 10 Mar 2004 20:44:10 -0600 In-Reply-To: <561568912.20040310183302@brandenburg.com> (Dave Crocker's message of "Wed, 10 Mar 2004 18:33:02 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (spfd: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <561568912.20040310183302@brandenburg.com> Dave Crocker writes: > w> When > w> you get to the point of identifying a particular author, I'm not sure > w> that it is so important to worry about the MTA that the email was sent > w> from. > > My reading of the majority of the MTA Authentication schemes is that > they purport to validate authorship (and, therefore, really are making > statements about the From field) based on having the message transit > authorized MTAs. I disagree. I know of none of the LMAP proposals that purport to validate authorship. They talk about authorization and authentication, but they don't try to pin down an author. I recommend reading: http://www.ietf.org/internet-drafts/draft-irtf-asrg-lmap-discussion-00.txt > w> You left out the relationship between the sending MTA and the domain > w> used in the HELO and/or MAIL FROM commands. > > What relationship do folks think this is (or should be) between the EHLO > domain name and the network the MTA operates in? I think that if an MTA claims to be involved with my domain on either the HELO or MAIL FROM commands, that I should have a say in it. > As for Mail From, that is a bounces address, and is not required to have > anything at all to do with authorship. I don't know anyone who thinks that the MAIL FROM has anything to do with the authorship. > There are entirely legitimate > uses that set the Mail From to an address that is entirely different > From the From field. Yes, for example, this mailing lists changes the MAIL FROM. -wayne From owner-ietf-mxcomp Wed Mar 10 18:48:20 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B2mKXZ047821; Wed, 10 Mar 2004 18:48: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 i2B2mKUE047820; Wed, 10 Mar 2004 18:48:20 -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 (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B2mJeV047810 for ; Wed, 10 Mar 2004 18:48:19 -0800 (PST) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.30) id 1B1GFF-0004MN-Lm; Wed, 10 Mar 2004 20:48:25 -0600 To: "Gordon Fecyk" Cc: Subject: Re: Questions about DNS lookups in DMP and FSV References: <700EEF5641B7E247AC1C9B82C05D125DA7B8@srv1.fecyk.ca> From: wayne Content-Type: text/plain; charset=US-ASCII Date: Wed, 10 Mar 2004 20:48:25 -0600 In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125DA7B8@srv1.fecyk.ca> (Gordon Fecyk's message of "Wed, 10 Mar 2004 20:34:57 -0600") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (spfd: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <700EEF5641B7E247AC1C9B82C05D125DA7B8@srv1.fecyk.ca> "Gordon Fecyk" writes: >> >> Doesn't this mean that DMP [...] require a minimum of 2 >> DNS queries? >> > >> > More like a maximum of two, minimum of one[1]. >> >> Ok, so DMP doesn't require you to fetch *both* the TXT record and the >> A record? Doesn't the TXT just say that "yes, this domain uses DMP"? > > There's no A RR used at all in DMP. Ooops, I was confused with FSV. But, that doesn't change my point much. > So a receiver queries the IP+domain first, and if it gives NXDOMAIN only then What is this "IP+domain" thing? That is two queries, right? One for the _smtp-client.$FQDN and one for the $REV-ADDRESS....$FQDN. -wayne From owner-ietf-mxcomp Wed Mar 10 19:05:28 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B35SGQ049760; Wed, 10 Mar 2004 19:05: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 i2B35S1V049759; Wed, 10 Mar 2004 19:05:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B35Q6J049752 for ; Wed, 10 Mar 2004 19:05:27 -0800 (PST) (envelope-from paf@cisco.com) Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 10 Mar 2004 19:14:35 +0000 Received: from XBE-AMS-302.cisco.com (xbe-ams-302.cisco.com [144.254.75.92]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2B34vHs019976; Thu, 11 Mar 2004 04:04:58 +0100 (MET) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by XBE-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 11 Mar 2004 04:04:08 +0100 Received: from [127.0.0.1] ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 11 Mar 2004 04:05:25 +0100 In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125DA7B9@srv1.fecyk.ca> References: <700EEF5641B7E247AC1C9B82C05D125DA7B9@srv1.fecyk.ca> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "IETF MXCOMP (E-mail)" From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: Potential Work Item: New DNS resource records Date: Thu, 11 Mar 2004 11:05:21 +0800 To: "Gordon Fecyk" X-Mailer: Apple Mail (2.612) X-OriginalArrivalTime: 11 Mar 2004 03:05:25.0861 (UTC) FILETIME=[B3642950:01C40715] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: [I am not writing this as chair of the BOF or anything, but as an individual] On 2004-03-11, at 10.37, Gordon Fecyk wrote: > The DNS folks made it clear that (ab)using existing record types would > be > unacceptable. So whatever data we want stored in the DNS cannot use > existing > record types and, ideally, not be stored in hard-defined name spaces > like > _vsf or _smtp-client or whatever. Wildcards were also generally a Bad > Idea[tm]. Yes, I think this should be a work item, and we should let DNS people do the work. I am probably "almost" one such person, and have initial comments below. When sending a query for a DNS record, you send a triple consisting of (Owner, Type, Class). One of the reasons for not using for example TXT record is that the client when issuing a query can not select only the TXT records for the given domain name used for this application without also getting other TXT records. I.e. one of the three items in the triple must be unique. Four alternatives: [1] Change the class Bad idea. Changing of class imply creating a new root in the DNS tree. I will not go into the details here. [2] Add a suffix to the owner (i.e. for example.com, query for example.com.service.) Also very bad idea. Also creates a new root in the DNS tree. [3] Add a prefix to the owner (i.e. _foo.example.com.) Problematic for two reasons: If we have example.com. IN MX 10 mail.example.com. it is for me much better to have the same owner for the "RMX" resource record as the MX because then we know for sure both MX and the "RMX" is in the same zone, and have to be signed by the same owner/mechanism. Second problem has to do with wildcards. If one have *.example.com. IN MX 10 mail.example.com. then one can have still *.example.com. IN RMX ... But, if one use _foo.example.com for the mechanism, we can not have: _foo.*.example.com. [4] Change the resource record type See previous bullet, it forces the MX and the "RMX" to be in the same zone, which in turn forces the records to be managed by the same entity. This for me personally make things much more stable and "correct" and also partially answers the question Ted had about DNSSEC. paf From owner-ietf-mxcomp Wed Mar 10 19:31:24 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B3VOv6051502; Wed, 10 Mar 2004 19:31: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 i2B3VOqf051501; Wed, 10 Mar 2004 19:31:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (mail.santronics.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2B3VNvY051494 for ; Wed, 10 Mar 2004 19:31:23 -0800 (PST) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v5.7.450.9b13) for ietf-mxcomp@imc.org; Wed, 10 Mar 2004 22:33:28 -0500 Received: from ([68.215.115.72]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v5.7.450.9b13) with SMTP id 3428578859; Wed, 10 Mar 2004 22:33:27 -0500 Message-ID: <00aa01c40719$67a09310$6401a8c0@hdev1> From: "Hector Santos" To: "IETF MXCOMP \(E-mail\)" References: <404FB358.6010409@aol.net> <1194379365.20040310172424@brandenburg.com> Subject: Re: [Back to Normal] RE: Three major areas of concentration Date: Wed, 10 Mar 2004 22:28:19 -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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----- Original Message ----- From: "Dave Crocker" To: "IETF MXCOMP (E-mail)" Sent: Wednesday, March 10, 2004 8:24 PM Subject: Re: [Back to Normal] RE: Three major areas of concentration > In fact, it would probably help quite a lot for us to develop some > generic labels, that distinguish classes of mechanism. Good idea Dave. At the moment, I take issue with how CID is used for Microsoft's proposal. I already saw two different acronymns for Microsoft's CallerId Email Policy proposal. CID, which I think is terrible, since it is a common acroymn used in many systems (including ours) and I recently read a news rag reference it (abeit incorrectly) as CSRI, "Coordinated Spam Reduction Initiative." See http://www.microsoft.com/mscorp/twc/privacy/spam_csri.mspx Personally, we implemented and labled it as MCEP, "Microsoft's Callerid Email Policy" because we already use CID as part of our filter language macro system to reference a RPC client/server session connection or context id. No need to confuse our customers with such a generic and common acronymn. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp Wed Mar 10 19:59:02 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B3x2Vx053298; Wed, 10 Mar 2004 19:59: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 i2B3x25Z053297; Wed, 10 Mar 2004 19:59:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B3x1Zr053289 for ; Wed, 10 Mar 2004 19:59:02 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2B489d19442; Wed, 10 Mar 2004 20:08:09 -0800 Date: Wed, 10 Mar 2004 19:59:05 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1799694351.20040310195905@brandenburg.com> To: wayne CC: ietf-mxcomp@imc.org Subject: Re: Three major areas of concentration In-Reply-To: References: <404FB358.6010409@aol.net> <1194379365.20040310172424@brandenburg.com> <561568912.20040310183302@brandenburg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: wayne, w> I disagree. I know of none of the LMAP proposals that purport to w> validate authorship. They talk about authorization and w> authentication, but they don't try to pin down an author. what is the identity that is authenticated? what is its relationship to the message and/or the transmission of the message? d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Wed Mar 10 20:08:25 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B48PxE054286; Wed, 10 Mar 2004 20:08: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 i2B48PJU054285; Wed, 10 Mar 2004 20:08:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [208.210.125.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B48OJ1054277 for ; Wed, 10 Mar 2004 20:08:24 -0800 (PST) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [208.210.125.24]) by emerald.pobox.com (Postfix) with ESMTP id 30FED132CF9 for ; Wed, 10 Mar 2004 23:08:30 -0500 (EST) Received: by dumbo.pobox.com (Postfix, from userid 505) id 12E3D761; Wed, 10 Mar 2004 23:08:30 -0500 (EST) Date: Wed, 10 Mar 2004 23:08:30 -0500 From: Meng Weng Wong To: ietf-mxcomp@imc.org Subject: Some thoughts on the costs of Block vs Factored queries Message-ID: <20040311040830.GC8016@dumbo.pobox.com> References: <700EEF5641B7E247AC1C9B82C05D125DA7B8@srv1.fecyk.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125DA7B8@srv1.fecyk.ca> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Mar 10, 2004 at 08:34:57PM -0600, Gordon Fecyk wrote: | | What of the practicality of IP+domain queries, where each e-mail causes a | query, vs domain-only queries where maybe the domain's queried once in a | while with larger responses? Block records require more parsing, but subsequent lookups suffer zero marginal DNS cost. Factored records need slightly less parsing, but each new negative means a new DNS lookup. Today, a single spam run of a million messages may come from ten thousand hosts and may forge ten thousand domains. If we focus on the "ten thousand hosts", block records look less expensive. If we focus on the "ten thousand domains", factored records look less expensive. It's all a matter of perception :) But we should keep in mind that either way the extra DNS traffic will be cheaper: - for recipients, than receiving the spam, and - for forged sender domains, than dealing with the callback verifications and bounce messages. There are a few ways the costs of DNS lookups can be classified: - initial vs marginal - cached vs uncached - positive vs negative lookup result The first time a domain sends mail, the domain-specific record is fetched. This is the INITIAL DOMAIN COST which benefits from resolver caching. The next time the domain sends mail (legitimately), the cached record is used to obtain a positive result. In most cases no additional lookup needs to be done, so there is zero POSITIVE CACHED COST. Suppose a forged message comes in. The lookup will be negative. With factored records, negatives always cost one additional DNS lookup per new negative IP, thus the NEGATIVE UNCACHED LOOKUP COST is deemed "high". With block records, negatives don't cost anything because the entire positive space has been described up front. This is a big win, at the expense of per-user and per-p granularity. With a combination of block and factored records, negatives usually don't cost anything because positives are described up front, unless the domain has used a macro to set up a per-user or per-IP exemption. Then each new negative costs one additional DNS lookup. But most domains are not expected to do this. So the cost is variable. From owner-ietf-mxcomp Wed Mar 10 20:10:37 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B4Abxa054431; Wed, 10 Mar 2004 20:10: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 i2B4AbDv054430; Wed, 10 Mar 2004 20:10:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from xuxa.iecc.com (xuxa.iecc.com [208.31.42.42]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B4AYoG054420 for ; Wed, 10 Mar 2004 20:10:35 -0800 (PST) (envelope-from johnl@iecc.com) Received: (qmail 28056 invoked by uid 100); 11 Mar 2004 04:10:40 -0000 Date: 11 Mar 2004 04:10:40 -0000 Message-ID: <20040311041040.28055.qmail@xuxa.iecc.com> From: John Levine To: wayne@midwestcs.com Subject: Re: Questions about DNS lookups in DMP and FSV Newsgroups: iecc.lists.ietf.mxcomp In-Reply-To: Organization: I.E.C.C., Trumansburg NY USA Cc: ietf-mxcomp@imc.org Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >What is this "IP+domain" thing? That is two queries, right? One for >the _smtp-client.$FQDN and one for the $REV-ADDRESS....$FQDN. It's two queries, but you usually need only to make one of them. As the FSV draft says, it panders to both camps. If you have the kind of SMTP server where you want to slurp up the data once and remember it for subsequent sessions, you fetch the TXT record that has all of the info for the domain, parse it, and remember it. If you have the kind of server that starts a new process for each session, you check the IP+domain record to see if the IP you're talking to is listed. DMP and FSV share a common problem of no easy way to tell the difference between an IP+domain record that doesn't exist because the IP isn't valid and one that doesn't exist because the domain publishes no LMAP data at all. In that case, if you care, you have to go back and check to see if the base record exists, so that'd be a second query. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY http://www.taugh.com From owner-ietf-mxcomp Wed Mar 10 20:14:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B4EXMj054818; Wed, 10 Mar 2004 20: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 i2B4EXD0054817; Wed, 10 Mar 2004 20:14:33 -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 (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B4EWH8054810 for ; Wed, 10 Mar 2004 20:14:32 -0800 (PST) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.30) id 1B1Hag-0005TN-T6; Wed, 10 Mar 2004 22:14:38 -0600 To: "Hector Santos" Cc: "IETF MXCOMP \(E-mail\)" Subject: Re: [Back to Normal] RE: Three major areas of concentration References: <404FB358.6010409@aol.net> <1194379365.20040310172424@brandenburg.com> <00aa01c40719$67a09310$6401a8c0@hdev1> From: wayne Content-Type: text/plain; charset=US-ASCII Date: Wed, 10 Mar 2004 22:14:38 -0600 In-Reply-To: <00aa01c40719$67a09310$6401a8c0@hdev1> (Hector Santos's message of "Wed, 10 Mar 2004 22:28:19 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (spfd: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <00aa01c40719$67a09310$6401a8c0@hdev1> "Hector Santos" writes: > At the moment, I take issue with how CID is used for Microsoft's proposal. > I already saw two different acronymns for Microsoft's CallerId Email Policy > proposal. CID, which I think is terrible, since it is a common acroymn used > in many systems When I first heard about "caller-id for email", I assumed that people were talking about TRUSTe/MailShell's "caller-id" which was announced back in 2001. I dunno if they trademarked the name, but MicroSoft may have to change their name if they did. See: http://www.truste.org/about/about_mailshell.html -wayne From owner-ietf-mxcomp Wed Mar 10 20:23:28 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B4NSIk055357; Wed, 10 Mar 2004 20:23: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 i2B4NSfp055356; Wed, 10 Mar 2004 20:23:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mauve.mrochek.com ([209.55.107.55]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B4NRLh055350 for ; Wed, 10 Mar 2004 20:23:28 -0800 (PST) (envelope-from ned.freed@mrochek.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01L7KNI1W9VK001X79@mauve.mrochek.com> for ietf-mxcomp@imc.org; Wed, 10 Mar 2004 20:23:33 -0800 (PST) Date: Wed, 10 Mar 2004 19:57:28 -0800 (PST) From: ned.freed@mrochek.com Subject: Re: Three major areas of concentration In-reply-to: "Your message dated Wed, 10 Mar 2004 18:33:02 -0800" <561568912.20040310183302@brandenburg.com> To: Dave Crocker Cc: wayne , ietf-mxcomp@imc.org Message-id: <01L7KPHGXPOS001X79@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <404FB358.6010409@aol.net> <1194379365.20040310172424@brandenburg.com> <561568912.20040310183302@brandenburg.com> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > w> When > w> you get to the point of identifying a particular author, I'm not sure > w> that it is so important to worry about the MTA that the email was sent > w> from. > My reading of the majority of the MTA Authentication schemes is that > they purport to validate authorship (and, therefore, really are making > statements about the From field) based on having the message transit > authorized MTAs. I don't see this at all. Most of these proposal provide a way to make assertions about what IP addresses can use a given domain in one or more fields of a message. The criteria for picking a particular field or fields for the validity check are based on an understanding of how those fields are set and handled by the email infrastructure, not on what those fields "mean". For example, the proposals that validate MAIL FROM fields don't do it because they think the field names the author of the message. Rather, they do it mostly because (0) The field is generally believed to be amenable to this sort of check, (1) Envelope information is accessible earlier in the SMTP dialogue than header information, and (2) There's a nice synergy between the way these schemes work and the way mailing lists override the MAIL FROM. The obvious downside are (1) The pesky NULL MAIL FROM used for notifications and (2) Poor interactions with autoforward. Similar advantages and disadvantages can be enumerated for using various header fields for these sorts of checks. But this isn't an attempt to identify and check the author. And not only is it well understand that this isn't what MAIL FROM is for, it is far from clear that a check of this sort based on the author's address would be meaningful. Ned From owner-ietf-mxcomp Wed Mar 10 20:24:55 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B4OtCu055443; Wed, 10 Mar 2004 20:24: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 i2B4OtgX055442; Wed, 10 Mar 2004 20:24:55 -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 (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B4OsbR055436 for ; Wed, 10 Mar 2004 20:24:55 -0800 (PST) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.30) id 1B1Hkj-0005cU-Ns; Wed, 10 Mar 2004 22:25:01 -0600 To: Dave Crocker Cc: ietf-mxcomp@imc.org Subject: Re: Three major areas of concentration References: <404FB358.6010409@aol.net> <1194379365.20040310172424@brandenburg.com> <561568912.20040310183302@brandenburg.com> <1799694351.20040310195905@brandenburg.com> From: wayne Content-Type: text/plain; charset=US-ASCII Date: Wed, 10 Mar 2004 22:25:01 -0600 In-Reply-To: <1799694351.20040310195905@brandenburg.com> (Dave Crocker's message of "Wed, 10 Mar 2004 19:59:05 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (spfd: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <1799694351.20040310195905@brandenburg.com> Dave Crocker writes: > wayne, > > w> I disagree. I know of none of the LMAP proposals that purport to > w> validate authorship. They talk about authorization and > w> authentication, but they don't try to pin down an author. > > what is the identity that is authenticated? Well, while I don't know of anyone who thinks that the MAIL FROM is the author, I do think there is a lot of misuse of the word "authentication" floating around in this area. It is my opinion that the LMAP proposals do not authenticate anything. They authorize stuff. The use authenticated data, such as the IP address and DNS information in order to determine whether something is authorized, but they don't do any authentication themselves. So, what is the identity that is authenticated? I say "mu". You are asking a question that makes no sense. Using the terms floated around here, I guess others might say the "MAIL FROM address", the "HELO domain", etc. > what is its relationship to the message and/or the transmission of the > message? Again, I can't answer this question because I don't think the LMAP proposals are about creating an authenticated identity. They talk about authorized usage. -wayne From owner-ietf-mxcomp Wed Mar 10 20:27:35 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B4RY3q055644; Wed, 10 Mar 2004 20:27: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 i2B4RYDW055643; Wed, 10 Mar 2004 20:27:34 -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 (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B4RY3c055636 for ; Wed, 10 Mar 2004 20:27:34 -0800 (PST) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.30) id 1B1HnJ-0005gv-29 for ietf-mxcomp@imc.org; Wed, 10 Mar 2004 22:27:41 -0600 To: ietf-mxcomp@imc.org Subject: Re: Questions about DNS lookups in DMP and FSV References: <20040311041040.28055.qmail@xuxa.iecc.com> From: wayne Content-Type: text/plain; charset=US-ASCII Date: Wed, 10 Mar 2004 22:27:40 -0600 In-Reply-To: <20040311041040.28055.qmail@xuxa.iecc.com> (John Levine's message of "11 Mar 2004 04:10:40 -0000") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (spfd: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <20040311041040.28055.qmail@xuxa.iecc.com> John Levine writes: >>What is this "IP+domain" thing? That is two queries, right? One for >>the _smtp-client.$FQDN and one for the $REV-ADDRESS....$FQDN. > > It's two queries, but you usually need only to make one of them. > Thanks for the answers Jonh and Gordon. The "IP+domain" thing confused me. It is, if I'm not still confused, just a shorthand way of saying $REV-ADDRESS.$ADDRESS-TYPE._smtp-client.$FQDN (And, I can see the need for an abbreviation.) -wayne From owner-ietf-mxcomp Wed Mar 10 20:34:57 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B4Yv1v056410; Wed, 10 Mar 2004 20:34: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 i2B4YvPb056409; Wed, 10 Mar 2004 20:34:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mauve.mrochek.com ([209.55.107.55]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B4Yvog056403 for ; Wed, 10 Mar 2004 20:34:57 -0800 (PST) (envelope-from ned.freed@mrochek.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01L7KNI1W9VK001X79@mauve.mrochek.com> for ietf-mxcomp@imc.org; Wed, 10 Mar 2004 20:35:01 -0800 (PST) Date: Wed, 10 Mar 2004 20:30:10 -0800 (PST) From: ned.freed@mrochek.com Subject: Re: Three major areas of concentration In-reply-to: "Your message dated Wed, 10 Mar 2004 19:59:05 -0800" <1799694351.20040310195905@brandenburg.com> To: Dave Crocker Cc: wayne , ietf-mxcomp@imc.org Message-id: <01L7KPVPB4FQ001X79@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <404FB358.6010409@aol.net> <1194379365.20040310172424@brandenburg.com> <561568912.20040310183302@brandenburg.com> <1799694351.20040310195905@brandenburg.com> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > wayne, > w> I disagree. I know of none of the LMAP proposals that purport to > w> validate authorship. They talk about authorization and > w> authentication, but they don't try to pin down an author. > what is the identity that is authenticated? As far as I can tell there isn't one. These schemes specify a particular form of authorization, not authentication. > what is its relationship to the message and/or the transmission of the > message? The formal semantics haven't been a major concern, nor is it clear they should be. (I worry about the many and varied ratholes that litter the formal semantics landscape.) These proposals are all about operational semantics. Ned From owner-ietf-mxcomp Wed Mar 10 21:51:12 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B5pC5W062585; Wed, 10 Mar 2004 21:51:12 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2B5pCqV062584; Wed, 10 Mar 2004 21:51:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B5pCke062578 for ; Wed, 10 Mar 2004 21:51:12 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2B60Hd25922; Wed, 10 Mar 2004 22:00:17 -0800 Date: Wed, 10 Mar 2004 21:51:10 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1233419205.20040310215110@brandenburg.com> To: ned.freed@mrochek.com CC: Dave Crocker , wayne , ietf-mxcomp@imc.org Subject: Re: Three major areas of concentration In-Reply-To: <01L7KPVPB4FQ001X79@mauve.mrochek.com> References: <404FB358.6010409@aol.net> <1194379365.20040310172424@brandenburg.com> <561568912.20040310183302@brandenburg.com> <1799694351.20040310195905@brandenburg.com> <01L7KPVPB4FQ001X79@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ned >> what is the identity that is authenticated? nfmc> As far as I can tell there isn't one. These schemes specify a particular form nfmc> of authorization, not authentication. If there is no authentication, then the identities can be spoofed. In fact all of these mechanisms are intended to prevent spoofing. That means they have a basis for claiming that the identity being asserted is authentic(ated). These mechanisms at a minimum involve an identity and an authentication. And then, yes, they assert an authorization. And any rate, I had intended the focus of my note to be about identities and their relationships to entities and processes. >> what is its relationship to the message and/or the transmission of the >> message? nfmc> The formal semantics haven't been a major concern, nor is it clear they should nfmc> be. (I worry about the many and varied ratholes that litter the formal nfmc> semantics landscape.) These proposals are all about operational semantics. This was not intended to go down the formal logic/computer science path. Besides being a rathole, I don't know anything about them and try to stay away from them. So, operational semantics is fine. My point is that these discussions and specifications need to have more precise and consistent use of terms than is so far typical. Perhaps the most problematic term is "sender". Often it is not clear whether this means the client MTA for the current hop or the first hop, or the author, or the entity that originally posted the message to the first MTA, or what. So let's develop some very careful definitions and use them consistently. Let's identify particular types of identities, their relationships to a message and to particular MTAs, and the "meaning" of the authorization that is being assigned to the identities. By way of offering some examples about difficulties in current discussions -- and these are really intended only as examples, so folks should not get worried about whether these are the latest drafts: draft-irtf-asrg-lmap-discussion-01.txt 1.1. Summary of the Protocols The data published by a domain includes statements as to which IP's are permitted to originate mail from the domain in SMTP EHLO/HELO and MAIL FROM. The word "originate" historically refers to the initial act of passing from an authoring MUA into the first MTA. It notably does not refer to MTA-MTA exchanges. So it says nothing about peer MTA authorization. In any event I'm not certain all that is meant in this specification. There also is the implication that the domain in the EHLO and the Mail From must be the same. Is this new constraint on SMTP really intended? draft-mengwong-spf-02.9.54.txt Abstract SMTP receivers may use these descriptions to authenticate mail and better apply local policy. Sorry, but I felt compelled to note that some proposals do, in fact, purport to do authentication. 1.1 Designated Senders SPF defines mechanisms for domain owners to designate legitimate outbound mail servers. SMTP receivers may query sender domains using these mechanisms, and decide the validity of a given SMTP transaction while that transaction is ongoing, even before any message data is Simultaneously referring to "outbound mail servers" and to peer interactions (deciding the validity of a current transaction), sound like conflicting capabilities. Perhaps they are not, but this is the sort of reference that needs to be much clearer, if we are going to make careful decisions about the real behavior and impact of a specification. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Thu Mar 11 01:47:27 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B9lRWe049583; Thu, 11 Mar 2004 01:47:27 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2B9lRvG049582; Thu, 11 Mar 2004 01:47:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from argon.connect.org.uk (argon.connectinternetsolutions.com [193.110.243.33]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B9lQ0h049570 for ; Thu, 11 Mar 2004 01:47:26 -0800 (PST) (envelope-from jrk@merseymail.com) Received: from mmail by argon.connect.org.uk with local (connectmail/exim) id 1B1Mmk-0002eA-L9 for ietf-mxcomp@imc.org; Thu, 11 Mar 2004 09:47:26 +0000 Subject: Re: Three major areas of concentration To: From: "Jon Kyme" Reply-To: "Jon Kyme" X-Mailer: [ConnectMail 3.13.0] X-connectmail-Originating-IP: 172.25.243.3 Message-Id: Date: Thu, 11 Mar 2004 09:47:26 +0000 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dave Crocker wrote: > > My reading of the majority of the MTA Authentication schemes is that > they purport to validate authorship (and, therefore, really are making > statements about the From field) based on having the message transit > authorized MTAs. > whoop! whoop! "straw man" alert! From owner-ietf-mxcomp Thu Mar 11 03:48:02 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BBm1a1060956; Thu, 11 Mar 2004 03:48:01 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2BBm1Nd060955; Thu, 11 Mar 2004 03:48:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [208.210.125.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BBm02f060946 for ; Thu, 11 Mar 2004 03:48:01 -0800 (PST) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [208.210.125.24]) by emerald.pobox.com (Postfix) with ESMTP id E787D132D06 for ; Thu, 11 Mar 2004 06:47:57 -0500 (EST) Received: by dumbo.pobox.com (Postfix, from userid 505) id 9DCB95D7; Thu, 11 Mar 2004 06:47:57 -0500 (EST) Date: Thu, 11 Mar 2004 06:47:57 -0500 From: Meng Weng Wong To: ietf-mxcomp@imc.org Subject: authentication or authorization? Message-ID: <20040311114757.GD8016@dumbo.pobox.com> References: <404FB358.6010409@aol.net> <1194379365.20040310172424@brandenburg.com> <561568912.20040310183302@brandenburg.com> <1799694351.20040310195905@brandenburg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Mar 10, 2004 at 10:25:01PM -0600, wayne wrote: | > | > what is the identity that is authenticated? | | Well, while I don't know of anyone who thinks that the MAIL FROM is | the author, I do think there is a lot of misuse of the word | "authentication" floating around in this area. | | It is my opinion that the LMAP proposals do not authenticate | anything. They authorize stuff. The use authenticated data, such as | the IP address and DNS information in order to determine whether | something is authorized, but they don't do any authentication | themselves. | I think the confusion between "authentication" and "authorization" arises from perspective. >From the sender domain's point of view, the SMTP transaction is authorized or unauthorized. >From the receiver's point of view, the sender is authenticated or unauthenticated. To the tall, the average man is short. To the short, the average man is tall. Therefore, mu. From owner-ietf-mxcomp Thu Mar 11 04:14:11 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BCEAxg062239; Thu, 11 Mar 2004 04:14: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 i2BCEAgK062238; Thu, 11 Mar 2004 04:14:10 -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.8) with SMTP id i2BCEAHx062232 for ; Thu, 11 Mar 2004 04:14:10 -0800 (PST) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v5.7.450.9b13) for ietf-mxcomp@imc.org; Thu, 11 Mar 2004 07:16:11 -0500 Received: from ([68.215.115.72]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v5.7.450.9b13) with SMTP id 3459940578; Thu, 11 Mar 2004 07:16:09 -0500 Message-ID: <002401c40762$6dcb83a0$6401a8c0@hdev1> From: "Hector Santos" To: "Meng Weng Wong" , References: <404FB358.6010409@aol.net> <1194379365.20040310172424@brandenburg.com> <561568912.20040310183302@brandenburg.com> <1799694351.20040310195905@brandenburg.com> <20040311114757.GD8016@dumbo.pobox.com> Subject: Re: authentication or authorization? Date: Thu, 11 Mar 2004 07:09:56 -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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I think we should get away from using "authentication" too. SMTP authenticated sessions in the traditional SMTP sense means "login" and more importantly allows users or senders to relay mail. LMAP "authenticated" sessions are not for relaying mail. I hope not! :-) I vote for validated, permitted or even authorized sender. But not authenticated. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com ----- Original Message ----- From: "Meng Weng Wong" To: Sent: Thursday, March 11, 2004 6:47 AM Subject: authentication or authorization? > > > I think the confusion between "authentication" and "authorization" > arises from perspective. > > From the sender domain's point of view, the SMTP transaction is > authorized or unauthorized. > > From the receiver's point of view, the sender is authenticated or > unauthenticated. > > To the tall, the average man is short. > > To the short, the average man is tall. > > Therefore, mu. > > From owner-ietf-mxcomp Thu Mar 11 07:39:26 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BFdQN1073037; Thu, 11 Mar 2004 07:39: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 i2BFdQSY073036; Thu, 11 Mar 2004 07:39:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from moebius2.Space.Net (moebius2.Space.Net [195.30.1.100]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2BFdO15073027 for ; Thu, 11 Mar 2004 07:39:24 -0800 (PST) (envelope-from maex@Space.Net) Received: (qmail 47370 invoked by uid 1013); 11 Mar 2004 15:39:21 -0000 Date: Thu, 11 Mar 2004 16:39:21 +0100 From: Markus Stumpf To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= Cc: Gordon Fecyk , "IETF MXCOMP \(E-mail\)" Subject: Re: Potential Work Item: New DNS resource records Message-ID: <20040311153921.GA1804@Space.Net> References: <700EEF5641B7E247AC1C9B82C05D125DA7B9@srv1.fecyk.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.1i Organization: SpaceNet AG, Muenchen, Germany X-PGP-Fingerprint: 66 F3 75 79 01 D0 B8 5F 1A C7 77 88 4A B6 70 DF Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Mar 11, 2004 at 11:05:21AM +0800, Patrik Fältström wrote: > [3] Add a prefix to the owner (i.e. _foo.example.com.) > Problematic for two reasons: > If we have > example.com. IN MX 10 mail.example.com. > it is for me much better to have the same owner for the "RMX" resource > record as the MX because then we know for sure both MX and the "RMX" is > in the same zone, and have to be signed by the same owner/mechanism. I don't see a problem with having both example.com. IN MX 10 mail.example.com. _srv.example.com. IN NRR ... in the same zone. I don't even see a problem with having ns4.dns.space.net in the space.net zone. The only ones up to now that seem to have a problem is the italian NIC that insisted that dns.space.net MUST have a delegation. But these are problems relevant to RMX/SPF like proposals that use forward domains and not to the others. > Second problem has to do with wildcards. > If one have > *.example.com. IN MX 10 mail.example.com. > then one can have still > *.example.com. IN RMX ... > But, if one use _foo.example.com for the mechanism, we can not have: > _foo.*.example.com. This problem only becomes evident if there is a need for wildcard records. It may even be a design goal to make wildcard records impossible to make it harder for manually managed zones to set the NRR for the whole zone. As for automated (database backed) administration it doesn't make a big difference as they would probably assign the records to every LHS explicitely. I have asked at DNSOP a while back how the Ops manage their zones and got zero response. \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" From owner-ietf-mxcomp Thu Mar 11 07:48:05 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BFm5r0073402; Thu, 11 Mar 2004 07:48:05 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2BFm553073401; Thu, 11 Mar 2004 07:48:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [208.210.125.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BFm4OM073394 for ; Thu, 11 Mar 2004 07:48:04 -0800 (PST) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [208.210.125.24]) by emerald.pobox.com (Postfix) with ESMTP id C90ED132D11 for ; Thu, 11 Mar 2004 10:48:05 -0500 (EST) Received: by dumbo.pobox.com (Postfix, from userid 505) id 7A44961F; Thu, 11 Mar 2004 10:48:05 -0500 (EST) Date: Thu, 11 Mar 2004 10:48:05 -0500 From: Meng Weng Wong To: ietf-mxcomp@imc.org Subject: Re: authentication or authorization? Message-ID: <20040311154805.GE8016@dumbo.pobox.com> References: <404FB358.6010409@aol.net> <1194379365.20040310172424@brandenburg.com> <561568912.20040310183302@brandenburg.com> <1799694351.20040310195905@brandenburg.com> <20040311114757.GD8016@dumbo.pobox.com> <002401c40762$6dcb83a0$6401a8c0@hdev1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002401c40762$6dcb83a0$6401a8c0@hdev1> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Mar 11, 2004 at 07:09:56AM -0500, Hector Santos wrote: | | I think we should get away from using "authentication" too. | | I vote for validated, permitted or even authorized sender. But not | authenticated. | Perhaps "confirmation" would be a good term. Although that runs into callback verification. "Confirmed sender", "sender confirmation", etc. From owner-ietf-mxcomp Thu Mar 11 07:59:38 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BFxcdn073912; Thu, 11 Mar 2004 07:59: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 i2BFxcig073911; Thu, 11 Mar 2004 07:59:38 -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.8) with ESMTP id i2BFxbRP073905 for ; Thu, 11 Mar 2004 07:59:38 -0800 (PST) (envelope-from aland@newgiles.nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 859D416FD1 for ; Thu, 11 Mar 2004 11:03:07 -0500 (EST) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Three major areas of concentration In-Reply-To: Your message of "Wed, 10 Mar 2004 20:30:10 PST." <01L7KPVPB4FQ001X79@mauve.mrochek.com> Date: Thu, 11 Mar 2004 11:03:07 -0500 Message-Id: <20040311160307.859D416FD1@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ned.freed@mrochek.com wrote: > > what is the identity that is authenticated? > > As far as I can tell there isn't one. These schemes specify a particular form > of authorization, not authentication. Exactly. The original version of the LMAP discussion document specifically used the word "authorization" to describe the proposal. The later version was changed to use "authentication". I do not agree with that change. Future versions of the document will revert to the original wording. I've been working in the Authorization, Authentication, and Accounting (AAA) space since 1996. I've written a AAA server. I've designed and deployed AAA solutions, and trained customers in them. The various LMAP proposals have nothing whatsoever to do with identity or authentication. Alan DeKok. From owner-ietf-mxcomp Thu Mar 11 08:01:46 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BG1kOQ074112; Thu, 11 Mar 2004 08:01:46 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2BG1kpo074111; Thu, 11 Mar 2004 08:01:46 -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 (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BG1jRl074104 for ; Thu, 11 Mar 2004 08:01:45 -0800 (PST) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.30) id 1B1Sd2-0004Uj-7w; Thu, 11 Mar 2004 10:01:48 -0600 To: Meng Weng Wong Cc: ietf-mxcomp@imc.org Subject: Re: authentication or authorization? References: <404FB358.6010409@aol.net> <1194379365.20040310172424@brandenburg.com> <561568912.20040310183302@brandenburg.com> <1799694351.20040310195905@brandenburg.com> <20040311114757.GD8016@dumbo.pobox.com> From: wayne Content-Type: text/plain; charset=US-ASCII Date: Thu, 11 Mar 2004 10:01:47 -0600 In-Reply-To: <20040311114757.GD8016@dumbo.pobox.com> (Meng Weng Wong's message of "Thu, 11 Mar 2004 06:47:57 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (spfd: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <20040311114757.GD8016@dumbo.pobox.com> Meng Weng Wong writes: > I think the confusion between "authentication" and "authorization" > arises from perspective. > > From the sender domain's point of view, the SMTP transaction is > authorized or unauthorized. > > From the receiver's point of view, the sender is authenticated or > unauthenticated. I can see your point, but I still do not agree with the use of authentication to describe what the LMAP proposals do. Just because something is authentic doesn't mean it is authorized. Hector has suggested "validated" as a better term, and that was what I was going to suggest also. -wayne From owner-ietf-mxcomp Thu Mar 11 08:28:47 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BGSlZs075515; Thu, 11 Mar 2004 08:28: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 i2BGSl8g075514; Thu, 11 Mar 2004 08:28:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [208.210.125.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BGSkSE075507 for ; Thu, 11 Mar 2004 08:28:46 -0800 (PST) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [208.210.125.24]) by emerald.pobox.com (Postfix) with ESMTP id 6C985132D10 for ; Thu, 11 Mar 2004 11:28:48 -0500 (EST) Received: by dumbo.pobox.com (Postfix, from userid 505) id CD064655; Thu, 11 Mar 2004 11:28:47 -0500 (EST) Date: Thu, 11 Mar 2004 11:28:47 -0500 From: Meng Weng Wong To: ietf-mxcomp@imc.org Subject: Re: authentication or authorization? Message-ID: <20040311162847.GF8016@dumbo.pobox.com> References: <404FB358.6010409@aol.net> <1194379365.20040310172424@brandenburg.com> <561568912.20040310183302@brandenburg.com> <1799694351.20040310195905@brandenburg.com> <20040311114757.GD8016@dumbo.pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Mar 11, 2004 at 10:01:47AM -0600, wayne wrote: | | I can see your point, but I still do not agree with the use of | authentication to describe what the LMAP proposals do. Just because | something is authentic doesn't mean it is authorized. Hector has | suggested "validated" as a better term, and that was what I was going | to suggest also. | "accountable sender" also another possibility. From owner-ietf-mxcomp Thu Mar 11 08:41:04 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BGf4WV076904; Thu, 11 Mar 2004 08: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 i2BGf3Vw076902; Thu, 11 Mar 2004 08:41:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BGex8L076875 for ; Thu, 11 Mar 2004 08:41:02 -0800 (PST) (envelope-from hadmut@danisch.de) Received: from andromeda (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i2BGetpq028888 for ietf-mxcomp@imc.org; Thu, 11 Mar 2004 17:40:55 +0100 Received: (from hadmut@localhost) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-3) id i2BGel0O019844 for ietf-mxcomp@imc.org; Thu, 11 Mar 2004 17:40:47 +0100 From: Hadmut Danisch Date: Thu, 11 Mar 2004 17:40:47 +0100 To: ietf-mxcomp@imc.org Subject: Authentication and Authorization Message-ID: <20040311164046.GA19776@danisch.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Gentlemen, instead of proposing funny words meeting anyone's personal taste it would be better to use the words as they are already defined and known. E.g. Menezes, Oorschot, Vanstone, Handbook of Applied Cryptography, p. 3: entity authentication of identification corroboration of the identity of an entity (e.g., a person, a computer terminal, a credit card, etc.) authorization conveyance, to another entity, of official sanction to do or be something validation a means to provide timeliness of authorization to use or manipulate information or resources access control restricting access to resources to privileged entities regards Hadmut From owner-ietf-mxcomp Thu Mar 11 09:43:29 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BHhTv6081484; Thu, 11 Mar 2004 09:43: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 i2BHhTN2081483; Thu, 11 Mar 2004 09:43:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BHhTlt081476 for ; Thu, 11 Mar 2004 09:43:29 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.11/) with ESMTP id i2BHhNQf016852 for ; Thu, 11 Mar 2004 09:43:23 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 11 Mar 2004 09:43:23 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: ietf-mxcomp@imc.org Subject: RE: Authentication and Authorization Date: Thu, 11 Mar 2004 09:43:20 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I agree with Hadmut, we have to use these terms in the same way the security field does. In the security world we have an established nomenclature where: Authentication = Determining that "Alice" is really Alice Attributes = Information that describes Alice Access Policy = The rules that decide who is allowed access to a resource Authorization = The decision to allow "Alice" access to a resource I don't think that an attributes service is very descriptive which is why I invented the term accreditation to replace attributes in the context of information provided by a third party about a subject. since then most people seem to have started using it and we are starting to get it used in other security contexts. So even though the term comes after the Menzies book I think it is now valid. Let us see how these apply to our problem: Sender - originator of the mail transaction Receiver - recipient of the message The Sender is not providing any authorization information in the sense that we normally use the term. It is not even an access policy. What the sender is doing here is to specify the set of credentials (IP address, public key) which SHOULD be presented by any legitimate sender from the domain. We normally use the term 'policy' for that type of information. That is exactly what we are doing in the WS-Policy spec. As for 'accountable' and 'trusted'. These terms have an important place in the description here but not as given. The objective here is to be able to identify an accountable sender. We do that by determining that the sender is authenticated (meets sender policy of the domain), that the domain is accredited and that the accreditation ensures that the sender will face significant consequences if they spam. We establish trust by demonstrating that we accept responsibility. Phill Security Blog: http://hallambakersecurity.blogspot.com/atom.xml From owner-ietf-mxcomp Thu Mar 11 10:11:46 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BIBkmw083121; Thu, 11 Mar 2004 10:11: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 i2BIBkhK083120; Thu, 11 Mar 2004 10:11:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BIBkmx083114 for ; Thu, 11 Mar 2004 10:11:46 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2BIKod05644; Thu, 11 Mar 2004 10:20:50 -0800 Date: Thu, 11 Mar 2004 10:11:43 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <594157933.20040311101143@brandenburg.com> To: =?ISO-8859-15?B?UGF0cmlrIEbkbHRzdHL2bQ==?= CC: "IETF MXCOMP (E-mail)" Subject: Re: Potential Work Item: New DNS resource records In-Reply-To: References: <700EEF5641B7E247AC1C9B82C05D125DA7B9@srv1.fecyk.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Patrik, PF> [4] Change the resource record type PF> See previous bullet, it forces the MX and the "RMX" to be in the same PF> zone, which in turn forces the records to be managed by the same PF> entity. Your analysis did not consider differences in rate of deployment and adoption. The choice involves some tradeoffs. We need to make sure that we consider them as a set. New record types have a history of taking a _very_ long time before they gain widescale usability. Given the urgency of spam control, this is an important concern. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Thu Mar 11 10:43:54 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BIhsbg084874; Thu, 11 Mar 2004 10:43:54 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2BIhsb5084873; Thu, 11 Mar 2004 10:43:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BIhqEx084867 for ; Thu, 11 Mar 2004 10:43:53 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i2BIhrlm022256; Thu, 11 Mar 2004 10:43:53 -0800 (PST) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 11 Mar 2004 10:43:51 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Hector Santos'" , Meng Weng Wong , ietf-mxcomp@imc.org Subject: RE: authentication or authorization? Date: Thu, 11 Mar 2004 10:43:51 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: No, it is authentication. Confusion with SMTP authentication is utterly irrelevant. > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Hector Santos > Sent: Thursday, March 11, 2004 7:10 AM > To: Meng Weng Wong; ietf-mxcomp@imc.org > Subject: Re: authentication or authorization? > > > > I think we should get away from using "authentication" too. > > SMTP authenticated sessions in the traditional SMTP sense > means "login" and > more importantly allows users or senders to relay mail. > > LMAP "authenticated" sessions are not for relaying mail. I > hope not! :-) > > I vote for validated, permitted or even authorized sender. But not > authenticated. > > -- > Hector Santos, Santronics Software, Inc. > http://www.santronics.com > > > > > > > > > > ----- Original Message ----- > From: "Meng Weng Wong" > To: > Sent: Thursday, March 11, 2004 6:47 AM > Subject: authentication or authorization? > > > > > > > > I think the confusion between "authentication" and "authorization" > > arises from perspective. > > > > From the sender domain's point of view, the SMTP transaction is > > authorized or unauthorized. > > > > From the receiver's point of view, the sender is authenticated or > > unauthenticated. > > > > To the tall, the average man is short. > > > > To the short, the average man is tall. > > > > Therefore, mu. > > > > > > From owner-ietf-mxcomp Thu Mar 11 11:03:14 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BJ3ECT085909; Thu, 11 Mar 2004 11:03: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 i2BJ3ETM085908; Thu, 11 Mar 2004 11:03:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BJ3DcH085902 for ; Thu, 11 Mar 2004 11:03:13 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i2BJ34Vv005567; Thu, 11 Mar 2004 11:03:12 -0800 (PST) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 11 Mar 2004 11:02:31 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Dave Crocker'" , =?ISO-8859-15?Q?Patrik_F?= =?ISO-8859-15?Q?=E4ltstr=F6m?= Cc: "IETF MXCOMP (E-mail)" Subject: RE: Potential Work Item: New DNS resource records Date: Thu, 11 Mar 2004 11:02:28 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-15" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > The choice involves some tradeoffs. We need to make sure that we > consider them as a set. > > New record types have a history of taking a _very_ long time before > they gain widescale usability. Given the urgency of spam > control, this > is an important concern. The other issue to consider is risk of fracturing the spec. This is a competative enviornment. If the choice is between a spec I can deploy today and a spec that will be agreed in two, three ten years, when the IETF feels like doing something then it is a very easy one to make. I believe the following criteria should be met: 1) Immediate deployability 2) Content of the record MUST be text based so that parsing outside the context of DNS infrastructure is easy. 3) A policy record should not be confused with other records 4) It should be possible to request only records of type policy 5) Cache friendly. I know that some people want a DNS syntax for the record. In my view that would be the death of any spec. The implementation community are not keen on XML, but they will utterly loathe a binary format. The DNS binary syntax is not as bad as ASN.1 but it is pretty yucky. The other big problem with a binary syntax is the lack of flexibility. It is pretty easy to design a text based format in an extensible way. Sure, this is not how the DNS was designed. I really don't think that the original design is of interest here. There are four basic approaches possible: 1) SPF approach, hijack the TXT record for use by SPF I don't like this approach because it fails criteria (3,4). 2) TXT record with prefix label, e.g. _spf, _ep This fills all the requirements, with the possible exception of (1) since some DNS configurations reject labels with underscores. I think in the context of an IETF proposal we can get these fixed. 3) New RR with text encoding Critical issue here is when the RR is known and fixed. If this takes more than 3 months for the code point to be known the idea is dead. 4) New RR with DNS binary encoding Sure this meets the academic purity of the DNS design. It also means that we have to wait five years before deployment can happen. It is very unlikely that the email filter companies would use the IETF suggestion rather than a defacto SPF or callerID deployment. I would like to go the _spf route. OK we can be tactful and call it _lmap. But we should decide on the code point NOW so that people who are deploying TODAY can build in code that makes allowances. It is not too difficult to write code that checks for _lmap, _ep (callerID prefix) and unprefixed SPF records in that order. But we need to tell people what to do quickly. The unspoken issue that people have raised is one of control. If people can just extend the DNS at will by defining new prefixes bad things might happen. I don't accept that argument. Phill From owner-ietf-mxcomp Thu Mar 11 11:04:25 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BJ4PlI085984; Thu, 11 Mar 2004 11:04: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 i2BJ4PTu085983; Thu, 11 Mar 2004 11:04:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from scale01.mcom.com (h-64-236-139-249.aoltw.net [64.236.139.249]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BJ4Pma085971 for ; Thu, 11 Mar 2004 11:04:25 -0800 (PST) (envelope-from aoki@aol.net) Received: from aol.net ([10.178.176.188]) by scale01.nscp.aoltw.net (Netscape Messaging Server 6.1 (built Oct 3 2002)) with ESMTPA id <0HUF00DEREA6GV@scale01.nscp.aoltw.net> for ietf-mxcomp@imc.org; Thu, 11 Mar 2004 11:03:44 -0800 (PST) Date: Thu, 11 Mar 2004 11:04:25 -0800 From: Edwin Aoki Subject: Re: Authentication and Authorization In-reply-to: To: ietf-mxcomp@imc.org Message-id: <4050B839.6070009@aol.net> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031007 References: Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: There are some really good points here that I think we'd do well to adopt. Nonetheless, I still see one issue that seems to keep coming back in every discussion that I've had in every context of spam prevention: There are multiple entities being authenticated and multiple decisions made to authorize. Let me see if I can try to put this into an example: I (Edwin Aoki, aoki@aol.net) try to send a piece of mail to (for example) Dave Crocker. In my mind, here are the various sender assertions that could be made (without reference to any specific proposal): * I, Edwin Aoki, authored (created) this message * I, Edwin Aoki, sent (caused to be injected into the mail stream) this message * A machine at 1.2.3.4 is authorized to send mail * A machine at 1.2.3.4 is authorized to send mail on behalf of AOL (aol.net) And at the receiver, I can use the information asserted by the sender to make assertions such as: * I can verify that Edwin Aoki authored this message (or not) * The MTA from which my MTA received this message is listed as being allowed to send mail (or not) * The MTA from which my MTA received this message is listed as being allowed to send mail on behalf of the domain listed in the message (or not). I think one of the things that hangs us up is the notion that authorization is built into any of these proposals. They aren't. They provide a mechanism for the sending domains to list various assertions ("Policy" below, which I think is a fine term), that receiving MTAs can then use to make authorization decisions. But also note that there are two different "senders" here. The individual who created the message (author) and the MTA from which any given MTA receives a message. I don't want to get into a semantic argument either, but we need to get some clarification on the terms we're using, or we're never going to be able to communicate this out to the world. We need to have a way to tell people, "In order to implement a policy x, you must do these steps y." And receiving MTAs can make a statement that says, "we will only accept mail from senders with policy z." Further, authors and receiving users can make other assertions/decisions (such as "I, Dave Crocker, will only accept mail that has a verifiable signature,") but that's out of scope for this group. -Edwin Hallam-Baker, Phillip wrote: >I agree with Hadmut, we have to use these terms in the same way the security >field does. > >In the security world we have an established nomenclature where: > >Authentication = Determining that "Alice" is really Alice >Attributes = Information that describes Alice >Access Policy = The rules that decide who is allowed access to a resource > >Authorization = The decision to allow "Alice" access to a resource > > >I don't think that an attributes service is very descriptive which is why I >invented the term accreditation to replace attributes in the context of >information provided by a third party about a subject. since then most >people seem to have started using it and we are starting to get it used in >other security contexts. So even though the term comes after the Menzies >book I think it is now valid. > >Let us see how these apply to our problem: > >Sender - originator of the mail transaction >Receiver - recipient of the message > > >The Sender is not providing any authorization information in the sense that >we normally use the term. It is not even an access policy. What the sender >is doing here is to specify the set of credentials (IP address, public key) >which SHOULD be presented by any legitimate sender from the domain. > >We normally use the term 'policy' for that type of information. That is >exactly what we are doing in the WS-Policy spec. > > >As for 'accountable' and 'trusted'. These terms have an important place in >the description here but not as given. The objective here is to be able to >identify an accountable sender. We do that by determining that the sender is >authenticated (meets sender policy of the domain), that the domain is >accredited and that the accreditation ensures that the sender will face >significant consequences if they spam. > >We establish trust by demonstrating that we accept responsibility. > > > Phill > >Security Blog: http://hallambakersecurity.blogspot.com/atom.xml > > > From owner-ietf-mxcomp Thu Mar 11 11:09:10 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BJ9AJ7086264; Thu, 11 Mar 2004 11: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 i2BJ9AgM086263; Thu, 11 Mar 2004 11:09:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (mail.winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2BJ99YP086256 for ; Thu, 11 Mar 2004 11:09:10 -0800 (PST) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v5.7.450.9b13) for ietf-mxcomp@imc.org; Thu, 11 Mar 2004 14:11:11 -0500 Received: from ([68.215.115.72]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v5.7.450.9b13) with SMTP id 3484841468; Thu, 11 Mar 2004 14:11:10 -0500 Message-ID: <007e01c4079c$68c4d840$6401a8c0@hdev1> From: "Hector Santos" To: References: Subject: Re: authentication or authorization? Date: Thu, 11 Mar 2004 14:08:48 -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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Thats fine by me, but lets make sure we make the clear distinction that: 1) SMTP authentication provides a policy for senders (usually MUA or router) to relay mail 2) LMAP authentication provides a "amonymous access" policy for senders to send final destination mail only. Unless I completely missed the boat, LMAP authentication is not for relaying mail. Relaying managment is already addressed. Hell, we "google" all the time now. Maybe I just begin using "lmap" exclusively as a new term in a new industry: "Got LMAP?" "The sender was lmapped as a legimate sender" "logs: LMAP sender 1.2.3.4 "We lmapped our system to control spam!" "You are not a LMAP system... that is why your mail was rejected." -- Hector Santos, Santronics Software, Inc. http://www.santronics.com ----- Original Message ----- From: "Hallam-Baker, Phillip" To: "'Hector Santos'" ; "Meng Weng Wong" ; Sent: Thursday, March 11, 2004 1:43 PM Subject: RE: authentication or authorization? > > No, it is authentication. > > Confusion with SMTP authentication is utterly irrelevant. > > > -----Original Message----- > > From: owner-ietf-mxcomp@mail.imc.org > > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Hector Santos > > Sent: Thursday, March 11, 2004 7:10 AM > > To: Meng Weng Wong; ietf-mxcomp@imc.org > > Subject: Re: authentication or authorization? > > > > > > > > I think we should get away from using "authentication" too. > > > > SMTP authenticated sessions in the traditional SMTP sense > > means "login" and > > more importantly allows users or senders to relay mail. > > > > LMAP "authenticated" sessions are not for relaying mail. I > > hope not! :-) > > > > I vote for validated, permitted or even authorized sender. But not > > authenticated. > > > > -- > > Hector Santos, Santronics Software, Inc. > > http://www.santronics.com > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > From: "Meng Weng Wong" > > To: > > Sent: Thursday, March 11, 2004 6:47 AM > > Subject: authentication or authorization? > > > > > > > > > > > > > I think the confusion between "authentication" and "authorization" > > > arises from perspective. > > > > > > From the sender domain's point of view, the SMTP transaction is > > > authorized or unauthorized. > > > > > > From the receiver's point of view, the sender is authenticated or > > > unauthenticated. > > > > > > To the tall, the average man is short. > > > > > > To the short, the average man is tall. > > > > > > Therefore, mu. > > > > > > > > > > > > From owner-ietf-mxcomp Thu Mar 11 11:19:00 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BJJ0pd086712; Thu, 11 Mar 2004 11:19: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 i2BJJ0RK086711; Thu, 11 Mar 2004 11:19:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BJIxod086704 for ; Thu, 11 Mar 2004 11:18:59 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i2BJIuwW017643; Thu, 11 Mar 2004 11:19:01 -0800 (PST) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 11 Mar 2004 11:18:34 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Edwin Aoki'" , ietf-mxcomp@imc.org Subject: RE: Authentication and Authorization Date: Thu, 11 Mar 2004 11:18:24 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > There are some really good points here that I think we'd do well to > adopt. Nonetheless, I still see one issue that seems to keep coming > back in every discussion that I've had in every context of > spam prevention: > > There are multiple entities being authenticated and multiple > decisions > made to authorize. Let me see if I can try to put this into > an example: There are different perspectives on the same data. I may authorize a party to send, but I cannot make a decision to you the receiver. Therefore any information published in the DNS that describes the result of my authorization decision is IN YOUR CONTEXT policy or accreditation information. > I (Edwin Aoki, aoki@aol.net) try to send a piece of mail to (for > example) Dave Crocker. > > In my mind, here are the various sender assertions that could be made > (without reference to any specific proposal): > > * I, Edwin Aoki, authored (created) this message > * I, Edwin Aoki, sent (caused to be injected into the mail > stream) this message > * A machine at 1.2.3.4 is authorized to send mail This would be a policy statement. Actually I think it is really bad to think of any statement about the IP address as an authorization or even a policy statement. If the IP address is not authorized to send mail the packets should never have left the network - PERIOD END OF STORY. If a machine at 1.2.3.4 can connect to port 25 on machines outside its own network it has empirically been authorized to do so. The packets have crossed the firewall (and please, do not try to bring up the end-to-end crock, perimeter security is not a bogus artifact that will go away some day). The only reason the perimeter security will receive less emphasis in the future is that the controls will migrate down to the level of ethernet hubs. I would prefer here to have a descriptive statement. "1.2.3.4 is a statically allocated IP address for which the accountable domain is AOL.NET." "1.2.3.4 is allocated to a dialup modem pool" "1.2.3.4 is allocated to a pool of addresses allocated on request to broadband residential customers of an ISP" This is accreditation information that the recipient can feed into their decision process. If one of those residential users decides that they are going to run their own mail server, sets up the correct SPF configs and gets themselves accredited there is no reason to drop email from this source. > * A machine at 1.2.3.4 is authorized to send mail on behalf > of AOL (aol.net) The email sending policy of AOL.net is that the machines must have an IP address of (..., 1.2.3.4, ... ) > And at the receiver, I can use the information asserted by > the sender to > make assertions such as: > > * I can verify that Edwin Aoki authored this message (or not) > * The MTA from which my MTA received this message is listed as being > allowed to send mail (or not) > * The MTA from which my MTA received this message is listed as being > allowed to send mail on behalf of the domain listed in the > message (or not). > > I think one of the things that hangs us up is the notion that > authorization is built into any of these proposals. They > aren't. They > provide a mechanism for the sending domains to list various > assertions > ("Policy" below, which I think is a fine term), that > receiving MTAs can > then use to make authorization decisions. But also note that > there are > two different "senders" here. The individual who created the message > (author) and the MTA from which any given MTA receives a message. > > I don't want to get into a semantic argument either, but we > need to get > some clarification on the terms we're using, or we're never > going to be > able to communicate this out to the world. We need to have a way to > tell people, "In order to implement a policy x, you must do > these steps > y." And receiving MTAs can make a statement that says, "we will only > accept mail from senders with policy z." Further, authors > and receiving > users can make other assertions/decisions (such as "I, Dave Crocker, > will only accept mail that has a verifiable signature,") but > that's out > of scope for this group. > > -Edwin > > > Hallam-Baker, Phillip wrote: > > >I agree with Hadmut, we have to use these terms in the same > way the security > >field does. > > > >In the security world we have an established nomenclature where: > > > >Authentication = Determining that "Alice" is really Alice > >Attributes = Information that describes Alice > >Access Policy = The rules that decide who is allowed > access to a resource > > > >Authorization = The decision to allow "Alice" access > to a resource > > > > > >I don't think that an attributes service is very descriptive > which is why I > >invented the term accreditation to replace attributes in the > context of > >information provided by a third party about a subject. since > then most > >people seem to have started using it and we are starting to > get it used in > >other security contexts. So even though the term comes after > the Menzies > >book I think it is now valid. > > > >Let us see how these apply to our problem: > > > >Sender - originator of the mail transaction > >Receiver - recipient of the message > > > > > >The Sender is not providing any authorization information in > the sense that > >we normally use the term. It is not even an access policy. > What the sender > >is doing here is to specify the set of credentials (IP > address, public key) > >which SHOULD be presented by any legitimate sender from the domain. > > > >We normally use the term 'policy' for that type of > information. That is > >exactly what we are doing in the WS-Policy spec. > > > > > >As for 'accountable' and 'trusted'. These terms have an > important place in > >the description here but not as given. The objective here is > to be able to > >identify an accountable sender. We do that by determining > that the sender is > >authenticated (meets sender policy of the domain), that the domain is > >accredited and that the accreditation ensures that the > sender will face > >significant consequences if they spam. > > > >We establish trust by demonstrating that we accept responsibility. > > > > > > Phill > > > >Security Blog: http://hallambakersecurity.blogspot.com/atom.xml > > > > > > > From owner-ietf-mxcomp Thu Mar 11 11:39:55 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BJdtFS088046; Thu, 11 Mar 2004 11:39: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 i2BJdt3R088045; Thu, 11 Mar 2004 11:39:55 -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.8) with ESMTP id i2BJdqqZ088037 for ; Thu, 11 Mar 2004 11:39:54 -0800 (PST) (envelope-from aland@newgiles.nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 6BBDE170F3 for ; Thu, 11 Mar 2004 14:43:22 -0500 (EST) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Economics & deployment (was Re: Everyone back from Seoul yet? ) In-Reply-To: Your message of "Wed, 10 Mar 2004 14:06:05 EST." <4242.66.114.246.101.1078945565.squirrel@66.114.246.101> Date: Thu, 11 Mar 2004 14:43:22 -0500 Message-Id: <20040311194323.6BBDE170F3@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: millenix@zemos.net wrote: > No matter how much we wish, the Internet economy will not become efficient > for the sake of stopping spam. That price increase will never occur, > because there won't be upstream price increases in the domain registration > and web-hosting businesses. Agreed. So far as incentive goes, I just got my hands on an interesting set of data. It's stats for about a week of email traffic, from a system monitoring a large proportion of the SMTP traffic on the net. The quick conclusions are: - a simple whitelist of 75K IP's would allow 90% of non-spam messages through, some volume of spam, and would block 10% of non-spam messages. - to allow 99% of non-spam through, the list would be ~200K IP's. - 120 IP addresses account for 10% of the sent messages. So there are ~200K IP addresses which send small to large amounts of non-spam, and which stick around for most of the week. "Legitimate" senders with miniscule sending volumes were not included in this sample. These numbers mean that we know have a bit better feel for deployment costs of any solution. A solution which covers ~10^5 of the largest sending IP's means that greater than 90% of the legitimate traffic will be included in the solution. These numbers are relatively small, which makes it much easier to believe that the spam problem is solvable. Alan DeKok. From owner-ietf-mxcomp Thu Mar 11 11:48:46 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BJmjp7088791; Thu, 11 Mar 2004 11:48: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 i2BJmjvf088790; Thu, 11 Mar 2004 11:48:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BJmjs4088784 for ; Thu, 11 Mar 2004 11:48:45 -0800 (PST) (envelope-from hardie@qualcomm.com) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i2BJmkvf029562; Thu, 11 Mar 2004 11:48:46 -0800 (PST) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i2BJmilH009210; Thu, 11 Mar 2004 11:48:44 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <4050B839.6070009@aol.net> References: <4050B839.6070009@aol.net> Date: Thu, 11 Mar 2004 11:48:44 -0800 To: Edwin Aoki , ietf-mxcomp@imc.org From: Ted Hardie Subject: Re: Authentication and Authorization Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 11:04 AM -0800 03/11/2004, Edwin Aoki wrote: >There are some really good points here that I think we'd do well to >adopt. Nonetheless, I still see one issue that seems to keep coming >back in every discussion that I've had in every context of spam >prevention: > >There are multiple entities being authenticated and multiple >decisions made to authorize. Let me see if I can try to put this >into an example: > >I (Edwin Aoki, aoki@aol.net) try to send a piece of mail to (for >example) Dave Crocker. > >In my mind, here are the various sender assertions that could be >made (without reference to any specific proposal): > >* I, Edwin Aoki, authored (created) this message >* I, Edwin Aoki, sent (caused to be injected into the mail stream) >this message >* A machine at 1.2.3.4 is authorized to send mail >* A machine at 1.2.3.4 is authorized to send mail on behalf of AOL (aol.net) > >And at the receiver, I can use the information asserted by the >sender to make assertions such as: > >* I can verify that Edwin Aoki authored this message (or not) >* The MTA from which my MTA received this message is listed as being >allowed to send mail (or not) >* The MTA from which my MTA received this message is listed as being >allowed to send mail on behalf of the domain listed in the message >(or not). I believe the scope of the work we taking on is about MTA authorizaton, rather than verification of authorship or permission to inject into the mail stream. Assuming for a moment that the available mechanisms to check the credentials of those injecting mail into the stream are used, I believe the point we're trying to reach is: "* The MTA from which my MTA received this message is listed as being allowed to send mail on behalf of the domain listed in the message (or not)." From a very high level perspective, there are two ways of achieving that: Publish a record that describes the set of MTAs allowed to send mail on behalf of a domain, and then check to ensure that an MTA is a member of that set. Publish a record for each MTA that describes what it is permitted to do, then check those permissions against what the MTA is attempting. Speaking personally, I don't see much point in saying that an MTA is permitted to speak on behalf of *any* domain, as assertions of that type seem to me to lead toward the same arguments that closed down most open relays. So my take is that a record published about an MTA would have to describe for which domains it is permitted send mail. If that is correct, the key questions look like "is it operationally more sensible to publish a description of the set, and have recipients check the set, or publish the MTA record and have recipients check the record?" and "is the optimization required for handling a set harder or easier than the optimizations required for handling an MTA record". Buried in both is a question about how trust in the answer received is managed. Speaking personally, obviously, not in any particular role, regards, Ted Hardie From owner-ietf-mxcomp Thu Mar 11 11:40:15 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BJeFOq088084; Thu, 11 Mar 2004 11:40: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 i2BJeFNg088083; Thu, 11 Mar 2004 11:40:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from moebius2.Space.Net (moebius2.Space.Net [195.30.1.100]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2BJeCIg088073 for ; Thu, 11 Mar 2004 11:40:13 -0800 (PST) (envelope-from maex@Space.Net) Received: (qmail 66063 invoked by uid 1013); 11 Mar 2004 19:40:15 -0000 Date: Thu, 11 Mar 2004 20:40:15 +0100 From: Markus Stumpf To: "IETF MXCOMP \(E-mail\)" Subject: Re: Potential Work Item: New DNS resource records Message-ID: <20040311194015.GB56829@Space.Net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Organization: SpaceNet AG, Muenchen, Germany X-PGP-Fingerprint: 66 F3 75 79 01 D0 B8 5F 1A C7 77 88 4A B6 70 DF Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Mar 11, 2004 at 11:02:28AM -0800, Hallam-Baker, Phillip wrote: > 2) TXT record with prefix label, e.g. _spf, _ep > This fills all the requirements, with the possible exception > of (1) since some DNS configurations reject labels with > underscores. I think in the context of an IETF proposal we > can get these fixed. This is not a problem at all, as this kind of notation is already widely used and well defined for SRV records. > I would like to go the _spf route. OK we can be tactful and call it > _lmap. But we should decide on the code point NOW so that people > who are deploying TODAY can build in code that makes allowances. With a look at the future and not to pollute the flat namespace too much it would probably be a good idea to make a group (this is not a proposal for a name) _antispam.example.com and put the _lmap in there so to have _lmap._antispam.example.com. Thinking about that a bit more "_policy" might be a nice name to use for the subdomain. This also has the advantage that if we need more than one piece of information, like if we want to publish policies (nospam, optout, optin doubleoptin, ...) and SPF/RMX information we would not need to put it all into one big fat complicated record. \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" From owner-ietf-mxcomp Thu Mar 11 11:55:10 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BJtAO4089151; Thu, 11 Mar 2004 11:55: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 i2BJtAoS089150; Thu, 11 Mar 2004 11:55:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BJt82T089142 for ; Thu, 11 Mar 2004 11:55:09 -0800 (PST) (envelope-from hadmut@danisch.de) Received: from andromeda (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i2BJt74Z001694; Thu, 11 Mar 2004 20:55:07 +0100 Received: (from hadmut@localhost) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-3) id i2BJpl4r023808; Thu, 11 Mar 2004 20:51:47 +0100 From: Hadmut Danisch Date: Thu, 11 Mar 2004 20:51:47 +0100 To: Edwin Aoki Cc: ietf-mxcomp@imc.org Subject: Re: Authentication and Authorization Message-ID: <20040311195147.GA23688@danisch.de> References: <4050B839.6070009@aol.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4050B839.6070009@aol.net> User-Agent: Mutt/1.5.5.1+cvs20040105i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Mar 11, 2004 at 11:04:25AM -0800, Edwin Aoki wrote: > > I (Edwin Aoki, aoki@aol.net) try to send a piece of mail to (for > example) Dave Crocker. That's good to start an example, but that's the most simple case only and does not cover the pathological cases. > * I, Edwin Aoki, authored (created) this message That's clearly a matter of digital signatures. While this is beyond the scope of SMTP verification, the authorization record could contain a fingerprint of a pubkey or CA. > * I, Edwin Aoki, sent (caused to be injected into the mail stream) this > message That will be difficult. It's neither message authentication (because you're not author here), nor entity authentication (because you're not sending MTA and communication peer). A solution would be to create and additional pseudo-message, containing of MessageID, Hash Sum of body, sender, recipient address and a digital signature, encoded e.g. in a header line. > * A machine at 1.2.3.4 is authorized to send mail > * A machine at 1.2.3.4 is authorized to send mail on behalf of AOL > (aol.net) What's the point in the former one? If the latter one is true for any domain, what do you need the former for? If the latter one is not true for any domain, what's the use of the former? I do not strictly object, but this needs to be defined more precisely. > I think one of the things that hangs us up is the notion that > authorization is built into any of these proposals. They aren't. They > provide a mechanism for the sending domains to list various assertions > ("Policy" below, which I think is a fine term), that receiving MTAs can > then use to make authorization decisions. I believe here is some confusion about the term "authorization". RMX and similar records are authorization statements. Why shouldn't they be? Policy is the wrong term here. A policy would be to reject all messages which fail the LMAP/RMX/... check, i.e. how to treat messages which failed the authorization check. > But also note that there are > two different "senders" here. The individual who created the message > (author) and the MTA from which any given MTA receives a message. There are three: - author - transmission initiator (the one injecting into the mail network) - sender (MTA) > I don't want to get into a semantic argument either, but we need to get > some clarification on the terms we're using, or we're never going to be > able to communicate this out to the world. We therefore should use the terms as they have been defined outside in the world instead trying to redefine. > And receiving MTAs can make a statement that says, "we will only > accept mail from senders with policy z." Further, authors and receiving > users can make other assertions/decisions (such as "I, Dave Crocker, > will only accept mail that has a verifiable signature,") but that's out > of scope for this group. There is also a proposal to publish such a statement in common, prior to receiving an MTA. Before injecting the message I could lookup and learn that Dave is willing to accept messages with a digital signature only _before_ sending or even before writing the message. regards Hadmut From owner-ietf-mxcomp Thu Mar 11 12:09:04 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BK94WF090050; Thu, 11 Mar 2004 12:09: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 i2BK94eU090049; Thu, 11 Mar 2004 12:09:04 -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 (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BK933r090043 for ; Thu, 11 Mar 2004 12:09:03 -0800 (PST) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.30) id 1B1WUN-0007ia-AX for ietf-mxcomp@imc.org; Thu, 11 Mar 2004 14:09:07 -0600 To: ietf-mxcomp@imc.org Subject: Re: Potential Work Item: New DNS resource records References: <20040311194015.GB56829@Space.Net> From: wayne Content-Type: text/plain; charset=US-ASCII Date: Thu, 11 Mar 2004 14:09:06 -0600 In-Reply-To: <20040311194015.GB56829@Space.Net> (Markus Stumpf's message of "Thu, 11 Mar 2004 20:40:15 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (spfd: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <20040311194015.GB56829@Space.Net> Markus Stumpf writes: > On Thu, Mar 11, 2004 at 11:02:28AM -0800, Hallam-Baker, Phillip wrote: >> 2) TXT record with prefix label, e.g. _spf, _ep >> This fills all the requirements, with the possible exception >> of (1) since some DNS configurations reject labels with >> underscores. I think in the context of an IETF proposal we >> can get these fixed. > > This is not a problem at all, as this kind of notation is already widely > used and well defined for SRV records. The last time the SPF folks investigated where to place their TXT record, it was determined that a non-trivial number of web-based DNS administration systems (registrars, DNS providers, etc.) could not handle the underscore. Some can not deal with adding TXT records, and most do not allow you to add arbitrary RRs. I agree with Phillip here. I think that in the context of an IETF proposal, we can get these fixed, but there ARE problems that need to be fixed. Last fall, when it looked like SPF deployment would be going a lot slower, it was decided that using an underscore would be too much of a hurdle for rapid adoption. It was also determined that the usage of TXT records is low enough that there wasn't a need to place them in a subdomain in order to keep the DNS queries under 512 bytes. -wayne From owner-ietf-mxcomp Thu Mar 11 12:13:29 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BKDTmf090367; Thu, 11 Mar 2004 12:13: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 i2BKDTn8090366; Thu, 11 Mar 2004 12:13:29 -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.8) with ESMTP id i2BKDTo9090360 for ; Thu, 11 Mar 2004 12:13:29 -0800 (PST) (envelope-from aland@newgiles.nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 02F25170F3 for ; Thu, 11 Mar 2004 15:17:02 -0500 (EST) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Authentication and Authorization In-Reply-To: Your message of "Thu, 11 Mar 2004 20:51:47 +0100." <20040311195147.GA23688@danisch.de> Date: Thu, 11 Mar 2004 15:17:01 -0500 Message-Id: <20040311201703.02F25170F3@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hadmut Danisch wrote: > I believe here is some confusion about the term "authorization". > RMX and similar records are authorization statements. Why shouldn't > they be? > > Policy is the wrong term here. A policy would be to reject all > messages which fail the LMAP/RMX/... check, i.e. how to treat messages > which failed the authorization check. The domain publishing LMAP information is publishing a policy: Who is authorized to use it's name. The MTA receiving an SMTP connection may choose to enforce that policy. That enforcement is called authorization. Alan DeKok. From owner-ietf-mxcomp Thu Mar 11 12:15:22 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BKFMYu090451; Thu, 11 Mar 2004 12:15: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 i2BKFMAV090450; Thu, 11 Mar 2004 12:15:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BKFLSR090444 for ; Thu, 11 Mar 2004 12:15:21 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2BKORd15982; Thu, 11 Mar 2004 12:24:27 -0800 Date: Thu, 11 Mar 2004 12:15:20 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1138576445.20040311121520@brandenburg.com> To: Edwin Aoki CC: ietf-mxcomp@imc.org Subject: Re: Authentication and Authorization In-Reply-To: <4050B839.6070009@aol.net> References: <4050B839.6070009@aol.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Edwin, Thank you for pursuing a case analysis of terminology and assertions. I believe we really do need to become very precise and consistent in the terms we are using. This gets cumbersome, but the alternative vagueness that we suffer from is worse. I've put quotation marks around suggested terms, just to make them clear. Let me suggest a few modifications: EA> * I, Edwin Aoki, authored (created) this message EA> * I, Edwin Aoki, sent (caused to be injected into the mail stream) this EA> message I believe that the recent history of using the word "sender" in for so many different roles renders it useful as a precise label. Further, the historical term for the injection event is "post". Hence we have an author and a poster, possibly the same and possibly different. (The historical term for author is originator, but i frankly think that author goes to the matter of content better.) EA> * A machine at 1.2.3.4 is authorized to send mail EA> * A machine at 1.2.3.4 is authorized to send mail on behalf of AOL (aol.net) and: * A machine at 1.2.3.4 is authorized to send mail on behalf of the "author". * A machine at 1.2.3.4 is authorized to send mail on behalf of the "poster". EA> And at the receiver, I can use the information asserted by the sender to EA> make assertions such as: EA> * I can verify that Edwin Aoki authored this message (or not) EA> * The MTA from which my MTA received this message is listed as being EA> allowed to send mail (or not) -> allowed to operate a "client SMTP". EA> * The MTA from which my MTA received this message is listed as being EA> allowed to send mail on behalf of the domain listed in the message (or not). -> allowed to operate a "client SMTP" on behalf of the domain listed in the right-hand-side of the "RFC2822 From" field. and -> allowed to operate a client SMTP on behalf of the domain listed in the right-hand-side of the "RFC2822 Sender" field. EA> I think one of the things that hangs us up is the notion that EA> authorization is built into any of these proposals. They aren't. the phrase "allowed to operate" is denotationally a matter of authorization. EA> But also note that there are EA> two different "senders" here. The individual who created the message EA> (author) and the MTA from which any given MTA receives a message. yes! d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Thu Mar 11 12:20:16 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BKKGAR090636; Thu, 11 Mar 2004 12:20:16 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2BKKGpu090635; Thu, 11 Mar 2004 12:20:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BKKFUF090629 for ; Thu, 11 Mar 2004 12:20:15 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2BKTMd16555; Thu, 11 Mar 2004 12:29:22 -0800 Date: Thu, 11 Mar 2004 12:20:14 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <524330962.20040311122014@brandenburg.com> To: Ted Hardie CC: ietf-mxcomp@imc.org Subject: Re: Authentication and Authorization In-Reply-To: References: <4050B839.6070009@aol.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ted, TH> I believe the point we're trying to reach is: TH> "* The MTA from which my MTA received this message is listed as being TH> allowed to send mail on behalf of the domain listed in the message TH> (or not)." "domain listed in the message" could mean the RFC2822 From, RFC2822 Sender, the SMTP Mail-From, or possibly even the SMTP EHLO. Beyond "listed in the message" is being authorized by the containing service provider to act as a client MTA. (I'll leave out RFC2822 Reply-To, since I do not think anyone considers it a viable example.) These involve very different identity roles. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Thu Mar 11 12:22:07 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BKM70t090767; Thu, 11 Mar 2004 12:22:07 -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 i2BKM7tt090762; Thu, 11 Mar 2004 12:22:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BKM3sI090701 for ; Thu, 11 Mar 2004 12:22:04 -0800 (PST) (envelope-from hadmut@danisch.de) Received: from andromeda (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i2BKM6XR002585; Thu, 11 Mar 2004 21:22:06 +0100 Received: (from hadmut@localhost) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-3) id i2BKLSv9024069; Thu, 11 Mar 2004 21:21:28 +0100 From: Hadmut Danisch Date: Thu, 11 Mar 2004 21:21:28 +0100 To: Alan DeKok Cc: ietf-mxcomp@imc.org Subject: Re: Authentication and Authorization Message-ID: <20040311202128.GA24025@danisch.de> References: <20040311195147.GA23688@danisch.de> <20040311201703.02F25170F3@mail.nitros9.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040311201703.02F25170F3@mail.nitros9.org> User-Agent: Mutt/1.5.5.1+cvs20040105i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Mar 11, 2004 at 03:17:01PM -0500, Alan DeKok wrote: > > The domain publishing LMAP information is publishing a policy: Who > is authorized to use it's name. No. That's not a policy, that's authorization. > The MTA receiving an SMTP connection > may choose to enforce that policy. That enforcement is called > authorization. No. The receiving MTA is enforcing it's own policy. It's the receiver's policy to accept, tag, reject, burn unauthorized messages. Be careful with wording here. You just swapped them. regards Hadmut From owner-ietf-mxcomp Thu Mar 11 12:22:20 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BKMJkE091053; Thu, 11 Mar 2004 12:22: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 i2BKMJ5r091052; Thu, 11 Mar 2004 12:22:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (mail.winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2BKMJKs091019 for ; Thu, 11 Mar 2004 12:22:19 -0800 (PST) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v5.7.450.9b13) for ietf-mxcomp@imc.org; Thu, 11 Mar 2004 15:24:20 -0500 Received: from ([68.215.115.72]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v5.7.450.9b13) with SMTP id 3489230171; Thu, 11 Mar 2004 15:24:19 -0500 Message-ID: <00cf01c407a6$a0ccabf0$6401a8c0@hdev1> From: "Hector Santos" To: "Edwin Aoki" , References: <4050B839.6070009@aol.net> Subject: Re: Authentication and Authorization Date: Thu, 11 Mar 2004 15:22:43 -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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----- Original Message ----- From: "Edwin Aoki" To: Sent: Thursday, March 11, 2004 2:04 PM Subject: Re: Authentication and Authorization > > There are multiple entities being authenticated and multiple decisions > made to authorize. Let me see if I can try to put this into an example: In my analysis you have 50-55 scenarios! :-) > I (Edwin Aoki, aoki@aol.net) try to send a piece of mail to (for > example) Dave Crocker. > > In my mind, here are the various sender assertions that could be made > (without reference to any specific proposal): > > * I, Edwin Aoki, authored (created) this message > * I, Edwin Aoki, sent (caused to be injected into the mail stream) this > message > * A machine at 1.2.3.4 is authorized to send mail > * A machine at 1.2.3.4 is authorized to send mail on behalf of AOL (aol.net) How about a real example with a real AOL.COM transaction as captured by my logs. Maybe you can shed some light into this: ip: 172.176.112.164 helo acb070a4.ipt.aol.com mail from: rcpt to: Keep in mind the following: My LMAP validation and trust analysis has shown that factoring in all envelope parameters plays a major role in LMAP conclusions and specifically how each SPF and DMP differ. In addition, LMAP is for final destination only and local spoofing has been eliminated from the picture. In this example, there are no DMP records, so this would be a "no decision" result. For SPF, both domains offer a SPF policy with the following possibly result: FROM domain: softfail HELO domain: none (when using subdomain SPF lookup) HELO domain: neutral (when using the parent domain SPF lookup) So here we have a "mixed policy" situation and the question is, who provails? If the HELO domain says the machine is part of a SPF domain network, then the assertion is that the machine is valid as a sender. In other words, the only possible SPF results for a HELO lookup is none, pass or reject. Nothing in between. No neutral or softfail. This goes back to the assertion that the originating MTA established an authenticated session with the user and internal domain routers were within a trusted network. This can only be broken if the sender machine is also a receiver and it is an open relay. Analyzing how the message could of been injected into the aol.com network, a direct connect on port 25 to acb070a4.ipt.aol.com is not available, hence one possible topology for this would have to be: MUA --1--> aol.com --2--> acb070a4.ipt.aol.com --3--> winserver.com Transaction #1 must be an authenticated session in order for the originating MTA (aol.com) to allow the relay to winserver.com. Once injected into aol.com, transaction #2 "must" be trusted. If this is not the case, then in my opinion, then all bets are off with SPF (or LMAP in general). Even if the topology was single hop: MUA --1--> aol.com ---3--> winserver.com what it says is that the sender machine must first be validated as a possible sender before the return path domain LMAP relationship can be determined. May question to you is how is this transaction possible? I can only assume it is legitimate as it comes from a AOL.COM machine. In a system with mixed policies, it may suggest that the client domain (helo) may have a stronger role in the final outcome. In summary: 1) LMAP Proposals need to review Mixed policy situations. I am nearly finished with my LMAP trust analysis which show 45 to 50 of the total 55 possibiliies with mix policy situations. I think this is basically showing how HELO results can alter the FROM results and vice versa. I am already seeing many of these mixed policies situations in my logs as I showed above. I have not concluded whether they provided false negatives or false positives yet. One thing for sure....... 2) All LMAP proposals with relaxed policies should be eliminated as ASAP We need don't the same problematic design issues that got us here in the first place with relaxed SMTP functional specifications. LMAP concepts such as SPF neutral or softfail need to be temporary. In fact, maybe a recommended transitional period of X months should be expected once a domain exposes a SPF policy with relaxed results. Just yesterday I saw a spammer trying 3-4 sessions with different return path domains each with SPFsoftfail or neutral records. 3) Clarification on the new Received-SPF header. Not sure if this is important, but when it is added? Before the normal MTA addition of Receive: or after? I'm seeing messages out there with both. Soon SPAMMERS will just need google "Received-SPF" to look for vulnerable neutral/softfail sites. Do we need this type of "advertising" exposing exploitable MTA? I mean, sure for post validation systems, but if a transaction is deemed 100% acceptable, I don't think it needs a SPF header. 4) Any LMAP proposals with redirection concepts need redirection protection. For example, with the SPF directive "redirect," SPF can be enhanced to have a new directive that says NOR, "no redirections." 5) LMAP DNS Policy Record Spoof protection. Not as simple as redirection protection, all LMAP proposals need a concept so that LMAP DNS domain policies can not spoofed or borrowed by others. This may simply be answered by going back to the mixed policy concept which I believe shows the IP/HELO association *may* has a stronger trust requirement over the IP/FROM association. Also, I am thinking of a "secret" password concept on the LMAP policy coupled with a SMTP protocol level challenge string here. 6) LMAP proposals needs review on how HELO lookups are done, subdomain or parent? -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp Thu Mar 11 12:37:31 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BKbVZU092217; Thu, 11 Mar 2004 12:37:31 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2BKbV5G092216; Thu, 11 Mar 2004 12:37:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (listserv.winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2BKbULx092209 for ; Thu, 11 Mar 2004 12:37:30 -0800 (PST) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v5.7.450.9b13) for ietf-mxcomp@imc.org; Thu, 11 Mar 2004 15:39:30 -0500 Received: from ([68.215.115.72]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v5.7.450.9b13) with SMTP id 3490139656; Thu, 11 Mar 2004 15:39:28 -0500 Message-ID: <00e301c407a8$beed2810$6401a8c0@hdev1> From: "Hector Santos" To: "Dave Crocker" , "Edwin Aoki" Cc: References: <4050B839.6070009@aol.net> <1138576445.20040311121520@brandenburg.com> Subject: Re: Authentication and Authorization Date: Thu, 11 Mar 2004 15:37:50 -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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----- Original Message ----- From: "Dave Crocker" To: "Edwin Aoki" Cc: Sent: Thursday, March 11, 2004 3:15 PM Subject: Re: Authentication and Authorization > > Hence we have an author and a poster, possibly the same and possibly > different. (The historical term for author is originator, but i frankly > think that author goes to the matter of content better.) > > > EA> * A machine at 1.2.3.4 is authorized to send mail > EA> * A machine at 1.2.3.4 is authorized to send mail on behalf of AOL (aol.net) > > and: > > * A machine at 1.2.3.4 is authorized to send mail on behalf of the > "author". > > * A machine at 1.2.3.4 is authorized to send mail on behalf of the > "poster". Excuse if misunderstand you, Are we discussing LMAP or are back to Anti-Spam Research 101? This is not the proposal being discuss. LMAP does not authorized "authors" or "posters" In my opinion, when technology is invented that "authorized" the author and the targe receipient for that matter, then it really doesn't matter what IP is used in the ideal world. The assertion may become: A machine at 1.2.3.4 is [not] authorized to send "authorized authored mail" I believe that is what YDK attempts to address on behalf of the USER: A machine at 1.2.3.4 is [not] authorized to send YDK ready mail. The question is, does it matter is the mail is secured? Thats a rthorical question. But I would like to get back to focusing on LMAP either that or we stop playing games and just change SMTP to do the job it should be doing in the first place. After all, SendMail and YAHOO are going to be change their SMTP servers with what seems to be an unfair initial "exclusive" and "modified" SMTP systems before everyone else has it. [Is the YDK specs out?] As a side note: LMAP is use one of five test suite of methods we use. If no decisions are made on the initial test performed, the final test is a CBV which finally attempts to "validate" the complete return address. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp Thu Mar 11 12:48:21 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BKmLg3093121; Thu, 11 Mar 2004 12:48:21 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2BKmLkw093120; Thu, 11 Mar 2004 12:48:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BKm9QG093107 for ; Thu, 11 Mar 2004 12:48:10 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.11/) with ESMTP id i2BKm9qR019696; Thu, 11 Mar 2004 12:48:11 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 11 Mar 2004 12:48:09 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Hadmut Danisch'" , Alan DeKok Cc: ietf-mxcomp@imc.org Subject: RE: Authentication and Authorization Date: Thu, 11 Mar 2004 12:48:07 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > From: owner-ietf-mxcomp@mail.imc.org > On Thu, Mar 11, 2004 at 03:17:01PM -0500, Alan DeKok wrote: > > > > The domain publishing LMAP information is publishing a policy: Who > > is authorized to use it's name. > > No. That's not a policy, that's authorization. Hadmut, it is a policy. It is not authorization in this context. The record is there because someone was authorized to put it there but it is not authorization data as far as I am concerned. > > The MTA receiving an SMTP connection > > may choose to enforce that policy. That enforcement is called > > authorization. > > No. The receiving MTA is enforcing it's own policy. It's the > receiver's policy to accept, tag, reject, burn unauthorized messages. The receiving MTA has an authorization policy. > Be careful with wording here. You just swapped them. Alan is not entirely consistent with the language that has been developed by the field but he is a lot closer. The best model here is to look at the work we have done here in the context of Web Services, in particular SAML and WS-Policy. Phill From owner-ietf-mxcomp Thu Mar 11 12:49:15 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BKnFfA093158; Thu, 11 Mar 2004 12:49: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 i2BKnF32093157; Thu, 11 Mar 2004 12:49:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BKnEaW093151 for ; Thu, 11 Mar 2004 12:49:14 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.11/) with ESMTP id i2BKnIws020265; Thu, 11 Mar 2004 12:49:18 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 11 Mar 2004 12:49:18 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'wayne'" , ietf-mxcomp@imc.org Subject: RE: Potential Work Item: New DNS resource records Date: Thu, 11 Mar 2004 12:44:09 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > The last time the SPF folks investigated where to place their TXT > record, it was determined that a non-trivial number of web-based DNS > administration systems (registrars, DNS providers, etc.) could not > handle the underscore. Some can not deal with adding TXT records, and > most do not allow you to add arbitrary RRs. There is a difference of context though. An independent group does not have the same leverage here. It is much easier to get these companies to respond if the changes are endorsed by a credible party such as the major vendors, major ISPs, the maintainers of the code or a standards body. > I agree with Phillip here. I think that in the context of an IETF > proposal, we can get these fixed, but there ARE problems that need to > be fixed. Last fall, when it looked like SPF deployment would be > going a lot slower, it was decided that using an underscore would > be too much of a hurdle for rapid adoption. It was also determined > that the usage of TXT records is low enough that there wasn't a need > to place them in a subdomain in order to keep the DNS queries under > 512 bytes. The other piece of context that has changed here is that we are now in a standards process and I don't think that the naked TXT record is going to be credible, it is not a defensible position by any stretch. I think if there is an insistence on DNS binary encoding and waiting for a full proposal before any deployment is possible that we should just close the group now and stop wasting everybody's time. If the _prefix convention is used the deployment situation is at best no worse than for a new RR. The risk of collision is no different, there is no need to upgrade the legacy base. A new RR with a TXT string representation provides meaningless compatibility with a legacy architecture, adds no value, requires use to wait for the servers to be upgraded and is generally bogus but could be acceptable if done quickly. The only real risk is that DNSEXT does not 'get it'. I'll start taking that group seriously once they tell me that they are going to fix DNSSEC, but certainly not before. Phill From owner-ietf-mxcomp Thu Mar 11 12:54:30 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BKsUIv093641; Thu, 11 Mar 2004 12:54: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 i2BKsUL3093640; Thu, 11 Mar 2004 12:54:30 -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.8) with ESMTP id i2BKsURx093633 for ; Thu, 11 Mar 2004 12:54:30 -0800 (PST) (envelope-from aland@newgiles.nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 610FE170DD for ; Thu, 11 Mar 2004 15:58:03 -0500 (EST) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Authentication and Authorization In-Reply-To: Your message of "Thu, 11 Mar 2004 21:21:28 +0100." <20040311202128.GA24025@danisch.de> Date: Thu, 11 Mar 2004 15:58:03 -0500 Message-Id: <20040311205803.610FE170DD@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hadmut Danisch wrote: > > The domain publishing LMAP information is publishing a policy: Who > > is authorized to use it's name. > > No. That's not a policy, that's authorization. The set of authorization information, and the rules for when to apply them, is called a "policy". e.g. "We allow employees to enter our secret lab, but not clients." The application of that policy is called "authorization". e.g. "This person is a client. The policy states that they are not allowed to enter the secret lab, so the security guard does not authorize them to enter it." Note that one part of the policy may be that authentication is required, and what kind of authentication is required. e.g. "Sorry, sir. You claim you're an employee named Bob, but need to see a company-issued identity card before we let you into the secret lab." Some people may not be authorized to use certain kinds of authentication. e.g. "You're wearing a FedEx uniform. I don't care that you have an employee card issued by the company, I'm not letting you in to our secret lab." > The receiving MTA is enforcing it's own policy. It's the > receiver's policy to accept, tag, reject, burn unauthorized messages. The receiving MTA may also be enforcing the domains published LMAP policy. There's no requiremt for it to follow that policy, though. Alan DeKok. From owner-ietf-mxcomp Thu Mar 11 12:56:05 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BKu57l093721; Thu, 11 Mar 2004 12:56:05 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2BKu5Xo093720; Thu, 11 Mar 2004 12:56:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BKu55u093714 for ; Thu, 11 Mar 2004 12:56:05 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2BL4xd20230; Thu, 11 Mar 2004 13:04:59 -0800 Date: Thu, 11 Mar 2004 12:55:51 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <442718524.20040311125551@brandenburg.com> To: "Hector Santos" CC: ietf-mxcomp@imc.org Subject: Re: Authentication and Authorization In-Reply-To: <00e301c407a8$beed2810$6401a8c0@hdev1> References: <4050B839.6070009@aol.net> <1138576445.20040311121520@brandenburg.com> <00e301c407a8$beed2810$6401a8c0@hdev1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hector, HS> Are we discussing LMAP or are back to Anti-Spam Research 101? This thread is about defining and using careful and precise terminology. It is not about specific proposals. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Thu Mar 11 12:58:39 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BKwc6U093896; Thu, 11 Mar 2004 12:58: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 i2BKwcTD093895; Thu, 11 Mar 2004 12:58:38 -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.8) with ESMTP id i2BKwcJ2093889 for ; Thu, 11 Mar 2004 12:58:38 -0800 (PST) (envelope-from aland@newgiles.nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id A27C0170F4 for ; Thu, 11 Mar 2004 16:02:12 -0500 (EST) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Authentication and Authorization In-Reply-To: Your message of "Thu, 11 Mar 2004 12:48:07 PST." Date: Thu, 11 Mar 2004 16:02:12 -0500 Message-Id: <20040311210212.A27C0170F4@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Hallam-Baker, Phillip" wrote: > Alan is not entirely consistent with the language that has been > developed by the field but he is a lot closer. The terminology I'm familiar with comes from a related field: login access control and accounting. The terms are similar, but not always identical. I'll try to use definitions from the relevant field for this discussion... whatever that field is. Alan DeKok. From owner-ietf-mxcomp Thu Mar 11 13:00:44 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BL0i3u094064; Thu, 11 Mar 2004 13:00: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 i2BL0ijH094063; Thu, 11 Mar 2004 13:00:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BL0i2v094057 for ; Thu, 11 Mar 2004 13:00:44 -0800 (PST) (envelope-from hardie@qualcomm.com) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i2BL0hvf004401; Thu, 11 Mar 2004 13:00:44 -0800 (PST) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i2BL0flH024643; Thu, 11 Mar 2004 13:00:42 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <524330962.20040311122014@brandenburg.com> References: <4050B839.6070009@aol.net> <524330962.20040311122014@brandenburg.com> Date: Thu, 11 Mar 2004 13:00:41 -0800 To: Dave Crocker From: Ted Hardie Subject: Re: Authentication and Authorization Cc: ietf-mxcomp@imc.org, Dave Crocker Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 12:20 PM -0800 03/11/2004, Dave Crocker wrote: >Ted, > > >TH> I believe the point we're trying to reach is: > >TH> "* The MTA from which my MTA received this message is listed as being >TH> allowed to send mail on behalf of the domain listed in the message >TH> (or not)." > >"domain listed in the message" could mean the RFC2822 From, RFC2822 >Sender, the SMTP Mail-From, or possibly even the SMTP EHLO. > >Beyond "listed in the message" is being authorized by the containing >service provider to act as a client MTA. > >(I'll leave out RFC2822 Reply-To, since I do not think anyone considers >it a viable example.) > >These involve very different identity roles. > I agree. Which one is picked is a very important choice, and one aspect of that choice is how closely we can tie each identity to the MTA and to the zone maintainer. I did not go into in that message, since the focus was on "publish a permitted set description, check a record" vs. "publish a record, check the asserted permissions", but it clearly is a critical element to get right. regards, Ted Hardie From owner-ietf-mxcomp Thu Mar 11 13:15:23 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BLFNLQ094605; Thu, 11 Mar 2004 13:15: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 i2BLFNxK094604; Thu, 11 Mar 2004 13:15:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BLFNYM094598 for ; Thu, 11 Mar 2004 13:15:23 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.11/) with ESMTP id i2BLFRgY001771; Thu, 11 Mar 2004 13:15:27 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 11 Mar 2004 13:15:27 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Alan DeKok'" , ietf-mxcomp@imc.org Subject: RE: Authentication and Authorization Date: Thu, 11 Mar 2004 13:15:25 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > "Hallam-Baker, Phillip" wrote: > > Alan is not entirely consistent with the language that has been > > developed by the field but he is a lot closer. > > The terminology I'm familiar with comes from a related field: login > access control and accounting. The terms are similar, but not always > identical. Your terminology looked similar to the terminology we used in discussions at the start of SAML. Basically we found that some of the uses we were making of the terms were a bit ambiguous so we tightened up while writing the specs. Basically SAML was a joint effort of the single sign on vendors. So having gone through the terminology thing once I don't think it should be re-opened :-) The key thing here is a consistent point of view. Hadmut is looking at the problem from the point of view of the publisher of the information. This leads to very confused interpretations since the spec is about the information from the point of view of the people relying on it. The idea that the onus lies on the speaker to make themselves understood goes back to Aristotle and the rhetorics. When I issue an accreditation it will be on the basis of the infomation they supply and I authenticate. But I deliberately do not call it authentication information because it is only authentication in my context. The relying party has to authenticate the subject themselves and then determine if my accreditation information is relevant. Phill From owner-ietf-mxcomp Thu Mar 11 13:20:42 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BLKgN7095147; Thu, 11 Mar 2004 13:20: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 i2BLKg8q095146; Thu, 11 Mar 2004 13:20:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (ntbbs.santronics.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2BLKfRq095139 for ; Thu, 11 Mar 2004 13:20:42 -0800 (PST) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v5.7.450.9b13) for ietf-mxcomp@imc.org; Thu, 11 Mar 2004 16:22:47 -0500 Received: from ([68.215.115.72]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v5.7.450.9b13) with SMTP id 3492737156; Thu, 11 Mar 2004 16:22:46 -0500 Message-ID: <012001c407ae$cb416120$6401a8c0@hdev1> From: "Hector Santos" To: , "wayne" References: <20040311194015.GB56829@Space.Net> Subject: Re: Potential Work Item: New DNS resource records Date: Thu, 11 Mar 2004 16:21:01 -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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----- Original Message ----- From: "wayne" To: Sent: Thursday, March 11, 2004 3:09 PM Subject: Re: Potential Work Item: New DNS resource records > I agree with Phillip here. I think that in the context of an IETF > proposal, we can get these fixed, but there ARE problems that need to > be fixed. Last fall, when it looked like SPF deployment would be > going a lot slower, it was decided that using an underscore would > be too much of a hurdle for rapid adoption. It was also determined > that the usage of TXT records is low enough that there wasn't a need > to place them in a subdomain in order to keep the DNS queries under > 512 bytes. Small note: This should be a non-issue as most DNS resolvers should be supporting truncated datagrams DNS responses with a fallback to TCP streaming. For sure, Microsoft CEP depends on it based as it even documented the idea of split XML TXT records that need to be joined (implying +512 bytes situations). -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp Thu Mar 11 13:29:59 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BLTxs5095844; Thu, 11 Mar 2004 13:29:59 -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 i2BLTx0S095843; Thu, 11 Mar 2004 13:29:59 -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 (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BLTwK5095832 for ; Thu, 11 Mar 2004 13:29:58 -0800 (PST) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.30) id 1B1Xkg-0000Xf-Nv for ietf-mxcomp@imc.org; Thu, 11 Mar 2004 15:30:02 -0600 To: Subject: Re: Potential Work Item: New DNS resource records References: <20040311194015.GB56829@Space.Net> <012001c407ae$cb416120$6401a8c0@hdev1> From: wayne Content-Type: text/plain; charset=US-ASCII Date: Thu, 11 Mar 2004 15:30:02 -0600 In-Reply-To: <012001c407ae$cb416120$6401a8c0@hdev1> (Hector Santos's message of "Thu, 11 Mar 2004 16:21:01 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (spfd: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <012001c407ae$cb416120$6401a8c0@hdev1> "Hector Santos" writes: >> It was also determined >> that the usage of TXT records is low enough that there wasn't a need >> to place them in a subdomain in order to keep the DNS queries under >> 512 bytes. > > Small note: This should be a non-issue as most DNS resolvers should be > supporting truncated datagrams DNS responses with a fallback to TCP > streaming. Yes, in theory it *should* be a non-issue. Unfortunately, we found that there are all too many firewalls out there that think that TCP port 53 traffic should not be allowed. Since almost 100% of all DNS traffic goes via UDP, there is no reason to pass TCP DNS traffic and since you can't reliably use TCP DNS, almost 100% of all DNS traffic needs to go via UDP. *sigh* Yes, this is broken, but we need to consider the issue. > For sure, Microsoft CEP depends on it based as it even > documented the idea of split XML TXT records that need to be joined > (implying +512 bytes situations). Well, I don't know what MS found during their investigations, but Hotmail's C-ID records are split up via 's. This means that each of the four (4) required DNS queries are under 512 bytes each. -wayne From owner-ietf-mxcomp Thu Mar 11 13:40:10 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BLeAJU096945; Thu, 11 Mar 2004 13:40: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 i2BLeASu096944; Thu, 11 Mar 2004 13:40:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BLe9aR096938 for ; Thu, 11 Mar 2004 13:40:10 -0800 (PST) (envelope-from hadmut@danisch.de) Received: from andromeda (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i2BLeExA005182; Thu, 11 Mar 2004 22:40:14 +0100 Received: (from hadmut@localhost) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-3) id i2BLdmDE024675; Thu, 11 Mar 2004 22:39:48 +0100 From: Hadmut Danisch Date: Thu, 11 Mar 2004 22:39:48 +0100 To: Alan DeKok Cc: ietf-mxcomp@imc.org Subject: Re: Authentication and Authorization Message-ID: <20040311213948.GA24662@danisch.de> References: <20040311202128.GA24025@danisch.de> <20040311205803.610FE170DD@mail.nitros9.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040311205803.610FE170DD@mail.nitros9.org> User-Agent: Mutt/1.5.5.1+cvs20040105i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Mar 11, 2004 at 03:58:03PM -0500, Alan DeKok wrote: > > The set of authorization information, and the rules for when to > apply them, is called a "policy". > > e.g. "We allow employees to enter our secret lab, but not > clients." Only if the authorization informations and the rules are given by the same entity. Here the authorization information is given by the domain owner, the rules are given by the receiving MTA owner. regards Hadmut From owner-ietf-mxcomp Thu Mar 11 13:40:03 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BLe3BO096932; Thu, 11 Mar 2004 13:40: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 i2BLe3R2096931; Thu, 11 Mar 2004 13:40:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BLe1mR096925 for ; Thu, 11 Mar 2004 13:40:02 -0800 (PST) (envelope-from hadmut@danisch.de) Received: from andromeda (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i2BLe68R005172; Thu, 11 Mar 2004 22:40:06 +0100 Received: (from hadmut@localhost) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-3) id i2BLbZab024655; Thu, 11 Mar 2004 22:37:35 +0100 From: Hadmut Danisch Date: Thu, 11 Mar 2004 22:37:35 +0100 To: "Hallam-Baker, Phillip" Cc: Alan DeKok , ietf-mxcomp@imc.org Subject: Re: Authentication and Authorization Message-ID: <20040311213735.GA24430@danisch.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1+cvs20040105i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Mar 11, 2004 at 12:48:07PM -0800, Hallam-Baker, Phillip wrote: > > Hadmut, it is a policy. It is not authorization in this context. The > record is there because someone was authorized to put it there but it > is not authorization data as far as I am concerned. ... > Alan is not entirely consistent with the language that has been > developed by the field but he is a lot closer. Let's have a look at definitions found with google: http://www.securityfocus.com/infocus/1193 The nicest definition for 'policy' that I could find is from the American Heritage Dictionary of the English language. It reads: "A plan or course of action, as of a government, political party, or business, intended to influence and determine decisions, actions, and other matters" In practical security terms, I define a policy as a published document (or set of documents) in which the organization's philosophy, strategy, policies and practices with regard to confidentiality, integrity and availability of information and information systems are laid out. http://www.counterintrusion.com/images/What%20is%20a%20policy.htm A policy establishes who is authorized to access different types of information, and points to standards and guidelines regarding how much and what kinds of security measures are necessary. Procedures provide the method for implementing those standards and guidelines in order to carry out for implementing those standards and guidelines in order to carry out the established policy. http://rusecure.rutgers.edu/sec_plan/pandp.php A policy is a document that makes a specific statement requiring that a rule must be met. They are usually point-specific, covering a single area. Policies should be general in nature and not have to be updated on a regular basis. http://www.tolerantsystems.org/ITS_Ref/Carl_Landwehr.ppt What is a policy? A high-level overall plan embracing the general goals and acceptable procedures of a body (Merriam Webster) http://www.cap.nsw.edu.au/small_schools_manual/policy_writing.htm What is a Policy? A policy consists of a statement of purpose and one or more broad guidelines as to how the purpose is to be achieved which, when taken together, provide a framework for the operation of the school or program. The guidelines specify in general terms, the kind of action which will or may be taken; they imply an intention and a pattern for taking action. http://www.csd.uwo.ca/~kedwards/policy/policydef.html [lengthy definitions] http://www.snia.org/apps/group_public/download.php/1632/What_is_Security_Policy.pdf A set of documents that describes, at a high level,the security controls that will be implemented in the company. A set of rules that state which actions are permitted and which actions are prohibited. http://www.checkpoint.com/products/smallbusiness/smallbusiness_networkingfaq.html What is a security policy? Broadly speaking, a security policy is a collection of practices and rules (for example, you must change your password every three months) that help a business ensure that its electronic information assets remain secure. A firewall implements the rules from the security policy (for example, it checks that network users have provided the correct password) and determines what network communications are allowed to pass from one network to another. http://whatis.techtarget.com/definition/0,,sid9_gci887248,00.html In business, a security policy is a document that states in writing how a company plans to protect the company's physical and information technology (IT) assets. A security policy is often considered to be a "living document", meaning that the document is never finished, but is continuously updated as technology and employee requirements change. http://www.windowsecurity.com/articles/Defining_a_Security_Policy.html Well, a policy would be some form of documentation that is created to enforce specific rules or regulations and keep a structure on procedures. Here, in the context of \x{FFFD}security\x{FFFD}, is simply a policy based around procedures revolving around security. Think of any other kind of policy\x{FFFD} a disaster recovery policy is a set of procedures, rules and plans revolving around having a disaster and how to recover from it. Security polices are much the same. http://www.digitaldefence.ca/Professional_Policy_FAQs.htm An Information Security policy is a high-level statement of an organization's beliefs, goals and objectives, and the general direction for their attainment as it pertains to protecting corporate data and the infrastructure used for handling it. A policy is brief and never states \x{2018}how' to accomplish the objectives; instead, it delivers a strategy that is consistent over time and is capable of addressing organizational, procedural, and technical changes. Overall the policy must define the place that information security plays in supporting the mission and goals of the institution. http://www.hudsonbusiness.net/security/security_policy.html A security policy is: a document that contains management's directives that define the role of security in an organization. It determines how an organization will setup and administer their security program. It dictates security goals and objectives, assigns roles and responsibilities, it defines the value of the security program, and details how the security policy will be implemented and enforced. http://www.hkcert.org/faq/security_pb.html#q5 Security policy sets the basic mandatory rules and principles on information security. It should be observed throughout an organization and should be in accordance with your security requirements and organization's business objectives and goals. http://www.cs.purdue.edu/homes/clifton/cs526/policy.ppt What is a security policy? Defines what it means for a system to be secure So I still stick to my definition: Identity Sending MTA's IP address Authentication Verifying the Identity (TCP sequence numbers) Authorization Domain owner's statement Policy Receiving MTA's way to treat messages with or without Signature, LMAP authorization, or from domains without LMAP record, or DNS server down regards Hadmut From owner-ietf-mxcomp Thu Mar 11 14:22:35 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BMMZbM099286; Thu, 11 Mar 2004 14:22: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 i2BMMZ3R099285; Thu, 11 Mar 2004 14:22:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ogud.com (ns.ogud.com [66.92.146.160]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BMMX02099274 for ; Thu, 11 Mar 2004 14:22:34 -0800 (PST) (envelope-from ogud@ogud.com) Received: from ENGILL.ogud.com (mail.md.ogud.com [10.20.30.6]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i2BMMdVa009463; Thu, 11 Mar 2004 17:22:41 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.0.3.0.2.20040311164333.02740640@localhost> X-Sender: post@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Thu, 11 Mar 2004 16:53:16 -0500 To: Dave Crocker From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: Potential Work Item: New DNS resource records Cc: "IETF MXCOMP (E-mail)" In-Reply-To: <594157933.20040311101143@brandenburg.com> References: <700EEF5641B7E247AC1C9B82C05D125DA7B9@srv1.fecyk.ca> <594157933.20040311101143@brandenburg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 13:11 2004-03-11, Dave Crocker wrote: >Patrik, > >PF> [4] Change the resource record type > >PF> See previous bullet, it forces the MX and the "RMX" to be in the same >PF> zone, which in turn forces the records to be managed by the same >PF> entity. > > Your analysis did not consider differences in rate of deployment and > adoption. > > The choice involves some tradeoffs. We need to make sure that we > consider them as a set. > > New record types have a history of taking a _very_ long time before > they gain widescale usability. Given the urgency of spam control, this > is an important concern. > Ask your DNS vendor/supplier/support if they support RFC3597 http://ietf.org/rfc/rfc3597.txt today, if not ask them when. Explain to them that future spam fights will depend on this getting this done ASAP, everyone supporting RFC3597 can support new RR types overnight. Even us DNS people learn from history :-) Olafur From owner-ietf-mxcomp Thu Mar 11 14:39:08 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BMd7Q5000507; Thu, 11 Mar 2004 14:39:07 -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 i2BMd7vZ000506; Thu, 11 Mar 2004 14:39:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BMd7fM000500 for ; Thu, 11 Mar 2004 14:39:07 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2BMmEd27640; Thu, 11 Mar 2004 14:48:14 -0800 Date: Thu, 11 Mar 2004 14:39:06 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <18010009724.20040311143906@brandenburg.com> To: =?ISO-8859-15?B?02xhZnVyIEd18G11bmRzc29u?= CC: "IETF MXCOMP (E-mail)" Subject: Re: Potential Work Item: New DNS resource records In-Reply-To: <6.0.3.0.2.20040311164333.02740640@localhost> References: <700EEF5641B7E247AC1C9B82C05D125DA7B9@srv1.fecyk.ca> <594157933.20040311101143@brandenburg.com> <6.0.3.0.2.20040311164333.02740640@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ólafur, ÓG> Ask your DNS vendor/supplier/support if they support RFC3597 ÓG> http://ietf.org/rfc/rfc3597.txt today, if not ask them when. If something has a long history of being true, it is unwise to rely on it suddenly changing. The history of adoption of new DNS records, sufficient to be broadly relied on across the general Internet, is not very good. We can use any persuasive arguments we want, and they will not change that historical reality. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Thu Mar 11 15:03:12 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BN3Brv002314; Thu, 11 Mar 2004 15:03: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 i2BN3BIj002313; Thu, 11 Mar 2004 15:03:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BN3BaU002307 for ; Thu, 11 Mar 2004 15:03:11 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.11/) with ESMTP id i2BN3G0A029374; Thu, 11 Mar 2004 15:03:16 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 11 Mar 2004 15:03:15 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: =?iso-8859-1?Q?=27=D3lafur_Gu=F0mundsson=27?= , "'Dave Crocker'" Cc: "'IETF MXCOMP (E-mail)'" Subject: Re: Potential Work Item: New DNS resource records Date: Thu, 11 Mar 2004 15:03:09 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2BN3BaU002308 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The problem with this approach is that it is not true. The deployment of rfcs does nothing for the capacity to address spam. Spf and callerid are working today without deployment of dns extension code. Witholding functionality in the hope it will drive deployment is a very very bad strategy. -----Original Message----- From: Ólafur Guðmundsson [mailto:ogud@ogud.com] Sent: Thu Mar 11 14:24:46 2004 To: Dave Crocker Cc: IETF MXCOMP (E-mail) Subject: Re: Potential Work Item: New DNS resource records At 13:11 2004-03-11, Dave Crocker wrote: >Patrik, > >PF> [4] Change the resource record type > >PF> See previous bullet, it forces the MX and the "RMX" to be in the same >PF> zone, which in turn forces the records to be managed by the same >PF> entity. > > Your analysis did not consider differences in rate of deployment and > adoption. > > The choice involves some tradeoffs. We need to make sure that we > consider them as a set. > > New record types have a history of taking a _very_ long time before > they gain widescale usability. Given the urgency of spam control, this > is an important concern. > Ask your DNS vendor/supplier/support if they support RFC3597 http://ietf.org/rfc/rfc3597.txt today, if not ask them when. Explain to them that future spam fights will depend on this getting this done ASAP, everyone supporting RFC3597 can support new RR types overnight. Even us DNS people learn from history :-) Olafur From owner-ietf-mxcomp Thu Mar 11 15:11:30 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BNBUOp002778; Thu, 11 Mar 2004 15:11: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 i2BNBUcd002777; Thu, 11 Mar 2004 15:11:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BNBTbD002771 for ; Thu, 11 Mar 2004 15:11:30 -0800 (PST) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id 802C7E0F2D; Thu, 11 Mar 2004 18:11:34 -0500 (EST) Date: Thu, 11 Mar 2004 18:11:34 -0500 From: John Leslie To: Hadmut Danisch Cc: ietf-mxcomp@imc.org Subject: Re: Authentication and Authorization Message-ID: <20040311231134.GB42098@verdi> References: <20040311213735.GA24430@danisch.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040311213735.GA24430@danisch.de> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hadmut Danisch wrote: > ... > So I still stick to my definition: > > Identity Sending MTA's IP address > > Authentication Verifying the Identity (TCP sequence numbers) > > Authorization Domain owner's statement > > Policy Receiving MTA's way to treat messages with or > without Signature, LMAP authorization, or from > domains without LMAP record, or DNS server down While I do not agree with Hadmut's definitions, I cannot fault them. And I'm quite sure there are others who will share them. I believe we should try to avoid using these terms in meanings different from Hadmut's definitions. Yes, this probably means avoiding these terms at all -- which strikes me as an excellent idea. I'd like to remind everyone of the exact question that was hummed at the BoF: " Is there IETF work that we should take on to develop a mechanism " that allows an MTA to use a DNS-based record to signal to peer " MTA's that it is authorized to send mail? (That's as close to a charter as we have right now.) Within that statement, there is no "identity", no "authentication", and no "policy". :^) However, there is an "authorized". :^( Can we live with Hadmut's definition of "authorization"? (Keeping in mind that others will have different definitions) If not, can we describe what it is we wish to signal -- in terms that Hadmut won't interpret differently from others who will read our documents? -- John Leslie From owner-ietf-mxcomp Thu Mar 11 15:12:18 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BNCIvk002810; Thu, 11 Mar 2004 15:12: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 i2BNCIMH002809; Thu, 11 Mar 2004 15:12:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BNCIYC002800 for ; Thu, 11 Mar 2004 15:12:18 -0800 (PST) (envelope-from paf@cisco.com) Received: from ams-msg-core-1.cisco.com (144.254.74.60) by sj-iport-5.cisco.com with ESMTP; 11 Mar 2004 15:12:51 -0800 Received: from xbe-ams-312.cisco.com (xbe-ams-312.cisco.com [144.254.228.202]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2BMNkHs010747; Thu, 11 Mar 2004 23:23:46 +0100 (MET) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 11 Mar 2004 23:24:15 +0100 Received: from [127.0.0.1] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 11 Mar 2004 23:24:14 +0100 In-Reply-To: <20040311153921.GA1804@Space.Net> References: <700EEF5641B7E247AC1C9B82C05D125DA7B9@srv1.fecyk.ca> <20040311153921.GA1804@Space.Net> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Cc: Gordon Fecyk , "IETF MXCOMP \(E-mail\)" From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: Potential Work Item: New DNS resource records Date: Fri, 12 Mar 2004 06:24:09 +0800 To: Markus Stumpf X-Mailer: Apple Mail (2.612) X-OriginalArrivalTime: 11 Mar 2004 22:24:14.0498 (UTC) FILETIME=[95B03820:01C407B7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2BNCIYC002804 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2004-03-11, at 23.39, Markus Stumpf wrote: > On Thu, Mar 11, 2004 at 11:05:21AM +0800, Patrik Fältström wrote: >> [3] Add a prefix to the owner (i.e. _foo.example.com.) >> Problematic for two reasons: >> If we have >> example.com. IN MX 10 mail.example.com. >> it is for me much better to have the same owner for the "RMX" resource >> record as the MX because then we know for sure both MX and the "RMX" >> is >> in the same zone, and have to be signed by the same owner/mechanism. > > I don't see a problem with having both > example.com. IN MX 10 mail.example.com. > _srv.example.com. IN NRR ... > in the same zone. > > I don't even see a problem with having > ns4.dns.space.net in the space.net > zone. The only ones up to now that seem to have a problem is the > italian NIC that insisted that dns.space.net MUST have a delegation. Problem is that they might be in different zones. example.com. IN MX 10 mail.example.com. _srv.example.com. IN NS ... Is this something which have impact on the "trust" on the data? Is this a weakness which can be used as an attack vector when attacking the system? Especially when using DNSSEC? >> Second problem has to do with wildcards. >> If one have >> *.example.com. IN MX 10 mail.example.com. >> then one can have still >> *.example.com. IN RMX ... >> But, if one use _foo.example.com for the mechanism, we can not have: >> _foo.*.example.com. > > This problem only becomes evident if there is a need for wildcard > records. It may even be a design goal to make wildcard records > impossible > to make it harder for manually managed zones to set the NRR for the > whole zone. As for automated (database backed) administration it > doesn't make a big difference as they would probably assign the records > to every LHS explicitely. When DNSSEC was designed, and when the wildcard Verisign was playing around with was discussed there was a discussion whether the wildcard "was obsolete" and the outcome was that "it is needed in enterprise environments for email". But, of course we should ask again. paf From owner-ietf-mxcomp Thu Mar 11 16:37:08 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2C0b8Qu008096; Thu, 11 Mar 2004 16:37: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 i2C0b8X8008095; Thu, 11 Mar 2004 16:37:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2C0b4Yh008086 for ; Thu, 11 Mar 2004 16:37:05 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.11/) with ESMTP id i2C0b8ta005255; Thu, 11 Mar 2004 16:37:08 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 11 Mar 2004 16:37:08 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'John Leslie'" , Hadmut Danisch Cc: ietf-mxcomp@imc.org Subject: RE: Authentication and Authorization Date: Thu, 11 Mar 2004 16:37:04 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Can we live with Hadmut's definition of "authorization"? > (Keeping in mind that others will have different definitions) Not if we want the spec to be comprehensible in the security community. The information in the DNS is neither authorization policy nor is it an authorization decision. We went through all this with SAML, we had all the major single sign on vendors represented. This is re-inventing the terms to mean something completely different. We are not putting permissions data in the DNS here, we are putting credentials data in the DNS and stating that recipients should verify that mail messages purporting to originate from the zone are authentic with respect to a credential. That is a security policy according to the current usage in the field. From owner-ietf-mxcomp Thu Mar 11 16:39:12 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2C0dCnm008329; Thu, 11 Mar 2004 16:39:12 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2C0dCCF008328; Thu, 11 Mar 2004 16:39:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2C0dBIG008322 for ; Thu, 11 Mar 2004 16:39:11 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.11/) with ESMTP id i2C0dESA026829; Thu, 11 Mar 2004 16:39:14 -0800 (PST) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 11 Mar 2004 16:39:14 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Hadmut Danisch'" , "Hallam-Baker, Phillip" Cc: Alan DeKok , ietf-mxcomp@imc.org Subject: RE: Authentication and Authorization Date: Thu, 11 Mar 2004 16:39:10 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: These references are irrelevant, they are all informal definitions, most appear to be from marketting litterature. The relevant references here are security standards, NOT marketting litterature. From owner-ietf-mxcomp Thu Mar 11 18:11:45 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2C2BiWa012237; Thu, 11 Mar 2004 18:11: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 i2C2Bi7L012236; Thu, 11 Mar 2004 18:11:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mauve.mrochek.com ([209.55.107.55]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2C2Bgjk012229 for ; Thu, 11 Mar 2004 18:11:42 -0800 (PST) (envelope-from ned.freed@mrochek.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01L7KTEM74YO0027NR@mauve.mrochek.com> for ietf-mxcomp@imc.org; Thu, 11 Mar 2004 18:11:46 -0800 (PST) Date: Thu, 11 Mar 2004 18:08:43 -0800 (PST) From: ned.freed@mrochek.com Subject: Re: Authentication and Authorization In-reply-to: "Your message dated Thu, 11 Mar 2004 18:11:34 -0500" <20040311231134.GB42098@verdi> To: John Leslie Cc: Hadmut Danisch , ietf-mxcomp@imc.org Message-id: <01L7LZ6FKCRO0027NR@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <20040311213735.GA24430@danisch.de> <20040311231134.GB42098@verdi> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Hadmut Danisch wrote: > > ... > > So I still stick to my definition: > > > > Identity Sending MTA's IP address > > > > Authentication Verifying the Identity (TCP sequence numbers) > > > > Authorization Domain owner's statement > > > > Policy Receiving MTA's way to treat messages with or > > without Signature, LMAP authorization, or from > > domains without LMAP record, or DNS server down > While I do not agree with Hadmut's definitions, I cannot fault > them. And I'm quite sure there are others who will share them. I'm not wild about the wording, but this is close enough for me. I find no fault here either. I note in passing that these definitions are largely consistent with the definitions of the terms given in RFC 3539. > I believe we should try to avoid using these terms in meanings > different from Hadmut's definitions. Agreed. > Yes, this probably means avoiding these terms at all -- which > strikes me as an excellent idea. Yep. > I'd like to remind everyone of the exact question that was > hummed at the BoF: > " Is there IETF work that we should take on to develop a mechanism > " that allows an MTA to use a DNS-based record to signal to peer > " MTA's that it is authorized to send mail? Very good point. > (That's as close to a charter as we have right now.) > Within that statement, there is no "identity", no "authentication", > and no "policy". :^) > However, there is an "authorized". :^( > Can we live with Hadmut's definition of "authorization"? > (Keeping in mind that others will have different definitions) I certainly can. Ned From owner-ietf-mxcomp Thu Mar 11 18:24:14 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2C2OEUF013095; Thu, 11 Mar 2004 18:24: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 i2C2OEuo013094; Thu, 11 Mar 2004 18:24:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from xuxa.iecc.com (xuxa.iecc.com [208.31.42.42]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2C2OCsi013088 for ; Thu, 11 Mar 2004 18:24:13 -0800 (PST) (envelope-from johnl@iecc.com) Received: (qmail 21870 invoked by uid 100); 12 Mar 2004 02:21:03 -0000 From: John Levine To: ietf-mxcomp@imc.org Date: 11 Mar 2004 19:27:56 -0000 Message-ID: <20040311192756.23214.qmail@xuxa.iecc.com> Subject: Re: Potential Work Item: New DNS resource records In-Reply-To: <20040311153921.GA1804@Space.Net> Organization: I.E.C.C., Trumansburg NY USA Cc: Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >This problem only becomes evident if there is a need for wildcard >records. It may even be a design goal to make wildcard records >impossible to make it harder for manually managed zones to set the >NRR for the whole zone. That would be a problem. I give all of my users subdomains that map to subaddresses, e.g. farp@joe.iecc.com -> joe-farp@iecc.com. I really don't want to have to export my entire user database into the DNS. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://iecc.com/johnl, Sewer Commissioner "A book is a sneeze." - E.B. White, on the writing of Charlotte's Web From owner-ietf-mxcomp Thu Mar 11 18:59:07 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2C2x7T1014841; Thu, 11 Mar 2004 18:59:07 -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 i2C2x7vv014840; Thu, 11 Mar 2004 18:59:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2C2x7si014834 for ; Thu, 11 Mar 2004 18:59:07 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2C38Hd12269 for ; Thu, 11 Mar 2004 19:08:17 -0800 Date: Thu, 11 Mar 2004 18:59:08 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <95554446.20040311185908@brandenburg.com> To: ietf-mxcomp@imc.org Subject: Re: Authentication and Authorization In-Reply-To: <01L7LZ6FKCRO0027NR@mauve.mrochek.com> References: <20040311213735.GA24430@danisch.de> <20040311231134.GB42098@verdi> <01L7LZ6FKCRO0027NR@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Folks, I think that Hadmut is moving us in the right direction, but I continue to urge us to be more precise: >> > Identity Sending MTA's IP address This means the peer, SMTP client, right? >> > Authentication Verifying the Identity (TCP sequence numbers) >> > >> > Authorization Domain owner's statement Which domain? (It is ok if the answer is something "it depends upon which proposal is being considered" but, again, I think we need to be clear about our ambiguities/variables. For example, I suspect that the definition, for this level of discussion, needs to be something like "the owner of a domain that is obtained from some portion of an SMTP transaction." >> > Policy Receiving MTA's way to treat messages with or >> > without Signature, LMAP authorization, or from >> > domains without LMAP record, or DNS server down Most discussions have described a policy as guidance, from the domain owner and to the server SMTP, concerning the way the server should treat messages... That is, the policy comes from the domain owner; the server SMTP decides whether to conform to it. >> " Is there IETF work that we should take on to develop a mechanism >> " that allows an MTA to use a DNS-based record to signal to peer >> " MTA's that it is authorized to send mail? nfmc> Very good point. For reference, I think this is the right scope and goal for an IETF working group to tackle. However, as always, an agreement at a face-to-face meeting needs to be confirmed online. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Thu Mar 11 19:45:09 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2C3j9Nd017644; Thu, 11 Mar 2004 19:45:09 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2C3j96w017643; Thu, 11 Mar 2004 19:45:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mauve.mrochek.com ([209.55.107.55]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2C3j8hF017637 for ; Thu, 11 Mar 2004 19:45:08 -0800 (PST) (envelope-from ned.freed@mrochek.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01L7KTEM74YO0027NR@mauve.mrochek.com> for ietf-mxcomp@imc.org; Thu, 11 Mar 2004 19:45:14 -0800 (PST) Date: Thu, 11 Mar 2004 19:32:28 -0800 (PST) From: ned.freed@mrochek.com Subject: Re: Authentication and Authorization In-reply-to: "Your message dated Thu, 11 Mar 2004 18:59:08 -0800" <95554446.20040311185908@brandenburg.com> To: Dave Crocker Cc: ietf-mxcomp@imc.org Message-id: <01L7M2GASAOQ0027NR@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <20040311213735.GA24430@danisch.de> <20040311231134.GB42098@verdi> <01L7LZ6FKCRO0027NR@mauve.mrochek.com> <95554446.20040311185908@brandenburg.com> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > I think that Hadmut is moving us in the right direction, but I continue > to urge us to be more precise: Good. > >> > Identity Sending MTA's IP address > This means the peer, SMTP client, right? > >> > Authentication Verifying the Identity (TCP sequence numbers) > >> > > >> > Authorization Domain owner's statement > Which domain? > (It is ok if the answer is something "it depends upon which proposal is > being considered" but, again, I think we need to be clear about our > ambiguities/variables. > For example, I suspect that the definition, for this level of > discussion, needs to be something like "the owner of a domain that is > obtained from some portion of an SMTP transaction." Seems like a reasonable way to describe it to me. It is an important point since it puts out of scope schemes that involve a sepatate step to get or create identity information. > >> > Policy Receiving MTA's way to treat messages with or > >> > without Signature, LMAP authorization, or from > >> > domains without LMAP record, or DNS server down > Most discussions have described a policy as guidance, from the domain > owner and to the server SMTP, concerning the way the server should treat > messages... > That is, the policy comes from the domain owner; the server SMTP decides > whether to conform to it. Right, although there might be some issues surrounding what "domain owner" means. Not only do we have proposals that use different parts of the DNS in different ways, there's the mundane but nevertheless real issue that administrative control over a domain's email policies and administrative control over a domain's DNS entries may not be the same. > >> " Is there IETF work that we should take on to develop a mechanism > >> " that allows an MTA to use a DNS-based record to signal to peer > >> " MTA's that it is authorized to send mail? > nfmc> Very good point. > For reference, I think this is the right scope and goal for an IETF > working group to tackle. I agree. > However, as always, an agreement at a face-to-face meeting needs to be > confirmed online. Agreed, and it is all the more important here since the meeting ran late and the question didn't get posed until some people had left. Ned From owner-ietf-mxcomp Thu Mar 11 20:46:52 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2C4kqZF021705; Thu, 11 Mar 2004 20:46: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 i2C4kqRl021704; Thu, 11 Mar 2004 20:46:52 -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 (srv1.fecyk.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2C4kpXc021698 for ; Thu, 11 Mar 2004 20:46:52 -0800 (PST) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: Potential Work Item: New DNS resource records MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 11 Mar 2004 22:46:58 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA7BE@srv1.fecyk.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Potential Work Item: New DNS resource records Thread-Index: AcQHvUI/fxI3xz0rTxeW0aVcossfiwAK0dDg 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 i2C4kqXc021699 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Witholding functionality in the hope it will drive deployment > is a very very bad strategy. I won't say it. It's too easy. We're caught between a rock and a hard place over this. On one side we don't want to break existing functionality in DNS (ahem*s*te-f*nd*r*ahem) but on another we can't wait for bureaucracy to catch up (ahem*dnssec*ahem). I'm going to ignore the wildcard matter because I agree that wildcard abuse is a problem and I'd be happy to avoid them altogether. But the motivation to use TXT came from an existing RFC (albeit experimental and possibly bad design) and a way to tell the difference between records we're looking for vs records we're not looking for. Sure a query for TXT could return more than one TXT record but only one record, in theory, contains the property we'd be looking for. Consider: $ORIGIN example.com. @ TXT "property of example.com incorporated" @ TXT "antispamproperty=foo,bar,baz" @ TXT "otherprotocolproperty=something,else,entirely" Go ahead DNS people: cringe. I feel your pain. A straight TXT query would return all of these records of course. It'd be easy to tell the difference. At least I'd hope something parsing this could tell the difference. Now that was the theory. DNS purists have a problem with this, but there are apparently other applications that could have a problem with this or the DNS people wouldn't have moaned so loudly. I'm not interested in what those problems are because enough people have moaned loudly that I'll accept that it's a problem. With this in mind, I'd be glad to invent something that represents "antispamproperty=foo,bar,baz" and ask DNS vendors to support arbitrary record types as that's apparently easier than asking the DNS WG to tolerate record type abuse. Even in the Microsoft camp where I make my money, I'll swap a client's MSDNS with BIND 9 in a heartbeat [1] to support this if M$ ignores my plea to support it. Something like this should not stop us from avoiding the record overloading problem and it sure shouldn't stop us from storing sender authentication info. [1] BIND 9 supports Active Directory because it supports dynamic DNS updates. All I'd have to do is change the AD-integrated zones to standard zones, install BIND 9 for NT and tell it to use the zones MSDNS exported. Stubborn vendor's DNS replaced and new record types supported with little pain. -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Thu Mar 11 21:02:50 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2C52okw022286; Thu, 11 Mar 2004 21:02: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 i2C52oIa022285; Thu, 11 Mar 2004 21:02:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2C52onf022279 for ; Thu, 11 Mar 2004 21:02:50 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2C5Bwd21000; Thu, 11 Mar 2004 21:11:58 -0800 Date: Thu, 11 Mar 2004 21:02:48 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1039385978.20040311210248@brandenburg.com> To: ned.freed@mrochek.com CC: Dave Crocker , ietf-mxcomp@imc.org Subject: Re: Authentication and Authorization In-Reply-To: <01L7M2GASAOQ0027NR@mauve.mrochek.com> References: <20040311213735.GA24430@danisch.de> <20040311231134.GB42098@verdi> <01L7LZ6FKCRO0027NR@mauve.mrochek.com> <95554446.20040311185908@brandenburg.com> <01L7M2GASAOQ0027NR@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ned, >> That is, the policy comes from the domain owner; the server SMTP decides >> whether to conform to it. nfmc> Right, although there might be some issues surrounding what "domain owner" nfmc> means. indeed, I thought a bit about that, before sending the previous note, but decided it was a factorable question. (in other words, our efforts at precision will require dealing with the point, but it did not seem essential to include it in the previous round of posting.) but now that you've brought it up, I suggest that we be strictly operational: the domain owner is whoever has control over the RRs in the DNS, that are associated with the domain name. nfmc> Not only do we have proposals that use different parts of the DNS in nfmc> different ways, there's the mundane but nevertheless real issue that nfmc> administrative control over a domain's email policies and administrative nfmc> control over a domain's DNS entries may not be the same. oh boy. yes. but i think that we cannot do much about that, other than to suggest that mail senders have a domain name that RR records is under the control of the email administrators... >>> However, as always, an agreement at a face-to-face meeting needs to be >> confirmed online. nfmc> Agreed, and it is all the more important here since the meeting ran late and nfmc> the question didn't get posed until some people had left. and attendance by the usual suspects was quite poor, at this ietf, and... d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Thu Mar 11 21:40:40 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2C5eeiL023812; Thu, 11 Mar 2004 21:40: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 i2C5eeb7023811; Thu, 11 Mar 2004 21:40:40 -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 (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2C5edvL023802 for ; Thu, 11 Mar 2004 21:40:39 -0800 (PST) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.30) id 1B1fPa-0006gx-AI for ietf-mxcomp@imc.org; Thu, 11 Mar 2004 23:40:46 -0600 To: ietf-mxcomp@imc.org Subject: control of the DNS zone vs control of the email system References: <20040311213735.GA24430@danisch.de> <20040311231134.GB42098@verdi> <01L7LZ6FKCRO0027NR@mauve.mrochek.com> <95554446.20040311185908@brandenburg.com> <01L7M2GASAOQ0027NR@mauve.mrochek.com> From: wayne nGcc: nnml+outgoing:misc-mail Content-Type: text/plain; charset=US-ASCII Date: Thu, 11 Mar 2004 23:40:45 -0600 In-Reply-To: <01L7M2GASAOQ0027NR@mauve.mrochek.com> (ned freed's message of "Thu, 11 Mar 2004 19:32:28 -0800 (PST)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (spfd: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <01L7M2GASAOQ0027NR@mauve.mrochek.com> ned.freed@mrochek.com writes: > > [...] Not only do we have proposals that use different parts of the DNS in > different ways, there's the mundane but nevertheless real issue that > administrative control over a domain's email policies and administrative > control over a domain's DNS entries may not be the same. I really don't see this as a big deal. There *already* has to be communication between whoever controls the DNS zone and whoever controls the email system with respect to the MX records. -wayne From owner-ietf-mxcomp Fri Mar 12 00:02:24 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2C82Oqt073621; Fri, 12 Mar 2004 00:02: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 i2C82OCU073620; Fri, 12 Mar 2004 00:02:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2C82N46073604 for ; Fri, 12 Mar 2004 00:02:23 -0800 (PST) (envelope-from hadmut@danisch.de) Received: from www.rackland.de (localhost [127.0.0.1]) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with SMTP id i2C82Mod017700; Fri, 12 Mar 2004 09:02:22 +0100 Received: from 192.109.50.53 (SquirrelMail authenticated user hadmut) by www.rackland.de with HTTP; Fri, 12 Mar 2004 09:02:22 +0100 (CET) Message-ID: <60830.192.109.50.53.1079078542.squirrel@www.rackland.de> In-Reply-To: References: Date: Fri, 12 Mar 2004 09:02:22 +0100 (CET) Subject: RE: Authentication and Authorization From: "Hadmut Danisch" To: "Hallam-Baker, Phillip" Cc: 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: > These references are irrelevant, they are all informal definitions, > most appear to be from marketting litterature. > > The relevant references here are security standards, NOT marketting > litterature. These references would be a good starting point then if they have different or better definitions. Could you cite? regards Hadmut From owner-ietf-mxcomp Fri Mar 12 00:00:35 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2C80Zt3072902; Fri, 12 Mar 2004 00:00: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 i2C80Zgr072901; Fri, 12 Mar 2004 00:00:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2C80WZj072862 for ; Fri, 12 Mar 2004 00:00:35 -0800 (PST) (envelope-from hadmut@danisch.de) Received: from www.rackland.de (localhost [127.0.0.1]) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with SMTP id i2C80Tod017628; Fri, 12 Mar 2004 09:00:29 +0100 Received: from 192.109.50.53 (SquirrelMail authenticated user hadmut) by www.rackland.de with HTTP; Fri, 12 Mar 2004 09:00:29 +0100 (CET) Message-ID: <58986.192.109.50.53.1079078429.squirrel@www.rackland.de> In-Reply-To: References: Date: Fri, 12 Mar 2004 09:00:29 +0100 (CET) Subject: RE: Authentication and Authorization From: "Hadmut Danisch" To: "Hallam-Baker, Phillip" Cc: 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: > >> Can we live with Hadmut's definition of "authorization"? >> (Keeping in mind that others will have different definitions) > > Not if we want the spec to be comprehensible in the security > community. Oh, I thought I came from the security community. If there is any different definition used in the "security community", could you give me a reference? That's interesting. > We are not putting permissions data in the DNS here, we are > putting credentials data in the DNS and stating that recipients > should verify that mail messages purporting to originate from > the zone are authentic with respect to a credential. "credentials" is a term commonly used for attributes of an entity. What we keep in the DNS are authorization records, not really credentials. Again, could you give a citation for your definition? regards Hadmut From owner-ietf-mxcomp Fri Mar 12 04:03:13 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2CC3DAb029554; Fri, 12 Mar 2004 04:03: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 i2CC3DHi029553; Fri, 12 Mar 2004 04:03:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2CC3C26029545 for ; Fri, 12 Mar 2004 04:03:12 -0800 (PST) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id 4DB3BE0CE8; Fri, 12 Mar 2004 07:03:11 -0500 (EST) Date: Fri, 12 Mar 2004 07:03:11 -0500 From: John Leslie To: Dave Crocker Cc: ietf-mxcomp@imc.org Subject: Re: Authentication and Authorization Message-ID: <20040312120311.GE42098@verdi> References: <20040311213735.GA24430@danisch.de> <20040311231134.GB42098@verdi> <01L7LZ6FKCRO0027NR@mauve.mrochek.com> <95554446.20040311185908@brandenburg.com> <01L7M2GASAOQ0027NR@mauve.mrochek.com> <1039385978.20040311210248@brandenburg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1039385978.20040311210248@brandenburg.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dave Crocker wrote: > [ned.freed@mrochek.com wrote:] >> [Dave Crocker wrote:] [ commenting on: Hadmut: Policy Receiving MTA's way to treat messages with or Hadmut: without Signature, LMAP authorization, or from Hadmut: domains without LMAP record, or DNS server down ] >>> That is, the policy comes from the domain owner; the server >>> SMTP decides whether to conform to it. > >> Right, although there might be some issues surrounding what >> "domain owner" means. > > indeed, I thought a bit about that, before sending the previous > note, but decided it was a factorable question. (in other words, > our efforts at precision will require dealing with the point, > but it did not seem essential to include it in the previous round > of posting.) (I don't personally believe there's any hope that this WG can agree on a single meaning for "policy". Nonetheless, there are useful discussions to be held on what function(s) we envision for the information in the DNS record(s).) > but now that you've brought it up, I suggest that we be strictly > operational: the domain owner is whoever has control over the RRs > in the DNS, that are associated with the domain name. Here, I disagree with Dave. Rather than try to define "domain owner", we should try to define function; after that is agreed, we may or may not find that "ownership" of the domain makes a difference. As the operator of a MTA, I would like to signal that I have reason to believe the MAIL-From is a useful bounce address, and that I will respond to complaints if it isn't, or if anything about the email itself is abusive. Note that I have no desire to certify anything in particular about the contents of the email. If we want to use the "authorize" word here, I take it to mean that someone acting on behalf of HELO.domain has authorized me to transfer email on behalf of that domain, and that this particular email is sent under that authorization. I believe the "authorization" makes little difference to the operation of the 'net, while the signals about HELO and MAIL-From are the important functions. -- John Leslie From owner-ietf-mxcomp Fri Mar 12 06:14:47 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2CEEll6040102; Fri, 12 Mar 2004 06:14: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 i2CEElkV040101; Fri, 12 Mar 2004 06:14:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2CEEkw1040095 for ; Fri, 12 Mar 2004 06:14:47 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i2CEEkqS018921; Fri, 12 Mar 2004 06:14:46 -0800 (PST) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Fri, 12 Mar 2004 06:14:45 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Hadmut Danisch'" , "Hallam-Baker, Phillip" Cc: ietf-mxcomp@imc.org Subject: RE: Authentication and Authorization Date: Fri, 12 Mar 2004 06:14:41 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > >> Can we live with Hadmut's definition of "authorization"? > >> (Keeping in mind that others will have different definitions) > > > > Not if we want the spec to be comprehensible in the security > > community. > > Oh, I thought I came from the security community. You cited secondary and marketting litterature. I wrote the SAML spec. > If there is any different definition used in the "security > community", could you give me a reference? That's interesting. We defined the following Authentication - The PROCESS of determining that "alice" is Alice - The decision arrived at by an authentication process Authorization Decision - A statement by the controller of a resource granting access to Alice Authorization Policy - A statement of the criteria used to make an Authorization Decision. > > We are not putting permissions data in the DNS here, we are > > putting credentials data in the DNS and stating that recipients > > should verify that mail messages purporting to originate from > > the zone are authentic with respect to a credential. > > "credentials" is a term commonly used for attributes of an > entity. What we keep in the DNS are authorization records, not > really credentials. Again, could you give a citation for your > definition? A credential is a piece of data used to authenticate an individual. usually it is the part carried by the user though rather than the part used for verification. E.g. A digital certificate, a password, a biometric profile. There is some precedent for calling the information in the DNS a credential, but there is none for calling it an authorization. The owner of the resource here is the receiver of the message, it is the receipt of email service that is being controlled. Phill From owner-ietf-mxcomp Fri Mar 12 06:13:48 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2CEDm98040029; Fri, 12 Mar 2004 06:13: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 i2CEDmsc040028; Fri, 12 Mar 2004 06:13:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2CEDlUC040022 for ; Fri, 12 Mar 2004 06:13:47 -0800 (PST) (envelope-from hadmut@danisch.de) Received: from www.rackland.de (localhost [127.0.0.1]) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with SMTP id i2CEDgod024162; Fri, 12 Mar 2004 15:13:42 +0100 Received: from 192.109.50.41 (SquirrelMail authenticated user hadmut) by www.rackland.de with HTTP; Fri, 12 Mar 2004 15:13:42 +0100 (CET) Message-ID: <56533.192.109.50.41.1079100822.squirrel@www.rackland.de> In-Reply-To: <95554446.20040311185908@brandenburg.com> References: <20040311213735.GA24430@danisch.de> <20040311231134.GB42098@verdi><01L7LZ6FKCRO0027NR@mauve.mrochek.com> <95554446.20040311185908@brandenburg.com> Date: Fri, 12 Mar 2004 15:13:42 +0100 (CET) Subject: Re: Authentication and Authorization From: "Hadmut Danisch" To: "Dave Crocker" Cc: 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: > I think that Hadmut is moving us in the right direction, but I continue > to urge us to be more precise: > > >>> > Identity Sending MTA's IP address > > This means the peer, SMTP client, right? Exactly. And (in contrast to Microsoft's CallerID) within the time of the running SMTP connecting. Basically, this is what the receiving MTA gets with the getpeername() function (before finishing the SMTP connection, and even before replying OK to DATA). >>> > Authentication Verifying the Identity (TCP sequence numbers) >>> > >>> > Authorization Domain owner's statement > > Which domain? The domain given in the sender's address (or whatever part of the message. That who's held responsible in case of spam). > For example, I suspect that the definition, for this level of > discussion, needs to be something like "the owner of a domain that is > obtained from some portion of an SMTP transaction." Exactly. Good description. It is just that we somehow use the incoming message to locate a domain willing to authorize the sending MTA. >>> > Policy Receiving MTA's way to treat messages with or >>> > without Signature, LMAP authorization, or from >>> > domains without LMAP record, or DNS server down > > Most discussions have described a policy as guidance, from the domain > owner and to the server SMTP, concerning the way the server should treat > messages... > > That is, the policy comes from the domain owner; the server SMTP decides > whether to conform to it. No, that's what I do not agree with. The domain owner gives the authorization to use his domain or not. In my receiving SMTP relay I do not conform to anyone else's decisions. In my SMTP receiver I am the emperor, the one and only. (Wow!) I am the master of the dark forces and the configuration files. I am the one instructing the relay what to do with mails which failed the authorization check for the various reasons. I do instruct whether to burn them, tag them, move the priority down to junk or whatever. This decision given by me, the emperor, shall be known as my policy. My receiving MTA enforces my policy, because I am the one to write the configuration file. And it is my decision whether to accept mails which fail the check or not. This is not the domain owner's decision. And for exactly this reason it could also be my decision (spell: my policy) to not accept messages from domains which authorize 0.0.0.0/0 (=everyone). There are two statements need to make this all work: - The domain owner's statement, called the authorization - The receiving MTA owner's statement what to do with suspect mails, called the policy. regards Hadmut From owner-ietf-mxcomp Fri Mar 12 06:24:01 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2CEO0wT041072; Fri, 12 Mar 2004 06:24: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 i2CEO0f5041071; Fri, 12 Mar 2004 06:24:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2CEO0DD041065 for ; Fri, 12 Mar 2004 06:24:00 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2CEX6d22850 for ; Fri, 12 Mar 2004 06:33:06 -0800 Date: Fri, 12 Mar 2004 06:23:55 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <911791307.20040312062355@brandenburg.com> To: ietf-mxcomp@imc.org Subject: Re: Authentication and Authorization In-Reply-To: <20040312120311.GE42098@verdi> References: <20040311213735.GA24430@danisch.de> <20040311231134.GB42098@verdi> <01L7LZ6FKCRO0027NR@mauve.mrochek.com> <95554446.20040311185908@brandenburg.com> <01L7M2GASAOQ0027NR@mauve.mrochek.com> <1039385978.20040311210248@brandenburg.com> <20040312120311.GE42098@verdi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: John, >> the domain owner is whoever has control over the RRs >> in the DNS, that are associated with the domain name. JL> Here, I disagree with Dave. Rather than try to define "domain JL> owner", we should try to define function; after that is agreed, JL> we may or may not find that "ownership" of the domain makes a JL> difference. well, i was taking 'domain ownership' as the term already in use, but i agree that it's better to drop the term and just talk about contents of the RRs associated with the domain name. >>>> > Authentication Verifying the Identity (TCP sequence numbers) >>>> > Authorization Domain owner's statement >> >> Which domain? HD> The domain given in the sender's address (or whatever part of the HD> message. That who's held responsible in case of spam). I suggest we eliminate use of the word "sender", except as part of the term "RFC2822 Sender". When used without qualifiers, the term "sender" is now ambiguous. So which, exact, field provides the domain string on which authorization is based? d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Fri Mar 12 06:28:58 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2CESwlC041384; Fri, 12 Mar 2004 06:28: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 i2CESwM4041383; Fri, 12 Mar 2004 06:28:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mauve.mrochek.com ([209.55.107.55]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2CESvTU041377 for ; Fri, 12 Mar 2004 06:28:57 -0800 (PST) (envelope-from ned.freed@mrochek.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01L7KTEM74YO0027NR@mauve.mrochek.com> for ietf-mxcomp@imc.org; Fri, 12 Mar 2004 06:28:59 -0800 (PST) Date: Fri, 12 Mar 2004 06:27:53 -0800 (PST) From: ned.freed@mrochek.com Subject: Re: Authentication and Authorization In-reply-to: "Your message dated Thu, 11 Mar 2004 21:02:48 -0800" <1039385978.20040311210248@brandenburg.com> To: Dave Crocker Cc: ned.freed@mrochek.com, Dave Crocker , ietf-mxcomp@imc.org Message-id: <01L7MOXFJG4Y0027NR@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <20040311213735.GA24430@danisch.de> <20040311231134.GB42098@verdi> <01L7LZ6FKCRO0027NR@mauve.mrochek.com> <95554446.20040311185908@brandenburg.com> <01L7M2GASAOQ0027NR@mauve.mrochek.com> <1039385978.20040311210248@brandenburg.com> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > ned, > >> That is, the policy comes from the domain owner; the server SMTP decides > >> whether to conform to it. > nfmc> Right, although there might be some issues surrounding what "domain owner" > nfmc> means. > indeed, I thought a bit about that, before sending the previous note, > but decided it was a factorable question. (in other words, our efforts > at precision will require dealing with the point, but it did not seem > essential to include it in the previous round of posting.) > but now that you've brought it up, I suggest that we be strictly > operational: the domain owner is whoever has control over the RRs in the > DNS, that are associated with the domain name. Seems reasonable enough to me. > nfmc> Not only do we have proposals that use different parts of the DNS in > nfmc> different ways, there's the mundane but nevertheless real issue that > nfmc> administrative control over a domain's email policies and administrative > nfmc> control over a domain's DNS entries may not be the same. > oh boy. yes. but i think that we cannot do much about that, other than > to suggest that mail senders have a domain name that RR records is under the > control of the email administrators... I agree it isn't something we can fix, but it is another issue to keep in mind. The list is long... > >>> However, as always, an agreement at a face-to-face meeting needs to be > >> confirmed online. > nfmc> Agreed, and it is all the more important here since the meeting ran late and > nfmc> the question didn't get posed until some people had left. > and attendance by the usual suspects was quite poor, at this ietf, and... Yep. More than the usual caveats apply. Ned From owner-ietf-mxcomp Fri Mar 12 06:31:27 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2CEVRG2041545; Fri, 12 Mar 2004 06:31:27 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2CEVRY0041544; Fri, 12 Mar 2004 06:31:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2CEVQwf041538 for ; Fri, 12 Mar 2004 06:31:26 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.11/) with ESMTP id i2CEVSpU027297; Fri, 12 Mar 2004 06:31:28 -0800 (PST) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Fri, 12 Mar 2004 06:31:28 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Gordon Fecyk'" , "IETF MXCOMP (E-mail)" Subject: RE: Potential Work Item: New DNS resource records Date: Fri, 12 Mar 2004 06:31:28 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > We're caught between a rock and a hard place over this. On > one side we don't want to break existing functionality in DNS > (ahem*s*te-f*nd*r*ahem) but on > another we can't wait for bureaucracy to catch up (ahem*dnssec*ahem). No existing functionality is broken if you use the prefix mechanism. SRV already does this. The bureaucracy never catches up, it simply says no. > I'm going to ignore the wildcard matter because I agree that > wildcard abuse > is a problem and I'd be happy to avoid them altogether. Synthetic wildcards work fine. There is no reason that the wildcard has to be cacheable in this application. > Sure a query for TXT could return more than > one TXT record but only one record, in theory, contains the > property we'd be looking for. Consider: > > $ORIGIN example.com. > @ TXT "property of example.com incorporated" > @ TXT "antispamproperty=foo,bar,baz" > @ TXT "otherprotocolproperty=something,else,entirely" > > Go ahead DNS people: cringe. I feel your pain. Hence my proposal to use _prefix. It provides exactly the same degree of extensibiliy and scalability as defining new RRs does. We can view an RR as defining the syntax for the corresponding data. > With this in mind, I'd be glad to invent something that represents > "antispamproperty=foo,bar,baz" and ask DNS vendors to support > arbitrary > record types as that's apparently easier than asking the DNS > WG to tolerate > record type abuse. Ignoring the DNS WG is the best, most satisfactory and easiest route. By the time the proposal reaches the comment from other groups stage the water will have flowed way past their bridge. They are the folk who said 'it does not matter if DNSSEC is not deployable in .com, the solution is to reduce the size of .com'. There is a legitimate, principled architecture behind the prefix proposal. > [1] BIND 9 supports Active Directory because it supports > dynamic DNS updates. > All I'd have to do is change the AD-integrated zones to > standard zones, > install BIND 9 for NT and tell it to use the zones MSDNS > exported. Stubborn > vendor's DNS replaced and new record types supported with little pain. No deal, I will take a vendor, any vendor over the DNS WG any day. The vendors can drive deployment. The DNS WG will only crash the car. Phill From owner-ietf-mxcomp Fri Mar 12 06:45:01 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2CEj1RJ042087; Fri, 12 Mar 2004 06:45:01 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2CEj1ZT042086; Fri, 12 Mar 2004 06:45:01 -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 (srv1.fecyk.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2CEj0ga042077 for ; Fri, 12 Mar 2004 06:45:00 -0800 (PST) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: Potential Work Item: New DNS resource records MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 12 Mar 2004 08:45:02 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA7BF@srv1.fecyk.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Potential Work Item: New DNS resource records Thread-Index: AcQIPrXPeS+V2yRdQbiS3r3aj5d8uQAAVNCQ 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 i2CEj1ga042081 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > -----Original Message----- > From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com] > Sent: Friday, March 12, 2004 08:31 > To: Gordon Fecyk; IETF MXCOMP (E-mail) > Subject: RE: Potential Work Item: New DNS resource records > Ignoring the DNS WG is the best, most satisfactory and easiest > route. [...] > The vendors can drive deployment. The DNS WG will only crash the > car. /me ducks to avoid inevitable firefight -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Fri Mar 12 07:19:55 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2CFJtxN044059; Fri, 12 Mar 2004 07:19: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 i2CFJtxw044058; Fri, 12 Mar 2004 07:19:55 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2CFJtmT044052 for ; Fri, 12 Mar 2004 07:19:55 -0800 (PST) (envelope-from hardie@qualcomm.com) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i2CFJuvf016348 for ; Fri, 12 Mar 2004 07:19:56 -0800 (PST) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i2CFJsvx001049 for ; Fri, 12 Mar 2004 07:19:54 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <95554446.20040311185908@brandenburg.com> References: <20040311213735.GA24430@danisch.de> <20040311231134.GB42098@verdi> <01L7LZ6FKCRO0027NR@mauve.mrochek.com> <95554446.20040311185908@brandenburg.com> Date: Fri, 12 Mar 2004 07:19:52 -0800 To: ietf-mxcomp@imc.org From: Ted Hardie Subject: Re: Authentication and Authorization Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 6:59 PM -0800 03/11/2004, Dave Crocker wrote: > >> " Is there IETF work that we should take on to develop a mechanism >>> " that allows an MTA to use a DNS-based record to signal to peer >>> " MTA's that it is authorized to send mail? > >nfmc> Very good point. > >For reference, I think this is the right scope and goal for an IETF >working group to tackle. > >However, as always, an agreement at a face-to-face meeting needs to be >confirmed online. I've gotten a couple of private question about this, since the handling of this in a BoF could be a bit different from that of a working group. To clarify my take it, when a BoF is asked a question about the work the IETF should take on in an area, it is confirmed by an IETF-wide last call on the charter; since the IETF as a whole will spend resources on a topic (in the form of cross-area review, IESG time, meeting space, mailing lists, and so), it is appropriate that an IETF-wide scope be used for the confirmation. The charter will, of course, be discussed on this list, but the confirmation is at a larger stage. I apologize for the delay in presenting a charter to the group; I hope to do so in the very near future. Ted Hardie From owner-ietf-mxcomp Fri Mar 12 07:53:04 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2CFr4BF046830; Fri, 12 Mar 2004 07:53: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 i2CFr4HN046829; Fri, 12 Mar 2004 07:53:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2CFr38f046821 for ; Fri, 12 Mar 2004 07:53:03 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.11/) with ESMTP id i2CFr6oT005636; Fri, 12 Mar 2004 07:53:06 -0800 (PST) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Fri, 12 Mar 2004 07:53:06 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Gordon Fecyk'" , "IETF MXCOMP (E-mail)" Subject: RE: Potential Work Item: New DNS resource records Date: Fri, 12 Mar 2004 07:53:03 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > Ignoring the DNS WG is the best, most satisfactory and easiest > > route. > [...] > > The vendors can drive deployment. The DNS WG will only crash the > > car. > > /me ducks to avoid inevitable firefight Heh, heh, I don't think the DNSEXT guys are watching. They can't believe that something as horrible as SPF might happen to the DNS. My backchannels are reporting that several folk who think they are in control here are saying they agreed to the MARID group only as the best way to kill the idea. So no, I am not going to take proposals to wait three years for a RR at all seriously. I have a product here that will launch in months. You know exactly how much weight I give to the ponderances of the IETF :-) What I hope MARID will do is to trim out the unnecessary decoration form SPF, but anything that threatens to delay deployment is going to cause the group to bolt. Phill From owner-ietf-mxcomp Fri Mar 12 08:00:06 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2CG06Aj047475; Fri, 12 Mar 2004 08:00: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 i2CG06EG047474; Fri, 12 Mar 2004 08:00:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2CG05JS047468 for ; Fri, 12 Mar 2004 08:00:06 -0800 (PST) (envelope-from hadmut@danisch.de) Received: from andromeda (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i2CG08NW026766; Fri, 12 Mar 2004 17:00:08 +0100 Received: (from hadmut@localhost) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-3) id i2CFkKWb025850; Fri, 12 Mar 2004 16:46:20 +0100 From: Hadmut Danisch Date: Fri, 12 Mar 2004 16:46:20 +0100 To: "Hallam-Baker, Phillip" Cc: ietf-mxcomp@imc.org Subject: Re: Authentication and Authorization Message-ID: <20040312154620.GA25491@danisch.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1+cvs20040105i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Mar 12, 2004 at 06:14:41AM -0800, Hallam-Baker, Phillip wrote: > > You cited secondary and marketting litterature. I wrote the > SAML spec. Oh, come on Phil, that's ridiculous. Everything not meeting your taste is "secondary", buth the SAML is the holy bible and the encyclopaedia galactia. As if the security community was just waiting for SAML to redefine their terms. > We defined the following "We"? Who? Anyone authorized to arbitrarily define terms in a way that all other definitions become wrong at once? > Authentication - The PROCESS of determining that "alice" is > Alice > - The decision arrived at by an authentication > process > > Authorization Decision > - A statement by the controller of a resource > granting access to Alice > > Authorization Policy > - A statement of the criteria used to make > an Authorization Decision. This is not convincing. An "authorization policy" is a special kind of policy, this doesn't mean that every policy needs to be an authorization policy. A firefighter's truck is also a car, which doesn't imply that it necessarily take firefighters sitting in to make a car a car. If your definition was applicable for policies in common, you could never have a policy without authorization. I am talking about the policy of the receiving MTA, the configuration on which the decision to accept or not a message is based. That's an Anti Spam Policy, not an Authorization Policy. You might continue to call the decisions whom to authorize an Authorization Policy, but that's confusing and useless. Because it's outside the scope to tell domain owner's whom to authorize. That's their private business. > A credential is a piece of data used to authenticate an individual. > usually it is the part carried by the user though rather than the > part used for verification. > > E.g. A digital certificate, a password, a biometric profile. So this is definitely not what we are storing in DNS. The TCP sequence number is the credential here. > There is some precedent for calling the information in the DNS > a credential, but there is none for calling it an authorization. Why should we call it credential, if it isn't involved in authentication? > The owner of the resource here is the receiver of the message, > it is the receipt of email service that is being controlled. No. Definitely not. That's nonsense. The resource is the e-mail address to be used as a sender address. And even if it were to be called a resource, I as the owner of my receiving MTA will not accept that anyone else is giving me a policy that I would have to enforce. If I receive a message from sales@somedomain.com , then it is definitely not somedomain.com's owner's decision what my own MTA is receiving or not. Your view doesn't make sense. It is up to somedomain.com's owner to decide who is authorized to use @somedomain.com in the sender address. It is my own decision and my policy and nobody else's policy whether my MTA is accepting unauthorized messages or not. My MTA under my control will enforce my policy only and nothing else. I guess everyone else will agree with that. This is consistent with my definition, but not with yours. regards Hadmut From owner-ietf-mxcomp Fri Mar 12 08:10:06 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2CGA5Sp048624; Fri, 12 Mar 2004 08:10:05 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2CGA5up048623; Fri, 12 Mar 2004 08:10:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2CGA5bw048615 for ; Fri, 12 Mar 2004 08:10:05 -0800 (PST) (envelope-from hardie@qualcomm.com) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i2CGA6vf018400; Fri, 12 Mar 2004 08:10:06 -0800 (PST) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i2CGA3VK025038; Fri, 12 Mar 2004 08:10:04 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: References: Date: Fri, 12 Mar 2004 08:10:01 -0800 To: "Hallam-Baker, Phillip" , "'Gordon Fecyk'" , "IETF MXCOMP (E-mail)" From: Ted Hardie Subject: RE: Potential Work Item: New DNS resource records Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 7:53 AM -0800 03/12/2004, Hallam-Baker, Phillip wrote: > >My backchannels are reporting that several folk who think they are >in control here are saying they agreed to the MARID group only as >the best way to kill the idea. As one of the co-chairs of the BoF and the sponsoring AD of the proposed WG, I respectfully request you to stop using innuendo in this group. Other than the group at the BoF, no one has yet agreed to the group (cf. my previous message to the list on confirmation by the IETF), and no one who has discussed this with me has held the attitude that you report. Not that it is all that important in any case; we're here to solve an engineering problem, not have a group discussion of motivation. Please stick to the work at hand, thanks, Ted Hardie From owner-ietf-mxcomp Fri Mar 12 08:40:14 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2CGeEtx050156; Fri, 12 Mar 2004 08:40: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 i2CGeEKi050155; Fri, 12 Mar 2004 08:40:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.40]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2CGeDYa050144 for ; Fri, 12 Mar 2004 08:40:13 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.50] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1B1phh-0000YZ-00; Fri, 12 Mar 2004 11:40:09 -0500 Received: from [68.244.238.33] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1B1phg-0003ce-00; Fri, 12 Mar 2004 11:40:09 -0500 Message-ID: <4051E7D6.6020401@solidmatrix.com> Date: Fri, 12 Mar 2004 11:39:50 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: "Hallam-Baker, Phillip" CC: "'Gordon Fecyk'" , "IETF MXCOMP (E-mail)" Subject: Re: Potential Work Item: New DNS resource records References: In-Reply-To: X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hallam-Baker, Phillip wrote: > >>We're caught between a rock and a hard place over this. On >>one side we don't want to break existing functionality in DNS >>(ahem*s*te-f*nd*r*ahem) but on >>another we can't wait for bureaucracy to catch up (ahem*dnssec*ahem). > > > No existing functionality is broken if you use the prefix > mechanism. SRV already does this. > Before defining *how* the data is stored in DNS, we should work on *what* that data is. There is a significant disagreement on what kind of data should be included among different proposals, and this is something that is more important than how the actual data is stored. This is akin to writing up the book before figuring out what the cover page and the title should be, as opposed to picking a title and the picture on the cover, before writing the content. > > >>With this in mind, I'd be glad to invent something that represents >>"antispamproperty=foo,bar,baz" and ask DNS vendors to support >>arbitrary >>record types as that's apparently easier than asking the DNS >>WG to tolerate >>record type abuse. > > > Ignoring the DNS WG is the best, most satisfactory and easiest > route. By the time the proposal reaches the comment from other > groups stage the water will have flowed way past their bridge. > > They are the folk who said 'it does not matter if DNSSEC is not > deployable in .com, the solution is to reduce the size of .com'. > > There is a legitimate, principled architecture behind the prefix > proposal. > As much as some of us may be interested in your "war stories" about fighting the "gods" of the IETF, this is not proper forum for that type of discussion. Yakov From owner-ietf-mxcomp Fri Mar 12 09:05:12 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2CH5CAB051628; Fri, 12 Mar 2004 09:05:12 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2CH5CEa051627; Fri, 12 Mar 2004 09:05:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2CH5BHI051613 for ; Fri, 12 Mar 2004 09:05:11 -0800 (PST) (envelope-from hadmut@danisch.de) Received: from andromeda (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i2CH57hx028491; Fri, 12 Mar 2004 18:05:07 +0100 Received: (from hadmut@localhost) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-3) id i2CH1jK3028661; Fri, 12 Mar 2004 18:01:45 +0100 From: Hadmut Danisch Date: Fri, 12 Mar 2004 18:01:45 +0100 To: Yakov Shafranovich Cc: "IETF MXCOMP (E-mail)" Subject: Re: Potential Work Item: New DNS resource records Message-ID: <20040312170145.GA28615@danisch.de> References: <4051E7D6.6020401@solidmatrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4051E7D6.6020401@solidmatrix.com> User-Agent: Mutt/1.5.5.1+cvs20040105i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Mar 12, 2004 at 11:39:50AM -0500, Yakov Shafranovich wrote: > > Before defining *how* the data is stored in DNS, we should work on > *what* that data is. Absolutely. Once we know what to do encoding is a simple task. If we only knew what we want to do. regards Hadmut From owner-ietf-mxcomp Fri Mar 12 09:06:25 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2CH6PX6051688; Fri, 12 Mar 2004 09:06: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 i2CH6PeP051687; Fri, 12 Mar 2004 09:06:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2CH6O4S051681 for ; Fri, 12 Mar 2004 09:06:24 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.11/) with ESMTP id i2CH6SEJ013347 for ; Fri, 12 Mar 2004 09:06:28 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Fri, 12 Mar 2004 09:06:28 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "IETF MXCOMP (E-mail)" Subject: Real work items (Was: DNS etc.) Date: Fri, 12 Mar 2004 09:06:24 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Before defining *how* the data is stored in DNS, we should work on > *what* that data is. There is a significant disagreement on > what kind of > data should be included among different proposals, and this > is something > that is more important than how the actual data is stored. Agreed, moreover how many different ways do we need to express the same data? What is the best way to deal with the forwarding problem? should we attempt to define a macro language as Meng has done? Should we attempt some other means of addressing this problem? Does this mean that the charter should allow discussion of mechanisms other than pure DNS publication rules? > This is akin to writing up the book before figuring out > what the cover page and the > title should be, as opposed to picking a title and the picture on the > cover, before writing the content. We should probably discuss use cases and requirements. I believe use cases would be very helpful. Not the normal alice talks to bob use cases. I want to see the salient header features. My belief is that there are only really two interesting use cases: 1) Mail is sent to alice@example.com, possibly forwarded under the same name via relays controlled by the sender or receiver's ISP. 2) Mail is send to email@alias.example.com and forwarded under a different name, either through the action of a mailing list or a mail forwarding arrangement. There are also uninteresting use cases like going through open relays. Case (2) is where all the corner cases come from. One way to address this problem is by defining the actions of forwarders that change names very carefully. > As much as some of us may be interested in your "war stories" about > fighting the "gods" of the IETF, this is not proper forum for > that type of discussion. If it is asserted that a party has a legitimate interest in the direction of a spec it is legitimate to point out that they should be ignored. Phill From owner-ietf-mxcomp Fri Mar 12 09:24:31 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2CHOVjX053044; Fri, 12 Mar 2004 09:24:31 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2CHOVZD053043; Fri, 12 Mar 2004 09:24:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2CHOVIQ053037 for ; Fri, 12 Mar 2004 09:24:31 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.11/) with ESMTP id i2CHOW5a020695; Fri, 12 Mar 2004 09:24:32 -0800 (PST) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Fri, 12 Mar 2004 09:24:32 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Hadmut Danisch'" , "Hallam-Baker, Phillip" Cc: ietf-mxcomp@imc.org Subject: RE: Authentication and Authorization Date: Fri, 12 Mar 2004 09:24:23 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Oh, come on Phil, that's ridiculous. Everything not meeting your > taste is "secondary", buth the SAML is the holy bible and the > encyclopaedia galactia. As if the security community was just > waiting for SAML to redefine their terms. If you get 30 security people together in a room and they argue over these definitions for days followed by months on mailing lists and con calls I will give the result rather more weight than Merriam Webster or Checkpoint marketting litterature. dictionary definitions are irrelevant to a standards discussion when the word is already an established term of art in a specialist field. Take a look at XACML or AAARG. The weakness of your proposal is that you confuse two separate points of view. Sure the data in the DNS reflects the fact that the domain name owner has 'authorized' it to be there. But the same can be said of every single action a computer takes. A computer with security controls does not do anything without an authentication and authorization process having taken place. > "We"? Who? Anyone authorized to arbitrarily define terms in > a way that all other definitions become wrong at once? Take a look at the list of group members. Most of them are the principal architects of the main authorization products. > > Authentication - The PROCESS of determining that "alice" is > > Alice > > - The decision arrived at by an authentication > > process > > > > Authorization Decision > > - A statement by the controller of a resource > > granting access to Alice > > > > Authorization Policy > > - A statement of the criteria used to make > > an Authorization Decision. > > This is not convincing. An "authorization policy" is a special > kind of policy, this doesn't mean that every policy needs to be > an authorization policy. Absolutely. That is the point. Policy has tended to be the catch all bucket for 'something else'. What we have in the DNS is not an authorization policy. It could be called a credential policy. It is certainly a policy though. The domain is saying 'my security policy is that all messages that originate from this domain are capable of presenting the credentials described thus.' > > If your definition was applicable for policies in common, you > could never have a policy without authorization. Policies is a broader term, certainly. > I am talking about the policy of the receiving MTA, the configuration > on which the decision to accept or not a message is based. That's an > Anti Spam Policy, not an Authorization Policy. I will accept that term. But how about we think about the general case. I could put a record in the DNS saying 'all my email is S/MIME signed', 'my email servers always offer STARTTLS', 'My web servers always offer TLs upgrade'. Hence I prefer the term security policy as the most general case, security credential policy. > You might continue to call the decisions whom to authorize an > Authorization Policy, but that's confusing and useless. Because it's > outside the scope to tell domain owner's whom to authorize. That's > their private business. Actually that was the point I was trying to get across. I thought you were the person pushing to use the term authorization. > > A credential is a piece of data used to authenticate an individual. > > usually it is the part carried by the user though rather than the > > part used for verification. > > > > E.g. A digital certificate, a password, a biometric profile. > > So this is definitely not what we are storing in DNS. > The TCP sequence number is the credential here. The TCP address is one credential. The sequence number is a challenge/response token. > > There is some precedent for calling the information in the DNS > > a credential, but there is none for calling it an authorization. > > Why should we call it credential, if it isn't involved in > authentication? It provides the match criteria. Same as a biometric profile. > > The owner of the resource here is the receiver of the message, > > it is the receipt of email service that is being controlled. > > No. Definitely not. That's nonsense. The resource is the e-mail > address to be used as a sender address. I will have to think that one through. I believe my viewpoint is valid. Yours may also be valid. The problem here is that if you work from the viewpoint of the email address it starts to look like a DRM problem. > It is my own decision and my policy and nobody else's policy whether > my MTA is accepting unauthorized messages or not. My view is that if you accept a mail it is by definition authorized, if you reject it is by definition nont authorized. Therefore it is a logical impossibility for you to accept an unauthorized message. I think that it is completely valid for you to ignore the sender' security policy or any third party accreditation information if you choose. > My MTA under my control will enforce my policy only and nothing else. > I guess everyone else will agree with that. > > This is consistent with my definition, but not with yours. I don't think you have understood my position. I understand yours, you are trying to protect the address as a resource. From owner-ietf-mxcomp Fri Mar 12 09:32:15 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2CHWFuM053379; Fri, 12 Mar 2004 09:32: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 i2CHWFgh053378; Fri, 12 Mar 2004 09:32:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (mail.winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2CHWEh9053372 for ; Fri, 12 Mar 2004 09:32:14 -0800 (PST) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v5.7.450.9b13) for ietf-mxcomp@imc.org; Fri, 12 Mar 2004 12:34:13 -0500 Received: from ([68.215.115.72]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v5.7.450.9b13) with SMTP id 3565423781; Fri, 12 Mar 2004 12:34:12 -0500 Message-ID: <00dd01c40858$0a7858e0$6401a8c0@hdev1> From: "Hector Santos" To: "IETF MXCOMP \(E-mail\)" References: Subject: Re: Real work items (Was: DNS etc.) Date: Fri, 12 Mar 2004 12:32:41 -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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In my technical opinion, the weight of LMAP has on DNS, coupled with the complexity (or basic fact that coding needs to be done and development resources need to be allocated), while it may address the problem, it is too narrow in scope. In other words, we should use the opportunity to add more information such as server attributes so that we can begin to shift more logic or burden to the client to use this upfront information. The client needs to go to DNS to get the MX records anyway. So why not have it "get more" information about the server itself. This will help tremendously in reducing network bandwidth. Just consider that if all this work is presumed to pay off at stopping (or better managing) the anonymous access/spammer, the issue of overhead will evolve to one of redundancy. So I think the whole of idea of adding DNS records will be more "plausible" if it contained more information (server attributes). However, having studied and research this idea over the last few months, it will only work with a change to SMTP as it has concepts to authenticate, challenge and protect the client/server negotiation process using the server attribute information. I do have an outline draft on this idea but stopped to work with current directions instead. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com ----- Original Message ----- From: "Hallam-Baker, Phillip" To: "IETF MXCOMP (E-mail)" Sent: Friday, March 12, 2004 12:06 PM Subject: Real work items (Was: DNS etc.) > > > Before defining *how* the data is stored in DNS, we should work on > > *what* that data is. There is a significant disagreement on > > what kind of > > data should be included among different proposals, and this > > is something > > that is more important than how the actual data is stored. > > Agreed, moreover how many different ways do we need to express > the same data? > > What is the best way to deal with the forwarding problem? > should we attempt to define a macro language as Meng has > done? Should we attempt some other means of addressing this > problem? Does this mean that the charter should allow > discussion of mechanisms other than pure DNS publication > rules? > > > This is akin to writing up the book before figuring out > > what the cover page and the > > title should be, as opposed to picking a title and the picture on the > > cover, before writing the content. > > We should probably discuss use cases and requirements. > > I believe use cases would be very helpful. Not the normal > alice talks to bob use cases. I want to see the salient > header features. > > My belief is that there are only really two interesting > use cases: > > 1) Mail is sent to alice@example.com, possibly forwarded > under the same name via relays controlled by the sender > or receiver's ISP. > > 2) Mail is send to email@alias.example.com and forwarded > under a different name, either through the action of a > mailing list or a mail forwarding arrangement. > > There are also uninteresting use cases like going through > open relays. > > > Case (2) is where all the corner cases come from. One way > to address this problem is by defining the actions of > forwarders that change names very carefully. > > > As much as some of us may be interested in your "war stories" about > > fighting the "gods" of the IETF, this is not proper forum for > > that type of discussion. > > If it is asserted that a party has a legitimate interest in the > direction of a spec it is legitimate to point out that they should > be ignored. > > > Phill > > From owner-ietf-mxcomp Fri Mar 12 17:55:01 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2D1t0uq080860; Fri, 12 Mar 2004 17:55: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 i2D1t0iY080859; Fri, 12 Mar 2004 17:55:00 -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 (srv1.pan-am.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2D1sx6K080849 for ; Fri, 12 Mar 2004 17:55:00 -0800 (PST) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: Real work items (Was: DNS etc.) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 12 Mar 2004 19:55:05 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA7C1@srv1.fecyk.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Real work items (Was: DNS etc.) Thread-Index: AcQIWDSeYetP5HFARDKVMgIYlbdUwQARCRQA 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 i2D1t06K080851 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > The client needs to go to DNS to get the MX records anyway. > So why not have it "get more" information > about the server itself. Because the senders whose mail we don't want won't bother. Contrary to a rule #3 about spammers, spammers aren't stupid. Also, from a purely bandwidth viewpoint, what difference does it make? I think roughly the same number of bits will pass in both directions regardless of which side is doing the querying. As for processor time, isn't there a rule suggesting that the network will always be slower than the CPU? -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Fri Mar 12 19:09:15 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2D39FbQ084519; Fri, 12 Mar 2004 19:09: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 i2D39FV1084518; Fri, 12 Mar 2004 19:09:15 -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 (srv1.pan-am.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2D39E0Q084512 for ; Fri, 12 Mar 2004 19:09:14 -0800 (PST) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: control of the DNS zone vs control of the email system MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 12 Mar 2004 21:09:20 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA7C3@srv1.fecyk.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: control of the DNS zone vs control of the email system Thread-Index: AcQH9MLO2mucRzifS+KPfZqj2oG8DwAsBhNg From: "Gordon Fecyk" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2D39F0Q084513 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > there's the mundane but nevertheless real issue that > > administrative control over a domain's email policies and > > administrative > > control over a domain's DNS entries may not be the same. > > > I really don't see this as a big deal. There *already* has to be > communication between whoever controls the DNS zone and whoever > controls the email system with respect to the MX records. This was my primary inspiration [2] for using DNS, notably forward DNS. The organization that controls a DNS domain [1] ultimately controls its e-mail policy based on mail exchange records. Otherwise you'd be writing gordonf@206.45.235.30 and not gordonf@pan-am.ca if you wanted to write me. I imagine all authors using records in forward DNS were similarly inspired. There are political issues with regard to who has this control, but DNS hosting is a very competitive market. Joe Sixpack can choose from any number of hosts who can cater to his needs if he isn't technically adept enough to host his own domain, and he will change DNS providers if his current provider pisses him off. Once we're done, Joe Sixpack can look forward to DNS providers that offer sender verification for his e-mail in varying flavours, such as supporting dynamic IP, providing mailbox and relay services for his domain, and so on. Others have told me how hosting is such a low-margin market and tech support is the most neglected aspect of the business. I feel sorry for DNS host customers, then. I've changed ISPs twice because of pathetic tech support and up here in Nowhere Manitoba, my choices are limited to The Phone Company and The Cable Company. On the bright side, tech support improved noticably over the past twelve months between these two. Someone must be listening. DNS hosts will learn to deal with what we come up with if their customers ask for it. DNS vendors likewise.[3] [1] Yes, there are security matters regarding who really has this control and they were addressed in a draft whose title I forget at the moment. I was under the impression most of these were implementation problems and not flaws in the protocol itself before then. Still, I don't think they're a detriment to anything we come up with here. DNS as a database has been under constant attack since at least 1997, yet it survives. [2] The secondary inspiration, for me anyway, was that DNS will be used to look up any sender database if it didn't use DNS as its main protocol anyway. To look up such a database by name on the Internet you need DNS. So, why bother with the middleman? [3] I really had this happen once. I asked Microsoft for wildcard support for all DNS record types instead of just MX records back before NT4 Service Pack 4. I must've been one of many people who asked because complete wildcard support appeared in Service Pack 4. Vendors do listen. They get paid to please the customer. -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Fri Mar 12 21:09:30 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2D59Ucs088672; Fri, 12 Mar 2004 21:09: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 i2D59UnP088671; Fri, 12 Mar 2004 21:09:30 -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 (srv1.pan-am.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2D59Tqf088665 for ; Fri, 12 Mar 2004 21:09:29 -0800 (PST) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: Potential Work Item: New DNS resource records MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 12 Mar 2004 23:09:35 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA7C4@srv1.fecyk.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Potential Work Item: New DNS resource records Thread-Index: AcQIULF9saSRvSloTsasNSE4LtEUmAAZ4Fuw 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 i2D59Tqf088666 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Before defining *how* the data is stored in DNS, we should work on > *what* that data is. I merely wanted to present this as a potential work item, including what the data is. Seems there's agreement that it should be a work item because folks are arguing[1] about what should be in there. [1] So is this what is meant by "Rough Consensus?" :-) -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Fri Mar 12 21:21:28 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2D5LSLD088958; Fri, 12 Mar 2004 21:21: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 i2D5LSsR088957; Fri, 12 Mar 2004 21:21:28 -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 (srv1.pan-am.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2D5LRDc088951 for ; Fri, 12 Mar 2004 21:21:28 -0800 (PST) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: Three major areas of concentration MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 12 Mar 2004 23:21:35 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA7C5@srv1.fecyk.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Three major areas of concentration Thread-Index: AcQGmo56E+wKgjl5R3uMzsLBLK+E6ACHw3KA 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 i2D5LSDc088952 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > | I think it is likely that there will need to be completely separate > | proposals for: > | > | 1) The "is this IP address authorized to be an MTA?" question. > | (e.g., MTA-Mark, SS, DUL lists, etc.) > | > | 2) The "is this IP address authorized to use a given domain name in > | the MAIL FROM (and HELO) address?" (e.g. RMX, SPF, DMP, etc.) > | > | 3) The "is this From: header from who it claims to be from?" (GPG, > | S/MIME, DomainKeys, Caller-ID, etc.) > > I agree that these are three related but distinct areas; each deserves > consideration. You gave consideration to 1) and 2) as they're directly related to the work. I wanted to know if the third area referred to deserves consideration from this group. Or if there are others. I don't remember if it was decided to consider 3) because of the problem of using bandwidth to receive the e-mail in the first place, in order to analyze it. I would prefer not to consider it as all of the approaches to verify the headers requires us to receive the message in its entirety, saving no bandwidth at all. -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Sat Mar 13 04:16:44 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2DCGiqO084570; Sat, 13 Mar 2004 04:16: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 i2DCGiKr084569; Sat, 13 Mar 2004 04:16:44 -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 (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2DCGhDn084563 for ; Sat, 13 Mar 2004 04:16:43 -0800 (PST) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.30) id 1B284J-0002gr-Om; Sat, 13 Mar 2004 06:16:43 -0600 To: "Gordon Fecyk" Cc: "IETF MXCOMP (E-mail)" Subject: Re: Three major areas of concentration References: <700EEF5641B7E247AC1C9B82C05D125DA7C5@srv1.fecyk.ca> From: wayne Content-Type: text/plain; charset=US-ASCII Date: Sat, 13 Mar 2004 06:16:43 -0600 In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125DA7C5@srv1.fecyk.ca> (Gordon Fecyk's message of "Fri, 12 Mar 2004 23:21:35 -0600") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (spfd: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <700EEF5641B7E247AC1C9B82C05D125DA7C5@srv1.fecyk.ca> "Gordon Fecyk" writes: >> | I think it is likely that there will need to be completely separate >> | proposals for: >> | >> | 1) The "is this IP address authorized to be an MTA?" question. >> | (e.g., MTA-Mark, SS, DUL lists, etc.) >> | >> | 2) The "is this IP address authorized to use a given domain name in >> | the MAIL FROM (and HELO) address?" (e.g. RMX, SPF, DMP, etc.) >> | >> | 3) The "is this From: header from who it claims to be from?" (GPG, >> | S/MIME, DomainKeys, Caller-ID, etc.) > > You gave consideration to 1) and 2) as they're directly related to the work. > I wanted to know if the third area referred to deserves consideration from > this group. Or if there are others. I definately think that 3) (checking the mail headers) deserves consideration. It is a much harder problem, but it is at least as important as the other two. Only 3) will really address phishing scams. I can not think of any other areas that deserve consideration. > I don't remember if it was decided to consider 3) because of the problem of > using bandwidth to receive the e-mail in the first place, in order to analyze > it. I would prefer not to consider it as all of the approaches to verify the > headers requires us to receive the message in its entirety, saving no > bandwidth at all. The choice of whether to do any of these validations should be left up to the individual mail admins. I see no particular reason why a mail admin couldn't use all of them, if they wanted to. Just because an email passes one of these test doesn't mean it will pass all of them. Personally, I use DUL lists for 1), SPF for 2) and I would use something for 3) if there was something available. -wayne From owner-ietf-mxcomp Sat Mar 13 06:58:28 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2DEwSYh092237; Sat, 13 Mar 2004 06:58: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 i2DEwSfP092236; Sat, 13 Mar 2004 06:58:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2DEwRHo092230 for ; Sat, 13 Mar 2004 06:58:27 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i2DEwT2S027201; Sat, 13 Mar 2004 06:58:29 -0800 (PST) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Sat, 13 Mar 2004 06:58:29 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Gordon Fecyk'" , "IETF MXCOMP (E-mail)" Subject: RE: Three major areas of concentration Date: Sat, 13 Mar 2004 06:58:28 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I think people are looking at the 'authority' issue from the wrong end. Who has the 'right' to tell me how I can use an IP address? If you look at the authorization question from the producer end of the equation you will end up running right into a whole pile of mess. Mere control of the reverse DNS for an IP address is not normally considered to entail the 'right' to dictate the uses to which the address can be put. continue on that line and you will find that you start redefining the business model of the entire Internet. You can try to do that but if you do you will not be finished in time to have any impact on the solution. This is not a producer problem, it is a receiver problem. That is where any control decision will be made. All that the sender is doing here is providing some additional information that helps the receiver determine that a message is legitimate. If you word the spec the way it is going at the moment you will find you have authorized things that you will really, really hate. For example if I am a backbone carrier and I see an attempt to connect to port 25 outbound from an address that is not 'permitted' to send email according to the spec I would be within my 'rights' to simply suppress this packet. > > | 1) The "is this IP address authorized to be an MTA?" question. > > | (e.g., MTA-Mark, SS, DUL lists, etc.) > > | > > | 2) The "is this IP address authorized to use a given > domain name in > > | the MAIL FROM (and HELO) address?" (e.g. RMX, SPF, DMP, etc.) > > | > > | 3) The "is this From: header from who it claims to be > from?" (GPG, > > | S/MIME, DomainKeys, Caller-ID, etc.) 1) What type of IP address is this? 2) Does the use of the source MTA IP address comply with the sender policy of the domain specified in the SMTP transport? 3) Does the use of the source MTA IP address comply with the sender policy of the domain specified in the message body? 4) As a receiver will I accept the message? We can even do away with the 'sender policy' confusion altogether if we instead think of the information in the forward DNS as a description of the mail configuration of the outgoing mail servers. Another advantage of the 'its just a description' point of view is that we separate concerns. The sender is not doing authorization, they are simply providing information to the recipient. The recipient uses that information together with a model of how email passes through the Internet to decide whether to accept the message. One of the strong implications of the work in this group is that the model of email transport in the internet is going to change. I do not expect forwarding relationships to be maintained in the same way as at present in a few years time. I think we will move to a proof of consent mechanism (spec on its way soon). If you follow the authorization model of thinking you end up with a procedural description of how to interpret the data. That will inevitably be out of date. I think that the dictatorial tone of the specs is the legacy of the blacklists. The problem there was that people started to order people what to do and that is how the problem tends to be thought of. We are helping people to help themselves here, not ordering them about. From owner-ietf-mxcomp Sat Mar 13 08:14:11 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2DGEBVe095321; Sat, 13 Mar 2004 08:14:11 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2DGEBpq095320; Sat, 13 Mar 2004 08:14:11 -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 (srv1.pan-am.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2DGEAIW095313 for ; Sat, 13 Mar 2004 08:14:10 -0800 (PST) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: Three major areas of concentration MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sat, 13 Mar 2004 10:14:12 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA7C6@srv1.fecyk.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Three major areas of concentration Thread-Index: AcQJC6Z1LZx0xGEGQD28JjClJQiMtQACAYJQ 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 i2DGEAIW095314 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > I think people are looking at the 'authority' issue from the > wrong end. I won't say it. It's too easy. > Who has the 'right' to tell me how I can use an IP address? 'rights' to send traffic are tempered with 'rights' to refuse or accept it at the other end. It is a whole other theological argument that was beaten to death a decade ago and I wouldn't want to see repeated here. I believe it's often referred to as: "Flogging the greasy spot on the pavement where the dead horse used to be". (Posted to SPAM-L by John Mozena, although he stated that he got it someplace else. :-) -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Sat Mar 13 09:24:39 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2DHOdkH098599; Sat, 13 Mar 2004 09:24: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 i2DHOdtc098598; Sat, 13 Mar 2004 09:24:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2DHOceX098591 for ; Sat, 13 Mar 2004 09:24:38 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i2DHOfPD016782; Sat, 13 Mar 2004 09:24:41 -0800 (PST) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Sat, 13 Mar 2004 09:24:41 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Gordon Fecyk'" , "IETF MXCOMP (E-mail)" Subject: RE: Three major areas of concentration Date: Sat, 13 Mar 2004 09:24:37 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > I think people are looking at the 'authority' issue from the > > wrong end. > > I won't say it. It's too easy. > > > Who has the 'right' to tell me how I can use an IP address? > > 'rights' to send traffic are tempered with 'rights' to refuse > or accept it at the other end. It is a whole other theological > argument that was beaten to > death a decade ago and I wouldn't want to see repeated here. Then you are in the wrong place. The argument that 'this was already decided elsewhere' has zero credibility. If you don't want to argue your case, fine, don't. Just accept the other point of view :-) This tactic is part of what is called 'agenda denial' in the propaganda litterature. Instead of answering legitimate issues you attack the question. It is terribly unpatriotic of you to attempt tactics of this kind, it only gives encouragement to the enemies of this country. The consistent point of view here is that we are not talking about an access control problem except at the receiver end. The asset we are trying to protect here is the end user's indox and the resources at the receiving end. > I believe it's often referred to as: "Flogging the greasy > spot on the pavement where the dead horse used to be". > (Posted to SPAM-L by John Mozena, although he stated > that he got it someplace else. :-) Unfortunately we are not talking about a spam problem any more. We are talking about a security specification. The discussions on spam mailing lists don't have a lot of bearing. They were not writing a standards specification. I have been doing this stuff since before SPAM-L existed. so don't try to pull rank here, you will lose that game. The reason that Hadmut's attempted definitions do not fit the traditional nomeclature of access control is that the point of view is 180 degrees arround from the point of view where they are written for. The confusion that is created in the group is going to be repeated each time someone tries to implement. Consider what you are going to tell people to configure: 1) Enter a description of the use of the IP address _ Allocated to a DHCP dynamic address pool _ Allocated to a dialup modem bank _ Allocated to a broadband modem connection _ Statically allocated to an external service 2) Enter the domain name that your mail server announces itself using in the HELO command: 3) Enter the IP address(s) of the mail server(s) used to send outgoing mail from xyz.com: Think in terms of the web page or wizard you would want to present to the system administrator. Do you want to use terms like 'permitted' or authorization here? do you want to have to explain them? do you want to have to explain them in a vocabulary that is out of skew with the terms used in the security world? If you do it my way a lot of the problems disappear. For example the whole confusion between CallerID style message header validation and SPF style envelope validation. This is no longer part of the NORMATIVE specification. Sure we give an INFORMATIONAL algorithm for interpretation but that does not have to be updated to track the changing configurations of the Internet. We should not be arguing over how the receiver uses this information, it is not relevant. A lot of that stuff is going to be proprietary. It is appropriate for a server at the edge to verify HELO and MAIL FROM. It is appropriate for an inner server or a client to verify the message origin indication. It also means that we can have two distinct descriptions here: forwarder.com "If the IP address is 10.2.3.2 forwarder.com can be held liable for the messages sent through it" "forwarder.com is accredited by the association of email freight forwarders" company.com "If the IP address is 10.5.3.2 and the message FROM is company.com the message is authentic and company.com can be held liable" "Accreditation of company.com" Until we have mail servers that are configured to verify their configuration before sending each piece of outgoing mail it is unlikely that anyone is going to reject outright email that fails SPF validation. instead they will attach a negative score and run the mail through the spam filters. Phill From owner-ietf-mxcomp Sat Mar 13 09:42:19 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2DHgIbI099441; Sat, 13 Mar 2004 09:42: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 i2DHgIjf099440; Sat, 13 Mar 2004 09:42:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2DHgIu6099434 for ; Sat, 13 Mar 2004 09:42:18 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.11/) with ESMTP id i2DHgGMu023248; Sat, 13 Mar 2004 09:42:18 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Sat, 13 Mar 2004 09:42:16 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Hadmut Danisch'" , Alan DeKok Cc: ietf-mxcomp@imc.org Subject: RE: Authentication and Authorization Date: Sat, 13 Mar 2004 09:42:15 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Only if the authorization informations and the rules are given > by the same entity. Here the authorization information is given > by the domain owner, the rules are given by the receiving MTA owner. How about we use the term 'Sender profile' for the information published in the DNS? This avoids all the unpleasant pre-commited uses of the term authorization. From owner-ietf-mxcomp Sat Mar 13 09:55:16 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2DHtG7Q099956; Sat, 13 Mar 2004 09:55:16 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2DHtFG2099955; Sat, 13 Mar 2004 09:55:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2DHtCLN099946 for ; Sat, 13 Mar 2004 09:55:15 -0800 (PST) (envelope-from hadmut@danisch.de) Received: from andromeda (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i2DHt6FH023274; Sat, 13 Mar 2004 18:55:06 +0100 Received: (from hadmut@localhost) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-3) id i2DHqSTx006714; Sat, 13 Mar 2004 18:52:28 +0100 From: Hadmut Danisch Date: Sat, 13 Mar 2004 18:52:28 +0100 To: "Hallam-Baker, Phillip" Cc: Alan DeKok , ietf-mxcomp@imc.org Subject: Re: Authentication and Authorization Message-ID: <20040313175228.GA6700@danisch.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1+cvs20040105i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, Mar 13, 2004 at 09:42:15AM -0800, Hallam-Baker, Phillip wrote: > > > How about we use the term 'Sender profile' for the information published > in the DNS? Naw, this is misleading. My 'sender profile' is that I write 80% german, 20% english, mostly in the evening, sometimes with typos. What about DDD Domain Delivery Descriptor ? regards Hadmut From owner-ietf-mxcomp Sat Mar 13 10:00:56 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2DI0u7O000350; Sat, 13 Mar 2004 10:00: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 i2DI0uSx000349; Sat, 13 Mar 2004 10:00:56 -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.8) with ESMTP id i2DI0qK3000339 for ; Sat, 13 Mar 2004 10:00:56 -0800 (PST) (envelope-from aland@newgiles.nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id D452816FDF for ; Sat, 13 Mar 2004 13:04:23 -0500 (EST) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Three major areas of concentration In-Reply-To: Your message of "Sat, 13 Mar 2004 09:24:37 PST." Date: Sat, 13 Mar 2004 13:04:23 -0500 Message-Id: <20040313180423.D452816FDF@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Hallam-Baker, Phillip" wrote: > It is terribly unpatriotic of you to attempt tactics of this kind, > it only gives encouragement to the enemies of this country. Like Gordon, I live in Canada. It's patriotic for the two of us to say all sorts of bad things about other countries. But that's off-topic... > We should not be arguing over how the receiver uses this information, > it is not relevant. I agree. If people published information about how they expected their network to be used, then recipients of traffic from their networks can still make whatever choices they make today. They'll just have more information. Alan DeKok. From owner-ietf-mxcomp Sat Mar 13 10:15:57 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2DIFuWr001213; Sat, 13 Mar 2004 10:15: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 i2DIFuQh001212; Sat, 13 Mar 2004 10:15:56 -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.8) with SMTP id i2DIFufY001205 for ; Sat, 13 Mar 2004 10:15:56 -0800 (PST) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v5.7.450.9b13) for ietf-mxcomp@imc.org; Sat, 13 Mar 2004 13:17:52 -0500 Received: from ([68.215.115.72]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v5.7.450.9b13) with SMTP id 3654442703; Sat, 13 Mar 2004 13:17:51 -0500 Message-ID: <009401c40927$51215510$6401a8c0@hdev1> From: "Hector Santos" To: "Hallam-Baker, Phillip" , "'Hadmut Danisch'" , "Alan DeKok" Cc: References: Subject: Re: Authentication and Authorization Date: Sat, 13 Mar 2004 13:16:26 -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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----- Original Message ----- From: "Hallam-Baker, Phillip" To: "'Hadmut Danisch'" ; "Alan DeKok" Cc: Sent: Saturday, March 13, 2004 12:42 PM Subject: RE: Authentication and Authorization > > > > Only if the authorization informations and the rules are given > > by the same entity. Here the authorization information is given > > by the domain owner, the rules are given by the receiving MTA owner. > > How about we use the term 'Sender profile' for the information published > in the DNS? > > This avoids all the unpleasant pre-commited uses of the term authorization. I personally prefer "policy," but no problem with profile. But as my high school english teacher preached "Being specific is terrific!" Why not use the following? [insert specific LMAP proposal] Sender Profile But in addition, you might wish to consider taking into account the possibilies for mixed profiles in transactions. [insert specific LMAP proposal] Sender|Domain Profile SPF domain profile SPF sender profile example: ip: 172.176.112.164 helo acb070a4.ipt.aol.com mail from: The SPF Domain Profile for sezman.cz is different from the SPF Sender Profile defined by aol.com. Respectively, one says softfail, the other says neutral. Who provails? -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp Sat Mar 13 10:18:03 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2DII3WY001280; Sat, 13 Mar 2004 10:18: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 i2DII3p9001279; Sat, 13 Mar 2004 10:18:03 -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 (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2DII21n001273 for ; Sat, 13 Mar 2004 10:18:03 -0800 (PST) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.30) id 1B2Di2-0005xv-Ay for ietf-mxcomp@imc.org; Sat, 13 Mar 2004 12:18:06 -0600 To: "IETF MXCOMP" Subject: Re: Three major areas of concentration References: From: wayne Content-Type: text/plain; charset=US-ASCII Date: Sat, 13 Mar 2004 12:18:05 -0600 In-Reply-To: (Phillip Hallam-Baker's message of "Sat, 13 Mar 2004 09:24:37 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (spfd: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In "Hallam-Baker, Phillip" writes: > The argument that 'this was already decided elsewhere' has zero > credibility. If you don't want to argue your case, fine, don't. > Just accept the other point of view :-) > > This tactic is part of what is called 'agenda denial' in the > propaganda litterature. Instead of answering legitimate issues > you attack the question. It is terribly unpatriotic of you to > attempt tactics of this kind, it only gives encouragement to > the enemies of this country. "credibility", "propoganda", "attack", "unpatriotic", "enemies", .... *sigh* Call me whatever you will, but I accept that there are a limited range of discussions that are on-topic for this forum. -wayne From owner-ietf-mxcomp Sat Mar 13 10:30:04 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2DIU4n1002700; Sat, 13 Mar 2004 10:30: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 i2DIU4Ud002699; Sat, 13 Mar 2004 10:30:04 -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.8) with SMTP id i2DITuGN002688 for ; Sat, 13 Mar 2004 10:29:57 -0800 (PST) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v5.7.450.9b13) for ietf-mxcomp@imc.org; Sat, 13 Mar 2004 13:32:01 -0500 Received: from ([68.215.115.72]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v5.7.450.9b13) with SMTP id 3655291593; Sat, 13 Mar 2004 13:32:00 -0500 Message-ID: <00d401c40929$4b24f980$6401a8c0@hdev1> From: "Hector Santos" To: "Hallam-Baker, Phillip" , "'Hadmut Danisch'" , "Alan DeKok" Cc: References: <009401c40927$51215510$6401a8c0@hdev1> Subject: Re: Authentication and Authorization Date: Sat, 13 Mar 2004 13:26:23 -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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----- Original Message ----- From: "Hector Santos" To: "Hallam-Baker, Phillip" ; "'Hadmut Danisch'" ; "Alan DeKok" Cc: Sent: Saturday, March 13, 2004 1:16 PM Subject: Re: Authentication and Authorization > example: > > ip: 172.176.112.164 > helo acb070a4.ipt.aol.com > mail from: > > The SPF Domain Profile for sezman.cz is different from the SPF Sender > Profile defined by aol.com. Respectively, one says softfail, the other says > neutral. Who provails? Correction: The SPF sender profile for the specific helo sub-domain is NONE, however, how one item about the specificationI have mixed feelings about. For the helo domain, should the parent domain be used for the query? In reality, aol.com is SPF ready which may result in a result other than none. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp Sat Mar 13 10:38:17 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2DIcHQS003089; Sat, 13 Mar 2004 10:38: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 i2DIcH0f003087; Sat, 13 Mar 2004 10:38:17 -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 (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2DIcFOH003065 for ; Sat, 13 Mar 2004 10:38:16 -0800 (PST) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.30) id 1B2E1a-0006Da-Nr for ietf-mxcomp@imc.org; Sat, 13 Mar 2004 12:38:18 -0600 To: "IETF MXCOMP" Subject: Re: Three major areas of concentration References: From: wayne Content-Type: text/plain; charset=US-ASCII Date: Sat, 13 Mar 2004 12:38:16 -0600 In-Reply-To: (Phillip Hallam-Baker's message of "Sat, 13 Mar 2004 09:24:37 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (spfd: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In "Hallam-Baker, Phillip" writes: > The asset we are trying to protect here is the end user's > indox and the resources at the receiving end. I think that the user's inbox is just *one* of the assets that I am interested in seeing protected. The domain owner and network owner's good name is another asset that I think needs to be protected. There are already a lot of techniques to help protect the inbox, but there are far few to protect people from misuse of domain names. > If you do it my way a lot of the problems disappear. For example the > whole confusion between CallerID style message header validation and > SPF style envelope validation. This is no longer part of the NORMATIVE > specification. Sure we give an INFORMATIONAL algorithm for interpretation > but that does not have to be updated to track the changing configurations > of the Internet. I don't see that the problems would just disappear. The envelope information and the header information are different in many ways. Information what is appropriate for one may well not be appropriate for the other. > We should not be arguing over how the receiver uses this information, > it is not relevant. It's the receiver's MTA, so it is the receiver's rules. It will always be up to the receiver to do with email as they think is best. > Until we have mail servers that are configured to verify their > configuration before sending each piece of outgoing mail it is unlikely > that anyone is going to reject outright email that fails SPF validation. > instead they will attach a negative score and run the mail through the > spam filters. There are already a growing number of mail servers that reject email outright if the SPF validation fails. I wish I knew how many MTAs were doing this, but it is much harder to track than the domains that publish SPF records. For example, I block email that fails SPF validation. Because it is new technology, I am watching it fairly closely. The results so far have been quite good. I haven't seen a false positive yet, and it is blocking about 1% of the spam I receive. Sure, that isn't a very high percentage, but SPF is still pretty new. -wayne From owner-ietf-mxcomp Sat Mar 13 14:41:08 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2DMf8NS013180; Sat, 13 Mar 2004 14: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 i2DMf8dS013179; Sat, 13 Mar 2004 14:41:08 -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 (srv1.pan-am.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2DMf7dV013172 for ; Sat, 13 Mar 2004 14:41:08 -0800 (PST) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: Three major areas of concentration MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sat, 13 Mar 2004 16:41:12 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA7C7@srv1.fecyk.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Three major areas of concentration Thread-Index: AcQJIBL72SlKWAU5TCyNjFo35dUxPQAKqDkA 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 i2DMf8dV013174 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > I have been doing this stuff since before SPAM-L existed. so > don't try to pull rank here, you will lose that game. "When I was your age I had to connect to the Internet using RFC 1149. Up wind, both ways." -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Sat Mar 13 15:30:05 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2DNU5Fw014393; Sat, 13 Mar 2004 15:30:05 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2DNU5xl014392; Sat, 13 Mar 2004 15:30:05 -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 (srv1.pan-am.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2DNU487014386 for ; Sat, 13 Mar 2004 15:30:04 -0800 (PST) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: Comedy vs Hysteria MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sat, 13 Mar 2004 17:30:09 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA7C8@srv1.fecyk.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comedy vs Hysteria Thread-Index: AcQJUzWB/AAYJj4ZT/Ky4hHU5kUYvw== 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 i2DNU587014387 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Subscribers might've noticed a slight, or some would say blatant, comedic stance I'm taking. The stuff you folks are posting to this list is just so absurd it's begging for a comedian's touch. I mean, you're all arguing over piddly details and the real work hasn't even started yet: "Authentication vs Authorization." These words have strict dictionary defenitions. You're not going to rewrite Miriam-Webster's just because your pet protocol / pet project / yearly salary depends on it. Big companies have tried. [1] "Potential Work Item." It was just that. I wasn't asking for a bunch of work, just opinions as to wether this should be a work item. Instead I got conspiracy theories about the DNS working group, and conspiracy theories about certain companies whose fiscal survival depends on the DNS. I at least got a feeling of "yes, it should be an item when we need it," even though it took 48 hours to determine that from reading the whole thread. No wonder people think we'd take too long. "Three major areas of concentration." OK, so I didn't help here. I thought Meng was asking for input and I gave it. Again I got conspiracy theories about certain entities whose fiscal survival depends on but one of the aforementioned areas. "[Back to Normal]" This was completely my fault and I regret starting this. Meng, sorry. OK? At least I can laugh at myself. I mean really, I wasn't much better early on either. You're going to see more laughing from me and more absurdities pointed out. While I might not have been around as long as most of my fellow geeks, I've been on the "front line" dealing with Joe Sixpack for the past ten years. And Joe Sixpack thinks you're all a riot, and he'd write you saying so if his Delete key wasn't broken from pressing it too many times. Oh, and he says: "Go to your local comedy club more often. Don't forget to tip your waitress - she's putting the salt on your glass for YOUR margarita."[2] But before you killfile me for being too absurd, ask yourself these questions: Who dismisses levity as irresponsibility? Who excludes comedy from the debate? Be careful how you answer. You might learn something. [1] window -- (computer science) a rectangular part of a computer screen that contains a display different from the rest of the screen. windows -- a concept in computer graphical user interfaces. See window (computing). [2] Oh, and you'll also see me borrowing from Rob Rosenberger a lot. -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Sat Mar 13 15:59:02 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2DNx2KF015326; Sat, 13 Mar 2004 15:59: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 i2DNx254015325; Sat, 13 Mar 2004 15:59:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2DNwtXY015316 for ; Sat, 13 Mar 2004 15:58:55 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.11/) with ESMTP id i2DNx0I7000459; Sat, 13 Mar 2004 15:59:01 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Sat, 13 Mar 2004 15:59:00 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Alan DeKok'" , ietf-mxcomp@imc.org Subject: RE: Three major areas of concentration Date: Sat, 13 Mar 2004 15:59:00 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > "Hallam-Baker, Phillip" wrote: > > It is terribly unpatriotic of you to attempt tactics of this kind, > > it only gives encouragement to the enemies of this country. > > Like Gordon, I live in Canada. It's patriotic for the two of us to > say all sorts of bad things about other countries. But that's > off-topic... It was an example of agenda denial. There is a whole litterature on it. 'This has already been decided' is a common gambit. From owner-ietf-mxcomp Sat Mar 13 16:15:21 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2E0FLMs015930; Sat, 13 Mar 2004 16:15:21 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2E0FLsM015929; Sat, 13 Mar 2004 16:15:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2E0FKA3015921 for ; Sat, 13 Mar 2004 16:15:21 -0800 (PST) (envelope-from hardie@qualcomm.com) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i2E0FMnp017400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Mar 2004 16:15:23 -0800 (PST) Received: from [205.214.163.13] (vpn-10-50-16-68.qualcomm.com [10.50.16.68]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i2E0FHlH001780; Sat, 13 Mar 2004 16:15:19 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: References: Date: Sat, 13 Mar 2004 16:15:16 -0800 To: "Hallam-Baker, Phillip" , "'Gordon Fecyk'" , "IETF MXCOMP (E-mail)" From: Ted Hardie Subject: RE: Three major areas of concentration Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 9:24 AM -0800 03/13/2004, Hallam-Baker, Phillip wrote: > >Then you are in the wrong place. > >The argument that 'this was already decided elsewhere' has zero >credibility. Pointers to previous work done an issue, as you have done with SAML, though, are appropriate ways to ensure that the group does not get bogged down in issues that have been carefully considered elsewhere. If Gordon's point is that others have considered a "rights" based view of this (rather than a contracts based view, for example), then asking him to provide more detail on the pointer is appropriate. Unless there is an engineering reason for making the distinction, though, I believe we are off topic. When raising a point in philosophical terms, I would appreciate mailing list participants making explicit *how it affects the engineering*. Doing so early on, in clear terms, and with constant reference to the engineering needs is very useful; leaving it out is not and can contribute to mailing list noise that hinders progress. > Instead of answering legitimate issues >you attack the question. It is terribly unpatriotic of you to >attempt tactics of this kind, it only gives encouragement to >the enemies of this country. The IETF is an international organization, and statements like that above are not appropriate in this venue. We are trying to develop an engineering specification here, and it is discussion of the engineering issues, rather than philosophy or motivations, will help move us forward. regards, Ted Hardie From owner-ietf-mxcomp Sat Mar 13 17:44:14 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2E1iEvo019203; Sat, 13 Mar 2004 17:44: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 i2E1iET2019202; Sat, 13 Mar 2004 17:44:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.41]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2E1iCJr019195 for ; Sat, 13 Mar 2004 17:44:13 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.50] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1B2Kfn-0000Ru-00; Sat, 13 Mar 2004 20:44:15 -0500 Received: from [68.244.217.18] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1B2Kfm-0001SJ-00; Sat, 13 Mar 2004 20:44:15 -0500 Message-ID: <4053B8E3.1080003@solidmatrix.com> Date: Sat, 13 Mar 2004 20:44:03 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Gordon Fecyk CC: "IETF MXCOMP (E-mail)" Subject: Re: Potential Work Item: New DNS resource records References: <700EEF5641B7E247AC1C9B82C05D125DA7C4@srv1.fecyk.ca> In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125DA7C4@srv1.fecyk.ca> X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Gordon Fecyk wrote: >>Before defining *how* the data is stored in DNS, we should work on >>*what* that data is. > > > I merely wanted to present this as a potential work item, including what the > data is. Seems there's agreement that it should be a work item because folks > are arguing[1] about what should be in there. > > [1] So is this what is meant by "Rough Consensus?" :-) > I think that there is a rough consensus about the need for this work item. However, IMHO there is a need to put this work item towards the bottom of the list, in order to concentrate on the other issues first. Yakov From owner-ietf-mxcomp Sun Mar 14 02:03:13 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2EA3DBC013278; Sun, 14 Mar 2004 02:03: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 i2EA3DNv013277; Sun, 14 Mar 2004 02:03:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from argon.connect.org.uk (argon.connectinternetsolutions.com [193.110.243.33]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2EA3BTq013270 for ; Sun, 14 Mar 2004 02:03:12 -0800 (PST) (envelope-from jrk@merseymail.com) Received: from mmail by argon.connect.org.uk with local (connectmail/exim) id 1B2SSb-0001Xp-Fv; Sun, 14 Mar 2004 10:03:09 +0000 In-Reply-To: Subject: Re: RE: Three major areas of concentration To: "Hallam-Baker, Phillip" From: "Jon Kyme" Cc: ietf-mxcomp@imc.org X-Mailer: [ConnectMail 3.13.0] X-connectmail-Originating-IP: 82.69.7.27 Message-Id: Date: Sun, 14 Mar 2004 10:03:09 +0000 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > Until we have mail servers that are configured to verify their > configuration before sending each piece of outgoing mail [...] Phillip, I'm honestly not being argumentative here. But what exactly do you mean by this? I think I don't understand. Rgds, JK From owner-ietf-mxcomp Sun Mar 14 02:15:09 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2EAF9us013988; Sun, 14 Mar 2004 02:15:09 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2EAF9Gs013987; Sun, 14 Mar 2004 02:15:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2EAF8jC013981 for ; Sun, 14 Mar 2004 02:15:08 -0800 (PST) (envelope-from hadmut@danisch.de) Received: from andromeda (uucp@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with BSMTP id i2EAF6hW010233; Sun, 14 Mar 2004 11:15:06 +0100 Received: (from hadmut@localhost) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-3) id i2EADeAD013038; Sun, 14 Mar 2004 11:13:40 +0100 From: Hadmut Danisch Date: Sun, 14 Mar 2004 11:13:40 +0100 To: Gordon Fecyk Cc: "IETF MXCOMP (E-mail)" Subject: Re: Comedy vs Hysteria Message-ID: <20040314101340.GA13024@danisch.de> References: <700EEF5641B7E247AC1C9B82C05D125DA7C8@srv1.fecyk.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125DA7C8@srv1.fecyk.ca> User-Agent: Mutt/1.5.5.1+cvs20040105i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: :-) From owner-ietf-mxcomp Sun Mar 14 07:06:40 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2EF6enP028569; Sun, 14 Mar 2004 07:06: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 i2EF6e02028568; Sun, 14 Mar 2004 07:06:40 -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 (srv1.pan-am.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2EF6c2S028560 for ; Sun, 14 Mar 2004 07:06:39 -0800 (PST) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: This looks familiar... MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 14 Mar 2004 09:06:32 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA7C9@srv1.fecyk.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: This looks familiar... Thread-Index: AcQJ1gXZQI4oOvxMQ+qzeRqs0CBbsg== 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 i2EF6d2S028563 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Copied from a Slashdot forum about the DARPA robot challenge... On Winning (Score:3, Interesting) by macmurph (622189) on Saturday March 13, @09:11PM (#8558874) You have to engineer the process of winning, not just the technology to win. I worked on a solar powered race car that was to cross the country. Our superior car won the first few days, but eventually crashed. I learned a lot more about _team work and egos_ [emphasis mine] than I did about technology. The technology was there, the money was there, the open-minded cooperation was not there. The car was engineered very well, the win was not engineered at all. Re:On Winning (Score:3, Insightful) by mabu (178417) on Saturday March 13, @11:17PM (#8559514) You've hit upon a very big issue. People don't work well together the way they used to. The open source movement is not an exception. These people all work virtually and at their own schedule and desire. It's very difficult to find committed people who can see the "big picture" without having to finance their loyalty. A good analogy can be found in the music industry. What makes a great band often has more to do with X number of guys being open-minded and ambitious AND able to work well together. They may make a lot of mistakes and suck early on, but if they hang in there, they will prevail (look at Bon Jovi - talent is obviously not a prerequisite - tolerance is). [end] -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Sun Mar 14 14:14:19 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2EMEJQR048715; Sun, 14 Mar 2004 14:14: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 i2EMEJbW048714; Sun, 14 Mar 2004 14:14:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2EMEIMG048698 for ; Sun, 14 Mar 2004 14:14:18 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.11/) with ESMTP id i2EMENMS029101; Sun, 14 Mar 2004 14:14:23 -0800 (PST) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Sun, 14 Mar 2004 14:14:23 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Jon Kyme'" , "Hallam-Baker, Phillip" Cc: ietf-mxcomp@imc.org Subject: RE: RE: Three major areas of concentration Date: Sun, 14 Mar 2004 14:14:21 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > Until we have mail servers that are configured to verify their > > configuration before sending each piece of outgoing mail [...] > > Phillip, I'm honestly not being argumentative here. But what > exactly do you > mean by this? I think I don't understand. I would expect that at some point mail servers that are trying to send email from example.com that know they are external facing would do a check of the DNS config to see that they are actually configured to do this. Otherwise alert operator to fact that there is a misconfiguration. From owner-ietf-mxcomp Sun Mar 14 14:20:58 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2EMKwKv049282; Sun, 14 Mar 2004 14:20: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 i2EMKw6G049281; Sun, 14 Mar 2004 14:20:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2EMKwJK049275 for ; Sun, 14 Mar 2004 14:20:58 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.11/) with ESMTP id i2EML3ao000671; Sun, 14 Mar 2004 14:21:03 -0800 (PST) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Sun, 14 Mar 2004 14:21:03 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Ted Hardie'" , "Hallam-Baker, Phillip" , "'Gordon Fecyk'" , "IETF MXCOMP (E-mail)" Subject: RE: Three major areas of concentration Date: Sun, 14 Mar 2004 14:21:02 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Unless there is an engineering reason for making the distinction, > though, I believe we are off topic. There is a critical engineering point here. Is the specification going to be dependent on a particular model of email transport accross the Internet? Is the specification going to be defined in declarative or procedural terms? > > Instead of answering legitimate issues > >you attack the question. It is terribly unpatriotic of you to > >attempt tactics of this kind, it only gives encouragement to > >the enemies of this country. > > The IETF is an international organization, and statements like > that above are not appropriate in this venue. Ted, you removed the context. The tactic being used was agenda denial. I was giving another common example of the same tactic. I thought the example sufficiently absurd that the chance of someone thinking anyone would make an agument of that type seriously was remote. I appologise if this led to confusion. From owner-ietf-mxcomp Sun Mar 14 19:04:10 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2F349qt063478; Sun, 14 Mar 2004 19:04:09 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2F349X4063477; Sun, 14 Mar 2004 19:04:09 -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 (srv1.pan-am.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2F3482F063471 for ; Sun, 14 Mar 2004 19:04:09 -0800 (PST) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: Three major areas of concentration MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 14 Mar 2004 21:04:15 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA7CC@srv1.fecyk.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Three major areas of concentration Thread-Index: AcQKEqPB5FGQPUKyR42YIygByT3E/AAIPk1A 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 i2F3492F063472 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > If Gordon's point is that > > others have considered a "rights" based view of this > > (rather than a contracts based view, for example), then > > asking him to provide more detail on the pointer is > > appropriate. For the record I haven't been asked to provide that detail. I will if asked, but I'll take it out of the list. > There is a critical engineering point here. Is the specification going > to be dependent on a particular model of email transport accross the > Internet? I think Patrik drew up that model at the beginning of the BOF. The "ugly" part of that model looks like the toughest to deal with but I thought the others looked simple enough. What slide was that and is there publicly accessible URL for it? -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Sun Mar 14 19:19:47 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2F3JlR9064283; Sun, 14 Mar 2004 19:19: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 i2F3Jl4o064282; Sun, 14 Mar 2004 19:19:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.41]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2F3Jktb064276 for ; Sun, 14 Mar 2004 19:19:46 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.50] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1B2idq-0000ES-00; Sun, 14 Mar 2004 22:19:50 -0500 Received: from [68.244.251.144] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1B2idp-0005CE-00; Sun, 14 Mar 2004 22:19:50 -0500 Message-ID: <405520C5.908@solidmatrix.com> Date: Sun, 14 Mar 2004 22:19:33 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Gordon Fecyk CC: "IETF MXCOMP (E-mail)" Subject: Re: Three major areas of concentration References: <700EEF5641B7E247AC1C9B82C05D125DA7CC@srv1.fecyk.ca> In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125DA7CC@srv1.fecyk.ca> X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Gordon Fecyk wrote: >>There is a critical engineering point here. Is the specification going >>to be dependent on a particular model of email transport accross the >>Internet? > > > I think Patrik drew up that model at the beginning of the BOF. The "ugly" > part of that model looks like the toughest to deal with but I thought the > others looked simple enough. > > What slide was that and is there publicly accessible URL for it? > http://www.imc.org/ietf-mxcomp/index.html From owner-ietf-mxcomp Mon Mar 15 01:10:20 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2F9AK66036648; Mon, 15 Mar 2004 01:10: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 i2F9AKGm036647; Mon, 15 Mar 2004 01:10:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from argon.connect.org.uk (argon.connectinternetsolutions.com [193.110.243.33]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2F9AJoS036628 for ; Mon, 15 Mar 2004 01:10:20 -0800 (PST) (envelope-from jrk@merseymail.com) Received: from mmail by argon.connect.org.uk with local (connectmail/exim) id 1B2o71-0003nv-3T; Mon, 15 Mar 2004 09:10:19 +0000 Subject: Re: RE: RE: Three major areas of concentration To: "Hallam-Baker, Phillip" From: "Jon Kyme" Cc: X-Mailer: [ConnectMail 3.13.0] X-connectmail-Originating-IP: 172.25.243.3 Message-Id: Date: Mon, 15 Mar 2004 09:10:19 +0000 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > would do a check of the DNS config to see that they are actually > configured to do this. Otherwise alert operator to fact that there Thanks. I get you. My tiny brain working now. You may be assuming better reading comprehension than some of us can actually manage - e.g. discussion of "agenda denial" and patriotism :-) From owner-ietf-mxcomp Mon Mar 15 05:39:53 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2FDdrJm069702; Mon, 15 Mar 2004 05:39: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 i2FDdrqU069701; Mon, 15 Mar 2004 05:39:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [208.210.125.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2FDdqHe069695 for ; Mon, 15 Mar 2004 05:39:53 -0800 (PST) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [208.210.125.24]) by emerald.pobox.com (Postfix) with ESMTP id BD5E0132CFF for ; Mon, 15 Mar 2004 08:39:53 -0500 (EST) Received: by dumbo.pobox.com (Postfix, from userid 505) id 9697F5CB; Mon, 15 Mar 2004 08:39:43 -0500 (EST) Date: Mon, 15 Mar 2004 08:39:43 -0500 From: Meng Weng Wong To: "IETF MXCOMP (E-mail)" Subject: mail flows diagram Message-ID: <20040315133943.GG8016@dumbo.pobox.com> References: <700EEF5641B7E247AC1C9B82C05D125DA7CC@srv1.fecyk.ca> <405520C5.908@solidmatrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <405520C5.908@solidmatrix.com> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, Mar 14, 2004 at 10:19:33PM -0500, Yakov Shafranovich wrote: | >I think Patrik drew up that model at the beginning of the BOF. The "ugly" | >part of that model looks like the toughest to deal with but I thought the | >others looked simple enough. | > | >What slide was that and is there publicly accessible URL for it? | > | | http://www.imc.org/ietf-mxcomp/index.html A direct version (in different formats) is at http://spf.pobox.com/mailflows.html http://spf.pobox.com/mailflows-l.png http://spf.pobox.com/mailflows.png From owner-ietf-mxcomp Mon Mar 15 08:52:37 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2FGqauJ080447; Mon, 15 Mar 2004 08:52:36 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2FGqat3080446; Mon, 15 Mar 2004 08:52:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2FGqPQZ080426 for ; Mon, 15 Mar 2004 08:52:30 -0800 (PST) (envelope-from aland@newgiles.nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id DF6EB16D00 for ; Mon, 15 Mar 2004 11:55:59 -0500 (EST) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Three major areas of concentration In-Reply-To: Your message of "Sat, 13 Mar 2004 06:58:28 PST." Date: Mon, 15 Mar 2004 11:55:59 -0500 Message-Id: <20040315165559.DF6EB16D00@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Hallam-Baker, Phillip" wrote: > Mere control of the reverse DNS for an IP address is not normally considered > to entail the 'right' to dictate the uses to which the address can be put. No... but also historically, there has been a strong correlation between the people "owning" the IP, and the people administering rDNS for that IP. When they are the same people, it's logical to publish expected use information in rDNS. There's no concept of "dictation", then, as people can't dictate terms to themselves. > We can even do away with the 'sender policy' confusion altogether > if we instead think of the information in the forward DNS as a > description of the mail configuration of the outgoing mail > servers. That's probably a better description of the data. > Another advantage of the 'its just a description' point of view is > that we separate concerns. The sender is not doing authorization, > they are simply providing information to the recipient. In my view, "authorization" means an active role in the process. "Policy" is a static description of how the active authorization should proceed. So the sender publishes authorization policy in DNS, and the recipient applies that policy to perform the authorization action. Alan DeKok. From owner-ietf-mxcomp Mon Mar 15 08:58:35 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2FGwZjZ080731; Mon, 15 Mar 2004 08:58: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 i2FGwZnh080730; Mon, 15 Mar 2004 08:58:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2FGwYPr080724 for ; Mon, 15 Mar 2004 08:58:34 -0800 (PST) (envelope-from hardie@qualcomm.com) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i2FGwZvf003011; Mon, 15 Mar 2004 08:58:36 -0800 (PST) Received: from [205.214.163.85] (vpn-10-50-16-34.qualcomm.com [10.50.16.34]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i2FGwVlH029679; Mon, 15 Mar 2004 08:58:32 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: References: Date: Mon, 15 Mar 2004 08:58:33 -0800 To: "Hallam-Baker, Phillip" , "'Gordon Fecyk'" , "IETF MXCOMP (E-mail)" From: Ted Hardie Subject: RE: Three major areas of concentration Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 2:21 PM -0800 03/14/2004, Hallam-Baker, Phillip wrote: > I was giving another common example of the same tactic. >I thought the example sufficiently absurd that the chance of >someone thinking anyone would make an agument of that type seriously >was remote. I appologise if this led to confusion. This did not come through to me as an example, and so I was confused on your intention. Thanks for the clarification. regards, Ted Hardie From owner-ietf-mxcomp Mon Mar 15 09:37:49 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2FHbn9Z082760; Mon, 15 Mar 2004 09:37: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 i2FHbnrA082759; Mon, 15 Mar 2004 09:37:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2FHbmYU082753 for ; Mon, 15 Mar 2004 09:37:48 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i2FHbplD018290; Mon, 15 Mar 2004 09:37:51 -0800 (PST) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 15 Mar 2004 09:37:51 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Jon Kyme'" , "Hallam-Baker, Phillip" Cc: ietf-mxcomp@imc.org Subject: RE: RE: RE: Three major areas of concentration Date: Mon, 15 Mar 2004 09:37:49 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > would do a check of the DNS config to see that they are actually > > configured to do this. Otherwise alert operator to fact that there > > Thanks. I get you. My tiny brain working now. You may be > assuming better > reading comprehension than some of us can actually manage > - e.g. discussion of "agenda denial" and patriotism :-) I think that is a side effect of the fact that the AI and political science courses at MIT began as outsourced research labs for the CIA. There was a time when AI and the CIA shared the same floor. Danny Hillis had a sign with two arrows that read 'Intelligence' and 'Artificial Intelligence'. Phill From owner-ietf-mxcomp Mon Mar 15 15:13:27 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2FNDROp003695; Mon, 15 Mar 2004 15:13:27 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2FNDRqk003694; Mon, 15 Mar 2004 15:13:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2FNDQFI003688 for ; Mon, 15 Mar 2004 15:13:26 -0800 (PST) (envelope-from hardie@qualcomm.com) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i2FNDUnp026002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Mar 2004 15:13:30 -0800 (PST) Received: from [205.214.163.2] (vpn-10-50-0-47.qualcomm.com [10.50.0.47]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i2FNDNVK029385 for ; Mon, 15 Mar 2004 15:13:25 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: Date: Mon, 15 Mar 2004 15:13:26 -0800 To: ietf-mxcomp@imc.org From: Ted Hardie Subject: DRAFT charter Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Below is a DRAFT charter; I believe it reflects the consensus of the meeting, has a reasonable description of the aim of the group, and reflects a strong project management focus, designed to help us meet the timeline we need to make this work relevant. The two proposed Chairs, Marshall Rose and Andy Newton, are both experienced and I believe they will work well together.. This draft is on the IESG agenda for this week, for internal review; comments to the list, Chairs, me, or IESG are all appropriate. I hope, however, that we can focus on the big picture here, as spending too much time on the charter will seriously hurt our ability to get this work done. regards, Ted Hardie MTA Authorization Records in DNS (MARID) Chairs: Marshall Rose Andrew Newton Applications Area Directors: Ted Hardie Scott Hollenbeck Applications Area Advisor: Ted Hardie Mailing Lists: General Discussion: ietf-mxcomp@imc.org To Subscribe: ietf-mxcomp-request@imc.org In Body: Subscribe Archive: http://www.imc.org/ietf-mxcomp/index.html Description of Working Group: It would useful for Mail Transfer Agents (MTAs) to be able to confirm that peer MTAs are authorized to send mail on behalf of a specific domain or network. This working group will develop a DNS-based mechanism for storing and distributing information associated with that authorization. While the primary current use case for this facility is to combat a certain class of domain forgery in spam, the solution chosen should be generally usable for MTA authorization. This working group is being chartered after extensive discussion of the issues in the IRTF's Anti-spam Research Group, and it is presumed that all active participants will be familiar with the documents produced there which describe the problem. This working group is not, however, an extension of that research group; it has no general writ to study spam or to produce specifications on the topic. It will not consider anti-spam abatement measures outside of the area of MTA authorization. An individual message may be associated with multiple identities (specifically the domains present in the RFC2822 From, RFC2822 Sender, the SMTP Mail-From, and the SMTP EHLO), the first task of the working group will be to establish which of these identities should be associated with MTA authorization. Once this decision has been reached, it will limit the scope of further activity in this working group, and the chairs will rule out of order discussion related to schemes which use other identities as the basis of authorization. Upon chartering of this working group, the IESG intends to request that the IRTF Chair and the Chairs of the IRTF's Anti-Spam Research Group seek publication of the listed input documents as experimental RFCs, so that they are available on an archival basis; the IESG also intends to request that the RFC editor insert a note into each document informing the reader that the IETF's MARID working group has taken on the task of producing a standard in this area. Working Group Goals and Milestones: March 04 Discuss identities with which MTA authorization should be associated April 04 Publish one or more proposals, as I-Ds, specifying the required semantics used for MTA authorization. April 04 Working Group last call on which identities will be used for MTA authorization May 04 Interim Meeting to determine which semantics proposal to use. May 04 Publish one or more syntax proposals, as I-Ds, to meet required semantics June 04 Final selection of syntax and document review of selected proposal July 04 Working group last call Aug 04 Submit working group document on MTA Authorization Record in DNS to PS. Aug 04 Enter FIN_WAIT Input documents: draft-irtf-asrg-lmap-discussion draft-stumpf-dns-mtamark draft-brand-drip draft-danisch-dns-rr-smtp draft-fecyk-dmp draft-mengwong-spf draft-levine-fsv From owner-ietf-mxcomp Mon Mar 15 15:45:18 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2FNjH1I005344; Mon, 15 Mar 2004 15:45: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 i2FNjH7P005343; Mon, 15 Mar 2004 15:45:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.40]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2FNjGoM005337 for ; Mon, 15 Mar 2004 15:45:17 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.52] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1B31lk-0006WI-00; Mon, 15 Mar 2004 18:45:16 -0500 Received: from [68.24.236.98] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1B31lj-0000Oz-00; Mon, 15 Mar 2004 18:45:16 -0500 Message-ID: <40563FF8.3050004@solidmatrix.com> Date: Mon, 15 Mar 2004 18:44:56 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Ted Hardie CC: ietf-mxcomp@imc.org Subject: Re: DRAFT charter References: In-Reply-To: X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ted Hardie wrote: > Upon chartering of this working group, the IESG intends to request > that the IRTF Chair and the Chairs of the IRTF's Anti-Spam Research Group > seek publication of the listed input documents as experimental RFCs, > so that they are available on an archival basis; the IESG also > intends to request that the RFC editor insert a note into each document > informing the reader that the IETF's MARID working group > has taken on the task of producing a standard in this area. > I assume that the discussion document will be published an informational RFC with the others being experimental. Yakov From owner-ietf-mxcomp Mon Mar 15 18:04:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2G24X8h013678; Mon, 15 Mar 2004 18:04: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 i2G24Xei013677; Mon, 15 Mar 2004 18:04:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2G24WJT013671 for ; Mon, 15 Mar 2004 18:04:32 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.11/) with ESMTP id i2G24cfn008470; Mon, 15 Mar 2004 18:04:38 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 15 Mar 2004 18:04:38 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Ted Hardie'" , ietf-mxcomp@imc.org Subject: RE: DRAFT charter Date: Mon, 15 Mar 2004 18:04:36 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This makes sense to me. It should be emphasized that the decision to exclude other technologies in this particular group does not in any way prevent them from being raised and persued independly in other groups. What could foreclose these groups though would be a scheme that was strictly limited to information to support MTA authentication by IP address with no provision made to allow any other form of information to ever be included. I am a little concerned that we have the 'authorization' language in the draft. There is a concrete distinction here as to scope. The 'describe the configuration of a mail server' point of view would cover information such as the IP address of the mail server and could also extend to other information that would help the email sender persuade the recipient that a message is not spam, in particular accreditation information such as the accreditation information that a Bonded Sender might provide. Clearly we do not want to define the protocol by which such accreditations would be verified in this group. But they are a core component of the accountable sender scheme that was developed at the Aspen institute roundtable and of the Microsoft CSRI proposal. It has also been discussed at length in the SPF group. It should be possible to inform the recipient that an accreditation exists. I can explain later why this is sufficient. I would respectfully suggest that this be allowed into the scope. Phill > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Ted Hardie > Sent: Monday, March 15, 2004 6:13 PM > To: ietf-mxcomp@imc.org > Subject: DRAFT charter > > > > Below is a DRAFT charter; I believe it reflects the consensus > of the meeting, > has a reasonable description of the aim of the group, and reflects a > strong project > management focus, designed to help us meet the timeline we need to > make this work relevant. The two proposed Chairs, Marshall Rose and > Andy Newton, are both experienced and I believe they will work well > together.. > > This draft is on the IESG agenda for this week, for internal > review; comments > to the list, Chairs, me, or IESG are all appropriate. I > hope, however, that we > can focus on the big picture here, as spending too much time on the > charter will > seriously hurt our ability to get this work done. > > regards, > Ted Hardie > > > MTA Authorization Records in DNS (MARID) > > Chairs: > > Marshall Rose > Andrew Newton > > Applications Area Directors: > > Ted Hardie > Scott Hollenbeck > > Applications Area Advisor: > > Ted Hardie > > Mailing Lists: > > General Discussion: ietf-mxcomp@imc.org > To Subscribe: ietf-mxcomp-request@imc.org > In Body: Subscribe > Archive: http://www.imc.org/ietf-mxcomp/index.html > > Description of Working Group: > > It would useful for Mail Transfer Agents (MTAs) to be able to > confirm that peer MTAs are authorized to send mail on behalf of a > specific domain or network. This working group will develop > a DNS-based > mechanism for storing and distributing information associated > with that > authorization. While the primary current use case for this > facility is to > combat a certain class of domain forgery in spam, the solution chosen > should be generally usable for MTA authorization. > > This working group is being chartered after extensive discussion of > the issues in the IRTF's Anti-spam Research Group, and it is presumed > that all active participants will be familiar with the > documents produced > there which describe the problem. This working group is not, > however, an > extension of that research group; it has no general writ to > study spam or to > produce specifications on the topic. It will not consider > anti-spam abatement > measures outside of the area of MTA authorization. > > An individual message may be associated with multiple identities > (specifically the domains present in the RFC2822 From, RFC2822 Sender, > the SMTP Mail-From, and the SMTP EHLO), the first task of the > working group > will be to establish which of these identities should be > associated with MTA authorization. Once this decision has been > reached, it will limit the scope of further activity in this > working group, > and the chairs will rule out of order discussion related to > schemes which > use other identities as the basis of authorization. > > Upon chartering of this working group, the IESG intends to request > that the IRTF Chair and the Chairs of the IRTF's Anti-Spam > Research Group > seek publication of the listed input documents as experimental RFCs, > so that they are available on an archival basis; the IESG also > intends to request that the RFC editor insert a note into > each document > informing the reader that the IETF's MARID working group > has taken on the task of producing a standard in this area. > > > Working Group Goals and Milestones: > > March 04 Discuss identities with which MTA authorization > should be associated > > April 04 Publish one or more proposals, as I-Ds, > specifying the > required semantics used for MTA authorization. > > April 04 Working Group last call on which identities will be > used for MTA authorization > > May 04 Interim Meeting to determine which semantics proposal > to use. > > May 04 Publish one or more syntax proposals, > as I-Ds, to meet > required semantics > > June 04 Final selection of syntax and document review of > selected proposal > > July 04 Working group last call > > Aug 04 Submit working group document on MTA > Authorization > Record in DNS to PS. > > Aug 04 Enter FIN_WAIT > > > Input documents: > > draft-irtf-asrg-lmap-discussion > draft-stumpf-dns-mtamark > draft-brand-drip > draft-danisch-dns-rr-smtp > draft-fecyk-dmp > draft-mengwong-spf > draft-levine-fsv > From owner-ietf-mxcomp Mon Mar 15 18:17:12 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2G2HCKx014230; Mon, 15 Mar 2004 18:17:12 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2G2HCLQ014229; Mon, 15 Mar 2004 18:17:12 -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 (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2G2HB5H014222 for ; Mon, 15 Mar 2004 18:17:11 -0800 (PST) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.30) id 1B348r-0007Gw-8j for ietf-mxcomp@imc.org; Mon, 15 Mar 2004 20:17:17 -0600 To: "IETF MXCOMP" Subject: Re: Economics & deployment References: <20040311194323.6BBDE170F3@mail.nitros9.org> From: wayne Content-Type: text/plain; charset=US-ASCII Date: Mon, 15 Mar 2004 20:17:17 -0600 In-Reply-To: <20040311194323.6BBDE170F3@mail.nitros9.org> (Alan DeKok's message of "Thu, 11 Mar 2004 14:43:22 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (spfd: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <20040311194323.6BBDE170F3@mail.nitros9.org> "Alan DeKok" writes: > So far as incentive goes, I just got my hands on an interesting set > of data. It's stats for about a week of email traffic, from a system > monitoring a large proportion of the SMTP traffic on the net. > > The quick conclusions are: > > [discussion of IP addresses snipped] Alan: Would you be able to provide some information on the domain names used in this email traffic sample? It appears likely that both IP and domain name info will be considered by this WG and it would be nice to have data on both. -wayne From owner-ietf-mxcomp Mon Mar 15 18:34:19 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2G2YJOk014743; Mon, 15 Mar 2004 18:34: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 i2G2YJ9W014742; Mon, 15 Mar 2004 18:34:19 -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.8) with SMTP id i2G2YINE014735 for ; Mon, 15 Mar 2004 18:34:18 -0800 (PST) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v5.7.450.9b13) for ietf-mxcomp@imc.org; Mon, 15 Mar 2004 21:36:24 -0500 Received: from ([68.211.139.123]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v5.7.450.9b13) with SMTP id 3857154796; Mon, 15 Mar 2004 21:36:23 -0500 Message-ID: <002501c40aff$5242bc20$6401a8c0@hdev1> From: "Hector Santos" To: "Hallam-Baker, Phillip" , "'Ted Hardie'" , References: Subject: Re: DRAFT charter Date: Mon, 15 Mar 2004 21:35:00 -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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----- Original Message ----- From: "Hallam-Baker, Phillip" To: "'Ted Hardie'" ; Sent: Monday, March 15, 2004 9:04 PM Subject: RE: DRAFT charter > This makes sense to me. > Yes. Same here, with the same concern you have: > I am a little concerned that we have the 'authorization' language in the > draft. There is a concrete distinction here as to scope. For example, this is what I have to deal with from a production standpoint. At the layman level (my customers), the distinction will need to be very clear with the SMTP authentication options already provided: Allow Relay/Routing Options: [X] IP relay tables [X] ESMTP Auth [_] Required for all connections (Intranets Only) [X] POP3 before SMTP Of hand, I don't think I want to get into addition a forth option: [X] LMAP based authentication atleast not using the current specification that lacks LMAP/DNS record sender profile spoof protection and has the high protection to hide reputation (LMAP compliant spammers). However, if it does become a general MTA authorization method, I might have to change it to something like this but I will most definitely add a sub-option to LMAP to keep it with backward SMTP compatibility (or BCP) of allowing only final destination mail for anonymous access. Sender Authentication Methods [X] IP relay tables [X] ESMTP Auth [_] Required for all connections (Intranets Only) [X] POP3 before SMTP [X] LMAP based authentication [_] Allow Relay/Routing Also, in the issue of "reputation" we have an option: [X] Use RBL for IP rejection [X] Ignore RBL rejections if authenticated Anyway, I didn't want to get into details like this and I certainly hope I am not out of line with the IETF process, but that is what I have to think about across the board. A genreal "MTA authorization" concept has the potential of creating a stirred pot of too many other interface point considerations. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp Mon Mar 15 19:32:24 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2G3WOf9019608; Mon, 15 Mar 2004 19:32: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 i2G3WOPr019607; Mon, 15 Mar 2004 19:32:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2G3WFNr019596 for ; Mon, 15 Mar 2004 19:32:17 -0800 (PST) (envelope-from aland@newgiles.nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id D8F3C16D00 for ; Mon, 15 Mar 2004 22:35:59 -0500 (EST) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Economics & deployment In-Reply-To: Your message of "Mon, 15 Mar 2004 20:17:17 CST." Date: Mon, 15 Mar 2004 22:35:59 -0500 Message-Id: <20040316033559.D8F3C16D00@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: wayne wrote: > Would you be able to provide some information on the domain names used > in this email traffic sample? I have no information on domain names. It's just a list of IP's. Alan DeKok. From owner-ietf-mxcomp Tue Mar 16 08:37:32 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2GGbWk5043207; Tue, 16 Mar 2004 08:37: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 i2GGbWCD043206; Tue, 16 Mar 2004 08:37:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2GGbVVk043200 for ; Tue, 16 Mar 2004 08:37:31 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i2GGbYZJ013623 for ; Tue, 16 Mar 2004 08:37:34 -0800 (PST) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 16 Mar 2004 08:37:34 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "IETF MXCOMP (E-mail) (E-mail)" Subject: On the interpretation question. Date: Tue, 16 Mar 2004 08:37:33 -0800 Reply-By: Mon, 31 Mar 2003 20:02:00 -0800 X-Message-Flag: Outlook spreads viruses and spam alike! MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Take a look at the following post from the SPF list. One thing it shows is that this particular user has a problem that is due to his local mail configuration. Rather than telling him to fix it (he won't) I think we need to accept that any set of rules for processing records are going to be affected by the local mail configuration. So rather than having the 'debate' proposed in the charter as to which aspects of a mail message are the 'right' ones to use I think we should try to write a spec that does not need the debate. The quickest way to write the spec is to specify the least amount that is required in order to achieve interoperability with a sender and a receiver. If the receiver is a standard one and the mail has not been transfered through a forwarder it does not matter which of the attributes are used they should all work as well. If you work at the gateway then you can use the SMTP FROM address and the results will work. If you are writing a client side filter you are going to have to be clever and work out how to sense what the local mail config happens to be and adapt. The point is that we do not need to write normative text for the receiver end, and even if we do write normative text it can and should be ignored. The only point where the text needs to be normative is at the generator end. And that is where the sender gets told 'before you deploy SPF records make sure your mail server is in compliance with these particular RFC 2821 etc requirements.' when necessary. Writing the spec in a declarative fashion becomes quite easy. You simply tell the sender to list out the set of all outgoing mail services at the edge of their network that you wish external receivers to accept mail from. You then provide simple ways to encode that set: 1) A list of the IP addresses themselves 2) By reference to other configuration data (e.g. mx records) 3) By reference to a look up service Where we can argue over which of these are necessary/desirable/etc. The point is that it is pretty easy to describe the semantics of the entries unambiguously. That is the part of the spec that has to be normative. That is the part of the spec that has to be reviewed extensively. One idea here would be we divide the spec into two documents, the first a purely normative spec which describes the data the sender wants to put into the DNS. The second would be an informational guide that describes ways the information can be used. Phill -----Original Message----- From: owner-spf-discuss@v2.listbox.com [mailto:owner-spf-discuss@v2.listbox.com]On Behalf Of Alain Knaff Sent: Tuesday, March 16, 2004 8:33 AM To: spf-discuss@v2.listbox.com Cc: Greg Cirino - Cirelle Enterprises Subject: Re: [spf-discuss] Everyone Having an SPF Record Fails From This List begin Tuesday 16 March 2004 14:03, Greg Cirino - Cirelle Enterprises quote: > I have a qmail system running maildrop which > calls spfquery with the appropriate headers and > It appears everyone that has an spf record in their > dns fails to this list, all others return none. > (i add headers to incoming mail to identify this) > > Is this the expected behavior? No, this is not expected... > > according to: > > http://spf.pobox.com/newheader.html > > When an SPF query returns "fail", the MTA should reject the connection. > > There would be a lot of mail going to the bit bucket, > or whatever, if I did that. Usually, mailing lists are supposed to put the listmasters address in the enveloppe From (in this case owner-spf-discuss@v2.listbox.com), and the spf list does indeed set this correctly (or else many other people, such as myself, would reject the list as well...). Maybe what is happening is that some program local to you is stripping the envelope From, and then reinitializing it from the header From? Regards, Alain ------- Sender Policy Framework: http://spf.pobox.com/ Archives at http://archives.listbox.com/spf-discuss/current/ Latest draft at http://spf.pobox.com/spf-draft-200403.txt Wiki: http://spfwiki.infinitepenguins.net/pmwiki.php/SenderPermittedFrom/ To unsubscribe, change your address, or temporarily deactivate your subscription, please go to http://v2.listbox.com/member/?listname=spf-discuss@v2.listbox.com From owner-ietf-mxcomp Tue Mar 16 11:13:41 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2GJDfmj054677; Tue, 16 Mar 2004 11:13: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 i2GJDfg5054676; Tue, 16 Mar 2004 11:13:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2GJDfXC054670 for ; Tue, 16 Mar 2004 11:13:41 -0800 (PST) (envelope-from hardie@qualcomm.com) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i2GJDhnp011018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 16 Mar 2004 11:13:43 -0800 (PST) Received: from [205.214.163.49] (vpn-10-50-16-102.qualcomm.com [10.50.16.102]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i2GJDdvx009180 for ; Tue, 16 Mar 2004 11:13:41 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: Date: Tue, 16 Mar 2004 11:13:38 -0800 To: ietf-mxcomp@imc.org From: Ted Hardie Subject: re: Draft Charter Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >It would useful for Mail Transfer Agents (MTAs) to be able to >confirm that peer MTAs are authorized to send mail on behalf of a >specific domain or network. This working group will develop a DNS-based >mechanism for storing and distributing information associated with that >authorization. While the primary current use case for this facility is to >combat a certain class of domain forgery in spam, the solution chosen >should be generally usable for MTA authorization. A number of folks have raised issues with this section of the charter; some of those have been on list (Phill, Hector) and some others off-list. Working through those comments, I don't see any that run counter to the sense of the meeting in Seoul or the discussions to date. In coming up with replacement language, though, I confess that I keep running into either very muddy language or appearing to specify a solution in the charter. Here's a crack at replacement text; comments welcome. ---new--draft--text It would be useful for Mail Transfer Agents (MTAs) implementing message acceptance policies to be able to confirm that peer MTAs' actions are authorized by specific domains or networks. This working group will develop a DNS-based mechanism for storing and distributing information associated with that authorization. While the primary current use case for this facility is to combat a certain class of domain forgery in spam, the solution chosen should be generally useful for MTA-MTA authorization. ___________________________________ regards, Ted Hardie From owner-ietf-mxcomp Tue Mar 16 12:21:35 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2GKLZAp059806; Tue, 16 Mar 2004 12:21: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 i2GKLZJ5059805; Tue, 16 Mar 2004 12:21:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2GKLYqY059798 for ; Tue, 16 Mar 2004 12:21:34 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i2GKLcmw012598; Tue, 16 Mar 2004 12:21:38 -0800 (PST) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 16 Mar 2004 12:21:38 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Ted Hardie'" , ietf-mxcomp@imc.org Subject: RE: Draft Charter Date: Tue, 16 Mar 2004 12:21:35 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Given that this is the charter lets try to avoid all use of terms that are considered contentious by anyone, in particular 'policy', 'authorization' etc. It would be useful for Mail Transfer Agents (MTAs) implementing message acceptance restrictions to be able to confirm that information provided by peer MTAs' is consistent with a description of the configuration of the purported origin. This working group will develop a DNS-based mechanism for storing and distributing information that describes the configuration of domains and networks that are relevant to this task. While the primary current use case for this facility is to combat a certain class of domain forgery in spam, the solution chosen should be generally useful for MTA-MTA authentication. [Notes: 1) Changed policy to restrictions, if left unqualified the term will be interpreted by some to mean authorization policy which in the context of SAML etc. is a statement by the resource owner that directly controls the resource. 2) A description of the configuration could include an authorization to send - if you want to think of the statement in those terms. I still think that we should avoid that characterization. 3) It would be nice to work in the principle outlined in CSRI, that what we are attempting to do here is provide a way for the sender of an email to provide the recipient with a small amount of additional information that allows the recipient to determine that it should be accepted. i.e. it is not likely to be spam because the purported origin is authentic and has a good reputation. 4) The term 'MTA-MTA' authorization does not seem right at all, the principle use of the information here is authentication of the message origin. We are not really providing authorization information, that is certainly involved - there will be accreditations of a peer MTA and there will be evaluations of accreditation providers. But those are exactly the parts that we don't want to have in scope. > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Ted Hardie > Sent: Tuesday, March 16, 2004 2:14 PM > To: ietf-mxcomp@imc.org > Subject: re: Draft Charter > > > > >It would useful for Mail Transfer Agents (MTAs) to be able to > >confirm that peer MTAs are authorized to send mail on behalf of a > >specific domain or network. This working group will > develop a DNS-based > >mechanism for storing and distributing information > associated with that > >authorization. While the primary current use case for this > facility is to > >combat a certain class of domain forgery in spam, the > solution chosen > >should be generally usable for MTA authorization. > > A number of folks have raised issues with this section of the charter; > some of those have been on list (Phill, Hector) and some > others off-list. > Working through those comments, I don't see any that run counter to > the sense of the meeting in Seoul or the discussions to date. In > coming up with replacement language, though, I confess that I keep > running into either very muddy language or appearing to specify > a solution in the charter. Here's a crack at replacement > text; comments > welcome. > > > ---new--draft--text > It would be useful for Mail Transfer Agents (MTAs) implementing > message acceptance policies to be able to confirm that peer MTAs' > actions are authorized by specific domains or networks. This > working group will develop a DNS-based mechanism for storing > and distributing information associated with that authorization. > While the primary current use case for this facility is to combat > a certain class of domain forgery in spam, the solution chosen > should be generally useful for MTA-MTA authorization. > ___________________________________ > > regards, > Ted Hardie > From owner-ietf-mxcomp Tue Mar 16 12:39:01 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2GKd1nG060711; Tue, 16 Mar 2004 12:39:01 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2GKd1eo060710; Tue, 16 Mar 2004 12:39:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from argon.connect.org.uk (argon.connectinternetsolutions.com [193.110.243.33]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2GKd0Z7060704 for ; Tue, 16 Mar 2004 12:39:00 -0800 (PST) (envelope-from jrk@merseymail.com) Received: from mmail by argon.connect.org.uk with local (connectmail/exim) id 1B3LL4-0002br-9s; Tue, 16 Mar 2004 20:39:02 +0000 Subject: Re: RE: Draft Charter To: "Hallam-Baker, Phillip" From: "Jon Kyme" Cc: "'Ted Hardie'" , X-Mailer: [ConnectMail 3.13.0] X-connectmail-Originating-IP: 82.69.7.27 Message-Id: Date: Tue, 16 Mar 2004 20:39:02 +0000 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: It would be useful for Mail Transfer Agents (MTAs) implementing message acceptance restrictions to be able to confirm that information provided by peer MTAs' is consistent with a description of the configuration of the purported origin. There's any number of possible uses for the information. Need it be limited to one kind of use? (so if Phillip can't bring himself to say 'policy' we shouldn't say anything narrower). Consider an MTA that just labels the message ... leaving accept/deny to another entity. My 2p. From owner-ietf-mxcomp Tue Mar 16 12:51:54 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2GKps1f061300; Tue, 16 Mar 2004 12:51:54 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2GKpspR061299; Tue, 16 Mar 2004 12:51:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2GKps18061293 for ; Tue, 16 Mar 2004 12:51:54 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i2GKpwaC029094; Tue, 16 Mar 2004 12:51:58 -0800 (PST) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 16 Mar 2004 12:51:58 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Jon Kyme'" , "Hallam-Baker, Phillip" Cc: "'Ted Hardie'" , ietf-mxcomp@imc.org Subject: RE: RE: Draft Charter Date: Tue, 16 Mar 2004 12:51:55 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > It would be useful for Mail Transfer Agents (MTAs) > implementing > message acceptance restrictions to be able to confirm that > information provided by peer MTAs' is consistent with a description > of the configuration of the purported origin. > > There's any number of possible uses for the information. Need > it be limited > to one kind of use? (so if Phillip can't bring himself to say > 'policy' we > shouldn't say anything narrower). Consider an MTA that just labels the > message ... leaving accept/deny to another entity. Brilliant. And moreover a little later in the charter there is a line to say that this is not the only use: "While the primary current use case for this facility is to combat a certain class of domain forgery in spam, the solution chosen should be generally useful for MTA-MTA authentication." I think that is enough context for a charter. If we do write a spec that does MTAMARK type work then the uses are likely to be quite broad. For example when our anti-phishing response incident unit finds a site the first thing the response engineer wants to know is who hosts the site and what type of site is it. It is very likely that we would pull up information from MTAMARK to display on the response dashboard to help her. This is another reason that I am keen to avoid policy commitments on the part of the sender. If you tell me that an IP address is a cable modem pool or an unattended PC in a cyber cafe I will probably respond very differently. Phill From owner-ietf-mxcomp Tue Mar 16 12:54:02 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2GKs2tj061414; Tue, 16 Mar 2004 12:54: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 i2GKs2OU061413; Tue, 16 Mar 2004 12:54:02 -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 (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2GKs1f9061407 for ; Tue, 16 Mar 2004 12:54:01 -0800 (PST) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.30) id 1B3LZd-0001cV-MP for ietf-mxcomp@imc.org; Tue, 16 Mar 2004 14:54:05 -0600 To: "IETF MXCOMP" Subject: Re: Draft Charter References: From: wayne Content-Type: text/plain; charset=US-ASCII Date: Tue, 16 Mar 2004 14:54:05 -0600 In-Reply-To: (Ted Hardie's message of "Tue, 16 Mar 2004 11:13:38 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (spfd: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In Ted Hardie writes: > A number of folks have raised issues with this section of the charter; I guess one other comment: I believe that all LMAP proposals can do their work inside the MTA during the transaction, but they could also do their work later on in, say, a spam filter or the MUA. I think that it is very important to be able to create a system that is useful both during them SMTP session, and after. A system that, for example, requires a challenge-response during the SMTP session that couldn't be done later, would not be very useful. Similarly, a system that required human interaction could work in the MUA, but not in the MTA. Is this a valid requirement for the charter? All the references to "MTA" in the charter kind of makes it sound like being able to work in the MUA is not important. I also think that is very useful, although maybe not critical, for the proposed system to work before the SMTP DATA command. That is, depending at all on the content of the email would make the system much less useful for me. Should this be a requirement for the charter also? Or, should we leave it up in the air? -wayne From owner-ietf-mxcomp Tue Mar 16 13:02:01 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2GL21Bn062377; Tue, 16 Mar 2004 13:02:01 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2GL21dl062376; Tue, 16 Mar 2004 13:02:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.40]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2GL21Lk062367 for ; Tue, 16 Mar 2004 13:02:01 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.52] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1B3LhJ-0004fI-00; Tue, 16 Mar 2004 16:02:01 -0500 Received: from [68.244.151.155] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1B3LhH-0007xR-00; Tue, 16 Mar 2004 16:02:01 -0500 Message-ID: <40576B3B.8090207@solidmatrix.com> Date: Tue, 16 Mar 2004 16:01:47 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: wayne CC: IETF MXCOMP Subject: Re: Draft Charter References: In-Reply-To: X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: wayne wrote: > In Ted Hardie writes: > > >>A number of folks have raised issues with this section of the charter; > > I guess one other comment: I believe that all LMAP proposals can do > their work inside the MTA during the transaction, but they could also > do their work later on in, say, a spam filter or the MUA. > The charter states "This working group will develop a DNS-based mechanism for storing and distributing information associated with that authorization". If we limit the scope of the charter to the mechanism for storing the data as opposed to how it is applied, we can avoid restricting the use of data only at MTA level and not MUA. We need to give people leaway on how the data is applied. The current draft charter seems to me to focus only on how the data is stored and distributed, not on how it is applied which might be something left to the implementors. All of this is my personal opinion of course. Yakov From owner-ietf-mxcomp Tue Mar 16 13:36:18 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2GLaIqX064248; Tue, 16 Mar 2004 13:36: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 i2GLaIVl064247; Tue, 16 Mar 2004 13:36:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2GLaI4J064241 for ; Tue, 16 Mar 2004 13:36:18 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.11/) with ESMTP id i2GLaMRL002694; Tue, 16 Mar 2004 13:36:22 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 16 Mar 2004 13:36:22 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'wayne'" , IETF MXCOMP Subject: RE: Draft Charter Date: Tue, 16 Mar 2004 13:36:20 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > I guess one other comment: I believe that all LMAP proposals can do > their work inside the MTA during the transaction, but they could also > do their work later on in, say, a spam filter or the MUA. I agree. The spec has two basic parts, sender and receiver. Only the sender part of the spec has to be standardized to make interoperability work. Ergo only the sender part should be normative. The description of the receiver part of the spec should be marked non-normative. If someone works out a way to interpret the information that is 'better' they will use it. > I think that it is very important to be able to create a system that > is useful both during them SMTP session, and after. A system that, > for example, requires a challenge-response during the SMTP session > that couldn't be done later, would not be very useful. Similarly, a > system that required human interaction could work in the MUA, but not > in the MTA. I beleive that the charter is very narrowly drawn to make sure that we only address the issue that is absolutely critical here - sender authentication by means of IP address information published in the DNS. Everything else apart from that record is out of scope. As for challenge-response, I think that is now so discredited that there is no way anything could happen in three months. This is a pity since although I detest these people who think they are so important that they use these schemes for every email they ever send, there are justifications. For example, confirming mailing list subscriptions is good. Given the amount of hassle I get from people sending me Zip files with viruses I don't think its unreasonable to use C/R for that particular case. But I do think it unreasonable to expect anything useful to happen using C/R by August. > Is this a valid requirement for the charter? All the references to > "MTA" in the charter kind of makes it sound like being able to work in > the MUA is not important. I think the references bind to the originating MTA. I don't think the recieving MTA is referenced as the focus of the work. > Should this be a requirement for the charter also? Or, should we > leave it up in the air? The charter describes only the scope of the work, not the requirements for the work. So it is good as written From owner-ietf-mxcomp Tue Mar 16 13:40:52 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2GLeqNx064539; Tue, 16 Mar 2004 13:40: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 i2GLeqQd064538; Tue, 16 Mar 2004 13:40:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2GLeqUM064532 for ; Tue, 16 Mar 2004 13:40:52 -0800 (PST) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id 2FDDFE0760; Tue, 16 Mar 2004 16:40:56 -0500 (EST) Date: Tue, 16 Mar 2004 16:40:56 -0500 From: John Leslie To: "Hallam-Baker, Phillip" Cc: "'Ted Hardie'" , ietf-mxcomp@imc.org Subject: Re: Draft Charter Message-ID: <20040316214056.GK18211@verdi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hallam-Baker, Phillip wrote: > [Ted Hardie wrote:] > >> ---new--draft--text >> It would be useful for Mail Transfer Agents (MTAs) implementing >> message acceptance policies to be able to confirm that peer MTAs' >> actions are authorized by specific domains or networks. > > Given that this is the charter lets try to avoid all use of terms > that are considered contentious by anyone, in particular 'policy', > 'authorization' etc. Mea culpa. I did suggest avoiding those terms. :^( > It would be useful for Mail Transfer Agents (MTAs) implementing > message acceptance restrictions to be able to confirm that > information provided by peer MTAs' is consistent with a description > of the configuration of the purported origin. I find Ted's language a _lot_ clearer here. "Message acceptance policies" makes it clear that the "policies" (whatever that might mean) are the province of the operators of the receiving MTA. "Restriction", alas, does not. Also, "information provided by peer MTAs" is awfully vague, and connotes something quite different from "actions". Ted's "authorized by specific domains or networks", to me, is clear in stating that the "authorization" (whatever that might mean) comes from specific domains or specific networks. Phillip's text is not clear on that. I, frankly, prefer Ted's text. I don't think there's any need for us to argue what "policy" means, or what "authorized" means, so long as the context makes it clear who assigns meaning to them. >> This working group will develop a DNS-based mechanism for storing >> and distributing information associated with that authorization. > > This working group will develop a DNS-based mechanism for storing > and distributing information that describes the configuration of > domains and networks that are relevant to this task. Phillip's text _may_ be an improvement here, but I still find Ted's text a lot clearer -- and I'm not at all sure our charter should talk of "describing the configuration". Does anyone else feel strongly? >> While the primary current use case for this facility is to combat >> a certain class of domain forgery in spam, the solution chosen >> should be generally useful for MTA-MTA authorization. > > 4) The term 'MTA-MTA' authorization does not seem right at all, > the principal use of the information here is authentication of the > message origin. There's that nasty "authentication" word! ;^) I suspect that this use of "authorization" may deserve to be dropped. Our standard should find uses that go well beyond MTA-MTA authorization. > We are not really providing authorization information, that is > certainly involved - there will be accreditations of a peer MTA > and there will be evaluations of accreditation providers. But > those are exactly the parts that we don't want to have in scope. Does anyone believe we need to change anything in Ted's draft to clarify that those parts are _not_ in our scope? -- John Leslie From owner-ietf-mxcomp Tue Mar 16 13:41:14 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2GLfECh064562; Tue, 16 Mar 2004 13:41: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 i2GLfExp064561; Tue, 16 Mar 2004 13:41:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2GLfD69064555 for ; Tue, 16 Mar 2004 13:41:13 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.11/) with ESMTP id i2GLfIML021555; Tue, 16 Mar 2004 13:41:18 -0800 (PST) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 16 Mar 2004 13:41:18 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Yakov Shafranovich'" , wayne Cc: IETF MXCOMP Subject: RE: Draft Charter Date: Tue, 16 Mar 2004 13:41:15 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > The charter states "This working group will develop a DNS-based > mechanism for storing and distributing information associated > with that > authorization". If we limit the scope of the charter to the mechanism > for storing the data as opposed to how it is applied, we can avoid > restricting the use of data only at MTA level and not MUA. I believe the opposite. I beleive that if we focus on only describing the configuration of the outgoing mail servers using the DNS in the normative part of the spec EVERYTHING else is non-normative. So we give an example of how to apply the data at the incomming MTA. We also provide an example of how to apply the data at an MUA with reasonable assumptions being made about the intermediate servers. But we do not require any particular approach here, this section is non-normative. > We need to give people leaway on how the data is applied. The current > draft charter seems to me to focus only on how the data is stored and > distributed, not on how it is applied which might be > something left to the implementors. Exactly, we provide complete freedom on the receiver side, they are going to ignore the group in any case, except as a source of hints. Phill From owner-ietf-mxcomp Tue Mar 16 13:48:20 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2GLmK2x064849; Tue, 16 Mar 2004 13:48: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 i2GLmKMG064848; Tue, 16 Mar 2004 13:48:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.41]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2GLmJ71064842 for ; Tue, 16 Mar 2004 13:48:19 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.50] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1B3MQ9-0003iZ-00; Tue, 16 Mar 2004 16:48:21 -0500 Received: from [68.244.151.155] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1B3MQ8-0006xU-00; Tue, 16 Mar 2004 16:48:21 -0500 Message-ID: <40577619.10805@solidmatrix.com> Date: Tue, 16 Mar 2004 16:48:09 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: "Hallam-Baker, Phillip" CC: wayne , IETF MXCOMP Subject: Re: Draft Charter References: In-Reply-To: X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hallam-Baker, Phillip wrote: >>The charter states "This working group will develop a DNS-based >>mechanism for storing and distributing information associated >>with that >>authorization". If we limit the scope of the charter to the mechanism >>for storing the data as opposed to how it is applied, we can avoid >>restricting the use of data only at MTA level and not MUA. > > > I believe the opposite. I beleive that if we focus on only describing > the configuration of the outgoing mail servers using the DNS in the > normative part of the spec EVERYTHING else is non-normative. > > So we give an example of how to apply the data at the incomming MTA. > We also provide an example of how to apply the data at an MUA with > reasonable assumptions being made about the intermediate servers. But > we do not require any particular approach here, this section is > non-normative. > The normative/non-normative split you are describing sounds good to me. I do have a different concern with the scope - if we are describing the configuration of the outgoing mail server, where do we draw the line? Right now we are focusing on ways to tie in MTA to the domain among other things, which is something present in several other protocols. However, describing the configuration would probably encompass a whole slew of other things, and might need a sightly different approach. Perhaps you can provide other examples of configuration data aside from accredidation? As for accredidation, I don't see how that is relevant to the "configuration" of the outgoing mail server. Perhaps you can elaborate? Yakov From owner-ietf-mxcomp Tue Mar 16 13:55:48 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2GLtm43065139; Tue, 16 Mar 2004 13:55: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 i2GLtmRG065138; Tue, 16 Mar 2004 13:55:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2GLtlHn065130 for ; Tue, 16 Mar 2004 13:55:47 -0800 (PST) (envelope-from hardie@qualcomm.com) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i2GLtnvf018872; Tue, 16 Mar 2004 13:55:49 -0800 (PST) Received: from [205.214.163.49] (vpn-10-50-16-102.qualcomm.com [10.50.16.102]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i2GLthvx017232; Tue, 16 Mar 2004 13:55:45 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: References: Date: Tue, 16 Mar 2004 13:55:43 -0800 To: "Hallam-Baker, Phillip" , ietf-mxcomp@imc.org From: Ted Hardie Subject: RE: Draft Charter Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 12:21 PM -0800 03/16/2004, Hallam-Baker, Phillip wrote: >Given that this is the charter lets try to avoid all use of terms >that are considered contentious by anyone, in particular 'policy', >'authorization' etc. Sadly, I think this would leave us with no terms at all. I think we must use some of the technical terms of the trade here. > >It would be useful for Mail Transfer Agents (MTAs) implementing >message acceptance restrictions to be able to confirm that >information provided by peer MTAs' is consistent with a description >of the configuration of the purported origin. "is consistent with a description of the configuration of the purported origin" seems to me personally to be too vague. We're actually aiming at something fairly specific, not at a general purpose descriptive RR. To take MX records as an example, they mean, essentially, "you can deliver mail to this domain at this host". The question it answers is "where do I send mail intended to reach this domain? MX record data could have been part of a record that was much more general, but it got pinned down to a specific function and it works pretty well. The key issue here is getting the question that needs to be asked right, so we can specify the record answering the question well. One way of asking the question might be "has the network or domain associated with this mail exchange listed this MTA in the DNS as being able to take this action"? In everyday English, "does this domain list this host as able to act as an outbound mail server?" is one question that falls under that general rubric. That may not be the right question, but, in my opinion, the question we answer needs to be at about that level of specificity to be really useful. Note that we don't need to get this question right in order to specify how an MTA uses it; we need to get this question right so that the DNS can store an answer, rather than a free-form description. (And none of this means, of course, that the receiving MTA will make its decision solely based on the listing--it is information it uses to make its determination.) Here's another shot, striking the "implementing message acceptance" and describing things slightly more from the "what gets stored" side than the "how it gets used side. ++++++++++++new++++text+++++++++++++++ It would be useful for those maintaining domains and networks to be able to specify that individual hosts or nodes are authorized to act as MTAs for messages sent from those domains or networks. This working group will develop a DNS-based mechanism for storing and distributing information associated with that authorization. The primary current use case for this facility is to allow recipient MTAs to confirm that peer MTAs' actions are authorized by specific domains or networks. This will help combat a certain class of domain forgery common in spam. The solution chosen, however, should be generally useful for others which might check this authorization data. +++++++++end++++++++++++++++++++++++++ From owner-ietf-mxcomp Tue Mar 16 13:56:42 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2GLugV6065201; Tue, 16 Mar 2004 13:56: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 i2GLug6i065200; Tue, 16 Mar 2004 13:56:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2GLuf79065193 for ; Tue, 16 Mar 2004 13:56:41 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.11/) with ESMTP id i2GLukak010263; Tue, 16 Mar 2004 13:56:46 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 16 Mar 2004 13:56:46 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'John Leslie'" , "Hallam-Baker, Phillip" Cc: "'Ted Hardie'" , ietf-mxcomp@imc.org Subject: RE: Draft Charter Date: Tue, 16 Mar 2004 13:56:43 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > It would be useful for Mail Transfer Agents (MTAs) implementing > > message acceptance restrictions to be able to confirm that > > information provided by peer MTAs' is consistent with a description > > of the configuration of the purported origin. > > I find Ted's language a _lot_ clearer here. "Message acceptance > policies" makes it clear that the "policies" (whatever that might > mean) are the province of the operators of the receiving MTA. > "Restriction", alas, does not. Actualy Jon pointed out we don't need that clause at all. Taking into account the other points raised I don't think we need the text at all: It would be useful for Mail Transfer Agents (MTAs) to be able to confirm that actions performed by peer MTAs' is consistent with the purported origin of messages they attempt to transfer. > Ted's "authorized by specific domains or networks", to me, is > clear in stating that the "authorization" (whatever that might mean) > comes from specific domains or specific networks. Phillip's text > is not clear on that. My problem was with the '"authorization" (whatever that might mean)' But I don't think we need it at all for charter purposes > I, frankly, prefer Ted's text. I don't think there's any need > for us to argue what "policy" means, or what "authorized" means, > so long as the context makes it clear who assigns meaning to them. I don't think we need to use the terms at all, my point is that they are making it harder to understand the problem, not easier. > >> This working group will develop a DNS-based mechanism for storing > >> and distributing information associated with that authorization. > > > > This working group will develop a DNS-based mechanism for storing > > and distributing information that describes the configuration of > > domains and networks that are relevant to this task. This working group will develop a DNS-based mechanism for storing and distributing information that is relevant to this task. > I suspect that this use of "authorization" may deserve to be > dropped. Our standard should find uses that go well beyond MTA-MTA > authorization. It seemed to me that 'authorization' was being used as a shorthand for 'access control', just because you often do the authorization part after authentication does not mean that it has to be that way. > > We are not really providing authorization information, that is > > certainly involved - there will be accreditations of a peer MTA > > and there will be evaluations of accreditation providers. But > > those are exactly the parts that we don't want to have in scope. > > Does anyone believe we need to change anything in Ted's draft > to clarify that those parts are _not_ in our scope? I think that it should be clear that C-R schemes, the details of how accreditation information are interpreted should be out of scope. But we have to be careful that we do not arbitrarily cut off important connections between this spec and other schemes that will be required. I have to be able to tell people that I have an accreditation as part of the sender description, the rules for interpreting that information are not in scope. From owner-ietf-mxcomp Tue Mar 16 14:03:56 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2GM3uvx065670; Tue, 16 Mar 2004 14:03:56 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2GM3uPE065669; Tue, 16 Mar 2004 14:03:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2GM3uVZ065661 for ; Tue, 16 Mar 2004 14:03:56 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.11/) with ESMTP id i2GM41Bi013019; Tue, 16 Mar 2004 14:04:01 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 16 Mar 2004 14:04:01 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Ted Hardie'" , "Hallam-Baker, Phillip" , ietf-mxcomp@imc.org Subject: RE: Draft Charter Date: Tue, 16 Mar 2004 14:03:57 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > At 12:21 PM -0800 03/16/2004, Hallam-Baker, Phillip wrote: > >Given that this is the charter lets try to avoid all use of terms > >that are considered contentious by anyone, in particular 'policy', > >'authorization' etc. > > Sadly, I think this would leave us with no terms at all. I > think we must use some of the technical terms of the trade here. Tempting though it is to try to reduce the charter to carte blanche to fix everything that needs fixing on the Internet in the next three months I'll accept that. > >It would be useful for Mail Transfer Agents (MTAs) implementing > >message acceptance restrictions to be able to confirm that > >information provided by peer MTAs' is consistent with a description > >of the configuration of the purported origin. > In everyday English, "does this domain > list this host as able to act as an outbound mail server?" I prefer the everyday English, "does this domain list this host as being configured to act as an outgoing mail server?" But the revision looks close enough here. If it will get through the IESG it has done its work. > Here's another shot, striking the "implementing message acceptance" > and describing things slightly more from the "what gets stored" side > than the "how it gets used side. > ++++++++++++new++++text+++++++++++++++ > It would be useful for those maintaining domains and networks > to be able to specify that individual hosts or nodes are authorized > to act as MTAs for messages sent from those domains or networks. > This working group will develop a DNS-based mechanism for > storing and distributing information associated with that > authorization. > The primary current use case for this facility is to allow recipient > MTAs to confirm that peer MTAs' actions are authorized by > specific domains or networks. This will help combat a certain > class of domain forgery common in spam. The solution chosen, > however, should be generally useful for others which might > check this authorization data. > > +++++++++end++++++++++++++++++++++++++ > From owner-ietf-mxcomp Tue Mar 16 17:06:38 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2H16cVX075855; Tue, 16 Mar 2004 17:06: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 i2H16cFN075854; Tue, 16 Mar 2004 17:06:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from i2kc04-ukbr.domain1.systemhost.net (smtp4.smtp.bt.com [217.32.164.151]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2H16awx075841 for ; Tue, 16 Mar 2004 17:06:37 -0800 (PST) (envelope-from wayne@midwestcs.com) Received: from mail pickup service by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC; Wed, 17 Mar 2004 01:01:52 +0000 Received: from i2kc04-ukbr.domain1.systemhost.net ([217.32.164.183]) by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 02:17:35 +0000 Received: From smtp4.smtp.bt.com ([10.216.123.44]) by i2kc04-ukbr.domain1.systemhost.net (WebShield SMTP v4.5 MR1a); id 1079403455379; Tue, 16 Mar 2004 02:17:35 +0000 Received: from above.proper.com ([208.184.76.39]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 02:17:34 +0000 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2G2HCKx014230; Mon, 15 Mar 2004 18:17:12 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2G2HCLQ014229; Mon, 15 Mar 2004 18:17:12 -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 (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2G2HB5H014222 for ; Mon, 15 Mar 2004 18:17:11 -0800 (PST) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.30) id 1B348r-0007Gw-8j for ietf-mxcomp@imc.org; Mon, 15 Mar 2004 20:17:17 -0600 To: "IETF MXCOMP" Subject: Re: Economics & deployment References: <20040311194323.6BBDE170F3@mail.nitros9.org> From: wayne Content-Type: text/plain; charset=US-ASCII Date: Mon, 15 Mar 2004 20:17:17 -0600 In-Reply-To: <20040311194323.6BBDE170F3@mail.nitros9.org> (Alan DeKok's message of "Thu, 11 Mar 2004 14:43:22 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (spfd: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 16 Mar 2004 02:17:34.0863 (UTC) FILETIME=[D83561F0:01C40AFC] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <20040311194323.6BBDE170F3@mail.nitros9.org> "Alan DeKok" writes: > So far as incentive goes, I just got my hands on an interesting set > of data. It's stats for about a week of email traffic, from a system > monitoring a large proportion of the SMTP traffic on the net. > > The quick conclusions are: > > [discussion of IP addresses snipped] Alan: Would you be able to provide some information on the domain names used in this email traffic sample? It appears likely that both IP and domain name info will be considered by this WG and it would be nice to have data on both. -wayne From owner-ietf-mxcomp Tue Mar 16 19:00:51 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2H30p84081804; Tue, 16 Mar 2004 19:00:51 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2H30plO081803; Tue, 16 Mar 2004 19:00:51 -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 (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2H30oYY081789 for ; Tue, 16 Mar 2004 19:00:50 -0800 (PST) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.30) id 1B3RIe-0004V7-Et for ietf-mxcomp@imc.org; Tue, 16 Mar 2004 21:00:56 -0600 To: "IETF MXCOMP" Subject: Re: Draft Charter References: From: wayne In-Reply-To: (Phillip Hallam-Baker's message of "Tue, 16 Mar 2004 13:36:20 -0800") User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) Message-ID: Content-Type: text/plain; charset=US-ASCII Date: Tue, 16 Mar 2004 20:58:40 -0600 MIME-Version: 1.0 Received-SPF: pass (spfd: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In "Hallam-Baker, Phillip" writes: >> I think that it is very important to be able to create a system that >> is useful both during them SMTP session, and after. A system that, >> for example, requires a challenge-response during the SMTP session > [...] > > As for challenge-response, I think that is now so discredited that > there is no way anything could happen in three months. When I mentioned "challenge-response", I meant the very general term as in CRAM, and not the common "challenge emails that require 'proof' of a human". There have been suggestions of adding a C-R system to the SMTP session to augment the TCP sequence numbers in authenticating the IP address. If any proposal *required* this, it might rule out the use in an MUA. Now, I don't claim to be a universal security expert, let alone someone who helps set industry wide definitions of terms. So, maybe my use of C-R is wrong, or maybe you really mean that things like CRAM have been discredited. If either of these are the case, please let me know. >> Is this a valid requirement for the charter? All the references to >> "MTA" in the charter kind of makes it sound like being able to work in >> the MUA is not important. > > I think the references bind to the originating MTA. I don't think the > recieving MTA is referenced as the focus of the work. There are mentions of "peer MTAs" and "recipient MTAs" in the charter text. >> Should this be a requirement for the charter also? Or, should we >> leave it up in the air? > > The charter describes only the scope of the work, not the requirements > for the work. So it is good as written I have not been seriously involved in IETF work groups before, but I was under the impression that requirement documents in the charter were not unheard off. (And, yes, I have read the "Tao of IETF" and the WG RFC and such to try to get up to speed.) -wayne From owner-ietf-mxcomp Tue Mar 16 19:00:51 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2H30p9H081801; Tue, 16 Mar 2004 19:00:51 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2H30pY7081800; Tue, 16 Mar 2004 19:00:51 -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 (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2H30nCt081788 for ; Tue, 16 Mar 2004 19:00:49 -0800 (PST) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.30) id 1B3RIe-0004V0-2E for ietf-mxcomp@imc.org; Tue, 16 Mar 2004 21:00:56 -0600 To: "IETF MXCOMP" Subject: Re: On the interpretation question. References: From: wayne Content-Type: text/plain; charset=US-ASCII Date: Tue, 16 Mar 2004 18:53:32 -0600 In-Reply-To: (Phillip Hallam-Baker's message of "Tue, 16 Mar 2004 08:37:33 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (spfd: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In "Hallam-Baker, Phillip" writes: > Take a look at the following post from the SPF list. > > One thing it shows is that this particular user has a problem that is > due to his local mail configuration. No, it was a problem with a user not understanding the difference between the "RFC2821 from" and the "RFC2822 from". > Rather than telling him to fix it (he won't) I think we need to accept > that any set of rules for processing records are going to be affected > by the local mail configuration. The user *did* fix it, he is now using the right data. > So rather than having the 'debate' proposed in the charter as to which > aspects of a mail message are the 'right' ones to use I think we should > try to write a spec that does not need the debate. I really do not see how you can write a system that works equally well for both the RFC2821 and RFC2822 "from" address. In some ways, a set of rules for the exact process would have reduced the chance that this person would have made an error. > Writing the spec in a declarative fashion becomes quite easy. You simply > tell the sender to list out the set of all outgoing mail services at > the edge of their network that you wish external receivers to accept > mail from. You then provide simple ways to encode that set: I think this will likely cause a certain amount of confusion. It isn't just the domain owner's machines that it can be acceptable to send email from. Basically, I think there is going to be a certain level of confusion by mail admins and email users no matter what we do. I do not think that a declarative spec with not even hints about how the information is supposed to be used is a cure-all. -wayne From owner-ietf-mxcomp Tue Mar 16 19:24:39 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2H3Od5R083599; Tue, 16 Mar 2004 19:24: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 i2H3OdnA083598; Tue, 16 Mar 2004 19:24:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2H3OciP083592 for ; Tue, 16 Mar 2004 19:24:38 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i2H3Oje3022817; Tue, 16 Mar 2004 19:24:45 -0800 (PST) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 16 Mar 2004 19:24:45 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'wayne'" , IETF MXCOMP Subject: RE: Draft Charter Date: Tue, 16 Mar 2004 19:24:36 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > When I mentioned "challenge-response", I meant the very general term > as in CRAM, and not the common "challenge emails that require 'proof' > of a human". Well that is going on but embedded deep in the TCP/IP sequence number. The IP based auth is simply listing the valid IP addresses. > There have been suggestions of adding a C-R system to > the SMTP session to augment the TCP sequence numbers in authenticating > the IP address. If any proposal *required* this, it might rule out > the use in an MUA. That is not being proposed. > I have not been seriously involved in IETF work groups before, but I > was under the impression that requirement documents in the charter > were not unheard off. (And, yes, I have read the "Tao of IETF" and > the WG RFC and such to try to get up to speed.) I think that requirements docs can serve their purpose but not in a WG that has a three month charter. From owner-ietf-mxcomp Tue Mar 16 19:32:57 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2H3WvKo083941; Tue, 16 Mar 2004 19:32: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 i2H3WvJ7083940; Tue, 16 Mar 2004 19:32:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.41]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2H3WuKr083934 for ; Tue, 16 Mar 2004 19:32:56 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.50] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1B3Rnh-0007NX-00; Tue, 16 Mar 2004 22:33:01 -0500 Received: from [68.244.151.155] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1B3Rng-0004Cu-00; Tue, 16 Mar 2004 22:33:01 -0500 Message-ID: <4057C6D9.6030501@solidmatrix.com> Date: Tue, 16 Mar 2004 22:32:41 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: "Hallam-Baker, Phillip" CC: "'wayne'" , IETF MXCOMP Subject: Re: Draft Charter References: In-Reply-To: X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hallam-Baker, Phillip wrote: >>There have been suggestions of adding a C-R system to >>the SMTP session to augment the TCP sequence numbers in authenticating >>the IP address. If any proposal *required* this, it might rule out >>the use in an MUA. > > > That is not being proposed. > This was part of MSFT's proposal which has not been formally submitted. The relevant quote appears on pages 20-21 and discusses NOOP command use with a form of C/R in combination with an SHA1 hash of the HELO greeting. This is not part of any document that was *formally* submitted to the IETF as input to the BoF, therefore it is NOT being proposed to my knowledge. Yakov From owner-ietf-mxcomp Tue Mar 16 20:21:42 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2H4LfdI085836; Tue, 16 Mar 2004 20:21: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 i2H4Lfm7085835; Tue, 16 Mar 2004 20:21:41 -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.8) with ESMTP id i2H4LX8o085828 for ; Tue, 16 Mar 2004 20:21:35 -0800 (PST) (envelope-from aland@newgiles.nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id F03EA170BB for ; Tue, 16 Mar 2004 23:25:16 -0500 (EST) From: "Alan DeKok" To: "IETF MXCOMP" Subject: Re: Economics & deployment In-Reply-To: Your message of "Mon, 15 Mar 2004 20:17:17 CST." Date: Tue, 16 Mar 2004 23:25:16 -0500 Message-Id: <20040317042516.F03EA170BB@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: wayne wrote: > Would you be able to provide some information on the domain names used > in this email traffic sample? I have no information on domain names. One domain may use multiple source addresses, and one address may be shared among multiple domains. The important thing is that even with 10^8 domains (so the registrars say), there are only 10^5 IP's originating volumes of non-spam SMTP traffic. Alan DeKok. From owner-ietf-mxcomp Wed Mar 17 07:33:25 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HFXP0e010828; Wed, 17 Mar 2004 07:33: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 i2HFXPXN010827; Wed, 17 Mar 2004 07:33:25 -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 (srv1.pan-am.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HFXOQR010821 for ; Wed, 17 Mar 2004 07:33:24 -0800 (PST) (envelope-from gordonf@pan-am.ca) Subject: Speaking of Propaganda... Date: Wed, 17 Mar 2004 09:33:26 -0600 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA7D4@srv1.pan-am.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Speaking of Propaganda... Thread-Index: AcQMNUfuQ8nrQ7wYTImPbxkvX9jSWQ== content-class: urn:content-classes:message From: "Gordon Fecyk" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 To: "IETF MXCOMP (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2HFXOQR010822 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Hallam-Baker, > Phillip > Sent: Tuesday, March 16, 2004 10:38 > To: IETF MXCOMP (E-mail) (E-mail) > Subject: On the interpretation question. > X-Message-Flag: Outlook spreads viruses and spam alike! Do you use Evilu, er, Evolution, instead of Outlook? Beware. -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Wed Mar 17 07:41:54 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HFfsK7011501; Wed, 17 Mar 2004 07:41:54 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2HFfsRv011500; Wed, 17 Mar 2004 07:41:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HFfrab011494 for ; Wed, 17 Mar 2004 07:41:53 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.11/) with ESMTP id i2HFfusg021192 for ; Wed, 17 Mar 2004 07:41:56 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 17 Mar 2004 07:41:56 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: IETF MXCOMP Subject: Accreditation NON-Proposal Date: Wed, 17 Mar 2004 07:41:55 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C40C36.600A6C5F" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C40C36.600A6C5F Content-Type: text/plain; charset="iso-8859-1" All, Attached is a proposal for an accreditation mechanism based on the existing DNS A record conventions but designed to allow extension to support other approaches. I do not propose the draft as a work item IN THIS PARTICULAR GROUP. However I do believe that the MARID proposal should provide at least the same degree of support for accreditation as CallerID and SPF do. Basically it should be possible to announce the fact that there is an accreditation and the location where that accreditation should be verified. If there is no way to say who your accreditation service is then we will be stuck with the 'single root of trust' problem that people have complained of wrt SSL certificates. It also means that a receiver does not end up having to check every accreditation service in existence just to find out which one the sender is subscribed to. The information that needs to be added into the domain record is a tripple: Accreditation - This attribute describes an accreditation Domain - The domain of the accreditation service Protocol(s) - A list of the verification protocol(s) that the service supports. The draft describes how this information can be expressed in the SPF and CallerID formats. Given the MARID schedule it is likely that there will be experience from trial deployments before the MARID spec is ready. Phill ------_=_NextPart_000_01C40C36.600A6C5F Content-Type: text/plain; name="accreditation.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="accreditation.txt" ASRG Working Group = =20 Internet Draft P. = Hallam-Baker=20 Document: draft-spf-accreditation-00.txt = VeriSign Inc.=20 Expires: September 2004 = March 2004=20 =20 =20 DNS Publication Accreditation Data=20 =20 =20 Status of this Memo=20 =20 This document is an Internet-Draft and is NOT offered in = accordance=20 with Section 10 of RFC2026, and the author does not provide = the=20 IETF with any rights other than to publish as an = Internet-Draft =20 =20 Internet-Drafts are working documents of the Internet = Engineering=20 Task Force (IETF), its areas, and its working groups. Note = that =20 other groups may also distribute working documents as = Internet- Drafts.=20 =20 Internet-Drafts are draft documents valid for a maximum of = six=20 months and may be updated, replaced, or obsoleted by other=20 documents at any time. It is inappropriate to use = Internet-Drafts=20 as reference material or to cite them other than as "work in=20 progress."=20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt=20 The list of Internet-Draft Shadow Directories can be accessed = at=20 http://www.ietf.org/shadow.html.=20 =20 Abstract=20 =20 This document describes a mechanism that may be used to = publish=20 accreditation data associated with email senders = authenticated by=20 means of SPF or CallerID.=20 =20 An accreditation is a description by a third party that = describes=20 an email sender in some way that helps the recipient estimate = the=20 likelihood that a message authenticated as being originated = by the=20 sender is spam. =20 =20 Conventions used in this document=20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL = NOT",=20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" = in=20 this document are to be interpreted as described in RFC-2119 = [1].=20 =20 =20 =20 Hallam-Baker Expires - September 2004 = [Page 1]=20 =20 =0C DNS Publication of Accreditation Data = March 2004=20 =20 =20 Table of Contents=20 =20 1. = Introduction...................................................2=20 1.1 Accreditation = Authorities..................................2=20 1.2 Accreditation = Statements...................................4=20 1.3 Publication of Accreditation = Statements....................4=20 1.4 Interpretation of Accreditation = Statements.................5=20 2. DNS Publication of Accreditation = Statements....................5=20 2.1 Accreditation Authority Description TXT = Record.............7=20 2.2 Sender Recipient A = Record..................................8=20 2.3 Sender Recipient TXT = Record................................8=20 3. Filter Interpretation = Guidelines...............................8=20 3.1 Establishing Provider = Reputation...........................9=20 3.2 Combining = Accreditations...................................9=20 4. Security = Considerations........................................9=20 4.1 Unauthenticated or Wrongly Authenticated = Sender............9=20 4.2 Untrustworthy Accreditation = Provider......................10=20 4.3 DNS Security = Issues.......................................10=20 = References.......................................................10=20 = Acknowledgments..................................................11=20 Author's = Addresses...............................................11=20 =20 1. Introduction=20 =20 This specification describes a mechanism that may be used to=20 publish accreditation data associated with email senders=20 authenticated by means of SPF [2] or CallerID [3].=20 =20 An accreditation is a statement by a third party that the = recipient=20 of an email may use to estimate the probability that the = sender is=20 a spammer.=20 =20 The architecture of this proposal generalizes existing = industry=20 practice with respect to publication of DNS blacklists = according to=20 the method proposed by Vixie [4]. =20 =20 Unlike the earlier proposal the mechanism described in this=20 document MAY be used by accreditation agencies that only = report=20 accreditation data for some email senders without unnecessary = queries for parties that are not covered. It is thus better = suited=20 to applications where the accreditation authority is = reporting=20 positive accreditation data concerning a small group of = trusted=20 senders.=20 =20 1.1 Accreditation Authorities=20 =20 =20 =20 Hallam-Baker Expires - September 2004 = [Page 2]=20 =20 =0C DNS Publication of Accreditation Data = March 2004=20 =20 =20 An Accreditation Authority is a third party that is = responsible for=20 making statements that describe email senders. =20 =20 Accreditation Authorities MAY be restricted or unrestricted. = A=20 restricted accreditation authority only publishes statements = that=20 relate to a restricted number of email senders. An = unrestricted=20 accreditation authority publishes statements for all email = senders.=20 =20 An accreditation authority may take additional measures to = improve=20 the value of their accreditation, for example bringing civil = suits=20 against parties that breach the undertakings given.=20 =20 1.2 Accountability of Accreditation Authorities=20 =20 Experience of anti-spam blacklists has shown that those who = attempt=20 to provide accountability must in turn be accountable.=20 =20 There is no difficulty in ensuring that accreditation = providers are=20 accountable to email recipients. An accreditation authority = that=20 provides incorrect accreditation will soon be ignored. The = value of=20 an accreditation may be measured empirically by measuring the = proportion of the message sent bearing a particular = accreditation=20 that are determined to be spam (e.g. through user reports).=20 =20 If the ability to measure the value of an accreditation = agency is=20 to be of use to the recipient it must be possible for new=20 accreditation providers to offer their services without = artificial=20 barriers to entry such as magic lists of =91approved=92 = providers.=20 =20 One way to avoid this problem is to allow email senders to = specify=20 the accreditation providers they favor. Although it is = unlikely=20 that any individual would specify an accreditation provider = that=20 gave them a bad rating, an accreditation service that had=20 established a sufficiently high reputation on the basis of = its=20 positive accreditations could offer to supply negative = ratings.=20 =20 This mechanism offers substantial advantages over the current = situation in which maintainers of anti-spam blacklists are=20 effectively unaccountable to any party. Accreditation = services are=20 held accountable to both senders and receivers. =20 =20 1.3 Practices Considerations=20 As a trusted third party the actions of an Accreditation = Authority=20 are raise numerous legal issues. These issues are outside the = scope=20 of this document. =20 =20 =20 =20 Hallam-Baker Expires - September 2004 = [Page 3]=20 =20 =0C DNS Publication of Accreditation Data = March 2004=20 =20 =20 1.4 Accreditation Statements=20 =20 At present a large number of different parties act as = Accreditation=20 Authorities with respect to sending of email. Blacklists = attempt to=20 identify bad faith actors while whitelists look to identify = good=20 faith actors. Whitelist accreditations may involve a simple = promise=20 not to spam or a promise that is backed up by some form of = penalty=20 such as the forfeiture of a bond or the publication of = negative=20 reputation data.=20 =20 Despite the wide variety in the types of data Accreditation=20 Authorities provide the inferences that anti-spam filtering=20 techniques attempt to draw are the same, is a particular item = of=20 email likely or unlikely to be spam. For this reason we leave = the=20 details of the accreditation mechanism to the Accreditation=20 Authority.=20 =20 An accreditation authority MAY publish any form of = accreditation=20 statement they choose. The following types of statement are = likely=20 to be of greatest utility.=20 =20 Identity Accreditation=20 =20 The email sender has provided a real world identity and a = physical=20 address at which legal process can be served and this = information=20 has been authenticated by means of some trustworthy process.=20 =20 Undertaking Accreditation=20 =20 In addition to meeting the identity accreditation = requirements, the=20 email sender has undertaken to comply with a specified email=20 sending policy.=20 =20 Performance Accreditation=20 =20 The email sender has been determined to have met the = requirements=20 of an email sending policy. If the email sender has = previously=20 undertaken to comply with the email sending policy in = question the=20 accreditation is a Compliance Accreditation.=20 =20 1.5 Notification of Accreditation Existence=20 =20 A sender MAY notify recipients of the existence of an = accreditation=20 statement by means of a policy notification mechanism such as = CallerID or SPF.=20 =20 The use of the policy notification mechanism allows senders = to=20 bring the existence of a new accreditation mechanism to the=20 =20 =20 Hallam-Baker Expires - September 2004 = [Page 4]=20 =20 =0C DNS Publication of Accreditation Data = March 2004=20 =20 =20 attention of an adaptive filtering mechanism. Such a filter = would=20 determine the reputation of an accreditation agency = empirically by=20 measuring the accuracy with which the agency categorizes = senders.=20 =20 Senders are unlikely to advertise the existence of = unfavorable=20 accreditation statements unless they believe that there is a = high=20 probability that the recipient will not verify the statement. = =20 Accreditation authorities that publish unfavorable data = concerning=20 a subject need to inform recipients that the accreditation = service=20 is 'open' and MAY be consulted to obtain information even if = the=20 sender does not list the service as an accreditor. This = information=20 SHOULD be provided by means of an Accreditation Authority=20 Description record.=20 =20 1.6 Publication of Accreditation Statements=20 =20 Accreditation statements are published by means of an = extension of=20 the existing mechanism used for publication of anti-spam = blacklists=20 via DNS.=20 =20 An accreditation statement is published by means of the DNS A = record. To avoid collisions with other uses of the DNS = addresses in=20 the 127.x.x.x loopback address range are used.=20 =20 1.7 Accreditation Authority Description Data=20 =20 The domain prefix specified for an accreditation service MAY=20 contain a record that describes the use of the particular=20 accreditation service with the key _accredit.=20 =20 1.8 Interpretation of Accreditation Statements=20 =20 Email recipients MAY interpret Accreditation Statements in = any=20 fashion they choose, including regarding an Accreditation = Statement=20 as a negative indicator.=20 =20 The reputation of the Accreditation Authority MUST be = considered=20 suspect until proven reliable.=20 =20 2. Policy Notification Bindings=20 =20 Policy notification bindings are specified for SPF and = CallerID.=20 Other notification bindings MAY be specified in the = specification=20 document describing the policy notification mechanism where = they=20 are to be used.=20 =20 =20 Hallam-Baker Expires - September 2004 = [Page 5]=20 =20 =0C DNS Publication of Accreditation Data = March 2004=20 =20 =20 Note that the policy bindings are not exclusive. A sender MAY = use=20 both the SPF and CallerID methods of specifying the email = policy.=20 =20 2.1 SPF=20 =20 A sender MAY use the SPF modifier 'accredit' to notify = recipients=20 of the existence of an accreditation record concerning the = sender=20 domain.=20 =20 accredit =3D =20 =20 The value specifies the location of the = accreditation=20 service. =20 =20 If the value of is 'accredit.test' and the sender = domain=20 is 'example.com':=20 =20 The accreditation authority description record for the = domain=20 will be the TXT record associated with the DNS label=20 accredit.test.=20 =20 The sender recipient record for the domain 'example.com' = will be=20 associated with the DNS label=20 example.com._accredit.accredit.test.=20 =20 A sender MAY specify multiple accreditation records. =20 =20 2.2 CallerID=20 =20 A sender MAY use the =91Per domain indication of email = transmission=20 policy=92 specified in the CSRI architecture [5]. The = accreditation=20 domain is specified by means of the element as = specified in=20 that document. The equivalent code for the SPF example above = would=20 be:=20 =20 =20 =20 accredit.test=20 =20 =20 =20 3. DNS Publication of Accreditation Statements=20 =20 The DNS is used to publish two types of accreditation = information:=20 =20 1. Information that describes how accreditation records MAY = be=20 interpreted.=20 =20 =20 Hallam-Baker Expires - September 2004 = [Page 6]=20 =20 =0C DNS Publication of Accreditation Data = March 2004=20 =20 =20 2. Accreditation records that describe the accreditation = status=20 of specific domains.=20 =20 The accreditation statements will in most cases be interpreted = by an=20 email filtering system that estimates the likelihood that the = email=20 message is wanted by combining information from a large number = of=20 sources.=20 =20 3.1 Accreditation Authority Description TXT Record=20 =20 The accreditation authority description record provides such a = filter=20 with hints that help an email filtering system interpret the=20 accreditation information. Such a filter can never be required = to=20 interpret any piece of data in a particular fashion since the = data may=20 be provided by an untrustworthy or even a malicious source.=20 =20 Knowing the type of information that an accreditation record = expresses=20 is useful when attempting to compare the information provided by = one=20 accreditation source with information from other sources.=20 Accreditation sources that claim to provide the same type of=20 information should show a high degree of correlation in the=20 information they provide.=20 =20 type:{ identity | undertaking | performance }=20 The type of accreditation provided as described in the = introduction.=20 =20 open:=20 If true the accreditation service is open and MAY be=20 consulted to obtain information even if the sender = does not=20 list the service as an accreditor.=20 =20 protocol: {dns-a | dns-txt | other }=20 The protocol by which the accreditation may be = retrieved.=20 The keyword dns-a specifies that the accreditation = record is=20 encoded as a DNS A record. The keyword dns-txt = specifies=20 that the accreditation record is encoded as a DNS TXT=20 record.=20 =20 length:=20 The number of bits in the record value that have=20 significance. =20 =20 =20 =20 Hallam-Baker Expires - September 2004 = [Page 7]=20 =20 =0C DNS Publication of Accreditation Data = March 2004=20 =20 =20 scale: {log2 | log10 | linear | none}=20 The scale to be applied when comparing the = corresponding=20 record values.=20 =20 3.2 Sender Recipient A Record=20 =20 The data in the A record is interpreted using direction = provided by=20 the accreditation authority description TXT record. =20 =20 The A record data field consists of four bytes. The existing=20 convention established by real-time DNS blacklist schemes = requires=20 that the most significant byte of the address be 127 to = indicate=20 the host loop-back address and that the least significant bit = of=20 the address indicate the presence or absence of a party from = a=20 blacklist.=20 =20 Bits 24-31=20 Authority SHOULD set these bits to the value 127. Relying = parties MUST ignore.=20 =20 Bits 8-23=20 These bits are used to encode the scale value=20 =20 Bits 4-7=20 These bits are reserved. Relying parties MUST ignore=20 =20 Bits 0-3=20 If the subject is accredited these bits are set to the = value=20 10. If the subject is not accredited these bits are set = to the=20 value 15.=20 =20 This convention is broadly compatible with existing conventions, = including those specified in the CSRI and SPF specifications.=20 =20 3.3 Other Sender Recipient Records=20 =20 Additional information MAY be provided by means of other DNS=20 records, for example TXT or NAPTR records. A Certificate = Authority=20 that has issued digital certificate(s) corresponding to an=20 accreditation MAY publish links to the certificate in the=20 accreditation record.=20 =20 4. Filter Interpretation Guidelines=20 =20 An email filter MAY make any use it chooses of information=20 provided. Accreditation information may come from an = untrustworthy=20 or even outright malicious source. The fact that an email = sender is=20 =20 =20 Hallam-Baker Expires - September 2004 = [Page 8]=20 =20 =0C DNS Publication of Accreditation Data = March 2004=20 =20 =20 accredited by such a source MAY be considered a negative = judgment=20 on the reputation of the source.=20 =20 4.1 Establishing Provider Reputation=20 =20 It is suggested that email filters SHOULD determine = weightings to=20 assign to accreditation notices from particular Accreditation = Authorities by means of empirical measurement of their=20 effectiveness rather than fixed a-priori values. If fixed=20 weightings are assigned it SHOULD be possible to override = these=20 values.=20 =20 For example an email recipient receiving a large quantity of = email=20 might perform an analysis of the accuracy of various = Accreditation=20 Authorities on a statistically significant sample of that = email.=20 =20 Recipients of smaller quantities of email might rely on third = party=20 assessments of the accuracy of Accreditation Authorities or = on=20 feedback from end-users identifying messages that have been = wrongly=20 categorized.=20 =20 4.2 Combining Accreditations=20 =20 When combining Accreditations from different Accreditation=20 Providers filters MAY use the information provided in the=20 Accreditation Authority Description record to determine = whether the=20 information provided is likely to have dependencies or not.=20 =20 For example an email sender that is accredited by two = different=20 Accreditation Authorities that verify identity information is = not=20 likely to be significantly less likely to be a spammer than = an=20 email sender that is only accredited by one Accreditation=20 Authority. But an Email sender that is accredited by one=20 Accreditation Authority that verifies identity information = and=20 another that monitors complaints from end users is less = likely to=20 be a spammer than a sender with only one of the = accreditations.=20 =20 5. Security Considerations=20 =20 5.1 Unauthenticated or Wrongly Authenticated Sender=20 =20 A positive accreditation has no value if someone other than = the=20 accreditation subject can make use of it. It is therefore = essential=20 for the sender of an email to be accredited before a positive = weight is given to an accreditation value.=20 =20 =20 =20 Hallam-Baker Expires - September 2004 = [Page 9]=20 =20 =0C DNS Publication of Accreditation Data = March 2004=20 =20 =20 5.2 Untrustworthy Accreditation Provider=20 =20 An Accreditation Authority may be untrustworthy for many = reasons,=20 they may perform their activities in a negligent fashion or = with=20 actual malice.=20 =20 For example a spammer might run an unrestricted accreditation = service that accurately listed all his rivals as spammers but = did=20 not list the spammer who operated the service. Alternatively = an=20 Accreditation service may maliciously publish a negative = reputation=20 about a subject.=20 =20 For this reason email filters MUST evaluate the reputation of = the=20 Accreditation Authority as well as the data provided by that=20 authority. =20 =20 The number of email senders that reference accreditation = records=20 published by an Accreditation Authority MAY provide an = indication=20 of the relative trustworthiness of that provider.=20 =20 5.3 DNS Security Issues=20 =20 The DNS protocol does not provide cryptographic assurance of = the=20 integrity of the information published and is vulnerable to = Denial=20 of Service attacks.=20 =20 These weaknesses do not seriously affect the security of the=20 accreditation mechanism when used for the purpose of spam = reduction=20 but may affect the security of the mechanism if it is applied = to=20 other purposes.=20 =20 References=20 =20 =20 1 Bradner, S., "Key words for use in RFCs to Indicate=20 Requirement Levels", BCP 14, RFC 2119, March 1997=20 =20 2 Meng Weng Wong, et. al., "Sender Policy Framework (SPF)",=20 Internet draft, February 2004, http://spf.pobox.com/draft- mengwong-spf-00.txt =20 =20 3 Microsoft Corp., "Caller ID for E-Mail Technical = Specification",=20 = http://www.microsoft.com/mscorp/twc/privacy/spam_callerid.mspx =20 =20 4 Paul Vixie, Proposal to IETF ASRG working group.=20 http://www1.ietf.org/mail-archive/working- groups/asrg/current/msg04508.html =20 =20 =20 Hallam-Baker Expires - September 2004 = [Page 10]=20 =20 =0C DNS Publication of Accreditation Data = March 2004=20 =20 =20 = =20 =20 5 Microsoft Corp. "Coordinated Spam Reduction Initiative", = February=20 2004, = http://download.microsoft.com/download/7/6/b/76b1a9e6- e240-4678-bcc7-fa2d4c1142ea/csri.pdf =20 =20 Acknowledgments=20 =20 The author acknowledges the contributions made to this proposal = by=20 Jeff Burstein and Nico Popp of VeriSign, Meng Weng Wong of = PoBox.com=20 and Bob Atkinson of Microsoft.=20 =20 Author's Addresses=20 =20 Phillip Hallam-Baker=20 VeriSign Inc.=20 Email: pbaker@verisign.com=20 =20 =20 =20 Hallam-Baker Expires - September 2004 = [Page 11]=20 =20 =0C ------_=_NextPart_000_01C40C36.600A6C5F-- From owner-ietf-mxcomp Wed Mar 17 07:43:40 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HFhep0011574; Wed, 17 Mar 2004 07:43: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 i2HFhet1011573; Wed, 17 Mar 2004 07:43:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HFhexA011567 for ; Wed, 17 Mar 2004 07:43:40 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2HFqCd30829; Wed, 17 Mar 2004 07:52:12 -0800 Date: Wed, 17 Mar 2004 07:42:59 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1552521530.20040317074259@brandenburg.com> To: Ted Hardie CC: ietf-mxcomp@imc.org Subject: Draft Charter milestone sequence In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ted, A thought on the milestones: Given the long and difficult history of discussion about MTA-based authentication: An effort to first choose the identity that is being authenticated, before discussing concrete proposals, is likely to suffer too much abstraction. This is not a topic and this is not a group of participants with much success as such fuzziness. That said, I think that agreeing on the identity, before choosing the the authentication _mechanism_, is a good thing. It gives us a tight, incremental approach to the process, and we need all the process help we can get. How to resolve the problem? I suggest that we have a deadline for _semantic_ proposals, before we attempt to choose an identity. That is, folks should submit a description of the identity and the proposed approach to its authentication, without the syntax or other protocol details. Hence the discussion of choice of identity can refer to proposals associated, without having to get bogged down in their gory details. So, we might have 3 proposals for identity X and 2 for identity Y. We could choose X or Y without deciding which of the proposals. This gives us incremental steps in the fashion you are attempting, but gives a sense of the ways identities will be authenticated as input to the identity-choosing exercise. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Wed Mar 17 07:50:35 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HFoZq2012876; Wed, 17 Mar 2004 07:50: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 i2HFoZVW012875; Wed, 17 Mar 2004 07:50:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HFoYuw012867; Wed, 17 Mar 2004 07:50:34 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.11/) with ESMTP id i2HFobFS002944; Wed, 17 Mar 2004 07:50:37 -0800 (PST) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 17 Mar 2004 07:50:37 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Gordon Fecyk'" , "IETF MXCOMP (E-mail)" Cc: "'Paul Hoffman / IMC'" Subject: RE: Speaking of Propaganda... Date: Wed, 17 Mar 2004 07:50:33 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This header does not appear in the messages I am receiving. It might be that we strip out unrecognized headers. But it seems more likely that it is being added by your own virus or spam filtering config. If it was the IMC doing this it would be a pretty serious breach of trust as well as being childish. Phill > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Gordon Fecyk > Sent: Wednesday, March 17, 2004 10:33 AM > To: IETF MXCOMP (E-mail) > Subject: Speaking of Propaganda... > > > > > -----Original Message----- > > From: owner-ietf-mxcomp@mail.imc.org > > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Hallam-Baker, > > Phillip > > Sent: Tuesday, March 16, 2004 10:38 > > To: IETF MXCOMP (E-mail) (E-mail) > > Subject: On the interpretation question. > > X-Message-Flag: Outlook spreads viruses and spam alike! > > Do you use Evilu, er, Evolution, instead of Outlook? Beware. > > > -- > PGP key (0x0AFA039E): > What's a PGP Key? See > GOD BLESS AMER, er, THE INTERNET. > > From owner-ietf-mxcomp Wed Mar 17 08:08:44 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HG8h0t014412; Wed, 17 Mar 2004 08:08: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 i2HG8hc1014411; Wed, 17 Mar 2004 08:08:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HG8gnG014400 for ; Wed, 17 Mar 2004 08:08:43 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: Date: Wed, 17 Mar 2004 08:08:31 -0800 To: ietf-mxcomp@imc.org From: Paul Hoffman / IMC Subject: RE: Speaking of Propaganda... Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 7:50 AM -0800 3/17/04, Hallam-Baker, Phillip wrote: >If it was the IMC doing this it would be a pretty serious >breach of trust as well as being childish. So, Phill, if you think that an organization is doing something that is a serious breach of trust as well as being childish, shouldn't you ask them first in private? Or simply look at the dozens of other mailing lists that the organization runs and see if the action is being taken there? Either of these might be considered more mature and less of a waste of bandwidth than simply posting an accusation on a public mailing list. And, in case it isn't clear: no, of course we're not adding that header. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-mxcomp Wed Mar 17 08:15:53 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HGFrdI014911; Wed, 17 Mar 2004 08:15: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 i2HGFr9x014910; Wed, 17 Mar 2004 08:15:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HGFq98014902; Wed, 17 Mar 2004 08:15:52 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i2HGFt36012727; Wed, 17 Mar 2004 08:15:55 -0800 (PST) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 17 Mar 2004 08:15:55 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Paul Hoffman / IMC'" , ietf-mxcomp@imc.org Subject: RE: Speaking of Propaganda... Date: Wed, 17 Mar 2004 08:15:52 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > At 7:50 AM -0800 3/17/04, Hallam-Baker, Phillip wrote: > >If it was the IMC doing this it would be a pretty serious > >breach of trust as well as being childish. > > So, Phill, if you think that an organization is doing something that > is a serious breach of trust as well as being childish, shouldn't you > ask them first in private? No because my mail made it clear that I did not think you were doing it. The accusation had been made though, hence the need for a rebuttal. Phill From owner-ietf-mxcomp Wed Mar 17 08:20:51 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HGKpTc015352; Wed, 17 Mar 2004 08:20:51 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2HGKps3015351; Wed, 17 Mar 2004 08:20:51 -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 (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HGKot9015343; Wed, 17 Mar 2004 08:20:51 -0800 (PST) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.30) id 1B3dmn-0003yN-NZ; Wed, 17 Mar 2004 10:20:53 -0600 To: "IETF MXCOMP" Cc: "'Paul Hoffman / IMC'" Subject: Re: Speaking of Propaganda... References: From: wayne Content-Type: text/plain; charset=US-ASCII Date: Wed, 17 Mar 2004 10:20:53 -0600 In-Reply-To: (Phillip Hallam-Baker's message of "Wed, 17 Mar 2004 07:50:33 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (spfd: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: [top-posting corrected] In "Hallam-Baker, Phillip" writes: > >> > Phillip writes: >> > From: owner-ietf-mxcomp@mail.imc.org >> > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Hallam-Baker, >> > Phillip >> > Sent: Tuesday, March 16, 2004 10:38 >> > To: IETF MXCOMP (E-mail) (E-mail) >> > Subject: On the interpretation question. >> > X-Message-Flag: Outlook spreads viruses and spam alike! > > In <700EEF5641B7E247AC1C9B82C05D125DA7D4@srv1.pan-am.ca> "Gordon Fecyk" writes: >> >> Do you use Evilu, er, Evolution, instead of Outlook? Beware. >> Initially, I thought that the propoganda that was being pointed out was the article on vmyths, which was written over three years ago and is full of FUD. > This header does not appear in the messages I am receiving. While most of the messages that I receive from this list do not have this message, PHB's original message with the subject "On the interpretation question." does indeed have it. This appears to be either something that PHB added, or something that verislime added. -wayne From owner-ietf-mxcomp Wed Mar 17 08:25:17 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HGPHAo015545; Wed, 17 Mar 2004 08:25: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 i2HGPHid015544; Wed, 17 Mar 2004 08:25:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HGPGeB015536; Wed, 17 Mar 2004 08:25:16 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i2HGPJ5V016482; Wed, 17 Mar 2004 08:25:19 -0800 (PST) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 17 Mar 2004 08:25:19 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "Hallam-Baker, Phillip" , "'Paul Hoffman / IMC'" , ietf-mxcomp@imc.org Subject: RE: Speaking of Propaganda... Date: Wed, 17 Mar 2004 08:25:13 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: OK, I have now found the source of the header! It turns out that outlook includes all the headers of a message along with the content. Presumably so that calendar functions etc work properly. The source of the original message that I forwarded had added the header. So it is not the IMC (we never thought it was) but it is still pretty childish. Phill > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Hallam-Baker, > Phillip > Sent: Wednesday, March 17, 2004 11:16 AM > To: 'Paul Hoffman / IMC'; ietf-mxcomp@imc.org > Subject: RE: Speaking of Propaganda... > > > > > > At 7:50 AM -0800 3/17/04, Hallam-Baker, Phillip wrote: > > >If it was the IMC doing this it would be a pretty serious > > >breach of trust as well as being childish. > > > > So, Phill, if you think that an organization is doing > something that > > is a serious breach of trust as well as being childish, > shouldn't you > > ask them first in private? > > No because my mail made it clear that I did not think you were > doing it. The accusation had been made though, hence the need for > a rebuttal. > > > Phill > From owner-ietf-mxcomp Wed Mar 17 08:30:32 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HGUWaM015787; Wed, 17 Mar 2004 08:30: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 i2HGUWXk015786; Wed, 17 Mar 2004 08:30:32 -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 (srv1.pan-am.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HGUTWr015777 for ; Wed, 17 Mar 2004 08:30:32 -0800 (PST) (envelope-from gordonf@pan-am.ca) Subject: RE: Draft Charter Date: Wed, 17 Mar 2004 10:30:32 -0600 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA7D7@srv1.pan-am.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft Charter content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Index: AcQLoalFpPlUNgTiTqOl+rGTw+sJsAAlCrQQ From: "Gordon Fecyk" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2HGUWWr015781 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > At 12:21 PM -0800 03/16/2004, Hallam-Baker, Phillip wrote: > >Given that this is the charter lets try to avoid all use of terms > >that are considered contentious by anyone, in particular 'policy', > >'authorization' etc. > > Sadly, I think this would leave us with no terms at all. I think that's what he wants. :-) > ++++++++++++new++++text+++++++++++++++ > It would be useful for those maintaining domains and networks > to be able to specify that individual hosts or nodes are authorized > to act as MTAs for messages sent from those domains or networks. > This working group will develop a DNS-based mechanism for > storing and distributing information associated with that > authorization. I'm happy with this, as it describes exactly what the existing proposals try to do. > The primary current use case for this facility is to allow recipient > MTAs to confirm that peer MTAs' actions are authorized by > specific domains or networks. This will help combat a certain > class of domain forgery common in spam. The solution chosen, > however, should be generally useful for others which might > check this authorization data. > > +++++++++end++++++++++++++++++++++++++ Just to make sure I'm on the right track with the language used, if it isn't English or some proprietary form of legalese, I'm interpreting "authorization" as the sender domain saying: "These hosts or nodes can act as MTAs for our domain or network." -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Wed Mar 17 08:31:35 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HGVZdT015835; Wed, 17 Mar 2004 08:31: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 i2HGVZob015834; Wed, 17 Mar 2004 08:31:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HGVYgd015828 for ; Wed, 17 Mar 2004 08:31:34 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.11/) with ESMTP id i2HGVbvw019671; Wed, 17 Mar 2004 08:31:37 -0800 (PST) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 17 Mar 2004 08:31:37 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Dave Crocker'" , Ted Hardie Cc: ietf-mxcomp@imc.org Subject: RE: Draft Charter milestone sequence Date: Wed, 17 Mar 2004 08:31:37 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: There is another way to avoid this, leave out the identity issue altogether. There are a number of source headers that a sender might be authenticating. Which one is important depends on whether the mail server is the original source of the message or a forwarder of some type. In the most plain vanila mail config all the possible addresses will match. In the most complex all of these can be different. But it actually does not matter, as a receiver choose ANY address you like, look for the SPF record and if it is there see if the information you have is compatible with the message being sent from a listed outgoing mail server. The only thing we need to agree on here is that if the DNS record lists the set of IP addresses X (by whatever means) then at some point Y during the transfer the message SHOULD have passed through a mail server at IP address z such that z is a member of X. In certain circumstances we can narrow down the issue of point Y further. The address given in SMTP FROM should always be consistent with the IP address from which the packet came[1]. (i.e. if IP address 1.2.3.4 says HELO example.com then we check that 1.2.3.4 is listed for example.com. [1] Although this is most relevant for externally facing mail services it is actually true for any mail service. Look up Adelyn Lee and Larry Ellison to see why this is useful for non external services. I don't think we need to open up the identity question at all. Clearly there is a big difference in the effect that we get if we authenticate different parts of the message. In particular: Message From: This is the address presented to the user by most MUAs. We should authenticate this address to prevent impersonation spam (aka joe jobs) Envelope FROM: This address is not seen by the user, but it can be used for accreditation purposes. E.g. message comes from isp.com, isp.com has positive reputation, accept it. Other Message headers can be used in the same way as envelope from. I don't think we need to get into the identity issue here. The question is already decided in the protocols. > An effort to first choose the identity that is being > authenticated, before discussing concrete proposals, is likely to > suffer too much abstraction. > > This is not a topic and this is not a group of participants with much > success as such fuzziness. > > That said, I think that agreeing on the identity, before choosing the > the authentication _mechanism_, is a good thing. It gives us a tight, > incremental approach to the process, and we need all the > process help we > can get. > > How to resolve the problem? > > I suggest that we have a deadline for _semantic_ > proposals, before > we attempt to choose an identity. > > That is, folks should submit a description of the identity and the > proposed approach to its authentication, without the syntax or other > protocol details. Hence the discussion of choice of identity can refer > to proposals associated, without having to get bogged down in > their gory > details. > > So, we might have 3 proposals for identity X and 2 for identity Y. We > could choose X or Y without deciding which of the proposals. > This gives > us incremental steps in the fashion you are attempting, but gives a > sense of the ways identities will be authenticated as input to the > identity-choosing exercise. > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA > From owner-ietf-mxcomp Wed Mar 17 08:36:02 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HGa2k1016110; Wed, 17 Mar 2004 08:36: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 i2HGa2Jw016109; Wed, 17 Mar 2004 08:36:02 -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 (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HGa14U016103 for ; Wed, 17 Mar 2004 08:36:02 -0800 (PST) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.30) id 1B3e1U-0004FC-RF for ietf-mxcomp@imc.org; Wed, 17 Mar 2004 10:36:04 -0600 To: "IETF MXCOMP" Subject: Re: Speaking of Propaganda... References: From: wayne Content-Type: text/plain; charset=US-ASCII Date: Wed, 17 Mar 2004 10:36:04 -0600 In-Reply-To: (Phillip Hallam-Baker's message of "Wed, 17 Mar 2004 08:25:13 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (spfd: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In "Hallam-Baker, Phillip" writes: > OK, I have now found the source of the header! > > It turns out that outlook includes all the headers of a message along with > the content. Presumably so that calendar functions etc work properly. No, Outlook does *not* include all the headers of a message. If it did, your message would have had a References: and In-Reply-To: header. It sure would be nice if all MUAs created and included those headers, it would make threading work a heck of a lot better. -wayne From owner-ietf-mxcomp Wed Mar 17 08:37:16 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HGbGA5016237; Wed, 17 Mar 2004 08:37:16 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2HGbGfr016236; Wed, 17 Mar 2004 08:37:16 -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 (srv1.pan-am.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HGbFA1016229 for ; Wed, 17 Mar 2004 08:37:15 -0800 (PST) (envelope-from gordonf@pan-am.ca) Subject: RE: Accreditation NON-Proposal Date: Wed, 17 Mar 2004 10:37:18 -0600 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA7D8@srv1.pan-am.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Accreditation NON-Proposal content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Index: AcQMNtjIJmprQdDvR/eJre2MGbKOlQAAHaPw From: "Gordon Fecyk" To: "IETF MXCOMP" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2HGbGA1016231 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Hallam-Baker, > Phillip > > Attached is a proposal for an accreditation mechanism > based on the > existing DNS A record conventions but designed to allow > extension to support other approaches. > Basically it should be possible to announce the fact > that there is > an accreditation and the location where that accreditation should be > verified. If there is no way to say who your accreditation > service is then > we will be stuck with the 'single root of trust' problem that > people have complained of wrt SSL certificates. I wanted to use DNS to avoid the use of any "single root of trust" or collection of trusted roots. All of the existing proposals assume the domain decides which of its hosts or nodes or other entities send mail, assuming the administrators of the domain have that control.[2] So by using DNS we've already addressed this particular problem. Wether the domain itself is trustworthy or not, I believe, is not the decision of any central authority or array of loosely centralized authorities. The recipient decides.[1] My impression is no e-mail domain admins want any centralized authority or collection thereof to say they're allowed to send mail. [1] The receiver pays to receive e-mail. The ISP gets paid by the receiver, and the ISP has to pay someone to receive e-mail. While it's been an anti-spammer's mantra for five years, I've only seen spammers and purists try to argue it, with only rare success. [2] I won't say it. It's too easy. -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Wed Mar 17 08:50:14 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HGoEus017163; Wed, 17 Mar 2004 08:50: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 i2HGoEM6017162; Wed, 17 Mar 2004 08:50:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HGoDvu017156 for ; Wed, 17 Mar 2004 08:50:13 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i2HGoGkU026430; Wed, 17 Mar 2004 08:50:16 -0800 (PST) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 17 Mar 2004 08:50:15 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Gordon Fecyk'" , IETF MXCOMP Subject: RE: Accreditation NON-Proposal Date: Wed, 17 Mar 2004 08:50:13 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > So by using DNS we've already addressed this particular > problem. Wether the > domain itself is trustworthy or not, I believe, is not the > decision of any > central authority or array of loosely centralized > authorities. The recipient decides.[1] The problem with this approach is that it means that you can only have negative accreditation data. This get you into the problem of trying to police the entire net which as MAPS and SPEWS prove is impossible to do well. As a sender I get to choose which positive actions I will take to obtain an accreditation. I can choose to obtain an accreditation from one source or many. But I have to choose which ones I get the accreditation from. As a receiver you get to choose whether to take any notice of it at all, or even that the accreditation is so widely abused that you will consider that advertising it reduces my reputation. > My impression is no e-mail domain admins want any centralized > authority or collection thereof to say they're allowed to send mail. My impression is that they hate MAPS, SPEWS and everyone in between with a passion, precisely because they have set themselves up to do that. There is an immense demand for a credible multi-party whitelist scheme. Instead of separately having to get an erroneous blacklist entry cancelled at AOL, Comcast, Yahoo etc, show that you are not a spammer. As I said at the time, 'collateral damage' is an ego trip for the blacklists that causes real harm to innocent parties. Phill From owner-ietf-mxcomp Wed Mar 17 09:23:41 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HHNf8L019404; Wed, 17 Mar 2004 09: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 i2HHNf0W019403; Wed, 17 Mar 2004 09:23:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HHNeBg019397 for ; Wed, 17 Mar 2004 09:23:41 -0800 (PST) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id A2614E06AC; Wed, 17 Mar 2004 12:23:43 -0500 (EST) Date: Wed, 17 Mar 2004 12:23:43 -0500 From: John Leslie To: "Hallam-Baker, Phillip" Cc: "'Gordon Fecyk'" , IETF MXCOMP Subject: Re: Accreditation NON-Proposal Message-ID: <20040317172343.GN18211@verdi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hallam-Baker, Phillip wrote: > [Gordon Fecyk wrote:] > >> Whether the domain itself is trustworthy or not, I believe, is >> not the decision of any central authority or array of loosely >> centralized authorities. The recipient decides. The recipient needs some basis to decide. Accreditation (though I'd prefer to avoid that term) could help the recipient decide. > The problem with this approach is that it means that you can only > have negative accreditation data. Actually, that's not true. With or without an "accreditation" record in DNS, there will be whitelists as well as blacklists. The advantage of having such records in DNS is to assist the sender in suggesting a particular whitelist to check. > This get you into the problem of trying to police the entire net > which as MAPS and SPEWS prove is impossible to do well. Whether or not we believe blacklists to be evil, I would hope we could agree that policing the entire net is impossible. > As a sender I get to choose which positive actions I will take > to obtain an accreditation. I can choose to obtain an accreditation > from one source or many. But I have to choose which ones I get > the accreditation from. Note that Phillip has clarified here that he's thinking in terms of advertising multiple "accreditations". While I saw very little point in being able to advertise only one, I see a potential for great benefits from advertising many. The recipient can choose which (if any) to "trust". > As a receiver you get to choose whether to take any notice of > it at all, or even that the accreditation is so widely abused > that you will consider that advertising it reduces my reputation. That, too -- though it's probably a very silly policy... >> My impression is no e-mail domain admins want any centralized >> authority or collection thereof to say they're allowed to send >> mail. There's quite a difference between exactly-one "accreditation" source and a potentially-large marketplace of "accreditation" sources. > There is an immense demand for a credible multi-party whitelist > scheme. Instead of separately having to get an erroneous blacklist > entry cancelled at AOL, Comcast, Yahoo etc, show that you are not > a spammer. It seems worth trying... -- John Leslie From owner-ietf-mxcomp Wed Mar 17 09:27:35 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HHRZ8V019607; Wed, 17 Mar 2004 09:27: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 i2HHRZOU019606; Wed, 17 Mar 2004 09:27:35 -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 (srv1.pan-am.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HHRYgj019600 for ; Wed, 17 Mar 2004 09:27:34 -0800 (PST) (envelope-from gordonf@pan-am.ca) Subject: RE: Accreditation NON-Proposal Date: Wed, 17 Mar 2004 11:27:37 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA7DA@srv1.pan-am.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: content-class: urn:content-classes:message Thread-Topic: Accreditation NON-Proposal X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Index: AcQMP+25in2eYyrDQsCzGSQVZMFpWQAAstRw From: "Gordon Fecyk" To: "IETF MXCOMP" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2HHRYgj019601 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > So by using DNS we've already addressed this particular > > problem. Wether the > > domain itself is trustworthy or not, I believe, is not the > > decision of any > > central authority or array of loosely centralized > > authorities. The recipient decides.[1] > > The problem with this approach is that it means that you can only > have negative accreditation data. I disagree. The current proposals *assume* negative accreditation but the sender domains publish positive accreditation. It's that information that lets the domain control how their domain is used. That's actually the point of all this. A SMTP server trusts everyone by default, and we've gone to great lengths to block abusive e-mail *after the fact*. Yet we continue to accept abusive e-mail by default. > This get you into the problem of trying to police the entire net > which as MAPS and SPEWS prove is impossible to do well. I won't argue this. Projects like those can only catch abusive mail and senders after the fact. It's why I started looking at before-the-fact approaches and I believe Hadmut, Meng and Raymond etc were similarly motivated. I believe it's high time for assuming "negative accreditation" and asking questions later. Those questions, and corresponding answers, are what the current proposals are about. I once suggested: "spammer until proven innocent." I should generalize that to: "If I don't know you[1] you're not welcome." There are so many real-world analogies to it that I can't list them all here. [1] My accepted value of $knowyou in this case, is, "Are you really who you say you are?" or authentication, and "are you allowed to do this on behalf of who you say you are?" or authorization. -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Wed Mar 17 09:41:14 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HHfE7D020418; Wed, 17 Mar 2004 09:41: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 i2HHfE0m020417; Wed, 17 Mar 2004 09:41:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HHfBtT020403 for ; Wed, 17 Mar 2004 09:41:11 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.11/) with ESMTP id i2HHfEQJ001279; Wed, 17 Mar 2004 09:41:14 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 17 Mar 2004 09:41:14 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'John Leslie'" , "Hallam-Baker, Phillip" Cc: "'Gordon Fecyk'" , IETF MXCOMP Subject: RE: Accreditation NON-Proposal Date: Wed, 17 Mar 2004 09:41:05 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Note that Phillip has clarified here that he's thinking in terms > of advertising multiple "accreditations". While I saw very little > point in being able to advertise only one, I see a potential for > great benefits from advertising many. The recipient can choose > which (if any) to "trust". I suspect that there will be multiple levels here. If there is a bonded sender type scheme it should suffice to be a member of a single program (costs multiply otherwise). But there is certainly a value to multiple performance evaluations. Here the basic 'identity' accreditation proves that you are a real business and shows that there is some considerable friction that discourages 'churn and burn' use of addresses. It means that you close the $9 buy a domain name vulnerability by making it a $1000+ build a new fake corporate identity cost. But you still need some control here, an ISP that does not police their customers still needs to go on an 'downgraded' status. Basically the accreditation programs have to work hard to be as widely trusted as possible and provide information that is as accurate as possible. It is all about accountability, the accreditation service has to be accountable to both sides, senders AND receivers. > > As a receiver you get to choose whether to take any notice of > > it at all, or even that the accreditation is so widely abused > > that you will consider that advertising it reduces my reputation. > > That, too -- though it's probably a very silly policy... Or lacks an authentication component. That is the problem with Habeas. Sure the Haiku/DRM type approach would work for some applications, we use a similar scheme to police Siteseal, if someone uses the program without consent the robot sends out the writs with remarkably little human intervention (yes the provocations without fraudulent intent do get spotted). But in this application, against organized crime the haiku is useless and many people now have it at a negative score. > >> My impression is no e-mail domain admins want any centralized > >> authority or collection thereof to say they're allowed to send > >> mail. > > There's quite a difference between exactly-one "accreditation" > source and a potentially-large marketplace of "accreditation" > sources. Yep. the accreditation services differentiate themselves by being better (or not) at identifying spammers and discrediting them. Phill From owner-ietf-mxcomp Wed Mar 17 10:13:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HIDX21022580; Wed, 17 Mar 2004 10:13: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 i2HIDXZF022579; Wed, 17 Mar 2004 10:13:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HIDWwJ022573 for ; Wed, 17 Mar 2004 10:13:32 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.11/) with ESMTP id i2HIDaCQ001810; Wed, 17 Mar 2004 10:13:36 -0800 (PST) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 17 Mar 2004 10:13:36 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Gordon Fecyk'" , IETF MXCOMP Subject: RE: Accreditation NON-Proposal Date: Wed, 17 Mar 2004 10:13:28 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > I believe it's high time for assuming "negative > accreditation" and asking questions later. At this point internet email appears to be about 80% spam. I get about 1000 spam a day and about 200 legit emails of which perhaps 40 are sent directly to me rather than via mailing lists. The meaning I am attempting to attach to accreditation is that it is a statement provided by a third party. But I would ceetainly accept that we need to change the equation, assume all email guilty until proven innocent. Phill From owner-ietf-mxcomp Wed Mar 17 10:42:42 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HIgg9k025099; Wed, 17 Mar 2004 10:42: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 i2HIgg2n025098; Wed, 17 Mar 2004 10:42:42 -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 (srv1.pan-am.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HIgfn0025091 for ; Wed, 17 Mar 2004 10:42:42 -0800 (PST) (envelope-from gordonf@pan-am.ca) Subject: RE: Accreditation NON-Proposal Date: Wed, 17 Mar 2004 12:42:45 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA7DD@srv1.pan-am.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Accreditation NON-Proposal Thread-Index: AcQMS5HbW0QgWfMARaaYxhYPWOBYQgAAC9Lw From: "Gordon Fecyk" To: "IETF MXCOMP" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2HIggn0025093 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com] > > > I believe it's high time for assuming "negative > > accreditation" and asking questions later. > > The meaning I am attempting to attach to accreditation > is that it is a statement provided by a third party. OK, this is "gut feeling" but it is based on the experience I've ranted about before. I don't believe *implicitly* accepting statements from a third party, about accreditation, will be accepted by e-mail users or administrators. Explicitly accepting statements is different (ie: MAPS)[1] as that's the recipient deciding. I'd hate to cite Habeas as an example because I thought they were good people with good intentions, but they're the best one to cite as a third-party accreditation authority gone wrong. People trusted this third-party right until spammers started faking the Habeas headers and *getting away with it.* After that, people started using the headers for filtering as abusive e-mail. The only proof I can offer of this right now, is the noise in SPAM-L about Habeas and a couple of links from sites whose administrators are effectively flipping Habeas off: If you dig around in Google you'll find plenty of other examples. Search on "Habeas lawsuit". You could throw all kinds of cryptography behind a third party's accreditation but I see them subject to vulnerabilities of their own, along with export controls and so on. No less vulnerable than DNS, except domain admins control their own domain's DNS and can answer for many of the vulnerabilities, as opposed to waiting for the third party to fix theirs. > But I would certainly accept that we need to change the > equation, assume all email guilty until proven innocent. Agreed. Then it's a matter of how to prove innocence. For me, the sender (domain) demonstrating accountability is enough. I'd want that demonstrated by the sender (domain) and not by a third party however. [1] These are after-the-fact anti-spam as I've explained, the point is the receipient explicitly decides to use them. Only one major backbone used one of these things to block on their routers and I suspect they lost customers over it. But that's speculation. -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Wed Mar 17 11:04:01 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HJ416u026930; Wed, 17 Mar 2004 11:04:01 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2HJ41kA026929; Wed, 17 Mar 2004 11:04:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HJ41Ht026921 for ; Wed, 17 Mar 2004 11:04:01 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.11/) with ESMTP id i2HJ44dX028439; Wed, 17 Mar 2004 11:04:04 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 17 Mar 2004 11:04:04 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Gordon Fecyk'" , IETF MXCOMP Subject: RE: Accreditation NON-Proposal Date: Wed, 17 Mar 2004 11:04:00 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > The meaning I am attempting to attach to accreditation > > is that it is a statement provided by a third party. > > OK, this is "gut feeling" but it is based on the experience > I've ranted about > before. I don't believe *implicitly* accepting statements > from a third > party, about accreditation, will be accepted by e-mail users or > administrators. Explicitly accepting statements is different > (ie: MAPS)[1] as that's the recipient deciding. The recipient still decides here. Even if the recipient decides that they WAY they are going to decide is by allowing spam assasin and some sort of feedback loop to work out what the value should be. I don't like manual configuration alone, in most cases the accreditations will start out being 100% accurate indicators of the accredited party not being spam. The spammers will attack the service as they discover that it has credibility. So the measured quality is likely to drop over time, hence a constant re-evaluation is needed. > I'd hate to cite Habeas as an example because I thought they > were good people with good intentions, but they're the best one > to cite as a third-party accreditation authority gone wrong. > People trusted this third-party right > until spammers started faking the Habeas headers and *getting > away with it.* Absolutely, hence the relevance to this spec. Habeas did not fail because the idea is bad, it failled because it did not have an authentication component. Hence the relevance to MARID. We do NOT have to discuss the details of the accreditation concept here, they are not in scope. But it is important that the authentication concept be capable of supporting an accreditation use. Otherwise all this will do is to drive up demand for domain names. And nobody here would want that. Phill From owner-ietf-mxcomp Wed Mar 17 11:31:16 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HJVGut028846; Wed, 17 Mar 2004 11:31:16 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2HJVG5X028845; Wed, 17 Mar 2004 11:31:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.undergrid.net (mx2.undergrid.net [64.174.245.170]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HJVFqC028827 for ; Wed, 17 Mar 2004 11:31:15 -0800 (PST) (envelope-from Jeremy.Bouse@undergrid.net) Received: from TheOne.undergrid.net (root@theone.undergrid.net [192.168.112.30]) by mail.undergrid.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i2HJSNZE022949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 17 Mar 2004 11:28:24 -0800 Received: from TheOne.undergrid.net (undrgrid@localhost [127.0.0.1]) by TheOne.undergrid.net (8.12.11/8.12.11/Debian-3) with ESMTP id i2HJSNPH009201 for ; Wed, 17 Mar 2004 11:28:23 -0800 Received: (from undrgrid@localhost) by TheOne.undergrid.net (8.12.11/8.12.11/Debian-3) id i2HJSNfs009200 for ietf-mxcomp@imc.org; Wed, 17 Mar 2004 11:28:23 -0800 Date: Wed, 17 Mar 2004 11:28:22 -0800 From: "Jeremy T. Bouse" To: IETF MXCOMP Subject: Re: Accreditation NON-Proposal Message-ID: <20040317192822.GA9187@UnderGrid.net> Mail-Followup-To: IETF MXCOMP References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 . X-GPG-Debian: 1024D/29AB4CDD C745 FA35 27B4 32A6 91B3 3935 D573 D5B1 29AB 4CDD X-GPG-General: 1024D/62DBDF62 E636 AB22 DC87 CD52 A3A4 D809 544C 4868 62DB DF62 User-Agent: Mutt/1.5.5.1+cvs20040105i X-UnderGrid-MailScanner: Found to be clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I would tend to agree with the assumption that about 80% of the email traffic is spam given I just reset counters about 24 hours ago on my mail servers and about 40% has been flagged spam but most of the mail is mailing list traffic. Just looking at my inbox (mail not to the mailing lists I'm subscribed to) atleast 80% if not 90% is spam. The problem I see with accreditation is how much weight it will hold; much like any certification program available. If there is no weight given to it than what merit should it be given. As others had mentioned Habeas, I've been using the SWE mark in my outgoing emails for some months and it's only been of late that I've seen a rise of spammers using it illegally and getting through. Prior to this attack I hadn't seen any problems nor have I experienced any problems with my mail being delivered. I treat everything coming into my network as guilty until proven otherwise and haven't had any problems. I think that unfortunately that is the stance that has to be taken however to curb the digital pollution that I think in most ways is worse than the smog problems in major metros. Regards, Jeremy On Wed, Mar 17, 2004 at 10:13:28AM -0800, Hallam-Baker, Phillip wrote: > > > I believe it's high time for assuming "negative > > accreditation" and asking questions later. > > At this point internet email appears to be about 80% spam. > I get about 1000 spam a day and about 200 legit emails > of which perhaps 40 are sent directly to me rather than > via mailing lists. > > The meaning I am attempting to attach to accreditation > is that it is a statement provided by a third party. > > But I would ceetainly accept that we need to change the > equation, assume all email guilty until proven innocent. > > > Phill > From owner-ietf-mxcomp Wed Mar 17 11:36:53 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HJar5c029132; Wed, 17 Mar 2004 11:36: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 i2HJar1n029131; Wed, 17 Mar 2004 11:36:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HJaqJ9029125 for ; Wed, 17 Mar 2004 11:36:52 -0800 (PST) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id A4887E0495; Wed, 17 Mar 2004 14:36:55 -0500 (EST) Date: Wed, 17 Mar 2004 14:36:55 -0500 From: John Leslie To: Gordon Fecyk Cc: IETF MXCOMP Subject: Re: Accreditation NON-Proposal Message-ID: <20040317193655.GB38511@verdi> References: <700EEF5641B7E247AC1C9B82C05D125DA7DD@srv1.pan-am.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125DA7DD@srv1.pan-am.ca> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Gordon Fecyk wrote: >> From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com] > >> But I would certainly accept that we need to change the >> equation, assume all email guilty until proven innocent. I hope you mean that _recipients_ would assume this, as a matter of individual choice. > Agreed. Then it's a matter of how to prove innocence. For me, the > sender (domain) demonstrating accountability is enough. Ah, but what counts as "demonstrating accountability"? A lot of the largest ISPs have an mailbox, which even generates pleasant- sounding autoreplies, but there's considerable controversy whether abuse complaints are acted upon... > I'd want that demonstrated by the sender (domain) and not by a third > party however. I'm afraid I don't understand _how_ a sender you have no out-of-band contact with _could_ demonstrate this. Personally, I'd want multiple third-party evaluations of how responsive they are to reports. -- John Leslie From owner-ietf-mxcomp Wed Mar 17 14:29:41 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HMTfav056543; Wed, 17 Mar 2004 14:29: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 i2HMTfAV056541; Wed, 17 Mar 2004 14:29:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HMTe65056534 for ; Wed, 17 Mar 2004 14:29:40 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.11/) with ESMTP id i2HMTgfN011094 for ; Wed, 17 Mar 2004 14:29:42 -0800 (PST) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 17 Mar 2004 14:29:41 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: IETF MXCOMP Subject: Proof of Consent NON-Proposal Date: Wed, 17 Mar 2004 14:29:41 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C40C6F.56F292CE" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C40C6F.56F292CE Content-Type: text/plain; charset="iso-8859-1" following up the great success of my accreditation non-proposal that nobody wants to make a work item, here is a second. Again the relevance is that the existence of the concept affects the spec that MARID may produce. In this case however the point is to reduce the scope of the spec by eliminating a particularly problematic set of corner cases. Detailed discussion should take place on ASRG. One of the biggest headaches with any SPF/RMX like proposal is how to deal with a forwarding relationship. I.E Mail is send to alice@alumni.ardvark.com It is then forwarded to alice@homeisp.net The change of the email address in mid stream is problematic because it means that homeisp.net will be receiving the mail from the alumni.ardvark.com forwarder and not from the place it is expected to come from. I believe that an forwarding relationship of this type should only occur because the ultimate destination of the message intends to collect mail from the additional contact address whether it be mailing list or forwarding relationship. In other words alice should have to 'choose' to listen at that address in the first place. This is a consent relationship. One of the biggest net.problems to hit the blacklists was how to deal with outright malicious complaints about mailing list senders. At the FTC workshop Cindy Cohen described an organized campaign to get moveon.org blacklisted. People subscribed to the list simply so that they could report it to their ISP as spam. The problem is that even though Alice subscribed to the list the incomming email infrastructure does not know that this happened. I do not like he-said-she-said problems. This one is easy to deal with, simply attach a proof of consent to every message the forwarding relationship generates. The proof can be generated during the original subscription opt-in process. All we need to do to deploy this is to update the mailing list software C/R module and then update the spam filters. This is similar in concept to SRS but avoids the hokey address transformations which I think confuse the end user. Every time my wife sees something unusual in her email she demands a 30 minute consultation and an explanation of why it is happening. She does not accept the fact that it is futile to expect a computer whose fundamental operations are based on quantum mechanics to behave in a deterministic manner. 'Thats just the way the wave function collapsed today' is not considered acceptable. So I don't like specs that do things that might confuse end users. Phill ------_=_NextPart_000_01C40C6F.56F292CE Content-Type: text/plain; name="proofofconsent.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="proofofconsent.txt" P. Hallam- Baker = Internet Draft VeriSign Inc.=20 Document: draft-hallam-baker- March 2004=20 proofconsent-00.txt=20 Expires: October 2004 =20 =20 Proof of Consent Mechanism=20 =20 Status of this Memo=20 =20 This document is an Internet-Draft and is NOT offered in = accordance with Section 10 of RFC2026, and the author=20 does not provide the IETF with any rights other than to=20 publish as an Internet-Draft =20 =20 Internet-Drafts are working documents of the Internet=20 Engineering Task Force (IETF), its areas, and its=20 working groups. Note that other groups may also=20 distribute working documents as Internet-Drafts.=20 =20 Internet-Drafts are draft documents valid for a maximum=20 of six months and may be updated, replaced, or obsoleted = by other documents at any time. It is inappropriate to=20 use Internet-Drafts as reference material or to cite=20 them other than as "work in progress."=20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt =20 The list of Internet-Draft Shadow Directories can be=20 accessed at=20 http://www.ietf.org/shadow.html. =20 =20 Abstract=20 =20 We propose a mechanism Proof of Consent that allows an=20 email recipient to provide verifiable proof of = =91opt-in=92=20 consent to receive email. Proof of Consent may be used=20 to automatically whitelist email from mailing lists and=20 email forwarded from another email server.=20 =20 Proof of Consent is designed to require minimal state=20 maintenance by both the email sender and the recipient=20 and to be deployable with minimal impact on existing=20 email infrastructure.=20 =20 1. Requirements=20 =20 The Proof of Consent mechanism provides a verifiable and=20 revocable proof that a recipient consented to receive email = from a specified source. It is designed to address several=20 of the existing problems of maintaining mailing lists and=20 =0C other consent based bulk mail such as newsletters and=20 solicited advertisements.=20 =20 We note that other protocols such as Really Simple=20 Syndication (RSS) and Network News Transport Protocol=20 (NNTP) offer facilities that are similar to mailing lists=20 without the need for a proof of consent mechanism. Despite=20 the existence of these mechanisms email remains the most=20 commonly used means of obtaining data of this type and it=20 is appropriate to address these requirements in the context = of email mailing lists despite the existence of alternative = protocols that already meet them.=20 =20 1.1 Subscription Consent Problem=20 =20 The SMTP protocol does not provide a means to allow a mail=20 server receiving a message alleged to have been sent to a=20 mailing list message to determine whether it was solicited=20 or not.=20 =20 1.2 Reputation Attacks =20 =20 An SMTP mail server may be falsely accused of having sent=20 messages to a non-subscriber. =20 =20 As the situation currently stands there is no way to=20 determine the truth or falsehood of such allegations. A=20 party may even sign up for a newsletter with opposing views = so as to be able to complain about the messages sent and=20 hope to cause the mailing list to be put on a blacklist.=20 =20 Events of this type have occurred in connection with=20 mailing lists of every political persuasion. When=20 complaints are made about a blacklisting they are typically = met with further hearsay accusations that the accused was=20 =91notorious=92.=20 =20 1.3 Unsubscribe Problem=20 =20 Mailing list users often find it difficult to unsubscribe.=20 In many cases requests to be unsubscribed are sent to the=20 entire list.=20 =20 The un-subscription problem can be a serious problem when=20 an intermediary such as a mailing list gateway is involved. = =20 1.4 Abandoned Subscription Problem=20 =20 =0C Users often fail to unsubscribe from mailing lists, = causing=20 huge volumes of mail to accumulate unread in an unused=20 account or an unread mail folder. In some cases the=20 subscribed email account is also abandoned.=20 =20 Often a mail user will subscribe to a mailing list on a=20 speculative basis and find that they do not read the list=20 often.=20 =20 1.5 Abandoned List Problem=20 =20 Mailing lists are often created and then abandoned after a=20 period of time after falling into disuse. This can create=20 serious problems if a spammer after discovers an abandoned=20 list without an administrator and starts to send messages=20 to the list.=20 =20 1.6 Maintenance Problem=20 =20 The management of a high volume mailing list requires a=20 considerable amount of effort, largely because of the need=20 to manage the problems of subscribers who are unable to=20 unsubscribe, have abandoned subscriptions etc. Another=20 increasing concern for mailing list administrators is that=20 their lists may be blocked by blacklists, often through no=20 fault of their own due to reputation attacks.=20 =20 2. Deployment Constraints=20 =20 The deployed email infrastructure is the result of more=20 than twenty years of development, much of which has taken=20 place in an ad-hoc fashion. As such it is vital that any=20 proposal to change that infrastructure be compatible with=20 the infrastructure as deployed and not merely as it is=20 described in theoretical specifications.=20 =20 2.1 SMTP Deployment Limitations=20 =20 Many SMTP servers are poorly configured and perform=20 arbitrary and in many cases capricious modifications to=20 messages as they are transmitted.=20 =20 2.2 SMTP Client Limitations=20 =20 Adding features to SMTP clients is a slow process. The=20 features offered by mail readers have not changed=20 significantly in the past five years, basic principles of=20 mail delivery have been unchanged for almost ten years. As=20 =0C a result few end users are likely to upgrade their mail=20 client in order to be able to take advantage of a protocol=20 meeting the requirements described.=20 =20 2.3 Separate Servers for Incoming and Outgoing Mail=20 =20 Enterprises are increasingly using separate mail servers=20 for incoming and outgoing mail. Even if the end user=20 interacts with a single server it is likely that incoming=20 mail will be pre-processed by some form of mail proxy,=20 particularly if anti-spam filtering is being performed.=20 =20 2.4 Network Protocol Access Limitations=20 =20 Many ISPs limit or block completely use of certain Internet = protocols. These blocks may be imposed for a variety of=20 reasons that include preventing spam, service=20 differentiation and caprice.=20 =20 2.5 Existing Features Insufficiently Observed=20 =20 Many of the problems with mailing lists could be addressed=20 by simply deploying the existing proposals in [RFC2369].=20 These provide a mechanism that allows mailing lists to use=20 URIs to specify how users can perform functions unsubscribe = from a list.=20 =20 A header of particular interest in this specification is=20 the Mailing-List header that uniquely identifies a mailing=20 list.=20 =20 3. The Proof of Consent Protocol=20 =20 The chief deficiency in the email protocols with respect to = the requirements is that an incoming mail server has no=20 means of determining whether a recipient did legitimately=20 consent to opt-in. =20 =20 Most mailing list applications support the use of a=20 challenge/response protocol to verify subscription=20 requests. The mailing list sends the subscriber a challenge = token consisting of a string of characters. To confirm=20 subscription to the list the subscriber returns the token=20 to the mailing list.=20 =20 The Proof of Consent mechanism proposes the use of a second = token that is created by the subscriber=92s incoming mail=20 server and forwarded together with the challenge token to=20 =0C the mailing list. The mailing list then includes a copy = of=20 the token in every email message sent to provide the proof=20 that it was solicited.=20 =20 This mechanism minimizes the need for state maintenance at=20 each stage in the mail transfer protocol, avoiding the need = for additional per user records to be stored at either the=20 incoming or outgoing servers.=20 =20 3.1 Initialization=20 =20 The incoming mail server establishes a shared secret k. In=20 the case that there are multiple incoming servers the=20 shared secret may be established manually or by means of=20 some form of key agreement protocol using public key based=20 credentials.=20 =20 Once established, the shared secret is maintained for an=20 extended time period such as a year. Incoming mail servers=20 must keep a record of all shared secrets that have ever=20 been used and the validity intervals in which they were=20 used.=20 =20 3.2 Confirmation Code=20 =20 During the subscription process we establish a confirmation = code that is cryptographically bound to the mailing list=20 name, the recipient email address and the date of=20 subscription by means of the shared secret:=20 =20 Code =3D MAC (mailing-list, recipient, date)=20 =20 Where:=20 =20 list=20 The string the mailing list will use in the=20 Mailing-List header=20 recipient=20 The email address of the recipient=20 date=20 The day on which the subscription took place.=20 =20 Each message sent from the mailing list contains a=20 Confirmation-Code header as follows:=20 =20 Confirmation-Code: =20 =20 =0C The mailing list already needs to maintain a = per-subscriber=20 record of mailing addresses. The additional state required=20 to support the confirmation code protocol is negligible.=20 =20 We require the subscription date to be stored explicitly=20 for two reasons, first it requires the mailing list=20 administrator to take notice of the age of subscriptions,=20 secondly it allows the incoming mail server to reject mail=20 with a stale confirmation code that is many years old. This = allows a mail server to reject mail sent to a mailing list=20 that a previous holder of an account name subscribed to.=20 =20 The incoming mail server can authenticate a confirmation=20 code (but not the attached message) by means of the shared=20 secret. Note that it is not necessary for the MAC algorithm = to be standardized, it is sufficient for the sender and=20 receiver to use the same one.=20 =20 3.3 Subscription Process=20 =20 The confirmation code is generated during the subscription=20 process and communicated to the mailing list server.=20 =20 We assume that any subscription process involves a=20 confirmation process by means of an email callback loop=20 challenge. The incoming mail server detects a mailing list=20 request for subscription confirmation and causes it to be=20 redirected so that the appropriate confirmation code can be = added.=20 =20 The callback loop challenge contains a new header=20 constructed as follows:=20 =20 Challenge-Code: =20 =20 Where=20 mailing-list=20 The string the mailing list will use in the=20 Mailing-List header=20 recipient=20 The email address of the recipient=20 opaque=20 An opaque code defined by the mailing list=20 confirmation server to be used for confirmation=20 purposes.=20 =20 =0C If the user responds to the confirmation request the=20 appropriate challenge code is generated and forwarded to=20 the indicated address along with the opaque code to=20 establish that the user did intend to subscribe.=20 =20 3.4 Legacy Subscriptions=20 =20 The confirmation code protocol must support gradual=20 introduction. It must be possible for a mailing list to=20 deploy the protocol without having to re-subscribe existing = users. It would be advantageous if this can be achieved in=20 such a way that allows a mailing list administrator to be=20 able to deploy the protocol incrementally and still be able = to establish that unsolicited messages are never sent.=20 =20 When a mailing list server sends a message to a legacy=20 subscriber the confirmation-code header is still present=20 but only the date field is filled, the confirmation field=20 is absent. This alerts the incoming server to the fact that = the message is purported to be a legacy subscription.=20 =20 If the incoming server supports the confirmation code=20 protocol it may query the user to determine whether the=20 subscription is actually authorized and if so provide the=20 relevant confirmation code to the mailing list server to=20 avoid the need for subsequent authorizations. =20 =20 A similar procedure may be employed when the confirmation=20 code protocol is deployed on an existing incoming mail=20 server. In this case it is recommended that the service=20 provide some mechanism to allow the user to send=20 confirmation codes to a group of mailing lists at the same=20 time.=20 =20 Mailing list administrators may defend themselves against=20 malicious allegations by having a copy of the mailing list=20 signed by a digital notary at the time the protocol is=20 deployed. The signature format may be chosen in such a way=20 that validity of each entry in the list may be determined=20 independently without revealing any information about any=20 other list member. Various schemes suggest themselves=20 including use of Merkle hash trees or the XML Signature=20 manifest object. It is recommended that any mechanism=20 chosen use a random mask value within each entry to prevent = attackers from finding out that a specified party has=20 subscribed to a list.=20 =20 =0C This information could be made available through some = form=20 of protocol, however it is likely that requiring existing=20 users to re-subscribe will prove more attractive.=20 =20 3.5 Revocation of Confirmation Codes=20 =20 The mechanism described only provides for the authenticity=20 of subscription requests to be established. No assurance is = provided for un-subscription requests, nor is the protocol=20 easily modified to achieve this directly.=20 =20 The confirmation code is cryptographically bound to the=20 mailing list identifier. An incoming mail server or spam=20 filtering application can filter incoming mail on the basis = of the mailing list identifier. Although this requires the=20 service to maintain state the overhead is minimal and saves = considerable resources in the long run. A mailing list may=20 choose not to observe requests to unsubscribe but there is=20 no incentive to do so if the messages are unlikely to be=20 read.=20 =20 4. Security Considerations=20 =20 4.1 Replay Attack=20 =20 The consent to receive mechanism provides proof that the=20 recipient of an email message has consented to receive=20 messages from a specified source. It does not provide=20 definitive proof that a particular message originates from=20 the source specified.=20 =20 An attacker that obtains a consent token for a particular=20 recipient/sender combination can generate an arbitrary=20 volume of messages containing the token. =20 =20 This vulnerability is unlikely to represent a significant=20 risk in the context of spam mitigation. It is highly=20 unlikely that a spammer could obtain a sufficiently large=20 number of consent tokens to make bulk distribution of spam=20 through this mechanism feasible. =20 =20 The vulnerability may be eliminated through use of the=20 consent token mechanism in combination with an=20 authentication mechanism.=20 =20 References=20 =20 [RFC2369] http://www.ietf.org/rfc/rfc2369.txt =20 =0C =20 [ListSpec] http://www.nisto.com/listspec/ =20 =20 =0C ------_=_NextPart_000_01C40C6F.56F292CE-- From owner-ietf-mxcomp Wed Mar 17 14:59:49 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HMxnXE062398; Wed, 17 Mar 2004 14:59: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 i2HMxn9B062392; Wed, 17 Mar 2004 14:59:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HMxm25062386 for ; Wed, 17 Mar 2004 14:59:48 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2HN1Wd06004; Wed, 17 Mar 2004 15:01:33 -0800 Date: Wed, 17 Mar 2004 14:52:17 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1467023194.20040317145217@brandenburg.com> To: "Hallam-Baker, Phillip" CC: Ted Hardie , ietf-mxcomp@imc.org Subject: Re: Draft Charter milestone sequence In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Phillip, HBP> There is another way to avoid this, leave out the identity issue HBP> altogether. Please what it means to authenticate something, when there is no identity being authenticated. For starters, what is the authentication tied to? d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Wed Mar 17 15:10:13 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HNADqT064485; Wed, 17 Mar 2004 15:10: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 i2HNADwg064484; Wed, 17 Mar 2004 15:10:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HNADId064472 for ; Wed, 17 Mar 2004 15:10:13 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2HNHxd07778; Wed, 17 Mar 2004 15:18:00 -0800 Date: Wed, 17 Mar 2004 15:08:44 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <241529002.20040317150844@brandenburg.com> To: "Hallam-Baker, Phillip" CC: ietf-mxcomp@imc.org Subject: Re: Draft Charter milestone sequence In-Reply-To: <1467023194.20040317145217@brandenburg.com> References: <1467023194.20040317145217@brandenburg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dave, DC> Phillip, HBP>> There is another way to avoid this, leave out the identity issue HBP>> altogether. DC> Please what it means to authenticate something, when there is no DC> identity being authenticated. DC> For starters, what is the authentication tied to? sigh. re-reading _after_ posting is never pleasant. I meant: Please explain what it means to... d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Wed Mar 17 15:22:13 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HNMDgZ066847; Wed, 17 Mar 2004 15:22: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 i2HNMDbb066846; Wed, 17 Mar 2004 15:22:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.undergrid.net (mx2.undergrid.net [64.174.245.170]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HNMCrr066799 for ; Wed, 17 Mar 2004 15:22:12 -0800 (PST) (envelope-from Jeremy.Bouse@undergrid.net) Received: from TheOne.undergrid.net (root@theone.undergrid.net [192.168.112.30]) by mail.undergrid.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i2HNJZ9c032416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 17 Mar 2004 15:19:36 -0800 Received: from TheOne.undergrid.net (undrgrid@localhost [127.0.0.1]) by TheOne.undergrid.net (8.12.11/8.12.11/Debian-3) with ESMTP id i2HNJZVc009682 for ; Wed, 17 Mar 2004 15:19:35 -0800 Received: (from undrgrid@localhost) by TheOne.undergrid.net (8.12.11/8.12.11/Debian-3) id i2HNJYCA009681 for ietf-mxcomp@imc.org; Wed, 17 Mar 2004 15:19:34 -0800 Date: Wed, 17 Mar 2004 15:19:34 -0800 From: "Jeremy T. Bouse" To: IETF MXCOMP Subject: Re: Proof of Consent NON-Proposal Message-ID: <20040317231934.GA9631@UnderGrid.net> Mail-Followup-To: IETF MXCOMP References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 . X-GPG-Debian: 1024D/29AB4CDD C745 FA35 27B4 32A6 91B3 3935 D573 D5B1 29AB 4CDD X-GPG-General: 1024D/62DBDF62 E636 AB22 DC87 CD52 A3A4 D809 544C 4868 62DB DF62 User-Agent: Mutt/1.5.5.1+cvs20040105i X-UnderGrid-MailScanner: Found to be clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Mar 17, 2004 at 02:29:41PM -0800, Hallam-Baker, Phillip wrote: > following up the great success of my accreditation non-proposal that nobody > wants to make a work item, here is a second. > Having read both there might be a reason for that... > Again the relevance is that the existence of the concept affects the spec > that MARID may produce. In this case however the point is to reduce the > scope of the spec by eliminating a particularly problematic set of corner > cases. > > Detailed discussion should take place on ASRG. > > > One of the biggest headaches with any SPF/RMX like proposal is how to deal > with a forwarding relationship. I.E > > Mail is send to alice@alumni.ardvark.com > It is then forwarded to alice@homeisp.net > > The change of the email address in mid stream is problematic because it > means that homeisp.net will be receiving the mail from the > alumni.ardvark.com forwarder and not from the place it is expected to come > from. > Provided alumni.ardvark.com has implemented something like SRS along with SPF/RMX than this issue is completed negated provided homeisp.net also runs an SPF/RMX compliant system when receiving email. > > I believe that an forwarding relationship of this type should only occur > because the ultimate destination of the message intends to collect mail from > the additional contact address whether it be mailing list or forwarding > relationship. In other words alice should have to 'choose' to listen at that > address in the first place. > > This is a consent relationship. One of the biggest net.problems to hit the > blacklists was how to deal with outright malicious complaints about mailing > list senders. At the FTC workshop Cindy Cohen described an organized > campaign to get moveon.org blacklisted. People subscribed to the list simply > so that they could report it to their ISP as spam. > > The problem is that even though Alice subscribed to the list the incomming > email infrastructure does not know that this happened. > > I do not like he-said-she-said problems. This one is easy to deal with, > simply attach a proof of consent to every message the forwarding > relationship generates. The proof can be generated during the original > subscription opt-in process. > Honestly after reading everything and having ran several mailing lists I would think the easiest solution is to simple have the mailing list software sign and archive the original confirmation email which could be presented as proof. Clean, simple and much less headache than trying to implement a scheme like this. > All we need to do to deploy this is to update the mailing list software C/R > module and then update the spam filters. > Not really, as I read the proposal it would require updates to mailing lists as well as the MTA itself. This would not be as trivial a task as you make it out to be. You also mention later in the proposal that standardization of the MAC algorithm need not be done so long as sender and received use the same one which is doubtful to happen without standardization. > > This is similar in concept to SRS but avoids the hokey address > transformations which I think confuse the end user. Every time my wife sees > something unusual in her email she demands a 30 minute consultation and an > explanation of why it is happening. She does not accept the fact that it is > futile to expect a computer whose fundamental operations are based on > quantum mechanics to behave in a deterministic manner. 'Thats just the way > the wave function collapsed today' is not considered acceptable. So I don't > like specs that do things that might confuse end users. > > Phill > I'm not sure where you're coming with this arguement of SRS as SRS modifies the Return-path: not the From: so it should be nominally visible to a novice that would have trouble grasping it. My nearly computer illiterate girlfriend has no problems with the fact my mail servers use SRS as it's almost completly invisible to her. I just don't follow the logic you're trying to present. Another point you fail to acknowledge is that most mailing list software already does actions similar to SRS with VERP when it sends the mail out for delivery to the subscribers. Are you than trying to say that VERP is any less confusing than SRS which follow a similar principle but add a cryptographic verfication hash? I find SRS far more verfiable than VERP by any standard. Regards, Jeremy From owner-ietf-mxcomp Wed Mar 17 15:33:41 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HNXeAN068865; Wed, 17 Mar 2004 15:33: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 i2HNXe0F068864; Wed, 17 Mar 2004 15:33:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HNXeRv068858 for ; Wed, 17 Mar 2004 15:33:40 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.11/) with ESMTP id i2HNU4u7005937; Wed, 17 Mar 2004 15:32:45 -0800 (PST) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 17 Mar 2004 15:24:47 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Dave Crocker'" , "Hallam-Baker, Phillip" Cc: ietf-mxcomp@imc.org Subject: RE: Draft Charter milestone sequence Date: Wed, 17 Mar 2004 15:24:45 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > DC> Please what it means to authenticate something, when > there is no > DC> identity being authenticated. > > DC> For starters, what is the authentication tied to? > > sigh. re-reading _after_ posting is never pleasant. > > I meant: Please explain what it means to... I want to authenticate the purported originating email address whether that be envelope or data FROM, Reply-To, Sender or whatever. In terms of bare authentication alone the only link that seems to me to add real value is authenticating the Data From: address. Authenticating fake Envelope From can have benefits if you also do something else: * If you authenticate Data From then also authenticating the envelope from may allow you to reject an impersonation spam earlier * If you combing the envelope from authentication with attributes that are tied to the authenticated domain, i.e. an accreditation by a third party. I don't think we need to set a hard and fast rule about what is 'legitimate' use here. The authentication part of the spec does not need to be normative so the identity does not need to be discussed. All that gets published in the DNS record is a note to say that as the owner of the domain phb.com the emails I send may be authenticated by the fact that they are consistent with the following characteristics: * The set of IP addresses of the outgoing edge servers * The use of specific cryptographic authentication enhancements (e.g. S/MIME signature under specified root) * That certain cryptographic security enhancements are always offered (e.g. STARTTLS is always offered) We can argue about which of these features should be defined in version 1 of the spec. But we don't have to get into the PKIX style philosophical arguments over what we mean by identity. Phill From owner-ietf-mxcomp Wed Mar 17 16:00:49 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2I00nVJ073756; Wed, 17 Mar 2004 16:00: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 i2I00nfJ073755; Wed, 17 Mar 2004 16:00:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2I00ns9073748 for ; Wed, 17 Mar 2004 16:00:49 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2I0A5d12272; Wed, 17 Mar 2004 16:10:05 -0800 Date: Wed, 17 Mar 2004 16:00:49 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1533844677.20040317160049@brandenburg.com> To: "Hallam-Baker, Phillip" CC: ietf-mxcomp@imc.org Subject: Re: Draft Charter milestone sequence In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Phillip, HBP> I want to authenticate the purported originating email address HBP> whether that be envelope or data FROM, Reply-To, Sender or HBP> whatever. Each of those contains a value with different semantics. The key word in your sentence is "whatever". It is exactly that lack of precision that will prevent reaching common, useful understanding and consensus. HBP> In terms of bare authentication alone the only link that seems HBP> to me to add real value is authenticating the Data From: address. I have not heard of a "Data From" address. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Wed Mar 17 16:43:21 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2I0hL8u082132; Wed, 17 Mar 2004 16:43:21 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2I0hLq1082131; Wed, 17 Mar 2004 16:43:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2I0hK45082123 for ; Wed, 17 Mar 2004 16:43:20 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.11/) with ESMTP id i2I0hMpj024973; Wed, 17 Mar 2004 16:43:22 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 17 Mar 2004 16:43:22 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Jeremy T. Bouse'" , IETF MXCOMP Subject: RE: Proof of Consent NON-Proposal Date: Wed, 17 Mar 2004 16:43:15 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Provided alumni.ardvark.com has implemented something like SRS > along with SPF/RMX than this issue is completed negated provided > homeisp.net also runs an SPF/RMX compliant system when > receiving email. SRS is not a work item here. Deployment has a major effect on infrastructure. I have to get my mail server to accept SRS 'munged' addresses. I don't think that SRS is viable for use by the non-geek community. > Honestly after reading everything and having ran several mailing > lists I would think the easiest solution is to simple have the mailing > list software sign and archive the original confirmation email which > could be presented as proof. Clean, simple and much less headache than > trying to implement a scheme like this. I tried working through that particular scheme. VeriSign offers high quality archival notary services... But then we are back to an accreditation problem. The big problem with mailing lists is that with the excpetion of a handful of very big commercial senders who are whitelisted everywhere (Yahoo, AOL) most are run on an ad-hoc volunteer basis. Unless you believe that people are going to continue to provide high quality, trustworthy accreditation services pro-bono indefinitely I can't see the market working here. The mailing lists are inevitably going to be the place where the most disputes turn up. I can't see Paul or anyone else volunteering to run mailing lists if they are going to have to pay for the privilege. However you work it the accreditation approach requires a lot of unfunded effort in the mailing list case. > > All we need to do to deploy this is to update the mailing > list software C/R > > module and then update the spam filters. > > > Not really, as I read the proposal it would require updates to > mailing lists as well as the MTA itself. No, only to the incomming mail filter MTA, which is usually going to be a spam guard anyway and to the mailing list. There are only three or four packages that are used by the vast majority of mailing lists. This is not a complex feature to implement. > This would not be as trivial a task as you make it out to be. A short while ago almost every mailing list on the net implemented the opt-in scheme in a 48 hour period > You also mention later in the proposal > that standardization of the MAC algorithm need not be done so long as > sender and received use the same one which is doubtful to > happen without standardization. No, it is not necessary. It is just a validation hack, the party that generates the token is the verifier. > Another point you fail to acknowledge is that most mailing list > software already does actions similar to SRS with VERP when > it sends the > mail out for delivery to the subscribers. Are you than trying to say > that VERP is any less confusing than SRS which follow a similar > principle but add a cryptographic verfication hash? I find > SRS far more > verfiable than VERP by any standard. But what does SRS prove? From owner-ietf-mxcomp Wed Mar 17 16:53:04 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2I0r48R083863; Wed, 17 Mar 2004 16:53: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 i2I0r4iF083862; Wed, 17 Mar 2004 16:53:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2I0r4t2083856 for ; Wed, 17 Mar 2004 16:53:04 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.11/) with ESMTP id i2I0r9hN027988; Wed, 17 Mar 2004 16:53:09 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 17 Mar 2004 16:53:09 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Dave Crocker'" , "Hallam-Baker, Phillip" Cc: ietf-mxcomp@imc.org Subject: RE: Draft Charter milestone sequence Date: Wed, 17 Mar 2004 16:53:01 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Each of those contains a value with different semantics. > > The key word in your sentence is "whatever". It is exactly > that lack of > precision that will prevent reaching common, useful understanding and > consensus. And I am saying that it does not matter in the slightest. That discussion of the semantics is unnecessary and counter-productive. Whatever the semantics of the headers are is already decided. Therefore there is absolutely nothing this group can do to change them. Far from it being essential to have a rigid formal model of the morass that is SMTP deployment it is essential to design a spec that is entirely indifferent to it. Everything the receiver does is non-normative. Phill From owner-ietf-mxcomp Wed Mar 17 17:52:27 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2I1qRPw095836; Wed, 17 Mar 2004 17:52:27 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2I1qRYS095835; Wed, 17 Mar 2004 17:52:27 -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 (srv1.pan-am.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2I1qPLH095828 for ; Wed, 17 Mar 2004 17:52:26 -0800 (PST) (envelope-from gordonf@pan-am.ca) Subject: RE: Accreditation NON-Proposal Date: Wed, 17 Mar 2004 19:52:31 -0600 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DAC4F@srv1.pan-am.ca> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C40C8B.AD0AA226" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Accreditation NON-Proposal content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Index: AcQMVzfBb0cwgd9NTFGtvN1t/wghDgAMjBR3 From: "Gordon Fecyk" Cc: "IETF MXCOMP" 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_001_01C40C8B.AD0AA226 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KFBsZWFzZSBmb3JnaXZlIHRoZSBIVE1MIC0gbm90IGF0IG15IG5vcm1hbCBkZXNrIGF0IHRoZSBt b21lbnQuKQ0KDQoJR29yZG9uIEZlY3lrIDxnb3Jkb25mQHBhbi1hbS5jYT4gd3JvdGU6DQoJPj4g RnJvbTogSGFsbGFtLUJha2VyLCBQaGlsbGlwIFttYWlsdG86cGJha2VyQHZlcmlzaWduLmNvbQ0K PG1haWx0bzpwYmFrZXJAdmVyaXNpZ24uY29tPiBdDQoJPiANCgk+PiBCdXQgSSB3b3VsZCBjZXJ0 YWlubHkgYWNjZXB0IHRoYXQgd2UgbmVlZCB0byBjaGFuZ2UgdGhlDQoJPj4gZXF1YXRpb24sIGFz c3VtZSBhbGwgZW1haWwgZ3VpbHR5IHVudGlsIHByb3ZlbiBpbm5vY2VudC4NCgkNCgk+ICAgIEkg aG9wZSB5b3UgbWVhbiB0aGF0IF9yZWNpcGllbnRzXyB3b3VsZCBhc3N1bWUgdGhpcywgYXMgYSBt YXR0ZXINCm9mDQoJaW5kaXZpZHVhbCBjaG9pY2UuDQoNCglZZXAuICBJZiB5b3UncmUgZ29pbmcg dG8gaG9sZCBtZSB0byAiVGhlIHJlY2lwaWVudCBkZWNpZGVzLCIgdGhlbg0KaG9sZCBtZSB0byBp dCBoZXJlLCB0b28uICBBcyBJJ3ZlIG5vdGVkLCBJIGRvbid0IHdhbnQgYSB0aGlyZC1wYXJ0eSB0 bw0KaW1wbGljaXRseSB0ZWxsIG1lIHRvIHRyZWF0IGFsbCBzZW5kZXJzIGFzIHN1c3BlY3QgdW50 aWwgcHJvdmVuIG90aGVyd2lzZS4NCgkNCgk+IFRoZW4gaXQncyBhIG1hdHRlciBvZiBob3cgdG8g cHJvdmUgaW5ub2NlbmNlLiAgRm9yIG1lLCB0aGUNCgk+IHNlbmRlciAoZG9tYWluKSBkZW1vbnN0 cmF0aW5nIGFjY291bnRhYmlsaXR5IGlzIGVub3VnaC4NCgkNCgk+ICAgIEFoLCBidXQgd2hhdCBj b3VudHMgYXMgImRlbW9uc3RyYXRpbmcgYWNjb3VudGFiaWxpdHkiPw0KDQoJR29vZCBxdWVzdGlv bi4gIE15IGlkZWEgb2YgZGVtb25zdHJhdGluZyBhY2NvdW50YWJpbGl0eSwgYXQgbGVhc3QgcGVy DQpkb21haW4sIGlzIHRoZSBkb21haW4gaWRlbnRpZnlpbmcgYSBzZW5kaW5nIGhvc3QgYXMgb25l IG9mIHRoZWlycy4gIEFsbCBvZg0KdGhlIHByb3Bvc2FscyB0byBkYXRlIHVzZSB0aGlzIGFwcHJv YWNoIHRvIGxldCBhIGRvbWFpbiBhZG1pbmlzdHJhdGlvbg0KZGVtb25zdHJhdGUgYWNjb3VudGFi aWxpdHkuICBUaGVyZSBtYXkgYmUgYmV0dGVyIHdheXMsIHdoaWNoIGlzIHdoYXQgSQ0KYmVsaWV2 ZSB3ZSdyZSBoZXJlIHRvIGZpbmQuDQoNCgk+IEEgbG90IG9mIHRoZQ0KCT4gbGFyZ2VzdCBJU1Bz IGhhdmUgYW4gPGFidXNlPiBtYWlsYm94LCB3aGljaCBldmVuIGdlbmVyYXRlcw0KcGxlYXNhbnQt DQoJPiBzb3VuZGluZyBhdXRvcmVwbGllcywgYnV0IHRoZXJlJ3MgY29uc2lkZXJhYmxlIGNvbnRy b3ZlcnN5IHdoZXRoZXINCgk+IGFidXNlIGNvbXBsYWludHMgYXJlIGFjdGVkIHVwb24uLi4NCg0K CVRoYXQncyBub3QgdmVyeSBhY2NvdW50YWJsZSwgYWdyZWVkLg0KDQoJDQoNCglJIHdhbnQgdG8g YmUgYWJsZSB0byBjb21wbGFpbiB0byBhIGRvbWFpbiBpbiB0aGUgZm9sbG93aW5nIGVzY2FsYXRp bmcNCm9yZGVyICh0aGlzIGlzIGp1c3QgbXkgcHJlZmVyZW5jZSk6IGFidXNlIG1haWxib3ggKGlm IGl0IGV4aXN0cyAtIGl0J3Mgbm90DQpyZXF1aXJlZCksIHBvc3RtYXN0ZXIgbWFpbGJveCwgd2hv aXMgY29udGFjdHMsIGhvc3RpbmcgSVNQLiAgRnJvbSB0aGVyZSBJDQp3YW50IHRvIHJlZnVzZSBt YWlsIGZyb20gdGhlIGRvbWFpbiBpZiBpdCdzIHVucmVzb2x2ZWQuDQoNCglJIGNhbid0IGRvIHRo YXQgaWYgdGhlIG1haWwgY2xhaW1pbmcgdG8gYmUgZnJvbSBhIGRvbWFpbiBpc24ndCByZWFsbHkN CmZyb20gdGhlIGRvbWFpbiwgb3IgaXNuJ3QgZnJvbSBhIHVzZXIgb3IgaG9zdCB0aGUgZG9tYWlu J3MgYWNjb3VudGFibGUgZm9yLg0KDQoJPiA+IEknZCB3YW50IHRoYXQgZGVtb25zdHJhdGVkIGJ5 IHRoZSBzZW5kZXIgKGRvbWFpbikgYW5kIG5vdCBieSBhDQp0aGlyZA0KCT4gPiBwYXJ0eSBob3dl dmVyLg0KCQ0KCT4gICAgSSdtIGFmcmFpZCBJIGRvbid0IHVuZGVyc3RhbmQgX2hvd18gYSBzZW5k ZXIgeW91IGhhdmUgbm8NCm91dC1vZi1iYW5kDQoJY29udGFjdCB3aXRoIF9jb3VsZF8gZGVtb25z dHJhdGUgdGhpcy4NCg0KCUknZCBsaWtlIHRvIHRoaW5rIFRIQVQncyBvbmUgb2YgdGhlIHJlYXNv bnMgd2UncmUgaGVyZS4gIFRvIHByb3ZpZGUgYQ0Kd2F5IGZvciBhbiBlbnRlcnByaXNlIHRvIGRl bW9uc3RyYXRlIGUtbWFpbCBhY2NvdW50YWJpbGl0eS4NCgkNCgk+ICBQZXJzb25hbGx5LCBJJ2Qg d2FudCBtdWx0aXBsZSB0aGlyZC1wYXJ0eSBldmFsdWF0aW9ucyBvZiBob3cNCglyZXNwb25zaXZl IHRoZXkgYXJlIHRvIDxhYnVzZT4gcmVwb3J0cy4NCg0KCVRoZSByZWNlaXZlciBkZWNpZGVzLCBh bmQgSSB3b3VsZCBuZXZlciBmYXVsdCB5b3UgZm9yIHdhbnRpbmcgdGhpcw0Ka2luZCBvZiBpbmZv cm1hdGlvbiBiZWZvcmUgYWNjZXB0aW5nIGEgZG9tYWluJ3MgbWFpbC4gIEknbSBub3QgY29tZm9y dGFibGUNCndpdGggaXQgYW5kIEkgYmVsaWV2ZSBpdCBoYXMgdG9vLWhpZ2ggYSBiYXJyaWVyIHRv IGVudHJ5IGZvciBzZW5kZXJzLiAgSWYgdGhlDQpkb21haW4gYWRtaW5pc3RyYXRpb24gY2FuIHRl bGwgbWUgZGlyZWN0bHkgSSdsbCB0cnVzdCB0aGF0IGZpcnN0LiBGaW5kaW5nIGENCndheSBmb3Ig dGhlbSB0byB0ZWxsIG1lLCBhZ2FpbiwgaXMgd2h5IEkgYmVsaWV2ZSB3ZSdyZSBoZXJlLg0KDQo= ------_=_NextPart_001_01C40C8B.AD0AA226 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPgo8IURPQ1RZUEUgSFRNTCBQVUJMSUMgIi0vL1czQy8vRFREIEhUTUwgMy4yLy9F TiI+CjxIVE1MPgo8SEVBRD4KCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMgRXhj aGFuZ2UgU2VydmVyIHZlcnNpb24gNi4wLjY0ODcuMSI+CjxUSVRMRT5SZTogQWNjcmVkaXRhdGlv biBOT04tUHJvcG9zYWw8L1RJVExFPgo8L0hFQUQ+CjxCT0RZIGRpcj1sdHI+CjxESVY+PEZPTlQg ZmFjZT0iQ291cmllciBOZXciIHNpemU9Mj4oUGxlYXNlIGZvcmdpdmUgdGhlIEhUTUwgLSBub3Qg YXQgbXkgbm9ybWFsIApkZXNrIGF0IHRoZSBtb21lbnQuKTwvRk9OVD48L0RJVj4KPEJMT0NLUVVP VEUgZGlyPWx0ciBzdHlsZT0iTUFSR0lOLVJJR0hUOiAwcHgiPgogIDxQPjxGT05UIGZhY2U9IkNv dXJpZXIgTmV3IiBzaXplPTI+R29yZG9uIEZlY3lrICZsdDtnb3Jkb25mQHBhbi1hbS5jYSZndDsg CiAgd3JvdGU6PEJSPiZndDsmZ3Q7IEZyb206IEhhbGxhbS1CYWtlciwgUGhpbGxpcCBbPC9GT05U PjxBIAogIGhyZWY9Im1haWx0bzpwYmFrZXJAdmVyaXNpZ24uY29tIj48Rk9OVCBmYWNlPSJDb3Vy aWVyIE5ldyIgCiAgc2l6ZT0yPm1haWx0bzpwYmFrZXJAdmVyaXNpZ24uY29tPC9GT05UPjwvQT48 Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgCiAgc2l6ZT0yPl08QlI+Jmd0OyZuYnNwOzxCUj4mZ3Q7 Jmd0OyBCdXQgSSB3b3VsZCBjZXJ0YWlubHkgYWNjZXB0IHRoYXQgd2UgbmVlZCAKICB0byBjaGFu Z2UgdGhlPEJSPiZndDsmZ3Q7IGVxdWF0aW9uLCBhc3N1bWUgYWxsIGVtYWlsIGd1aWx0eSB1bnRp bCBwcm92ZW4gCiAgaW5ub2NlbnQuPEJSPjxCUj4mZ3Q7ICZuYnNwOyZuYnNwOyBJIGhvcGUgeW91 IG1lYW4gdGhhdCBfcmVjaXBpZW50c18gd291bGQgCiAgYXNzdW1lIHRoaXMsIGFzIGEgbWF0dGVy IG9mPEJSPmluZGl2aWR1YWwgY2hvaWNlLjwvRk9OVD48L1A+CiAgPFA+PEZPTlQgZmFjZT0iQ291 cmllciBOZXciIHNpemU9Mj5ZZXAuJm5ic3A7IElmIHlvdSdyZSBnb2luZyB0byBob2xkIG1lIHRv IAogICJUaGUgcmVjaXBpZW50IGRlY2lkZXMsIiB0aGVuIGhvbGQgbWUgdG8gaXQgaGVyZSwgdG9v LiZuYnNwOyBBcyBJJ3ZlIG5vdGVkLCBJIAogIGRvbid0IHdhbnQgYSB0aGlyZC1wYXJ0eSB0byBp bXBsaWNpdGx5IHRlbGwgbWUgdG8gdHJlYXQgYWxsIHNlbmRlcnMgYXMgc3VzcGVjdCAKICB1bnRp bCBwcm92ZW4gb3RoZXJ3aXNlLjxCUj48QlI+Jmd0OyZuYnNwO1RoZW4gaXQncyBhIG1hdHRlciBv ZiBob3cgdG8gcHJvdmUgCiAgaW5ub2NlbmNlLiZuYnNwOyBGb3IgbWUsIHRoZTxCUj4mZ3Q7IHNl bmRlciAoZG9tYWluKSBkZW1vbnN0cmF0aW5nIAogIGFjY291bnRhYmlsaXR5IGlzIGVub3VnaC48 QlI+PEJSPiZndDsgJm5ic3A7Jm5ic3A7IEFoLCBidXQgd2hhdCBjb3VudHMgYXMgCiAgImRlbW9u c3RyYXRpbmcgYWNjb3VudGFiaWxpdHkiPzwvRk9OVD48L1A+CiAgPFA+PEZPTlQgZmFjZT0iQ291 cmllciBOZXciIHNpemU9Mj5Hb29kIHF1ZXN0aW9uLiZuYnNwOyBNeSBpZGVhIG9mIAogIGRlbW9u c3RyYXRpbmcgYWNjb3VudGFiaWxpdHksIGF0IGxlYXN0IHBlciBkb21haW4sIGlzIHRoZSBkb21h aW4gaWRlbnRpZnlpbmcgYSAKICBzZW5kaW5nIGhvc3QgYXMgb25lIG9mIHRoZWlycy4mbmJzcDsg QWxsIG9mIHRoZSBwcm9wb3NhbHMgdG8gZGF0ZSB1c2UgdGhpcyAKICBhcHByb2FjaCB0byBsZXQg YSBkb21haW4gYWRtaW5pc3RyYXRpb24gZGVtb25zdHJhdGUgYWNjb3VudGFiaWxpdHkuJm5ic3A7 IAogIFRoZXJlIG1heSBiZSBiZXR0ZXIgd2F5cywgd2hpY2ggaXMgd2hhdCBJIGJlbGlldmUgd2Un cmUgaGVyZSB0byAKICBmaW5kLjwvRk9OVD48L1A+CiAgPFA+PEZPTlQgZmFjZT0iQ291cmllciBO ZXciIHNpemU9Mj4mZ3Q7Jm5ic3A7QSBsb3Qgb2YgdGhlPEJSPiZndDsgbGFyZ2VzdCBJU1BzIAog IGhhdmUgYW4gJmx0O2FidXNlJmd0OyBtYWlsYm94LCB3aGljaCBldmVuIGdlbmVyYXRlcyBwbGVh c2FudC08QlI+Jmd0OyBzb3VuZGluZyAKICBhdXRvcmVwbGllcywgYnV0IHRoZXJlJ3MgY29uc2lk ZXJhYmxlIGNvbnRyb3ZlcnN5IHdoZXRoZXI8QlI+Jmd0OyBhYnVzZSAKICBjb21wbGFpbnRzIGFy ZSBhY3RlZCB1cG9uLi4uPC9GT05UPjwvUD4KICA8UD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIg c2l6ZT0yPlRoYXQncyBub3QgdmVyeSBhY2NvdW50YWJsZSwgCiAgYWdyZWVkLjwvRk9OVD48L1A+ PEZPTlQgZmFjZT0iQ291cmllciBOZXciIHNpemU9Mj48L0ZPTlQ+PC9CTE9DS1FVT1RFPgo8QkxP Q0tRVU9URSBkaXI9bHRyIHN0eWxlPSJNQVJHSU4tUklHSFQ6IDBweCI+CiAgPFA+PEZPTlQgZmFj ZT0iQ291cmllciBOZXciIHNpemU9Mj5JIHdhbnQgdG8gYmUgYWJsZSB0byBjb21wbGFpbiB0byBh IGRvbWFpbiAKICBpbiB0aGUgZm9sbG93aW5nIGVzY2FsYXRpbmcgb3JkZXIgKHRoaXMgaXMganVz dCBteSBwcmVmZXJlbmNlKTogYWJ1c2UgbWFpbGJveCAKICAoaWYgaXQgZXhpc3RzIC0gaXQncyBu b3QgcmVxdWlyZWQpLCBwb3N0bWFzdGVyIG1haWxib3gsIHdob2lzIGNvbnRhY3RzLCAKICBob3N0 aW5nIElTUC4mbmJzcDsgRnJvbSB0aGVyZSBJIHdhbnQgdG8gcmVmdXNlIG1haWwgZnJvbSB0aGUg ZG9tYWluIGlmIGl0J3MgCiAgdW5yZXNvbHZlZC48L0ZPTlQ+PC9QPgogIDxQPjxGT05UIGZhY2U9 IkNvdXJpZXIgTmV3IiBzaXplPTI+SSBjYW4ndCBkbyB0aGF0IGlmIHRoZSBtYWlsIGNsYWltaW5n IHRvIGJlIAogIGZyb20gYSBkb21haW4gaXNuJ3QgcmVhbGx5IGZyb20gdGhlIGRvbWFpbiwgb3Ig aXNuJ3QmbmJzcDtmcm9tIGEgdXNlciBvciBob3N0IAogIHRoZSBkb21haW4ncyBhY2NvdW50YWJs ZSBmb3IuPC9QPgogIDxQPiZndDsgJmd0OyBJJ2Qgd2FudCB0aGF0IGRlbW9uc3RyYXRlZCBieSB0 aGUgc2VuZGVyIChkb21haW4pIGFuZCBub3QgYnkgYSAKICB0aGlyZDxCUj4mZ3Q7ICZndDsgcGFy dHkgaG93ZXZlci48QlI+PEJSPiZndDsgJm5ic3A7Jm5ic3A7IEknbSBhZnJhaWQgSSBkb24ndCAK ICB1bmRlcnN0YW5kIF9ob3dfIGEgc2VuZGVyIHlvdSBoYXZlIG5vIG91dC1vZi1iYW5kPEJSPmNv bnRhY3Qgd2l0aCBfY291bGRfIAogIGRlbW9uc3RyYXRlIHRoaXMuPC9QPgogIDxQPkknZCBsaWtl IHRvIHRoaW5rJm5ic3A7VEhBVCdzJm5ic3A7b25lIG9mIHRoZSByZWFzb25zJm5ic3A7d2UncmUg CiAgaGVyZS4mbmJzcDsgVG8gcHJvdmlkZSBhIHdheSZuYnNwO2ZvciBhbiBlbnRlcnByaXNlJm5i c3A7dG8gZGVtb25zdHJhdGUgZS1tYWlsIAogIGFjY291bnRhYmlsaXR5LjxCUj48QlI+Jmd0OyZu YnNwOyBQZXJzb25hbGx5LCBJJ2Qgd2FudCBtdWx0aXBsZSB0aGlyZC1wYXJ0eSAKICBldmFsdWF0 aW9ucyBvZiBob3c8QlI+cmVzcG9uc2l2ZSB0aGV5IGFyZSB0byAmbHQ7YWJ1c2UmZ3Q7IHJlcG9y dHMuPC9QPgogIDxQPlRoZSByZWNlaXZlciBkZWNpZGVzLCBhbmQgSSB3b3VsZCBuZXZlciBmYXVs dCB5b3UgZm9yIHdhbnRpbmcgdGhpcyBraW5kIG9mIAogIGluZm9ybWF0aW9uIGJlZm9yZSBhY2Nl cHRpbmcgYSBkb21haW4ncyBtYWlsLiZuYnNwOyBJJ20gbm90IGNvbWZvcnRhYmxlIHdpdGggCiAg aXQgYW5kIEkgYmVsaWV2ZSBpdCBoYXMgdG9vLWhpZ2ggYSBiYXJyaWVyIHRvIGVudHJ5IGZvciBz ZW5kZXJzLiZuYnNwOyBJZiB0aGUgCiAgZG9tYWluIGFkbWluaXN0cmF0aW9uIGNhbiB0ZWxsIG1l IGRpcmVjdGx5IEknbGwgdHJ1c3QgdGhhdCBmaXJzdC4gRmluZGluZyBhIAogIHdheSBmb3IgdGhl bSB0byB0ZWxsIG1lLCBhZ2FpbiwgaXMgd2h5IEkgYmVsaWV2ZSB3ZSdyZSAKaGVyZS48L1A+PC9G T05UPjwvQkxPQ0tRVU9URT4KCjwvQk9EWT4KPC9IVE1MPg== ------_=_NextPart_001_01C40C8B.AD0AA226-- From owner-ietf-mxcomp Wed Mar 17 18:20:26 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2I2KQdw002432; Wed, 17 Mar 2004 18:20: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 i2I2KQ85002431; Wed, 17 Mar 2004 18:20:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2I2KPS7002423 for ; Wed, 17 Mar 2004 18:20:25 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.11/) with ESMTP id i2I2KVRl028740; Wed, 17 Mar 2004 18:20:31 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 17 Mar 2004 18:20:31 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Gordon Fecyk'" Cc: IETF MXCOMP Subject: RE: Accreditation NON-Proposal Date: Wed, 17 Mar 2004 18:20:26 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="utf-8" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > A lot of the > largest ISPs have an mailbox, which even generates pleasant- > sounding autoreplies, but there's considerable controversy whether > abuse complaints are acted upon... It is pretty easy to provide empirical measures. Number of mails sent to spampots for example. We have to think in terms of a phased approach. There are multiple spam problems. At the moment the criminal-spam problem swamps all the rest. I believe that the criminal spammers will fall at the first hurdle where they are asked to provide an address where legal process can be served. Then we can return to the problem of how to hold non-criminals accountable for the email they send. That is where the performance and consequences criteria are critical. Phill From owner-ietf-mxcomp Wed Mar 17 18:21:24 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2I2LO5t002630; Wed, 17 Mar 2004 18:21: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 i2I2LOL1002629; Wed, 17 Mar 2004 18:21:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2I2LNV6002619 for ; Wed, 17 Mar 2004 18:21:23 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.11/) with ESMTP id i2I2LTJV028932; Wed, 17 Mar 2004 18:21:29 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 17 Mar 2004 18:21:29 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Yakov Shafranovich'" , "Hallam-Baker, Phillip" Cc: "'Dave Crocker'" , ietf-mxcomp@imc.org Subject: RE: Draft Charter milestone sequence Date: Wed, 17 Mar 2004 18:21:29 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > By publishing MARID records in DNS, isn't the sender stating > facts about > a relationship between his domain/IP and some header? No, he is telling the world where his outgoing mail server sits. Nothing else. From owner-ietf-mxcomp Wed Mar 17 18:52:21 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2I2qLTl009237; Wed, 17 Mar 2004 18:52:21 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2I2qLWR009236; Wed, 17 Mar 2004 18:52:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2I2qKir009230 for ; Wed, 17 Mar 2004 18:52:20 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i2I2qRR7010429; Wed, 17 Mar 2004 18:52:27 -0800 (PST) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 17 Mar 2004 18:52:27 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "Hallam-Baker, Phillip" , "'Yakov Shafranovich'" Cc: "'ietf-mxcomp@imc.org'" Subject: RE: Draft Charter milestone sequence Date: Wed, 17 Mar 2004 18:52:25 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > By publishing MARID records in DNS, isn't the sender stating > > facts about > > a relationship between his domain/IP and some header? > > No, he is telling the world where his outgoing mail server sits. > > Nothing else. sorry for responding to my own post, but if people think that the sender should be talking about headers then we should allow the sender to choose which header they are going to talk about. "10.0.0.1 is authorized to send mail with an envelope From of *@example.com" "10.0.0.2 is authorized to send mail with a message From of *@example.com" "10.0.0.3 is authorized to send mail with a message Reply-to of *@example.com" Question is what is the recipient going to do here? They are going to choose for themselves what they want to look up, they might even look up all three. Now imagine what happens if we get an email from 10.0.0.3 and look up the address of the envelope from "example.com". Oh dear we don't have the right data here! But what is the chance that this is a forgery vs merely a misconfig? There clearly is a strong connection to example.com here so we are almost certain to accept the message REGARDLESS OF WHAT THE RFC SAYS. Now imagine that we decide to only allow one of those statements to be expressed. Say the Envelope From statement. But someone is writing a filter at the MUA level so they don't see the envelope from. Do they tell their pointy haired boss that the project is impossible or do they just ignore the spec? And that is why this argument is unnecessary. It makes no difference what we decide to do, the receivers will do their thing. That is why I believe the spec should consist of only two parts: 1) Normative: How to publish the IP addresses of your mail servers and other helpful information for receivers. 2) Non-Normative: Humble and respectful hints to developers suggesting ways that they might choose to make use of this data if they happen to be interested in listening to experience of others. The big ISPs are already doing this, to get on a whitelist you give them the IP addresses of your mail servers, not the details of your headers. Phill From owner-ietf-mxcomp Wed Mar 17 19:42:36 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2I3gaRN019512; Wed, 17 Mar 2004 19:42:36 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2I3gaXC019511; Wed, 17 Mar 2004 19:42:36 -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 (srv1.pan-am.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2I3gZ4p019505 for ; Wed, 17 Mar 2004 19:42:36 -0800 (PST) (envelope-from gordonf@pan-am.ca) Subject: RE: Draft Charter milestone sequence Date: Wed, 17 Mar 2004 21:42:42 -0600 MIME-Version: 1.0 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA7DE@srv1.pan-am.ca> Content-Type: text/plain; charset="iso-8859-1" X-MS-Has-Attach: X-MS-TNEF-Correlator: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Draft Charter milestone sequence Thread-Index: AcQMfFlNrGkqIxq8TaGsC8SvKsIzFAAHSjhQ From: "Gordon Fecyk" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2I3ga4p019506 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > HBP> In terms of bare authentication alone the only link that seems > HBP> to me to add real value is authenticating the Data From: address. > > I have not heard of a "Data From" address. I'm guessing he means "MAIL FROM:" aka: "Bounces-to" which is what it really means. Authenticating this alone avoids a pile of content screening issues, never mind saves a pile of bandwidth from never having to see the unathenticated message at all, and satisfies RFC 2821 7.1, specifically: [begin] Efforts to make it more difficult for users to set envelope return path and header "From" fields to point to valid addresses other than their own are largely misguided: they frustrate legitimate applications in which mail is sent by one user on behalf of another or in which error (or normal) replies should be directed to a special address. (Systems that provide convenient ways for users to alter these fields on a per-message basis should attempt to establish a primary and permanent mailbox address for the user so that Sender fields within the message data can be generated sensibly.) This specification does not further address the authentication issues associated with SMTP other than to advocate that useful functionality not be disabled in the hope of providing some small margin of protection against an ignorant user who is trying to fake mail. [end] I would rather not touch the message itself including headers and body. Deal with the envelope. This also partially satisfies "demonstrating accountability" as I was questioned on earlier. If a domain's prepared to handle bounces and receiving servers can send bounces "reliably"[1] to a sender domain, I consider that beginning to demonstrate accountability. [1] "reliably" depends on other things too, sure. -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Wed Mar 17 19:47:31 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2I3lVNI020655; Wed, 17 Mar 2004 19:47:31 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2I3lVMx020654; Wed, 17 Mar 2004 19:47:31 -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 (srv1.pan-am.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2I3lUqX020644 for ; Wed, 17 Mar 2004 19:47:30 -0800 (PST) (envelope-from gordonf@pan-am.ca) Subject: RE: Draft Charter milestone sequence Date: Wed, 17 Mar 2004 21:47:37 -0600 MIME-Version: 1.0 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA7DF@srv1.pan-am.ca> Content-Type: text/plain; charset="iso-8859-1" X-MS-Has-Attach: X-MS-TNEF-Correlator: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Draft Charter milestone sequence Thread-Index: AcQMj/HwNRKVw6AkQQ+zWzBW5Q7/KAAC10kQ From: "Gordon Fecyk" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2I3lVqX020648 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > By publishing MARID records in DNS, isn't the sender stating > > facts about > > a relationship between his domain/IP and some header? > > No, he is telling the world where his outgoing mail server sits. > > Nothing else. I missed the rest of the last post. But I'm inferring that whoever Phillip answered here is wondering if the sender's possibly exposing themselves or their affiliates. Yakov addressed this in the LMAP draft: 5.2. Network Infrastructure Publication of LMAP information results in a readily available list of IP addresses of hosts authorized to send messages associated with a domain. These lists yield information about the network structure, and business relationships, and presents hostile parties with a list of targets to attempt to compromise. However, such information is often already publicly accessible through other means. Anyone communicating with individuals at a domain may readily obtain this information, and share it with anyone else. Business relationships have been discovered, for example, prior to "official" public announcement, by examining DNS records. Nearly all such "private" information about network structure and relationships may therefore be described as already being readily available. If such information is to be kept secret, it is the users responsibility to send messages in such a way as to keep that information private. [end] -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Wed Mar 17 19:55:39 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2I3td0v022288; Wed, 17 Mar 2004 19:55: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 i2I3tdnJ022287; Wed, 17 Mar 2004 19:55:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2I3td6E022281 for ; Wed, 17 Mar 2004 19:55:39 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2I44td32554; Wed, 17 Mar 2004 20:04:55 -0800 Date: Wed, 17 Mar 2004 19:55:38 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <817919586.20040317195538@brandenburg.com> To: "Gordon Fecyk" CC: ietf-mxcomp@imc.org Subject: Re: Draft Charter milestone sequence In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125DA7DE@srv1.pan-am.ca> References: <700EEF5641B7E247AC1C9B82C05D125DA7DE@srv1.pan-am.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Gordon, >> I have not heard of a "Data From" address. GF> I'm guessing he means "MAIL FROM:" I can make guesses, too. Each of us can. Guessing what each of us means is not the way to develop protocols, because we are certain to discover, much later, that our guesses were wrong. We all need to start using precise, consistent language and we all need to use it the same way. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Wed Mar 17 19:58:16 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2I3wGt4022722; Wed, 17 Mar 2004 19:58:16 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2I3wGwE022721; Wed, 17 Mar 2004 19:58:16 -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 (srv1.pan-am.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2I3wFa4022713 for ; Wed, 17 Mar 2004 19:58:16 -0800 (PST) (envelope-from gordonf@pan-am.ca) Subject: RE: Draft Charter milestone sequence Date: Wed, 17 Mar 2004 21:58:22 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA7E1@srv1.pan-am.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Draft Charter milestone sequence Thread-Index: AcQMnOQcC8Qs5boBTEKXdJza6OZ2FgAACK1w From: "Gordon Fecyk" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2I3wGa4022715 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Guessing what each of us means is not the way to develop protocols, > because we are certain to discover, much later, that our guesses were > wrong. > > We all need to start using precise, consistent language and > we all need to use it the same way. The language is there. It's in the existing RFCs and it's in Miriam-Webster's. I agree we need to stick with it. OK, whoever posted that: What did "Data From" mean? -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Wed Mar 17 19:58:23 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2I3wMaX022751; Wed, 17 Mar 2004 19:58: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 i2I3wMfx022750; Wed, 17 Mar 2004 19:58:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2I3wMeR022744 for ; Wed, 17 Mar 2004 19:58:22 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.11/) with ESMTP id i2I3wTIG004521; Wed, 17 Mar 2004 19:58:29 -0800 (PST) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 17 Mar 2004 19:58:29 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Gordon Fecyk'" , ietf-mxcomp@imc.org Subject: RE: Draft Charter milestone sequence Date: Wed, 17 Mar 2004 19:58:26 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > never mind saves a pile of bandwidth from never having to see the > unathenticated message at all, and satisfies RFC 2821 7.1, > specifically: The paper in question was wrong. It completely ignores the fact that criminals are stealing over a million dollars a week by exploiting said loophole. The unstated 'other uses' can be dispensed with. From now on a message that says it comes from paypal had better come from paypal and absolutely nobody else. If the email specs were completely satisfactory we would not be in this mess in the first place. They are broken, the fact they were broken was studiously ignored, that is why there is spam and now phishing-spam. Phill From owner-ietf-mxcomp Wed Mar 17 20:08:47 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2I48kNx024115; Wed, 17 Mar 2004 20:08: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 i2I48kxi024114; Wed, 17 Mar 2004 20:08:46 -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 (srv1.pan-am.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2I48jg0024099 for ; Wed, 17 Mar 2004 20:08:46 -0800 (PST) (envelope-from gordonf@pan-am.ca) Subject: RE: Draft Charter milestone sequence Date: Wed, 17 Mar 2004 22:08:52 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA7E2@srv1.pan-am.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Draft Charter milestone sequence Thread-Index: AcQMnUbLkXIVysYPQv2hJbqAn9VuhQAAB8jA From: "Gordon Fecyk" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2I48kg0024107 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > never mind saves a pile of bandwidth from never having to see the > > unathenticated message at all, and satisfies RFC 2821 7.1, > > specifically: > > The paper in question was wrong. > > It completely ignores the fact that criminals are stealing over > a million dollars a week by exploiting said loophole. We're working to close that very loophole. I just believe it can be done without sacrificing the functionality of sending on behalf of another. Originally I wanted From: (RFC 822/2822)[1] verified alongside MAIL FROM: (RFC 821/2821) and matched. Reply-To: (RFC 822/2822) could serve the purpose of being able to send on behalf of another entity. Unfortunately, to do that requires receiving the entire message first and I believed saving the bandwidth was more important than matching the RFC 2822 headers to the RFC 2821 envelope. It happens that by not matching these, we happen to avoid removing what many (in my opinion) consider still useful functionality, not to mention avoid a pile of real world censorship/content-filtering problems. However, like any other functionality consistently abused, it will be taken away. The moment I start seeing MAIL FROM: sending From: service@paypal.com under an envelope-only verification system, I'll start matching headers to envelopes and bouncing mail. Baby steps, though. This is still new (well, newer than SMTP). [1] This is an attempt to cite the language I'm using so I'm clear on the meanings. -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Wed Mar 17 20:09:58 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2I49wqB024349; Wed, 17 Mar 2004 20:09: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 i2I49wYb024348; Wed, 17 Mar 2004 20:09:58 -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 (srv1.pan-am.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2I49vaj024341 for ; Wed, 17 Mar 2004 20:09:58 -0800 (PST) (envelope-from gordonf@pan-am.ca) Subject: RE: Proof of Consent NON-Proposal Date: Wed, 17 Mar 2004 22:10:04 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA7E3@srv1.pan-am.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Proof of Consent NON-Proposal Thread-Index: AcQMdwEZ4/I2WRBeTlWoTOmlahfH/QAJP/0A From: "Gordon Fecyk" To: "IETF MXCOMP" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2I49waj024343 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > My nearly > computer illiterate girlfriend has no problems with the fact my mail > servers use SRS as it's almost completly invisible to her. This was something I began to speak about before censoring myself on product names. End users know where the "send" button is. They don't care what happens to the mail while in transit as long as it reaches the intended recipient, or is notified if it doesn't.[1] Letting me veer off topic just for a moment... we could replace SMTP with a completely new transport that supported RFC 822/2822 style messages and I doubt end users would notice. I hope that happens one day, but I digress. In the meantime I don't believe anything we do here will affect end users until they start asking about the bounces. And then I believe it will be a matter of the mail provider (re-)explaining their terms of use to the clueless user. [1] The details of what to bounce on and how to express that, I believe, is also part of why we're here. -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Wed Mar 17 21:25:27 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2I5PRlg040391; Wed, 17 Mar 2004 21:25:27 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2I5PRGI040390; Wed, 17 Mar 2004 21:25:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2I5PQBa040384 for ; Wed, 17 Mar 2004 21:25:27 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.11/) with ESMTP id i2I5PX0W015950; Wed, 17 Mar 2004 21:25:34 -0800 (PST) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 17 Mar 2004 21:25:33 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Gordon Fecyk'" , ietf-mxcomp@imc.org Subject: RE: Draft Charter milestone sequence Date: Wed, 17 Mar 2004 21:25:32 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > We're working to close that very loophole. I just believe it > can be done > without sacrificing the functionality of sending on behalf of another. I think so too, but the receiver should know this happened, outlook showed the from line of your message as: owner-ietf-mxcomp@mail.imc.org; on behalf of; Gordon Fecyk [gordonf@pan-am.ca] I think that is the right approach. Use Sender: and From: by all means, but explain to the user what just happened. This would eliminate a lot of the email postcard problems. > Unfortunately, to do that > requires receiving the entire message first and I believed saving the > bandwidth was more important than matching the RFC 2822 > headers to the RFC 2821 envelope. These are computers, they work for cheap. They can check both if we tell them to. > It happens that by not matching these, we happen to avoid > removing what many (in my opinion) consider still useful > functionality, not to mention avoid a > pile of real world censorship/content-filtering problems. I think this is possible, we just need to explain a good way to do it right. Perhaps there is a non-normative part 3 to the spec, how to achieve the various functionalities people ask for in a manner that is compatible with authentication. > However, like any other functionality consistently abused, it > will be taken > away. The moment I start seeing MAIL > FROM: sending > From: service@paypal.com under an envelope-only verification > system, I'll > start matching headers to envelopes and bouncing mail. Baby > steps, though. This is still new (well, newer than SMTP). Perhaps an attribute that could appear in the paypal.com reocrd would be an attribute 'Frequent target of phishing attacks'. From owner-ietf-mxcomp Wed Mar 17 23:48:43 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2I7mgYk008467; Wed, 17 Mar 2004 23:48: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 i2I7mg5U008465; Wed, 17 Mar 2004 23:48:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.40]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2I7mg60008455 for ; Wed, 17 Mar 2004 23:48:42 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.50] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1B3sGf-0001p1-00; Thu, 18 Mar 2004 02:48:41 -0500 Received: from [68.244.163.173] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1B3sGd-0004uN-00; Thu, 18 Mar 2004 02:48:41 -0500 Message-ID: <40595437.1070406@solidmatrix.com> Date: Thu, 18 Mar 2004 02:48:07 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Gordon Fecyk CC: ietf-mxcomp@imc.org Subject: Re: Draft Charter milestone sequence References: <700EEF5641B7E247AC1C9B82C05D125DA7DF@srv1.pan-am.ca> In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125DA7DF@srv1.pan-am.ca> X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Gordon Fecyk wrote: >>>By publishing MARID records in DNS, isn't the sender stating >>>facts about >>>a relationship between his domain/IP and some header? >> >>No, he is telling the world where his outgoing mail server sits. >> >>Nothing else. > > > I missed the rest of the last post. But I'm inferring that whoever Phillip > answered here is wondering if the sender's possibly exposing themselves or > their affiliates. > > Yakov addressed this in the LMAP draft: > I think that was either Alan or John. Yakov From owner-ietf-mxcomp Wed Mar 17 23:47:41 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2I7lfKI007947; Wed, 17 Mar 2004 23:47: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 i2I7lfuD007946; Wed, 17 Mar 2004 23:47:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.40]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2I7leEp007928 for ; Wed, 17 Mar 2004 23:47:40 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.50] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1B3sFf-0001f1-00; Thu, 18 Mar 2004 02:47:39 -0500 Received: from [68.244.163.173] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1B3sFd-0004tD-00; Thu, 18 Mar 2004 02:47:39 -0500 Message-ID: <4059540D.1070300@solidmatrix.com> Date: Thu, 18 Mar 2004 02:47:25 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: "Hallam-Baker, Phillip" CC: "'ietf-mxcomp@imc.org'" Subject: Re: Draft Charter milestone sequence References: In-Reply-To: X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hallam-Baker, Phillip wrote: > That is why I believe the spec should consist of only > two parts: > > 1) Normative: How to publish the IP addresses of your mail servers > and other helpful information for receivers. > How does MTA MARK and DRIP fit in this? Also, what would be the scope of that "other helpful information"? > 2) Non-Normative: Humble and respectful hints to developers > suggesting ways that they might choose to make use of this > data if they happen to be interested in listening to > experience of others. > Sounds interesting. Yakov From owner-ietf-mxcomp Thu Mar 18 00:12:58 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2I8CwBO020281; Thu, 18 Mar 2004 00:12: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 i2I8CwW4020279; Thu, 18 Mar 2004 00:12:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.40]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2I8CsJK020234 for ; Thu, 18 Mar 2004 00:12:56 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.50] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1B3se5-0004ok-00; Thu, 18 Mar 2004 03:12:53 -0500 Received: from [68.244.163.173] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1B3se4-0005Vt-00; Thu, 18 Mar 2004 03:12:53 -0500 Message-ID: <405959F7.9080105@solidmatrix.com> Date: Thu, 18 Mar 2004 03:12:39 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: "Hallam-Baker, Phillip" CC: IETF MXCOMP Subject: Re: Accreditation NON-Proposal References: In-Reply-To: X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hallam-Baker, Phillip wrote: > Attached is a proposal for an accreditation mechanism based on the > existing DNS A record conventions but designed to allow extension to support > other approaches. > > I do not propose the draft as a work item IN THIS PARTICULAR GROUP. > However I do believe that the MARID proposal should provide at least the > same degree of support for accreditation as CallerID and SPF do. > Its kind of hard to follow the discussion in multiple forums, would the main ASRG list be more appropriate? Yakov From owner-ietf-mxcomp Thu Mar 18 00:14:24 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2I8EOsN021027; Thu, 18 Mar 2004 00:14: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 i2I8EOwJ021025; Thu, 18 Mar 2004 00:14:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.41]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2I8EN7m021014 for ; Thu, 18 Mar 2004 00:14:24 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.50] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1B3sfU-0005SM-00; Thu, 18 Mar 2004 03:14:20 -0500 Received: from [68.244.163.173] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1B3sfT-0005Xg-00; Thu, 18 Mar 2004 03:14:20 -0500 Message-ID: <40595A4E.4050800@solidmatrix.com> Date: Thu, 18 Mar 2004 03:14:06 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: "Hallam-Baker, Phillip" CC: IETF MXCOMP Subject: Re: Proof of Consent NON-Proposal References: In-Reply-To: X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hallam-Baker, Phillip wrote: > following up the great success of my accreditation non-proposal that nobody > wants to make a work item, here is a second. > I am assuming that we can expect both in the Internet draft archive soon? Also, if you want to make something a work item, just ask. > Again the relevance is that the existence of the concept affects the spec > that MARID may produce. In this case however the point is to reduce the > scope of the spec by eliminating a particularly problematic set of corner > cases. > > Detailed discussion should take place on ASRG. > Which is where I will make my comments. Yakov From owner-ietf-mxcomp Thu Mar 18 04:23:53 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2ICNrqE040680; Thu, 18 Mar 2004 04:23: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 i2ICNrI8040674; Thu, 18 Mar 2004 04:23:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [208.210.125.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2ICNqBW040657 for ; Thu, 18 Mar 2004 04:23:52 -0800 (PST) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [208.210.125.24]) by emerald.pobox.com (Postfix) with ESMTP id BD315132D3C for ; Thu, 18 Mar 2004 07:23:51 -0500 (EST) Received: by dumbo.pobox.com (Postfix, from userid 505) id 9D40A5D8; Thu, 18 Mar 2004 07:23:51 -0500 (EST) Date: Thu, 18 Mar 2004 07:23:51 -0500 From: Meng Weng Wong To: IETF MXCOMP Subject: onus on mailing lists Message-ID: <20040318122351.GI8016@dumbo.pobox.com> References: <20040317231934.GA9631@UnderGrid.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040317231934.GA9631@UnderGrid.net> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Mar 17, 2004 at 03:19:34PM -0800, Jeremy T. Bouse wrote: | | Honestly after reading everything and having ran several mailing | lists I would think the easiest solution is to simple have the mailing | list software sign and archive the original confirmation email which | could be presented as proof. Clean, simple and much less headache than | trying to implement a scheme like this. For the record, I want to follow this thought to its logical conclusion: all mailing list subscriptions will now need to be password protected, and you also have to archive every time a mailing list member changes their subscribed email address. Lazy unsubs are an interesting problem. Right now we have conventions: we have majordomo-style and listserv-style listname-request addresses or listname-unsubscribe addresses, but the mailing list world lacks a consistent machine-readable format for unsubscriptions. My first stab at addressing the problem of lazy unsubs was to define a modifier in the SPF record specifically for mailing list unsubscriptions. If MLMs publish something like "unsubscribe=%{listname}-unsubscribe@%{d}" then we can slide in another layer of intelligence. When the user presses "this is junk mail" the MUA can power up some state logic where the first click triggers an unsub message to the address, and after 24 hours a subsequent click can report an unsuccessful unsubscribe to a reputation service, etc. From owner-ietf-mxcomp Thu Mar 18 06:11:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IEBXd4058608; Thu, 18 Mar 2004 06:11: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 i2IEBXjL058607; Thu, 18 Mar 2004 06:11:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IEBXoa058600 for ; Thu, 18 Mar 2004 06:11:33 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.11/) with ESMTP id i2IEBX2T025854; Thu, 18 Mar 2004 06:11:33 -0800 (PST) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 18 Mar 2004 06:11:33 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Meng Weng Wong'" , IETF MXCOMP Subject: RE: onus on mailing lists Date: Thu, 18 Mar 2004 06:11:26 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Right now we have conventions: we have majordomo-style > and listserv-style listname-request addresses or listname-unsubscribe > addresses, but the mailing list world lacks a consistent > machine-readable format for unsubscriptions. Don't we have that in the mailing list headers? There was a proposal that added an unsubscribe header some time ago. List-Archive: List-Unsubscribe: List-ID: The problem here is that most email readers (correctly) do not fuzz up the user interface with irrelevant header info. So the headers do little to solve the clueless user problem. I think that after the core spec is written we should circle back and do some cleanup. I know the charter says enter FIN_WAIT in August, but if the group delivers the spec by then I think we have a pretty good case to recharter using the pinball precedent (you win, you get to play again). What concerned me here is that we might end up with a spec that has no extension sockets and hence be unable to add features in version 2 that are essential - accreditation is one example. I think that the conversation with Gordon has persuaded me we might need a flag to say 'I am a frequent target of impersonation, interpret the rules for my domain with extreme strictness'. I don't want to get into the anti-phishing stuff in detail here, it is an occasion when full disclosure is not the best move. Suffice it to say that we are anticipating attacks that are more sophisticated than sending out ten million criminal solicitations at the same time. The other concern was that we end up diving into the rat-hole of fixing the mailing list and forwarding problem when there are much better ways to address the same problem. Phill From owner-ietf-mxcomp Thu Mar 18 06:35:03 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IEZ3Nw059848; Thu, 18 Mar 2004 06:35: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 i2IEZ3Mm059847; Thu, 18 Mar 2004 06:35:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IEZ22w059838 for ; Thu, 18 Mar 2004 06:35:02 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.11/) with ESMTP id i2IEZ4wu010768 for ; Thu, 18 Mar 2004 06:35:04 -0800 (PST) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 18 Mar 2004 06:35:02 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: IETF MXCOMP Subject: Another tweak to eliminate objections - SRV records Date: Thu, 18 Mar 2004 06:34:59 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: One of the biggest complaints about RMX style proposals is that all outgoing mail has to be funnelled through the 'authorized' mail servers. Perhaps simplifying the means of configuring mail clients to do this would help eliminate some of the complaints. Fortunately we seem to already have a scheme that (almost) does this. We could describe SRV service points for _OUT_SMTP._TCP, _POP3._TCP, _OUT_NNTP._TCP, that would be used to configure the client automagically. All the user should need to do is to give the email address they want to use and the password for authentication. I think this is again something that should be deferred until we get to the 'reload' stage. Phill From owner-ietf-mxcomp Thu Mar 18 06:46:01 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IEk1Dp060783; Thu, 18 Mar 2004 06:46:01 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2IEk16X060782; Thu, 18 Mar 2004 06:46:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [208.210.125.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IEk0da060773 for ; Thu, 18 Mar 2004 06:46:00 -0800 (PST) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [208.210.125.24]) by emerald.pobox.com (Postfix) with ESMTP id 32A30132D3C for ; Thu, 18 Mar 2004 09:46:00 -0500 (EST) Received: by dumbo.pobox.com (Postfix, from userid 505) id 07B885CD; Thu, 18 Mar 2004 09:46:00 -0500 (EST) Date: Thu, 18 Mar 2004 09:46:00 -0500 From: Meng Weng Wong To: IETF MXCOMP Subject: sender vs author, channel vs object, designated sender vs crypto signatures Message-ID: <20040318144600.GJ8016@dumbo.pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At the risk of reopening the terminology debate, I want to put a question to the WG. I will provisionally define "sender" as that entity which: - injects the message into the mailstream, - receives bounces, and - is identified in the envelope MAIL FROM return path. I will provisionally define "author" as that entity which: - is responsible for the content of the message, - appears to the receiver in most MUAs, and - is identified in the header From:. The dichotomy corresponds to the "Channel" vs "Object" concepts, respectively, illustrated at page 5 of http://icauce.org/proceedings/Dave_Crocker(panel).pdf These definitions may not satisfy everyone but please accept the dichotomy as a working definition so I can get to my question. The question I want to ask is: I believe that channel/sender authentication/accountability corresponds naturally to designated sender methods, ie. "this MTA is authorized to originate mail with this envelope return-path." I believe that object/author authentication/accountability corresponds naturally to cryptographic signatures, ie. "this message and its associated headers including From/Sender/etc have been signed by this key which is traceable to this persistent identity at this keyserver / DNS record, etc". In short, I believe that the solution domain of designated sender schemes matches the problem domain of sender authentication, and that the solution domain of crytographic signatures matches the problem domain of author authentication. I would like to get a sense of whether my belief is generally shared by this WG. (As a matter of process I think WGs would be tremendously helped by a simple online polling type function as long as there is some protection from ballot-stuffing. But I don't want this thread to be about "what is rough consensus" --- please focus on the first question about the match between problem and solution domains :) From owner-ietf-mxcomp Thu Mar 18 06:50:08 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IEo8Xo061013; Thu, 18 Mar 2004 06:50: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 i2IEo82I061012; Thu, 18 Mar 2004 06:50:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [208.210.125.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IEo7Af061006 for ; Thu, 18 Mar 2004 06:50:08 -0800 (PST) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [208.210.125.24]) by emerald.pobox.com (Postfix) with ESMTP id BFCEF132D7C for ; Thu, 18 Mar 2004 09:50:09 -0500 (EST) Received: by dumbo.pobox.com (Postfix, from userid 505) id A32965EA; Thu, 18 Mar 2004 09:50:09 -0500 (EST) Date: Thu, 18 Mar 2004 09:50:09 -0500 From: Meng Weng Wong To: IETF MXCOMP Subject: Re: onus on mailing lists Message-ID: <20040318145009.GK8016@dumbo.pobox.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Mar 18, 2004 at 06:11:26AM -0800, Hallam-Baker, Phillip wrote: | | > Right now we have conventions: we have majordomo-style | > and listserv-style listname-request addresses or listname-unsubscribe | > addresses, but the mailing list world lacks a consistent | > machine-readable format for unsubscriptions. | | Don't we have that in the mailing list headers? There was a proposal | that added an unsubscribe header some time ago. | | List-Archive: | List-Unsubscribe: | List-ID: | Another problem is that because these headers are subject to forgery, the spammer can forge List-Unsubscribe: which fools the MUA; putting that metadata into the SPF record moves the announcement back into a space that's controlled by the purported sender domain. You only want to trust a List-Unsubscribe if the message itself passes RMX/DMP/LMAP/MXCOMP/MARID tests. From owner-ietf-mxcomp Thu Mar 18 06:57:07 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IEv7QT061471; Thu, 18 Mar 2004 06:57:07 -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 i2IEv7xg061470; Thu, 18 Mar 2004 06:57:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sklave3.rackland.de (sklave3.rackland.de [213.133.101.23]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IEv55p061459 for ; Thu, 18 Mar 2004 06:57:06 -0800 (PST) (envelope-from hadmut@danisch.de) Received: from www.rackland.de (localhost [127.0.0.1]) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) with SMTP id i2IEv1mN030630; Thu, 18 Mar 2004 15:57:01 +0100 Received: from 192.109.50.33 (SquirrelMail authenticated user hadmut) by www.rackland.de with HTTP; Thu, 18 Mar 2004 15:57:01 +0100 (CET) Message-ID: <49417.192.109.50.33.1079621821.squirrel@www.rackland.de> In-Reply-To: References: Date: Thu, 18 Mar 2004 15:57:01 +0100 (CET) Subject: Re: Another tweak to eliminate objections - SRV records From: "Hadmut Danisch" To: "Hallam-Baker, Phillip" Cc: "IETF MXCOMP" 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: > > One of the biggest complaints about RMX style proposals is that all > outgoing > mail has to be funnelled through the 'authorized' mail servers. > > Perhaps simplifying the means of configuring mail clients to do this would > help eliminate some of the complaints. Fortunately we seem to already have > a > scheme that (almost) does this. > > We could describe SRV service points for _OUT_SMTP._TCP, _POP3._TCP, > _OUT_NNTP._TCP, that would be used to configure the client automagically. > All the user should need to do is to give the email address they want to > use > and the password for authentication. Phil, I have already invented this. See my SCAF draft and the RMX++ slides. regards Hadmut From owner-ietf-mxcomp Thu Mar 18 07:00:58 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IF0wan061766; Thu, 18 Mar 2004 07:00: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 i2IF0wp0061765; Thu, 18 Mar 2004 07:00:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [208.210.125.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IF0vI3061759 for ; Thu, 18 Mar 2004 07:00:58 -0800 (PST) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [208.210.125.24]) by emerald.pobox.com (Postfix) with ESMTP id E357A132D6E for ; Thu, 18 Mar 2004 10:00:58 -0500 (EST) Received: by dumbo.pobox.com (Postfix, from userid 505) id 3BA7C5F5; Thu, 18 Mar 2004 10:00:58 -0500 (EST) Date: Thu, 18 Mar 2004 10:00:58 -0500 From: Meng Weng Wong To: IETF MXCOMP Subject: Re: sender vs author, channel vs object, designated sender vs crypto signatures Message-ID: <20040318150058.GL8016@dumbo.pobox.com> References: <20040318144600.GJ8016@dumbo.pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040318144600.GJ8016@dumbo.pobox.com> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Mar 18, 2004 at 09:46:00AM -0500, Meng Weng Wong wrote: | | I would like to get a sense of whether my belief is generally shared by | this WG. | Specifically, I would like to get a show of hands, so I can see how things break down along these lines: - yes, I agree with the described matchup of problem to solution domain. - no, I think designated sender should work for author information also. - mu, I disagree with your dichotomy and reject the question. - blort, I don't care about your dichotomy and will use this as a launching point for my totally new, off-topic proposal that involves a complicated next-generation protocol that rotates micropayments and challenge-response systems through the fourth dimension and uses an EBCDIC encoding for UTF8 and stops all spam as we know it as long as spammers play by my rules and everybody upgrades to IPv8-aware MTAs. :) From owner-ietf-mxcomp Thu Mar 18 07:07:23 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IF7N0c062056; Thu, 18 Mar 2004 07:07: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 i2IF7NHC062055; Thu, 18 Mar 2004 07:07: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 (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IF7M9G062048 for ; Thu, 18 Mar 2004 07:07:22 -0800 (PST) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.30) id 1B3z7E-0003R9-II for ietf-mxcomp@imc.org; Thu, 18 Mar 2004 09:07:24 -0600 To: "IETF MXCOMP" Subject: Re: onus on mailing lists References: From: wayne Content-Type: text/plain; charset=US-ASCII Date: Thu, 18 Mar 2004 09:07:24 -0600 In-Reply-To: (Phillip Hallam-Baker's message of "Thu, 18 Mar 2004 06:11:26 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (spfd: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In "Hallam-Baker, Phillip" writes: >> Right now we have conventions: we have majordomo-style >> and listserv-style listname-request addresses or listname-unsubscribe >> addresses, but the mailing list world lacks a consistent >> machine-readable format for unsubscriptions. > > Don't we have that in the mailing list headers? There was a proposal > that added an unsubscribe header some time ago. You mean the correct way to unsubscribe from a mailing list isn't to file a report with spamcop or the sender's abuse desk? Seriously though, people have been taught to never unsubscribe to spam because that just confirms to the spammer that they have a live email address. Combine that with most people's definition of spam being "spam is anything I don't like", and you have big problems for legitimate mailing lists. The proposal on proof of consent works between the sender and the receiver, but doesn't help folks like spamcop or abuse desks in determining if the email really was unsolicited. I have some ideas of how to solve this problem, but this is probably not the right forum to discuss the issue. -wayne From owner-ietf-mxcomp Thu Mar 18 07:24:30 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IFOUuc063022; Thu, 18 Mar 2004 07:24: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 i2IFOU0M063021; Thu, 18 Mar 2004 07:24:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IFOUMf063015 for ; Thu, 18 Mar 2004 07:24:30 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2IFXhd19800; Thu, 18 Mar 2004 07:33:43 -0800 Date: Thu, 18 Mar 2004 07:24:24 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <12710305727.20040318072424@brandenburg.com> To: Meng Weng Wong CC: IETF MXCOMP Subject: Re: sender vs author, channel vs object, designated sender vs crypto signatures In-Reply-To: <20040318144600.GJ8016@dumbo.pobox.com> References: <20040318144600.GJ8016@dumbo.pobox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Meng, MWW> I will provisionally define "sender" as that entity which: MWW> - injects the message into the mailstream, MWW> - receives bounces, and MWW> - is identified in the envelope MAIL FROM return path. Your definition requires that bounces always go to the address responsible for initial posting of a message. There are valid and useful scenarios that require the bounces address to differ from both RFC2822 From and RFC2822 Sender. Hence your definition requires breaking valid, useful and existing Internet mail services. MWW> I will provisionally define "author" as that entity which: ... You left out a definition to cover the peer MTA. It injects the message into the next-hop mailstream. Given the likely charter of this working group, we had better have a term to cover that role explicitly. And that's the reason I suggest we stop using the word sender entirely, except when qualified with "rfc2822". d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Thu Mar 18 07:33:57 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IFXvFV063576; Thu, 18 Mar 2004 07:33: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 i2IFXvWw063575; Thu, 18 Mar 2004 07:33:57 -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 (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IFXuJj063569 for ; Thu, 18 Mar 2004 07:33:56 -0800 (PST) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.30) id 1B3zWx-0003rB-Ba for ietf-mxcomp@imc.org; Thu, 18 Mar 2004 09:33:59 -0600 To: "IETF MXCOMP" Subject: Re: sender vs author, channel vs object, designated sender vs crypto signatures References: <20040318144600.GJ8016@dumbo.pobox.com> From: wayne Content-Type: text/plain; charset=US-ASCII Date: Thu, 18 Mar 2004 09:33:59 -0600 In-Reply-To: <20040318144600.GJ8016@dumbo.pobox.com> (Meng Weng Wong's message of "Thu, 18 Mar 2004 09:46:00 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (spfd: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <20040318144600.GJ8016@dumbo.pobox.com> Meng Weng Wong writes: > In short, I believe that the solution domain of designated sender > schemes matches the problem domain of sender authentication, and that > the solution domain of crytographic signatures matches the problem > domain of author authentication. > > I would like to get a sense of whether my belief is generally shared by > this WG. I tend to agree with this. -wayne From owner-ietf-mxcomp Thu Mar 18 07:34:46 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IFYkxf063615; Thu, 18 Mar 2004 07: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 i2IFYkbR063614; Thu, 18 Mar 2004 07:34:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from argon.connect.org.uk (argon.connectinternetsolutions.com [193.110.243.33]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IFYjN1063601 for ; Thu, 18 Mar 2004 07:34:46 -0800 (PST) (envelope-from jrk@merseymail.com) Received: from mmail by argon.connect.org.uk with local (connectmail/exim) id 1B3zXc-0007L9-AE; Thu, 18 Mar 2004 15:34:40 +0000 Subject: Re: sender vs author, channel vs object, designated sender vs crypto signatures To: "Dave Crocker" From: "Jon Kyme" Cc: "IETF MXCOMP" X-Mailer: [ConnectMail 3.13.0] X-connectmail-Originating-IP: 172.25.243.3 Message-Id: Date: Thu, 18 Mar 2004 15:34:40 +0000 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Save Crocker wrote: > > MWW> I will provisionally define "sender" as that entity which: > MWW> - injects the message into the mailstream, > MWW> - receives bounces, and > MWW> - is identified in the envelope MAIL FROM return path. > > Your definition requires that bounces always go to the address > responsible for initial posting of a message. > > There are valid and useful scenarios that require the bounces address to > differ from both RFC2822 From and RFC2822 Sender. Have you got a list of some such scenarios? Seriously, that would help. Or some reference that you can point me to. Regards, JK From owner-ietf-mxcomp Thu Mar 18 07:36:06 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IFa6p7063895; Thu, 18 Mar 2004 07:36: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 i2IFa6Dp063894; Thu, 18 Mar 2004 07:36:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IFa6a3063876 for ; Thu, 18 Mar 2004 07:36:06 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2IFjKd21184; Thu, 18 Mar 2004 07:45:20 -0800 Date: Thu, 18 Mar 2004 07:36:01 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <16010556602.20040318073601@brandenburg.com> To: "Gordon Fecyk" CC: ietf-mxcomp@imc.org Subject: Re: Draft Charter milestone sequence In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125DA7E2@srv1.pan-am.ca> References: <700EEF5641B7E247AC1C9B82C05D125DA7E2@srv1.pan-am.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Gordon, GF> Reply-To: (RFC 822/2822) could serve the purpose GF> of being able to send on behalf of another entity. That would change the 25+ year semantics of Reply-to. GF> The moment I start seeing MAIL FROM: sending GF> From: service@paypal.com under an envelope-only verification system, I'll GF> start matching headers to envelopes and bouncing mail. It is already done by legitimate subscription bulk mail senders. The redirection of bounce messages to special servers is a core part of serious bulk mail services. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Thu Mar 18 07:36:54 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IFasW6063930; Thu, 18 Mar 2004 07:36:54 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2IFasTo063929; Thu, 18 Mar 2004 07:36:54 -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 (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IFarHv063923 for ; Thu, 18 Mar 2004 07:36:53 -0800 (PST) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.30) id 1B3zZo-0003sg-9y for ietf-mxcomp@imc.org; Thu, 18 Mar 2004 09:36:56 -0600 To: "IETF MXCOMP" Subject: Re: sender vs author, channel vs object, designated sender vs crypto signatures References: <20040318144600.GJ8016@dumbo.pobox.com> <12710305727.20040318072424@brandenburg.com> From: wayne Content-Type: text/plain; charset=US-ASCII Date: Thu, 18 Mar 2004 09:36:56 -0600 In-Reply-To: <12710305727.20040318072424@brandenburg.com> (Dave Crocker's message of "Thu, 18 Mar 2004 07:24:24 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (spfd: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <12710305727.20040318072424@brandenburg.com> Dave Crocker writes: > > Your definition requires that [...] Dave, Those definitions were just so that people could understand the question that Meng posed. Sadly, you didn't answer the question... -wayne From owner-ietf-mxcomp Thu Mar 18 07:50:19 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IFoJij064740; Thu, 18 Mar 2004 07:50: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 i2IFoJp1064739; Thu, 18 Mar 2004 07:50:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [208.210.125.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IFoIs8064732 for ; Thu, 18 Mar 2004 07:50:19 -0800 (PST) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [208.210.125.24]) by emerald.pobox.com (Postfix) with ESMTP id AC4B4132D85 for ; Thu, 18 Mar 2004 10:50:20 -0500 (EST) Received: by dumbo.pobox.com (Postfix, from userid 505) id 857405E5; Thu, 18 Mar 2004 10:50:20 -0500 (EST) Date: Thu, 18 Mar 2004 10:50:20 -0500 From: Meng Weng Wong To: IETF MXCOMP Subject: Re: sender vs author, channel vs object, designated sender vs crypto signatures Message-ID: <20040318155020.GM8016@dumbo.pobox.com> References: <20040318144600.GJ8016@dumbo.pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040318144600.GJ8016@dumbo.pobox.com> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Mar 18, 2004 at 09:46:00AM -0500, Meng Weng Wong wrote: | | In short, I believe that the solution domain of designated sender | schemes matches the problem domain of sender authentication, and that | the solution domain of crytographic signatures matches the problem | domain of author authentication. | OK, let me rephrase. I believe that the solution domain of designated sender schemes matches the problem domain of RFC2821 MAIL FROM authentication, and that the solution domain of crytographic signatures matches the problem domain of RFC2822 header From: authentication. From owner-ietf-mxcomp Thu Mar 18 07:57:48 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IFvlUg065424; Thu, 18 Mar 2004 07:57: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 i2IFvlFM065423; Thu, 18 Mar 2004 07:57:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IFvlMG065417 for ; Thu, 18 Mar 2004 07:57:47 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2IG6ud23564; Thu, 18 Mar 2004 08:06:56 -0800 Date: Thu, 18 Mar 2004 07:57:37 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <743853478.20040318075737@brandenburg.com> To: "Jon Kyme" CC: "Dave Crocker" , "IETF MXCOMP" Subject: Re: sender vs author, channel vs object, designated sender vs crypto signatures In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon, >> There are valid and useful scenarios that require the bounces address to >> differ from both RFC2822 From and RFC2822 Sender. JK> Have you got a list of some such scenarios? Seriously, that would help. Or JK> some reference that you can point me to. Legitimate bulk-mail sending (for example, newsletters) is the current, major example. In fact, redirecting bounces to special servers is a key functionality for serious mail-sending services. In your MUA, you will probably find a Return-Path header. This contains the address that was in the RFC2821 Mail From field. It is frequently (usually?) different from both RFC2822 From and RFC2822 Sender. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Thu Mar 18 08:01:31 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IG1VH8065606; Thu, 18 Mar 2004 08:01:31 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2IG1Vhq065605; Thu, 18 Mar 2004 08:01:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IG1Ua3065599 for ; Thu, 18 Mar 2004 08:01:30 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2IGAdd23977; Thu, 18 Mar 2004 08:10:39 -0800 Date: Thu, 18 Mar 2004 08:01:19 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1199049623.20040318080119@brandenburg.com> To: Meng Weng Wong CC: IETF MXCOMP Subject: Re: sender vs author, channel vs object, designated sender vs crypto signatures In-Reply-To: <20040318155020.GM8016@dumbo.pobox.com> References: <20040318144600.GJ8016@dumbo.pobox.com> <20040318155020.GM8016@dumbo.pobox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Meng, MWW> I believe that the solution domain of designated sender schemes matches MWW> the problem domain of RFC2821 MAIL FROM authentication, and that the MWW> solution domain of crytographic signatures matches the problem domain of MWW> RFC2822 header From: authentication. The mail system use for RFC2821 Mail From has always been for bounces. As I've been noting, this address can and does legitimately differ from the standard array of RFC2822 addresses. Using Mail From to authenticate a role involved with authorship or posting (initial sending) will break those legitimate uses and will remove an important capability from Internet mail. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Thu Mar 18 08:03:39 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IG3daS065701; Thu, 18 Mar 2004 08:03: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 i2IG3dNH065700; Thu, 18 Mar 2004 08:03:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IG3Wgr065686 for ; Thu, 18 Mar 2004 08:03:38 -0800 (PST) (envelope-from aland@newgiles.nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id C42D8170BB for ; Thu, 18 Mar 2004 11:07:07 -0500 (EST) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Draft Charter milestone sequence In-Reply-To: Your message of "Wed, 17 Mar 2004 19:55:38 PST." <817919586.20040317195538@brandenburg.com> Date: Thu, 18 Mar 2004 11:07:07 -0500 Message-Id: <20040318160707.C42D8170BB@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dave Crocker wrote: > Guessing what each of us means is not the way to develop protocols, > because we are certain to discover, much later, that our guesses were > wrong. Which is, of course, why RFC's are written. The problem then is that the RFC's don't fully define the protocol under discussion. So we are left with guesses and ambiguities. It is somtimes possible to refer to "original intent", but not everyone has been involved in IETF for 20 years, and not everyone has access to the original authors of a protocol. The vast majority of the problems I've seen in ASRG involve people having strong opinions about the intent of vague documents. Unfortunately, I don't know how to fix either problem. > We all need to start using precise, consistent language and we all need > to use it the same way. We are suffering under the barrier of communicating via a shared language. Everyone "knows" what the words mean, and confusion ensues. "That depends on what the meaning of the word 'is' is". - well-known politician. Alan DeKok. From owner-ietf-mxcomp Thu Mar 18 08:12:48 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IGCmAl066985; Thu, 18 Mar 2004 08:12: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 i2IGCmcr066984; Thu, 18 Mar 2004 08:12:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [208.210.125.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IGClKE066972 for ; Thu, 18 Mar 2004 08:12:47 -0800 (PST) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [208.210.125.24]) by emerald.pobox.com (Postfix) with ESMTP id 62E08132D6E; Thu, 18 Mar 2004 11:12:49 -0500 (EST) Received: by dumbo.pobox.com (Postfix, from userid 505) id 3C65A5D6; Thu, 18 Mar 2004 11:12:49 -0500 (EST) Date: Thu, 18 Mar 2004 11:12:49 -0500 From: Meng Weng Wong To: Dave Crocker Cc: IETF MXCOMP Subject: Re: sender vs author, channel vs object, designated sender vs crypto signatures Message-ID: <20040318161249.GN8016@dumbo.pobox.com> References: <20040318144600.GJ8016@dumbo.pobox.com> <20040318155020.GM8016@dumbo.pobox.com> <1199049623.20040318080119@brandenburg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1199049623.20040318080119@brandenburg.com> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Mar 18, 2004 at 08:01:19AM -0800, Dave Crocker wrote: | | Using Mail From to authenticate a role involved with authorship or | posting (initial sending) will break those legitimate uses and will | remove an important capability from Internet mail. | I'm not sure what point you're making. Are you saying that the RFC2821 MAIL FROM should not be the subject of autentication at all? If that is not what you are saying, then we are talking at cross purposes. In my first post in this thread, I explicitly dissociated the concept of authorship from the MAIL FROM, so we are not in disagreement. From owner-ietf-mxcomp Thu Mar 18 08:20:21 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IGKL0m067615; Thu, 18 Mar 2004 08:20:21 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2IGKLRA067614; Thu, 18 Mar 2004 08:20:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [208.210.125.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IGKLnj067607 for ; Thu, 18 Mar 2004 08:20:21 -0800 (PST) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [208.210.125.24]) by emerald.pobox.com (Postfix) with ESMTP id 75906132D8D for ; Thu, 18 Mar 2004 11:20:22 -0500 (EST) Received: by dumbo.pobox.com (Postfix, from userid 505) id DD8AC5D6; Thu, 18 Mar 2004 11:20:22 -0500 (EST) Date: Thu, 18 Mar 2004 11:20:22 -0500 From: Meng Weng Wong To: IETF MXCOMP Subject: Re: sender vs author, channel vs object, designated sender vs crypto signatures Message-ID: <20040318162022.GO8016@dumbo.pobox.com> References: <20040318144600.GJ8016@dumbo.pobox.com> <20040318155020.GM8016@dumbo.pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040318155020.GM8016@dumbo.pobox.com> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Mar 18, 2004 at 10:50:20AM -0500, Meng Weng Wong wrote: | | OK, let me rephrase. | | I believe that the solution domain of designated sender schemes matches | the problem domain of RFC2821 MAIL FROM authentication, and that the | solution domain of crytographic signatures matches the problem domain of | RFC2822 header From: authentication. OK, let me rephrase again. 1) I believe that it is important to protect the RFC2821 MAIL FROM from illegitimate spoofing, independent of the RFC2822 header From:. 2) I believe that the most appropriate way to do so is with a designated sender scheme. 3) I believe that it is also important to protect the RFC2822 header From: from illegitimate spoofing, independent of the RFC2821 MAIL FROM. 4) I believe that the most appropriate way to do so is with a cryptographic signature system. 5) By "appropriate", I mean "engineering tradeoffs that require the least amount of total work to preserve existing desired functionality and inhibit undesired illegitimate spoofing." I assume that some of this work may have to be done by operators of newsletters, forwarder services, senders of web-generated email, etc. From owner-ietf-mxcomp Thu Mar 18 08:29:29 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IGTTAf068412; Thu, 18 Mar 2004 08:29: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 i2IGTTSP068411; Thu, 18 Mar 2004 08:29:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [208.210.125.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IGTSLl068404 for ; Thu, 18 Mar 2004 08:29:28 -0800 (PST) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [208.210.125.24]) by emerald.pobox.com (Postfix) with ESMTP id 0010F132D20 for ; Thu, 18 Mar 2004 11:29:30 -0500 (EST) Received: by dumbo.pobox.com (Postfix, from userid 505) id 2A1465D6; Thu, 18 Mar 2004 11:29:30 -0500 (EST) Date: Thu, 18 Mar 2004 11:29:30 -0500 From: Meng Weng Wong To: IETF MXCOMP Subject: Re: sender vs author, channel vs object, designated sender vs crypto signatures Message-ID: <20040318162930.GP8016@dumbo.pobox.com> References: <20040318144600.GJ8016@dumbo.pobox.com> <20040318155020.GM8016@dumbo.pobox.com> <20040318162022.GO8016@dumbo.pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040318162022.GO8016@dumbo.pobox.com> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Mar 18, 2004 at 11:20:22AM -0500, Meng Weng Wong wrote: | | 5) By "appropriate", I mean "engineering tradeoffs that require the | least amount of total work to preserve existing desired functionality | and inhibit undesired illegitimate spoofing." I assume that some of | this work may have to be done by operators of newsletters, forwarder | services, senders of web-generated email, etc. 5) By "appropriate", I mean "engineering tradeoffs that require the least amount of total work to preserve existing desired functionality and effectively inhibit undesired illegitimate spoofing in accordance with a deterministic algorithm which can be clearly specified for senders, intermediaries, and recipients such that conformance to an authentication/accountability standard can be objectively established and the gray areas moved into the domain of accreditation, reputation, and local policy." From owner-ietf-mxcomp Thu Mar 18 09:38:54 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IHcsjs073169; Thu, 18 Mar 2004 09:38:54 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2IHcs3m073168; Thu, 18 Mar 2004 09:38:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IHcsJ6073162 for ; Thu, 18 Mar 2004 09:38:54 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2IHm8d00575; Thu, 18 Mar 2004 09:48:08 -0800 Date: Thu, 18 Mar 2004 09:38:49 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <5810142822.20040318093849@brandenburg.com> To: Meng Weng Wong CC: IETF MXCOMP Subject: Re: sender vs author, channel vs object, designated sender vs crypto signatures In-Reply-To: <20040318161249.GN8016@dumbo.pobox.com> References: <20040318144600.GJ8016@dumbo.pobox.com> <20040318155020.GM8016@dumbo.pobox.com> <1199049623.20040318080119@brandenburg.com> <20040318161249.GN8016@dumbo.pobox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Meng, MWW> | Using Mail From to authenticate a role involved with authorship or MWW> | posting (initial sending) will break those legitimate uses and will MWW> | remove an important capability from Internet mail. MWW> I'm not sure what point you're making. Are you saying that the RFC2821 MWW> MAIL FROM should not be the subject of autentication at all? I'll assume that your later posts cover this concern. MWW> 1) I believe that it is important to protect the RFC2821 MAIL FROM from MWW> illegitimate spoofing, independent of the RFC2822 header From:. That phrasing sounds like an assertion that we can have productive discussion about. Even worse (...) it sounds like a pretty reasonable goal, since I am sure folks will agree that unauthorized use of bounces addresses is a serious problem. MWW> 2) I believe that the most appropriate way to do so is with a designated MWW> sender scheme. When the working group starts debating particular schemes for achieving the desired authentication (and maybe authorization) we can pursue of this scheme, and others, further. MWW> 3) I believe that it is also important to protect the RFC2822 header From: MWW> from illegitimate spoofing, independent of the RFC2821 MAIL FROM. Hard to argue with that view. (Although, of course, a community like this can argue about anything...) d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Thu Mar 18 09:51:03 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IHp3FK073810; Thu, 18 Mar 2004 09:51: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 i2IHp3jv073809; Thu, 18 Mar 2004 09:51:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IHp2WQ073803 for ; Thu, 18 Mar 2004 09:51:02 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2II0Cd01716; Thu, 18 Mar 2004 10:00:12 -0800 Date: Thu, 18 Mar 2004 09:50:53 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <569480615.20040318095053@brandenburg.com> To: "Alan DeKok" CC: ietf-mxcomp@imc.org Subject: Re: Draft Charter milestone sequence In-Reply-To: <20040318160707.C42D8170BB@mail.nitros9.org> References: Your message of "Wed, 17 Mar 2004 19:55:38 PST." <817919586.20040317195538@brandenburg.com> <20040318160707.C42D8170BB@mail.nitros9.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Alan, I'm not entirely sure I understand the direction of your comments, but here's an attempt to formulate a constructive response: 1. Specifications need to be as clear, precise and accurate as the folks writing them can make them, given the usual constraints of time and skill. 2. Later efforts to write specifications in the same technical arena must continue this effort. However these later documents must perform a difficult balancing act, between the history of the earlier documents, the reality of current practise and discussion, and the needs of future capabilities. No specification is ever perfect, either technical or linguistically. We all just do the best we can. And we revise things as we learn more. When we discover errors and ambiguities, later, we need to develop remedies. Right now, it is clear that the word "sender" is highly ambiguous. So we should stop using it, unless it is qualified enough to make the reference precise. What is also clear is that the world of anti-spam discussion is littered with vague terminology. This is not viable as a foundation for conducting standards discussions. A specification that is so ambiguous as to result in highly differential interpretations among different readers is a specification that fails. It is not possible to build interoperable implementations if everyone reads the specs differently. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Thu Mar 18 10:13:25 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IIDPm3075295; Thu, 18 Mar 2004 10:13: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 i2IIDPss075294; Thu, 18 Mar 2004 10:13:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (IDENT:root@ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IIDOQP075283 for ; Thu, 18 Mar 2004 10:13:24 -0800 (PST) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-19-105.client.comcast.net [24.6.19.105]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i2IIDOiL021867 for ; Thu, 18 Mar 2004 10:13:24 -0800 (PST) Received: by tethys.bitshift.org (Postfix, from userid 1001) id 1DDC822887; Thu, 18 Mar 2004 10:13:24 -0800 (PST) Date: Thu, 18 Mar 2004 10:13:24 -0800 From: "Mark C. Langston" To: IETF MXCOMP Subject: Re: sender vs author, channel vs object, designated sender vs crypto signatures Message-ID: <20040318181323.GO8629@bitshift.org> References: <20040318144600.GJ8016@dumbo.pobox.com> <20040318155020.GM8016@dumbo.pobox.com> <20040318162022.GO8016@dumbo.pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040318162022.GO8016@dumbo.pobox.com> User-Agent: Mutt/1.4.1i X-Uptime: 10:08AM up 275 days, 13:18, 4 users, load averages: 0.03, 0.01, 0.00 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Mar 18, 2004 at 11:20:22AM -0500, Meng Weng Wong wrote: > > 1) I believe that it is important to protect the RFC2821 MAIL FROM from > illegitimate spoofing, independent of the RFC2822 header From:. > > 3) I believe that it is also important to protect the RFC2822 header From: > from illegitimate spoofing, independent of the RFC2821 MAIL FROM. > Meng - Could you provide us with en example of what you view as legitimate spoofing of RFC2821 MAIL FROM and RFC2822 header From:? Do you believe that the pursuit of points 1 and 3 should override the preservation of these legitimate spoofs? -- Mark C. Langston Sr. Unix SysAdmin mark@bitshift.org mark@seti.org Systems & Network Admin SETI Institute http://bitshift.org http://www.seti.org From owner-ietf-mxcomp Thu Mar 18 10:19:08 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IIJ8HI075665; Thu, 18 Mar 2004 10:19: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 i2IIJ8Cw075664; Thu, 18 Mar 2004 10:19:08 -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 (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IIJ8oh075657 for ; Thu, 18 Mar 2004 10:19:08 -0800 (PST) (envelope-from andy@hxr.us) Received: from [10.131.244.249] ([::ffff:216.168.239.87]) (AUTH: LOGIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Thu, 18 Mar 2004 13:19:11 -0500 Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Cc: Ted Hardie , Scott Hollenbeck Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: MARID WG List Etiquette (Modified by Andrew Newton) Date: Wed, 17 Mar 2004 15:16:24 -0500 To: Marshall Rose X-Mailer: Apple Mail (2.613) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello all, The (soon-to-be) MARID working group has a very short schedule for accomplishing a very important task. So we, the potential chairs, request the following of all participants so that this list is a highly effective communication medium. o Be professional in your correspondence. o Remember that citation of research and documented experience is more helpful for positive discussions than citation of credentials. o Email does not always perfectly reflect proper human emotional tone, so please consider how others will receive your messages and be forgiving of messages you read. o While the business of the IETF is conducted in English, remember that not all participants are native English speakers. o Please consider traffic volume when using the MARID list. Instead of emitting or replying to many individual messages, consider using a summary format message, no more than three times a day. This is a guideline, not a rule. o Most of us have scars from past battles in other IETF working groups and related endeavors, however it is not generally constructive to re-enact glorious victories or resounding defeats of the past. o Finally, familiarize yourselves with BCP 83. We would also encourage participants to take advantage of the Jabber/XMPP chat room at marid@ietf.xmpp.org. The archives may be found at http://www.xmpp.org/ietf-logs/marid@ietf.xmpp.org/ . As a proposal, perhaps working group participants could meet there at 21:00 UTC (4pm EST, 1pm PST, 22:00 CET, 7am AU EST) on Monday of every other week starting March 22. -andy From owner-ietf-mxcomp Thu Mar 18 10:42:13 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IIgDkr077026; Thu, 18 Mar 2004 10:42: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 i2IIgDbb077025; Thu, 18 Mar 2004 10:42:13 -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.8) with ESMTP id i2IIg8AD077015 for ; Thu, 18 Mar 2004 10:42:08 -0800 (PST) (envelope-from aland@newgiles.nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id ED245170BB for ; Thu, 18 Mar 2004 13:45:53 -0500 (EST) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Draft Charter milestone sequence In-Reply-To: Your message of "Thu, 18 Mar 2004 09:50:53 PST." <569480615.20040318095053@brandenburg.com> Date: Thu, 18 Mar 2004 13:45:53 -0500 Message-Id: <20040318184553.ED245170BB@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dave Crocker wrote: > I'm not entirely sure I understand the direction of your comments, but > here's an attempt to formulate a constructive response: My comments were meant to indicate that because RFC's can be vague and ill-defined, any discussion about the RFC's or implementations is necessarily vague and ill-defined. While people try their best to write clear text, English is an imprecise language, and miscommunication can occur. If we had a complete state-machine specification of a protocol, we could use automated tools to validate the protocol, and much of these problems could be avoided, or dealt with via automatic tools. (e.g. the TFTP exponential explosion of packets problem could have been discovered through a protocol validator.) The problem is that such state machine descriptions often practically impossible. So we're stuck with specifications which are English text, incomplete, and thus open to interpretation. > 1. Specifications need to be as clear, precise and accurate as the folks > writing them can make them, given the usual constraints of time and > skill. I agree. But because they are written by humans, they will have human errors, leading to implementors making guesses about the authors intent. Such guesses lead to inter-operability problems, security flaws, etc. > 2. Later efforts to write specifications in the same technical arena > must continue this effort. However these later documents must perform a > difficult balancing act, between the history of the earlier documents, > the reality of current practise and discussion, and the needs of future > capabilities. I agree. The difficulty I have is with things *not* written in the RFC's. e.g. "The original design goals of SMTP." I can't find those anywhere. RFC 821 says: "The objective of Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently." but beyond that, the goals aren't stated explicitly. Yet arguments for/against anti-spam systems talk about fulfilling/countering the "original design goals" of SMTP. For the life of me, I can't figure out why. It's all magic that people pull out of the ether, with no documented foundation. It's unproductive, and causes miscommunication and religous wars. That's why my intentions are to focus on tangible items: machines in the network, fields in a protocol, etc. I try to shy away from discussing "original intent", because it is an intangible. So to the original subject of "guessing" at what people mean, those guesses are more likely to be correct when the discussion involves tangibles. > No specification is ever perfect, either technical or linguistically. > We all just do the best we can. And we revise things as we learn more. And we can change the accepted interpretation of fields in SMTP, if we so choose, and if that change doesn't break existing implementations. > A specification that is so ambiguous as to result in highly differential > interpretations among different readers is a specification that fails. > It is not possible to build interoperable implementations if everyone > reads the specs differently. Of course, wehich is what interops are for. SPF, et. al. are currently undergoing inter-operation tests in a live network. If the evidence there shows them to be useful and backwards compatible, then there's proof of inter-operability and running code, which indicates that publication as a standard may be possible. Alan DeKok. From owner-ietf-mxcomp Thu Mar 18 11:07:12 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IJ7CRF078876; Thu, 18 Mar 2004 11:07:12 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2IJ7C2c078875; Thu, 18 Mar 2004 11:07:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IJ7B1i078869 for ; Thu, 18 Mar 2004 11:07:11 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2IJGLd08446; Thu, 18 Mar 2004 11:16:21 -0800 Date: Thu, 18 Mar 2004 11:07:01 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <843844257.20040318110701@brandenburg.com> To: "Alan DeKok" CC: ietf-mxcomp@imc.org Subject: Re: Draft Charter milestone sequence In-Reply-To: <20040318184553.ED245170BB@mail.nitros9.org> References: Your message of "Thu, 18 Mar 2004 09:50:53 PST." <569480615.20040318095053@brandenburg.com> <20040318184553.ED245170BB@mail.nitros9.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Alan, >> 2. Later efforts to write specifications in the same technical arena ... AD> Yet arguments for/against anti-spam systems talk about AD> fulfilling/countering the "original design goals" of SMTP. Ahh. Now I understand. Yes, than could be a bit frustrating. In fact, I have not noticed that particular language and would certainly agree that, at most, it should be stated very judiciously. My own view is that we must pay attention to actual practise and we should try to impose new limitations with as much restraint as possible. Discussion about initial intent can be useful guidance for understanding a broader, unexplored scope, but I agree that it is dangerous to try to beat people up with that particular stick. (I've no doubt that my own postings have crossed the line, in this regard. It's always tempting to say something like "that's not what we had in mind", but no, it's not very helpful, except in the way all historical perspectives can be useful.) By contrast, I think that discussion about requirements and preferences for "human, group and organization communications via messaging" is entirely relevant. After all, that's the real functional domain of email and the technical work needs to conform to the human requirements, not vice versa. Yes, this type of discussion tends to be fuzzy, because most social and psychological discussions tend to be fuzzy, but the provide essential underpinnings to technical discussions. AD> Of course, wehich is what interops are for. SPF, et. al. are AD> currently undergoing inter-operation tests in a live network. If the AD> evidence there shows them to be useful and backwards compatible, We need to be careful about interpreting the results of interoperability testing. it shows that a protocol works between independent implementations. It does not show that the protocol is actually _useful_. Efficacy is demonstrated by real use, not by testing. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Thu Mar 18 12:46:36 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IKka4Q085697; Thu, 18 Mar 2004 12:46:36 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2IKka48085696; Thu, 18 Mar 2004 12:46:36 -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 (srv1.pan-am.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IKkY33085689 for ; Thu, 18 Mar 2004 12:46:35 -0800 (PST) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: Draft Charter milestone sequence Date: Thu, 18 Mar 2004 14:46:38 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA7E7@srv1.pan-am.ca> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 X-MS-TNEF-Correlator: Thread-Topic: Draft Charter milestone sequence Thread-Index: AcQM/rwhbVtUnxKiTm+BHr/NIqPP4QAKsylA From: "Gordon Fecyk" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2IKkZ33085691 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > GF> Reply-To: (RFC 822/2822) could serve the purpose > GF> of being able to send on behalf of another entity. > > That would change the 25+ year semantics of Reply-to. Another good reason to not match headers to envelopes. If we're going to play Lawyer with the letter of the RFCs just to continue this filibuster, then I'll stick with the letter of the RFCs. As I thought I explained umpteen times to no beneficial effect, I'm not interested in mucking with RFC 822/2822 content. > GF> The moment I start seeing MAIL > FROM: sending > GF> From: service@paypal.com under an envelope-only > verification system, I'll > GF> start matching headers to envelopes and bouncing mail. > > It is already done by legitimate subscription bulk mail senders. Yet another good reason to not match headers to envelopes. Can we stop now? -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Thu Mar 18 14:09:53 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IM9rf2092105; Thu, 18 Mar 2004 14:09: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 i2IM9rHe092104; Thu, 18 Mar 2004 14:09:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from moebius2.Space.Net (moebius2.Space.Net [195.30.1.100]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2IM9nVA092096 for ; Thu, 18 Mar 2004 14:09:51 -0800 (PST) (envelope-from maex@Space.Net) Received: (qmail 21281 invoked by uid 1013); 18 Mar 2004 22:09:48 -0000 Date: Thu, 18 Mar 2004 23:09:48 +0100 From: Markus Stumpf To: Meng Weng Wong Cc: IETF MXCOMP Subject: Re: onus on mailing lists Message-ID: <20040318220948.GV83770@Space.Net> References: <20040318145009.GK8016@dumbo.pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040318145009.GK8016@dumbo.pobox.com> User-Agent: Mutt/1.4.1i Organization: SpaceNet AG, Muenchen, Germany X-PGP-Fingerprint: 66 F3 75 79 01 D0 B8 5F 1A C7 77 88 4A B6 70 DF Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Mar 18, 2004 at 09:50:09AM -0500, Meng Weng Wong wrote: > | List-Archive: > | List-Unsubscribe: > | List-ID: We shouldn't forget about all the unsubscribe mechanisms via HTTP that tend to be more (l)user friendly. > Another problem is that because these headers are subject to forgery, > the spammer can forge > List-Unsubscribe: > which fools the MUA; putting that metadata into the SPF record moves > the announcement back into a space that's controlled by the purported > sender domain. You only want to trust a List-Unsubscribe if the message > itself passes RMX/DMP/LMAP/MXCOMP/MARID tests. I don't think I can follow you here? Well behaved MLMs use double-ACK for opt-in as well as opt-out. However I am aware that with this list I could probably unsubscribe all of you with a single batch job. IMHO the proposal should not make workarounds to try to fix security flaws in MLM software or their configuration. ezmlm e.g. shows (and I think at least majordomo can also do this) how you can use safe crypto cookies for confirmation of the subscribe and unsubscribe process. This can be securely done without any LMAP checking at all: new@example.net requests unsubscribe for joe@example.com MLM creates unique secret with a token only known to the MLM and sends it back to joe@example.com. It also has a upper limit on duration of validity Now the mailbox joe@example.com has a cookie that will only unsubscribe joe@example.com from one particular ML. You can even forward that cookie to your new account new@example.net and still use the cookie together with the address joe@example.com to unsubscribe joe@example.com (and none else). A LMAP check would IMHO even be counterproductive here. \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" From owner-ietf-mxcomp Thu Mar 18 15:03:36 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IN3aZx095148; Thu, 18 Mar 2004 15:03:36 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2IN3a0g095147; Thu, 18 Mar 2004 15:03:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IN3ZvM095141 for ; Thu, 18 Mar 2004 15:03:35 -0800 (PST) (envelope-from hardie@qualcomm.com) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i2IN3bvf024150 for ; Thu, 18 Mar 2004 15:03:37 -0800 (PST) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i2IN3Zvx013848 for ; Thu, 18 Mar 2004 15:03:36 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: Date: Thu, 18 Mar 2004 15:03:35 -0800 To: ietf-mxcomp@imc.org From: Ted Hardie Subject: Draft charter to be sent for public review Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Howdy, The IESG approved sending the MARID charter out for public review at today's meeting. The charter will now go to the IETF's main list for a two week discussion period, and the IETF will notify those organizations with which it has liaisons that it is considering this work. This is the normal second step in the progression of getting a working group charter approved. The only change to the charter since it was last sent to the list is the addition of a Technical Advisor from the DNS community; Rob Austein has agreed to take that role (and one or more additional advisors may be appointed). Adding an advisor (or advisors) here is meant to ensure that the group has early cross area review with the DNS community, which should help us avoid later delay. As I said early on, please do not wait for the charter to complete this process before working on the issues; though this step is necessary and issues may be raised, the most effective behavior at this point is to go forward as if the charter were already in force. My thanks to all of you for your contributions on the charter and to the work we're taking on. regards, Ted Hardie From owner-ietf-mxcomp Thu Mar 18 15:25:35 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2INPZ3U097753; Thu, 18 Mar 2004 15:25: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 i2INPZQE097752; Thu, 18 Mar 2004 15:25:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2INPYWl097743 for ; Thu, 18 Mar 2004 15:25:34 -0800 (PST) (envelope-from millenix@zemos.net) Received: from fda.zemos.net ([68.38.12.170]) by comcast.net (sccrmhc12) with ESMTP id <2004031823253301200n7kv1e>; Thu, 18 Mar 2004 23:25:33 +0000 Received: from zemos.net (phil [10.0.0.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fda.zemos.net (Postfix) with ESMTP id B6D1318682; Thu, 18 Mar 2004 18:01:17 -0500 (EST) Message-ID: <405A2A3D.9060507@zemos.net> Date: Thu, 18 Mar 2004 18:01:17 -0500 From: Philip Miller User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040312 Debian/1.6-3 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Markus Stumpf Cc: Meng Weng Wong , IETF MXCOMP Subject: Re: onus on mailing lists References: <20040318145009.GK8016@dumbo.pobox.com> <20040318220948.GV83770@Space.Net> In-Reply-To: <20040318220948.GV83770@Space.Net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Markus Stumpf wrote: > On Thu, Mar 18, 2004 at 09:50:09AM -0500, Meng Weng Wong wrote: >>Another problem is that because these headers are subject to forgery, >>the spammer can forge >> List-Unsubscribe: >>which fools the MUA; putting that metadata into the SPF record moves >>the announcement back into a space that's controlled by the purported >>sender domain. You only want to trust a List-Unsubscribe if the message >>itself passes RMX/DMP/LMAP/MXCOMP/MARID tests. > > I don't think I can follow you here? > Well behaved MLMs use double-ACK for opt-in as well as opt-out. > However I am aware that with this list I could probably unsubscribe all > of you with a single batch job. > > IMHO the proposal should not make workarounds to try to fix security > flaws in MLM software or their configuration. > > ezmlm e.g. shows (and I think at least majordomo can also do this) how you > can use safe crypto cookies for confirmation of the subscribe and unsubscribe > process. This can be securely done without any LMAP checking at all: > new@example.net requests unsubscribe for joe@example.com > MLM creates unique secret with a token only known to the MLM and > sends it back to joe@example.com. It also has a upper limit on > duration of validity > Now the mailbox joe@example.com has a cookie that will only unsubscribe > joe@example.com from one particular ML. You can even forward that cookie > to your new account new@example.net and still use the cookie together > with the address joe@example.com to unsubscribe joe@example.com (and > none else). > > A LMAP check would IMHO even be counterproductive here. You're thinking of checking the wrong message against LMAP criteria. It looks like you're thinking of validating the unsubscribe request, while Meng was talking about only trusting List-* headers in messages that have passed LMAP validation. Philip Miller From owner-ietf-mxcomp Thu Mar 18 16:30:19 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2J0UJrv002796; Thu, 18 Mar 2004 16:30: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 i2J0UJO7002795; Thu, 18 Mar 2004 16:30:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from moebius2.Space.Net (moebius2.Space.Net [195.30.1.100]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2J0UIUM002788 for ; Thu, 18 Mar 2004 16:30:18 -0800 (PST) (envelope-from maex@Space.Net) Received: (qmail 23158 invoked by uid 1013); 19 Mar 2004 00:30:23 -0000 Date: Fri, 19 Mar 2004 01:30:23 +0100 From: Markus Stumpf To: Philip Miller Cc: Markus Stumpf , Meng Weng Wong , IETF MXCOMP Subject: Re: onus on mailing lists Message-ID: <20040319003023.GC22179@Space.Net> References: <20040318145009.GK8016@dumbo.pobox.com> <20040318220948.GV83770@Space.Net> <405A2A3D.9060507@zemos.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <405A2A3D.9060507@zemos.net> User-Agent: Mutt/1.4.1i Organization: SpaceNet AG, Muenchen, Germany X-PGP-Fingerprint: 66 F3 75 79 01 D0 B8 5F 1A C7 77 88 4A B6 70 DF Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Mar 18, 2004 at 06:01:17PM -0500, Philip Miller wrote: > You're thinking of checking the wrong message against LMAP criteria. It > looks like you're thinking of validating the unsubscribe request, while > Meng was talking about only trusting List-* headers in messages that have > passed LMAP validation. Why? With double-ACK it is absolutely irrelevant, either of those. If this message would fake List-Unsubscribe for the ietf-asrg list, and I would hit unsubscribe, so what? I'd get a message from ietf-asrg to confirm the unsubscribe, and I would think "just a second, what?" and I would of course not send the ACK. If the list admin set up the list for unsubscribe without ACK it doesn't make a difference either, as I can probably right now unsubscribe all those who sent a message to this list from the list (it's just a grep in my mailbox and 3 lines of shell). So checking List-* against LMAP is not how to make mailing lists more secure and protect them from evil sent unsubscribes. And it should definitely not be done by a MTA. If someone wants he can even check Message-Ids against LMAP at user level ;-) \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" From owner-ietf-mxcomp Thu Mar 18 17:22:26 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2J1MQ6g006065; Thu, 18 Mar 2004 17:22: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 i2J1MQic006064; Thu, 18 Mar 2004 17:22:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [208.210.125.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2J1MPYs006056 for ; Thu, 18 Mar 2004 17:22:25 -0800 (PST) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [208.210.125.24]) by emerald.pobox.com (Postfix) with ESMTP id EDA34132D8D; Thu, 18 Mar 2004 20:22:28 -0500 (EST) Received: by dumbo.pobox.com (Postfix, from userid 505) id E097D599; Thu, 18 Mar 2004 20:22:28 -0500 (EST) Date: Thu, 18 Mar 2004 20:22:28 -0500 From: Meng Weng Wong To: "Mark C. Langston" Cc: IETF MXCOMP Subject: preserving desired functionality at the cost of changing implementations Message-ID: <20040319012228.GQ8016@dumbo.pobox.com> References: <20040318144600.GJ8016@dumbo.pobox.com> <20040318155020.GM8016@dumbo.pobox.com> <20040318162022.GO8016@dumbo.pobox.com> <20040318181323.GO8629@bitshift.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040318181323.GO8629@bitshift.org> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Mar 18, 2004 at 10:13:24AM -0800, Mark C. Langston wrote: | | On Thu, Mar 18, 2004 at 11:20:22AM -0500, Meng Weng Wong wrote: | > | > 1) I believe that it is important to protect the RFC2821 MAIL FROM from | > illegitimate spoofing, independent of the RFC2822 header From:. | > | > 3) I believe that it is also important to protect the RFC2822 header From: | > from illegitimate spoofing, independent of the RFC2821 MAIL FROM. | > | | Could you provide us with en example of what you view as legitimate | spoofing of RFC2821 MAIL FROM and RFC2822 header From:? Legitimate spoofing of RFC2821 MAIL FROM: - web-generated email (I log in to eBay and send mail using eBay's web UI to another eBay member; I want to see bounces.) - verbatim forwarding (a@a.com sends mail to b@b.com which forwards to c@c.com; if c@c.com is undeliverable, a@a.com should get the bounce.) Legitimate spoofing of RFC2822 header From: - My mother comes to me and asks me to email my father with a note to buy milk and eggs on his way home. I send mail using a mail client that lets me edit the From: header field so I change it to her email address; I put my email address in the Sender: header. | Do you believe that the pursuit of points 1 and 3 should override the | preservation of these legitimate spoofs? Yes; legitimate spoofing is by definition very hard to distinguish from illegitmate spoofing. ... all experience hath shewn, that mankind are more disposed to suffer, while evils are sufferable, than to right themselves by abolishing the forms to which they are accustomed. If breaking the current implementations of the above legitimate spoofing scenarios means we can solve the forgery problem, then I think we should break them, and expect the community to respond by working around. The functionality is what's important: in the future, I still want to be able to send mail to another eBay member and get the bounces if the mail is undeliverable. I want to be able to mail b@b.com and get the bounces if c@c.com is undeliverable. If SRS makes it into MTAs, the average email admin won't have to do anything more than upgrade his MTA --- and that's if he wants to support email forwarding. If he doesn't do forwarding, he doesn't have to do anything. I want to be able to send mail to my dad on behalf of my mother. (If per-user crypto is used, I may not be able to forge my mother's From: unless she gives me her passphrase and private key, so that changes behaviours a little bit. If per-domain crypto is used, I can do the spoof if we happen to have the same ISP. But maybe this kind of spoofing will have to come to an end: I may have to just say "Hey, Dad, it's me; Mom wanted you to know: ...") The important thing is that the functionality that people care about can be preserved, albeit at an added cost in implementation complexity (eg. SRS for forwarders and web-generated email). So, in this future, we do break backward compatibility; but the places where it breaks are well defined. The number of people who have to do work to get around the breakage is relatively small: basically it's the email admins who have to deal with change, and that's OK, because it's their job to do that. That's better than requiring a change in behaviour from absolutely everybody. And that's better than going on with things as they are today. Choosing an effective, timely solution that has well-defined breakage whose workarounds are the responsibility of (professional) administrators just sounds to me like good engineering. I have a slideshow that makes the above argument more visually. Click on the RHS of the image to step forward. http://spf.pobox.com/slides/apcauce2004/7000.html From owner-ietf-mxcomp Thu Mar 18 17:38:07 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2J1c69C006789; Thu, 18 Mar 2004 17:38: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 i2J1c6oa006788; Thu, 18 Mar 2004 17:38:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [208.210.125.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2J1c6A4006782 for ; Thu, 18 Mar 2004 17:38:06 -0800 (PST) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [208.210.125.24]) by emerald.pobox.com (Postfix) with ESMTP id A3FCF132D32; Thu, 18 Mar 2004 20:38:11 -0500 (EST) Received: by dumbo.pobox.com (Postfix, from userid 505) id 87D06619; Thu, 18 Mar 2004 20:38:11 -0500 (EST) Date: Thu, 18 Mar 2004 20:38:11 -0500 From: Meng Weng Wong To: Dave Crocker Cc: Meng Weng Wong , IETF MXCOMP Subject: Re: sender vs author, channel vs object, designated sender vs crypto signatures Message-ID: <20040319013811.GR8016@dumbo.pobox.com> References: <20040318144600.GJ8016@dumbo.pobox.com> <20040318155020.GM8016@dumbo.pobox.com> <1199049623.20040318080119@brandenburg.com> <20040318161249.GN8016@dumbo.pobox.com> <5810142822.20040318093849@brandenburg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5810142822.20040318093849@brandenburg.com> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Mar 18, 2004 at 09:38:49AM -0800, Dave Crocker wrote: | MWW> 1) I believe that it is important to protect the RFC2821 MAIL FROM from | MWW> illegitimate spoofing, independent of the RFC2822 header From:. | | That phrasing sounds like an assertion that we can have productive | discussion about. Thanks for your comments Dave, I'm glad we can agree on this. | MWW> 3) I believe that it is also important to protect the RFC2822 header From: | MWW> from illegitimate spoofing, independent of the RFC2821 MAIL FROM. | | Hard to argue with that view. (Although, of course, a community like | this can argue about anything...) (For people who were not at the BOF, widespread outbreaks of agreement like this are now called the Dave Crocker Lovefest Effect. :) I wanted to focus on these two items because they are facts that exist in the field; we can have endless debates about different identity roles but the fact is there is RFC2821 MAIL FROM and there are RFC2822 From: and Sender: and Resent-From and Resent-Sender so let's see what we can do with that. The former is read more by machines than users; the second is read more by users than machines. http://www.ietf.org/internet-drafts/draft-irtf-asrg-lmap-discussion-00.txt section 2.1 identiifies four types of forgeries. I associate phishing-spam with 2822 forgery, designed to fool humans. I associate joe-jobs with 2821 forgery, designed to fool machines. (I believe MTAs whitelist on the basis of 2821 FROM, MUAs whitelist on the basis of 2822 From:.) | MWW> 2) I believe that the most appropriate way to do so is with a designated | MWW> sender scheme. | | When the working group starts debating particular schemes for achieving | the desired authentication (and maybe authorization) we can pursue of | this scheme, and others, further. Does anybody not agree that designated sender is the best way to combat RFC2821 MAIL FROM forgery? Show of hands please ... Does anybody not agree that crypto is the best way to combat RFC2822 header From: forgery? By "best" I mean "best combination of timely, deployable, implementable, gaming-proof, long-term effective, deterministic, and politically palatable". If we have rough consensus on the above two points, then I propose that we proceed to the question of whether designated sender can be appropriate for attacking RFC2822 forgery in certain circumstances. From owner-ietf-mxcomp Thu Mar 18 18:07:23 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2J27NB9008828; Thu, 18 Mar 2004 18:07: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 i2J27NUU008827; Thu, 18 Mar 2004 18:07:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2J27MUS008820 for ; Thu, 18 Mar 2004 18:07:22 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i2J27RBT026476; Thu, 18 Mar 2004 18:07:27 -0800 (PST) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 18 Mar 2004 18:07:27 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Meng Weng Wong'" , Dave Crocker Cc: IETF MXCOMP Subject: RE: sender vs author, channel vs object, designated sender vs cry pto signatures Date: Thu, 18 Mar 2004 18:07:26 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >Does anybody not agree that designated sender is the best way to combat >RFC2821 MAIL FROM forgery? Show of hands please ... >Does anybody not agree that crypto is the best way to combat RFC2822 >header From: forgery? I think thats the wrong way to look at the issue. The cost of IP based authentication is so low compared to other mechanisms that in this case it is applicable in both cases. So far apart from a handful of folk saying that they just have to send their email from their laptop direct I don't see the cases that just have to be done with cryptography. I think that it would be reasonable to have a set of flags to say what the match should be. I would like to prevent any VeriSign employee from sending any email except through the verisign mail servers. That way we can control in one single place, scan for viruses etc. Phill From owner-ietf-mxcomp Thu Mar 18 18:11:09 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2J2B96u009090; Thu, 18 Mar 2004 18:11:09 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2J2B9ip009089; Thu, 18 Mar 2004 18:11:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [208.210.125.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2J2B8eZ009083 for ; Thu, 18 Mar 2004 18:11:08 -0800 (PST) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [208.210.125.24]) by emerald.pobox.com (Postfix) with ESMTP id A6BB7132D85; Thu, 18 Mar 2004 21:11:13 -0500 (EST) Received: by dumbo.pobox.com (Postfix, from userid 505) id 78BDA680; Thu, 18 Mar 2004 21:11:13 -0500 (EST) Date: Thu, 18 Mar 2004 21:11:13 -0500 From: Meng Weng Wong To: "Hallam-Baker, Phillip" Cc: IETF MXCOMP Subject: Re: sender vs author, channel vs object, designated sender vs cry pto signatures Message-ID: <20040319021113.GQ27090@dumbo.pobox.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Mar 18, 2004 at 06:07:26PM -0800, Hallam-Baker, Phillip wrote: | | I think thats the wrong way to look at the issue. The cost of IP based | authentication is so low compared to other mechanisms that in this case | it is applicable in both cases. | | I think that it would be reasonable to have a set of flags to say what | the match should be. I would like to prevent any VeriSign employee | from sending any email except through the verisign mail servers. That | way we can control in one single place, scan for viruses etc. | Doesn't that mean you'd have to subscribe to this list under a different email address? From owner-ietf-mxcomp Thu Mar 18 18:38:31 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2J2cVVv011154; Thu, 18 Mar 2004 18:38:31 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2J2cV46011153; Thu, 18 Mar 2004 18:38:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.40]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2J2cU3I011147 for ; Thu, 18 Mar 2004 18:38:30 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.52] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1B49u6-0006vb-00; Thu, 18 Mar 2004 21:38:34 -0500 Received: from [68.244.174.234] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1B49u4-0008Fs-00; Thu, 18 Mar 2004 21:38:34 -0500 Message-ID: <405A5D16.9070603@solidmatrix.com> Date: Thu, 18 Mar 2004 21:38:14 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Meng Weng Wong CC: Dave Crocker , IETF MXCOMP Subject: Re: sender vs author, channel vs object, designated sender vs crypto signatures References: <20040318144600.GJ8016@dumbo.pobox.com> <20040318155020.GM8016@dumbo.pobox.com> <1199049623.20040318080119@brandenburg.com> <20040318161249.GN8016@dumbo.pobox.com> <5810142822.20040318093849@brandenburg.com> <20040319013811.GR8016@dumbo.pobox.com> In-Reply-To: <20040319013811.GR8016@dumbo.pobox.com> X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Meng Weng Wong wrote: > On Thu, Mar 18, 2004 at 09:38:49AM -0800, Dave Crocker wrote: > | MWW> 1) I believe that it is important to protect the RFC2821 MAIL FROM from > | MWW> illegitimate spoofing, independent of the RFC2822 header From:. > | > | That phrasing sounds like an assertion that we can have productive > | discussion about. > > Thanks for your comments Dave, I'm glad we can agree on this. > Sounds good to me also. > | MWW> 3) I believe that it is also important to protect the RFC2822 header From: > | MWW> from illegitimate spoofing, independent of the RFC2821 MAIL FROM. > | > | Hard to argue with that view. (Although, of course, a community like > | this can argue about anything...) > While it may be independent, it may also be done via the same mechanism for both (which is what Phil is arguing). > (For people who were not at the BOF, widespread outbreaks of agreement > like this are now called the Dave Crocker Lovefest Effect. :) > Good to know :) > I wanted to focus on these two items because they are facts that exist > in the field; we can have endless debates about different identity roles > but the fact is there is RFC2821 MAIL FROM and there are RFC2822 From: > and Sender: and Resent-From and Resent-Sender so let's see what we can > do with that. The former is read more by machines than users; the > second is read more by users than machines. > > http://www.ietf.org/internet-drafts/draft-irtf-asrg-lmap-discussion-00.txt > section 2.1 identiifies four types of forgeries. I associate > phishing-spam with 2822 forgery, designed to fool humans. I associate > joe-jobs with 2821 forgery, designed to fool machines. > I am not so sure about joe-jobs. Joe-jobs that are meant to generate lots of bounces are done with MAIL FROM, but joe jobs that promote child pornography with someone's domain or are designed to annoy a domain owner with angry letters, can be done via either one since they are intended for human consumption. > (I believe MTAs whitelist on the basis of 2821 FROM, MUAs whitelist on > the basis of 2822 From:.) > > | MWW> 2) I believe that the most appropriate way to do so is with a designated > | MWW> sender scheme. > | > | When the working group starts debating particular schemes for achieving > | the desired authentication (and maybe authorization) we can pursue of > | this scheme, and others, further. > > Does anybody not agree that designated sender is the best way to combat > RFC2821 MAIL FROM forgery? Show of hands please ... > I am not sure if it is the best way to do it, but it is one way to do it. > Does anybody not agree that crypto is the best way to combat RFC2822 > header From: forgery? > While designated sender schemes can be used for fight header forgery (like CID does), they might be breaking too many things. The question we should be asking is whether we should be verifying the "from" header, not whether proposal X is better. We need to establish that this proposal might not the be the best one suited for this, but while others are available we don't have to pick a specific one. So while I have doubts about whether "from" header forgery is something we should be applying this scheme to, I do not agree that crypto is the best option. But it is irrelevant whether crypto is the right option, since that's not what we are deciding here. > By "best" I mean "best combination of timely, deployable, implementable, > gaming-proof, long-term effective, deterministic, and politically > palatable". > > If we have rough consensus on the above two points, then I propose that > we proceed to the question of whether designated sender can be > appropriate for attacking RFC2822 forgery in certain circumstances. > The main problem with RFC2822 forgery and MARID schemes is that too many things tend to break. We can try to figure out whether specific use cases can be done without breakage, but I don't know if in real life people will bother. They just might verify "from" headers in every case. Also, while Phil does make a compelling argument of killing two birds with one stone, there are alternatives. If we want to use this scheme for "from" header checking, then MUAs have to be modified. If we verify the RFC2821 from instead which is the return path, than MUAs can be modified to display it to the user since it is verified. Either way modifications in MUAs can help. Yakov From owner-ietf-mxcomp Thu Mar 18 19:04:03 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2J343e5013032; Thu, 18 Mar 2004 19:04: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 i2J343uo013031; Thu, 18 Mar 2004 19:04:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (IDENT:root@ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2J342aY013020 for ; Thu, 18 Mar 2004 19:04:02 -0800 (PST) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-19-105.client.comcast.net [24.6.19.105]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i2J344iL021511 for ; Thu, 18 Mar 2004 19:04:04 -0800 (PST) Received: by tethys.bitshift.org (Postfix, from userid 1001) id 52C652288A; Thu, 18 Mar 2004 19:04:04 -0800 (PST) Date: Thu, 18 Mar 2004 19:04:04 -0800 From: "Mark C. Langston" To: IETF MXCOMP Subject: Re: sender vs author, channel vs object, designated sender vs crypto signatures Message-ID: <20040319030404.GH49487@bitshift.org> References: <20040318144600.GJ8016@dumbo.pobox.com> <20040318155020.GM8016@dumbo.pobox.com> <1199049623.20040318080119@brandenburg.com> <20040318161249.GN8016@dumbo.pobox.com> <5810142822.20040318093849@brandenburg.com> <20040319013811.GR8016@dumbo.pobox.com> <405A5D16.9070603@solidmatrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <405A5D16.9070603@solidmatrix.com> User-Agent: Mutt/1.4.1i X-Uptime: 7:00PM up 275 days, 22:10, 6 users, load averages: 0.00, 0.00, 0.00 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Mar 18, 2004 at 09:38:14PM -0500, Yakov Shafranovich wrote: > > Meng Weng Wong wrote: > > > >Does anybody not agree that designated sender is the best way to combat > >RFC2821 MAIL FROM forgery? Show of hands please ... > > > > I am not sure if it is the best way to do it, but it is one way to do it. > I share Yakov's position. > >Does anybody not agree that crypto is the best way to combat RFC2822 > >header From: forgery? > > > > While designated sender schemes can be used for fight header forgery > (like CID does), they might be breaking too many things. The question we > should be asking is whether we should be verifying the "from" header, > not whether proposal X is better. Indeed. -- Mark C. Langston Sr. Unix SysAdmin mark@bitshift.org mark@seti.org Systems & Network Admin SETI Institute http://bitshift.org http://www.seti.org From owner-ietf-mxcomp Thu Mar 18 19:19:00 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2J3J0Pp014072; Thu, 18 Mar 2004 19:19: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 i2J3J0Uv014071; Thu, 18 Mar 2004 19:19:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2J3Ixj5014065 for ; Thu, 18 Mar 2004 19:18:59 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2J3SId17719; Thu, 18 Mar 2004 19:28:18 -0800 Date: Thu, 18 Mar 2004 19:18:56 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <110797578.20040318191856@brandenburg.com> To: Meng Weng Wong CC: IETF MXCOMP Subject: Re: sender vs author, channel vs object, designated sender vs crypto signatures In-Reply-To: <20040319013811.GR8016@dumbo.pobox.com> References: <20040318144600.GJ8016@dumbo.pobox.com> <20040318155020.GM8016@dumbo.pobox.com> <1199049623.20040318080119@brandenburg.com> <20040318161249.GN8016@dumbo.pobox.com> <5810142822.20040318093849@brandenburg.com> <20040319013811.GR8016@dumbo.pobox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Meng, MWW> (For people who were not at the BOF, widespread outbreaks of agreement MWW> like this are now called the Dave Crocker Lovefest Effect. :) even when they do not involve me, perhaps? egad, that would make me a generic brand... MWW> I wanted to focus on these two items because they are facts that exist MWW> in the field; we can have endless debates about different identity roles MWW> but the fact is there is RFC2821 MAIL FROM and there are RFC2822 From: MWW> and Sender: and Resent-From and Resent-Sender There is also the domain identity asserted in EHLO. MWW> Does anybody not agree that designated sender is the best way to combat MWW> RFC2821 MAIL FROM forgery? Show of hands please ... You keep trying to debate schemes, when we are not there yet. The charter calls for debating choice of identity. So let's try to follow the plan. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Thu Mar 18 19:20:38 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2J3KcPP014142; Thu, 18 Mar 2004 19:20: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 i2J3KcjW014141; Thu, 18 Mar 2004 19:20:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from emerald.pobox.com (postfix@emerald.pobox.com [208.210.125.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2J3Kbaf014135 for ; Thu, 18 Mar 2004 19:20:37 -0800 (PST) (envelope-from mengwong@dumbo.pobox.com) Received: from dumbo.pobox.com (dumbo.pobox.com [208.210.125.24]) by emerald.pobox.com (Postfix) with ESMTP id 52E21132D85; Thu, 18 Mar 2004 22:20:43 -0500 (EST) Received: by dumbo.pobox.com (Postfix, from userid 505) id 3537D661; Thu, 18 Mar 2004 22:20:43 -0500 (EST) Date: Thu, 18 Mar 2004 22:20:43 -0500 From: Meng Weng Wong To: "Mark C. Langston" Cc: IETF MXCOMP Subject: Re: sender vs author, channel vs object, designated sender vs crypto signatures Message-ID: <20040319032043.GS8016@dumbo.pobox.com> References: <20040318144600.GJ8016@dumbo.pobox.com> <20040318155020.GM8016@dumbo.pobox.com> <1199049623.20040318080119@brandenburg.com> <20040318161249.GN8016@dumbo.pobox.com> <5810142822.20040318093849@brandenburg.com> <20040319013811.GR8016@dumbo.pobox.com> <405A5D16.9070603@solidmatrix.com> <20040319030404.GH49487@bitshift.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040319030404.GH49487@bitshift.org> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Mar 18, 2004 at 07:04:04PM -0800, Mark C. Langston wrote: | > | > While designated sender schemes can be used for fight header forgery | > (like CID does), they might be breaking too many things. The question we | > should be asking is whether we should be verifying the "from" header, | > not whether proposal X is better. | | Indeed. | OK, what is your answer? From owner-ietf-mxcomp Thu Mar 18 19:27:07 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2J3R7jU014557; Thu, 18 Mar 2004 19:27:07 -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 i2J3R7UD014556; Thu, 18 Mar 2004 19:27:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2J3R7PO014550 for ; Thu, 18 Mar 2004 19:27:07 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2J3ZRd18230; Thu, 18 Mar 2004 19:35:27 -0800 Date: Thu, 18 Mar 2004 19:26:05 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <8197999.20040318192605@brandenburg.com> To: Meng Weng Wong CC: "Mark C. Langston" , IETF MXCOMP Subject: when spoofing isn't In-Reply-To: <20040319012228.GQ8016@dumbo.pobox.com> References: <20040318144600.GJ8016@dumbo.pobox.com> <20040318155020.GM8016@dumbo.pobox.com> <20040318162022.GO8016@dumbo.pobox.com> <20040318181323.GO8629@bitshift.org> <20040319012228.GQ8016@dumbo.pobox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Meng, MWW> | Could you provide us with en example of what you view as legitimate MWW> | spoofing of RFC2821 MAIL FROM and RFC2822 header From:? MWW> Legitimate spoofing of RFC2821 MAIL FROM: Dictionary.com: tr.v. spoofed, spoof·ing, spoofs 1. To deceive. "legitimate spoofing" is an oxymoron. MWW> - web-generated email (I log in to eBay and send mail using eBay's web MWW> UI to another eBay member; I want to see bounces.) That's not spoofing. It is entirely fine for you to do it and you are not deceiving anyone. And it is, in fact, common practise, as has been cited quite a few times. So, it ain't spoofing. MWW> - verbatim forwarding (a@a.com sends mail to b@b.com which forwards to MWW> c@c.com; if c@c.com is undeliverable, a@a.com should get the bounce.) this is not spoofing. MWW> Legitimate spoofing of RFC2822 header From: MWW> - My mother comes to me and asks me to email my father with a note MWW> to buy milk and eggs on his way home. I send mail using a mail client MWW> that lets me edit the From: header field so I change it to her MWW> email address; I put my email address in the Sender: header. In other words, she is the author. So, again, this is not spoofing. MWW> | Do you believe that the pursuit of points 1 and 3 should override the MWW> | preservation of these legitimate spoofs? MWW> Yes; legitimate spoofing is by definition very hard to distinguish from MWW> illegitmate spoofing. Not if it isn't spoofing. It involves no deception. You are describing entirely valid, legal, practical and used scenarios. MWW> I want to be able to send mail to my dad on behalf of my mother. Or, rather, your mother wants to send mail, through your account. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Thu Mar 18 20:27:25 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2J4RP5P018872; Thu, 18 Mar 2004 20:27: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 i2J4RPES018871; Thu, 18 Mar 2004 20:27:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.40]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2J4ROBp018864 for ; Thu, 18 Mar 2004 20:27:24 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.50] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1B4BaW-00037S-00; Thu, 18 Mar 2004 23:26:28 -0500 Received: from [68.244.149.246] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1B4BaV-00049K-00; Thu, 18 Mar 2004 23:26:28 -0500 Message-ID: <405A7668.4090103@solidmatrix.com> Date: Thu, 18 Mar 2004 23:26:16 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Meng Weng Wong CC: "Mark C. Langston" , IETF MXCOMP Subject: Re: sender vs author, channel vs object, designated sender vs crypto signatures References: <20040318144600.GJ8016@dumbo.pobox.com> <20040318155020.GM8016@dumbo.pobox.com> <1199049623.20040318080119@brandenburg.com> <20040318161249.GN8016@dumbo.pobox.com> <5810142822.20040318093849@brandenburg.com> <20040319013811.GR8016@dumbo.pobox.com> <405A5D16.9070603@solidmatrix.com> <20040319030404.GH49487@bitshift.org> <20040319032043.GS8016@dumbo.pobox.com> In-Reply-To: <20040319032043.GS8016@dumbo.pobox.com> X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Meng Weng Wong wrote: > On Thu, Mar 18, 2004 at 07:04:04PM -0800, Mark C. Langston wrote: > | > > | > While designated sender schemes can be used for fight header forgery > | > (like CID does), they might be breaking too many things. The question we > | > should be asking is whether we should be verifying the "from" header, > | > not whether proposal X is better. > | > | Indeed. > | > > OK, what is your answer? > You can choose to verify the "from" header in all cases like Phil is pushing, you can can verify the "from" header in *some* cases like you original proposal, or can choose *not* to verify it. Case #1 breaks too many things, case #2 might work but is likely not to be followed when implemented, and case #3 does not stop header forgery at all. HOWEVER, the main problem with header forging is fooling the user. If the MUA can indicate to the user that a message is suspicious perhaps by displaying the "Return Path" header OR comparing the "Return Path" to the "from" header, and simply putting a question mark somewhere; that might be something useful. Even if you are only verifying the MAIL FROM, you did accomplish something - the "Return Path" header in the mail message itself is now verified and can be relied on (assuming you can deal with the forged ones by removing them). Now that you verified it, you can build on that fact. Yakov From owner-ietf-mxcomp Thu Mar 18 20:30:16 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2J4UGD0019049; Thu, 18 Mar 2004 20:30:16 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2J4UGq2019048; Thu, 18 Mar 2004 20:30:16 -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 (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2J4UFEl019041 for ; Thu, 18 Mar 2004 20:30:15 -0800 (PST) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.30) id 1B4BeI-00058G-IS for ietf-mxcomp@imc.org; Thu, 18 Mar 2004 22:30:22 -0600 To: "IETF MXCOMP" Subject: Why we should choose the RFC2821 MAIL FROM/HELO identities References: From: wayne Content-Type: text/plain; charset=US-ASCII Date: Thu, 18 Mar 2004 22:30:22 -0600 In-Reply-To: (Ted Hardie's message of "Mon, 15 Mar 2004 15:13:26 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (spfd: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In Ted Hardie writes: > Working Group Goals and Milestones: > > March 04 Discuss identities with which MTA authorization > should be associated > > April 04 Working Group last call on which identities > will be > used for MTA authorization Ok, we are supposed to be discussing the identities with which MTA authorization should be associated with. I've thought about this for well over a year now, and my opinions haven't changed, despite all rehashing of stuff that was discussed on ASRG many moons ago. So, I might a well state my opinions and be done with it *** I think the identities that we should consider are the RFC2821 *** MAIL FROM and HELO domains names. My reasons for this are more pragmatic than technical. Why I think we should work first on the RFC2821 MAIL FROM and HELO domains. * The MAIL FROM is where bounces go to and a lot of the spam that makes it past SpamAssassin and into my inbox are bogus bounces/virus notifications. * Both the HELO domain and the MAIL FROM show up in email headers. When non-email-gurus look for the source of the spam, they are often mislead into believing that the spoofed domains are the real source. This causes bogus abuse desk complaints. * A very large percentage of the email being sent now-a-days is spam with forged MAIL FROM addresses. As a result, it is no longer safe to accept email and then send bounces to the MAIL FROM address without causing problems for innocent third parties. No other header/identity is acceptable to send bounces to either. As a result, we have effectively lost the ability to safely send bounces. the best we can do is use a 5xx rejection code during the SMTP session, and even that can cause innocent third parties to receive bogus bounces. The MAIL FROM address has basically lost all of its historical usefulness. While we can not restore all of the functionality it once had, we can restore a great deal of it. * I believe that the this is an easier problem to solve than the RFC2822 header spoofing problems. The RFC2821 data is handled almost entirely by programs and thus lends itself to verification via programs. * There are positive incentive for domain owners to publish designated sender records and for email receivers to check them. Besides the reduced number of bogus bounces and bogus complaints, by publishing designated sender records, domain owners are making a public notice to protect their brand names and their good good reputations. This is kind of like putting up "No trespassing" signs. Publishing records is a very low cost thing to do, even if initially there isn't a huge payback. For email receivers, the benefits for checking is pretty clear: it catches spam, joe-jobs and phishing. It will never catch all of it, but again, this is a fairly low cost thing to check. Even at this early stage, SPF checks are stopping about 1% of the spam that reaches my machine. * With SPF having been in field testing for months, the problem space is (comparatively) well understood. * I believe that rolling out a system that validates the RFC2821 data can play an important part in the process of validating the RFC2822 data. I don't think we need to get into bogged down in exactly how this will work right now. Let's pick the low hanging fruit first. Why not the IP address via MTA-MARK/SS * Receivers can already largely solve this problem today via DUL lists. * Senders can already largely solve this problem today via port 25 blocking. * I see little reason why owners of IP space who don't publish DUL lists or do port 25 blocking would do MTA mark. There is no incentive for them, this is something that they will have to spend a great deal of time doing in order to help out other people. * The rDNS space is a mess. Why not the RFC2822 headers: * To be really effective at protecting the RFC2822 headers from phishing and such, you need to changes to MUAs. * There are several decimal orders of magnitude (hi Ted) more installed MUAs than installed MTAs. * We have far less influence in the MUA market. * Solving the RFC2822 data spoofing is a much harder problem * There are too many different headers created by too many different programs and that creates too many different cases to analyze. * The RFC2822 headers allow comment string, so if you really want to tackle phishing and spoofing, you have to figure out how to block email claiming to be from things like this: From: "Paypal Security Desk" * I don't believe the RFC2822 spoofing problem space is as well understood as the RFC2821 problem space. Even though this is a fairly long post, it really only covers the surface of why I am convinced that the RFC2821 data is the thing to tackle first. While I'm certain that, for each point mentioned above, there are people who disagree with me. I'm certain that there are people who disagree with all of this. However, to change my mind after studying this problem for as long as I have, you would need to come up with some pretty strong arguments. If such arguments existed, I would likely have heard them before now. So, with two weeks to go before a "last call" on this issue is needed, I'm ready to put my two cents in. -wayne From owner-ietf-mxcomp Thu Mar 18 20:36:04 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2J4a4Ff019690; Thu, 18 Mar 2004 20:36: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 i2J4a4Tv019689; Thu, 18 Mar 2004 20:36:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (IDENT:root@ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2J4a44A019681 for ; Thu, 18 Mar 2004 20:36:04 -0800 (PST) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-19-105.client.comcast.net [24.6.19.105]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i2J4a6iL011657 for ; Thu, 18 Mar 2004 20:36:07 -0800 (PST) Received: by tethys.bitshift.org (Postfix, from userid 1001) id 91FC922888; Thu, 18 Mar 2004 20:36:06 -0800 (PST) Date: Thu, 18 Mar 2004 20:36:06 -0800 From: "Mark C. Langston" To: IETF MXCOMP Subject: Re: sender vs author, channel vs object, designated sender vs crypto signatures Message-ID: <20040319043606.GI49487@bitshift.org> References: <20040318144600.GJ8016@dumbo.pobox.com> <20040318155020.GM8016@dumbo.pobox.com> <1199049623.20040318080119@brandenburg.com> <20040318161249.GN8016@dumbo.pobox.com> <5810142822.20040318093849@brandenburg.com> <20040319013811.GR8016@dumbo.pobox.com> <405A5D16.9070603@solidmatrix.com> <20040319030404.GH49487@bitshift.org> <20040319032043.GS8016@dumbo.pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040319032043.GS8016@dumbo.pobox.com> User-Agent: Mutt/1.4.1i X-Uptime: 7:06PM up 275 days, 22:16, 6 users, load averages: 0.00, 0.00, 0.00 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Mar 18, 2004 at 10:20:43PM -0500, Meng Weng Wong wrote: > On Thu, Mar 18, 2004 at 07:04:04PM -0800, Mark C. Langston wrote: > | > > | > While designated sender schemes can be used for fight header forgery > | > (like CID does), they might be breaking too many things. The question we > | > should be asking is whether we should be verifying the "from" header, > | > not whether proposal X is better. > | > | Indeed. > | > > OK, what is your answer? My answer to "Should we be verifying the RFC2822 From: header"? I'm not sure we can using crypto without MUA rewrites, though there are other approaches. For example, I think the idea of using the RFC2821 ENVELOPE-FROM as a means to assgn greater or lesser credibility to the contents of the RFC2822 From: header has some merit, but that enters into the realm of a reputation-based system, and as Yakov said, the issue is not "what's a good way to do it?" but rather, "should be we considering it?" Right now, my answer would be "yes, we should consider it", if only to determine the manner and extent of the breakage the various approaches may introduce. As long as the distinction between "consideration" and "recommendation" is kept clear. -- Mark C. Langston Sr. Unix SysAdmin mark@bitshift.org mark@seti.org Systems & Network Admin SETI Institute http://bitshift.org http://www.seti.org From owner-ietf-mxcomp Thu Mar 18 21:01:11 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2J51BhT021444; Thu, 18 Mar 2004 21:01: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 i2J51Bu9021443; Thu, 18 Mar 2004 21:01:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (IDENT:root@ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2J51AQ4021435 for ; Thu, 18 Mar 2004 21:01:10 -0800 (PST) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-19-105.client.comcast.net [24.6.19.105]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i2J51EiL017254 for ; Thu, 18 Mar 2004 21:01:14 -0800 (PST) Received: by tethys.bitshift.org (Postfix, from userid 1001) id 0C50122887; Thu, 18 Mar 2004 21:01:14 -0800 (PST) Date: Thu, 18 Mar 2004 21:01:14 -0800 From: "Mark C. Langston" To: IETF MXCOMP Subject: Re: when spoofing isn't Message-ID: <20040319050114.GJ49487@bitshift.org> References: <20040318144600.GJ8016@dumbo.pobox.com> <20040318155020.GM8016@dumbo.pobox.com> <20040318162022.GO8016@dumbo.pobox.com> <20040318181323.GO8629@bitshift.org> <20040319012228.GQ8016@dumbo.pobox.com> <8197999.20040318192605@brandenburg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8197999.20040318192605@brandenburg.com> User-Agent: Mutt/1.4.1i X-Uptime: 7:06PM up 275 days, 22:16, 6 users, load averages: 0.00, 0.00, 0.00 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Mar 18, 2004 at 07:26:05PM -0800, Dave Crocker wrote: > Meng, > > > MWW> | Could you provide us with en example of what you view as legitimate > MWW> | spoofing of RFC2821 MAIL FROM and RFC2822 header From:? > > MWW> Legitimate spoofing of RFC2821 MAIL FROM: > > Dictionary.com: > > tr.v. spoofed, spoof?ing, spoofs > > 1. To deceive. > > "legitimate spoofing" is an oxymoron. > > > MWW> - web-generated email (I log in to eBay and send mail using eBay's web > MWW> UI to another eBay member; I want to see bounces.) > > That's not spoofing. It is entirely fine for you to do it and you are > not deceiving anyone. Except when it isn't fine to do it. I may not articulate this well, so if the following is confusing, please ask for clarification. If the service provider has clauses in their acceptable use policy (as many seem to, these days) that specify that mail headers may not be molested, it would seem that the above would indeed be considered "spoofing", because you're deceiving the recipient...but only in the eyes of the service provider. The service provider expects outgoing mail to have the account and domain name given to the user in the RFC2822 From: header. When the recipient receives mail from that service provider's MTA, with the service provider's HELO and RFC2821 ENVELOPE-FROM, but with RFC2822 headers that do not reflect use of the service provider's services, the service provider may infer that the sending entity was attempting to deceive the recipient. Deception appears to be relative. I agree that "[il]legitmate spoofing" is an awkward term, but there are four parties with an interest in the identifying information attached to an outgoing email: The sending entity, the sending entity's provider, the recipient's provider, and the recipient. Any one of these may consider alteration of identifying information an attempt at deception (consider the case in which the sending entity's ISP substitutes the entity's account name and the ISP's domain name in the From: header of outgoing email, overwriting whatever the sending entity had put there). On a somewhat related note, it would seem we are moving towards requiring all outbound email to be routed through authorized MTAs, and doing away with the ability to connect directly to a recipient's MX to send an email. I'm not bringing it up because I necessarily view it as a bad thing; I'm unsure how prevalent this behavior still it, and whether it's something to keep in mind. -- Mark C. Langston Sr. Unix SysAdmin mark@bitshift.org mark@seti.org Systems & Network Admin SETI Institute http://bitshift.org http://www.seti.org From owner-ietf-mxcomp Thu Mar 18 21:12:06 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2J5C6EP022181; Thu, 18 Mar 2004 21:12: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 i2J5C6SS022180; Thu, 18 Mar 2004 21:12:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.40]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2J5C5Sq022174 for ; Thu, 18 Mar 2004 21:12:06 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.50] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1B4CIm-0008Mh-00; Fri, 19 Mar 2004 00:12:12 -0500 Received: from [68.244.149.246] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1B4CIl-0006In-00; Fri, 19 Mar 2004 00:12:12 -0500 Message-ID: <405A8120.1030500@solidmatrix.com> Date: Fri, 19 Mar 2004 00:12:00 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: wayne CC: IETF MXCOMP Subject: Re: Why we should choose the RFC2821 MAIL FROM/HELO identities References: In-Reply-To: X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: wayne wrote: > * I believe that rolling out a system that validates the RFC2821 data > can play an important part in the process of validating the RFC2822 > data. I don't think we need to get into bogged down in exactly how > this will work right now. Let's pick the low hanging fruit first. > I agree especially with the fact that verifying RFC2822 data is much more complicated with all the headers involved and the lack of the connecting IP address present. We need to separate the two problems - RFC2821 verification and RFC2822 verification. > > Why not the IP address via MTA-MARK/SS > > * Receivers can already largely solve this problem today via DUL > lists. > It is more logical to have it in the IP address record itself - control over rDNS space of an address is logically something that belongs to the owner, just like forward DNS to domain owner. This allows people who get dedicated IP addresses with rDNS control over them to mark them as MTAs. > * Senders can already largely solve this problem today via port 25 > blocking. > Blocking has its problems and it is also not applied universally. > * I see little reason why owners of IP space who don't publish DUL > lists or do port 25 blocking would do MTA mark. There is no > incentive for them, this is something that they will have to spend a > great deal of time doing in order to help out other people. > > * The rDNS space is a mess. > The same applied for bounce addresses today :) As Phil mentioned somewhere else if you give enough usefulness to it, the rDNS situtation may improve since people will begin to use and maintain it. Another possibility is an alternative place to store the data. > > > Why not the RFC2822 headers: > > * To be really effective at protecting the RFC2822 headers from > phishing and such, you need to changes to MUAs. > > * There are several decimal orders of magnitude (hi Ted) more > installed MUAs than installed MTAs. > > * We have far less influence in the MUA market. > > * Solving the RFC2822 data spoofing is a much harder problem > > * There are too many different headers created by too many different > programs and that creates too many different cases to analyze. > > * The RFC2822 headers allow comment string, so if you really want to > tackle phishing and spoofing, you have to figure out how to block > email claiming to be from things like this: > > From: "Paypal Security Desk" > > * I don't believe the RFC2822 spoofing problem space is as well > understood as the RFC2821 problem space. > I would add to this that even with RFC2821 verification you also happen to verify one RFC2822 header - Return Path. This fact can be used by the MUA to alert users. Yakov From owner-ietf-mxcomp Fri Mar 19 00:05:22 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2J85MUI072149; Fri, 19 Mar 2004 00:05: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 i2J85MK3072148; Fri, 19 Mar 2004 00:05:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2J85MMd072141 for ; Fri, 19 Mar 2004 00:05:22 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2J8DSd03566; Fri, 19 Mar 2004 00:13:28 -0800 Date: Fri, 19 Mar 2004 00:04:05 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <403091675.20040319000405@brandenburg.com> To: "Mark C. Langston" CC: IETF MXCOMP Subject: Re: when spoofing isn't In-Reply-To: <20040319050114.GJ49487@bitshift.org> References: <20040318144600.GJ8016@dumbo.pobox.com> <20040318155020.GM8016@dumbo.pobox.com> <20040318162022.GO8016@dumbo.pobox.com> <20040318181323.GO8629@bitshift.org> <20040319012228.GQ8016@dumbo.pobox.com> <8197999.20040318192605@brandenburg.com> <20040319050114.GJ49487@bitshift.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Mark, MCL> If the service provider has clauses in their acceptable use policy (as MCL> many seem to, these days) that specify that mail headers may not be that is the nice thing about citing a hypothetical. it is certain to support whatever position you want. it does not, however, justify a course of action that eliminates legitimate uses of long-standing facilities. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Fri Mar 19 01:10:01 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2J9A10j093858; Fri, 19 Mar 2004 01:10:01 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2J9A133093857; Fri, 19 Mar 2004 01:10:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from argon.connect.org.uk (argon.connectinternetsolutions.com [193.110.243.33]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2J9A0kZ093844 for ; Fri, 19 Mar 2004 01:10:01 -0800 (PST) (envelope-from jrk@merseymail.com) Received: from mmail by argon.connect.org.uk with local (connectmail/exim) id 1B4G0t-0004VS-R7; Fri, 19 Mar 2004 09:09:59 +0000 In-Reply-To: Subject: Re: Why we should choose the RFC2821 MAIL FROM/HELO identities To: "wayne" From: "Jon Kyme" Cc: X-Mailer: [ConnectMail 3.13.0] X-connectmail-Originating-IP: 172.25.243.3 Message-Id: Date: Fri, 19 Mar 2004 09:09:59 +0000 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Wayne > > Ok, we are supposed to be discussing the identities with which MTA > authorization should be associated with. > *** I think the identities that we should consider are the RFC2821 > *** MAIL FROM and HELO domains names. > I agree that the *first* push should be at these identities, since this is the stuff claimed by the MTA. And that's what we're about right? Authorizing MTAs. This is not to say that names used in (2822)headers aren't a concern, but it's primarily a concern in MUA. I don't have a strong philosophical objection to server MTA components doing tests on content, but it's not the client MTA that asserts identities in (2822)headers. From owner-ietf-mxcomp Fri Mar 19 08:25:57 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JGPvW5041083; Fri, 19 Mar 2004 08:25: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 i2JGPvlX041082; Fri, 19 Mar 2004 08:25:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (IDENT:root@ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JGPvc1041072 for ; Fri, 19 Mar 2004 08:25:57 -0800 (PST) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-19-105.client.comcast.net [24.6.19.105]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i2JGPuiL027611 for ; Fri, 19 Mar 2004 08:25:56 -0800 (PST) Received: by tethys.bitshift.org (Postfix, from userid 1001) id 439C52288B; Fri, 19 Mar 2004 08:25:56 -0800 (PST) Date: Fri, 19 Mar 2004 08:25:56 -0800 From: "Mark C. Langston" To: IETF MXCOMP Subject: Re: when spoofing isn't Message-ID: <20040319162556.GA67093@bitshift.org> References: <20040318144600.GJ8016@dumbo.pobox.com> <20040318155020.GM8016@dumbo.pobox.com> <20040318162022.GO8016@dumbo.pobox.com> <20040318181323.GO8629@bitshift.org> <20040319012228.GQ8016@dumbo.pobox.com> <8197999.20040318192605@brandenburg.com> <20040319050114.GJ49487@bitshift.org> <403091675.20040319000405@brandenburg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <403091675.20040319000405@brandenburg.com> User-Agent: Mutt/1.4.1i X-Uptime: 8:24AM up 276 days, 11:34, 6 users, load averages: 0.06, 0.08, 0.02 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Mar 19, 2004 at 12:04:05AM -0800, Dave Crocker wrote: > Mark, > > MCL> If the service provider has clauses in their acceptable use policy (as > MCL> many seem to, these days) that specify that mail headers may not be > > > that is the nice thing about citing a hypothetical. it is certain to > support whatever position you want. > > it does not, however, justify a course of action that eliminates > legitimate uses of long-standing facilities. I agree completely. I'm firmly on the side of "let's not break things." -- Mark C. Langston Sr. Unix SysAdmin mark@bitshift.org mark@seti.org Systems & Network Admin SETI Institute http://bitshift.org http://www.seti.org From owner-ietf-mxcomp Fri Mar 19 08:49:58 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JGnvam042644; Fri, 19 Mar 2004 08:49: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 i2JGnvJA042643; Fri, 19 Mar 2004 08:49:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from dedicated60-bos.wh.sprintip.net (smtp.sprintpcs.com [63.167.114.16]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JGnvgM042636 for ; Fri, 19 Mar 2004 08:49:57 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from solidmatrix.com (014-513-997.area3.spcsdns.net [68.244.154.180]) by dedicated60-bos.wh.sprintip.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPA id <0HUU00EF0157HV@dedicated60-bos.wh.sprintip.net> for ietf-mxcomp@imc.org; Fri, 19 Mar 2004 16:44:31 +0000 (GMT) Date: Fri, 19 Mar 2004 11:44:32 -0500 From: Yakov Shafranovich Subject: Re: when spoofing isn't In-reply-to: <20040319162556.GA67093@bitshift.org> To: "Mark C. Langston" Cc: IETF MXCOMP Message-id: <405B2370.7040102@solidmatrix.com> Organization: SolidMatrix Technologies, Inc. MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en, he, ru User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime References: <20040318144600.GJ8016@dumbo.pobox.com> <20040318155020.GM8016@dumbo.pobox.com> <20040318162022.GO8016@dumbo.pobox.com> <20040318181323.GO8629@bitshift.org> <20040319012228.GQ8016@dumbo.pobox.com> <8197999.20040318192605@brandenburg.com> <20040319050114.GJ49487@bitshift.org> <403091675.20040319000405@brandenburg.com> <20040319162556.GA67093@bitshift.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Mark C. Langston wrote: > On Fri, Mar 19, 2004 at 12:04:05AM -0800, Dave Crocker wrote: > >>Mark, >> >>MCL> If the service provider has clauses in their acceptable use policy (as >>MCL> many seem to, these days) that specify that mail headers may not be >> >> >> that is the nice thing about citing a hypothetical. it is certain to >> support whatever position you want. >> >> it does not, however, justify a course of action that eliminates >> legitimate uses of long-standing facilities. > > I agree completely. I'm firmly on the side of "let's not break things." > Some things are going to break. If the benefit of breaking them is much greater than the cost from the breakage that it might be worth it. We should not say that we absolutely will not change anything, rather we need to look at costs and benefits, and figure out how to break the least number of things while achieving the greatest benefit. Yakov From owner-ietf-mxcomp Fri Mar 19 09:01:39 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JH1dvL043592; Fri, 19 Mar 2004 09:01: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 i2JH1dKb043591; Fri, 19 Mar 2004 09:01:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JH1cR1043583 for ; Fri, 19 Mar 2004 09:01:39 -0800 (PST) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-19-105.client.comcast.net [24.6.19.105]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i2JH1aiL006215 for ; Fri, 19 Mar 2004 09:01:37 -0800 (PST) Received: by tethys.bitshift.org (Postfix, from userid 1001) id CD15E2288D; Fri, 19 Mar 2004 09:01:36 -0800 (PST) Date: Fri, 19 Mar 2004 09:01:36 -0800 From: "Mark C. Langston" To: IETF MXCOMP Subject: Re: when spoofing isn't Message-ID: <20040319170136.GB67093@bitshift.org> References: <20040318144600.GJ8016@dumbo.pobox.com> <20040318155020.GM8016@dumbo.pobox.com> <20040318162022.GO8016@dumbo.pobox.com> <20040318181323.GO8629@bitshift.org> <20040319012228.GQ8016@dumbo.pobox.com> <8197999.20040318192605@brandenburg.com> <20040319050114.GJ49487@bitshift.org> <403091675.20040319000405@brandenburg.com> <20040319162556.GA67093@bitshift.org> <405B2370.7040102@solidmatrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <405B2370.7040102@solidmatrix.com> User-Agent: Mutt/1.4.1i X-Uptime: 8:57AM up 276 days, 12:06, 6 users, load averages: 0.00, 0.00, 0.00 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Mar 19, 2004 at 11:44:32AM -0500, Yakov Shafranovich wrote: > > Some things are going to break. If the benefit of breaking them is much > greater than the cost from the breakage that it might be worth it. We > should not say that we absolutely will not change anything, rather we > need to look at costs and benefits, and figure out how to break the > least number of things while achieving the greatest benefit. > That's what I meant. I should have said, "Let's not break things unnecessarily." My biggest concern at the moment is that we not place too great an onus on the MUA due to MTA changes, lest we create breakage for entire classes of service, such as SMTP via cellphone. -- Mark C. Langston Sr. Unix SysAdmin mark@bitshift.org mark@seti.org Systems & Network Admin SETI Institute http://bitshift.org http://www.seti.org From owner-ietf-mxcomp Fri Mar 19 09:31:38 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JHVcOm045485; Fri, 19 Mar 2004 09:31: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 i2JHVcCc045484; Fri, 19 Mar 2004 09:31:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JHVboC045477 for ; Fri, 19 Mar 2004 09:31:37 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.11/) with ESMTP id i2JHUX7Q009710; Fri, 19 Mar 2004 09:30:34 -0800 (PST) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Fri, 19 Mar 2004 09:30:33 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Mark C. Langston'" , IETF MXCOMP Subject: RE: when spoofing isn't Date: Fri, 19 Mar 2004 09:30:27 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > I agree completely. I'm firmly on the side of "let's not > break things." I am firmly on the side of breaking the Internet for the spammers. I don't think that there is much value in envelope from alone. It has to be matched to either an accreditation or to one of the other headers _that_the_user_will_see From owner-ietf-mxcomp Fri Mar 19 09:46:30 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JHkUXc046275; Fri, 19 Mar 2004 09:46: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 i2JHkU6c046274; Fri, 19 Mar 2004 09:46:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.40]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JHkTG5046266 for ; Fri, 19 Mar 2004 09:46:29 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.50] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1B4O3e-0000AL-00; Fri, 19 Mar 2004 12:45:22 -0500 Received: from [68.244.154.180] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1B4O3d-0001cW-00; Fri, 19 Mar 2004 12:45:22 -0500 Message-ID: <405B31A6.8020101@solidmatrix.com> Date: Fri, 19 Mar 2004 12:45:10 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: "Hallam-Baker, Phillip" CC: "'Mark C. Langston'" , IETF MXCOMP Subject: Re: when spoofing isn't References: In-Reply-To: X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hallam-Baker, Phillip wrote: > >>I agree completely. I'm firmly on the side of "let's not >>break things." > > > I am firmly on the side of breaking the Internet for the spammers. > But not for legit users. > I don't think that there is much value in envelope from alone. It has > to be matched to either an accreditation or to one of the other headers > _that_the_user_will_see > Let the MUA display the "Return Path" header which will be verified via MAIL FROM. Yakov From owner-ietf-mxcomp Fri Mar 19 09:53:18 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JHrIEK046735; Fri, 19 Mar 2004 09:53: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 i2JHrIlQ046734; Fri, 19 Mar 2004 09:53:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JHrIJi046727 for ; Fri, 19 Mar 2004 09:53:18 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2JI2Zd12282 for ; Fri, 19 Mar 2004 10:02:35 -0800 Date: Fri, 19 Mar 2004 09:53:10 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1885812560.20040319095310@brandenburg.com> To: IETF MXCOMP Subject: Re: when spoofing isn't In-Reply-To: <405B2370.7040102@solidmatrix.com> References: <20040318144600.GJ8016@dumbo.pobox.com> <20040318155020.GM8016@dumbo.pobox.com> <20040318162022.GO8016@dumbo.pobox.com> <20040318181323.GO8629@bitshift.org> <20040319012228.GQ8016@dumbo.pobox.com> <8197999.20040318192605@brandenburg.com> <20040319050114.GJ49487@bitshift.org> <403091675.20040319000405@brandenburg.com> <20040319162556.GA67093@bitshift.org> <405B2370.7040102@solidmatrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Folks, >>> it does not, however, justify a course of action that eliminates >>> legitimate uses of long-standing facilities. >> I agree completely. I'm firmly on the side of "let's not break things." >> YS> Some things are going to break. If the benefit of breaking them is much YS> greater than the cost from the breakage that it might be worth it. We There is an obvious and correct logic to your statement. However it has some very serious, real-world problems with it. Most of the problems involve perspective: The people who decide the value of a trade-off -- that is, _us_ -- are not the same as the people who must adopt the decision. In particular, the people who decide the value do not get to dictate to the adopters. Add to this mix a third group -- the people who must live with the results -- and predicting success becomes indirect and obscure. So, we have to worry very hard about the real incentives, not just the "logical" incentives. Basically, this requires being extraordinarily conservative in the assumptions we make about the rest of the world. Internet technology has been easy to upgrade when it has paid very, very careful attention to protection of the installed base. It has been very difficult to upgrade when that attention has been insufficient. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Fri Mar 19 10:03:10 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JI3Apc047570; Fri, 19 Mar 2004 10:03: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 i2JI3A1U047569; Fri, 19 Mar 2004 10:03:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JI39KA047563 for ; Fri, 19 Mar 2004 10:03:09 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.11/) with ESMTP id i2JI26am023369; Fri, 19 Mar 2004 10:02:06 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Fri, 19 Mar 2004 10:02:06 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Yakov Shafranovich'" , "Hallam-Baker, Phillip" Cc: "'Mark C. Langston'" , IETF MXCOMP Subject: RE: when spoofing isn't Date: Fri, 19 Mar 2004 10:01:59 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: For my particular domain verisign.com I want all email that does not originate from the verisign email servers to be eliminated. * No Web mails * No postcards * No cartoons from Cagle * No unauthorized laptops sending email directly. That is because we are in the payments and security business. I don't want Phishing scams pretending to come from the VeriSign domain. I don't think these are actually legit for any email address, the message does not come from me, it comes from Cagle or whoever has the web site. It should have their name on it, not mine. > Let the MUA display the "Return Path" header which will be > verified via MAIL FROM. Changing the MUAs is a completely unreasonable demand. Changing the ad hoc forwarding services to honestly describe themselves as such is a completely reasonable one. The easy way to address this is to add a flag onto the policy description: _spf.verisign.com TXT "IP:10.0.0.1/24 verify=rfc822" Or equivalent in your favorite syntax. All we are doing here is listing out the edge mail servers. You can play whatever games you like but this is where implementers will make their own decisions. If they want to check 822 headers they will. Rather than telling the postcard web sites that nothing is going to change it would be better to tell them how to change in a way that is going to maximize the chance their mail gets through. That is the reason that people are putting these records up, they want to maximize the probability that the email they source gets through. Phill From owner-ietf-mxcomp Fri Mar 19 10:25:09 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JIP92x049519; Fri, 19 Mar 2004 10:25:09 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2JIP9wJ049518; Fri, 19 Mar 2004 10:25:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JIP8Q8049511 for ; Fri, 19 Mar 2004 10:25:08 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.11/) with ESMTP id i2JIPCvw002218 for ; Fri, 19 Mar 2004 10:25:12 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Fri, 19 Mar 2004 10:25:12 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: IETF MXCOMP Subject: When spoofing is. Date: Fri, 19 Mar 2004 10:25:10 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Most of the problems involve perspective: The people who decide the > value of a trade-off -- that is, _us_ -- Actually the only people who get that choice are the people who write the filters and the people who insert the records. We don't actually have all that much influence unless they happen to like our trade offs. > Internet technology has been easy to upgrade when it has paid > very, very careful attention to protection of the installed > base. It has been very difficult to upgrade when that attention > has been insufficient. The issue is not the level of pain it is where it is felt. Is it going to be felt by people who are likely to change? Is it going to be felt by a constituency essential for adoption? In this case the pain felt by postcard services does not seem very important to me since they are not a constituency that is critical to the success of the spec, the value of the information they send is generally considered to be very very low and so there is little downside for the receivers. The postcard services won't be able to exist unless they change, it is easy for them to do so, therefore they will do it. In this particular case there is a very easy fix for the postcard sites, they just use their own name, not a random name that someone entered into a web form. they should have done that all along. Fixing other forwarding relationships is a little trickier but not all that hard. I think that the layout of the draft should be: 1. Definition of terms 2. Statements of the requirements addressed 3. Semantics of the DNS record entry (Normative) How to specify the set of outgoing mail server IP addresses By value (IPv4, IPv6) By reference (mx record, domain name, address lookup) Other authentication information STARTTLS always offered S/MIME always used Certificate validation Other server attributes Accreditation Frequent phishing target 4. Hints for filter writers (NON-Normative) At the gateway MTA Verifying HELO Verifying RFC 821 From Implications of forwarding services At other points MUA considerations MTA considerations Verifying RFC 822 From, Sender, Reply-to Implications of forwarding services 5. Hints for writers of mail services (NON-Normative) How to send postcards that get through every time How to forward email and get through every time 6. Security Considerations Email address spoofing IP spoofing (unlikely) DNS spoofing (preventable) DNS security issues 7. Acknowledgements 8. References Phill From owner-ietf-mxcomp Fri Mar 19 10:37:05 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JIb5BT050298; Fri, 19 Mar 2004 10:37:05 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2JIb5fs050297; Fri, 19 Mar 2004 10:37:05 -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 (srv1.pan-am.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JIb49i050288 for ; Fri, 19 Mar 2004 10:37:04 -0800 (PST) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: when spoofing isn't MIME-Version: 1.0 Date: Fri, 19 Mar 2004 12:37:07 -0600 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA7E8@srv1.pan-am.ca> X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: when spoofing isn't Thread-Index: AcQN2H7Pw0riEPFXTCqdmd4VZAmbWAAB2ZPg From: "Gordon Fecyk" To: "IETF MXCOMP" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2JIb49i050291 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Hallam-Baker, > Phillip > > I agree completely. I'm firmly on the side of "let's not > > break things." > > I don't think that there is much value in envelope from[2] alone. It has > to be matched to either an accreditation or to one of the > other headers _that_the_user_will_see[1] There are a whole mess of content filtering issues arising from going beyond the RFC 2821 envelope previously stated. Who was over from AOL that commented they could possibly be banned from filtering on content by certain governments? That, costs of running said accreditations and an unwillingless to pay for said accreditation, mailing lists that use different envelopes than headers as Dave pointed out, are all liabilities caused by going beyond the RFC 2821 envelope. I have to agree with Dave that matching RFC2821 envelopes to RFC2822 headers is better off in the hands of the user, as in the final recipient of a message. I would not want pan-am.ca as a domain doing this, but I'd show my users how to do this. [1] I won't say it, it's too easy. [2] Be specific. Do you mean the RFC 2821 envelope MAIL FROM: ? -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Fri Mar 19 10:37:34 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JIbXDF050560; Fri, 19 Mar 2004 10:37: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 i2JIbXXY050559; Fri, 19 Mar 2004 10:37:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (IDENT:root@ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JIbX8j050549 for ; Fri, 19 Mar 2004 10:37:33 -0800 (PST) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-19-105.client.comcast.net [24.6.19.105]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i2JIbXiL029096 for ; Fri, 19 Mar 2004 10:37:33 -0800 (PST) Received: by tethys.bitshift.org (Postfix, from userid 1001) id 528B222887; Fri, 19 Mar 2004 10:37:33 -0800 (PST) Date: Fri, 19 Mar 2004 10:37:33 -0800 From: "Mark C. Langston" To: IETF MXCOMP Subject: Re: when spoofing isn't Message-ID: <20040319183733.GC67093@bitshift.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Uptime: 10:25AM up 276 days, 13:35, 7 users, load averages: 0.05, 0.01, 0.00 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Mar 19, 2004 at 10:01:59AM -0800, Hallam-Baker, Phillip wrote: > For my particular domain verisign.com I want all email that does not > originate from the verisign email servers to be eliminated. > > * No Web mails > * No postcards > * No cartoons from Cagle > * No unauthorized laptops sending email directly. > > That is because we are in the payments and security business. I don't > want Phishing scams pretending to come from the VeriSign domain. > > I don't think these are actually legit for any email address, the > message does not come from me, it comes from Cagle or whoever has > the web site. It should have their name on it, not mine. > Which don't you view as legitimate, the services you mention above, or those services with verisign.com as the primary identity used in the outgoing emails? > > All we are doing here is listing out the edge mail servers. You can > play whatever games you like but this is where implementers will make > their own decisions. If they want to check 822 headers they will. > ...which is fine, for people that want to have a way to authoritatively identify a short list of allowed MTAs for a given domain. But we shouldn't necessarily break things for those who don't wish to or can't o do so (e.g., MUA direct-to-recipient-MX connections). If we are in fact going down the path that leads to the end of MUA direct-to-recipient-MX connections, we should acknowledge that. > Rather than telling the postcard web sites that nothing is going to > change it would be better to tell them how to change in a way that > is going to maximize the chance their mail gets through. > > That is the reason that people are putting these records up, they > want to maximize the probability that the email they source gets > through. > I was thinking about this yesterday. The original trust model for email is "trust everyone". Obviously, that's led to some problems. However, the approach I see you taking is changing the trust model to "trust no one, except for [insert method here that modifies trust positively]." We should also consider a third trust model, which would be "trust-neutral": Neither trust nor distrust a given piece of email, except for [insert method here that alters trust positively or negatively, and carry forward that trust to future interactions]. -- Mark C. Langston Sr. Unix SysAdmin mark@bitshift.org mark@seti.org Systems & Network Admin SETI Institute http://bitshift.org http://www.seti.org From owner-ietf-mxcomp Fri Mar 19 10:58:54 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JIwrXN052617; Fri, 19 Mar 2004 10:58: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 i2JIwruE052616; Fri, 19 Mar 2004 10:58:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (IDENT:root@ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JIwr4E052608 for ; Fri, 19 Mar 2004 10:58:53 -0800 (PST) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-19-105.client.comcast.net [24.6.19.105]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i2JIwqiL004069 for ; Fri, 19 Mar 2004 10:58:53 -0800 (PST) Received: by tethys.bitshift.org (Postfix, from userid 1001) id D54B822887; Fri, 19 Mar 2004 10:58:52 -0800 (PST) Date: Fri, 19 Mar 2004 10:58:52 -0800 From: "Mark C. Langston" To: IETF MXCOMP Subject: Re: When spoofing is. Message-ID: <20040319185852.GE67093@bitshift.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Uptime: 10:25AM up 276 days, 13:35, 7 users, load averages: 0.05, 0.01, 0.00 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Mar 19, 2004 at 10:25:10AM -0800, Hallam-Baker, Phillip wrote: > > The issue is not the level of pain it is where it is felt. Is it going > to be felt by people who are likely to change? More importantly, is it going to be felt by people who are able to change? If our solution requires, for example, the use of certain MUA features that may not be present in all deployed MUAs, the end-users may be faced with a no-win situation: They can't send mail using the MUA in question, and they may not be able to change MUAs (again, I'll raise the example of a cellphone MUA. These are typically not end-user upgradeable, and the cellphone providers seem somewhat slow in rolling out new firmware which adds features. This is further complicated by the existence of phones which to not have the ability to receive firmware updates via the cell radio, but instead require a trip to a provider brick-and-mortar to get the firmware installed). Certainly, the cellphone example is a bit of an extreme case, but it's illustrative of the ease with which what seems an otherwise innocuous change can have lasting impact on an entire class of end-users. > > In this case the pain felt by postcard services does not seem very important > to me since they are not a constituency that is critical to the success > of the spec, the value of the information they send is generally considered > to be very very low and so there is little downside for the receivers. The > postcard services won't be able to exist unless they change, it is easy > for them to do so, therefore they will do it. Value is a relative term. The value of such a service may seem low to you, but the value to the service users and providers is almost certainly higher. This is, I believe, one of the points Dave was trying to make. We need to be very careful about such assumptions. > > In this particular case there is a very easy fix for the postcard sites, > they just use their own name, not a random name that someone entered > into a web form. they should have done that all along. > So, how should the recipient identify the entity that caused the card to be sent, and how should the recipient reply to that entity? -- Mark C. Langston Sr. Unix SysAdmin mark@bitshift.org mark@seti.org Systems & Network Admin SETI Institute http://bitshift.org http://www.seti.org From owner-ietf-mxcomp Fri Mar 19 11:22:24 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JJMO28053841; Fri, 19 Mar 2004 11:22: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 i2JJMOiF053840; Fri, 19 Mar 2004 11:22:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.40]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JJMN1j053834 for ; Fri, 19 Mar 2004 11:22:23 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.50] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1B4PZ1-0005Gw-00; Fri, 19 Mar 2004 14:21:51 -0500 Received: from [68.244.224.192] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1B4PZ0-0005B7-00; Fri, 19 Mar 2004 14:21:51 -0500 Message-ID: <405B4844.5030607@solidmatrix.com> Date: Fri, 19 Mar 2004 14:21:40 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: "Hallam-Baker, Phillip" CC: "'Mark C. Langston'" , IETF MXCOMP Subject: Re: when spoofing isn't References: In-Reply-To: X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hallam-Baker, Phillip wrote: >>Let the MUA display the "Return Path" header which will be >>verified via MAIL FROM. > > > Changing the MUAs is a completely unreasonable demand. Changing the > ad hoc forwarding services to honestly describe themselves as such > is a completely reasonable one. > So I am assuming that you want the "From" header to be checked at the MTA level during the DATA command. Doesn't MSFT's CID proposal check headers at MUA level? They don't seen to have a problem with MUA changes but then again they develop 70% of MUAs in the world. I am not against checking MAIL FROM, but checking RFC2822 headers brings up a host of other issues which are difficult to deal with. It will break more functionality than RFC2821 headers, and is more difficult to implement. Therefore, if we want to be moving in that direction, we need to evaluate issues much more carefully. > > The easy way to address this is to add a flag onto the policy > description: > > _spf.verisign.com TXT "IP:10.0.0.1/24 verify=rfc822" > > Or equivalent in your favorite syntax. > Key word "policy description". This group is concerned with a very small goal - authorization records for MTAs or in your own words "listing out the edge mail servers". We are not making generic policy exchange mechanisms - if you want to make those, then we need to restate the problem and evaluate it from that angle. Otherwise, you will end up overloading MARID for the purposes it was not intended to be. > > All we are doing here is listing out the edge mail servers. You can > play whatever games you like but this is where implementers will make > their own decisions. If they want to check 822 headers they will. > I am not so sure. It would greatly help if we can get feedback from actual people who will be implemented since neither Verisign nor SolidMatrix is in the business of making email filters. > Rather than telling the postcard web sites that nothing is going to > change it would be better to tell them how to change in a way that > is going to maximize the chance their mail gets through. > > That is the reason that people are putting these records up, they > want to maximize the probability that the email they source gets > through. > I am not sure I get this. If we verify MAIL FROM, then the greeting cards companies are changing anyway? Yakov From owner-ietf-mxcomp Fri Mar 19 11:28:00 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JJS0j8054068; Fri, 19 Mar 2004 11:28: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 i2JJS0nb054067; Fri, 19 Mar 2004 11:28:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.41]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JJRxou054061 for ; Fri, 19 Mar 2004 11:27:59 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.50] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1B4Pez-0003sN-00; Fri, 19 Mar 2004 14:28:01 -0500 Received: from [68.244.224.192] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1B4Pex-0005Q8-00; Fri, 19 Mar 2004 14:28:01 -0500 Message-ID: <405B49B4.4010907@solidmatrix.com> Date: Fri, 19 Mar 2004 14:27:48 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: "Hallam-Baker, Phillip" CC: IETF MXCOMP Subject: Re: When spoofing is. References: In-Reply-To: X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hallam-Baker, Phillip wrote: > >>Most of the problems involve perspective: The people who decide the >>value of a trade-off -- that is, _us_ -- > > > Actually the only people who get that choice are the people who write > the filters and the people who insert the records. We don't actually > have all that much influence unless they happen to like our trade offs. > So perhaps it would help if we can get feedback from those people directly. We need to get some realistic real world feedback on this kind of stuff, since we are working on assumptions here. Otherwise, if this is a case of "I said" and "you said", we need to be conservative since we simply don't know otherwise. > >>Internet technology has been easy to upgrade when it has paid >>very, very careful attention to protection of the installed >>base. It has been very difficult to upgrade when that attention >>has been insufficient. > > > The issue is not the level of pain it is where it is felt. Is it going > to be felt by people who are likely to change? Is it going to be > felt by a constituency essential for adoption? > We don't have that information. We are basing this discussion on our assumptions, so unless we clearly have information to point us, like Dave said we should try to be conservative. > In this case the pain felt by postcard services does not seem very important > to me since they are not a constituency that is critical to the success > of the spec, the value of the information they send is generally considered > to be very very low and so there is little downside for the receivers. The > postcard services won't be able to exist unless they change, it is easy > for them to do so, therefore they will do it. > I am not sure if American Greetings and their customers will agree with you. The players that are actually ones who will implement this and change are not present here - they need to be informed and engaged, because I can bet you that we don't even realize half of the issues involved with this, that those companies can point out to us. Otherwise, I would stick with the smallest changes possible. > I think that the layout of the draft should be: > ... > Other authentication information > STARTTLS always offered > S/MIME always used > Certificate validation > Other server attributes > Accreditation > Frequent phishing target This is generic policy stuff - we don't want to get into that. It is a much bigger can of worms than you think. Yakov From owner-ietf-mxcomp Fri Mar 19 11:34:40 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JJYd21054492; Fri, 19 Mar 2004 11:34: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 i2JJYdce054491; Fri, 19 Mar 2004 11:34:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JJYdhH054484 for ; Fri, 19 Mar 2004 11:34:39 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.11/) with ESMTP id i2JJYDKL027026; Fri, 19 Mar 2004 11:34:13 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Fri, 19 Mar 2004 11:34:12 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Yakov Shafranovich'" , "Hallam-Baker, Phillip" Cc: "'Mark C. Langston'" , IETF MXCOMP Subject: RE: when spoofing isn't Date: Fri, 19 Mar 2004 11:34:09 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > So I am assuming that you want the "From" header to be checked at the > MTA level during the DATA command. Doesn't MSFT's CID proposal check > headers at MUA level? They don't seen to have a problem with > MUA changes but then again they develop 70% of MUAs in the world. Convince them to participate in the group, and that they would change to doing it the way you suggest and you might have a point. But even so, any change to the client population takes about four years to be deployed. I use a version of outlook that shipped in 1999. changes to clients take much much longer to achieve than changes to servers and services. > I am not against checking MAIL FROM, but checking RFC2822 > headers brings > up a host of other issues which are difficult to deal with. So tell people it is hard, give them a list of the pitfalls to consider. They are most likely to either decide to do it another way or to do it right. > Key word "policy description". This group is concerned with a > very small > goal - authorization records for MTAs or in your own words > "listing out > the edge mail servers". We are not making generic policy exchange > mechanisms - if you want to make those, then we need to restate the > problem and evaluate it from that angle. Otherwise, you will end up > overloading MARID for the purposes it was not intended to be. The charter does not limit the scope to envelope from or to data from. It seems strange to argue that therefore we have to pick one and only one. > I am not sure I get this. If we verify MAIL FROM, then the greeting > cards companies are changing anyway? The greeting card companies will not be sending messages that falsely claim to come from another party as they do today. Phill From owner-ietf-mxcomp Fri Mar 19 11:47:14 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JJlEVN055227; Fri, 19 Mar 2004 11:47: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 i2JJlEau055226; Fri, 19 Mar 2004 11:47:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (IDENT:root@ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JJlDTt055219 for ; Fri, 19 Mar 2004 11:47:13 -0800 (PST) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-19-105.client.comcast.net [24.6.19.105]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i2JJlEiL014284; Fri, 19 Mar 2004 11:47:14 -0800 (PST) Received: by tethys.bitshift.org (Postfix, from userid 1001) id 49F7322887; Fri, 19 Mar 2004 11:47:14 -0800 (PST) Date: Fri, 19 Mar 2004 11:47:14 -0800 From: "Mark C. Langston" To: IETF MXCOMP Cc: Yakov Shafranovich Subject: Re: When spoofing is. Message-ID: <20040319194714.GG67093@bitshift.org> References: <405B49B4.4010907@solidmatrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <405B49B4.4010907@solidmatrix.com> User-Agent: Mutt/1.4.1i X-Uptime: 11:44AM up 276 days, 14:53, 7 users, load averages: 0.00, 0.00, 0.00 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Mar 19, 2004 at 02:27:48PM -0500, Yakov Shafranovich wrote: > > Hallam-Baker, Phillip wrote: > > > >>Most of the problems involve perspective: The people who decide the > >>value of a trade-off -- that is, _us_ -- > > > > > >Actually the only people who get that choice are the people who write > >the filters and the people who insert the records. We don't actually > >have all that much influence unless they happen to like our trade offs. > > > > So perhaps it would help if we can get feedback from those people > directly. We need to get some realistic real world feedback on this kind > of stuff, since we are working on assumptions here. Otherwise, if this > is a case of "I said" and "you said", we need to be conservative since > we simply don't know otherwise. > Well, if it helps, I'll be the one inserting the records here, and I'm currently experimenting with filter writing (more specifically, milter writing). -- Mark C. Langston Sr. Unix SysAdmin mark@bitshift.org mark@seti.org Systems & Network Admin SETI Institute http://bitshift.org http://www.seti.org From owner-ietf-mxcomp Fri Mar 19 11:51:11 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JJpBHu055578; Fri, 19 Mar 2004 11:51: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 i2JJpBBo055577; Fri, 19 Mar 2004 11:51:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.41]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JJpAHI055571 for ; Fri, 19 Mar 2004 11:51:10 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.52] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1B4Q0W-00070n-00; Fri, 19 Mar 2004 14:50:16 -0500 Received: from [68.244.224.192] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1B4Q0V-0005gU-00; Fri, 19 Mar 2004 14:50:16 -0500 Message-ID: <405B4ED6.508@solidmatrix.com> Date: Fri, 19 Mar 2004 14:49:42 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: "Hallam-Baker, Phillip" CC: "'Mark C. Langston'" , IETF MXCOMP Subject: Re: when spoofing isn't References: In-Reply-To: X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hallam-Baker, Phillip wrote: > >>Key word "policy description". This group is concerned with a >>very small >>goal - authorization records for MTAs or in your own words >>"listing out >>the edge mail servers". We are not making generic policy exchange >>mechanisms - if you want to make those, then we need to restate the >>problem and evaluate it from that angle. Otherwise, you will end up >>overloading MARID for the purposes it was not intended to be. > > > The charter does not limit the scope to envelope from or to data > from. It seems strange to argue that therefore we have to pick one > and only one. > You are right, I assumed that you are looking at MARID as a generic policy mechanism. I have no problems with ability to indicate multiple identities being in there, as long as it does not devolve into a generic mechanism. Allowing an ability for the sender to indicate a specific identity might be one possible solution. I would rather see such ability if put in, to be normative, rather than non-normative. Yakov From owner-ietf-mxcomp Fri Mar 19 12:07:52 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JK7qPF056676; Fri, 19 Mar 2004 12:07: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 i2JK7qB7056675; Fri, 19 Mar 2004 12:07:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [64.139.47.218]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JK7qrT056669 for ; Fri, 19 Mar 2004 12:07:52 -0800 (PST) (envelope-from gconnor@nekodojo.org) Received: from gconnor.corp.yahoo.com (gconnor.corp.yahoo.com [216.145.58.43]) (authenticated) by neko-base.nekodojo.org (8.11.6/8.11.6) with ESMTP id i2JK7ul03645 for ; Fri, 19 Mar 2004 12:07:56 -0800 Date: Fri, 19 Mar 2004 12:07:32 -0800 From: Greg Connor To: IETF MXCOMP Subject: Re: when spoofing isn't Message-ID: <7371920.1079698052@gconnor.corp.yahoo.com> In-Reply-To: <20040319162556.GA67093@bitshift.org> References: <20040319162556.GA67093@bitshift.org> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello- I agree with Wayne and Yakov (and others) that validating RFC2821 MAIL FROM is "a good place to start". I would *like* to see some more controls on the RFC2822 From: and other headers, but frankly, I don't think we have done enough research and field testing to support those controls -- yet. (Or perhaps we have and the results haven't been distributed widely :) Similarly, I think RFC2821 HELO checking can produce some useful results (especially in blocking really blatant forgeries like HELO microsoft.com or HELO using the recipient's own domain.) But, I'm cautious about this as well. Let me throw some ideas out here and you can all either praise or mock them :) Points 1-4 below can be taken individually or together in combination... If you disagree with any of 1-4 please say which ones you do or don't agree with for the sake of clarity. 1. RFC2821 MAIL FROM identified as Phase One of the designated sender program. Pros: + Mail can be blocked before DATA phase, saving bandwidth + Helps to reduce bounce-spam, which is an incentive to adopt + Visible to users and helpstaff as "Return-Path" (usually) Cons: - "Nearly invisible" to novice users - Doesn't effectively stop phishing or other forgeries aimed at tricking users - Need a "fallback plan" for MAIL FROM: <> 2. RFC2822 From: Sender: etc. calls for "more research and testing" Questions: ? In a large/diverse set of "good mail" does Return-Path match one of From, Sender, Resent-From, Resent-Sender? ? If there is a strong correlation, would we benefit by warning the user when the Return-Path *doesn't* match one of the headers? ? In the case of VERP (and SRS) Return-Path will not match. Can we decode the Return-Path and match, or can we get a partial match only on domain? My guess is that RFC2821 MAIL FROM will match From: or Sender: most of the time. But, spammers/phishers are crafty- if MAIL FROM / Return-Path validation starts in earnest, they may start to diverge from this. Spammers will change their behavior a lot faster than admins will update their normal MTAs. If we want to validate RFC2822 From: address as Phase 2, let's start this research now. If we can anticipate the logical "next move" by the spammer we can be ready. 3. Provide recommendations to MUA developers, but don't depend on them for our efforts to succeed. MUA developers can take advantage of our efforts right away, by way of * Allow the user to view Return-Path * Allow the user to view sender authentication info if present in headers * If sender authentication succeeds, and the From: address matches it, provide some visible feedback (such as a green check mark next to From:) * If sender authentication presents any warnings (such as From:/Return-Path: mismatch) provide visible feedback (like a ! mark next to From:) However, assuming NO action on the part of MUA developers, we could provide some results to the user right away. These could be optional features that the receiver's MTA could turn on or off as appropriate: * Possibility to add text to the From: address (not part but "Visible" part) such as "(unverified)" or "(possibly forged)" * Possibility to add text to the subject * Possibility to add text to the body of the message, though in the case of MIME we would have to proceed carefully. * Possibility to defang the MIME parts and substitute our own visible part, similar to Spamassassin ("This message may be forged. The original message is added as an attachment. Some suspicious attachments have been dropped. etc") 4. Some checking of RFC 2821 HELO might be helpful but this should not be the main focus of the sender authentication effort. For example, SPF uses HELO as a fallback when MAIL FROM: <> - in this case, you would limit your possible "false positive" result to blocking bounce reports from badly-configured mailers, and those mailers could still send you normal mail, just not bounces. However, some users have reported that they get really great results from blocking "obviously forged" HELO names, and leaving other questionable HELO results alone. For example, my servers might HELO with "mail1.example.com" or "mail2.example.com" and no legitimate server should ever HELO with just "example.com", so I can safely block those. There may be servers with short (mail1), private (mail1.corp.internal), or obviously fake (localhost.localdomain) HELO names but we probably don't want to tackle those yet. More research/testing would be good here too. Therefore, HELO may not want to be included in Phase 1 - we may choose to focus only on MAIL FROM for Phase 1, so that we don't blur the message or confuse people... but I don't have a strong opinion here so I'm interested in everyone else's feedback. Who knows... if we could provide a conservative strategy for HELO and roll it out, that might add lots of great results for relatively little cost. -- Greg Connor From owner-ietf-mxcomp Fri Mar 19 12:18:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JKIXKZ057606; Fri, 19 Mar 2004 12: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 i2JKIXNh057605; Fri, 19 Mar 2004 12:18:33 -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 (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JKISqZ057596 for ; Fri, 19 Mar 2004 12:18:32 -0800 (PST) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.30) id 1B4QRs-0007kU-KO for ietf-mxcomp@imc.org; Fri, 19 Mar 2004 14:18:32 -0600 To: "IETF MXCOMP" Subject: Re: When spoofing is. References: From: wayne Content-Type: text/plain; charset=US-ASCII Date: Fri, 19 Mar 2004 14:18:32 -0600 In-Reply-To: (Phillip Hallam-Baker's message of "Fri, 19 Mar 2004 10:25:10 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (spfd: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In "Hallam-Baker, Phillip" writes: > > Fixing other forwarding relationships is a little trickier but not > all that hard. "Not all that hard." Hmmm... I disagree. There are a lot of options for email forwarders, none of them are pretty. I think we will sink a lot of time into this subject alone, even if we limit it to RFC2821 data. > I think that the layout of the draft should be: > > 4. Hints for filter writers (NON-Normative) > At other points > MUA considerations > Verifying RFC 822 From, Sender, Reply-to The only "MUA consideration" and RFC2822 data verification stuff I think should be put into the RFC is a list of known problems and a recommendation proceed with extreme caution. On the SPF-discuss list, we had the following exchange: : > Trying to determine how far down the Received: chain you can trust can : > be a real challenge, but there are reasonably good techniques for : > doing so. : : It is near to impossible one one message alone unless you have the : user configure it for you (not happening for most users) : : But it is quite easy on a series of messages. The funny thing is that just yesterday, SpamCop started to roll out a change in their system that requires every SpamCop user to specify their trusted incoming email routing. Spammers have gotten good enough with forging headers, that the SpamCop folks have given up trying to figure out how far down the Received: chain you can trust. This is despite the fact that they are sharp cookies, know a lot about email, have been working in the area of RFC2822 header analysis for years, and have collected a great deal of data about email relationships. I'm sorry, but I'm *very* skeptical of trying to do anything with the RFC2822 data. Until someone comes up with a specific program (preferably open source so that it can be experimented with) that can be shown to do a good job on real live data, I will object to trying to add this to the RFC. I do not think we can get a useful RFC out in a reasonable amount of time and have any confidence that RFC2822 checking is correct. Phill: Do you have code that verifies the RFC2822 data? Can you show it to us? -wayne From owner-ietf-mxcomp Fri Mar 19 12:18:37 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JKIaFI057621; Fri, 19 Mar 2004 12:18:36 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2JKIaYQ057620; Fri, 19 Mar 2004 12:18:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JKIacS057598 for ; Fri, 19 Mar 2004 12:18:36 -0800 (PST) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-19-105.client.comcast.net [24.6.19.105]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i2JKIZiL021183 for ; Fri, 19 Mar 2004 12:18:35 -0800 (PST) Received: by tethys.bitshift.org (Postfix, from userid 1001) id 5950C22887; Fri, 19 Mar 2004 12:18:35 -0800 (PST) Date: Fri, 19 Mar 2004 12:18:35 -0800 From: "Mark C. Langston" To: IETF MXCOMP Subject: Re: when spoofing isn't Message-ID: <20040319201835.GH67093@bitshift.org> References: <20040319162556.GA67093@bitshift.org> <7371920.1079698052@gconnor.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7371920.1079698052@gconnor.corp.yahoo.com> User-Agent: Mutt/1.4.1i X-Uptime: 12:12PM up 276 days, 15:21, 7 users, load averages: 0.06, 0.05, 0.01 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Mar 19, 2004 at 12:07:32PM -0800, Greg Connor wrote: > > My guess is that RFC2821 MAIL FROM will match From: or Sender: most of the > time. But, spammers/phishers are crafty- if MAIL FROM / Return-Path > validation starts in earnest, they may start to diverge from this. > Spammers will change their behavior a lot faster than admins will update > their normal MTAs. If we want to validate RFC2822 From: address as Phase > 2, let's start this research now. If we can anticipate the logical "next > move" by the spammer we can be ready. > But here, you assume that the RFC2822 identities would be the logical next target. I'd think that the spammers would be more likely to take a less subtle approach and try to subvert the authorization mechanism. In the case of several approaches, this would mean DNS poisoning, denial of service attacks against nameservers, and other such trickery. -- Mark C. Langston Sr. Unix SysAdmin mark@bitshift.org mark@seti.org Systems & Network Admin SETI Institute http://bitshift.org http://www.seti.org From owner-ietf-mxcomp Fri Mar 19 13:08:58 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JL8wZk060882; Fri, 19 Mar 2004 13:08: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 i2JL8wx0060881; Fri, 19 Mar 2004 13:08:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [64.139.47.218]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JL8vso060875 for ; Fri, 19 Mar 2004 13:08:58 -0800 (PST) (envelope-from gconnor@nekodojo.org) Received: from gconnor.corp.yahoo.com (gconnor.corp.yahoo.com [216.145.58.43]) (authenticated) by neko-base.nekodojo.org (8.11.6/8.11.6) with ESMTP id i2JL92l04841 for ; Fri, 19 Mar 2004 13:09:02 -0800 Date: Fri, 19 Mar 2004 13:08:40 -0800 From: Greg Connor To: IETF MXCOMP Subject: Re: when spoofing isn't Message-ID: <11039584.1079701719@gconnor.corp.yahoo.com> In-Reply-To: <20040319201835.GH67093@bitshift.org> References: <20040319201835.GH67093@bitshift.org> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > On Fri, Mar 19, 2004 at 12:07:32PM -0800, Greg Connor wrote: >> >> My guess is that RFC2821 MAIL FROM will match From: or Sender: most of >> the time. But, spammers/phishers are crafty- if MAIL FROM / >> Return-Path validation starts in earnest, they may start to diverge >> from this. Spammers will change their behavior a lot faster than admins >> will update their normal MTAs. If we want to validate RFC2822 From: >> address as Phase 2, let's start this research now. If we can >> anticipate the logical "next move" by the spammer we can be ready. --"Mark C. Langston" wrote: > But here, you assume that the RFC2822 identities would be the logical > next target. I'd think that the spammers would be more likely to take a > less subtle approach and try to subvert the authorization mechanism. In > the case of several approaches, this would mean DNS poisoning, denial of > service attacks against nameservers, and other such trickery. I'm assuming that RFC2822 is "a" logical next target, but not the only one. It is possible for spammers to use a different domain in the envelope than what's in the data, but it's not the only reaction possible. The other reactions you stated are quite possible too, as well as others. (Also, spammers will not move as a group, they will probably move in ALL available directions at once :) There is a good reason for checking RFC2822 From: - that is, it is highly visible to the user. If we plan to start protecting that, sometime in the future, we might benefit a great deal by finding out where it already matches RFC2821 MAIL FROM and warning the user if it starts to NOT match. But, I'm not actually suggesting anything to be done with RFC2822 headers right now, apart from researching what patterns exist now. How do people feel about coming up with a draft RFC that focuses on RFC2821 MAIL FROM first and following up with a DATA/Headers extension to it later? Can we have multiple draft RFC's come from the same working group? -- Greg Connor From owner-ietf-mxcomp Fri Mar 19 13:36:40 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JLae3I063179; Fri, 19 Mar 2004 13:36: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 i2JLaeLv063178; Fri, 19 Mar 2004 13:36:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JLaeMT063172 for ; Fri, 19 Mar 2004 13:36:40 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.11/) with ESMTP id i2JLagd6016459; Fri, 19 Mar 2004 13:36:42 -0800 (PST) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Fri, 19 Mar 2004 13:36:42 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Greg Connor'" , IETF MXCOMP Subject: RE: when spoofing isn't Date: Fri, 19 Mar 2004 13:36:37 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > How do people feel about coming up with a draft RFC that > focuses on RFC2821 > MAIL FROM first and following up with a DATA/Headers > extension to it later? > Can we have multiple draft RFC's come from the same working group? That is the usual approach. But if we are going to divide up the work this way we still need to think about the flag now. If MARID is going to gain traction it has to have at least the level of functionality that SPF and CID already provide. (Functionality <> features). I am going to strongly advise frequent phishing victims to deploy SPF, CallerID AND Marid as soon as possible. We are currently finding that the best means of discovery of a new attack is analyzing bounce messages. Phill From owner-ietf-mxcomp Fri Mar 19 13:41:53 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JLfrVh063391; Fri, 19 Mar 2004 13:41: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 i2JLfrs4063390; Fri, 19 Mar 2004 13:41:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JLfrEe063384 for ; Fri, 19 Mar 2004 13:41:53 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.11/) with ESMTP id i2JLfM6h004057; Fri, 19 Mar 2004 13:41:22 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Fri, 19 Mar 2004 13:41:22 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Mark C. Langston'" , IETF MXCOMP Subject: RE: when spoofing isn't Date: Fri, 19 Mar 2004 13:41:20 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > But here, you assume that the RFC2822 identities would be the logical > next target. I'd think that the spammers would be more > likely to take a > less subtle approach and try to subvert the authorization > mechanism. In > the case of several approaches, this would mean DNS > poisoning, denial of > service attacks against nameservers, and other such trickery. I think that the attacks you propose are brittle, entirely infeasible on a bulk basis even if the attackers had the ability. Forging RFC822 is trivial. How aout we compromise here? Put all the parts of the draft I suggest be non-normative off in a separate document. Focus on defining the normative text and getting that approved. The non-normative text is delivered when nits are ironed out. It would be informational so updates are much easier. From owner-ietf-mxcomp Fri Mar 19 13:44:17 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JLiHr2063488; Fri, 19 Mar 2004 13:44: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 i2JLiHT7063487; Fri, 19 Mar 2004 13:44:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.41]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JLiGWk063479 for ; Fri, 19 Mar 2004 13:44:17 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.50] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1B4Rmo-00028g-00; Fri, 19 Mar 2004 16:44:14 -0500 Received: from [68.244.224.192] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1B4Rmo-000232-00; Fri, 19 Mar 2004 16:44:14 -0500 Message-ID: <405B69A0.9050503@solidmatrix.com> Date: Fri, 19 Mar 2004 16:44:00 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Greg Connor CC: IETF MXCOMP Subject: Re: when spoofing isn't References: <20040319201835.GH67093@bitshift.org> <11039584.1079701719@gconnor.corp.yahoo.com> In-Reply-To: <11039584.1079701719@gconnor.corp.yahoo.com> X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Greg Connor wrote: > How do people feel about coming up with a draft RFC that focuses on > RFC2821 MAIL FROM first and following up with a DATA/Headers extension > to it later? Can we have multiple draft RFC's come from the same working > group? > The key here is whether the DNS-based mechanism that is defined in this WG will allow for both. If the mechanism is made extensible enough, than we can start off with the MAIL FROM or HELO mechanism first, get that approved, and then delve into the "from" header issues. And yes - a WG can produce multiple RFCs. Yakov From owner-ietf-mxcomp Fri Mar 19 13:53:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JLrX9D064135; Fri, 19 Mar 2004 13:53:33 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2JLrXBi064134; Fri, 19 Mar 2004 13:53:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.41]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JLrWQD064128 for ; Fri, 19 Mar 2004 13:53:33 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.50] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1B4RvN-0003kC-00; Fri, 19 Mar 2004 16:53:05 -0500 Received: from [68.244.224.192] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1B4RvM-0002Lr-00; Fri, 19 Mar 2004 16:53:05 -0500 Message-ID: <405B6BB0.6010806@solidmatrix.com> Date: Fri, 19 Mar 2004 16:52:48 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: "Hallam-Baker, Phillip" CC: "'Mark C. Langston'" , IETF MXCOMP Subject: Re: when spoofing isn't References: In-Reply-To: X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hallam-Baker, Phillip wrote: > >>But here, you assume that the RFC2822 identities would be the logical >>next target. I'd think that the spammers would be more >>likely to take a >>less subtle approach and try to subvert the authorization >>mechanism. In >>the case of several approaches, this would mean DNS >>poisoning, denial of >>service attacks against nameservers, and other such trickery. > > > I think that the attacks you propose are brittle, entirely infeasible > on a bulk basis even if the attackers had the ability. > > Forging RFC822 is trivial. > > How aout we compromise here? > > Put all the parts of the draft I suggest be non-normative off > in a separate document. Focus on defining the normative text > and getting that approved. > > The non-normative text is delivered when nits are ironed out. > It would be informational so updates are much easier. > There is the issue of what you put inside the record itself. If it is just the IP addresses and nothing more, than we can do this. However, if we want to indicate other stuff in it like identity to verify against (which I personally would like to be normative rather than a hint), then it makes things a bit more complicated. If this is evolved into a very generic policy mechanism, then we would open a can of worms. I also believe that there is a difference of approaches here - some people want to approach this with a single identity in mind. Others want ability to choose different identities and mechanisms like SPF does. Yet others, want ability to extend this into a more generic "server configuration description" language. Determination of scope would be helpful. Yakov From owner-ietf-mxcomp Fri Mar 19 15:15:04 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JNF4bE070664; Fri, 19 Mar 2004 15:15: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 i2JNF4Co070663; Fri, 19 Mar 2004 15:15:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from slot.hollandcasino.net (slot.hollandcasino.net [193.172.40.18]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JNF3Os070655 for ; Fri, 19 Mar 2004 15:15:03 -0800 (PST) (envelope-from alex@ergens.op.het.net) Received: by slot.hollandcasino.net (Postfix, from userid 501) id 1305B17DC05; Sat, 20 Mar 2004 00:15:08 +0100 (CET) Date: Sat, 20 Mar 2004 00:15:08 +0100 From: Alex van den Bogaerdt To: IETF MXCOMP Subject: Re: When spoofing is. Message-ID: <20040320001507.A15929@slot.hollandcasino.net> Mail-Followup-To: IETF MXCOMP References: <20040319185852.GE67093@bitshift.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040319185852.GE67093@bitshift.org>; from mark@bitshift.org on Fri, Mar 19, 2004 at 10:58:52AM -0800 X-Legal-Note: ---------------------------------------------- Everything I write or say expresses my opinion only! Unless otherwise stated, I do not represent my employer or anyone else for that matter. ---------------------------------------------------- Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Mar 19, 2004 at 10:58:52AM -0800, Mark C. Langston wrote: > > In this particular case there is a very easy fix for the postcard sites, > > they just use their own name, not a random name that someone entered > > into a web form. they should have done that all along. > > So, how should the recipient identify the entity that caused the card to > be sent, and how should the recipient reply to that entity? Why should the recipient identify this entity? Those postcard sites are vulnerable to spoofing, let them fix their own problems. First thing to do is to make them stop lying; once they've done that I can decide if I trust them. If I do, I know I can reply to the message. And if I don't trust them, I can block the undesired messages without going through many hoops. just my 2c. Alex van den Bogaerdt From owner-ietf-mxcomp Fri Mar 19 15:19:05 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JNJ5CB071187; Fri, 19 Mar 2004 15:19:05 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2JNJ5YU071186; Fri, 19 Mar 2004 15:19:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [64.139.47.218]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JNJ2w8071179 for ; Fri, 19 Mar 2004 15:19:05 -0800 (PST) (envelope-from gconnor@nekodojo.org) Received: from gconnor.corp.yahoo.com (gconnor.corp.yahoo.com [216.145.58.43]) (authenticated) by neko-base.nekodojo.org (8.11.6/8.11.6) with ESMTP id i2JNJ8l07303 for ; Fri, 19 Mar 2004 15:19:08 -0800 Date: Fri, 19 Mar 2004 15:18:45 -0800 From: Greg Connor To: IETF MXCOMP Subject: Re: when spoofing isn't Message-ID: <18844887.1079709525@gconnor.corp.yahoo.com> In-Reply-To: <405B6BB0.6010806@solidmatrix.com> References: <405B6BB0.6010806@solidmatrix.com> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Yakov Shafranovich wrote: > I also believe that there is a difference of approaches here - some > people want to approach this with a single identity in mind. Others want > ability to choose different identities and mechanisms like SPF does. Yet > others, want ability to extend this into a more generic "server > configuration description" language. Determination of scope would be > helpful. I agree. I would like to see a relative narrow focus for the first milestone (such as announcing authorized outgoing servers and refuting others) and I'm willing to delay some of my other desired goals (such as declaring other policies, examining other headers, having more flexible mechanisms). I think it would be a good thing for the working group to announce an early success in a limited area, than to spend a longer time coming up with something more feature-rich. In other words, I am a big fan of SPF, but I would support something less extensible, if it could be folded into an RFC sooner. Now. That said, I would like "being extensible in general" to be a goal as well. There are other milestones to come, and if we choose an implementation that is as streamlined as possible for specifying outgoing servers, but can't be extended to add other mechanisms or other policies, we basically have to start all those other efforts from scratch. So I guess I am saying: Most important: Ability to easily specify outgoing servers and refute others Next most important: Implementation that could be used for other purposes later is preferred over one that can't I think it's appropriate to discuss our other goals, and kick around some ideas and some ways that they could be complementary to our first goal, but we should not have to agree on all the other possibilities in order to get to our first milestone. We can determine a scope for the first milestone (first RFC) and not necessarily rule out discussion on other topics. -- Greg Connor From owner-ietf-mxcomp Fri Mar 19 15:47:11 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JNlBpn072637; Fri, 19 Mar 2004 15:47: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 i2JNlABX072636; Fri, 19 Mar 2004 15:47:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (IDENT:root@ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JNlAIn072629 for ; Fri, 19 Mar 2004 15:47:10 -0800 (PST) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-19-105.client.comcast.net [24.6.19.105]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i2JNlCiL005179 for ; Fri, 19 Mar 2004 15:47:12 -0800 (PST) Received: by tethys.bitshift.org (Postfix, from userid 1001) id 6396F22887; Fri, 19 Mar 2004 15:47:12 -0800 (PST) Date: Fri, 19 Mar 2004 15:47:12 -0800 From: "Mark C. Langston" To: IETF MXCOMP Subject: Re: when spoofing isn't Message-ID: <20040319234712.GK67093@bitshift.org> Mail-Followup-To: IETF MXCOMP References: <405B6BB0.6010806@solidmatrix.com> <18844887.1079709525@gconnor.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18844887.1079709525@gconnor.corp.yahoo.com> User-Agent: Mutt/1.4.1i X-Uptime: 3:25PM up 276 days, 18:35, 7 users, load averages: 0.00, 0.01, 0.00 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Mar 19, 2004 at 03:18:45PM -0800, Greg Connor wrote: > > Most important: Ability to easily specify outgoing servers and refute others I'd modify that to say: "Ability to easily specify an arbitrary number of outgoing servers and/or refute others." Even so, there's an issue with the maximum length of TXT records (255 chars, after which BIND seems to split the record), and the arbitrary returned order of multiple TXT records. -- Mark C. Langston Sr. Unix SysAdmin mark@bitshift.org mark@seti.org Systems & Network Admin SETI Institute http://bitshift.org http://www.seti.org From owner-ietf-mxcomp Fri Mar 19 15:49:05 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JNn5s3072724; Fri, 19 Mar 2004 15:49:05 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2JNn58F072723; Fri, 19 Mar 2004 15:49:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (IDENT:root@ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JNn4nE072714 for ; Fri, 19 Mar 2004 15:49:05 -0800 (PST) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-19-105.client.comcast.net [24.6.19.105]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i2JNn6iL005458 for ; Fri, 19 Mar 2004 15:49:07 -0800 (PST) Received: by tethys.bitshift.org (Postfix, from userid 1001) id D8A942288D; Fri, 19 Mar 2004 15:49:06 -0800 (PST) Date: Fri, 19 Mar 2004 15:49:06 -0800 From: "Mark C. Langston" To: IETF MXCOMP Subject: Re: When spoofing is. Message-ID: <20040319234906.GL67093@bitshift.org> Mail-Followup-To: IETF MXCOMP References: <20040319185852.GE67093@bitshift.org> <20040320001507.A15929@slot.hollandcasino.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040320001507.A15929@slot.hollandcasino.net> User-Agent: Mutt/1.4.1i X-Uptime: 3:25PM up 276 days, 18:35, 7 users, load averages: 0.00, 0.01, 0.00 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, Mar 20, 2004 at 12:15:08AM +0100, Alex van den Bogaerdt wrote: > > On Fri, Mar 19, 2004 at 10:58:52AM -0800, Mark C. Langston wrote: > > > > > So, how should the recipient identify the entity that caused the card to > > be sent, and how should the recipient reply to that entity? > > Why should the recipient identify this entity? Those postcard sites are > vulnerable to spoofing, let them fix their own problems. > Because Grandma might like to know which of her grandkids sent the postcard. Solving problems by creating problems for others won't aid our efforts. Particularly when it seems that the problems have been created to address unspoken motives. -- Mark C. Langston Sr. Unix SysAdmin mark@bitshift.org mark@seti.org Systems & Network Admin SETI Institute http://bitshift.org http://www.seti.org From owner-ietf-mxcomp Fri Mar 19 16:38:55 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2K0ctBt074775; Fri, 19 Mar 2004 16:38: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 i2K0ctYU074774; Fri, 19 Mar 2004 16:38:55 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2K0ctma074768 for ; Fri, 19 Mar 2004 16:38:55 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.11/) with ESMTP id i2K0cQLJ006305; Fri, 19 Mar 2004 16:38:26 -0800 (PST) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Fri, 19 Mar 2004 16:38:26 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Mark C. Langston'" , IETF MXCOMP Subject: RE: When spoofing is. Date: Fri, 19 Mar 2004 16:38:25 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Mark C. Langston > Sent: Friday, March 19, 2004 6:49 PM > To: IETF MXCOMP > Subject: Re: When spoofing is. > > > > On Sat, Mar 20, 2004 at 12:15:08AM +0100, Alex van den Bogaerdt wrote: > > > > On Fri, Mar 19, 2004 at 10:58:52AM -0800, Mark C. Langston wrote: > > > > > > > > So, how should the recipient identify the entity that > caused the card to > > > be sent, and how should the recipient reply to that entity? > > > > Why should the recipient identify this entity? Those > postcard sites are > > vulnerable to spoofing, let them fix their own problems. > > > > Because Grandma might like to know which of her grandkids sent the > postcard. From:owner-ietf-mxcomp@mail.imc.org; on behalf of; Mark C. Langston [mark@bitshift.org] Reply-To: Mark C. Langston [mark@bitshift.org] What part of that do you think Grandma will have a problem with? From:postcards@crummypostcards.com; on behalf of; little jimmy [jimmy@bitshift.org] Reply-To: little jimmy [jimmy@bitshift.org] From owner-ietf-mxcomp Fri Mar 19 17:06:53 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2K16rro076186; Fri, 19 Mar 2004 17:06: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 i2K16riL076185; Fri, 19 Mar 2004 17:06:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (IDENT:root@ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2K16qW6076178 for ; Fri, 19 Mar 2004 17:06:52 -0800 (PST) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-19-105.client.comcast.net [24.6.19.105]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i2K16tiL022180 for ; Fri, 19 Mar 2004 17:06:55 -0800 (PST) Received: by tethys.bitshift.org (Postfix, from userid 1001) id 5B59122887; Fri, 19 Mar 2004 17:06:55 -0800 (PST) Date: Fri, 19 Mar 2004 17:06:55 -0800 From: "Mark C. Langston" To: IETF MXCOMP Subject: Re: When spoofing is. Message-ID: <20040320010655.GM67093@bitshift.org> Mail-Followup-To: IETF MXCOMP References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Uptime: 5:00PM up 276 days, 20:10, 7 users, load averages: 0.01, 0.01, 0.00 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Mar 19, 2004 at 04:38:25PM -0800, Hallam-Baker, Phillip wrote: > > > > -----Original Message----- > > From: owner-ietf-mxcomp@mail.imc.org > > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Mark C. Langston > > Sent: Friday, March 19, 2004 6:49 PM > > To: IETF MXCOMP > > Subject: Re: When spoofing is. > > > > On Sat, Mar 20, 2004 at 12:15:08AM +0100, Alex van den Bogaerdt wrote: > > > > > > On Fri, Mar 19, 2004 at 10:58:52AM -0800, Mark C. Langston wrote: > > > > > > > > > > > So, how should the recipient identify the entity that > > caused the card to > > > > be sent, and how should the recipient reply to that entity? > > > > > > Why should the recipient identify this entity? Those > > postcard sites are > > > vulnerable to spoofing, let them fix their own problems. > > > > > > > Because Grandma might like to know which of her grandkids sent the > > postcard. > > From:owner-ietf-mxcomp@mail.imc.org; on behalf of; > Mark C. Langston [mark@bitshift.org] > Reply-To: Mark C. Langston [mark@bitshift.org] > > > What part of that do you think Grandma will have a problem with? The bit where her MUA only displays the From:, and none of the "on behalf of" part (much like many other MUAs. Mutt, for example, which I'm using now, doesn't display that). Grandma doesn't parse mail headers manually. Grandma looks at the "From:" if we're lucky. More often, she just looks at the quoted string that supplies the supposed name associated with the email address (or that stored in her address book, which her MUA was kind enough to dredge up for her). This sounds like it's headed towards "solution: educate the end users." Speaking from experience, this never works. -- Mark C. Langston Sr. Unix SysAdmin mark@bitshift.org mark@seti.org Systems & Network Admin SETI Institute http://bitshift.org http://www.seti.org From owner-ietf-mxcomp Fri Mar 19 17:09:35 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2K19ZaR076246; Fri, 19 Mar 2004 17:09: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 i2K19Zi3076245; Fri, 19 Mar 2004 17:09:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from slot.hollandcasino.net (slot.hollandcasino.net [193.172.40.18]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2K19YxM076239 for ; Fri, 19 Mar 2004 17:09:35 -0800 (PST) (envelope-from alex@ergens.op.het.net) Received: by slot.hollandcasino.net (Postfix, from userid 501) id 9FFA117DC05; Sat, 20 Mar 2004 02:09:40 +0100 (CET) Date: Sat, 20 Mar 2004 02:09:40 +0100 From: Alex van den Bogaerdt To: IETF MXCOMP Subject: Re: When spoofing is. Message-ID: <20040320020940.A16782@slot.hollandcasino.net> Mail-Followup-To: IETF MXCOMP References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from pbaker@verisign.com on Fri, Mar 19, 2004 at 04:38:25PM -0800 X-Legal-Note: ---------------------------------------------- Everything I write or say expresses my opinion only! Unless otherwise stated, I do not represent my employer or anyone else for that matter. ---------------------------------------------------- Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Mar 19, 2004 at 04:38:25PM -0800, Hallam-Baker, Phillip wrote: > > > > So, how should the recipient identify the entity that > > caused the card to > > > > be sent, and how should the recipient reply to that entity? > > > > > > Why should the recipient identify this entity? Those > > postcard sites are > > > vulnerable to spoofing, let them fix their own problems. > > > > > > > Because Grandma might like to know which of her grandkids sent the > > postcard. > > From:owner-ietf-mxcomp@mail.imc.org; on behalf of; > Mark C. Langston [mark@bitshift.org] > Reply-To: Mark C. Langston [mark@bitshift.org] I was thinking about envelope-from but yes, this is true as well. > What part of that do you think Grandma will have a problem with? > > From:postcards@crummypostcards.com; on behalf of; little jimmy > [jimmy@bitshift.org] > Reply-To: little jimmy [jimmy@bitshift.org] Which still doesn't make sure it _is_ little jimmy sending the card. If envelope-from is set to postcards@crummypostcards.com, that domain will have to deal with bounces, not jimmy@bitshift.org This is especially important if jmimy can't speel. cheers, Alex From owner-ietf-mxcomp Fri Mar 19 17:12:15 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2K1CF6P076351; Fri, 19 Mar 2004 17:12: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 i2K1CFNh076350; Fri, 19 Mar 2004 17:12:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from slot.hollandcasino.net (slot.hollandcasino.net [193.172.40.18]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2K1CEw8076344 for ; Fri, 19 Mar 2004 17:12:15 -0800 (PST) (envelope-from alex@ergens.op.het.net) Received: by slot.hollandcasino.net (Postfix, from userid 501) id 8D70F17DC05; Sat, 20 Mar 2004 02:12:20 +0100 (CET) Date: Sat, 20 Mar 2004 02:12:20 +0100 From: Alex van den Bogaerdt To: IETF MXCOMP Subject: Re: When spoofing is. Message-ID: <20040320021220.B16782@slot.hollandcasino.net> Mail-Followup-To: IETF MXCOMP References: <20040319185852.GE67093@bitshift.org> <20040320001507.A15929@slot.hollandcasino.net> <20040319234906.GL67093@bitshift.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040319234906.GL67093@bitshift.org>; from mark@bitshift.org on Fri, Mar 19, 2004 at 03:49:06PM -0800 X-Legal-Note: ---------------------------------------------- Everything I write or say expresses my opinion only! Unless otherwise stated, I do not represent my employer or anyone else for that matter. ---------------------------------------------------- Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Mar 19, 2004 at 03:49:06PM -0800, Mark C. Langston wrote: > > Why should the recipient identify this entity? Those postcard sites are > > vulnerable to spoofing, let them fix their own problems. > > > > Because Grandma might like to know which of her grandkids sent the > postcard. So exactly how does Grandma _know_ who sent the card? I asked: _know_, not _guess_ or _believe_. > Solving problems by creating problems for others won't aid our efforts. > Particularly when it seems that the problems have been created to > address unspoken motives. You have seen no problems so there are no problems ? Sure... From owner-ietf-mxcomp Fri Mar 19 18:27:11 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2K2RBHE080161; Fri, 19 Mar 2004 18:27: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 i2K2RBMv080160; Fri, 19 Mar 2004 18:27:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2K2RA6R080153 for ; Fri, 19 Mar 2004 18:27:10 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i2K2RBtc029609; Fri, 19 Mar 2004 18:27:12 -0800 (PST) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Fri, 19 Mar 2004 18:27:11 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Alex van den Bogaerdt'" , IETF MXCOMP Subject: RE: When spoofing is. Date: Fri, 19 Mar 2004 18:27:10 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Which still doesn't make sure it _is_ little jimmy sending the card. > If envelope-from is set to postcards@crummypostcards.com, that domain > will have to deal with bounces, not jimmy@bitshift.org Which is exactly how it should be. I get about 75 bounces every day just from misconfigured virus scanners bouncing mail I never sent. The info that goes into those web forms is not authenticated, it should not cause any bounces to go anywhere other than to the site sending the stuff. I often use potus@a1.eop.gov as the from address in those forms I bet many others do similar. Phill From owner-ietf-mxcomp Fri Mar 19 20:22:32 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2K4MW2D087094; Fri, 19 Mar 2004 20:22: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 i2K4MWH9087093; Fri, 19 Mar 2004 20:22:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (IDENT:root@ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2K4MVbN087086 for ; Fri, 19 Mar 2004 20:22:31 -0800 (PST) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-19-105.client.comcast.net [24.6.19.105]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i2K4MaiL011274 for ; Fri, 19 Mar 2004 20:22:36 -0800 (PST) Received: by tethys.bitshift.org (Postfix, from userid 1001) id 039A622888; Fri, 19 Mar 2004 20:22:36 -0800 (PST) Date: Fri, 19 Mar 2004 20:22:35 -0800 From: "Mark C. Langston" To: IETF MXCOMP Subject: Re: When spoofing is. Message-ID: <20040320042235.GN67093@bitshift.org> Mail-Followup-To: IETF MXCOMP References: <20040319185852.GE67093@bitshift.org> <20040320001507.A15929@slot.hollandcasino.net> <20040319234906.GL67093@bitshift.org> <20040320021220.B16782@slot.hollandcasino.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040320021220.B16782@slot.hollandcasino.net> User-Agent: Mutt/1.4.1i X-Uptime: 5:10PM up 276 days, 20:20, 7 users, load averages: 0.02, 0.03, 0.00 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, Mar 20, 2004 at 02:12:20AM +0100, Alex van den Bogaerdt wrote: > > On Fri, Mar 19, 2004 at 03:49:06PM -0800, Mark C. Langston wrote: > > > > Why should the recipient identify this entity? Those postcard sites are > > > vulnerable to spoofing, let them fix their own problems. > > > > > > > Because Grandma might like to know which of her grandkids sent the > > postcard. > > So exactly how does Grandma _know_ who sent the card? > > I asked: _know_, not _guess_ or _believe_. > To the layperson, the three are identical, thus the distinction for Grandma is irrelevant, as she doesn't have the technical knowledge to distinguish among the three in this arena. She knows because her children and children's children have told her what their email addresses are; she knows because her friends have told her what their email addresses are. More than that, she knows because that's who the computer told her it was, and she has no reason, nor desire, to doubt it. Grandma trusts that From: header (or whatever prettified equivalent is presented to her by her MUA) as surely as she trusts the Caller-ID display on her phone, or even as much as she trusts that the voice she hears on the other end of that phone is who she thinks it is. > > Solving problems by creating problems for others won't aid our efforts. > > Particularly when it seems that the problems have been created to > > address unspoken motives. > > You have seen no problems so there are no problems ? Sure... That's not what I said. I said that sniping at legitimate services under the guise of attacking spammers isn't likely to win friends and influence people. We should be conservative in what we break. -- Mark C. Langston Sr. Unix SysAdmin mark@bitshift.org mark@seti.org Systems & Network Admin SETI Institute http://bitshift.org http://www.seti.org From owner-ietf-mxcomp Sat Mar 20 05:50:20 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2KDoKeY091934; Sat, 20 Mar 2004 05: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 i2KDoKk0091933; Sat, 20 Mar 2004 05:50:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2KDoJT0091927 for ; Sat, 20 Mar 2004 05:50:19 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.11/) with ESMTP id i2KDnpb3009683; Sat, 20 Mar 2004 05:49:51 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Sat, 20 Mar 2004 05:49:51 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Mark C. Langston'" , IETF MXCOMP Subject: RE: When spoofing is. Date: Sat, 20 Mar 2004 05:49:49 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > To the layperson, the three are identical, thus the distinction for > Grandma is irrelevant, as she doesn't have the technical knowledge to > distinguish among the three in this arena. The distinction is irrelevant because she certainly won't be running Mutt as you hypothesised earlier. > She knows because her children and children's children have told her > what their email addresses are; she knows because her friends > have told her what their email addresses are. Familiarity would be the issue, seeing them before. > More than that, she knows because > that's who the computer told her it was, and she has no reason, nor > desire, to doubt it. Grandma trusts that From: header (or whatever > prettified equivalent is presented to her by her MUA) as surely as she > trusts the Caller-ID display on her phone, or even as much as > she trusts > that the voice she hears on the other end of that phone is who she > thinks it is. And today that trust is completely misplaced > > > Solving problems by creating problems for others won't > aid our efforts. > > > Particularly when it seems that the problems have been created to > > > address unspoken motives. > > > > You have seen no problems so there are no problems ? Sure... > > That's not what I said. I said that sniping at legitimate services > under the guise of attacking spammers isn't likely to win friends and > influence people. We should be conservative in what we break. The postcard sites already have a big problem getting their mail through. I don't think they really care very much about this issue. Just tell them how to do it right. They can fix their perl script in a few days. Some geek gets a few hours consulting somewhere but its not a big deal. If you read CAN-SPAM there could even be legislative requirement already to use the from address of the postcard site, not one added in from a form. From owner-ietf-mxcomp Sat Mar 20 05:55:52 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2KDtqQM092504; Sat, 20 Mar 2004 05:55: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 i2KDtqtJ092503; Sat, 20 Mar 2004 05:55:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2KDtpJe092494 for ; Sat, 20 Mar 2004 05:55:51 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.11/) with ESMTP id i2KDtp4B027505; Sat, 20 Mar 2004 05:55:51 -0800 (PST) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Sat, 20 Mar 2004 05:55:51 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Alex van den Bogaerdt'" , IETF MXCOMP Subject: RE: When spoofing is. Date: Sat, 20 Mar 2004 05:55:48 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > From:owner-ietf-mxcomp@mail.imc.org; on behalf of; > > Mark C. Langston [mark@bitshift.org] > > Reply-To: Mark C. Langston [mark@bitshift.org] > > I was thinking about envelope-from but yes, this is true as well. Why would this be anyone other than the postcard site? What use if made of envelope from by the MUA or MTA in any case? At the moment it appears to be completely unnecessary. > > What part of that do you think Grandma will have a problem with? > > > > From:postcards@crummypostcards.com; on behalf of; little jimmy > > [jimmy@bitshift.org] > > Reply-To: little jimmy [jimmy@bitshift.org] > > Which still doesn't make sure it _is_ little jimmy sending the card. > If envelope-from is set to postcards@crummypostcards.com, that domain > will have to deal with bounces, not jimmy@bitshift.org > > This is especially important if jmimy can't speel. > > cheers, > Alex > From owner-ietf-mxcomp Sat Mar 20 09:52:36 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2KHqaQf004894; Sat, 20 Mar 2004 09:52:36 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2KHqa2g004893; Sat, 20 Mar 2004 09:52:36 -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 (srv1.pan-am.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2KHqZNC004887 for ; Sat, 20 Mar 2004 09:52:36 -0800 (PST) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: [overloading TXT again?] RE: when spoofing isn't MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sat, 20 Mar 2004 11:52:35 -0600 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA7EE@srv1.pan-am.ca> X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: when spoofing isn't Thread-Index: AcQODM4kezfLUSl7SgS58IQsfTRVdQAlzb1g From: "Gordon Fecyk" To: "IETF MXCOMP" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2KHqaNC004888 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > Most important: Ability to easily specify outgoing servers > and refute others > > Even so, there's an issue with the maximum length of TXT records (255 > chars, after which BIND seems to split the record), and the arbitrary > returned order of multiple TXT records. I thought we weren't going to overload existing record types. -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Sat Mar 20 09:56:49 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2KHun3H005131; Sat, 20 Mar 2004 09:56: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 i2KHunju005130; Sat, 20 Mar 2004 09:56:49 -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.8) with SMTP id i2KHulh8005124 for ; Sat, 20 Mar 2004 09:56:48 -0800 (PST) (envelope-from winserver.support@winserver.com) Received: by winserver.com (Wildcat! SMTP Router v5.7.450.9b13) for ietf-mxcomp@imc.org; Sat, 20 Mar 2004 12:58:56 -0500 Received: from ([68.154.110.135]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v5.7.450.9b13) with SMTP id 4258106390; Sat, 20 Mar 2004 12:58:55 -0500 Message-ID: <002e01c40ea4$ea73f5b0$6401a8c0@hdev1> From: "Hector Santos" To: "IETF-MXCOMP" Subject: Top Concerns, Issues, Comments Date: Sat, 20 Mar 2004 12:58:10 -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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Some accumulated thoughts o No Spams this week! o LMAP works best to protect your own domains. Low trust in remote domain checking. o LMAP has a high DNS overhead for remote domain checking. o LMAP compliant spammers is a reality! Can't trust remote checks! o LMAP only tries to link the DOMAIN and not the USER PART of the email address. o CBV continues to prove the return path address is more important than just the return path domain. o Anonymous Access Management system *can* work without a fundamental change to SMTP. o SMTP functional specifications (the RFCs) must change in order for technical specification enforcement to take place. o SMTP functional specifications must change in order for CAN-SPAM can even begin to work. o Why is it that I get a constant ~2500 connections? with a constant spam/rejection 90% rate? o 80% of all transactions is spoofed. o Local Domain (HELO) Spoofing is 10%. 80% is RBL rejected, 10% rejected by CBV o Many systems don't support extended multi-line response. o Too many systems rely on "dumb scripting" systems, hence lack of support for SMTP features. o SPF needs to get rid of softfail and neutral policies. If system is not ready for it, then use it! Suggestions: o CAN-SPAM provides two mandates; return path validation and topic identication; Use this model!! o Add Multiple line greeting to eliminate many of your spammers! 60% on our system. o LMAP may provide incentive for the building of "Network Relationships" or "LMAP-Nets" o Need SMTP Message-Id Verification (Exist) Feedback System. o SMTP needs a protocol topic identication command, i.e., "SUBJ" o BCP: RCPT validation stops SORBIG generation email virus distribution dependency on bounce mail attacks. That's it for now. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp Sat Mar 20 10:06:13 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2KI6DIG005546; Sat, 20 Mar 2004 10:06: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 i2KI6DLe005545; Sat, 20 Mar 2004 10:06: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 (srv1.pan-am.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2KI6C2i005539 for ; Sat, 20 Mar 2004 10:06:12 -0800 (PST) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: [more like "when spoofing is judged by a double standard"] RE: When spoofing is. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sat, 20 Mar 2004 12:06:15 -0600 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA7EF@srv1.pan-am.ca> X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: When spoofing is. Thread-Index: AcQOI09cjT7iTbgFQEWPL50C3I8L1gAgScJg From: "Gordon Fecyk" To: "IETF MXCOMP" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2KI6C2i005540 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > I often use potus@a1.eop.gov as the from address in those forms > I bet many others do similar. As much as "no.thanks@no.spam.wanted.invalid" and "go-away@example.com" are popular entries for "mandatory e-mail address" forms, those at least point to black holes. I'd hate to be Mr/Ms/Dear/etc "Potus" when that mailbox is opened, and I'd hate to be the administrator of a1.eop.gov after seeing the bounce logs. Now this is interesting. Anything we come up with here will go to marketers' [1] advantage, as anyone requiring e-mail addresses to send resource access information can make sure a registration request actually came from said person. Or at least the domain of said person if validating the domain part only... hey... I can live with that actually, given that I can hold said marketers to the same standard and refuse their domain's mail. Who needs a double standard when the standard works to everyone's benefit? [1] not 'spammers' necessarily. -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Sat Mar 20 11:40:48 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2KJemPr009806; Sat, 20 Mar 2004 11:40: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 i2KJemkd009805; Sat, 20 Mar 2004 11:40:48 -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 (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2KJelou009798 for ; Sat, 20 Mar 2004 11:40:47 -0800 (PST) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.30) id 1B4mKv-000690-GW for ietf-mxcomp@imc.org; Sat, 20 Mar 2004 13:40:49 -0600 To: "IETF MXCOMP" Subject: Re: [overloading TXT again?] RE: when spoofing isn't References: <700EEF5641B7E247AC1C9B82C05D125DA7EE@srv1.pan-am.ca> From: wayne Content-Type: text/plain; charset=US-ASCII Date: Sat, 20 Mar 2004 13:40:49 -0600 In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125DA7EE@srv1.pan-am.ca> (Gordon Fecyk's message of "Sat, 20 Mar 2004 11:52:35 -0600") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (spfd: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <700EEF5641B7E247AC1C9B82C05D125DA7EE@srv1.pan-am.ca> "Gordon Fecyk" writes: >> Even so, there's an issue with the maximum length of TXT records (255 >> chars, after which BIND seems to split the record), and the arbitrary >> returned order of multiple TXT records. The maximum length of a TXT is something like 64k, but the text is broken up into substrings of a maximum of 255 bytes (127 bytes for djbdns). While I couldn't find anything in an RFC that says that these substrings will sent in a consistent order, I don't know of a DNS implementation that mixes them up. Note that there is a difference between one TXT record with mutliple strings, and multiple TXT records under a given domain name. The latter *will* often be reordered. The following is a single TXT record with multiple strings: example.com TXT "substring one" "substring two" The following are multiple TXT records within a given domain example.org TXT "string one" example.org TXT "string two" > I thought we weren't going to overload existing record types. The charter says that we are supposed to be discussing the choices of identities now. Considering that the WG hasn't even gotten final approval yet, I don't think "we" could have decided anything yet. -wayne From owner-ietf-mxcomp Sat Mar 20 16:57:39 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2L0vdkD025687; Sat, 20 Mar 2004 16:57: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 i2L0vdNo025686; Sat, 20 Mar 2004 16:57:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2L0vc4U025678 for ; Sat, 20 Mar 2004 16:57:38 -0800 (PST) (envelope-from millenix@zemos.net) Received: from fda.zemos.net ([68.38.12.170]) by comcast.net (sccrmhc12) with ESMTP id <2004032100573801200a84ege>; Sun, 21 Mar 2004 00:57:38 +0000 Received: from zemos.net (phil [10.0.0.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fda.zemos.net (Postfix) with ESMTP id 89BAC1867F; Sat, 20 Mar 2004 19:57:37 -0500 (EST) Message-ID: <405CE880.8020805@zemos.net> Date: Sat, 20 Mar 2004 19:57:36 -0500 From: Philip Miller User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040312 Debian/1.6-3 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Hector Santos Cc: IETF-MXCOMP Subject: Re: Top Concerns, Issues, Comments References: <002e01c40ea4$ea73f5b0$6401a8c0@hdev1> In-Reply-To: <002e01c40ea4$ea73f5b0$6401a8c0@hdev1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hector Santos wrote: > Some accumulated thoughts And some collected responses > o No Spams this week! nope, all spammers!> Congratulations. Does this mean 0 false positives that you've distinguished purely by how they were recorded in your MTA logs? > o LMAP works best to protect your own domains. Low trust in remote domain > checking. On the contrary, you can trust that if a domain publishes LMAP records, and an incoming connection claiming association with that domain that is not born out by the LMAP data, you can pretty well trust that it is a forged connection. > o LMAP has a high DNS overhead for remote domain checking. Should be no worse than doing an A lookup on the HELO name or the PTR lookup on the IP. I'm not so familiar with the inner workings of DNS, but couldn't the LMAP and HELO/A lookups be done in a single query? > o LMAP compliant spammers is a reality! Can't trust remote checks! Sure you can: you can trust that they control the domain they're sending as, and not forging someone else's. > o LMAP only tries to link the DOMAIN and not the USER PART of the email > address. Ummm..... yes. > o CBV continues to prove the return path address is more important than just > the return path domain. Could you elaborate on this point? > o Anonymous Access Management system *can* work without a fundamental change > to SMTP. And this, too? > o SMTP functional specifications (the RFCs) must change in order for > technical specification enforcement to take place. You can enforce any technical specification you'd like. RFC [2]821 explicitly allow the rejection of any connection for any local policy reason. > o SMTP functional specifications must change in order for CAN-SPAM can even > begin to work. CAN-SPAM is irrelevant to the work of this group, because the Internet encompasses more than the jurisdiction of US law. > o Why is it that I get a constant ~2500 connections? with a constant > spam/rejection 90% rate? Since you obviously see some significance to those numbers, you tell us. > o 80% of all transactions is spoofed. By what criteria? > o Local Domain (HELO) Spoofing is 10%. 80% is RBL rejected, 10% rejected by > CBV You mean 10% of rejections are based on the results of your algorithm for detection of HELO spoofing. You're algortihm can't determine if it's legitimate. > o Many systems don't support extended multi-line response. Interesting data point. > o Too many systems rely on "dumb scripting" systems, hence lack of support > for SMTP features. Of course, it goes faster that way. If we start enforcing strict SMTP compliance, they'll start complying. > o SPF needs to get rid of softfail and neutral policies. If system is not > ready for it, then use it! I can't really answer that, as I'm not too deeply familiar with SPF. However, I suspect that softfail modes are probably there for the same reason that the Postfix MTA has a softbounce option (45x rather than 55x on failures): to prevent configuration errors leading to catastrophies. > Suggestions: > > o CAN-SPAM provides two mandates; return path validation and topic > identication; Use this model!! As stated above, CAN-SPAM is irrelevant. > o Add Multiple line greeting to eliminate many of your spammers! 60% on our > system. Perhaps I'll try it. > o LMAP may provide incentive for the building of "Network Relationships" or > "LMAP-Nets" If you've been following ASRG's SMTP-Verify subgroup, you'll see a great deal of ongoing discussion of the 'web of trust' concept. > o Need SMTP Message-Id Verification (Exist) Feedback System. May be the next step, but there's nothing to stop a spammer from setting up a system to provide that verification. Just makes them incrementally more traceable. > o SMTP needs a protocol topic identication command, i.e., "SUBJ" Why would any spammers comply with it? Only the 'legitimate' (as in above the table) marketers would, and they're already easy to filter. > o BCP: RCPT validation stops SORBIG generation email virus distribution > dependency on bounce mail attacks. I'm not quite sure what you're saying with this. All of the LMAP-like proposals on the table would prevent the initial spoofing of domains that worms & viruses do. > That's it for now. Then I'll stop replying for now ;-) Philip Miller From owner-ietf-mxcomp Sat Mar 20 17:32:22 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2L1WM49027250; Sat, 20 Mar 2004 17:32: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 i2L1WMb6027249; Sat, 20 Mar 2004 17:32:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.40]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2L1WLdm027238 for ; Sat, 20 Mar 2004 17:32:22 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.52] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1B4rp1-00028c-00 for ietf-mxcomp@imc.org; Sat, 20 Mar 2004 20:32:15 -0500 Received: from [68.244.224.26] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1B4rp0-00010o-00 for ietf-mxcomp@imc.org; Sat, 20 Mar 2004 20:32:15 -0500 Message-ID: <405CF096.5060407@solidmatrix.com> Date: Sat, 20 Mar 2004 20:32:06 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: "IETF MXCOMP (E-mail)" Subject: Choice of identities: compromise? X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Am I sensing a compromise that we should first concentrate on RFC2821 stuff (HELO and MAIL FROM) with an eye toward possible RFC2822 headers in the future (past San Diego)? Yakov. P.S. And whatever happened to MTA MARK and IP identity? From owner-ietf-mxcomp Sat Mar 20 17:38:10 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2L1c9fr027472; Sat, 20 Mar 2004 17:38:09 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2L1c9Ys027471; Sat, 20 Mar 2004 17:38:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (IDENT:root@ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2L1c9LF027465 for ; Sat, 20 Mar 2004 17:38:09 -0800 (PST) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-19-105.client.comcast.net [24.6.19.105]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i2L1cDiL024448 for ; Sat, 20 Mar 2004 17:38:13 -0800 (PST) Received: by tethys.bitshift.org (Postfix, from userid 1001) id 9C86B22887; Sat, 20 Mar 2004 17:38:13 -0800 (PST) Date: Sat, 20 Mar 2004 17:38:13 -0800 From: "Mark C. Langston" To: "IETF MXCOMP (E-mail)" Subject: Re: Choice of identities: compromise? Message-ID: <20040321013813.GT67093@bitshift.org> Mail-Followup-To: "IETF MXCOMP (E-mail)" References: <405CF096.5060407@solidmatrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <405CF096.5060407@solidmatrix.com> User-Agent: Mutt/1.4.1i X-Uptime: 5:37PM up 277 days, 20:47, 7 users, load averages: 0.03, 0.03, 0.00 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, Mar 20, 2004 at 08:32:06PM -0500, Yakov Shafranovich wrote: > > Am I sensing a compromise that we should first concentrate on RFC2821 > stuff (HELO and MAIL FROM) with an eye toward possible RFC2822 headers > in the future (past San Diego)? Works for me. -- Mark C. Langston Sr. Unix SysAdmin mark@bitshift.org mark@seti.org Systems & Network Admin SETI Institute http://bitshift.org http://www.seti.org From owner-ietf-mxcomp Sat Mar 20 18:19:51 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2L2JpfA029356; Sat, 20 Mar 2004 18:19:51 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2L2JpQL029355; Sat, 20 Mar 2004 18:19:51 -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 (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2L2Jo2C029349 for ; Sat, 20 Mar 2004 18:19:50 -0800 (PST) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.30) id 1B4sZA-0001pH-Fh for ietf-mxcomp@imc.org; Sat, 20 Mar 2004 20:19:56 -0600 To: "IETF MXCOMP" Subject: Re: Choice of identities: compromise? References: <405CF096.5060407@solidmatrix.com> From: wayne Content-Type: text/plain; charset=US-ASCII Date: Sat, 20 Mar 2004 20:19:56 -0600 In-Reply-To: <405CF096.5060407@solidmatrix.com> (Yakov Shafranovich's message of "Sat, 20 Mar 2004 20:32:06 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (spfd: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <405CF096.5060407@solidmatrix.com> Yakov Shafranovich writes: > Am I sensing a compromise that we should first concentrate on RFC2821 > stuff (HELO and MAIL FROM) with an eye toward possible RFC2822 headers > in the future (past San Diego)? If you remove the word "possible", you would have exactly my position. -wayne From owner-ietf-mxcomp Sat Mar 20 18:30:19 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2L2UJ15029633; Sat, 20 Mar 2004 18:30: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 i2L2UJqY029632; Sat, 20 Mar 2004 18:30:19 -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 (srv1.pan-am.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2L2UII0029626 for ; Sat, 20 Mar 2004 18:30:18 -0800 (PST) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: Choice of identities: compromise? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sat, 20 Mar 2004 20:30:24 -0600 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA7F1@srv1.pan-am.ca> X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Choice of identities: compromise? Thread-Index: AcQO5K0/9mdHfF2bRdWIaLOwhPxMYAAB8ovQ 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 i2L2UJI0029627 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Am I sensing a compromise that we should first concentrate on RFC2821 > stuff (HELO and MAIL FROM) with an eye toward possible > RFC2822 headers in the future (past San Diego)? That satisfies my concerns. -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Sat Mar 20 20:45:56 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2L4jueA036812; Sat, 20 Mar 2004 20:45: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 i2L4jumO036811; Sat, 20 Mar 2004 20:45:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2L4ju1h036805 for ; Sat, 20 Mar 2004 20:45:56 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2L4k1d22125; Sat, 20 Mar 2004 20:46:01 -0800 Date: Sat, 20 Mar 2004 20:45:39 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1976055222.20040320204539@brandenburg.com> To: Yakov Shafranovich CC: "IETF MXCOMP (E-mail)" Subject: Re: Choice of identities: compromise? In-Reply-To: <405CF096.5060407@solidmatrix.com> References: <405CF096.5060407@solidmatrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Yakov, YS> Am I sensing a compromise that we should first concentrate on RFC2821 YS> stuff (HELO and MAIL FROM) with an eye toward possible RFC2822 headers YS> in the future (past San Diego)? I think this is a good division of efforts. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Sat Mar 20 21:07:52 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2L57pjV037454; Sat, 20 Mar 2004 21:07:51 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2L57prZ037453; Sat, 20 Mar 2004 21:07:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from drakken.dbc.mtview.ca.us (adsl-64-168-10-254.dsl.scrm01.pacbell.net [64.168.10.254]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2L57pjW037447 for ; Sat, 20 Mar 2004 21:07:51 -0800 (PST) (envelope-from mrose+internet.ietf.mxcomp@dbc.mtview.ca.us) Received: from drakken.dbc.mtview.ca.us (localhost [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.9/8.12.9) with SMTP id i2L57xqJ004188; Sat, 20 Mar 2004 21:07:59 -0800 (PST) Date: Sat, 20 Mar 2004 21:07:59 -0800 From: Marshall Rose To: ietf-mxcomp@imc.org Subject: reminder: text conferencing Message-Id: <20040320210759.70decebd.mrose+internet.ietf.mxcomp@dbc.mtview.ca.us> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.8.11claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: a reminder that there will be an informal group chat via xmpp this monday march 22nd, at 21:00utc. au/eastern = 3/23 7am eu/central = 3/22 10pm us/eastern = 3/22 4pm our plan is to discuss identities with which mta authorization should be associated. for instructions (how to get an xmpp client, how to connect to the conference room, etc.), please consult: http://xmpp.org/ietf-chat.html to connect, do "join group chat" with your client and enter: group/room: marid server: ietf.xmpp.org this conference room is up and running right now (although probably no one will be in it when you connect). if you have never used xmpp and wish to participate, i urge you to: go to the instructions page NOW, download a client NOW, and test your set-up by connecting to the conference room NOW. If you are unable to participate, you can find logs for the conference room at: http://www.xmpp.org/ietf-logs/marid@ietf.xmpp.org/ thanks, /mtr ps: at the present time, the chairs intend to host these chats every other monday. we will alter this schedule based on feedback from the working group as to the usefulness and timeliness of these chats. enjoy! From owner-ietf-mxcomp Sat Mar 20 21:18:40 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2L5IefY038380; Sat, 20 Mar 2004 21:18: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 i2L5Ie3S038379; Sat, 20 Mar 2004 21:18:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (IDENT:root@ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2L5Id5R038372 for ; Sat, 20 Mar 2004 21:18:39 -0800 (PST) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-19-105.client.comcast.net [24.6.19.105]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i2L5IjiL010985 for ; Sat, 20 Mar 2004 21:18:45 -0800 (PST) Received: by tethys.bitshift.org (Postfix, from userid 1001) id ADD9B22888; Sat, 20 Mar 2004 21:18:45 -0800 (PST) Date: Sat, 20 Mar 2004 21:18:45 -0800 From: "Mark C. Langston" To: ietf-mxcomp@imc.org Subject: Re: reminder: text conferencing Message-ID: <20040321051845.GV67093@bitshift.org> Mail-Followup-To: ietf-mxcomp@imc.org References: <20040320210759.70decebd.mrose+internet.ietf.mxcomp@dbc.mtview.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040320210759.70decebd.mrose+internet.ietf.mxcomp@dbc.mtview.ca.us> User-Agent: Mutt/1.4.1i X-Uptime: 9:16PM up 278 days, 26 mins, 7 users, load averages: 0.00, 0.00, 0.00 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, Mar 20, 2004 at 09:07:59PM -0800, Marshall Rose wrote: > > au/eastern = 3/23 7am > eu/central = 3/22 10pm > us/eastern = 3/22 4pm > > ps: at the present time, the chairs intend to host these chats every > other monday. we will alter this schedule based on feedback from the > working group as to the usefulness and timeliness of these > chats. enjoy! It's a good idea, but unfortunately I have a meeting every Monday at that time, so I'll be unable to participate. I'll just follow along with the logs, if people don't mind me occasionally following up on points raised using the mailing list. -- Mark C. Langston Sr. Unix SysAdmin mark@bitshift.org mark@seti.org Systems & Network Admin SETI Institute http://bitshift.org http://www.seti.org From owner-ietf-mxcomp Sat Mar 20 22:17:19 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2L6HJC6044734; Sat, 20 Mar 2004 22:17: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 i2L6HJe4044733; Sat, 20 Mar 2004 22:17:19 -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.8) with SMTP id i2L6HIYJ044720 for ; Sat, 20 Mar 2004 22:17:18 -0800 (PST) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v5.7.450.9b13) for ietf-mxcomp@imc.org; Sun, 21 Mar 2004 01:19:31 -0500 Received: from ([68.154.110.135]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v5.7.450.9b13) with SMTP id 7573125; Sun, 21 Mar 2004 01:19:29 -0500 Message-ID: <002801c40f0c$60dda860$6401a8c0@hdev1> From: "Hector Santos" To: "IETF-MXCOMP" References: <002e01c40ea4$ea73f5b0$6401a8c0@hdev1> <405CE880.8020805@zemos.net> Subject: Re: Top Concerns, Issues, Comments Date: Sun, 21 Mar 2004 01:18:43 -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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----- Original Message ----- From: "Philip Miller" To: "Hector Santos" Cc: "IETF-MXCOMP" Sent: Saturday, March 20, 2004 7:57 PM Subject: Re: Top Concerns, Issues, Comments > > o No Spams this week! > nope, all spammers!> > > Congratulations. Does this mean 0 false positives that you've distinguished > purely by how they were recorded in your MTA logs? Hi Philip, I check for both false negatives (incorrect rejections) and false postivies (incorrect acceptance). Yes, I look at everything. Trust me. Engineering is in my bones. Here is an example of a false negative: Date: 20040217 02:14:31 ------------------------------------- 02:14:31 version : 1.54 / 1.52 02:14:31 calltype : SMTP 02:14:31 state : rcpt 02:14:31 cip : 208.184.76.39 02:14:31 helo : above.proper.com 02:14:31 from : 02:14:31 rcpt : 02:14:31 ruid : 228761 02:14:31 srvip : 208.247.131.9 02:14:32 sapfilter : pass 02:14:32 sapspf : none No SPF record for above.proper.com. 02:14:32 saprbl : testing 39.76.184.208.sbl.spamhaus.org 02:14:34 saprbl : testing 39.76.184.208.list.dsbl.org 02:14:35 saprbl : testing 39.76.184.208.bl.spamcop.net 02:14:37 saprbl : pass RBL lookup passed. Now the final CBV test is done since nothing else passed it. internal filter rules passed. (Btw, in current setup, RBL is before SPF test) 02:14:39 sapcbv : total mx records: 0 02:14:40 try domain : above.proper.com ip: 208.184.76.39 02:14:40 # connecting to 208.184.76.39 02:14:41 S: 220 above.proper.com ESMTP Sendmail 8.12.11/8.12.8; Mon, 16 Feb 2004 23:12:58 -0800 (PST) NO UBE 02:14:41 C: NOOP WCSAP v1.54 Wildcat! Sender Authentication Protocol http://www.santronics.com 02:14:41 S: 250 2.0.0 OK 02:14:41 C: HELO mail.winserver.com 02:14:41 S: 250 above.proper.com Hello mail.santronics.com [208.247.131.9], pleased to meet you 02:14:41 C: MAIL FROM: <> 02:14:41 S: 250 2.1.0 <>... Sender ok 02:14:41 C: RCPT TO: 02:14:41 S: 550 5.1.1 ... User unknown 02:14:41 C: QUIT 02:14:41 sapcbv : 550 02:14:41 smtp code : 552 02:14:41 reason : Rejected by WCSAP CBV 02:14:41 wcsap finish (9953 msecs) This is a example where the testing fell through to the final CBV test and it failed because the return path was not acceptable at this domain. This was back in Feb 17. So I can't say today, but without the CBV you won't see this. I can't throw out the baby with the bath water because of situations like this. It do find it ironic one of the top people in IETF does not have a valid return path in his setup. This is not in no way a knock on Paul, and I surely hope he doesn't see it that way, but this is an example of the realities of the new world. Compliancy is a very big of the picture for any of this new work can even have a chance. If the above is deemed "acceptable" then we might as well give up now. Incidently, with SPF implemented, in the past few weeks, we are experiencing an increase in false positives which are eventually filtered by the CBV or by mail-content filters at the DATA stage. This indicates the expected increase of SPF compliant spammers. Spammers will either comply or they don't. Spoofing will probably no longer work for those who apply LMAP concepts. With that experience, it was obvious we needed to a SPF options to our product to offer some control over the remote non-fail situation: ; SPF can return low trust results. A pass means the sender has ; a valid SPF record and is accepted. Softfail and Neutral means ; no match is found but rejection is not automatic. Setting a ; true accept can provide a loophole for potential spoofers who have ; SPF records and think they will be allowed access. The options ; below allow you to control this. Accept-SPF-Pass True ; if false, continue testing Accept-SPF-SoftFail False ; if false, continue testing Accept-SPF-Neutral False ; if false, continue testing > > o LMAP works best to protect your own domains. Low trust in remote domain > > checking. > > On the contrary, you can trust that if a domain publishes LMAP records, and > an incoming connection claiming association with that domain that is not > born out by the LMAP data, you can pretty well trust that it is a forged > connection. Clarification: - LMAP offers 100% trust in local domain spoof protection - LMAP offers less than or equal 100% trust in remote domain reject results. - LMAP offers little to no trust in remote non-fail results. A positive result can not be trusted 100%, where a negative has a 100% trust value: 0 < trust positive < trust negative = 100% More specifically, the trust inquality is: 0 < Remote Domain Pass < Remote Domain Reject < Local Domain = 100% > > o LMAP has a high DNS overhead for remote domain checking. > > Should be no worse than doing an A lookup on the HELO name or the PTR lookup > on the IP. I'm not so familiar with the inner workings of DNS, but couldn't > the LMAP and HELO/A lookups be done in a single query? I don't claim to be a DNS expect (but I'm getting there ), but based on my analysis, I think it all depends on whether the domain exist or not. I posted this for Meng last month when he wanted to see a comparision of DMP vs SPF (we had DMP first before adding SPF). " Good News: When the DOMAIN is valid in DNS, SPF is on average 3-4 times faster than DMP with ranges in the milliseconds (i.e, 30 ms to 120 ms) Bad News: When the DOMAIN is invalid in DNS (NXDOMAIN), SPF is on average 4-6 times SLOWER than DMP with ranges in seconds (i.e, 6-4 secs to 1- 0.5 secs). " Now, I believe DNS behaves the same for A records lookups. It depends on whether it exist or not. This is why I consistently and continue to say that LMAP operates best for Local Domain Spoof protection. Once you (and everyone else for that matter) go to remote, well, not only do you increase DNS overhead when the majority of the domains are spoofed or don't exist, but the result can not be trusted unless it is reject. The question than becomes of a trade off. This is why you need to understand my LMAP Validation tables posted at: http://www.winserver.com/public/antispam/lmap/draft-lmapanalysis1.htm In Table 1.0, Group D shows 3 states where LMAP can be used when RCPT validation is not a factor. Table 2.0 shows how Group D is expanded to 6 states when RCPT is considered but LMAP is only necessary for 3 of the 6 states; when the RCPT user is local (final destination). For remote RCPT, that requires an entirely different relay authentication standard practice. So it doesn't apply. In other words, this tells you that if you postpone the LMAP lookup until the RCTP state is known, you can drastically improve your LMAP operations. In fact, but our estimates when LMAP (or WCSAP) was done before RCPT is none, the average session time was 60+ seconds. When wcSAP was postpone until the RCPT was known, the average session time shot down to 21+ seconds. > > o LMAP compliant spammers is a reality! Can't trust remote checks! > > Sure you can: you can trust that they control the domain they're sending as, > and not forging someone else's. See trust statement above. :-) > > o CBV continues to prove the return path address is more important than just > > the return path domain. > > Could you elaborate on this point? address #1: baduser@spfdomain.com address #2: gooduser@spfdomain.com Both addresses may pass the domain spf policy test when in actuality, only user #2 is valid. The CBV will pick up on this and usually does. Of course, that doesn't mean it the remote can't easily bypass it. Nothing you can about that. But again, the focus in our testing is to look for "rejects" as they are the only thing you can trust. >From a RFC 2821 standpoint, CBV or LMAP, what needs to be clarify is the ambiguity surrounding the "time" when the return path is considered legitimate. I've seen interesting comments that even though the RFC presumes the return path to be valid, it only needs to be valid come bounce time. Well, that is what the spammers exploits, this exact mode of operation. PS: I understand all the technical issues surrounding a CBV. That is why we are even dealing with other methods as a means to bypass the CBV. > > o Anonymous Access Management system *can* work without a fundamental change > > to SMTP. > > And this, too? answer below > > o SMTP functional specifications (the RFCs) must change in order for > > technical specification enforcement to take place. > > You can enforce any technical specification you'd like. RFC [2]821 > explicitly allow the rejection of any connection for any local policy reason. This is a false philosophy that has played the rounds for so many years, which does have legal precedence, but it is NOT as clear cut as you make is sound. Actually the law does have something to say about this.. I've designed mail transport, gateway, frontend software for many networks as well. The law covers all systems. The implications is if you accept, you are responsible for it. Delivery or Bounce. The RFC covers this, but it is the law with precedence behind it. The most important point here is that the ADMIN has full control of the system on the initial acceptance of the message. What is also very important is you better not tamper with it. [Side track note] Another email myth is the private mail system. If I write you a private message, legal precedence has provided the recipient the right to make the message public. However, if the author clearly states in the message the "intent of privacy is to be maintained", then the recipient risk tort liability by making it public. The exception to this ECPA law is company employer mail systems. Employees had no privacy rights. Implications with LMAP? False Rejections being sent to SPAM database sites making private mail public. > > o SMTP functional specifications must change in order for CAN-SPAM can even > > begin to work. > > CAN-SPAM is irrelevant to the work of this group, because the Internet > encompasses more than the jurisdiction of US law. May be irrevalent to you or this group but it isn't to the product vendor. We already have customers (whether they understand the concepts or not) asking if we are "CAM-SPAM ready." I have a deep and long time ethical and software engineering philosophy that can not be shaken. We write products for other people. Not just for us. We are not ignorant of liability issues, we follow the standard to the fullest possible extent and there is simply no compromise. If a US Federal Law has provide two mandates in CAN-SPAM that says: - Return Address must be valid - Topic Identification must be provided then we are not going to be oblivous to this new federal requirement for spammers and for mail systems to help make it happen. The FEDs have given the IETF 18 months (now 15 months) to define the IETF standards that the spammers must comply with. LMAP has given SMTP developer industry the ability to statisfy mandate #1. So Anonymous Access Management is possible with current SMTP standards if we use LMAP as a way to provide the enforcement policies lacking in SMTP alone. What is missing now is #2, and this is where there is a conflict with current SMTP standard operations. We need an ESMTP extension for this at the protocol level otherwise systems will be force to operate in a "always accept" mail mode for post SMTP validation or DATA stage validation. > > o Why is it that I get a constant ~2500 connections? with a constant > > spam/rejection 90% rate? > > Since you obviously see some significance to those numbers, you tell us. I need to do some IP analytics. What is surprising me is that the numbers are constant. Its like these guys are organized with a scheduler that repeats itself over and over again. :-) Look at the statistics yourself: http://www.winserver.com/public/antispam In isolated analysis, it does seem there is a "change" in behavior or some go away, some come back. :-) But the statistics are just too consistent. There has to be an explanation. I can only think these guys have me on auto pilot and could care less if you reject them or not. That isn't going to stop them from trying anyway. This has me thinking of late that not only there is a potential for a localized network relationship of your mail transactions, i.e, "web of trust," but also a "web of mis-trust." I think there is a pattern here and I would like to one day analyze this, if possible. In other words, it isn't as random as one might think. > > o 80% of all transactions is spoofed. > > By what criteria? By emperical data and by industry research data. When we first only had CBV, the rate we were seeing between 80-94% of all transactions were rejected with spoofed or non-existence domains. It has matched all industry research published on the subject. > > o Local Domain (HELO) Spoofing is 10%. 80% is RBL rejected, 10% rejected by > > CBV > > You mean 10% of rejections are based on the results of your algorithm for > detection of HELO spoofing. You're algortihm can't determine if it's legitimate. We are not in the business of determining legitimany of mail. We are 100% focus on protocol level compliancy. Take a moment to see our stats. I will summerize it here (Using March stats upto this point) Average Calls/Connects: 2449 Immediate Drops at the greeting (no HELO/EHLO issued): 5.3% Drops after issueing HELO/EHLO: 75.2% This means 575 reach MAIL FROM. Now, we delay the wcSAP validation in MAIL FROM until RCPT is known. This is per the RFC 2821 recommendation. Rejects at RCPT: 31.5% This means that wcSAP will only be called for 69.5% or 400 transactions for local domain users issued. Before a RCPT response is issued, wcSAP is then called to perform a suite of test based on the IP, HELO, and MAIL FROM. What we see is is 53% of the 400 or 212 is rejected by wcSAP for one reason or another. The break is: FLT (Internal Filter Accept/Reject rules), 8.6% or 18 RBL, 78.1% or 166 SPF, 0% CBV, 12% or 25 The remaining 188 reaching the DATA stage, 10.8% is rejected with our in-house rule based mail filters, leaving, about 168 messages that were accepted. Now if you are looking at the stats, the %accept shows ~90 transactions were accepted. This is the true amount as it is based on the final "250 message accepted for delivered" for the DATA stage. So the missing amounts not shown are drops after HELO and/or the duplicate RCPT rejected which increases the percentage. In any case, this has been pretty consistent. What I am going to add soon is a column should the number of domains with SPF records. I'm am differently seeing more spammers than legitimate systems, which I guess make sense, given the fact I have such a high rate of spoofing spammers. > > o Too many systems rely on "dumb scripting" systems, hence lack of support > > for SMTP features. > > Of course, it goes faster that way. If we start enforcing strict SMTP > compliance, they'll start complying. ditto. :-) > > o SPF needs to get rid of softfail and neutral policies. If system is not > > ready for it, then use it! > > I can't really answer that, as I'm not too deeply familiar with SPF. > However, I suspect that softfail modes are probably there for the same > reason that the Postfix MTA has a softbounce option (45x rather than 55x on > failures): to prevent configuration errors leading to catastrophies. First, I missed a word above. "If the system is not ready for it, then *don't* use it!" Actually, it (softfail, neutral) is there for migration reasons based on the SPF specification. I already suggested to Meng that there should be a time limit for this specified in the specification. It can not be permanent. The "relaxed" specifications opens the doors to loopholes which is what we are trying to get away from in the first place with the relaxed SMTP specs. Those items need to go IMO They are totally useless (except for reject results). > > Suggestions: > > > > o CAN-SPAM provides two mandates; return path validation and topic > > identication; Use this model!! > > As stated above, CAN-SPAM is irrelevant. Not in my view and IMO, I strongly believe it would be a mistake by anyone seriously addressing the email issue to ignore it like its doesn't exist. CAN-SPAM is already being used a model for other nations laws. In any case, we will differ strongly on this point, so its not worth any more discussion about it. > > o Add Multiple line greeting to eliminate many of your spammers! 60% on our > > system. > > Perhaps I'll try it. Ironically, one of our last minute changes to our new version pending release, was to address a PHP "mail()" command bug where this multi-line greeting was found to cause a problem for a customer with the new version he was gamma testing. The new logic is to only show the multiline policy file at the greeting if and only if the IP is remote, not local. He was running PHP script from a local web server on the same network. So the new logic fixes this. Of course, it is also optional by default. > > o LMAP may provide incentive for the building of "Network Relationships" or > > "LMAP-Nets" > > If you've been following ASRG's SMTP-Verify subgroup, you'll see a great > deal of ongoing discussion of the 'web of trust' concept. "The more things change, the more they remain the same." :-) > > o Need SMTP Message-Id Verification (Exist) Feedback System. > > May be the next step, but there's nothing to stop a spammer from setting up > a system to provide that verification. Just makes them incrementally more > traceable. As a side note. What I find interesting in all these efforts is a focus to design a system that fit the current "spam model based on current SMTP model" Well, the solution is to change it, i.e, force the SPAMMERS to change. Lack of compliance can only be blamed on lack of enforcement policies. We can always use a time framework concept. > > o SMTP needs a protocol topic identication command, i.e., "SUBJ" > > Why would any spammers comply with it? CAN-SPAM? Oh, its irrevalent :-) > Only the 'legitimate' (as in above the table) marketers would, and they're already easy to filter. Good point, which is another thought I had: - LMAP efforts is a high cost narrow focused incomplete solution for a short term problem What is funny about all this is that what is technically a simple authentication issue, we have add a new level of fuzzy logic to the equation that may required a neural network to make it all work. :-) Of course, the way to look at this is what if it does work? at what expense? What will be a overhead issue, now becames an redundancy issue. > > o BCP: RCPT validation stops SORBIG generation email virus distribution > > dependency on bounce mail attacks. > > I'm not quite sure what you're saying with this. All of the LMAP-like > proposals on the table would prevent the initial spoofing of domains that > worms & viruses do. That depends on your perspective, which is another issue I find in the many forums: - Philosophical differences can be traced to the mode of operation one is used to operating in; dynamic vs post SMTP RCPT validation. If you don't validate RCPT at the SMTP level, then you will be operating in a mode which promotes bounces. Remember, once you accept a message, it is a traditional engineering design as well as ethical and when push comes to shove, even legal obligation to deliver it or bounce it. You simply can't just "lose it." RFC 2821 spells that out, but that is inherent in all mail network systems. As I said above, the local system policy does have a strong say here, but you are open to liability issues. There is precedence for this. What is changing this long time traditional fundamental "natural law" in mail transport design is the new era of malicious mail, thus the legal question has become that you can now reject "SMTP accepted mail" without further notification. This is something that is totally brand new in the mail transport design - the idea of rejecting and discarding "already accepted" mail based on post transaction mail filters without notification. It can open a can of worms. This is why I strongly believe a system lowers its liability by doing the mail filter rejection at the DATA stage while the transaction is still active. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp Sat Mar 20 22:48:59 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2L6mxqD057683; Sat, 20 Mar 2004 22:48:59 -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 i2L6mxbi057682; Sat, 20 Mar 2004 22:48:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mout.perfora.net (mout.perfora.net [217.160.230.41]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2L6mwUB057670 for ; Sat, 20 Mar 2004 22:48:58 -0800 (PST) (envelope-from research@solidmatrix.com) Received: from [217.160.230.50] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1B4wlS-0007Tq-00; Sun, 21 Mar 2004 01:48:54 -0500 Received: from [68.244.185.217] (helo=solidmatrix.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1B4wlR-0007zn-00; Sun, 21 Mar 2004 01:48:54 -0500 Message-ID: <405D3AC6.4020507@solidmatrix.com> Date: Sun, 21 Mar 2004 01:48:38 -0500 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, he, ru MIME-Version: 1.0 To: Hector Santos CC: IETF-MXCOMP Subject: Re: Top Concerns, Issues, Comments References: <002e01c40ea4$ea73f5b0$6401a8c0@hdev1> <405CE880.8020805@zemos.net> <002801c40f0c$60dda860$6401a8c0@hdev1> In-Reply-To: <002801c40f0c$60dda860$6401a8c0@hdev1> X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hector Santos wrote: > then we are not going to be oblivous to this new federal requirement for > spammers and for mail systems to help make it happen. The FEDs have given > the IETF 18 months (now 15 months) to define the IETF standards that the > spammers must comply with. The phrase "The FEDs have given the IETF 18 months" is a bit misleading. In my conversations with people at the FTC on behalf of the ASRG, it is very clear to them that the FTC is responsible for drafting this report and any suggested plans/standards for labeling spam NOT the IETF. In their understanding, the intent of the Act is that anything the Commission will come up with does not break existing IETF standards. So the more correct phrase would be that Congress gave the FTC 18 months. In any case, this is way out of scope for this list. Yakov From owner-ietf-mxcomp Sat Mar 20 23:12:58 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2L7Cwfc067629; Sat, 20 Mar 2004 23:12: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 i2L7CwfI067628; Sat, 20 Mar 2004 23:12:58 -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.8) with SMTP id i2L7CvLG067616 for ; Sat, 20 Mar 2004 23:12:57 -0800 (PST) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v5.7.450.9b13) for ietf-mxcomp@imc.org; Sun, 21 Mar 2004 02:15:14 -0500 Received: from ([68.154.110.135]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v5.7.450.9b13) with SMTP id 10917063; Sun, 21 Mar 2004 02:15:13 -0500 Message-ID: <007b01c40f14$2a130a70$6401a8c0@hdev1> From: "Hector Santos" To: "Yakov Shafranovich" , "IETF MXCOMP \(E-mail\)" References: <405CF096.5060407@solidmatrix.com> Subject: Re: Choice of identities: compromise? Date: Sun, 21 Mar 2004 02:11:57 -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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Yakov, First, I agree. I am very happy to see people are beginning to finally see this. I strongly believe this is the right course of action. Second, wow! You don't know how tickled pick I am to hear you say this. :-) You know since day one I have been a big advocate of first focusing on clearing up the inconsistencies, ambiguities and relaxed provisions in the SMTP functional specifications before any proposal can even begin or have a change to work. I repeatedly stated and illustrated the usage the CBV, not as a competing LMAP proposal, but as a proof of concept of what's inherently wrong or inconsistent with the specs. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com ----- Original Message ----- From: "Yakov Shafranovich" To: "IETF MXCOMP (E-mail)" Sent: Saturday, March 20, 2004 8:32 PM Subject: Choice of identities: compromise? > > Am I sensing a compromise that we should first concentrate on RFC2821 > stuff (HELO and MAIL FROM) with an eye toward possible RFC2822 headers > in the future (past San Diego)? > > Yakov. > > P.S. And whatever happened to MTA MARK and IP identity? > > From owner-ietf-mxcomp Sun Mar 21 00:03:53 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2L83q7R084233; Sun, 21 Mar 2004 00:03: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 i2L83qis084232; Sun, 21 Mar 2004 00:03:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (mail.santronics.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2L83pGV084220 for ; Sun, 21 Mar 2004 00:03:52 -0800 (PST) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v5.7.450.9b13) for ietf-mxcomp@imc.org; Sun, 21 Mar 2004 03:05:56 -0500 Received: from ([68.154.110.135]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v5.7.450.9b13) with SMTP id 13959344; Sun, 21 Mar 2004 03:05:55 -0500 Message-ID: <008001c40f1b$3f865b80$6401a8c0@hdev1> From: "Hector Santos" To: "Yakov Shafranovich" Cc: "IETF-MXCOMP" References: <002e01c40ea4$ea73f5b0$6401a8c0@hdev1> <405CE880.8020805@zemos.net> <002801c40f0c$60dda860$6401a8c0@hdev1> <405D3AC6.4020507@solidmatrix.com> Subject: Re: Top Concerns, Issues, Comments Date: Sun, 21 Mar 2004 03:00:16 -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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----- Original Message ----- From: "Yakov Shafranovich" To: "Hector Santos" Cc: "IETF-MXCOMP" Sent: Sunday, March 21, 2004 1:48 AM Subject: Re: Top Concerns, Issues, Comments > > Hector Santos wrote: > > then we are not going to be oblivous to this new federal requirement for > > spammers and for mail systems to help make it happen. The FEDs have given > > the IETF 18 months (now 15 months) to define the IETF standards that the > > spammers must comply with. > > The phrase "The FEDs have given the IETF 18 months" is a bit misleading. Oh, I certainly do not want to misled anyone. > In my conversations with people at the FTC on behalf of the ASRG, it is > very clear to them that the FTC is responsible for drafting this report > and any suggested plans/standards for labeling spam NOT the IETF. In > their understanding, the intent of the Act is that anything the > Commission will come up with does not break existing IETF standards. So > the more correct phrase would be that Congress gave the FTC 18 months. Yakov, Then I think your conversation with whoever needs more input from others I believe there you expressed here what I believe is a fundamental mis-understanding of the problem. The Act clearly says the IETF is to define the standards that the spammers must comply with. Whether thats true or not is not the point. I understand perfectly everyone wants to use the current model and I am willing to bet that most people believed the "honor" system and other solutions will be enough to address the spam problem, using two very clear mandates it provides: o Don't lie about who you are (Valid Return Addresses), o Don't lie or hide your true intent (Topic Identification). Now, in my view, it is the up to the IETF to provide input on whether it is technically possible to enforce this. In other words the FTC wants the IETF input on the matter so they can write their report to Congress. The fact is, the SMTP functional specs does not lend itself to enforce the above items. Even though LMAP makes an attempt with the return address issue, it is proven to be incomplete as it only validates the domain. Microsoft CEP and YK may prevail just on this simple point. Anyway, I sincerely hope this is the not the dominate view point. I think it is a required mindset to address the problem before us. The above provides a working model to start with. Software vendors will need to comply with this both legally and technically and that can only happen if the IETF is on board in shaping the proper specs. I certainly don't wish this to be a debate. I will not participate in it. To me, it is quite clear. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp Sun Mar 21 04:24:10 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2LCOAAx034098; Sun, 21 Mar 2004 04:24: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 i2LCOAho034097; Sun, 21 Mar 2004 04:24:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from slot.hollandcasino.net (slot.hollandcasino.net [193.172.40.18]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2LCO71g034091 for ; Sun, 21 Mar 2004 04:24:10 -0800 (PST) (envelope-from alex@ergens.op.het.net) Received: by slot.hollandcasino.net (Postfix, from userid 501) id 481AC17DC05; Sun, 21 Mar 2004 13:24:08 +0100 (CET) Date: Sun, 21 Mar 2004 13:24:08 +0100 From: Alex van den Bogaerdt To: IETF MXCOMP Subject: Re: When spoofing is. Message-ID: <20040321132408.A29937@slot.hollandcasino.net> Mail-Followup-To: IETF MXCOMP References: <20040319185852.GE67093@bitshift.org> <20040320001507.A15929@slot.hollandcasino.net> <20040319234906.GL67093@bitshift.org> <20040320021220.B16782@slot.hollandcasino.net> <20040320042235.GN67093@bitshift.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040320042235.GN67093@bitshift.org>; from mark@bitshift.org on Fri, Mar 19, 2004 at 08:22:35PM -0800 X-Legal-Note: ---------------------------------------------- Everything I write or say expresses my opinion only! Unless otherwise stated, I do not represent my employer or anyone else for that matter. ---------------------------------------------------- Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Mar 19, 2004 at 08:22:35PM -0800, Mark C. Langston wrote: > > > Solving problems by creating problems for others won't aid our efforts. > > > Particularly when it seems that the problems have been created to > > > address unspoken motives. > > > > You have seen no problems so there are no problems ? Sure... > > That's not what I said. I said that sniping at legitimate services > under the guise of attacking spammers isn't likely to win friends and > influence people. We should be conservative in what we break. I don't think that sites such as those postcard sites are legitimate services. They are spoofing addresses, sending unsollicited email and are very irresponsible when it comes down to handling errors. They make no effort at all to verify the initiating side is valid, nor do they care if the receiving side is able to take their mail. "... that the problems have been created ..." makes me feel personally attacked; you are telling me I am seeing problems that are not real. And you've repeated that. I am not here to combat spam. I am here to combat email fraud. Spam is just one of many forms of fraud. Alex From owner-ietf-mxcomp Sun Mar 21 04:28:32 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2LCSWK0034322; Sun, 21 Mar 2004 04:28: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 i2LCSWRG034321; Sun, 21 Mar 2004 04:28:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from slot.hollandcasino.net (slot.hollandcasino.net [193.172.40.18]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2LCSVTq034315 for ; Sun, 21 Mar 2004 04:28:32 -0800 (PST) (envelope-from alex@ergens.op.het.net) Received: by slot.hollandcasino.net (Postfix, from userid 501) id 0211B17DC05; Sun, 21 Mar 2004 13:28:32 +0100 (CET) Date: Sun, 21 Mar 2004 13:28:32 +0100 From: Alex van den Bogaerdt To: IETF MXCOMP Subject: Re: When spoofing is. Message-ID: <20040321132832.B29937@slot.hollandcasino.net> Mail-Followup-To: IETF MXCOMP References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from pbaker@verisign.com on Sat, Mar 20, 2004 at 05:55:48AM -0800 X-Legal-Note: ---------------------------------------------- Everything I write or say expresses my opinion only! Unless otherwise stated, I do not represent my employer or anyone else for that matter. ---------------------------------------------------- Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, Mar 20, 2004 at 05:55:48AM -0800, Hallam-Baker, Phillip wrote: > > > > From:owner-ietf-mxcomp@mail.imc.org; on behalf of; > > > Mark C. Langston [mark@bitshift.org] > > > Reply-To: Mark C. Langston [mark@bitshift.org] > > > > I was thinking about envelope-from but yes, this is true as well. > > Why would this be anyone other than the postcard site? Because they are unwilling to receive their junk back. I've seen things as bad as: HELO mailhost.domain.tld MAIL FROM: RCPT TO: DATA ... Reply-to: user@domain.tld Errors-to: user@domain.tld From: user@domain.tld To: user@domain.tld Subject: Otheruser@otherdomain has send you an e-card ... > What use if made of envelope from by the MUA or MTA in any case? > At the moment it appears to be completely unnecessary. Bounces. Alex From owner-ietf-mxcomp Sun Mar 21 05:22:16 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2LDMGHb037548; Sun, 21 Mar 2004 05:22:16 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2LDMGp3037547; Sun, 21 Mar 2004 05:22:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2LDMFAB037541 for ; Sun, 21 Mar 2004 05:22:15 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.11/) with ESMTP id i2LDM4cF026856; Sun, 21 Mar 2004 05:22:14 -0800 (PST) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Sun, 21 Mar 2004 05:13:48 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Alex van den Bogaerdt'" , IETF MXCOMP Subject: RE: When spoofing is. Date: Sun, 21 Mar 2004 05:13:47 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > things as bad as: > > HELO mailhost.domain.tld > MAIL FROM: > RCPT TO: > DATA > ... > Reply-to: user@domain.tld > Errors-to: user@domain.tld > From: user@domain.tld > To: user@domain.tld > Subject: Otheruser@otherdomain has send you an e-card > ... And we should prevent giving folk like this some pain because??? From owner-ietf-mxcomp Sun Mar 21 05:27:50 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2LDRoGk038133; Sun, 21 Mar 2004 05:27: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 i2LDRo5q038132; Sun, 21 Mar 2004 05:27:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from slot.hollandcasino.net (slot.hollandcasino.net [193.172.40.18]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2LDRo5Q038124 for ; Sun, 21 Mar 2004 05:27:50 -0800 (PST) (envelope-from alex@ergens.op.het.net) Received: by slot.hollandcasino.net (Postfix, from userid 501) id 9DD0617DC05; Sun, 21 Mar 2004 14:27:51 +0100 (CET) Date: Sun, 21 Mar 2004 14:27:51 +0100 From: Alex van den Bogaerdt To: IETF MXCOMP Subject: Re: When spoofing is. Message-ID: <20040321142751.A30437@slot.hollandcasino.net> Mail-Followup-To: IETF MXCOMP References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from pbaker@verisign.com on Sun, Mar 21, 2004 at 05:13:47AM -0800 X-Legal-Note: ---------------------------------------------- Everything I write or say expresses my opinion only! Unless otherwise stated, I do not represent my employer or anyone else for that matter. ---------------------------------------------------- Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, Mar 21, 2004 at 05:13:47AM -0800, Hallam-Baker, Phillip wrote: > > things as bad as: > > > > HELO mailhost.domain.tld > > MAIL FROM: > > RCPT TO: > > DATA > > ... > > Reply-to: user@domain.tld > > Errors-to: user@domain.tld > > From: user@domain.tld > > To: user@domain.tld > > Subject: Otheruser@otherdomain has send you an e-card > > ... > > And we should prevent giving folk like this some pain because??? ??? I think you are mistaken about the side I'm on. Alex From owner-ietf-mxcomp Sun Mar 21 07:02:02 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2LF22VD043182; Sun, 21 Mar 2004 07:02: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 i2LF225a043181; Sun, 21 Mar 2004 07:02:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2LF212Y043174 for ; Sun, 21 Mar 2004 07:02:02 -0800 (PST) (envelope-from aland@newgiles.nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 3170A170BB for ; Sun, 21 Mar 2004 10:05:46 -0500 (EST) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: When spoofing is. In-Reply-To: Your message of "Sun, 21 Mar 2004 13:28:32 +0100." <20040321132832.B29937@slot.hollandcasino.net> Date: Sun, 21 Mar 2004 10:05:46 -0500 Message-Id: <20040321150546.3170A170BB@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Alex van den Bogaerdt wrote: > > Why would this be anyone other than the postcard site? > > Because they are unwilling to receive their junk back. I've seen > things as bad as: ... Or: EHLO [recipient-ip-address] Such nonsense is highly correlated with spam. The fact that many MTA's accept such traffic can be viewed as a serious implementation flaw. Well.. not really. Nothing in RFC 821 leads anyone to believe that the IP address used in the HELO has to have any value whatsoever. The standard was written at a time when there were certain unspoken expectations, and those were carried into RFC 2821: - MTA's are MTA's for one domain - everyone uses their IP in the EHLO, so there's no need to specify that they need to use it. - etc. ... Alan DeKok. From owner-ietf-mxcomp Sun Mar 21 08:53:44 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2LGriFu049917; Sun, 21 Mar 2004 08:53: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 i2LGriMw049916; Sun, 21 Mar 2004 08:53:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2LGrZcF049908 for ; Sun, 21 Mar 2004 08:53:35 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2LGrWd06102; Sun, 21 Mar 2004 08:53:32 -0800 Date: Sun, 21 Mar 2004 08:53:11 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <127201286.20040321085311@brandenburg.com> To: "Alan DeKok" CC: ietf-mxcomp@imc.org Subject: Re: When spoofing is. In-Reply-To: <20040321150546.3170A170BB@mail.nitros9.org> References: Your message of "Sun, 21 Mar 2004 13:28:32 +0100." <20040321132832.B29937@slot.hollandcasino.net> <20040321150546.3170A170BB@mail.nitros9.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Alan, AD> - MTA's are MTA's for one domain not really. ISPs that support customer-specific domain names have MTAs that service many domains. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Sun Mar 21 09:20:45 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2LHKjSj051074; Sun, 21 Mar 2004 09:20: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 i2LHKjSC051073; Sun, 21 Mar 2004 09:20:45 -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 (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2LHKiuY051065 for ; Sun, 21 Mar 2004 09:20:44 -0800 (PST) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.30) id 1B56cx-0008E4-V3 for ietf-mxcomp@imc.org; Sun, 21 Mar 2004 11:20:48 -0600 To: "IETF MXCOMP" Subject: Re: When spoofing is. References: <20040321132832.B29937@slot.hollandcasino.net> <20040321150546.3170A170BB@mail.nitros9.org> <127201286.20040321085311@brandenburg.com> From: wayne Content-Type: text/plain; charset=US-ASCII Date: Sun, 21 Mar 2004 11:20:47 -0600 In-Reply-To: <127201286.20040321085311@brandenburg.com> (Dave Crocker's message of "Sun, 21 Mar 2004 08:53:11 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (spfd: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Mail-From: wayne@midwestcs.com X-SA-Exim-Scanned: No (on backbone.midwestcs.com); SAEximRunCond expanded to false Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <127201286.20040321085311@brandenburg.com> Dave Crocker writes: > AD> The standard [RFC821] was written at a time when there were > AD> certain unspoken expectations, and those were carried into RFC > AD> 2821: [I unsnipped the above] > AD> - MTA's are MTA's for one domain > > not really. ISPs that support customer-specific domain names have MTAs > that service many domains. There were ISPs when RFC821 was written? My memory is a little fuzzy, but I didn't think the term "ISP" was even invented until the late-80s/early-90s. -wayne From owner-ietf-mxcomp Sun Mar 21 09:34:21 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2LHYLik052017; Sun, 21 Mar 2004 09:34:21 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2LHYLoX052016; Sun, 21 Mar 2004 09:34:21 -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.8) with ESMTP id i2LHYKEM052010 for ; Sun, 21 Mar 2004 09:34:20 -0800 (PST) (envelope-from aland@newgiles.nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id B330D170BB for ; Sun, 21 Mar 2004 12:38:11 -0500 (EST) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: When spoofing is. In-Reply-To: Your message of "Sun, 21 Mar 2004 08:53:11 PST." <127201286.20040321085311@brandenburg.com> Date: Sun, 21 Mar 2004 12:38:11 -0500 Message-Id: <20040321173811.B330D170BB@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dave Crocker wrote: > AD> - MTA's are MTA's for one domain > > not really. ISPs that support customer-specific domain names have MTAs > that service many domains. Now. As I said, back when RFC 821 was written, that kind of deployment was not widely used, so the RFC's weren't written with that configuration in mind. So now that we have that kind of configuration, it's unclear how those MTA's should be set up. What does it mean when an MTA delivers mail for many domains? What is the relationship between the fields in SMTP and those domains? Is it expected to get EHLO example.com, and MAIL FROM user@example.net? The current implementation and deployment of MTAs may "just work", but that doesn't mean they're optimal, or even correct. Alan DeKok. From owner-ietf-mxcomp Sun Mar 21 09:37:28 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2LHbSL3052204; Sun, 21 Mar 2004 09:37: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 i2LHbSRJ052203; Sun, 21 Mar 2004 09:37:28 -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.8) with ESMTP id i2LHbRma052197 for ; Sun, 21 Mar 2004 09:37:27 -0800 (PST) (envelope-from aland@newgiles.nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 1FEE1170BB for ; Sun, 21 Mar 2004 12:41:19 -0500 (EST) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: When spoofing is. In-Reply-To: Your message of "Sun, 21 Mar 2004 11:20:47 CST." Date: Sun, 21 Mar 2004 12:41:19 -0500 Message-Id: <20040321174119.1FEE1170BB@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: wayne wrote: > > AD> The standard [RFC821] was written at a time when there were > > AD> certain unspoken expectations, and those were carried into RFC > > AD> 2821: > [I unsnipped the above] Thank you. Having my text quoted out of context inverted the sense of what I was saying. Alan DeKok. From owner-ietf-mxcomp Sun Mar 21 09:38:24 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2LHcNJb052236; Sun, 21 Mar 2004 09:38: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 i2LHcNl7052235; Sun, 21 Mar 2004 09:38:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (IDENT:root@ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2LHcNDW052229 for ; Sun, 21 Mar 2004 09:38:23 -0800 (PST) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-19-105.client.comcast.net [24.6.19.105]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i2LHcOiL025602 for ; Sun, 21 Mar 2004 09:38:24 -0800 (PST) Received: by tethys.bitshift.org (Postfix, from userid 1001) id 968CA22887; Sun, 21 Mar 2004 09:38:24 -0800 (PST) Date: Sun, 21 Mar 2004 09:38:24 -0800 From: "Mark C. Langston" To: IETF MXCOMP Subject: Re: When spoofing is. Message-ID: <20040321173824.GY67093@bitshift.org> Mail-Followup-To: IETF MXCOMP References: <20040319185852.GE67093@bitshift.org> <20040320001507.A15929@slot.hollandcasino.net> <20040319234906.GL67093@bitshift.org> <20040320021220.B16782@slot.hollandcasino.net> <20040320042235.GN67093@bitshift.org> <20040321132408.A29937@slot.hollandcasino.net> Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20040321132408.A29937@slot.hollandcasino.net> User-Agent: Mutt/1.4.1i X-Uptime: 9:27AM up 278 days, 12:37, 7 users, load averages: 0.00, 0.00, 0.00 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, Mar 21, 2004 at 01:24:08PM +0100, Alex van den Bogaerdt wrote: > > I don't think that sites such as those postcard sites are legitimate > services. They are spoofing addresses, sending unsollicited email and > are very irresponsible when it comes down to handling errors. They > make no effort at all to verify the initiating side is valid, nor do > they care if the receiving side is able to take their mail. > Perhaps you and I are thinking of different services. I'm thinking of the likes of http://apple.com/icards/. What are you thinking of? It's certainly legitimate, and it's typically unsolicited but not unwelcome (the unstated assumption underlying unsolicited -- when people use "unsolicited email" perjoratively, they mean both unsolicited and unwelcome). As for their error-handling, well, I've not heard of any incidents involving Apple, but right now, most MTAs are as guilty of your charges as postcard sites. Even after MARID is published, adopted, and embraced by the community, that will still be true. > "... that the problems have been created ..." makes me feel personally > attacked; you are telling me I am seeing problems that are not real. > And you've repeated that. Once again, no. I'm saying the following: If we create a solution, and that solution seems prima facæ to be an attack against certain specific legitimate services out of spite as well as spammers, it won't be taken well. The odds of it being taken as such are high, given that this mailing list is archived, and said spite has already been voiced. > > I am not here to combat spam. I am here to combat email fraud. Spam > is just one of many forms of fraud. Could you list the others? This goes back to the "[il]legitimate spoofing" thread, and it'd be good to have suppositions about what you view as "fraud" on the table. Right now, I'm getting the impression that it's any altering of the From: or ENVELOPE-FROM header. -- Mark C. Langston Sr. Unix SysAdmin mark@bitshift.org mark@seti.org Systems & Network Admin SETI Institute http://bitshift.org http://www.seti.org From owner-ietf-mxcomp Sun Mar 21 09:47:49 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2LHln5m052777; Sun, 21 Mar 2004 09:47: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 i2LHlnKa052776; Sun, 21 Mar 2004 09:47:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (IDENT:root@ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2LHlnSt052769 for ; Sun, 21 Mar 2004 09:47:49 -0800 (PST) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-19-105.client.comcast.net [24.6.19.105]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i2LHloiL028423 for ; Sun, 21 Mar 2004 09:47:50 -0800 (PST) Received: by tethys.bitshift.org (Postfix, from userid 1001) id 4B75522887; Sun, 21 Mar 2004 09:47:50 -0800 (PST) Date: Sun, 21 Mar 2004 09:47:50 -0800 From: "Mark C. Langston" To: IETF MXCOMP Subject: Re: When spoofing is. Message-ID: <20040321174750.GZ67093@bitshift.org> Mail-Followup-To: IETF MXCOMP References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Uptime: 9:27AM up 278 days, 12:37, 7 users, load averages: 0.00, 0.00, 0.00 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, Mar 21, 2004 at 05:13:47AM -0800, Hallam-Baker, Phillip wrote: > > > things as bad as: > > > > HELO mailhost.domain.tld > > MAIL FROM: > > RCPT TO: > > DATA > > ... > > Reply-to: user@domain.tld > > Errors-to: user@domain.tld > > From: user@domain.tld > > To: user@domain.tld > > Subject: Otheruser@otherdomain has send you an e-card > > ... > > And we should prevent giving folk like this some pain because??? Can you distinguish between that evil postcard site based on RFC2821 identity, and a mobile user attempting to use an address other than the one his ISP has assigned him (say, for example, his work address)? Assume for the sake of argument that the ISP blocks outbound port 25, 465 and 587, so the entity cannot connect directly to their office MTA. Or, shall we force everyone who travels on business to expose their personal email accounts when conducting business while on the road? -- Mark C. Langston Sr. Unix SysAdmin mark@bitshift.org mark@seti.org Systems & Network Admin SETI Institute http://bitshift.org http://www.seti.org From owner-ietf-mxcomp Sun Mar 21 11:24:13 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2LJODhH058596; Sun, 21 Mar 2004 11:24: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 i2LJODNw058595; Sun, 21 Mar 2004 11:24:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (IDENT:root@ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2LJOCn6058588 for ; Sun, 21 Mar 2004 11:24:12 -0800 (PST) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-19-105.client.comcast.net [24.6.19.105]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i2LJOEiL022139 for ; Sun, 21 Mar 2004 11:24:15 -0800 (PST) Received: by tethys.bitshift.org (Postfix, from userid 1001) id CDDB422887; Sun, 21 Mar 2004 11:24:14 -0800 (PST) Date: Sun, 21 Mar 2004 11:24:14 -0800 From: "Mark C. Langston" To: IETF MXCOMP Subject: Re: When spoofing is. Message-ID: <20040321192414.GA67093@bitshift.org> Mail-Followup-To: IETF MXCOMP References: <20040321174750.GZ67093@bitshift.org> Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.1i X-Uptime: 10:41AM up 278 days, 13:51, 7 users, load averages: 0.08, 0.05, 0.01 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, Mar 21, 2004 at 12:32:29PM -0600, wayne wrote: > > In <20040321174750.GZ67093@bitshift.org> "Mark C. Langston" writes: > > > On Sun, Mar 21, 2004 at 05:13:47AM -0800, Hallam-Baker, Phillip wrote: > >> > >> > [example SMTP session with all domains spoofed] > >> > >> And we should prevent giving folk like this some pain because??? > > > > > > Can you distinguish between that evil postcard site based on RFC2821 > > identity, and a mobile user attempting to use an address other than the > > one his ISP has assigned him (say, for example, his work address)? > > No, we can't make a distinguish between various kinds of > spoofing/forgery/munging/whatever-you-want-to-call-it. > Well, semantic difficulties aside (we won't get into the whole "legitimate spoofing" again), there are legitimate reasons to alter RFC2822 headers. And we need to be careful that the restrictions placed on RFC2821 headers don't create widespread problems for legitimate changes of identity. > > > Assume for the sake of argument that the ISP blocks outbound port 25, > > 465 and 587, so the entity cannot connect directly to their office MTA. > > Well, I have a whole bundle of disagreements with this sentence. > > First, you would also have to assume that the ISP blocks all VPNs, > port 80/443 traffic to webmail systems run by their company, SMTP over > other ports and all other means to communication with their office. > I doubt that you can find such an ISP, but if you do, I would > recommend not using them. They don't sound particularly useful. > And here, you've assumed the presence of VPN, webmail systems, SMTP over nonstandard ports, etc. Many ISPs prohibit VPN use or insist on a more expensive service tier if TCP protos 50 and 51 are to be used. As for blocking outbound mail use, Earthlink's a good example. It's all well and good to think, "we'll put in a very strong anti-spoofing system and let the chips fall where they may", but I'm on Dave's side with this: We need to be careful what consequences ensue from our recommendations. We can't see ourselves as dictating widespread infrastructure changes unnecessarily; we should be seeking a solution that has maximum desired effect _and_ minimum infrastructure impact. Otherwise, we'll be greatly limiting the acceptance of this group's product. Here's another valid use of spoofing (again, apologies to Dave): Anonymous remailers. If the postcard contingent aren't viewed as valuable in this discussion, how about the bulk of the pro-privacy and cryptography communities? > > Second, does the hypothetical ISP prevent email going through there > MTA to have the same RFC2821 MAIL FROM as the RFC2822 From: data? > If not, you can, at least theoretically, use your ISPs account on the > RFC2821 MAIL FROM: and your work address on the From:. This is > basically what all mailing list software does. > Yes, but is it what all MUAs do? End-users never interact with the RFC2821 identity; the software does that for them. > Can you cite examples of ISPs that would have such a restriction? > Which restriction? Blocking outbound mail use on servers other than their MTAs? Earthlink, for one. Insisting upon the ISP's assigned account be in the RFC2822 From: header? Programmatically, no, not off the top of my head. By policy, yes: Comcast is but one example. From http://www.comcast.net/terms/use.jsp : (xviii) impersonate any person or entity, engage in sender address falsification, forge anyone else's digital or manual signature, or perform any other similar fraudulent activity; > > Third, I can understand an ISP/Companies blocking port 25 traffic > from other than their authorized MTAs. The vast majority of such > email is spam, and blocking such traffic cuts down on abuse desk > costs. However, I have a much harder time understanding why an ISP > would block 587 traffic. It is my understanding that almost all MTAs > require some sort of validation before accepting email on the > submission port. > > Can you cite examples of MTAs that accept unauthorized email to port > 587? Can you cite examples of ISPs that block port 587? > No. But æs Meng states on the pobox.com SPF pages, ISPs don't _yet_ block port 587, which he points out as justification for using it as a workaround for ISPs blocking 25 outbound. As for reasons as to why they might in the future: The ISP may view use of port 587 as an attempt to skirt their outbound 25 block. The ISP may not have a well-implemented port-blocker, and it may already be blocked out of negligence, and remain so out of inertia. The ISP may wish to keep their customers on their infrastructure, and therefore block 587 just as they block 25. It's okay to say, "change ISPs" when it's a single, rogue ISP doing this. But when the status quo is, "thou shalt use our MTAs, and only our MTAs, for all outbound mail", the lack of port 587 blocking may largely be due to the lack of port 587 use. Force traffic to migrate to that port, and it may well end up blocked as well. We can't guess the reasons for ISPs doing these things, nor can we know whether they will. The one thing that's certain is that wholescale changes like this will have consequences, and those consequences aren't easily knowable. We could recommend those changes and hope for the best, but hoping for the best is what got us into this situation to begin with. We're moving from an open trust model to a closed trust model. I believe that movement will result in a balkanization among service providers to the detriment of the end user, unless and until software catches up to the changes and finds ways to minimize the damage. > > Fourth, if someone is really in a very locked down network (public > access terminals?), is it really that unreasonable to ask them to use > the appropriate email address and add a comment to the top of the > message that says "Hi, I'm at a restricted terminal, this is really > foo@example.net"? I don't know. Is it reasonable to assume automated anti-spam tools can interpret that? You assume that comment will make it to a human. Whitelisting in current tools works on RFC2822 identities, typically. > > Domain owners that publish LMAP restrictions need to be aware that in > some cases, their legitimate users will have to make some changes. I > don't see this as a big problem. > User education as solution? > > > Or, shall we force everyone who travels on business to expose their > > personal email accounts when conducting business while on the road? > > I'm not sure what you mean by "expose" here. If I'm travelling on business, and I can't use my work address in the headers for whatever reason (whether it's due to ISP enforcement or bounces resulting from RFC2821 checks), I'd have to use whatever works with that ISP. The same holds true if I want to send work email from my home, using my home ISP. If that's my personal ISP account, it's been "exposed". Many people prefer to keep their business and personal email separate. Futher, they like to keep one group from discovering the identity used in the other group. Handing over a list of personal addresses to one's employer isn't typical. Perhaps the solution is to have the employer pay for the ISPs used on the road, and that's reasonable. But what about all other scenarios in which the employee is out of the office, on personal time, and needing to send an email with a work address? I'm all for everyone moving to SMTP AUTH. In much the same way, I'm in favor of ubiquitous encrypted communication. But I don't believe either are going to occur until everyone is forced to do so. I don't think forcing everyone to do so is the correct approach, however. Not without an easy transition between the two, _and_ a sunset provision for the older, less-secure approach. I can see a way to do the former, but no way to enforce the latter. Without the latter, I can't see any impetus to change, particularly in organizations where change is met with significant inertia. What I'm getting at here is this: Is there any data on how MUAs create the RFC2821 identity based on RFC2822 identity? How many MUAs simply take what's on the RFC2822 From: and use it for the RFC2821 ENVELOPE-FROM, and how many allow manipulation of the RFC2821 identity? If we're moving towards a world in which we completely eliminate the MUA direct-to-recipient-MTA connection, we should acknowledge and embrace that, rather than talking around it. -- Mark C. Langston Sr. Unix SysAdmin mark@bitshift.org mark@seti.org Systems & Network Admin SETI Institute http://bitshift.org http://www.seti.org From owner-ietf-mxcomp Sun Mar 21 11:27:21 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2LJRLZr058698; Sun, 21 Mar 2004 11:27:21 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2LJRL8U058697; Sun, 21 Mar 2004 11:27:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (IDENT:root@ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2LJRLnd058690 for ; Sun, 21 Mar 2004 11:27:21 -0800 (PST) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-19-105.client.comcast.net [24.6.19.105]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i2LJRNiL022480 for ; Sun, 21 Mar 2004 11:27:23 -0800 (PST) Received: by tethys.bitshift.org (Postfix, from userid 1001) id 414232288B; Sun, 21 Mar 2004 11:27:23 -0800 (PST) Date: Sun, 21 Mar 2004 11:27:23 -0800 From: "Mark C. Langston" To: IETF MXCOMP Subject: Re: When spoofing is. Message-ID: <20040321192723.GB67093@bitshift.org> Mail-Followup-To: IETF MXCOMP References: <20040321174750.GZ67093@bitshift.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Uptime: 11:25AM up 278 days, 14:34, 8 users, load averages: 0.08, 0.06, 0.01 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, Mar 21, 2004 at 12:32:29PM -0600, wayne wrote: > > Can you cite examples of ISPs that would have such a restriction? > I should also add this statement from Comcast's AUP (from the section entitled "Electronic Mail"): Forging, altering, or removing electronic mail headers is prohibited. I believe this restriction is fairly common across ISPs. By implication, the end user is expected to use the ISP-supplied email address and only that address with all outbound email. -- Mark C. Langston Sr. Unix SysAdmin mark@bitshift.org mark@seti.org Systems & Network Admin SETI Institute http://bitshift.org http://www.seti.org From owner-ietf-mxcomp Sun Mar 21 10:32:26 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2LIWQBR055755; Sun, 21 Mar 2004 10:32: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 i2LIWQN7055754; Sun, 21 Mar 2004 10:32:26 -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 (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2LIWPsY055744 for ; Sun, 21 Mar 2004 10:32:25 -0800 (PST) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.30) id 1B57kL-0000pm-Ce for ietf-mxcomp@imc.org; Sun, 21 Mar 2004 12:32:29 -0600 To: IETF MXCOMP Subject: Re: When spoofing is. References: <20040321174750.GZ67093@bitshift.org> From: wayne Content-Type: text/plain; charset=US-ASCII Date: Sun, 21 Mar 2004 12:32:29 -0600 In-Reply-To: <20040321174750.GZ67093@bitshift.org> (Mark C. Langston's message of "Sun, 21 Mar 2004 09:47:50 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (spfd: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Mail-From: wayne@midwestcs.com X-SA-Exim-Scanned: No (on backbone.midwestcs.com); SAEximRunCond expanded to false Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <20040321174750.GZ67093@bitshift.org> "Mark C. Langston" writes: > On Sun, Mar 21, 2004 at 05:13:47AM -0800, Hallam-Baker, Phillip wrote: >> >> > [example SMTP session with all domains spoofed] >> >> And we should prevent giving folk like this some pain because??? > > > Can you distinguish between that evil postcard site based on RFC2821 > identity, and a mobile user attempting to use an address other than the > one his ISP has assigned him (say, for example, his work address)? No, we can't make a distinguish between various kinds of spoofing/forgery/munging/whatever-you-want-to-call-it. > Assume for the sake of argument that the ISP blocks outbound port 25, > 465 and 587, so the entity cannot connect directly to their office MTA. Well, I have a whole bundle of disagreements with this sentence. First, you would also have to assume that the ISP blocks all VPNs, port 80/443 traffic to webmail systems run by their company, SMTP over other ports and all other means to communication with their office. I doubt that you can find such an ISP, but if you do, I would recommend not using them. They don't sound particularly useful. Can you cite any examples of ISPs that prevent all communication? Second, does the hypothetical ISP prevent email going through there MTA to have the same RFC2821 MAIL FROM as the RFC2822 From: data? If not, you can, at least theoretically, use your ISPs account on the RFC2821 MAIL FROM: and your work address on the From:. This is basically what all mailing list software does. Can you cite examples of ISPs that would have such a restriction? Third, I can understand an ISP/Companies blocking port 25 traffic from other than their authorized MTAs. The vast majority of such email is spam, and blocking such traffic cuts down on abuse desk costs. However, I have a much harder time understanding why an ISP would block 587 traffic. It is my understanding that almost all MTAs require some sort of validation before accepting email on the submission port. Can you cite examples of MTAs that accept unauthorized email to port 587? Can you cite examples of ISPs that block port 587? Fourth, if someone is really in a very locked down network (public access terminals?), is it really that unreasonable to ask them to use the appropriate email address and add a comment to the top of the message that says "Hi, I'm at a restricted terminal, this is really foo@example.net"? Domain owners that publish LMAP restrictions need to be aware that in some cases, their legitimate users will have to make some changes. I don't see this as a big problem. > Or, shall we force everyone who travels on business to expose their > personal email accounts when conducting business while on the road? I'm not sure what you mean by "expose" here. -wayne From owner-ietf-mxcomp Sun Mar 21 11:44:52 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2LJiqDn060168; Sun, 21 Mar 2004 11:44: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 i2LJiqfP060167; Sun, 21 Mar 2004 11:44:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from slot.hollandcasino.net (slot.hollandcasino.net [193.172.40.18]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2LJipuI060161 for ; Sun, 21 Mar 2004 11:44:52 -0800 (PST) (envelope-from alex@ergens.op.het.net) Received: by slot.hollandcasino.net (Postfix, from userid 501) id 1D41E17DC05; Sun, 21 Mar 2004 20:44:55 +0100 (CET) Date: Sun, 21 Mar 2004 20:44:55 +0100 From: Alex van den Bogaerdt To: IETF MXCOMP Subject: Re: When spoofing is. Message-ID: <20040321204455.A32450@slot.hollandcasino.net> Mail-Followup-To: IETF MXCOMP References: <20040319185852.GE67093@bitshift.org> <20040320001507.A15929@slot.hollandcasino.net> <20040319234906.GL67093@bitshift.org> <20040320021220.B16782@slot.hollandcasino.net> <20040320042235.GN67093@bitshift.org> <20040321132408.A29937@slot.hollandcasino.net> <20040321173824.GY67093@bitshift.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040321173824.GY67093@bitshift.org>; from mark@bitshift.org on Sun, Mar 21, 2004 at 09:38:24AM -0800 X-Legal-Note: ---------------------------------------------- Everything I write or say expresses my opinion only! Unless otherwise stated, I do not represent my employer or anyone else for that matter. ---------------------------------------------------- Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, Mar 21, 2004 at 09:38:24AM -0800, Mark C. Langston wrote: > > I am not here to combat spam. I am here to combat email fraud. Spam > > is just one of many forms of fraud. > > Could you list the others? This goes back to the "[il]legitimate > spoofing" thread, and it'd be good to have suppositions about what you > view as "fraud" on the table. Right now, I'm getting the impression > that it's any altering of the From: or ENVELOPE-FROM header. for instance: Received: from e3.ny.us.ibm.com (e3.esmtp.ibm.com [9.14.6.103]) by d01as03.pok.ibm.com (8.12.10/8.12.10) with ESMTP id i2LG2lSw025428 for ; Sun, 21 Mar 2004 11:02:47 -0500 Received: from us.ibm.com ([203.193.137.98]) by e3.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i2LG2ddJ785288 for ; Sun, 21 Mar 2004 11:02:41 -0500 Message-Id: <200403211602.i2LG2ddJ785288@e3.ny.us.ibm.com> From: alex@slot.hollandcasino.net To: simo@us.ibm.com Subject: how? with the usual virus payload attached. How do I see these headers? Well, IBM was kind enough to bounce them to me. I'm sure you've seen other examples, such as paypal asking you to verify your account information. But let's not participate in this silliness. I don't believe you are unaware of the many problems, so the only logical conclusion is that you are a troll. Go feed on someone else please. Alex From owner-ietf-mxcomp Sun Mar 21 11:56:35 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2LJuZ9I060810; Sun, 21 Mar 2004 11:56:35 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2LJuZsT060809; Sun, 21 Mar 2004 11:56:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (IDENT:root@ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2LJuYDm060803 for ; Sun, 21 Mar 2004 11:56:34 -0800 (PST) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-19-105.client.comcast.net [24.6.19.105]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i2LJubiL029933 for ; Sun, 21 Mar 2004 11:56:37 -0800 (PST) Received: by tethys.bitshift.org (Postfix, from userid 1001) id 49E9422887; Sun, 21 Mar 2004 11:56:37 -0800 (PST) Date: Sun, 21 Mar 2004 11:56:37 -0800 From: "Mark C. Langston" To: IETF MXCOMP Subject: Re: When spoofing is. Message-ID: <20040321195637.GC67093@bitshift.org> Mail-Followup-To: IETF MXCOMP References: <20040319185852.GE67093@bitshift.org> <20040320001507.A15929@slot.hollandcasino.net> <20040319234906.GL67093@bitshift.org> <20040320021220.B16782@slot.hollandcasino.net> <20040320042235.GN67093@bitshift.org> <20040321132408.A29937@slot.hollandcasino.net> <20040321173824.GY67093@bitshift.org> <20040321204455.A32450@slot.hollandcasino.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040321204455.A32450@slot.hollandcasino.net> User-Agent: Mutt/1.4.1i X-Uptime: 11:51AM up 278 days, 15 hrs, 8 users, load averages: 0.00, 0.01, 0.00 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, Mar 21, 2004 at 08:44:55PM +0100, Alex van den Bogaerdt wrote: > > On Sun, Mar 21, 2004 at 09:38:24AM -0800, Mark C. Langston wrote: > > > > I am not here to combat spam. I am here to combat email fraud. Spam > > > is just one of many forms of fraud. > > > > Could you list the others? This goes back to the "[il]legitimate > > spoofing" thread, and it'd be good to have suppositions about what you > > view as "fraud" on the table. Right now, I'm getting the impression > > that it's any altering of the From: or ENVELOPE-FROM header. > [...snip] > > with the usual virus payload attached. How do I see these headers? Well, > IBM was kind enough to bounce them to me. > > I'm sure you've seen other examples, such as paypal asking you to verify > your account information. Actually, I was hoping you'd list less obvious, more borderline cases of identity alteration, rather than going for what everyone would agree was spam. You said you want to "combat email fraud", and I mentioned that to me, your position seems to be "prohibit any and all identity alteration". I was just asking you to clarify your position. So, let me ask in a different way: Do you agree or disagree that your position is "prohibit any and all identity alteration"? If you disagree, could you provide an example of what you'd view as legitimate identity alteration? > > But let's not participate in this silliness. I don't believe you are > unaware of the many problems, so the only logical conclusion is that > you are a troll. Go feed on someone else please. That's not productive. Could we keep the discussion focused on the task at hand, rather than personal attacks? You brought up a very broad term -- "email fraud" -- and stated you were against it. I'm just trying to understand the boundaries of the term you introduced, from your point of view. -- Mark C. Langston Sr. Unix SysAdmin mark@bitshift.org mark@seti.org Systems & Network Admin SETI Institute http://bitshift.org http://www.seti.org From owner-ietf-mxcomp Sun Mar 21 12:46:19 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2LKkJMp064384; Sun, 21 Mar 2004 12:46: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 i2LKkJpM064383; Sun, 21 Mar 2004 12:46:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [64.139.47.218]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2LKkIFi064377 for ; Sun, 21 Mar 2004 12:46:18 -0800 (PST) (envelope-from gconnor@nekodojo.org) Received: from [10.12.1.18] (gconnor-home-pv.nekodojo.org [10.12.1.18]) by neko-base.nekodojo.org (Postfix) with ESMTP id 5F7E91D656 for ; Sun, 21 Mar 2004 12:46:22 -0800 (PST) Date: Sun, 21 Mar 2004 12:46:26 -0800 From: Greg Connor To: IETF MXCOMP Subject: Re: When spoofing is. Message-ID: <73580140.1079873186@[10.12.1.18]> In-Reply-To: <20040321192414.GA67093@bitshift.org> References: <20040321192414.GA67093@bitshift.org> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2LKkJFi064378 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >> > On Sun, Mar 21, 2004 at 05:13:47AM -0800, Hallam-Baker, Phillip wrote: >> >> And we should prevent giving folk like this some pain because??? >> > >> In <20040321174750.GZ67093@bitshift.org> "Mark C. Langston" >> writes: >> > Can you distinguish between that evil postcard site based on RFC2821 >> > identity, and a mobile user attempting to use an address other than the >> > one his ISP has assigned him (say, for example, his work address)? >> > On Sun, Mar 21, 2004 at 12:32:29PM -0600, wayne wrote: >> No, we can't make a distinguish between various kinds of >> spoofing/forgery/munging/whatever-you-want-to-call-it. >> > --"Mark C. Langston" wrote: > Well, semantic difficulties aside (we won't get into the whole > "legitimate spoofing" again), there are legitimate reasons to alter > RFC2822 headers. And we need to be careful that the restrictions placed > on RFC2821 headers don't create widespread problems for legitimate > changes of identity. Mark and Wayne- I think you two agree more than you disagree. May I suggest that you try a bit harder to state your own positions concisely, rather than concentrating on DISagreeing with what the other person said? I would much rather read a paragraph or two of well-written and well-thought text describing what you think, than to see a thread go on and on with one-liner comebacks that are all argument and no discussion. Let's assume that there is a WIDE range of proposals possible, and at either two extremes are "Modify nothing. Fix nothing." and "Break as much as possible to make things more technically correct." I don't think anyone here would reasonably pick either of these. I think we want a solution that gives a balance of "maximal pain to spammers, minimal pain to legitimate users". So, please focus on saying what you mean and what you think. And please don't assume that because someone uses an extreme or a generalization to make a point that they necessarily advocate extremes or believe generalizations. Using extremes and generalizations are lazy ways to make a point, but attacking those instead of attacking the point prolongs the agony for everyone else :) Thanks for your time. >> > Assume for the sake of argument that the ISP blocks outbound port 25, >> > 465 and 587, so the entity cannot connect directly to their office MTA. >> >> Well, I have a whole bundle of disagreements with this sentence. >> >> First, you would also have to assume that the ISP blocks all VPNs, >> port 80/443 traffic to webmail systems run by their company, SMTP over >> other ports and all other means to communication with their office. >> I doubt that you can find such an ISP, but if you do, I would >> recommend not using them. They don't sound particularly useful. >> > > And here, you've assumed the presence of VPN, webmail systems, SMTP over > nonstandard ports, etc. Many ISPs prohibit VPN use or insist on a > more expensive service tier if TCP protos 50 and 51 are to be used. As > for blocking outbound mail use, Earthlink's a good example. > > It's all well and good to think, "we'll put in a very strong > anti-spoofing system and let the chips fall where they may", but I'm on > Dave's side with this: We need to be careful what consequences ensue > from our recommendations. We can't see ourselves as dictating > widespread infrastructure changes unnecessarily; we should be seeking a > solution that has maximum desired effect _and_ minimum infrastructure > impact. Otherwise, we'll be greatly limiting the acceptance of this > group's product. > > Here's another valid use of spoofing (again, apologies to Dave): > Anonymous remailers. If the postcard contingent aren't viewed as > valuable in this discussion, how about the bulk of the pro-privacy and > cryptography communities? > >> >> Second, does the hypothetical ISP prevent email going through there >> MTA to have the same RFC2821 MAIL FROM as the RFC2822 From: data? >> If not, you can, at least theoretically, use your ISPs account on the >> RFC2821 MAIL FROM: and your work address on the From:. This is >> basically what all mailing list software does. >> > > Yes, but is it what all MUAs do? End-users never interact with the > RFC2821 identity; the software does that for them. > >> Can you cite examples of ISPs that would have such a restriction? >> > > Which restriction? Blocking outbound mail use on servers other than > their MTAs? Earthlink, for one. Insisting upon the ISP's assigned > account be in the RFC2822 From: header? Programmatically, no, not off > the top of my head. By policy, yes: Comcast is but one example. > > From http://www.comcast.net/terms/use.jsp : > (xviii) impersonate any person or entity, engage in sender address > falsification, forge anyone else's digital or manual signature, or > perform any other similar fraudulent activity; > >> >> Third, I can understand an ISP/Companies blocking port 25 traffic >> from other than their authorized MTAs. The vast majority of such >> email is spam, and blocking such traffic cuts down on abuse desk >> costs. However, I have a much harder time understanding why an ISP >> would block 587 traffic. It is my understanding that almost all MTAs >> require some sort of validation before accepting email on the >> submission port. >> >> Can you cite examples of MTAs that accept unauthorized email to port >> 587? Can you cite examples of ISPs that block port 587? >> > > No. But æs Meng states on the pobox.com SPF pages, ISPs don't _yet_ > block port 587, which he points out as justification for using it as a > workaround for ISPs blocking 25 outbound. > > As for reasons as to why they might in the future: The ISP may view use > of port 587 as an attempt to skirt their outbound 25 block. The ISP may > not have a well-implemented port-blocker, and it may already be blocked > out of negligence, and remain so out of inertia. The ISP may wish to > keep their customers on their infrastructure, and therefore block 587 > just as they block 25. > > It's okay to say, "change ISPs" when it's a single, rogue ISP doing > this. But when the status quo is, "thou shalt use our MTAs, and only > our MTAs, for all outbound mail", the lack of port 587 blocking may > largely be due to the lack of port 587 use. Force traffic to migrate to > that port, and it may well end up blocked as well. > > We can't guess the reasons for ISPs doing these things, nor can we know > whether they will. The one thing that's certain is that wholescale > changes like this will have consequences, and those consequences aren't > easily knowable. > > We could recommend those changes and hope for the best, but hoping for > the best is what got us into this situation to begin with. We're moving > from an open trust model to a closed trust model. I believe that > movement will result in a balkanization among service providers to the > detriment of the end user, unless and until software catches up to the > changes and finds ways to minimize the damage. > > >> >> Fourth, if someone is really in a very locked down network (public >> access terminals?), is it really that unreasonable to ask them to use >> the appropriate email address and add a comment to the top of the >> message that says "Hi, I'm at a restricted terminal, this is really >> foo@example.net"? > > I don't know. Is it reasonable to assume automated anti-spam tools can > interpret that? You assume that comment will make it to a human. > Whitelisting in current tools works on RFC2822 identities, typically. > >> >> Domain owners that publish LMAP restrictions need to be aware that in >> some cases, their legitimate users will have to make some changes. I >> don't see this as a big problem. >> > > User education as solution? > >> >> > Or, shall we force everyone who travels on business to expose their >> > personal email accounts when conducting business while on the road? >> >> I'm not sure what you mean by "expose" here. > > If I'm travelling on business, and I can't use my work address in the > headers for whatever reason (whether it's due to ISP enforcement or > bounces resulting from RFC2821 checks), I'd have to use whatever works > with that ISP. The same holds true if I want to send work email from my > home, using my home ISP. > > If that's my personal ISP account, it's been "exposed". Many people > prefer to keep their business and personal email separate. Futher, they > like to keep one group from discovering the identity used in the other > group. Handing over a list of personal addresses to one's employer > isn't typical. > > Perhaps the solution is to have the employer pay for the ISPs used on > the road, and that's reasonable. But what about all other scenarios in > which the employee is out of the office, on personal time, and needing > to send an email with a work address? I'm all for everyone moving to > SMTP AUTH. In much the same way, I'm in favor of ubiquitous encrypted > communication. But I don't believe either are going to occur until > everyone is forced to do so. I don't think forcing everyone to do so is > the correct approach, however. Not without an easy transition between > the two, _and_ a sunset provision for the older, less-secure approach. > I can see a way to do the former, but no way to enforce the latter. > Without the latter, I can't see any impetus to change, particularly in > organizations where change is met with significant inertia. > > What I'm getting at here is this: Is there any data on how MUAs create > the RFC2821 identity based on RFC2822 identity? How many MUAs simply > take what's on the RFC2822 From: and use it for the RFC2821 > ENVELOPE-FROM, and how many allow manipulation of the RFC2821 identity? > > If we're moving towards a world in which we completely eliminate > the MUA direct-to-recipient-MTA connection, we should acknowledge and > embrace that, rather than talking around it. > > > -- > Mark C. Langston Sr. Unix SysAdmin > mark@bitshift.org mark@seti.org > Systems & Network Admin SETI Institute > http://bitshift.org http://www.seti.org -- Greg Connor From owner-ietf-mxcomp Sun Mar 21 13:30:28 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2LLUScG067389; Sun, 21 Mar 2004 13:30: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 i2LLUSKA067388; Sun, 21 Mar 2004 13:30: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 (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2LLUR29067382 for ; Sun, 21 Mar 2004 13:30:27 -0800 (PST) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.30) id 1B5AWe-00035a-5x for ietf-mxcomp@imc.org; Sun, 21 Mar 2004 15:30:32 -0600 To: IETF MXCOMP Subject: Re: When spoofing is. References: <20040321174750.GZ67093@bitshift.org> <20040321192414.GA67093@bitshift.org> From: wayne Content-Type: text/plain; charset=ISO-8859-1 Date: Sun, 21 Mar 2004 15:30:31 -0600 In-Reply-To: <20040321192414.GA67093@bitshift.org> (Mark C. Langston's message of "Sun, 21 Mar 2004 11:24:14 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (spfd: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Mail-From: wayne@midwestcs.com X-SA-Exim-Scanned: No (on backbone.midwestcs.com); SAEximRunCond expanded to false Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2LLUS29067383 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: [note: Co-chair Andrew Newton posted a etiquette list that suggests posting no more than three times a day, so this will be my last post today.] In <20040321192414.GA67093@bitshift.org> "Mark C. Langston" writes: > And we need to be careful that the restrictions placed > on RFC2821 headers don't create widespread problems for legitimate > changes of identity. Agreed. >> > Assume for the sake of argument that the ISP blocks outbound port 25, >> > 465 and 587, so the entity cannot connect directly to their office MTA. >> >> Well, I have a whole bundle of disagreements with this sentence. >> >> First, you would also have to assume that the ISP blocks all VPNs, >> port 80/443 traffic to webmail systems run by their company, SMTP over >> other ports and all other means to communication with their office. >> I doubt that you can find such an ISP, but if you do, I would >> recommend not using them. They don't sound particularly useful. >> > > And here, you've assumed the presence of VPN, webmail systems, SMTP over > nonstandard ports, etc. Many ISPs prohibit VPN use or insist on a > more expensive service tier if TCP protos 50 and 51 are to be used. It is encumbent on those domain owners that *choose* to publish LMAP restrictions to provide their legitimate users methods of working within those restrictions. Users who have IT departments that make bad choices generally know how to contact them to voice their complaints. There will probably be some users that have IT departments that are so bad that the market place will take care of eliminating them. > As for blocking outbound mail use, Earthlink's a good example. I realize that there are ISPs that block outbound email. I am not aware of any ISPs that block all methods of communication. > It's all well and good to think, "we'll put in a very strong > anti-spoofing system and let the chips fall where they may", but I'm on "We" are not going to put in a very strong anti-spoofing system. "We" are going to give domain owners, via the LMAP proposals, a voice and a way for email receivers to listen. Domain owners and/or email receivers can choose not to communicate anything. > Dave's side with this: We need to be careful what consequences ensue > From our recommendations. We can't see ourselves as dictating > widespread infrastructure changes unnecessarily; we should be seeking a > solution that has maximum desired effect _and_ minimum infrastructure > impact. Yes, our recommendations need to inform people of the consequences of their actions. "We" can not dictate anything, much less widespread infrastructure changes. > Here's another valid use of spoofing (again, apologies to Dave): > Anonymous remailers. If the postcard contingent aren't viewed as > valuable in this discussion, how about the bulk of the pro-privacy and > cryptography communities? All LMAP proposals allow domain owners to choose to say that all IP addresses are valid sources of email. By default, this will let them keep the status quo. >> Second, does the hypothetical ISP prevent email going through there >> MTA to have the same RFC2821 MAIL FROM as the RFC2822 From: data? >> If not, you can, at least theoretically, use your ISPs account on the >> RFC2821 MAIL FROM: and your work address on the From:. This is >> basically what all mailing list software does. >> > > Yes, but is it what all MUAs do? End-users never interact with the > RFC2821 identity; the software does that for them. If any of the LMAP proposals are widely adopted, it may be useful for MUA developers to allow that option. (I suspect that it will be rarely needed, but...) >> Can you cite examples of ISPs that would have such a restriction? > > Which restriction? Blocking outbound mail use on servers other than > their MTAs? Earthlink, for one. Insisting upon the ISP's assigned > account be in the RFC2822 From: header? Programmatically, no, not off > the top of my head. By policy, yes: Comcast is but one example. You raised the point about distinguishing between postcard sites that allow arbitrary creation of RFC2821/2822 headers to be sent and roaming users. The restrictions, therefore, are ISPs that allow you to send out email with arbitrary RFC2821/2822 headers, but not allow you to send out email where they don't match. Neither of the examples you cite restrict the latter without restricting the former. Therefore, the LMAP proposals do not make things any worse. >> Can you cite examples of MTAs that accept unauthorized email to port >> 587? Can you cite examples of ISPs that block port 587? >> > > No. But æs Meng states on the pobox.com SPF pages, ISPs don't _yet_ > block port 587, which he points out as justification for using it as a > workaround for ISPs blocking 25 outbound. > > As for reasons as to why they might in the future: The ISP may view use > of port 587 as an attempt to skirt their outbound 25 block. The ISP may > not have a well-implemented port-blocker, and it may already be blocked > out of negligence, and remain so out of inertia. The ISP may wish to > keep their customers on their infrastructure, and therefore block 587 > just as they block 25. We can not prevent ISPs from doing stupid stuff, but in any case, it is their network and their rules. The LMAP proposals do not change this situation. > We're moving > from an open trust model to a closed trust model. No, we are moving from a model where domain owners have no voice to a model where they do. Domain owners that like the open trust model will be able to express that and email receivers that don't want any closed model will not have to listen. > I believe that > movement will result in a balkanization among service providers to the > detriment of the end user, unless and until software catches up to the > changes and finds ways to minimize the damage. I disagree. If you give people a voice, there will always be those that will choose to use their freedom of speech to say things that are stupid/bad/hateful/destructive/silly. However, I fundamentally trust that the benefits of free speech outweigh the costs. This is especially true when no one is forced to listen, as in the case of all of the LMAP proposals. Buying a domain name is only $5-10/yr, so even if you need to buy a domain to get a voice, we aren't talking about a huge cost. >> Domain owners that publish LMAP restrictions need to be aware that in >> some cases, their legitimate users will have to make some changes. I >> don't see this as a big problem. > > User education as solution? Yes. Educating domain owners/email receivers and having them educate their users is not always easy, but it is far better than not allowing them to have a voice. > If we're moving towards a world in which we completely eliminate > the MUA direct-to-recipient-MTA connection, we should acknowledge and > embrace that, rather than talking around it. None of the LMAP proposals in any way give new restrictions the direct-to-recipient-MTA connection. They simply take company/ISP policies off of the web pages, TUAs, employee handbooks, etc., and automate them. -wayne From owner-ietf-mxcomp Sun Mar 21 14:39:42 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2LMdgpm070920; Sun, 21 Mar 2004 14:39: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 i2LMdggp070919; Sun, 21 Mar 2004 14:39:42 -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 (srv1.pan-am.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2LMdfJc070911 for ; Sun, 21 Mar 2004 14:39:42 -0800 (PST) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: When spoofing is. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 21 Mar 2004 16:39:46 -0600 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA7F5@srv1.pan-am.ca> X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: When spoofing is. Thread-Index: AcQPew9z8otw++hVRz2LpHnGZHtOWwAGNUhA From: "Gordon Fecyk" To: "IETF MXCOMP" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2LMdgJc070913 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Here's another valid use of spoofing (again, apologies to Dave): > Anonymous remailers. If the postcard contingent aren't viewed as > valuable in this discussion, how about the bulk of the pro-privacy and > cryptography communities? Alan and John (et al - correct authors cited this time!) covered this in the LMAP discussion draft. It is possible for an enterprise to provide both accountable and anonymous services. Now this is a good reason to verify by domain only and not necessarily by sender, though a clever design could verify by anonymous sender too, without exposing the identity of the sender. > No. But as Meng states on the pobox.com SPF pages, ISPs don't _yet_ > block port 587, which he points out as justification for using it as a > workaround for ISPs blocking 25 outbound. I would think any mail host offering SMTP on port 587 requires some kind of authentication, and only authorized users would use it. It wouldn't be open to abuse by default. At least not from a "responsible" mail host but that's another discussion altogether. The original point of blocking outbound port 25 was to avoid dial-up and relay spam, though some ISPs use it as a means to enforce corporate identity. If not 587 then some other port, probably - users would get uppity if port 1863 (MSN Messenger) was blocked. Or Jabber ports. Or Protocol 47 (GRE used for PPTP). Or Port 443 for secure webmail. Or whatever. You'd have to be a pretty repressive ISP, coprorate entity or government to block these and not get lynched by your customers. > User education as solution? Customer service issue. Of course I've ranted about this at length, too. -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Sun Mar 21 15:14:56 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2LNEu0e073363; Sun, 21 Mar 2004 15:14: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 i2LNEur5073362; Sun, 21 Mar 2004 15:14:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2LNEtCx073355 for ; Sun, 21 Mar 2004 15:14:56 -0800 (PST) (envelope-from millenix@zemos.net) Received: from fda.zemos.net ([68.38.12.170]) by comcast.net (rwcrmhc13) with ESMTP id <2004032123144901500ks52ue>; Sun, 21 Mar 2004 23:14:49 +0000 Received: from zemos.net (phil [10.0.0.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fda.zemos.net (Postfix) with ESMTP id C326818680; Sun, 21 Mar 2004 18:14:48 -0500 (EST) Message-ID: <405E21E8.6010107@zemos.net> Date: Sun, 21 Mar 2004 18:14:48 -0500 From: Philip Miller User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040312 Debian/1.6-3 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Hector Santos Cc: IETF-MXCOMP Subject: Re: Top Concerns, Issues, Comments References: <002e01c40ea4$ea73f5b0$6401a8c0@hdev1> <405CE880.8020805@zemos.net> <002801c40f0c$60dda860$6401a8c0@hdev1> In-Reply-To: <002801c40f0c$60dda860$6401a8c0@hdev1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hector Santos wrote: >>> o No Spams this week! >> logs... nope, all spammers!> >> >> Congratulations. Does this mean 0 false positives that you've >> distinguished purely by how they were recorded in your MTA logs? > > I check for both false negatives (incorrect rejections) and false > postivies (incorrect acceptance). > > Yes, I look at everything. Trust me. Engineering is in my bones. I ask then, when you're checking for incorrect results, how can you tell before DATA whether a mail was spam or not. Obviously, if it was rejected, it didn't comply with your implemented policy. For example, if someone on these lists whose address you didn't recognize (perhaps using a private address not used on the list) sent you a personal message that was blocked by the spamcop RBL, you would not be able to distinguish it in your logs. My assertion here is that you can't possibly 'look at everything' when you haven't received everything, DATA and all. As a point of interest, SMTP allows a fairly long wait (10 minutes, RFC 2821 4.5.3.2) between receiving the end of DATA's payload and sending the final response code. Ideally, transactions would never get to DATA because it wastes bandwidth and processing time, but for development purposes, perhaps you should be going to that point. This way you could still reject it on whatever criteria you'd like, but you now have the DATA payload to confirm against. Statistical information about the payload of the messages you're rejecting vs. accepting could also be useful. > Here is an example of a false negative: > [snip log data] > > This is a example where the testing fell through to the final CBV test and > it failed because the return path was not acceptable at this domain. This > was back in Feb 17. So I can't say today, but without the CBV you won't see > this. I can't throw out the baby with the bath water because of situations > like this. It do find it ironic one of the top people in IETF does not have > a valid return path in his setup. This is not in no way a knock on Paul, > and I surely hope he doesn't see it that way, but this is an example of the > realities of the new world. Compliancy is a very big of the picture for > any of this new work can even have a chance. If the above is deemed > "acceptable" then we might as well give up now. Again, if you didn't recognize that address as belonging to Paul Hoffman, how would you know it's an incorrect result? (Side note here: I think you're reversing the common usage of false positive and false negative. False positives are messages incorrectly treated as spam, and false negatives are messages incorrectly treated as non-spam/ham.) > Incidently, with SPF implemented, in the past few weeks, we are > experiencing an increase in false positives which are eventually filtered by > the CBV or by mail-content filters at the DATA stage. This indicates the > expected increase of SPF compliant spammers. Spammers will either comply > or they don't. Spoofing will probably no longer work for those who apply > LMAP concepts. That's good. What we're trying to achieve in these first steps is preventing spammers from taking advantage of someone else's good reputation and abusing their resources with false CBV attempts and bounce messages. > With that experience, it was obvious we needed to a SPF options to our > product to offer some control over the remote non-fail situation: > > ; SPF can return low trust results. A pass means the sender has > ; a valid SPF record and is accepted. Softfail and Neutral means > ; no match is found but rejection is not automatic. Setting a > ; true accept can provide a loophole for potential spoofers who have > ; SPF records and think they will be allowed access. The options > ; below allow you to control this. > > Accept-SPF-Pass True ; if false, continue testing > Accept-SPF-SoftFail False ; if false, continue testing > Accept-SPF-Neutral False ; if false, continue testing No comment here, aside from noting that your product sounds very nice. >>> o LMAP works best to protect your own domains. Low trust in remote >>> domain checking. >> >> On the contrary, you can trust that if a domain publishes LMAP records, >> and an incoming connection claiming association with that domain that >> is not born out by the LMAP data, you can pretty well trust that it is >> a forged connection. > > Clarification: > > - LMAP offers 100% trust in local domain spoof protection > - LMAP offers less than or equal 100% trust in remote domain reject results. > - LMAP offers little to no trust in remote non-fail results. > > A positive result can not be trusted 100%, where a negative has a 100% > trust value: > > 0 < trust positive < trust negative = 100% > > More specifically, the trust inquality is: > > 0 < Remote Domain Pass < Remote Domain Reject < Local Domain = 100% OK, I see now. I just have one issue with equating LMAP with SPF. LMAP has no official implementation as yet. SPF is an implementation of the ideas LMAP entails plus somewhat more. >>>o LMAP has a high DNS overhead for remote domain checking. >> >> Should be no worse than doing an A lookup on the HELO name or the PTR >> lookup on the IP. I'm not so familiar with the inner workings of DNS, >> but couldn't the LMAP and HELO/A lookups be done in a single query? Let me clarify this: in the case of a system that's not logging so much connection-time data, I think you could replace the A and PTR lookups on the hostname and IP and only do the LMAP lookup. > I don't claim to be a DNS expert (but I'm getting there ), but based > on my analysis, I think it all depends on whether the domain exist or > not. OK. > [snip DNS timing issue for my lack of relevant knowledge] > > Now, I believe DNS behaves the same for A records lookups. It depends on > whether it exist or not. This is why I consistently and continue to say > that LMAP operates best for Local Domain Spoof protection. Once you (and > everyone else for that matter) go to remote, well, not only do you increase > DNS overhead when the majority of the domains are spoofed or don't exist, > but the result can not be trusted unless it is reject. The goal is that eventually no lookup will result in an immediate reject, because spammers will be compliant too. The upside of this is that they will no longer be abusing the name and resources of an innocent third party. > The question than becomes of a trade off. This is why you need to > understand my LMAP Validation tables posted at: > > http://www.winserver.com/public/antispam/lmap/draft-lmapanalysis1.htm > > In Table 1.0, Group D shows 3 states where LMAP can be used when RCPT > validation is not a factor. Table 2.0 shows how Group D is expanded to 6 > states when RCPT is considered but LMAP is only necessary for 3 of the 6 > states; when the RCPT user is local (final destination). For remote RCPT, > that requires an entirely different relay authentication standard practice. > So it doesn't apply. OK. > In other words, this tells you that if you postpone the LMAP lookup until > the RCTP state is known, you can drastically improve your LMAP operations. > In fact, by our estimates when LMAP (or WCSAP) was done before RCPT is > known, the average session time was 60+ seconds. When wcSAP was postpone > until the RCPT was known, the average session time shot down to 21+ seconds. Do you really get that many invalid RCPT TO addresses that get rejected that moving wcSAP checks after RCPT checking makes a 40 second difference on average? >>>o LMAP compliant spammers is a reality! Can't trust remote checks! >> >> Sure you can: you can trust that they control the domain they're >> sending as, and not forging someone else's. > > See trust statement above. :-) OK. >>> o CBV continues to prove the return path address is more important >>> than just the return path domain. >> >>Could you elaborate on this point? > > address #1: baduser@spfdomain.com > address #2: gooduser@spfdomain.com > > Both addresses may pass the domain spf policy test when in actuality, only > user #2 is valid. The CBV will pick up on this and usually does. Of > course, that doesn't mean it the remote can't easily bypass it. Nothing you > can about that. But again, the focus in our testing is to look for > "rejects" as they are the only thing you can trust. Out of curiosity, could you test VRFY before RCPT when checking a given MAIL FROM address? It'd be interesting to see how they compare. Using VRFY may also speed things up a bit if it actually provides the necessary information, as a client is allowed (RFC 2821, 4.1.4) to issue VRFY without sending and getting responses to EHLO and MAIL first. The issue there is that many sites disable the use of VRFY to prevent higher-speed dictionary & harvesting attacks. > From a RFC 2821 standpoint, CBV or LMAP, what needs to be clarified is the > ambiguity surrounding the "time" when the return path is considered > legitimate. I've seen interesting comments that even though the RFC > presumes the return path to be valid, it only needs to be valid come bounce > time. Well, that is what the spammers exploits, this exact mode of > operation. I agree with you that the return path should always be valid at the time of the transaction, at least in principle. However, the issue of checking it via RCPT TO is sticky. Your goal of finding a strict justification to reject is clearly hampered by this. I just don't see how we can reasonably solve it. > PS: I understand all the technical issues surrounding a CBV. That is why we > are even dealing with other methods as a means to bypass the CBV. On the other hand, I see rejecting messages if a RCPT TO the return path is rejected as a perfectly legitimate local policy, which if implemented Internet-wide would at least prevent many double-bounces and the like. >>>o Anonymous Access Management system *can* work without a fundamental change >>>to SMTP. >>> >>>o SMTP functional specifications (the RFCs) must change in order for >>>technical specification enforcement to take place. >> >> You can enforce any technical specification you'd like. RFC [2]821 >> explicitly allow the rejection of any connection for any local policy >> reason. > > This is a false philosophy that has played the rounds for so many years, > which does have legal precedence, but it is NOT as clear cut as you make is > sound. Actually the law does have something to say about this.. I've > designed mail transport, gateway, frontend software for many networks as > well. The law covers all systems. The implications is if you accept, you > are responsible for it. Delivery or Bounce. The RFC covers this, but it is > the law with precedence behind it. The most important point here is that > the ADMIN has full control of the system on the initial acceptance of the > message. What is also very important is you better not tamper with it. OK, so I think we agree that the most important goals with respect to reducing liability would be to: 1. Maximize the number of messages that can be rejected during the SMTP session, rather than bounced 2. Guarantee the validity of the bounce address to the furthest possible extent For #2, I think 'the furthest possible extent', when implemented on the Internet scale is exactly what you're testing: a. the domain is not spoofed b. messages to the bounce address will be accepted Once the domain is validated, it is the responsibility of that domain to validate the mailbox part of the MAIL FROM address. This includes using facilities such as SMTP and TLS client certificates to prevent outbound transmissions with spoofed addresses, as well as ensuring that any message sent can be correctly bounced. > [Side track note] Another email myth is the private mail system. If I write > you a private message, legal precedence has provided the recipient the > right to make the message public. However, if the author clearly states in > the message the "intent of privacy is to be maintained", then the recipient > risk tort liability by making it public. The exception to this ECPA law is > company employer mail systems. Employees had no privacy rights. > Implications with LMAP? False Rejections being sent to SPAM database sites > making private mail public. This is something to note in a BCP: don't auto-submit messages determined by local policy to be spam to public databases. On the other hand, if the message is automatically submitted, rather than seen by a human being, is the system administrator liable for that violation of privacy? That's a question for a lawyer, but I would think that he is not liable. >>> o SMTP functional specifications must change in order for CAN-SPAM >>> can even begin to work. >> >>CAN-SPAM is irrelevant to the work of this group, because the Internet >>encompasses more than the jurisdiction of US law. > > May be irrevalent to you or this group but it isn't to the product vendor. > We already have customers (whether they understand the concepts or not) > asking if we are "CAM-SPAM ready." > > I have a deep and long time ethical and software engineering philosophy that > can not be shaken. We write products for other people. Not just for us. We > are not ignorant of liability issues, we follow the standard to the fullest > possible extent and there is simply no compromise. If a US Federal Law has > provide two mandates in CAN-SPAM that says: > > - Return Address must be valid > - Topic Identification must be provided > > then we are not going to be oblivous to this new federal requirement for > spammers and for mail systems to help make it happen. The FEDs have given > the IETF 18 months (now 15 months) to define the IETF standards that the > spammers must comply with. And you can legitimately tell your customers that they can send messages that are compliant with the requirements placed on them by [random {[inter]national,regional,state,local anti-spam law] using your software and doing X, Y, and Z in addition. In other words, you can say "Yes, it is possible to send CAN-SPAM compliant messages with my product" to your customers. In the case of CAN-SPAM, they effectively must own the domain name they're sending from, accept bounces, honor unsubscribe requests, and use accurate subject lines, possibly including an 'ADV:' or similar tag. Hell, you could offer CAN-SPAM consultation and training, to show them how to properly send mail. Also, as Yakov has pointed out, that is a mischaracterization of the law's implications for IETF. > LMAP has given SMTP developer industry the ability to statisfy mandate #1. > So Anonymous Access Management is possible with current SMTP standards if we > use LMAP as a way to provide the enforcement policies lacking in SMTP alone. This is not a mandate for receivers to enforce. This is a minimum hurdle for senders to pass to avoid legal consequences absent other abusive and/or illegal behaviour. If a new law were passed requiring that marketing messages only be sent by those with 18" long red hair, would you ask the IETF for a standard to aid enforcement of that, too? Perhaps we need coiffure accreditation (CA) companies to verify this for the rest of us? > What is missing now is #2, and this is where there is a conflict with > current SMTP standard operations. We need an ESMTP extension for this at > the protocol level otherwise systems will be force to operate in a "always > accept" mail mode for post SMTP validation or DATA stage validation. That's way out of this group's likely scope. May possibly be within scope of ASRG SMTP-Verify, though I'm not sure. >>>o Why is it that I get a constant ~2500 connections? with a constant >>>spam/rejection 90% rate? >> >>Since you obviously see some significance to those numbers, you tell us. > > I need to do some IP analytics. What is surprising me is that the numbers > are constant. Its like these guys are organized with a scheduler that > repeats itself over and over again. :-) Look at the statistics yourself: > > http://www.winserver.com/public/antispam > > In isolated analysis, it does seem there is a "change" in behavior or some > go away, some come back. :-) But the statistics are just too consistent. > There has to be an explanation. I can only think these guys have me on auto > pilot and could care less if you reject them or not. That isn't going to > stop them from trying anyway. > > This has me thinking of late that not only there is a potential for a > localized network relationship of your mail transactions, i.e, "web of > trust," but also a "web of mis-trust." I think there is a pattern here and > I would like to one day analyze this, if possible. In other words, it isn't > as random as one might think. Take it to ASRG, there are interested parties there. When there's specific data and information in that of interest in the development of a complement to MX records, please point it out specifically. >>>o 80% of all transactions is spoofed. >> >>By what criteria? > > By emperical data and by industry research data. When we first only had > CBV, the rate we were seeing between 80-94% of all transactions were > rejected with spoofed or non-existence domains. It has matched all > industry research published on the subject. Internet-wide MXCOMP implementation should change that by making it useless for spammers to spoof at all. Most likely, it doesn't mean that the number of connections we see will drop by 80%. >>> o Local Domain (HELO) Spoofing is 10%. 80% is RBL rejected, 10% >>> rejected by CBV >> >> You mean 10% of rejections are based on the results of your algorithm >> for detection of HELO spoofing. You're algorithm can't determine if >> it's legitimate. > > We are not in the business of determining legitimacy of mail. We are 100% > focus on protocol level compliancy. Take a moment to see our stats. I will > summarize it here (Using March stats upto this point) I'm not talking about legitimacy of mail, but legitimacy of HELO usage. There is nothing in the protocol beyond being a FQDN or address literal that defines protocol compliance of the HELO argument. > Average Calls/Connects: 2449 > Immediate Drops at the greeting (no HELO/EHLO issued): 5.3% > Drops after issueing HELO/EHLO: 75.2% Lack of HELO/EHLO is clearly non-compliant, so that's within reason to reject. Presently, however, rejection based on EHLO-IP correlation is explicitly prohibited (RFC 2821, 4.1.4, paragraph 6) > This means 575 reach MAIL FROM. Now, we delay the wcSAP validation in MAIL > FROM until RCPT is known. This is per the RFC 2821 recommendation. > > Rejects at RCPT: 31.5% > > This means that wcSAP will only be called for 69.5% or 400 transactions for > local domain users issued. Before a RCPT response is issued, wcSAP is then > called to perform a suite of test based on the IP, HELO, and MAIL FROM. > > What we see is is 53% of the 400 or 212 is rejected by wcSAP for one reason > or another. The break is: > > FLT (Internal Filter Accept/Reject rules), 8.6% or 18 > RBL, 78.1% or 166 > SPF, 0% > CBV, 12% or 25 > > The remaining 188 reaching the DATA stage, 10.8% is rejected with our > in-house rule based mail filters, leaving, about 168 messages that were > accepted. > > Now if you are looking at the stats, the %accept shows ~90 transactions were > accepted. This is the true amount as it is based on the final "250 message > accepted for delivered" for the DATA stage. So the missing amounts not > shown are drops after HELO and/or the duplicate RCPT rejected which > increases the percentage. > > In any case, this has been pretty consistent. What I am going to add soon > is a column should the number of domains with SPF records. I'm am > differently seeing more spammers than legitimate systems, which I guess make > sense, given the fact I have such a high rate of spoofing spammers. Data on the specific breakdown of implementation of various MXCOMP designs would be most useful here. >[snip] >>> o SPF needs to get rid of softfail and neutral policies. If system is >>> not ready for it, then don't use it! >> >> I can't really answer that, as I'm not too deeply familiar with SPF. >> However, I suspect that softfail modes are probably there for the same >> reason that the Postfix MTA has a softbounce option (45x rather than >> 55x on failures): to prevent configuration errors leading to >> catastrophies. > > Actually, it (softfail, neutral) is there for migration reasons based on the > SPF specification. I already suggested to Meng that there should be a > time limit for this specified in the specification. It can not be permanent. > The "relaxed" specifications opens the doors to loopholes which is what we > are trying to get away from in the first place with the relaxed SMTP specs. > Those items need to go IMO They are totally useless (except for reject > results). It should certainly be possible to put a 'flag day' in place, after which email whose originating domains offer softfail and neutral policies could be rejected. That is certainly something to keep in mind if SPF or something substantially similar is settled upon by this group. >>>Suggestions: >>> >>>o CAN-SPAM provides two mandates; return path validation and topic >>>identication; Use this model!! >> >>As stated above, CAN-SPAM is irrelevant. > > Not in my view and IMO, I strongly believe it would be a mistake by anyone > seriously addressing the email issue to ignore it like its doesn't exist. > CAN-SPAM is already being used a model for other nations laws. > > In any case, we will differ strongly on this point, so its not worth any > more discussion about it. OK, I agree that we should consider its provisions when shaping any anti-spam spec or standard, but by irrelevant I mean that our requirements for an MXCOMP solution should not be shaped by it without regard to the actual technical problem that we are trying to address. >>> o Add Multiple line greeting to eliminate many of your spammers! 60% >>> on our system. >> >>Perhaps I'll try it. > > Ironically, one of our last minute changes to our new version pending > release, was to address a PHP "mail()" command bug where this multi-line > greeting was found to cause a problem for a customer with the new version he > was gamma testing. Has this been reported to php.net as a bug? If not, I'll gladly do so. > The new logic is to only show the multiline policy file at the greeting if > and only if the IP is remote, not local. He was running PHP script from a > local web server on the same network. So the new logic fixes this. Of > course, it is also optional by default. As a general policy, implementing such a work-around seems like a bad idea, but if it's disabled by default, I see no reason not to provide better service to your customers. >>> o LMAP may provide incentive for the building of "Network >>> Relationships" or "LMAP-Nets" >> >>If you've been following ASRG's SMTP-Verify subgroup, you'll see a great >>deal of ongoing discussion of the 'web of trust' concept. > > "The more things change, the more they remain the same." :-) :-) >>>o Need SMTP Message-Id Verification (Exist) Feedback System. >> >> May be the next step, but there's nothing to stop a spammer from >> setting up a system to provide that verification. Just makes them >> incrementally more traceable. > > As a side note. What I find interesting in all these efforts is a focus to > design a system that fit the current "spam model based on current SMTP > model" Well, the solution is to change it, i.e, force the SPAMMERS to > change. Lack of compliance can only be blamed on lack of enforcement > policies. We can always use a time framework concept. We are in the process of changing the system to reject certain invalid transactions, to force spammers to change along with it. That's the purpose of this group. I don't quite understand that last sentence. Perhaps you could rephrase it? >>>o SMTP needs a protocol topic identication command, i.e., "SUBJ" >> >>Why would any spammers comply with it? > > CAN-SPAM? Oh, it's irrevalent :-) In terms of actually stopping spam from reaching user's mailboxes, I still believe it is irrelevant. >> Only the 'legitimate' (as in above the table) marketers would, and >> they're already easy to filter. > > Good point, which is another thought I had: > > - LMAP efforts is a high cost narrow focused incomplete solution for a short > term problem > > What is funny about all this is that what is technically a simple > authentication issue, we have add a new level of fuzzy logic to the > equation that may required a neural network to make it all work. :-) I don't see where the fuzzy logic comes in here. Presently, we have a variety of systems that check HELO and IP in myriad (fuzzy) ways. MXCOMP will ideally collapse those to something much simpler and more deterministic. > Of course, the way to look at this is what if it does work? at what expense? > What will be a overhead issue, now becames an redundancy issue. Not following you here... >>>o BCP: RCPT validation stops SOBIG generation email virus distribution >>>dependency on bounce mail attacks. >> >>I'm not quite sure what you're saying with this. All of the LMAP-like >>proposals on the table would prevent the initial spoofing of domains that >>worms & viruses do. > > That depends on your perspective, which is another issue I find in the many > forums: > > - Philosophical differences can be traced to the mode of operation one is > used to operating in; dynamic vs post SMTP RCPT validation. > > If you don't validate RCPT at the SMTP level, then you will be operating in > a mode which promotes bounces. Remember, once you accept a message, it is > a traditional engineering design as well as ethical and when push comes to > shove, even legal obligation to deliver it or bounce it. You simply can't > just "lose it." RFC 2821 spells that out, but that is inherent in all mail > network systems. As I said above, the local system policy does have a > strong say here, but you are open to liability issues. There is precedence > for this. Agreed on this point, and I addressed it above. > What is changing this long time traditional fundamental "natural law" in > mail transport design is the new era of malicious mail, thus the legal > question has become that you can now reject "SMTP accepted mail" without > further notification. > > This is something that is totally brand new in the mail transport design - > the idea of rejecting and discarding "already accepted" mail based on post > transaction mail filters without notification. It can open a can of worms. > This is why I strongly believe a system lowers its liability by doing the > mail filter rejection at the DATA stage while the transaction is still > active. Well, RFC 2821 explicitly allows up to 10 minutes to do this, and perhaps IETF should be involved in creating standards for better communciation between MTAs and filters. Again, something outside this group's narrow predicted scope. This is certainly worthwhile discussion, although I'm not sure it should be happening here. Perhaps we should move this to ASRG? Please simply redirect your response, or split this thread into scoped parts, if you agree. Phil From owner-ietf-mxcomp Sun Mar 21 16:06:02 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2M062Yw075873; Sun, 21 Mar 2004 16:06: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 i2M062KY075872; Sun, 21 Mar 2004 16:06:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2M062xF075866 for ; Sun, 21 Mar 2004 16:06:02 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2M067d02579 for ; Sun, 21 Mar 2004 16:06:07 -0800 Date: Sun, 21 Mar 2004 16:05:46 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1657222923.20040321160546@brandenburg.com> To: IETF MXCOMP Subject: Choice of SMTP headers In-Reply-To: <7371920.1079698052@gconnor.corp.yahoo.com> References: <20040319162556.GA67093@bitshift.org> <7371920.1079698052@gconnor.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Folks, GC> My guess is that RFC2821 MAIL FROM will match From: or Sender: most of the GC> time. Certainly, for a very long time, folks thought RFC2822 Sender and RFC2821 Mail From really were the same. They both were expected to list the agent that initially injected the mail into the transfer service. However that is not the world we live in today. RFC2822 is quite clear about the intended semantics for Sender (cf, section 3.6.2). RFC2821 (section 3.3) has language that is proving somewhat more challenging, since it refers to the "source" without explaining what that actually means. However the second part of the language talks about actual use of the string "to report errors", and actual use always trumps theory. So, yes, frequently Mail From == Sender, such as for this very mailing list. However redirection of bounces to different addresses that are not "source" addresses has become a common, essential requirement for many, legitimate bulk mail operations. GC> But, spammers/phishers are crafty- if MAIL FROM / Return-Path GC> validation starts in earnest, they may start to diverge from this. There is no "may" about it. Spammers use any means available to bypass controls attempted against them. GC> 4. Some checking of RFC 2821 HELO might be helpful but this should not be GC> the main focus of the sender authentication effort. Why? What is it that we can be certain of learning from Mail From, versus what is it we can be certain of learning from EHLO? And why is one more important than the other, for control of spam. GC> However, some users have reported that they get really great results GC> from... We need to be very, very careful about _any_ statement beginning with language like this. There have been many "localized" effects in the control of spam, but nothing has had any global effect at reducing spam. Therefore, generalizing from prior experience in spam control can be very misleading. Often, something that works in small, local environments, does not scale to the global Internet. >> How do people feel about coming up with a draft RFC that focuses on >> RFC2821 MAIL FROM first and following up with a DATA/Headers extension >> to it later? Can we have multiple draft RFC's come from the same working >> group? If the work is within the scope of the working group's charter, then it is fine to have multiple specification documents YS> The key here is whether the DNS-based mechanism that is defined in this YS> WG will allow for both. If the mechanism is made extensible enough, than YS> we can start off with the MAIL FROM or HELO mechanism first, get that YS> approved, and then delve into the "from" header issues. The question will be whether an "extension" to the first mechanism will provide the requisite necessary functionality. FWIW, my guess is that this "extension" will require a different mechanism, even if both use the DNS. >> AD> - MTA's are MTA's for one domain >> >> not really. ISPs that support customer-specific domain names have MTAs >> that service many domains. AD> Now. As I said, back when RFC 821 was written, that kind of AD> deployment was not widely used, so the RFC's weren't written with that AD> configuration in mind. (Not that this alters the technical discussion, but just to offer some history...) In fact off-net relaying was a core part of the discussions for RFC2821, both with respect to the design of SMTP and the benefit of domain names. There were at least two major relaying operations on the net at the time, and one of them was particularly well represented in the SMTP specification efforts. This latter activity was called CSNet -- it turned out to be a precursor to NSFNet -- and two sites did relaying for about 30-40 organizations, in those days. So, udel.edu and rand.org were the domains listed in the HELO string, but were typically not the MAIL FROM or From or Sender strings. What _has_ fundamentally changed, of course, is the implicit trust through the service. sigh. AD> What does it mean when an MTA delivers mail for many domains? It means we need to be clear about the role of a third-party carriage service. That's like postal monopolies (USPS, Canada Post, etc.) or Fedex/UPS, or a telephone company. As we consider having the carriage service impose requirements on the content, we should pay careful attention to prior experience with that in related, large-scale services. MCL> Here's another valid use of spoofing (again, apologies to Dave): MCL> Anonymous remailers. If the postcard contingent aren't viewed as I think folks missed the reason I took exception to using the word spoof to cover legitimate situations: Very simply, it is not spoofing. Spoofing is about deception, typically by a third party. When the mail says it is from me and, in fact, it is from me, then it is not spoofing. The fact that I might be sending the mail from a different place than usual does not make it spoofing. When you are traveling and you post a letter with the hotel, rather than by having the letter carrier pick it up from the mailbox attached to your house, is that spoofing? Of course not. It is mobility. It is flexible posting. It is posting from multiple MUAs. It is lots of things. But it is not spoofing. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Sun Mar 21 18:13:47 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2M2DlTo083113; Sun, 21 Mar 2004 18:13: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 i2M2DlwE083112; Sun, 21 Mar 2004 18:13:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [64.139.47.218]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2M2Dk7F083101 for ; Sun, 21 Mar 2004 18:13:46 -0800 (PST) (envelope-from gconnor@nekodojo.org) Received: from [10.12.1.18] (gconnor-home-pv.nekodojo.org [10.12.1.18]) by neko-base.nekodojo.org (Postfix) with ESMTP id B0C811D656 for ; Sun, 21 Mar 2004 18:13:52 -0800 (PST) Date: Sun, 21 Mar 2004 18:13:57 -0800 From: Greg Connor To: IETF MXCOMP Subject: Re: Choice of SMTP headers Message-ID: <93230703.1079892837@[10.12.1.18]> In-Reply-To: <1657222923.20040321160546@brandenburg.com> References: <1657222923.20040321160546@brandenburg.com> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > GC> 4. Some checking of RFC 2821 HELO might be helpful but this should > not be GC> the main focus of the sender authentication effort. > --Dave Crocker wrote: > Why? > > What is it that we can be certain of learning from Mail From, versus > what is it we can be certain of learning from EHLO? > > And why is one more important than the other, for control of spam. Actually, I don't have a strong preference regarding HELO checking, so let me back off of my previous statement a bit. I would like to see the first push aimed at RFC2821 MAIL FROM, but beyond that, HELO checking might have some value too. Clearly both HELO and MAIL FROM were important enough at one time to make it into RFC821. I have a general idea that there is a lot of broken software out there that gives HELO as a short, unqualified, non-existent or otherwise weird name. I don't have a lot of data to back it up... I have just heard from others in passing that HELO checking can be good, but currently requires a lot of white-listing and exceptions. Who knows? Perhaps HELO checking and enforcement is incredibly important. It could be. I just don't have any data to back that up. > GC> However, some users have reported that they get really great results > GC> from... > > We need to be very, very careful about _any_ statement beginning with > language like this. There have been many "localized" effects in the > control of spam, but nothing has had any global effect at reducing spam. > > Therefore, generalizing from prior experience in spam control can be > very misleading. Often, something that works in small, local > environments, does not scale to the global Internet. Point well taken. I would agree with this. There are a number of folks who have localized solutions supported by analyzing their own data flow, but a lot of data about "the whole picture" is not really known or well-measured. About the only thing we can do about it is 1. a lot more research among many parties, or 2. make some educated guesses and then test them out. -- Greg Connor From owner-ietf-mxcomp Sun Mar 21 18:34:54 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2M2YsNg084639; Sun, 21 Mar 2004 18:34:54 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2M2Ysa4084638; Sun, 21 Mar 2004 18:34:54 -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 (srv1.pan-am.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2M2Yreh084631 for ; Sun, 21 Mar 2004 18:34:53 -0800 (PST) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: Choice of SMTP headers MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 21 Mar 2004 20:34:59 -0600 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA7F8@srv1.pan-am.ca> X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Choice of SMTP headers Thread-Index: AcQPs/n6c4VP35TrSJ2d67/I5jVP4wAAMJ1g From: "Gordon Fecyk" To: "IETF MXCOMP" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2M2Yreh084633 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Who knows? Perhaps HELO checking and enforcement is > incredibly important. > It could be. I just don't have any data to back that up. I approached HELO as a way to check delivery status notification messages (MAIL FROM:<>). At one point this was a popular way to get past early spam filters and RFC 2821 still requires accepting this envelope. So I only wanted to check HELO if the envelope was null, to make sure the message really came from a MTA as opposed to a user. That being said I do see a lot of "HELO MACHINE-NAME" coming from MTAs (not just MUAs run by users, but MTAs too). It isn't normally what I see but it's there. I find it's usually because the machine doesn't know the domain it belongs to and it can be fixed by telling it. Other MTAs have a HELO or EHLO string setting they can change. While MUAs often don't know what domain they're in and just HELO MACHINENAME all the time, allowed networks or AUTH should be able to override any LMAP-type checks so they can send mail through that server. The HELO check becomes moot. I'm only interested in an outside MTA's HELO, and again only if the RFC 2821 envelope is null. -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Sun Mar 21 19:59:54 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2M3xsbg089660; Sun, 21 Mar 2004 19:59:54 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2M3xsTM089659; Sun, 21 Mar 2004 19:59:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2M3xrH0089653 for ; Sun, 21 Mar 2004 19:59:53 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.11/) with ESMTP id i2M400Yi010049 for ; Sun, 21 Mar 2004 20:00:00 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Sun, 21 Mar 2004 20:00:00 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: IETF MXCOMP Subject: RE: Choice of SMTP headers Date: Sun, 21 Mar 2004 19:59:55 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: i think there are two worthwhile solutions that can be built on authentication. 1) Authentication of valid use of domain name + Accreditation 2) Eliminate impersonation spam aka 'Joe Job' that decieves the _HUMAN_RECIPIENT_ as to the origin of the message by preventing unauthorized use of a domain name in RFC822 From header. >From the point of view of accreditation it simply does not matter what part of the message you choose to authenticate, it can be HELO, it can be 821 From, 822 From, Reply-to, even a received header. It does not matter because the only use for the data is to determine that the sender has a valid claim on the good reputation carried in the accreditation. If you do not do accreditation I see absolutely no value in authenticating headers and protocol data values that are only ever seen by machines. >From the point of view of providing value from this spec as a stand-alone work I don't see that there is much value unless we address issue (2). In that case we do quite a bit to mitigate phishing attacks, even though some MUAs do not display actual rfc822 addresses. Either way any mail will have to be relayed through an IP address that holds an authentication credential (i.e. its IP address is listed). I think the small number of geeks who set up their laptops to send out mail direct from their hotel rooms can figure out the necessary dynamic dns tweak to make it work. The rest of us will relay their mail through a static server. Phill From owner-ietf-mxcomp Sun Mar 21 20:09:57 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2M49vSi090541; Sun, 21 Mar 2004 20:09: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 i2M49v8Q090540; Sun, 21 Mar 2004 20:09:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (IDENT:root@ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2M49vY2090533 for ; Sun, 21 Mar 2004 20:09:57 -0800 (PST) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-19-105.client.comcast.net [24.6.19.105]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i2M4A0iL006252 for ; Sun, 21 Mar 2004 20:10:00 -0800 (PST) Received: by tethys.bitshift.org (Postfix, from userid 1001) id 25A4C22887; Sun, 21 Mar 2004 20:10:00 -0800 (PST) Date: Sun, 21 Mar 2004 20:10:00 -0800 From: "Mark C. Langston" To: IETF MXCOMP Subject: Re: Choice of SMTP headers Message-ID: <20040322041000.GE67093@bitshift.org> Mail-Followup-To: IETF MXCOMP References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Uptime: 8:02PM up 278 days, 23:11, 8 users, load averages: 0.00, 0.00, 0.00 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, Mar 21, 2004 at 07:59:55PM -0800, Hallam-Baker, Phillip wrote: > > > I think the small number of geeks who set up their laptops to send > out mail direct from their hotel rooms can figure out the necessary > dynamic dns tweak to make it work. The rest of us will relay their > mail through a static server. > Do you have data on the frequency of this behavior? I don't have hard data, but anecdotal data from the organizations for which I've worked over the past 15 years or so would indicate that the volume is somewhat higher than "a few geeks". It's not just hotel rooms, either. It's hotel rooms, coffee houses, client sites, airports, trains, and various other locations, using a variety of connection methods, including POTS, cellular dial-up, cellular data, packet radio, 802.11b/g, and various flavors of tethered broadband. Each has its own ideosyncratic method of handling outbound email, from blocking it, to transparent proxying, to allowing anything through. And it's it largely not geeks doing this (though it was back when notebooks and phones were both enough to give one a hernia). Instead, it's salespeople, professors, marketing staff, executives, students, and pretty much every other type of person you can imagine. The days of the geek being the only person taking advantage of ubiquitous access are over. Have been for a few years now, at least. -- Mark C. Langston Sr. Unix SysAdmin mark@bitshift.org mark@seti.org Systems & Network Admin SETI Institute http://bitshift.org http://www.seti.org From owner-ietf-mxcomp Sun Mar 21 20:24:46 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2M4OkQQ091557; Sun, 21 Mar 2004 20:24: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 i2M4OkoX091556; Sun, 21 Mar 2004 20:24:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (IDENT:root@ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2M4OjLA091548 for ; Sun, 21 Mar 2004 20:24:45 -0800 (PST) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-19-105.client.comcast.net [24.6.19.105]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i2M4OoiL011949 for ; Sun, 21 Mar 2004 20:24:50 -0800 (PST) Received: by tethys.bitshift.org (Postfix, from userid 1001) id 8297E22888; Sun, 21 Mar 2004 20:24:50 -0800 (PST) Date: Sun, 21 Mar 2004 20:24:50 -0800 From: "Mark C. Langston" To: IETF MXCOMP Subject: Re: When spoofing is. Message-ID: <20040322042450.GF67093@bitshift.org> Mail-Followup-To: IETF MXCOMP References: <20040321192414.GA67093@bitshift.org> <73580140.1079873186@[10.12.1.18]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <73580140.1079873186@[10.12.1.18]> User-Agent: Mutt/1.4.1i X-Uptime: 8:02PM up 278 days, 23:11, 8 users, load averages: 0.00, 0.00, 0.00 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, Mar 21, 2004 at 12:46:26PM -0800, Greg Connor wrote: > > Mark and Wayne- > > I think you two agree more than you disagree. May I suggest that you try a > bit harder to state your own positions concisely, rather than concentrating > on DISagreeing with what the other person said? > Understood and agreed. My position: * I'd prefer a solution that focuses on RFC2821 identity enforcement (at least until there's more data in on the relationship between RC2821 and RFC2822 data and the correlation of those relationships with undesireable* uses of email). * I'd prefer this solution accomodate uses of a single identity across multiple providers and layer 1/2 transit types in a relatively robust manner (possibly using a client-side, authenticated dynamic update method where necessary; not as an addition to MUAs at first, but as a standalone daemon). * I'd prefer this solution preserve the ability to non-abusively alter RFC2821 and RFC2822 identities, without forcing certain information into the RFC2822 From: header (unless it's in the form of a comment, rather than a complete From: header substitution). * I'd prefer this solution place as much of the burden on MTA admins, and as little on the end-user as possible. The solution should be transparent to the end-user. * I'd prefer this solution be something layered on top of existing MTAs (at first), rather than rewriting rewrites of existing MTAs, to ease adoption and transition. (*NOTE: I'm trying to eliminate perspective-based language from this, but I find it difficult. Perhaps if we were to focus on one or two well-defined and well-known problems, such as joe-jobs, it'd clarify things further. I'm willing to s/undesireable uses of email/joe-jobs/g , because the need to define a tractable problem here is evident.) -- Mark C. Langston Sr. Unix SysAdmin mark@bitshift.org mark@seti.org Systems & Network Admin SETI Institute http://bitshift.org http://www.seti.org From owner-ietf-mxcomp Sun Mar 21 20:56:14 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2M4uE2A094391; Sun, 21 Mar 2004 20:56: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 i2M4uEbJ094390; Sun, 21 Mar 2004 20:56:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2M4uDD2094384 for ; Sun, 21 Mar 2004 20:56:14 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2M4uHd22178; Sun, 21 Mar 2004 20:56:19 -0800 Date: Sun, 21 Mar 2004 20:56:16 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <134490370.20040321205616@brandenburg.com> To: Greg Connor CC: IETF MXCOMP Subject: Re: Choice of SMTP headers In-Reply-To: <93230703.1079892837@[10\.12\.1\.18]> References: <1657222923.20040321160546@brandenburg.com> <93230703.1079892837@[10.12.1.18]> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Greg, GC> I would like to see the first GC> push aimed at RFC2821 MAIL FROM, Why? What does a validated bounces address tell you and what does it take to validate it reasonably? (Yes, I understand that unauthorized use of bounces addresses are a problem, but the question is whether directly solving that makes sense or whether solving it indirectly makes sense. Of course, the answer hinges on the difficulty of each approach.) GC> but beyond that, HELO checking might have GC> some value too. HELO asserts the identity of the MTA. It is the only place this is asserted. Would it be useful to know that an MTA is authorized to be an MTA? Would it be useful to know this independently of any particular From/Sender/MailFrom address? MCL> data, but anecdotal data from the organizations for which I've worked MCL> over the past 15 years or so would indicate that the volume is somewhat MCL> higher than "a few geeks". Indeed, the growth of hotspots and probably explosion of mobile Internet access suggests that we be very careful in limiting access and usage scenarios. Pretty much every time we take a snapshot of current behavior and assert that it predicts the future, we are wrong. The current problems with site multi-homing are an example. 10 years ago, the CIDR discussions included the challenge of having a site homed through multiple, indpendent upstream providers. Because it was not popular back then, the scenario was utterly dismissed. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Mon Mar 22 02:55:07 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2MAt7Bh087556; Mon, 22 Mar 2004 02:55:07 -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 i2MAt7kr087555; Mon, 22 Mar 2004 02:55:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from argon.connect.org.uk (argon.connectinternetsolutions.com [193.110.243.33]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2MAt6EV087549 for ; Mon, 22 Mar 2004 02:55:06 -0800 (PST) (envelope-from jrk@merseymail.com) Received: from mmail by argon.connect.org.uk with local (connectmail/exim) id 1B5N5C-0001MT-Fj; Mon, 22 Mar 2004 10:55:02 +0000 Subject: Re: Choice of SMTP headers To: "Greg Connor" From: "Jon Kyme" Cc: "IETF MXCOMP" X-Mailer: [ConnectMail 3.13.0] X-connectmail-Originating-IP: 172.25.243.3 Message-Id: Date: Mon, 22 Mar 2004 10:55:02 +0000 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > I have a general idea that there is a lot of broken software out there > that > gives HELO as a short, unqualified, non-existent or otherwise weird name. > I don't have a lot of data to back it up... I have just heard from others > in passing that HELO checking can be good, but currently requires a lot > of > white-listing and exceptions. > > Who knows? Perhaps HELO checking and enforcement is incredibly important. > It could be. I just don't have any data to back that up. > > A quick grep through my logs shows that of about 18% of HELOs have bad syntax and 25% use a name with no DNS (sample 250k HELOs). I believe Hotmail is pretty bad on the second point. From owner-ietf-mxcomp Mon Mar 22 05:56:13 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2MDuDQt099502; Mon, 22 Mar 2004 05:56: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 i2MDuDFo099501; Mon, 22 Mar 2004 05:56:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2MDuD2g099495 for ; Mon, 22 Mar 2004 05:56:13 -0800 (PST) (envelope-from pbaker@verisign.com) Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.11/) with ESMTP id i2MDuBMW001594; Mon, 22 Mar 2004 05:56:11 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 22 Mar 2004 05:56:11 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Mark C. Langston'" , IETF MXCOMP Subject: RE: Choice of SMTP headers Date: Mon, 22 Mar 2004 05:56:10 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > It's not just hotel rooms, either. It's hotel rooms, coffee houses, > client sites, airports, trains, and various other locations, using a > variety of connection methods, including POTS, cellular dial-up, > cellular data, packet radio, 802.11b/g, and various flavors > of tethered > broadband. Each has its own ideosyncratic method of handling outbound > email, from blocking it, to transparent proxying, to allowing anything > through. And it's it largely not geeks doing this (though it was back > when notebooks and phones were both enough to give one a hernia). > Instead, it's salespeople, professors, marketing staff, executives, > students, and pretty much every other type of person you can > imagine. Most users employ an email client that routes outgoing mail through their mail server hub. Direct mail send is not even supported with the most widely used clients (Outlook, Outlook Express) and discouraged on most others. The type of transitory connectivity you describe is precisely the type of situation where routing through a hub becomes the most convenient way to send. Phill From owner-ietf-mxcomp Mon Mar 22 05:57:45 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2MDvjo8099600; Mon, 22 Mar 2004 05:57: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 i2MDvjpK099597; Mon, 22 Mar 2004 05:57:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2MDviwH099585 for ; Mon, 22 Mar 2004 05:57:44 -0800 (PST) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id 425EAE0AB6; Mon, 22 Mar 2004 08:57:44 -0500 (EST) Date: Mon, 22 Mar 2004 08:57:44 -0500 From: John Leslie To: Jon Kyme Cc: IETF MXCOMP Subject: Re: Choice of SMTP headers Message-ID: <20040322135744.GB29788@verdi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Kyme wrote: > > A quick grep through my logs shows that of about 18% of HELOs have > bad syntax and 25% use a name with no DNS (sample 250k HELOs). This is something eMail admins could fix quickly -- if they saw any reason to... We pretty much _need_ HELO for the case of bounce messages received (as opposed to errors generated during SMTP-sending sessions). Otherwise there's nothing the admin of the domain sending the bounce can do to assure us that it's a legitimate bounce. Other uses for checking the HELO will no doubt show up. At this point it's not important to specify them -- only to design for expansion. I don't believe we'll be recommending returning an error to the HELO (without waiting for MAIL From); but recall our purpose is not to design "the" way everyone must do things: it's to enable eMail admins to pass information out-of-band. -- John Leslie From owner-ietf-mxcomp Mon Mar 22 06:31:40 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2MEVdBN002622; Mon, 22 Mar 2004 06:31: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 i2MEVdw1002621; Mon, 22 Mar 2004 06:31:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2MEVdHu002614 for ; Mon, 22 Mar 2004 06:31:39 -0800 (PST) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id 514BCE0ADF; Mon, 22 Mar 2004 09:31:41 -0500 (EST) Date: Mon, 22 Mar 2004 09:31:41 -0500 From: John Leslie To: Dave Crocker Cc: IETF MXCOMP Subject: Re: Choice of SMTP headers Message-ID: <20040322143141.GC29788@verdi> References: <1657222923.20040321160546@brandenburg.com> <93230703.1079892837@[10.12.1.18]> <134490370.20040321205616@brandenburg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <134490370.20040321205616@brandenburg.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dave Crocker wrote: > [Greg Connor wrote:] > >> I would like to see the first push aimed at RFC2821 MAIL FROM, > > Why? What does a validated bounces address tell you and what does it > take to validate it reasonably? This deserves a real answer. First of all, it tells you (the eMail admin receiving) that you can safely pass this email on with assurance that a bounce message generated after the close of the SMTP session is likely to reach someone who can act on it. Otherwise, you'd need to do everything possible _during_ the SMTP session -- since bouncing to an innocent third party (forged by a spammer) is a BAD thing. IMHO, validating a bounces-to address should rest upon a record maintained by the eMail admin for the domain part, stating that this particular SMTP sender (by IP address) is presumed to do appropriate checking of the MAIL-From addresses it sends. Note that "appropriate checking" covers a vast territory. For example, a sending MTA could substitute a role account with an authenticated sender enclosed in parentheses; or it could place the authenticated sender directly following the MAIL-From; or it could (especially for a personal domain) trust whatever the authenticated sender asks it to put there. (Some eMail admins will no doubt want to authorize different SMTP senders for different users -- I hope we will leave expansion room to handle this in the future.) (Other eMail admins will no doubt want to override the bounces-to address, perhaps retaining the original in parentheses -- I hope we will leave expansion room for that, too.) > (Yes, I understand that unauthorized use of bounces addresses are a > problem, but the question is whether directly solving that makes sense > or whether solving it indirectly makes sense. Of course, the answer > hinges on the difficulty of each approach.) IMHO, it's going to be hard enough to convince people to use a "direct" solution. I'd avoid "indirect" solutions unless the "direct" solutions don't actually solve it. >> but beyond that, HELO checking might have some value too. > > HELO asserts the identity of the MTA. It is the only place this is > asserted. Would it be useful to know that an MTA is authorized to be > an MTA? This doesn't deserve a real answer; but I'll hint at one. That it is authorized to "be an MTA" helps us not at all, unless the authorization comes from a source we have reason to trust. > [Mark C. Langston wrote:] > >" ... anecdotal data from the organizations for which I've worked >" over the past 15 years or so would indicate that the volume is >" somewhat higher than "a few geeks". > > Indeed, the growth of hotspots and probably explosion of mobile > Internet access suggests that we be very careful in limiting access > and usage scenarios. Here's where "authorized to be _an_ MTA" could help. If such authorization was from a "trustworthy" source, and included directions on overriding the bounces-to, we could indeed proceed to trust the bounces-to and pass the email on to the next stage. -- John Leslie From owner-ietf-mxcomp Mon Mar 22 09:17:22 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2MHHLj2013548; Mon, 22 Mar 2004 09:17:21 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2MHHLZx013547; Mon, 22 Mar 2004 09:17:21 -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.8) with ESMTP id i2MHHAxF013529 for ; Mon, 22 Mar 2004 09:17:14 -0800 (PST) (envelope-from aland@newgiles.nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 9601F16FDF for ; Mon, 22 Mar 2004 12:20:58 -0500 (EST) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Choice of SMTP headers In-Reply-To: Your message of "Sun, 21 Mar 2004 20:10:00 PST." <20040322041000.GE67093@bitshift.org> Date: Mon, 22 Mar 2004 12:20:58 -0500 Message-Id: <20040322172058.9601F16FDF@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Mark C. Langston" wrote: > It's not just hotel rooms, either. It's hotel rooms, coffee houses, > client sites, airports, trains, and various other locations, using a > variety of connection methods, including POTS, cellular dial-up, > cellular data, packet radio, 802.11b/g, and various flavors of tethered > broadband. Each has its own ideosyncratic method of handling outbound > email, from blocking it, to transparent proxying, to allowing anything > through. And why aren't they using the technologies designed specifically to address the "roaming user" issue? We can't solve marketing/political solutions through technical means. People have political/emotional reasons for their current email behaviour, and the existence of an equivalent technology to implement their intentions is irrelevant. They won't use it until forced to. I'm not saying the "IETF" should force anyone to do anthing, but it should design protocols to allow recipients to discover non-accountable senders, so that those recipients can choose to not accept non-accountable messages. Eventually, roaming users will discover that certain technologies won't get their messages through, and they will switch to technologies which work. Alan DeKok. From owner-ietf-mxcomp Mon Mar 22 10:26:22 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2MIQMO7018843; Mon, 22 Mar 2004 10:26: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 i2MIQMGn018842; Mon, 22 Mar 2004 10:26:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from polis.nbtsc.org (polis.nbtsc.org [206.168.119.2]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2MIQL0N018835 for ; Mon, 22 Mar 2004 10:26:21 -0800 (PST) (envelope-from aredridel@nbtsc.org) Received: from aredridel by polis.nbtsc.org with local (Exim 4.30) id 1B5U80-0004OL-FA for ietf-mxcomp@imc.org; Mon, 22 Mar 2004 11:26:24 -0700 Date: Mon, 22 Mar 2004 11:26:24 -0700 From: Aredridel To: IETF MXCOMP Subject: Re: Choice of identities: compromise? Message-ID: <20040322182624.GA11381@mail.nbtsc.org> References: <405CF096.5060407@solidmatrix.com> <1976055222.20040320204539@brandenburg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1976055222.20040320204539@brandenburg.com> User-Agent: Mutt/1.4.2.1i X-Arbitrary-Number-Of-The-Day: 42 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > YS> Am I sensing a compromise that we should first concentrate on RFC2821 > YS> stuff (HELO and MAIL FROM) with an eye toward possible RFC2822 headers > YS> in the future (past San Diego)? > > I think this is a good division of efforts. Ditto. Ari From owner-ietf-mxcomp Mon Mar 22 10:44:00 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2MIi0OV020021; Mon, 22 Mar 2004 10:44: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 i2MIi0tp020020; Mon, 22 Mar 2004 10:44:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (IDENT:root@ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2MIi0UE020012 for ; Mon, 22 Mar 2004 10:44:00 -0800 (PST) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-19-105.client.comcast.net [24.6.19.105]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i2MIhwiL006576 for ; Mon, 22 Mar 2004 10:44:02 -0800 (PST) Received: by tethys.bitshift.org (Postfix, from userid 1001) id ECA2122887; Mon, 22 Mar 2004 10:43:57 -0800 (PST) Date: Mon, 22 Mar 2004 10:43:57 -0800 From: "Mark C. Langston" To: ietf-mxcomp@imc.org Subject: Re: Choice of SMTP headers Message-ID: <20040322184357.GJ67093@bitshift.org> Mail-Followup-To: ietf-mxcomp@imc.org References: <20040322041000.GE67093@bitshift.org> <20040322172058.9601F16FDF@mail.nitros9.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040322172058.9601F16FDF@mail.nitros9.org> User-Agent: Mutt/1.4.1i X-Uptime: 10:34AM up 279 days, 13:44, 8 users, load averages: 0.07, 0.02, 0.00 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Mar 22, 2004 at 12:20:58PM -0500, Alan DeKok wrote: > > And why aren't they using the technologies designed specifically to > address the "roaming user" issue? > By "they", do you mean the end-users, or the ISPs? my example was meant more to highlight problems introduced by the intermediary transit (the ISP, e.g., via a transparent proxy) than by the end-user or the administrators of the end-user's desired MX (or, more likely, by policies the administrators must obey). > Eventually, roaming users will discover that certain technologies > won't get their messages through, and they will switch to > technologies which work. This sounds as though you believe all the power lies with the end-user. In many instances, the end-user is powerless to effect change in the intermediary ISP (except by discontinuing service -- not always an option) or in the end-user's desired MX (except by discontinuing use of the MX -- not realistic when it's the end-user's employer). I'd prefer everyone move to secure, authenticated mail exchange, but the reality is that it hasn't occurred. Getting organizations -- particularly large ones -- to make widespread client-side changes would be difficult. That's why I'd prefer a recommendation that's transparent to the end-user if at all possible: it stands a greater chance of adoption. -- Mark C. Langston Sr. Unix SysAdmin mark@bitshift.org mark@seti.org Systems & Network Admin SETI Institute http://bitshift.org http://www.seti.org From owner-ietf-mxcomp Mon Mar 22 11:29:53 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2MJTrb3022977; Mon, 22 Mar 2004 11:29: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 i2MJTrXx022976; Mon, 22 Mar 2004 11:29:53 -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.8) with ESMTP id i2MJTkSs022963 for ; Mon, 22 Mar 2004 11:29:47 -0800 (PST) (envelope-from aland@newgiles.nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 87526170DD for ; Mon, 22 Mar 2004 14:33:40 -0500 (EST) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Choice of SMTP headers In-Reply-To: Your message of "Mon, 22 Mar 2004 10:43:57 PST." <20040322184357.GJ67093@bitshift.org> Date: Mon, 22 Mar 2004 14:33:40 -0500 Message-Id: <20040322193340.87526170DD@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Mark C. Langston" wrote: > By "they", do you mean the end-users, or the ISPs? Everybody. > my example was meant more to highlight problems introduced by the > intermediary transit (the ISP, e.g., via a transparent proxy) than > by the end-user or the administrators of the end-user's desired MX > (or, more likely, by policies the administrators must obey). The intermediate policies are chosen to prevent end-users from abusing network resources. e.g. Blocking port 25 outbound is an attempt to stop end-users from sending spam. Both (ab)use, and policy, are hacks to work around lack of a technological solution, or lack of deploymenty of a solution. > This sounds as though you believe all the power lies with the end-user. > In many instances, the end-user is powerless to effect change in the > intermediary ISP If the end users have alternative methods which are accountable, the ISP's policy can be relaxed to permit those methods. > I'd prefer everyone move to secure, authenticated mail exchange, but the > reality is that it hasn't occurred. Getting organizations -- > particularly large ones -- to make widespread client-side changes would > be difficult. They upgrade laptops regularly. So there's already an existing model for deploying software upgrades. Wait 2-3 years, and deployment will have reached the majority of users. Alan DeKok. From owner-ietf-mxcomp Mon Mar 22 11:47:15 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2MJlFkp024163; Mon, 22 Mar 2004 11:47: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 i2MJlFjA024162; Mon, 22 Mar 2004 11:47:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (IDENT:root@ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2MJlEuZ024154 for ; Mon, 22 Mar 2004 11:47:14 -0800 (PST) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-19-105.client.comcast.net [24.6.19.105]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i2MJlGiL019867 for ; Mon, 22 Mar 2004 11:47:16 -0800 (PST) Received: by tethys.bitshift.org (Postfix, from userid 1001) id BA14D22888; Mon, 22 Mar 2004 11:47:16 -0800 (PST) Date: Mon, 22 Mar 2004 11:47:16 -0800 From: "Mark C. Langston" To: ietf-mxcomp@imc.org Subject: Re: Choice of SMTP headers Message-ID: <20040322194716.GL67093@bitshift.org> Mail-Followup-To: ietf-mxcomp@imc.org References: <20040322184357.GJ67093@bitshift.org> <20040322193340.87526170DD@mail.nitros9.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040322193340.87526170DD@mail.nitros9.org> User-Agent: Mutt/1.4.1i X-Uptime: 11:40AM up 279 days, 14:49, 7 users, load averages: 0.00, 0.01, 0.00 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Mar 22, 2004 at 02:33:40PM -0500, Alan DeKok wrote: > > > my example was meant more to highlight problems introduced by the > > intermediary transit (the ISP, e.g., via a transparent proxy) than > > by the end-user or the administrators of the end-user's desired MX > > (or, more likely, by policies the administrators must obey). > > The intermediate policies are chosen to prevent end-users from > abusing network resources. e.g. Blocking port 25 outbound is an > attempt to stop end-users from sending spam. > ...which is fine, and has workarounds today. I'd prefer our recommendation not break those workarounds. > > They upgrade laptops regularly. So there's already an existing > model for deploying software upgrades. Wait 2-3 years, and deployment > will have reached the majority of users. ...and for those people that must wait a year, or two, or three, before email is functional again? When a service that many view as fundamental, such as email, stops functioningi as deployed, trickling out a fix isn't seen as an appropriate response. There are individual organizations in which that trickle-out could take two to three years. For that reason, it'd be better to come up with a recommendation whose impact is largely, or completely, server-side, and transparent to the client and end-users. -- Mark C. Langston Sr. Unix SysAdmin mark@bitshift.org mark@seti.org Systems & Network Admin SETI Institute http://bitshift.org http://www.seti.org From owner-ietf-mxcomp Mon Mar 22 15:07:14 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2MN7Es2039011; Mon, 22 Mar 2004 15:07: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 i2MN7EfF039010; Mon, 22 Mar 2004 15:07:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2MN7DE6039004 for ; Mon, 22 Mar 2004 15:07:13 -0800 (PST) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id D526CE0521; Mon, 22 Mar 2004 18:07:15 -0500 (EST) Date: Mon, 22 Mar 2004 18:07:15 -0500 From: John Leslie To: Ted Hardie Cc: ietf-mxcomp@imc.org Subject: Intermediate MTA setting MAIL-From Message-ID: <20040322230715.GA48854@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: on Jabber this afternoon, Ted Hardie wrote: > > why is the intermediate MTA setting the Mail from to a new > address not forgery or to use a more neutral term "impersonation"? NB: The log is at http://www.xmpp.org/ietf-logs/marid@ietf.xmpp.org/2004-03-22.html To put this in context: Dave: isn't mailfrom RFC 2821? yeah, but what is the actual _use_ of the string: directing bounces. who cares about that? the folks responsible for the original posting. Is there some reason the sending MTA shouldn't SET bounces-to? the SMTP client in a relaying sequence will not have a basis for knowing anything about where bounces should go, except what it has been told by the upstream entity. there's no reason a relaying SMTP sender shouldn't know it's relaying, and set bounces-to to something known good. sorry, no. random mtas in a sequence of mtas must no go around arbitrarily setting bounces addresses. why not? yeah, the "known good" address could get bounce storms from that pretty fast why "bounce storms"? if delivery fails, who needs to know, to take corrective action? certainly not a stray mta in the middle of a transfer sequence. setting to a "known good" address that isn't specific to the message means that address gets all the bounces, which it may not be able to address. A bad hat in the middle could use that to send bounces to a "known good" address, dos'ing that account. Dave's main point is more important though--MTAs should not be arbitrarily resetting these. yes, DOS is possible -- but if the MAIL-From can't be verified, aren't bounces to forged addresses worse? why is the intermediate MTA setting the Mail from to a new address not forgery or to use a more neutral term "impersonation"? (For the record: I did suggest to Ted that Jabber logs shouldn't be considered the "public record". He disagreed. I'll take my chances on Dave Crocker getting mad at me...) It is _really_ unfortunate that RFC821 MAIL-From has that name. It has led to untold confusion over the years. It is more correctly called "Envelope-From", and I believe we've come to agreement here that it really is a Bounces-To address. I'd like to suggest that there's absolutely nothing wrong with bounces that must use the RFC821 Bounces-To address traveling back the same path of relaying MTAs that was followed to reach the process which generates the bounce. (This is not to say there's necessarily a benefit.) Every MTA along that path has had access to the full text; so there's no _new_ privacy issue in relaying the text back. If one of the MTAs along the path turns out to be under the control of a spammer, we're no worse off by returning the bounce through him. (And, of course, there's nothing _now_ preventing him from inserting himself in the bounces path.) So, while, rewriting the Bounces-To may _sound_ like forgery when we call it "Mail From", it really is nothing of the kind. The equivalent in postal mail is forwarding a letter by enclosing it in an envelope on which you put new postage. People habitually put their own return address on the outer envelope, and it's certainly not forgery _or_ impersonation. As for the reasons I think this would _sometimes_ be a good thing to do, I'll save that for another email... -- John Leslie From owner-ietf-mxcomp Mon Mar 22 16:52:50 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2N0qoqi043908; Mon, 22 Mar 2004 16:52: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 i2N0qowd043907; Mon, 22 Mar 2004 16:52:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2N0qnn4043901 for ; Mon, 22 Mar 2004 16:52:49 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2N0qod12938; Mon, 22 Mar 2004 16:52:50 -0800 Date: Mon, 22 Mar 2004 16:52:44 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1002287875.20040322165244@brandenburg.com> To: John Leslie CC: Ted Hardie , ietf-mxcomp@imc.org Subject: Re: Intermediate MTA setting MAIL-From In-Reply-To: <20040322230715.GA48854@verdi> References: <20040322230715.GA48854@verdi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: John, JL> (For the record: I did suggest to Ted that Jabber logs shouldn't be JL> considered the "public record". He disagreed. I'll take my chances on my view is that the jabber session is a public working group meeting. JL> It is _really_ unfortunate that RFC821 MAIL-From has that name. I agree. The last few months of discussion have been unpleasantly enlightening to me, in that regard. JL> It JL> has led to untold confusion over the years. It is more correctly JL> called "Envelope-From", In the postal world, it is called "return address". In fact, that is its real function. The fact that the return address is often the from address is an unfortunate correlation, when trying to discuss messaging semantics. JL> I'd like to suggest that there's absolutely nothing wrong with JL> bounces that must use the RFC821 Bounces-To There is no reference to Bounces-To in RFC821 or RFC2821. Which address are you referring to? JL> Every MTA along that path has had access to the full text; so there's JL> no _new_ privacy issue in relaying the text back. The question is not one of privacy, but of authority to set the value in MailFrom. JL> So, while, rewriting the Bounces-To may _sound_ like forgery when we JL> call it "Mail From", it really is nothing of the kind. That is why we need to be clear about the lines of authority for setting values. As a practical matter, I view MailFrom as being under the authority of the entity referenced in the RFC2822 Sender field. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Mon Mar 22 21:17:50 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2N5Hnc9061275; Mon, 22 Mar 2004 21:17: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 i2N5HnHX061274; Mon, 22 Mar 2004 21:17:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [64.139.47.218]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2N5HlTv061266 for ; Mon, 22 Mar 2004 21:17:49 -0800 (PST) (envelope-from gconnor@nekodojo.org) Received: from [10.12.1.18] (gconnor-home-pv.nekodojo.org [10.12.1.18]) by neko-base.nekodojo.org (Postfix) with ESMTP id BD5441D651 for ; Mon, 22 Mar 2004 21:17:54 -0800 (PST) Date: Mon, 22 Mar 2004 21:18:00 -0800 From: Greg Connor To: ietf-mxcomp@imc.org Subject: Re: Choice of SMTP headers Message-ID: <1491234.1079990280@[10.12.1.18]> In-Reply-To: <20040322194716.GL67093@bitshift.org> References: <20040322194716.GL67093@bitshift.org> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > On Mon, Mar 22, 2004 at 02:33:40PM -0500, Alan DeKok wrote: >> >> They upgrade laptops regularly. So there's already an existing >> model for deploying software upgrades. Wait 2-3 years, and deployment >> will have reached the majority of users. --"Mark C. Langston" wrote: > ...and for those people that must wait a year, or two, or three, before > email is functional again? When a service that many view as > fundamental, such as email, stops functioningi as deployed, trickling > out a fix isn't seen as an appropriate response. > > There are individual organizations in which that trickle-out could take > two to three years. > > For that reason, it'd be better to come up with a recommendation whose > impact is largely, or completely, server-side, and transparent to the > client and end-users. I'm a little confused by the "argumenty" nature of this conversation, and I get the feeling there is an important point that both of you are trying to get across that I'm not getting. I *think* I agree with both of you, if I understand you both correctly. I think that we would all agree that the forgery problem is serious enough that we should start acting immediately if not sooner. However, I think that any RFC will take multiple years to reach significant adoption. If someone's spam problem is bad enough that his email is non-functional now, this working group will not ride to his rescue anytime soon. -- Greg Connor From owner-ietf-mxcomp Tue Mar 23 00:30:23 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2N8UMUK021266; Tue, 23 Mar 2004 00:30: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 i2N8UMOB021265; Tue, 23 Mar 2004 00:30:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from argon.connect.org.uk (argon.connectinternetsolutions.com [193.110.243.33]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2N8UL5j021253 for ; Tue, 23 Mar 2004 00:30:22 -0800 (PST) (envelope-from jrk@merseymail.com) Received: from mmail by argon.connect.org.uk with local (connectmail/exim) id 1B5hIj-0007C6-NI; Tue, 23 Mar 2004 08:30:21 +0000 In-Reply-To: <1002287875.20040322165244@brandenburg.com> Subject: Re: Intermediate MTA setting MAIL-From To: "Dave Crocker" From: "Jon Kyme" Cc: X-Mailer: [ConnectMail 3.13.0] X-connectmail-Originating-IP: 82.69.7.27 Message-Id: Date: Tue, 23 Mar 2004 08:30:21 +0000 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dave, I'm not sure what you mean by > > That is why we need to be clear about the lines of authority for setting > values. As a practical matter, I view MailFrom as being under the > authority of the entity referenced in the RFC2822 Sender field. > > Surely (2822)Sender should only be there in particular circumstances (i.e. not always). From owner-ietf-mxcomp Tue Mar 23 00:52:53 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2N8qrlb029621; Tue, 23 Mar 2004 00:52: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 i2N8qr98029619; Tue, 23 Mar 2004 00:52:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2N8qr6b029612 for ; Tue, 23 Mar 2004 00:52:53 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2N8qed15468; Tue, 23 Mar 2004 00:52:40 -0800 Date: Tue, 23 Mar 2004 00:52:34 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1988357318.20040323005234@brandenburg.com> To: "Jon Kyme" CC: "Dave Crocker" , ietf-mxcomp@imc.org Subject: Re: Intermediate MTA setting MAIL-From In-Reply-To: References: <1002287875.20040322165244@brandenburg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon, Who has authority to set the mailfrom? If more than one entity has the authority, what is the relationship among them? If we validate that the field is authentic, what good is that? What will be better? What will not be changed? d/ JK> Dave, I'm not sure what you mean by >> >> That is why we need to be clear about the lines of authority for setting >> values. As a practical matter, I view MailFrom as being under the >> authority of the entity referenced in the RFC2822 Sender field. >> >> JK> Surely (2822)Sender should only be there in particular circumstances JK> (i.e. not always). d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Tue Mar 23 02:52:11 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NAqBUp059903; Tue, 23 Mar 2004 02:52: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 i2NAqBhW059902; Tue, 23 Mar 2004 02:52:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from argon.connect.org.uk (argon.connectinternetsolutions.com [193.110.243.33]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NAqA3I059896 for ; Tue, 23 Mar 2004 02:52:10 -0800 (PST) (envelope-from jrk@merseymail.com) Received: from mmail by argon.connect.org.uk with local (connectmail/exim) id 1B5jVz-0003FU-3L; Tue, 23 Mar 2004 10:52:11 +0000 In-Reply-To: <1988357318.20040323005234@brandenburg.com> Subject: Re: Intermediate MTA setting MAIL-From To: "Dave Crocker" From: "Jon Kyme" Cc: ietf-mxcomp@imc.org X-Mailer: [ConnectMail 3.13.0] X-connectmail-Originating-IP: 172.25.243.3 Message-Id: Date: Tue, 23 Mar 2004 10:52:11 +0000 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Who has authority to set the mailfrom? If more than one entity has the > authority, what is the relationship among them? > > If we validate that the field is authentic, what good is that? What will > be better? What will not be changed? You're right, of course, these are interesting points. In other fields we often see a name "owner" exercising the right to control the use of their name in public. In our area the idea of a "Domain name owner" is fairly well established. It's known that various agents assert names in (2821)MAIL FROM (and HELO) even though they have no connection with the name owner. Often this is done with bad intentions. Sometimes this is done with the best intentions. It's not currently easy to determine what the wishes of the name owner are. Something involving MARID should make it easy for any agent to determine this. This is in scope (I think). Once we have this information, it can be made available to local policy enforcement elements. What *use* is made of it will be subject to local policy, but we can imagine any number of possible *uses*. This is not strictly in scope (I don't believe). From owner-ietf-mxcomp Tue Mar 23 05:50:39 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NDodsi074137; Tue, 23 Mar 2004 05:50: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 i2NDodaH074136; Tue, 23 Mar 2004 05:50:39 -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.8) with SMTP id i2NDocIl074129 for ; Tue, 23 Mar 2004 05:50:38 -0800 (PST) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v5.7.450.9b13) for ietf-mxcomp@imc.org; Tue, 23 Mar 2004 08:52:46 -0500 Received: from ([68.154.110.135]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v5.7.450.9b13) with SMTP id 207568094; Tue, 23 Mar 2004 08:52:44 -0500 Message-ID: <003401c410de$0e440760$6401a8c0@hdev1> From: "Hector Santos" To: "Dave Crocker" Cc: References: <1002287875.20040322165244@brandenburg.com> <1988357318.20040323005234@brandenburg.com> Subject: Re: Intermediate MTA setting MAIL-From Date: Tue, 23 Mar 2004 08:52:09 -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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Does it make sense to view this as a technical behavioral issue, rather than philosophical first? Maybe it is worth while if we examine and measure how systems behave currently in regards to HELO, MAIL FROM, including RCPT, as well as the mail content (headers). This will give us a good premise to work with and some current practice issues to discuss the ideals. It will also allow us to measure how the effect of change on these systems. Example: We ask how "human logic" will examine the MAIL FROM. Well, many of those examinations can be assisted by knowing other factors such as RCPT or even the mail content. For our particular system, it will not make any decision on HELO/MAIL FROM until RCPT is known. This logic is based on a RFC 2821 recommendation. I am not saying that all systems should be operate this way. But we do it because the correctness of MAIL FROM is helped by knowing some level of intent of the sender. I am pointing out that a system might benefit by naturally behaving as you might think a might human today when some unknown person knocks on the door and rings your phone: Ring ring....Caller Id is shown on phone Receiver does not recognize the caller id, answered it. Receiver: Hello? Caller: Is Tom There? Receiver: Sorry, wrong number. Caller: Ok, sorry, bye. Of course, there are other realistic scenarios (a public house) where the receiver may or may not know if Tom exist. On a related note: This is basically one of the points I tried to make in my LMAP Validation analysis; how results change when the examination includes knowledge about RCPT. It is based on a traditional BCP operation for SMTP: - anonymous access can only send final destination or hosted domains transactions - Trust is required for routing/relay. I poised some questions to John Klensin (incidentally, what does he have to say about all this?) in an attempt to get a feel about the routed trust behavior from his point of view. Here is some of his answers. This is not a knock, but just to illustrate we have some real philosophical conflicts to be resolved. Response from John to Hector's "Simple Questions about Multi-Hop Routing:" HS> In general, SMTP says that for final destination mail, anonymous access is allowed (authentication is not required) HS> and for relaying, authentication or some trusted relationship *SHOULD* be established. John: Says where? HS> In general, that trust is gained with: HS> HS> - Sender IP is part of Receiver network ip domain John: Maybe. This is considered a weak test, not much better than simply using a receiver (target)-supplied MX chain, which covers most of the cases in which relaying occurs these days. HS> - allow relay IP tables John: Not covered by any standard HS> - POP3 before SMTP John: Not a mechanism applicable to relays -- and one that causes other problems. HS> - ESMTP AUTH John: yes HS> In a multi-hop situation, where there is a route between two HS> MTAs, I have always presumed a trust was established with HS> these non-MUA transactions. In other words: HS> HS> MUA -----> MTA1 ----> MTA2 ---> MTA3 (Final Destination) HS> HS> MUA is required to authenticate with MTA1 in order to relay HS> mail. Right? John: nope [Hector's comment today: This threw me for a spin. I don't think we can solve anything if we can't establish a trust system with routes. Maybe he meant it wasn't a requirement, but that's one of the issues we need to get cleared, because LMAP will be dependent on this trusted route premise, otherwise it simply will never work (can't be trusted).] HS> MTA2 does not require authenticate with MTA3 because it is a HS> final destination transaction. Right? HS> HS> But what about the transaction between MTA1 and MTA2? HS> HS> Can I safely assume that there is a TRUST established here? John: Nope, not in the general, or most other, cases. [Hector comment today: Again, this threw me for a spin. When I see this type of thinking, it just makes you wonder how can anything be done to correct the anonymous access problem.] HS> Of course, I am not considering the situation where there is a HS> "broken" open relay or proxy, but under legitimate operations, HS> can I safely assume that all transactions between two non-MUA HS> routers are trusted? John: Trust is in the mind of the beholder. But, generally, no. Hector's comment today: Again, this threw me for a spin. I think I understand what he is basically saying, but I firmly believe we have some fundamental mail transport design and operational concepts that needs to be resolved. Before anyone can even begin to programmatically add logic to software to examine the protocol level envelope to determine what they mean, we first need to know how the topology of the mail transport system is suppose to work. In my view, if the above two basic principles of BCP SMTP operations can not be agreed upon as a standard requirement for the new era of trusted operations, I honestly don't see how anything can be accomplished or solved with reliability. We need some fundamental ground rules, baselines and/or SMTP principles established and I think the best way to do that is to study how the current systems behavior. I can begin this by saying that "today," most systems see a MTA receiver who allows anonymous access routes as a Open Relay and will be an instant candidate for blacklisting. If this is a problem for some people here helping to mold the outcome, then we got some major issues to work out. Anyway, my intent in the questions to John as it relates to LMAP is that I can in no way see LMAP work if trust can not be established at the point of message submission. This is a fundamental principle that needs to be confirmed by everyone. At the final destination, LMAP presumes that the MAIL was submitted with trust and if applicable, it was routed with trust. If that "trust chain" is broken, then the final destination transaction is invalid. So how can this be programmatically validated? I don't see how can it can validated without seeing the mail headers. The mail headers will provide some level of validation based on the # of hops. Again, LMAP can only work if the "trust chain" is consistent. I have many thoughts on this, but it always boils down to the ultimate question of how much do we want to change SMTP to address this. After all my research and work, and see what's out there, I can only conclude that ultimately, to ideally address this entire issue, we will need to expand the envelope to provide more information (i,e, ESMTP extension to split the DATA command to HEAD + BODY). If we are concern about the Microsoft and Yahoo's pushing the issue of requiring systems to accept mail before any trust logic can be applied, then maybe ESMTP needs to begin preparing for the inevitable. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com ----- Original Message ----- From: "Dave Crocker" To: "Jon Kyme" Cc: "Dave Crocker" ; Sent: Tuesday, March 23, 2004 3:52 AM Subject: Re: Intermediate MTA setting MAIL-From > > Jon, > > Who has authority to set the mailfrom? If more than one entity has the > authority, what is the relationship among them? > > If we validate that the field is authentic, what good is that? What will > be better? What will not be changed? > > d/ > > > JK> Dave, I'm not sure what you mean by > >> > >> That is why we need to be clear about the lines of authority for setting > >> values. As a practical matter, I view MailFrom as being under the > >> authority of the entity referenced in the RFC2822 Sender field. > >> > >> > > JK> Surely (2822)Sender should only be there in particular circumstances > JK> (i.e. not always). > > > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA > > From owner-ietf-mxcomp Tue Mar 23 06:55:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NEtXBU080193; Tue, 23 Mar 2004 06:55: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 i2NEtX4Y080192; Tue, 23 Mar 2004 06:55: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.8) with ESMTP id i2NEtTJg080183 for ; Tue, 23 Mar 2004 06:55:30 -0800 (PST) (envelope-from aland@newgiles.nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id A50B0170BB for ; Tue, 23 Mar 2004 09:59:22 -0500 (EST) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Intermediate MTA setting MAIL-From In-Reply-To: Your message of "Tue, 23 Mar 2004 00:52:34 PST." <1988357318.20040323005234@brandenburg.com> Date: Tue, 23 Mar 2004 09:59:22 -0500 Message-Id: <20040323145922.A50B0170BB@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dave Crocker wrote: > Who has authority to set the mailfrom? The administrative domain which "originates" a message. I'd say then that an end-user "submits" mail to that domain for delivery to a destination. > If more than one entity has the authority, what is the relationship > among them? Only one entity: the administrative domain which will accept bounces. Note that mailing lists can be viewed as an end-user using SMTP to deliver a message, which is then submitted to the list exploder. The administrative domain for the list then accepts responsibility for the message, the bounces, and thus sets MAIL FROM. > If we validate that the field is authentic, what good is that? What will > be better? What will not be changed? We will know that someone has accepted responsibility for that message, and that a bounce path exists. To be pedantic, any LMAP implementation should also check the MX records for the bounce path. If here are no MX records, then the bounce cannot be delivered, and he message should not be accepted. What will be better is that the restrictions of RFC 2821 will be better enforced. An MTA should either accept responsibility for delivering the message, or responsibility for bouncing it. If it can't bounce the message, it has no failure path if it later has an error (spam or not). To put it another way, RFC 2821 requires MTA's to deliver or bounce the message. However, it provides insufficient methods for an MTA to determine if it is possible to bounce the message. Additional verification can then be viewed as fixing design flaws in the original proposal: There is a valid use-case of SMTP in which an MTA must contradict the requirements of SMTP, and fail to deliver or bounce a message, after it has accepted responsibility for it. Alan DeKok. From owner-ietf-mxcomp Tue Mar 23 07:23:22 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NFNMgT082431; Tue, 23 Mar 2004 07:23: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 i2NFNM8c082430; Tue, 23 Mar 2004 07:23:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NFNL2D082423 for ; Tue, 23 Mar 2004 07:23:22 -0800 (PST) (envelope-from matthew@elvey.com) X-Sasl-enc: vy/Lr3x5IEz1c8VOSQWaPg 1080055025 Received: from elvey.com (adsl-63-195-86-147.dsl.snfc21.pacbell.net [63.195.86.147]) by mail.messagingengine.com (Postfix) with ESMTP id 39C1D82D20D; Tue, 23 Mar 2004 10:17:04 -0500 (EST) Message-ID: <406054EC.2040301@elvey.com> Date: Tue, 23 Mar 2004 07:17:00 -0800 From: Matthew Elvey User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-mxcomp@imc.org Subject: Re: when spoofing isn't References: <700EEF5641B7E247AC1C9B82C05D125DA7E8@srv1.pan-am.ca> In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125DA7E8@srv1.pan-am.ca> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 3/19/2004 10:37 AM, Gordon Fecyk sent forth electrons to convey: >From: "PHB" Hallam-Baker, Phillip > > >>Mark wrote: >> >> >>>I agree completely. I'm firmly on the side of "let's not >>>break things." >>> >>> >>I don't think that there is much value in envelope from[2] alone. It has >>to be matched to either an accreditation or to one of the >>other headers _that_the_user_will_see[1] >> >> I agree. I would like to hear from draft writers (none of whom addressed this issue in their drafts but probably spent a bunch of time thinking about it) whether they put this off to deal with later/in a different spec, or whether they felt it was undoable. > >There are a whole mess of content filtering issues arising from going beyond >the RFC 2821 envelope previously stated. > > I believe we must tackle them. Previously stated on this list, or where? Did anyone make a list that appeared to be pretty comprehensive? If all we aim to achieve by this work is to eliminate bounces due to email forged to come from us, then I regret my efforts to move LMAP et. al. forward. We must do more. >Who was over from AOL that commented they could possibly be banned from >filtering on content by certain governments? That, costs of running said >accreditations and an unwillingless to pay for said accreditation, mailing >lists that use different envelopes than headers as Dave pointed out, are all >liabilities caused by going beyond the RFC 2821 envelope. > > I don't give a shit about hearsay that unnamed gov'ts are allegedly considering shooting themselves in the foot. I remember hearing a rumor that the US Congress was going to pass a strong anti-spam bill. >I have to agree with Dave that matching RFC2821 envelopes to RFC2822 headers >is better off in the hands of the user, as in the final recipient of a >message. > Yes, but: >I would not want pan-am.ca as a domain doing this, but I'd show my >users how to do this. > > I think you _would_ be happy with a sieve script on pan-am.ca that you wrote doing this! I have a sieve script on fastmail.fm that does roughly what I want it to do. I can't make it refuse spam instead of accept and then bounce it, so I wrote what will soon be (-00 is out, already). It doesn't support SPF yet, but it will soon, and it does support SpamAssassin, and all the things that implies - RHS lists, reputation services, etc. >[1] I won't say it, it's too easy. > >[2] Be specific. Do you mean the RFC 2821 envelope MAIL FROM: ? > > It's clear to me that he does. *** In the messages below (from smtp-verify), Alan and Meng defend LMAP. My view: John's cost-benefit analysis is correct. He's saying that if all LMAP does is prevent a small subset of forgeries, specificially the bounces that those forgeries currently cause, then it's not worth it. And he's right! **BUT** LMAP can accomplish more than that, AND we need to talk more about how, and get it in the specifications! [PHB's outline looks good to me.] First of all, we shouldn't pretend that reputation services (blacklists and whitelists, free and otherwise) won't be part of the solution, or that scoring systems (like SpamAssassin) won't be part of the solution. They must be. With this in mind, LMAP can accomplish a lot. We should be talking about this now, figuring out if/how we are tightening the noose tight enough to strangle all the spammers. IP Blacklists already do a very good job with IPs that send nothing but spam. IP whitelists haven't really caught on much, but they can do a good job too, to help tighten the noose a bit further. Blacklists have done only a fair job with "grey" IPs that send spam and ham. Fair isn't good enough. 1) LMAP can take a big chunk of the mail from these grey IPs and classify it as ham. This chunk would be the P2P mail where the header From: is the same as the envelope FROM and is LMAP authorized, and the domain is not in a RHSBL (right hand side blacklist) that lists domains with LMAP records that spam, and is in RHSWL that says how long its been registered and sending mail (something SpamCop/Senderbase do), and it's not new. 2) LMAP can take a big chunk of the mail from these grey IPs and classify it as spam. This would be the stuff that's specifically unauthorized by LMAP. 3)For most users, the remaining chunk will go into a suspect/grey mail folder that senders will not want their email going into. They will come under increasing pressure to get with the program. The fact that 1) is leaving much less ham in the grey mail folder will mean that spam score threshold can be much more agressive! This will improve filter accuracy dramatically. Let's enumerate the categories of email that are still left in the grey area, and discuss how to move as much of it as possible into the very likely spam or very likely ham buckets. On 2/27/2004 11:14 PM, Meng Weng Wong sent forth electrons to convey: >On Sat, Feb 28, 2004 at 02:24:37AM -0000, John Levine wrote: >| >| I would argue that the biggest weakness of all the LMAP systems is >| that the domain they test, the one in the envelope bounce address, >| isn't one that means anything to recipients. If I were a bad guy, I'd >| register some throwaway domains, or I'd forge some badly managed >| third-world domains with no LMAP data, use them in the bounce address >| to pass LMAP checks, and forge like crazy in the From: and Sender: >| lines that people see. > >That's fine by me as long as I stop getting the bounce messages. > What an idiotic thing to say! On 2/28/2004 7:29 AM, Alan DeKok sent forth electrons to convey: >John Levine wrote: > > >>If I were a bad guy, I'd register some throwaway domains, or I'd >>forge some badly managed third-world domains with no LMAP data, use >>them in the bounce address to pass LMAP checks, and forge like crazy >>in the From: and Sender: lines that people see. >> > There are many ways of getting around the problem of forged LMAP >entries. > > > >>The first problem is the biggest, whether preventing envelope forgery >>will in practice deter spammers. If not, the whole LMAP exercise is >>pointless. >> >> > > > There is no magic bullet. > > But I don't see people doing cost/benefit analysis. > > I do. > Can we please agree that there is no one perfect magic bullet, and >stop wasting our time denigrating solutions because they're *not* the >magic bullet? > > I think you misread John's comments completely. Looked like constructive criticism to me. > Alan DeKok. > > --Matthew Elvey From owner-ietf-mxcomp Tue Mar 23 08:08:13 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NG8DQO085930; Tue, 23 Mar 2004 08:08: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 i2NG8DlS085929; Tue, 23 Mar 2004 08:08:13 -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.8) with ESMTP id i2NG8APG085920 for ; Tue, 23 Mar 2004 08:08:10 -0800 (PST) (envelope-from aland@newgiles.nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 0791F17106 for ; Tue, 23 Mar 2004 11:12:03 -0500 (EST) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Choice of SMTP headers In-Reply-To: Your message of "Mon, 22 Mar 2004 21:18:00 PST." <1491234.1079990280@[10.12.1.18]> Date: Tue, 23 Mar 2004 11:12:02 -0500 Message-Id: <20040323161204.0791F17106@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Greg Connor wrote: > I'm a little confused by the "argumenty" nature of this conversation, and I > get the feeling there is an important point that both of you are trying to > get across that I'm not getting. Much conversation involves *not* stating assumptions. When people have different assumptions, miscommunication ensues. > I *think* I agree with both of you, if I understand you both correctly. I > think that we would all agree that the forgery problem is serious enough > that we should start acting immediately if not sooner. However, I think > that any RFC will take multiple years to reach significant adoption. Yes. So we can start now. > If someone's spam problem is bad enough that his email is > non-functional now, this working group will not ride to his rescue > anytime soon. My email system has been close to non-functional for 5 years, due to the volume of spam. No one believed me, and no one believed that it would happen to them. Millions of delivered spams a day. That's the future we're fighting against. If anyone disagrees, they can ask me to point my MX to them... Alan DeKok. From owner-ietf-mxcomp Tue Mar 23 10:25:54 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NIPscW096938; Tue, 23 Mar 2004 10:25:54 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2NIPs7a096937; Tue, 23 Mar 2004 10:25:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mauve.mrochek.com ([209.55.107.55]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NIPpaH096931 for ; Tue, 23 Mar 2004 10:25:52 -0800 (PST) (envelope-from ned.freed@mrochek.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01L827ENSCOW0027NR@mauve.mrochek.com> for ietf-mxcomp@imc.org; Tue, 23 Mar 2004 10:25:54 -0800 (PST) Date: Tue, 23 Mar 2004 10:02:08 -0800 (PST) From: ned.freed@mrochek.com Subject: Re: Intermediate MTA setting MAIL-From In-reply-to: "Your message dated Tue, 23 Mar 2004 00:52:34 -0800" <1988357318.20040323005234@brandenburg.com> To: Dave Crocker Cc: Jon Kyme , Dave Crocker , ietf-mxcomp@imc.org Message-id: <01L82AEYL1TO0027NR@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <1002287875.20040322165244@brandenburg.com> <1988357318.20040323005234@brandenburg.com> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: (At long least we've reached a matter of operational realities, rather than discussion of what the various fields mean.) > Who has authority to set the mailfrom? The simple theory is that the original submitter sets the field. It may subsequently be changed by list processors. > If more than one entity has the > authority, what is the relationship among them? See above. > If we validate that the field is authentic, what good is that? The benefits are huge. In brief, if I, an email user, look at my inbox, I find three sorts of messages in it that I don't want to see in there: (1) Pure spam sent to me directly. A variety of filtering faciliteis can be brought to bear to reduce this to manageable levels. (2) Pure virii sent to me directly. These also can be blocked. (3) Joe-jobs sent using my address that end up bouncing to me in a variety of formats due to my address appearing in the origina message's MAIL FROM field. Due to the large variety of formats used and the varying amount of information returned these are extraordinarily difficult to block without also blocking legitimate nondelivery notifications. A widely deployed authorization system that checks MAIL FROM addresses stops (3) in its tracks. It does this by preventing joe-jobbers from sending mail using my address in the MAIL FROM field to other people. It is important to note that my checking of the use of my own domain is mostly irrelevant; what matters is that everyone else does it. (Actually, having a few large ISPs do it would be of significant benefit.) > What will be better? The trash that's hardest to block is reduced. > What will not be changed? Someone can still forge mail purporting to be from me in the message header. To the extent that spammers use stolen addresses in their mail, this measure will provide some reduction for a short period in the amount of spam that is sent. However, spammers will adapt and start using addresses in MAIL FROM fields that are not protected. But doing this has the side effect of eliminating (3). And remember, spammers don't really care about (3) - its just collateral damage their activities bring about. Another factor to consider is the possibility this will lead to attacks on the DNS. While this is always a possibility, I don't think it is a likely one. It will always be much much easier to simply find and use an unprotected address in the MAIL FROM than it will be to attack the DNS just to be able to use a particular address. Ned From owner-ietf-mxcomp Tue Mar 23 10:35:38 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NIZb0j097989; Tue, 23 Mar 2004 10:35: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 i2NIZbHV097988; Tue, 23 Mar 2004 10:35:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NIZbEI097982 for ; Tue, 23 Mar 2004 10:35:37 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2NIZfd02653 for ; Tue, 23 Mar 2004 10:35:41 -0800 Date: Tue, 23 Mar 2004 10:35:34 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <63181045.20040323103534@brandenburg.com> To: ietf-mxcomp@imc.org Subject: definition of joe job and phishing MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Folks, I recently did some research on the term Joe-Job and discovered some ambiguity, or rather, a broader meaning than folks often assume: Joe Jobbing is the unauthorized use of someone else's email address. It has two major purposes. One is to redirect an expected mass of error messages. The other is to gain access to a recipient by tricking them into believing the message is from the unauthorized address. Phishing derives from this second function, and seeks to further exploit the deception, in order to gain private information from the recipient. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Tue Mar 23 10:50:28 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NIoSHo098907; Tue, 23 Mar 2004 10:50: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 i2NIoSd6098906; Tue, 23 Mar 2004 10:50:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (IDENT:root@ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NIoR3w098899 for ; Tue, 23 Mar 2004 10:50:27 -0800 (PST) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-19-105.client.comcast.net [24.6.19.105]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i2NIoUiL008862 for ; Tue, 23 Mar 2004 10:50:30 -0800 (PST) Received: by tethys.bitshift.org (Postfix, from userid 1001) id 075D02288D; Tue, 23 Mar 2004 10:50:30 -0800 (PST) Date: Tue, 23 Mar 2004 10:50:30 -0800 From: "Mark C. Langston" To: ietf-mxcomp@imc.org Subject: Re: Intermediate MTA setting MAIL-From Message-ID: <20040323185029.GF96036@bitshift.org> References: <1002287875.20040322165244@brandenburg.com> <1988357318.20040323005234@brandenburg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1988357318.20040323005234@brandenburg.com> User-Agent: Mutt/1.4.1i X-Uptime: 10:24AM up 280 days, 13:34, 8 users, load averages: 0.00, 0.02, 0.00 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Mar 23, 2004 at 12:52:34AM -0800, Dave Crocker wrote: > > Who has authority to set the mailfrom? The original sending entity, plus any MX handling the mail. Basically, whichever entity is currently handling the mail has the authority to change RFC2821 ENVELOPE-FROM. I can imagine this might stike some people as odd, but if we're assuming that the originating entity is always forced to go through an authorized MX to send mail, I see no reason why that MX can't be granted authority over ENVELOPE-FROM. Similarly, the receiving MX shouldn't be prohibited from altering ENVELOPE-FROM during processing (though this is more likely to cause breakage than the other two authorities making changes). > If more than one entity has the authority, what is the relationship > among them? > See above. > If we validate that the field is authentic, what good is that? > Well, depends on what you mean by "authentic". If "authentic" means, "is a valid address capable of receiving mail", then there's not much value in it, except to ensure bounces go somewhere. It'll still allow joe-jobs. If by "authentic" you mean "somehow verified as authoritative for receiving bounces for some identity [I'm unclear as to whether this identity would be derived from HELO/EHLO, RFC2822 identities, or some combination of these]", the value increases somewhat (though whether it'll stop practices like joe-jobbing depends on what identity is used to authenticate, and the constraints of the authentication process). > What will be better? > I think additional checks would be beneficial, but I see no reason to exclude a check on ENVELOPE-FROM. > What will not be changed? MTAs will remain misconfigured and insecure, and joe-jobs, or the next iteration in the evolution of such practices, will still exist. -- Mark C. Langston Sr. Unix SysAdmin mark@bitshift.org mark@seti.org Systems & Network Admin SETI Institute http://bitshift.org http://www.seti.org From owner-ietf-mxcomp Tue Mar 23 10:53:04 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NIr3qv099057; Tue, 23 Mar 2004 10:53: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 i2NIr3Nh099055; Tue, 23 Mar 2004 10:53:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (IDENT:root@ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NIr3H9099047 for ; Tue, 23 Mar 2004 10:53:03 -0800 (PST) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-19-105.client.comcast.net [24.6.19.105]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i2NIr5iL009195 for ; Tue, 23 Mar 2004 10:53:05 -0800 (PST) Received: by tethys.bitshift.org (Postfix, from userid 1001) id 3309022887; Tue, 23 Mar 2004 10:53:05 -0800 (PST) Date: Tue, 23 Mar 2004 10:53:05 -0800 From: "Mark C. Langston" To: ietf-mxcomp@imc.org Subject: Re: definition of joe job and phishing Message-ID: <20040323185305.GG96036@bitshift.org> References: <63181045.20040323103534@brandenburg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <63181045.20040323103534@brandenburg.com> User-Agent: Mutt/1.4.1i X-Uptime: 10:24AM up 280 days, 13:34, 8 users, load averages: 0.00, 0.02, 0.00 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Mar 23, 2004 at 10:35:34AM -0800, Dave Crocker wrote: > > Folks, > > I recently did some research on the term Joe-Job and discovered some > ambiguity, or rather, a broader meaning than folks often assume: > > Joe Jobbing is the unauthorized use of someone else's email address. It > has two major purposes. One is to redirect an expected mass of error > messages. For clarity's sake, when I use the term "joe-job", the above is what I mean. Maybe we should call it something different, like "bounce-bombing", since "joe-job" is vague. -- Mark C. Langston Sr. Unix SysAdmin mark@bitshift.org mark@seti.org Systems & Network Admin SETI Institute http://bitshift.org http://www.seti.org From owner-ietf-mxcomp Tue Mar 23 11:16:15 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NJGFS9000925; Tue, 23 Mar 2004 11:16: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 i2NJGF1q000924; Tue, 23 Mar 2004 11:16:15 -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.8) with ESMTP id i2NJGCQ7000915 for ; Tue, 23 Mar 2004 11:16:15 -0800 (PST) (envelope-from aland@newgiles.nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 9532B17105 for ; Tue, 23 Mar 2004 14:20:04 -0500 (EST) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Choice of SMTP headers In-Reply-To: Your message of "Mon, 22 Mar 2004 11:47:16 PST." <20040322194716.GL67093@bitshift.org> Date: Tue, 23 Mar 2004 14:20:04 -0500 Message-Id: <20040323192005.9532B17105@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Mark C. Langston" wrote: > > They upgrade laptops regularly. So there's already an existing > > model for deploying software upgrades. Wait 2-3 years, and deployment > > will have reached the majority of users. > > ...and for those people that must wait a year, or two, or three, before > email is functional again? They will have incentive to upgrade sooner. > When a service that many view as fundamental, such as email, stops > functioningi as deployed, trickling out a fix isn't seen as an > appropriate response. It's already stopped functioning properly. And you're confusing the design of a fix with it's deployment (or "trickling out"). We shouldn't throw away designs simply because some people will deploy it slowly. That's their problem. My original comment on the 2-3 year deployment was that it was an UPPER bound on deployment time. After 2-3 years, a large number of people will have upgraded software, through the simple expedient of upgrading their systems. People who want it deployed sooner have incentive to do so, and can choose to do so. > For that reason, it'd be better to come up with a recommendation whose > impact is largely, or completely, server-side, and transparent to the > client and end-users. Such as...? This is the problem I've seen on ASRG for over a year now. "Solution X doesn't satisfy criteria A, so we should wait for a solution which does satisfy it". But no one proposes such a system. After a year of this, that argument starts to look like a polite way of refusing to deploy anything, ever. Alan DeKok. From owner-ietf-mxcomp Tue Mar 23 12:14:32 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NKEWLM005790; Tue, 23 Mar 2004 12:14: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 i2NKEWfg005789; Tue, 23 Mar 2004 12:14:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (IDENT:root@ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NKEVbX005780 for ; Tue, 23 Mar 2004 12:14:32 -0800 (PST) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-19-105.client.comcast.net [24.6.19.105]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i2NKEYiL026444 for ; Tue, 23 Mar 2004 12:14:34 -0800 (PST) Received: by tethys.bitshift.org (Postfix, from userid 1001) id 3810722887; Tue, 23 Mar 2004 12:14:34 -0800 (PST) Date: Tue, 23 Mar 2004 12:14:34 -0800 From: "Mark C. Langston" To: ietf-mxcomp@imc.org Subject: Re: Choice of SMTP headers Message-ID: <20040323201434.GH96036@bitshift.org> References: <20040322194716.GL67093@bitshift.org> <20040323192005.9532B17105@mail.nitros9.org> Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20040323192005.9532B17105@mail.nitros9.org> User-Agent: Mutt/1.4.1i X-Uptime: 11:59AM up 280 days, 15:09, 7 users, load averages: 0.05, 0.03, 0.01 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Mar 23, 2004 at 02:20:04PM -0500, Alan DeKok wrote: > > "Mark C. Langston" wrote: > > > For that reason, it'd be better to come up with a recommendation whose > > impact is largely, or completely, server-side, and transparent to the > > client and end-users. > > Such as...? > (NOTE: This is NOT meant as advocacy for any particular proposal. I'm merely offering an example to answer the question.) SPF is an example of a server-side solution, with minimum impact on the client and transparent to the end-user. I say "minimum impact" rather than "zero impact" because in certain cases, it would be necessary to change the client authentication method, and for certain classes of use (e.g., cellphones), that's not a trivial prospect, particularly if the deployed base doesn't currently support that authentication method (or, if the cellphone example has been played out -- and given that I bring it up all the time, it probably has -- non-MUA software that originates email without going though the localhost MTA (perhaps due to a lack of localhost MTA, or perhaps just due to poor coding)). "Entities sitting at desks, in front of desktop computers, using an MUA to originate email, which will be sent to the sender's MX prior to being sent by that MX to the recipient's MX" is the archetype that seems to underly some of the assumptions thæat we're making. I'm trying to avoid that archetype, because it leads to the assumption that end-user and MUA impact is easy to deal with. > This is the problem I've seen on ASRG for over a year now. > "Solution X doesn't satisfy criteria A, so we should wait for a > solution which does satisfy it". But no one proposes such a system. > > After a year of this, that argument starts to look like a polite way > of refusing to deploy anything, ever. Perhaps when we reach the point in the agenda where we're discussing potential solutions, we should start by coming to agreement on the criteria the solution should meet, and stick to working within those constraints. -- Mark C. Langston Sr. Unix SysAdmin mark@bitshift.org mark@seti.org Systems & Network Admin SETI Institute http://bitshift.org http://www.seti.org From owner-ietf-mxcomp Tue Mar 23 12:30:50 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NKUo59006913; Tue, 23 Mar 2004 12:30: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 i2NKUoVZ006912; Tue, 23 Mar 2004 12:30:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from scale01.mcom.com (h-64-236-139-249.aoltw.net [64.236.139.249]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NKUodW006896 for ; Tue, 23 Mar 2004 12:30:50 -0800 (PST) (envelope-from aoki@aol.net) Received: from aol.net ([10.178.176.106]) by scale01.nscp.aoltw.net (Netscape Messaging Server 6.1 (built Oct 3 2002)) with ESMTPA id <0HV100EF2QA4KP@scale01.nscp.aoltw.net> for ietf-mxcomp@imc.org; Tue, 23 Mar 2004 12:30:06 -0800 (PST) Date: Tue, 23 Mar 2004 12:30:42 -0800 From: Edwin Aoki Subject: Re: Choice of SMTP headers In-reply-to: <20040323192005.9532B17105@mail.nitros9.org> To: Alan DeKok Cc: ietf-mxcomp@imc.org Message-id: <40609E72.10604@aol.net> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031007 References: <20040323192005.9532B17105@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I believe there are a couple of assumptions that are hidden here and in similar conversations that have taken place on this and many other similar lists over the past n years. 1) The fundamental principle behind mail is that it's a communication between (at least) two entities. Solutions may have costs, barriers, and benefits that affect senders, receivers, or both. And the costs and benefits may accrue to different people. 2) Most end-users rely on their ISPs (or ASPs), Enterprise IT managers, or educational institutions to manage their mail servers, DNS, and other infrastructure pieces (I'll refer to these folks collectively as infrastructure providers). Their choice of mail client may be driven from above or may be a personal choice. Users and infrastructure providers have different motivations for implementing these solutions, and, as above, differences in cost, conveninence, and desire. I don't bring these up in support of or against any specific proposal, but to remind us of some core principles behind what we're building. Like the International Email Address (IEA) and International Domain Name (IDN) efforts, there's a lot of work involved in moving us from here to there, and the various groups have very different reasons for wanting or not wanting to get there. I think this has been proposed before, but for each proposal (including these kind of discussions), I think it would be very helpful for folks to articulate which constituent does the work and which problem it is supposed to solve. Thanks, -Edwin Alan DeKok wrote: >"Mark C. Langston" wrote: > > >>> They upgrade laptops regularly. So there's already an existing >>>model for deploying software upgrades. Wait 2-3 years, and deployment >>>will have reached the majority of users. >>> >>> >>...and for those people that must wait a year, or two, or three, before >>email is functional again? >> >> > > They will have incentive to upgrade sooner. > > > >> When a service that many view as fundamental, such as email, stops >>functioningi as deployed, trickling out a fix isn't seen as an >>appropriate response. >> >> > > It's already stopped functioning properly. And you're confusing the >design of a fix with it's deployment (or "trickling out"). We >shouldn't throw away designs simply because some people will deploy it >slowly. That's their problem. > > My original comment on the 2-3 year deployment was that it was an >UPPER bound on deployment time. After 2-3 years, a large number of >people will have upgraded software, through the simple expedient of >upgrading their systems. People who want it deployed sooner have >incentive to do so, and can choose to do so. > > > >>For that reason, it'd be better to come up with a recommendation whose >>impact is largely, or completely, server-side, and transparent to the >>client and end-users. >> >> > > Such as...? > > This is the problem I've seen on ASRG for over a year now. >"Solution X doesn't satisfy criteria A, so we should wait for a >solution which does satisfy it". But no one proposes such a system. > > After a year of this, that argument starts to look like a polite way >of refusing to deploy anything, ever. > > Alan DeKok. > > > From owner-ietf-mxcomp Tue Mar 23 12:42:01 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NKg1Ec008311; Tue, 23 Mar 2004 12:42:01 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2NKg1ct008310; Tue, 23 Mar 2004 12:42:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from argon.connect.org.uk (argon.connectinternetsolutions.com [193.110.243.33]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NKg0b3008303 for ; Tue, 23 Mar 2004 12:42:01 -0800 (PST) (envelope-from jrk@merseymail.com) Received: from mmail by argon.connect.org.uk with local (connectmail/exim) id 1B5siq-00054O-Qu; Tue, 23 Mar 2004 20:42:04 +0000 Subject: Re: Intermediate MTA setting MAIL-From To: From: "Jon Kyme" Cc: X-Mailer: [ConnectMail 3.13.0] X-connectmail-Originating-IP: 82.69.7.27 Message-Id: Date: Tue, 23 Mar 2004 20:42:04 +0000 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ned.freed> (At long least we've reached a matter of operational realities, rather > than > discussion of what the various fields mean.) > Consensus on what the data we exchange "mean" is the only ground for (inter) operational reality. But of course, "meaning" isn't an inherent property of the data, often, it emerges in *use*. A piece of data can have multiple (even contradictory) meanings in different contexts, for different actors. This realisation can lead us to a valuable engineering insight - we can specify an enabling mechanism which supports the different uses (meanings) that may be made by various entities but needn't necessarily (although we may) endorse, or deprecate, any particular use. From owner-ietf-mxcomp Tue Mar 23 13:25:35 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NLPZon011753; Tue, 23 Mar 2004 13:25: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 i2NLPZd1011752; Tue, 23 Mar 2004 13:25:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mauve.mrochek.com ([209.55.107.55]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NLPYv1011744 for ; Tue, 23 Mar 2004 13:25:34 -0800 (PST) (envelope-from ned.freed@mrochek.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01L827ENSCOW0027NR@mauve.mrochek.com> for ietf-mxcomp@imc.org; Tue, 23 Mar 2004 13:25:37 -0800 (PST) Date: Tue, 23 Mar 2004 13:20:13 -0800 (PST) From: ned.freed@mrochek.com Subject: Re: Intermediate MTA setting MAIL-From In-reply-to: "Your message dated Tue, 23 Mar 2004 20:42:04 +0000" To: Jon Kyme Cc: ned.freed@mrochek.com, ietf-mxcomp@imc.org Message-id: <01L82GOSG4NG0027NR@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > ned.freed> (At long least we've reached a matter of operational realities, > rather than discussion of what the various fields mean.) > Consensus on what the data we exchange "mean" is the only ground for > (inter) operational reality. But of course, "meaning" isn't an inherent > property of the data, often, it emerges in *use*. A piece of data can have > multiple (even contradictory) meanings in different contexts, for different > actors. This realisation can lead us to a valuable engineering insight - we > can specify an enabling mechanism which supports the different uses > (meanings) that may be made by various entities but needn't necessarily > (although we may) endorse, or deprecate, any particular use. Whatever. The point I was trying to make is that there's a big difference between discussing the intended use of various fields and discussing their actual use and the implications of that usage. IMO in the present situation we need to be focusing on the latter. I find it clearer to think of the former in terms of "meaning" and the latter in terms of "operational reality". But if you prefer to consider both of them to be "meaning", albeit of different sorts, the more power to you. But none of this brings us any closer to understanding why we should or should not perform authorization checks based on the MAIL FROM address. So this will be my last message on this subtopic. Ned From owner-ietf-mxcomp Tue Mar 23 13:57:35 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NLvZl1015365; Tue, 23 Mar 2004 13:57: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 i2NLvZ5q015364; Tue, 23 Mar 2004 13:57:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NLvY6K015357 for ; Tue, 23 Mar 2004 13:57:34 -0800 (PST) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id 17279E0629; Tue, 23 Mar 2004 16:57:39 -0500 (EST) Date: Tue, 23 Mar 2004 16:57:39 -0500 From: John Leslie To: Hector Santos Cc: ietf-mxcomp@imc.org, John C Klensin Subject: Re: Intermediate MTA setting MAIL-From Message-ID: <20040323215739.GJ48854@verdi> References: <1002287875.20040322165244@brandenburg.com> <1988357318.20040323005234@brandenburg.com> <003401c410de$0e440760$6401a8c0@hdev1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003401c410de$0e440760$6401a8c0@hdev1> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hector Santos wrote: > > This is basically one of the points I tried to make in my LMAP > Validation analysis; how results change when the examination includes > knowledge about RCPT. It is based on a traditional BCP operation > for SMTP: > > - anonymous access can only send final destination or hosted domains > transactions > - Trust is required for routing/relay. This is one way of stating a nearly universal practice of MTAs which serve as both receivers and senders: A local authenticated user may send anywhere, and mail from anywhere may be delivered locally. Anything elses is likely to be rejected with "We do not relay". (IMHO, this is a good practice, for those that practice it. Whether it can be expanded beyond those that currently practice it is unclear.) > I poised some questions to John Klensin... > Here is some of his answers. This is not a knock, but just to > illustrate we have some real philosophical conflicts to be resolved. I'm not sure "philosophical conflicts" can be resolved; but I agree they should be understood -- otherwise our documents are likely to mean different things to different people. > HS> In general, SMTP says that for final destination mail, anonymous > access is allowed (authentication is not required) and for > relaying, authentication or some trusted relationship *SHOULD* > be established. > > John: Says where? This certainly isn't in John Klensin's RFC2821 or RFC2822. If Hector wants a capital-SHOULD, it needs to find a home in some RFC. > HS> In general, that trust is gained with: > - Sender IP is part of Receiver network ip domain > > John: Maybe. This is considered a weak test, not much better than > simply using a receiver (target)-supplied MX chain, which > covers most of the cases in which relaying occurs these days. There may be a misunderstanding. Hector is describing the locally authenticated user, just assuming that the routing of that IP is sufficient authentication. This is often true. However, Hector did not _exclude_ the case where routing is _not_ sufficient authentication, which appears to be John's point. > HS> - allow relay IP tables > > John: Not covered by any standard These are less common, and John is correct. > HS> - POP3 before SMTP > > John: Not a mechanism applicable to relays -- and one that causes > other problems. Indeed, POP-before-SMTP is useless for accepting email forced to go through an intermediary MTA. Nonetheless, it _is_ widely used. There may even be a way to expand upon this idea so as to be useful when MTA relays are involved: but most of us aren't expecting that. > HS> - ESMTP AUTH > > John: yes A clearly better solution than POP-before-SMTP. > HS> In a multi-hop situation, where there is a route between two > MTAs, I have always presumed a trust was established with > these non-MUA transactions. In other words: > > MUA -----> MTA1 ----> MTA2 ---> MTA3 (Final Destination) > > MUA is required to authenticate with MTA1 in order to relay > mail. Right? > > John: nope John is correct. There is no requirement, and seldom any test beyond considering MUA to be "local" based on IP address. > [Hector's comment today: This threw me for a spin. I don't think > we can solve anything if we can't establish a trust system with > routes. Maybe he meant it wasn't a requirement, but that's one of > the issues we need to get cleared, because LMAP will be dependent > on this trusted route premise, otherwise it simply will never work > (can't be trusted).] To the extent MTA1 "trusts" MUA based on IP address alone, it can be defined to be sufficient trust. We should, IMHO, feel free to _recommend_ SMTP-AUTH here, but we certainly cannot _require_ it. > HS> MTA2 does not require authenticate with MTA3 because it is a > final destination transaction. Right? > But what about the transaction between MTA1 and MTA2? > Can I safely assume that there is a TRUST established here? > > John: Nope, not in the general, or most other, cases. Certainly not in the "general" case. But in several classes of cases, there is an implied trust; and in others, MTA1 is delivering to the recipient's agent based upon MX records. IMHO, whether to call that "trust" is not a helpful question. > [Hector comment today: Again, this threw me for a spin. When I > see this type of thinking, it just makes you wonder how can anything > be done to correct the anonymous access problem.] In we are discussing how: " " those maintaining domains and networks [may] " specify that individual hosts or nodes are authorized to act as " MTAs for messages sent from those domains or networks. The semantics of such specifications are not yet established. I quite agree with Dave Crocker that discussing them would be helpful. > HS> Of course, I am not considering the situation where there is a > "broken" open relay or proxy, but under legitimate operations, > can I safely assume that all transactions between two non-MUA > routers are trusted? > > John: Trust is in the mind of the beholder. But, generally, no. This doesn't _necessarily_ mean that mxcomp can do nothing to clarify "trust"... > Hector's comment today: > > Again, this threw me for a spin. I think I understand what he is > basically saying, but I firmly believe we have some fundamental > mail transport design and operational concepts that needs to be > resolved. I doubt we can do much of that here. > Before anyone can even begin to programmatically add logic to > software to examine the protocol level envelope to determine what > they mean, we first need to know how the topology of the mail > transport system is suppose to work. The topology is simple: any two machines at the edge can establish a SMTP session. Period. > We need some fundamental ground rules, baselines and/or SMTP > principles established and I think the best way to do that is to > study how the current systems behavior. Many of us have done that already. > Anyway, my intent in the questions to John as it relates to LMAP is > that I can in no way see LMAP work if trust can not be established > at the point of message submission. This is a fundamental principle > that needs to be confirmed by everyone. There is no such thing as a "fundamental principle that needs to be confirmed by everyone". If you can't wrap your mind around that, you don't belong here. Here, we believe in rough consensus and running code. > At the final destination, LMAP presumes that the MAIL was submitted > with trust and if applicable, it was routed with trust. If that > "trust chain" is broken, then the final destination transaction is > invalid. You're free to configure your MTA on that belief. Others are free not to. > So how can this be programmatically validated? I don't see how can > it can validated without seeing the mail headers. The mail headers > will provide some level of validation based on the # of hops. Again, > LMAP can only work if the "trust chain" is consistent. We're not here to validate "LMAP" (whatever that may mean). Live with it. Read the charter! > I have many thoughts on this, but it always boils down to the > ultimate question of how much do we want to change SMTP to address > this. Very little. > After all my research and work, and see what's out there, I can only > conclude that ultimately, to ideally address this entire issue, we > will need to expand the envelope to provide more information (i,e, > ESMTP extension to split the DATA command to HEAD + BODY). That's an interesting idea. I almost wish it weren't off-topic. -- John Leslie From owner-ietf-mxcomp Tue Mar 23 16:20:55 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2O0KtTK027972; Tue, 23 Mar 2004 16:20: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 i2O0KtEx027971; Tue, 23 Mar 2004 16:20:55 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2O0Ktfm027964 for ; Tue, 23 Mar 2004 16:20:55 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2O0KPd00791; Tue, 23 Mar 2004 16:20:25 -0800 Date: Tue, 23 Mar 2004 16:20:12 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <647038785.20040323162012@brandenburg.com> To: "Mark C. Langston" CC: ietf-mxcomp@imc.org Subject: Re: Intermediate MTA setting MAIL-From In-Reply-To: <20040323185029.GF96036@bitshift.org> References: <1002287875.20040322165244@brandenburg.com> <1988357318.20040323005234@brandenburg.com> <20040323185029.GF96036@bitshift.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Mark, >> Who has authority to set the mailfrom? MCL> The original sending entity, plus any MX handling the mail. Huh? Why should an MX (ie, a relay) have authority to redirect bounces? MCL> Basically, MCL> whichever entity is currently handling the mail has the authority to MCL> change RFC2821 ENVELOPE-FROM. Oh boy, do I disagree! That's like saying that anyone in the postal system has the authority to change the return address on the envelope from me. MCL> I can imagine this might stike some MCL> people as odd, but if we're assuming that the originating entity is MCL> always forced to go through an authorized MX to send mail, I see no MCL> reason why that MX can't be granted authority over ENVELOPE-FROM. MX is outbound, not inbound. There is no such thing as a "receiving MX". >> If we validate that the field is authentic, what good is that? MCL> Well, depends on what you mean by "authentic". If "authentic" means, MCL> "is a valid address capable of receiving mail", ... MCL> If by "authentic" you mean "somehow verified as authoritative for All of the proposals under discussion provide a formal authentication mechanism. That's what I mean by authentic. >> What will be better? MCL> I think additional checks would be beneficial, but I see no reason to MCL> exclude a check on ENVELOPE-FROM. Folks need to start paying attention to aggregate costs. They also need to pay attention to steps that do not provide significant improvements. A security mechanism with wasteful requirements winds up being less secure. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Tue Mar 23 16:44:51 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2O0ipO7029336; Tue, 23 Mar 2004 16:44:51 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2O0ipRG029335; Tue, 23 Mar 2004 16:44:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (IDENT:root@ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2O0ioXU029329 for ; Tue, 23 Mar 2004 16:44:51 -0800 (PST) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-19-105.client.comcast.net [24.6.19.105]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i2O0itiL027377 for ; Tue, 23 Mar 2004 16:44:55 -0800 (PST) Received: by tethys.bitshift.org (Postfix, from userid 1001) id E03F122887; Tue, 23 Mar 2004 16:44:54 -0800 (PST) Date: Tue, 23 Mar 2004 16:44:54 -0800 From: "Mark C. Langston" To: ietf-mxcomp@imc.org Subject: Re: Intermediate MTA setting MAIL-From Message-ID: <20040324004454.GM96036@bitshift.org> References: <1002287875.20040322165244@brandenburg.com> <1988357318.20040323005234@brandenburg.com> <20040323185029.GF96036@bitshift.org> <647038785.20040323162012@brandenburg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <647038785.20040323162012@brandenburg.com> User-Agent: Mutt/1.4.1i X-Uptime: 4:23PM up 280 days, 19:33, 7 users, load averages: 0.01, 0.03, 0.00 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Mar 23, 2004 at 04:20:12PM -0800, Dave Crocker wrote: > Mark, > > > >> Who has authority to set the mailfrom? > MCL> The original sending entity, plus any MX handling the mail. > > Huh? Why should an MX (ie, a relay) have authority to redirect bounces? > Well, I agree that bounces should go to some source capable of reacting to them, and that one of those bounce recipients should be the originating entity, but must that source be the original sender only? [snip and apologies. I had laid out a scenario in which the MX would rewrite the ENVELOPE-FROM, and act on bounces for the originating entity, but I realized in writing it that what I was describing was a system in which mail is forwarded on behalf of the originating entity. Thus, there's no need to rewrite ENVELOPE-FROM...it should always be the originating entity. Thank you, Dave, for helping me think that through.] However, would allowing the MX to _correct_ a fraudulent ENVELOPE-FROM submitted by the originating entity be a scenario in which someone other than the originating entity has the authority to set ENVELOPE-FROM? If one assumes that the MX has authenticated the originating entity prior to allowing mail transfer, the MX would be in a position to determine whether the ENVELOPE-FROM sent by the originating entity was valid. > MX is outbound, not inbound. There is no such thing as a "receiving > MX". > Sorry. That should have been MTA. I was thinking in DNS record terms. It's moot now, however, given the above. > > > All of the proposals under discussion provide a formal authentication > mechanism. That's what I mean by authentic. > The broadest use of the term, then. I was reading too much into it. > > >> What will be better? > MCL> I think additional checks would be beneficial, but I see no reason to > MCL> exclude a check on ENVELOPE-FROM. > > Folks need to start paying attention to aggregate costs. They also need > to pay attention to steps that do not provide significant improvements. > A security mechanism with wasteful requirements winds up being less > secure. I didn't mean to suggest that an acceptable solution would be one in which only ENVELOPE-FROM checks were performed. The most benefit may be derived from multiple checks that support one another, none sufficient in themselves, except in very small problem spaces. -- Mark C. Langston Sr. Unix SysAdmin mark@bitshift.org mark@seti.org Systems & Network Admin SETI Institute http://bitshift.org http://www.seti.org From owner-ietf-mxcomp Tue Mar 23 17:15:20 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2O1FKpM030920; Tue, 23 Mar 2004 17:15: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 i2O1FKjU030919; Tue, 23 Mar 2004 17:15:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2O1FJrZ030912 for ; Tue, 23 Mar 2004 17:15:19 -0800 (PST) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id C3357E065C; Tue, 23 Mar 2004 20:15:22 -0500 (EST) Date: Tue, 23 Mar 2004 20:15:22 -0500 From: John Leslie To: Edwin Aoki Cc: ietf-mxcomp@imc.org Subject: Re: Choice of SMTP headers Message-ID: <20040324011522.GK48854@verdi> References: <20040323192005.9532B17105@mail.nitros9.org> <40609E72.10604@aol.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40609E72.10604@aol.net> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Edwin Aoki wrote: > > I believe there are a couple of assumptions that are hidden here and > in similar conversations that have taken place on this and many other > similar lists over the past n years. We're all guilty of "assumptions". Plural... > 1) The fundamental principle behind mail is that it's a communication > between (at least) two entities. Solutions may have costs, barriers, > and benefits that affect senders, receivers, or both. And the costs > and benefits may accrue to different people. In IETF, we often attempt to deny costs; and we often consider it out of scope to try to balance costs and benefits... > 2) Most end-users rely on their ISPs (or ASPs), Enterprise IT > managers, or educational institutions to manage their mail servers, > DNS, and other infrastructure pieces (I'll refer to these folks > collectively as infrastructure providers). Their choice of mail > client may be driven from above or may be a personal choice. > Users and infrastructure providers have different motivations for > implementing these solutions, and, as above, differences in cost, > conveninence, and desire. Yes, assumptions, plural... > I don't bring these up in support of or against any specific > proposal, but to remind us of some core principles behind what > we're building. Like the International Email Address (IEA) and > International Domain Name (IDN) efforts, there's a lot of work > involved in moving us from here to there, and the various groups > have very different reasons for wanting or not wanting to get there. > > I think this has been proposed before, but for each proposal > (including these kind of discussions), I think it would be very > helpful for folks to articulate which constituent does the work > and which problem it is supposed to solve. We tend to think, not in terms of constitutents, rather in terms of functions. Thus we talk of MTAs, not of the entities which operate them. Here in mxcomp, we're charged to: " " develop a DNS-based mechanism for storing and distributing " information... " to specify that individual hosts or nodes are authorized to act " as MTAs for messages sent from those domains or networks. You should feel free to ask occasionally for such articulation -- if nothing else we need to discuss whether a proposal is scalable -- but you may not always get an answer... -- John Leslie From owner-ietf-mxcomp Tue Mar 23 20:00:20 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2O40KeX041678; Tue, 23 Mar 2004 20:00: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 i2O40Ki6041677; Tue, 23 Mar 2004 20:00:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2O40Jgr041670 for ; Tue, 23 Mar 2004 20:00:19 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2O40Qd17554 for ; Tue, 23 Mar 2004 20:00:26 -0800 Date: Tue, 23 Mar 2004 20:00:17 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1992131755.20040323200017@brandenburg.com> To: ietf-mxcomp@imc.org Subject: Re: Choice of SMTP headers In-Reply-To: <20040322193340.87526170DD@mail.nitros9.org> References: Your message of "Mon, 22 Mar 2004 10:43:57 PST." <20040322184357.GJ67093@bitshift.org> <20040322193340.87526170DD@mail.nitros9.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Folks, >> I'd prefer everyone move to secure, authenticated mail exchange, but the >> reality is that it hasn't occurred. Getting organizations -- >> particularly large ones -- to make widespread client-side changes would >> be difficult. AD> They upgrade laptops regularly. So there's already an existing AD> model for deploying software upgrades. Wait 2-3 years, and deployment AD> will have reached the majority of users. I would like to encourage folks to be more cautious about these sorts of assumptions. There is a long track-record with making changes to the running Internet. The track record is that new services -- as opposed to changes to an existing service -- take 3-5 years to gain widespread deployment, and that is only if they require no changes to the infrastructure. Try to change an existing service or institute infrastructure modifications, and the timeframe is 5-10 (and the upper bound really is longer than that, with the lower bound rarely being that short.) We can formulate all sorts of scenarios about incentives and coercion, but the track record is the track record. We project something different from that record only at our peril. That said, there are things that can be done to make adoption easier or harder: Flexible implementation choice aids adoption. Easy and scalable deployment and administration aid adoption. Incremental benefit aids adoption. Broad utility aids adoption. MCL> For that reason, it'd be better to come up with a recommendation whose MCL> impact is largely, or completely, server-side, and transparent to the MCL> client and end-users. The best place for a new bit of capability will depend on quite a few user, organizational and technical factors. However, here is something to think about: A change that is architecturally designed to go into servers MUST go into servers. A change that is architecturally designed to go into end user systems MAY go into end user systems or MAY be put into servers (to work on behalf of the users.) Think about the difference in flexibility. MCL> SPF is an example of a server-side solution, with minimum impact on the MCL> client and transparent to the end-user. Let's see. It requires end-users to pre-register the MTAs that they will use. Otherwise, it breaks third-party MUA usage, and quite a bit of mailing list usage, and otherwise-legitimate mobility scenarios. I do not think I'd call that "transparent to the end-user". MCL> Perhaps when we reach the point in the agenda where we're discussing MCL> potential solutions, we should start by coming to agreement on the MCL> criteria the solution should meet, and stick to working within those MCL> constraints. Yes! EA> I think this has been proposed before, but for each proposal (including EA> these kind of discussions), I think it would be very helpful for folks EA> to articulate which constituent does the work and which problem it is EA> supposed to solve. This is such a stellar suggestion, I'm inclined to recommend that the wg chairs formally require it. JL> In IETF, we often attempt to deny costs; I'd say we are more inclined to ignore them than to even spend the effort to deny them... JL> and we often consider it JL> out of scope to try to balance costs and benefits... Of course! It isn't any fun to do the balancing assessment. JL> We tend to think, not in terms of constitutents, rather in terms JL> of functions. Thus we talk of MTAs, not of the entities which JL> operate them. This is another one of those massively important bits of insight that we need to keep in mind. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Tue Mar 23 20:08:35 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2O48ZqG042177; Tue, 23 Mar 2004 20:08: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 i2O48Z2m042176; Tue, 23 Mar 2004 20:08:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2O48YZ4042167 for ; Tue, 23 Mar 2004 20:08:34 -0800 (PST) (envelope-from matthew@elvey.com) X-Sasl-enc: RUfCSKz3s26fFuuy5nQqWw 1080101161 Received: from elvey.com (ns.nextbus.com [64.164.28.194]) by mail.messagingengine.com (Postfix) with ESMTP id 3A99E84301F; Tue, 23 Mar 2004 23:06:00 -0500 (EST) Message-ID: <40610927.1060409@elvey.com> Date: Tue, 23 Mar 2004 20:05:59 -0800 From: Matthew Elvey User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-mxcomp@imc.org Subject: greeting card sites not a problem for LMAP X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: My experience is that about 2/3 of the greeting card email I get is UCE. For the sites sending other third, I expect their email will get through more in an LMAP world than it does now. They should be happy if LMAP takes off! These sites will want to continue to have their email received. They will typically switch to sending mail that is from (in the header and envelope) themselves, and publish an appropriate LMAP record for their domain. The subject and body can say who allegedly caused it to be sent. They will or will not have a reputation for being a source of UBE. They can take advantage of reputation services as they wish; some will be free. If they use measures such as rate limiting, or verifying alleged senders, it's likely they will be able to maintain a good reputation, and their mail will reach its intended recipients. Another option would be for them to send the email to the sender, and have them forward it to the intended recipient. Besides, as PHB stated, they probably have to stop doing what they have been doing anyway to comply with CAN-SPAM. From owner-ietf-mxcomp Tue Mar 23 21:29:32 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2O5TW9A047054; Tue, 23 Mar 2004 21:29: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 i2O5TWWR047053; Tue, 23 Mar 2004 21:29:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2O5TV4h047046 for ; Tue, 23 Mar 2004 21:29:31 -0800 (PST) (envelope-from matthew@elvey.com) X-Sasl-enc: +5mD/d5nSWwPz39caMbnbg 1080105792 Received: from elvey.com (ns.nextbus.com [64.164.28.194]) by mail.messagingengine.com (Postfix) with ESMTP id 68C98844672; Wed, 24 Mar 2004 00:23:12 -0500 (EST) Message-ID: <40611B3C.5010305@elvey.com> Date: Tue, 23 Mar 2004 21:23:08 -0800 From: Matthew Elvey User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MXCOMP Subject: LMAP scenarios. Correction. Paging DeKok, Levine. How to authenticate header From: !? X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Alan DeKok/John Levine: are you still working on draft-irtf-asrg-lmap-discussion? went unanswered, I believe. ********* I'd like to take back something I said earlier, now that I think about it. LMAP can do a lot more than stopping joes, even without matching header From:, if it's used in conjunction with reputation services, such as RHSW&BLs. Matching stuff in the header is a nice-to-have, but I think LMAP can reduce spam (which I see as the goal, not just reducing forgeries) without it. (See mailing list/paypal comments far below.) ********** I've already read (and contributed to) the LMAP-discussion draft, and it attempts to address all major scenarios of usage, but I thought it would be useful to try another tack as well. I have many valid email addresses. As a thought experiment, let me see how well each of them (munged) would work in a pervasive LMAP world - I bet I cover most common usage scenarios. 1)me@elvey.dom - Different users at elvey.dom use different SMTP servers. The LMAP record will list the mail servers of the perhaps dozen ISPs of users of the domain. All will be peachy. As the mail admin, I'll have to explain to the users/ walk them through setting up SMTP AUTH to their ISP, so that they can send mail when traveling. Or I could set up an smtp.elvey.com mail server. 2)me@aya.yale.dom - my alumni account. Either Yale sets up a mail server for alums to use, that LMAP authorizes, or mail sent from @aya.yale.dom will at least be greylisted, if not blacklisted as a frequent envelope FROM of spam. (LMAP contenders allow aya.yale.dom to have different LMAP records from @yale.dom, right? SPF does, at least, IIRC.) Perhaps my mail client/ISP could work together so I could send mail with envelope FROM = something valid for my usual SMTP server, LMAP-wise, and header From: with my address. This would involve changing MUAs - a non-starter. Also, this would perhaps be suspicious to, say SpamAssassin. I never send email from this address, so I probably won't be willing to pay for smarthost access to the aya.yale server, but they probably are willing to provide it free (they already pay a third party to manage the current receive and-relay only system). 3)me@pacbell.dom - PacBell. my ISP, may do something stupid like publish an LMAP record allowing mail only from their mail servers, but not allow people not currently on their network to use those mail servers, even with AUTH. Actually, I think they used to, but no longer do this. If I actually still cared about this addres, and they did something stupid like this, it would be a big problem, but they'd get a ton of support calls and fix it PDQ. If not, I'd set up a server on my DSL line to relay email for me, but non-geeks would be screwed. (I could sell access to the server I'd set up to other pacbell users though!) Peachy. 4)me@myemployer.dom - I'll set up my MUA to send through their server when I want to send as @them, or have them add my usual SMTP server to the server list authorized for their domain in LMAP. Peachy. 5)me@theclientofmyemployer.dom - I'll set up my MUA to send through their server when I want to send as @them. Peachy. 6)me@myEmailServiceProvider.dom - I'll use their SMTP server (mail.messagingengine.com) (it's what I use by default currently, with SSL, to send all my mail). 7)me@ieee.dom - same as 2). 8)me@hotmail.dom - I'll use the web or http interface to send email from this account, as Microsoft is likely to publish restrictive LMAP records. I'll have to stop sending mail from me@hotmail.dom using mail.messagingengine.com, but that's fine; I rarely send mail from this account anyway. M$ will get some add'l revenue from the ads I view (unless I block 'em) while sending mail using the web interface. 9)me@yahoo.dom - I'll use the web interface to send email from this account, as Yahoo is likely to publish restrictive LMAP records. Also, I happen to have free POP/SMTP access (because I have SBC/Yahoo DSL) so I can use that too. Peachy. 10)me@anOutblaze domain. same as 9) but no free SMTP access. So, in all 10 cases, I can probably still send email. Also, in all the cases, I think envelope FROM will = header From:, at least initially. When I post to a list, it'll be doing VERP/SRS. In each case, my email will be more easily categorizable as not spam, and hence more likely to reach the recipients. Hotmail and Yahoo probably won't do a great job terminating spammers using their services, so their reputations will reflect that, but a @yahoo.com or @hotmail.com will be much less of a spamsign/more respected than it is now. I'll probably use Hotmail and Yahoo a little less than I do now. Only in case #1 so I have to pre-register my MTA to get it into the domain's LMAP entries. There are no mobility issues. I receive lots of different kinds of email, including mail to mailing lists and the above addresses. Let's see see how each of them would work in a pervasive LMAP world. (Postponed to next email.) I run a mailing list at freelists.org. I think that the mail software they use may no longer be maintained. But it already sends out mail with @freelists.org in the envelope FROM, so it should be fine. header From: is the original sender, so envelope FROM will != header From: Perhaps domains like verisign.com, paypal.com or bigbank.dom would have LMAP entries specifically saying it was NOT ok for them to be in the header From: where envelope FROM to != header From:. Typical domains would not have LMAP entries like this because it would typically prevent their users from having their mailing list postings accepted by recipients, effectively meaning they couldn't post to mailing lists with their work domains, which their employers would probably view as a good thing anyway. Would there be a point to freelists.org, ietf.org, imc.org and the like having LMAP entries saying that it WAS ok for envelope FROM to != header From: where they were in the envelope? I think not, but perhaps. Perhaps RHSWLs would appear that listed domains that hosted legit mailing lists. PS I believe it's clear that by header From:, I mean (RFC2822)From: and envelope FROM = (RFC2821)MAIL FROM, so I use the simpler and shorter, but still clear terms. How to authenticate header From: - Would this work?: If envelope FROM != header From:, but envelope FROM checks out in LMAP, and reputation services, we *can* probably trust the topmost Received header (prior to any added by the receiving MTA itself), which will in most such cases have an IP that matches the domain in the header From:! Right? Cool!? From owner-ietf-mxcomp Wed Mar 24 01:04:43 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2O94hxL015707; Wed, 24 Mar 2004 01:04: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 i2O94hjT015706; Wed, 24 Mar 2004 01:04:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from argon.connect.org.uk (argon.connectinternetsolutions.com [193.110.243.33]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2O94fte015692 for ; Wed, 24 Mar 2004 01:04:42 -0800 (PST) (envelope-from jrk@merseymail.com) Received: from mmail by argon.connect.org.uk with local (connectmail/exim) id 1B64JV-0002vs-K5; Wed, 24 Mar 2004 09:04:41 +0000 Subject: Re: Intermediate MTA setting MAIL-From To: From: "Jon Kyme" Cc: X-Mailer: [ConnectMail 3.13.0] X-connectmail-Originating-IP: 172.25.243.3 Message-Id: Date: Wed, 24 Mar 2004 09:04:41 +0000 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > >But none of this brings us any closer to understanding why we should or >should >not perform authorization checks based on the MAIL FROM address. So this >will >be my last message on this subtopic. > That's unfortunate. "why *we* should or should not perform such checks" is a moderately interesting question (at best), but liable to get rather noisy. Whether "we" should work to produce a (global) mechanism which enables such checks (and others, in support of local, or publisher's, policies) is a rather more interesting question. It may be somewhat less "religious". But, "whatever", if you want a nice and tidy 'ruling' on the first question, good luck to you. From owner-ietf-mxcomp Wed Mar 24 06:54:08 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OEs8D0060545; Wed, 24 Mar 2004 06: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 i2OEs8xf060544; Wed, 24 Mar 2004 06:54:08 -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.8) with ESMTP id i2OEs3jk060527 for ; Wed, 24 Mar 2004 06:54:03 -0800 (PST) (envelope-from aland@newgiles.nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id EC5A1170BB for ; Wed, 24 Mar 2004 09:57:58 -0500 (EST) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Choice of SMTP headers In-Reply-To: Your message of "Tue, 23 Mar 2004 20:00:17 PST." <1992131755.20040323200017@brandenburg.com> Date: Wed, 24 Mar 2004 09:57:58 -0500 Message-Id: <20040324145758.EC5A1170BB@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dave Crocker wrote: > There is a long track-record with making changes to the running > Internet. The track record is that new services -- as opposed to changes > to an existing service -- take 3-5 years to gain widespread deployment, Which new services have achieved widespread deployment in less than 3-5 years? What properties do they have? I can think of a number of new protocols deployed at the edge, and in wide use, in significantly less than 3 years. But none of them had IETF involvement. Perhaps that's the biggest issue here. > MCL> SPF is an example of a server-side solution, with minimum impact on the > MCL> client and transparent to the end-user. > > Let's see. > > It requires end-users to pre-register the MTAs that they will use. SPF says nothing about end-users registering MTA's. It talks about domains listing MTA's in DNS. The two statements are very, very, different. And if end-users wish to use an MTA not listed in DNS for a domain, they can talk to the domain owner. That owner can either include their domain (end-user registration of MTA with the domain), or the owner can tell them to use one of umpteen existing protocols to send mail through a system controlled by the domain owner. That is, SPF allows end-users to register MTA's. It doesn't "require" that registration. A domain can publish a record saying "permitted from 0/0", which means no registration is required for anyone. > Otherwise, it breaks third-party MUA usage, and quite a bit of mailing > list usage, and otherwise-legitimate mobility scenarios. I guess that means SUBMIT isn't part of the solution. And the alternative is worse. Do we really intend to permit end-users to use a domains name without the consent of the domain owner? Worse, do we intend to FORCE the domain owner to accept that behaviour, even if they want to restrict use of their name? Do we want to prevent the domain owner from being able to make that choice, or publish that decision? RMX (SPF and variants) are about choice: permitting people to cooperatively and consensually communicate. If we decide that we don't want to permit people to make those choices, then we are imposing a dictatorial solution on them. IMHO, that makes us just as bad as spammers, who want to force their garbage on us despite our stated non-consent. Alan DeKok. From owner-ietf-mxcomp Wed Mar 24 07:18:54 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OFIsi0063227; Wed, 24 Mar 2004 07:18:54 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2OFIsYf063226; Wed, 24 Mar 2004 07:18:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OFIqnP063215 for ; Wed, 24 Mar 2004 07:18:53 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28054; Wed, 24 Mar 2004 10:18:53 -0500 (EST) Message-Id: <200403241518.KAA28054@ietf.org> From: The IESG To: IETF-Announce: ; Cc: ietf-mxcomp@imc.org Reply-to: iesg@ietf.org Subject: WG Review: MTA Authorization Records in DNS (marid) Date: Wed, 24 Mar 2004 10:18:52 -0500 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: A new IETF working group has been proposed in the Application Area. The IESG has not made any determination as yet. The following description was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by March 31st. MTA Authorization Records in DNS (marid) ---------------------------------------- Current Status: Proposed Working Group Description of Working Group: It would be useful for those maintaining domains and networks to be able to specify that individual hosts or nodes are authorized to act as MTAs for messages sent from those domains or networks. This working group will develop a DNS-based mechanism for storing and distributing information associated with that authorization. The primary current use case for this facility is to allow recipient MTAs to confirm that peer MTAs' actions are authorized by specific domains or networks. This will help combat a certain class of domain forgery common in spam. The solution chosen, however, should be generally useful for others which might check this authorization data. This working group is being chartered after extensive discussion of the issues in the IRTF's Anti-spam Research Group, and it is presumed that all active participants will be familiar with the documents produced there which describe the problem. It is not, however, an extension of that research group; it has no general writ to study spam or to produce specifications on the topic. It will not consider anti-spam abatement measures outside of the area of MTA authorization. Because individual messages may be associated with multiple domains (among them the domains present in the RFC2822 From, RFC2822 Sender, the SMTP Mail-From, and the SMTP EHLO), the first task of the working group will be to establish which of these identities should be associated with MTA authorization. Once this decision has been reached, it will limit the scope of further activity in this working group, and the chairs will rule out of order discussion related to schemes which use other identities as the basis of authorization. The groups Technical Advisors will help ensure that the semantics of proposals originating within this group are consonant with DNS standards and syntax, and they will be available for early cross-review to ensure that this work proceeds at an appropriate pace. Upon chartering of this working group, the IESG intends to request that the IRTF Chair and the Chairs of the IRTF's Anti-Spam Research Group seek publication of the listed input documents as Experimental RFCs, so that they are available on an archival basis. The IESG also intends to request that the RFC editor insert a note into each document informing the reader that the IETF's MARID working group has taken on the task of producing a standard in this area. From owner-ietf-mxcomp Wed Mar 24 07:17:52 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OFHqUl063184; Wed, 24 Mar 2004 07:17: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 i2OFHqIN063183; Wed, 24 Mar 2004 07:17:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OFHpRn063177 for ; Wed, 24 Mar 2004 07:17:51 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2OFHjd01820; Wed, 24 Mar 2004 07:17:45 -0800 Date: Wed, 24 Mar 2004 07:17:35 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <158927513.20040324071735@brandenburg.com> To: "Alan DeKok" CC: ietf-mxcomp@imc.org Subject: Re: Choice of SMTP headers In-Reply-To: <20040324145758.EC5A1170BB@mail.nitros9.org> References: Your message of "Tue, 23 Mar 2004 20:00:17 PST." <1992131755.20040323200017@brandenburg.com> <20040324145758.EC5A1170BB@mail.nitros9.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Alan, AD> Which new services have achieved widespread deployment in less than AD> 3-5 years? What properties do they have? None that I know of. AD> I can think of a number of new protocols deployed at the edge, and AD> in wide use, in significantly less than 3 years. Please name them. In any event, this working group is not about a new service. It is about changing an existing one. >> It requires end-users to pre-register the MTAs that they will use. AD> SPF says nothing about end-users registering MTA's. The end-user carries the ultimate burden imposed by SPF. Only the end-user can possibly know the variety of access venues they will have. And many require registration. AD> It talks about AD> domains listing MTA's in DNS. The two statements are very, very, AD> different. Actually, no they aren't. This is one of the serious impacts that MTA registration schemes tend to carry and discussion tends to miss, for the reason I cite above. AD> And if end-users wish to use an MTA not listed in DNS for a domain, AD> they can talk to the domain owner. That is the same as saying that the end-user carries the burden. This is about end-user impact, not the act of text editing domain records. AD> That owner can either include AD> their domain (end-user registration of MTA with the domain), or the AD> owner can tell them to use one of umpteen existing protocols to send AD> mail through a system controlled by the domain owner. As I said. This is visible to users. AD> That is, SPF allows end-users to register MTA's. It doesn't AD> "require" that registration. Right. And end-users are not "required" to send email. AD> A domain can publish a record saying AD> "permitted from 0/0", which means no registration is required for AD> anyone. That disables the protection mechanism, which is exactly what I hope no one wants for a mobile user (or anyone else). >> Otherwise, it breaks third-party MUA usage, and quite a bit of mailing >> list usage, and otherwise-legitimate mobility scenarios. AD> I guess that means SUBMIT isn't part of the solution. First, I listed 3 problems and you responded to one. Second, I was citing end-user impacts. Submit has very low adoption so far, it involves quite a bit of end-user visibility to change that. AD> And the alternative is worse. Do we really intend to permit AD> end-users to use a domains name without the consent of the domain AD> owner? This is the stage of discussion that seems to occur quite predictably in anti-spam discussions. Some assertions are made. Some concerns and clarifications are raised. These are then denied or dismissed and ultimately things devolve into a reference to the lack of any real choice in the matter, because spam is serious and we must do something. We are all here because we seek to get useful spam control mechanisms created and deployed. However, this purpose is not severed if we create mechanisms that have onerous impact on legitimate uses and/or high administrative overhead. AD> RMX (SPF and variants) are about choice: permitting people to AD> cooperatively and consensually communicate. This is a bit like saying that current airport security mechanisms are about choice. You can, after all, choose not to fly. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Wed Mar 24 07:58:24 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OFwN53066397; Wed, 24 Mar 2004 07:58: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 i2OFwN4v066396; Wed, 24 Mar 2004 07:58:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OFwNAj066390 for ; Wed, 24 Mar 2004 07:58:23 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2OFwKd06127; Wed, 24 Mar 2004 07:58:21 -0800 Date: Wed, 24 Mar 2004 07:58:10 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <605744965.20040324075810@brandenburg.com> To: Yakov Shafranovich CC: wayne , IETF MXCOMP Subject: Re: Why we should choose the RFC2821 MAIL FROM/HELO identities In-Reply-To: <405A8120.1030500@solidmatrix.com> References: <405A8120.1030500@solidmatrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Yakov, YS> I agree especially with the fact that verifying RFC2822 data is much YS> more complicated with all the headers involved and the lack of the YS> connecting IP address present. In the interest of accuracy: A systems-level analysis of the requirements for administering and performing an MTA registration scheme, like SPF, versus an author signature scheme, like DomainKeys, will show that they are very nearly identical. Well, actually, the administrative burden imposed by SPF is much higher, for mobile users and users who employ third-party services (like greeting card and kiosks). YS> The same applied for bounce addresses today :) As Phil mentioned YS> somewhere else if you give enough usefulness to it, the rDNS situtation YS> may improve since people will begin to use and maintain it. When there is a solid track record of something happening (or not happening) it is dangerous to make decisions that rely on that record changing. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Wed Mar 24 08:20:32 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OGKWLJ068060; Wed, 24 Mar 2004 08:20: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 i2OGKWFK068059; Wed, 24 Mar 2004 08:20:32 -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.8) with ESMTP id i2OGKVKW068052 for ; Wed, 24 Mar 2004 08:20:31 -0800 (PST) (envelope-from aland@newgiles.nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id B88E2170BB for ; Wed, 24 Mar 2004 11:24:27 -0500 (EST) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Choice of SMTP headers In-Reply-To: Your message of "Wed, 24 Mar 2004 07:17:35 PST." <158927513.20040324071735@brandenburg.com> Date: Wed, 24 Mar 2004 11:24:27 -0500 Message-Id: <20040324162427.B88E2170BB@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dave Crocker wrote: > AD> I can think of a number of new protocols deployed at the edge, and > AD> in wide use, in significantly less than 3 years. > > Please name them. Napster, for one: http://grammy.aol.com/features/0130_naptimeline.html It took a little over a year from the first version of software, to having millions of people using it. Other P2P protocols have similar deployment timescales. > The end-user carries the ultimate burden imposed by SPF. Only the > end-user can possibly know the variety of access venues they will have. > And many require registration. The end user is already carrying the burden of dealing with spam. I don't see how any method of removing that burden from the user can be cost-free. The only question then, is: Is the additional burden of RMX acceptable? I believe the answer is "yes". > AD> That is, SPF allows end-users to register MTA's. It doesn't > AD> "require" that registration. > > Right. And end-users are not "required" to send email. Exactly. It's a choice. Choices often have costs. If the cost of spam email becomes too high, many users will simply give up. Many users are *already* giving up on email. I simply don't believe that giving up on email is a better choice than using RMX. > [ 0/0 ] > > That disables the protection mechanism, which is exactly what I hope no > one wants for a mobile user (or anyone else). Exactly. People who think the cost of registration or SUBMIT is unacceptable can publish 0/0 records, and change none of their other behaviour in an RMX-aware world. Once again, it's their choice. RMX allows them to make that choice. I don't see this as a problem. > First, I listed 3 problems and you responded to one. I'm not perfect, and I don't have all the answers. > Second, I was citing end-user impacts. Submit has very low adoption > so far, it involves quite a bit of end-user visibility to change > that. So... we can work on end-user visibility. People don't use SUBMIT because there's no reason to: They just run an SMTP client themselves. RMX gives people incentive to use SUBMIT. It's a little odd to push back on deploying RMX because SUBMIT isn't widely deployed. The deployment of the two protocols can feed off each other. To me, that sounds like another reason to use RMX: It will encourage people to use SUBMIT. > AD> And the alternative is worse. Do we really intend to permit > AD> end-users to use a domains name without the consent of the domain > AD> owner? > > This is the stage of discussion that seems to occur quite predictably in > anti-spam discussions. And we've been having this discussion for nearly a year now. I still haven't gotten an answer to that question from anyone opposing the deployment of RMX. Maybe the question is too controversial, but I see it as one of the main sources of disagreement between the pro & con camps. RMX allows people to make choices, however bad (e.g. 0/0). People who disagree with RMX don't want to permit others to use RMX. That is, they're removing others ability to freely choose. > These are then denied or dismissed and ultimately things devolve > into a reference to the lack of any real choice in the matter, > because spam is serious and we must do something. I have never demanded that anyone implement or deploy RMX (despite Vernons claims to the contrary). Rather, I'm opposed to the people who are opposed to others deploying RMX. The double negative seems a bit much, but it's an accurate statement of my position. If some people believe that deploying RMX will solve their spam problem, or make them better in bed, I really couldn't care less. If their deployment of RMX causes problems when I try to communicate with them, I can either consent to their conditions for communication, or I can stop talking to them. To me, that's really what this argument is about. While discussion of deployment costs is nice, those costs matter only to the people who are deploying RMX, or interacting with people who deploy RMX. For everyone else, it just doesn't matter. The real argument is that (so far as I can tell), the people opposing RMX don't want to change their behaviour in an RMX world. So rather than not communicating with people implementing RMX, they try to prevent those people from implementing RMX. See, neither of our opinions about costs matter in the long run. If people administering systems decide that RMX is benefical and has sufficiently low cost, they're going to deploy it no matter what we think of the costs. I'd like to give them that choice. I don't see why that's a problem. > We are all here because we seek to get useful spam control mechanisms > created and deployed. However, this purpose is not severed if we create > mechanisms that have onerous impact on legitimate uses and/or high > administrative overhead. More onerous than giving up on email entirely? That's the world we're headed to. If you disagree, I'll point my MX at you. And the only reason I'm supporting RMX is that there's nothing better out there. RMX isn't perfect, but it stops one kind of spam. This is not a panicked attempt to cobble together a "solution" to the spam problem. It's a reasoned method to attack one part of the spam problem, where people can choose to implement the protocol if they believe the costs are managable > AD> RMX (SPF and variants) are about choice: permitting people to > AD> cooperatively and consensually communicate. > > This is a bit like saying that current airport security mechanisms are > about choice. You can, after all, choose not to fly. Exactly. It's an ugly world, but that's the reality. If you don't like it, you can try to change the security requirements by talking to your government... In contrast, the arguments against RMX are like someone trying to prevent airlines from implementing security, because they believe that the security measures are too expensive for everyone else, even though they have no intention of flying themselves... Alan DeKok. From owner-ietf-mxcomp Wed Mar 24 08:58:20 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OGwKi2070654; Wed, 24 Mar 2004 08:58: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 i2OGwKIe070653; Wed, 24 Mar 2004 08:58:20 -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 (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OGwJGc070647 for ; Wed, 24 Mar 2004 08:58:19 -0800 (PST) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.30) id 1B6Bht-0006JM-6c for ietf-mxcomp@imc.org; Wed, 24 Mar 2004 10:58:21 -0600 To: "IETF MXCOMP" Subject: fyi; MARID video bittorrents are going away From: wayne Content-Type: text/plain; charset=US-ASCII Date: Wed, 24 Mar 2004 10:58:18 -0600 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (spfd: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Mail-From: wayne@midwestcs.com X-SA-Exim-Scanned: No (on backbone.midwestcs.com); SAEximRunCond expanded to false Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: After the MARID BoF was over, I converted the 1.2GB high-res stereo sound videos of the meeting into equivalent 190MB videos. I made this video available via bittorrent but I am now down to only two bittorrent uploaders and that is not enough for me to support downloading. I figure should give people one more chance to try downloading the MARID BoF video before I shut down the torrent. If you are interested in grabbing the video before it goes away, see: http://www.midwestcs.com/spf/IETF_videos/ The following is a copy of the README file from the above directory: For those that want to see this session, you can download an mpeg from: ftp://limestone.uoregon.edu/pub/videolab/video/ietf59/ietf59-ch1-thur-am_040304_0845_5.mpg Note that this mpeg is 1.2GB of nice high res pictures of people talking in stereo sound at 192kbps. I have created a smaller file (over a factor of 6 smaller) that has almost the same quality. The bad news is that this mpeg does not seem to run on Windows. It appears to work fine on Linux and *BSD using mplayer and xine, but no one has found any program to display it on Windows. I'm not a video geek and I know just enough about this stuff to be dangerous. :-< Sorry Windows people. If some kind person with a clue would help me out, or do the conversion themselves, that would be great. The Unix mpeg is available via bittorrent at: http://www.midwestcs.com/spf/IETF_videos/ietf_marid.mpg.torrent I need bittorrent users to keep their torrents up, I can not provide that much bandwidth. BitTorrent plugins can ben found at: http://bitconjurer.org/BitTorrent/ There are rumors that this video works under Win2K using the Videolan client. http://www.videolan.org/vlc/ They have a MacOSX port to. I also suspect it will work fine under Mac OS X, with the mplayerOSX binaries. See: http://mplayerosx.sourceforge.net/ William(at)elan.net provided the following tips: For windows try the following links (ffdshow is probably what you need): ffdshow: http://cutka.szm.sk/ffdshow or http://sourceforge.net/projects/ffdshow XviD: http://www.xvid.org ffmpeg: http://ffmpeg.org mplayer: http://www.mplayerhq.hu The command I used to create these on Linux was: mencoder -o ietf_marid.avi -oac mp3lame \ -ovc lavc -lavcopts vcodec=mpeg4:vhq:vbitrate=100 \ -lameopts preset=voice ietf59-ch1-thur-am_040304_0845_5.mpg From owner-ietf-mxcomp Wed Mar 24 09:03:55 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OH3t59071024; Wed, 24 Mar 2004 09:03: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 i2OH3tQq071023; Wed, 24 Mar 2004 09:03:55 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OH3sNY071017 for ; Wed, 24 Mar 2004 09:03:54 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2OH3jd12539; Wed, 24 Mar 2004 09:03:46 -0800 Date: Wed, 24 Mar 2004 09:03:34 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <375772385.20040324090334@brandenburg.com> To: "Alan DeKok" CC: ietf-mxcomp@imc.org Subject: Re: Choice of SMTP headers In-Reply-To: <20040324162427.B88E2170BB@mail.nitros9.org> References: Your message of "Wed, 24 Mar 2004 07:17:35 PST." <158927513.20040324071735@brandenburg.com> <20040324162427.B88E2170BB@mail.nitros9.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Alan, AD> Dave Crocker wrote: >> AD> I can think of a number of new protocols deployed at the edge, and >> AD> in wide use, in significantly less than 3 years. AD> Napster, for one: http://grammy.aol.com/features/0130_naptimeline.html ok. central registration and a centralized query service. initially a single implementation. yes, those do facilitate rapid deployment. IETF work is typically about multiple implementations of services that are truly distributed. Certainly email falls into that category, as do changes to it. >> The end-user carries the ultimate burden imposed by SPF. Only the >> end-user can possibly know the variety of access venues they will have. >> And many require registration. AD> The end user is already carrying the burden of dealing with spam. Both true and irrelevant. You claimed that SPF imposes no user burden. The truth of that statement does not hinge on whether other things impose a burden. AD> The only question then, is: Is the additional burden of AD> RMX acceptable? I believe the answer is "yes". That question is entirely different from claiming there is no user visible impact. AD> If the cost of spam email becomes too high, many users will simply AD> give up. Many users are *already* giving up on email. I simply don't AD> believe that giving up on email is a better choice than using RMX. Again: we all know spam is a problem. Constantly citing its seriousness does nothing to further the technical discussion. Characterizing adoption of an RMX scheme, versus giving up on email as the only two choices is simply wrong. There are more choices than that. AD> Exactly. People who think the cost of registration or SUBMIT is AD> unacceptable can publish 0/0 records, and change none of their other AD> behaviour in an RMX-aware world. AD> Once again, it's their choice. RMX allows them to make that AD> choice. I don't see this as a problem. Once again, a scheme that requires disabling the scheme, to support significant, valid scenarios, is a very problematic scheme. >> First, I listed 3 problems and you responded to one. AD> I'm not perfect, and I don't have all the answers. damn. please stop destroying my illusions... >> Second, I was citing end-user impacts. Submit has very low adoption >> so far, it involves quite a bit of end-user visibility to change >> that. AD> So... we can work on end-user visibility. People don't use SUBMIT AD> because there's no reason to: They just run an SMTP client AD> themselves. RMX gives people incentive to use SUBMIT. Perhaps. But you claimed all of this was not user visible. Changing to Submit is user visible. AD> It's a little odd to push back on deploying RMX because SUBMIT isn't AD> widely deployed. It is a little odd to claim something is not user visible when in fact it is highly user visible. AD> The deployment of the two protocols can feed off AD> each other. Adoption plans that have dependencies on other adoption plans take much longer and often fail. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Wed Mar 24 09:04:40 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OH4emL071110; Wed, 24 Mar 2004 09:04: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 i2OH4ewx071109; Wed, 24 Mar 2004 09:04:40 -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 (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OH4dKB071103 for ; Wed, 24 Mar 2004 09:04:39 -0800 (PST) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.30) id 1B6Bo2-0006Qi-RQ for ietf-mxcomp@imc.org; Wed, 24 Mar 2004 11:04:42 -0600 To: "IETF MXCOMP" Subject: Re: Why we should choose the RFC2821 MAIL FROM/HELO identities References: <405A8120.1030500@solidmatrix.com> <605744965.20040324075810@brandenburg.com> From: wayne Content-Type: text/plain; charset=US-ASCII Date: Wed, 24 Mar 2004 11:04:42 -0600 In-Reply-To: <605744965.20040324075810@brandenburg.com> (Dave Crocker's message of "Wed, 24 Mar 2004 07:58:10 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (spfd: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Mail-From: wayne@midwestcs.com X-SA-Exim-Scanned: No (on backbone.midwestcs.com); SAEximRunCond expanded to false Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <605744965.20040324075810@brandenburg.com> Dave Crocker writes: > In the interest of accuracy: > > A systems-level analysis of the requirements for administering and > performing an MTA registration scheme, like SPF, versus an author > signature scheme, like DomainKeys, will show that they are very nearly > identical. > > Well, actually, the administrative burden imposed by SPF is much higher, > for mobile users and users who employ third-party services (like > greeting card and kiosks). I do not believe that the burden imposed by SPF is much higher than DomainKeys, but that is based on a very fuzzy idea of how DomainKeys would have to work. As far as I can tell, there are some subtle details that cause DomainKeys to be either almost useless or to require massive changes in the email infrastructure. Do you have a copy of the exact DomainKeys spec and example code? If not, how can you do systems-level analysis? -wayne From owner-ietf-mxcomp Wed Mar 24 09:27:13 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OHRDwe073262; Wed, 24 Mar 2004 09:27: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 i2OHRDbs073261; Wed, 24 Mar 2004 09:27:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mauve.mrochek.com ([209.55.107.55]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OHRCmM073255 for ; Wed, 24 Mar 2004 09:27:13 -0800 (PST) (envelope-from ned.freed@mrochek.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01L82RM6HIWW0027NR@mauve.mrochek.com> for ietf-mxcomp@imc.org; Wed, 24 Mar 2004 09:27:14 -0800 (PST) Date: Wed, 24 Mar 2004 09:11:13 -0800 (PST) From: ned.freed@mrochek.com Subject: Re: Choice of SMTP headers In-reply-to: "Your message dated Wed, 24 Mar 2004 07:17:35 -0800" <158927513.20040324071735@brandenburg.com> To: Dave Crocker Cc: Alan DeKok , ietf-mxcomp@imc.org Message-id: <01L83MNL78ME0027NR@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <1992131755.20040323200017@brandenburg.com> <20040324145758.EC5A1170BB@mail.nitros9.org> <158927513.20040324071735@brandenburg.com> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Alan, > AD> Which new services have achieved widespread deployment in less than > AD> 3-5 years? What properties do they have? > None that I know of. Actually, I believe that the SMTP NOTARY extension did achieve widespread deployment within 3-5 years. (I base this assessment on the timing of the problem reports that invariably come in after such deployment occurs.) But it is instructive to look at why this happened: It was mostly an accident of timing. Specifically, NOTARY was implemented in various MTAs around the time open relaying ceased to be viable. As a result NOTARY support showed up in the same revisions of several products that improved relay blocking also showed up in. There was rapid uptake of these revisions to get better relay blocking capabilities, and NOTARY support came along for the ride. So what does this say about deployment of other new facilities? One thing it says is that facilities people have to have, or think they have to have, in order to remain operational, will deploy quickly. But of course this begs the question of whether or not whatever this working group produces will be seen in this light. I don't think we can count on this being the case no matter what we come up with. There's also another factor that will act as something of a wildcard in these matters. Historically the majority of MTAs have been designed as monolithic agents with limited extensibility. But this has changed. Modern MTAs have various sorts of callout hooks in them that can be used to extend the MTA's functionality without having to install a new version. This lets someone apart from the MTA vendor write plugins. And this changes the dynamics of the situation in ways that are hard to predict. > AD> And the alternative is worse. Do we really intend to permit > AD> end-users to use a domains name without the consent of the domain > AD> owner? > This is the stage of discussion that seems to occur quite predictably in > anti-spam discussions. Some assertions are made. Some concerns and > clarifications are raised. These are then denied or dismissed and > ultimately things devolve into a reference to the lack of any real > choice in the matter, because spam is serious and we must do something. > We are all here because we seek to get useful spam control mechanisms > created and deployed. However, this purpose is not severed if we create > mechanisms that have onerous impact on legitimate uses and/or high > administrative overhead. THen what needs to be done is to come up with a series of use cases that can be used to assess the impact of the various proposals. If handwaving about the benefits outweighing the costs is unacceptable so is simple insistance that the costs are too high. Ned From owner-ietf-mxcomp Wed Mar 24 09:54:55 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OHstsK074820; Wed, 24 Mar 2004 09:54: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 i2OHstTv074819; Wed, 24 Mar 2004 09:54:55 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OHssRR074813 for ; Wed, 24 Mar 2004 09:54:54 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2OHsod17595; Wed, 24 Mar 2004 09:54:50 -0800 Date: Wed, 24 Mar 2004 09:54:38 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <622647405.20040324095438@brandenburg.com> To: ned.freed@mrochek.com CC: Dave Crocker , Alan DeKok , ietf-mxcomp@imc.org Subject: Re: Choice of SMTP headers In-Reply-To: <01L83MNL78ME0027NR@mauve.mrochek.com> References: <1992131755.20040323200017@brandenburg.com> <20040324145758.EC5A1170BB@mail.nitros9.org> <158927513.20040324071735@brandenburg.com> <01L83MNL78ME0027NR@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ned, nfmc> used to assess the impact of the various proposals. If handwaving about the nfmc> benefits outweighing the costs is unacceptable so is simple insistance that nfmc> the costs are too high. Correct. That's why the problems with RMX-based approaches, in terms of visible user impact, eliminating of essentially all cross-Internet store-and-forward -- including mailing lists -- and elimination of various mobility scenarios including third-party MUAs, all have been cited repeatedly. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Wed Mar 24 10:25:39 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OIPcOX077766; Wed, 24 Mar 2004 10:25: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 i2OIPcuh077765; Wed, 24 Mar 2004 10:25:38 -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 (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OIPbNU077759 for ; Wed, 24 Mar 2004 10:25:38 -0800 (PST) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.30) id 1B6D4P-0007VE-EK for ietf-mxcomp@imc.org; Wed, 24 Mar 2004 12:25:41 -0600 To: "IETF MXCOMP" Subject: Re: Choice of SMTP headers References: <1992131755.20040323200017@brandenburg.com> <20040324145758.EC5A1170BB@mail.nitros9.org> <158927513.20040324071735@brandenburg.com> From: wayne Content-Type: text/plain; charset=US-ASCII Date: Wed, 24 Mar 2004 12:25:40 -0600 In-Reply-To: <158927513.20040324071735@brandenburg.com> (Dave Crocker's message of "Wed, 24 Mar 2004 07:17:35 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (spfd: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Mail-From: wayne@midwestcs.com X-SA-Exim-Scanned: No (on backbone.midwestcs.com); SAEximRunCond expanded to false Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <158927513.20040324071735@brandenburg.com> Dave Crocker writes: > AD> I can think of a number of new protocols deployed at the edge, and > AD> in wide use, in significantly less than 3 years. > > Please name them. Well, I guess it all depends on your definition of "wide use", but off the top of my head, I can suggest HTTP, AIM, DNSBLs, and it looks like SPF is well on the road to widespread use. As Alan said, all of these have had the property of not having the IETF involved. >>> It requires end-users to pre-register the MTAs that they will use. > > AD> SPF says nothing about end-users registering MTA's. > > The end-user carries the ultimate burden imposed by SPF. This isn't entirely true. Companies that use SPF to restrict the usage of their domain name pay almost the entire cost of their choice. Part of that cost may involve training of employees, or helping employees change the way they do things, but the company still pays the employees for this time. ISPs and such that use SPF to restrict the usage of their domain names, and do it in such a way as to be painful for their customers, will likely lose customers. This puts the ultimate burden on both the ISPs and the end-users. This, unfortunately, is no different from many other bad policies that ISPs can choose to do, or good policies that ISPs choose to do in bad ways. Right now, the burden of unauthorized usage of domain names falls largely on the domain name owners. > The end-user carries the ultimate burden imposed by SPF. Only the > end-user can possibly know the variety of access venues they will have. > And many require registration. Actually, the LMAP proposals all allow the domain owner to track the DNS lookups, so that they can get a general idea of the variety of access venues. SPF allows for much more detailed tracking and for the DNS lookups to be directed to a different nameserver so that the logging is much more practical. This means that the domain name owner can have a much better idea of of the variety of access venues than any individual end-user. > AD> And if end-users wish to use an MTA not listed in DNS for a domain, > AD> they can talk to the domain owner. > > That is the same as saying that the end-user carries the burden. This > is about end-user impact, not the act of text editing domain records. If the end-user has no legal right to use the domain name, then denying them the use of that domain name is not a "burden". Stores that install anti-shoplifting devices are not placing a "burden" on shoplifters, even though shoplifters may no longer be able to shoplift. > AD> That is, SPF allows end-users to register MTA's. It doesn't > AD> "require" that registration. > > Right. And end-users are not "required" to send email. End users are not required to send email from domains that have not approved of their use. With domain name ownership going for $5-$10/yr, it is likely that end-users will be easily able to find a domain name that they can reasonably use. The LMAP proposals are, fundementally, about giving domain name owners a voice. The fact that some domain owners will choose to say things that are shortsighted, bad, hateful, or stupid is not a valid reason keep them gagged. Receivers of email are easily able to decide if they want to listen to domain name owners or not, which greatly limits any damage that domain owner's speech can cause. -wayne From owner-ietf-mxcomp Wed Mar 24 11:15:00 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OJF0ND081122; Wed, 24 Mar 2004 11:15: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 i2OJF0xb081121; Wed, 24 Mar 2004 11:15:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (IDENT:root@ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OJExSK081106 for ; Wed, 24 Mar 2004 11:14:59 -0800 (PST) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-19-105.client.comcast.net [24.6.19.105]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i2OJExhX026383 for ; Wed, 24 Mar 2004 11:14:59 -0800 (PST) Received: by tethys.bitshift.org (Postfix, from userid 1001) id 960C72288D; Wed, 24 Mar 2004 11:14:59 -0800 (PST) Date: Wed, 24 Mar 2004 11:14:59 -0800 From: "Mark C. Langston" To: IETF MXCOMP Subject: Re: Choice of SMTP headers Message-ID: <20040324191459.GO96036@bitshift.org> References: <1992131755.20040323200017@brandenburg.com> <20040324145758.EC5A1170BB@mail.nitros9.org> <158927513.20040324071735@brandenburg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Uptime: 10:35AM up 281 days, 13:44, 8 users, load averages: 0.03, 0.05, 0.01 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Mar 24, 2004 at 12:25:40PM -0600, wayne wrote: > > In <158927513.20040324071735@brandenburg.com> Dave Crocker writes: > > > AD> I can think of a number of new protocols deployed at the edge, and > > AD> in wide use, in significantly less than 3 years. > > > > Please name them. > > Well, I guess it all depends on your definition of "wide use", but off > the top of my head, I can suggest HTTP, AIM, DNSBLs, and it looks like > SPF is well on the road to widespread use. > HTTP did not see "wide use, in significantly less tha 3 years". From http://www.mit.edu/people/mkgray/net/web-growth-summary.html : In the two year period from 6/93 to 6/95, there were only 23,500 websites. I can't find any data on the growth of AIM or the OSCAR protocol, but I'd be very interested in seeing the data on which you've based your claim. Similarly, I can't find any historical data on DNSBL use versus number of deployed MTAs, but I'd imagine Paul Vixie may have such for MAPS. But MAPS started as a private list, distributed via BGP. It was started in 1997, and there were rulesets that could be manually added to sendmail.cf late that year, but whether it saw "widespread use" significantly before 2000 is an open question. Certainly, sendmail 8.9 had MAPS use as a feature, but that wasn't until mid-1998. And inclusion of a capability does not connote use, unless that feature's turned on by default. It wasn't. As for SPF on the road to widespread use: Isn't the current registry at only about 6000 or so domains? Out of an estimated 250,000,000 (source: http://www.isc.org/index.pl?/ops/ds/ ). Even if there were 6 million domains advertising SPF records, it wouldn't we "widespread use". Further, "use" would include the number of MTAs performing SPF checks. Sure, the number will spike a bit when the version of SpamAssassin that includes SPF scoring is released, but that's like saying that the #6 Torx screw is hugely popular with consumers based on their consumption of microwaves. The consumers must really love that screw. > > Right now, the burden of unauthorized usage of domain names falls > largely on the domain name owners. > And right now, that burden is a bit difficult to bear in mobile scenarios, without very short zone TTLs and some means to dynamically update the records remotely and securely. Some may argue the latter's easy for a notebook, and I might agree. But notebooks aren't the only mobile devices that use SMTP. > > Actually, the LMAP proposals all allow the domain owner to track the > DNS lookups, so that they can get a general idea of the variety of > access venues. SPF allows for much more detailed tracking and for the > DNS lookups to be directed to a different nameserver so that the > logging is much more practical. > > This means that the domain name owner can have a much better idea of > of the variety of access venues than any individual end-user. > Actually, it means the domain name _administrator_ can have that idea. Bear in mind that "domain name owner" and "entity responsible for zone changes, tracking such statistics, etc." are often two very different people. The owner may well want to use SPF, but be unable to because the entity administering the domain does not have knowledge of SPF, the tools with which to manage use of SPF, or the willingness to change the zone in the manner requested once, let alone on an on-demand basis. > > > AD> And if end-users wish to use an MTA not listed in DNS for a domain, > > AD> they can talk to the domain owner. > > > > That is the same as saying that the end-user carries the burden. This > > is about end-user impact, not the act of text editing domain records. > > If the end-user has no legal right to use the domain name, then > denying them the use of that domain name is not a "burden". Stores > that install anti-shoplifting devices are not placing a "burden" on > shoplifters, even though shoplifters may no longer be able to shoplift. > If the end-user DOES have a legal right to use the domain name, and they are prohibted from doing so thanks to SPF or similar proposals, what then? > > > AD> That is, SPF allows end-users to register MTA's. It doesn't > > AD> "require" that registration. > > > > Right. And end-users are not "required" to send email. > > End users are not required to send email from domains that have not > approved of their use. With domain name ownership going for > $5-$10/yr, it is likely that end-users will be easily able to find a > domain name that they can reasonably use. > Again, what about the legitimate use of a domain name, prohibited because the end-user doesn't happen to be sitting behind a "blessed" machine at the moment, or is unable to connect to a "blessed" MX? > > > The LMAP proposals are, fundementally, about giving domain name owners > a voice. The fact that some domain owners will choose to say things > that are shortsighted, bad, hateful, or stupid is not a valid reason > keep them gagged. Okay, then: This domain name owner would like to use his voice to state that he's not happy with the idea of being unable to use his domain names while mobile. Bear in mind that the addition of hoops that must be jumped through while mobile will not win me over, because one of my uses is via cellphone -- a device that's not very flexible when someone points to it and says, "just make it jump through these additional hoops..." I've always operated on a "send from lots of various places under a single identity" principle. Home, work, coffeeshops, in the park, at a hotel, in an airport, at a friend's house. From my laptop, other people's laptops, public terminals, PDAs, cellphones with MUAs built-in, cellphones acting as modems, and so forth. I can see merit in the argument that begins, "a client could be written to dynamically update the TXT record when you connect to the network", were we discussing a notebook I own, on a network with no transparent proxies. But that's not the case. -- Mark C. Langston Sr. Unix SysAdmin mark@bitshift.org mark@seti.org Systems & Network Admin SETI Institute http://bitshift.org http://www.seti.org From owner-ietf-mxcomp Wed Mar 24 12:16:23 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OKGNa1086060; Wed, 24 Mar 2004 12:16: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 i2OKGNWU086059; Wed, 24 Mar 2004 12:16: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 (midwestcs.com [206.222.212.234]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OKGLkG086052 for ; Wed, 24 Mar 2004 12:16:22 -0800 (PST) (envelope-from wayne@midwestcs.com) Received: from footbone.midwestcs.com ([206.222.212.237] helo=midwestcs.com) by backbone.midwestcs.com with esmtp (Exim 4.30) id 1B6EnY-0000Xq-SI for ietf-mxcomp@imc.org; Wed, 24 Mar 2004 14:16:24 -0600 To: "IETF MXCOMP" Subject: Re: Choice of SMTP headers References: <1992131755.20040323200017@brandenburg.com> <20040324145758.EC5A1170BB@mail.nitros9.org> <158927513.20040324071735@brandenburg.com> <20040324191459.GO96036@bitshift.org> From: wayne Content-Type: text/plain; charset=US-ASCII Date: Wed, 24 Mar 2004 14:16:23 -0600 In-Reply-To: <20040324191459.GO96036@bitshift.org> (Mark C. Langston's message of "Wed, 24 Mar 2004 11:14:59 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (spfd: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Mail-From: wayne@midwestcs.com X-SA-Exim-Scanned: No (on backbone.midwestcs.com); SAEximRunCond expanded to false Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: [note: I'm exceeding the suggested limit of 3 emails to this list per day because I didn't post anything yesterday. This will be my last email for today.] In <20040324191459.GO96036@bitshift.org> "Mark C. Langston" writes: > On Wed, Mar 24, 2004 at 12:25:40PM -0600, wayne wrote: > >> Well, I guess it all depends on your definition of "wide use", but [...] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > HTTP did not see "wide use, in significantly less tha 3 years". > [and other such comments snipped] As I said, it all depends on what your defintion of "wide use" is. The numbers you quoted are inline with my understandings and I would certainly consider them to show widespread use. Trying to pin down a definition of "wide use" is probably pretty useless though. > As for SPF on the road to widespread use: Isn't the current registry at > only about 6000 or so domains? Adoption rolls are notoriously inaccurate and only really show an absolute miminum. That said, the last numbers I saw on the website was around 9,000 and it has (apparently) reached the point where the number of domains is exceeding the resources of a volunteer's efforts to track them. It is also known that several large domain parking systems have published SPF records for all of their parked domains. The number of actual domains with SPF records is probably in the range of 100,000 to 500,000, but that could be off by a factor of >10. > Even if there were 6 million > domains advertising SPF records, it wouldn't we "widespread use". Again, I disagree on your definition of "widespread use". Besides, a more important measure is percentage of email with that is sent rather than the number of domains. Heck, even a better measure is the number of unauthorized emails sent, since that is what the LMAP proposals are trying to eliminate. > If the end-user DOES have a legal right to use the domain name, and they > are prohibted from doing so thanks to SPF or similar proposals, what > then? Then there are, obvious, well known and well established methods of seeking legal remedies. The existance of such legal remedies tends to limit the amount of illegal abuse. >> The LMAP proposals are, fundementally, about giving domain name owners >> a voice. The fact that some domain owners will choose to say things >> that are shortsighted, bad, hateful, or stupid is not a valid reason >> keep them gagged. > > Okay, then: This domain name owner would like to use his voice to state > that he's not happy with the idea of being unable to use his domain > names while mobile. If you, as a domain name owner, choose to make your life difficult for your self, then, well, I'm happy for you. > I can see merit in the argument that begins, "a client could be written > to dynamically update the TXT record when you connect to the network", > were we discussing a notebook I own, on a network with no transparent > proxies. But that's not the case. A proof-of-concept rate-limiting DNS server for SPF was published several months ago. This would allow you, as a domain owner, to let a certain number of emails from unexpected sources to go through without any problems, while still greatly limiting the damage done by spammers. There was at least one person earlier this year that was talking about writing an SPF-after-IMAP DNS server, but I don't know if there was ever working code written. -wayne From owner-ietf-mxcomp Wed Mar 24 12:45:36 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OKjZ07088536; Wed, 24 Mar 2004 12:45:36 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2OKjZxt088535; Wed, 24 Mar 2004 12:45:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (IDENT:root@ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OKjZec088526 for ; Wed, 24 Mar 2004 12:45:35 -0800 (PST) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-19-105.client.comcast.net [24.6.19.105]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i2OKjbhX014406 for ; Wed, 24 Mar 2004 12:45:37 -0800 (PST) Received: by tethys.bitshift.org (Postfix, from userid 1001) id BFF0A22887; Wed, 24 Mar 2004 12:45:37 -0800 (PST) Date: Wed, 24 Mar 2004 12:45:37 -0800 From: "Mark C. Langston" To: IETF MXCOMP Subject: Re: Choice of SMTP headers Message-ID: <20040324204537.GP96036@bitshift.org> References: <1992131755.20040323200017@brandenburg.com> <20040324145758.EC5A1170BB@mail.nitros9.org> <158927513.20040324071735@brandenburg.com> <20040324191459.GO96036@bitshift.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Uptime: 12:35PM up 281 days, 15:44, 7 users, load averages: 0.29, 0.07, 0.02 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Mar 24, 2004 at 02:16:23PM -0600, wayne wrote: > > It is also known that several large domain parking systems have > published SPF records for all of their parked domains. Oho! With or without the domain owners' permission? Here is a great example of how something like this can quickly become a problem. How many of the domain owners even know that there's an SPF record published for their domain, and what impact that publication may have on their ability to successfully send mail? How many know the steps to take to have that record altered or removed? Is the entity responsible for putting the record there even willing to remove it? > > > If the end-user DOES have a legal right to use the domain name, and they > > are prohibted from doing so thanks to SPF or similar proposals, what > > then? > > Then there are, obvious, well known and well established methods of > seeking legal remedies. The existance of such legal remedies tends to > limit the amount of illegal abuse. > So, your solution is to sue providers who use, say, transparent proxies? > > > > Okay, then: This domain name owner would like to use his voice to state > > that he's not happy with the idea of being unable to use his domain > > names while mobile. > > If you, as a domain name owner, choose to make your life difficult for > your self, then, well, I'm happy for you. > You miss the point. I'm trying to make my life easy and convenient. It's the proposals that will eliminate this ease and convenience that will make my life difficult. I don't understand why the "we must do something, or stop using mail" crowd is so eager to provide "stop using mail" as a solution to certain problems, when it seems so abhorrent to them. > > > I can see merit in the argument that begins, "a client could be written > > to dynamically update the TXT record when you connect to the network", > > were we discussing a notebook I own, on a network with no transparent > > proxies. But that's not the case. > > A proof-of-concept rate-limiting DNS server for SPF was published several > months ago. This would allow you, as a domain owner, to let a certain > number of emails from unexpected sources to go through without any > problems, while still greatly limiting the damage done by spammers. > There was at least one person earlier this year that was talking about > writing an SPF-after-IMAP DNS server, but I don't know if there was > ever working code written. So, domain owners have to convince their nameservice providers to switch to an entirely new DNS server? I don't find that to be a reasonable expectation. It's fine if you provide your own nameservice, but of those 250 million domain names, I'd wager the vast majority don't. -- Mark C. Langston Sr. Unix SysAdmin mark@bitshift.org mark@seti.org Systems & Network Admin SETI Institute http://bitshift.org http://www.seti.org From owner-ietf-mxcomp Wed Mar 24 12:48:34 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OKmYNk088664; Wed, 24 Mar 2004 12:48: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 i2OKmYDh088663; Wed, 24 Mar 2004 12:48: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.8) with ESMTP id i2OKmUI9088655 for ; Wed, 24 Mar 2004 12:48:33 -0800 (PST) (envelope-from aland@newgiles.nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 5D9E7170BB for ; Wed, 24 Mar 2004 15:52:24 -0500 (EST) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Choice of SMTP headers In-Reply-To: Your message of "Wed, 24 Mar 2004 09:03:34 PST." <375772385.20040324090334@brandenburg.com> Date: Wed, 24 Mar 2004 15:52:24 -0500 Message-Id: <20040324205224.5D9E7170BB@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dave Crocker wrote: > >> AD> I can think of a number of new protocols deployed at the edge, and > >> AD> in wide use, in significantly less than 3 years. > AD> Napster, for one: http://grammy.aol.com/features/0130_naptimeline.html > > ok. central registration and a centralized query service. initially a > single implementation. Yes. Edge deployments. End-user work required to deal with RMX variants is similar. The end users install new software (SUBMIT client) which connects to a centralized service (ISP or business MTA). Everyone uses the same client, but the "centralized service" is distributed, and everyone can choose which service to point their client at. > You claimed that SPF imposes no user burden. The truth of that statement > does not hinge on whether other things impose a burden. If I did, it was either a mis-statement, or an unclear phrasing on my part. My messages should make it clear that I understand SPF may require end-users to change their behaviour, or to upgrade software. > Characterizing adoption of an RMX scheme, versus giving up on email as > the only two choices is simply wrong. There are more choices than that. Of course. But many people I know have simply stopped reading "postmaster" mail for their domains, due to the number of bounces (thousands an hour for a 10-user domain.) RMX/SPF would stop those bounces *entirely*. Either the bounce would never be sent, or the recipient could tell the bounce was about a fraudulent message, and discard it. Many MTA administrators I know like RMX, if only because it permits them to read "postmaster" mail again. Lack of a useful "postmaster" has significant cost and stability issues for many domains. That is, a flaw in the design of SMTP is preventing another feature of SMTP from being useful. The protocol design is contradictory, and should be fixed. We should either not do bounce-path verification (e.g. LMAP), and admit that bounces are no longer useful; OR we should demand that bounces be useful, and resign ourselves to implementing bounce-path verification. > [ 0/0 ] > > Once again, a scheme that requires disabling the scheme, to support > significant, valid scenarios, is a very problematic scheme. It's not "disabling" the scheme. It's working within the scheme to acheive backwards compatibility with end-users who don't want to change their behaviour. And this is the entire reason for LMAP: to give recipients the ability to tell valid from invalid scenarios. You can claim on a mailing list that some scenario is "valid", but my MTA doesn't read this list. Alan DeKok. From owner-ietf-mxcomp Wed Mar 24 13:08:15 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OL8Fsx089932; Wed, 24 Mar 2004 13:08: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 i2OL8E3L089931; Wed, 24 Mar 2004 13:08:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OL8EqV089925 for ; Wed, 24 Mar 2004 13:08:14 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2OL8Dd03180; Wed, 24 Mar 2004 13:08:13 -0800 Date: Wed, 24 Mar 2004 13:08:01 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1323702485.20040324130801@brandenburg.com> To: "Alan DeKok" CC: ietf-mxcomp@imc.org Subject: Re: Choice of SMTP headers In-Reply-To: <20040324205224.5D9E7170BB@mail.nitros9.org> References: Your message of "Wed, 24 Mar 2004 09:03:34 PST." <375772385.20040324090334@brandenburg.com> <20040324205224.5D9E7170BB@mail.nitros9.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Alan, >> ok. central registration and a centralized query service. initially a >> single implementation. AD> Yes. Edge deployments. requiring a central server is not an 'edge' deployment. AD> End-user work required to deal with RMX variants is similar. The AD> end users install new software (SUBMIT client) which connects to a AD> centralized service (ISP or business MTA). I think that the origin of this sub-tread continue to be forgotten. Note: MCL> For that reason, it'd be better to come up with a recommendation whose MCL> impact is largely, or completely, server-side, and transparent to the MCL> client and end-users. So, this is about claimed transparency and a counter-claims that RMX approaches are a long way from being transparent to end-users. >> You claimed that SPF imposes no user burden. The truth of that statement >> does not hinge on whether other things impose a burden. AD> If I did, it was either a mis-statement, or an unclear phrasing on AD> my part. my bad. MCL made the claim. Still, it was the basis for this sub-thread. AD> Many MTA administrators I know like RMX, if only because it permits AD> them to read "postmaster" mail again. Lack of a useful "postmaster" AD> has significant cost and stability issues for many domains. Solutions that become unwieldly with large-scale use have their own cost and stability issues, especially if their benefit is ephemeral. >> Once again, a scheme that requires disabling the scheme, to support >> significant, valid scenarios, is a very problematic scheme. AD> It's not "disabling" the scheme. It's working within the scheme to AD> acheive backwards compatibility with end-users who don't want to AD> change their behaviour. For the users with the problem, it renders the scheme useless, except for creating hassles. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Wed Mar 24 13:18:29 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OLITgD091076; Wed, 24 Mar 2004 13:18: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 i2OLITHY091075; Wed, 24 Mar 2004 13:18:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (IDENT:root@ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OLIMVG091063 for ; Wed, 24 Mar 2004 13:18:22 -0800 (PST) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-19-105.client.comcast.net [24.6.19.105]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i2OLIMhX020603; Wed, 24 Mar 2004 13:18:22 -0800 (PST) Received: by tethys.bitshift.org (Postfix, from userid 1001) id B951722887; Wed, 24 Mar 2004 13:18:22 -0800 (PST) Date: Wed, 24 Mar 2004 13:18:22 -0800 From: "Mark C. Langston" To: Dave Crocker Cc: Alan DeKok , ietf-mxcomp@imc.org Subject: Re: Choice of SMTP headers Message-ID: <20040324211822.GS96036@bitshift.org> References: <375772385.20040324090334@brandenburg.com> <20040324205224.5D9E7170BB@mail.nitros9.org> <1323702485.20040324130801@brandenburg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1323702485.20040324130801@brandenburg.com> User-Agent: Mutt/1.4.1i X-Uptime: 1:14PM up 281 days, 16:23, 7 users, load averages: 0.00, 0.00, 0.00 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Mar 24, 2004 at 01:08:01PM -0800, Dave Crocker wrote: > > my bad. MCL made the claim. Still, it was the basis for this > sub-thread. I did, and when I made it, I didn't intend it to be taken as "SPF has zero end-user impact". It has a good deal of end-user impact, particularly when the end-user is mobile. I meant to emphasize that the bulk of the operational changes are server-side in SPF rather than client-side, and that it's one of the proposals that swings more towards server-side burden. I apologize; I'm trying to be clear in my statements, but I seem to be failing. -- Mark C. Langston Sr. Unix SysAdmin mark@bitshift.org mark@seti.org Systems & Network Admin SETI Institute http://bitshift.org http://www.seti.org From owner-ietf-mxcomp Wed Mar 24 15:23:03 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2ONN339099584; Wed, 24 Mar 2004 15:23: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 i2ONN3Dc099583; Wed, 24 Mar 2004 15:23:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from polis.nbtsc.org (polis.nbtsc.org [206.168.119.2]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2ONMwpf099575 for ; Wed, 24 Mar 2004 15:23:02 -0800 (PST) (envelope-from aredridel@nbtsc.org) Received: from aredridel by polis.nbtsc.org with local (Exim 4.30) id 1B6Hi9-0000Vy-Af for ietf-mxcomp@imc.org; Wed, 24 Mar 2004 16:23:01 -0700 Date: Wed, 24 Mar 2004 16:23:01 -0700 From: Aredridel To: ietf-mxcomp@imc.org Subject: Re: Why we should choose the RFC2821 MAIL FROM/HELO identities Message-ID: <20040324232301.GA27875@mail.nbtsc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > Well, actually, the administrative burden imposed by SPF is much higher, > > for mobile users and users who employ third-party services (like > > greeting card and kiosks). > > I do not believe that the burden imposed by SPF is much higher than > DomainKeys, but that is based on a very fuzzy idea of how DomainKeys > would have to work. As far as I can tell, there are some subtle > details that cause DomainKeys to be either almost useless or to require > massive changes in the email infrastructure. I agree here -- SPF as it's currently specified only checks SMTP-level fields, not headers -- it's easy enough to rewrite any third-party service to use their own domain as the sending domain in the MAIL FROM. Their numbers are far fewer than end-users, so requiring software changes there is probably the smallest breakage. SPF also codifies what's rapidly becoming a best practice: rejecting mail that claims to come from one place (domain) when in fact it is coming from an unrelated (and unauthorized) place (specified with a map in the domain). Already, many ISPs reject mail claiming to be from a user in their domain if it does not carry with it some local authorization (whether source IP address, specific HELO, out-of-band authorization protocol data or in-band data such as SMTP AUTH). Rejecting such mail makes tracking of abuse much simpler, allows much better policy enforcement and by making even a weak verification of the MAIL FROM, it makes it a much more trustworthy piece of information. Directing bounces is the most difficult part of such an exchange, since SMTP specifies that the MAIL FROM is also the place where bounces should go to, leaving no application protocol level source of identity data. The only solution is to have the originating system relay bounces to the appropriate destination as a separate transaction, instead of short-circuiting and going straight to the unverifiable sender address. In essence, by validating MAIL FROM, it allows semantics such as if MAIL FROM != RFC2822-From, then display as "From: on behalf of " Which I consider very useful. At the moment, the is totally useless, because I have no indication that it is legitimate or forged simply to coerce me into thinking the mail is valid. The main reason I prefer validating MAIL FROM instead of header fields is that it maintains some semblance of layering: RFC2821 specifically tries to avoid relying on RFC{2,}822 semantics too much: When RFC 822 format [7, 32] is being used, the mail data include the memo header items such as Date, Subject, To, Cc, From. Server SMTP systems SHOULD NOT reject messages based on perceived defects in the RFC 822 or MIME [12] message header or message body. In particular, they MUST NOT reject messages in which the numbers of Resent-fields do not match or Resent-to appears without Resent-from and/or Resent- date. That hands-off approach lets future mail formats interoperate fairly well. "Received:" headers must be prepended, allowing easy removal, as is SPF's proposed "Received-SPF:" header. It's also lightweight: the usual SPF record's query bandwidth is near the minimum used in a single SMTP session to transmit a message with no data. With DNS caching, a mail delivery system should see no more than a few percent increase in bandwidth in even the pathological case. SPF-like proposals also scale well -- in addition to the proven scalability of DNS, ability to specify netblocks as designated senders (even the wide open 0.0.0.0/0 or ::/0) allows domains enough flexibility to do most authorization schemes, and the "exists:" mechanism in SPF allows dynamic authorization for mobile senders -- and by design, that service could be contracted out to a third party if a domain doesn't wish to run its own dynamic authorization server, simply by referencing a DNS-based list maintained elsewhere. I hope this comes off clearly. With regards to all, Aredridel. From owner-ietf-mxcomp Wed Mar 24 15:37:51 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2ONbp9n000821; Wed, 24 Mar 2004 15:37:51 -0800 (PST) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2ONbpmZ000820; Wed, 24 Mar 2004 15:37:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2ONbptU000814 for ; Wed, 24 Mar 2004 15:37:51 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2ONbrd16189; Wed, 24 Mar 2004 15:37:53 -0800 Date: Wed, 24 Mar 2004 15:37:40 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1464718935.20040324153740@brandenburg.com> To: Aredridel CC: ietf-mxcomp@imc.org Subject: Re: Why we should choose the RFC2821 MAIL FROM/HELO identities In-Reply-To: <20040324232301.GA27875@mail.nbtsc.org> References: <20040324232301.GA27875@mail.nbtsc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Aredridel, >> I do not believe that the burden imposed by SPF is much higher than >> DomainKeys, ... A> I agree here -- SPF as it's currently specified only checks SMTP-level A> fields, not headers That difference does not constitute much of a technical difference to the software. It's all part of a protocol stream and none is more difficult to parse. A> -- it's easy enough to rewrite any third-party A> service to use their own domain as the sending domain in the MAIL FROM. MailFrom does not specify the sending domain. It specifies a return address. It is not appropriate to have intermediaries arbitrarily changing the return address. A> SPF also codifies what's rapidly becoming a best practice: rejecting A> mail that claims to come from one place (domain) when in fact it is A> coming from an unrelated (and unauthorized) place (specified with a map that's not distinctive to spf. A> if MAIL FROM != RFC2822-From, then display as "From: A> on behalf of " you want the user to be shown the return address, if it does not match the From field? A> The main reason I prefer validating MAIL FROM instead of header fields A> is that it maintains some semblance of layering: RFC2821 specifically A> tries to avoid relying on RFC{2,}822 semantics too much: Actually, this has pretty close to nothing to do with layering. You can model the analysis module at whatever layer is appropriate to the data. A> SPF-like proposals also scale well Something that requires pre-registration of all of the places I may send mail from does not scale all that well. Imagine having to preregister every telephone you might call from. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Wed Mar 24 15:55:47 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2ONtlPh001764; Wed, 24 Mar 2004 15:55: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 i2ONtl4R001763; Wed, 24 Mar 2004 15:55:47 -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 (srv1.pan-am.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2ONtkIe001757 for ; Wed, 24 Mar 2004 15:55:47 -0800 (PST) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: Why we should choose the RFC2821 MAIL FROM/HELO identities MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 24 Mar 2004 17:55:51 -0600 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA7FD@srv1.pan-am.ca> X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Why we should choose the RFC2821 MAIL FROM/HELO identities Thread-Index: AcQR+XFAd3AvjbleTOqcxvn62jvvogAAC8VQ From: "Gordon Fecyk" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2ONtlIe001758 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > A> SPF-like proposals also scale well > Something that requires pre-registration of all of the places > I may send > mail from does not scale all that well. Imagine having to preregister > every telephone you might call from. "Calling-Card." At least that's what my phone company calls them - effectively a credit card for making local and long distance phone calls without depositing money. It's my "registration." But that's more analogous to SMTP AUTH, or SMTP AUTH over a different port. Now this was covered in the LMAP discussion draft, too. There are many ways for authorized users to authenticate themselves against a relay server for sending mail. Just like calling cards let me place long distance calls at my phone company's rates from a phone not serviced by my phone company. And as explained in said draft, they don't have to scale with the Internet, just with the number of users at a given site. The die-hards who just have to be their own MTA can use dynamic DNS to "pre-register" and "de-register" their locations seamlessly. I believe these to be in the extreme minority but they're not excluded. This is an implementation problem, not a design problem for us. It's an easy problem to solve too, at least for the IP-based designs like DMP and FSV.[1] [1] If folks are going to say "spf-like," "rmx-like," I am going to say it. -- PGP key (0x0AFA039E): What's a PGP Key? See GOD BLESS AMER, er, THE INTERNET. From owner-ietf-mxcomp Wed Mar 24 16:10:11 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2P0ABMr002644; Wed, 24 Mar 2004 16:10: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 i2P0ABXJ002643; Wed, 24 Mar 2004 16:10:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2P0AAgZ002632 for ; Wed, 24 Mar 2004 16:10:10 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2P0AFd19056; Wed, 24 Mar 2004 16:10:15 -0800 Date: Wed, 24 Mar 2004 16:10:02 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <332000134.20040324161002@brandenburg.com> To: "Gordon Fecyk" CC: ietf-mxcomp@imc.org Subject: Re: Why we should choose the RFC2821 MAIL FROM/HELO identities In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125DA7FD@srv1.pan-am.ca> References: <700EEF5641B7E247AC1C9B82C05D125DA7FD@srv1.pan-am.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Gordon, >> mail from does not scale all that well. Imagine having to preregister >> every telephone you might call from. GF> "Calling-Card." That's actually quite different. RMX mechanisms require registering the MTA. That's equivalent to having to pre-register the physical telephones that you will use. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-ietf-mxcomp Wed Mar 24 16:14:19 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2P0EJDt002981; Wed, 24 Mar 2004 16:14: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 i2P0EJGa002980; Wed, 24 Mar 2004 16:14:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (IDENT:root@ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2P0EIZI002971 for ; Wed, 24 Mar 2004 16:14:18 -0800 (PST) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-19-105.client.comcast.net [24.6.19.105]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i2P0EMhX025250 for ; Wed, 24 Mar 2004 16:14:22 -0800 (PST) Received: by tethys.bitshift.org (Postfix, from userid 1001) id 22ACF2288A; Wed, 24 Mar 2004 16:14:22 -0800 (PST) Date: Wed, 24 Mar 2004 16:14:22 -0800 From: "Mark C. Langston" To: ietf-mxcomp@imc.org Subject: Re: Why we should choose the RFC2821 MAIL FROM/HELO identities Message-ID: <20040325001422.GW96036@bitshift.org> References: <700EEF5641B7E247AC1C9B82C05D125DA7FD@srv1.pan-am.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125DA7FD@srv1.pan-am.ca> User-Agent: Mutt/1.4.1i X-Uptime: 3:56PM up 281 days, 19:06, 8 users, load averages: 0.03, 0.04, 0.00 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Mar 24, 2004 at 05:55:51PM -0600, Gordon Fecyk wrote: > > > A> SPF-like proposals also scale well > > > Something that requires pre-registration of all of the places > > I may send > > mail from does not scale all that well. Imagine having to preregister > > every telephone you might call from. > > "Calling-Card." > > At least that's what my phone company calls them - effectively a credit card > for making local and long distance phone calls without depositing money. > It's my "registration." But that's more analogous to SMTP AUTH, or SMTP AUTH > over a different port. > "location that blocks use of calling cards except the ones they sell, by blocking outbound toll-free calls" (yes, they do exist, and are the calling-card equivalent of hotels that transparently hijack outbound toll calls to route them over their own preferred LD carrier, for profit. Until recently, I faced one at work, and there was NO way around it: cellphones were verboten, and as it's a remote jungle location, you either jumped through their hoops or did without. Unfortunately, business needs eliminate the "do without" option. This is even beginning to happen with cellphones in Japan -- the cellular signal is intercepted and routed through the location's private cell net instead.) So yes, both SMTP AUTH and calling cards are solutions to the "I desire that my outbound traffic take a particular route" problem. But they aren't a solution to the "I am unable to direct my outbound traffic over a particular route due to ( sending device limitations | external restrictions imposed with or without my knowledge )" problem. The assumption that device limitations are easily overcome, and the assumption that external restrictions are always known and/or easily avoided seem to underly your approach. How should a cellphone user facing a transparent SMTP proxy solve this problem? Short of completely reconfiguring the MUA, how should an end-user borrowing a friend's/co-worker's machine or using a public terminal solve this problem, without resorting to insisting that there be web-based email available? > > The die-hards who just have to be their own MTA can use dynamic DNS to > "pre-register" and "de-register" their locations seamlessly. Again, I'll hold up the cellphone user as an example of use in which this is simply not possible without a good deal of effort on behalf of the cellphone equipment provider and the cell carrier (as the two often work cooperatively, though some would say antagonistically) to deploy firmware updates to phones. -- Mark C. Langston Sr. Unix SysAdmin mark@bitshift.org mark@seti.org Systems & Network Admin SETI Institute http://bitshift.org http://www.seti.org From owner-ietf-mxcomp Wed Mar 24 18:03:57 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2P23v0G012492; Wed, 24 Mar 2004 18:03: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 i2P23vrY012491; Wed, 24 Mar 2004 18:03:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2P23uiJ012483 for ; Wed, 24 Mar 2004 18:03:56 -0800 (PST) (envelope-from millenix@zemos.net) Received: from fda.zemos.net ([68.38.12.170]) by comcast.net (rwcrmhc12) with ESMTP id <2004032502035701400jb61de>; Thu, 25 Mar 2004 02:03:57 +0000 Received: from zemos.net (phil [10.0.0.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fda.zemos.net (Postfix) with ESMTP id E7FDF18680; Wed, 24 Mar 2004 21:03:55 -0500 (EST) Message-ID: <40623E0B.7010104@zemos.net> Date: Wed, 24 Mar 2004 21:03:55 -0500 From: Philip Miller User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040312 Debian/1.6-3 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Dave Crocker Cc: ietf-mxcomp@imc.org Subject: Re: Why we should choose the RFC2821 MAIL FROM/HELO identities References: <700EEF5641B7E247AC1C9B82C05D125DA7FD@srv1.pan-am.ca> <332000134.20040324161002@brandenburg.com> In-Reply-To: <332000134.20040324161002@brandenburg.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dave Crocker wrote: >>>mail from does not scale all that well. Imagine having to preregister >>>every telephone you might call from. > > GF> "Calling-Card." > > That's actually quite different. > > RMX mechanisms require registering the MTA. That's equivalent to having > to pre-register the physical telephones that you will use. No, I think it's much closer to preregistering a small, fixed set of operators who are willing to relay your call. That would include those of your personal service provider, who you can connect to with the use of your card from any phone that takes it. Registering the MAC address of each computer you will use to send mail is equivalent to registering the telephone. All this talk of analogies between the email system and any other system, for communication or anything else, does nothing to advance this discussion. People here are using analogies to create an image of the costs and benefits that differs greatly from those seen in email and the proposals on the table. Therefore, I suggest that we stop using analogies between the email system (with or without changes) and other systems entirely, and provide hard statements of facts, assumptions, and beliefs. Philip Miller From owner-ietf-mxcomp Wed Mar 24 18:26:38 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2P2Qbej013873; Wed, 24 Mar 2004 18:26: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 i2P2Qb8P013872; Wed, 24 Mar 2004 18:26:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gate012.lsu.edu (gate012.ocs.lsu.edu [130.39.184.214]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2P2QbNi013866 for ; Wed, 24 Mar 2004 18:26:37 -0800 (PST) (envelope-from bz+ietf@chemserv.chem.lsu.edu) Received: from CHEM-BZO4 ([130.39.161.199]) by gate012.lsu.edu (Lotus Domino Release 6.0.2CF1) with SMTP id 2004032420264112-19441 for ; Wed, 24 Mar 2004 20:26:41 -0600 Posted-and-Mailed: no Subject: Re: Why we should choose the RFC2821 MAIL FROM/HELO From: bz References: <1lS%b.9384471$Id.1564181@news.easynews.com> <4f9d3d24.0402281610.7c07a0ba@posting.google.com> <%mY7c.11457779$Of.1923976@news.easynews.com> <10639d0ctsu9f56@corp.supernews.com> Organization: LSU Chemistry Department User-Agent: Xnews/5.04.25 To: ietf-mxcomp@imc.org Date: Wed, 24 Mar 2004 20:26:42 -0600 Message-ID: Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Aredridel said: > Directing bounces is the most difficult part of such an exchange, since > SMTP specifies that the MAIL FROM is also the place where bounces should > go to, leaving no application protocol level source of identity data. > The only solution is to have the originating system relay bounces to the > appropriate destination as a separate transaction, instead of > short-circuiting and going straight to the unverifiable sender address. > a recent discussion on ietf-smtp has been addressing the question: "Do the must 'bounce' rules need to be relaxed for virus infected messages?" Would a relaxation of the 'must bounce' rule also help here? -- bz please pardon my infinite ignorance, the set-of-things-I-do-not-know is an infinite set. bz+ietf@chem.lsu.edu From owner-ietf-mxcomp Wed Mar 24 19:04:45 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2P34jXP016464; Wed, 24 Mar 2004 19:04: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 i2P34j0a016463; Wed, 24 Mar 2004 19:04:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2P34iwT016454 for ; Wed, 24 Mar 2004 19:04:45 -0800 (PST) (envelope-from millenix@zemos.net) Received: from fda.zemos.net ([68.38.12.170]) by comcast.net (sccrmhc13) with ESMTP id <2004032503044401600r0t68e>; Thu, 25 Mar 2004 03:04:44 +0000 Received: from zemos.net (phil [10.0.0.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fda.zemos.net (Postfix) with ESMTP id CDCA018680; Wed, 24 Mar 2004 22:04:43 -0500 (EST) Message-ID: <40624C4B.6000909@zemos.net> Date: Wed, 24 Mar 2004 22:04:43 -0500 From: Philip Miller User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040312 Debian/1.6-3 X-Accept-Language: en, en-us MIME-Version: 1.0 To: bz Cc: ietf-mxcomp@imc.org Subject: Re: Why we should choose the RFC2821 MAIL FROM/HELO References: <1lS%b.9384471$Id.1564181@news.easynews.com> <4f9d3d24.0402281610.7c07a0ba@posting.google.com> <%mY7c.11457779$Of.1923976@news.easynews.com> <10639d0ctsu9f56@corp.supernews.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: bz wrote: > Aredridel said: >>Directing bounces is the most difficult part of such an exchange, since >>SMTP specifies that the MAIL FROM is also the place where bounces should >>go to, leaving no application protocol level source of identity data. >>The only solution is to have the originating system relay bounces to the >>appropriate destination as a separate transaction, instead of >>short-circuiting and going straight to the unverifiable sender address. > > a recent discussion on ietf-smtp has been addressing the question: > "Do the must 'bounce' rules need to be relaxed for virus infected messages?" > > Would a relaxation of the 'must bounce' rule also help here? For the time being, the IETF should publish a BCP RFC recommending against bounce messages in response to viruses known to forge MAIL FROM. Other than that, I think the 'must bounce' specification is a good one, and provides great benefit in a world in which bounce is guaranteed to be directed to someone in a position to react to it. Specifically, if the domain in MAIL FROM cannot be forged, and a site receives an email-carried virus with a given domain in the MAIL FROM, I would imagine that most administrators would like to receive notice of the crap leaving their network. Philip Miller From owner-ietf-mxcomp Wed Mar 24 19:45:19 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2P3jJ82018653; Wed, 24 Mar 2004 19:45: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 i2P3jJiN018652; Wed, 24 Mar 2004 19:45:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from polis.nbtsc.org (polis.nbtsc.org [206.168.119.2]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2P3jIgB018644 for ; Wed, 24 Mar 2004 19:45:18 -0800 (PST) (envelope-from aredridel@nbtsc.org) Received: from mizar.nbtsc.org ([2001:470:1f01:301:230:1bff:feac:c01c]) by polis.nbtsc.org with asmtp (Exim 4.30) id 1B6Lo5-0006RH-BK for ietf-mxcomp@imc.org; Wed, 24 Mar 2004 20:45:25 -0700 Received: from aredridel by mizar.nbtsc.org with local (Exim 4.30) id 1B6LoN-0007SE-KZ for ietf-mxcomp@imc.org; Wed, 24 Mar 2004 20:45:43 -0700 Date: Wed, 24 Mar 2004 20:45:43 -0700 From: Aredridel To: ietf-mxcomp@imc.org Subject: Re: Why we should choose the RFC2821 MAIL FROM/HELO Message-ID: <20040325034543.GB28620@mail.nbtsc.org> References: <1lS%b.9384471$Id.1564181@news.easynews.com> <4f9d3d24.0402281610.7c07a0ba@posting.google.com> <%mY7c.11457779$Of.1923976@news.easynews.com> <10639d0ctsu9f56@corp.supernews.com> <40624C4B.6000909@zemos.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40624C4B.6000909@zemos.net> User-Agent: Mutt/1.4.2.1i X-Arbitrary-Number-Of-The-Day: 42 X-Scan-Signature: 0d078a28f4167edd29e3d960bb0dd8b0 X-Spam-Score: 0.0 (/) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > >a recent discussion on ietf-smtp has been addressing the question: > >"Do the must 'bounce' rules need to be relaxed for virus infected > >messages?" > > > >Would a relaxation of the 'must bounce' rule also help here? Only if the message is verified as coming from outside the network you'd be notifying. Bounces are a -good- thing. > For the time being, the IETF should publish a BCP RFC recommending against > bounce messages in response to viruses known to forge MAIL FROM. Other than > that, I think the 'must bounce' specification is a good one, and provides > great benefit in a world in which bounce is guaranteed to be directed to > someone in a position to react to it Agreed. . > Specifically, if the domain in MAIL FROM cannot be forged, and a site > receives an email-carried virus with a given domain in the MAIL FROM, I > would imagine that most administrators would like to receive notice of the > crap leaving their network. Yes -- at the moment such messages are discarded fairly blindly. However, if many domains were to implement an SPF-like system, I think I'd pay more attention and actually go track down my users (for the record, I'm the operator of a small ISP -- we have 400 or so customers, with a 400:1 customer:tech support ratio) who are infected. Ari From owner-ietf-mxcomp Wed Mar 24 22:04:30 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2P64UMw027629; Wed, 24 Mar 2004 22:04: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 i2P64T5E027627; Wed, 24 Mar 2004 22:04:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from polis.nbtsc.org (polis.nbtsc.org [206.168.119.2]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2P64TCX027614 for ; Wed, 24 Mar 2004 22:04:29 -0800 (PST) (envelope-from aredridel@nbtsc.org) Received: from mizar.nbtsc.org ([2001:470:1f01:301:230:1bff:feac:c01c]) by polis.nbtsc.org with asmtp (Exim 4.30) id 1B6Nym-0008RV-Ub for ietf-mxcomp@imc.org; Wed, 24 Mar 2004 23:04:36 -0700 Received: from aredridel by mizar.nbtsc.org with local (Exim 4.30) id 1B6Nz4-0007Vx-RA for ietf-mxcomp@imc.org; Wed, 24 Mar 2004 23:04:54 -0700 Date: Wed, 24 Mar 2004 23:04:54 -0700 From: Aredridel To: ietf-mxcomp@imc.org Subject: Re: Why we should choose the RFC2821 MAIL FROM/HELO identities Message-ID: <20040325060454.GD28620@mail.nbtsc.org> References: <700EEF5641B7E247AC1C9B82C05D125DA7FD@srv1.pan-am.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125DA7FD@srv1.pan-am.ca> User-Agent: Mutt/1.4.2.1i X-Arbitrary-Number-Of-The-Day: 42 X-Scan-Signature: 14acfafb94e3fb1dab98340a1365c021 X-Spam-Score: 0.0 (/) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > [1] If folks are going to say "spf-like," "rmx-like," I am going to say it. I'm not set on the current spec of SPF. I just like the concept. (I actually find the syntax baroque, as others have complained of.) It does work in every test I've made, though, so while a bit dated seeming, it does the job. Here are the use cases I come in contact with: * My users already use SMTP AUTH, because many of them come from a shared network used by many ISPs. * I have ports 25 and 587 both open for MUA to MTA message submission: 587 was opened first because my users are already having their mail blocked while traveling -- one at a hotel, one on a cable network at their office, and several others on a wireless ISP. * I see 50% of the mail I deliver as spam, or is virus payload. I * outright reject at least the same volume based on Spam Assassin scoring. * Some 5% of the unwanted mail (a good portion of those are virii) is sent with a null sender, but could be rejected with a system like SRS -- and since my systems would be the only ones who have to handle it specially, I plan to deploy such a system shortly. * I've run into the case of an ad-hoc SPF-like system already deployed, where messages my systems forwarded (without sender rewriting) was rejected because my system "didn't appear to be the sending domain" -- people are desparate to stop spam, and it looks like the traveling mailman will be the first casualty. At least with a DNS-based designated-sender system that's easily updatable, there's some chance of having it work. Thoughts to ponder. Ari From owner-ietf-mxcomp Thu Mar 25 00:36:28 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2P8aSUs084877; Thu, 25 Mar 2004 00:36: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 i2P8aSt9084876; Thu, 25 Mar 2004 00:36:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from slot.hollandcasino.net (slot.hollandcasino.net [193.172.40.18]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2P8aR1Q084865 for ; Thu, 25 Mar 2004 00:36:28 -0800 (PST) (envelope-from alex@slot.hollandcasino.net) Received: by slot.hollandcasino.net (Postfix, from userid 501) id 2A4C617DC05; Thu, 25 Mar 2004 09:36:27 +0100 (CET) Date: Thu, 25 Mar 2004 09:36:27 +0100 From: Alex van den Bogaerdt To: ietf-mxcomp@imc.org Subject: Re: Why we should choose the RFC2821 MAIL FROM/HELO identities Message-ID: <20040325093627.A1192@slot.hollandcasino.net> Mail-Followup-To: ietf-mxcomp@imc.org References: <20040324232301.GA27875@mail.nbtsc.org> <1464718935.20040324153740@brandenburg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1464718935.20040324153740@brandenburg.com>; from dhc@dcrocker.net on Wed, Mar 24, 2004 at 03:37:40PM -0800 X-Legal-Note: ---------------------------------------------- Everything I write or say expresses my opinion only! Unless otherwise stated, I do not represent my employer or anyone else for that matter. ---------------------------------------------------- Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Mar 24, 2004 at 03:37:40PM -0800, Dave Crocker wrote: > A> SPF-like proposals also scale well When compared to other methods such as centralized registries. > Something that requires pre-registration of all of the places I may send > mail from does not scale all that well. Imagine having to preregister > every telephone you might call from. You don't have to. However, I sometimes program my phone to make sound only when known numbers call me. People wanting my support in the middle of the night better use a preregistered number. Also, phone companies make sure this number is not easily spoofed, something we are only now trying to accomplish with SMTP. Futhermore, when someone calls me from an unknown number, and when I do pick up the phone, there's still the matter of voice recognition. This means I recognize the person on the remote end. You could compare this to authenticated SMTP. In the end, PSTN and SMTP are not much different. The biggest difference is that spammers calling me over the phone pay the bill whereas spammers sending me email do not. Alex -- begin sig http://www.googlism.com/index.htm?ism=alex+van+den+bogaerdt&type=1 This message was produced without any