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:0