From owner-ietf-mxcomp@mail.imc.org Fri Jun 11 14:39:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23792 for ; Fri, 11 Jun 2004 14:39:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BIWpQ3062288; Fri, 11 Jun 2004 11:32:51 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5BIWpHK062287; Fri, 11 Jun 2004 11:32:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BIWo8S062273 for ; Fri, 11 Jun 2004 11:32:50 -0700 (PDT) (envelope-from edlewis@arin.net) Received: by smtp2.arin.net (Postfix, from userid 5003) id 349B919B5D1; Fri, 11 Jun 2004 14:32:43 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id B451A19B3AB; Fri, 11 Jun 2004 14:32:42 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.136.136.83]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1760658; Fri, 11 Jun 2004 14:32:53 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Fri, 11 Jun 2004 14:33:01 -0400 To: "Hallam-Baker, Phillip" From: Edward Lewis Subject: RE: suggested path and arch Cc: "'Edward Lewis'" , ietf-mxcomp@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63-arin1 (2004-01-11) on smtp2.arin.net X-Spam-Status: No, hits=-8.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63-arin1 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 21:07 -0700 6/10/04, Hallam-Baker, Phillip wrote: >If you had listened to other people at the face to face rather >than shouting them down you would know that DNSEXT is not an >option here. I'm assuming that DNSEXT is a typo. What I heard at the face to face, and what was circulated in email at the time was that: Could a new type be entered into existing DNS servers? The answer was yes, there was a survey of DNS implementations on the mailing list [0] showing support for new types. It might require hex encoding of the RDATA of the type, but existing name server code is able to understand what's been called "an unknown" type. Could an application on a client be able to query directly for the desired type, foregoing the native OS support? The answer I heard was yes except for those clients that are obscured from the Internet by an environment that only allowed RPC access to lookup services. [0] Survey is: http://www.imc.org/ietf-mxcomp/mail-archive/msg01423.html [1] Claim that this can't be done in Windows: http://www.imc.org/ietf-mxcomp/mail-archive/msg01471.html I can't find an answer to "couldn't a client program just to the lookup itself, if the OS didn't support the new type?" -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Even the voices inside my head are refusing to talk to me anymore. From owner-ietf-mxcomp@mail.imc.org Fri Jun 11 15:17:44 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26609 for ; Fri, 11 Jun 2004 15:17:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BIwoBJ064930; Fri, 11 Jun 2004 11:58:50 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5BIwoYx064929; Fri, 11 Jun 2004 11:58:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ernie.mail-abuse.org (Ernie.mail-abuse.org [168.61.5.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BIwo5k064921 for ; Fri, 11 Jun 2004 11:58:50 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.mail-abuse.org (DDev.mail-abuse.org [168.61.10.124]) by ernie.mail-abuse.org (8.12.0.Beta19/8.12.0) with ESMTP id i5BIwmPQ050447; Fri, 11 Jun 2004 11:58:48 -0700 (PDT) Subject: Re: Alternative to TXT or new RR was: Comments on draft-ietf-marid-core-01 xml use From: Douglas Otis To: Michel Py Cc: MARID In-Reply-To: References: Content-Type: text/plain Message-Id: <1086980327.20584.4.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 11 Jun 2004 11:58:48 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2004-06-10 at 23:15, Michel Py wrote: > > Douglas Otis wrote: > > Looking to simplify an aspect of deployment must consider > > the entire process. To premise a design based upon an > > architecture where SMTP rarely enters without a bridging > > component may place too much emphasis on this aspect over > > perhaps more pressing matters having to do with the overall > > integrity of the system. > > No argument here, has to see the big picture. > > > There is a problem in that the "core" proposal is adding > > restrictions on a TXT record where few exist but stops short > > of ensuring further changes occur as a result of a standards > > process. > > A very valid point indeed; however I think you do not put it in the > right context, and here's why: > > In _appearance_, we are facing the following decision to make: pick one > out of the following three: > > 1. We do it quick and dirty with TXT. > 2. We do it right and slow with a new RR type. > 3. We say that we'll go with 1 as a temporary measure and with 2 in the > long run. > > Two problems here: > a) All three have major shortcomings: 1 is dirty, 2 is too slow, and 3 > is a bastard that leaves us with having to support both. > b) This "choice" is something we have only in _appearance_. In reality, > we don't have a choice and here's why: > > - If this WG leans towards 1, there will be enough opposition about the > solution being dirty (and for good reasons) to stall the process and > never achieve the "quick" part of it. > > - If this WG leans towards 2, a schism that will split the SPF community > will inevitably happen, and everyone loses. Not only the SPF spinoff > will deploy much sooner, likely making MARID irrelevant due to > time-to-market issues; but even worse the "old-new" SPF will still put > whatever they see fit in TXT outside of any IETF standard, which was > your fear in the first place. > > - If this WG leans towards 3, it pleases no-one and goes nowhere. I have > seen enough "3 month temporary" solutions that are still in service 10 > years later to believe in this one. > > > There is a way out of this, IMHO. This way is as follows: > > I. We use the TXT RR for SPFID, because we need it now and not in 5 > years. > > II. At the same time, we obsolete the RFCs describing the > TXT RR and replace them with new text that says: > > i) The TXT RR is now reserved for SPFID and you can't put > anything you want in it anymore; anything that would go > into the TXT record needs to be cleared by MARID first. > > ii) We create a TXT1 RR that will fulfill the role > previously assigned to the TXT RR. > > > Comments? There is an alternative to a hostile take-over of the TXT record as I mentioned. Use a token such as "MARID-1" and follow this with a CRC-32c checksum (good Hamming distance and code used in SCTP) of the entire record where the checksum field is treated as zero. Such as "MARID-1[FD034A45]..." or perhaps "FD034A45_MARID-1...". See RFC3309 for an example of language and code. As it may be improbable a TXT record would start with the token or checksum, but with the checksum it would take several lifetimes of random text files before there should be a conflict. The token would also create a foundation for other future uses of the TXT record without requiring a new record invented. This would be an alternative to the use of the label to indicate revisions as would be a problem with SPF if its label was replaced with an asterisk. -Doug > > Michel. From owner-ietf-mxcomp@mail.imc.org Fri Jun 11 15:22:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26953 for ; Fri, 11 Jun 2004 15:22:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BJ9IT6066054; Fri, 11 Jun 2004 12:09:18 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5BJ9IvY066053; Fri, 11 Jun 2004 12:09:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BJ9IEU066037 for ; Fri, 11 Jun 2004 12:09:18 -0700 (PDT) (envelope-from michel@arneill-py.sacramento.ca.us) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Alternative to TXT or new RR was: Comments on draft-ietf-marid-core-01 xml use Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 11 Jun 2004 12:09:14 -0700 Message-ID: Thread-Topic: Alternative to TXT or new RR was: Comments on draft-ietf-marid-core-01 xml use Thread-Index: AcRPgmNaIKe5uM6wQTaj3+cybDS1QwAZJOmg From: "Michel Py" To: "william\(at\)elan.net" Cc: "MARID" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5BJ9IEU066046 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > william(at)elan.net wrote: > [..] I was joking because while this may seem like a way out, > in no way do I think it should be done or that it'll ever fly > by IETF top guys. We should never attempt to completely take > over somebody else record, that is a very bad precident for IETF. Then, which one out of the three alternatives I posted yesterday would you recommend (or add your own)? 1. We do it quick and dirty with TXT. 2. We do it right and slow with a new RR type. 3. We say that we'll go with 1 as a temporary measure and with 2 in the long run. Michel. From owner-ietf-mxcomp@mail.imc.org Fri Jun 11 15:28:48 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27222 for ; Fri, 11 Jun 2004 15:28:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BJIq4e067116; Fri, 11 Jun 2004 12:18:52 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5BJIqH4067114; Fri, 11 Jun 2004 12:18:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BJIq8K067082 for ; Fri, 11 Jun 2004 12:18:52 -0700 (PDT) (envelope-from michel@arneill-py.sacramento.ca.us) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Alternative to TXT or new RR was: Comments on draft-ietf-marid-core-01 xml use Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 11 Jun 2004 12:18:51 -0700 Message-ID: Thread-Topic: Alternative to TXT or new RR was: Comments on draft-ietf-marid-core-01 xml use Thread-Index: AcRP3ywLlZPx6sJMSCWQRPtx8zVT1gACUnLQ From: "Michel Py" To: "Edward Lewis" Cc: "MARID" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5BJIq8K067101 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > Edward Lewis > The TXT RR is used by ISC's dhcpd to record client > identities in DNS. I haven't been able to track > this back to any DHCP specification. Is TXT RR the one for the domain itself or is there one per host? If the later, I don't see any conflict. Could you post an example? Michel. From owner-ietf-mxcomp@mail.imc.org Fri Jun 11 15:30:33 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27294 for ; Fri, 11 Jun 2004 15:30:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BJKM1l067237; Fri, 11 Jun 2004 12:20:22 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5BJKM1H067236; Fri, 11 Jun 2004 12:20:22 -0700 (PDT) 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.9) with SMTP id i5BJKLku067230 for ; Fri, 11 Jun 2004 12:20:21 -0700 (PDT) (envelope-from maex@Space.Net) Received: (qmail 93531 invoked by uid 1013); 11 Jun 2004 19:20:24 -0000 Date: Fri, 11 Jun 2004 21:20:24 +0200 From: Markus Stumpf To: IETF MARID WG Subject: Re: MTAmark (was: Reality check please) Message-ID: <20040611192024.GC99040@Space.Net> References: <20040611172844.GB32187@Space.Net> 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 Fri, Jun 11, 2004 at 01:04:22PM -0500, wayne wrote: > Since > the interim meeting, all 2821 proposals are now out of scope. Ah. Says who? I can only see a single pointer to that mentioned in the minutes of the interim meeting: *> Andy asked the room if they found the converged plan valuable and *> wise use of time and received a loud hum. This was about the convergence of CID and SPF. I can see no mention in the minutes nor a statement on the list that the WG has set the goal to publish a standard along the lines of CID/SPF merge. I can't see that any verification has taken place in this mailing list which would be required by RFC 2418 / 3.3. Session management. But I don't think I care any longer, it is of no use to beat a dead horse. As I said before this WG has lost contact to reality and timely deployment if the goal is SPG/CID merge with XML in DNS. We had the day before yesterday (yesterday was public holiday here so lesser emails than usual) on a /medium (to some smaller) sized/ MTA: 499078 non bounce messages 40885 unique sender domain. Quite some of them are mailing lists and forwards, but if MARID goes 2822 checks the number of unique sender domains probably doubles. Did anybody seriously think about the time delay, bandwidth increase, memory increase in the caches and load increase on the auth servers this will result in? Queries for the MARID records and queries for the "includes" and queries for the reputation and accreditation services which have to some degree be serialized (can't query reputation and accreditation services before the MARID records are queried in depth) and all will be useless as not more than 10% of all existing domains will deploy MARID within the next 5 years. Ok, make it 50% and it doesn't change a thing. Because of a 50:50 chance no one will reject messages. Oh and about preventing phishing "because we authorize with MARID records and have authentication" read http://weblog.infoworld.com/udell/2004/03/23.html > I don't think Markus was at the meeting, Neither me privately not my employer were willing to pay the 2000 or so bucks for travelling across half of the world to attend a one day meeting. > but PHB was, so I'm surprised > he is posting this out of scope stuff. Unless there is a clear and agreed upon scope different from the charter for this WG posted here and official announced, postings like this of PHB are hardly out of scope. \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@mail.imc.org Fri Jun 11 15:53:12 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28437 for ; Fri, 11 Jun 2004 15:53:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BJdkIs069262; Fri, 11 Jun 2004 12:39:46 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5BJdkE7069261; Fri, 11 Jun 2004 12:39:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.pan-am.ca (srv1.pan-am.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BJdjk3069255 for ; Fri, 11 Jun 2004 12:39:46 -0700 (PDT) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: [RFC 1464?] RE: Alternative to TXT or new RR was: Comments ondraft-ietf-marid-core-01 xml use MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 11 Jun 2004 14:39:49 -0500 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA8C1@srv1.pan-am.ca> X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Alternative to TXT or new RR was: Comments ondraft-ietf-marid-core-01 xml use Thread-Index: AcRP6VI7X9qt0O4UStOr3OmOgQIEigAAhTlw From: "Gordon Fecyk" To: "MARID" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5BJdkk3069256 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > There is an alternative to a hostile take-over of the TXT record as I > mentioned. > > Use a token such as "MARID-1" and follow this with a CRC-32c checksum > (good Hamming distance and code used in SCTP) of the entire > record where > the checksum field is treated as zero. Such as "MARID-1[FD034A45]..." > or perhaps "FD034A45_MARID-1...". See RFC3309 for an example > of language and code. No one's brought up RFC 1464 yet, which describes how to store unique and arbitrary information in TXT records in DNS. SPF does this, DMP does this. It avoids the TXT record collision problem by describing a unique attribute name along with a value for the attribute. How does ISC dhcpd store its host information in the TXT records? And how does it tell the difference between its own records and something else's? Doesn't it use a token like RFC 3309 or an attribute format like RFC 1464? -- PGP key (0x0AFA039E): Sometimes it's hard to tell where the game ends and where reality bites, er, begins. From owner-ietf-mxcomp@mail.imc.org Fri Jun 11 16:08:12 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29014 for ; Fri, 11 Jun 2004 16:08:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BJtM9P071493; Fri, 11 Jun 2004 12:55:22 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5BJtMl0071492; Fri, 11 Jun 2004 12:55:22 -0700 (PDT) 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.9) with SMTP id i5BJtKxQ071486 for ; Fri, 11 Jun 2004 12:55:21 -0700 (PDT) (envelope-from maex@Space.Net) Received: (qmail 35859 invoked by uid 1013); 11 Jun 2004 19:55:24 -0000 Date: Fri, 11 Jun 2004 21:55:24 +0200 From: Markus Stumpf To: MARID Subject: Re: Alternative to TXT or new RR was: Comments on draft-ietf-marid-core-01 xml use Message-ID: <20040611195524.GG99040@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 Fri, Jun 11, 2004 at 12:18:51PM -0700, Michel Py wrote: > Is TXT RR the one for the domain itself or is there one per host? If the > later, I don't see any conflict. Could you post an example? A receiving MTA cannot find out whether the RHS side of the @ in an email address is a host or a (sub-)domain. Just think arneill-py.sacramento.ca.us sacramento.ca.us ca.us \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@mail.imc.org Fri Jun 11 16:27:52 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00846 for ; Fri, 11 Jun 2004 16:27:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BKBsks073557; Fri, 11 Jun 2004 13:11:54 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5BKBsmH073556; Fri, 11 Jun 2004 13:11:54 -0700 (PDT) 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.9) with SMTP id i5BKBrnV073539 for ; Fri, 11 Jun 2004 13:11:53 -0700 (PDT) (envelope-from maex@Space.Net) Received: (qmail 56353 invoked by uid 1013); 11 Jun 2004 20:11:57 -0000 Date: Fri, 11 Jun 2004 22:11:57 +0200 From: Markus Stumpf To: Gordon Fecyk Cc: MARID Subject: Re: [RFC 1464?] RE: Alternative to TXT or new RR was: Comments ondraft-ietf-marid-core-01 xml use Message-ID: <20040611201157.GH99040@Space.Net> References: <700EEF5641B7E247AC1C9B82C05D125DA8C1@srv1.pan-am.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125DA8C1@srv1.pan-am.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 Fri, Jun 11, 2004 at 02:39:49PM -0500, Gordon Fecyk wrote: > No one's brought up RFC 1464 yet, which describes how to store unique and > arbitrary information in TXT records in DNS. SPF does this, DMP does this. > It avoids the TXT record collision problem by describing a unique attribute > name along with a value for the attribute. We used it for an early draft of MTAMARK (MTA=yes and MTA=no) and gave up on it (after some helpful discussion with Arnt Gulbrandsen): ------------------------------------------------------------------------ Storing arbitrary string attributes in the Domain Name System [RFC1464] is a technique described and used at least since 1993. One solution that we took into consideration has been to store string attributes like "MTA=1" or "MTA=0" at the same level as PTR records. However this method does not support specific queries and has a high overhead for parsing the responses, is prone to naming collisions and will trigger errors and problems in old implementations of DNS servers with the 512 byte size limit. ------------------------------------------------------------------------ With the above you would ask "gimme all your TXT records" and choose which one suits you. Asking for e.g. _marid.example.org is an exact and specific question with (if configured correctly) exactly one answer. \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@mail.imc.org Fri Jun 11 16:40:09 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02891 for ; Fri, 11 Jun 2004 16:40:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BKTI2R075212; Fri, 11 Jun 2004 13:29:18 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5BKTIgB075211; Fri, 11 Jun 2004 13:29:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BKTIog075194 for ; Fri, 11 Jun 2004 13:29:18 -0700 (PDT) (envelope-from michel@arneill-py.sacramento.ca.us) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [RFC 1464?] RE: Alternative to TXT or new RR was: Comments ondraft-ietf-marid-core-01 xml use Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 11 Jun 2004 13:29:17 -0700 Message-ID: Thread-Topic: [RFC 1464?] RE: Alternative to TXT or new RR was: Comments ondraft-ietf-marid-core-01 xml use Thread-Index: AcRP6VI7X9qt0O4UStOr3OmOgQIEigAAhTlwAAFGAVA= From: "Michel Py" To: "Gordon Fecyk" , "MARID" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5BKTIog075205 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > Gordon Fecyk wrote: > No one's brought up RFC 1464 yet, which describes how to store > unique and arbitrary information in TXT records in DNS. SPF does > this, DMP does this. It avoids the TXT record collision problem > by describing a unique attribute name along with a value for the > attribute. I don't think that's the main concern. I believe that the issue is that there is no way to request 'all TXT records which attribute equals "v" and value begins with "spf1"'. Unless I missed something the way to check for specific records is to query for all TXT records then parse which ones are relevant, which is sub-optimal. I could live with it, but apparently many people can't. > How does ISC dhcpd store its host information in the TXT > records? And how does it tell the difference between > its own records and something else's? Doesn't it use a > token like RFC 3309 or an attribute format like RFC 1464? That would be interesting to know indeed. Michel. From owner-ietf-mxcomp@mail.imc.org Fri Jun 11 16:42:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03085 for ; Fri, 11 Jun 2004 16:42:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BKWKjd075450; Fri, 11 Jun 2004 13:32:20 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5BKWKBa075449; Fri, 11 Jun 2004 13:32:20 -0700 (PDT) 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.9) with ESMTP id i5BKWJoc075443 for ; Fri, 11 Jun 2004 13:32:19 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i5BKWO8S005198; Fri, 11 Jun 2004 13:32:24 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Fri, 11 Jun 2004 13:32:24 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'IETF MARID WG'" , "'IETF MARID WG'" Subject: Re: MTAmark (was: Reality check please) Date: Fri, 11 Jun 2004 13:32:23 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Well as someone will undoubtedly point out according to the theory the list is what counts. I don't think we should move on mta mark type ideas at this point, if we do we should be looking at something more general than just spam. But it is certainly useful to ask what a marid style mta mark proposal would lok like. It helps validate the marid design if it is extensible to cover here as well. -----Original Message----- From: wayne [mailto:wayne@midwestcs.com] Sent: Fri Jun 11 11:26:44 2004 To: IETF MARID WG Subject: Re: MTAmark (was: Reality check please) In <20040611172844.GB32187@Space.Net> Markus Stumpf writes: > On Thu, Jun 10, 2004 at 09:21:07PM -0700, Hallam-Baker, Phillip wrote: >> I am unable to support MTAMARK because [...] > > MTAMARK suggests adding [...] You guys are raising good and interesting points about both the pros and cons of things like MTAMARK, but this is all irrelevant. Since the interim meeting, all 2821 proposals are now out of scope. The suggestion of pursing both 2822 and 2821 proposals was also rejected, one reason cited was 2821 discussions would cause too much traffic on this mailing list. I don't think Markus was at the meeting, but PHB was, so I'm surprised he is posting this out of scope stuff. -wayne From owner-ietf-mxcomp@mail.imc.org Fri Jun 11 16:48:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04342 for ; Fri, 11 Jun 2004 16:48:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BKbpqJ075952; Fri, 11 Jun 2004 13:37:51 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5BKbpkv075951; Fri, 11 Jun 2004 13:37:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BKbpAq075935 for ; Fri, 11 Jun 2004 13:37:51 -0700 (PDT) (envelope-from michel@arneill-py.sacramento.ca.us) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Alternative to TXT or new RR was: Comments on draft-ietf-marid-core-01 xml use Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 11 Jun 2004 13:37:48 -0700 Message-ID: Thread-Topic: Alternative to TXT or new RR was: Comments on draft-ietf-marid-core-01 xml use Thread-Index: AcRP7jz+rBaoG05JT4arJnGHMSVajQABSf5w From: "Michel Py" To: "Markus Stumpf" , "MARID" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5BKbpAq075946 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit >>> Edward Lewis wrote: >>> The TXT RR is used by ISC's dhcpd to record client >>> identities in DNS. I haven't been able to track >>> this back to any DHCP specification. >> Michel Py wrote: >> Is TXT RR the one for the domain itself or is there >> one per host? If the later, I don't see any conflict. >> Could you post an example? > Markus Stumpf wrote: > A receiving MTA cannot find out whether the RHS side > of the @ in an email address is a host or a (sub-)domain. > Just think > arneill-py.sacramento.ca.us > sacramento.ca.us > ca.us You lost me. What is the relation with ISC's dhcpd? Besides, why does it matter? Michel. From owner-ietf-mxcomp@mail.imc.org Fri Jun 11 16:51:09 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04454 for ; Fri, 11 Jun 2004 16:51:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BKdh37076111; Fri, 11 Jun 2004 13:39:43 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5BKdh3r076110; Fri, 11 Jun 2004 13:39:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BKdgZu076104 for ; Fri, 11 Jun 2004 13:39:42 -0700 (PDT) (envelope-from edlewis@arin.net) Received: by smtp2.arin.net (Postfix, from userid 5003) id 870AA19B8E5; Fri, 11 Jun 2004 16:39:34 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id DAD5F19B8E3; Fri, 11 Jun 2004 16:39:33 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.136.136.83]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1761122; Fri, 11 Jun 2004 16:39:46 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Fri, 11 Jun 2004 16:27:20 -0400 To: "Michel Py" From: Edward Lewis Subject: RE: Alternative to TXT or new RR was: Comments on draft-ietf-marid-core-01 xml use Cc: "Edward Lewis" , "MARID" Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63-arin1 (2004-01-11) on smtp2.arin.net X-Spam-Status: No, hits=-8.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63-arin1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5BKdhZu076105 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit At 12:18 -0700 6/11/04, Michel Py wrote: >> Edward Lewis >> The TXT RR is used by ISC's dhcpd to record client >> identities in DNS. I haven't been able to track >> this back to any DHCP specification. > >Is TXT RR the one for the domain itself or is there one per host? If the >later, I don't see any conflict. Could you post an example? This is from the dhcpd.leases man file: # The ddns-text variable # # The ddns-text variable is used to record the value of the client's TXT # identification record when the interim ddns update style has been used to # update the DNS for a particular lease.  (I found a copy of it at http://linux.com.hk/PenguinWeb/manpage.jsp?section=5&name=dhcpd.leases) This was from a message in an archive somewhere: (http://www.seattlewireless.net/pipermail/dev/2001-November/004968.html) # A note about using TXT records and dhcpd servers (in this case # ISC dhcpd 3.0): # When the DHCP server issues a client a new lease, it cre- # ates a text string that is an MD5 hash over the DHCP # client's identification (see draft-ietf-dnsext-dhcid- # rr-??.txt for details). The update adds an A record with # the name the server chose and a TXT record containing the # hashed identifier string (hashid). If this update suc- # ceeds, the server is done. # # # Sure enough, when running in ddns-update-style interim these records # are added: # # nitrous TXT "313fe40368e0c95848c336d33f7dd03bc7" # A 10.100.3.252 -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Even the voices inside my head are refusing to talk to me anymore. From owner-ietf-mxcomp@mail.imc.org Fri Jun 11 17:03:57 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04888 for ; Fri, 11 Jun 2004 17:03:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BKq1UC077352; Fri, 11 Jun 2004 13:52:01 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5BKq1HX077351; Fri, 11 Jun 2004 13:52:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BKq1sH077341 for ; Fri, 11 Jun 2004 13:52:01 -0700 (PDT) (envelope-from michel@arneill-py.sacramento.ca.us) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Alternative to TXT or new RR was: Comments on draft-ietf-marid-core-01 xml use Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 11 Jun 2004 13:52:00 -0700 Message-ID: Thread-Topic: Alternative to TXT or new RR was: Comments on draft-ietf-marid-core-01 xml use Thread-Index: AcRP3ywLlZPx6sJMSCWQRPtx8zVT1gAFpvhw From: "Michel Py" To: "Edward Lewis" Cc: "MARID" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5BKq1sH077346 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > Edward Lewis wrote: > The TXT RR is used by ISC's dhcpd to record client > identities in DNS. I haven't been able to track this > back to any DHCP specification. On a per-host (vs. per-domain) basis, it appears. I'm sorry, but I fail to see your point here? Michel. From owner-ietf-mxcomp@mail.imc.org Fri Jun 11 17:04:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04906 for ; Fri, 11 Jun 2004 17:03:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BKrLSe077508; Fri, 11 Jun 2004 13:53:21 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5BKrLA4077507; Fri, 11 Jun 2004 13:53:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BKrL3W077500 for ; Fri, 11 Jun 2004 13:53:21 -0700 (PDT) (envelope-from edlewis@arin.net) Received: by smtp2.arin.net (Postfix, from userid 5003) id DF97419B5B2; Fri, 11 Jun 2004 16:53:12 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 6927519B483; Fri, 11 Jun 2004 16:53:12 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.136.136.83]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1761174; Fri, 11 Jun 2004 16:53:25 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Fri, 11 Jun 2004 16:51:50 -0400 To: "Michel Py" From: Edward Lewis Subject: RE: Alternative to TXT or new RR was: Comments on draft-ietf-marid-core-01 xml use Cc: "Markus Stumpf" , "MARID" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63-arin1 (2004-01-11) on smtp2.arin.net X-Spam-Status: No, hits=-8.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63-arin1 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 13:37 -0700 6/11/04, Michel Py wrote: > >You lost me. What is the relation with ISC's dhcpd? >Besides, why does it matter? The point was that MARID can't claim the TXT record as it's own. At 23:15 -0700 6/10/04, Michel Py wrote: >II. At the same time, we obsolete the RFCs describing the >TXT RR and replace them with new text that says: > > i) The TXT RR is now reserved for SPFID and you can't put > anything you want in it anymore; anything that would go > into the TXT record needs to be cleared by MARID first. ISC's DHCP implementation is one thing that uses the TXT RR (and as far as I know, not spec'd by a std). I know of other experimental uses of the TXT RR, for one, opportunistic encryption. There is an RFC in preparation to document that. So, MARID can't claim the TXT for it's own - others already use it. And the fact that one of these of the TXT RR is spec'd in any IETF document (so far as I have been able to tell), reliance on TXT in a proposed standard chancy - in my opinion. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Even the voices inside my head are refusing to talk to me anymore. From owner-ietf-mxcomp@mail.imc.org Fri Jun 11 17:07:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05277 for ; Fri, 11 Jun 2004 17:07:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BKsClP077570; Fri, 11 Jun 2004 13:54:12 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5BKsCPT077569; Fri, 11 Jun 2004 13:54:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BKsCHJ077562 for ; Fri, 11 Jun 2004 13:54:12 -0700 (PDT) (envelope-from edlewis@arin.net) Received: by smtp2.arin.net (Postfix, from userid 5003) id 0D20919B5AD; Fri, 11 Jun 2004 16:54:04 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 9C14C19B483; Fri, 11 Jun 2004 16:54:03 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.136.136.83]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1761175; Fri, 11 Jun 2004 16:54:16 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Fri, 11 Jun 2004 16:54:19 -0400 To: "Michel Py" From: Edward Lewis Subject: RE: Alternative to TXT or new RR was: Comments on draft-ietf-marid-core-01 xml use Cc: "Edward Lewis" , "MARID" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63-arin1 (2004-01-11) on smtp2.arin.net X-Spam-Status: No, hits=-8.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63-arin1 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 13:52 -0700 6/11/04, Michel Py wrote: >On a per-host (vs. per-domain) basis, it appears. I'm sorry, but I fail >to see your point here? My point was that MARID can't rule out others from using the TXT. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Even the voices inside my head are refusing to talk to me anymore. From owner-ietf-mxcomp@mail.imc.org Fri Jun 11 17:34:12 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06814 for ; Fri, 11 Jun 2004 17:34:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BLOpWs080778; Fri, 11 Jun 2004 14:24:51 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5BLOpnM080777; Fri, 11 Jun 2004 14:24:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BLOo6D080760 for ; Fri, 11 Jun 2004 14:24:50 -0700 (PDT) (envelope-from michel@arneill-py.sacramento.ca.us) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Alternative to TXT or new RR was: Comments on draft-ietf-marid-core-01 xml use Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 11 Jun 2004 14:24:50 -0700 Message-ID: Thread-Topic: Alternative to TXT or new RR was: Comments on draft-ietf-marid-core-01 xml use Thread-Index: AcRP9iSUpg1dqEzKQXyKjLGMxlrNDAAAi5vw From: "Michel Py" To: "Edward Lewis" Cc: "MARID" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5BLOp6D080772 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > Edward Lewis wrote: > ISC's DHCP implementation is one thing that uses the > TXT RR (and as far as I know, not spec'd by a std). As it appears their implementation is not compliant with RFC1464 (I did not see any attributes nor equal sign), I would say it's ISC's problem. > I know of other experimental uses of the TXT RR, for one, > opportunistic encryption. There is an RFC in preparation to > document that. So, MARID can't claim the TXT for it's own > - others already use it. If they are using a well-known set of attributes, I don't see why. Part of the spec could be acknowledging the other attributes already in use. > And the fact that one of these of the TXT RR is spec'd > in any IETF document (so far as I have been able to tell), > reliance on TXT in a proposed standard chancy - in my opinion. I'm with you here. However, if who uses what (as far as attributes are concerned) is documented, this might change. My original text was: > i) The TXT RR is now reserved for SPFID and you can't put > anything you want in it anymore; anything that would go > into the TXT record needs to be cleared by MARID first. This is too strong; what I meant is that we should have a list of known attributes for the TXT record. Anyone wanting to use an attribute should register it. Would this make the TXT record palatable for PS if attributes were reserved for SPFID? Michel. From owner-ietf-mxcomp@mail.imc.org Fri Jun 11 18:00:48 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09526 for ; Fri, 11 Jun 2004 18:00:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BLqfRp083503; Fri, 11 Jun 2004 14:52:41 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5BLqfcL083502; Fri, 11 Jun 2004 14:52:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BLqfkt083493 for ; Fri, 11 Jun 2004 14:52:41 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.131.244.249] ([::ffff:216.168.239.87]) (AUTH: LOGIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Fri, 11 Jun 2004 17:52:44 -0400 id 0007BE0E.40CA29AC.00005F25 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "Edward Lewis" , "MARID" From: Andrew Newton Subject: Re: Alternative to TXT or new RR was: Comments on draft-ietf-marid-core-01 xml use Date: Fri, 11 Jun 2004 17:52:41 -0400 To: "Michel Py" X-Mailer: Apple Mail (2.613) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jun 11, 2004, at 5:24 PM, Michel Py wrote: > > As it appears their implementation is not compliant with RFC1464 (I did > not see any attributes nor equal sign), I would say it's ISC's problem. RFC 1464 clearly says "Experimental". TXT is defined RFC 1035 (or so says RFC 1464). -andy From owner-ietf-mxcomp@mail.imc.org Fri Jun 11 18:03:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09737 for ; Fri, 11 Jun 2004 18:03:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BLvoIO084055; Fri, 11 Jun 2004 14:57:50 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5BLvoJo084054; Fri, 11 Jun 2004 14:57:50 -0700 (PDT) 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.9) with SMTP id i5BLvmlT084041 for ; Fri, 11 Jun 2004 14:57:49 -0700 (PDT) (envelope-from maex@Space.Net) Received: (qmail 43276 invoked by uid 1013); 11 Jun 2004 21:57:53 -0000 Date: Fri, 11 Jun 2004 23:57:53 +0200 From: Markus Stumpf To: MARID Subject: Re: Alternative to TXT or new RR was: Comments on draft-ietf-marid-core-01 xml use Message-ID: <20040611215753.GB77339@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 Fri, Jun 11, 2004 at 02:24:50PM -0700, Michel Py wrote: > As it appears their implementation is not compliant with RFC1464 (I did > not see any attributes nor equal sign), I would say it's ISC's problem. ------------------------------------------------------------------------ Status of this Memo This memo defines an Experimental Protocol for the Internet community. Discussion and suggestions for improvement are requested. ------------------------------------------------------------------------ This paper describes a simple means to associate arbitrary string information (ASCII text) with attributes that have not been defined by the DNS. It uses DNS TXT resource records to store the information. It requires no change to current DNS implementations. ------------------------------------------------------------------------ Nowhere in that document is anything that tell me I am REQUIRED to use key=value pairs for TXT records. > If they are using a well-known set of attributes There is no such thing as that as there is no registry. > This is too strong; what I meant is that we should have a list of known > attributes for the TXT record. Anyone wanting to use an attribute should > register it. Would this make the TXT record palatable for PS if > attributes were reserved for SPFID? Believe me, you don't want to do a query for all TXT records of a entity and then parse the 750 records and select the one that fits. And with TXT records it's either all or nothing, just with any other RR type, too. I really don't see the problem querying for ( _marid.example.com. , TXT ) ( _marid._smtp._tcp._srv.example.com. , TXT ) And all those records have to exists for every host that is using its name in an email address. So if you webserver is sending via script as webmaster@www.example.com, www.example.com has to carry the records and if your mailserver is sending bounces as postmaster@mail.example.com mail.example.com has to carry the records, ... Ok, I see a lot of problems, but that is another thread. \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@mail.imc.org Fri Jun 11 18:10:05 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10736 for ; Fri, 11 Jun 2004 18:10:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BM5EnX084645; Fri, 11 Jun 2004 15:05:14 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5BM5Ewd084644; Fri, 11 Jun 2004 15:05:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from republico.estv.ipv.pt (tunadao.ipv.pt [193.137.7.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BM5C4R084630 for ; Fri, 11 Jun 2004 15:05:13 -0700 (PDT) (envelope-from lbruno@republico.estv.ipv.pt) Received: from lbruno by republico.estv.ipv.pt with local (Exim 4.22) id 1BYuAA-00030Y-9e for ietf-mxcomp@imc.org; Fri, 11 Jun 2004 23:06:14 +0100 Date: Fri, 11 Jun 2004 23:06:14 +0100 From: Luis Bruno To: ietf-mxcomp@imc.org Subject: Re: suggested path and arch Message-ID: <20040611220614.GB11080@republico.estv.ipv.pt> Mail-Followup-To: ietf-mxcomp@imc.org References: <7BD19F59D0DA4C448B0C4BBE78C35BE3136219@DF-SEADOG-MSG.exchange.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7BD19F59D0DA4C448B0C4BBE78C35BE3136219@DF-SEADOG-MSG.exchange.corp.microsoft.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Bob Atkinson wrote: > TXT is not a prototyping notion here; it's the mainstream deployment > option. [...] there's no point to a dedicated RR type > > You've missed the arguments Maybe I'm being overly dense, but I've been diving into the archives and I may have missed the arguments too. You and Jim Lyon have justified the need for a temporary representation in TXT; please correct me if I'm wrong. Cheers, -- Luis Bruno UTM: 29T 629481E 4511776N 576m From owner-ietf-mxcomp@mail.imc.org Fri Jun 11 19:13:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13719 for ; Fri, 11 Jun 2004 19:13:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BN47KU090307; Fri, 11 Jun 2004 16:04:07 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5BN47tj090306; Fri, 11 Jun 2004 16:04:07 -0700 (PDT) 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.9) with SMTP id i5BN46bi090298 for ; Fri, 11 Jun 2004 16:04:06 -0700 (PDT) (envelope-from maex@Space.Net) Received: (qmail 55465 invoked by uid 1013); 11 Jun 2004 23:04:11 -0000 Date: Sat, 12 Jun 2004 01:04:11 +0200 From: Markus Stumpf To: IETF MARID WG Subject: Re: MTAmark (was: Reality check please) Message-ID: <20040611230411.GC77339@Space.Net> References: <20040609215845.GO99969@Space.Net> <20040610150711.GA9692@zardoc.esmtp.org> <002101c44fa9$a7feaf90$6401a8c0@hdev1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002101c44fa9$a7feaf90$6401a8c0@hdev1> 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 Fri, Jun 11, 2004 at 07:42:38AM -0400, Hector Santos wrote: > Nevertheless, one common thing I see around here is this "BIG" vs. "SMALL" > thing, and I guess, the small end of the spectrum doesn't count as much for > MARID. I may be off based, but if this is true, this would be another > mistake in the making as the early wide spread adoption will come from the > larger pool of smaller systems. I believe SPF has shown this very clearly. > However, I will note that we jumped on board only when we saw AOL.COM, a > major source of spam, began to support it. I'd really like where all this urban legends come from. Isn't anybody on this list runing a mailserver of some size? Out of 500,000 messages with about 90% marked spam and viruses (this is 450,000 messages) I had 18164 hotmail.com (4.03%) 15013 yahoo.com (3.36%) 11620 web.de 10069 gmx.de 8671 AOL (1.92%) 8172 msn.com 2750 yahoo.de AOL supporting SPF didn't change anything, besides some media hype. Give me one site that really utilizes the client side of SPF? Serious business companies CANNOT do it, as it will raise their false positive rate and nobody will do that. The above domains account (+GMX.*) for about 15% of all messages (and quite some messages from GMX and WEB.DE are legal, as we are in DE). So the main question is: Why do spammers use hotmail, yahoo, AOL? Simple answer: you cannot block those domain totally, but if the domain is "lamer.de" you don't sleep bad at night blocking it. As soon as those "big" domains publish MARID records and the technique is well established, spammers will immediately switch and ONLY do what they already do now: abuse "small" domains. And these are easy to find, as they don't publish MARID records. 23410 unique domains only injected one message. 5635 injected 2 messages only about 15% of all messages already NOW account to "the big ones". So which problem are we trying to solve? \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@mail.imc.org Fri Jun 11 19:33:29 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14401 for ; Fri, 11 Jun 2004 19:33:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BNRAs9093041; Fri, 11 Jun 2004 16:27:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5BNRAOR093040; Fri, 11 Jun 2004 16:27:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ernie.mail-abuse.org (Ernie.mail-abuse.org [168.61.5.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BNR9MO093033 for ; Fri, 11 Jun 2004 16:27:09 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.mail-abuse.org (DDev.mail-abuse.org [168.61.10.124]) by ernie.mail-abuse.org (8.12.0.Beta19/8.12.0) with ESMTP id i5BNRAPQ054129; Fri, 11 Jun 2004 16:27:10 -0700 (PDT) Subject: Re: [RFC 1464?] RE: Alternative to TXT or new RR was: Comments ondraft-ietf-marid-core-01 xml use From: Douglas Otis To: Gordon Fecyk Cc: MARID In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125DA8C1@srv1.pan-am.ca> References: <700EEF5641B7E247AC1C9B82C05D125DA8C1@srv1.pan-am.ca> Content-Type: text/plain Message-Id: <1086996430.20584.50.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 11 Jun 2004 16:27:10 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2004-06-11 at 12:39, Gordon Fecyk wrote: > > There is an alternative to a hostile take-over of the TXT record as I > > mentioned. > > > > Use a token such as "MARID-1" and follow this with a CRC-32c checksum > > (good Hamming distance and code used in SCTP) of the entire > > record where > > the checksum field is treated as zero. Such as "MARID-1[FD034A45]..." > > or perhaps "FD034A45_MARID-1...". See RFC3309 for an example > > of language and code. > > No one's brought up RFC 1464 yet, which describes how to store unique and > arbitrary information in TXT records in DNS. SPF does this, DMP does this. > It avoids the TXT record collision problem by describing a unique attribute > name along with a value for the attribute. > > How does ISC dhcpd store its host information in the TXT records? And how > does it tell the difference between its own records and something else's? > Doesn't it use a token like RFC 3309 or an attribute format like RFC 1464? There are few problems depending upon RFC1464. Over the following decade, it never established a token registry as it claims is needed before this scheme is usable. It also assumes a simple format offers protection from otherwise arbitrary text. It is also experimental and never adopted as a standard. The concern is with the possibility of those using an asterisk in what would be defined as a unique label in 'fubar' standard to identify the TXT record placed as if a sub-domain. The publisher's motivation would be to allow this TXT record to cover many sub-domains. There needs to be a safe method of being able to identify compliance with a format from standard 'fubar' and standard 'snafu'. The 16 byte overhead as with the example token and checksum field will provide assurance there was not a mistake made even if there are random character generators creating text strings. An assumption a label can be used to isolate TXT records seems fatal. Just as with RFC1464, a registry must be created for the tokens. -Doug From owner-ietf-mxcomp@mail.imc.org Fri Jun 11 19:37:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14488 for ; Fri, 11 Jun 2004 19:37:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BNTqtP093358; Fri, 11 Jun 2004 16:29:52 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5BNTqT8093357; Fri, 11 Jun 2004 16:29:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BNTUQW093320 for ; Fri, 11 Jun 2004 16:29:50 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i5BNRXKC031903; Fri, 11 Jun 2004 16:27:33 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i5BNRXHf031900; Fri, 11 Jun 2004 16:27:33 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Fri, 11 Jun 2004 16:27:33 -0700 (PDT) From: "william(at)elan.net" To: "Hallam-Baker, Phillip" cc: "'IETF MARID WG'" Subject: Re: MTAmark (was: Reality check please) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On the other hand while the current primary work is on SPF+CallerID, that does not mean the group can not work on other DNS+email authorization ideas now or in the future. MTAMark should remain as one of the topics for current and future discussions of this WG. But just not something that we should work very hard to get done by next next IETF (and at that time it would be good to reexamine our timeline to see whats next). On Fri, 11 Jun 2004, Hallam-Baker, Phillip wrote: > > Well as someone will undoubtedly point out according to the theory the list > is what counts. > > I don't think we should move on mta mark type ideas at this point, if we do > we should be looking at something more general than just spam. > > But it is certainly useful to ask what a marid style mta mark proposal would > lok like. It helps validate the marid design if it is extensible to cover > here as well. > > > -----Original Message----- > From: wayne [mailto:wayne@midwestcs.com] > Sent: Fri Jun 11 11:26:44 2004 > To: IETF MARID WG > Subject: Re: MTAmark (was: Reality check please) > > > In <20040611172844.GB32187@Space.Net> Markus Stumpf > writes: > > > On Thu, Jun 10, 2004 at 09:21:07PM -0700, Hallam-Baker, Phillip wrote: > >> I am unable to support MTAMARK because [...] > > > > MTAMARK suggests adding [...] > > You guys are raising good and interesting points about both the pros > and cons of things like MTAMARK, but this is all irrelevant. Since > the interim meeting, all 2821 proposals are now out of scope. The > suggestion of pursing both 2822 and 2821 proposals was also rejected, > one reason cited was 2821 discussions would cause too much traffic on > this mailing list. > > I don't think Markus was at the meeting, but PHB was, so I'm surprised > he is posting this out of scope stuff. > > > -wayne From owner-ietf-mxcomp@mail.imc.org Fri Jun 11 19:55:49 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15225 for ; Fri, 11 Jun 2004 19:55:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BNm58V094878; Fri, 11 Jun 2004 16:48:05 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5BNm5WW094877; Fri, 11 Jun 2004 16:48:05 -0700 (PDT) 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.9) with ESMTP id i5BNm44g094870 for ; Fri, 11 Jun 2004 16:48:04 -0700 (PDT) (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.34) id 1BYvke-0007zu-TH for ietf-mxcomp@imc.org; Fri, 11 Jun 2004 18:48:09 -0500 To: "IETF MARID WG" References: From: wayne Reply-To: "IETF MARID WG" Date: Fri, 11 Jun 2004 18:48:00 -0500 In-Reply-To: (Edward Lewis's message of "Fri, 11 Jun 2004 16:51:50 -0400") 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 (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: Alternative to TXT or new RR Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-4.4 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In Edward Lewis writes: > At 23:15 -0700 6/10/04, Michel Py wrote: >>II. At the same time, we obsolete the RFCs describing the >>TXT RR and replace them with new text that says: >> >> i) The TXT RR is now reserved for SPFID and you can't put >> anything you want in it anymore; anything that would go >> into the TXT record needs to be cleared by MARID first. > > ISC's DHCP implementation is one thing that uses the TXT RR (and as > far as I know, not spec'd by a std). I know of other experimental > uses of the TXT RR, for one, opportunistic encryption. There is an > RFC in preparation to document that. > > So, MARID can't claim the TXT for it's own - others already use it. > > And the fact that one of these of the TXT RR is spec'd in any IETF > document (so far as I have been able to tell), reliance on TXT in a > proposed standard chancy - in my opinion. I agree, MARID can't claim the TXT RR for it's own. Not only do others already use it, but there will be new uses for it in the future. I think that if MARID uses the TXT record, it must "play fair" by keeping the records as short as possible, making them distinctive, and placing in parts of the DNS tree that don't cause conflicts. I have mentioned several times that before the interim meeting, I did a scan of 1.3 million email domains (e.g. places that would likely be checked for SPF records). I found that the usage of TXT records isn't that high, almost all domains have enough space left in the 512B UDP DNS packet that you can add SPF records without problems. Of the dozen or so domains that would need TCP, half are already over the limit. Ed mentioned two different examples of existing usage. In the survey, I found 13 examples of the ISC DHCP records. These records are short and distinctive, so I think they play fair with the limited TXT resources. I found 8 examples of what I would guess are the opportunistic encryption. Those records are so long that, hmmm, I guess they account for most of the domains that can't add SPF records without going to TCP. Those records are distinctive, but are way too long. They certainly need their own RR type, and may need to be shorten up even then. For those who are interested in lightly cooked data, you can download a list of all the text records that I found at: http://www.midwestcs.com/dns_txt_rr.text Note that some domains had many records, and each of these are listed once. I have also collapsed similar records and the leading number is the count of those records. For example, all valid SPF records are collapsed into one line, even though there are many different variations. This will give you a good idea of what is out there that SPF records will have to co-exist with. -wayne From owner-ietf-mxcomp@mail.imc.org Fri Jun 11 20:03:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15556 for ; Fri, 11 Jun 2004 20:03:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BNtuAk095549; Fri, 11 Jun 2004 16:55:56 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5BNtuaJ095548; Fri, 11 Jun 2004 16:55:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BNttq2095542 for ; Fri, 11 Jun 2004 16:55:55 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i5BNrxdN032575; Fri, 11 Jun 2004 16:53:59 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i5BNrwC6032572; Fri, 11 Jun 2004 16:53:58 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Fri, 11 Jun 2004 16:53:58 -0700 (PDT) From: "william(at)elan.net" To: Michel Py cc: MARID Subject: RE: Alternative to TXT or new RR was: Comments on draft-ietf-marid-core-01 xml use In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 11 Jun 2004, Michel Py wrote: > > william(at)elan.net wrote: > > [..] I was joking because while this may seem like a way out, > > in no way do I think it should be done or that it'll ever fly > > by IETF top guys. We should never attempt to completely take > > over somebody else record, that is a very bad precident for IETF. > > Then, which one out of the three alternatives I posted yesterday would > you recommend (or add your own)? > > 1. We do it quick and dirty with TXT. > 2. We do it right and slow with a new RR type. > 3. We say that we'll go with 1 as a temporary > measure and with 2 in the long run. I'd prefer #2 actually. I think it would not be as slow as you predict because greater majority of mail operators are not using microsoft os (> 80%) and will be able to use new MARID record type quite quickly. Having situations that unix folks are able to do it while microsoft can not will put greater pressure on microsoft (plus their charimans's comments that spam problem would be "solved" by 2006) and might even cause to have patch for dns resolver & dns server released before next OS. That said I'd be ok with option #3. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Fri Jun 11 20:47:28 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17417 for ; Fri, 11 Jun 2004 20:47:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5C0d7i4000145; Fri, 11 Jun 2004 17:39:07 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5C0d7Rs000144; Fri, 11 Jun 2004 17:39:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from xuxa.iecc.com (xuxa.iecc.com [208.31.42.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5C0d4Gm000126 for ; Fri, 11 Jun 2004 17:39:04 -0700 (PDT) (envelope-from johnl@iecc.com) Received: (qmail 29764 invoked by uid 100); 12 Jun 2004 00:39:09 -0000 Date: 12 Jun 2004 00:39:09 -0000 Message-ID: <20040612003909.29763.qmail@xuxa.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: Re: suggested path and arch In-Reply-To: Organization: I.E.C.C., Trumansburg NY USA Cc: edlewis@arin.net Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >I can't find an answer to "couldn't a client program just do the >lookup itself, if the OS didn't support the new type?" For clients that can exchange UDP packets with the Internet, either directly or through a DNS cache, almost certainly yes. For clients behind RPC-speaking firewalls, nope. A closely related question that I haven't seen addressed is how hard it would be to provide a new specialized MARID RPC service to run on the firewall for the benefit of MARID clients that are in RPC jail. From owner-ietf-mxcomp@mail.imc.org Fri Jun 11 21:06:29 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17988 for ; Fri, 11 Jun 2004 21:06:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5C0xbTj002617; Fri, 11 Jun 2004 17:59:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5C0xb9G002616; Fri, 11 Jun 2004 17:59:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5C0xbCF002610 for ; Fri, 11 Jun 2004 17:59:37 -0700 (PDT) (envelope-from bobatk@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 11 Jun 2004 17:59:42 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 11 Jun 2004 17:59:42 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 11 Jun 2004 17:59:44 -0700 Received: from DF-SEADOG-MSG.exchange.corp.microsoft.com ([157.54.6.247]) by df-fido-msg.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 11 Jun 2004 17:59:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Alternative to TXT or new RR Date: Fri, 11 Jun 2004 18:03:38 -0700 Message-ID: <7BD19F59D0DA4C448B0C4BBE78C35BE3136764@DF-SEADOG-MSG.exchange.corp.microsoft.com> Thread-Topic: Alternative to TXT or new RR Thread-Index: AcRQDxRzNd8sxIAHQ7mHLhpTgeTlrgACePtg From: "Bob Atkinson" To: "IETF MARID WG" X-OriginalArrivalTime: 12 Jun 2004 00:59:39.0296 (UTC) FILETIME=[89B47A00:01C45018] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5C0xbCF002611 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > I agree, MARID can't claim the TXT RR for it's own. Let's be clear; this is NOT the plan of record in the current draft. Rather, MARID is claiming the COMBINATION of a particular domain prefix and TXT as it's own. Bob From owner-ietf-mxcomp@mail.imc.org Fri Jun 11 23:31:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22536 for ; Fri, 11 Jun 2004 23:31:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5C3HpuJ014471; Fri, 11 Jun 2004 20:17:51 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5C3HpWm014470; Fri, 11 Jun 2004 20:17:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from miz-mishtal.dbc.mtview.ca.us (adsl-64-168-10-250.dsl.scrm01.pacbell.net [64.168.10.250]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5C3HoDi014463 for ; Fri, 11 Jun 2004 20:17:50 -0700 (PDT) (envelope-from mrose@dbc.mtview.ca.us) Received: from [IPv6:::1] (localhost [127.0.0.1]) by miz-mishtal.dbc.mtview.ca.us (8.12.10/8.12.9) with ESMTP id i5C38kjG017256; Fri, 11 Jun 2004 20:08:46 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marshall Rose Subject: Re: MARID charter and using 2822 data Date: Fri, 11 Jun 2004 20:08:46 -0700 To: "IETF MARID WG" X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit apologies for the lateness in this reply. i sent a reply yesterday, but it seems to have gotten trapped somewhere. i don't think there is anything in the text you cite that prevents the wg from considering 2822 as a part of the solution. like it or not MTAs know about 2822 content. in the simplest example of this, consider the Received: header. /mtr On Jun 10, 2004, at 20:09, wayne wrote: > Yah know, I was poking around the MARID stuff and I re-read the > official MARID charter (see > > > In particular, I remembered this: > > [...] the > first task of the working group will be to establish which of > these identities should be associated with MTA > authorization. Once this decision has been reached, it will > limit the scope of further activity in this working group, and > the chairs will rule out of order discussion related to schemes > which use other identities as the basis of authorization. > > I also thought that all decisions made in meetings must be confirmed > on the mailing list. > > > Now, earlier there was a decision made to go with the 2821 > identities. At the interim meeting, we suddenly changed to 2822 > identities with a simple hum. Is it really possible to violate the > written charter with a single hum, late on the final day and not have > this change confirmed on the mailing list? From owner-ietf-mxcomp@mail.imc.org Sat Jun 12 03:12:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15818 for ; Sat, 12 Jun 2004 03:11:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5C6xqFQ083748; Fri, 11 Jun 2004 23:59:52 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5C6xq6I083747; Fri, 11 Jun 2004 23:59:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (mail.winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5C6xn9s083721 for ; Fri, 11 Jun 2004 23:59:49 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Sat, 12 Jun 2004 03:03:20 -0400 Received: from ([66.156.222.143]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 834448063; Sat, 12 Jun 2004 03:03:19 -0400 Message-ID: <004101c4504b$d24a7200$6401a8c0@hdev1> From: "Hector Santos" To: "Markus Stumpf" , "IETF MARID WG" References: <20040609215845.GO99969@Space.Net> <20040610150711.GA9692@zardoc.esmtp.org> <002101c44fa9$a7feaf90$6401a8c0@hdev1> <20040611230411.GC77339@Space.Net> Subject: Re: MTAmark (was: Reality check please) Date: Sat, 12 Jun 2004 03:06:39 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.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: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Markus Stumpf" To: "IETF MARID WG" Sent: Friday, June 11, 2004 7:04 PM Subject: Re: MTAmark (was: Reality check please) > Out of 500,000 messages with about 90% marked spam and viruses (this is > 450,000 messages) The rate is on par with industry average. > AOL supporting SPF didn't change anything, besides some media hype. It did for us. > Give me one site that really utilizes the client side of SPF? Not sure what this question ask. > Serious business companies CANNOT do it, as it will raise their false positive > rate and nobody will do that. Whats the difference between a serious business and a just plain anyone else running a legitimate mail server servicing end-users, internal or otherwise? > So the main question is: Why do spammers use hotmail, yahoo, AOL? > Simple answer: you cannot block those domain totally, For hotmail, MCEP works. For yahoo, you have a problem as they go agains the grain of standard operations contributing to the spamming problem. For AOL, they are the best of the "large ISP" bunch. Explain more below. > As soon as those "big" domains publish MARID records and the > technique is well established, spammers will immediately switch > and ONLY do what they already do now: abuse "small" domains. And these > are easy to find, as they don't publish MARID records. Well, the harder (and complex) you make it publish, you will find a barrier to implementation. In my view, as soon as the "big" domains publish MARID records, they will spammers spoof them even more due to the "CodeRed Principle" that every modern virus/hacker and now spammer now enjoys, and that is there will always be a segment of market place that are still not updated with new anti-spam logic. > So which problem are we trying to solve? For me, the focus is on solving the "anonymous mail abuse" using SMTP technical compliancy with total disregard on the intent of the mail sender. Hotmail publishes a _EP record, so this has help stop some of its spam. But for our system, we use a CBV as the final analysis because in our view, ultimately, the complete address must be verifible. We use white/black listing, RBL and LMAP methods as initial checks with one goal in mind - eliminate the obvious and the need for the final CBV. AOL is the best of the bunch because they support dynamic SMTP Local User Validation. So the CBV works great in elimination all AOL spam that get pass the initial checks. YAHOO is problematic (doesn't help) because it validates ALL users. That is why you got more spammers using YAHOO. I forget, but HOTMAIL was also problematic, but not for the same reasons YAHOO was. Local User Validation is (should be) a important part of the anti-spam effort/design. Not only will it help eliminate the overhead in MARID lookup requirements but it will also reduce your bounce requirements which is a major part of the SORBIG-based virus dual-tier distribution logic. Just consider this: Connecting IP HELO MAIL FROM RCPT TO: If your RCPT TO is not valid, then you need not bother to check for MARID. Sure, probably deemed an implementation issue, but for me: anti-spam is directly proportional and a function of (IP, HELO, MAIL FROM, RCPT TO) to ignore RCPT TO, well, you are just adding a major burden to your system when the odds are very high the mail (about 40% bad RCPT) was going to be non-deliverable in the first place. Comment from customer: "Just wanted to tell you what a great job the WcSAP piece is! I had our network admin (From my work), help me set it up, and after about 30 minutes of learning/tweaking, it has been working great! Dozens of messages blocked, and no new virus warnings in the last hour. -He is a die-hard Linux freak and after he took a crack at studying the communications from multiple mail servers, log files, and my machine's logs, he was totally impressed how well it works. Our Linux mailservers use a similar type of verification, but he mentioned your version was very efficient in how it performed the verifications. That means alot to me since he hardly ever says anything positive about anything that runs on Windows. Great update! Thanks! -Chris Weis" -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Sat Jun 12 04:58:11 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19568 for ; Sat, 12 Jun 2004 04:58:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5C8np45028166; Sat, 12 Jun 2004 01:49:51 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5C8npKC028165; Sat, 12 Jun 2004 01:49:51 -0700 (PDT) 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.9) with ESMTP id i5C8noJn028141 for ; Sat, 12 Jun 2004 01:49:51 -0700 (PDT) (envelope-from cm--jrk@merseymail.com) Received: from mmail by argon.connect.org.uk with local (connectmail/exim) id 1BZ4Cy-0002O3-HW; Sat, 12 Jun 2004 09:49:48 +0100 In-Reply-To: <20040611230411.GC77339@Space.Net> Subject: Re: MTAmark (was: Reality check please) To: "Markus Stumpf" From: "Jon Kyme" Cc: ietf-mxcomp@imc.org X-Mailer: [ConnectMail 3.15.6] X-connectmail-Originating-IP: 82.69.7.27 Message-Id: Date: Sat, 12 Jun 2004 09:49:48 +0100 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > only about 15% of all messages already NOW account to "the big ones". > > So which problem are we trying to solve? > > \Maex There was a little discussion in a "measuring MARID" thread. It appears that around 4% of sending domains currently publish SPF. As you point out, "big domains" don't account for a large proportion of our messages. I suspect that much SPF evangelism is faith-based. From owner-ietf-mxcomp@mail.imc.org Sat Jun 12 10:38:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03859 for ; Sat, 12 Jun 2004 10:38:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5CEKIaW092521; Sat, 12 Jun 2004 07:20:18 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5CEKIKU092520; Sat, 12 Jun 2004 07:20:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from republico.estv.ipv.pt (republico.estv.ipv.pt [193.137.7.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5CEKC3W092486 for ; Sat, 12 Jun 2004 07:20:16 -0700 (PDT) (envelope-from lbruno@republico.estv.ipv.pt) Received: from lbruno by republico.estv.ipv.pt with local (Exim 4.22) id 1BZ9Na-0004Ie-OD for ietf-mxcomp@imc.org; Sat, 12 Jun 2004 15:21:06 +0100 Date: Sat, 12 Jun 2004 15:21:06 +0100 From: Luis Bruno To: IETF MARID WG Subject: Re: Towards resolution on Wildcards Message-ID: <20040612142106.GA16526@republico.estv.ipv.pt> Mail-Followup-To: IETF MARID WG References: <81AC085044D04B429F5FB883D94FA1AF3A1124@df-fido-msg.exchange.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF3A1124@df-fido-msg.exchange.corp.microsoft.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jim Lyon wrote: > The biggest problem is that if you publish a new record format, a > significant fraction of the people on the internet will not be able > to see it [...] ... for a while. Maybe I didn't express myself clearly: Should we use TXT as a stopgap while the new RR isn't deployed? That's the question I'd like to see answered; do you guys have any difficulties with that? It would mean extra traffic for DNS servers who don't support the new RR. On the receiving-MTA side, I don't see any problem with a second query; if I'm wrong, please correct me. I'd rather use a new RR for the final infrastructure and make it binary, since the RR is for machine consumption. -- Luis Bruno UTM: 29T 629481E 4511776N 576m From owner-ietf-mxcomp@mail.imc.org Sat Jun 12 14:17:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14620 for ; Sat, 12 Jun 2004 14:17:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5CHvm7K021794; Sat, 12 Jun 2004 10:57:48 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5CHvmHU021792; Sat, 12 Jun 2004 10:57:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (ntbbs.winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5CHvjs9021772 for ; Sat, 12 Jun 2004 10:57:47 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Sat, 12 Jun 2004 14:01:08 -0400 Received: from ([66.156.222.143]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 873915985; Sat, 12 Jun 2004 14:01:07 -0400 Message-ID: <001301c450a7$b87655e0$6401a8c0@hdev1> From: "Hector Santos" To: "william\(at\)elan.net" , "Michel Py" Cc: "MARID" References: Subject: Re: Alternative to TXT or new RR was: Comments on draft-ietf-marid-core-01 xml use Date: Sat, 12 Jun 2004 14:04:30 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.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: Content-Transfer-Encoding: 7bit My input on the issue of TXT vs. RR. When it comes to DNS, I am not enough of a cog to know the technical issues related to TXT vs. RR. However, from a developer standpoint, unless there will be some programmatic algorithm to automate the process of determining which is used to query a domain policy, there should be ONE record type, not two. Again, if there will be two, the logic needs to be in place to automatically determine what is to be use. The last thing you want is for a MARID client to be doing two or more different record lookups. Personally, I have trouble understanding why anyone would start a new design with a "kludge" concept. But again, I don't know why the TXT vs. RR is an issue. Maybe would be kind enough to sent me a personal message with the basic issue between the two. Finally, I hope I am not being redundant but I would like to point out again that the majority of the mail is spam and while MARID made help protect the spoofing of domains, most lookups will be failures (NXDOMAIN or none). This efficient issue should not be ignored. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com ----- Original Message ----- From: "william(at)elan.net" To: "Michel Py" Cc: "MARID" Sent: Friday, June 11, 2004 7:53 PM Subject: RE: Alternative to TXT or new RR was: Comments on draft-ietf-marid-core-01 xml use > > On Fri, 11 Jun 2004, Michel Py wrote: > > > > william(at)elan.net wrote: > > > [..] I was joking because while this may seem like a way out, > > > in no way do I think it should be done or that it'll ever fly > > > by IETF top guys. We should never attempt to completely take > > > over somebody else record, that is a very bad precident for IETF. > > > > Then, which one out of the three alternatives I posted yesterday would > > you recommend (or add your own)? > > > > 1. We do it quick and dirty with TXT. > > 2. We do it right and slow with a new RR type. > > 3. We say that we'll go with 1 as a temporary > > measure and with 2 in the long run. > > I'd prefer #2 actually. > I think it would not be as slow as you predict because greater majority > of mail operators are not using microsoft os (> 80%) and will be able to > use new MARID record type quite quickly. Having situations that unix folks > are able to do it while microsoft can not will put greater pressure on > microsoft (plus their charimans's comments that spam problem would be > "solved" by 2006) and might even cause to have patch for dns resolver & > dns server released before next OS. > > That said I'd be ok with option #3. > > -- > William Leibzon > Elan Networks > william@elan.net > > > From owner-ietf-mxcomp@mail.imc.org Sat Jun 12 14:46:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16780 for ; Sat, 12 Jun 2004 14:46:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5CIf5XR028239; Sat, 12 Jun 2004 11:41:05 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5CIf5nk028238; Sat, 12 Jun 2004 11:41:05 -0700 (PDT) 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.9) with SMTP id i5CIf3aZ028212 for ; Sat, 12 Jun 2004 11:41:04 -0700 (PDT) (envelope-from maex@Space.Net) Received: (qmail 67202 invoked by uid 1013); 12 Jun 2004 18:40:56 -0000 Date: Sat, 12 Jun 2004 20:40:56 +0200 From: Markus Stumpf To: Marshall Rose Cc: IETF MARID WG Subject: Re: MARID charter and using 2822 data Message-ID: <20040612184056.GA67169@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 Fri, Jun 11, 2004 at 08:08:46PM -0700, Marshall Rose wrote: > wg from considering 2822 as a part of the solution. like it or not MTAs > know about 2822 content. in the simplest example of this, consider the > Received: header. Exactly what in the process of adding a line (or two) at the beginning of the data stream from the network to disk makes you believe MTAs know about 2822 content? \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@mail.imc.org Sat Jun 12 16:00:44 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20550 for ; Sat, 12 Jun 2004 16:00:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5CJqKg3036673; Sat, 12 Jun 2004 12:52:20 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5CJqKIi036672; Sat, 12 Jun 2004 12:52:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [64.139.47.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5CJqJRW036665 for ; Sat, 12 Jun 2004 12:52:19 -0700 (PDT) (envelope-from gconnor@nekodojo.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by neko-base.nekodojo.org (Postfix) with ESMTP id 1815A1D651 for ; Sat, 12 Jun 2004 12:52:22 -0700 (PDT) Date: Sat, 12 Jun 2004 12:52:20 -0700 From: Greg Connor To: MARID Subject: A layered approach to identities, possibilities for a chain of trust Message-ID: <1136343.1087044740@[10.12.1.26]> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Team- Here is a first stab at defining "layers" based on who handled the message, and what data changes at each stage. (This is not really a proposal, but perhaps one will come out of discussion on this.) This is not an attempt to steer us in one particular direction or other, but more an attempt to classify different identities and group them according to how and when they change during the life of a message. As we saw during the discussion of "which identities to use", some identities change very often (like HELO, which changes at every hop) and therefore have a strong association with the IP of the MTA client. Other identities have a longer lifetime (like 2822.From which has the longest) and tell you more about the message, but have a weaker link to IP. Using these definitions, Layer 1 is where both SPF and CID really shine, because the association to IP is strong. The trouble is, SPF depends on the idea that MAIL FROM will be rewritten at each injection (MAIL FROM + SRS) and CID depends on a header being added to make PRA work, so neither exactly matches the way email is used today. From:, Sender:, and MAIL FROM (non-SRS) are described here as Layer 2, and they don't currently have a strong tie to verifiable IP information. However, if you give some level of trust to the forwarding agent, it might be possible to stretch a Layer 1 PASS result to a Layer 2 result you can accept. (See description below in Layer 2.) Again, don't treat it as a proposal, but we might be able to use this to make sense of PRA, and how it might lead to a stronger level of trust in more important identities. ______________________________________________________________________ Layer 0: Hop / Relay / MTA receive Identities: 2821: HELO Set by: last hop client Association to IP: Strong (if domain fully qualified) Purpose of checks: To catch fraudulent MTAs that lie about their own name, if the name is protected by LMAP info. Description: If LMAP information exists for the HELO name, check to see if the current IP is allowed to use the name. If this check fails, reject the mail. Justification for rejection: The domain owner is responsible for publishing LMAP info that includes use of her name in MTA HELO, if the name is allowed to be used by any MTA to identify itself. ______________________________________________________________________ Layer 1: Injection / Redirection Identities: 2821.SUBMITTER, 2822.PRA (i.e. Resent-From, Resent-Sender, Delivered-To, Sender, From), [2821.MAIL FROM only if SRS is used] Set by: A layer 2 identified party (on 1st injection), or forwarding agent if forwarding is requested by the receiver. Association to IP: Strong (checking at receiver's edge) Purpose of checks: Match IP information to "some" domain claiming responsibility, EITHER for the message OR its redirection to you. Description: If PRA/SUBMITTER pass an LMAP IP check, the mail should be considered "Verified Indirect Mail" (unless it also passes at Layer 2). If these identities fail an LMAP IP check, mail should be rejected. Justification for rejection: The domain owner at the first injection is responsible for listing all MTAs that may pass the message from an agent of the sender to an agent of the receiver. The domain owner of the forwarding/redirecting domain lists its MTAs similarly. The forwarding/redirection agent is responsible for adding his information in the appropriate header to override PRA (and SUBMITTER if available). Only perform this check at receiver's edge, not at further relays within the receiver's organization. ______________________________________________________________________ Layer 2: Message / Transaction Identities: 2822.From, 2822.Sender:, 2821.MAIL FROM Set by: MUA of person who authored the message, or person who forwarded the message via old-fashioned manual Fwd: (if Direct), or a mailing list robot Association to IP: Weak Description: If From:, Sender:, or MAIL FROM pass an LMAP IP check, the mail should be considered "Verified Direct Mail". The mail should be identified as coming from whichever identity passes its IP check (From: Sender: or MAIL FROM:) Reason for not rejecting: If these identities don't pass an LMAP IP check, proceed to per transaction checks. The mail still may be allowed as Indirect. Currently no rejection takes place at this layer using LMAP because the association between its identities and the relaying IP is weak, but if a Pass result is received, this is valuable information. More info: A Pass result from checking layer 2 can be recorded along with the Received: information. Another party receiving the message later may decide to go ahead and use the layer 2 information recorded by a previous layer 1 receiver, IF the layer 1 IP validates the forwarder AND the receiver implicitly trusts the forwarder. For example, joe@aol.com sends the message to frank@pobox.com, who forwards it to frankie123@earthlink.net. If pobox.com is able to validate layer 2 (because joe@aol.com passes based on the first IP) then pobox.com records this fact. When frankie123@earthlink.net receives the message, checks that it is from pobox.com's IP, and pobox.com is on his trusted forwarders white list, joe@aol.com's identity is verified through the "chain of trust". (Note, for the chain of trust to work, the END recipient must trust ALL the forwarding agents involved and ALL the forwarding injections must result in a layer 1 PASS). ______________________________________________________________________ (Why I didn't include a Layer 3:) (In this model, mailing list robots set the Sender: and MAIL FROM, but not the From:, so they might be considered as the endpoint of one Layer 2 transaction and the start of a second Layer 2 transaction. So, it might make sense to talk about a Layer 3 that is truly end-to-end-delivery. I think only crypto proposals are going to be effective at layer 3 if layer 2 checking does not suffice. For now I am lumping From: into layer 2 along with Sender: and MAIL FROM.) Thoughts, comments, flames? Though I know it's kind of incomplete as of yet... -- Greg Connor From owner-ietf-mxcomp@mail.imc.org Sat Jun 12 19:28:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28916 for ; Sat, 12 Jun 2004 19:28:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5CNIEiH064500; Sat, 12 Jun 2004 16:18:14 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5CNIExO064499; Sat, 12 Jun 2004 16:18:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from hoster911.com (hoster911.com [66.211.137.37]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5CNIDE5064486 for ; Sat, 12 Jun 2004 16:18:13 -0700 (PDT) (envelope-from marid@bcdef.com) Message-Id: <200406122318.i5CNIDE5064486@above.proper.com> Received: (qmail 4694 invoked from network); 12 Jun 2004 23:19:22 -0000 X-Relay-Users: bcdef.user X-Abuse: Send abuse reports to: abuse@suresupport.com Received: from unknown (HELO tancho) (24.34.60.225) by ns1.hoster911.com with SMTP; 12 Jun 2004 23:19:22 -0000 From: "Rich Rosenbaum" To: Subject: [RFC 1464?] RE: Alternative to TXT or new RR was: Comments ondraft-ietf-marid-core-01 xml use Date: Sat, 12 Jun 2004 19:18:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcRQ05Bp/jLIEinRSRucoBNJn35KnQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Some notes on RFC 1464: As has been noted, RFC 1464 never progressed beyond being experimental, so calling a TXT record that conforms to it "standards-based" is not correct. Over the years since 1464 was published I've received occasional inquiries about it; some people claim to have used it in their applications. However I believe SPF was the first time wide scale deployment of a 1464-compliant TXT record scheme was proposed. The bottom line is that RFC 1464 was a syntax proposal design to simplify information sharing. A registry was proposed to control name collisions, but that never happened. It still seems to be a reasonable approach and perhaps someone will put it back on the standards track someday if appropriate. Rich [author, RFC 1464] From owner-ietf-mxcomp@mail.imc.org Sat Jun 12 19:37:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29139 for ; Sat, 12 Jun 2004 19:37:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5CNW7IP066189; Sat, 12 Jun 2004 16:32:07 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5CNW7pD066188; Sat, 12 Jun 2004 16:32:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5CNW7Uw066167 for ; Sat, 12 Jun 2004 16:32:07 -0700 (PDT) (envelope-from michel@arneill-py.sacramento.ca.us) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Towards resolution on Wildcards X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Sat, 12 Jun 2004 16:32:05 -0700 Message-ID: Thread-Topic: Towards resolution on Wildcards Thread-Index: AcRPAXdSBZ8DtfBPRx2K9jP+e2JTxgAcdyZg From: "Michel Py" To: "IETF MARID WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5CNW7Uw066182 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > wayne wrote: > I mean, really, what's the point of doing XML in TXT > if Outlook and Exchange don't use it until 2007? It's not really relevant, here's why. I will compare with using RBL lists. First, the Outlook situation and the Exchange situation are not the same. Exchange: --------- At the time Exchange came out, I don't remember anything about RBL lists. When RBL lists became popular, Exchange did not support them (that would be 5.5 time frame). I use Exchange, and as of today I don't even know if it supports checking RBL lists because that's not where I check them. I begun using BCWare NoSPam (http://www.bcwaresystems.com/nospam/) with 5.5 and now I am using the check built in SMSMSE (http://enterprisesecurity.symantec.com/products/products.cfm?ProductID= 66&EID=0). Whether Exchange supports RBL lists or not is not relevant to me. This has not changed with SPF (third-party software being already available, and support coming into mainstream products) and there is no reason to believe that this would change for SPFID either. Outlook: -------- There it would be nice indeed to have handling that displays a magnifying glass with a checkmark if the message has been checked by SPF, and a thumbnail if it comes from a source listed in a reputation system. However, these can be accommodated by having the SPF engine inserting a short string at the beginning of the subject, such as instead of: wayne Re: Towards res... we could have something like: wayne (S ) Re: Towards res... Has been SPFID-checked wayne ( +) Re: Towards res... Sender is IADB accredited wayne (S+) Re: Towards res... Both SPF and IADB wayne ( -) Re: Towards res... Bad reputation The need for integration will come from MTA-side implementation. Michel. From owner-ietf-mxcomp@mail.imc.org Sat Jun 12 19:43:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29306 for ; Sat, 12 Jun 2004 19:43:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5CNWhoP066271; Sat, 12 Jun 2004 16:32:43 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5CNWhYV066270; Sat, 12 Jun 2004 16:32:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5CNWh87066255 for ; Sat, 12 Jun 2004 16:32:43 -0700 (PDT) (envelope-from michel@arneill-py.sacramento.ca.us) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Alternative to TXT or new RR X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Sat, 12 Jun 2004 16:32:43 -0700 Message-ID: Thread-Topic: Alternative to TXT or new RR Thread-Index: AcRQDxRzNd8sxIAHQ7mHLhpTgeTlrgACePtgAC35itA= From: "Michel Py" To: "Bob Atkinson" , "IETF MARID WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5CNWh87066265 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit >> wayne wrote: >> I agree, MARID can't claim the TXT RR for it's own. Ok I tried, no cigar this time. > Bob Atkinson wrote: > Let's be clear; this is NOT the plan of record in the > current draft. Rather, MARID is claiming the COMBINATION > of a particular domain prefix and TXT as it's own. For the record, which I support. Nevertheless, numerous posts have highlighted the fact that this might not be "good enough" to go to PS (compared to a solution that would use a new RR), so everything that makes the TXT solution sexier is generally a good idea. >> Wayne: >> almost all domains have enough space left in the >> 512B UDP DNS packet that you can add SPF records >> without problems. Obviously this applies to SFPID only if the SPFID record keeps a size comparable to the SPF record. Michel. From owner-ietf-mxcomp@mail.imc.org Sat Jun 12 22:59:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06036 for ; Sat, 12 Jun 2004 22:59:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5D2oagv089971; Sat, 12 Jun 2004 19:50:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5D2oa1H089970; Sat, 12 Jun 2004 19:50:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5D2oZi6089951 for ; Sat, 12 Jun 2004 19:50:35 -0700 (PDT) (envelope-from michel@arneill-py.sacramento.ca.us) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [RFC 1464?] RE: Alternative to TXT or new RR was: Comments ondraft-ietf-marid-core-01 xml use X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Sat, 12 Jun 2004 19:50:37 -0700 Message-ID: Thread-Topic: [RFC 1464?] RE: Alternative to TXT or new RR was: Comments ondraft-ietf-marid-core-01 xml use Thread-Index: AcRQ05Bp/jLIEinRSRucoBNJn35KnQAHR4fg From: "Michel Py" To: "Rich Rosenbaum" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5D2oZi6089964 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > Rich Rosenbaum wrote: > The bottom line is that RFC 1464 was a syntax proposal > design to simplify information sharing. A registry was > proposed to control name collisions, but that never > happened. It still seems to be a reasonable approach > and perhaps someone will put it back on the standards > track someday if appropriate. Thanks for the feedback, Rich. IMHO, this WG will yield significant benefits by finding the appropriate way to update RFC1464 by a) creating a registry for it and b) upgrading status to standards track. It should be easier to get on the standards track now that there is at least one (SPF) implementation that is widely in use. Michel. From owner-ietf-mxcomp@mail.imc.org Sun Jun 13 08:40:01 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08382 for ; Sun, 13 Jun 2004 08:40:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5DCS0G0064165; Sun, 13 Jun 2004 05:28:00 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5DCS0UT064164; Sun, 13 Jun 2004 05:28:00 -0700 (PDT) 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.9) with ESMTP id i5DCRxLl064157 for ; Sun, 13 Jun 2004 05:27:59 -0700 (PDT) (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 i5DCRviq009465; Sun, 13 Jun 2004 05:27:58 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Sun, 13 Jun 2004 05:27:57 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Rich Rosenbaum'" , ietf-mxcomp@imc.org Subject: RE: [RFC 1464?] RE: Alternative to TXT or new RR was: Comments on draft-ietf-marid-core-01 xml use Date: Sun, 13 Jun 2004 05:27:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > The bottom line is that RFC 1464 was a syntax proposal design > to simplify > information sharing. A registry was proposed to control name > collisions, but > that never happened. It still seems to be a reasonable > approach and perhaps > someone will put it back on the standards track someday if > appropriate. I agree with most of the idea, but I don't agree with the registry part. According to ICANN, IANA is costing $700,000 a year to maintain. I think it is time to either look at why it costs so much and work to reduce it, or start looking for engineering designs that do not depend on registry functions. In the case of DNS RR prefixing there is no real problem since the possible name space is essentially unlimited. The chance of accidental collision is minimal. The value that a registry would provide is as a concordance. The engineering way to deal with this problem would be to move to a competent document format such as XML, assign all code points automatically from a dictionary and build the concodances and indexes automatically from the documents themselves. This is somewhat over-engineered for our case since we already have a unique key, the group name is in theory unique over time. Using _MARID as the prefix is practically guaranteed to be accidental collision free. Adding the protocol identifier to the base prefix is arguably an improvement, since we might use _SMPT._MARID. From owner-ietf-mxcomp@mail.imc.org Sun Jun 13 10:43:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16248 for ; Sun, 13 Jun 2004 10:43:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5DEZ9ao084061; Sun, 13 Jun 2004 07:35:09 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5DEZ93F084060; Sun, 13 Jun 2004 07:35:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [64.139.47.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5DEZ9Pc084052 for ; Sun, 13 Jun 2004 07:35:09 -0700 (PDT) (envelope-from gconnor@nekodojo.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by neko-base.nekodojo.org (Postfix) with ESMTP id CD2321D651; Sun, 13 Jun 2004 07:35:11 -0700 (PDT) Date: Sun, 13 Jun 2004 07:35:11 -0700 From: Greg Connor To: Jim Lyon Cc: ietf-mxcomp@imc.org Subject: exists element (draft-ietf-marid-core-00) Message-ID: <3904203.1087112111@[10.12.1.26]> In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF30C80F@df-fido-msg.exchange.corp.microsoft.com> References: <81AC085044D04B429F5FB883D94FA1AF30C80F@df-fido-msg.exchange.cor p.microsoft.com> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --Jim Lyon wrote: > 5.1.5 "exists" element > > Attributes: None > Child Elements: None > Character Data: A domain name, with macro expansion. > > This element matches iff the domain given by the character data > (after macro expansion) exists in DNS. If the DNS lookup fails for > any reason other than nonexistence, the client authorization function > returns "unknown". This should be clarified as to what type of lookup needs to be done. I believe the current SPF spec says this should be an A record (to make it similar to how an RBL works). The wording in this draft might be understood to mean an ANY query should be done, but I'm not sure that's what is intended... if it is, that should be clarified. -- Greg Connor From owner-ietf-mxcomp@mail.imc.org Sun Jun 13 11:08:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17491 for ; Sun, 13 Jun 2004 11:08:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5DF1m0l088175; Sun, 13 Jun 2004 08:01:48 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5DF1m15088174; Sun, 13 Jun 2004 08:01:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [64.139.47.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5DF1lTL088167 for ; Sun, 13 Jun 2004 08:01:47 -0700 (PDT) (envelope-from gconnor@nekodojo.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by neko-base.nekodojo.org (Postfix) with ESMTP id 350A31D651; Sun, 13 Jun 2004 08:01:50 -0700 (PDT) Date: Sun, 13 Jun 2004 08:01:50 -0700 From: Greg Connor To: Jim Lyon Cc: ietf-mxcomp@imc.org Subject: Ancient history (draft-ietf-marid-core-00) Message-ID: <5502822.1087113710@[10.12.1.26]> In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF30C80F@df-fido-msg.exchange.corp.microsoft.com> References: <81AC085044D04B429F5FB883D94FA1AF30C80F@df-fido-msg.exchange.cor p.microsoft.com> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --Jim Lyon wrote: > 12. Acknowledgements > > Variations on the idea of using a DNS record to check the legitimacy > of an email address have occurred multiple times. The earliest known > work is [RMX]; others include [SPF} and [CallerID]. > > The current document borrows heavily from each of the above, and > incorporates many ideas proposed by many members of the MARID working > group. I am not sure, but I seem to remember Andrew Church published a draft for MS records that predates RMX. There was also a proposal by Paul Vixie but I don't know if it was published. -- Greg Connor From owner-ietf-mxcomp@mail.imc.org Sun Jun 13 12:29:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22112 for ; Sun, 13 Jun 2004 12:29:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5DGKLak000898; Sun, 13 Jun 2004 09:20:21 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5DGKL1K000897; Sun, 13 Jun 2004 09:20:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mms-dmz.tumbleweed.com (tumbleweed1.tumbleweed.com [216.148.213.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5DGKI36000871 for ; Sun, 13 Jun 2004 09:20:18 -0700 (PDT) (envelope-from mark.joseph@tumbleweed.com) Received: from 10.1.5.15 by mms-dmz.tumbleweed.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.6.3)); Sun, 13 Jun 2004 09:21:18 -0700 X-Server-Uuid: 9E62DAEC-D7BB-48B1-92D4-FD536B790981 Received: by pigeon.tumbleweed.com with Internet Mail Service ( 5.5.2657.72) id ; Sun, 13 Jun 2004 09:20:05 -0700 Message-ID: From: "Mark Joseph" To: "'Markus Stumpf '" , "'owner-ietf-mxcomp@mail.imc.org '" , "'Marshall Rose '" cc: "'IETF MARID WG '" Subject: RE: MARID charter and using 2822 data Date: Sun, 13 Jun 2004 09:20:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) List-Unsubscribe: X-Server-Uuid: 9E62DAEC-D7BB-48B1-92D4-FD536B790981 X-Filter-Reason: 9E62DAEC-D7BB-48B1-92D4-FD536B790981 X-Mail-Filter: 9E62DAEC-D7BB-48B1-92D4-FD536B790981 X-Authentication-Warning: 9E62DAEC-D7BB-48B1-92D4-FD536B790981 X-PGP-Fingerprint: 9E62DAEC-D7BB-48B1-92D4-FD536B790981 X-WSS-ID: 9E62DAEC-D7BB-48B1-92D4-FD536B790981 X-WSS-ID: 6CD2A1741M82847740-01-02 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C45162.222F5BDC" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C45162.222F5BDC Content-Type: text/plain Content-Transfer-Encoding: 7bit >Exactly what in the process of adding a line (or two) at the beginning >of the data stream from the network to disk makes you believe MTAs know >about 2822 content? MTAs will often add Message-ID, and Date headers because email client don't. To do so an MTA must parse and understand the basic headers of a message. Also MTAs might have to translate body types form 8 bit to 7 bit data. An MTA can accept a message in 8bitMime but in forwarding the message to its final destination might hit another MTA that only takes 7 bit encodings. Postfix for example can do the translation form 8 bit to 7. To do so it must understand the message structure. There are probably other examples as well. Regards, Mark Joseph -----Original Message----- From: owner-ietf-mxcomp@mail.imc.org To: Marshall Rose Cc: IETF MARID WG Sent: 6/12/2004 11:40 AM Subject: Re: MARID charter and using 2822 data On Fri, Jun 11, 2004 at 08:08:46PM -0700, Marshall Rose wrote: > wg from considering 2822 as a part of the solution. like it or not MTAs > know about 2822 content. in the simplest example of this, consider the > Received: header. Exactly what in the process of adding a line (or two) at the beginning of the data stream from the network to disk makes you believe MTAs know about 2822 content? \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" ------_=_NextPart_001_01C45162.222F5BDC Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: MARID charter and using 2822 data

>Exactly what in the process of adding a line (or = two) at the beginning
>of the data stream from the network to disk = makes you believe MTAs know
>about 2822 content?

MTAs will often add Message-ID, and Date headers = because email
client don't.   To do so an MTA must parse = and understand the
basic headers of a message.

Also MTAs might have to translate body types form 8 = bit to 7 bit data.
An MTA can accept a message in 8bitMime but in = forwarding the message
to its final destination might hit another MTA that = only takes 7 bit
encodings.   Postfix for example can do = the translation form 8 bit to
7.  To do so it must understand the message = structure.

There are probably other examples as well.

Regards,
Mark Joseph

-----Original Message-----
From: owner-ietf-mxcomp@mail.imc.org
To: Marshall Rose
Cc: IETF MARID WG
Sent: 6/12/2004 11:40 AM
Subject: Re: MARID charter and using 2822 = data


On Fri, Jun 11, 2004 at 08:08:46PM -0700, Marshall = Rose wrote:
> wg from considering 2822 as a part of the = solution. like it or not
MTAs
> know about 2822 content. in the simplest = example of this, consider the

> Received: header.

Exactly what in the process of adding a line (or two) = at the beginning
of the data stream from the network to disk makes = you believe MTAs know
about 2822 content?

        \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"

------_=_NextPart_001_01C45162.222F5BDC-- From owner-ietf-mxcomp@mail.imc.org Sun Jun 13 12:40:58 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22483 for ; Sun, 13 Jun 2004 12:40:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5DGZ2Vh002960; Sun, 13 Jun 2004 09:35:02 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5DGZ2lh002959; Sun, 13 Jun 2004 09:35:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [64.139.47.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5DGZ14F002950 for ; Sun, 13 Jun 2004 09:35:01 -0700 (PDT) (envelope-from gconnor@nekodojo.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by neko-base.nekodojo.org (Postfix) with ESMTP id A050D1D651; Sun, 13 Jun 2004 09:35:04 -0700 (PDT) Date: Sun, 13 Jun 2004 09:35:04 -0700 From: Greg Connor To: Jim Lyon , ietf-mxcomp@imc.org Subject: RE: Comments on draft-ietf-marid-core-01 xml use Message-ID: <11097236.1087119304@[10.12.1.26]> In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF3A0D0F@df-fido-msg.exchange.corp.microsoft.com> References: <81AC085044D04B429F5FB883D94FA1AF3A0D0F@df-fido-msg.exchange.cor p.microsoft.com> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --Jim Lyon wrote: > > Arguing against XML, Alan DeKok says: "Does that extensibility have to > exist in DNS records? I think > that's the point of contention, here." > > It seems to me that as we invent extensions, the DNS records need to > either contain the extension data, or contain some kind of information > that points us to the extension data outside of DNS. > > It also seems reasonable that as extensions are invented, if the amount > of data that needs to be communicated is small, it should probably go > in-line in the DNS record. If the amount of data is large, it probably > shouldn't. This would argue that extensions that define flags and small > constants should certainly go in the DNS record, and extensions that > carry certificates as data almost certainly should not go in DNS. In > between, we have things like data containing email addresses (probably > in DNS), and data containing public keys (possibly in DNS, but probably > not). > > The point of using XML is to have confidence that we have sufficient > syntactic flexibility to describe the probable future extensions, > whether they contain data in-line or they contain pointers to external > data. Jim and I (among others) discussed this a bit off-line between sessions of the interim meeting. Here are my thoughts on the subject. 1. New features may come along later, that allow more ways to include messages that might otherwise not be validated, or to reject messages that might otherwise be included. Domain owners will want to use the features, and implementers will want to support them. 2. XML provides "syntactic extensibility" but not "feature extensibility". It is possible to use this to include other "interesting" data, but the new data should not alter the output of the validation function. There is no magic way for XML to add new features to old implementations, or alters the behavior of existing features. 3. IF we decide we might need new features later (i.e. if we cannot rule out that we may need them) it is to our benefit to build in some manner of "feature extensibility". This would allow use of the new feature if both the receiver and domain owner support it. But, there must be a sensible way for old implementations to fall back on the core feature set while still honoring the domain owner's wishes, to the extent possible. 4. Adding new features on the fly doesn't have to be a scary thing.. it just requires some forethought in the spec that tells existing implementations how to navigate around the features it doesn't yet understand. 5. We should also take some precautions to ensure that typos are not mistakenly processed as "unknown features". Given the above goals, let me take a stab at a proposal. 1. There should be a way to carry "extra data" that does not change the results of the authorization function (such as comments, contact names, pointers to the URL of a failure explanation message, etc). The receiver is free to use or ignore these. If they are used, they should not alter the actual result. In XML the "extra" information could be added as a new root element, or a child of "ep" that is not "out", or a child of "out" that is not "m". In SPF, the "extra" data is added as a modifier like "extra=hi_there". 2. New "feature" nodes may be added later, as long as there is a sensible way to route around them if they are not implemented by the receiver. The "fallback" or "alternate" behavior should be specified by the domain owner. For example, in XML this could be implemented as: In SPF the fallback could be defined by a modifier that comes right before the unknown mechanism, such as v=spf1 a mx alt=ignore foobar -all 3. The "alt" tells the receiver what to do if the feature we are trying to use is not supported. Possible values might be: alt=ignore OK to ignore the unknown feature and continue processing the record alt=unknown If you can't understand the new feature, stop and return unknown alt=fail If you can't understand the new feature, stop and return fail alt=error If the feature is unknown, stop and return an error If the fallback or alternate is not specified, the receiver should assume that the unknown feature or mechanism is a typo and abort processing of the record (alt=error). Therefore it is the responsibility of those using the new feature to explicitly define their fallback behavior... not to do so will be considered an error. 4. Mechanisms in the original core feature set (as defined in the published spec) must not have an alt= tag. It is not possible to skip over core features. Any implementation that does not implement all features in the original core set should be deemed non-compliant. 5. A newer version of the spec may be published in the future, which rolls in new features and promotes them to "core" status. If there is a new spec that collects new mechanisms and features, it should have its own URI and possibly its own prefix. When publishing records in the new URI or new prefix, the alt= tag is not needed (and may be considered an error) because those features are now "core". Similarly, receivers that are compliant with the future rolled-up spec must honor all features of that spec. Why are we leaving it up to the domain owner to decide what the fallback should be? Why wouldn't it work to just decide on a single fallback and run with it? Consider two companies that might use domainkeys (or whatever feature). Company A might say "All our mail uses domainkeys. If it doesn't have domainkeys, reject it. If you are not able to check for domainkeys, all our mail should come from our address space anyway, so use "a mx ptr -all". In that case it makes sense to put domainkeys up front, because they are giving us the OK to reject mail without it, even if it comes from their IP space: v=spf1 alt=ignore +domainkeys alt=ignore -domainkeys:unsigned a mx ptr -all Another company might choose to offer domain keys as a way to include mail that would otherwise be excluded (in other words, change their ?all to a -all). Not all their mail is signed, but if it doesn't meet "a mx ptr" it must be signed. Receivers who can't process domainkeys should use ?all. v=spf1 a mx ptr alt=unknown domainkeys -all Final note, while XML has syntactic extensibility, it cannot get feature extensibility for free, we have to do our homework ahead of time. Conversely, plain SPF has a similar restriction, but adding a couple of carefully chosen elements to the language can give us feature extensibility in a sensible way. I am not expressing a preference for either XML or plain SPF in this message. Comments, feedback, flames? Thanks gregc -- Greg Connor From owner-ietf-mxcomp@mail.imc.org Sun Jun 13 13:09:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23454 for ; Sun, 13 Jun 2004 13:09:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5DGu6ss006322; Sun, 13 Jun 2004 09:56:06 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5DGu6hj006321; Sun, 13 Jun 2004 09:56:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from hoster911.com (hoster911.com [66.211.137.37]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5DGu5GN006314 for ; Sun, 13 Jun 2004 09:56:06 -0700 (PDT) (envelope-from marid@bcdef.com) Message-Id: <200406131656.i5DGu5GN006314@above.proper.com> Received: (qmail 3913 invoked from network); 13 Jun 2004 16:57:13 -0000 X-Relay-Users: bcdef.user X-Abuse: Send abuse reports to: abuse@suresupport.com Received: from unknown (HELO tancho) (24.34.60.225) by ns1.hoster911.com with SMTP; 13 Jun 2004 16:57:13 -0000 From: "Rich Rosenbaum" To: Subject: RE: [RFC 1464?] RE: Alternative to TXT or new RR was: Comments ondraft-ietf-marid-core-01 xml use Date: Sun, 13 Jun 2004 12:56:19 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcRRQtjJsWHZpYTuTBqhvZuCpcqZXwAA2JwgAAg9yiA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > I wrote: > The bottom line is that RFC 1464 was a syntax proposal design to > simplify information sharing. A registry was proposed to control name > collisions, but that never happened. It still seems to be a reasonable > approach and perhaps someone will put it back on the standards track > someday if appropriate. Apologies for the ambiguity of my message. I meant to say that I thought the syntax part (the core of RFC 1464) was a reasonable idea. I agree with Phillip that the creation of a registry requires more thought. Preventing name collisions through use of careful identifier selection would be a good idea, registry or not (especially with no registry). Rich From owner-ietf-mxcomp@mail.imc.org Sun Jun 13 14:08:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25454 for ; Sun, 13 Jun 2004 14:08:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5DHxs56016184; Sun, 13 Jun 2004 10:59:54 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5DHxsFI016183; Sun, 13 Jun 2004 10:59:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (news.winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5DHxrqN016165 for ; Sun, 13 Jun 2004 10:59:53 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Sun, 13 Jun 2004 14:03:22 -0400 Received: from ([66.156.222.143]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 960449719; Sun, 13 Jun 2004 14:03:21 -0400 Message-ID: <002e01c45171$35a274d0$6401a8c0@hdev1> From: "Hector Santos" To: "Greg Connor" , "Jim Lyon" , References: <81AC085044D04B429F5FB883D94FA1AF3A0D0F@df-fido-msg.exchange.cor p.microsoft.com> <11097236.1087119304@[10.12.1.26]> Subject: Re: Comments on draft-ietf-marid-core-01 xml use Date: Sun, 13 Jun 2004 14:06:44 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.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: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Greg Connor" To: "Jim Lyon" ; Sent: Sunday, June 13, 2004 12:35 PM Subject: RE: Comments on draft-ietf-marid-core-01 xml use > Given the above goals, let me take a stab at a proposal. > > [clip] > > Final note, while XML has syntactic extensibility, it cannot get feature > extensibility for free, we have to do our homework ahead of time. > Conversely, plain SPF has a similar restriction, but adding a couple of > carefully chosen elements to the language can give us feature extensibility > in a sensible way. I am not expressing a preference for either XML or > plain SPF in this message. > > Comments, feedback, flames? You raised some good points, especially the idea of utililizing XML entity attributes should be maximized as much as possible. This has technical optimization consideration. What we seem to be having here is a classic "chicken vs. egg" design problem. It seems to me we are getting lost on a format without having a clear logic flow for all the possible issues. Any format, linear or hierarchical, will provide a solution on flexibility. I personally believe a linear format has optimization considerations, but I wouldn't use that as a sole basis to rule out XML. I look at all the other design issues that XML will mandate: - XML parsing requirements. This is can a costly development issue for many as it is not a traditional or intrinsic component in languages libraries. It is something that needs to be imported. Not a big deal for developers worth their salt, but not a piece of cake either. We currently use the lightweight PugXML ANSI compatible C/C++ class. *nix people can look at this for an open source reliable XML parser. In regards to Microsoft, the mantra for Microsoft .NET designs is 100% XML based. So for them, it makes a lot of sense. Microsoft offers XML components so for .NET or ActiveX or ATL Windows developers, it is more possible for them. But this can lead to another issue: - XML namespace. Clearly, without a doubt, any system that requires a namespace raises a red flag that has electronic privacy (ECPA) implementations. A XML parsing component that requires the importing of the namespace gives the source system an opportunity to track the usage of the structure. Sorry, this is an immediate a NO-NO in our long tradition for ethical design of software. Pulled from our custom XML parsing implementation for MCEP. The last thing we want to hear from customers is "why is your mail software pinging Microsoft?" With that said, although XML is a serious technology and a requirement for a product vendors keeping on par with industry directions across the board. However, for this particular MARID implementation, I have technical design problem with it. Given the choice, I would rather have a linear approach. It has nothing to do with being faith-based, or to borrow a phrase, "a devil on your shoulder or a raised hair on your back," but it 100% about the technical issues related to it - a relative high/cost design implementation requirement vs. a narrow design specification scope need. But obviously, we have a group, including a champion pushing the issue strongly who prefers to make this the MARID format. And you also have a completing group that already have a strong following, with a system that "works" without all the "extras" that an XML format will impose. So my proposal would be, from a technical standpoint, is that there should an minimum "anchor" format. One that defines what client logic is to be used. Some examples: It will help define the LMAP technology in place, the record type and possible prefix to be used. Of course, with attribute defaults, the anchor can be further minimized. This will have a major benefit not only because it would be small and sweet, but also in my view, since the majority of the systems will only need a small sub-set of all the possibilities, the minimum anchor format may offer validation logic just as well: For example, for a small mail server with one MTA, it can have: So for this chicken and egg problem, my recommendation balanced with real world design implementation issues and LMAP operations as well, is to take advantage of an entity attribute to help minimum the format, offer flexibility to "methods" requirements and to also help define the domain policy as well. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Sun Jun 13 16:34:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02535 for ; Sun, 13 Jun 2004 16:34:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5DKLG3k041412; Sun, 13 Jun 2004 13:21:16 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5DKLG5t041411; Sun, 13 Jun 2004 13:21:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from xuxa.iecc.com (xuxa.iecc.com [208.31.42.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5DKLFgb041396 for ; Sun, 13 Jun 2004 13:21:16 -0700 (PDT) (envelope-from johnl@iecc.com) Received: (qmail 4450 invoked by uid 100); 13 Jun 2004 20:21:17 -0000 Date: 13 Jun 2004 20:21:17 -0000 Message-ID: <20040613202117.4449.qmail@xuxa.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: Re: header rewriting, was MARID charter and using 2822 data In-Reply-To: Organization: I.E.C.C., Trumansburg NY USA Cc: mark.joseph@tumbleweed.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >>Exactly what in the process of adding a line (or two) at the beginning >>of the data stream from the network to disk makes you believe MTAs know >>about 2822 content? > >MTAs will often add Message-ID, and Date headers because email >client don't. To do so an MTA must parse and understand the >basic headers of a message. ... There's a chronic confusion in 2821/2822 mail between mail submission, in which a MUA sends a new message, ant mail transfer, in which a message goes from one MTA to another. In a more perfect world, MSAs would clean up headers at submission time, and MTAs wouldn't mess with messages other than putting headers at the top to say where it's been. I run qmail, which makes about as clear a separation as possible between submission and transfer, but even there some kinds of forwarding accidentally go through the header rewriter. Perhaps we can say that any MSA/MTA that rewrites headers is taking responsibility for the message and should be prepared to vouch for it if it goes out via SMTP again. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY http://www.taugh.com From owner-ietf-mxcomp@mail.imc.org Sun Jun 13 17:26:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04495 for ; Sun, 13 Jun 2004 17:26:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5DLEbYU050269; Sun, 13 Jun 2004 14:14:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5DLEbqD050268; Sun, 13 Jun 2004 14:14:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5DLEbKB050261 for ; Sun, 13 Jun 2004 14:14:37 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from [192.168.2.24] (adsl-64-142-13-68.sonic.net [64.142.13.68]) by a.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i5DLEcVA007269; Sun, 13 Jun 2004 14:14:39 -0700 Subject: RE: [RFC 1464?] RE: Alternative to TXT or new RR was: Comments on draft-ietf-marid-core-01 xml use From: Douglas Otis To: "Hallam-Baker, Phillip" Cc: "'Rich Rosenbaum'" , ietf-mxcomp@imc.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1087161278.2641.64.camel@bash.adsl-64-142-13-68.sonic.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 13 Jun 2004 14:14:38 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sun, 2004-06-13 at 05:27, Hallam-Baker, Phillip wrote: > > The bottom line is that RFC 1464 was a syntax proposal design > > to simplify information sharing. A registry was proposed to > > control name collisions, but that never happened. It still > > seems to be a reasonable approach and perhaps someone will > > put it back on the standards track someday if appropriate. > > I agree with most of the idea, but I don't agree with the > registry part. > > According to ICANN, IANA is costing $700,000 a year to > maintain. I think it is time to either look at why it > costs so much and work to reduce it, or start looking for > engineering designs that do not depend on registry functions. Whether there are too many people maintaining the registry information is separate concern from whether a registry is needed. Moving Protocol Number Assignment to a function of the IETF rather an IANA is a decision well beyond the scope of this group. A registry is a vital function that must be employed to ensure the function of past and future protocols. > In the case of DNS RR prefixing there is no real problem > since the possible name space is essentially unlimited. > The chance of accidental collision is minimal. > > The value that a registry would provide is as a concordance. As there are already protocols using text records to store random strings, collision avoidance is depending upon labels. The problem is uses of a label as a sub-domain is prone to collision irrespective of the differences of the labels as a result of wild cards, as there would be motivation for using such a mechanism regardless of how it was specified. > The engineering way to deal with this problem would be to move > to a competent document format such as XML, assign all > code points automatically from a dictionary and build the > concodances and indexes automatically from the documents > themselves. A concordance, (a registry) would need to encompass not just the specification being developed, but other specifications either in progress or already in use. There would need to be agreement where this information is to be centralized and arbitrated, and it would need to be kept current and updated. You imply such specification is free from conflict but that is hand waving. Just as using a domain name is not free from conflict as it could have been owned by prior entities where previous history is unknown without a registry. > This is somewhat over-engineered for our case since we > already have a unique key, the group name is in theory > unique over time. Work group names were never ensured not to conflict with anything but work groups. In addition, these groups expire and are no longer a ready reference. > Using _MARID as the prefix is practically guaranteed to > be accidental collision free. As a label, it would not be free from conflict even if indeed no other protocol used the label. As a token, it is already in conflict with random text strings. > Adding the protocol identifier to the base prefix is > arguably an improvement, since we might use _SMPT._MARID. Again as a label, this offers little assurance. Using more characters for a token embedded in the text reduces chances of a collision, but so would an embedded checksum of the entire record where such chances of collision would billions of times less using just 8 characters. It would also ensure the TXT record would be generated as a result of a script that would likely perform format checks in addition to calculating the checksum. A checksum can defend against random strings. To allow future protocols the use of same mechanism, a registry is still needed. It has already been proposed the XML header is not included within the TXT record, such that XML registries offer no benefit as this information is virtual and too bulky for DNS. -Doug From owner-ietf-mxcomp@mail.imc.org Sun Jun 13 19:22:26 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10663 for ; Sun, 13 Jun 2004 19:22:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5DN0XFP068331; Sun, 13 Jun 2004 16:00:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5DN0X1s068330; Sun, 13 Jun 2004 16:00:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from miz-mishtal.dbc.mtview.ca.us (adsl-64-168-10-250.dsl.scrm01.pacbell.net [64.168.10.250]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5DN0WSR068323 for ; Sun, 13 Jun 2004 16:00:32 -0700 (PDT) (envelope-from mrose@dbc.mtview.ca.us) Received: from [IPv6:::1] (localhost [127.0.0.1]) by miz-mishtal.dbc.mtview.ca.us (8.12.10/8.12.9) with ESMTP id i5DMrijG019244; Sun, 13 Jun 2004 15:53:45 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <861B7E2F-BD8C-11D8-A332-000A95CA7FAE@dbc.mtview.ca.us> Content-Transfer-Encoding: 7bit From: Marshall Rose Subject: topic for monday's chat Date: Sun, 13 Jun 2004 15:53:45 -0700 To: IETF MARID WG X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit here's the topic for monday's chat: we're going to talk about XML. specifically, are its encodings too large for use in the DNS and, if so, should the DNS contain pointers to the actual XML document instead? /mtr From owner-ietf-mxcomp@mail.imc.org Sun Jun 13 22:22:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17089 for ; Sun, 13 Jun 2004 22:22:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5E20Bkt005405; Sun, 13 Jun 2004 19:00:11 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5E20BDm005404; Sun, 13 Jun 2004 19:00:11 -0700 (PDT) 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.9) with ESMTP id i5E20AQ7005397 for ; Sun, 13 Jun 2004 19:00:10 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i5E20GHW026574; Sun, 13 Jun 2004 19:00:16 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Sun, 13 Jun 2004 19:00:16 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Douglas Otis'" , "Hallam-Baker, Phillip" Cc: "'Rich Rosenbaum'" , ietf-mxcomp@imc.org Subject: RE: [RFC 1464?] RE: Alternative to TXT or new RR was: Comments on draft-ietf-marid-core-01 xml use Date: Sun, 13 Jun 2004 19:00:10 -0700 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: > Whether there are too many people maintaining the registry information > is separate concern from whether a registry is needed. > Moving Protocol > Number Assignment to a function of the IETF rather an IANA is > a decision > well beyond the scope of this group. A registry is a vital function > that must be employed to ensure the function of past and future > protocols. Designing protocols to minimize the load on IANA has always been a concern in the ietf. From owner-ietf-mxcomp@mail.imc.org Mon Jun 14 04:41:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14701 for ; Mon, 14 Jun 2004 04:41:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5E8MkJc047159; Mon, 14 Jun 2004 01:22:46 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5E8Mji4047158; Mon, 14 Jun 2004 01:22:46 -0700 (PDT) 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.9) with ESMTP id i5E8MjZr047132 for ; Mon, 14 Jun 2004 01:22:45 -0700 (PDT) (envelope-from cm--jrk@merseymail.com) Received: from mmail by argon.connect.org.uk with local (connectmail/exim) id 1BZmjq-0001vm-UF; Mon, 14 Jun 2004 09:22:42 +0100 In-Reply-To: <20040613202117.4449.qmail@xuxa.iecc.com> Subject: Re: header rewriting, was MARID charter and using 2822 data To: "John Levine" From: "Jon Kyme" Cc: ietf-mxcomp@imc.org X-Mailer: [ConnectMail 3.15.6] X-connectmail-Originating-IP: 172.25.243.3 Message-Id: Date: Mon, 14 Jun 2004 09:22:42 +0100 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > Perhaps we can say that any MSA/MTA that rewrites headers is taking > responsibility for the message and should be prepared to vouch for > it if it goes out via SMTP again. > Perhaps, or maybe - the last entity to modify the message (except by merely adding trace data) must be able to vouch for the message. Incidentally, I'd hope that "vouch" would mean either; assert something about the source of the message and be able to provide some evidence; or to take responsibility for the message. From owner-ietf-mxcomp@mail.imc.org Mon Jun 14 05:14:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15633 for ; Mon, 14 Jun 2004 05:14:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5E91L7L063563; Mon, 14 Jun 2004 02:01:22 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5E91L4l063562; Mon, 14 Jun 2004 02:01:21 -0700 (PDT) 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.9) with ESMTP id i5E91KY3063546 for ; Mon, 14 Jun 2004 02:01:21 -0700 (PDT) (envelope-from cm--jrk@merseymail.com) Received: from mmail by argon.connect.org.uk with local (connectmail/exim) id 1BZnLF-0004U0-77 for ietf-mxcomp@imc.org; Mon, 14 Jun 2004 10:01:21 +0100 In-Reply-To: Subject: RE: Alternative to TXT or new RR To: ietf-mxcomp@imc.org From: "Jon Kyme" X-Mailer: [ConnectMail 3.15.6] X-connectmail-Originating-IP: 172.25.243.3 Message-Id: Date: Mon, 14 Jun 2004 10:01:21 +0100 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > >> wayne wrote: > >> I agree, MARID can't claim the TXT RR for it's own. > FWIW, there's been an interesting little thread on SPF problems caused by non-SPF stuff in TXT here: http://archives.listbox.com/spf-discuss@v2.listbox.com/200406/0697.html From owner-ietf-mxcomp@mail.imc.org Mon Jun 14 09:36:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01506 for ; Mon, 14 Jun 2004 09:36:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5EDPFcA023710; Mon, 14 Jun 2004 06:25:15 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5EDPFq3023709; Mon, 14 Jun 2004 06:25:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.pan-am.ca (srv1.pan-am.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5EDPESS023703 for ; Mon, 14 Jun 2004 06:25:14 -0700 (PDT) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: Alternative to TXT or new RR MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 14 Jun 2004 08:25:15 -0500 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA8C3@srv1.pan-am.ca> X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Alternative to TXT or new RR Thread-Index: AcRR81zsPS9WfOkrQOOU6RkHBDDWGAAHu+Hg From: "Gordon Fecyk" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5EDPESS023704 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > FWIW, there's been an interesting little thread on SPF > problems caused by non-SPF stuff in TXT here: The problem described there looks like an implementation error only. The parser that Michael was using that failed didn't take into account additional records with non-SPF information. While RFC 1464 is one way to distinguish useful information from not useful information, it isn't the only way. Other unique tokens identifying MARID records would work. -- PGP key (0x0AFA039E): Sometimes it's hard to tell where the game ends and where reality bites, er, begins. From owner-ietf-mxcomp@mail.imc.org Mon Jun 14 09:38:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01608 for ; Mon, 14 Jun 2004 09:38:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5EDM9J2023197; Mon, 14 Jun 2004 06:22:09 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5EDM9gN023196; Mon, 14 Jun 2004 06:22:09 -0700 (PDT) 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.9) with ESMTP id i5EDM8gN023180 for ; Mon, 14 Jun 2004 06:22:08 -0700 (PDT) (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.34) id 1BZrPO-0004Oy-8v for ietf-mxcomp@imc.org; Mon, 14 Jun 2004 08:22:08 -0500 To: "IETF MARID WG" References: From: wayne Reply-To: "IETF MARID WG" Date: Mon, 14 Jun 2004 08:21:54 -0500 In-Reply-To: (Jon Kyme's message of "Mon, 14 Jun 2004 10:01:21 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: Alternative to TXT or new RR Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-4.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In "Jon Kyme" writes: >> >> >> wayne wrote: >> >> I agree, MARID can't claim the TXT RR for it's own. >> > > FWIW, there's been an interesting little thread on SPF problems caused by > non-SPF stuff in TXT here: > http://archives.listbox.com/spf-discuss@v2.listbox.com/200406/0697.html If you read that thread, you will find: 1) It is not clear *what* the cause of the problem is. Despite my attempts, I have not been able to recreate the problem. 2) If anything, it appears that the problem was caused by *long* TXT records, rather than a conflict with another SPF record. 3) Out of spec implementations will always be a problem and has nothing to do with the theoretical nor practical use of TXT records by SPF. -wayne From owner-ietf-mxcomp@mail.imc.org Mon Jun 14 09:59:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03243 for ; Mon, 14 Jun 2004 09:59:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5EDlNiI027941; Mon, 14 Jun 2004 06:47:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5EDlNB8027940; Mon, 14 Jun 2004 06:47:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.pan-am.ca (srv1.pan-am.ca [206.45.235.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5EDlM6E027931 for ; Mon, 14 Jun 2004 06:47:22 -0700 (PDT) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: topic for monday's chat MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 14 Jun 2004 08:47:24 -0500 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA8C4@srv1.pan-am.ca> X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: topic for monday's chat Thread-Index: AcRRoXTgBwOpHKpARsS+mFKSUdvlEAAcZv0Q From: "Gordon Fecyk" To: "IETF MARID WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5EDlN6E027932 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I might be occupied this afternoon so I want to say something beforehand. Please accept this as my input for today's XMPP session. Are its encodings too large for DNS? It skirts the maximum DNS UDP packet size as described in marid-core too often that it's going to exceed it for any records describing more than two or three senders. Even RMX used simpler, shorter descriptions and it too became too large for DNS UDP. Seeing XML also leads to to something Doug brought up some time ago: Even if XML was useful, why encode it in UTF-8 by default? Both XML and Unicode are convenient choices for authors whose employers use those technologies natively in their implementations. These are not as convenient for anyone else. I think we don't need to concern ourselves with making life convenient just for one vendor. And even with that, there are other vendors who develop e-mail for the same vendor's platform that would not benefit from the same convenience. As for storing XML documents in other locations and referring to them in DNS: That solves the DNS packet size problem but it doesn't solve the bandwidth problem. Again, some time ago someone posted an example XML document that weighed in at about 450 bytes. The average e-mail in this list is about 3 KB in size. That's a 12% increase in bandwidth to receive a message on this list - best case! With smaller messages it gets worse, and I haven't even included the DNS overhead in fetching the pointers. By comparison, DMP added a mere 4% increase in its worst case, and 1% and less in best cases. I remind everyone that e-mail isn't going to die if we don't come up with something by August. If we rush into this with what's on the table now we're going to come up with a cure that's definitely worse than the disease. On the plus side, some very useful things have come out of marid-core and marid-submitter: The Resent-From: header is a good thing to check against to allow remailers, including mailing lists and forwarders. It places accountability on the remailer. For those who choose to check 2821 instead of 2822, marid-submitter provides a good compromise to remailers. These could be adapted to any of the original input proposals. -- PGP key (0x0AFA039E): Sometimes it's hard to tell where the game ends and where reality bites, er, begins. From owner-ietf-mxcomp@mail.imc.org Mon Jun 14 10:21:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05103 for ; Mon, 14 Jun 2004 10:21:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5EEDfT9033118; Mon, 14 Jun 2004 07:13:41 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5EEDfjs033116; Mon, 14 Jun 2004 07:13:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5EEDdV0033084 for ; Mon, 14 Jun 2004 07:13:40 -0700 (PDT) (envelope-from edlewis@arin.net) Received: by smtp2.arin.net (Postfix, from userid 5003) id B144619BBC9; Mon, 14 Jun 2004 10:12:36 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 28F1419BBC8; Mon, 14 Jun 2004 10:12:36 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.136.136.83]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1770181; Mon, 14 Jun 2004 10:13:36 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Mon, 14 Jun 2004 10:11:35 -0400 To: "Michel Py" From: Edward Lewis Subject: RE: Alternative to TXT or new RR was: Comments on draft-ietf-marid-core-01 xml use Cc: "Edward Lewis" , "MARID" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63-arin1 (2004-01-11) on smtp2.arin.net X-Spam-Status: No, hits=-8.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63-arin1 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 14:24 -0700 6/11/04, Michel Py wrote: >> I know of other experimental uses of the TXT RR, for one, >> opportunistic encryption. There is an RFC in preparation to >> document that. So, MARID can't claim the TXT for it's own >> - others already use it. > >If they are using a well-known set of attributes, I don't see why. Part >of the spec could be acknowledging the other attributes already in use. The issue is that, as ISC does, anyone at anytime can take up using the TXT record for any purpose. My point, which I've done a poor job of stating, is that if documents are relied upon for specification enforcement is also restricted to document space. The IETF does not have a specification enforcement capability, adherence is voluntary. Through specification you can't guarantee no one else will squat on the TXT records. Once again making a case for $MARID RR, if that is defined, then the protocol will restrict the use of the RR to the rules set forth for it. The enforcement is then in the "on the wire protocol". The enforcement is limited to the syntax and handling of the record in DNS, not the use, that is true - a non MARID app can use it, but the implementations would bound its use to one that is compatible with the definition of the $MARID RR. >This is too strong; what I meant is that we should have a list of known >attributes for the TXT record. Anyone wanting to use an attribute should >register it. Would this make the TXT record palatable for PS if >attributes were reserved for SPFID? To do this, there's a need to establish a registry of TXT contents, most likely an IANA registry. This would be a change one of the original (RFC 1035) types, so I'm sure it's undergo a thorough review. I'm doubtful this would be doable, honestly, but one can always try. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. From owner-ietf-mxcomp@mail.imc.org Mon Jun 14 10:23:52 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05284 for ; Mon, 14 Jun 2004 10:23:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5EEDfZX033117; Mon, 14 Jun 2004 07:13:41 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5EEDfUA033115; Mon, 14 Jun 2004 07:13:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5EEDdAc033087 for ; Mon, 14 Jun 2004 07:13:40 -0700 (PDT) (envelope-from edlewis@arin.net) Received: by smtp2.arin.net (Postfix, from userid 5003) id AB01A19B7B5; Mon, 14 Jun 2004 10:12:38 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 9191B19BBC8; Mon, 14 Jun 2004 10:12:37 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.136.136.83]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1770182; Mon, 14 Jun 2004 10:13:37 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Mon, 14 Jun 2004 10:13:34 -0400 To: Andrew Newton From: Edward Lewis Subject: Re: Alternative to TXT or new RR was: Comments on draft-ietf-marid-core-01 xml use Cc: "Michel Py" , "Edward Lewis" , "MARID" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63-arin1 (2004-01-11) on smtp2.arin.net X-Spam-Status: No, hits=-8.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63-arin1 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 17:52 -0400 6/11/04, Andrew Newton wrote: >On Jun 11, 2004, at 5:24 PM, Michel Py wrote: >> >> As it appears their implementation is not compliant with RFC1464 (I did >> not see any attributes nor equal sign), I would say it's ISC's problem. > >RFC 1464 clearly says "Experimental". >TXT is defined RFC 1035 (or so says RFC 1464). Yeah - for that reason, it's not a "problem" for ISC. It's not really a problem for MARID either in that it's unlikely that there'd ever be a conflict. I raised it only as an example that MARID would have a hard time "co-opting" the TXT RR for it's use because there are prior uses of it by others - and in unregistered but RFC-compliant ways. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. From owner-ietf-mxcomp@mail.imc.org Mon Jun 14 10:46:49 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06829 for ; Mon, 14 Jun 2004 10:46:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5EEXsFH038005; Mon, 14 Jun 2004 07:33:54 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5EEXsQG038004; Mon, 14 Jun 2004 07:33:54 -0700 (PDT) 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.9) with ESMTP id i5EEXrfC037990 for ; Mon, 14 Jun 2004 07:33:53 -0700 (PDT) (envelope-from cm--jrk@merseymail.com) Received: from mmail by argon.connect.org.uk with local (connectmail/exim) id 1BZsX2-0004hl-Tb for ietf-mxcomp@imc.org; Mon, 14 Jun 2004 15:33:52 +0100 In-Reply-To: Subject: Re: Alternative to TXT or new RR To: "IETF MARID WG" From: "Jon Kyme" X-Mailer: [ConnectMail 3.15.6] X-connectmail-Originating-IP: 172.25.243.3 Message-Id: Date: Mon, 14 Jun 2004 15:33:52 +0100 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > wayne@midwestcs.com pointed out: > If you read that thread, you will find: > > 1) It is not clear *what* the cause of the problem is. Despite my > attempts, I have not been able to recreate the problem. > Unfortunately, I wasn't able to read into the future at the time... How about "an unexplained problem with a SPF implementation using TXT". That OK with you? I do like the rapid deployment of "WORKS FOR ME". Squash those bugs! :-) From owner-ietf-mxcomp@mail.imc.org Mon Jun 14 11:00:30 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07923 for ; Mon, 14 Jun 2004 11:00:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5EElP68041352; Mon, 14 Jun 2004 07:47:25 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5EElPTZ041350; Mon, 14 Jun 2004 07:47:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5EElLM8041320 for ; Mon, 14 Jun 2004 07:47:25 -0700 (PDT) (envelope-from aland@newgiles.nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 2CD7916FCD for ; Mon, 14 Jun 2004 10:53:39 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Ancient history (draft-ietf-marid-core-00) In-Reply-To: Your message of "Sun, 13 Jun 2004 08:01:50 PDT." <5502822.1087113710@[10.12.1.26]> Date: Mon, 14 Jun 2004 10:53:39 -0400 Message-Id: <20040614145339.2CD7916FCD@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Greg Connor wrote: > I am not sure, but I seem to remember Andrew Church published a draft for > MS records that predates RMX. http://www.rnp.br/ietf/internet-drafts/draft-church-dns-mail-sender-02.txt August, 2002. Hadmut's -00 of RMX was Dec, 2002. http://www.danisch.de/work/security/antispam.html Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Mon Jun 14 11:21:03 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08972 for ; Mon, 14 Jun 2004 11:21:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5EFBPQ4046492; Mon, 14 Jun 2004 08:11:25 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5EFBPAG046489; Mon, 14 Jun 2004 08:11:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5EFBODA046472 for ; Mon, 14 Jun 2004 08:11:24 -0700 (PDT) (envelope-from edlewis@arin.net) Received: by smtp2.arin.net (Postfix, from userid 5003) id BADCB19B5F4; Mon, 14 Jun 2004 11:10:25 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 3660F19B5F4; Mon, 14 Jun 2004 11:10:25 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.136.136.83]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1770495; Mon, 14 Jun 2004 11:11:26 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <20040612142106.GA16526@republico.estv.ipv.pt> References: <81AC085044D04B429F5FB883D94FA1AF3A1124@df-fido-msg.exchange.corp.microsof t.com> <20040612142106.GA16526@republico.estv.ipv.pt> Date: Mon, 14 Jun 2004 11:04:24 -0400 To: Luis Bruno From: Edward Lewis Subject: Re: Towards resolution on Wildcards Cc: IETF MARID WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63-arin1 (2004-01-11) on smtp2.arin.net X-Spam-Status: No, hits=-8.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63-arin1 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 15:21 +0100 6/12/04, Luis Bruno wrote: > Should we use TXT as a stopgap while the new RR isn't deployed? I think so. The purist in my wants a new type, but the realist says the spam problem can't wait the time it takes for a new type to appear in DNS. >That's the question I'd like to see answered; do you guys have any >difficulties with that? It would mean extra traffic for DNS servers who >don't support the new RR. On the receiving-MTA side, I don't see any >problem with a second query; if I'm wrong, please correct me. I don't see anything wrong with parallel queries. BIND (not DNS) does that now for A and AAAA records when getting addresses for name servers, as well as SSH. Transitions do work, e.g., ip6.int to ip6.arpa is happening. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. From owner-ietf-mxcomp@mail.imc.org Mon Jun 14 11:29:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10016 for ; Mon, 14 Jun 2004 11:29:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5EFBPwE046493; Mon, 14 Jun 2004 08:11:25 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5EFBPs5046484; Mon, 14 Jun 2004 08:11:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5EFBORb046473 for ; Mon, 14 Jun 2004 08:11:24 -0700 (PDT) (envelope-from edlewis@arin.net) Received: by smtp2.arin.net (Postfix, from userid 5003) id E071E19B7B0; Mon, 14 Jun 2004 11:10:25 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 687EA19B504; Mon, 14 Jun 2004 11:10:24 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.136.136.83]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1770494; Mon, 14 Jun 2004 11:11:25 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Mon, 14 Jun 2004 10:56:20 -0400 To: "IETF MARID WG" From: Edward Lewis Subject: Re: Alternative to TXT or new RR Cc: "IETF MARID WG" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63-arin1 (2004-01-11) on smtp2.arin.net X-Spam-Status: No, hits=-8.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63-arin1 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 18:48 -0500 6/11/04, wayne wrote: >I found 8 examples of what I would guess are the opportunistic >encryption. ... ... >They certainly need their own RR type, and may need to be shorten up >even then. OE is defining their own type: http://www.ietf.org/html.charters/ipseckey-charter.html -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. From owner-ietf-mxcomp@mail.imc.org Mon Jun 14 12:20:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12648 for ; Mon, 14 Jun 2004 12:20:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5EFx0jq056902; Mon, 14 Jun 2004 08:59:00 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5EFx08W056901; Mon, 14 Jun 2004 08:59:00 -0700 (PDT) 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.9) with ESMTP id i5EFwxkG056880 for ; Mon, 14 Jun 2004 08:59:00 -0700 (PDT) (envelope-from cm--jrk@merseymail.com) Received: from mmail by argon.connect.org.uk with local (connectmail/exim) id 1BZtrO-0003PX-JV for ietf-mxcomp@imc.org; Mon, 14 Jun 2004 16:58:58 +0100 In-Reply-To: <20040614145339.2CD7916FCD@mail.nitros9.org> Subject: Re: Ancient history (draft-ietf-marid-core-00) To: ietf-mxcomp@imc.org From: "Jon Kyme" X-Mailer: [ConnectMail 3.15.6] X-connectmail-Originating-IP: 172.25.243.3 Message-Id: Date: Mon, 14 Jun 2004 16:58:58 +0100 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > Hadmut's -00 of RMX was Dec, 2002. > > http://www.danisch.de/work/security/antispam.html > Yes, according to IETF-Announce it was 2002-12-3. From owner-ietf-mxcomp@mail.imc.org Mon Jun 14 13:18:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16233 for ; Mon, 14 Jun 2004 13:18:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5EGmhGt067678; Mon, 14 Jun 2004 09:48:43 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5EGmh5U067677; Mon, 14 Jun 2004 09:48:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5EGmeK1067652 for ; Mon, 14 Jun 2004 09:48:42 -0700 (PDT) (envelope-from edlewis@arin.net) Received: by smtp2.arin.net (Postfix, from userid 5003) id 6B79219BBE8; Mon, 14 Jun 2004 12:47:39 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 8495A19BBDF for ; Mon, 14 Jun 2004 12:47:38 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.136.136.83]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1770965; Mon, 14 Jun 2004 12:48:40 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: Date: Mon, 14 Jun 2004 12:28:56 -0400 To: ietf-mxcomp@imc.org From: Edward Lewis Subject: comments on SPF Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63-arin1 (2004-01-11) on smtp2.arin.net X-Spam-Status: No, hits=-8.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63-arin1 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I was asked to make some comments on the SPF document. These comments are based on the -01 of draft-mengwong-spf. Section 2.1: # If additional records are used, they MAY be published under the # "_spf" subdomain. See Appendix B for examples. Allowing for a second location is an invitation to encourage chained subsequent queries. E.g., looking at the "normal place" and then if needed the second place. If the strategy is to ask for all record types and all locations simultaneously, then we'll have many queries issued per event (and per answer). Multiple parallel queries are done already and aren't the death of any protocol, but if taken to extremes can be a problem. It would be really good to limit the number of places/types sought to just what is needed. # Note: Many nameserver implementations will silently split long # strings in TXT records into several shorter strings. I don't know if this will be an issue, but if a name server ever splits into multiple TXT RR's you'll need to make people aware of that. In DNS terminology, ever since RFC 2181, we've talked about "sets" of RR's and not single RR's as the unit of work in DNS. RR sets are sets - no duplicates and no guaranteed ordering, so if there are multiple TXT RR's involved, spf would have to do it's own reassembly. This may be a non-issue, but it was one that hung up review of the OE document on how it experimentally used TXT RR's. Section 2.2.2: # If a domain has no SPF record, clients MAY substitute SPF data from # a parent domain ONLY IF the appropriate parent domain's SPF record # sets "match_subdomains=yes". For example, if no SPF record is # found for "workstation.example.com", clients MAY proceed to # automatically query "example.com". The appropriate parent domain # to fallback on MUST be determined according to the DNS zone cut. This relates to something that came up in the early days of DNSSEC. It's not a good idea to assume that there's any relationship between the parent and child of a zone cut. In DNS naming, there's a hierarchy, but that doesn't translate into any other hierarchy of authority. E.g., the root zone does not represent the center of the Internet nor the center of email processing. The point is that it's not wise to let the protocol try to make the parent of a delegation look like the parent of the child organization. If you want to allow child zones to follow the parent zone's rules, then I'd recommend a two part mechanism. Both side have to consent, it's not fair for just one side to unilaterally rely or speak for the other. Section 3: # Error: indicates an error during lookup; an MTA SHOULD reject the # message using a transient failure code, such as 450. # # Unknown: indicates incomplete processing: an MTA MUST proceed as # if a domain did not publish SPF data. Does this include a DNS server failures? E.g., let's say that the com servers are down but there is an example.com server running. You can't get to it - but it's not a fault of the example.com organization. Should mail be dropped in this case? (Or am I confusing something?) Section 4.4: # 4.4 "a" Does this cover IP4 and IP6? Section 4.8: # ... DNS A record query ... and/or AAAA? Section 7.1: # Use of the "t" macro in DNS lookups would greatly reduce the # effectiveness of DNS caching. The "t" macro is only allowed in # explanation records. The value of the "t" macro SHOULD NOT change # during the evaluation of a given SPF record. With "t = current timestamp in UTC epoch seconds notation" I don't understand the problem. I'm not questioning the statement, I just don't see why this is given the text that is present. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. From owner-ietf-mxcomp@mail.imc.org Mon Jun 14 13:36:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16877 for ; Mon, 14 Jun 2004 13:36:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5EHInJe074433; Mon, 14 Jun 2004 10:18:50 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5EHInaC074432; Mon, 14 Jun 2004 10:18:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from republico.estv.ipv.pt (tunadao.ipv.pt [193.137.7.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5EHImrL074425 for ; Mon, 14 Jun 2004 10:18:49 -0700 (PDT) (envelope-from lbruno@republico.estv.ipv.pt) Received: from lbruno by republico.estv.ipv.pt with local (Exim 4.22) id 1BZv7g-0000rw-Cc for ietf-mxcomp@imc.org; Mon, 14 Jun 2004 18:19:52 +0100 Date: Mon, 14 Jun 2004 18:19:52 +0100 From: Luis Bruno To: ietf-mxcomp@imc.org Subject: Re: Alternative to TXT or new RR was: Comments on draft-ietf-marid-core-01 xml use Message-ID: <20040614171952.GA1973@republico.estv.ipv.pt> Mail-Followup-To: ietf-mxcomp@imc.org References: <001301c450a7$b87655e0$6401a8c0@hdev1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001301c450a7$b87655e0$6401a8c0@hdev1> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'd like to hear comments on this, even flames or pointers to threads I've missed. If this discussion is in any way out of order now, I apologise; but do tell me to shut up in that case. Hector Santos wrote: > I don't know why the TXT vs. RR is an issue. From my point of view, creating a new RR type is the correct approach. The problem lies with Microsoft's existing design, which makes the deployment of a new RR type harder. It's actually a moot point; my personal peeve is the representation of the MARID information: you could place the binary information in a TXT record, as I see it. I'd like to have the MARID information in a binary representation; the current design favors a textual representation, with a lot of overhead. I'll use hotmail.com as an example. You can see the information at: http://www.lessspam.org/CallerIDPolicyWizard/?domain=hotmail.com [37 records snipped] The information occupies 537 bytes without tags. In binary, that would be 185 bytes: 5 binary octets * 37 records. The work on representing prefix lists has already been made by RFC3123. As I see it, it supports the SPF a, mx, ip4 and ip6 mechanisms. Each of the prefixes in that list can be negated. I think this is a better way to publish the MARID information. If we use TXT for that or not, it seems irrelevant. As I understand it, we could use TXT to publish binary information: RFC1035 seems to allow arbitrary information in TXT RDATA. -- Luis Bruno UTM: 29T 629481E 4511776N 576m From owner-ietf-mxcomp@mail.imc.org Mon Jun 14 14:11:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18688 for ; Mon, 14 Jun 2004 14:11:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5EHlSwK080705; Mon, 14 Jun 2004 10:47:28 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5EHlSDC080704; Mon, 14 Jun 2004 10:47:28 -0700 (PDT) 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.9) with ESMTP id i5EHlFAm080536 for ; Mon, 14 Jun 2004 10:47:28 -0700 (PDT) (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 i5EHl0wI018623; Mon, 14 Jun 2004 10:47:00 -0700 (PDT) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 14 Jun 2004 10:47:00 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Greg Connor'" , Jim Lyon Cc: ietf-mxcomp@imc.org Subject: RE: Ancient history (draft-ietf-marid-core-00) Date: Mon, 14 Jun 2004 10:47:00 -0700 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: Paul Vixie sent a draft to the DNSEXT WG mailing list and again to ASRG when it started. The Vixie draft credits Jim Miller for the original idea. > --Jim Lyon wrote: > > > 12. Acknowledgements > > > > Variations on the idea of using a DNS record to check > the legitimacy > > of an email address have occurred multiple times. The > earliest known > > work is [RMX]; others include [SPF} and [CallerID]. > > > > The current document borrows heavily from each of the above, and > > incorporates many ideas proposed by many members of the > MARID working > > group. > > > I am not sure, but I seem to remember Andrew Church published > a draft for > MS records that predates RMX. > > There was also a proposal by Paul Vixie but I don't know if it was > published. > > -- > Greg Connor > From owner-ietf-mxcomp@mail.imc.org Mon Jun 14 15:28:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23473 for ; Mon, 14 Jun 2004 15:28:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5EJAqLD097935; Mon, 14 Jun 2004 12:10:52 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5EJAqUA097934; Mon, 14 Jun 2004 12:10:52 -0700 (PDT) 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.9) with SMTP id i5EJApvw097885 for ; Mon, 14 Jun 2004 12:10:51 -0700 (PDT) (envelope-from maex@Space.Net) Received: (qmail 41983 invoked by uid 1013); 14 Jun 2004 19:10:45 -0000 Date: Mon, 14 Jun 2004 21:10:45 +0200 From: Markus Stumpf To: IETF MARID WG Subject: Re: MTAmark (was: Reality check please) Message-ID: <20040614191045.GA39184@Space.Net> References: <20040609215845.GO99969@Space.Net> <20040610150711.GA9692@zardoc.esmtp.org> <002101c44fa9$a7feaf90$6401a8c0@hdev1> <20040611230411.GC77339@Space.Net> <004101c4504b$d24a7200$6401a8c0@hdev1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004101c4504b$d24a7200$6401a8c0@hdev1> 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 Sat, Jun 12, 2004 at 03:06:39AM -0400, Hector Santos wrote: > > Give me one site that really utilizes the client side of SPF? > Not sure what this question ask. Let me see one serious site that rejects mail from AOL.com because the IP that sent the message was not on the SPF list. > > Serious business companies CANNOT do it, as it will raise their false > positive > > rate and nobody will do that. > > Whats the difference between a serious business and a just plain anyone else > running a legitimate mail server servicing end-users, internal or otherwise? Nothing. Neither of these can reject messages based on SPF information. I, as a private person can do, if I don't care to piss off some friends. > Local User Validation is (should be) a important part of the anti-spam > effort/design. Not only will it help eliminate the overhead in MARID lookup > requirements but it will also reduce your bounce requirements which is a > major part of the SORBIG-based virus dual-tier distribution logic. For Sober use: if HELO.host == MAILFROM.username"."MAILFROM.tld if MAILFROM.username == MAILFROM.domain pass() else reject() but I agree on the local user validation. That's the reason why most spam engines use the reverse MX path. We have a special setup with a special backup MX and catch about 40% of all spam that way. \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@mail.imc.org Mon Jun 14 15:57:13 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24974 for ; Mon, 14 Jun 2004 15:57:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5EJYd36002911; Mon, 14 Jun 2004 12:34:39 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5EJYdk1002910; Mon, 14 Jun 2004 12:34:39 -0700 (PDT) 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.9) with ESMTP id i5EJYapv002896 for ; Mon, 14 Jun 2004 12:34:38 -0700 (PDT) (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.34) id 1BZxDu-0000uq-De for ietf-mxcomp@imc.org; Mon, 14 Jun 2004 14:34:40 -0500 To: ietf-mxcomp@imc.org References: <001301c450a7$b87655e0$6401a8c0@hdev1> <20040614171952.GA1973@republico.estv.ipv.pt> From: wayne Reply-To: "IETF MARID WG" Date: Mon, 14 Jun 2004 14:34:26 -0500 In-Reply-To: <20040614171952.GA1973@republico.estv.ipv.pt> (Luis Bruno's message of "Mon, 14 Jun 2004 18:19:52 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: Alternative to TXT or new RR was: Comments on draft-ietf-marid-core-01 xml use Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-4.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <20040614171952.GA1973@republico.estv.ipv.pt> Luis Bruno writes: > I'd like to have the MARID information in a binary representation; the > current design favors a textual representation, with a lot of overhead. libspf-alt currently byte-compiles all SPF records into a compact, network portable, binary format that requires no text parsing. > I'll use hotmail.com as an example. You can see the information at: > http://www.lessspam.org/CallerIDPolicyWizard/?domain=hotmail.com > [37 records snipped] > > The information occupies 537 bytes without tags. > In binary, that would be 185 bytes: 5 binary octets * 37 records. Hotmail's email policy in: XML: 1040 bytes SPF: 776 bytes (XML * 1.32) byte-compiled: 240 bytes (XML * 4.33, SPF * 3.23) -wayne From owner-ietf-mxcomp@mail.imc.org Mon Jun 14 16:15:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26258 for ; Mon, 14 Jun 2004 16:15:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5EJuTIV007454; Mon, 14 Jun 2004 12:56:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5EJuTIP007453; Mon, 14 Jun 2004 12:56:29 -0700 (PDT) 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.9) with ESMTP id i5EJuSGE007447 for ; Mon, 14 Jun 2004 12:56:28 -0700 (PDT) (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.34) id 1BZxYz-00019c-0E for ietf-mxcomp@imc.org; Mon, 14 Jun 2004 14:56:32 -0500 To: "IETF MARID WG" References: From: wayne Reply-To: "IETF MARID WG" Date: Mon, 14 Jun 2004 14:56:12 -0500 In-Reply-To: (Edward Lewis's message of "Mon, 14 Jun 2004 12:28:56 -0400") 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 (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: comments on SPF Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-4.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In Edward Lewis writes: > Section 2.1: > > # If additional records are used, they MAY be published under the > # "_spf" subdomain. See Appendix B for examples. > > Allowing for a second location is an invitation to encourage chained > subsequent queries. E.g., looking at the "normal place" and then if > needed the second place. You snipped off the first sentence in that paragraph: # In unusual situations, directives may require additional DNS records. If, for example, you are hotmail and your list of outgoing IP addresses is too large to fit in a single 512B UDP DNS packet, you should split the information into two (or more) records. These additional records need to be placed somewhere, and the SPF spec recommends a spot for them. The vast majority of domains won't need to do this. This doesn't have anything to do with looking two differen places for stuff, the first spot will direct you to whatever the second place is that you need to look. > # Note: Many nameserver implementations will silently split long > # strings in TXT records into several shorter strings. > > I don't know if this will be an issue, but if a name server ever > splits into multiple TXT RR's you'll need to make people aware of > that. I have investigated this issue some, and from what I can tell, this doesn't happen. I must admit, that it I was involved with SPF a long time before I found out that a single TXT record can have *multiple* substrings. Each substring is a single byte length, followed by that much data. So, a TXT record like '@ TXT "hello" "email" "world"' is really three different substrings, and they are not concatinated together in the resolver. (See rfc1035 for details) > Section 2.2.2: > > # If a domain has no SPF record, clients MAY substitute SPF data from > # a parent domain ONLY IF the appropriate parent domain's SPF record > # sets "match_subdomains=yes". For example, if no SPF record is > # found for "workstation.example.com", clients MAY proceed to > # automatically query "example.com". The appropriate parent domain > # to fallback on MUST be determined according to the DNS zone cut. > > This relates to something that came up in the early days of > DNSSEC. It's not a good idea to assume that there's any relationship > between the parent and child of a zone cut. [...] I don't think this paragraph is very clear, but the idea is that you would never cross a zone cut boundary, there is no parent/child zone cut involved. If workstation.example.com is in a *dfferent* zone cut than example.com (e.g. it has been delegated), then it would not be allowed to use an SPF record from example.com for workstation.example.com. > Section 3: > > # Error: indicates an error during lookup; an MTA SHOULD reject the > # message using a transient failure code, such as 450. > # > # Unknown: indicates incomplete processing: an MTA MUST proceed as > # if a domain did not publish SPF data. > > Does this include a DNS server failures? E.g., let's say that the com > servers are down but there is an example.com server running. You > can't get to it - but it's not a fault of the example.com > organization. Should mail be dropped in this case? (Or am I > confusing something?) The "error" result is for DNS server failures and other temporary failures like running out of process/memory/whatever. In this case, the email should not be dropped, but the client MTA should be told (via the 450 STMP code) to try again later. The "unknown" result is for things like syntax errors and such where simply retrying later will be unlikely to change anything. > Section 4.4: > > # 4.4 "a" > > Does this cover IP4 and IP6? Yes. See section 4.3: # If the SMTP connection is IPv6, read "AAAA lookup" for "A lookup", # except where "A" lookups are explicitly specified. > Section 7.1: > > # Use of the "t" macro in DNS lookups would greatly reduce the > # effectiveness of DNS caching. The "t" macro is only allowed in > # explanation records. The value of the "t" macro SHOULD NOT change > # during the evaluation of a given SPF record. > > With "t = current timestamp in UTC epoch seconds notation" I don't > understand the problem. I'm not questioning the statement, I just > don't see why this is given the text that is present. The problem is with using malicoius SPF record such as: v=spf1 a:%{t}.victim.com a:%{t}.victim.com a:%{t}.victim.com ..." Such a SPF record could be used for DoS attacks. There is no good reason to use the timestamp as part of an SPF mechanism, and if each evaluation of %{t} is different, it will create a different DNS lookup. -wayne From owner-ietf-mxcomp@mail.imc.org Mon Jun 14 16:28:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27797 for ; Mon, 14 Jun 2004 16:28:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5EKAnXa010212; Mon, 14 Jun 2004 13:10:49 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5EKAnuM010211; Mon, 14 Jun 2004 13:10:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from orca.agcom.amgreetings.com (orca.ag.com [207.58.192.149]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5EKAmZA010176 for ; Mon, 14 Jun 2004 13:10:48 -0700 (PDT) (envelope-from MWeiner@ag.com) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Alternative to TXT or new RR was: Comments on draft-ietf-marid-core-01 xml use Date: Mon, 14 Jun 2004 16:10:46 -0400 Message-ID: <4FD2C985D5E2A642AE25823DFD61C2B00139F1C5@orca.agcom.amgreetings.com> Thread-Topic: Alternative to TXT or new RR was: Comments on draft-ietf-marid-core-01 xml use Thread-Index: AcRSRu1sNY68Hu9rR2KWDLrOf0D6AgABKa2A From: "MW Mike Weiner \(5028\)" To: "IETF MARID WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5EKAmZA010206 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > I'll use hotmail.com as an example. You can see the information at: > http://www.lessspam.org/CallerIDPolicyWizard/?domain=hotmail.com > [37 records snipped] > > The information occupies 537 bytes without tags. > In binary, that would be 185 bytes: 5 binary octets * 37 records. Hotmail's email policy in: XML: 1040 bytes SPF: 776 bytes (XML * 1.32) byte-compiled: 240 bytes (XML * 4.33, SPF * 3.23) Thanks whomever posted that URL, very handy. Thank you Michael Weiner From owner-ietf-mxcomp@mail.imc.org Mon Jun 14 17:19:52 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03224 for ; Mon, 14 Jun 2004 17:19:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5EKp6PJ018763; Mon, 14 Jun 2004 13:51:06 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5EKp62D018762; Mon, 14 Jun 2004 13:51:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5EKp56m018750 for ; Mon, 14 Jun 2004 13:51:05 -0700 (PDT) (envelope-from edlewis@arin.net) Received: by smtp2.arin.net (Postfix, from userid 5003) id B9AF619B48F; Mon, 14 Jun 2004 16:50:02 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 59AAD19B370; Mon, 14 Jun 2004 16:50:01 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.136.136.83]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1772124; Mon, 14 Jun 2004 16:51:06 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Mon, 14 Jun 2004 16:30:54 -0400 To: "IETF MARID WG" From: Edward Lewis Subject: Re: comments on SPF Cc: "IETF MARID WG" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63-arin1 (2004-01-11) on smtp2.arin.net X-Spam-Status: No, hits=-8.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63-arin1 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 14:56 -0500 6/14/04, wayne wrote: >You snipped off the first sentence in that paragraph: ># In unusual situations, directives may require additional DNS records. I guess I had left that off because it didn't make sense to me. The following part of your note does clarify it - perhaps including the example in the draft would help. >If, for example, you are hotmail and your list of outgoing IP >addresses is too large to fit in a single 512B UDP DNS packet, you >should split the information into two (or more) records. These >additional records need to be placed somewhere, and the SPF spec >recommends a spot for them. > >The vast majority of domains won't need to do this. This doesn't have >anything to do with looking two differen places for stuff, the first >spot will direct you to whatever the second place is that you need to >look. In that case, why not just rely on the DNS RR set, putting multiple RR's in the same location? You'd have to define how to reassemble/combine them. ... In response to the thought of multiple TXT RR's... >I have investigated this issue some, and from what I can tell, this >doesn't happen. Looking at the first item in this reply, perhaps it would be something to pursue. 'Course, I'm not a fan of using the TXT record, but looking on one place and getting many is preferable to having to "chain" lookups to get more. >I don't think this paragraph is very clear, but the idea is that you >would never cross a zone cut boundary, there is no parent/child zone >cut involved. If workstation.example.com is in a *dfferent* zone cut >than example.com (e.g. it has been delegated), then it would not be >allowed to use an SPF record from example.com for >workstation.example.com. Okay - I tripped over the mixture of "parent domain" and the zone cut. >> Section 4.4: >> >> # 4.4 "a" >> >> Does this cover IP4 and IP6? > >Yes. See section 4.3: > ># If the SMTP connection is IPv6, read "AAAA lookup" for "A lookup", ># except where "A" lookups are explicitly specified. In section 4.8, you mention "A" lookup. Is AAAA explicitly not done in that case? While looking at that I noticed I marked up 4.6 (but didn't dog ear it). It says "Check all validated hostnames ... If any do ..." Instead of checking all, why not check until one is found that satisfies the condition? >The problem is with using malicoius SPF record such as: > > v=spf1 a:%{t}.victim.com a:%{t}.victim.com a:%{t}.victim.com ..." > >Such a SPF record could be used for DoS attacks. There is no good >reason to use the timestamp as part of an SPF mechanism, and if each >evaluation of %{t} is different, it will create a different DNS >lookup. I see. I guess I never say anything that explained the "t" other than the definition as equaling the current time stamp and then the warning about it's impact on DNS. Maybe it would be clear to show an example or explain a "positive" use for the macro. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. From owner-ietf-mxcomp@mail.imc.org Mon Jun 14 17:51:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05219 for ; Mon, 14 Jun 2004 17:51:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ELYotJ027249; Mon, 14 Jun 2004 14:34:50 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5ELYocR027248; Mon, 14 Jun 2004 14:34:50 -0700 (PDT) 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.9) with ESMTP id i5ELYnIg027241 for ; Mon, 14 Jun 2004 14:34:49 -0700 (PDT) (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 i5ELYsfb007531; Mon, 14 Jun 2004 14:34:54 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 14 Jun 2004 14:34:54 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Markus Stumpf'" , IETF MARID WG Subject: RE: MTAmark (was: Reality check please) Date: Mon, 14 Jun 2004 14:34:44 -0700 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: > On Sat, Jun 12, 2004 at 03:06:39AM -0400, Hector Santos wrote: > > > Give me one site that really utilizes the client side of SPF? > > Not sure what this question ask. > > Let me see one serious site that rejects mail from AOL.com > because the IP > that sent the message was not on the SPF list. Wrong test. There are plenty of sites that now accept mail from AOL as genuine because the IP address is correct. Otherwise it goes into the spam filter with a huge penalty attached. Later on we will be defining a protocol to notify a site when mail from that source is failing authentication. Later on lots of things will be happening that makes the MARID checking add a lot more value. Phill From owner-ietf-mxcomp@mail.imc.org Mon Jun 14 17:53:01 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05417 for ; Mon, 14 Jun 2004 17:53:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ELVAwd026474; Mon, 14 Jun 2004 14:31:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5ELVAcl026473; Mon, 14 Jun 2004 14:31:10 -0700 (PDT) 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.9) with ESMTP id i5ELVAkh026466 for ; Mon, 14 Jun 2004 14:31:10 -0700 (PDT) (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 i5ELVCiV019575; Mon, 14 Jun 2004 14:31:12 -0700 (PDT) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 14 Jun 2004 14:31:12 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Luis Bruno'" , ietf-mxcomp@imc.org Subject: RE: Alternative to TXT or new RR was: Comments on draft-ietf-mari d-core-01 xml use Date: Mon, 14 Jun 2004 14:31:09 -0700 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: Why on earth are we even discussing this? There is no difference whatsoever between a 1 byte packet and a 500 byte packet. Either data fits in a packet or it does not. Only the number of packets has significance when considering the impact on the network. The hotmail policy is an outlier, there are perhaps ten ISPs of similar scope. Nobody disputes the fact that most policies will easily fit in a single packet - even without dns extensions. Once read the hotmail policy will be cached for at least 24 hours. If AOL has a thousand servers accepting mail then worst case the difference between binary and text amounts to 1 packet a day on their external network and maybe a couple of thousand on their internal network. Thats less than a single powerpoint attachement. This is control information we are discussing here. This is a tiny fraction of the message data volume. > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Luis Bruno > Sent: Monday, June 14, 2004 1:20 PM > To: ietf-mxcomp@imc.org > Subject: Re: Alternative to TXT or new RR was: Comments on > draft-ietf-marid-core-01 xml use > > > > I'd like to hear comments on this, even flames or pointers to threads > I've missed. If this discussion is in any way out of order now, I > apologise; but do tell me to shut up in that case. > > Hector Santos wrote: > > I don't know why the TXT vs. RR is an issue. > > From my point of view, creating a new RR type is the correct approach. > The problem lies with Microsoft's existing design, which makes the > deployment of a new RR type harder. > > It's actually a moot point; my personal peeve is the representation of > the MARID information: you could place the binary information in a TXT > record, as I see it. > > I'd like to have the MARID information in a binary representation; the > current design favors a textual representation, with a lot of > overhead. > > I'll use hotmail.com as an example. You can see the information at: > http://www.lessspam.org/CallerIDPolicyWizard/?domain=hotmail.com > [37 records snipped] > > The information occupies 537 bytes without tags. > In binary, that would be 185 bytes: 5 binary octets * 37 records. > > The work on representing prefix lists has already been made > by RFC3123. > As I see it, it supports the SPF a, mx, ip4 and ip6 mechanisms. Each > of the prefixes in that list can be negated. > > I think this is a better way to publish the MARID > information. If we use > TXT for that or not, it seems irrelevant. As I understand it, we could > use TXT to publish binary information: RFC1035 seems to allow > arbitrary > information in TXT RDATA. > > -- > Luis Bruno UTM: 29T 629481E > 4511776N 576m > From owner-ietf-mxcomp@mail.imc.org Mon Jun 14 18:19:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07946 for ; Mon, 14 Jun 2004 18:19:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ELwuTG031643; Mon, 14 Jun 2004 14:58:56 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5ELwuxV031642; Mon, 14 Jun 2004 14:58:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from aismtp2g.bellsouth.com (aismtp2g.bellsouth.com [139.76.165.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ELwt4q031615 for ; Mon, 14 Jun 2004 14:58:56 -0700 (PDT) (envelope-from Damon.Sauer@BELLSOUTH.COM) Received: from 01al10015010113.ad.bls.com ([90.152.52.35] [90.152.52.35]) by aismtp2g.bellsouth.com with ESMTP; Mon, 14 Jun 2004 17:58:52 -0400 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Importance: normal Subject: [Levity] RE: Alternative to TXT or new RR was: Comments on draft-ietf-marid-core-01 xml use X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Date: Mon, 14 Jun 2004 16:58:42 -0500 Message-Id: <38363D9940D92A458010AAE24D162EB903003297@bremocog-55> Thread-Topic: [Levity] RE: Alternative to TXT or new RR was: Comments on draft-ietf-marid-core-01 xml use Thread-Index: AcRSV08H5D09Hxf+QUG1oiwyRdckhAAAjLFQ From: "Sauer, Damon" To: "Hallam-Baker, Phillip" , "Luis Bruno" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5ELwu4q031637 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit HEY! (tongue being inserted in cheek) Snippet from the WINZIP FAQ- By contrast, some types of data (such as text files and picture files in the BMP format that the Microsoft Paint program uses) (insert) can often be compressed by 90% or more; some types (such as program files) are often compressed by 50%. Let's just ZIP'm ;) Call it. aRRGzip StuffItXML ZIPSPIF JustZIPitMardid Regards, Damon Sauer -----Original Message----- From: owner-ietf-mxcomp@mail.imc.org [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of Hallam-Baker, Phillip Sent: Monday, June 14, 2004 5:31 PM To: 'Luis Bruno'; ietf-mxcomp@imc.org Subject: RE: Alternative to TXT or new RR was: Comments on draft-ietf-marid-core-01 xml use Why on earth are we even discussing this? There is no difference whatsoever between a 1 byte packet and a 500 byte packet. Either data fits in a packet or it does not. Only the number of packets has significance when considering the impact on the network. The hotmail policy is an outlier, there are perhaps ten ISPs of similar scope. Nobody disputes the fact that most policies will easily fit in a single packet - even without dns extensions. Once read the hotmail policy will be cached for at least 24 hours. If AOL has a thousand servers accepting mail then worst case the difference between binary and text amounts to 1 packet a day on their external network and maybe a couple of thousand on their internal network. Thats less than a single powerpoint attachement. This is control information we are discussing here. This is a tiny fraction of the message data volume. > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Luis Bruno > Sent: Monday, June 14, 2004 1:20 PM > To: ietf-mxcomp@imc.org > Subject: Re: Alternative to TXT or new RR was: Comments on > draft-ietf-marid-core-01 xml use > > > > I'd like to hear comments on this, even flames or pointers to threads > I've missed. If this discussion is in any way out of order now, I > apologise; but do tell me to shut up in that case. > > Hector Santos wrote: > > I don't know why the TXT vs. RR is an issue. > > From my point of view, creating a new RR type is the correct approach. > The problem lies with Microsoft's existing design, which makes the > deployment of a new RR type harder. > > It's actually a moot point; my personal peeve is the representation of > the MARID information: you could place the binary information in a TXT > record, as I see it. > > I'd like to have the MARID information in a binary representation; the > current design favors a textual representation, with a lot of > overhead. > > I'll use hotmail.com as an example. You can see the information at: > http://www.lessspam.org/CallerIDPolicyWizard/?domain=hotmail.com > [37 records snipped] > > The information occupies 537 bytes without tags. > In binary, that would be 185 bytes: 5 binary octets * 37 records. > > The work on representing prefix lists has already been made > by RFC3123. > As I see it, it supports the SPF a, mx, ip4 and ip6 mechanisms. Each > of the prefixes in that list can be negated. > > I think this is a better way to publish the MARID > information. If we use > TXT for that or not, it seems irrelevant. As I understand it, we could > use TXT to publish binary information: RFC1035 seems to allow > arbitrary > information in TXT RDATA. > > -- > Luis Bruno UTM: 29T 629481E > 4511776N 576m > ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 113 From owner-ietf-mxcomp@mail.imc.org Mon Jun 14 19:03:39 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11092 for ; Mon, 14 Jun 2004 19:03:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5EMqraq042347; Mon, 14 Jun 2004 15:52:53 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5EMqrZ9042346; Mon, 14 Jun 2004 15:52:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from data.6o4.ca (mail.6o4.ca [24.207.0.211]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5EMqqPR042331 for ; Mon, 14 Jun 2004 15:52:52 -0700 (PDT) (envelope-from jcouzens@6o4.ca) Received: (qmail 2697 invoked by uid 1006); 14 Jun 2004 22:52:56 -0000 Received: from unknown (HELO nas1) (24.207.1.85) by data.6o4.ca with SMTP; 14 Jun 2004 22:52:56 -0000 Received-SPF: neutral (data.6o4.ca: domain of jcouzens@6o4.ca is neutral about designating 24.207.1.85 as permitted sender) Subject: Why should I link a library thats larger than my ENTIRE MTA? From: James Couzens Reply-To: jcouzens@6o4.ca To: MXCOMP LIST Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-aawM1czZDqzPBWtxr0hp" Message-Id: <1087253601.12374.29.camel@antitrust.6o4.ca> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 14 Jun 2004 15:53:21 -0700 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-aawM1czZDqzPBWtxr0hp Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hello everyone. Greetings and salutations to you all. Since we are on the fine topic of XML, I would like to throw in my two bits if you please. Rather than quibbling about whether XML belongs in DNS or not, I would like to raise a more important question. Since I've found illustrations to be useful in helping others to understand things, and I myself personally benefit from them I would like to use one here, a visual one. ---- START VISUAL AID ---- [james@lore] / $ du -sh /var/qmail/bin 1010K /var/qmail/bin [james@lore] / $ ls -lah /usr/lib | grep libspf.so.1.0.1 -rwxr-xr-x 1 root root 65K Jun 14 15:40 libspf.so Smashing! 1010K in qmail binaries, to be fair my binaries already include my Qmail-SPF patch, as well as various other patches to bring it in line with all the "hacks" made to SMTP and POP3 etc.. over the years. [james@lore] / $ ls -lah /usr/lib | grep libxml2.a -rwxr-xr-x 1 root root 1.3M Jun 4 18:42 libxml2.so.2.6.9 Lets pretend we're talking about money instead of bytes Qmail ... $ 1,010 Qmail ... $ 1,010 libSPF .. $ 65 libXML2 . $ 1,300 spfid?! ????? ----- ----- Total ... $ 1,075 Total ... $ 2,300 ---- END VISUAL AID ---- Now can anyone see whats wrong with this picture, because *I* for one certainly can. So I am supposed to link a 1.3M library against my MTA, ___JUST___ to validate senders? Can someone please explain this to me?=20 I would ask why XML is even being considered but I'm not out looking to start a flame, I simply would like to illustrate to everyone here that there are some very deeply wrong things with XML, completely outside the realm of publishing XML within DNS. If this is not the appropriate time to be raising this point then I apologize and please continue with the current discussion and I shall attempt to resume this at another date and time. Thank you all for reading. Cheers, James --=20 James Couzens, Programmer ----------------------------------------------------------------- http://libspf.org -- ANSI C Sender Policy Framework library http://libsrs.org -- ANSI C Sender Rewriting Scheme library ----------------------------------------------------------------- PGP: http://gpg.mit.edu:11371/pks/lookup?op=3Dget&search=3D0x6E0396B3 --=-aawM1czZDqzPBWtxr0hp Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBAzixgyJv1gm4DlrMRAhtcAJwI4Nk/G3kzJAUm4oMRQ8nPWYlBGACfVQa8 PLH2bMWyb8ibXWUnVh4/TnM= =j7em -----END PGP SIGNATURE----- --=-aawM1czZDqzPBWtxr0hp-- From owner-ietf-mxcomp@mail.imc.org Mon Jun 14 19:13:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11407 for ; Mon, 14 Jun 2004 19:13:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5EMsrBh042742; Mon, 14 Jun 2004 15:54:53 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5EMsraj042741; Mon, 14 Jun 2004 15:54:53 -0700 (PDT) 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.9) with ESMTP id i5EMsqSf042731 for ; Mon, 14 Jun 2004 15:54:52 -0700 (PDT) (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.34) id 1Ba0Lg-0003N1-Da for ietf-mxcomp@imc.org; Mon, 14 Jun 2004 17:54:57 -0500 To: "IETF MARID WG" References: From: wayne Reply-To: "IETF MARID WG" Date: Mon, 14 Jun 2004 17:54:40 -0500 In-Reply-To: (Edward Lewis's message of "Mon, 14 Jun 2004 16:30:54 -0400") 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 (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: comments on SPF Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-4.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In Edward Lewis writes: > At 14:56 -0500 6/14/04, wayne wrote: > > In that case, why not just rely on the DNS RR set, putting multiple > RR's in the same location? You'd have to define how to > reassemble/combine them. Because what makes the records "too large" is that they no longer fit in a 512B UDP packet. Putting them in a RR set won't help. Falling back to TCP is more expensive than several UDP DNS lookups due to the three-way TCP handshake setup and the four-way TCP teardown. > In section 4.8, you mention "A" lookup. Is AAAA explicitly not done > in that case? Sorry, I didn't check that reference. Yes, the exists: mechanism explicitly checks *only* A records, even if the MTA connection is via IPv6. This is to maintain compatibility with already existing DNS blacklists and whitelists. > While looking at that I noticed I marked up 4.6 (but didn't dog ear > it). It says "Check all validated hostnames ... If any do ..." > Instead of checking all, why not check until one is found that > satisfies the condition? I'm not sure why Meng phrased this section the way he did, but you can certainly short-circuit the evaluation. >>The problem is with using malicoius SPF record such as: >> >> v=spf1 a:%{t}.victim.com a:%{t}.victim.com a:%{t}.victim.com ..." >> >>Such a SPF record could be used for DoS attacks. There is no good >>reason to use the timestamp as part of an SPF mechanism, and if each >>evaluation of %{t} is different, it will create a different DNS >>lookup. > > I see. I guess I never say anything that explained the "t" other than > the definition as equaling the current time stamp and then the warning > about it's impact on DNS. Maybe it would be clear to show an example > or explain a "positive" use for the macro. Personally, I'm not that attached to the %{t} macro variable, so maybe I'm underselling it. The idea is that it would be used in conjunction with the exp= (explanation) modifier. While the (macro expanded) explanation text can be anything, typically it is a URL that someone who had their email rejected can go to for a more complete explanation. The timestamp can be added as an argument to the cgi-script, along with the IP address, the email address that was used, etc. The timestamp could then be used to narrow down the exact email that was sent, or to format it in a localized format, or whatever. The %{t} macro variable is an example of something that I think could be gotten rid of from SPF without any problems, but then, it also is trivial to implement. -wayne From owner-ietf-mxcomp@mail.imc.org Mon Jun 14 19:33:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12630 for ; Mon, 14 Jun 2004 19:33:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ENNGbu047973; Mon, 14 Jun 2004 16:23:16 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5ENNGZg047972; Mon, 14 Jun 2004 16:23:16 -0700 (PDT) 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.9) with SMTP id i5ENNE4J047959 for ; Mon, 14 Jun 2004 16:23:15 -0700 (PDT) (envelope-from maex@Space.Net) Received: (qmail 55156 invoked by uid 1013); 14 Jun 2004 23:23:19 -0000 Date: Tue, 15 Jun 2004 01:23:19 +0200 From: Markus Stumpf To: IETF MARID WG Subject: Re: MTAmark (was: Reality check please) Message-ID: <20040614232319.GD46577@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 Mon, Jun 14, 2004 at 02:34:44PM -0700, Hallam-Baker, Phillip wrote: > There are plenty of sites that now accept mail from AOL as genuine > because the IP address is correct. Otherwise it goes into the spam > filter with a huge penalty attached. Wrong strategy. I don't want my mailserver to take over responsibility for spam mails. And I don't want my users/employees to take over responsibility and have them stolen their time and my money (as employer) having them wade around in spam mail folders sorting out false positives. Spam ist a problem of the sender. Leave it up to the sender to fix and handle the problem and do not allow the sender to shift the problem to your side, the recipient. Because of that don't accept the message the first place. We run a very facistic DNSBL. A host sends spam, he gets listed. No expire. Sometimes (very rarely) someone comes whining "but we have fixed the problem 1 year ago". So what? They harassed me and my users. They had a problem, I fixed it for me. It's not my job to trigger them permanently and ask if the problem is fixed to remove them. They had a problem, so it's their task to talk to the hosts they harassed, make an excuse and get accreditation to send eMails again. It is always the problem of the sender, don't shift it to the receiver. \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@mail.imc.org Mon Jun 14 19:50:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13432 for ; Mon, 14 Jun 2004 19:50:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ENdmAv051384; Mon, 14 Jun 2004 16:39:48 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5ENdmtE051378; Mon, 14 Jun 2004 16:39:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from polis.nbtsc.org (polis.nbtsc.org [206.168.119.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ENdldW051363 for ; Mon, 14 Jun 2004 16:39:48 -0700 (PDT) (envelope-from aredridel@nbtsc.org) Received: from betelgeuse.theinternetco.net ([206.168.119.12]) by polis.nbtsc.org with asmtp (Exim 4.34) id 1Ba13D-0006vS-57 for ietf-mxcomp@imc.org; Mon, 14 Jun 2004 17:39:39 -0600 Subject: Re: comments on SPF From: Aredridel To: IETF MARID WG In-Reply-To: References: Content-Type: text/plain Date: Mon, 14 Jun 2004 17:39:23 -0600 Message-Id: <1087256363.5461.12.camel@betelgeuse.theinternetco.net> Mime-Version: 1.0 X-Mailer: Evolution 1.5.9.1 Content-Transfer-Encoding: 7bit X-Scan-Signature: bad3feba76987eff44d9b8a458412ecc Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > > In section 4.8, you mention "A" lookup. Is AAAA explicitly not done > > in that case? > > Sorry, I didn't check that reference. > > Yes, the exists: mechanism explicitly checks *only* A records, even if > the MTA connection is via IPv6. This is to maintain compatibility > with already existing DNS blacklists and whitelists. Any reason not to query for ANY? Ari From owner-ietf-mxcomp@mail.imc.org Mon Jun 14 20:08:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14629 for ; Mon, 14 Jun 2004 20:08:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ENov7O053823; Mon, 14 Jun 2004 16:50:57 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5ENovej053822; Mon, 14 Jun 2004 16:50:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from polis.nbtsc.org (polis.nbtsc.org [206.168.119.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ENovEq053816 for ; Mon, 14 Jun 2004 16:50:57 -0700 (PDT) (envelope-from aredridel@nbtsc.org) Received: from betelgeuse.theinternetco.net ([206.168.119.12]) by polis.nbtsc.org with asmtp (Exim 4.34) id 1Ba1E4-0007G1-In for ietf-mxcomp@imc.org; Mon, 14 Jun 2004 17:50:52 -0600 Subject: Re: Why should I link a library thats larger than my ENTIRE MTA? From: Aredridel To: ietf-mxcomp@imc.org In-Reply-To: <1087253601.12374.29.camel@antitrust.6o4.ca> References: <1087253601.12374.29.camel@antitrust.6o4.ca> Content-Type: text/plain Date: Mon, 14 Jun 2004 17:50:35 -0600 Message-Id: <1087257035.5689.6.camel@betelgeuse.theinternetco.net> Mime-Version: 1.0 X-Mailer: Evolution 1.5.9.1 Content-Transfer-Encoding: 7bit X-Scan-Signature: 0d078a28f4167edd29e3d960bb0dd8b0 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > Now can anyone see whats wrong with this picture, because *I* for one > certainly can. So I am supposed to link a 1.3M library against my MTA, > ___JUST___ to validate senders? Can someone please explain this to me? > I would ask why XML is even being considered but I'm not out looking to > start a flame, I simply would like to illustrate to everyone here that > there are some very deeply wrong things with XML, completely outside the > realm of publishing XML within DNS. May I suggest a much more appropriate tool for the job? Expat, the XML parser from James Clark, is a far smaller and simpler library. libxml is a good general tool for dealing with large, complex XML related tasks. For a simple record parser, expat is a much more natural interface. A visual aid: -rwxr-xr-x 1 root root 125K Jan 19 10:23 /usr/lib/libexpat.so.0.5.0 -rwxr-xr-x 1 root root 475K Mar 11 03:28 /usr/lib/libxml.so.1.8.17 -rwxr-xr-x 1 root root 957K Apr 19 04:41 /usr/lib/libxml2.so.2.6.9 So if your libraries are a bit larger than mine (debugging symbols, likely), you're talking more like 200K. I think that's reasonable. If not, in the tradition of qmail, a little patch doing just the neccesary parsing and nothing more is likely to be quite a bit tighter. I think the 20K tossed around earlier is quite likely to be accurate to well less than an order of magnitude. You won't get the ease of extensibility, but I think that's a fair compromise. Ari From owner-ietf-mxcomp@mail.imc.org Mon Jun 14 21:03:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17779 for ; Mon, 14 Jun 2004 21:03:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5F0eD8r062764; Mon, 14 Jun 2004 17:40:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5F0eDFp062763; Mon, 14 Jun 2004 17:40:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ernie.mail-abuse.org (Ernie.mail-abuse.org [168.61.5.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5F0eDEp062736 for ; Mon, 14 Jun 2004 17:40:13 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.mail-abuse.org (DDev.mail-abuse.org [168.61.10.124]) by ernie.mail-abuse.org (8.12.0.Beta19/8.12.0) with ESMTP id i5F0eAPQ022326; Mon, 14 Jun 2004 17:40:10 -0700 (PDT) Subject: Re: Why should I link a library thats larger than my ENTIRE MTA? From: Douglas Otis To: jcouzens@6o4.ca Cc: MXCOMP LIST In-Reply-To: <1087253601.12374.29.camel@antitrust.6o4.ca> References: <1087253601.12374.29.camel@antitrust.6o4.ca> Content-Type: text/plain Message-Id: <1087260010.31443.77.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 14 Jun 2004 17:40:10 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 2004-06-14 at 15:53, James Couzens wrote: > > Now can anyone see whats wrong with this picture, because *I* for one > certainly can. So I am supposed to link a 1.3M library against my MTA, > ___JUST___ to validate senders? Can someone please explain this to me? > I would ask why XML is even being considered but I'm not out looking to > start a flame, I simply would like to illustrate to everyone here that > there are some very deeply wrong things with XML, completely outside the > realm of publishing XML within DNS. XML needs more characters to encode data than an encoding scheme specifically designed for CIDR information for outbound SMTP hosts. Something like BGP comes to mind. By making the XML headers virtual, standalone, and cast in stone by the standard, then it should not require an XML parser for the records as the syntax should then be fairly simple for basic scripts. This is not likely to happen however, as there is a desire from some vendors to leave this header open while claiming not to understand the meaning of 'standalone' in the XML standards or accept a concept of keeping this record definition a function of the standards process. The reason is to rapidly evolve this record, their stated goal, likely into a largely proprietary format where the size of the record will grow well beyond reasonable limits for DNS. Their previously stated limit for this record was 2 K bytes and then changed to no limit. : ( In this regard of size, I was not happy to see a macro language added to SPF. Simple error messages as part of refusal or standardized header notices could offer the same information. These errors should be enumerated to the degree needed and include related fields. There is also a concern as to the number of queries needed and how many times a record can be dereferenced. If this becomes even moderately used, it will seriously limit an ability to handle a mail stream with the number of transactions. Looking within the message is also based upon trust. To enable such trust, trust is forwarded to other entities, or taken over by rewriting parameters as a means to claim trust. As proposed, there is no means to publish a comprehensive list of such relationships or to detect breaks in this chain. It would be better to stop mail at its source rather than "perhaps" stopping a bounce. If this even remotely puts a dent in the amount of mail abuse, expect the system to be taken to its knees by the complexity allowed in the standard. -Doug From owner-ietf-mxcomp@mail.imc.org Mon Jun 14 21:14:39 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18244 for ; Mon, 14 Jun 2004 21:14:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5F15aA1067657; Mon, 14 Jun 2004 18:05:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5F15as3067656; Mon, 14 Jun 2004 18:05:36 -0700 (PDT) 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.9) with ESMTP id i5F15ZSe067642 for ; Mon, 14 Jun 2004 18:05:35 -0700 (PDT) (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 i5F15dTW016129; Mon, 14 Jun 2004 18:05:39 -0700 (PDT) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 14 Jun 2004 18:05:39 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Markus Stumpf'" , IETF MARID WG Subject: RE: MTAmark (was: Reality check please) Date: Mon, 14 Jun 2004 18:05:37 -0700 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: > On Mon, Jun 14, 2004 at 02:34:44PM -0700, Hallam-Baker, Phillip wrote: > > There are plenty of sites that now accept mail from AOL as genuine > > because the IP address is correct. Otherwise it goes into the spam > > filter with a huge penalty attached. > > Wrong strategy. > > I don't want my mailserver to take over responsibility for spam mails. > And I don't want my users/employees to take over > responsibility and have > them stolen their time and my money (as employer) having them > wade around > in spam mail folders sorting out false positives. So, it appears that MARID does not solve your problem the way you would like it to be solved. So what? MARID solves the problem it was chartered to solve in the way it was chartered to solve it. > We run a very facistic DNSBL. A host sends spam, he gets listed. No > expire. Sometimes (very rarely) someone comes whining "but we > have fixed > the problem 1 year ago". So what? They harassed me and my users. It sounds to me that you are part of the problem that we are trying to solve here. From owner-ietf-mxcomp@mail.imc.org Mon Jun 14 21:17:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18351 for ; Mon, 14 Jun 2004 21:17:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5F12h6B066954; Mon, 14 Jun 2004 18:02:43 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5F12hUs066953; Mon, 14 Jun 2004 18:02:43 -0700 (PDT) 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.9) with ESMTP id i5F12g8U066946 for ; Mon, 14 Jun 2004 18:02:42 -0700 (PDT) (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 i5F12hBq022345; Mon, 14 Jun 2004 18:02:43 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 14 Jun 2004 18:02:43 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Aredridel'" , ietf-mxcomp@imc.org Subject: RE: Why should I link a library thats larger than my ENTIRE MTA? Date: Mon, 14 Jun 2004 18:02:40 -0700 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 pretty easy to write a simple and compact XML parser for a single DTD. I once wrote a Web browser that was only 75Kb of code, and that had an SGML parser which is a much clunkier affair. Phill > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Aredridel > Sent: Monday, June 14, 2004 7:51 PM > To: ietf-mxcomp@imc.org > Subject: Re: Why should I link a library thats larger than my ENTIRE > MTA? > > > > > Now can anyone see whats wrong with this picture, because > *I* for one > > certainly can. So I am supposed to link a 1.3M library > against my MTA, > > ___JUST___ to validate senders? Can someone please explain > this to me? > > I would ask why XML is even being considered but I'm not > out looking to > > start a flame, I simply would like to illustrate to > everyone here that > > there are some very deeply wrong things with XML, > completely outside the > > realm of publishing XML within DNS. > > May I suggest a much more appropriate tool for the job? Expat, the XML > parser from James Clark, is a far smaller and simpler > library. libxml is > a good general tool for dealing with large, complex XML related tasks. > For a simple record parser, expat is a much more natural interface. > > A visual aid: > > -rwxr-xr-x 1 root root 125K Jan 19 10:23 /usr/lib/libexpat.so.0.5.0 > -rwxr-xr-x 1 root root 475K Mar 11 03:28 /usr/lib/libxml.so.1.8.17 > -rwxr-xr-x 1 root root 957K Apr 19 04:41 /usr/lib/libxml2.so.2.6.9 > > So if your libraries are a bit larger than mine (debugging symbols, > likely), you're talking more like 200K. I think that's reasonable. If > not, in the tradition of qmail, a little patch doing just the > neccesary > parsing and nothing more is likely to be quite a bit tighter. I think > the 20K tossed around earlier is quite likely to be accurate to well > less than an order of magnitude. You won't get the ease of > extensibility, but I think that's a fair compromise. > > Ari > From owner-ietf-mxcomp@mail.imc.org Mon Jun 14 21:42:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19880 for ; Mon, 14 Jun 2004 21:42:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5F1LB0I070551; Mon, 14 Jun 2004 18:21:11 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5F1LBLu070549; Mon, 14 Jun 2004 18:21:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from data.6o4.ca (mail.6o4.ca [24.207.0.211]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5F1LBru070536 for ; Mon, 14 Jun 2004 18:21:11 -0700 (PDT) (envelope-from jcouzens@6o4.ca) Received: (qmail 9632 invoked by uid 1006); 15 Jun 2004 01:21:19 -0000 Received: from unknown (HELO nas1) (24.207.1.85) by data.6o4.ca with SMTP; 15 Jun 2004 01:21:18 -0000 Received-SPF: neutral (data.6o4.ca: domain of jcouzens@6o4.ca is neutral about designating 24.207.1.85 as permitted sender) Subject: Re: Why should I link a library thats larger than my ENTIRE MTA? From: James Couzens Reply-To: jcouzens@6o4.ca To: MXCOMP LIST In-Reply-To: <1087257035.5689.6.camel@betelgeuse.theinternetco.net> References: <1087253601.12374.29.camel@antitrust.6o4.ca> <1087257035.5689.6.camel@betelgeuse.theinternetco.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-/U8SgunF3ESvtT1glnlf" Message-Id: <1087262504.12994.68.camel@antitrust.6o4.ca> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 14 Jun 2004 18:21:45 -0700 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-/U8SgunF3ESvtT1glnlf Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2004-06-14 at 16:50, Aredridel wrote: > > Now can anyone see whats wrong with this picture, because *I* for one > > certainly can. So I am supposed to link a 1.3M library against my MTA, > > ___JUST___ to validate senders? Can someone please explain this to me?= =20 > > I would ask why XML is even being considered but I'm not out looking to > > start a flame, I simply would like to illustrate to everyone here that > > there are some very deeply wrong things with XML, completely outside th= e > > realm of publishing XML within DNS. >=20 > May I suggest a much more appropriate tool for the job? Expat, the XML > parser from James Clark, is a far smaller and simpler library. libxml is > a good general tool for dealing with large, complex XML related tasks. > For a simple record parser, expat is a much more natural interface. >=20 > A visual aid: >=20 > -rwxr-xr-x 1 root root 125K Jan 19 10:23 /usr/lib/libexpat.so.0.5.0 > -rwxr-xr-x 1 root root 475K Mar 11 03:28 /usr/lib/libxml.so.1.8.17 > -rwxr-xr-x 1 root root 957K Apr 19 04:41 /usr/lib/libxml2.so.2.6.9 >=20 > So if your libraries are a bit larger than mine (debugging symbols, > likely), you're talking more like 200K. I think that's reasonable. If > not, in the tradition of qmail, a little patch doing just the neccesary > parsing and nothing more is likely to be quite a bit tighter. I think > the 20K tossed around earlier is quite likely to be accurate to well > less than an order of magnitude. You won't get the ease of > extensibility, but I think that's a fair compromise. >=20 > Ari I do not believe it is appropriate to just write a small patch and implement "just the necessary parsing", just as you can not do this with SPF, you either implement all of it, or you don't bother at all. This can't be a hack-job. You know as well as I do what all the click monkey super admins are going to try to do with this, the next thing you know you won't be able to parse anything. And what if I don't want to loose my precious extensibility? (Rumour has it the SPF query language is extensible btw). =20 My point remains even with James Clarks's libexpat (mine is 175K stripped btw) why should I have to link this hulking library, PLUS another library which then has to interpret the XML? I bet its very feasible to get my SPF parser down to much less than 65K (which btw includes its own DNS parsing as well). XML just does not make any sense. Its going to cause problems in DNS, even the smallest library is still massive comparative to my SPF parser. All of this bloat for what? =20 SPFv1 is extensible SPFv1 fits in DNS SPFv1 parser is only 65K (and could EASILY be smaller) SPFv1 wasn't developed by a corporation and thus its motives are void of dollar signs Hrm, thats odd, SPFv1 does absolutely everything we need, without any of the problems we don't. XML has everyone's knickers in a knot and its just a really really bad idea. I thought we were trying to fix problems here, not create more. All I see is feature creep. Furthermore, I would like to ask just what is with everyone and "extensibility" here? I thought we were trying to fix a problem? Since when does stopping forgery need to be extensible? Why can't we just fix this problem right the first time? Seems to me this entire thing reminds me of something.. can't quite put a finger on it... something about releasing software with the mindset that should there have been any oversight it can just be patched later? ..something update.. If we are going to have to involve things other than originally aspired to by the SPFv1 DRAFT (which coincidentally seems to be missing from the table...) we ought to be doing so keeping the KISS principle in mind.=20 Saying that we need to use XML because in 2020 something different might need to be done is like saying I should go buy a Greyhound bus because I might have some children in the future. As was clearly iterated by Gordon Fecyk: > Both XML and Unicode are convenient choices for authors whose > employers use those technologies natively in their implementations.=20 > These are not as convenient for anyone else. I think we don't need to > concern ourselves with making life convenient just for one vendor.=20 > And even with that, there are other vendors who develop e-mail for the > same vendor's platform that would not benefit from the same > convenience. What SPFv1 has proposed is suitable for ALL operating systems, and can easily be implemented likely in any modern language, and there already exist parsers many of which are cross platform, and there are patches against all of the major MTA's including Exchange (albeit you'll have to pay for this plugin). Cheers, James --=20 James Couzens, Programmer ----------------------------------------------------------------- http://libspf.org -- ANSI C Sender Policy Framework library http://libsrs.org -- ANSI C Sender Rewriting Scheme library ----------------------------------------------------------------- PGP: http://gpg.mit.edu:11371/pks/lookup?op=3Dget&search=3D0x6E0396B3 --=-/U8SgunF3ESvtT1glnlf Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBAzk8oyJv1gm4DlrMRAmB6AJ99S9kfOZIiDmpmT3KnFztIOzsKbwCfVM56 qhbRMnatUoWrBjxvbsUgCI8= =gpma -----END PGP SIGNATURE----- --=-/U8SgunF3ESvtT1glnlf-- From owner-ietf-mxcomp@mail.imc.org Mon Jun 14 22:20:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22196 for ; Mon, 14 Jun 2004 22:20:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5F27FWo079915; Mon, 14 Jun 2004 19:07:15 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5F27FNR079914; Mon, 14 Jun 2004 19:07:15 -0700 (PDT) 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.9) with ESMTP id i5F27E9M079907 for ; Mon, 14 Jun 2004 19:07:14 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbfujip (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i5F27Jl02117 for ; Mon, 14 Jun 2004 19:07:20 -0700 Date: Mon, 14 Jun 2004 19:07:11 -0700 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1665390638.20040614190711@brandenburg.com> To: ietf-mxcomp@imc.org Subject: CSV specification revision available MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Folks, We finally have a new version of the Client SMTP Validation specification. The changes are massive. It is now 4 documents. The master document is based on the CSV specification; it is now the 'systems integration service' specification. It carefully describes motivation and scope. An example in the Appendix shows a simple mode of use that would be beneficial. The new documents cover component functions of authentication, authorization and accreditation. Until they come out as internet drafts, you can get copies at: d/ ps. I am going on vacation for 5 weeks, as of tonight, and do not know what my Internet access will be. Might be great, might not. In my absence, of course my co-authors have my proxy. Since I won't b here, I've sent the as draft-crocker-marid-*, rather than seeking official working group status at this point, simply to ensure that they get issued right away. ----- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA ; From owner-ietf-mxcomp@mail.imc.org Mon Jun 14 23:34:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02777 for ; Mon, 14 Jun 2004 23:34:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5F3AiJ2093089; Mon, 14 Jun 2004 20:10:45 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5F3AieI093088; Mon, 14 Jun 2004 20:10:44 -0700 (PDT) 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.9) with ESMTP id i5F3AhHM093050 for ; Mon, 14 Jun 2004 20:10:43 -0700 (PDT) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id B5C0DE0630; Mon, 14 Jun 2004 23:10:48 -0400 (EDT) Date: Mon, 14 Jun 2004 23:10:48 -0400 From: John Leslie To: ietf-mxcomp@imc.org Subject: Re: CSV specification revision available Message-ID: <20040615031048.GP44160@verdi> References: <1665390638.20040614190711@brandenburg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1665390638.20040614190711@brandenburg.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dave Crocker wrote: > > The master document is based on the CSV specification; it is now the > 'systems integration service' specification. It carefully describes > motivation and scope. An example in the Appendix shows a simple mode > of use that would be beneficial. > > The new documents cover component functions of authentication, > authorization and accreditation. > > Until they come out as internet drafts, you can get copies at: > > If you have trouble getting them there, feel free to try: -- John Leslie From owner-ietf-mxcomp@mail.imc.org Mon Jun 14 23:56:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03610 for ; Mon, 14 Jun 2004 23:56:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5F3cLab099149; Mon, 14 Jun 2004 20:38:21 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5F3cL5Z099148; Mon, 14 Jun 2004 20:38:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [64.139.47.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5F3cLkV099128 for ; Mon, 14 Jun 2004 20:38:21 -0700 (PDT) (envelope-from gconnor@nekodojo.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by neko-base.nekodojo.org (Postfix) with ESMTP id 1C3151D651 for ; Mon, 14 Jun 2004 20:38:26 -0700 (PDT) Date: Mon, 14 Jun 2004 20:38:27 -0700 From: Greg Connor To: IETF MARID WG Subject: Re: comments on SPF Message-ID: <3313764.1087245507@[192.168.0.3]> In-Reply-To: <1087256363.5461.12.camel@betelgeuse.theinternetco.net> References: <1087256363.5461.12.camel@betelgeuse.theinternetco.net> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --Aredridel wrote: > > >> > In section 4.8, you mention "A" lookup. Is AAAA explicitly not done >> > in that case? >> >> Sorry, I didn't check that reference. >> >> Yes, the exists: mechanism explicitly checks *only* A records, even if >> the MTA connection is via IPv6. This is to maintain compatibility >> with already existing DNS blacklists and whitelists. > > Any reason not to query for ANY? I can come up with one, though I don't have a strong preference on this. DNSBLs are often set up to return an A record if you are on the list (like 127.0.0.2) and a TXT record for "more info" (which not all users will care about). Using a A query allows you to get the shortest response, and if you want more info, you can query for txt, or some users might want to query for ANY at the start, if they are always going to record the TXT if present. It is remotely possible that a directory structure might have TXT records for a label but not A records. In that case, the TXT might contain descriptive info about the IP (or whatever you are requesting) but not be an "active listing". I would say if there is no A record it should be considered not to exist for purposes of exists: even if there is other data there. So, if someone does an ANY query, they should explicitly check for an A in the reply. > Ari -- Greg Connor From owner-ietf-mxcomp@mail.imc.org Tue Jun 15 00:50:52 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07465 for ; Tue, 15 Jun 2004 00:50:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5F4eKi0014090; Mon, 14 Jun 2004 21:40:20 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5F4eKIK014089; Mon, 14 Jun 2004 21:40:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from polis.nbtsc.org (polis.nbtsc.org [206.168.119.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5F4eK7j014083 for ; Mon, 14 Jun 2004 21:40:20 -0700 (PDT) (envelope-from aredridel@nbtsc.org) Received: from mizar.nbtsc.org ([206.168.67.102]) by polis.nbtsc.org with asmtp (Exim 4.34) id 1Ba5kI-0001pO-7K for ietf-mxcomp@imc.org; Mon, 14 Jun 2004 22:40:26 -0600 Subject: Re: comments on SPF From: Aredridel To: ietf-mxcomp@imc.org In-Reply-To: <3313764.1087245507@[192.168.0.3]> References: <1087256363.5461.12.camel@betelgeuse.theinternetco.net> <3313764.1087245507@[192.168.0.3]> Content-Type: text/plain Date: Mon, 14 Jun 2004 22:41:17 -0600 Message-Id: <1087274477.4845.2.camel@mizar.nbtsc.org> Mime-Version: 1.0 X-Mailer: Evolution 1.5.9.1 Content-Transfer-Encoding: 7bit X-Scan-Signature: ef55b62caefc509aed7f66c60f4c2312 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Greg Connor wrote: > > > Yes, the exists: mechanism explicitly checks *only* A records, even if > > > the MTA connection is via IPv6. This is to maintain compatibility > > > with already existing DNS blacklists and whitelists. > > > > Any reason not to query for ANY? > > [clip] > It is remotely possible that a directory structure might have TXT records > for a label but not A records. In that case, the TXT might contain > descriptive info about the IP (or whatever you are requesting) but not be > an "active listing". I would say if there is no A record it should be > considered not to exist for purposes of exists: even if there is other data > there. So, if someone does an ANY query, they should explicitly check for > an A in the reply. Hm. In the interest of future-proofing, it might be nice to specify ANY. Imagine twenty years from now when IPv4 is finally seen by most as antique, and AAAA is the normal query. Perhaps the MARID system will not seem so baroque then as it might otherwise. Ari From owner-ietf-mxcomp@mail.imc.org Tue Jun 15 00:55:12 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07666 for ; Tue, 15 Jun 2004 00:55:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5F4jNug015146; Mon, 14 Jun 2004 21:45:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5F4jNA9015145; Mon, 14 Jun 2004 21:45:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5F4jMS2015139 for ; Mon, 14 Jun 2004 21:45:22 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: ZJjR2CgAAhdU1Ln3/lI44g 1087274729 Received: from elvey.com (ns.nextbus.com [64.164.28.194]) by mail.messagingengine.com (Postfix) with ESMTP id F07C5C064F1; Tue, 15 Jun 2004 00:45:28 -0400 (EDT) Message-ID: <40CE7EE7.7090003@elvey.com> Date: Mon, 14 Jun 2004 21:45:27 -0700 From: Matthew Elvey User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MXCOMP Subject: Re: Reality check please References: <20040609215845.GO99969@Space.Net> <40C7A206.6020407@elvey.com> In-Reply-To: <40C7A206.6020407@elvey.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit (Posted on 6/9 just to Markus, perhaps by mistake; haven't heard back; the minimum price of a domain is important!) On 6/9/2004 2:58 PM, Markus Stumpf sent forth electrons to convey: > > > And a point which is deliberately ignored is the problem of 0.10 USD > throwaway domains and short-TTL bot networks. Sorry, where can I get a domain for $0.10 US? (And I don't mean foo.cjb.net or foo.cjb.co.uk) If these are coming or here, as you and Gordon seem to be saying they are, then MARID won't work as well as I had thought it would. You think an icann-authorized TLD will start selling domains at this price? Please explain in more detail. > Yeah, I know, this will be > solved anytime later with accreditation services. > > CSV: > > >> Is an SMTP client authorized to use a particular domain name in its >> SMTP EHLO command? [CSV] attempts to answer this question. It >> suffers from the fact that the EHLO name has a tenuous relationship, >> at best, with the contents of any mail message. >> > > > So what? It is MTA authorization records not message authorization > records, even if the group morphed to it. Indeed! Watch this point be studiously ignored. > A EHLO identifier is the > way one MTA tells another MTA about himself and his identity. It is > an important fact to know if this identity is faked. However this > could probably also partially accomplished by requiring the EHLO > to match at least one PTR record and have the forward lookup of this > record match the connecting IP (aka EHLO must match paranoid lookup). > > Some of the syntax and semantics of SPF records provide useful additional functionality without weakening the effectiveness with which an MTA is authorized by a domain. The benefit is that it allows every legit MTA to pass MARID inspection, even the 1-10% of legit MTAs don't have control over rDNS, and hence don't pass the rDNS test. And yet it ties that MTA to a domain that has a valuable reputation. That being the goal of MARID. > RMX/SPF: > > >> These suffer from the fact that the MAIL FROM address really >> describes where to send NDRs to, and in many third-party and >> forwarder situations this address is unrelated to the domain that is >> resending the message. > > > This has not more or less backdraws than to check a Resent-From: > This provides no more or less authentication for a faked Resent-From: > of a throwaway domain and in that case if the message is not checked > during the SMTP transaction the bounce goes where to? > The faked envelope sender? To the SUBMITTER, which is an address > the originator of the message will never be able to check for mistyped > addresses. What have we won? > > Nothing but big headaches, IMO. > ... the XML hype ... > I think the vocal opponents of XML have RSI. Or perhaps their jaws dropped open and they're speechless. From owner-ietf-mxcomp@mail.imc.org Tue Jun 15 02:04:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14217 for ; Tue, 15 Jun 2004 02:04:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5F5qacL049102; Mon, 14 Jun 2004 22:52:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5F5qaoG049101; Mon, 14 Jun 2004 22:52:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5F5qZRT049069 for ; Mon, 14 Jun 2004 22:52:35 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: UdZpIG1EZiNMVRUTxWwU3Q 1087278760 Received: from elvey.com (ns.nextbus.com [64.164.28.194]) by mail.messagingengine.com (Postfix) with ESMTP id 13C52C06F3E; Tue, 15 Jun 2004 01:52:39 -0400 (EDT) Message-ID: <40CE8EA6.8040203@elvey.com> Date: Mon, 14 Jun 2004 22:52:38 -0700 From: Matthew Elvey User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: IETF MARID WG Subject: Re: Alternative to TXT or new RR References: In-Reply-To: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Groan. The pros and cons of using TXT were discussed at the interim meeting, and if memory serves, no compelling argument for abandoning TXT was made, and compelling arguments against alternatives were discussed. Ed presented his arguments and few if any bought them. The alternatives were all shot down and Ed couldn't revive 'em, and the issues with TXT have all been addressed (e.g. by wayne's stats)! At least my (perhaps biased) recollection is that Ed backed down. Let's move on. (or squarely address the issues already raised, pro and con, instead of irrelevancies like "MARID can't claim the TXT record as it's own"). MARID is likely gonna use TXT; there's no alternative, the sky will not fall, and the issues are not dealbreakers. Bob Atkinson wrote in the same thread: > Let's be clear; this is NOT the plan of record in the > current draft. Rather, MARID is claiming the COMBINATION > of a particular domain prefix and TXT as it's own. "the current draft"? Let's be clear: a small subgroup of MARID is working on a particular draft; others are working on other drafts. There is nothing even approaching a consensus that suggests that any particular draft is 'the one'. e.g. I think a poll on "Would you support a standard based on a merger of SPF and CID (using A, B and C from SPF and XML, E and F from CID) as a good solution to the problem MARID intends to solve?" would find that the majority answer would be NO. If that isn't clear, then I hope there's a hum on this soon! There was a hum at the last meeting, but it asked was basically: "Do you think it would be valuable to merge SPF's semantics with CID's use of 2822.From and the new RFROM, in a new set of specs with the layers broken out?" wayne wrote: >Since >the interim meeting, all 2821 proposals are now out of scope. From owner-ietf-mxcomp@mail.imc.org Tue Jun 15 02:07:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16142 for ; Tue, 15 Jun 2004 02:07:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5F5qgjN049153; Mon, 14 Jun 2004 22:52:42 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5F5qgB2049152; Mon, 14 Jun 2004 22:52:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5F5qf6X049142 for ; Mon, 14 Jun 2004 22:52:41 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: SY8zeqbQ+hzcoeek6Gb5zA 1087278769 Received: from elvey.com (ns.nextbus.com [64.164.28.194]) by mail.messagingengine.com (Postfix) with ESMTP id C88C1C06F40; Tue, 15 Jun 2004 01:52:48 -0400 (EDT) Message-ID: <40CE8EAF.4050505@elvey.com> Date: Mon, 14 Jun 2004 22:52:47 -0700 From: Matthew Elvey User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MARID WG Subject: Re: MTAmark (was: Reality check please) References: <20040611172844.GB32187@Space.Net> In-Reply-To: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/11/2004 11:04 AM, wayne sent forth electrons to convey: >You guys are raising good and interesting points about both the pros >and cons of things like MTAMARK, but this is all irrelevant. Since >the interim meeting, all 2821 proposals are now out of scope. > I'm sorry, but I WAS at the interim meeting. I believe that was NOT decided. In which of the 13 items mentioned in the minutes is this? Perhaps I was out of the room. What Markus has said re. RFC 2418 / 3.3 is correct, to which I should add that IMO, the minutes are not accurate regarding the hum - as I'd discussed with a chair, and IIRC, he said he's planning to revise in a new minutes version. See the email I just posted, Subject: Re: Alternative to TXT or new RR. I was there for the hum in question. There are dealbreakers that SPF+CallerID hasn't faced yet. Dealbreakers that other proposals do not have. On 6/11/2004 4:27 PM, william(at)elan.net sent forth electrons to convey: > [T]he current primary work is on SPF+CallerID ... False. From what I know of one of the IESG's members, SPF+CallerID is likely a non-starter, primarily for gross violation of the KISS principle. From owner-ietf-mxcomp@mail.imc.org Tue Jun 15 02:12:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20774 for ; Tue, 15 Jun 2004 02:12:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5F64F44057629; Mon, 14 Jun 2004 23:04:15 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5F64FBS057626; Mon, 14 Jun 2004 23:04:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5F64FHc057606 for ; Mon, 14 Jun 2004 23:04:15 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from [192.168.2.24] (adsl-64-142-13-68.sonic.net [64.142.13.68]) by b.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i5F64JAS031207; Mon, 14 Jun 2004 23:04:19 -0700 Subject: Re: Reality check please From: Douglas Otis To: Matthew Elvey Cc: MXCOMP In-Reply-To: <40CE7EE7.7090003@elvey.com> References: <20040609215845.GO99969@Space.Net> <40C7A206.6020407@elvey.com> <40CE7EE7.7090003@elvey.com> Content-Type: text/plain Message-Id: <1087279459.2256.21.camel@bash.adsl-64-142-13-68.sonic.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 14 Jun 2004 23:04:19 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 2004-06-14 at 21:45, Matthew Elvey wrote: > (Posted on 6/9 just to Markus, perhaps by mistake; haven't heard back; > the minimum price of a domain is important!) > > On 6/9/2004 2:58 PM, Markus Stumpf sent forth electrons to convey: > > > > > > > And a point which is deliberately ignored is the problem of 0.10 USD > > throwaway domains and short-TTL bot networks. > > Sorry, where can I get a domain for $0.10 US? (And I don't mean > foo.cjb.net or foo.cjb.co.uk) > If these are coming or here, as you and Gordon seem to be saying they > are, then MARID won't work as well as I had thought it would. > You think an icann-authorized TLD will start selling domains at this > price? Please explain in more detail. To slip past a filter, new domains are simply the price of doing business for those that abuse the system. Unlike an IP address, a history can be expected of a domain name that is not possible with just an IP address. New domain, offer little credit. Tried and true, offer full credit. Tried and bad, no credit. Using a domain name with a reasonably good authentication practice is tremendously safer than relying solely upon the address whether or not an accreditation service helps administrate the lists. > > Yeah, I know, this will be solved anytime later with accreditation > > services. > > > > CSV: > > > >> Is an SMTP client authorized to use a particular domain name in its > >> SMTP EHLO command? [CSV] attempts to answer this question. It > >> suffers from the fact that the EHLO name has a tenuous relationship, > >> at best, with the contents of any mail message. > > > > So what? It is MTA authorization records not message authorization > > records, even if the group morphed to it. > > Indeed! Watch this point be studiously ignored. Although the problem can be seen as forged headers, much of this junk traffic comes from sources that can be tracked and this is made easier through the use of names rather than IP addresses where accountability is otherwise doubtful if not impossible. > > A EHLO identifier is the way one MTA tells another MTA about himself > > and his identity. It is an important fact to know if this identity is > > faked. However this could probably also partially accomplished by > > requiring the EHLO to match at least one PTR record and have the > > forward lookup of this record match the connecting IP (aka EHLO must > > match paranoid lookup). > > Some of the syntax and semantics of SPF records provide useful > additional functionality without weakening the effectiveness with which > an MTA is authorized by a domain. The benefit is that it allows every > legit MTA to pass MARID inspection, even the 1-10% of legit MTAs don't > have control over rDNS, and hence don't pass the rDNS test. And yet it > ties that MTA to a domain that has a valuable reputation. That being > the goal of MARID. The use of an SRV record has the advantage of returning all the needed information in a single query where both authorization is discovered and the authentication is validated. -Doug From owner-ietf-mxcomp@mail.imc.org Tue Jun 15 02:24:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25234 for ; Tue, 15 Jun 2004 02:24:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5F68Vkb060290; Mon, 14 Jun 2004 23:08:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5F68VfM060289; Mon, 14 Jun 2004 23:08:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5F68UQC060279 for ; Mon, 14 Jun 2004 23:08:30 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: dkTAOc+l6UI3aVyW5iamHw 1087279717 Received: from elvey.com (ns.nextbus.com [64.164.28.194]) by mail.messagingengine.com (Postfix) with ESMTP id 21985C06EBF; Tue, 15 Jun 2004 02:08:36 -0400 (EDT) Message-ID: <40CE9263.4090501@elvey.com> Date: Mon, 14 Jun 2004 23:08:35 -0700 From: Matthew Elvey User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Luis Bruno Cc: ietf-mxcomp@imc.org Subject: Re: Alternative to TXT or new RR was: Comments on draft-ietf-marid-core-01 xml use References: <001301c450a7$b87655e0$6401a8c0@hdev1> <20040614171952.GA1973@republico.estv.ipv.pt> In-Reply-To: <20040614171952.GA1973@republico.estv.ipv.pt> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/14/2004 10:19 AM, Luis Bruno sent forth electrons to convey: >I'd like to hear comments on this, even flames or pointers to threads >I've missed. > You missed the discussion (probably including posts from wayne) about how the simple format of SPF made it easier to deploy and the stats showing how many domains had deployed SPF vs. CID. (something like 30,000 vs. sixty). Also discussed: New RR support in deployed clients is poor and in servers is fair but not great. The former is easily fixed by having the client embedded in the MARID implementation. The latter is not easily fixed. A third problem is firewalls that block queries of the new RR becaue they don't recognize it. (Any known cases of firewalls that do this? Cisco PIXes don't; they just block (by configurable default) DNS packets larger than 512Bytes.) From owner-ietf-mxcomp@mail.imc.org Tue Jun 15 03:11:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27992 for ; Tue, 15 Jun 2004 03:11:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5F72dpa087813; Tue, 15 Jun 2004 00:02:39 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5F72dRr087812; Tue, 15 Jun 2004 00:02:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5F72cDm087780 for ; Tue, 15 Jun 2004 00:02:38 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: Js7aNtSx7V4u+BBlQTFhNw 1087282955 Received: from elvey.com (ns.nextbus.com [64.164.28.194]) by mail.messagingengine.com (Postfix) with ESMTP id 7B814C07241; Tue, 15 Jun 2004 03:02:34 -0400 (EDT) Message-ID: <40CE9F08.2050002@elvey.com> Date: Tue, 15 Jun 2004 00:02:32 -0700 From: Matthew Elvey User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MXCOMP Subject: Re: CSV specification revision available References: <1665390638.20040614190711@brandenburg.com> <20040615031048.GP44160@verdi> In-Reply-To: <20040615031048.GP44160@verdi> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/14/2004 8:10 PM, John Leslie sent forth electrons to convey: > > > That new URL helped. Comments: I don't get why draft-crocker-marid-csvhna-00.html says in "2.1 Reverse DNS" that "For authentication of sending SMTP clients, Reverse DNS can be used by itself" This doesn't make sense to me. e.g. Spammer controls 345.0.0.0/24 (including having rDNS delegated from its ISP), and makes 345.0.0.5 resolve in rDNS to mx34.aol.com, and sends spam with EHLO = mx34.aol.com. This fails to protect aol.com or tie the abuse to a responsible party. Reverse DNS does not appear to be a good way to tie a domain to an IP. Also, allowing it doesn't make CSV easier to implement, does it? "2.2 Forward DNS Lookup" is adequate to the task; there's no need for 2.1, AFAICT. An accreditation service used by CSV cannot accredit aol.com as a non-spammer if CSV does not allow aol to protect its use in HELO from this abuse. Also, I don't see how 3.2 SMTP Auth protects aol.com from this same abuse. RE. 3.1 StartTLS: *IF* STARTTLS is used *AND* the sending server's cert is CA signed, then that makes sense. (Yes, I plan to rip out part of SPF and propose it as a replacement for draft-crocker-marid-csvhna-00.html and draft-crocker-marid-csvcsa-00.html in CSV, and create a chart comparing the pieces chosen and the reason for each choice, all if I find the time.) draft-crocker-marid-csvcsa-00.html won't work with wildcards, right? From owner-ietf-mxcomp@mail.imc.org Tue Jun 15 03:45:57 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29566 for ; Tue, 15 Jun 2004 03:45:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5F7cCDP005172; Tue, 15 Jun 2004 00:38:12 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5F7cCRH005171; Tue, 15 Jun 2004 00:38:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5F7cBq9005156 for ; Tue, 15 Jun 2004 00:38:11 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: NFMBUL4CPSnUvdTphxZblA 1087285091 Received: from elvey.com (ns.nextbus.com [64.164.28.194]) by mail.messagingengine.com (Postfix) with ESMTP id AB8BBC06E1C; Tue, 15 Jun 2004 03:38:10 -0400 (EDT) Message-ID: <40CEA761.1000201@elvey.com> Date: Tue, 15 Jun 2004 00:38:09 -0700 From: Matthew Elvey User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Douglas Otis Cc: MXCOMP Subject: Re: Reality check please References: <20040609215845.GO99969@Space.Net> <40C7A206.6020407@elvey.com> <40CE7EE7.7090003@elvey.com> <1087279459.2256.21.camel@bash.adsl-64-142-13-68.sonic.net> In-Reply-To: <1087279459.2256.21.camel@bash.adsl-64-142-13-68.sonic.net> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/14/2004 11:04 PM, Douglas Otis sent forth electrons to convey: >On Mon, 2004-06-14 at 21:45, Matthew Elvey wrote: > >> Sorry, where can I get a domain for $0.10 US? (And I don't mean >> >>foo.cjb.net or foo.cjb.co.uk) >>If these are coming or here, as you and Gordon seem to be saying they >>are, then MARID won't work as well as I had thought it would. >>You think an icann-authorized TLD will start selling domains at this >>price? Please explain in more detail. >> >> > >To slip past a filter, new domains are simply the price of doing >business for those that abuse the system. Unlike an IP address, a >history can be expected of a domain name that is not possible with just >an IP address. New domain, offer little credit. Tried and true, offer >full credit. Tried and bad, no credit. Using a domain name with a >reasonably good authentication practice is tremendously safer than >relying solely upon the address whether or not an accreditation service >helps administrate the lists. > > True, but I would like to know if domains will be avaiable for << $5. It'll impact reputation service / RHSRxL scalability, but MARID will still work. IF the price approaches $0, all domains will need accredidation, and RHSBLs become unscalable, as they will take up more space than regular IP BLs. We must assume spammers can warehouse domains and allow them to age, unused, until not new. >>>A EHLO identifier is the way one MTA tells another MTA about himself >>>and his identity. It is an important fact to know if this identity is >>>faked. However this could probably also partially accomplished by >>>requiring the EHLO to match at least one PTR record and have the >>>forward lookup of this record match the connecting IP (aka EHLO must >>>match paranoid lookup). >>> >>> >> >>Some of the syntax and semantics of SPF records provide useful >>additional functionality without weakening the effectiveness with which >>an MTA is authorized by a domain. The benefit is that it allows every >>legit MTA to pass MARID inspection, even the 1-10% of legit MTAs don't >>have control over rDNS, and hence don't pass the rDNS test. And yet it >>ties that MTA to a domain that has a valuable reputation. That being >>the goal of MARID. >> >> > >The use of an SRV record has the advantage of returning all the needed >information in a single query where both authorization is discovered and >the authentication is validated. > > Yup, and CSV's CSA doesn't rely on rDNS. Pretty nifty. (Though all of hotmail's SRV records would take up much more cache space than their SPF record, even in XML format.) I still need to mull over what SPF allows that CSA doesn't, and whether (IMO) CSA can or should be extended. Also, piggybacking on the deployed SPF records and creation tools is tempting. (It seems to have hooked Microsoft.) From owner-ietf-mxcomp@mail.imc.org Tue Jun 15 04:02:22 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00695 for ; Tue, 15 Jun 2004 04:02:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5F7qMFZ012263; Tue, 15 Jun 2004 00:52:22 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5F7qMZ2012262; Tue, 15 Jun 2004 00:52:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5F7qLkw012252 for ; Tue, 15 Jun 2004 00:52:21 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: 4TnolC+TsLXo+LnaYT8bXw 1087285941 Received: from elvey.com (ns.nextbus.com [64.164.28.194]) by mail.messagingengine.com (Postfix) with ESMTP id 05B4AC06CCE; Tue, 15 Jun 2004 03:52:20 -0400 (EDT) Message-ID: <40CEAAB2.7040608@elvey.com> Date: Tue, 15 Jun 2004 00:52:18 -0700 From: Matthew Elvey User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: IETF MARID WG Subject: Re: Alternative to TXT or new RR References: <40CE8EA6.8040203@elvey.com> In-Reply-To: <40CE8EA6.8040203@elvey.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/14/2004 10:52 PM, Matthew Elvey sent forth electrons to convey: > Sorry, I missed Ed's later "Re: Towards resolution on Wildcards" post from this morning, and other recent substantive comments. Yum, shoe leather. From owner-ietf-mxcomp@mail.imc.org Tue Jun 15 05:11:52 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03891 for ; Tue, 15 Jun 2004 05:11:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5F900ee044032; Tue, 15 Jun 2004 02:00:00 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5F900Z1044031; Tue, 15 Jun 2004 02:00:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (catinthebox.net [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5F8xx96044014 for ; Tue, 15 Jun 2004 01:59:59 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Tue, 15 Jun 2004 05:03:27 -0400 Received: from ([68.158.106.18]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 1100854641; Tue, 15 Jun 2004 05:03:25 -0400 Message-ID: <00ed01c452b8$115cefe0$6401a8c0@hdev1> From: "Hector Santos" To: "IETF MARID WG" References: <20040609215845.GO99969@Space.Net> <20040610150711.GA9692@zardoc.esmtp.org> <002101c44fa9$a7feaf90$6401a8c0@hdev1> <20040611230411.GC77339@Space.Net> <004101c4504b$d24a7200$6401a8c0@hdev1> <20040614191045.GA39184@Space.Net> Subject: Re: MTAmark (was: Reality check please) Date: Tue, 15 Jun 2004 05:06:28 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.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: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Markus Stumpf" To: "IETF MARID WG" Sent: Monday, June 14, 2004 3:10 PM Subject: Re: MTAmark (was: Reality check please) > On Sat, Jun 12, 2004 at 03:06:39AM -0400, Hector Santos wrote: > > > Give me one site that really utilizes the client side of SPF? > > Not sure what this question ask. > > Let me see one serious site that rejects mail from AOL.com because the IP > that sent the message was not on the SPF list. The continued embedded usage of tthe word "serious" keeps me scratching my head The mere fact a mail server is made part of the common and world wide network, makes it a "serious" operation with standards and BCP responsibilities. I don't mind saying (because I believe it very strongly), putting up a mail server with the intent of running a mail operation but failing to adhere to common practice and standards, well, is bordeline unethical and malpractice that puts you at risk with your peers. You seem to put alot of weight on the "its my ball" syndrome with a heavy weight placed on a system admin (you) policy to decide what mail transactions are acceptable. However, from what I have seen and personally experienced, it is all based on some criterias that in my view, "serious" mail server operations do not usually typically use. Auto-generated permanent blocks based on what I believe are weak criterias is what I see on your system. Oh well, its your toy. As long as you keep your automated blocking methods to your system only, thats fine. But once you get into the game of passing on this highly false "blocking IP database" information to a public and general database, well, that is just plain "wrong." Anyway, AOL? Markus, in this case, if the sender IP using a AOL sender domain is not validated by the AOL SPF policy, then for this specific situation, you have AOL neutral result. A no-decision based on a SPF neutral criteria. This alone can not be used for rejection per AOL's SPF policy. But any "serious" anti-spam system is not going to rely solely on SPF or MARID, period. It doesn't solve or cover all possibilties, so you need to incorporate other methods as well. There would be several ways to reject this: o Use popular RBL sites to cover the known reputation of the IP. o Use Local Domain/IP spoof checking. MARID/SPF not required. o or use a CBV against AOL's local user validation which they support. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Tue Jun 15 06:19:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08299 for ; Tue, 15 Jun 2004 06:19:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5FA7fb2075575; Tue, 15 Jun 2004 03:07:41 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5FA7f3a075574; Tue, 15 Jun 2004 03:07:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5FA7ejk075555 for ; Tue, 15 Jun 2004 03:07:40 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: pcWFnPqJbCusdolxPTplTA 1087294058 Received: from elvey.com (ns.nextbus.com [64.164.28.194]) by mail.messagingengine.com (Postfix) with ESMTP id 93E45C06E92; Tue, 15 Jun 2004 06:07:37 -0400 (EDT) Message-ID: <40CECA68.3070008@elvey.com> Date: Tue, 15 Jun 2004 03:07:36 -0700 From: Matthew Elvey User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus Stumpf Subject: Re: Reality check please (You set me up! Thanks!) References: <20040609215845.GO99969@Space.Net> <40C7A206.6020407@elvey.com> <20040611182958.GB99040@Space.Net> In-Reply-To: <20040611182958.GB99040@Space.Net> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/11/2004 11:29 AM, Markus Stumpf sent forth electrons to convey: >Oups, hit send to early :/ > >On Wed, Jun 09, 2004 at 04:49:26PM -0700, Matthew Elvey wrote: > > >>Some of the syntax and semantics of SPF records provide useful >>additional functionality without weakening the effectiveness with which >>an MTA is authorized by a domain. >> >> > >Let's make a real life deployment test: >How much people that use the Internet "for fun" (some web browsing, a >bit of email and maybe chats) do you know? > > ~100 >How many of them have their own domain? > > ~20 >How many of them will be able to specify (even with software aid) >correct SPF records that will not make it totally impossible for them >to send eMails? > ~10 (I live in San Francsico, else likely ~5) > A big german hoster has registered - according to their >website - more than 2 millions of domains for their users. A large >portion of them are domains used like business cards or are the hobby >of people like joe-user.de. >Do yopu expect them or anyone else for them to be able to specify >correct SPF records? > No. Also you forgot that in an SPF world, they'll have to configure their mail clients. What about the ones that use many different From:'s http://wiki.fastmail.fm/wiki/index.php/FromLine, e.g. with Mozilla's new Multiple Identity Support: http://www.mozilla.org/projects/thunderbird/identities.html? But I'm not advocating SPF in its entirety, just "some of the syntax and semantics"! > Some folx which are my friends have such domains. >They send out their emails through the mailserver of Internet on demand >ISPs and DSL providers and and and. They change (with the aid of >programs) their IPs, ISP and mailserver like other change their >underware. Managing correct SPF records for them is hell. > > No, you misunderstand my proposal. (Thanks for setup though!) We still use EHLO to select the domain to authenticate; we ditch the PRL and SRS. So our friends DON'T HAVE TO DO ANYTHING! The big german hoster just has to make sure that the EHLO its server sends out is a domain that has an SPF record that validates its IP (and reputation/accredidation). SRS doesn't need to be deployed! In my proposal, most domains DON'T NEED new DNS records AT ALL. (And none of this RFrom stuff is necessary either.) Near lightning-fast deployment is feasible. And we're still providing and using M.A.R.I.D. effectively. How cool is that? > > > >>don't pass the rDNS test. And yet it ties that MTA to a domain that has >>a valuable reputation. That being the goal of MARID. >> >> > >Do you know what hell it will be for a large ISP offering mail relay for >their customers to change the IP of an outgoing SMTP server? >That's why I wrote "reality check". It is one side to design a kewl >and nitfy system and it is a completely other thing to make it work >in the real world. How many systems fail in the real world you can read >each day in the newspapers about. > > I agree. > \Maex > > > On 6/11/2004 11:15 AM, Markus Stumpf sent forth electrons to convey: >On Wed, Jun 09, 2004 at 04:49:26PM -0700, Matthew Elvey wrote: > > >>Sorry, where can I get a domain for $0.10 US? (And I don't mean >>foo.cjb.net or foo.cjb.co.uk) >> >> > >What is the difference with regards to MARID and MARID records >between a domain example.com and foo.cjb.net or foo.cjb.co.uk? > > Big difference. Generally a cjb.net (a second level domain) will have a reputation (or get RHSBL'd), and cjb.co.uk (a third level domain) will too. the domains I listed generally won't have reputations separate from their parent domains. >"Full featured" SLDs are as cheap as 5 USD (google for "cheap domains"). > > (I know. I said so tonight.) You said I could get domains for $0.10. I asked Where? No answer. I guess you're taking back your claim! Good! > > >>If these are coming or here, as you and Gordon seem to be saying they >>are, then MARID won't work as well as I had thought it would. >>You think an icann-authorized TLD will start selling domains at this >>price? Please explain in more detail. >> >> > >Domains ARE cheap, most bundle it with disk space and webservers. > > Yes, but not so cheap that they make RHSBLs unscalable. As was discussed (with stats) a while ago on the list. 1GB of RAM costs a lot less than 50GB of RAM. (the $5 to $.10 ratio) From owner-ietf-mxcomp@mail.imc.org Tue Jun 15 06:31:13 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08814 for ; Tue, 15 Jun 2004 06:31:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5FANCXo078709; Tue, 15 Jun 2004 03:23:12 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5FANC5i078708; Tue, 15 Jun 2004 03:23:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from svrmail.roving.com (SVRMAIL.roving.com [208.198.98.29]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5FANBW6078675 for ; Tue, 15 Jun 2004 03:23:11 -0700 (PDT) (envelope-from molson@constantcontact.com) Received: by mail.constantcontact.com with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Jun 2004 06:23:03 -0400 Message-ID: From: "Olson, Margaret" To: IETF MARID WG Subject: SPF and SenderID /MARID comparisons Date: Mon, 14 Jun 2004 21:53:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4527B.98BA0780" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4527B.98BA0780 Content-Type: text/plain; charset="iso-8859-1" This is a follow up to the discussion on jabber this afternoon, on comparing SPF records to SenderID/MARID records. Limiting the comparison to just the size of the records is misleading; the usage of SPF and SenderID is quite different and you have to take into account other factors. Most non-technical small business domains outsource some or all of their email. It's not just email that a small business will outsource, it's almost everything technical and it's usually outsourced along function/feature lines rather than by role. In other words, they don't have an outsourced IT department, they have outsourced problem solutions. A local design firm created the web site and it is hosted at a small business hosting provider. The ecommerce shopping cart is hosted somewhere else. Person to person email is the local ISP. Email marketing is yet another company. That makes up to three providers for sending email, none of them related to one another. For each of these three email providers, bounces are handled by the provider in a manner appropriate to the function provided. Generally, for person to person mail the bounces go back to the sender. For the other two, the bounces are handled by the application. If you look at SPF version 1, each provider publishes for his or her domain and there is no coordination between the various means that the same sender uses to send mail. But it's highly likely that the purported responsible domain in all three cases is that of the sender. So for SenderID/MARID, there is a new record which points to three other records: one each for the ISP, the shopping cart, and the email marketing service. For large companies, the tangled manner in which they send mail is even more complicated, with multiple departments each outsourcing to multiple providers. Using the PRD will mean that far more domains will need to be publishing SenderID records than are publishing SPF records to get the same level of participation. But, most of these new publishers will just have one or more entries pointing elsewhere, where "elsewhere" is an organization that is a spf v1 publication candidate. With all of the sending methods of a domain documented through the MARID records, you can hold the domains each responsible and track their behavior across their providers. This is the only way to curtail the extremely aggressive marketers. It is secondary to preventing forgeries, but at the same time it is critical to solving the spam problem. Those of you who shop at small online businesses can see some of the sending method mix yourselves by carefully examining the headers of transactional, person to person, and promotional messages. If you get messages from more than one part of a large, decentralized company you can examine those headers and get a sense of the diversity of sending methodologies in that part of the market. In summary, with SenderID the mix of domains publishing will change, and the characteristics of the records will change. I do not see a problem here, but I do caution the group about drawing conclusions about record and publication characteristics based on the SPF experience. Margaret. ------_=_NextPart_001_01C4527B.98BA0780 Content-Type: text/html; charset="iso-8859-1" SPF and SenderID /MARID comparisons

This is a follow up to the discussion on jabber this afternoon, on comparing
SPF records to SenderID/MARID records.
 
Limiting the comparison to just the size of the records is misleading; the
usage of SPF and SenderID is quite different and you have to take into
account other factors.

Most non-technical small business domains outsource some or all of their
email. It's not just email that a small business will outsource, it's almost
everything technical and it's usually outsourced along function/feature
lines rather than by role. In other words, they don't have an outsourced IT
department, they have outsourced problem solutions. A local design firm
created the web site and it is hosted at a small business hosting provider.
The ecommerce shopping cart is hosted somewhere else. Person to person email
is the local ISP. Email marketing is yet another company. That makes up to
three providers for sending email, none of them related to one another.

For each of these three email providers, bounces are handled by the provider
in a manner appropriate to the function provided. Generally, for person to
person mail the bounces go back to the sender. For the other two, the
bounces are handled by the application. If you look at SPF version 1, each
provider publishes for his or her domain and there is no coordination
between the various means that the same sender uses to send mail. But it's
highly likely that the purported responsible domain in all three cases is
that of the sender. So for SenderID/MARID, there is a new record which
points to three other records: one each for the ISP, the shopping cart, and
the email marketing service.

For large companies, the tangled manner in which they send mail is even more
complicated, with multiple departments each outsourcing to multiple
providers.

Using the PRD will mean that far more domains will need to be publishing
SenderID records than are publishing SPF records to get the same level of
participation. But, most of these new publishers will just have one or more
<indirect> entries pointing elsewhere, where "elsewhere" is an organization
that is a spf v1 publication candidate. With all of the sending methods of a
domain documented through the MARID records, you can hold the domains each
responsible and track their behavior across their providers. This is the
only way to curtail the extremely aggressive marketers. It is secondary to
preventing forgeries, but at the same time it is critical to solving the
spam problem.

Those of you who shop at small online businesses can see some of the sending
method mix yourselves by carefully examining the headers of transactional,
person to person, and promotional messages. If you get messages from more
than one part of a large, decentralized company you can examine those
headers and get a sense of the diversity of sending methodologies in that
part of the market.

In summary, with SenderID the mix of domains publishing will change, and the
characteristics of the records will change. I do not see a problem here, but
I do caution the group about drawing conclusions about record and
publication characteristics based on the SPF experience.

Margaret.




------_=_NextPart_001_01C4527B.98BA0780-- From owner-ietf-mxcomp@mail.imc.org Tue Jun 15 08:11:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12722 for ; Tue, 15 Jun 2004 08:11:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5FBwUIe098288; Tue, 15 Jun 2004 04:58:30 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5FBwUZe098287; Tue, 15 Jun 2004 04:58:30 -0700 (PDT) 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.9) with ESMTP id i5FBwTdC098268 for ; Tue, 15 Jun 2004 04:58:29 -0700 (PDT) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id 93C80E0792; Tue, 15 Jun 2004 07:58:28 -0400 (EDT) Date: Tue, 15 Jun 2004 07:58:28 -0400 From: John Leslie To: Matthew Elvey Cc: MXCOMP Subject: Re: CSV specification revision available Message-ID: <20040615115828.GQ44160@verdi> References: <1665390638.20040614190711@brandenburg.com> <20040615031048.GP44160@verdi> <40CE9F08.2050002@elvey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40CE9F08.2050002@elvey.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Matthew Elvey wrote: > On 6/14/2004 8:10 PM, John Leslie sent forth electrons to convey: > >> >> > Comments: I don't get why draft-crocker-marid-csvhna-00.html says in > "2.1 Reverse DNS" > that "For authentication of sending SMTP clients, Reverse DNS can be > used by itself" We need to admit up-front that this document was the last one written, and didn't get the same amount of scrutiny as the others. :^( That said, the whole intent of the Host Name Authentication document was to survey the field for things currently being done; not to recommend which of them to use. > This doesn't make sense to me. > e.g. Spammer controls 345.0.0.0/24 (including having rDNS delegated from > its ISP), and makes 345.0.0.5 resolve in rDNS to mx34.aol.com, and sends > spam with EHLO = mx34.aol.com. > This fails to protect aol.com or tie the abuse to a responsible party. You're right. This will be corrected. In truth, most actual use of Reverse DNS sets out to do both forward- and reverse-DNS queries, looking for a match between them. In fact, that is mentioned a few paragraphs earlier. I plead guilty to not proofreading the 2.1 section carefully enough. > Reverse DNS does not appear to be a good way to tie a domain to an IP. > Also, allowing it doesn't make CSV easier to implement, does it? The host-name authentication function actually recommended is found in the Client SMTP Authentication document, section 4 and following: namely that the response to the SRV query should ordinarily list the IP address(es) authorized to perform the MTA function; and that a match of the actual IP address of the established SMTP connection to one of these satisfies the authentication requirement. I shall ensure that either the overview document or the HNA document makes it clear what is being recommended; and that the HNA document explains the weakness of using reverse-DNS without verifying the forward-DNS match. > "2.2 Forward DNS Lookup" > is adequate to the task; there's no need for 2.1, AFAICT. I agree 2.1 should not be mentioned without a warning of its weakness. > An accreditation service used by CSV cannot accredit aol.com as a > non-spammer if CSV does not allow aol to protect its use in HELO from > this abuse. You are correct that omission of host-name authentication, or the use of inadequate host-name authentication renders accreditation by domain-name virtually useless. > Also, I don't see how 3.2 SMTP Auth protects aol.com from this same abuse. > RE. 3.1 StartTLS: *IF* STARTTLS is used *AND* the sending server's cert > is CA signed, then that makes sense. I'm not sure I understand your question here. Could you clarify? > (Yes, I plan to rip out part of SPF and propose it as a replacement for > draft-crocker-marid-csvhna-00.html and > draft-crocker-marid-csvcsa-00.html in CSV, and create a chart comparing > the pieces chosen and the reason for each choice, all if I find the time.) Sounds like a good execrcise. > draft-crocker-marid-csvcsa-00.html won't work with wildcards, right? CSA was designed to validate the EHLO string, which should never involve wildcards, IMHO. Thus "working with wildcards" was never a design goal. (Please note that the Domain Name Accreditation methods _are_ designed to work with wildcards.) -- John Leslie From owner-ietf-mxcomp@mail.imc.org Tue Jun 15 09:29:48 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16848 for ; Tue, 15 Jun 2004 09:29:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5FDFWLn014427; Tue, 15 Jun 2004 06:15:32 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5FDFWi5014426; Tue, 15 Jun 2004 06:15:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from orange.csi.cam.ac.uk (exim@orange.csi.cam.ac.uk [131.111.8.77]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5FDFUYQ014419 for ; Tue, 15 Jun 2004 06:15:31 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from fanf2 (helo=localhost) by orange.csi.cam.ac.uk with local-esmtp (Exim 4.12) id 1BaDml-00036o-00; Tue, 15 Jun 2004 14:15:31 +0100 Date: Tue, 15 Jun 2004 14:15:31 +0100 From: Tony Finch X-X-Sender: fanf2@orange.csi.cam.ac.uk To: Dave Crocker cc: ietf-mxcomp@imc.org Subject: Re: CSV specification revision available In-Reply-To: <1665390638.20040614190711@brandenburg.com> Message-ID: References: <1665390638.20040614190711@brandenburg.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 14 Jun 2004, Dave Crocker wrote: > > We finally have a new version of the Client SMTP Validation > specification. The changes are massive. The new documents are much clearer, however they are still vague on important details, they take an awfully long time to get to the point, and they contain an amazing amount of irrelevant digression. This is a shame because I greatly prefer this approach to SPF and its ilk, since it does not confuse email addresses and IP addresses. I have a few comments: draft-crocker-marid-smtp-validate-01 Section 1, Address-based Authentication: It's probably worth explaining why this doesn't work so well in the current Internet, particularly the use of NATs and dynamically-allocated addresses. An IP address may be used by more than one host at a time or over a period of time. E.g. if I blacklist a virus-infected zombie, have I just blacklisted a NATted network? Will the zombie get through again after it has obtained another DHCP lease? (in which case I'll blacklist the whole DHCP range eventually) Section 3.3 The CSV spec makes a nice distinction between authentication and authorization. So why is the CSV authorization step defined by a document called "Client SMTP authentication"? (Actually this appears to be a typo since the document calls itself "Client SMTP authorization".) draft-crocker-marid-csvhna-00 Section 2 DNS-based Mapping "Often when contacted by a remote host, a host uses a reverse-DNS query to get the name of the remote host." This should be changed to "names" plural -- there can be multiple PTR records for a given IP address. "Although [forward + reverse DNS consistency checking] has known limitations, it is considered sufficient for many basic uses." This comment needs a citation to a document contining a proper explanation of the limitations. I'm very dubious of the weaker DNS checking suggested in 2.1 and 2.2. I think there should be much more discussion of the possible attacks and defences, and why they are under consideration when full foward + reverse checking is available. The whole section needs to be more explicit about how the process works and what the actions of the checker should be in reaction to various kinds of failure. 3.1 StartTLS Again this needs to be more explicit about the authentication process. 3.2 SMTP Auth As I understand it this draft is intended to be independent of SMTP. Therefore SASL should be cited instead. In addition to this, SASL is generally used for user authentication not hostname authentication. This section needs to be more explicit about how this unusual use works in practice. There also needs to be some comment on the limits to scalability of this option, since it requires pre-existing bilateral agreements between all senders and all recipients. 4 Independent Policy Services "In effect, the question about domain name use is a question about the reputation and accountability of the domain name administrator." No, it is a question about the reliability of the host. This entire section refers to a part of the CSV process covered by the DNS draft. draft-ietf-marid-dsvcsa-00 Sections 4 & 5 These sections overlap rather a lot. They also omit to specify what the server should do if the client's CSA records has invalid data. What should go in the (reserved) port field? What does the SRV target mean for a client? i.e. what should go in that field? Does it have to be the same as the EHLO domain name if the client is authorized? If the client is not authorized, this draft specifies that the EHLO name should go in the target. Does it still have to have address records in accordance with RFC 2782? 6 Domain administrator advice Paragraph three appears to be a discussion of SMTP server policy, not DNS. It probably belongs in the DNA draft. The protocol specified in this draft appears to be (I'm reading between the lines here) that the EHLO domain name stated by the SMTP client is used to look up a SRV record. This record states in the weight field if that name may be used by an SMTP client, and it also contains a target name. The DNS reply should contain additional data, being the IP address records associated with this target name. One of these must match the client IP address from the SMTP connection in order for the EHLO domain name to be considered valid. Or maybe (according to HNA) the IP addresses associated with the EHLO domain itself must match the connection IP address. Or maybe the reverse DNS must agree too. This is not clear. It's also not clear how this relates to the RFC 2821 nix on EHLO checks. draft-crocker-marid-csvdna-00 There's no discussion of the obvious attack of a client recommending accreditation services that all say the client is wonderful. -- Tony Finch http://dotat.at/ From owner-ietf-mxcomp@mail.imc.org Tue Jun 15 10:38:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22150 for ; Tue, 15 Jun 2004 10:38:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5FER9gb029368; Tue, 15 Jun 2004 07:27:09 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5FER9e2029367; Tue, 15 Jun 2004 07:27:09 -0700 (PDT) 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.9) with ESMTP id i5FER8Gl029349 for ; Tue, 15 Jun 2004 07:27:09 -0700 (PDT) (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.34) id 1BaEtp-0006aR-Gr for ietf-mxcomp@imc.org; Tue, 15 Jun 2004 09:27:09 -0500 To: "IETF MARID WG" References: <20040611172844.GB32187@Space.Net> <40CE8EAF.4050505@elvey.com> From: wayne Reply-To: "IETF MARID WG" Date: Tue, 15 Jun 2004 09:26:53 -0500 In-Reply-To: <40CE8EAF.4050505@elvey.com> (Matthew Elvey's message of "Mon, 14 Jun 2004 22:52:47 -0700") 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 (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Humming at the Interim (Was: MTAmark) Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-4.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <40CE8EAF.4050505@elvey.com> Matthew Elvey writes: > On 6/11/2004 11:04 AM, wayne sent forth electrons to convey: > >>You guys are raising good and interesting points about both the pros >>and cons of things like MTAMARK, but this is all irrelevant. Since >> the interim meeting, all 2821 proposals are now out of scope. >> > I'm sorry, but I WAS at the interim meeting. I believe that was NOT > decided. > In which of the 13 items mentioned in the minutes is this? > Perhaps I was out of the room. Yes, I know you were at the meeting also, as were several others. I've asked around and apparently what I remember isn't at all what others remember. What I remember is that near the end of the second day, there were three hums taking in quick succession. The first asked if MARID should pursue the Caller-ID/SPF thing, and I remember a loud hum. Then I clearly remember someone (Ted? Andy?) saying that this would mean that we wouldn't pursue 2821 proposals, which I was quite surprised by, and I remember others being unclear on this. So, a second hum was taking on the issue of whether we should pursue both, and there wasn't a rough consensus that we should. Finally, after a little more discussion, a hum was taken as to whether we should go back to the 2821 issue after we have finished 2821, and I seem to recall a consensus on that. > What Markus has said re. RFC 2418 / 3.3 is correct, Agreed. > to which I should add that IMO, the minutes are not accurate regarding > the hum - as I'd discussed with a chair, and IIRC, he said he's > planning to revise in a new minutes version. Well, memories are fading. If my memory is wrong, I will actually be very happy. I really don't want the 2821 proposals being off the table. If my faulty memory has created confusion and problems, please accept my apologies. -wayne From owner-ietf-mxcomp@mail.imc.org Tue Jun 15 11:19:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26470 for ; Tue, 15 Jun 2004 11:19:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5FF8cPb038281; Tue, 15 Jun 2004 08:08:38 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5FF8cuI038280; Tue, 15 Jun 2004 08:08:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5FF8cse038263 for ; Tue, 15 Jun 2004 08:08:38 -0700 (PDT) (envelope-from edlewis@arin.net) Received: by smtp2.arin.net (Postfix, from userid 5003) id A454B19B34E; Tue, 15 Jun 2004 11:07:17 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 19D6519B77C; Tue, 15 Jun 2004 11:07:17 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1775532; Tue, 15 Jun 2004 11:08:35 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Tue, 15 Jun 2004 10:38:22 -0400 To: "IETF MARID WG" From: Edward Lewis Subject: Re: comments on SPF Cc: "IETF MARID WG" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63-arin1 (2004-01-11) on smtp2.arin.net X-Spam-Status: No, hits=-8.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63-arin1 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 17:54 -0500 6/14/04, wayne wrote: >Yes, the exists: mechanism explicitly checks *only* A records, even if >the MTA connection is via IPv6. This is to maintain compatibility >with already existing DNS blacklists and whitelists. That answers my question. >Personally, I'm not that attached to the %{t} macro variable, so maybe >I'm underselling it. ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. From owner-ietf-mxcomp@mail.imc.org Tue Jun 15 11:57:03 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28889 for ; Tue, 15 Jun 2004 11:57:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5FFdp1O044949; Tue, 15 Jun 2004 08:39:51 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5FFdpUw044945; Tue, 15 Jun 2004 08:39:51 -0700 (PDT) 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.9) with ESMTP id i5FFdjhs044915 for ; Tue, 15 Jun 2004 08:39:46 -0700 (PDT) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id 952C5E0A42; Tue, 15 Jun 2004 11:39:44 -0400 (EDT) Date: Tue, 15 Jun 2004 11:39:44 -0400 From: John Leslie To: Tony Finch Cc: Dave Crocker , ietf-mxcomp@imc.org Subject: Re: CSV specification revision available Message-ID: <20040615153944.GS44160@verdi> References: <1665390638.20040614190711@brandenburg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Thanks, Tony, for your extensive comments. Tony Finch wrote: > > The new documents are much clearer, Thank you. (There's been a lot of discussion leading to them.) > however they are still vague on important details, they take an awfully > long time to get to the point, and they contain an amazing amount of > irrelevant digression. We mostly adopted the attitude that if any of us were confused, more explanation was needed. > I have a few comments: Some of these I need to defer to Dave Crocker. Alas, it will be several days before we know _whether_ he'll have useful Internet access at his vacation spot. Please note, when I "defer to Dave" it doesn't mean I'm unwilling to discuss the issue -- merely that I want Dave to be responsible for changes to the document in question. > draft-crocker-marid-smtp-validate-01 (This is the one document we tried to keep short.) > Section 1, Address-based Authentication: > > It's probably worth explaining why this doesn't work so well in the > current Internet, particularly the use of NATs and dynamically-allocated > addresses. An IP address may be used by more than one host at a time or > over a period of time. E.g. if I blacklist a virus-infected zombie, have I > just blacklisted a NATted network? Will the zombie get through again after > it has obtained another DHCP lease? (in which case I'll blacklist the > whole DHCP range eventually) We discussed most of this, and Dave chose the terse wording: } } Increased topological, transfer and access complexities... I'm going to defer to Dave whether to expand that. > The CSV spec makes a nice distinction between authentication and > authorization. So why is the CSV authorization step defined by a document > called "Client SMTP authentication"? (Actually this appears to be a typo > since the document calls itself "Client SMTP authorization".) This is a typo. It will be fixed. > draft-crocker-marid-csvhna-00 > > Section 2 DNS-based Mapping > > "Often when contacted by a remote host, a host uses a reverse-DNS query to > get the name of the remote host." This should be changed to "names" plural > -- there can be multiple PTR records for a given IP address. I agree with you, but I'm going to defer to Dave on changes. > "Although [forward + reverse DNS consistency checking] has known > limitations, it is considered sufficient for many basic uses." This > comment needs a citation to a document contining a proper explanation of > the limitations. There wasn't time to chase references. I'm confident we'll add some. > I'm very dubious of the weaker DNS checking suggested in 2.1 and 2.2. I > think there should be much more discussion of the possible attacks and > defences, and why they are under consideration when full foward + reverse > checking is available. > > The whole section needs to be more explicit about how the process works > and what the actions of the checker should be in reaction to various kinds > of failure. I agree with you, but I'd much prefer to defer to Dave on actual wording. > 3.1 StartTLS > > Again this needs to be more explicit about the authentication process. I'm not sure I agree. RFC3207 is cited. But I'll defer to Dave. > 3.2 SMTP Auth > > As I understand it this draft is intended to be independent of SMTP. > Therefore SASL should be cited instead. Defer to Dave. > In addition to this, SASL is generally used for user authentication not > hostname authentication. This section needs to be more explicit about how > this unusual use works in practice. Defer to Dave. > There also needs to be some comment on the limits to scalability of this > option, since it requires pre-existing bilateral agreements between all > senders and all recipients. I agree, but I'll defer to Dave. > 4 Independent Policy Services > > "In effect, the question about domain name use is a question about the > reputation and accountability of the domain name administrator." > > No, it is a question about the reliability of the host. This entire > section refers to a part of the CSV process covered by the DNS draft. I'm afraid we'll have to agree to disagree here. We intend for the domain-name to be closely bound to those who administer the host -- not the machine itself. And we're more concerned about quick response to problems than we are about the actual configuration of the host. > draft-ietf-marid-dsvcsa-00 > > Sections 4 & 5 > > These sections overlap rather a lot.i Indeed they do. We wanted to introduce the concept before the details. > They also omit to specify what the server should do if the client's > CSA records has invalid data. True. We're going to have to confer on what to say about these cases. > What should go in the (reserved) port field? Zero. (I'm sure this was in a previous draft!) > What does the SRV target mean for a client? i.e. what should go in > that field? It should ordinarily be a domain-name (typically the same as the EHLO string) that resolves to the correct list of IP addresses. > Does it have to be the same as the EHLO domain name if the client is > authorized? No, but it ordinarily will be. > If the client is not authorized, this draft specifies that the > EHLO name should go in the target. Does it still have to have > address records in accordance with RFC 2782? We really don't care: the list of IP Addresses (if any) will be ignored. I agree some more words are needed. We'll confer on that. > 6 Domain administrator advice > > Paragraph three appears to be a discussion of SMTP server policy, not DNS. > It probably belongs in the DNA draft. It got written here: we'll confer on whether there's a better place for it. > The protocol specified in this draft appears to be (I'm reading between > the lines here) that the EHLO domain name stated by the SMTP client is > used to look up a SRV record. This record states in the weight field if > that name may be used by an SMTP client, and it also contains a target > name. The DNS reply should contain additional data, being the IP address > records associated with this target name.i Correct. > One of these must match the client IP address from the SMTP connection > in order for the EHLO domain name to be considered valid. Or maybe > (according to HNA) the IP addresses associated with the EHLO domain > itself must match the connection IP address. Or maybe the reverse DNS > must agree too. This is not clear.i For various reasons, we agreed not to talk about "authentication" here. We consider it to be an "optimization" that the match of an IP address here might satisfy the "authentication" need. Thus, there is no need for any IP checking in order for the _name_ to be authorized. I agree the wording could be clearer. We'll confer on this. > It's also not clear how this relates to the RFC 2821 nix on EHLO checks. I do believe we've been over this before... RFC2821 specifically allows error responses to EHLO, but forbids one very particular case: ] ] An SMTP server MAY verify that the domain name parameter in the EHLO ] command actually corresponds to the IP address of the client. ] However, the server MUST NOT refuse to accept a message for this ] reason if the verification fails We are not refusing "for that reason" (though, of course, it's already quite common to refuse for that reason). I quite agree that a clarification of this issue probably belongs in the published MARID RFC. > draft-crocker-marid-csvdna-00 > > There's no discussion of the obvious attack of a client recommending > accreditation services that all say the client is wonderful. I must disagree. See section 3, specifically the discussion of "negative weighting", for example. -- John Leslie From owner-ietf-mxcomp@mail.imc.org Tue Jun 15 12:05:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29345 for ; Tue, 15 Jun 2004 12:05:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5FFrhtn047704; Tue, 15 Jun 2004 08:53:43 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5FFrh4g047703; Tue, 15 Jun 2004 08:53:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from orange.csi.cam.ac.uk (exim@orange.csi.cam.ac.uk [131.111.8.77]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5FFrgv5047695 for ; Tue, 15 Jun 2004 08:53:42 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from fanf2 (helo=localhost) by orange.csi.cam.ac.uk with local-esmtp (Exim 4.12) id 1BaGFr-0004ZR-00; Tue, 15 Jun 2004 16:53:43 +0100 Date: Tue, 15 Jun 2004 16:53:43 +0100 From: Tony Finch X-X-Sender: fanf2@orange.csi.cam.ac.uk To: John Leslie cc: Dave Crocker , ietf-mxcomp@imc.org Subject: Re: CSV specification revision available In-Reply-To: <20040615153944.GS44160@verdi> Message-ID: References: <1665390638.20040614190711@brandenburg.com> <20040615153944.GS44160@verdi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 15 Jun 2004, John Leslie wrote: > > > 4 Independent Policy Services > > > > "In effect, the question about domain name use is a question about the > > reputation and accountability of the domain name administrator." > > > > No, it is a question about the reliability of the host. This entire > > section refers to a part of the CSV process covered by the DNS draft. > > I'm afraid we'll have to agree to disagree here. We intend for the > domain-name to be closely bound to those who administer the host -- > not the machine itself. And we're more concerned about quick response > to problems than we are about the actual configuration of the host. OK, but how does the section relate to authenticating that the host you are talking to is permitted to use the name it has claimed? There's no description of a mechanism for doing that. > > draft-crocker-marid-csvdna-00 > > > > There's no discussion of the obvious attack of a client recommending > > accreditation services that all say the client is wonderful. > > I must disagree. See section 3, specifically the discussion of > "negative weighting", for example. Ah yes. This should probably be cross-referenced in the security considerations section, and flagged as an important consideration if the SMTP server pays any attention to the client's suggestions. Otherwise thanks for reading my comments. I look forward to the next versions of the documents. -- Tony Finch http://dotat.at/ From owner-ietf-mxcomp@mail.imc.org Tue Jun 15 12:15:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29660 for ; Tue, 15 Jun 2004 12:15:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5FFxMUo049077; Tue, 15 Jun 2004 08:59:22 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5FFxMtl049075; Tue, 15 Jun 2004 08:59:22 -0700 (PDT) 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.9) with ESMTP id i5FFxLmX049064 for ; Tue, 15 Jun 2004 08:59:21 -0700 (PDT) (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.34) id 1BaGL7-0007hz-04 for ietf-mxcomp@imc.org; Tue, 15 Jun 2004 10:59:24 -0500 To: "IETF MARID WG" References: From: wayne Reply-To: "IETF MARID WG" Date: Tue, 15 Jun 2004 10:59:08 -0500 In-Reply-To: (Margaret Olson's message of "Mon, 14 Jun 2004 21:53:45 -0400") 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 (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: SPF and SenderID /MARID comparisons Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-4.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In "Olson, Margaret" writes: > This is a follow up to the discussion on jabber this afternoon, on comparing > SPF records to SenderID/MARID records. thanks! > [ details deleted ] That makes up to > three providers for sending email, none of them related to one another. Ok > For each of these three email providers, bounces are handled by the provider > in a manner appropriate to the function provided. Generally, for person to > person mail the bounces go back to the sender. For the other two, the > bounces are handled by the application. If you look at SPF version 1, each > provider publishes for his or her domain and there is no coordination > between the various means that the same sender uses to send mail. But it's > highly likely that the purported responsible domain in all three cases is > that of the sender. So for SenderID/MARID, there is a new record which > points to three other records: one each for the ISP, the shopping cart, and > the email marketing service. SPFv1 has long had both include: and redirect= that, from what I can tell, would handle these situations just fine. > For large companies, the tangled manner in which they send mail is even more > complicated, with multiple departments each outsourcing to multiple > providers. I can believe that. > Using the PRD will mean that far more domains will need to be publishing > SenderID records than are publishing SPF records to get the same level of > participation. I don't understand this at all. To the best of my knowledge, there is no semantic difference between the SenderID and SPFv1 records. They both have the same features and use the same algorithm. The only difference is the syntax. Granted, the syntax difference may (but by no means must) allow for future differences in semantics, but until that happens, they are, as Jim Lyon pointed out, isomorphic. -wayne From owner-ietf-mxcomp@mail.imc.org Tue Jun 15 12:47:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01612 for ; Tue, 15 Jun 2004 12:47:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5FGZqQg058788; Tue, 15 Jun 2004 09:35:52 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5FGZqdm058787; Tue, 15 Jun 2004 09:35:52 -0700 (PDT) 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.9) with ESMTP id i5FGZo6n058760 for ; Tue, 15 Jun 2004 09:35:50 -0700 (PDT) (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.34) id 1BaGuJ-0008B1-UD for ietf-mxcomp@imc.org; Tue, 15 Jun 2004 11:35:53 -0500 To: "IETF MARID WG" From: wayne Reply-To: "IETF MARID WG" Date: Tue, 15 Jun 2004 11:35:31 -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 (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: rough consensus and working code Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-4.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Yesterday in the Jabber session, Marshall raised the issue that there really doesn't appear to be a rough consensus in this working group, and people are not working toward a compromise solution. In fact, people appear to be hardening their positions. If this working group can't reach a rough consensus, then it is unlikely that the IESG will agree with any RFCs we try to publish. I have to agree with this assessment. There doesn't appear to be a rough consensus. However, the long standing IETF mantra has, to the best of my knowledge, been "rough consensus *AND* working code". What we lack with most proposals is working code. I think the lack of a rough consensus is in large part due to the lack of working code. Working code quickly dispels both wishful-thinking and FUD. Working code is a different way of expressing a proposal so disagreements and misunderstandings about a proposal can be cleared up by looking at the code and then either the code or the proposal can be fixed to make things clearer. The devil is always in the details. As long as we continue to consider proposals that don't have working code, we allow people to nit-pick proposals that are complete, while glossing over the problems with proposals that exist on paper only. Maybe I'm wrong, but I strongly suspect that the IESG is going to require working implementations of any RFC we submit as standard track RFCs. At some point before we select one or more proposals, we have to have a near-finalized document with working code, preferably with at least two different people/organizations creating code from the spec. I see three basic possibilities: 1) We stop talking about proposals that don't have working code 2) People putting forward proposals need to start publish code ASAP 3) We change the schedule to allow for more time. Back in March, I made the following post which I will repost here: http://www.imc.org/ietf-mxcomp/mail-archive/msg00617.html It is a long post but, sadly, it has worn well with time. Only a few things really need to be changed. I posted it before the Caller-ID proposal came around, so please change the "Gordon, Hadmut, Markus" to "Harry, Jim, Bob". Also, since this was posted months ago, you need to change SPF email checking from "5-50 million messages per *month*" to "5-50 million messages per *day*" I think it is sad that very little has changed in the intervening months with respect to working code. Working code is not only very important, but something that can't just be whipped up quickly. (Code can be written quickly, but it is rarly working code.) The final paragraph almost makes me want to cry. * To: "IETF MXCOMP" * Subject: Re: Ruminations * From: wayne * Date: Mon, 29 Mar 2004 12:22:42 -0600 In <20040328035322.GA45563@xxxxxxxxx> Markus Stumpf writes: > On Sat, Mar 27, 2004 at 03:36:21PM -0600, Gordon Fecyk wrote: >> It's happening right now. Meng should pat himself on the back for a great >> marketing campaign but ultimately, they decided. Meng produced a lot of working code, and listened to what many other people said. SPF didn't gain it's current popularity by marketing. It is the leading designated sender system because of the work of many many people working on many different parts of the problem. > But it may take some time to se any results at all. > Currently there is a big hype about adding SPF records. So what? > It has no effect at all. One of the things that was discussed last summer on the SPF lists is how to solve the chicken-and-egg problem of no one publishing SPF records if no one checks them, and no one checking them if there aren't any published. We realized that people would publish SPF records, just to make a public statement by the domain owners that they want to protect their brand names and good reputation. This has benefits even if few people are actually checking the SPF records. With this in mind, we was decided that we needed to pay *very* close attention to making it as easy as possible for people to publish SPF records, and for those SPF records to require minimal maintenance. Hence the creation of the 'mx', 'ptr' and 'include' mechanisms, and the "SPF wizards" web pages which help people create SPF records. > If I didn't, miss something, I'd like to see a big ISP or mail hoster > that actually rejects emails because of SPF records. As soon as that is > going to happen THEN the users will tell and then we'll see if that big > entity is going to keep a counterstance. And that is what I still doubt, > at least until all the current problems are resolved and the solution > implemented in the MTAs. The amount of email that is being checked with SPF is doubling ever 2-3 weeks and is currently on the order of 5-50 million messages per month. Yes, that is a very small percentage of all email, but the rate of growth is almost scary. The amount of email being checked via SPF has already meant that there has been a stead stream of email forwarders and such that have wandered into the the SPF mailing lists because SPF of the effect that SPF has had on them. Yes, many of them are not happy with the situation or with the possible solutions such as SRS. However, the response has actually been better than I was expecting. I'm seeing quite a few forwarders adopting things like SRS in order to keep email flowing smoothly. So, the first goal of SPF was to make it easy to publish SPF records. The next goal was to make it easy for mail admins to adopt SPF and SRS by creating easy-to-install plugins to the major MTAs. It was decided that any time there was a choice between making things easier for domain owners and mail admins or making the job of writing SPF implementations easier, the domain owners and mail admins should win. The result has been that the creation of high quality SPF implementations has taken some time, and this has made it harder for mail admins to start checking SPF records, especially for the "big ISPs". This situation is improving and I would say that SPF checking will have had enough field testing and have high enough quality/performance implementations that you will start seeing larger ISPs checking SPF records by this summer, or maybe earlier. This working group, however, appears to already be falling badly behind on its own schedule, with no end of the debate about 'which identities' in sight. Instead we get to hear the sour-grapes moaning from Gordon, Hadmut, Markus, et al who, over the last year, have decided to put a lot more effort into talking than actually implementing their ideas. If you guys had actually been able to work *with* people instead of promoting exclusively yourselves, either one of your proposals would have become the de-facto standard that SPF has become. Maybe, if the IETF decides to be irrelevant, one of you will get the honor of a de-jure standard, but I doubt that will happen either. Oh, and before you get all huffy about my comments showing that I can't "work with people", remember that having a thick skin is an important part of being able to work with people. I've held my tounge for a long time while various people have poked jabs at SPF. If I can deal with such jabs as long as there is something productive coming with them. The proof of the pudding is in the eating and there are more people actually working together on SPF than all of the other LMAP proposals, plus this working group combined. Sadly, what I really expect to happen is over the next year or so, this working group will try to come up with some sort of modified SPF proposal with gratuitously incompatible changes. Mean while, SPF will continue to slowly evolve, adopting any really good suggestions that are proposed and ignoring the bad ones, just like it has since last summer. After much debate, (2 years?) this working group will finally realize that SPF is the de-facto standard and will finally decide to throw out their work and adopt SPF. *yawn* I have code to write and bugs to fix in the SPF system. -wayne From owner-ietf-mxcomp@mail.imc.org Tue Jun 15 12:54:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01781 for ; Tue, 15 Jun 2004 12:54:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5FGhrm9060712; Tue, 15 Jun 2004 09:43:53 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5FGhrZA060711; Tue, 15 Jun 2004 09:43:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from CORPMAIL1.roving.com (cctmby1.roving.com [208.198.98.24]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5FGhpRU060685 for ; Tue, 15 Jun 2004 09:43:52 -0700 (PDT) (envelope-from molson@constantcontact.com) Content-class: urn:content-classes:message Subject: RE: SPF and SenderID /MARID comparisons MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Tue, 15 Jun 2004 12:43:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <3B7C31950DEB8445B24D3FDF991E81BBD6DB@CORPMAIL1.roving.com> Thread-Topic: SPF and SenderID /MARID comparisons Thread-Index: AcRS8wuu95pgVduMQzCS+o6lKoWXDgAA5dnw From: "Olson, Margaret" To: "IETF MARID WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5FGhqRU060704 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > I don't understand this at all. To the best of my knowledge, there is > no semantic difference between the SenderID and SPFv1 records. They > both have the same features and use the same algorithm. The only > difference is the syntax. Granted, the syntax difference may (but by > no means must) allow for future differences in semantics, but until > that happens, they are, as Jim Lyon pointed out, isomorphic. Maybe I'm misunderstanding something. Isn't SPF v1 checking the 2821 MAIL-FROM and SenderID checking the SUBMITTER? For an incredible amount of mail these are not the same thing; the MAIL-FROM is the bounce and error handler, and the SUBMITTER is the same as the 2822 from (or the forwarder or the mail server). The MAIL-FROM and the SUBMITTER will generally be the same for person to person mail, but are not likely to be the same for either volume or transactional mailings. A cruise through the headers in my personal mail inbox regularly shows a rich variety of domain combinations in the return-path and from fields. Margaret. From owner-ietf-mxcomp@mail.imc.org Tue Jun 15 13:33:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04134 for ; Tue, 15 Jun 2004 13:33:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5FHNW88071217; Tue, 15 Jun 2004 10:23:32 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5FHNW3d071216; Tue, 15 Jun 2004 10:23:32 -0700 (PDT) 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.9) with SMTP id i5FHNVEZ071167 for ; Tue, 15 Jun 2004 10:23:31 -0700 (PDT) (envelope-from maex@Space.Net) Received: (qmail 17379 invoked by uid 1013); 15 Jun 2004 17:23:24 -0000 Date: Tue, 15 Jun 2004 19:23:24 +0200 From: Markus Stumpf To: IETF MARID WG Subject: Re: MTAmark (was: Reality check please) Message-ID: <20040615172324.GA16989@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 Mon, Jun 14, 2004 at 06:05:37PM -0700, Hallam-Baker, Phillip wrote: > So, it appears that MARID does not solve your problem the way you > would like it to be solved. Wrong. One draft that the MARID WG has produced and which urban legends tell will be the MARID standard does not solve the problem in the way I want it to be solved. > So what? MARID solves the problem it was chartered to solve in the > way it was chartered to solve it. The draft-marid-core solves it in ONE way. That charter does not give a way at all to solve the problem and surely it doesn't talk about accept and rate or reject. This decision is part of the decision finding process. > It sounds to me that you are part of the problem that we are trying > to solve here. With about 100 Mio addresses on the reject block and a straight blocking rate of 40% connections a day on a 30000 connections a day mailserver with about 1 complaint per month I don't think I'm too big a problem. As it looks now MARID will not solve a problem but introduce a bunch of new ones, but then the charter doesn't say it shouldn't. \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@mail.imc.org Tue Jun 15 13:36:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04314 for ; Tue, 15 Jun 2004 13:36:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5FHQg0e071951; Tue, 15 Jun 2004 10:26:42 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5FHQg64071950; Tue, 15 Jun 2004 10:26:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5FHQg8N071935 for ; Tue, 15 Jun 2004 10:26:42 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.131.244.249] ([::ffff:216.168.239.87]) (AUTH: LOGIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Tue, 15 Jun 2004 13:26:43 -0400 id 000E3E56.40CF3153.000044E1 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2A7BA78A-BEF1-11D8-B76B-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: rough consensus and working code Date: Tue, 15 Jun 2004 13:26:41 -0400 To: "IETF MARID WG" X-Mailer: Apple Mail (2.613) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jun 15, 2004, at 12:35 PM, wayne wrote: > I have to agree with this assessment. There doesn't appear to be a > rough consensus. However, the long standing IETF mantra has, to the > best of my knowledge, been "rough consensus *AND* working code". What > we lack with most proposals is working code. I think implementations are a good thing, a very good thing. However, RFC 2026 mentions that to get a Proposed Standard RFC implementations are not required (though they are encouraged). To get a standard from Proposed Standard to Draft Standard, two separate interoperating implementations are required. Our milestones explicitly says "PS" - for Proposed Standard. -andy From owner-ietf-mxcomp@mail.imc.org Tue Jun 15 13:55:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05231 for ; Tue, 15 Jun 2004 13:55:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5FHfAf3075047; Tue, 15 Jun 2004 10:41:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5FHfA6D075046; Tue, 15 Jun 2004 10:41:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from xuxa.iecc.com (xuxa.iecc.com [208.31.42.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5FHf97v075039 for ; Tue, 15 Jun 2004 10:41:09 -0700 (PDT) (envelope-from johnl@iecc.com) Received: (qmail 2240 invoked by uid 100); 15 Jun 2004 17:41:11 -0000 Date: 15 Jun 2004 17:41:11 -0000 Message-ID: <20040615174111.2239.qmail@xuxa.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: FTC says no do-not-email until there's authentication Organization: I.E.C.C., Trumansburg NY USA Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The U.S. Federal Trade Commission just released their report on a do-not-email list, which says that it's not a good idea, at least not right now. This wouldn't be relevant to MARID except that they said that the biggest reason it's not a good idea is that it's nearly impossible to tell where any particular spam came from, and Internet e-mail needs better authentication, like what MARID is doing. They go on to say that they hope that industry (that's us) come up with something, but if we don't, the government should mandate one. The FTC understands the spam problem quite well, they know all of the other reasons that a do-not-email list, particularly one of individual addresses, would be a bad idea, so PLEASE don't rehash them here. If you want to comment further, it would be a good idea to look at the press release and report first. You can quote the first two words on page 33 so we can tell that you've looked at the report. http://www.ftc.gov/opa/2004/06/canspam2.htm (press release) http://www.ftc.gov/reports/dneregistry/report.pdf (report) Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY http://www.taugh.com From owner-ietf-mxcomp@mail.imc.org Tue Jun 15 13:57:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05297 for ; Tue, 15 Jun 2004 13:57:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5FHmKT9077041; Tue, 15 Jun 2004 10:48:20 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5FHmKP2077039; Tue, 15 Jun 2004 10:48:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from xuxa.iecc.com (xuxa.iecc.com [208.31.42.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5FHmJoK076996 for ; Tue, 15 Jun 2004 10:48:19 -0700 (PDT) (envelope-from johnl@iecc.com) Received: (qmail 4172 invoked by uid 100); 15 Jun 2004 17:48:22 -0000 Date: 15 Jun 2004 17:48:22 -0000 Message-ID: <20040615174822.4171.qmail@xuxa.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: Re: rough consensus and working code In-Reply-To: <2A7BA78A-BEF1-11D8-B76B-000A95B3BA44@hxr.us> Organization: I.E.C.C., Trumansburg NY USA Cc: andy@hxr.us Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >> rough consensus. However, the long standing IETF mantra has, to the >> best of my knowledge, been "rough consensus *AND* working code". What >> we lack with most proposals is working code. > >I think implementations are a good thing, a very good thing. > >However, RFC 2026 mentions that to get a Proposed Standard RFC >implementations are not required (though they are encouraged). We really do need working code. Publishing records is fine, but until people start running a lot of mail through MARID authentication checkers, we won't know whether it really scales or how easy it is for bad guys to circumvent. This doesn't mean that you have to use it for live spam filtering (you'd be nuts to bounce mail that failed SPF, for example) but at least log it and count what you find. I know there's open source code for domain keys coming shortly. What's available for SPF, Caller ID, and the merged thing? Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY http://www.taugh.com From owner-ietf-mxcomp@mail.imc.org Tue Jun 15 14:15:52 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06146 for ; Tue, 15 Jun 2004 14:15:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5FI2Ibp081322; Tue, 15 Jun 2004 11:02:18 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5FI2IXG081321; Tue, 15 Jun 2004 11:02:18 -0700 (PDT) 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.9) with ESMTP id i5FI2HHx081315 for ; Tue, 15 Jun 2004 11:02:17 -0700 (PDT) (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.34) id 1BaIG5-0000ch-53 for ietf-mxcomp@imc.org; Tue, 15 Jun 2004 13:02:21 -0500 To: "IETF MARID WG" References: <2A7BA78A-BEF1-11D8-B76B-000A95B3BA44@hxr.us> From: wayne Reply-To: "IETF MARID WG" Date: Tue, 15 Jun 2004 13:02:04 -0500 In-Reply-To: <2A7BA78A-BEF1-11D8-B76B-000A95B3BA44@hxr.us> (Andrew Newton's message of "Tue, 15 Jun 2004 13:26:41 -0400") 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 (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: rough consensus and working code Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-4.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <2A7BA78A-BEF1-11D8-B76B-000A95B3BA44@hxr.us> Andrew Newton writes: > On Jun 15, 2004, at 12:35 PM, wayne wrote: >> I have to agree with this assessment. There doesn't appear to be a >> rough consensus. However, the long standing IETF mantra has, to the >> best of my knowledge, been "rough consensus *AND* working code". What >> we lack with most proposals is working code. > > I think implementations are a good thing, a very good thing. > > However, RFC 2026 mentions that to get a Proposed Standard RFC > implementations are not required (though they are encouraged). To get > a standard from Proposed Standard to Draft Standard, two separate > interoperating implementations are required. *sigh* Ok, for the second time in two weeks, I will quote the relevant potions of RFC2026: Usually, neither implementation nor operational experience is required for the designation of a specification as a Proposed Standard. However, such experience is highly desirable, and will usually represent a strong argument in favor of a Proposed Standard designation. The IESG may require implementation and/or operational experience prior to granting Proposed Standard status to a specification that materially affects the core Internet protocols or that specifies behavior that may have significant operational impact on the Internet. I never said that we are *required* to have working code. What I have said is that I think that working code helps reach consensus and that the IESG may likely consider MARID to "materially affect a core Internet Protocol" and/or "have significant operational impact on the Internet". Personally, I think the IESG would be nuts not to require such testing and that we would be nuts not to have all our ducks lined up in a row before we go to the IESG asking for a PS RFC. The requirements for going from a PS to a DS are much higher, in particular needing two implemenations of every feature and I suspect that the IESG will not require that level of testing. For a slightly longer discussion, see my earlier note at: http://www.imc.org/ietf-mxcomp/mail-archive/msg01796.html -wayne From owner-ietf-mxcomp@mail.imc.org Tue Jun 15 14:28:58 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06914 for ; Tue, 15 Jun 2004 14:28:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5FIErRJ084186; Tue, 15 Jun 2004 11:14:53 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5FIEr9g084185; Tue, 15 Jun 2004 11:14:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5FIEqO8084168 for ; Tue, 15 Jun 2004 11:14:52 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i5FIDYUD008376; Tue, 15 Jun 2004 11:13:34 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i5FIDXTA008373; Tue, 15 Jun 2004 11:13:33 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Tue, 15 Jun 2004 11:13:33 -0700 (PDT) From: "william(at)elan.net" To: John Levine cc: ietf-mxcomp@imc.org, Subject: Re: rough consensus and working code In-Reply-To: <20040615174822.4171.qmail@xuxa.iecc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 15 Jun 2004, John Levine wrote: > >> rough consensus. However, the long standing IETF mantra has, to the > >> best of my knowledge, been "rough consensus *AND* working code". What > >> we lack with most proposals is working code. > > > >I think implementations are a good thing, a very good thing. > > > >However, RFC 2026 mentions that to get a Proposed Standard RFC > >implementations are not required (though they are encouraged). > > We really do need working code. Publishing records is fine, but until > people start running a lot of mail through MARID authentication > checkers, we won't know whether it really scales or how easy it is for > bad guys to circumvent. This doesn't mean that you have to use it for > live spam filtering (you'd be nuts to bounce mail that failed SPF, for > example) but at least log it and count what you find. > > I know there's open source code for domain keys coming shortly. What's > available for SPF, Caller ID, and the merged thing? Its inappropriate to compare domain keys to MARID, they are not doing IETF WG effort. If anything you can compare it to individual/non-IETF-group effort like SPF and in that case you see that there is substantial amount of working code available and they are major component of the MARID. Considering SPF community, I think once standards here are formalized and these standards have community support (i.e. "consensus"), the code will become available very soon. --- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Tue Jun 15 14:42:33 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07735 for ; Tue, 15 Jun 2004 14:42:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5FIQNVv087721; Tue, 15 Jun 2004 11:26:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5FIQNgB087719; Tue, 15 Jun 2004 11:26:23 -0700 (PDT) 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.9) with ESMTP id i5FIQKjn087665 for ; Tue, 15 Jun 2004 11:26:21 -0700 (PDT) (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.34) id 1BaIdM-0000uj-Kz for ietf-mxcomp@imc.org; Tue, 15 Jun 2004 13:26:24 -0500 To: "IETF MARID WG" From: wayne Reply-To: "IETF MARID WG" Date: Tue, 15 Jun 2004 13:26:08 -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 (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: XML exploits Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-4.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In the overtime part of the Jabber session yesterday, Andy asked a good question: Has anybody ever known of an exploit that targeted a vulnerability in the XML spec? When no one answered, Jim Lyon responded " Andy, you should take that as a resounding no." Now there is a problem here folks. When I first started getting interested in designated sender systems (before SPF was even started), I investigated the security issues of DNS, IP spoofing and SMTP. I've investigated them several times since then. There *are* problems of various forms will all of those systems, but none that I think are critical to SPF. However, I could easily have answered questions similar to what Andy asked about the proposals I'm involved in. Now, a quick check of bugtraq finds the following XML related problems: Microsoft Internet Explorer XML Parsing Denial Of Service Vulnerability remote Yes published May 10, 2004 http://www.securityfocus.com/bid/10318 This is *exactly* the type of problem that mail admins are to justify not wanting anything to do with XML on their mail servers. They are already under enough DoS attacks, thank you very much. Multiple Vendor XML DTD Parameter Entity SOAP Server Denial Of Service Vulnerability remote Yes published Dec 11, 2003 Microsoft Internet Explorer XML Object Zone Restriction Bypass Vulnerability remote Yes published Nov 11, 2003 Sun Java XML Document Nested Entity Denial Of Service Vulnerability remote No published Sep 22, 2003 The list goes on, and that is only the very first source that I checked. Ok, now, I'm bothered. Why didn't Jim or Harry immediately mention such known security with XML. Yes, they are likely not problems any longer, but then neither are the DNS/IP-spoofing/SMTP problems that I can name. I've never claimed to be an XML expert. When I ask questions about it, I do so in order to learn about stuff. Stuff that I think is important to know. Ok, for those who know more about XML than I do, can you give me an example of where XML has been put into as hostile an environment as anti-forgery/phishing SMTP? Where so many different platforms will need to be able to safely deal with XML documents from malicious users? -wayne From owner-ietf-mxcomp@mail.imc.org Tue Jun 15 14:51:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08276 for ; Tue, 15 Jun 2004 14:51:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5FITi8f088494; Tue, 15 Jun 2004 11:29:44 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5FITiMR088493; Tue, 15 Jun 2004 11:29:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5FITh1P088487 for ; Tue, 15 Jun 2004 11:29:43 -0700 (PDT) (envelope-from rand@sendmail.com) Received: from snoopy.smi.sendmail.com ([10.210.202.22]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.0) with ESMTP id i5FITk22013670 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 15 Jun 2004 11:29:46 -0700 Date: Tue, 15 Jun 2004 11:29:46 -0700 (PDT) From: Rand Wacker X-X-Sender: rand@snoopy.smi.sendmail.com To: ietf-mxcomp@imc.org cc: "Murray S. Kucherawy" , Eric Allman , Mark Delany , Miles Libbey Subject: Re: rough consensus and working code In-Reply-To: <20040615174822.4171.qmail@xuxa.iecc.com> Message-ID: References: <20040615174822.4171.qmail@xuxa.iecc.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 15 Jun 2004, John Levine wrote: > I know there's open source code for domain keys coming shortly. ^coming shortly^available for the past couple of weeks We (Sendmail) released an open source implementation of a DomainKeys milter just prior to the INBOX conference. It plugs into Sendmail through the milter protocol and can currently sign outgoing messages and verify and mark incoming messages. There's been quite a bit of feedback so far and Murray has kicked out numerous incremental releases since then. I'm sure someone will point out that there are questions about some of the Yahoo licensing terms but those are being worked through as we type. More info, code, and mailing lists can be found at: http://www.sendmail.net/dk-milter/ > What's available for SPF, Caller ID, and the merged thing? We had also been working on a Caller-ID milter (as there were already a few SPFv1 implementations out there), but haven't released it yet as to wait and see what happens with the spec merger. > We really do need working code. Publishing records is fine, but until > people start running a lot of mail through MARID authentication > checkers, we won't know whether it really scales or how easy it is for > bad guys to circumvent. This doesn't mean that you have to use it for > live spam filtering (you'd be nuts to bounce mail that failed SPF, for > example) but at least log it and count what you find. One of the other things we've been working on is a test plan to evaluate all of the major schemes against a number of different criteria. We've built a site to help coordinate community testing effort, and are still working on some of the technical details. I'm sure that this group has enough brainpower and probably some good tools to help in evaluating all of these solutions, we'd be happy to help in coordinating putting them to use. For more information on what we've done so far, please check out: http://sendmail.net/ -Rand From owner-ietf-mxcomp@mail.imc.org Tue Jun 15 15:08:49 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09531 for ; Tue, 15 Jun 2004 15:08:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5FIepu7090942; Tue, 15 Jun 2004 11:40:51 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5FIepnk090941; Tue, 15 Jun 2004 11:40:51 -0700 (PDT) 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.9) with ESMTP id i5FIeplM090920 for ; Tue, 15 Jun 2004 11:40:51 -0700 (PDT) (envelope-from hardie@qualcomm.com) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i5FIel3T012071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Jun 2004 11:40:48 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i5FIeio4023516; Tue, 15 Jun 2004 11:40:45 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: References: <2A7BA78A-BEF1-11D8-B76B-000A95B3BA44@hxr.us> Date: Tue, 15 Jun 2004 11:40:43 -0700 To: "IETF MARID WG" From: Ted Hardie Subject: Re: rough consensus and working code Cc: wayne Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >wayne wrote: >Personally, I think the IESG would be nuts not to require such testing >and that we would be nuts not to have all our ducks lined up in a row >before we go to the IESG asking for a PS RFC. The requirements for >going from a PS to a DS are much higher, in particular needing two >implemenations of every feature and I suspect that the IESG will not >require that level of testing. > As a different data point, note that the IESG did approve this working group with a very tight timeline, knowing that there would be trade-offs in that approval. I have also discussed a number of the issues raised in the group on the IESG's bi-weekly calls, so I hope there will be few surprises to the IESG in the work. Perhaps the best advice I can give you here is to worry about getting the engineering right rather than worrying about the IESG. The first tends to take care of the second, and the second rarely takes care of the first. regards, Ted Hardie From owner-ietf-mxcomp@mail.imc.org Tue Jun 15 15:11:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09809 for ; Tue, 15 Jun 2004 15:11:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5FIwmRp095207; Tue, 15 Jun 2004 11:58:48 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5FIwmv5095206; Tue, 15 Jun 2004 11:58:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from xuxa.iecc.com (xuxa.iecc.com [208.31.42.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5FIwkJV095184 for ; Tue, 15 Jun 2004 11:58:47 -0700 (PDT) (envelope-from johnl@iecc.com) Received: (qmail 28799 invoked by uid 100); 15 Jun 2004 18:58:50 -0000 Date: 15 Jun 2004 18:58:50 -0000 Message-ID: <20040615185850.28798.qmail@xuxa.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: Re: rough consensus and working code In-Reply-To: Organization: I.E.C.C., Trumansburg NY USA Cc: william@elan.net Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >Considering SPF community, I think once standards here are formalized >and these standards have community support (i.e. "consensus"), the >code will become available very soon. I sure hope the code precedes formalization, because I have little confidence that a paper design will stand up in practice. As many others have noted, e-mail and anti-spam is one of the most hostile computing enviroments around, and if there's any exploitable chinks in the armor, the bad guys will exploit them to the utmost. Re SPF, I know about the SPF publishing wizard, and I've seen a couple of libraries that decode SPF data, but how many people have actually plugged them into their MTAs to see what happens? Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY http://www.taugh.com From owner-ietf-mxcomp@mail.imc.org Tue Jun 15 15:52:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12722 for ; Tue, 15 Jun 2004 15:52:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5FJXp0L004094; Tue, 15 Jun 2004 12:33:51 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5FJXpr4004093; Tue, 15 Jun 2004 12:33:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5FJXoGf004066 for ; Tue, 15 Jun 2004 12:33:51 -0700 (PDT) (envelope-from matthew@elvey.com) Received: from server2.messagingengine.com (server2.internal [10.202.2.133]) by mail.messagingengine.com (Postfix) with ESMTP id C0F78C0723E; Tue, 15 Jun 2004 15:33:48 -0400 (EDT) Received: by server2.messagingengine.com (Postfix, from userid 99) id 9B7618450B; Tue, 15 Jun 2004 15:33:49 -0400 (EDT) Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.4 (F2.72; T1.001; A1.62; B3.01; Q3.01) Cc: "MXCOMP" References: <1665390638.20040614190711@brandenburg.com> <20040615031048.GP44160@verdi> <40CE9F08.2050002@elvey.com> <20040615115828.GQ44160@verdi> Subject: Re: CSV specification revision available In-Reply-To: <20040615115828.GQ44160@verdi> To: "John Leslie" Date: Tue, 15 Jun 2004 11:33:49 -0800 From: "Matthew Elvey" X-Sasl-Enc: CXmLGnlH97YEcfV/5iKPOA 1087328029 Message-Id: <1087328029.10303.198484820@webmail.messagingengine.com> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Glad to see the spec get refined a bit; perfection in an ID isn't expected; some refinement discussion snipped. This is how IETF specs are supposed to be developed - in open discussion. On Tue, 15 Jun 2004 07:58:28 -0400, "John Leslie" said: > Matthew Elvey wrote: >> ... > The host-name authentication function actually recommended is found > in the Client SMTP Authentication document, section 4 and following: > namely that the response to the SRV query should ordinarily list the > IP address(es) authorized to perform the MTA function; and that a match > of the actual IP address of the established SMTP connection to one of > these satisfies the authentication requirement. > > > "2.2 Forward DNS Lookup" > > is adequate to the task; there's no need for 2.1, AFAICT. > > I agree 2.1 should not be mentioned without a warning of its weakness. Sounds good. (IMO, it should be mentioned as supplemental, if at all, as KISS makes the spec easier to read, and that's critical.) > > > > Also, I don't see how 3.2 SMTP Auth protects aol.com from this same abuse. > > RE. 3.1 StartTLS: *IF* STARTTLS is used *AND* the sending server's cert > > is CA signed, then that makes sense. > > I'm not sure I understand your question here. Could you clarify? I'm saying two things. 1)Just as rDNS doesn't tie an IP to a domain for our purposes, perhaps neither does SMTP Auth. So it perhaps shouldn't be part of the spec, if the purpose is just to be a component of CSV. 2)Just as rDNS doesn't tie an IP to a domain for our purposes, STARTTLS might not either - i.e. STARTTLS should be used to validate the identity of the connection initiator, not the connection acceptor. Typically, STARTTLS validates the connection acceptor to the initiator. In other words, it typically (e.g. in https:// or for secure SMTP) is used to ensure that when you go to a site, you're communicating with who you think you're communicating with. It typically doesn't ensure that the site is communicating whith whom it thinks it's communicating with - the web surfer doesn't have an identity tied to a domain; the site (the connection acceptor) is tied to a domain via the CA. Hopefully that's more clear, not less clear. I guess if either these two methods are mentioned here but not relevant to CSV, that should be stated. > > > (Yes, I plan to rip out part of SPF and propose it as a replacement for > > draft-crocker-marid-csvhna-00.html and > > draft-crocker-marid-csvcsa-00.html in CSV, and create a chart comparing > > the pieces chosen and the reason for each choice, all if I find the time.) > > Sounds like a good execrcise. :) > > > draft-crocker-marid-csvcsa-00.html won't work with wildcards, right? > > CSA was designed to validate the EHLO string, which should never > involve wildcards, IMHO. Thus "working with wildcards" was never a > design goal. (Please note that the Domain Name Accreditation methods > _are_ designed to work with wildcards.) Oh, right. There's an MX wildcard on elvey.com. But I expect no server is going to send EHLO matthew.elvey.com. Or even EHLO elvey.com, unless I set up my own server. Thinking aloud about something: Well, I just noticed that my posts ARE often from a server that seems to be sending EHLO elvey.com, e.g. Received: from elvey.com (adsl-63-195-86-147.dsl.snfc21.pacbell.net [63.195.86.147]) by mail.messagingengine.com (Postfix) with ESMTP id D227ABDDD8D; Wed, 26 May 2004 22:17:21 -0400 (EDT) But this doesn't matter because this is me sending to a server that I've authenticated to with STARTTLS. It will not be doing CSV validation on email I send it; it trusts me. It's not the the hop that we're concerned with. My mail server doesn't do something silly like put elvey.com in the EHLO just because it's in the from for this hop: Received: from out2.smtp.messagingengine.com ([66.111.4.26]) by ietf-mx with esmtp (Exim 4.12) id 1BTAUD-0005Mh-00 for asrg@ietf.org; Wed, 26 May 2004 22:19:13 -0400 and I don't think others do either. From owner-ietf-mxcomp@mail.imc.org Tue Jun 15 17:54:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19607 for ; Tue, 15 Jun 2004 17:54:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5FLerWl031168; Tue, 15 Jun 2004 14:40:53 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5FLerLk031167; Tue, 15 Jun 2004 14:40:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from miz-mishtal.dbc.mtview.ca.us (adsl-64-168-10-250.dsl.scrm01.pacbell.net [64.168.10.250]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5FLerD9031154 for ; Tue, 15 Jun 2004 14:40:53 -0700 (PDT) (envelope-from mrose@dbc.mtview.ca.us) Received: from [IPv6:::1] (localhost [127.0.0.1]) by miz-mishtal.dbc.mtview.ca.us (8.12.10/8.12.9) with ESMTP id i5FLXrqt010011; Tue, 15 Jun 2004 14:33:54 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marshall Rose Subject: Re: XML exploits Date: Tue, 15 Jun 2004 14:33:54 -0700 To: "IETF MARID WG" X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit some might think it odd that i, as co-chair responsible for process, would respond to this email; however, a careful reading between the lines will inform the thoughtful reader as to why this reply is appropriate. On Jun 15, 2004, at 11:26, wayne wrote: > Ok, now, I'm bothered. Why didn't Jim or Harry immediately mention > such known security with XML. Yes, they are likely not problems any > longer, but then neither are the DNS/IP-spoofing/SMTP problems that I > can name. i wouldn't claim to be an XML expert, though i've been deploying xml-based code for five years this month. however, i know a few things about phrasing an argument. there are certain things which are unprovable, such as trying to prove a negative. i also know a few things about fear, uncertainty, and doubt, and how to use them in trying to advance a position. it isn't clear to me that the particular exploits you mention are xml-specific or specific to a particular implementation. i think that a carefully written implementation of an xml-parser is likely to be resilient to all kinds of malicious nonsense; similarly, i think that an implementation that isn't carefully written can have problems. i think i can s/xml/current spf syntax/g and get the same truth value for the statement above. certainly i can s/xml/ber/g and get the same truth value, although in that case it took about 8 years before exploits started showing up. the underlying assumption is that things have to be provably perfect in order to proceed. certainly spf isn't provably perfect. far, far from it. certainly caller-id isn't provably perfect. neither is xml. though each of the three exhibit a certain elegance in their own way. however, the assumption is flawed because while theorists may be interested in provably perfect systems, experienced practitioners are not. /mtr From owner-ietf-mxcomp@mail.imc.org Tue Jun 15 17:55:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19692 for ; Tue, 15 Jun 2004 17:55:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5FLY3Am029794; Tue, 15 Jun 2004 14:34:03 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5FLY3HJ029793; Tue, 15 Jun 2004 14:34:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from goose.ehsco.com (goose.ehsco.com [207.65.203.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5FLY2FR029784 for ; Tue, 15 Jun 2004 14:34:02 -0700 (PDT) (envelope-from ehall@ehsco.com) Received: from ehsco.com (ferret.corp.ntrg.com [207.65.71.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Eric A. Hall", Issuer "Network Technology Research Group Certificate Authority" (verified OK)) by goose.ehsco.com (Postfix ) with ESMTP id A2F605F9BE; Tue, 15 Jun 2004 16:34:05 -0500 (CDT) Message-ID: <40CF6AE0.1080002@ehsco.com> Date: Tue, 15 Jun 2004 16:32:16 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Levine Cc: ietf-mxcomp@imc.org Subject: Re: rough consensus and working code References: <20040615185850.28798.qmail@xuxa.iecc.com> In-Reply-To: <20040615185850.28798.qmail@xuxa.iecc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/15/2004 1:58 PM, John Levine wrote: > Re SPF, I know about the SPF publishing wizard, and I've seen a couple > of libraries that decode SPF data, but how many people have actually > plugged them into their MTAs to see what happens? I did for a while (not doing so today, but that's incidental with infrastructure issues). SPF is useful when [1] there is a record, and [2] the mail comes from a source that is clearly unauthorized for the associated domain. It is not particularly useful in any other combination. For example, you cannot *reliably* interpret the lack of a record as meaning anything, since many organizations (including some of my big customers) will send mail from an account in a division-specific domain, but will use a server in a parent or sibling domain for relay purposes. Meanwhile, the mere existence of a record and the use of an authorized server doesn't tell you much either, since spammers can create records that point to their servers too. So all in all, the subset of messages that meet the criteria are small, but this is primarily due to the relatively small number of domains that have records. I don't actually think that this will change much, since even while more domains may get records, spammers will either use other domains or will setup their own records. But the whole value proposition of SPF and similar efforts is that I can prevent *MY* domain from being used in various forgeries, so in that regard it is still useful. On the other hand, the cost of operating a server goes up somewhat due to the increased query load, the fact that synchronous blocking lowers the number of transfers per day that my machinery can handle, etc., while the benefits mostly flow to other people. SPF is worth publishing, but the value for checking is marginal and will probably stay that way. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-ietf-mxcomp@mail.imc.org Tue Jun 15 18:55:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23413 for ; Tue, 15 Jun 2004 18:55:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5FMWXlg041425; Tue, 15 Jun 2004 15:32:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5FMWXx9041424; Tue, 15 Jun 2004 15:32:33 -0700 (PDT) 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.9) with ESMTP id i5FMWWJL041417 for ; Tue, 15 Jun 2004 15:32:33 -0700 (PDT) (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 A5CF3132D05 for ; Tue, 15 Jun 2004 18:32:36 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 67FC9627; Tue, 15 Jun 2004 18:32:36 -0400 (EDT) Date: Tue, 15 Jun 2004 18:32:36 -0400 From: Meng Weng Wong To: IETF MARID WG Subject: Re: Alternative to TXT or new RR Message-ID: <20040615223236.GA13225@dumbo.pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Jun 14, 2004 at 10:52:38PM -0700, Matthew Elvey wrote: | | MARID is likely gonna use TXT; there's no alternative, the sky will not | fall, and the issues are not dealbreakers. You know, it's interesting to consider what we'd be doing now if TXT had never existed in the first place. The arguments for a new RRtype would be much more compelling, but we'd still look for workarounds that didn't need a new RRtype. I'm guessing an SRV lookup against DOMAIN.COM with a reserved port number would return a domain name, something like MARID-RECORD.DOMAIN.COM, and then something like http://marid-record.domain.com/marid-record.txt http://marid-record.domain.com/marid-record.xml Or maybe instead of an SRV lookup, we'd do an MX query against an underscore subdomain ... From owner-ietf-mxcomp@mail.imc.org Tue Jun 15 19:33:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26025 for ; Tue, 15 Jun 2004 19:33:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5FNCuRE052275; Tue, 15 Jun 2004 16:12:56 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5FNCupd052274; Tue, 15 Jun 2004 16:12:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from goose.ehsco.com (goose.ehsco.com [207.65.203.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5FNCtTR052268 for ; Tue, 15 Jun 2004 16:12:55 -0700 (PDT) (envelope-from ehall@ehsco.com) Received: from ehsco.com (ferret.corp.ntrg.com [207.65.71.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Eric A. Hall", Issuer "Network Technology Research Group Certificate Authority" (verified OK)) by goose.ehsco.com (Postfix ) with ESMTP id 68E885F9E9 for ; Tue, 15 Jun 2004 18:13:00 -0500 (CDT) Message-ID: <40CF820F.5020101@ehsco.com> Date: Tue, 15 Jun 2004 18:11:11 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-mxcomp@imc.org Subject: Re: rough consensus and working code References: <20040615185850.28798.qmail@xuxa.iecc.com> <40CF6AE0.1080002@ehsco.com> In-Reply-To: <40CF6AE0.1080002@ehsco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/15/2004 4:32 PM, Eric A. Hall wrote: > SPF is worth publishing, but the value for checking is marginal and > will probably stay that way. ps--if the value for checking is proportional to the cost (which it is), then the value goes down as: * record sizes require fallback processing * firewalls/bugs/etc break fallback processing * large numbers of large records make caching expensive/difficult * multiple RRs of the same type (but not the same meaning) require deeper analysis (= more processing, = more blocking) I know some folks have said that they will actively work against large RRs, but for me I'll just not implement the checker. Almost every mail that was ever trapped with SPF was also trapped via other analysis (such as spamassassin checks). Slightly improved heuristic trapping just isn't worth the extra expense, especially at large scales. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-ietf-mxcomp@mail.imc.org Tue Jun 15 20:40:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28024 for ; Tue, 15 Jun 2004 20:40:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5G0QC3u067542; Tue, 15 Jun 2004 17:26:12 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5G0QC5d067541; Tue, 15 Jun 2004 17:26:12 -0700 (PDT) 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.9) with ESMTP id i5G0QCZB067534 for ; Tue, 15 Jun 2004 17:26:12 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbfujip (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i5G0Pcl03648; Tue, 15 Jun 2004 17:26:04 -0700 Date: Wed, 16 Jun 2004 08:24:25 +0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <787690161.20040616082425@brandenburg.com> To: Tony Finch CC: ietf-mxcomp@imc.org Subject: Re: CSV specification revision available In-Reply-To: References: <1665390638.20040614190711@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: Content-Transfer-Encoding: 7bit Tony, First of all, MANY thanks for such a quick review! TF> The new documents are much clearer, however they are still vague on TF> important details, please note where i've asked for clarification about what you want to have different. if you did not list something in your note, please send details. TF> they take an awfully long time to get to the point, and TF> they contain an amazing amount of irrelevant digression. Given the amount of effort we put into fleshing out the text and working on clarity and completeness, it is not likely that any of its irrelevance or digressiveness will be obvious to us. So, again, your comments say exactly what you think needs to be changed, right? In any event, none of us expects these drafts to be in their final form. In fact there are aspects we have internal disagreements about, but decided it would better to pursue public discussion rather than wait longer to figure out a consensus among the 3 of us. I'm in transit, and do not yet know what my connectivity will be for the next 5 weeks. Therefore, John L. will be doing the heavy lifting of responding to comments, so I'll just touch on any of your comments that seem to go at core difficulties or issues. TF> Section 3.3 TF> The CSV spec makes a nice distinction between authentication and TF> authorization. So why is the CSV authorization step defined by a document TF> called "Client SMTP authentication"? (Actually this appears to be a typo TF> since the document calls itself "Client SMTP authorization".) Indeed, a typo. We, ourselves, have had a very, very tough time keeping the two functions clearly separate. The typo is residue. TF> I'm very dubious of the weaker DNS checking suggested in 2.1 and 2.2. I TF> think there should be much more discussion of the possible attacks and TF> defences, Perhaps. THere is a challenge to balance between specification and pedagogy. At the least, we felt is likely to be sufficient to make clear that we do not see it as a useful technique for any type of really serious authentication. TF> and why they are under consideration when full foward + reverse TF> checking is available. reverse is often not available, as we noted. so the question is whether forward, by itself, is useful. Our conclusion is that for this very constrained use, it is. It won't surprise anyone that we won't be surprised if the community concludes otherwise TF> 3.2 SMTP Auth TF> As I understand it this draft is intended to be independent of SMTP. TF> Therefore SASL should be cited instead. Well, we do have a bit of a challenge, given that the actual use of the document is part of an smtp-based service. TF> In addition to this, SASL is generally used for user authentication not TF> hostname authentication. This section needs to be more explicit about how TF> this unusual use works in practice. interesting point. TF> 4 Independent Policy Services TF> "In effect, the question about domain name use is a question about the TF> reputation and accountability of the domain name administrator." TF> No, it is a question about the reliability of the host. This entire TF> section refers to a part of the CSV process covered by the DNS draft. reliability is often part of the input to an accreditation process. TF> draft-ietf-marid-dsvcsa-00 TF> Sections 4 & 5 TF> These sections overlap rather a lot. They also omit to specify what the TF> server should do if the client's CSA records has invalid data. What do you mean by "invalid" data? How is invalidity assessed? TF> The protocol specified in this draft appears to be (I'm reading between TF> the lines here) that the EHLO domain name stated by the SMTP client is TF> used to look up a SRV record. This record states in the weight field if TF> that name may be used by an SMTP client, and it also contains a target TF> name. The DNS reply should contain additional data, being the IP address TF> records associated with this target name. One of these must match the TF> client IP address from the SMTP connection in order for the EHLO domain TF> name to be considered valid. Or maybe (according to HNA) the IP addresses TF> associated with the EHLO domain itself must match the connection IP TF> address. Or maybe the reverse DNS must agree too. This is not clear. It's TF> also not clear how this relates to the RFC 2821 nix on EHLO checks. wow. what a really excellent summary! wish we had written it, and thoroughly appreciate that you did. it will be a nice addition to the doc. TF> draft-crocker-marid-csvdna-00 TF> There's no discussion of the obvious attack of a client recommending TF> accreditation services that all say the client is wonderful. that's not an attack. i would fully expect a client to cite only those with positive assessments. the question is what the receiving smtp server thinks of those accreditation services. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Tue Jun 15 20:41:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28069 for ; Tue, 15 Jun 2004 20:41:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5G0M6aX066750; Tue, 15 Jun 2004 17:22:06 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5G0M6o9066749; Tue, 15 Jun 2004 17:22:06 -0700 (PDT) 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.9) with ESMTP id i5G0M5OT066743 for ; Tue, 15 Jun 2004 17:22:05 -0700 (PDT) (envelope-from dcrocker@brandenburg.com) Received: from bbfujip (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i5G0Lol03420; Tue, 15 Jun 2004 17:21:53 -0700 Date: Wed, 16 Jun 2004 08:21:38 +0800 From: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <956329992.20040616082138@brandenburg.com> To: Tony Finch CC: ietf-mxcomp@imc.org Subject: Re: CSV specification revision available In-Reply-To: References: <1665390638.20040614190711@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: Content-Transfer-Encoding: 7bit Tony, First of all, MANY thanks for such a quick review! TF> The new documents are much clearer, however they are still vague on TF> important details, please note where i've asked for clarification about what you want to have different. if you did not list something in your note, please send details. TF> they take an awfully long time to get to the point, and TF> they contain an amazing amount of irrelevant digression. Given the amount of effort we put into fleshing out the text and working on clarity and completeness, it is not likely that any of its irrelevance or digressiveness will be obvious to us. So, again, your comments say exactly what you think needs to be changed, right? In any event, none of us expects these drafts to be in their final form. In fact there are aspects we have internal disagreements about, but decided it would better to pursue public discussion rather than wait longer to figure out a consensus among the 3 of us. I'm in transit, and do not yet know what my connectivity will be for the next 5 weeks. Therefore, John L. will be doing the heavy lifting of responding to comments, so I'll just touch on any of your comments that seem to go at core difficulties or issues. TF> Section 3.3 TF> The CSV spec makes a nice distinction between authentication and TF> authorization. So why is the CSV authorization step defined by a document TF> called "Client SMTP authentication"? (Actually this appears to be a typo TF> since the document calls itself "Client SMTP authorization".) Indeed, a typo. We, ourselves, have had a very, very tough time keeping the two functions clearly separate. The typo is residue. TF> I'm very dubious of the weaker DNS checking suggested in 2.1 and 2.2. I TF> think there should be much more discussion of the possible attacks and TF> defences, Perhaps. THere is a challenge to balance between specification and pedagogy. At the least, we felt is likely to be sufficient to make clear that we do not see it as a useful technique for any type of really serious authentication. TF> and why they are under consideration when full foward + reverse TF> checking is available. reverse is often not available, as we noted. so the question is whether forward, by itself, is useful. Our conclusion is that for this very constrained use, it is. It won't surprise anyone that we won't be surprised if the community concludes otherwise TF> 3.2 SMTP Auth TF> As I understand it this draft is intended to be independent of SMTP. TF> Therefore SASL should be cited instead. Well, we do have a bit of a challenge, given that the actual use of the document is part of an smtp-based service. TF> In addition to this, SASL is generally used for user authentication not TF> hostname authentication. This section needs to be more explicit about how TF> this unusual use works in practice. interesting point. TF> 4 Independent Policy Services TF> "In effect, the question about domain name use is a question about the TF> reputation and accountability of the domain name administrator." TF> No, it is a question about the reliability of the host. This entire TF> section refers to a part of the CSV process covered by the DNS draft. reliability is often part of the input to an accreditation process. TF> draft-ietf-marid-dsvcsa-00 TF> Sections 4 & 5 TF> These sections overlap rather a lot. They also omit to specify what the TF> server should do if the client's CSA records has invalid data. What do you mean by "invalid" data? How is invalidity assessed? TF> The protocol specified in this draft appears to be (I'm reading between TF> the lines here) that the EHLO domain name stated by the SMTP client is TF> used to look up a SRV record. This record states in the weight field if TF> that name may be used by an SMTP client, and it also contains a target TF> name. The DNS reply should contain additional data, being the IP address TF> records associated with this target name. One of these must match the TF> client IP address from the SMTP connection in order for the EHLO domain TF> name to be considered valid. Or maybe (according to HNA) the IP addresses TF> associated with the EHLO domain itself must match the connection IP TF> address. Or maybe the reverse DNS must agree too. This is not clear. It's TF> also not clear how this relates to the RFC 2821 nix on EHLO checks. wow. what a really excellent summary! wish we had written it, and thoroughly appreciate that you did. it will be a nice addition to the doc. TF> draft-crocker-marid-csvdna-00 TF> There's no discussion of the obvious attack of a client recommending TF> accreditation services that all say the client is wonderful. that's not an attack. i would fully expect a client to cite only those with positive assessments. the question is what the receiving smtp server thinks of those accreditation services. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 01:19:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25189 for ; Wed, 16 Jun 2004 01:19:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5G58TBB028892; Tue, 15 Jun 2004 22:08:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5G58TgC028891; Tue, 15 Jun 2004 22:08:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5G58SmI028824 for ; Tue, 15 Jun 2004 22:08:28 -0700 (PDT) (envelope-from michel@arneill-py.sacramento.ca.us) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: OT: do-not-spam list X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 15 Jun 2004 22:08:28 -0700 Message-ID: Thread-Topic: OT: do-not-spam list Thread-Index: AcRTOOtgogUYvOnwTSmvLKkvrqdCdwAJvQ6g From: "Michel Py" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5G58SmI028884 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit http://www.cnn.com/2004/TECH/internet/06/15/internet.spam.ap/index.html From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 01:24:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25876 for ; Wed, 16 Jun 2004 01:24:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5G5E5pl031809; Tue, 15 Jun 2004 22:14:05 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5G5E5lk031807; Tue, 15 Jun 2004 22:14:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [64.139.47.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5G5E45I031777 for ; Tue, 15 Jun 2004 22:14:05 -0700 (PDT) (envelope-from gconnor@nekodojo.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by neko-base.nekodojo.org (Postfix) with ESMTP id 7E8891D651 for ; Tue, 15 Jun 2004 22:14:09 -0700 (PDT) Date: Tue, 15 Jun 2004 22:14:11 -0700 From: Greg Connor To: ietf-mxcomp@imc.org Subject: Working toward unity on XML Message-ID: <11604246.1087337651@[10.12.1.26]> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I made the following comment during the jabber session yesterday, when it seemed we were moving further and further away from an agreement on XML: > gconnor: I think the XML issue is a very small part of the important work > we are doing within MARID. It's an implementation detail. We have made a > lot of progress in terms of coming together on identities and features. > let's not forget that. I know the XML issue pushes a lot of people's hot > buttons. I don't want this issue, which I consider "not really central to > the problem we are trying to solve" to tear the group apart I don't have a strong vested interest in whether MARID get implemented in XML, plain SPF, or Java or Tcl for that matter. I have some opinions, but I am not going to let my opinion stand in the way of the larger goal - MARID success and a proposed standard. Here is my attempt to review some of the positions on the issue. I agree with Marshall that there really needs to be some compromise between the two extremes or we are not going to be successful. Therefore, please read this message through to the end before replying. Position 1. In favor of XML: XML is extensible. We can add new syntax later without breaking things. Our MARID data should be part of a larger picture of "email policy". There are standard tools out there to parse XML that we can re-use. We are going to look silly and be irrelevant in 5 years if we don't allow extensions. Position 2. Opposed to XML: XML records are too big for what we want. Rampant extensibility might lead to inconsistent results later. An XML parser would be too big for my MTA or other mail-analyzing program. Keep It Simple. Testing an XML parser would be onerous compared to other testing needed. Mistrust of Microsoft and their motives for wanting XML If we implement something too big or complex, we will look silly and be irrelevant in 5 years. Position 3. Implement both, let domain owners decide: Plain SPF and XML MUST be supported by all implementations. Domain owners are free to publish in either format. People can vote with their feet. If there is no extension really needed, plain text will probably be preferred because it is more readable. If there is some extension that people end up needing, the XML may be preferred in the future. If there is a clear winner in terms of market adoption, perhaps a later version of our standard will deprecate one or the other. Position 4. Leave it up to the MTA: Plain SPF MUST be supported. XML SHOULD be supported. Those implementing MTA and mail filters can start with SPF as it is written today, and are encouraged to support XML also, but reading and acting on only the Plain SPF format is also allowed. Software vendors that don't support XML do so at their own risk. Users who feel they need XML support may complain. The software not supporting XML may get negative reviews later, or have a checkmark missing on the feature grid. Patches later might be needed. Software that understand SPF now will be pretty much ready-to-go as is. Domain owners may choose XML but might be faced with less support among receivers. Assuming the XML may be extended and the plain format might not be, when both are present, the XML should be used, falling back to SPF plain only if the MTA doesn't support XML. Allows people to vote with their feet, sort of. Software vendors have some freedom to choose, but are ultimately accountable to the customers. More thoughts on extensibility: There are two kinds of extensibility, and there is some disagreement as to which we want, if any. "Feature" or "semantic" extensibility adds new mechanisms later, and may change the output of the checking function, or even add new inputs to the function. This can be supported, if done carefully. Either an intelligent default, or an "alt=" type of statement attached to the extended feature, would be needed in order for the software of today to "navigate around" the data points we throw at it tomorrow. There is some support for this kind of extensibility, but there are also others who feel strongly that we should NOT be able to add new features on the fly, as this would lead to inconsistent behavior among some implementations and that's not good. Regarding feature extensibility, my guess is there are probably a lot of people who like it, but their support is lukewarm and they aren't passionate about it enough to defend it. At the same time, there are probably some people who feel strongly enough to come out swinging against such flexibility, fearing that the new extensions won't add enough value to offset the potential harm in flaky software not doing extensibility right or not being consistent with each other. We also have "syntax" extensibility, which allows us to thrown in new data later, but only as "extra" or "not core" data. The new data might give extra info (like publish a domain's desire to receive problem reports) or it might be something not relevant to MARID at all (like whether a domain uses domainkeys, or where to find accreditation, or something like that). Just syntax extensions, with no feature extensions, are easy to add (to any language, not just XML) as long as the rules are clear from the start. For example, no "extra" data will ever result in a change to the accept/deny/unknown function. An MTA can either ignore it totally, or complain that it's a possible typo, depending on where the data appears. (For example, an "ep" might have nodes other than "out" and "out" might have nodes other than "m", but nodes within "m" should be of a recognized type or the implementation should interpret this as a typo and throw an error) More about size: XML is going to be a bit bigger than plain SPF or other plain-token language. Frankly, I don't see size to be a big issue... it is a concern, but not enough of a concern for me to exert a veto or leave the party early. We will have an include-type mechanism for stitching together records. DNS *does* actually have a mechanism for fetching larger records, even though it may be blocked by some firewalls... I think it's the responsibility of the domain owner to make sure that the record fits in a response packet, and test this, and those who choose to publish larger records should do so at their own risk. Wrap up, and where to go from here: I would prefer not to see replies to this post where people tear it up and match one or two sentences of mine with some quick comeback of theirs. That's a great style for arguing, but I think the time for arguing is past. Most people who care about the issue have made most of the intelligent arguments they are going to make. What I would really prefer to see is a few paragraphs that say: 1. What position you support 2. What other fallback or compromise positions you can live with, and 3. How strongly you feel about one or the other. If you respond supporting one extreme, and don't state a compromise position that you can live with (either 3 or 4 or something else I haven't spelled out), then you might want to add a footnote saying why you believe this issue is enough of a dealbreaker that you are not willing to compromise, and why you are willing to let MARID fail rather than give in on the issue. This is where the rubber really meets the road, and the hard work of the working group starts. Failure to reach any agreement is a *guaranteed* way to look silly and be irrelevant in 5 years :) Let's all try to work together and rise to the challenge. We can do this. Thanks for your time. gregc -- Greg Connor From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 02:26:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27555 for ; Wed, 16 Jun 2004 02:26:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5G6EgJG073418; Tue, 15 Jun 2004 23:14:42 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5G6Egh0073417; Tue, 15 Jun 2004 23:14:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from goose.ehsco.com (goose.ehsco.com [207.65.203.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5G6EfiD073368 for ; Tue, 15 Jun 2004 23:14:41 -0700 (PDT) (envelope-from ehall@ehsco.com) Received: from ehsco.com (ferret.corp.ntrg.com [207.65.71.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Eric A. Hall", Issuer "Network Technology Research Group Certificate Authority" (verified OK)) by goose.ehsco.com (Postfix ) with ESMTP id 665143AB6A for ; Wed, 16 Jun 2004 01:14:46 -0500 (CDT) Message-ID: <40CFE4E6.3010208@ehsco.com> Date: Wed, 16 Jun 2004 01:12:54 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-mxcomp@imc.org Subject: Re: Working toward unity on XML References: <11604246.1087337651@[10.12.1.26]> In-Reply-To: <11604246.1087337651@[10.12.1.26]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/16/2004 12:14 AM, Greg Connor wrote: > XML is extensible. We can add new syntax later without breaking things. DNS dictates the use of small messages containing public data. No amount of pleading or stubbornness changes that. Meanwhile, if the underlying goal behind the use of XML is infinite extensibility, DNS is a poor choice. Per-user policy statements require user-keyed lookups (email address instead of domain), future extensions are likely to require authenticated access, and so forth. Most of all, the service needs to be able to serve this data reliably and efficiently, which DNS is unable to satisfy considering its optimizations. In short, neither DNS nor the goal of extensibility are ultimately satisfied by trying to force them to work together. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 02:43:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10236 for ; Wed, 16 Jun 2004 02:43:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5G6YpV8085403; Tue, 15 Jun 2004 23:34:51 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5G6YpCl085402; Tue, 15 Jun 2004 23:34:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5G6Yo0P085393 for ; Tue, 15 Jun 2004 23:34:51 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from [192.168.2.24] (adsl-64-142-13-68.sonic.net [64.142.13.68]) by b.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i5G6Yn99010073; Tue, 15 Jun 2004 23:34:49 -0700 Subject: Re: OT: do-not-spam list From: Douglas Otis To: Michel Py Cc: ietf-mxcomp@imc.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1087367689.2912.8.camel@bash.adsl-64-142-13-68.sonic.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 15 Jun 2004 23:34:49 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 2004-06-15 at 22:08, Michel Py wrote: > http://www.cnn.com/2004/TECH/internet/06/15/internet.spam.ap/index.html Read their privacy notice. http://www.cnn.com/privacy.html From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 02:48:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11178 for ; Wed, 16 Jun 2004 02:48:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5G6dpVd088776; Tue, 15 Jun 2004 23:39:51 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5G6dpAg088775; Tue, 15 Jun 2004 23:39:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5G6doTW088709 for ; Tue, 15 Jun 2004 23:39:50 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 15 Jun 2004 23:39:44 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 15 Jun 2004 23:39:44 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 15 Jun 2004 23:39:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Working toward unity on XML Date: Tue, 15 Jun 2004 23:39:39 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF42A0D6@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: Working toward unity on XML Thread-Index: AcRTYYdcikxgi868RPyWMPcIH4uXbgACQEdg From: "Jim Lyon" To: "Greg Connor" , X-OriginalArrivalTime: 16 Jun 2004 06:39:44.0521 (UTC) FILETIME=[B5D1B790:01C4536C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5G6doTW088768 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I think that Greg has done an excellent write-up of the positions. Position 1 was originally taken by Microsoft Caller ID. Position 2 was originally taken by SPF. I see position 3 as the best of both worlds, and heartily support it. I see position 4 as the worst of both worlds. I believe that "syntax" extensibility will be crucial in the future. I believe that "feature" extensibility has a positive but small value, but probably isn't worth the cost. Just to be clear, the current compromise draft takes position 3 (parsers support both SPF and XML, domain owners publish one or the other). It also enables "syntax" extensibility. While it doesn't go out of its way to support "feature" extensibility -- there's no ALT mechanism, for example -- it doesn't completely rule it out, either. -- jimbo From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 03:44:39 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22358 for ; Wed, 16 Jun 2004 03:44:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5G7WorX018744; Wed, 16 Jun 2004 00:32:50 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5G7WoI6018743; Wed, 16 Jun 2004 00:32:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5G7WoDX018717 for ; Wed, 16 Jun 2004 00:32:50 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from [192.168.2.24] (adsl-64-142-13-68.sonic.net [64.142.13.68]) by a.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i5G7Wmio027230; Wed, 16 Jun 2004 00:32:48 -0700 Subject: Re: Working toward unity on XML From: Douglas Otis To: Greg Connor Cc: ietf-mxcomp@imc.org In-Reply-To: <11604246.1087337651@[10.12.1.26]> References: <11604246.1087337651@[10.12.1.26]> Content-Type: text/plain Message-Id: <1087371168.2912.68.camel@bash.adsl-64-142-13-68.sonic.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 16 Jun 2004 00:32:48 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 2004-06-15 at 22:14, Greg Connor wrote: > What I would really prefer to see is a few paragraphs that say: > 1. What position you support No parser is better. Virtually all DNS data is returned structured in a binary format to keep information concise and small. This would require either existing records other than TXT or a new record. Attempting to add into a single TXT record seems an outcome of seeing text as synonymous with a polymorphic web page; a dangerous design practice for DNS. Excessive combining and dereferencing could be fatal for both DNS and MAIL. > 2. What other fallback or compromise positions you can live with, and CSV-HNA-CSA~DNA : ) > 3. How strongly you feel about one or the other. Neither are great. Keeping XML controlled is not allowed it would seem, but even SPF should be limited with more restrictions. Can an assurance be established? Will benefits outweigh risk? Would a hexidecimal encoding of a structured array be more concise? -Doug From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 08:41:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23703 for ; Wed, 16 Jun 2004 08:41:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GCUadA041118; Wed, 16 Jun 2004 05:30:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GCUauF041117; Wed, 16 Jun 2004 05:30:36 -0700 (PDT) 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.9) with ESMTP id i5GCUZmU041108 for ; Wed, 16 Jun 2004 05:30:35 -0700 (PDT) (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.34) id 1BaZYY-0004he-0p for ietf-mxcomp@imc.org; Wed, 16 Jun 2004 07:30:37 -0500 To: "IETF MARID WG" References: From: wayne Reply-To: "IETF MARID WG" Date: Wed, 16 Jun 2004 07:30:17 -0500 In-Reply-To: (Marshall Rose's message of "Tue, 15 Jun 2004 14:33:54 -0700") 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 (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: XML exploits Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-4.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In Marshall Rose writes: > some might think it odd that i, as co-chair responsible for process, > would respond to this email; however, a careful reading between the > lines will inform the thoughtful reader as to why this reply is > appropriate. Marshall, when I first read your reply, I thought you might be agreeing with me since I agreed with almost everything you said. However, I think you have actually read stuff into my message that just isn't there. > On Jun 15, 2004, at 11:26, wayne wrote: > >> Ok, now, I'm bothered. Why didn't Jim or Harry immediately mention >> such known security with XML. Yes, they are likely not problems any >> longer, but then neither are the DNS/IP-spoofing/SMTP problems that I >> can name. > > however, i know a few things about phrasing an argument. there are > certain things which are unprovable, such as trying to prove a > negative. i also know a few things about fear, uncertainty, and doubt, > and how to use them in trying to advance a position. Correct. And the failure of people who are not XML experts to answer a question without research is not proof that a problem doesn't exist. > it isn't clear to me that the particular exploits you mention are > xml-specific or specific to a particular implementation. Completely irrelevant. What is important is whether there are enough exploits for mail admins to object to having XML on their servers. > i think that a carefully written implementation of an xml-parser is > likely to be resilient to all kinds of malicious nonsense; similarly, > i think that an implementation that isn't carefully written can have > problems. > > i think i can > > s/xml/current spf syntax/g > > and get the same truth value for the statement above. certainly i can Yes, but remember that the current XML syntax requires a *complete* SPF syntax parser in addition to an XML parser. > the underlying assumption is that things have to be provably perfect > in order to proceed. certainly spf isn't provably perfect. far, far > from it. certainly caller-id isn't provably perfect. neither is > xml. though each of the three exhibit a certain elegance in their own > way. I never said that I wanted something that is provably perfect and I never implied it. We are trying to engineer a solution here. We aren't supposed to be some debating club where if you don't have a rebuttal card prepared the other side scores a point. We aren't even supposed to have sides here. What I expect in order to make engineering decisions, and what Jim Lyon didn't provide, is the provide the security background required by RFC3552. Since Jim is an RFC author, Jim is already supposed to have done this research and disclosed all known security issues. When I answer a question raised by your co-chair that went unanswered, I don't think the dismissive attitude toward XML security issues that both Jim and you have displayed is appropriate. -wayne From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 09:02:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23924 for ; Wed, 16 Jun 2004 09:02:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GCmjMF046638; Wed, 16 Jun 2004 05:48:45 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GCmj7J046637; Wed, 16 Jun 2004 05:48:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from hoster907.com (ns1.hoster907.com [66.211.137.27]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5GCmi50046619 for ; Wed, 16 Jun 2004 05:48:44 -0700 (PDT) (envelope-from margaret@margaretolson.com) Received: (qmail 21048 invoked from network); 16 Jun 2004 12:49:49 -0000 X-Relay-Users: margaret.user X-Abuse: Send abuse reports to: abuse@suresupport.com Received: from unknown (HELO ?192.168.254.212?) (208.198.98.2) by ns1.hoster907.com with SMTP; 16 Jun 2004 12:49:49 -0000 In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF42A0D6@df-fido-msg.exchange.corp.microsoft.com> References: <81AC085044D04B429F5FB883D94FA1AF42A0D6@df-fido-msg.exchange.corp.microsoft.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7E241D17-BF93-11D8-999B-000A95BC6A7E@margaretolson.com> Content-Transfer-Encoding: 7bit Cc: , "Greg Connor" From: Margaret Olson Subject: Re: Working toward unity on XML Date: Wed, 16 Jun 2004 08:48:40 -0400 To: "Jim Lyon" X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I On Jun 16, 2004, at 2:39 AM, Jim Lyon wrote: > > I think that Greg has done an excellent write-up of the positions. > > Position 1 was originally taken by Microsoft Caller ID. > Position 2 was originally taken by SPF. > I see position 3 as the best of both worlds, and heartily support it. > I see position 4 as the worst of both worlds. > I believe that "syntax" extensibility will be crucial in the future. > I believe that "feature" extensibility has a positive but small value, > but probably isn't worth the cost. I see authenticating a domain as fairly well understood at this point, but the necessary additional services are just beginning to emerge. You need to tie the reputation and accreditation to the authentication, and we may find that it's crucial to do so in the MARID record. Reputation and accreditation are new and poorly understood areas, so I would not credit anyone's crystal ball on what will be required. Given that, I think syntax extensibility is critical and that the possibility of feature extensibility is also critical, with the caveat that the feature extensibility must be backwards compatible, an exercise that by definition has to be left to the designers of the new feature. With syntax extensibility you can in theory get some backwards compatible semantic extensibility. So like Jim, I heartily support position 3, which I would define as backwards compatibility for the existing SPF syntax. I'll observe that SenderID has a feature extension (SUBMITTER, the PRD algorithm) over SPF. Many thanks to Greg for taking the time to write up the positions. Margaret. (I have not read the current draft closely enough to understand how publishing domains express their wish to be treated as SPF v1 or SenderID so I have held off on commenting on how well I think that will work.) From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 09:04:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23960 for ; Wed, 16 Jun 2004 09:04:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5G8MkNw048038; Wed, 16 Jun 2004 01:22:46 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5G8MkB5048031; Wed, 16 Jun 2004 01:22:46 -0700 (PDT) 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.9) with ESMTP id i5G8MjIh047992 for ; Wed, 16 Jun 2004 01:22:46 -0700 (PDT) (envelope-from cm--jrk@merseymail.com) Received: from mmail by argon.connect.org.uk with local (connectmail/exim) id 1BaVgx-0006bs-Hd for ietf-mxcomp@imc.org; Wed, 16 Jun 2004 09:22:43 +0100 In-Reply-To: <40CF820F.5020101@ehsco.com> Subject: Re: rough consensus and working code To: ietf-mxcomp@imc.org From: "Jon Kyme" X-Mailer: [ConnectMail 3.15.6] X-connectmail-Originating-IP: 172.25.243.3 Message-Id: Date: Wed, 16 Jun 2004 09:22:43 +0100 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > > > On 6/15/2004 4:32 PM, Eric A. Hall wrote: > > > SPF is worth publishing, but the value for checking is marginal and > > will probably stay that way. > I think this has been said about a million times before, but surely SPF (etc) is, as things stand, only worth publishing if a sufficient proportion of sites check it? If, as you suggest, the benefit in checking is low, the benefit in publishing will remain small. There are a few things that could change this relationship without the proportion of checking sites suddenly going up. 1. Spammers move away from forged senders. Benefit in publishing falls 2. Receivers more strongly weight their local policy against non-publishers Benefit of publishing increases 3. Publishers tighten their published policy i.e. for SPF move to -all (or as we call it in our office "f**k-all") Benefit of checking increases, which *may* increase the benefit of publishing. I believe we'll see some of these processes in action over the next few months. But given that we know precisely nothing about the relative strength of the effects, it's simply not possible to say what the outcome will be. Hence much SPF (and MARID) evangelism must be faith-based. Now that's not bad in itself, but it shouldn't be confused with engineering. Of course one thing that could really change the interactions here would be some regulatory change affecting a large proportion of hosts of the MTS :-) From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 09:08:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24100 for ; Wed, 16 Jun 2004 09:08:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GCuhBk048945; Wed, 16 Jun 2004 05:56:43 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GCuh18048944; Wed, 16 Jun 2004 05:56:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from hoster907.com (ns1.hoster907.com [66.211.137.27]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5GCugrF048934 for ; Wed, 16 Jun 2004 05:56:42 -0700 (PDT) (envelope-from margaret@margaretolson.com) Received: (qmail 23000 invoked from network); 16 Jun 2004 12:57:50 -0000 X-Relay-Users: margaret.user X-Abuse: Send abuse reports to: abuse@suresupport.com Received: from unknown (HELO ?192.168.254.212?) (208.198.98.2) by ns1.hoster907.com with SMTP; 16 Jun 2004 12:57:50 -0000 Mime-Version: 1.0 (Apple Message framework v618) In-Reply-To: References: <11604246.1087337651@[10.12.1.26]> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9CC16D8E-BF94-11D8-999B-000A95BC6A7E@margaretolson.com> Content-Transfer-Encoding: 7bit From: Margaret Olson Subject: Re: Working toward unity on XML Date: Wed, 16 Jun 2004 08:56:41 -0400 To: "IETF MARID WG" X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > >> Position 1. In favor of XML: > > Caller-ID (XML) has not had a huge publication rate. This *may* be a > case of domain owners vetoing XML, but there are many other > possibilities. > I do not think this has anything to do with XML vs SPF syntax; I think it's a reflection of the level and kind of information you have to gather in order to publish. As I have mentioned elsewhere, for most domains publishing to catch all P.R.D. is much different exercise than publishing the valid MAIL-FROM ip addresses. It's also much more valuable information for the receiver, and required for tracking reputation and accreditation by authoring domain rather than by channel. Margaret. From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 09:42:44 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25160 for ; Wed, 16 Jun 2004 09:42:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GAZUcP009137; Wed, 16 Jun 2004 03:35:30 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GAZUAf009126; Wed, 16 Jun 2004 03:35:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GAYx4T008980 for ; Wed, 16 Jun 2004 03:35:29 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id 254371A6FF; Wed, 16 Jun 2004 12:34:57 +0200 (CEST) Received: from prosecco.oryx.com (unknown [217.19.171.140]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by bra.gulbrandsen.priv.no (Postfix) with ESMTP id 4FDD31A6F6 for ; Wed, 16 Jun 2004 12:34:55 +0200 (CEST) Message-Id: <1Fz8AGrZ9eBGLNyWqdk4Mg.md5@prosecco.oryx.com> From: Arnt Gulbrandsen To: IETF MARID WG Subject: Re: Alternative to TXT or new RR References: <20040615223236.GA13225@dumbo.pobox.com> In-Reply-To: <20040615223236.GA13225@dumbo.pobox.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Wed, 16 Jun 2004 12:36:21 +0200 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Meng Weng Wong writes, about "what if there were no TXT": > I'm guessing an SRV lookup against DOMAIN.COM with a > reserved port number would return a domain name, something like > MARID-RECORD.DOMAIN.COM, and then something like I'm pretty sure we'd be doing a SRV lookup for _marid._udp. and then asking that server whether to fail/pass/... the message. The entire SPF/CID/XML thing would never be published - the policy would be executed by the same entity that chose the policy. Only the IP address, email address and pass/fail/... result would cross the net. Arnt From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 09:43:12 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25335 for ; Wed, 16 Jun 2004 09:43:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GACeQt003418; Wed, 16 Jun 2004 03:12:40 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GACe8E003417; Wed, 16 Jun 2004 03:12:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from orange.csi.cam.ac.uk (exim@orange.csi.cam.ac.uk [131.111.8.77]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GACciJ003403 for ; Wed, 16 Jun 2004 03:12:39 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from fanf2 (helo=localhost) by orange.csi.cam.ac.uk with local-esmtp (Exim 4.12) id 1BaXPK-0005HL-00; Wed, 16 Jun 2004 11:12:38 +0100 Date: Wed, 16 Jun 2004 11:12:38 +0100 From: Tony Finch X-X-Sender: fanf2@orange.csi.cam.ac.uk To: Dave Crocker cc: ietf-mxcomp@imc.org Subject: Re: CSV specification revision available In-Reply-To: <956329992.20040616082138@brandenburg.com> Message-ID: References: <1665390638.20040614190711@brandenburg.com> <956329992.20040616082138@brandenburg.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 16 Jun 2004, Dave Crocker wrote: > > Given the amount of effort we put into fleshing out the text and > working on clarity and completeness, it is not likely that any of its > irrelevance or digressiveness will be obvious to us. So, again, your > comments say exactly what you think needs to be changed, right? Yes, I think the high-level structure of the specification is up to you; I was reviewing it mainly from the point of view of trying to understand how to implement it. If I were going to make suggestions about how to structure the spec, I'd throw away HNA and the CSV overview. I'd improve the CSA spec with a more precise explanation of the authentication process (in a separate section). If you want to keep HNA in something like its current form, then I suggest that it should describe each authentication method with reference to a subject domain that is to be authenticated and what other protocol information it is compared with. e.g. the forward DNS method is to look up the A or AAAA records for the subject domain and ensure that one of the addresses is the same as the client IP address from the TCP connection. The TLS method is to require a client certificate with a common name that corresponds to the subject domain. Actually that doesn't work very well because CSA's input into the forward DNS process is the CSA SRV target domain, not the EHLO domain. In the TLS case perhaps the subject domain is the output of the process rather than an input. The problem with a strict separation between authentication and authorization in the presentation of CSV is that the protocol does not separate them as described. In fact if my understanding of the protocol is correct (see below) then the description in the CSV draft that authorization follows authentication is wrong. The process is interleaved: look up the authorization record; look up the authentication record; check authentication; check authorization. The DNA spec is not really tied to CSV in the way your document structure suggests -- it's useful as the next step after any domain authentication system (SPF, CID, DK, etc.). > Our conclusion is that for this very constrained use, [forward-only > checking is sufficient]. It won't surprise anyone that we won't be > surprised if the community concludes otherwise I didn't work out that that was what your protocol requires until after reading both HNA and CSA. I think most of the discussion in HNA is relevant only in a rationale document, not a spec. (There are no useful SHOULDs or MUSTs in it!) However the spec should probably explain why a full forward-and-reverse DNS consistency check isn't necessary. > TF> HNA section 4 Independent Policy Services > > reliability is often part of the input to an accreditation process. > TF> draft-ietf-marid-dsvcsa-00 > TF> Sections 4 & 5 > TF> These sections overlap rather a lot. They also omit to specify what the > TF> server should do if the client's CSA records has invalid data. > > What do you mean by "invalid" data? How is invalidity assessed? Outside the spec. E.g. a non-zero port, or a weight that isn't 0, 1, or 3, or a priority that isn't 1, etc. > TF> The protocol specified in this draft appears to be (I'm reading between > TF> the lines here) that the EHLO domain name stated by the SMTP client is > TF> used to look up a SRV record. This record states in the weight field if > TF> that name may be used by an SMTP client, and it also contains a target > TF> name. The DNS reply should contain additional data, being the IP address > TF> records associated with this target name. One of these must match the > TF> client IP address from the SMTP connection in order for the EHLO domain > TF> name to be considered valid. Or maybe (according to HNA) the IP addresses > TF> associated with the EHLO domain itself must match the connection IP > TF> address. Or maybe the reverse DNS must agree too. This is not clear. It's > TF> also not clear how this relates to the RFC 2821 nix on EHLO checks. > > wow. what a really excellent summary! wish we had written it, and thoroughly > appreciate that you did. it will be a nice addition to the doc. I'm glad you like it :-) The question still remains about the authentication process. Does it use the addresses of the client EHLO domain? (As I understand it, no.) Or does it only use the CSA SRV target domain? (AIUI, yes.) Does it use both? if so, how? (AIUI, no.) What about reverse DNS? (AIUI, no.) -- Tony Finch http://dotat.at/ From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 09:53:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26861 for ; Wed, 16 Jun 2004 09:53:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GDZKT6058883; Wed, 16 Jun 2004 06:35:20 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GDZKYS058882; Wed, 16 Jun 2004 06:35:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from oe-im2.bizmailsrvcs.net (oe-im2pub.managedmail.com [206.46.164.53]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GDZJNd058862 for ; Wed, 16 Jun 2004 06:35:19 -0700 (PDT) (envelope-from sam_silberman+marid@openwave.com) Received: from mm-ismta4.bizmailsrvcs.net ([192.168.133.29]) by oe-im2.bizmailsrvcs.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040616133516.RTFT24679.oe-im2.bizmailsrvcs.net@mm-ismta4.bizmailsrvcs.net> for ; Wed, 16 Jun 2004 08:35:16 -0500 Received: from silbermans ([24.91.165.86]) by mm-ismta4.bizmailsrvcs.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040616133516.LRHL1757.mm-ismta4.bizmailsrvcs.net@silbermans> for ; Wed, 16 Jun 2004 08:35:16 -0500 Message-ID: <051701c453a6$c1826000$3a05440a@myopwv.com> Reply-To: "Sam Silberman" From: "Sam Silberman" To: References: <11604246.1087337651@[10.12.1.26]> Subject: Re: Working toward unity on XML Date: Wed, 16 Jun 2004 09:35:09 -0400 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.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Nice write-up Greg! [comments inline] ----- Original Message ----- From: "Greg Connor" To: Sent: Wednesday, June 16, 2004 1:14 AM Subject: Working toward unity on XML > > Position 3. Implement both, let domain owners decide: > Plain SPF and XML MUST be supported by all implementations. > > Position 4. Leave it up to the MTA: > Plain SPF MUST be supported. XML SHOULD be supported. The engineer side of my brain leans toward #3. If we go this direction, it will inevitable result in Position #4. It is easier to publish a DNS record than deploy the software to use them. It does not mater what we (or anyone) put on paper, If the MTAs don't use the MARID record, the exercise is moot. Since the MTA authors and system admins will have choices, they will choose the simplest approach that work for them (not us). No matter what we all think, we are on the road to #4. -Sam From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 11:15:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05757 for ; Wed, 16 Jun 2004 11:15:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GF01M9079149; Wed, 16 Jun 2004 08:00:01 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GF01mL079148; Wed, 16 Jun 2004 08:00:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GF01rc079123 for ; Wed, 16 Jun 2004 08:00:01 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.131.244.249] ([::ffff:216.168.239.87]) (AUTH: LOGIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Wed, 16 Jun 2004 10:59:59 -0400 id 000E3E40.40D06070.00003109 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <11604246.1087337651@[10.12.1.26]> References: <11604246.1087337651@[10.12.1.26]> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: Working toward unity on XML Date: Wed, 16 Jun 2004 10:59:58 -0400 To: IETF MARID WG X-Mailer: Apple Mail (2.613) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jun 16, 2004, at 1:14 AM, Greg Connor wrote: > Position 3. Implement both, let domain owners decide: > > Plain SPF and XML MUST be supported by all implementations. > Domain owners are free to publish in either format. People can vote > with their feet. > If there is no extension really needed, plain text will probably be > preferred because it is more readable. > If there is some extension that people end up needing, the XML may be > preferred in the future. > If there is a clear winner in terms of market adoption, perhaps a > later version of our standard will deprecate one or the other. > > > > Position 4. Leave it up to the MTA: > > Plain SPF MUST be supported. XML SHOULD be supported. > Those implementing MTA and mail filters can start with SPF as it is > written today, and are encouraged to support XML also, but reading and > acting on only the Plain SPF format is also allowed. > Software vendors that don't support XML do so at their own risk. > Users who feel they need XML support may complain. The software not > supporting XML may get negative reviews later, or have a checkmark > missing on the feature grid. Patches later might be needed. > Software that understand SPF now will be pretty much ready-to-go as is. > Domain owners may choose XML but might be faced with less support > among receivers. > Assuming the XML may be extended and the plain format might not be, > when both are present, the XML should be used, falling back to SPF > plain only if the MTA doesn't support XML. > Allows people to vote with their feet, sort of. Software vendors have > some freedom to choose, but are ultimately accountable to the > customers. The one thing that a standards specification must do, above getting past the standards process and finding community adoption, is to be interoperable. Quite simply, with a two syntax system, one of two things must be done for interoperability: 1) the publisher needs to publish both syntaxes, or 2) the receiver needs to implement both syntaxes. Additionally, a two syntax specification is many times more implementation work than a two record type system. To support two record types with the same syntax, the necessary code is simply "lookup type Y; if no records then lookup type X". For two separate syntaxes, the code paths are not nearly so similar. In fact, they are dissimilar enough that semantic interpretation will yield different results (leading toward interoperability problems). Finally, we must realize that any work put forward by the MARID working group will receive broader community review (IESG review and an IETF-wide last call). To any outsider looking at a MARID draft specifying two syntaxes, it could easily appear that the working group did not come to consensus on a syntax and is attempting to route around that fact. Both the SPF and XML syntaxes do the job at hand. Both are workable. And both are extensible. But we need to pick ONE. So the question should be, which one has the extensibility we desire. -andy From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 11:25:12 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07748 for ; Wed, 16 Jun 2004 11:25:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GFFUw9082515; Wed, 16 Jun 2004 08:15:30 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GFFUvw082513; Wed, 16 Jun 2004 08:15:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from goose.ehsco.com (goose.ehsco.com [207.65.203.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GFFTjr082501 for ; Wed, 16 Jun 2004 08:15:30 -0700 (PDT) (envelope-from ehall@ehsco.com) Received: from ehsco.com (ferret.corp.ntrg.com [207.65.71.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Eric A. Hall", Issuer "Network Technology Research Group Certificate Authority" (verified OK)) by goose.ehsco.com (Postfix ) with ESMTP id 2F9C945FE9; Wed, 16 Jun 2004 10:15:31 -0500 (CDT) Message-ID: <40D063F5.6030506@ehsco.com> Date: Wed, 16 Jun 2004 10:15:01 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Arnt Gulbrandsen , ietf-mxcomp@imc.org Subject: Re: Alternative to TXT or new RR References: <20040615223236.GA13225@dumbo.pobox.com> <1Fz8AGrZ9eBGLNyWqdk4Mg.md5@prosecco.oryx.com> In-Reply-To: <1Fz8AGrZ9eBGLNyWqdk4Mg.md5@prosecco.oryx.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/16/2004 5:36 AM, Arnt Gulbrandsen wrote: > I'm pretty sure we'd be doing a SRV lookup for _marid._udp. and > then asking that server whether to fail/pass/... the message. Has this been proposed? I'd support it since it avoids most of the problems with the existing approaches. The cost is shifted to the sender, who can implement whatever tests they want (or can afford), but who cannot get a ride on everybody else' dime. Blocking time would be slightly longer than DCC/Razor. It could still be made extensible if the RR listed the servers and the needed test data (MAIL-FROM, From:, Message-ID:, Date:, ...). The size of that RR would not be prohibitively large. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 11:34:12 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10069 for ; Wed, 16 Jun 2004 11:34:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GFNpWX084428; Wed, 16 Jun 2004 08:23:51 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GFNpIg084427; Wed, 16 Jun 2004 08:23:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GFNpfC084411 for ; Wed, 16 Jun 2004 08:23:51 -0700 (PDT) (envelope-from edlewis@arin.net) Received: by smtp2.arin.net (Postfix, from userid 5003) id 5DAB219B420; Wed, 16 Jun 2004 11:22:13 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id B508A19B451; Wed, 16 Jun 2004 11:22:11 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.136.136.83]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1780161; Wed, 16 Jun 2004 11:23:47 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: <11604246.1087337651@[10.12.1.26]> Date: Wed, 16 Jun 2004 11:23:45 -0400 To: Andrew Newton From: Edward Lewis Subject: Re: Working toward unity on XML Cc: IETF MARID WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63-arin1 (2004-01-11) on smtp2.arin.net X-Spam-Status: No, hits=-9.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63-arin1 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 10:59 -0400 6/16/04, Andrew Newton wrote: >has the extensibility we desire. Extensibility, per se, is desirable. But, given that MARID WG is supposed to a "quick hit" effort, on a short time scale for that reason, I am not convinced that extensibility is a realistic (primary) goal. Don't avoid it, but don't reach for it. The TXT RR is being favored by the group for expediency, against the architectural sensibilities of (at least some) DNS protocol experts. I think that the expediency argument holds more water if the solution derived in this group targets the immediate problem with an immediately focused solution, rather than being too concerned with extensibility. I find it odd that some would like to retain support for two different syntax's, yet resist proposing a new RR while maintaining the TXT RR for transition. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 11:35:44 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10513 for ; Wed, 16 Jun 2004 11:35:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GFPLtI084731; Wed, 16 Jun 2004 08:25:21 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GFPLQo084730; Wed, 16 Jun 2004 08:25:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GFPKEK084722 for ; Wed, 16 Jun 2004 08:25:20 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id 6907E1A702; Wed, 16 Jun 2004 17:25:22 +0200 (CEST) Received: from prosecco.oryx.com (unknown [217.19.171.140]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by bra.gulbrandsen.priv.no (Postfix) with ESMTP id BCFDE1A6D5 for ; Wed, 16 Jun 2004 17:25:20 +0200 (CEST) Message-Id: From: Arnt Gulbrandsen To: ietf-mxcomp@imc.org Subject: Re: Alternative to TXT or new RR References: <20040615223236.GA13225@dumbo.pobox.com> <1Fz8AGrZ9eBGLNyWqdk4Mg.md5@prosecco.oryx.com> <40D063F5.6030506@ehsco.com> In-Reply-To: <40D063F5.6030506@ehsco.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Wed, 16 Jun 2004 17:26:45 +0200 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Eric A. Hall writes: > On 6/16/2004 5:36 AM, Arnt Gulbrandsen wrote: >> I'm pretty sure we'd be doing a SRV lookup for _marid._udp. >> and then asking that server whether to fail/pass/... the message. > > Has this been proposed? I'd support it since it avoids most of the > problems with the existing approaches. I've mentioned it once or twice. Noone else has, as far as I know. Wasn't quite sure whether I was overlooking something obvious or everyone. > It could still be made extensible if the RR listed the servers and the > needed test data (MAIL-FROM, From:, Message-ID:, Date:, ...). The > size of that RR would not be prohibitively large. That would be possible even without a new RR, if the server's allowed to return a result such as "cannot decide for lack of header fields x y and z". But if the server's allowed to ask for any amount of data, TCP has to be used. Arnt From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 11:36:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10754 for ; Wed, 16 Jun 2004 11:36:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GFQRhC084971; Wed, 16 Jun 2004 08:26:27 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GFQRec084970; Wed, 16 Jun 2004 08:26:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (ntbbs.winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5GFQQ6I084962 for ; Wed, 16 Jun 2004 08:26:26 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Wed, 16 Jun 2004 11:29:39 -0400 Received: from ([68.219.67.20]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 1210426985; Wed, 16 Jun 2004 11:29:38 -0400 Message-ID: <007101c453b7$31674ab0$6401a8c0@hdev1> From: "Hector Santos" To: "Greg Connor" , "IETF-MXCOMP" References: <11604246.1087337651@[10.12.1.26]> Subject: Re: Working toward unity on XML Date: Wed, 16 Jun 2004 11:32:45 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.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: Content-Transfer-Encoding: 7bit Greg, You touched base with many fair issues on both sides. In our anti-spam product SMTP component (upgrade with new LMAP support released in in April), we added support forr DMP, SPF and MCEP. The reason was to be open and flexible and to means what works or not. I have just posted a survey in our support group to get some feedback on which polices they have defined. Also, I have the following stated in our online Setup documents. "CEP is relatively new and it is nearly equivalent in logic to SPF CEP does not have the large support yet as SPF. However, it should go without saying Microsoft CEP will become a major new internet standard in short time once it is added to their software packages." So even though from a technical support, I don't agree with the decision of using XML, we are not dumb either. I guess this holds with your position 3. [Side Note: I can not use CID as a acroynmn because it an 20 year old display scripting MACRO keyword and acroymn for Caller ID in our modem hosting product for modem CID Verification Support, logging and reporting. So logically, I used a new acroymn that is more techncally appropiate based on the Title of Microsoft own document - MCEP for Microsoft' Caller-id Email Policy. Just in case if people were wondering.] So with that said, I would like to say the following: Think about it what the new SMTP + MARID design requirements will be: - RFC 2821 - RFC 2822 - RFC MARID - Standard XML Library (for common behavior (including problems)). plus all the rest that come from this? - RFC 2376 (XML Media Types)? - RFC 3470 Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols.? - RFC 3688 The IETF XML Registry? Is this the level of complexity we are looking for such a narrow scope of a problem with a limited half-life? I believe this would be among the first time, if not the first, in the annals of internet development that a new standard will include a major provision for the usage of a 3rd party technology and/or sub-system. No big deal right? Well, it will imply the unrealistic belief that everyone will borrow or use the same or similar set of tools. In other words, it ignores the probability developer will re-invent the wheel and write their own parsers. A possible false security blanket due to possible "differences" where potential exploits will evolve and target. It would be a wrong assumption *all* Windows developers are using Microsoft component engineering technologies for product development. In fact, using the Microsoft XML components will introduce additional Windows OS sub-systems that may not be desirable for product design - ATL, DCOM, ACTIVEX. Once you do, you open yourself up to the Microsoft security nightmares the world has endured. The high quality of non Microsoft products for Windows platform is typically based on not using these poorly designed sub-systems from Microsoft which continue to this day to have new security issues. In short, the XML requirement will increase the vendors quality assurance requirements when in reality, it wasn't something that was necesary if only it made life easier for some people. We will use XML, if need be, but with our design, it will be own design. No problem, but absolutely a Microsoft dependency will not be introduced at this level. If this is people want, fine, but overall, I think you need not worry about what people will think 5 years from now, but rather what this high level requirement being imposes. It makes it all look silly today!! It is such a narrow scope, this XML introduction and the debate that followed because of it should not be the reason this WG is now threathen, but instead, the reason it should not be used. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com ----- Original Message ----- From: "Greg Connor" To: Sent: Wednesday, June 16, 2004 1:14 AM Subject: Working toward unity on XML > Position 1. In favor of XML: > > XML is extensible. We can add new syntax later without breaking things. > Our MARID data should be part of a larger picture of "email policy". > There are standard tools out there to parse XML that we can re-use. > We are going to look silly and be irrelevant in 5 years if we don't allow > extensions. I'm too old to have regrets, but I think it already looks silly that the solution proposed has so many questionable designs issues. > Position 2. Opposed to XML: > > XML records are too big for what we want. > Rampant extensibility might lead to inconsistent results later. > An XML parser would be too big for my MTA or other mail-analyzing program. > Keep It Simple. Testing an XML parser would be onerous compared to other > testing needed. > Mistrust of Microsoft and their motives for wanting XML > If we implement something too big or complex, we will look silly and be > irrelevant in 5 years. > > > Position 3. Implement both, let domain owners decide: > > Plain SPF and XML MUST be supported by all implementations. > Domain owners are free to publish in either format. People can vote with > their feet. > If there is no extension really needed, plain text will probably be > preferred because it is more readable. > If there is some extension that people end up needing, the XML may be > preferred in the future. > If there is a clear winner in terms of market adoption, perhaps a later > version of our standard will deprecate one or the other. > > > > Position 4. Leave it up to the MTA: > > Plain SPF MUST be supported. XML SHOULD be supported. > Those implementing MTA and mail filters can start with SPF as it is written > today, and are encouraged to support XML also, but reading and acting on > only the Plain SPF format is also allowed. > Software vendors that don't support XML do so at their own risk. Users who > feel they need XML support may complain. The software not supporting XML > may get negative reviews later, or have a checkmark missing on the feature > grid. Patches later might be needed. > Software that understand SPF now will be pretty much ready-to-go as is. > Domain owners may choose XML but might be faced with less support among > receivers. > Assuming the XML may be extended and the plain format might not be, when > both are present, the XML should be used, falling back to SPF plain only if > the MTA doesn't support XML. > Allows people to vote with their feet, sort of. Software vendors have some > freedom to choose, but are ultimately accountable to the customers. > > > > More thoughts on extensibility: > > There are two kinds of extensibility, and there is some disagreement as to > which we want, if any. > > "Feature" or "semantic" extensibility adds new mechanisms later, and may > change the output of the checking function, or even add new inputs to the > function. This can be supported, if done carefully. Either an intelligent > default, or an "alt=" type of statement attached to the extended feature, > would be needed in order for the software of today to "navigate around" the > data points we throw at it tomorrow. There is some support for this kind > of extensibility, but there are also others who feel strongly that we > should NOT be able to add new features on the fly, as this would lead to > inconsistent behavior among some implementations and that's not good. > > Regarding feature extensibility, my guess is there are probably a lot of > people who like it, but their support is lukewarm and they aren't > passionate about it enough to defend it. At the same time, there are > probably some people who feel strongly enough to come out swinging against > such flexibility, fearing that the new extensions won't add enough value to > offset the potential harm in flaky software not doing extensibility right > or not being consistent with each other. > > We also have "syntax" extensibility, which allows us to thrown in new data > later, but only as "extra" or "not core" data. The new data might give > extra info (like publish a domain's desire to receive problem reports) or > it might be something not relevant to MARID at all (like whether a domain > uses domainkeys, or where to find accreditation, or something like that). > > Just syntax extensions, with no feature extensions, are easy to add (to any > language, not just XML) as long as the rules are clear from the start. For > example, no "extra" data will ever result in a change to the > accept/deny/unknown function. An MTA can either ignore it totally, or > complain that it's a possible typo, depending on where the data appears. > (For example, an "ep" might have nodes other than "out" and "out" might > have nodes other than "m", but nodes within "m" should be of a recognized > type or the implementation should interpret this as a typo and throw an > error) > > > More about size: > > XML is going to be a bit bigger than plain SPF or other plain-token > language. Frankly, I don't see size to be a big issue... it is a concern, > but not enough of a concern for me to exert a veto or leave the party > early. We will have an include-type mechanism for stitching together > records. DNS *does* actually have a mechanism for fetching larger records, > even though it may be blocked by some firewalls... I think it's the > responsibility of the domain owner to make sure that the record fits in a > response packet, and test this, and those who choose to publish larger > records should do so at their own risk. > > > Wrap up, and where to go from here: > > I would prefer not to see replies to this post where people tear it up and > match one or two sentences of mine with some quick comeback of theirs. > That's a great style for arguing, but I think the time for arguing is past. > Most people who care about the issue have made most of the intelligent > arguments they are going to make. > > What I would really prefer to see is a few paragraphs that say: > 1. What position you support > 2. What other fallback or compromise positions you can live with, and > 3. How strongly you feel about one or the other. > > If you respond supporting one extreme, and don't state a compromise > position that you can live with (either 3 or 4 or something else I haven't > spelled out), then you might want to add a footnote saying why you believe > this issue is enough of a dealbreaker that you are not willing to > compromise, and why you are willing to let MARID fail rather than give in > on the issue. > > This is where the rubber really meets the road, and the hard work of the > working group starts. Failure to reach any agreement is a *guaranteed* way > to look silly and be irrelevant in 5 years :) Let's all try to work > together and rise to the challenge. We can do this. > > Thanks for your time. > gregc > -- > Greg Connor > > From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 12:02:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14349 for ; Wed, 16 Jun 2004 12:02:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GFtXiq091371; Wed, 16 Jun 2004 08:55:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GFtXSW091370; Wed, 16 Jun 2004 08:55:33 -0700 (PDT) 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.9) with ESMTP id i5GFtWcV091357 for ; Wed, 16 Jun 2004 08:55:32 -0700 (PDT) (envelope-from cm--jrk@merseymail.com) Received: from mmail by argon.connect.org.uk with local (connectmail/exim) id 1BaclA-0003qF-Gi; Wed, 16 Jun 2004 16:55:32 +0100 In-Reply-To: Subject: Re: Alternative to TXT or new RR To: "Arnt Gulbrandsen" From: "Jon Kyme" Cc: ietf-mxcomp@imc.org X-Mailer: [ConnectMail 3.15.6] X-connectmail-Originating-IP: 172.25.243.3 Message-Id: Date: Wed, 16 Jun 2004 16:55:32 +0100 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > > > Has this been proposed? I'd support it since it avoids most of the > > problems with the existing approaches. > > > I've mentioned it once or twice. Noone else has, as far as I know. > > Wasn't quite sure whether I was overlooking something obvious or > everyone. > > > It could still be made extensible if the RR listed the servers and the > > needed test data (MAIL-FROM, From:, Message-ID:, Date:, ...). The > > size of that RR would not be prohibitively large. > I think things like this *have* been proposed elsewhere (asrg?) no ref. sorry. Also, since reputation services have been suggested as being useful in anti-spam schemes involving marid, it's been suggested that marid can be reduced to a noop by supplying the peer-IP, MAIL-FROM duple (and anything else?) to some service providing reputation and/or authorisation. Well, actually, here MARID is reduced to (at most) a way of discovering the service. All very interesting - in scope? I dunno. From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 12:51:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19532 for ; Wed, 16 Jun 2004 12:51:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GGbihQ001863; Wed, 16 Jun 2004 09:37:44 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GGbixu001862; Wed, 16 Jun 2004 09:37:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GGbi3H001855 for ; Wed, 16 Jun 2004 09:37:44 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 16 Jun 2004 09:37:47 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 16 Jun 2004 09:37:49 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 16 Jun 2004 09:37:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-7d749d88-f1e9-48ce-b706-15518f9d28c7" Subject: On Extensibility in MARID Records Date: Wed, 16 Jun 2004 09:37:41 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF42A122@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: On Extensibility in MARID Records thread-index: AcRTwD5S6uGXwzGwQK25MmkrnsCgyA== From: "Jim Lyon" To: "IETF-MXCOMP" X-OriginalArrivalTime: 16 Jun 2004 16:37:46.0956 (UTC) FILETIME=[416AC8C0:01C453C0] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPartTM-000-7d749d88-f1e9-48ce-b706-15518f9d28c7 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C453C0.409985C8" ------_=_NextPart_001_01C453C0.409985C8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've been asked to defend the proposition that MARID records need more extensibility than can be easily afforded by SPF syntax. This thread is an attempt to do so, using two possible extensions. To paraphrase Mark Twain, I apologize for writing such a long email -- I didn't have time to write a short one. To set the stage, let's consider Rich Segal's comments at the interim meeting. He says IBM will publish a record something like: v=3Dspf1 +a:xxx +a:yyy +a:zzz -exists:%{i}.rbl.com ?all This says that if a message comes from one of the servers he knows about, it's good. If a message comes from a blacklisted address, it's bad. Otherwise, he's not sure. Now, he would like to be able to change the final "?all" to "-all", but he's not sure he's found all of the servers that send mail on IBM's behalf. Therefore, he needs feedback about mail that matches the "?all" so that he can refine his list. At first blush, he could say something like: v=3Dspf1 +a:xxx +a:yyy +a:zzz -exists:%{i}.rbl.com ?all feedback=3Dfeedback@ibm.com But that begs the question of what feedback he wants. In order to get feedback on mail that matches the "?all", the "feedback=3D" needs to = bind to the "?all". So, we could invent syntax like: v=3Dspf1 +a:xxx +a:yyy +a:zzz -exists:%{i}.rbl.com ?all/feedback=3Dfeedback@ibm.com (note the slash). This would be a step forward. It's also possible that their legal people would like feedback about mail that matches the "-exists", so that they can sue the offenders. So maybe their record ends up looking like: v=3Dspf1 +a:xxx +a:yyy +a:zzz -exists:%{i}.rbl.com/feedback=3Dabuse@ibm.com ?all/feedback=3Dfeedback@ibm.com Now, for purposes of refining their "?all", they may only want headers of messages that match, but for prosecuting abusers, they may need the entire message. So they might want to publish something like: v=3Dspf1 +a:xxx +a:yyy +a:zzz -exists:%{i}.rbl.com/feedback=3Dabuse@ibm.com,ret=3Dfull ?all/feedback=3Dfeedback@ibm.com,ret=3Dhdrs Now, IBM may very well want to monitor the activity of the third party they contract with that uses address zzz, so that mechanism might look like +a:zzz/feedback=3Dmonitor@ibm.com,ret=3Dhdrs All of the above has had to do with a hypothetical "feedback" extension, with various parameters. It's also possible that there will be extensions that classify the mail coming from various sources. For example, if the address range +a:zzz is used by IBM for sending bulk mail, the mechanism may want to say +a:zzz/type=3Dbulk Putting the two extensions together, we get +a:zzz/feedback=3Dmonitor@ibm.com,ret=3Dhdrs,type=3Dbulk Now we're really pushing the limits. In the above example, "ret=3Dhdrs" modifies "feedback", which modifies the mechanism. But "type=3Dbulk" = just modifies the mechanism. So the above example has syntactic ambiguity built in. We need a heavier structure to resolve the ambiguity: brackets or parentheses or tags or some such. We could get there with parentheses by writing something like: +a:zzz(feedback:monitor@ibm.com(ret=3Dhdrs))(type=3Dbulk) But now we've already left the realm of a simple regex parser -- the possibility of nesting implies at least a push-down parser. If we ever expect to be able to extend SPF records, we need to define the extensible syntax now. (Not the details of "feedback" or "type", but the syntax for telling where each extension starts and ends). That syntax needs to account for special characters, like email addresses that contain an "=3D" or ":". Processors that we deploy today need to = be able to parse (and discard) this stuff, even though things like the "feedback" extension may not be defined for another year or two. By the time we've got enough extensibility, the complexity of a conforming parser approaches that of XML. XML is rich enough to handle all of the above. The spec is well debugged. XML Schemas include a mechanism for defining what's legal in a document, even if part of what's legal is tags that haven't been defined yet. There are dozens of extant parsers -- for Linux, for Unix, for Windows, for S/390. Written in C, C++, Java, Perl, Python, C# and probably even Intercal. So, XML fits the requirements that I've outlined above, and it's the only thing that I know of that does. Of course, it would be possible to design an SPF-like language that meets these, but "possible" isn't enough. It hasn't been done, and I doubt that we would get it right on the first try if we did attempt it. ------_=_NextPart_001_01C453C0.409985C8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Extensibility in MARID Records

I've been asked to defend the = proposition that MARID records need more extensibility than can be = easily afforded by SPF syntax.  This thread is an attempt to do so, = using two possible extensions.  To paraphrase Mark Twain, I = apologize for writing such a long email -- I didn't have time to write a = short one.

To set the stage, let's consider = Rich Segal's comments at the interim meeting.  He says IBM will = publish a record something like:

    v=3Dspf1 = +a:xxx +a:yyy +a:zzz -exists:%{i}.rbl.com ?all
This says that if a message = comes from one of the servers he knows about, it's good.  If a = message comes from a blacklisted address, it's bad.  Otherwise, = he's not sure.

Now, he would like to be able to = change the final "?all" to "-all", but he's not sure = he's found all of the servers that send mail on IBM's behalf.  = Therefore, he needs feedback about mail that matches the = "?all" so that he can refine his list.  At first blush, = he could say something like:

    v=3Dspf1 = +a:xxx +a:yyy +a:zzz -exists:%{i}.rbl.com ?all = feedback=3Dfeedback@ibm.com

But that begs the question of = what feedback he wants.  In order to get feedback on mail that = matches the "?all", the "feedback=3D" needs to bind = to the "?all".  So, we could invent syntax = like:

    v=3Dspf1 = +a:xxx +a:yyy +a:zzz -exists:%{i}.rbl.com = ?all/feedback=3Dfeedback@ibm.com
(note the slash).  This = would be a step forward.  It's also possible that their legal = people would like feedback about mail that matches the = "-exists", so that they can sue the offenders.  So maybe = their record ends up looking like:

    v=3Dspf1 = +a:xxx +a:yyy +a:zzz -exists:%{i}.rbl.com/feedback=3Dabuse@ibm.com = ?all/feedback=3Dfeedback@ibm.com

Now, for purposes of refining = their "?all", they may only want headers of messages that = match, but for prosecuting abusers, they may need the entire = message.  So they might want to publish something like:

    v=3Dspf1 = +a:xxx +a:yyy +a:zzz = -exists:%{i}.rbl.com/feedback=3Dabuse@ibm.com,ret=3Dfull = ?all/feedback=3Dfeedback@ibm.com,ret=3Dhdrs

Now, IBM may very well want to = monitor the activity of the third party they contract with that uses = address zzz, so that mechanism might look like

    = +a:zzz/feedback=3Dmonitor@ibm.com,ret=3Dhdrs

All of the above has had to do = with a hypothetical "feedback" extension, with various = parameters.  It's also possible that there will be extensions that = classify the mail coming from various sources.  For example, if the = address range +a:zzz is used by IBM for sending bulk mail, the mechanism = may want to say

    = +a:zzz/type=3Dbulk

Putting the two extensions = together, we get
    = +a:zzz/feedback=3Dmonitor@ibm.com,ret=3Dhdrs,type=3Dbulk

Now we're really pushing the = limits. In the above example, "ret=3Dhdrs" modifies = "feedback", which modifies the mechanism.  But = "type=3Dbulk" just modifies the mechanism.  So the above = example has syntactic ambiguity built in. We need a heavier structure to = resolve the ambiguity: brackets or parentheses or tags or some = such.  We could get there with parentheses by writing something = like:

    = +a:zzz(feedback:monitor@ibm.com(ret=3Dhdrs))(type=3Dbulk)

But now we've already left the = realm of a simple regex parser -- the possibility of nesting implies at = least a push-down parser.  If we ever expect to be able to extend = SPF records, we need to define the extensible syntax now.  (Not the = details of "feedback" or "type", but the syntax for = telling where each extension starts and ends).  That syntax needs = to account for special characters, like email addresses that contain an = "=3D" or ":".  Processors that we deploy today = need to be able to parse (and discard) this stuff, even though things = like the "feedback" extension may not be defined for another = year or two.  By the time we've got enough extensibility, the = complexity of a conforming parser approaches that of XML.


XML is rich enough to handle all = of the above.  The spec is well debugged.  XML Schemas include = a mechanism for defining what's legal in a document, even if part of = what's legal is tags that haven't been defined yet.  There are = dozens of extant parsers -- for Linux, for Unix, for Windows, for = S/390.  Written in C, C++, Java, Perl, Python, C# and probably even = Intercal.

So, XML fits the requirements = that I've outlined above, and it's the only thing that I know of that = does.  Of course, it would be possible to design an SPF-like = language that meets these, but "possible" isn't enough.  = It hasn't been done, and I doubt that we would get it right on the first = try if we did attempt it.


------_=_NextPart_001_01C453C0.409985C8-- ------=_NextPartTM-000-7d749d88-f1e9-48ce-b706-15518f9d28c7-- From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 12:52:05 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19561 for ; Wed, 16 Jun 2004 12:52:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GBr1eG029604; Wed, 16 Jun 2004 04:53:01 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GBr1Ik029603; Wed, 16 Jun 2004 04:53:01 -0700 (PDT) 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.9) with ESMTP id i5GBr0Mr029580 for ; Wed, 16 Jun 2004 04:53:00 -0700 (PDT) (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.34) id 1BaYyA-0004HR-FQ for ietf-mxcomp@imc.org; Wed, 16 Jun 2004 06:53:00 -0500 To: "IETF MARID WG" References: <11604246.1087337651@[10.12.1.26]> From: wayne Reply-To: "IETF MARID WG" Date: Wed, 16 Jun 2004 06:52:42 -0500 In-Reply-To: <11604246.1087337651@[10.12.1.26]> (Greg Connor's message of "Tue, 15 Jun 2004 22:14:11 -0700") 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 (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: Working toward unity on XML Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-4.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <11604246.1087337651@[10.12.1.26]> Greg Connor writes: >> gconnor: I think the XML issue is a very small part of the important work >> we are doing within MARID. It's an implementation detail. We have made a >> lot of progress in terms of coming together on identities and features. >> let's not forget that. I know the XML issue pushes a lot of people's hot >> buttons. I don't want this issue, which I consider "not really central to >> the problem we are trying to solve" to tear the group apart This comment got a lot of support on the Jabber session. I'm going to this message reply out-of-order > I would prefer not to see replies to this post where people tear it up > and match one or two sentences of mine with some quick comeback of > theirs. That's a great style for arguing, but I think the time for > arguing is past. Most people who care about the issue have made most > of the intelligent arguments they are going to make. > > What I would really prefer to see is a few paragraphs that say: > 1. What position you support For better or worse, I think that position 2 is the only option that makes sense. > 2. What other fallback or compromise positions you can live with, and Position 4 > 3. How strongly you feel about one or the other. I, personally, don't feel that strongly against XML, but I do think things should be as simple as possible (but no simpler) and my position reflects what I sense from the people on SPF-discuss that are not involved in MARID. Ok, now that I've answered the questions the way Greg asked for, I have a few more comments. I think it is critical to keep in mind that there are no protocol police. In effect, there are several groups of people who have effective veto power over any of our choices. If domain owners don't like something, they won't publish records. If mail admins don't like something they won't check records. If MTA authors don't like something, they won't give mail admins a choice. If the IESG doesn't like something, they won't give us an RFC. > Position 1. In favor of XML: Caller-ID (XML) has not had a huge publication rate. This *may* be a case of domain owners vetoing XML, but there are many other possibilities. > Position 2. Opposed to XML: SPF-classic (SPF syntax) has had a far larger publication rate. This tells me that domain owners aren't vetoing SPF syntax. > Position 3. Implement both, let domain owners decide: Most domain owners who have published Caller-ID have also publish SPF-classic. There really isn't much to stop people from publishing both. > Position 4. Leave it up to the MTA: Here is the crux of the problem. It is generally mail admins that are the most vocal against XML, with a fair number of DNS folks and MTA patch authors thrown in. Again, there really isn't much to stop mail admins from checking just one. So, even if we officially say in the RFC that our is position 3), mail admins have veto power and will convert the situation into position 4) anyway. I don't particularly like position 4), but in reality, I don't think position 3) is an option on anything other than paper. So, when you realize that position 3) is really position 4), you accept that domain owners aren't vetoing position 2, and combined with the KISS principle, I think that position 2) is the only one that makes sense. Ok, let me repeat Greg's opening comment, it is worth a re-read: >> gconnor: I think the XML issue is a very small part of the important work >> we are doing within MARID. It's an implementation detail. We have made a >> lot of progress in terms of coming together on identities and features. >> let's not forget that. I know the XML issue pushes a lot of people's hot >> buttons. I don't want this issue, which I consider "not really central to >> the problem we are trying to solve" to tear the group apart The XML issue is not just tearing this group apart, it threatens the adoption by mail admins of any RFC that uses XML. I'm not going to claim that the opposition of XML by mail admins is always rational, but we must acknowledge and deal with this situation anyway. -wayne From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 12:54:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19995 for ; Wed, 16 Jun 2004 12:54:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GGlB2F003903; Wed, 16 Jun 2004 09:47:11 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GGlBXV003902; Wed, 16 Jun 2004 09:47:11 -0700 (PDT) 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.9) with ESMTP id i5GGlARf003894 for ; Wed, 16 Jun 2004 09:47:10 -0700 (PDT) (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 i5GGlASw010646 for ; Wed, 16 Jun 2004 09:47:12 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 16 Jun 2004 09:47:05 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: ietf-mxcomp@imc.org Subject: Its the XML infoset that is key RE: Working toward unity on XML Date: Wed, 16 Jun 2004 09:47:03 -0700 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 disagree with Greg's characterization of the problem. The key architectural advantage of XML is that you separate syntax definition and data structure definition. This makes for a vastly better result, it leads to much better consistency than you get with the ad hoc approach that has been encouraged by yacc. Regardless of the syntactic representation we should define SenderID in terms of the XML Infoset. SPF has a slight amount of convoluted syntax, but on the whole it reasonably clean - at least at present. The problem lies in the fact that the only extension mechanism provided in SPF is a list of attribute/value pairs. This allows a lot to be done but forces you into convoluted dances when you have an extension that requires values that have some structure. Do not forget here that our objective here is to gain acceptance by the Internet community at large. The endorsement of the IESG is significant but so is the endorsement of the stakeholders. What we definitely should not do is try to predict the disposition of the IESG through clairvoyance as some are suggesting. If the IESG want to make a point to the group then they should send us an email. I do not accept the claim that we should change course here and make decisions on what have been flagged as showstopper issues by key stakeholders on the basis of reading tea leaves. If this is a showstopper issue for the IESG then it is Ted's responsibility to tell us. We have a completely principled architecture here. We are recognizing the importance of both a clean architecture with clear separation of syntax and data structures, we equally recognize the need to provide support for legacy systems that use a less architecturally pure syntax. If this proves indigestible to the IESG my guess is that the XML RFC will be accepted as standard and the SPF RFC as informational. That suits me fine since I don't think anyone in the Internet world takes the slightest piece of notice of which status is applied. It will not change any product plans I have and I don't imagine it will change the product or project plans of any other party. From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 12:56:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20409 for ; Wed, 16 Jun 2004 12:56:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GGlCDi003912; Wed, 16 Jun 2004 09:47:12 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GGlCMD003911; Wed, 16 Jun 2004 09:47:12 -0700 (PDT) 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.9) with ESMTP id i5GGlBhw003876 for ; Wed, 16 Jun 2004 09:47:11 -0700 (PDT) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id ECCAAE06B0; Wed, 16 Jun 2004 12:47:10 -0400 (EDT) Date: Wed, 16 Jun 2004 12:47:10 -0400 From: John Leslie To: Matthew Elvey Cc: John Leslie , MXCOMP Subject: Re: CSV specification revision available Message-ID: <20040616164710.GG38007@verdi> References: <1665390638.20040614190711@brandenburg.com> <20040615031048.GP44160@verdi> <40CE9F08.2050002@elvey.com> <20040615115828.GQ44160@verdi> <1087328029.10303.198484820@webmail.messagingengine.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1087328029.10303.198484820@webmail.messagingengine.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Matthew Elvey wrote: > On Tue, 15 Jun 2004 07:58:28 -0400, "John Leslie" said: >> Matthew Elvey wrote: >> >>> Also, I don't see how 3.2 SMTP Auth protects aol.com from this same abuse. >>> >>> RE. 3.1 StartTLS: *IF* STARTTLS is used *AND* the sending server's cert >>> is CA signed, then that makes sense. >> >> I'm not sure I understand your question here. Could you clarify? > > I'm saying two things. > 1) Just as rDNS doesn't tie an IP to a domain for our purposes, perhaps > neither does SMTP Auth. True. SMTP AUTH does not tie to an IP address. It does, however, authenticate that you're talking with an SMTP client worthy of some level of trust (it gave an appropriate response to the challenge you issued). It didn't seem a stretch to think that this might sometimes prove it trustworthy enough to give a correct EHLO string. Having said that, it's hard to imagine the case where host name authentication would be the only thing missing _and_ SMTP AUTH would be in use. > So it perhaps shouldn't be part of the spec, if the purpose is just to > be a component of CSV. I believe Dave included it for completeness of background, and it really isn't part of our proposal. > 2) Just as rDNS doesn't tie an IP to a domain for our purposes, > STARTTLS might not either - i.e. STARTTLS should be used to validate > the identity of the connection initiator, not the connection acceptor. Agreed: if STARTTLS doesn't validate the initiator, it's useless for host name authentication. However, we realize there _will_ be cases where the SRV lookup doesn't return the matching IP address, but local policy may recognize STARTTLS as "sufficient authentication". > I guess if either these two methods are mentioned here but not relevant > to CSV, that should be stated. I can't quite agree they're "not relevant"; but I agree that a warning label is appropriate. ;^) -- John Leslie From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 13:20:50 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22753 for ; Wed, 16 Jun 2004 13:20:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GH9IY5008612; Wed, 16 Jun 2004 10:09:18 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GH9IWH008611; Wed, 16 Jun 2004 10:09:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gateway.deployzone.net (adsl-212-90-218-6.cybernet.ch [212.90.218.6]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5GH9GEM008581 for ; Wed, 16 Jun 2004 10:09:17 -0700 (PDT) (envelope-from chris@zumbrunn.com) Received: from userstation32.mediaconnect.ch [193.73.78.2] by gateway.deployzone.net; Wed, 16 Jun 2004 19:09:01 +0200 In-Reply-To: <11604246.1087337651@[10.12.1.26]> References: <11604246.1087337651@[10.12.1.26]> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: ietf-mxcomp@imc.org From: Chris Zumbrunn Subject: Re: Working toward unity on XML Date: Wed, 16 Jun 2004 19:08:59 +0200 To: Greg Connor X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 16. Jun 2004, at 7:14, Greg Connor wrote: > What I would really prefer to see is a few paragraphs that say: > 1. What position you support Position 2. Opposed to XML I'm against putting XML in DNS and I'm against forcing developers and admins to do XML parsing in MTAs. > 2. What other fallback or compromise positions you can live with, and Position 4. Plain SPF MUST be supported. XML SHOULD be supported. This position actually makes a lot of sense to me anyway because one can be much quicker deployed than the other. I would SUGGEST the following to be considered as a possible compromise: * The non-XML SPF DNS syntax would be extended so that DNS can contain a pointer to non-DNS based SPF policy data. * An SMTP POLICY command would be added for MTAs to fetch that data from the designated source. * That data could then be in any format that MTAs would be willing to read - including XML I would ACCEPT pretty much any compromise: It's not like I'd really have a choice ;-) BUT: I might wait with implementing it until I have to!!! > 3. How strongly you feel about one or the other. See above :-) Cheers, Chris chris@czv.com +41 329 41 41 41 Chris Zumbrunn Ventures - http://www.czv.com/ From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 13:32:22 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23601 for ; Wed, 16 Jun 2004 13:32:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GHJb8i011511; Wed, 16 Jun 2004 10:19:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GHJbRT011510; Wed, 16 Jun 2004 10:19:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [64.139.47.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GHJZT4011500 for ; Wed, 16 Jun 2004 10:19:36 -0700 (PDT) (envelope-from gconnor@nekodojo.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by neko-base.nekodojo.org (Postfix) with ESMTP id A540D1D651 for ; Wed, 16 Jun 2004 10:19:38 -0700 (PDT) Date: Wed, 16 Jun 2004 10:19:39 -0700 From: Greg Connor To: IETF MARID WG Subject: Re: Working toward unity on XML Message-ID: <6968019.1087381179@Ryoga.corp.sgi.com> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --Andrew Newton wrote: > > Both the SPF and XML syntaxes do the job at hand. Both are workable. > And both are extensible. But we need to pick ONE. So the question > should be, which one has the extensibility we desire. I appreciate the background info on IESG and IETF. It is useful. It sounds like you are saying "Pick ONE Language" should be considered a requirement of the group. Do you believe strongly that it should? In the case where we have to pick one and only one language, here is a new summary of issues and a new possible compromise position. > Position 1. In favor of XML: > 1. XML is it. * We see extensibility as a core requirement (at least syntax, but leaving the door open for features as well). We see XML as synonymous with extensibility, and we see a customized language like SPF as inferior in this regard, and can clearly articulate why. * Also, we see MARID as a part of a larger scheme of "email policy documents" and we can clearly articulate what that means. * There may be size issues but we are willing to deal with that. * Supporting those domains that have already published SPF is not a big concern. > Position 2. Opposed to XML: > 2. SPF classic syntax * Extensibility is a reasonable goal, but should not get in the way of simplicity, human-readability, and byte-economy, which we see as more important. * We are not convinced of the need to bind MARID together with a larger "email policy" document that is not yet defined. * SPF classic is extensible by way of adding modifiers (e.g. domainkeys=all) and by new version tags (e.g. v=spf1d). SPF records may contain unknown mechanism (like +dk) but pre-existing implementations will always stop and return "unknown" in that case. * Support for those domains that have already published SPF is important. > Position 3. Implement both, let domain owners decide: > > Position 4. Leave it up to the MTA: > 5. XML is the standard. Receivers MAY also check other "legacy" formats. * We believe XML is likely to take over in the future. Implementations are considered MARID-compliant if they read and understand XML TXT records published using a _prefix (such as _ep or _lmap) * It's up to sysadmins and MTA implementers if they want to support SPF records also. A large number of MTAs will choose to do this anyway, given the large amount of data already published. SPF data will be published at the domain itself, rather than at a _prefix label. * It is conceiveable that market forces may continue to create demand for SPF Classic even well after the initial deployment. If people continue to use and support SPF Classic and XML fails to take off, a future RFC may codify the de-facto standard. Here is my take on this. During the jabber session, Jim Lyon expressed that it is important to him that MARID be a part of a larger context, and that "email policy document" is something that the world needs anyway. This sounds "nice" BUT I don't accept this as a "requirement". Therefore, I am willing to accept compromise position 5 ONLY if there is a draft from MS saying "Here is why we need an Email Policy Document over and above MARID requirements" AND that draft receives favorable responses from MARID members. Right now, I don't believe extensibility trumps simplicity, economy, and the large amount of data published in SPF classic format. -- Greg Connor From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 13:49:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24497 for ; Wed, 16 Jun 2004 13:49:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GHYl0a015478; Wed, 16 Jun 2004 10:34:47 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GHYlnG015477; Wed, 16 Jun 2004 10:34:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp-out-1001.amazon.com (smtp-out-1001.amazon.com [207.171.160.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GHYkev015451 for ; Wed, 16 Jun 2004 10:34:47 -0700 (PDT) (envelope-from jonagard@amazon.com) Received: from ex-gate-02.ant.amazon.com by smtp-out-1001.amazon.com with ESMTP (peer crosscheck: [10.16.148.40]) X-Amazon-Corporate-Relay: smtp-out-1001.vdc.amazon.com X-AMAZON-TRACK: ietf-mxcomp@imc.org Received: from jonagard.desktop.amazon.com ([10.21.12.165]) by ex-gate-02.ant.amazon.com over TLS secured channel with Microsoft SMTPSVC(5.0.2195.6713); Wed, 16 Jun 2004 10:34:29 -0700 From: Jonathan Gardner Organization: Amazon To: "Jim Lyon" Subject: Re: On Extensibility in MARID Records Date: Wed, 16 Jun 2004 10:26:49 -0700 User-Agent: KMail/1.6 Cc: "IETF-MXCOMP" References: <81AC085044D04B429F5FB883D94FA1AF42A122@df-fido-msg.exchange.corp.microsoft.com> In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF42A122@df-fido-msg.exchange.corp.microsoft.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="euc-kr" Message-Id: <200406161026.50907.jonagard@amazon.com> X-OriginalArrivalTime: 16 Jun 2004 17:34:30.0247 (UTC) FILETIME=[2DEFC770:01C453C8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5GHYlev015472 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Not quoting as I couldn't find anythine appropriate to quote. Read the previous email in its entirety for context. It makes me wonder whether we would really want to add complexity like the above. I believe the K.I.S.S. (Keep It Simple, Stupid) applies here. Yes, XML can handle it. So could any other way of serializing data structures, however. SPF syntax could do it as well, as you have shown. We already have serious problems trying to get HTML and CSS to behave the same in both IE and Mozilla. I would hate for that to transfer into something that should be simple. In the email world, it isn't X vs. Y. It's A vs. B vs. ... Z. We have to make sure that every implementation behaves in exactly the same way. There is no room for ambiguity or contradicting results here. We can't get two web browsers to agree on a simple XML document. How can we expect to get 30+ implementations to agree on a different kind of XML? Extensibility is actually a bad thing, because we can't extend the syntax without upgrading every implementation out there. Let's return to the original intention. We want to establish authority for a server to send email for a domain. That's it. We aren't going to be sending emails for every email we receive for a domain; that doesn't scale, and you get into a situation where you can actually start recursive mails. I know that what you are describing is hypothetical, and I know that you would propose ways to work around these problems. But the point is that anything beyond establishing authority should be out-of-bounds and beyond the scope of this group. The original SPF syntax allows domain owners to express which servers are allowed to send email beautifully. Sure, it can't express every situation out there, but it expresses the vast majority of cases remarkably well. In the cases where the SPF syntax doesn't do a good job of expressing which servers are good or bad, the domain owners should probably find some way of simplifying their setup. There are already mechanisms where you can have a specific server calculate whether to deny or allow a server to send email based on all the information that's available when that decision needs to be made. What more can you possible want, without leaving the area of authentication? - -- Jonathan M. Gardner Mass Mail Systems Developer, Amazon.com jonagard@amazon.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFA0ILZBFeYcclU5Q0RAhdoAKCW4WZ/uNGRRtm/1thslhc3VltbeQCeJvRL d9Df59W2slMcP64uDBaWTfI= =jhOV -----END PGP SIGNATURE----- From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 13:50:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24774 for ; Wed, 16 Jun 2004 13:50:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GHghCY017501; Wed, 16 Jun 2004 10:42:43 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GHghdr017500; Wed, 16 Jun 2004 10:42:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ernie.mail-abuse.org (Ernie.mail-abuse.org [168.61.5.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GHghPD017483 for ; Wed, 16 Jun 2004 10:42:43 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.mail-abuse.org (DDev.mail-abuse.org [168.61.10.124]) by ernie.mail-abuse.org (8.12.0.Beta19/8.12.0) with ESMTP id i5GHggPQ056828; Wed, 16 Jun 2004 10:42:42 -0700 (PDT) Subject: Re: CSV specification revision available From: Douglas Otis To: John Leslie Cc: Matthew Elvey , MXCOMP In-Reply-To: <20040616164710.GG38007@verdi> References: <1665390638.20040614190711@brandenburg.com> <20040615031048.GP44160@verdi> <40CE9F08.2050002@elvey.com> <20040615115828.GQ44160@verdi> <1087328029.10303.198484820@webmail.messagingengine.com> <20040616164710.GG38007@verdi> Content-Type: text/plain Message-Id: <1087407761.32512.76.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 16 Jun 2004 10:42:42 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-06-16 at 09:47, John Leslie wrote: > Matthew Elvey wrote: > > On Tue, 15 Jun 2004 07:58:28 -0400, "John Leslie" said: > >> Matthew Elvey wrote: > >> > >>> Also, I don't see how 3.2 SMTP Auth protects aol.com from this same abuse. > >>> > >>> RE. 3.1 StartTLS: *IF* STARTTLS is used *AND* the sending server's cert > >>> is CA signed, then that makes sense. > >> > >> I'm not sure I understand your question here. Could you clarify? > > > > I'm saying two things. > > 1) Just as rDNS doesn't tie an IP to a domain for our purposes, perhaps > > neither does SMTP Auth. > > True. SMTP AUTH does not tie to an IP address. > > It does, however, authenticate that you're talking with an SMTP client > worthy of some level of trust (it gave an appropriate response to the > challenge you issued). It didn't seem a stretch to think that this might > sometimes prove it trustworthy enough to give a correct EHLO string. I think this can be restricted to only consider open systems. > Having said that, it's hard to imagine the case where host name > authentication would be the only thing missing _and_ SMTP AUTH would > be in use. > > > So it perhaps shouldn't be part of the spec, if the purpose is just to > > be a component of CSV. > > I believe Dave included it for completeness of background, and it > really isn't part of our proposal. > > > 2) Just as rDNS doesn't tie an IP to a domain for our purposes, > > STARTTLS might not either - i.e. STARTTLS should be used to validate > > the identity of the connection initiator, not the connection acceptor. > > Agreed: if STARTTLS doesn't validate the initiator, it's useless for > host name authentication. It can authenticate both ends. It normally does not. But this could be used in an open system. It is just too expensive to be used in this manner. > However, we realize there _will_ be cases where the SRV lookup doesn't > return the matching IP address, but local policy may recognize STARTTLS > as "sufficient authentication". > > > I guess if either these two methods are mentioned here but not relevant > > to CSV, that should be stated. > > I can't quite agree they're "not relevant"; but I agree that a warning > label is appropriate. ;^) > > -- > John Leslie From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 13:54:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25237 for ; Wed, 16 Jun 2004 13:54:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GHdcnb016648; Wed, 16 Jun 2004 10:39:38 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GHdcee016647; Wed, 16 Jun 2004 10:39:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ernie.mail-abuse.org (Ernie.mail-abuse.org [168.61.5.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GHdcRa016634 for ; Wed, 16 Jun 2004 10:39:38 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.mail-abuse.org (DDev.mail-abuse.org [168.61.10.124]) by ernie.mail-abuse.org (8.12.0.Beta19/8.12.0) with ESMTP id i5GHdKPQ056818; Wed, 16 Jun 2004 10:39:20 -0700 (PDT) Subject: Re: Alternative to TXT or new RR From: Douglas Otis To: "Eric A. Hall" Cc: Arnt Gulbrandsen , MARID In-Reply-To: <40D063F5.6030506@ehsco.com> References: <20040615223236.GA13225@dumbo.pobox.com> <1Fz8AGrZ9eBGLNyWqdk4Mg.md5@prosecco.oryx.com> <40D063F5.6030506@ehsco.com> Content-Type: text/plain Message-Id: <1087407560.32512.72.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 16 Jun 2004 10:39:20 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-06-16 at 08:15, Eric A. Hall wrote: > On 6/16/2004 5:36 AM, Arnt Gulbrandsen wrote: > > > I'm pretty sure we'd be doing a SRV lookup for _marid._udp. and > > then asking that server whether to fail/pass/... the message. > > Has this been proposed? I'd support it since it avoids most of the > problems with the existing approaches. > > The cost is shifted to the sender, who can implement whatever tests they > want (or can afford), but who cannot get a ride on everybody else' dime. > > Blocking time would be slightly longer than DCC/Razor. > > It could still be made extensible if the RR listed the servers and the > needed test data (MAIL-FROM, From:, Message-ID:, Date:, ...). The size of > that RR would not be prohibitively large. I doubt that such a mechanism would be able to block mail. The best that could be expected would be to mark mail. (The open list issue.) Blocking mail would be bad as static information is not comprehensive nor would tracking all possible avenues be practical to administer. There could be a system for those "off the reservation" to mail this "domain of record" a notice to accept mail sent from their current location, if it contained a valid signature perhaps. This could be treated like a cache where this information would expire after so many days. The next problem would be DoS. Can this be done using UDP? As this gets implemented, will these systems see mail rejected because their service approval service fails? -Doug From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 14:11:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25887 for ; Wed, 16 Jun 2004 14:11:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GHwgrl021040; Wed, 16 Jun 2004 10:58:42 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GHwgX7021039; Wed, 16 Jun 2004 10:58:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp-out-2002.amazon.com (smtp-out-2002.amazon.com [207.171.160.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GHwfVK021002 for ; Wed, 16 Jun 2004 10:58:41 -0700 (PDT) (envelope-from jonagard@amazon.com) Received: from ex-gate-02.ant.amazon.com by smtp-out-2002.amazon.com with ESMTP (peer crosscheck: [10.16.148.40]) X-Amazon-Corporate-Relay: smtp-out-2002.iad2.amazon.com X-AMAZON-TRACK: ietf-mxcomp@imc.org Received: from jonagard.desktop.amazon.com ([10.21.12.165]) by ex-gate-02.ant.amazon.com over TLS secured channel with Microsoft SMTPSVC(5.0.2195.6713); Wed, 16 Jun 2004 10:58:38 -0700 From: Jonathan Gardner Organization: Amazon To: Greg Connor Subject: Re: Working toward unity on XML Date: Wed, 16 Jun 2004 10:50:59 -0700 User-Agent: KMail/1.6 Cc: ietf-mxcomp@imc.org References: <11604246.1087337651@[10.12.1.26]> In-Reply-To: <11604246.1087337651@[10.12.1.26]> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="euc-kr" Message-Id: <200406161051.00332.jonagard@amazon.com> X-OriginalArrivalTime: 16 Jun 2004 17:58:39.0041 (UTC) FILETIME=[8D7C3310:01C453CB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5GHwfVK021033 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 15 June 2004 10:14 pm, Greg Connor wrote: > > What I would really prefer to see is a few paragraphs that say: > 1. What position you support > 2. What other fallback or compromise positions you can live with, and > 3. How strongly you feel about one or the other. > 1. Position 2: Plain SPF 2. I can't live with any other option. 3. I feel very strongly about (1). I believe that if (1) isn't adopted, we will lose all credibility. There is the very real risk of SPF being adopted regardless of the IETF. SPF has already shown momentum. No other proposal has. - -- Jonathan M. Gardner Mass Mail Systems Developer, Amazon.com jonagard@amazon.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFA0IiDBFeYcclU5Q0RAuhPAKCASNryOxrhPDMTszMYEH5IMJ/evACgy94x D6Lh2R/ILJ9MDX+ynxveGiU= =w+mm -----END PGP SIGNATURE----- From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 14:15:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25975 for ; Wed, 16 Jun 2004 14:15:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GI5N8P022429; Wed, 16 Jun 2004 11:05:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GI5NtI022428; Wed, 16 Jun 2004 11:05:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GI5MHB022417 for ; Wed, 16 Jun 2004 11:05:23 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.131.244.249] ([::ffff:216.168.239.87]) (AUTH: LOGIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Wed, 16 Jun 2004 14:05:20 -0400 id 000E3E46.40D08BE0.00004503 In-Reply-To: <6968019.1087381179@Ryoga.corp.sgi.com> References: <6968019.1087381179@Ryoga.corp.sgi.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Greg Connor From: Andrew Newton Subject: Re: Working toward unity on XML Date: Wed, 16 Jun 2004 14:05:19 -0400 To: IETF MARID WG X-Mailer: Apple Mail (2.613) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jun 16, 2004, at 1:19 PM, Greg Connor wrote: > > Here is my take on this. During the jabber session, Jim Lyon > expressed that it is important to him that MARID be a part of a larger > context, and that "email policy document" is something that the world > needs anyway. This sounds "nice" BUT I don't accept this as a > "requirement". And so this is the higher level question. Just how much extensibility do we need? -andy ps. thanks Greg. From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 14:16:09 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26008 for ; Wed, 16 Jun 2004 14:16:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GI1pRQ021693; Wed, 16 Jun 2004 11:01:51 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GI1pri021692; Wed, 16 Jun 2004 11:01:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GI1o5T021686 for ; Wed, 16 Jun 2004 11:01:50 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id BAE021A70D; Wed, 16 Jun 2004 20:01:52 +0200 (CEST) Received: from prosecco.oryx.com (unknown [217.19.171.140]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by bra.gulbrandsen.priv.no (Postfix) with ESMTP id 319C91A6F6; Wed, 16 Jun 2004 20:01:45 +0200 (CEST) Message-Id: <4lm/YdojNXkXSwJUjUdb1Q.md5@prosecco.oryx.com> From: Arnt Gulbrandsen To: Douglas Otis Subject: Re: Alternative to TXT or new RR Cc: "Eric A. Hall" , MARID References: <20040615223236.GA13225@dumbo.pobox.com> <1Fz8AGrZ9eBGLNyWqdk4Mg.md5@prosecco.oryx.com> <40D063F5.6030506@ehsco.com> <1087407560.32512.72.camel@ddev.mail-abuse.org> In-Reply-To: <1087407560.32512.72.camel@ddev.mail-abuse.org> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Wed, 16 Jun 2004 20:03:08 +0200 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Douglas Otis writes: > I doubt that such a mechanism would be able to block mail. The best > that could be expected would be to mark mail. (The open list issue.) Same as for SPF/CID, as far as I can tell. It all depends on which domain you choose to look up. The "_whatever." prefix doesn't matter, and neither does whether you interpret the resulting RRset yourself or perform an RPC. > The next problem would be DoS. Can this be done using UDP? Sure. You can DoS name servers easily, and you can DoS other UDP-using servers in exactly the same way(s). > As this gets implemented, will these systems see mail rejected because > their service approval service fails? They might, but since DNS is subject to the same attack, it should be no more and no less susceptible than SPF/CID. (DNS caches, but that doesn't mean anything for a DoS attack. The attacker will not want to cache.) Arnt From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 14:24:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26186 for ; Wed, 16 Jun 2004 14:24:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GIDb6V024192; Wed, 16 Jun 2004 11:13:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GIDbZs024191; Wed, 16 Jun 2004 11:13:37 -0700 (PDT) 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.9) with ESMTP id i5GIDZPd024184 for ; Wed, 16 Jun 2004 11:13:36 -0700 (PDT) (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.34) id 1Baeud-0000oA-O7 for ietf-mxcomp@imc.org; Wed, 16 Jun 2004 13:13:38 -0500 To: "IETF MARID WG" References: From: wayne Reply-To: "IETF MARID WG" Date: Wed, 16 Jun 2004 13:13:27 -0500 In-Reply-To: (Phillip Hallam-Baker's message of "Wed, 16 Jun 2004 09:47:03 -0700") 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 (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: Its the XML infoset that is key RE: Working toward unity on XML Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-4.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In "Hallam-Baker, Phillip" writes: > What we definitely should not do is try to predict the disposition of the > IESG through clairvoyance as some are suggesting. If the IESG want to make a > point to the group then they should send us an email. I do not accept the > claim that we should change course here and make decisions on what have been > flagged as showstopper issues by key stakeholders on the basis of reading > tea leaves. If this is a showstopper issue for the IESG then it is Ted's > responsibility to tell us. Who are these "key stakeholders" who have put a stake in the ground about requiring XML and won't budge? Is it the domain owners? Hmmm... no. The mail admins? No, they tend to be against XML. The MTA authors? Well, many are likely to be pragmatic and support XML, but that is far from flagging the removal of XML as a show stopper. So who is this Mysterious Stakeholder who seems to think it is important enough in the email world to have a Monopoly Situation? Is it right to let this Mysterious Stakeholder dictate its requirements for an engineering task force? What if stakeholders such as Equally Large, Another Outrageously Large, or Yet Another Huge Online Organization step forward with their own (conflicting) demands? Do we try to appease everyone? Will this Mysterious Stakeholder really refuse to support a MARID RFC if its demands are not met? Even when the US government (FTC) is considering email authentication requirements? I completely agree with Phill. Trying to use tea leaves to divine the position of the IESG is not reasonable, they should just openly tell us. On the other hand, I don't think it is productive to have vague references to a Mysterious Stakeholders who can veto the widespread adoption of a MARID RFC. I think it is time to call the Mysterious Stakeholder's bluff. Mysterious Stakeholder, please step forward and tell us: 1) When, if ever, you will release products that would support a MARID RFC if they include XML? 2) When, if ever, you will release products that would support a MARID RFC if they *do not* include XML? -wayne From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 14:40:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27025 for ; Wed, 16 Jun 2004 14:40:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GIPX7w026733; Wed, 16 Jun 2004 11:25:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GIPXv4026732; Wed, 16 Jun 2004 11:25:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GIPXjv026726 for ; Wed, 16 Jun 2004 11:25:33 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.131.244.249] ([::ffff:216.168.239.87]) (AUTH: LOGIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Wed, 16 Jun 2004 14:25:36 -0400 id 000E3E6D.40D090A0.0000472A In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF42A122@df-fido-msg.exchange.corp.microsoft.com> References: <81AC085044D04B429F5FB883D94FA1AF42A122@df-fido-msg.exchange.corp.microsoft.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8F37CC90-BFC2-11D8-B63F-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: "IETF-MXCOMP" From: Andrew Newton Subject: Re: On Extensibility in MARID Records Date: Wed, 16 Jun 2004 14:25:35 -0400 To: "Jim Lyon" X-Mailer: Apple Mail (2.613) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jun 16, 2004, at 12:37 PM, Jim Lyon wrote: > > Putting the two extensions together, we get > +a:zzz/feedback=monitor@ibm.com,ret=hdrs,type=bulk > > Now we're really pushing the limits. In the above example, "ret=hdrs" > modifies "feedback", which modifies the mechanism. But "type=bulk" > just > modifies the mechanism. So the above example has syntactic ambiguity > built in. We need a heavier structure to resolve the ambiguity: > brackets > or parentheses or tags or some such. We could get there with > parentheses by writing something like: My first stab is: +a:zzz/hdr-feedback-bulk=monitor@ibm.com or +a:zzz/feedback-policy="dns:feedback.ibm.com?class=TXT" -andy From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 14:41:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27115 for ; Wed, 16 Jun 2004 14:41:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GIYHNp028416; Wed, 16 Jun 2004 11:34:17 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GIYHxg028415; Wed, 16 Jun 2004 11:34:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from hoster907.com (ns1.hoster907.com [66.211.137.27]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5GIYGni028408 for ; Wed, 16 Jun 2004 11:34:17 -0700 (PDT) (envelope-from margaret@margaretolson.com) Received: (qmail 4938 invoked from network); 16 Jun 2004 18:35:24 -0000 X-Relay-Users: margaret.user X-Abuse: Send abuse reports to: abuse@suresupport.com Received: from unknown (HELO ?192.168.254.164?) (208.198.98.2) by ns1.hoster907.com with SMTP; 16 Jun 2004 18:35:24 -0000 In-Reply-To: References: <6968019.1087381179@Ryoga.corp.sgi.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: IETF MARID WG , Greg Connor From: Margaret Olson Subject: Re: Working toward unity on XML Date: Wed, 16 Jun 2004 14:34:15 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jun 16, 2004, at 2:05 PM, Andrew Newton wrote: > > > On Jun 16, 2004, at 1:19 PM, Greg Connor wrote: >> >> Here is my take on this. During the jabber session, Jim Lyon >> expressed that it is important to him that MARID be a part of a >> larger context, and that "email policy document" is something that >> the world needs anyway. This sounds "nice" BUT I don't accept this as >> a "requirement". > > And so this is the higher level question. Just how much extensibility > do we need? > We need to be able to extend the kinds of information conveyed in the authentication record, without restriction; authentication is part of a larger solution space which is currently poorly understood. Jim Lyons provided some good examples. We do not need to be able to change the result of the authentication test. From my point of view, backwards compatibility with SPF syntax with all extensions in XML is a perfectly reasonable compromise: it provides backwards compatibility for people who have already published and it provides the level of extensibility we need without inventing a new extensible language. Is it really unreasonable to expect the IESG to understand this argument? Surely this kind of compromise is common in engineering practical, deployable solutions. Margaret. From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 14:44:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27256 for ; Wed, 16 Jun 2004 14:44:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GIYarl028477; Wed, 16 Jun 2004 11:34:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GIYaxI028476; Wed, 16 Jun 2004 11:34:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.michaelbrumm.com (h-68-167-225-114.phndaz91.covad.net [68.167.225.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GIYYcg028450 for ; Wed, 16 Jun 2004 11:34:34 -0700 (PDT) (envelope-from me@michaelbrumm.com) Received: from devon ([68.167.225.115]) by mail.michaelbrumm.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 16 Jun 2004 18:34:35 +0000 From: "Michael R. Brumm" To: "IETF MARID WG" Subject: RE: On Extensibility in MARID Records Date: Wed, 16 Jun 2004 12:34:44 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF42A122@df-fido-msg.exchange.corp.microsoft.com> Importance: Normal X-OriginalArrivalTime: 16 Jun 2004 18:34:35.0780 (UTC) FILETIME=[93007440:01C453D0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5GIYZcg028470 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Jim Lyon wrote: >I've been asked to defend the proposition that MARID records need more >extensibility than can be easily afforded by SPF syntax. Well, it has been argued (successfully, IMHO) many times that the architectural advantage of SPF's non-extensible syntax is one of its best attributes. By freezing the feature-set, SPF is more stable, easier to understand and implement, and more uniformly practiced. Less ambiguity provides the authors of SPF records a larger degree of assurance that their records will be parsed correctly. Frozen syntax and semantics make MTA implementations easier to write and debug, and more likely to evaluate the records uniformly. A hidden problem with extensibility is the fact that non-uniform practices can emerge with multiple competing mechanisms fighting for dominance (imagine browser on SMTP). With a frozen spec, things are a lot more predictable because new mechanisms are thoroughly debated and vetted before being released uniformly as a new version. In general, extensibility is not a benefit to MARID. Michael R. Brumm From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 15:08:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01226 for ; Wed, 16 Jun 2004 15:08:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GInX7T031834; Wed, 16 Jun 2004 11:49:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GInXUB031833; Wed, 16 Jun 2004 11:49:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from goose.ehsco.com (goose.ehsco.com [207.65.203.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GInW7O031827 for ; Wed, 16 Jun 2004 11:49:32 -0700 (PDT) (envelope-from ehall@ehsco.com) Received: from ehsco.com (ferret.corp.ntrg.com [207.65.71.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Eric A. Hall", Issuer "Network Technology Research Group Certificate Authority" (verified OK)) by goose.ehsco.com (Postfix ) with ESMTP id 2AF4E5FA42 for ; Wed, 16 Jun 2004 13:49:36 -0500 (CDT) Message-ID: <40D09621.8030307@ehsco.com> Date: Wed, 16 Jun 2004 13:49:05 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-mxcomp@imc.org Subject: Re: Alternative to TXT or new RR References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/16/2004 10:55 AM, Jon Kyme wrote: > duple (and anything else?) to some service providing reputation and/or > authorisation. Well, actually, here MARID is reduced to (at most) a way > of discovering the service. > > All very interesting - in scope? I dunno. http://www.ietf.org/html.charters/marid-charter.html | It would be useful for those maintaining domains and networks to be | able to specify that individual hosts or nodes are authorized to act | as MTAs for messages sent from those domains or networks. This | working group will develop a DNS-based mechanism for storing and | distributing information associated with that authorization. ^^^^^^^^^^^^^^^ Charter does not say that scope is specifically associated with the explicit authorization data itself. Nor does it say that all processing must be receiver-side. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 15:12:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02394 for ; Wed, 16 Jun 2004 15:12:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GIxDtw033759; Wed, 16 Jun 2004 11:59:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GIxDFQ033758; Wed, 16 Jun 2004 11:59:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.michaelbrumm.com (h-68-167-225-114.phndaz91.covad.net [68.167.225.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GIxCME033729 for ; Wed, 16 Jun 2004 11:59:13 -0700 (PDT) (envelope-from me@michaelbrumm.com) Received: from devon ([68.167.225.115]) by mail.michaelbrumm.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 16 Jun 2004 18:59:11 +0000 From: "Michael R. Brumm" To: "IETF MARID WG" Subject: RE: XML exploits Date: Wed, 16 Jun 2004 12:59:22 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: Importance: Normal X-OriginalArrivalTime: 16 Jun 2004 18:59:11.0914 (UTC) FILETIME=[02D8A0A0:01C453D4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5GIxDME033753 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Marshall Rose wrote: >it isn't clear to me that the particular exploits you mention are >xml-specific or specific to a particular implementation. > >i think that a carefully written implementation of an xml-parser is >likely to be resilient to all kinds of malicious nonsense; similarly, i >think that an implementation that isn't carefully written can have >problems. > >i think i can > > s/xml/current spf syntax/g >however, the assumption is flawed because while theorists may be >interested in provably perfect systems, experienced practitioners are >not. The debating technique of turning the opposition's statement into an absurd absolute can be found in the book "Dilbert and the Way of the Weasel". A good read (and no, I'm not implying anyone here is a weasel). The argument was never this absurd absolute: XML-syntax has exploits, SPF-syntax can never have exploits. Therefore, we should use SPF because we want a perfect system. It was: XML-syntax, because it is more complicated, is more likely to have exploits. Several XML exploits are already known on multiple platforms. SPF-syntax is much, much simpler, and thus is less likely to have exploits. Therefore, SPF is preferable because we want a system which is less likely to have exploits. Michael R. Brumm From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 15:14:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03194 for ; Wed, 16 Jun 2004 15:14:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GItlCt033128; Wed, 16 Jun 2004 11:55:47 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GItlA3033127; Wed, 16 Jun 2004 11:55:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from goose.ehsco.com (goose.ehsco.com [207.65.203.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GItl5B033118 for ; Wed, 16 Jun 2004 11:55:47 -0700 (PDT) (envelope-from ehall@ehsco.com) Received: from ehsco.com (ferret.corp.ntrg.com [207.65.71.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Eric A. Hall", Issuer "Network Technology Research Group Certificate Authority" (verified OK)) by goose.ehsco.com (Postfix ) with ESMTP id 138557655; Wed, 16 Jun 2004 13:55:49 -0500 (CDT) Message-ID: <40D09796.6090404@ehsco.com> Date: Wed, 16 Jun 2004 13:55:18 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Douglas Otis Cc: Arnt Gulbrandsen , MARID Subject: Re: Alternative to TXT or new RR References: <20040615223236.GA13225@dumbo.pobox.com> <1Fz8AGrZ9eBGLNyWqdk4Mg.md5@prosecco.oryx.com> <40D063F5.6030506@ehsco.com> <1087407560.32512.72.camel@ddev.mail-abuse.org> In-Reply-To: <1087407560.32512.72.camel@ddev.mail-abuse.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/16/2004 12:39 PM, Douglas Otis wrote: > Blocking mail would be bad as static information is not comprehensive > nor would tracking all possible avenues be practical to administer. I think that is a per-domain judgement call. I only send mail through my mail server, so for me: C: MAIL-FROM: ; SERVER-IP: 207.65.203.98 S: OK and all other combinations are NO. Other domains may want to return UNKNOWN as a default case. Anyway, as with SPF, the only really useful receiver-side response is NO, UNKNOWN is meaningless and anybody can return a YES. > There could be a system for those "off the reservation" to mail this > "domain of record" a notice to accept mail sent from their current > location, if it contained a valid signature perhaps. This could be > treated like a cache where this information would expire after so many > days. Receiver-side caching is part of the problem IMO. I mean, folks are shying away from disk-based caching because they don't want to tell people that 500 mb of disk space is going to be needed, but are happy to push it to DNS where that 500 mb of RAM is out-of-sight, out-of-mind, and thus ok. > The next problem would be DoS. Can this be done using UDP? DoS is a fact of life for every service. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 15:14:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03220 for ; Wed, 16 Jun 2004 15:14:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GJ2pCE034546; Wed, 16 Jun 2004 12:02:51 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GJ2p5d034545; Wed, 16 Jun 2004 12:02:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GJ2pLf034539 for ; Wed, 16 Jun 2004 12:02:51 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.131.244.249] ([::ffff:216.168.239.87]) (AUTH: LOGIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Wed, 16 Jun 2004 15:02:55 -0400 id 000E3E6D.40D0995F.00004A4A Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: On Extensibility in MARID Records Date: Wed, 16 Jun 2004 15:02:54 -0400 To: IETF MARID WG X-Mailer: Apple Mail (2.613) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I would appreciate it if this thread were dedicated to the technical discussion of the variability of SPF vs. XML, as Jim is trying to show. If you have comments about the need or requirement for extensibility, then please use another thread (preferably the one Greg started on XML unity). This does not mean your opinion is invalid. I would just like these threads separated so people can track them more easily. -andy From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 15:27:28 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27026 for ; Wed, 16 Jun 2004 14:40:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GIWZV8028095; Wed, 16 Jun 2004 11:32:35 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GIWZEw028094; Wed, 16 Jun 2004 11:32:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ernie.mail-abuse.org (Ernie.mail-abuse.org [168.61.5.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GIWZIZ028069 for ; Wed, 16 Jun 2004 11:32:35 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.mail-abuse.org (DDev.mail-abuse.org [168.61.10.124]) by ernie.mail-abuse.org (8.12.0.Beta19/8.12.0) with ESMTP id i5GIWSPQ057981; Wed, 16 Jun 2004 11:32:28 -0700 (PDT) Subject: Re: On Extensibility in MARID Records From: Douglas Otis To: Jim Lyon Cc: IETF-MXCOMP In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF42A122@df-fido-msg.exchange.corp.microsoft.com> References: <81AC085044D04B429F5FB883D94FA1AF42A122@df-fido-msg.exchange.corp.microsoft.com> Content-Type: text/plain Message-Id: <1087410748.32512.119.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 16 Jun 2004 11:32:28 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-06-16 at 09:37, Jim Lyon wrote: > I've been asked to defend the proposition that MARID records need more > extensibility than can be easily afforded by SPF syntax. This thread > is an attempt to do so, using two possible extensions. To paraphrase > Mark Twain, I apologize for writing such a long email -- I didn't have > time to write a short one. > > To set the stage, let's consider Rich Segal's comments at the interim > meeting. He says IBM will publish a record something like: > > v=spf1 +a:xxx +a:yyy +a:zzz -exists:%{i}.rbl.com ?all > This says that if a message comes from one of the servers he knows > about, it's good. If a message comes from a blacklisted address, it's > bad. Otherwise, he's not sure. > > Now, he would like to be able to change the final "?all" to "-all", > but he's not sure he's found all of the servers that send mail on > IBM's behalf. Therefore, he needs feedback about mail that matches > the "?all" so that he can refine his list. At first blush, he could > say something like: > > v=spf1 +a:xxx +a:yyy +a:zzz -exists:%{i}.rbl.com ?all > feedback=feedback@ibm.com > > But that begs the question of what feedback he wants. In order to get > feedback on mail that matches the "?all", the "feedback=" needs to > bind to the "?all". So, we could invent syntax like: > > v=spf1 +a:xxx +a:yyy +a:zzz -exists:%{i}.rbl.com > ?all/feedback=feedback@ibm.com > (note the slash). This would be a step forward. It's also possible > that their legal people would like feedback about mail that matches > the "-exists", so that they can sue the offenders. So maybe their > record ends up looking like: > > v=spf1 +a:xxx +a:yyy +a:zzz > -exists:%{i}.rbl.com/feedback=abuse@ibm.com > ?all/feedback=feedback@ibm.com > > Now, for purposes of refining their "?all", they may only want headers > of messages that match, but for prosecuting abusers, they may need the > entire message. So they might want to publish something like: > > v=spf1 +a:xxx +a:yyy +a:zzz > -exists:%{i}.rbl.com/feedback=abuse@ibm.com,ret=full > ?all/feedback=feedback@ibm.com,ret=hdrs > > Now, IBM may very well want to monitor the activity of the third party > they contract with that uses address zzz, so that mechanism might look > like > > +a:zzz/feedback=monitor@ibm.com,ret=hdrs > > All of the above has had to do with a hypothetical "feedback" > extension, with various parameters. It's also possible that there > will be extensions that classify the mail coming from various > sources. For example, if the address range +a:zzz is used by IBM for > sending bulk mail, the mechanism may want to say > > +a:zzz/type=bulk > > Putting the two extensions together, we get > +a:zzz/feedback=monitor@ibm.com,ret=hdrs,type=bulk > > Now we're really pushing the limits. In the above example, "ret=hdrs" > modifies "feedback", which modifies the mechanism. But "type=bulk" > just modifies the mechanism. So the above example has syntactic > ambiguity built in. We need a heavier structure to resolve the > ambiguity: brackets or parentheses or tags or some such. We could get > there with parentheses by writing something like: > > +a:zzz(feedback:monitor@ibm.com(ret=hdrs))(type=bulk) > > But now we've already left the realm of a simple regex parser -- the > possibility of nesting implies at least a push-down parser. If we > ever expect to be able to extend SPF records, we need to define the > extensible syntax now. (Not the details of "feedback" or "type", but > the syntax for telling where each extension starts and ends). That > syntax needs to account for special characters, like email addresses > that contain an "=" or ":". Processors that we deploy today need to > be able to parse (and discard) this stuff, even though things like the > "feedback" extension may not be defined for another year or two. By > the time we've got enough extensibility, the complexity of a > conforming parser approaches that of XML. > > > XML is rich enough to handle all of the above. The spec is well > debugged. XML Schemas include a mechanism for defining what's legal > in a document, even if part of what's legal is tags that haven't been > defined yet. There are dozens of extant parsers -- for Linux, for > Unix, for Windows, for S/390. Written in C, C++, Java, Perl, Python, > C# and probably even Intercal. > > So, XML fits the requirements that I've outlined above, and it's the > only thing that I know of that does. Of course, it would be possible > to design an SPF-like language that meets these, but "possible" isn't > enough. It hasn't been done, and I doubt that we would get it right > on the first try if we did attempt it. Just as XML is extensible, it could be done in a manner that requires cooperation of the standards process before such changes are possible. Lock down what is contained in a related RR by making headers virtual and standalone and bar additional definitions. Change the possible content by changing the version declaration to reference a new and expanded virtual header. Adding features that "might" be useful is emblematic of "everything including the kitchen sink" that seems to prevail when text and XML is considered. DNS is not an http server. It seems to be a wild claim an organization or ISP will be able to define in this single record all possible avenues employed by their users. The most an open list provides is a check mark added next to the mail subject line. Can these extra functions be done using other methods? Claiming records may be chained or some may use TCP does not help. If such innovation can not be confined to a simple expression with constrained results, then add a single _mail-vouch._tcp.my-domain SRV record and point to a real http server where the SRV record also declares the port to be used. Now all things web-like become possible. Use dynamic techniques to allow users to add or subtract from their list automatically. With this done, it will not cause great concern for the health and function of DNS or MAIL. This can happen at the MUA where it can scale and perhaps even cache much of the information as much of this will likely be repetitive at the user level. A mail marking scheme does not improve the basic mail infrastructure to be worth considering at the MTA level. -Doug From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 16:06:05 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12445 for ; Wed, 16 Jun 2004 16:06:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GJt10a046572; Wed, 16 Jun 2004 12:55:01 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GJt1Fc046571; Wed, 16 Jun 2004 12:55:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ernie.mail-abuse.org (Ernie.mail-abuse.org [168.61.5.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GJsuGX046553 for ; Wed, 16 Jun 2004 12:54:56 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.mail-abuse.org (DDev.mail-abuse.org [168.61.10.124]) by ernie.mail-abuse.org (8.12.0.Beta19/8.12.0) with ESMTP id i5GJskPQ059851; Wed, 16 Jun 2004 12:54:46 -0700 (PDT) Subject: Re: Alternative to TXT or new RR From: Douglas Otis To: "Eric A. Hall" Cc: Arnt Gulbrandsen , MARID In-Reply-To: <40D09796.6090404@ehsco.com> References: <20040615223236.GA13225@dumbo.pobox.com> <1Fz8AGrZ9eBGLNyWqdk4Mg.md5@prosecco.oryx.com> <40D063F5.6030506@ehsco.com> <1087407560.32512.72.camel@ddev.mail-abuse.org> <40D09796.6090404@ehsco.com> Content-Type: text/plain Message-Id: <1087415686.32512.177.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 16 Jun 2004 12:54:46 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-06-16 at 11:55, Eric A. Hall wrote: > On 6/16/2004 12:39 PM, Douglas Otis wrote: > > > Blocking mail would be bad as static information is not comprehensive > > nor would tracking all possible avenues be practical to administer. > > I think that is a per-domain judgement call. I only send mail through my > mail server, so for me: > > C: MAIL-FROM: ; SERVER-IP: 207.65.203.98 > S: OK > > and all other combinations are NO. If you are the only one using the domain, then it could be possible to list all servers you "think" you are using. In doing so, you may discover SMTP has been intercepted and will then need to list machines your provider use. The policy for these machines will likely not check for your oddly closed record as being impractical on a message basis and often without benefit with most lists being declared open. This means if you take the step to include these machines in your record, as must be done in a closed list, then anyone using this information would know how to forge your mail. : ( > Other domains may want to return UNKNOWN as a default case. Other domains would not be queried except when you reference your provider. To keep their clients from having mail lost, their lists would be open, so then it really does not matter where the mail comes from, nor what the headers contain. The mail may not get a check mark, but could, if it was also directed through these machines. A mark that should not be trusted. : ( > Anyway, as with SPF, the only really useful receiver-side response is NO, > UNKNOWN is meaningless and anybody can return a YES. For a large system, the result will likely be Perhaps or Unknown. > > There could be a system for those "off the reservation" to mail this > > "domain of record" a notice to accept mail sent from their current > > location, if it contained a valid signature perhaps. This could be > > treated like a cache where this information would expire after so many > > days. > > Receiver-side caching is part of the problem IMO. I mean, folks are shying > away from disk-based caching because they don't want to tell people that > 500 mb of disk space is going to be needed, but are happy to push it to > DNS where that 500 mb of RAM is out-of-sight, out-of-mind, and thus ok. I suspect this estimate to be high. Using a key method becomes practical once query constraints of DNS are removed. (out of scope for this wg) http://www.ietf.org/internet-drafts/draft-fenton-identified-mail-00.txt This draft suggests use of user keys. The size could be relatively small. Perfect for the MUA, much like browser cookies. > > The next problem would be DoS. Can this be done using UDP? > > DoS is a fact of life for every service. Except that this DoS could result without hostile intent, making spoofing even more painful that early adopters will need to endure. -Doug From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 16:15:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13543 for ; Wed, 16 Jun 2004 16:15:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GK7Cis049447; Wed, 16 Jun 2004 13:07:12 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GK7CfJ049446; Wed, 16 Jun 2004 13:07:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mailout.TechFak.Uni-Bielefeld.DE (mailout.TechFak.Uni-Bielefeld.DE [129.70.136.245]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GK7Avt049417 for ; Wed, 16 Jun 2004 13:07:11 -0700 (PDT) (envelope-from pk@TechFak.Uni-Bielefeld.DE) Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2004/05/05/sjaenick) with ESMTP id i5GK79qe026312 for ; Wed, 16 Jun 2004 22:07:09 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id i5GK78909760 for ; Wed, 16 Jun 2004 22:07:09 +0200 (MEST) Message-Id: <200406162007.i5GK78909760@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: IETF MARID WG Subject: Re: MTAmark (was: Reality check please) In-reply-to: Your message of "Fri, 11 Jun 2004 19:12:18 +0200." <20040611171218.GA32187@Space.Net> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <9757.1087416428.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Wed, 16 Jun 2004 22:07:08 +0200 From: Peter Koch Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Markus Stumpf wrote: > I am currently trying to contact people in DE. Peter Koch who is doing > the monthly DNS host count for DE domains is willing to add a check for > MX hosts and will provide information about the number of unique (based > on IP address) MX server used for DE domains. starting with 11291065 MX RRs coming out of this month's DE hostcount (see http://www.TechFak.Uni-Bielefeld.DE/~pk/dns/hostcount/latest.html or http://www.ripe.net/ripencc/pub-services/stats/hostcount/ for information on what it is and how it works), the individual MX targets were identified, bogus ones deleted and the remaining ones were fed a resolver to find the number of unique IP addresses: 11291065 MX RRs 7600000 ~ number of 2nd level DE domains 1058962 unique MX RR targets 1057546 valid MX RR targets (no '.', IP addresses, ...) 146224 unique IP addresses after resolving MX RR target names 144582 non-bogus IP adresses (ignoring RFC 1918 addresses, unallocated address space, multicast, ...) Some remarks: o Targets may reside both inside and outside DE. o Some larger address space holders ("class B", universities etc) tend to define MX RRs for almost all of their systems/addresses, sometimes including dialin lines etc. Since MX is inbound only this may have an adverse effect on the guesstimate for the proposal mentioned in the subject line. o The 144582 addresses belong to 26552 /24 address ranges. o Approx. 75% of the addresses identified do have a working reverse mapping (lead to one or more PTR RRs), the rest either yields NXDOMAIN or has resolving problems (timeout, SERVFAIL). For NXDOMAIN I didn't further differentiate 'not delegated' vs. 'not named in zone'. o Viewing /24 zones (and ignoring RFC 2317 for the sake of simplicity) 80% of the /24's covered by the IP addresses found do have a working reverse mapping. So, this is just the data, I'm taking no position whether or not these figures can be used to calculate/estimate the number or percentage of ``legitimate'' outbound SMTP clients. -Peter From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 16:15:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13571 for ; Wed, 16 Jun 2004 16:15:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GK7dYF049544; Wed, 16 Jun 2004 13:07:39 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GK7drc049542; Wed, 16 Jun 2004 13:07:39 -0700 (PDT) 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.9) with ESMTP id i5GK7cmk049519 for ; Wed, 16 Jun 2004 13:07:38 -0700 (PDT) (envelope-from cm--jrk@merseymail.com) Received: from mmail by argon.connect.org.uk with local (connectmail/exim) id 1Bagh9-0000WN-Gk; Wed, 16 Jun 2004 21:07:39 +0100 In-Reply-To: <40D09621.8030307@ehsco.com> Subject: Re: Alternative to TXT or new RR To: "Eric A. Hall" From: "Jon Kyme" Cc: ietf-mxcomp@imc.org X-Mailer: [ConnectMail 3.15.6] X-connectmail-Originating-IP: 82.69.7.27 Message-Id: Date: Wed, 16 Jun 2004 21:07:39 +0100 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > > duple (and anything else?) to some service providing reputation and/or > > authorisation. Well, actually, here MARID is reduced to (at most) a way > > of discovering the service. > > > > All very interesting - in scope? I dunno. > > http://www.ietf.org/html.charters/marid-charter.html > [snip] > | DNS-based mechanism for storing and > | distributing information associated with that authorization. > ^^^^^^^^^^^^^^^ > > Charter does not say that scope is specifically associated with the > explicit authorization data itself. > > Nor does it say that all processing must be receiver-side. No, you're quite right, but while a minimal MARID may still be in scope, "no MARID" probably isn't :-) Realistically, there are only 3 places that processing can take place, domain-owner (publisher), receiver, third party. Who should pay the processing penalty? Who gets the benefit? I suspect that the momentum is too much to do anything with the brakes in the time available. I wouldn't be surprised if work on reputation services brings us back this way. From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 16:16:41 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13615 for ; Wed, 16 Jun 2004 16:16:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GK7dos049543; Wed, 16 Jun 2004 13:07:39 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GK7dnk049541; Wed, 16 Jun 2004 13:07:39 -0700 (PDT) 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.9) with ESMTP id i5GK7c1t049518 for ; Wed, 16 Jun 2004 13:07:38 -0700 (PDT) (envelope-from cm--jrk@merseymail.com) Received: from mmail by argon.connect.org.uk with local (connectmail/exim) id 1Bagh9-0000WI-FT; Wed, 16 Jun 2004 21:07:39 +0100 In-Reply-To: <40D09621.8030307@ehsco.com> Subject: Re: Alternative to TXT or new RR To: "Eric A. Hall" From: "Jon Kyme" Cc: ietf-mxcomp@imc.org X-Mailer: [ConnectMail 3.15.6] X-connectmail-Originating-IP: 82.69.7.27 Message-Id: Date: Wed, 16 Jun 2004 21:07:39 +0100 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > > duple (and anything else?) to some service providing reputation and/or > > authorisation. Well, actually, here MARID is reduced to (at most) a way > > of discovering the service. > > > > All very interesting - in scope? I dunno. > > http://www.ietf.org/html.charters/marid-charter.html > [snip] > | DNS-based mechanism for storing and > | distributing information associated with that authorization. > ^^^^^^^^^^^^^^^ > > Charter does not say that scope is specifically associated with the > explicit authorization data itself. > > Nor does it say that all processing must be receiver-side. No, you're quite right, but while a minimal MARID may still be in scope, "no MARID" probably isn't :-) Realistically, there are only 3 places that processing can take place, domain-owner (publisher), receiver, third party. Who should pay the processing penalty? Who gets the benefit? I suspect that the momentum is too much to do anything with the brakes in the time available. I wouldn't be surprised if work on reputation services brings us back this way. From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 16:26:03 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13962 for ; Wed, 16 Jun 2004 16:26:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GKFJbE050999; Wed, 16 Jun 2004 13:15:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GKFJ5s050998; Wed, 16 Jun 2004 13:15:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GKFIAh050990 for ; Wed, 16 Jun 2004 13:15:19 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id 285E51A719; Wed, 16 Jun 2004 22:15:20 +0200 (CEST) Received: from prosecco.oryx.com (unknown [217.19.171.140]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by bra.gulbrandsen.priv.no (Postfix) with ESMTP id 4FC8A1A69D; Wed, 16 Jun 2004 22:15:13 +0200 (CEST) Message-Id: From: Arnt Gulbrandsen To: Douglas Otis Subject: Re: Alternative to TXT or new RR Cc: "Eric A. Hall" , MARID References: <20040615223236.GA13225@dumbo.pobox.com> <1Fz8AGrZ9eBGLNyWqdk4Mg.md5@prosecco.oryx.com> <40D063F5.6030506@ehsco.com> <1087407560.32512.72.camel@ddev.mail-abuse.org> <40D09796.6090404@ehsco.com> <1087415686.32512.177.camel@ddev.mail-abuse.org> In-Reply-To: <1087415686.32512.177.camel@ddev.mail-abuse.org> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Wed, 16 Jun 2004 22:16:36 +0200 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: You know, if can give the receiver an SPF record to interpret, you can interpret that same data yourself. Therefore, RPC-to-publisher is at least as capable as SPF-like schemes. And it's more powerful. For example, it's easy to tell receivers "no" if the localpart's not an allowed sender. The IBM situation described in a different thread seems easy to handle, too. Arnt From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 16:34:41 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14545 for ; Wed, 16 Jun 2004 16:34:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GKPHep053105; Wed, 16 Jun 2004 13:25:17 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GKPH0Z053104; Wed, 16 Jun 2004 13:25:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GKPG1n053098 for ; Wed, 16 Jun 2004 13:25:16 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 16 Jun 2004 13:25:20 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 16 Jun 2004 13:25:21 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 16 Jun 2004 13:25:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Alternative to TXT or new RR Date: Wed, 16 Jun 2004 13:24:58 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF42A212@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: Alternative to TXT or new RR thread-index: AcRT344OgdN18KOTTPGbHWCujPapiAAACapw From: "Jim Lyon" To: "MARID" X-OriginalArrivalTime: 16 Jun 2004 20:25:20.0450 (UTC) FILETIME=[0B88A220:01C453E0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5GKPG1n053099 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > Therefore, RPC-to-publisher is at least as capable as SPF-like schemes. There are a lot of small domains out there. I believe that we can get many of them to take 5 minutes to add a DNS record. But getting them to install new software, and configure a new web service, is way past the ability of many of them. -- Jim Lyon From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 16:35:03 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14616 for ; Wed, 16 Jun 2004 16:35:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GKORRI052940; Wed, 16 Jun 2004 13:24:27 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GKORDe052939; Wed, 16 Jun 2004 13:24:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GKOQMA052919 for ; Wed, 16 Jun 2004 13:24:26 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id DD9DA1A719; Wed, 16 Jun 2004 22:24:28 +0200 (CEST) Received: from prosecco.oryx.com (unknown [217.19.171.140]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by bra.gulbrandsen.priv.no (Postfix) with ESMTP id ECAEA1A6C2; Wed, 16 Jun 2004 22:24:21 +0200 (CEST) Message-Id: From: Arnt Gulbrandsen To: Jon Kyme Subject: Re: Alternative to TXT or new RR Cc: "Eric A. Hall" , ietf-mxcomp@imc.org References: In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Wed, 16 Jun 2004 22:25:45 +0200 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Kyme writes: > Realistically, there are only 3 places that processing can take place, > domain-owner (publisher), receiver, third party. Who should pay the > processing penalty? Who gets the benefit? The domain owner gets the benefit, namely, less forged mail. (For the recipient, the biggest change is that the ever-increasing spam avalanche uses a different algorithm to pick its "from" algorithms, avoiding ones that are hard to forge.) Arnt From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 16:55:01 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15786 for ; Wed, 16 Jun 2004 16:55:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GKkQMh058013; Wed, 16 Jun 2004 13:46:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GKkQSi058012; Wed, 16 Jun 2004 13:46:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GKkNvM057982 for ; Wed, 16 Jun 2004 13:46:26 -0700 (PDT) (envelope-from aland@newgiles.nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id C90D516FAB for ; Wed, 16 Jun 2004 16:52:45 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Alternative to TXT or new RR In-Reply-To: Your message of "Wed, 16 Jun 2004 22:16:36 +0200." Date: Wed, 16 Jun 2004 16:52:45 -0400 Message-Id: <20040616205245.C90D516FAB@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Arnt Gulbrandsen wrote: > You know, if can give the receiver an SPF record to interpret, you can > interpret that same data yourself. Therefore, RPC-to-publisher is at > least as capable as SPF-like schemes. And more expensive for the publisher. It's cheap for the publisher to drop semi-static data into a packet, and have the recipient do validation. Having the publisher do the validation leads to a DoS. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 17:58:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20583 for ; Wed, 16 Jun 2004 17:58:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GLk3NJ067485; Wed, 16 Jun 2004 14:46:03 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GLk3X7067484; Wed, 16 Jun 2004 14:46:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GLk33c067478 for ; Wed, 16 Jun 2004 14:46:03 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 16 Jun 2004 14:46:07 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 16 Jun 2004 14:46:07 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 16 Jun 2004 14:46:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: On Extensibility in MARID Records Date: Wed, 16 Jun 2004 14:46:09 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF42A291@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: On Extensibility in MARID Records thread-index: AcRTz1vGeIG3QyedSJ+7MCv9CZjV8QAFrHRQ From: "Jim Lyon" To: "Andrew Newton" Cc: "IETF-MXCOMP" X-OriginalArrivalTime: 16 Jun 2004 21:46:07.0544 (UTC) FILETIME=[54A07B80:01C453EB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5GLk33c067479 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Andy takes a stab at asserting that SPFish syntax is enough, writing: > My first stab is: > +a:zzz/hdr-feedback-bulk=monitor@ibm.com > or > +a:zzz/feedback-policy="dns:feedback.ibm.com?class=TXT" Of course, there are problems here. In his first try, he says (by example) that you concatenate the various modifiers together, separated by "-". But the limits are immediately apparent: The "=monitor@ibm.com" really modifies "feedback", but is stuck after "bulk" which is unrelated to "feedback". Furthermore, someone pointed out that we'd never really want to receive a reply message for *every* matching message. So a publisher would probably also need to stick a "p=.001" (send feedback with probability 1 in 1000) somewhere in there, and it's not obvious where. Andy's fist example stops well short of showing that it's easy to extend SPF syntax to get there. His second example might be somewhat more promising. I assume that it means "go resolve the URL "dns:feedback.ibm.com?class=TXT", and you'll find something that gives the feedback policy. Of course, it immediately begs the question of which URL schemes are allowed (dns? http? gopher? ftp? mailto?) and what the format and language of the fetched document is (XML? something else? TBD?) To add more fuel to the fire of how hard it is to design a new language with extensibility, nobody has yet noticed that Andy's examples, as well as all of mine, are bogus: SPF already reserves the '/' character for other purposes. -- Jim Lyon From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 18:09:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22333 for ; Wed, 16 Jun 2004 18:09:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GLXpEo065949; Wed, 16 Jun 2004 14:33:51 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GLXpFa065948; Wed, 16 Jun 2004 14:33:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from goose.ehsco.com (goose.ehsco.com [207.65.203.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GLXorl065941 for ; Wed, 16 Jun 2004 14:33:50 -0700 (PDT) (envelope-from ehall@ehsco.com) Received: from ehsco.com (ferret.corp.ntrg.com [207.65.71.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Eric A. Hall", Issuer "Network Technology Research Group Certificate Authority" (verified OK)) by goose.ehsco.com (Postfix ) with ESMTP id CC5485FA86 for ; Wed, 16 Jun 2004 16:33:54 -0500 (CDT) Message-ID: <40D0BCA6.5050107@ehsco.com> Date: Wed, 16 Jun 2004 16:33:26 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MARID Subject: Re: Alternative to TXT or new RR References: <81AC085044D04B429F5FB883D94FA1AF42A212@df-fido-msg.exchange.corp.microsoft.com> In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF42A212@df-fido-msg.exchange.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/16/2004 3:24 PM, Jim Lyon wrote: >>Therefore, RPC-to-publisher is at least as capable as SPF-like >> schemes. > There are a lot of small domains out there. I believe that we can get > many of them to take 5 minutes to add a DNS record. But getting them to > install new software, and configure a new web service, is way past the > ability of many of them. They wouldn't be enforcing a reciever-side enforcement system either. If they don't think that forgery is enough of a problem for them to bother enforcing, then they've abstained. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 18:17:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23827 for ; Wed, 16 Jun 2004 18:17:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GM3dsX069800; Wed, 16 Jun 2004 15:03:39 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GM3dLw069799; Wed, 16 Jun 2004 15:03:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from polis.nbtsc.org (polis.nbtsc.org [206.168.119.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GM3cUK069793 for ; Wed, 16 Jun 2004 15:03:38 -0700 (PDT) (envelope-from aredridel@nbtsc.org) Received: from betelgeuse.theinternetco.net ([206.168.119.12]) by polis.nbtsc.org with asmtp (Exim 4.34) id 1BaiVT-0007PQ-FO for ietf-mxcomp@imc.org; Wed, 16 Jun 2004 16:03:43 -0600 Subject: RE: Alternative to TXT or new RR From: Aredridel To: ietf-mxcomp@imc.org In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF42A212@df-fido-msg.exchange.corp.microsoft.com> References: <81AC085044D04B429F5FB883D94FA1AF42A212@df-fido-msg.exchange.corp.microsoft.com> Content-Type: text/plain Date: Wed, 16 Jun 2004 16:03:42 -0600 Message-Id: <1087423422.6182.1.camel@betelgeuse.theinternetco.net> Mime-Version: 1.0 X-Mailer: Evolution 1.5.9.1 Content-Transfer-Encoding: 7bit X-Scan-Signature: bad3feba76987eff44d9b8a458412ecc Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-06-16 at 13:24 -0700, Jim Lyon wrote: > > Therefore, RPC-to-publisher is at least as capable as SPF-like > schemes. > There are a lot of small domains out there. I believe that we can get > many of them to take 5 minutes to add a DNS record. But getting them to > install new software, and configure a new web service, is way past the > ability of many of them. Absolutely. Rolling out SPF records took me all of forty minutes -- for the several hundred domains I host. That included testing. I couldn't get a new service up that quickly. Ari From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 18:18:29 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23986 for ; Wed, 16 Jun 2004 18:18:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GM0tBM069282; Wed, 16 Jun 2004 15:00:55 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GM0tNu069281; Wed, 16 Jun 2004 15:00:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GM0tBq069275 for ; Wed, 16 Jun 2004 15:00:55 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 16 Jun 2004 15:01:00 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 16 Jun 2004 15:00:59 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 16 Jun 2004 15:00:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Alternative to TXT or new RR Date: Wed, 16 Jun 2004 15:01:02 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF42A2AD@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: Alternative to TXT or new RR thread-index: AcRT7IJ+kda7ubXhRWOEpGdXn2trEAAAGP9w From: "Jim Lyon" To: "MARID" X-OriginalArrivalTime: 16 Jun 2004 22:00:59.0647 (UTC) FILETIME=[685C98F0:01C453ED] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5GM0tBq069276 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Regarding publishing via web services, Eric A. Hall says > [if a domain doesn't install new software,] they wouldn't be enforcing a > reciever-side enforcement system either. If they don't think that forgery > is enough of a problem for them to bother enforcing, then they've abstained. You're confusing the *publish* decision with the *check* decision -- it's perfectly reasonable to make them separately. We want to make it dirt easy for a domain to publish, because that increases the value of every one else's checking. It would be a grave mistake to tell people they can't publish without running a web server and installing new web service software. -- Jim Lyon From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 18:19:52 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24198 for ; Wed, 16 Jun 2004 18:19:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GM4wdB070084; Wed, 16 Jun 2004 15:04:58 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GM4wt6070083; Wed, 16 Jun 2004 15:04:58 -0700 (PDT) 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.9) with ESMTP id i5GM4vka070071 for ; Wed, 16 Jun 2004 15:04:57 -0700 (PDT) (envelope-from cm--jrk@merseymail.com) Received: from mmail by argon.connect.org.uk with local (connectmail/exim) id 1BaiWh-0007sQ-H6; Wed, 16 Jun 2004 23:04:59 +0100 In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF42A212@df-fido-msg.exchange.corp.microsoft.com> Subject: RE: Alternative to TXT or new RR To: "Jim Lyon" From: "Jon Kyme" Cc: ietf-mxcomp@imc.org X-Mailer: [ConnectMail 3.15.6] X-connectmail-Originating-IP: 82.69.7.27 Message-Id: Date: Wed, 16 Jun 2004 23:04:59 +0100 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > > Therefore, RPC-to-publisher is at least as capable as SPF-like > schemes. > There are a lot of small domains out there. I believe that we can get > many of them to take 5 minutes to add a DNS record. But getting them to > install new software, and configure a new web service, is way past the > ability of many of them. > Then they'd need to rely on the services of a third party (which is what might happen with reputation services anyway), or not benefit. So this isn't, on the face of it, a meaningful objection. From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 19:16:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29444 for ; Wed, 16 Jun 2004 19:16:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GMxfcg081164; Wed, 16 Jun 2004 15:59:41 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GMxfEX081162; Wed, 16 Jun 2004 15:59:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from miz-mishtal.dbc.mtview.ca.us (adsl-64-168-10-250.dsl.scrm01.pacbell.net [64.168.10.250]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GMxfXK081150 for ; Wed, 16 Jun 2004 15:59:41 -0700 (PDT) (envelope-from mrose@dbc.mtview.ca.us) Received: from [IPv6:::1] (localhost [127.0.0.1]) by miz-mishtal.dbc.mtview.ca.us (8.12.10/8.12.9) with ESMTP id i5GMsMqt003688; Wed, 16 Jun 2004 15:54:22 -0700 (PDT) In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF42A291@df-fido-msg.exchange.corp.microsoft.com> References: <81AC085044D04B429F5FB883D94FA1AF42A291@df-fido-msg.exchange.corp.microsoft.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1CD00592-BFE8-11D8-BD27-000A95CA7FAE@dbc.mtview.ca.us> Content-Transfer-Encoding: 7bit Cc: Andrew Newton , Ted Hardie From: Marshall Rose Subject: Drive Towards Consensus [was Re: On Extensibility in MARID Records] Date: Wed, 16 Jun 2004 15:54:24 -0700 To: IETF MARID WG X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit the co-chairs think this is a useful thread; in fact, we're going to place the following plan in front of the working group: it is clear to the co-chairs that the "tipping point" with respect to the working group's deliberations revolve around the sufficiency of the SPF syntax to address near-term concerns. if the syntax is adequate, it is hard to argue for an alternative or future syntax; if the syntax is inadequate, then the SPF syntax is of transitory use. in order to drive consensus on this issue, the chairs put forth this plan: between now and sunday, june 20, 2004 23:59:59 us/pacific time, ALL replies to this message must give examples of scenarios for which the SPF syntax is insufficient. any requests for clarifications MUST be sent directly to the authors of a scenario, who may then post a clarification in reply to their own email. starting monday, june 21, 2004 00:00:00 us/pacific time, the working group may reply to any of these scenario messages for the purpose of explaining how the SPF syntax is sufficient. on thursday, june 24, 2004 23:59:59 us/pacific time, the chairs will gauge the group's consensus on the issue of the sufficiency of the SPF syntax. based on the chair's reading, the working group will be presented with a plan for moving forward within the timeframe allotted by the charter. so, to re-cap: 1. now until sunday evening: people post difficult examples 2. monday until thursday evening: people post explanations on dealing with the difficulty 3. friday: chairs announce plan for moving forward. /mtr From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 19:25:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00553 for ; Wed, 16 Jun 2004 19:25:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GNFJHJ084326; Wed, 16 Jun 2004 16:15:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GNFJc0084325; Wed, 16 Jun 2004 16:15:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [64.139.47.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GNFJBd084319 for ; Wed, 16 Jun 2004 16:15:19 -0700 (PDT) (envelope-from gconnor@nekodojo.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by neko-base.nekodojo.org (Postfix) with ESMTP id 3A1661D651 for ; Wed, 16 Jun 2004 16:15:24 -0700 (PDT) Date: Wed, 16 Jun 2004 16:15:25 -0700 From: Greg Connor To: IETF-MXCOMP Subject: Re: On Extensibility in MARID Records Message-ID: <28314183.1087402525@Ryoga.corp.sgi.com> In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF42A122@df-fido-msg.exchange.corp.microsoft.com> References: <81AC085044D04B429F5FB883D94FA1AF42A122@df-fido-msg.exchange.cor p.microsoft.com> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --Jim Lyon wrote: > > I've been asked to defend the proposition that MARID records need more > extensibility than can be easily afforded by SPF syntax. This thread is > an attempt to do so, using two possible extensions. > [example of wanting extra data to be attached to a mechanism] > > XML is rich enough to handle all of the above. The spec is well > debugged. OK, for expedience I will concede that XML is better suited to extending the data in various directions, like a tree. I guess I would like feedback from the group as to whether we see this particular type of extensibility as a "requirement", or whether there is feeling that name=value pairs placed inline is enough. Also, did you want to say a few words about other things that might go in _ep besides out nodes? Now would be a good time to bring that up too if so. I will leave it to the group at large to chime in as to whether the "multi-dimensional extensibility" requirement Jim stated is more important than size, overall simplicity, etc. -- Greg Connor From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 19:39:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01647 for ; Wed, 16 Jun 2004 19:39:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GNNr6t086157; Wed, 16 Jun 2004 16:23:53 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GNNrm1086156; Wed, 16 Jun 2004 16:23:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tidy.obscurity.org (tidy.obscurity.org [66.199.168.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GNNrvk086141 for ; Wed, 16 Jun 2004 16:23:53 -0700 (PDT) (envelope-from ksoze@obscurity.org) Received: by tidy.obscurity.org (Postfix, from userid 1000) id 5646F69B0F; Wed, 16 Jun 2004 23:23:51 +0000 (UTC) Date: Wed, 16 Jun 2004 16:23:51 -0700 From: Sean Comeau To: Greg Connor Cc: IETF MARID WG Subject: Re: Working toward unity on XML Message-ID: <20040616232351.GA30711@obscurity.org> References: <6968019.1087381179@Ryoga.corp.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6968019.1087381179@Ryoga.corp.sgi.com> User-Agent: Mutt/1.5.6i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I agree that supporting two syntaxes is the worst possible option. On Wed, Jun 16, 2004 at 10:19:39AM -0700, Greg Connor wrote: > 2. SPF classic syntax > > * Extensibility is a reasonable goal, but should not get in the way of > simplicity, human-readability, and byte-economy, which we see as more > important. > * We are not convinced of the need to bind MARID together with a larger > "email policy" document that is not yet defined. > * SPF classic is extensible by way of adding modifiers (e.g. > domainkeys=all) and by new version tags (e.g. v=spf1d). SPF records may > contain unknown mechanism (like +dk) but pre-existing implementations will > always stop and return "unknown" in that case. > * Support for those domains that have already published SPF is important. > So far I haven't heard any good feature suggestions that require complex, structured arguements. I fear that supporting XML will lead to more complex client implementations resulting in more bugs. Many will try to create extentions and interoperability will suffer. This would cause mail admins more problems than it solves. As a mail admin I don't want to worry about what other sites running this implementation or that will do with my record. They MUST all work exactly the same way. It has to be perfect, not sortof almost perfect like what we get with web browsers. I strongly believe that new features should be worked out by groups like this one rather than being added randomly by vendors. The fact that we must be more careful when adding features to SPF is a benefit not a problem. This protocol should do only one thing and do it well: stop header forgery. From most to least important: Simplicity, byte-economy, human-readability, extensibility. From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 19:50:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02125 for ; Wed, 16 Jun 2004 19:50:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GNgUuB090160; Wed, 16 Jun 2004 16:42:30 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GNgU4j090159; Wed, 16 Jun 2004 16:42:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ernie.mail-abuse.org (Ernie.mail-abuse.org [168.61.5.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GNgU1C090101 for ; Wed, 16 Jun 2004 16:42:30 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.mail-abuse.org (DDev.mail-abuse.org [168.61.10.124]) by ernie.mail-abuse.org (8.12.0.Beta19/8.12.0) with ESMTP id i5GNgUPQ064376 for ; Wed, 16 Jun 2004 16:42:30 -0700 (PDT) Subject: RE: rough consensus and working code From: Douglas Otis To: MARID Content-Type: text/plain Message-Id: <1087429350.32512.412.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 16 Jun 2004 16:42:30 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jun 15, 2004, at 13:26:41 -0400 Andrew Newton writes: > On Jun 15, 2004, at 13:02:04 -0500, wayne wrote: > > > I have to agree with this assessment. There doesn't appear to be a > > rough consensus. However, the long standing IETF mantra has, to the > > best of my knowledge, been "rough consensus *AND* working code". What > > we lack with most proposals is working code. > > I think implementations are a good thing, a very good thing. > > However, RFC 2026 mentions that to get a Proposed Standard RFC > implementations are not required (though they are encouraged). To get > a standard from Proposed Standard to Draft Standard, two separate > interoperating implementations are required. > > Our milestones explicitly says "PS" - for Proposed Standard. > > -andy There is a black-listing model currently excluding much of the abusive mail today. This "working code" has demonstrated an ability to scale. Transitioning this mechanism from using IP addresses to authorized and authenticated names would both exclude abusers, but would also identify organizations able resolve issues that lead to the introduction of abusive mail. Current IP-based blacklists _assign_ responsibility to whoever holds that IP address and typically there is no method to determine when this address transfers to a different entity or if the policy issues have been resolved. Problem hosts often share addresses or use dynamic address assignment, where then the blacklisted IP address won't curtail the problem until a large block of IP address space becomes blacklisted. Consequently, a lot of IP space is blacklisted long after the irresponsible entity has ceased holding it. Efforts to enhance and upgrade this system to utilize authorized and authenticated names would be carried forward by those providing named based (RHSBL) services with otherwise negligible changes to the current operation of mail. This authorization and authentication would also greatly improve the usability of private lists of known good domains such as bonded providers. It may well evolve, out of necessity of scale, policy becomes based on known good together with those recently considered and those pending consideration with each receiving differing treatment. Much of this abuse is not a result of most users. There are a few however that send large amounts using fraudulent means. The challenge is to stop these fraudulent means of access while leaving unharmed users that have not abused the system. This mechanism at the MTA channel has demonstrated an ability to scale and, importantly, this will limit access to the mail system from those not willing to identify their systems for evaluation and follow-up whether an accreditation service is consulted or not. As opposed to the investment needed for signed digital certificates and certificate authorities, a simple DNS record will substantially enable an economic means of authorization/authentication of the MTA using existing infrastructure and "working code" all perhaps with a single DNS query. Just verifying the MTA alone will satisfy most requirements for policy enforcement. If there is a problem with an individual, then through MTA authentication, officials will know what domain must be queried to follow-up on criminal actions. If an individual takes action to intentionally bypass the safeguards inherent in this system, that by itself gives authorities a basis for criminal investigation. If the same individual refuses to cooperate with the investigation, that's likely to be grounds for prosecution. Without such a basis, legal remedies aren't likely to be effective at controlling abusive mail. The Security Consideration section of RFC2821 makes it clear where efforts should be placed to improve mail. Name authorization and Authentication for the MTA as advocated in CSV-HNA-CSA used in conjunction with an accreditation service DNA should dramatically and safely reduce mail abuse. -Doug From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 20:30:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03950 for ; Wed, 16 Jun 2004 20:30:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5H0GAF1096423; Wed, 16 Jun 2004 17:16:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5H0GAJW096422; Wed, 16 Jun 2004 17:16:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from goose.ehsco.com (goose.ehsco.com [207.65.203.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5H0G9YS096416 for ; Wed, 16 Jun 2004 17:16:10 -0700 (PDT) (envelope-from ehall@ehsco.com) Received: from ehsco.com (ferret.corp.ntrg.com [207.65.71.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Eric A. Hall", Issuer "Network Technology Research Group Certificate Authority" (verified OK)) by goose.ehsco.com (Postfix ) with ESMTP id C6E6F20E68 for ; Wed, 16 Jun 2004 19:16:14 -0500 (CDT) Message-ID: <40D0E2B2.7080501@ehsco.com> Date: Wed, 16 Jun 2004 19:15:46 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: MARID Subject: Re: Alternative to TXT or new RR References: <81AC085044D04B429F5FB883D94FA1AF42A2AD@df-fido-msg.exchange.corp.microsoft.com> In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF42A2AD@df-fido-msg.exchange.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/16/2004 5:01 PM, Jim Lyon wrote: > it's perfectly reasonable to make them separately. We want to make it > dirt easy for a domain to publish, because that increases the value of > every one else's checking. It would be a grave mistake to tell people > they can't publish without running a web server and installing new web > service software. You're confusing lightweight UDP transactions with "web server" -- what we've been describing is a simple input-output datagram transaction. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 20:39:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04421 for ; Wed, 16 Jun 2004 20:39:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5H0UhuR098236; Wed, 16 Jun 2004 17:30:43 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5H0UhdJ098234; Wed, 16 Jun 2004 17:30:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from miz-mishtal.dbc.mtview.ca.us (adsl-64-168-10-250.dsl.scrm01.pacbell.net [64.168.10.250]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5H0Uhga098223 for ; Wed, 16 Jun 2004 17:30:43 -0700 (PDT) (envelope-from mrose@dbc.mtview.ca.us) Received: from [IPv6:::1] (localhost [127.0.0.1]) by miz-mishtal.dbc.mtview.ca.us (8.12.10/8.12.9) with ESMTP id i5H0SRqt004809; Wed, 16 Jun 2004 17:28:27 -0700 (PDT) In-Reply-To: <1CD00592-BFE8-11D8-BD27-000A95CA7FAE@dbc.mtview.ca.us> References: <81AC085044D04B429F5FB883D94FA1AF42A291@df-fido-msg.exchange.corp.microsoft.com> <1CD00592-BFE8-11D8-BD27-000A95CA7FAE@dbc.mtview.ca.us> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4122658E-BFF5-11D8-BD27-000A95CA7FAE@dbc.mtview.ca.us> Content-Transfer-Encoding: 7bit Cc: Andrew Newton , Ted Hardie From: Marshall Rose Subject: Re: Drive Towards Consensus [was Re: On Extensibility in MARID Records] Date: Wed, 16 Jun 2004 17:28:28 -0700 To: IETF MARID WG X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > so, to re-cap: > > 1. now until sunday evening: people post difficult examples > > 2. monday until thursday evening: people post explanations on dealing > with the difficulty > > 3. friday: chairs announce plan for moving forward. a postscript: obviously, the "difficult examples" must refer to reasonably useful extensions; if the definition of "useful" becomes contentious, the chairs will make a determination. /mtr From owner-ietf-mxcomp@mail.imc.org Wed Jun 16 23:18:29 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11469 for ; Wed, 16 Jun 2004 23:18:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5H36Nc4027213; Wed, 16 Jun 2004 20:06:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5H36NfG027212; Wed, 16 Jun 2004 20:06:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from hoster907.com (ns1.hoster907.com [66.211.137.27]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5H36M2Q027196 for ; Wed, 16 Jun 2004 20:06:23 -0700 (PDT) (envelope-from margaret@margaretolson.com) Received: (qmail 29650 invoked from network); 17 Jun 2004 03:07:35 -0000 X-Relay-Users: margaret.user X-Abuse: Send abuse reports to: abuse@suresupport.com Received: from unknown (HELO ?192.168.254.218?) (208.198.98.2) by ns1.hoster907.com with SMTP; 17 Jun 2004 03:07:35 -0000 In-Reply-To: <1CD00592-BFE8-11D8-BD27-000A95CA7FAE@dbc.mtview.ca.us> References: <81AC085044D04B429F5FB883D94FA1AF42A291@df-fido-msg.exchange.corp.microsoft.com> <1CD00592-BFE8-11D8-BD27-000A95CA7FAE@dbc.mtview.ca.us> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <50B2A36E-C00B-11D8-999B-000A95BC6A7E@margaretolson.com> Content-Transfer-Encoding: 7bit Cc: Andrew Newton , IETF MARID WG , Ted Hardie From: Margaret Olson Subject: Re: Drive Towards Consensus [was Re: On Extensibility in MARID Records] Date: Wed, 16 Jun 2004 23:06:23 -0400 To: Marshall Rose X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Here's are my first few examples: Example1.com: example1.com uses two providers: esp.com and personalmail.com . Mail originating from personalmail.com is always conversational (corporate individual mailboxes) and rate limited to 100 messages a day by personalmail.com Mail authored by example1.com originating from esp.com is rate limited to 4,000 messages a month by esp.com. This mail is bulk mail. example1.com is a small b to b service business, as accredited by accreditors.com Note: esp.com and personalmail.com set rate limits on a per customer basis; these limits are functions of the customer, not functions of the service that apply in an undifferentiated manner to all customers. I am taking it as given that esp.com and personalmail.com can write code to do lookups to check the veracity of their customer's statements on the MARID record. Example2.com: Example2.com is a new customer at both personalmail.com and esp.com. They have no accreditation or reputation, but each service rate limits them to 100 messages a day and 400 messages a month, with a total address count of 100. In other words, they can not correspond with more than 100 different recipients over the period of a month on either service. Receivers side services can sum up the rate limits to calculate the total number of recipients and messages that can emanate from example2.com and decide whether it exceeds their policies on authenticated but unaccredited senders. Example3.com: Example3.com has limited internal controls and has decided to outsource the whole record management and sending policy enforcement problem to maridRus.com. They know they send outbound mail through their inbound servers, but other than that they don't know how they send. maridrus.com starts by publishing a record referencing the mx records. They need two kinds of feedback; abuse complaints, of which they want 100%, and channels not listed in the example.com records, of which they want 1 in 1,000 messages. Over time, example.com and maridRus.com conclude that esp1.com and esp2.com, in use by Departments A and B respectively, are authorized vendors, and that they don't need to duplicate complaint monitoring. They update the record such that complaints generated on mail on the esp1 or esp2 channel are handled by the esps, and not copied to maridRus.com. Example4.com Example4.com is an esp bounce handling domain. This domain appears only in MAIL-FROM and never in SUBMITTER or the 2822 from address. Example5.com: [This is included because I think that over time it will be useful to everyone to have receiving as well as sending policies published, and having another syntax for that side of the policy equation doesn't make much sense to me] Example5.com publishes their acceptance criteria as well their sending policies. They accept mail from authenticated but unaccredited senders who do not send more than 100 messages a day or 400 messages a month. Otherwise, they accept accreditations from accreditors.com (which presumably has pass-through arrangements with some number of other accreditors). example5.com requires confirmed opt in from everyone except senders accredited as financial institutions by verythoroughandexpensiveaccreditations.com. For financial institutions they require only prior business relationship, as defined by verythoroughandexpensiveaccreditations.com This is used by esp.com to decide whether or not to send based on the characteristics of each of their customers, and to report back to their customers on what they need to do to get their mail delivered. My real concern with SPF is the strong suspicion there is a lot we haven't thought of yet. Margaret. On Jun 16, 2004, at 6:54 PM, Marshall Rose wrote: > > the co-chairs think this is a useful thread; in fact, we're going to > place the following plan in front of the working group: > > it is clear to the co-chairs that the "tipping point" with respect to > the working group's deliberations revolve around the sufficiency of > the SPF syntax to address near-term concerns. if the syntax is > adequate, it is hard to argue for an alternative or future syntax; if > the syntax is inadequate, then the SPF syntax is of transitory use. > > in order to drive consensus on this issue, the chairs put forth this > plan: > > between now and sunday, june 20, 2004 23:59:59 us/pacific time, ALL > replies to this message must give examples of scenarios for which the > SPF syntax is insufficient. any requests for clarifications MUST be > sent directly to the authors of a scenario, who may then post a > clarification in reply to their own email. > > starting monday, june 21, 2004 00:00:00 us/pacific time, the working > group may reply to any of these scenario messages for the purpose of > explaining how the SPF syntax is sufficient. > > on thursday, june 24, 2004 23:59:59 us/pacific time, the chairs will > gauge the group's consensus on the issue of the sufficiency of the SPF > syntax. > > based on the chair's reading, the working group will be presented with > a plan for moving forward within the timeframe allotted by the > charter. > > so, to re-cap: > > 1. now until sunday evening: people post difficult examples > > 2. monday until thursday evening: people post explanations on dealing > with the difficulty > > 3. friday: chairs announce plan for moving forward. > > /mtr > > From owner-ietf-mxcomp@mail.imc.org Thu Jun 17 02:05:03 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22640 for ; Thu, 17 Jun 2004 02:05:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5H5nh7F066631; Wed, 16 Jun 2004 22:49:43 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5H5nhfO066630; Wed, 16 Jun 2004 22:49:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [64.139.47.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5H5ngcD066603 for ; Wed, 16 Jun 2004 22:49:42 -0700 (PDT) (envelope-from gconnor@nekodojo.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by neko-base.nekodojo.org (Postfix) with ESMTP id CBB5B1D651; Wed, 16 Jun 2004 22:27:53 -0700 (PDT) Date: Wed, 16 Jun 2004 22:27:55 -0700 From: Greg Connor To: Arnt Gulbrandsen , IETF MARID WG Subject: Re: Alternative to TXT or new RR Message-ID: <6462572.1087424875@[192.168.0.3]> In-Reply-To: <1Fz8AGrZ9eBGLNyWqdk4Mg.md5@prosecco.oryx.com> References: <1Fz8AGrZ9eBGLNyWqdk4Mg.md5@prosecco.oryx.com> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --Arnt Gulbrandsen wrote: > > Meng Weng Wong writes, about "what if there were no TXT": >> I'm guessing an SRV lookup against DOMAIN.COM with a >> reserved port number would return a domain name, something like >> MARID-RECORD.DOMAIN.COM, and then something like > > I'm pretty sure we'd be doing a SRV lookup for _marid._udp. and > then asking that server whether to fail/pass/... the message. > > The entire SPF/CID/XML thing would never be published - the policy would > be executed by the same entity that chose the policy. Only the IP > address, email address and pass/fail/... result would cross the net. Interestingly, SPF supports this mode of operation already, today: - A DNS request is sent to the domain the message claims to be from - The DNS response tells where to reach an authentication server via UDP - The receiver contacts the authentication server with a single UDP packet, including info the initial DNS response indicates is needed such as: MTA IP, Helo address, from address (complete or localpart only) - The authentication server responds with a one-packet UDP response saying approved or not. The mechanism used to invoke this behavior is called "exists" and the UDP authentication server is.... A DNS Server :) And No, this reply is not meant as a joke. The exists: mechanism is there for a reason. There are some policies that can't be readily described by a one-packet response. For those unique situations, a second query might be needed, giving the server some additional info. It also works well for situations where the domain owner doesn't want to reveal the complete policy (and prefers to answer questions one at a time) and cases where the policy might change on the fly (like a rate-limiting server that might answer YES for a questionable email/ip combination 10 times and then switch to NO, or many other cases where the domain owner wants more control over the individual yes/no decisions. The exists: mechanism isn't there by accident... there are some cases where it is actually needed, just not the majority. It's similar to DMP actually only a bit more flexible. Some sites will need it for special purposes, and most will not. If the first DNS reply packet is enough, great. If a second request is needed, the first packet says where to go and what extra information is needed. Is it possible to create a specialized new server that receives UDP packets and replies with UDP, to pass authentication info? Sure. Would it be substantially different from a normal DNS server? The server might be custom, but the client doesn't have to be. Implementing a custom server doesn't get around the one-packet size limit, unless you want to implement your own session-over-packet method to reorder and verify/retransmit missing packets, and if you need that you might as well use TCP. -- Greg Connor From owner-ietf-mxcomp@mail.imc.org Thu Jun 17 02:34:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04189 for ; Thu, 17 Jun 2004 02:34:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5H6K4Ts081127; Wed, 16 Jun 2004 23:20:04 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5H6K40S081126; Wed, 16 Jun 2004 23:20:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5H6K4JT081117 for ; Wed, 16 Jun 2004 23:20:04 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 16 Jun 2004 23:20:04 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 16 Jun 2004 23:20:04 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 16 Jun 2004 23:20:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: On Extensibility in MARID Records Date: Wed, 16 Jun 2004 23:19:58 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF42A3D2@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: On Extensibility in MARID Records thread-index: AcRUA2zBApzKlEKdSzSY4EKmhVZ7LgALuO5w From: "Jim Lyon" To: "IETF MARID WG" X-OriginalArrivalTime: 17 Jun 2004 06:20:03.0712 (UTC) FILETIME=[206A5000:01C45433] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5H6K4JT081119 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Wayne, I had somehow missed the message you reference. It actually makes a different point: SPF syntax like +a:foo.com/24 is already broken because it's not (syntactically) obvious whether the domain is foo.com or foo.com/24. I was making yet another point: The slash char has already been usurped by SPF syntax for something other than extensions. I also had not been aware of the details of the SPF report extension. Now that I'm aware, I agree that it's useless. The concept isn't useless, but that particular expression of it is. It's also hard to implement -- asking MTAs to keep running counters for each triple (domain,senderIP,receiverIP). People who want the feedback actually need to see a sampling of the actual messages. -- jimbo From owner-ietf-mxcomp@mail.imc.org Thu Jun 17 05:16:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12224 for ; Thu, 17 Jun 2004 05:16:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5H8s2Js054096; Thu, 17 Jun 2004 01:54:02 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5H8s2Sm054094; Thu, 17 Jun 2004 01:54:02 -0700 (PDT) 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.9) with ESMTP id i5H8s1R3054062 for ; Thu, 17 Jun 2004 01:54:02 -0700 (PDT) (envelope-from cm--jrk@merseymail.com) Received: from mmail by argon.connect.org.uk with local (connectmail/exim) id 1Basel-0007il-G4 for ietf-mxcomp@imc.org; Thu, 17 Jun 2004 09:53:59 +0100 In-Reply-To: <40D0E2B2.7080501@ehsco.com> Subject: Re: Alternative to TXT or new RR To: ietf-mxcomp@imc.org From: "Jon Kyme" X-Mailer: [ConnectMail 3.15.6] X-connectmail-Originating-IP: 172.25.243.3 Message-Id: Date: Thu, 17 Jun 2004 09:53:59 +0100 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > > > On 6/16/2004 5:01 PM, Jim Lyon wrote: > > > it's perfectly reasonable to make them separately. We want to make it > > dirt easy for a domain to publish, because that increases the value of > > every one else's checking. It would be a grave mistake to tell people > > they can't publish without running a web server and installing new web > > service software. > > You're confusing lightweight UDP transactions with "web server" -- what > we've been describing is a simple input-output datagram transaction. > I'm sure that what you want to do, might be done with such a service. On the other hand, I'm not sure that a more heavyweight protocol must be ruled out. We're already taking the trouble to talk (pretty verbose) SMTP over TCP here, I'd guess that extra workload involved in something heavyweight must be <= 100%. Load on my mailservers has been going up that much every year without me doing anything. I could justify a one-off step of that magnitude if it did something about the continual increase in demand. Besides, we've now offloaded the MARID processing costs (although I'm sure that doesn't save much). There might also be substantial advantages in (for instance) wed-service, the protocols are established, the software is largely written already, cacheing and cache-control is well understood ... You could deploy such a thing tomorrow. Or if you can't, you need to ask yourself whether you should be running an MTA. Something like this answers many questions about extensibility, per-user policy etc. The policy can be evaluated dynamically, with access to rules and data unavailable at the receiver. Whatever you think about that, I believe Eric's general point, that the publishers policy can be executed at the publisher, deserves an answer. It needs to be a better answer than "don't make it hard for the publisher". As it stands, we seem to be promising them something for effectively nothing, and that does seem too good to be true. From owner-ietf-mxcomp@mail.imc.org Thu Jun 17 05:20:28 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12470 for ; Thu, 17 Jun 2004 05:20:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5H90xmJ057989; Thu, 17 Jun 2004 02:00:59 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5H90x6p057988; Thu, 17 Jun 2004 02:00:59 -0700 (PDT) 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.9) with ESMTP id i5H90w9C057971 for ; Thu, 17 Jun 2004 02:00:59 -0700 (PDT) (envelope-from cm--jrk@merseymail.com) Received: from mmail by argon.connect.org.uk with local (connectmail/exim) id 1BaslX-00016i-8D; Thu, 17 Jun 2004 10:00:59 +0100 In-Reply-To: <6462572.1087424875@[192.168.0.3]> Subject: Re: Alternative to TXT or new RR To: "Greg Connor" From: "Jon Kyme" Cc: ietf-mxcomp@imc.org X-Mailer: [ConnectMail 3.15.6] X-connectmail-Originating-IP: 172.25.243.3 Message-Id: Date: Thu, 17 Jun 2004 10:00:59 +0100 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > The mechanism used to invoke this behavior is called "exists" and the UDP > authentication server is.... A DNS Server :) > > Yes, we know. But we're talking about MARID, not SPF particularly. The question becomes - why have anything else? And why DNS? :-) From owner-ietf-mxcomp@mail.imc.org Thu Jun 17 07:27:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20076 for ; Thu, 17 Jun 2004 07:27:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5HBB0NN098970; Thu, 17 Jun 2004 04:11:00 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5HBB0eD098969; Thu, 17 Jun 2004 04:11:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5HBAoUh098878 for ; Thu, 17 Jun 2004 04:10:59 -0700 (PDT) (envelope-from bortzmeyer@nic.fr) Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id i5HBAcTB714608; Thu, 17 Jun 2004 13:10:38 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id AE505FB6D; Thu, 17 Jun 2004 13:10:38 +0200 (CEST) Date: Thu, 17 Jun 2004 13:10:38 +0200 From: Stephane Bortzmeyer To: Jim Lyon Cc: IETF-MXCOMP Subject: The vast world of XML (Was: On Extensibility in MARID Records Message-ID: <20040617111038.GA7814@nic.fr> References: <81AC085044D04B429F5FB883D94FA1AF42A122@df-fido-msg.exchange.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF42A122@df-fido-msg.exchange.corp.microsoft.com> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ 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, Jun 16, 2004 at 09:37:41AM -0700, Jim Lyon wrote a message of 260 lines which said: > XML is rich enough to handle all of the above. The spec is well > debugged. XML Schemas include a mechanism for defining what's legal > in a document, even if part of what's legal is tags that haven't > been defined yet. There are dozens of extant parsers You certainly know everything I'm going to write but many people on the group are probably not XML experts, so I would like to emphasize one point: XML is modular and not all parts have the same status, speaking from an engineering point of view. XML, the core, is indeed well debugged and understood, has efficient (time and space) parsers for every operating system, every licencing preference and every programming language. But you say more: you talk about the rest of XML's very rich world. You mention W3C's XML Schemas, someone else mentioned Infoset. And these specifications are different standards (the W3C says "recommandations") which are clearly not so well debugged and not so well implemented. To talk specifically about W3C's XML Schemas, they are not consensual, there are at least two serious competing standards for XML validation (three, with the old DTDs): W3C's XML Schemas and Relax NG (See RFC 3470 for a discussion). I personally prefer Relax NG. But both are quite recent, have very few implementations and are far from being widely mastered. You cannot have your cake and eat it. Either you stick with XML, the core, and most of the pro-XML arguments hold or you want to benefit from the whole XML bestiary and many arguments (well tested, easily available) vanish. From owner-ietf-mxcomp@mail.imc.org Thu Jun 17 08:24:48 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24225 for ; Thu, 17 Jun 2004 08:24:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5HCDDMQ011818; Thu, 17 Jun 2004 05:13:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5HCDDrS011814; Thu, 17 Jun 2004 05:13:13 -0700 (PDT) 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.9) with ESMTP id i5HCDCl8011806 for ; Thu, 17 Jun 2004 05:13:12 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbfujip (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i5HCD2l15775; Thu, 17 Jun 2004 05:13:03 -0700 Date: Thu, 17 Jun 2004 10:06:32 +0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <14610081440.20040617100632@brandenburg.com> To: Tony Finch CC: ietf-mxcomp@imc.org Subject: Re: CSV specification revision available In-Reply-To: References: <1665390638.20040614190711@brandenburg.com> <956329992.20040616082138@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: Content-Transfer-Encoding: 7bit Tony, TF> If I were going to make suggestions about how to structure the spec, I'd TF> throw away HNA and the CSV overview. I'd improve the CSA spec with a more TF> precise explanation of the authentication process (in a separate section). CSA is about authorization, not authentication. The reference to the Additional Information mechanism, within CSA, is as a convenience rather than really being part of the spec. TF> If you want to keep HNA in something like its current form, then I suggest TF> that it should describe each authentication method with reference to a TF> subject domain that is to be authenticated and what other protocol TF> information it is compared with. e.g. the forward DNS method is to look up TF> the A or AAAA records for the subject domain and ensure that one of the TF> addresses is the same as the client IP address from the TCP connection. TF> The TLS method is to require a client certificate with a common name that TF> corresponds to the subject domain. Adding detail like this, to make VERY clear how each one gets used, sounds like an excellent idea. TF> Actually that doesn't work very well because CSA's input into the forward TF> DNS process is the CSA SRV target domain, not the EHLO domain. In the TLS TF> case perhaps the subject domain is the output of the process rather than TF> an input. Huh? CSA _is_ the forward DNS process. Take the EHLO domain, do a lookup on _client._smtp. and get back the authorization SRV. TF> The problem with a strict separation between authentication and TF> authorization in the presentation of CSV is that the protocol does not TF> separate them as described. Yes it does. TF> In fact if my understanding of the protocol is TF> correct (see below) then the description in the CSV draft that TF> authorization follows authentication is wrong. The text makes clear that the actual excecution might occur differently. Refer to "A proposal or its implementation" in the Introduction. TF> The process is interleaved: TF> look up the authorization record; look up the authentication record; check TF> authentication; check authorization. There is no one, right sequence. Folks will choose different sequences, for a variety of reasons. This provides yet-another example of the reason it is essential to be clear that separate functions are indeed separate in the specification. TF> The DNA spec is not really tied to CSV in the way your document structure TF> suggests -- it's useful as the next step after any domain authentication TF> system (SPF, CID, DK, etc.). we specified it, so it's tied to this spec. on the other hand, yes, any component of this could be replaced by some other method of satisfying the component requirement. the challenge is to make sure that it indeed does the right authentication, for example. alghouth spf, cid, and dk may well do nice authentications, it's not clear to me that any of them have the right semantics for what CSV is requiring. >> TF> draft-ietf-marid-dsvcsa-00 >> TF> Sections 4 & 5 >> TF> These sections overlap rather a lot. They also omit to specify what the >> TF> server should do if the client's CSA records has invalid data. >> What do you mean by "invalid" data? How is invalidity assessed? TF> Outside the spec. E.g. a non-zero port, or a weight that isn't 0, 1, or 3, TF> or a priority that isn't 1, etc. ahh. right. good catch. thanks. >> wow. what a really excellent summary! wish we had written it, and thoroughly >> appreciate that you did. it will be a nice addition to the doc. TF> I'm glad you like it :-) The question still remains about the TF> authentication process. Does it use the addresses of the client EHLO TF> domain? (As I understand it, no.) Or does it only use the CSA SRV target TF> domain? (AIUI, yes.) Does it use both? if so, how? (AIUI, no.) What about TF> reverse DNS? (AIUI, no.) i think the answer needs to depend on a step-through analysis of threats. what will be robust against administrative attacks. that is, what will be open to having a bad guy create dns records to permit deception, and what won't. in my current, jet-lagged, vacation mental state, i'm not even close to being able to perform the exercise. TF> I don't think it's worth making heavy weather of the distinction, TF> certainly not to the extent of forcing an order of presentation of the CSV TF> algorithm that has no relation to the order of execution. People are used TF> to authentication and authorization being very tightly bound; keeping them TF> apart isn't necessary if it is clear which part of the protocol is TF> performing which security function. The "used to" has two responses, both problematic: 1. That may well contribute to the reason folks are so bad at distinguishing between these two, very different functions and why we need to be thoroughly, painfully, crystal-ly clear about the differences between them. To that extent, the anti-spam work is working in territory that has been sadly lacking much history. 2. In fact authorization is rarely discussed within Internet standards specifications. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Thu Jun 17 09:09:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27311 for ; Thu, 17 Jun 2004 09:09:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5HCwDkG022463; Thu, 17 Jun 2004 05:58:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5HCwDQO022462; Thu, 17 Jun 2004 05:58:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from orange.csi.cam.ac.uk (exim@orange.csi.cam.ac.uk [131.111.8.77]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5HCwC89022455 for ; Thu, 17 Jun 2004 05:58:13 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from fanf2 (helo=localhost) by orange.csi.cam.ac.uk with local-esmtp (Exim 4.12) id 1BawT7-0000LE-00; Thu, 17 Jun 2004 13:58:13 +0100 Date: Thu, 17 Jun 2004 13:58:13 +0100 From: Tony Finch X-X-Sender: fanf2@orange.csi.cam.ac.uk To: Dave Crocker cc: Tony Finch , ietf-mxcomp@imc.org Subject: Re: CSV specification revision available In-Reply-To: <14610081440.20040617100632@brandenburg.com> Message-ID: References: <1665390638.20040614190711@brandenburg.com> <956329992.20040616082138@brandenburg.com> <14610081440.20040617100632@brandenburg.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 17 Jun 2004, Dave Crocker wrote: > > CSA is about authorization, not authentication. OK. But the point of using CSA as opposed to any other lookup mechanism is it gives you authn and authz in one protocol exchange. And the other authn mechanisms described in HNA are too unweildy for use on the scale of the Internet. I think that CSA is elegant and simple, but I think its specification is being WAY overdone. Three documents to describe an enhancement to forward and reverse DNS consistency checking?! People will get bored with the abstract discussion of the principles of security protocol design and not bother to read as far as the bit that explains how to implement it. I'm afraid I'm getting a bit frustrated because I doubt this will get anywhere near deployment. > Huh? CSA _is_ the forward DNS process. Take the EHLO domain, do a > lookup on _client._smtp. and get back the authorization > SRV. OK, but that's different from the normal A or AAAA lookup for the bare EHLO domain which HNA appears to describe. And "CSA is about authorization, not authentication." -- Tony Finch http://dotat.at/ From owner-ietf-mxcomp@mail.imc.org Thu Jun 17 09:21:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27998 for ; Thu, 17 Jun 2004 09:21:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5HD7ZgI024519; Thu, 17 Jun 2004 06:07:35 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5HD7ZLY024518; Thu, 17 Jun 2004 06:07:35 -0700 (PDT) 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.9) with ESMTP id i5HD7YUv024500 for ; Thu, 17 Jun 2004 06:07:34 -0700 (PDT) (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.34) id 1Bawc1-0003hB-0j for ietf-mxcomp@imc.org; Thu, 17 Jun 2004 08:07:34 -0500 To: "IETF MARID WG" References: <81AC085044D04B429F5FB883D94FA1AF42A3D2@df-fido-msg.exchange.corp.microsoft.com> From: wayne Reply-To: "IETF MARID WG" Date: Thu, 17 Jun 2004 08:07:24 -0500 In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF42A3D2@df-fido-msg.exchange.corp.microsoft.com> (Jim Lyon's message of "Wed, 16 Jun 2004 23:19:58 -0700") 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 (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: On Extensibility in MARID Records Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-4.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <81AC085044D04B429F5FB883D94FA1AF42A3D2@df-fido-msg.exchange.corp.microsoft.com> "Jim Lyon" writes: > I had somehow missed the message you reference. It actually makes a > different point: SPF syntax like > +a:foo.com/24 is already broken because it's not (syntactically) > obvious whether the domain is foo.com or foo.com/24. Well, "broken" is probably an overstatement. The BNF in the SPF spec makes it unambigious, CIDR notation must be the *final part* of the token. There will only be a conflict if there comes a day when there are top level domains such as "com/24". If such TLDs are created, you will need to use "a:foo.com/24." instead. While things like "adsl/18.foo.com" are valid domain names, they aren't valid host names, and thus I think it is pretty unlikely that such TLDs will be created. > I was making yet another point: The slash char has already been usurped > by SPF syntax for something other than extensions. I guess it is all how you look at it. My point was that slash is reserved for use in host names, with a special case for CIDR notation. It doesn't make much difference. All the creative talk about how to tag mechanism is irrelevant for SPFv1. You simply can not do it. You must think in terms of modifiers instead, but it is important to remember that modifiers are position independant and the spec recommends that you place them at the end. > I also had not been aware of the details of the SPF report extension. > Now that I'm aware, I agree that it's useless. The concept isn't > useless, but that particular expression of it is. It's also hard to > implement -- asking MTAs to keep running counters for each triple > (domain,senderIP,receiverIP). > > People who want the feedback actually need to see a sampling of the > actual messages. I think it is extremely unlikely that mail admins will send samples of actual messages to anyone, unless it is in a *very* controlled manner. The privicy and mailbombing implications rule it out. SPF already has a logging technique that is in use: "v=spf1 +exists:CL.%{i}.FR.%{s}.HE.%{h}.null.spf.altavista.com -all" As you pointed out during the interim meeting, this can give inaccurate results because legitimate SPF implementations may not do the DNS lookups when you expect them, but also because others can do DNS lookups any time they want to skew the results. These same problems occur with all the reporting techniques mentioned so far. Not only is it foolish to send reports to random email address specified by third parties, but it is foolish to trust the reports you get. -wayne From owner-ietf-mxcomp@mail.imc.org Thu Jun 17 10:34:11 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05134 for ; Thu, 17 Jun 2004 10:34:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5HEHw9g040594; Thu, 17 Jun 2004 07:17:58 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5HEHwBb040593; Thu, 17 Jun 2004 07:17:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from messagelevel.com ([208.253.112.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5HEHvSb040556 for ; Thu, 17 Jun 2004 07:17:57 -0700 (PDT) (envelope-from bill.mcinnis@messagelevel.com) Date: Thu, 17 Jun 2004 10:17:18 -0400 Message-Id: <200406171017.AA206700758@messagelevel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: "Bill Mcinnis" Reply-To: To: "Jim Lyon" , "Jon Kyme" CC: Subject: RE: Alternative to TXT or new RR X-Mailer: X-Declude-Sender: bill.mcinnis@messagelevel.com [127.0.0.1] X-Note: This E-mail was scanned by Declude JunkMail (www.declude.com) for spam. X-Spam-Tests-Failed: None [0] X-Note: This E-mail was sent from ([127.0.0.1]). Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I have not had a chance to read this list for a week or so, and have not been able to trace this thread with any ease, can someone summarize what started this thread, because I am reading a lot of bits and pieces that sound like what we have. Thanks, Bill McInnis www.messagelevel.com Message Level Authentication ---------- Original Message ---------------------------------- From: "Jon Kyme" Date: Wed, 16 Jun 2004 23:04:59 +0100 > >> >> > Therefore, RPC-to-publisher is at least as capable as SPF-like >> schemes. >> There are a lot of small domains out there. I believe that we can get >> many of them to take 5 minutes to add a DNS record. But getting them to >> install new software, and configure a new web service, is way past the >> ability of many of them. >> > >Then they'd need to rely on the services of a third party (which is what >might happen with reputation services anyway), or not benefit. So this >isn't, on the face of it, a meaningful objection. > > > ---- This outgoing message is guaranteed to be authentic by MessageLevel users. Guarantee the authenticity of your email @ http://www.messagelevel.com. From owner-ietf-mxcomp@mail.imc.org Thu Jun 17 10:56:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07117 for ; Thu, 17 Jun 2004 10:56:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5HEjDR8047325; Thu, 17 Jun 2004 07:45:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5HEjDcV047324; Thu, 17 Jun 2004 07:45:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [212.125.101.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5HEjCL5047301 for ; Thu, 17 Jun 2004 07:45:12 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: by kalyani.oryx.com (Postfix, from userid 1005) id 9A1571BDE83; Thu, 17 Jun 2004 16:45:11 +0200 (CEST) Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by kalyani.oryx.com (Postfix) with ESMTP id 934511BDE82 for ; Thu, 17 Jun 2004 16:45:09 +0200 (CEST) Message-Id: <9k88pDVCjt8nCbfGca/1Dw.md5@libertango.oryx.com> From: Arnt Gulbrandsen To: bill.mcinnis@messagelevel.com Subject: Re: Alternative to TXT or new RR Cc: Jon Kyme , Jim Lyon , ietf-mxcomp@imc.org References: <200406171017.AA206700758@messagelevel.com> In-Reply-To: <200406171017.AA206700758@messagelevel.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Thu, 17 Jun 2004 16:48:43 +0200 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Bill Mcinnis writes: > I have not had a chance to read this list for a week or so, and have > not been able to trace this thread with any ease, can someone > summarize what started this thread, because I am reading a lot of > bits and pieces that sound like what we have. SPF is like this: The message recipient figures out a sending domain, does a DNS lookup, receives an SPF program, interprets that program, and finally makes a decision. CID is much the same. I suggested an alternative: The message recipient figures out a sending domain, does a DNS lookup, receives the location of a server, asks that server whether a message from IP address so-and-so is permitted to have sender so-and-so, receives an answer, and makes a decision. The advantages: 1) that there is no longer an entire language in the MARID spec, 2) there is absolutely no need for a new RR, 3) programs aren't being shipped around the net to be executed by sundry mail receivers, 4) the domain owner (or software vendor) can do any processing they want, and 5) mail receivers don't need to accept and execute programs from strangers. One disadvantage has been mentioned: It's harder to set up such a service than to add the SPF TXT record. Arnt From owner-ietf-mxcomp@mail.imc.org Thu Jun 17 10:59:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07477 for ; Thu, 17 Jun 2004 10:59:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5HEoc7S048802; Thu, 17 Jun 2004 07:50:38 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5HEocTP048801; Thu, 17 Jun 2004 07:50:38 -0700 (PDT) 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.9) with ESMTP id i5HEobAY048783 for ; Thu, 17 Jun 2004 07:50:37 -0700 (PDT) (envelope-from cm--jrk@merseymail.com) Received: from mmail by argon.connect.org.uk with local (connectmail/exim) id 1BayDt-0004iB-4a; Thu, 17 Jun 2004 15:50:37 +0100 In-Reply-To: <200406171017.AA206700758@messagelevel.com> Subject: RE: Alternative to TXT or new RR To: From: "Jon Kyme" Cc: ietf-mxcomp@imc.org X-Mailer: [ConnectMail 3.15.6] X-connectmail-Originating-IP: 172.25.243.3 Message-Id: Date: Thu, 17 Jun 2004 15:50:37 +0100 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > I have not had a chance to read this list for a week or so, > and have not been able to trace this thread with any ease, can > someone summarize what started this thread, because I am reading a lot > of bits and pieces that sound like what we have. > > I don't believe that we've discussed anything that hasn't been discussed publicly here or elsewhere before. Why don't you make your "white paper" available without registration? From owner-ietf-mxcomp@mail.imc.org Thu Jun 17 11:13:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08863 for ; Thu, 17 Jun 2004 11:13:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5HEvVmh050349; Thu, 17 Jun 2004 07:57:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5HEvVtW050348; Thu, 17 Jun 2004 07:57:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5HEvUDW050339 for ; Thu, 17 Jun 2004 07:57:31 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Message-Id: From: Arnt Gulbrandsen To: Jon Kyme Subject: Re: Alternative to TXT or new RR Cc: "Eric A. Hall" , ietf-mxcomp@imc.org References: In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Thu, 17 Jun 2004 17:01:13 +0200 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Kyme writes: >> Nor does it say that all processing must be receiver-side. > > No, you're quite right, but while a minimal MARID may still be in > scope, "no MARID" probably isn't :-) The DNS-based mechanism must use a domain. MARID has to specify an algorithm to pick the domain. No escaping that minimum, so "no MARID" isn't an option. Arnt From owner-ietf-mxcomp@mail.imc.org Thu Jun 17 11:39:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10950 for ; Thu, 17 Jun 2004 11:39:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5HFPTtF057629; Thu, 17 Jun 2004 08:25:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5HFPThK057627; Thu, 17 Jun 2004 08:25:29 -0700 (PDT) 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.9) with ESMTP id i5HFPSuU057615 for ; Thu, 17 Jun 2004 08:25:28 -0700 (PDT) (envelope-from cm--jrk@merseymail.com) Received: from mmail by argon.connect.org.uk with local (connectmail/exim) id 1Bayle-0005uT-R9; Thu, 17 Jun 2004 16:25:30 +0100 In-Reply-To: Subject: Re: Alternative to TXT or new RR To: "Arnt Gulbrandsen" From: "Jon Kyme" Cc: ietf-mxcomp@imc.org X-Mailer: [ConnectMail 3.15.6] X-connectmail-Originating-IP: 172.25.243.3 Message-Id: Date: Thu, 17 Jun 2004 16:25:30 +0100 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > No, you're quite right, but while a minimal MARID may still be in > > scope, "no MARID" probably isn't :-) > > > The DNS-based mechanism must use a domain. MARID has to specify an > algorithm to pick the domain. No escaping that minimum, so "no MARID" > isn't an option. > Yes. Alternatively, if a scheme says make some RPC directly to the hostname _not_marid_.${mail_from_domain} passing peer_ip in some way to be decided (for instance) ... In that case, there's no authentication record in the DNS so it's not a MARID scheme. (Hence out of scope). Incidentally, I'd consider such a scheme to be pretty "obvious" :-) although I believe such things were discussed previously on asrg and elsewhere - and using the DNS to discover the service rather than rely on a well known name (or naming convention), as in the naive scheme above, is pretty well established also. From owner-ietf-mxcomp@mail.imc.org Thu Jun 17 11:46:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11653 for ; Thu, 17 Jun 2004 11:46:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5HFXYP7059346; Thu, 17 Jun 2004 08:33:34 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5HFXY4U059345; Thu, 17 Jun 2004 08:33:34 -0700 (PDT) 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.9) with ESMTP id i5HFXXKC059338 for ; Thu, 17 Jun 2004 08:33:33 -0700 (PDT) (envelope-from cm--jrk@merseymail.com) Received: from mmail by argon.connect.org.uk with local (connectmail/exim) id 1BaytT-00088R-Vv; Thu, 17 Jun 2004 16:33:35 +0100 In-Reply-To: Subject: Re: Alternative to TXT or new RR To: "Arnt Gulbrandsen" From: "Jon Kyme" Cc: ietf-mxcomp@imc.org X-Mailer: [ConnectMail 3.15.6] X-connectmail-Originating-IP: 172.25.243.3 Message-Id: Date: Thu, 17 Jun 2004 16:33:35 +0100 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I wrote: > In that case, there's no authentication record in the DNS s/authentication/authorisation/ Sorry, I was thinking about something else. From owner-ietf-mxcomp@mail.imc.org Thu Jun 17 12:41:57 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18386 for ; Thu, 17 Jun 2004 12:41:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5HGWPY1073369; Thu, 17 Jun 2004 09:32:25 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5HGWPlT073368; Thu, 17 Jun 2004 09:32:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from goose.ehsco.com (goose.ehsco.com [207.65.203.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5HGWOBd073351 for ; Thu, 17 Jun 2004 09:32:24 -0700 (PDT) (envelope-from ehall@ehsco.com) Received: from ehsco.com (ferret.corp.ntrg.com [207.65.71.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Eric A. Hall", Issuer "Network Technology Research Group Certificate Authority" (verified OK)) by goose.ehsco.com (Postfix ) with ESMTP id 566C05FB1E; Thu, 17 Jun 2004 11:32:24 -0500 (CDT) Message-ID: <40D1C777.6070308@ehsco.com> Date: Thu, 17 Jun 2004 11:31:51 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jon Kyme Cc: Arnt Gulbrandsen , ietf-mxcomp@imc.org Subject: Re: Alternative to TXT or new RR References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/17/2004 10:25 AM, Jon Kyme wrote: > In that case, there's no authentication record in the DNS so it's not a > MARID scheme. (Hence out of scope). That's not what the charter says. Read it again. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-ietf-mxcomp@mail.imc.org Thu Jun 17 12:48:26 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19246 for ; Thu, 17 Jun 2004 12:48:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5HGWQue073380; Thu, 17 Jun 2004 09:32:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5HGWQCN073379; Thu, 17 Jun 2004 09:32:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ernie.mail-abuse.org (Ernie.mail-abuse.org [168.61.5.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5HGWKZf073307 for ; Thu, 17 Jun 2004 09:32:20 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.mail-abuse.org (DDev.mail-abuse.org [168.61.10.124]) by ernie.mail-abuse.org (8.12.0.Beta19/8.12.0) with ESMTP id i5HGWGPQ083089; Thu, 17 Jun 2004 09:32:16 -0700 (PDT) Subject: Re: Alternative to TXT or new RR From: Douglas Otis To: Greg Connor Cc: Arnt Gulbrandsen , IETF MARID WG In-Reply-To: <6462572.1087424875@[192.168.0.3]> References: <1Fz8AGrZ9eBGLNyWqdk4Mg.md5@prosecco.oryx.com> <6462572.1087424875@[192.168.0.3]> Content-Type: text/plain Message-Id: <1087489936.769.28.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 17 Jun 2004 09:32:16 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-06-16 at 22:27, Greg Connor wrote: > --Arnt Gulbrandsen wrote: > > > > Meng Weng Wong writes, about "what if there were no TXT": > >> I'm guessing an SRV lookup against DOMAIN.COM with a > >> reserved port number would return a domain name, something like > >> MARID-RECORD.DOMAIN.COM, and then something like > > > > I'm pretty sure we'd be doing a SRV lookup for _marid._udp. and > > then asking that server whether to fail/pass/... the message. > > > > The entire SPF/CID/XML thing would never be published - the policy would > > be executed by the same entity that chose the policy. Only the IP > > address, email address and pass/fail/... result would cross the net. > > > Interestingly, SPF supports this mode of operation already, today: > > - A DNS request is sent to the domain the message claims to be from > - The DNS response tells where to reach an authentication server via UDP > - The receiver contacts the authentication server with a single UDP > packet, including info the initial DNS response indicates is needed such > as: MTA IP, Helo address, from address (complete or localpart only) > - The authentication server responds with a one-packet UDP response saying > approved or not. > > The mechanism used to invoke this behavior is called "exists" and the UDP > authentication server is.... A DNS Server :) > > > And No, this reply is not meant as a joke. The exists: mechanism is there > for a reason. There are some policies that can't be readily described by a > one-packet response. For those unique situations, a second query might be > needed, giving the server some additional info. It also works well for > situations where the domain owner doesn't want to reveal the complete > policy (and prefers to answer questions one at a time) and cases where the > policy might change on the fly (like a rate-limiting server that might > answer YES for a questionable email/ip combination 10 times and then switch > to NO, or many other cases where the domain owner wants more control over > the individual yes/no decisions. > > The exists: mechanism isn't there by accident... there are some cases where > it is actually needed, just not the majority. It's similar to DMP actually > only a bit more flexible. Some sites will need it for special purposes, > and most will not. If the first DNS reply packet is enough, great. If a > second request is needed, the first packet says where to go and what extra > information is needed. > > Is it possible to create a specialized new server that receives UDP packets > and replies with UDP, to pass authentication info? Sure. Would it be > substantially different from a normal DNS server? The server might be > custom, but the client doesn't have to be. Implementing a custom server > doesn't get around the one-packet size limit, unless you want to implement > your own session-over-packet method to reorder and verify/retransmit > missing packets, and if you need that you might as well use TCP. If there is to be an authentication server used for mail, then http://www.ietf.org/internet-drafts/draft-fenton-identified-mail-00.txt defines this process and does not require parsing TXT packets to find it, but instead uses a conventional SRV record. This mechanism can offer dynamic services and provide assurances about the person sending mail independent of the mail channel. Mail still works! : ) It seems absurd to suggest a rate limiting mechanism will be useful for either an SPF or CID approach. The only thing safely achieved would be to mark mail as checked, but even that information would be prone. Is it logical to expect a receiving SMTP server to drop mail based on cached information now claimed to be rapidly changing? With most lists being open (little of the mail will be dropped or blocked), mail will be marked at the MUA and put into the "maybe" folder next to the "spam" folder. SPF and CID will not ensure mail came from any specific domain as there would be no incentive to for such intensive checking to be done in transit if it resulted in no benefit for the service provider. ; ( -Doug From owner-ietf-mxcomp@mail.imc.org Thu Jun 17 12:53:29 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19842 for ; Thu, 17 Jun 2004 12:53:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5HGfsHY075363; Thu, 17 Jun 2004 09:41:54 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5HGfsae075362; Thu, 17 Jun 2004 09:41:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (mail.santronics.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5HGfrHL075355 for ; Thu, 17 Jun 2004 09:41:53 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Thu, 17 Jun 2004 12:45:14 -0400 Received: from ([68.223.169.60]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 1301361860; Thu, 17 Jun 2004 12:45:13 -0400 Message-ID: <006a01c4548a$ec8b7900$6401a8c0@hdev1> From: "Hector Santos" To: "IETF-MXCOMP" Subject: Wildcards Date: Thu, 17 Jun 2004 12:48:14 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.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: Content-Transfer-Encoding: 7bit I got an interesting report from a blackberry customer that highlighted a bug in our MCEP support. The domain in question was nextel blackberry.net We support SPF and MCEP. For SPF, the TXT record returns: d:\wc5beta>nslookup -query=txt nextel.blackberry.net Non-authoritative answer: nextel.blackberry.net text = "Standard MX Record" blackberry.net nameserver = xns01lhr.rim.net blackberry.net nameserver = xns01ykf.rim.net xns01ykf.rim.net internet address = 206.51.26.10 For a _EP lookup: d:\wc5beta>nslookup -query=txt _ep.nextel.blackberry.net Non-authoritative answer: _ep.nextel.blackberry.net text = "Wildcard MX Record" blackberry.net nameserver = xns01ykf.rim.net blackberry.net nameserver = xns01lhr.rim.net xns01lhr.rim.net internet address = 193.109.81.21 xns01ykf.rim.net internet address = 206.51.26.10 The BUG was that we didn't check for a "nslookup -query=txt _foobar.nextel.blackberry.net Non-authoritative answer: _foobar.nextel.blackberry.net text = "Wildcard MX Record" blackberry.net nameserver = xns01lhr.rim.net blackberry.net nameserver = xns01ykf.rim.net From owner-ietf-mxcomp@mail.imc.org Thu Jun 17 13:43:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26272 for ; Thu, 17 Jun 2004 13:43:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5HHWgm0088132; Thu, 17 Jun 2004 10:32:42 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5HHWgH4088131; Thu, 17 Jun 2004 10:32:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tom.iecc.com (tom.iecc.com [208.31.42.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5HHWecc088114 for ; Thu, 17 Jun 2004 10:32:41 -0700 (PDT) (envelope-from johnl@iecc.com) Received: (qmail 21683 invoked from network); 17 Jun 2004 17:32:43 -0000 Received: (ofmipd johnl@64.60.252.152); 17 Jun 2004 17:32:21 -0000 Date: 17 Jun 2004 10:33:10 -0700 Message-ID: <40D1D5D6.6010400@iecc.com> From: "John T Levine" To: "IETF-MXCOMP" User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: Against Extensibility in MARID Records References: <81AC085044D04B429F5FB883D94FA1AF42A122@df-fido-msg.exchange.cor p.microsoft.com> <28314183.1087402525@Ryoga.corp.sgi.com> In-Reply-To: <28314183.1087402525@Ryoga.corp.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > OK, for expedience I will concede that XML is better suited to extending > the data in various directions, like a tree. Margaret Olson gave some good examples of info that one might want to put in an XML document describing a mail sender. I can see why it could be useful to publish them, but I think it'd be a disaster to allow MARID extensions like that. One of the main points of MARID, as I understand it, is to develop something that can be implemented relatively quickly and will interoperate among senders and recipients all over the net. I don't know what I'd do with descriptions of how much mail a domain sent and for what purposes (starting with whether I'd believe those assertions, which I probably wouldn't unless it was from a sender whose mail I was going to accept anyway) but I'm sure that if I asked six people the same question, I'd get six different answers. That's not interoperability, that's chaos. I don't see any problem if the MARID record includes a pointer to a place where all of the extended XML goop can be found, probably as a URL. It's going to be big enough to need a TCP session anyway, and http is the only TCP service I know that is well standardized and is known to scale reasonably well via caches and the like. RSS shows us that it's practical to fetch XML info records via http. The MARID record needs to contain info that's universally understood. I understand what "these IPs can send our mail" means. I don't necessarily understand all the implications, but I understand that assertion. Much beyond that, it's still all in the fog, and I don't think any of us are well served by a spec that requires mail recipients to download fog they can't use and don't understand. If people want private extensions for, say, a domain to tell its own MUAs how to parse the received headers, that's fine, but it's not needed to interoperate among domains so I don't see that it belongs in MARID. If we take all the extra semantics off the table, the simple SPF format is quite adequate, and we can reasonably defer possible standardization of the XML over http, probably starting with conventions for the URL to ask about both the domain and the mailbox, until later. -- Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor "I dropped the toothpaste", said Tom, crestfallenly. From owner-ietf-mxcomp@mail.imc.org Thu Jun 17 14:15:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00931 for ; Thu, 17 Jun 2004 14:15:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5HI5Vsn095636; Thu, 17 Jun 2004 11:05:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5HI5V4R095635; Thu, 17 Jun 2004 11:05:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5HI5V0q095621 for ; Thu, 17 Jun 2004 11:05:31 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.131.244.249] ([::ffff:216.168.239.87]) (AUTH: LOGIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Thu, 17 Jun 2004 14:05:33 -0400 id 000580FD.40D1DD6D.000049A2 Mime-Version: 1.0 (Apple Message framework v613) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: IETF MARID WG From: Andrew Newton Subject: Mailing List Discourse Date: Thu, 17 Jun 2004 14:05:30 -0400 X-Mailer: Apple Mail (2.613) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Over the last couple of days I have received many private emails from individuals concerned about the type of discourse they have seen on the MARID mailing list, and they are concerned that participation is not a valuable use of their time. Quite simply, the unprofessional behavior has got to stop. On March 18, we asked the participants of this working group to abide by the following etiquette: http://www.imc.org/ietf-mxcomp/mail-archive/msg00358.html In addition, we ask that you follow this advice in how to comport yourselves: * Unless your name appears on the charter page for the MARID Working Group, your role in this working group is as individual participant only. The IETF treats all participants as individuals, not representatives of corporations, governments, or other organizations. If you feel that you should be treated otherwise, please petition the IAB for a formal liaison relationship with the IETF. * Because all the participants are individuals and represent no corporation, government or other type of organization, intimations and message subtext regarding the motives and/or hidden agendas of other participants will no longer be tolerated. For a definition of "no longer tolerated," please consult BCP 83. * The persons with names listed on the charter page for the MARID Working Group have certain roles and responsibilities for leading output of this working group through the IETF standards process. Matters of how MARID will interface with the IESG should be left in their hands so that participants are free to concentrate on the work of the group and not the process. * Above all else, participants should concentrate their energies on creating an interoperable standard. If MARID fails to emit an interoperable standard, everything else done here is for naught. -andy From owner-ietf-mxcomp@mail.imc.org Thu Jun 17 18:20:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21684 for ; Thu, 17 Jun 2004 18:20:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5HM5JUq032122; Thu, 17 Jun 2004 15:05:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5HM5Jeo032121; Thu, 17 Jun 2004 15:05:19 -0700 (PDT) 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.9) with ESMTP id i5HM5JhU032114 for ; Thu, 17 Jun 2004 15:05:19 -0700 (PDT) (envelope-from dcrocker@brandenburg.com) Received: from bbfujip (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i5HM4vl09455; Thu, 17 Jun 2004 15:05:05 -0700 Date: Thu, 17 Jun 2004 22:44:38 +0800 From: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1359564310.20040617224438@brandenburg.com> To: Tony Finch CC: ietf-mxcomp@imc.org Subject: Re: CSV specification revision available In-Reply-To: References: <1665390638.20040614190711@brandenburg.com> <956329992.20040616082138@brandenburg.com> <14610081440.20040617100632@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: Content-Transfer-Encoding: 7bit Tony, TF> On Thu, 17 Jun 2004, Dave Crocker wrote: >> >> CSA is about authorization, not authentication. TF> OK. But the point of using CSA as opposed to any other lookup mechanism is TF> it gives you authn and authz in one protocol exchange. Although that is a possible and an appealing scenario, it was certainly not "the point" behind the CSA SRV design. In fact, I'm expecting people to look for much stronger authentication, at least in some cases. TF> And the other TF> authn mechanisms described in HNA are too unweildy for use on the scale of TF> the Internet. not clear. certainly something as heavyweight as client-side authentication with TLS has not. and I remain skeptical about it, but the security guys keep banging on that door and, at some point, someone is likely to open it. TF> I think that CSA is elegant and simple, but I think its specification is TF> being WAY overdone. Three documents to describe an enhancement to forward TF> and reverse DNS consistency checking?! Well, it does rather more than that. First, it does not rely on forward/reverse and, in fact, allows much stronger alternatives for authentication. Second, the accreditation step is entirely new and explores territory with essentially no Internet standards history or large-scale, distributed operation testing. It well might turn out to be appropriate to compress the specifications, once folks are VERY clear about the service and have good consensus on it. However at this stage, it is proving almost impossible to get coherent discussion of these mail-reception control techniques, with any real clarity about the component functions. Unless and until we get there, dividing the topics up to be almost completely separate should aid that coherence. TF> People will get bored with the TF> abstract discussion of the principles of security protocol design and not TF> bother to read as far as the bit that explains how to implement it. That's why I like your suggested summaries of the total procedure. It permits easy scanning to extract the core characteristics, without having to first read all the detail. >> Huh? CSA _is_ the forward DNS process. Take the EHLO domain, do a >> lookup on _client._smtp. and get back the authorization >> SRV. TF> OK, but that's different from the normal A or AAAA lookup for the bare TF> EHLO domain which HNA appears to describe. And "CSA is about TF> authorization, not authentication." I had not understood that you meant the SECOND forward lookup. The first produces the CSA SRV record. And, yes, the second produces the A+ record of the SRV target. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Thu Jun 17 20:50:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01110 for ; Thu, 17 Jun 2004 20:50:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5I0aq8N061611; Thu, 17 Jun 2004 17:36:52 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5I0aqfR061610; Thu, 17 Jun 2004 17:36:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5I0apbA061604 for ; Thu, 17 Jun 2004 17:36:51 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 17 Jun 2004 17:36:57 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 17 Jun 2004 17:36:57 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 17 Jun 2004 17:36:57 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Against Extensibility in MARID Records Date: Thu, 17 Jun 2004 17:36:54 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF42A63A@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: Against Extensibility in MARID Records thread-index: AcRUkhVj6f6t3CbJQ3CLlSOWaLuLtwANEDLg From: "Jim Lyon" To: "John T Levine" , "IETF-MXCOMP" X-OriginalArrivalTime: 18 Jun 2004 00:36:57.0109 (UTC) FILETIME=[5C41BC50:01C454CC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5I0apbA061605 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit In arguing against extensibility, John Levine argues that it's a bad thing (he used the word "chaotic") to have information in a MARID record that is not understood by everyone. To rebut this, I note that substantially every successful data format and protocol contains buckets for information that isn't globally understood. For example, consider headers in RFC 2822 mail messages. The general ethos is that if you see a message that contains a header you don't understand, you just ignore it. Without this ethos, many useful extensions (MIME, for example) would have been impossible. A similar story applies to the headers in HTTP. Without the ethos of ignoring what you don't understand, many commonly used features would have been impossible. Similarly, in RFC 2821, responses to EHLO contain a list of extensions, many of which the client doesn't understand. Again, the ethos is that you completely ignore anything you don't understand. Doing so is exactly what enables SMTP extensions. Or look at DNS. In a DNS packet, there's only a single unassigned bit, and some deployed DNS software gets pissed off if it's not zero. This fact, more than any other, has hampered attempts to expand the DNS protocol. Or look at the difference between ASN-1 and XML. ASN-1 can describe anything for which the entire schema is known in advance, but it's hard to extend a schema after the fact. XML, on the other hand, has the clear ability to carry goo whose semantics are not known by older code. Guess which has been more successful. Given that we *know* that we'll need more information in the future (most of us are here to reduce spam, not just authenticate MTAs), it behooves us to plan the extensibility now. SPF's current modifiers are a step in the right direction (they have the ignore what you don't understand ethos), but as I've argued elsewhere, they aren't sufficient. The reason they're not sufficient has to do with cases where you need to attach new pieces of information to particular SPF mechanisms; SPF merely gives you a way to attach new information to the whole record. For this same reason, John's suggestion of just having a pointer to a separate XML document isn't sufficient, either. -- Jim Lyon PS: John also continues the misconception that anything that uses XML will be big enough to require DNS TCP. This just isn't true. It looks like most XML-encoded stuff runs about 20% bigger than SPF-encoded stuff. The size concern might be persuasive if typical SPF records were pushing 400 bytes, but they're not. They're usually around 50 bytes. The number of characters in the XML framing is just not that big an issue. When you're spending 18 bytes to represent an address range, it just doesn't matter that much whether you frame it with "+a:" and space, or with "" and "". From owner-ietf-mxcomp@mail.imc.org Thu Jun 17 21:03:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02052 for ; Thu, 17 Jun 2004 21:03:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5I0sI6v064965; Thu, 17 Jun 2004 17:54:18 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5I0sISx064964; Thu, 17 Jun 2004 17:54:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5I0sHif064956 for ; Thu, 17 Jun 2004 17:54:17 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 17 Jun 2004 17:54:23 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 17 Jun 2004 17:54:23 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 17 Jun 2004 17:54:23 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: On Extensibility in MARID Records Date: Thu, 17 Jun 2004 17:54:28 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF42A648@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: On Extensibility in MARID Records thread-index: AcRT+MYAyBGvj4pTRduw/uGkYX78bgA071yA From: "Jim Lyon" To: "Greg Connor" , "IETF-MXCOMP" X-OriginalArrivalTime: 18 Jun 2004 00:54:23.0297 (UTC) FILETIME=[CBD55B10:01C454CE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5I0sHif064959 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Greg Connor wrote: > Also, did you want to say a few words about other things that > might go in _ep besides out nodes? Now would be a good time > to bring that up too if so. Things that I have considered in this space include: 1. For incoming mail, the nature and difficulty of computational puzzles that the domain respects as indicative of non-spammy behavior. 2. For challenge/response systems, information about the nature of challenges that might be respected by the domain. 3. Information about where and how to complain about mail sent by the domain. (Arguably, this might be part of ). 4. For the benefit of MUAs in the domain, information about how to locate a message's Received header that was added when the message entered the domain. (Could be used to enable MUAs to perform MARID checks, instead of relying on MTAs to do it.) 5. Should opportunistic encryption ever become big, statements about what is supported. Each of these is quite small. (1) would probably contain a small identifier and an integer. (2) would contain just a small identifier. (3) would probably contain just an email address (or possibly a URL). (4) would contain a small string. (5) may just be a boolean. It would be a rare domain that published all five of these, and I'd be very surprised if the total XML bytes for all of these ever exceeded 100 bytes. These are examples of possibilities (the ones that I know have been discussed). It's not a promise to do these (I, for one, think challenge/response systems are a bad idea). It's also not a promise to do nothing but these.11 I would hate to side-track the discussion into the merits of each of these. I'm just responding to Greg's question about why there's room for expansion here. -- Jim Lyon From owner-ietf-mxcomp@mail.imc.org Thu Jun 17 21:15:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02826 for ; Thu, 17 Jun 2004 21:15:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5I16jMc067190; Thu, 17 Jun 2004 18:06:45 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5I16jM2067189; Thu, 17 Jun 2004 18:06:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from imo-d06.mx.aol.com (imo-d06.mx.aol.com [205.188.157.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5I16isE067182 for ; Thu, 17 Jun 2004 18:06:44 -0700 (PDT) (envelope-from CDHutzler@aol.com) Received: from CDHutzler@aol.com by imo-d06.mx.aol.com (mail_out_v37_r2.6.) id u.45.e8a57fb (15886); Thu, 17 Jun 2004 21:06:37 -0400 (EDT) Received: from aol.com (dhcp180-190-33.office.aol.com [10.180.190.33]) by air-id08.mx.aol.com (v99_r4.8) with ESMTP id MAILINID81-3e0e40d2401c193; Thu, 17 Jun 2004 21:06:37 -0400 Message-ID: <40D2401C.7020906@aol.com> Date: Thu, 17 Jun 2004 21:06:36 -0400 From: Carl Hutzler User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jimlyon@exchange.microsoft.com CC: Greg Connor , IETF-MXCOMP Subject: Re: On Extensibility in MARID Records References: <81AC085044D04B429F5FB883D94FA1AF42A648@df-fido-msg.exchange.corp.microsoft.com> In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF42A648@df-fido-msg.exchange.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 10.180.190.33 X-Mailer: Unknown (No Version) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit These make sense as examples of future directions, at least to a layman like me. I know I am working on #3 and other standard abuse reporting techniques as we speak. Not endorsing one or the other, but we should have a way to augment our Version 1.0 standards. -Carl jimlyon@exchange.microsoft.com wrote: >Greg Connor wrote: > > >>Also, did you want to say a few words about other things that >>might go in _ep besides out nodes? Now would be a good time >>to bring that up too if so. >> >> > >Things that I have considered in this space include: > >1. For incoming mail, the nature and difficulty of computational > puzzles that the domain respects as indicative of non-spammy > behavior. > >2. For challenge/response systems, information about the nature of > challenges that might be respected by the domain. > >3. Information about where and how to complain about mail sent by > the domain. (Arguably, this might be part of ). > >4. For the benefit of MUAs in the domain, information about how to > locate a message's Received header that was added when the > message entered the domain. (Could be used to enable MUAs to > perform MARID checks, instead of relying on MTAs to do it.) > >5. Should opportunistic encryption ever become big, statements > about what is supported. > >Each of these is quite small. (1) would probably contain a small >identifier and an integer. (2) would contain just a small identifier. >(3) would probably contain just an email address (or possibly a URL). >(4) would contain a small string. (5) may just be a boolean. It would >be a rare domain that published all five of these, and I'd be very >surprised if the total XML bytes for all of these ever exceeded 100 >bytes. > >These are examples of possibilities (the ones that I know have been >discussed). It's not a promise to do these (I, for one, think >challenge/response systems are a bad idea). It's also not a promise to >do nothing but these.11 > >I would hate to side-track the discussion into the merits of each of >these. I'm just responding to Greg's question about why there's room >for expansion here. > >-- Jim Lyon > > > -- Carl Hutzler Director, AntiSpam Operations America Online Mail Operations cdhutzler@aol.com 703.265.5521 work 703.915.6862 cell From owner-ietf-mxcomp@mail.imc.org Fri Jun 18 03:02:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02116 for ; Fri, 18 Jun 2004 03:02:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5I6hPVM050366; Thu, 17 Jun 2004 23:43:25 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5I6hP40050365; Thu, 17 Jun 2004 23:43:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tom.iecc.com (tom.iecc.com [208.31.42.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5I6hOAY050342 for ; Thu, 17 Jun 2004 23:43:24 -0700 (PDT) (envelope-from johnl@iecc.com) Received: (qmail 10885 invoked from network); 18 Jun 2004 06:43:23 -0000 Received: (ofmipd 127.0.0.1); 18 Jun 2004 06:43:01 -0000 Date: 18 Jun 2004 02:43:23 -0400 Message-ID: From: "John R Levine" To: "Jim Lyon" Cc: "IETF-MXCOMP" Subject: RE: Against Extensibility in MARID Records In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF42A63A@df-fido-msg.exchange.corp.microsoft.com> References: <81AC085044D04B429F5FB883D94FA1AF42A63A@df-fido-msg.exchange.corp.microsoft.com> Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > In arguing against extensibility, John Levine argues that it's a bad > thing (he used the word "chaotic") to have information in a MARID record > that is not understood by everyone. That's not what I said or what I meant, although I can see how you might have misread it to say that. What I meant is that it's a bad thing to have info in the record that doesn't have a consistent and well understood meaning. The goal of MARID, the last time I checked, is to do authentication: "mail with these characteristics really is from us." SPF and its descendants are well specified, and every MTA that looks up Sender ID data will use it the same way to verify whether a message matches a domain's rules. The proposed extensions I've seen are about reputation "here's why you should accept our mail", or inbound requirements "here's how you can persuade us to accept your mail", with a few items private to a domain "here's how MUAs within our network can decode headers added by our MTA." It strikes me as poor design to smoosh all that together. We are just beginning to understand reputation systems, but one thing that's clear to me that reputation will mostly be vouched for by third parties, and there's little a domain can say on its own behalf beyond "look at what these guys say about us." Inbound requirements are certainly an interesting area to think about, but I see no reason to put them in the same database as MARID. They're looked up by senders, not recipients, and keyed on RCPT TO or header To: and Cc: addresses, not the addresses that MARID uses. Is there an operational benefit to putting them in the same record? Not that I can see. Private domain info is yet a third separate area, again looked up differently. My MTA delivers mail for a lot of different domains into overlapping sets of mailboxes, and if I were looking up internal stuff, I'd want to key it by POP mailbox name, not incoming domain. Does it belong in the same record as MARID? Again, I don't see any advantage to doing so. > PS: John also continues the misconception that anything that uses XML > will be big enough to require DNS TCP. Once again, I didn't say that, and I have to say I don't understand this point. On the one hand I see an argument that we need to be able to load arbitrarily much stuff into a MARID record, and now it seems like you're saying that in fact nobody will do that. If you plan to load all of your spam related info into the MARID record, the record will get big, and you have to be prepared to face the consequences of needing vastly more TCP DNS transactions than before, unless you're saying that there'll be so few of them that recipients can just ignore any MARID records that don't fit. If the record is indeed too big for UDP, I hope it's obvious to everyone here why following a pointer to a URL is the same speed as falling back to DNS TCP. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor "I dropped the toothpaste", said Tom, crestfallenly. From owner-ietf-mxcomp@mail.imc.org Fri Jun 18 03:09:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02375 for ; Fri, 18 Jun 2004 03:09:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5I6rn2X055361; Thu, 17 Jun 2004 23:53:49 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5I6rn2G055360; Thu, 17 Jun 2004 23:53:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ernie.mail-abuse.org (Ernie.mail-abuse.org [168.61.5.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5I6rnHA055300 for ; Thu, 17 Jun 2004 23:53:49 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.mail-abuse.org (DDev.mail-abuse.org [168.61.10.124]) by ernie.mail-abuse.org (8.12.0.Beta19/8.12.0) with ESMTP id i5I6rfPQ002611; Thu, 17 Jun 2004 23:53:41 -0700 (PDT) Subject: RE: On Extensibility in MARID Records From: Douglas Otis To: Jim Lyon Cc: Greg Connor , IETF-MXCOMP In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF42A648@df-fido-msg.exchange.corp.microsoft.com> References: <81AC085044D04B429F5FB883D94FA1AF42A648@df-fido-msg.exchange.corp.microsoft.com> Content-Type: text/plain Message-Id: <1087541621.769.386.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 17 Jun 2004 23:53:41 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2004-06-17 at 17:54, Jim Lyon wrote: > Greg Connor wrote: > > Also, did you want to say a few words about other things that > > might go in _ep besides out nodes? Now would be a good time > > to bring that up too if so. The entire DNS response should be kept less than 512 bytes. If an average organization uses 3 services sending mail on their behalf, and has two out-bound SMTP servers where, for redundancy reasons, the two servers are located in different locations, then as a result, the macro definitions are of no value. Limiting syntax to using a single character to declare a string and one to terminate with dots and slash, the two addresses will require 40 bytes (20 bytes each for IPv4). Should these outside services have names similar to yours, then these names will require 72 characters where again a single character declares a domain and one terminates. Add one more character to declare the nature of this list such as open or closed. This then requires 121 characters of minimal but readable text. The added label of _ep. will add 4 bytes, the header, QTYPE and QCLASS add another 16 bytes, the answer will add 12 bytes of overhead for 32 bytes. With a domain name of 24 bytes again, this brings the total to 56 bytes or 335 bytes to spare. If the design allowed for increased name size due to things like PunyCode encoding unicode, allowing for one-half a maximal size for these 4 names, there would be 128+4, 128+2, 128+2, 128+2, 20, 20, 32 or 594 bytes. The estimate of available space depends heavily upon the size of the names. Please note these numbers assume the a minimum readable syntax for encoding. Using this minimal syntax, starting from 456 bytes and 24 byte names allows 21 address specs or 18 names (more depending upon use of macro expansion). If these names grow to 20% of the maximal, then this could allow 20 address specs or 7 names. Should this size consider DNSSEC? How much on average will be left after a greater effort is made to enable all valid domains to send mail on behalf of large organizations? The recursion limits for these queries have been removed it would appear, and for each of these new domains, a new set of queries becomes required. SPF had this limit set to 20. Can this be expected to happen with mail in transit? This type of processing of mail will not be reasonable where much of the mail comes from large and complex domains using large TXT records. This will quickly total more traffic than mail being checked. Does checking at the "from" domain really make sense? If this checking is done after mail has been delivered, then the veracity of the information is highly questionable in terms of tracking the source and the damage has been already done in terms of wasting time and bandwidth. > Things that I have considered in this space include: The space that is claimed to be available will be consumed by perhaps a 60 byte XML namespace declaration. This is to allow vendors the ability to "innovate" and there would be no review of these declarations or associated payload. (A very bad idea in my view.) In the one-tenth possible name size example, this then leaves 275 bytes. Again this does not consider the three to four times then number of characters needed to declare and terminate strings using XML which adds about 40 more bytes to this, leaving 235 bytes. Should this be a larger organization then these remaining bytes are used and, of course, another record will be specified to continue an already long chain of queries. > 1. For incoming mail, the nature and difficulty of computational > puzzles that the domain respects as indicative of non-spammy > behavior. Does this mean increase the overhead of handling a message? > 2. For challenge/response systems, information about the nature of > challenges that might be respected by the domain. Is this needed if the MTA has been authenticated? > 3. Information about where and how to complain about mail sent by > the domain. (Arguably, this might be part of ). You mean they don't read their abuse@ or postmaster@ mail? It has been spammed to death? Add yet another address to ignore? > 4. For the benefit of MUAs in the domain, information about how to > locate a message's Received header that was added when the > message entered the domain. (Could be used to enable MUAs to > perform MARID checks, instead of relying on MTAs to do it.) Could this be standardized? I would not expect many MTAs to run these MARID checks as spammers will happily bring those that do to their knees. > 5. Should opportunistic encryption ever become big, statements > about what is supported. I still like the idea of using an SRV record for this service as described in: http://www.ietf.org/internet-drafts/draft-fenton-identified-mail-00.txt In fact, unlike a dubious claim of being able to verify a user, this in fact does. It can do it with two queries by the MUA that can be easily cached locally. I would be very happy to see this service this available. What do you think? It does not break everyone's mail services or force them to change their mail address every time they obtain different access. > Each of these is quite small. (1) would probably contain a small > identifier and an integer. It could then be done twenty different ways, but dominance would help dictate this direction. : ) > (2) would contain just a small identifier. What? Is this to side-step SMTP protocols? > (3) would probably contain just an email address (or possibly a URL). Like nobody@? Again standardization would be better, but this will not work until the MTAs are authenticated. I doubt this scheme will ever be useful in that respect however. > (4) would contain a small string. (5) may just be a boolean. It would > be a rare domain that published all five of these, and I'd be very > surprised if the total XML bytes for all of these ever exceeded 100 > bytes. Don't wait. Specify it now so this is not kludged in later. Okay, now you pick two and then the next vendor picks a different two. These great innovations don't fit without expecting these records to chain and chain and chain and chain and chain and chain and chain and chain... You know I think this should be standalone='yes', bar all external definitions and use a single token as a virtual header. Better still, don't use XML. Don't use TXT. Use an SRV record to authenticate the MTA. If you want to allow positive identification of the sender, use an SRV record to find the key server as with the Fenton proposal. -Doug From owner-ietf-mxcomp@mail.imc.org Fri Jun 18 04:39:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06575 for ; Fri, 18 Jun 2004 04:39:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5I8GQtV090268; Fri, 18 Jun 2004 01:16:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5I8GQWq090266; Fri, 18 Jun 2004 01:16:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (catinthebox.net [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5I8GPP1090249 for ; Fri, 18 Jun 2004 01:16:25 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Fri, 18 Jun 2004 04:19:57 -0400 Received: from ([68.223.169.60]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 1357444485; Fri, 18 Jun 2004 04:19:55 -0400 Message-ID: <008801c4550d$825e4b10$6401a8c0@hdev1> From: "Hector Santos" To: "Jim Lyon" , "John T Levine" , "IETF-MXCOMP" References: <81AC085044D04B429F5FB883D94FA1AF42A63A@df-fido-msg.exchange.corp.microsoft.com> Subject: Re: Against Extensibility in MARID Records Date: Fri, 18 Jun 2004 04:23:14 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.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: Content-Transfer-Encoding: 7bit Jim, you raise a few key issues I have with the extension concept. o Possible 3rd party or Microsoft proprietary or undocumented extensions: o Transport vs. Application/Admin Level MARID feature/extension set: I would like to state that I support XML for MARID. But I hope you can consider my professional opinion on all this. I will express both concerns in detail. o Possible 3rd party or Microsoft proprietary or undocumented extensions: This one presents what I believe is an ethical and moral business dilemma. I believe in a concept I call "CoComp" - for Cooperative Competition. It relates to the usage of common and standard technology that is standard at a certain level but also allows for proprietary extensions that will not break the standard usage yet offers a vendor a way to distinguish themselves. I presented this CoComp concept in a 1992/93 talk at the first (or 2nd) ONE ISP CON trade show introducing a XML-like format (although not called XML back then) for a common mail storage and transport format between the hundreds of so mail products and the many different formats a product had to support between heterogeneous mail networks. This was before the Internet Email finally trumped all existing mail systems and formats at the time and rapidly became the industry standard. As a Windows shop, I've been involved with the Windows platform since its inception. On the positive side, it should go without saying the history of Microsoft has been to assist the ISV market to move forward in supporting the Windows platform by providing "tools," in particular helper APIs. On the negative side, there is a history of new feature sets that were either initially proprietary or undocumented. This is one of the main reasons why we do most of our tools requirement in-house is so that we are not strategically dependent on specific items under Microsoft control. Since you are involved in the development of Exchange, I don't think I will be completely off based for you to have natural tendency and competitive instinct to explore and implement new ideas that may make the Exchange product work better than the competition. In fact, it would expected of you and based on the way the Microsoft patent disclosures has grown, this could be an concern. But others can do the same too. We can come up with an extension only our servers understand. So I am believer in the CoComp concept, yet I can't help thinking XML will promote this concept for MARID. Proprietary Extensions from Microsoft or other vendors could be used as the differential factor between products. And of course, since Microsoft is the MCEP inventor and major promoter, I have a concern that this can be used against other smaller vendors. I sincerely hope you can understand this concern. Please realized that I believe Microsoft and all others have a natural right to do this and if everyone thinks this is "ok" for MARID where proprietary extensions promotes usage, then I am all for it. But it should be well noted that it may will happen with an extensions concept. MARID XML will promote extensions that may only work within certain product lines which brings me to my final point or concern. o Transport vs. Application/Admin Level MARID feature/extension set: Since the day we started the Anti-Spam research early 2003 to finally address the abusive spoofing of mail, I began with my first time participation in the IETF mail forum./discussion areas. It was my hope to be part of the new direction and help, assist and provide input where I can. It didn't take long to see what I believe was a fundamental difference in the philosophical positions many took on how Anti-Spam technology should be designed and even implemented in current products. I wish to strongly state that I wish no one take the following the wrong way. I mean no ill intent or categorization. I just wish to highlight what I believe is very important because this key difference in product operation philosophy is what's driven much of the design thinking in many mail/anti-spam forums with participants from a wide range of disciplines, including here in my opinion. The Dynamic vs. Post SMTP operations people run is one of the key differences driving or molding the thinking, the debates, the discussions and designs ideas to address the problem. If you are running a mail operation where mail analysis and/or extensions are only possible in a POST SMTP manner, you will have a philosophical different mindset than the person who is running a mail operation where mail analysis and/or extensions can be dynamically performed at the SMTP transport level. How is this related to MARID and Extensions? Well, MCEP has a POST SMTP dependency in order to work right because of its high RFC 2822 requirements. While a mail system can also support MCEP dynamically by performing the mail analysis at the DATA stage, this has a major design change implication at SMTP and it also can impact performance and scalaribility due to increase payloads. I view POST SMTP analysis as a Application or Admin level methodology where non-transport or 2822 entities are just one part of the total MARID package. Similarly, when it comes to extensions, such as this Report Generator extension concept, I also believe this is an Application or Admin level methodology. Not a SMTP level concept. So my concern is that MARID extensions can be used to force a design requirement that may not be appropriate at one level or another. Lets use the report extension that is used commonly for illustration. I believe IBM was used as an example for the desirable MARID behavior using the report extension. At SMTP, a MARID client processes a transaction where the RFC 2821 envelope information points to an obvious spoof and also MARID policy that will reject the transaction because the IP is not correct. A report is requested. Example: IP 1.2.3.4 HELO winserver.com MAIL FROM: tom@ibm.com In this example, the HELO domain is spoofed. winserver.com is our domain. The IP is not ours. This is an immediate transport level rejection. However, to follow MARID, the IBM.COM has a MARID domain policy that request a report to be sent to IBM help IBM track the abused email addresses. This level of reporting is outside the whelm of SMTP requirements. The application level report generation is now imposed on the SMTP client. Besides the fact there is more overhead to obtain the report type or format or extension that provides a report template, in this case, SMTP has a obvious transaction rejection that should not require any more processing. My main point here is whatever extensions are invented we need to make sure that the functionality of the extension is well placed within or separated from SMTP design requirements. How you agree with this or not depends largely on your philosophy or current mode of operation that I was describing above. If you are running a POST SMTP system, then this isn't so much of an issue and in this case, I will 100% agree because the report functionality is now appropriately located in the right system component location - outside the transport. A very nice report can be generated with all the time in world to produce it. But if you are running a system that is performing dynamic SMTP validations, this particular report extension is conflictive with SMTP product design and operation. I can understand Microsoft design is to use POST operations for total validation. So extensions are more affordable - outside the SMTP transport. Your point of view is well understand - from a Application Design standpoint. But for product like ours, it is a system design dilemma. Don't take me wrong. I am looking for a solution to all this. But extensions need to be clearly defined and separated per system vs application component. You use EHLO for example All extended features are for SMTP. Not outside of SMTP. You use HTTP request commands. Its all within the HTTP protocol. It is all clearly defined on where the extensions are used. That is not to say an extension obtained at the transport level can not be used to trigger post protocol operations. But for this need, where in my view, it is highly desirable to block the high rate of spammers at the transport level, extensions such as "reporting" may not be possible or less supported. -- Hector ----- Original Message ----- From: "Jim Lyon" To: "John T Levine" ; "IETF-MXCOMP" Sent: Thursday, June 17, 2004 8:36 PM Subject: RE: Against Extensibility in MARID Records > > In arguing against extensibility, John Levine argues that it's a bad > thing (he used the word "chaotic") to have information in a MARID record > that is not understood by everyone. > > To rebut this, I note that substantially every successful data format > and protocol contains buckets for information that isn't globally > understood. For example, consider headers in RFC 2822 mail messages. > The general ethos is that if you see a message that contains a header > you don't understand, you just ignore it. Without this ethos, many > useful extensions (MIME, for example) would have been impossible. > > A similar story applies to the headers in HTTP. Without the ethos of > ignoring what you don't understand, many commonly used features would > have been impossible. > > Similarly, in RFC 2821, responses to EHLO contain a list of extensions, > many of which the client doesn't understand. Again, the ethos is that > you completely ignore anything you don't understand. Doing so is > exactly what enables SMTP extensions. > > Or look at DNS. In a DNS packet, there's only a single unassigned bit, > and some deployed DNS software gets pissed off if it's not zero. This > fact, more than any other, has hampered attempts to expand the DNS > protocol. > > Or look at the difference between ASN-1 and XML. ASN-1 can describe > anything for which the entire schema is known in advance, but it's hard > to extend a schema after the fact. XML, on the other hand, has the > clear ability to carry goo whose semantics are not known by older code. > Guess which has been more successful. > > Given that we *know* that we'll need more information in the future > (most of us are here to reduce spam, not just authenticate MTAs), it > behooves us to plan the extensibility now. SPF's current modifiers are > a step in the right direction (they have the ignore what you don't > understand ethos), but as I've argued elsewhere, they aren't sufficient. > > The reason they're not sufficient has to do with cases where you need to > attach new pieces of information to particular SPF mechanisms; SPF > merely gives you a way to attach new information to the whole record. > For this same reason, John's suggestion of just having a pointer to a > separate XML document isn't sufficient, either. > > -- Jim Lyon > > PS: John also continues the misconception that anything that uses XML > will be big enough to require DNS TCP. This just isn't true. It looks > like most XML-encoded stuff runs about 20% bigger than SPF-encoded > stuff. The size concern might be persuasive if typical SPF records were > pushing 400 bytes, but they're not. They're usually around 50 bytes. > The number of characters in the XML framing is just not that big an > issue. When you're spending 18 bytes to represent an address range, it > just doesn't matter that much whether you frame it with "+a:" and space, > or with "" and "". > > From owner-ietf-mxcomp@mail.imc.org Fri Jun 18 08:26:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16739 for ; Fri, 18 Jun 2004 08:26:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ICCHc2073707; Fri, 18 Jun 2004 05:12:17 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5ICCHIo073706; Fri, 18 Jun 2004 05:12:17 -0700 (PDT) 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.9) with ESMTP id i5ICCFgh073698 for ; Fri, 18 Jun 2004 05:12:16 -0700 (PDT) (envelope-from cm--jrk@merseymail.com) Received: from mmail by argon.connect.org.uk with local (connectmail/exim) id 1BbIEC-0000FU-QA; Fri, 18 Jun 2004 13:12:16 +0100 Subject: RE: Alternative to TXT or new RR To: "Bill Mcinnis" From: "Jon Kyme" Cc: ietf-mxcomp@imc.org X-Mailer: [ConnectMail 3.15.6] X-connectmail-Originating-IP: 172.25.243.3 Message-Id: Date: Fri, 18 Jun 2004 13:12:16 +0100 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Given the nature of what we are working on, we need to know who has the > White Paper and how to get in touch with them aside from email. What is > your objection to registering for it? Would you like me to mail it to > you directly? > No, thank you. Incidentally, wasn't it suggested that asrg would be more interested in your scheme? This group's charter has more to do with authorisation than authentication. From owner-ietf-mxcomp@mail.imc.org Fri Jun 18 11:37:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00697 for ; Fri, 18 Jun 2004 11:37:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5IFMnMR012507; Fri, 18 Jun 2004 08:22:49 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5IFMnC7012506; Fri, 18 Jun 2004 08:22:49 -0700 (PDT) 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.9) with ESMTP id i5IFMmRQ012490 for ; Fri, 18 Jun 2004 08:22:49 -0700 (PDT) (envelope-from cm--jrk@merseymail.com) Received: from mmail by argon.connect.org.uk with local (connectmail/exim) id 1BbLCa-0005tn-EG; Fri, 18 Jun 2004 16:22:48 +0100 In-Reply-To: <7DF9D69B5FC4BB449AEFA3B1CCF7BF350D3E9E@exchange.rdcim.com> Subject: RE: Alternative to TXT or new RR To: "Bill Mcinnis" From: "Jon Kyme" Cc: ietf-mxcomp@imc.org X-Mailer: [ConnectMail 3.15.6] X-connectmail-Originating-IP: 172.25.243.3 Message-Id: Date: Fri, 18 Jun 2004 16:22:48 +0100 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Bill Mcinnis wrote: > I think what we are working on falls into the authorization part of this > charter, unless I have that defined wrong. Could someone please explain > the difference as you all see it just so I am clear. Again, I am trying > to find the right place to go with this and keep getting shot down. It > is frustrating because while you all are talking about getting working > code, we already have it. > AFAIK "Message Level Authentication", is concerned with answering "the fundamental question plaguing email today: 'Did you really send me this email?'", whereas this group has a charter to come up with a mechanism to enable "those maintaining domains and networks [...] to specify that individual hosts or nodes are authorized to act as MTAs for messages sent from those domains or networks" This difference may be easier to understand if you consider how you'd use either system *without* a message in hand: MARID: Q. domain name, IP A. Yes | No Message Level Authentication: Q. Did you really send me this email? A. What email? What are you on about? Are you on drugs? Regards, JRK From owner-ietf-mxcomp@mail.imc.org Fri Jun 18 12:07:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02825 for ; Fri, 18 Jun 2004 12:07:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5IFvjTl019100; Fri, 18 Jun 2004 08:57:45 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5IFvjjn019099; Fri, 18 Jun 2004 08:57:45 -0700 (PDT) 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.9) with ESMTP id i5IFviRW019092 for ; Fri, 18 Jun 2004 08:57:45 -0700 (PDT) (envelope-from cm--jrk@merseymail.com) Received: from mmail by argon.connect.org.uk with local (connectmail/exim) id 1BbLkR-0006mu-Jx; Fri, 18 Jun 2004 16:57:47 +0100 In-Reply-To: <7DF9D69B5FC4BB449AEFA3B1CCF7BF350D3EA3@exchange.rdcim.com> Subject: RE: Alternative to TXT or new RR To: "Bill Mcinnis" From: "Jon Kyme" Cc: ietf-mxcomp@imc.org X-Mailer: [ConnectMail 3.15.6] X-connectmail-Originating-IP: 172.25.243.3 Message-Id: Date: Fri, 18 Jun 2004 16:57:47 +0100 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > why not have a mechanism that can sit on their domain and > verify to those asking if a message came from their domain or network Why not indeed, however, a mechanism for answering that question probably isn't in scope here. From owner-ietf-mxcomp@mail.imc.org Fri Jun 18 13:05:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05404 for ; Fri, 18 Jun 2004 13:05:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5IGnUJO029401; Fri, 18 Jun 2004 09:49:30 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5IGnU95029400; Fri, 18 Jun 2004 09:49:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5IGnTTv029392 for ; Fri, 18 Jun 2004 09:49:29 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 18 Jun 2004 09:49:30 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 18 Jun 2004 09:49:30 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 18 Jun 2004 09:49:30 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Against Extensibility in MARID Records Date: Fri, 18 Jun 2004 09:49:22 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF42A6DD@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: Against Extensibility in MARID Records thread-index: AcRU/4aLJibVFA0DS7mCzhfRR0/t0AAUAB2w From: "Jim Lyon" To: "John R Levine" Cc: "IETF-MXCOMP" X-OriginalArrivalTime: 18 Jun 2004 16:49:30.0430 (UTC) FILETIME=[398BE5E0:01C45554] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5IGnTTv029395 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I said: > In arguing against extensibility, John Levine argues that it's a bad > thing (he used the word "chaotic") to have information in a MARID record > that is not understood by everyone. In response, John said: > That's not what I said or what I meant, although I can see how you > might have misread it to say that. What I meant is that it's a bad > thing to have info in the record that doesn't have a consistent and > well understood meaning. I'm sorry I misunderstood you. Yes, we definitely want to be in a world where if a domain publishes something, everyone who understands it arrives at the same meaning (including the publisher). My premise is that XML is well-tailored to making this possible. John said: > The proposed extensions I've seen are about reputation "here's why > you should accept our mail", or inbound requirements "here's how > you can persuade us to accept your mail", with a few items private > to a domain "here's how MUAs within our network can decode headers > added by our MTA." It strikes me as poor design to smoosh all that > together. Your argument has some merit with respect to mushing these categories together, and I could be persuaded that separate documents make more sense. However, I submit that the authentication stuff this group is working on is just a subpart of "here's why you should accept our mail". Furthermore, the reputation part of "here's why you should accept our mail" is in many cases going to be intimately intertwined with where the mail came from. Separating these will do more harm than good. Let me illustrate by way of an example. Suppose I have a small domain with no reputation. Suppose I'm a customer of both MSN and Comcast, and I send some of my outbound mail through MSN's mail servers, and some through Comcast's mail servers. As things currently stand, I'd publish a MARID record like: v=spf1 +indirect:msn.com +indirect:comcast.com -all This authenticates me very well (assuming that MSN and Comcast each do a sufficient job of policing their internal networks to keep other customers from masquerading as me). When we get into the question of reputation, the argument goes something like: If you get mail from me through MSN's mail servers, you should believe it's not spam because MSN does a good job of keeping its customers from sending spam. Similarly, if you get mail from me through Comcasts's mail servers. The degree to which you as a receiver believe my mail is not spam is exactly a function of one of my ISP's reputations. Using invented syntax, I could say something like: v=spf1 +indirect:msn.com/targetrep +indirect:comcast.com/targetrep -all which gets the point across nicely. Contrast this with the case of hotmail's record. Hotmail has more address ranges for outgoing servers than fits into a single DNS record, even using SPF syntax. So they publish something like: v=spf1 +indirect:a.hotmail.com +indirect:b.hotmail.com +indirect:c.hotmail.com -all In this case, the indirections are a mere implementation detail, and receivers shouldn't attempt to read anything into the fact that they received a message from the "b" list of servers instead of the "a" list. In short: 1. "Here's how you can persuade us to accept your mail" and "here's stuff for the benefit of people inside my domain" *are* separable. 2. "Here's why you should accept mail from us" and "Here's how to tell whether it's really me" are seriously intertwined. 3. Today's SPF syntax isn't rich enough to adequately capture that intertwining. XML is. 4. The XML world has lots of facilities to help two parties determine which fragments of a record they're speaking the same language on. -- Jim Lyon PS: John also said: > If the record is indeed too big for UDP, I hope it's obvious > to everyone here why following a pointer to a URL is the same > speed as falling back to DNS TCP. On this point, I 100% agree. From owner-ietf-mxcomp@mail.imc.org Fri Jun 18 13:20:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05951 for ; Fri, 18 Jun 2004 13:20:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5IH8niX033996; Fri, 18 Jun 2004 10:08:49 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5IH8nAK033995; Fri, 18 Jun 2004 10:08:49 -0700 (PDT) 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.9) with ESMTP id i5IH8m7p033980 for ; Fri, 18 Jun 2004 10:08:48 -0700 (PDT) (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 i5IH8kOw007196; Fri, 18 Jun 2004 10:08:46 -0700 (PDT) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Fri, 18 Jun 2004 10:08:46 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Hector Santos'" , Jim Lyon , John T Levine , IETF-MXCOMP Subject: RE: Against Extensibility in MARID Records Date: Fri, 18 Jun 2004 10:08:38 -0700 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: > o Possible 3rd party or Microsoft proprietary or undocumented > extensions: > > This one presents what I believe is an ethical and moral > business dilemma. I think it represents an oppotunity. I was speaking to Vint the other day about the early days of the Internet. The model then was experiment, deploy, write up the results. NOTHING in the original intent of the founders of the IETF was meant to discourage ANY party from experimentation. The model you appear to be advocating here is discuss, agree the standard, get permission, see if it works. That was the OSI model. Given the application, I cannot see how anyone could insert information into their DNS that would be relevant in the MARID context if it were undocumented or was not widely supported. From owner-ietf-mxcomp@mail.imc.org Fri Jun 18 13:32:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06922 for ; Fri, 18 Jun 2004 13:32:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5IHDPjG035123; Fri, 18 Jun 2004 10:13:25 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5IHDPWc035122; Fri, 18 Jun 2004 10:13:25 -0700 (PDT) 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.9) with ESMTP id i5IHDOM5035107 for ; Fri, 18 Jun 2004 10:13:24 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i5IHDQhX009125; Fri, 18 Jun 2004 10:13:26 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Fri, 18 Jun 2004 10:13:26 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Jon Kyme'" , Bill Mcinnis Cc: ietf-mxcomp@imc.org Subject: RE: Alternative to TXT or new RR Date: Fri, 18 Jun 2004 10:13:23 -0700 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: > > why not have a mechanism that can sit on their domain and > > verify to those asking if a message came from their domain > or network > > Why not indeed, however, a mechanism for answering that > question probably > isn't in scope here. We need some form of reporting function for exceptions. If my site is being phished I would like to be told. "Got message serial # wqwqkjwheqwekjh, failed MARID verification" "Thank you" or "Oh that was genuine, must be a relay" Should consider this at recharter time. From owner-ietf-mxcomp@mail.imc.org Fri Jun 18 13:48:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07811 for ; Fri, 18 Jun 2004 13:48:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5IHVj6b039355; Fri, 18 Jun 2004 10:31:45 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5IHVj7f039354; Fri, 18 Jun 2004 10:31:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5IHVjOc039348 for ; Fri, 18 Jun 2004 10:31:45 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 18 Jun 2004 10:31:48 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 18 Jun 2004 10:31:48 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 18 Jun 2004 10:31:48 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: On Extensibility in MARID Records Date: Fri, 18 Jun 2004 10:31:40 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF42A715@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: On Extensibility in MARID Records thread-index: AcRVAQK4rbO0BW7UTxKpAfbieziWAQAVGVBAAAAghMAAAHHC0A== From: "Jim Lyon" To: "Douglas Otis" Cc: "Greg Connor" , "IETF-MXCOMP" X-OriginalArrivalTime: 18 Jun 2004 17:31:48.0147 (UTC) FILETIME=[2224C830:01C4555A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5IHVjOc039349 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit In discussing record sizes, Doug Otis constructs an argument about how many address ranges or domain name references one could fit into a 512-byte DNS packet. Sumamrizing his numbers, and filling in the blanks from our actual proposals, we get: theoretical max SPF today XML as proposed --------------- --------- --------------- Address Ranges 21 20 17 Domain Names 18 17 14 While I think that Doug believes this damns XML syntax, it actually shows how reasonable XML syntax is. There are probably only a handful of domains on the face of the earth that send mail from more than 17 different address ranges. Since that handful constitutes the largest ISPs, any effort spent fetching their records (possibly through a couple of indirections) can be amortized over a large number of mail messages. (Doug's claims about bandwidth spent fetching records exceeding bandwidth spent receiving email fails on this point.) Doug then goes on with a bunch of calculations that show that, for typical sized organizations, they're nowhere close to the limit. He then says: > The space that is claimed to be available will be consumed by > perhaps a 60 byte XML namespace declaration. This is to allow > vendors the ability to "innovate" and there would be no review > of these declarations or associated payload. (A very bad idea > in my view.) and later > Okay, now you pick two and then the next vendor picks a different > two. These great innovations don't fit without expecting these > records to chain and chain and chain and chain and chain and > chain and chain and chain... This shows several misconceptions: 1. Vendors don't force anyone to publish any extensions. If there are vendor-promulgated extensions, presumably a domain will only publish a record that uses them if that domain sees some value in it. 2. The current spec is carefully written to allow IETF-standardized extensions with no penalty. This sounds like the right balance of burdens to me: the standard way is cheap, and the non- standard way costs. 3. Regardless of what happens in this debate, there *will* be extensions. A domain that decides it's useful to publish the night-shift janitor's Hilbert number will stick night-shift-janitors-Hilbert-number=7 onto the back of their SPF record. No standard can keep this from happening. Indeed, domains experimenting with doing this is exactly what leads to follow-on standards. A major point of XML is that it provides a way for independent organizations to do this, *without needing to first coordinate with each other*. Doug then goes on to make a number of comments about other extensions I mentioned. To be very clear, I am NOT seriously proposing these extensions at this time. I do NOT believe that they are all useful. They're certainly NOT yet well thought-out. I merely brought them up in response to John Levine asking what kinds of extensions had been considered. -- jimbo From owner-ietf-mxcomp@mail.imc.org Fri Jun 18 14:02:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08311 for ; Fri, 18 Jun 2004 14:02:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5IHpl8Q043623; Fri, 18 Jun 2004 10:51:47 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5IHplrg043622; Fri, 18 Jun 2004 10:51:47 -0700 (PDT) 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.9) with ESMTP id i5IHpkRd043613 for ; Fri, 18 Jun 2004 10:51:46 -0700 (PDT) (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.34) id 1BbNWT-0008R8-2n for ietf-mxcomp@imc.org; Fri, 18 Jun 2004 12:51:47 -0500 To: "IETF MARID WG" References: <81AC085044D04B429F5FB883D94FA1AF42A6DD@df-fido-msg.exchange.corp.microsoft.com> From: wayne Date: Fri, 18 Jun 2004 12:51:28 -0500 In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF42A6DD@df-fido-msg.exchange.corp.microsoft.com> (Jim Lyon's message of "Fri, 18 Jun 2004 09:49:22 -0700") 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 (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: Against Extensibility in MARID Records Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-4.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: [offlist, and this time I remembered to remove the Reply-To: header that my MUA automatically adds.) In <81AC085044D04B429F5FB883D94FA1AF42A6DD@df-fido-msg.exchange.corp.microsoft.com> "Jim Lyon" writes: > Let me illustrate by way of an example. [snip] I think you may want to clean up this example a tiny amount and repost it to the thread that Marshall and Andy reserved for examples of what XML can represent, but can't be done in the SPF syntax. I remember you giving this example at the dinner during the interim meeting. It probably won't surprise you that I have considered it and found the argument lacking. After all, if I thought it was compelling, I wouldn't be arguing against XML. Mind you, it isn't the concept that I dislike, quite the opposite, I like it. I just don't see the need for XML. My argument against needing XML is: If a receiver is going to do that kind of checking, there isn't much reason to not do it automatically for all include: mechanisms. Yes, a reputation for a.hotmail.com may not exist, but then, maybe because of the way hotmail has devided up their MTAs between dialups or country, a.hotmail.com may be a much larger source of spam than b.hotmail.com. A spammer who publishes "v=spf1 include:optinrealbig.com -all" will almost certainly not say to check the target's reputation, but a receiver may find that very useful to check. > 1. "Here's how you can persuade us to accept your mail" and > "here's stuff for the benefit of people inside my domain" > *are* separable. Yep, I agree, although having a small pointer that says "oh, btw, if you are interested in this stuff, look here" can be useful. > 2. "Here's why you should accept mail from us" and "Here's how > to tell whether it's really me" are seriously intertwined. Agreed. > 3. Today's SPF syntax isn't rich enough to adequately capture > that intertwining. XML is. I disagree. > 4. The XML world has lots of facilities to help two parties > determine which fragments of a record they're speaking > the same language on. I agree with this. XML is a great tool for many things, but I don't think it is the best tool for the job here. > PS: John also said: >> If the record is indeed too big for UDP, I hope it's obvious >> to everyone here why following a pointer to a URL is the same >> speed as falling back to DNS TCP. > > On this point, I 100% agree. Actually, I think a serious of DNS lookups, especially if done in parallel, will be quicker than a single TCP transaction. The three-way handshake on startup and the four-way teardown really kill the performance of sending one large TCP packet. -wayne From owner-ietf-mxcomp@mail.imc.org Fri Jun 18 16:55:58 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21860 for ; Fri, 18 Jun 2004 16:55:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5IKhbA2069257; Fri, 18 Jun 2004 13:43:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5IKhbFZ069256; Fri, 18 Jun 2004 13:43:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from messagelevel.com ([208.253.112.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5IKha7T069250 for ; Fri, 18 Jun 2004 13:43:36 -0700 (PDT) (envelope-from bill.mcinnis@messagelevel.com) Date: Fri, 18 Jun 2004 16:43:39 -0400 Message-Id: <200406181643.AA294977624@messagelevel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 From: "Bill Mcinnis" Reply-To: To: Subject: RE: Alternative to TXT or new RR X-Mailer: X-Declude-Sender: bill.mcinnis@messagelevel.com [127.0.0.1] X-Note: This E-mail was scanned by Declude JunkMail (www.declude.com) for spam. X-Spam-Tests-Failed: None [0] X-Note: This E-mail was sent from ([127.0.0.1]). Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5IKha7T069251 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Reposting as it did not go out to the list Fair enough. I just wanted to explain why I popped my head up (potential IP issues with some of the things I have read recently), call out for those interested in helping with what we have developed and address your follow up questions/comments. Is there a group that this would fit into as the ASRG doesn’t seem to be a fit either? We seem to still be a few steps ahead, but things keep moving ever so closely in our direction. Jon, thank you very much for your comments and questions. Bill McInnis Messagelevel.com -----Original Message----- From: Jon Kyme [mailto:jrk@merseymail.com] Sent: Friday, June 18, 2004 11:58 AM To: Bill Mcinnis Cc: ietf-mxcomp@imc.org Subject: RE: Alternative to TXT or new RR > why not have a mechanism that can sit on their domain and verify to > those asking if a message came from their domain or network Why not indeed, however, a mechanism for answering that question probably isn't in scope here. ---- This outgoing message is guaranteed to be authentic by MessageLevel users. Guarantee the authenticity of your email @ http://www.messagelevel.com. From owner-ietf-mxcomp@mail.imc.org Fri Jun 18 16:57:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21919 for ; Fri, 18 Jun 2004 16:57:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5IKjP4J069422; Fri, 18 Jun 2004 13:45:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5IKjPde069421; Fri, 18 Jun 2004 13:45:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from messagelevel.com ([208.253.112.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5IKjPCX069415 for ; Fri, 18 Jun 2004 13:45:25 -0700 (PDT) (envelope-from bill.mcinnis@messagelevel.com) Date: Fri, 18 Jun 2004 16:45:20 -0400 Message-Id: <200406181645.AA375455906@messagelevel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: "Bill Mcinnis" Reply-To: To: Subject: RE: Alternative to TXT or new RR X-Mailer: X-Declude-Sender: bill.mcinnis@messagelevel.com [127.0.0.1] X-Note: This E-mail was scanned by Declude JunkMail (www.declude.com) for spam. X-Spam-Tests-Failed: None [0] X-Note: This E-mail was sent from ([127.0.0.1]). Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: We have already given thought to that and have reporting set up to see what failed the query on the sites we are beta-ing this between. Naturally it only works between sites that have it running. But, in the last 3 weeks alone we have stopped over 15,000 spoof attacks amongst the sites (people pretending to be one of the sites we have it running on and trying to email that site or one of the others in the network) with 0 false positives. Bill McInnis Messagelevel.com -----Original Message----- From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com] Sent: Friday, June 18, 2004 1:13 PM To: 'Jon Kyme'; Bill Mcinnis Cc: ietf-mxcomp@imc.org Subject: RE: Alternative to TXT or new RR > > why not have a mechanism that can sit on their domain and verify to > > those asking if a message came from their domain > or network > > Why not indeed, however, a mechanism for answering that question > probably isn't in scope here. We need some form of reporting function for exceptions. If my site is being phished I would like to be told. "Got message serial # wqwqkjwheqwekjh, failed MARID verification" "Thank you" or "Oh that was genuine, must be a relay" Should consider this at recharter time. ---- This outgoing message is guaranteed to be authentic by MessageLevel users. Guarantee the authenticity of your email @ http://www.messagelevel.com. From owner-ietf-mxcomp@mail.imc.org Fri Jun 18 16:58:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21940 for ; Fri, 18 Jun 2004 16:58:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5IKf62m069086; Fri, 18 Jun 2004 13:41:06 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5IKf69k069085; Fri, 18 Jun 2004 13:41:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from messagelevel.com ([208.253.112.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5IKf51d069078 for ; Fri, 18 Jun 2004 13:41:06 -0700 (PDT) (envelope-from bill.mcinnis@messagelevel.com) Date: Fri, 18 Jun 2004 16:40:37 -0400 Message-Id: <200406181640.AA186450036@messagelevel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 From: "Bill Mcinnis" Reply-To: To: X-Mailer: X-Declude-Sender: bill.mcinnis@messagelevel.com [127.0.0.1] X-Note: This E-mail was scanned by Declude JunkMail (www.declude.com) for spam. X-Spam-Tests-Failed: None [0] X-Note: This E-mail was sent from ([127.0.0.1]). Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5IKf61d069080 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Reposting as it did not go out to the list Again as I say/ask this with all respect Since those maintaining domains and networks know who can send and where it should come from, it seems the goal is to set up a mechanism for communicating that so others will know it when they receive a message, correct? The goal is to know whether a message did indeed come from that domain, correct? Simplistically speaking, since domains/networks know how they are configured, why not have a mechanism that can sit on their domain and verify to those asking if a message came from their domain or network rather than trying to explain their whole setup to everyone? Likewise for those receiving the message have a mechanism that does the same thing in reverse. (for full disclosure this process is also something we have patent claims and working code on) That way you don’t have to list all of your users, ips, basically diagram your whole network setup to everyone. It seems to me that is you make all of your users, specific ips, etc available for everyone to see and know more information about upon request, that may lead to security problems we haven't even thought of yet, least of which is every spammer having the ability to associate an email address with the appropriate ip, where as now for mass mailing of spoofs they would have to guess. Wouldn't people rather be able to say "yup, it came from me and that’s all you need to know, I'll keep the rest private thank you."? Again, this is all spoken with the utmost respect. Bill McInnis Messagelevel.com -----Original Message----- From: Jon Kyme [mailto:jrk@merseymail.com] Sent: Friday, June 18, 2004 11:23 AM To: Bill Mcinnis Cc: ietf-mxcomp@imc.org Subject: RE: Alternative to TXT or new RR Bill Mcinnis wrote: > I think what we are working on falls into the authorization part of > this charter, unless I have that defined wrong. Could someone please > explain the difference as you all see it just so I am clear. Again, I > am trying to find the right place to go with this and keep getting > shot down. It is frustrating because while you all are talking about > getting working code, we already have it. > AFAIK "Message Level Authentication", is concerned with answering "the fundamental question plaguing email today: 'Did you really send me this email?'", whereas this group has a charter to come up with a mechanism to enable "those maintaining domains and networks [...] to specify that individual hosts or nodes are authorized to act as MTAs for messages sent from those domains or networks" This difference may be easier to understand if you consider how you'd use either system *without* a message in hand: MARID: Q. domain name, IP A. Yes | No Message Level Authentication: Q. Did you really send me this email? A. What email? What are you on about? Are you on drugs? Regards, JRK ---- This outgoing message is guaranteed to be authentic by MessageLevel users. Guarantee the authenticity of your email @ http://www.messagelevel.com. From owner-ietf-mxcomp@mail.imc.org Fri Jun 18 17:15:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22938 for ; Fri, 18 Jun 2004 17:15:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5IL3VD4071687; Fri, 18 Jun 2004 14:03:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5IL3VVE071686; Fri, 18 Jun 2004 14:03:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ernie.mail-abuse.org (Ernie.mail-abuse.org [168.61.5.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5IL3Vmt071664 for ; Fri, 18 Jun 2004 14:03:31 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.mail-abuse.org (DDev.mail-abuse.org [168.61.10.124]) by ernie.mail-abuse.org (8.12.0.Beta19/8.12.0) with ESMTP id i5IL3VPQ019999 for ; Fri, 18 Jun 2004 14:03:31 -0700 (PDT) Subject: RE: On Extensibility in MARID Records From: Douglas Otis To: MARID In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF42A715@df-fido-msg.exchange.corp.microsoft.com> References: <81AC085044D04B429F5FB883D94FA1AF42A715@df-fido-msg.exchange.corp.microsoft.com> Content-Type: text/plain Message-Id: <1087592610.2002.73.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 18 Jun 2004 14:03:31 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2004-06-18 at 10:31, Jim Lyon wrote: > In discussing record sizes, Doug Otis constructs an argument about how > many address ranges or domain name references one could fit into a > 512-byte DNS packet. Sumamrizing his numbers, and filling in the blanks > from our actual proposals, we get: > > theoretical max SPF today XML as proposed > --------------- --------- --------------- > Address Ranges 21 20 17 > Domain Names 18 17 14 As I said, not all names have the same size, but it does show the mischief a single record could cause by invoking this number of redirects. > While I think that Doug believes this damns XML syntax, it actually > shows how reasonable XML syntax is. There are probably only a handful > of domains on the face of the earth that send mail from more than 17 > different address ranges. Since that handful constitutes the largest > ISPs, any effort spent fetching their records (possibly through a couple > of indirections) can be amortized over a large number of mail messages. > (Doug's claims about bandwidth spent fetching records exceeding > bandwidth spent receiving email fails on this point.) This fails to consider the number of queries required nor that only addresses would be referenced in these smaller organization. Just as these large mail sites will require sequential queries (this does become cached), those many smaller sites will have equally many reasons for also listing more than a single record to be retrieved. I use several mail addresses, but only have an ability to send from a few. If forced by closed lists, it may become the norm for each site to have more than one domain referenced in their record. Do you see a potential problem yet? Now you add the "report mechanism" and the "spy on remote users mechanism" and the "where to mail your problem" etc. These quickly become more records that will be linked in this nearly endless DNS chain of records. No one forced them to add this stuff, but it is for the consumer of this now serialized stone soup to consume. > Doug then goes on with a bunch of calculations that show that, for > typical sized organizations, they're nowhere close to the limit. This concept clearly goes beyond a reasonable limit. How can this mechanism be employed in transit if there is no consideration of the workload generated or the problems created? With many of these lists likely to remain open to prevent endless problems a closed list will cause, there will be no benefit whatsoever for those that provide mail service to consider implementing this expensive mechanism. > He then says: > > The space that is claimed to be available will be consumed by > > perhaps a 60 byte XML namespace declaration. This is to allow > > vendors the ability to "innovate" and there would be no review > > of these declarations or associated payload. (A very bad idea > > in my view.) > and later > > Okay, now you pick two and then the next vendor picks a different > > two. These great innovations don't fit without expecting these > > records to chain and chain and chain and chain and chain and > > chain and chain and chain... > > This shows several misconceptions: > > 1. Vendors don't force anyone to publish any extensions. If there > are vendor-promulgated extensions, presumably a domain will only > publish a record that uses them if that domain sees some value > in it. Consuming this serialized stuff will be where problems occur. Now that you made it well beyond any standards process to control, what is left but to abandon the entire mechanism. Might as well; it will never fly. > 2. The current spec is carefully written to allow IETF-standardized > extensions with no penalty. This sounds like the right balance > of burdens to me: the standard way is cheap, and the non- > standard way costs. So the standards process can dog-pile on as well as anyone else? > 3. Regardless of what happens in this debate, there *will* be > extensions. A domain that decides it's useful to publish > the night-shift janitor's Hilbert number will stick > night-shift-janitors-Hilbert-number=7 > onto the back of their SPF record. No standard can keep > this from happening. Indeed, domains experimenting with > doing this is exactly what leads to follow-on standards. > A major point of XML is that it provides a way for > independent organizations to do this, *without needing > to first coordinate with each other*. Use a SRV record and then no one will be "sticking" in anything that was not specified. How is this dog-pile is a good thing? If it becomes the norm for domains to include other domains in the description of outbound mail to accommodate desires of users to use their desired address, then even if these lists become expressed as closed, the query process may never converge. It will become an endless search for the next record. This then implies a need for search algorithms to handle great depths of recursion and redirection. Of course, a loop must be detected and there must be some limit assigned to a depth this process may extend. If I point to domain X because I have an mail address there, then I find they have pointed to six other domains because of their relationships, and each of these points to yet more domains, where does it end? Now you want to add to this by suggesting it is okay to grow these records to experiment and innovate without coordinating with any other vendor? This process accomplishes nothing if it is only somewhat possible at the MUA. It does not deter any of the common abuses nor does it allow any follow-up should there be a problem nor does it mitigate any of the damage. Again, the Fenton proposal for ensuring the identity of the user solves this problem in a much cleaner fashion. To prevent the abuse, authenticate the MTA using a simple SRV record. One well defined and controlled query one time per session. -Doug From owner-ietf-mxcomp@mail.imc.org Fri Jun 18 18:10:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26559 for ; Fri, 18 Jun 2004 18:10:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ILwoak082886; Fri, 18 Jun 2004 14:58:50 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5ILwoKZ082885; Fri, 18 Jun 2004 14:58:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ILwnY9082868 for ; Fri, 18 Jun 2004 14:58:49 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: NUjeQ9YvvKYcQ7pD7pw3Ew 1087595928 Received: from [192.168.1.141] (ns.nextbus.com [64.164.28.194]) by mail.messagingengine.com (Postfix) with ESMTP id 6C785C0C513; Fri, 18 Jun 2004 17:58:47 -0400 (EDT) Message-ID: <40D36596.6050907@elvey.com> Date: Fri, 18 Jun 2004 14:58:46 -0700 From: Matthew Elvey User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Leslie Cc: MXCOMP Subject: Re: CSV specification revision available References: <1665390638.20040614190711@brandenburg.com> <20040615031048.GP44160@verdi> <40CE9F08.2050002@elvey.com> <20040615115828.GQ44160@verdi> <1087328029.10303.198484820@webmail.messagingengine.com> <20040616164710.GG38007@verdi> In-Reply-To: <20040616164710.GG38007@verdi> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/16/2004 9:47 AM, John Leslie sent forth electrons to convey: >Matthew Elvey wrote: > > >>On Tue, 15 Jun 2004 07:58:28 -0400, "John Leslie" said: >> >> >>>Matthew Elvey wrote: >>> >>> >>> >>>>Also, I don't see how 3.2 SMTP Auth protects aol.com from this same abuse. >>>> >>>>RE. 3.1 StartTLS: *IF* STARTTLS is used *AND* the sending server's cert >>>>is CA signed, then that makes sense. >>>> >>>> >>>I'm not sure I understand your question here. Could you clarify? >>> >>> >>I'm saying two things. >>1) Just as rDNS doesn't tie an IP to a domain for our purposes, perhaps >> neither does SMTP Auth. >> >> > > True. SMTP AUTH does not tie to an IP address. > > It does, however, authenticate that you're talking with an SMTP client >worthy of some level of trust (it gave an appropriate response to the >challenge you issued). It didn't seem a stretch to think that this might >sometimes prove it trustworthy enough to give a correct EHLO string. > > It's a huge stretch. I must strenuously object. E.g., here's a simple solution to the spam problem that has the same problem. (Yeah, nominally that's not the problem we're solving; I'm just making the point clear.) Solution: all non-spam must include the header X-This-is-spam: false. Only accept mail with this header. Spammers would [include the header|use SMTP AUTH] faster than non-spammers. They are solutions that impose requirements that spammers can meet more readily than non-spammers. These are, I think, examples of what Dave Crocker is calling an 'administrative attack'. Actually that point bears amplification/restatement: (Without the reputation services that are being contemplated,) all the MARID proposals impose requirements that spammers can meet more readily than non-spammers. It's been said that SPF validation currently correlates positively with spamminess. > Having said that, it's hard to imagine the case where host name >authentication would be the only thing missing _and_ SMTP AUTH would >be in use. > > > >>So it perhaps shouldn't be part of the spec, if the purpose is just to >>be a component of CSV. >> >> > > I believe Dave included it for completeness of background, and it >really isn't part of our proposal. > > > >>2) Just as rDNS doesn't tie an IP to a domain for our purposes, >> STARTTLS might not either - i.e. STARTTLS should be used to validate >> the identity of the connection initiator, not the connection acceptor. >> >> > > Agreed: if STARTTLS doesn't validate the initiator, it's useless for >host name authentication. > > However, we realize there _will_ be cases where the SRV lookup doesn't >return the matching IP address, but local policy may recognize STARTTLS >as "sufficient authentication". > > "_will_"? I'd say "might". I expect STARTTLS will not take off. (But since it can authenticate the initator, if TCP traffic from an IP not really being from that IP becomes common and IPsec doesn't, I could see it taking off). (BTW, TLS used like this is sort of a naiive hashcash implementation - it's expensive, as Otis points out - though he may be referring to the cost of the CA-signed cert; I'm thinking of the CPU cost of starting a TLS connection.) > > >>I guess if either these two methods are mentioned here but not relevant >>to CSV, that should be stated. >> >> > > I can't quite agree they're "not relevant"; but I agree that a warning >label is appropriate. ;^) > > Ok, I can live with that, grudgingly. >-- >John Leslie > > > From owner-ietf-mxcomp@mail.imc.org Fri Jun 18 18:55:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29062 for ; Fri, 18 Jun 2004 18:55:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5IMg9Nh090851; Fri, 18 Jun 2004 15:42:09 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5IMg9mR090850; Fri, 18 Jun 2004 15:42:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5IMg8Hk090844 for ; Fri, 18 Jun 2004 15:42:08 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 18 Jun 2004 15:42:13 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 18 Jun 2004 15:42:11 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 18 Jun 2004 15:42:13 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Drive Towards Consensus [was Re: On Extensibility in MARID Records] Date: Fri, 18 Jun 2004 15:42:09 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF42A88A@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: Drive Towards Consensus [was Re: On Extensibility in MARID Records] thread-index: AcRT9wM5NnN27LcWSJOoZkoaZfI/gABh2Zlw From: "Jim Lyon" To: "IETF MARID WG" X-OriginalArrivalTime: 18 Jun 2004 22:42:13.0154 (UTC) FILETIME=[7F835020:01C45585] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5IMg8Hk090845 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit As requested by the cochairs, here are two more examples of scenarios for which the SPF syntax is insufficient. My initial scenario (feedback tied to individual mechanisms, xxx) kicked off the thread. The second scenario deals with reputation tied to individual mechanisms. The third scenario deals with message types tied to individual mechanisms. Reputations Tied to Individual Mechanisms ----------- ---- -- ---------- ---------- (This is mostly a repeat of xxx) Suppose I have a small domain with no reputation. Suppose I'm a customer of both MSN and Comcast, and I send some of my outbound mail through MSN's mail servers, and some through Comcast's mail servers. As things currently stand, I'd publish a MARID record like: v=spf1 +indirect:msn.com +indirect:comcast.com -all This authenticates me very well (assuming that MSN and Comcast each do a sufficient job of policing their internal networks to keep other customers from masquerading as me). When we get into the question of reputation, the argument goes something like: If you get mail from me through MSN's mail servers, you should believe it's not spam because MSN does a good job of keeping its customers from sending spam. Similarly, if you get mail from me through Comcasts's mail servers. The degree to which you as a receiver believe my mail is not spam is exactly a function of one of my ISP's reputations. Using invented syntax, I could say something like: v=spf1 +indirect:msn.com/targetrep +indirect:comcast.com/targetrep -all which gets the point across nicely. Contrast this with the case of hotmail's record. Hotmail has more address ranges for outgoing servers than fits into a single DNS record, even using SPF syntax. So they publish something like: v=spf1 +indirect:a.hotmail.com +indirect:b.hotmail.com +indirect:c.hotmail.com -all In this case, the indirections are a mere implementation detail, and receivers shouldn't attempt to read anything into the fact that they received a message from the "b" list of servers instead of the "a" list. As a separate example, consider a domain that sends a lot of spam, through its own servers. It also sends non-spam, indirected through Comcast. It may well publish a MARID record like: v=spf1 +mx +indirect:comcast.com/targetrep -all So, if you get mail directly from this domain's servers, the domain's lousy reputation applies. If you get mail from Comcast's servers, Comcast's reputation applies. (This example sidesteps the question of whether some vigilantes might want to reject a domain's identifiably legitimate mail because it also sends spam -- a question I don't want to go into right now). Message Types Tied to Individual Mechanisms ------- ----- ---- -- ---------- ---------- Many domains send both non-bulk and bulk mail, generally through very different parts of their organization. It may be useful to have annotations on an SPF mechanism that describe the kinds of mail they send. For example: v=spf1 +mx/bulk +indirect:comcast.com/nonbulk -all Summary ------- The common theme among these hard-to-represent-in-SPF extensions is that the extension says something about an individual mechanism, instead of saying something about the domain as a whole -- other proposed extensions that say something about the domain as a whole are much easier to represent using SPF modifiers (unless the somethings have internal structure, in which case it gets hard again). When you put it all together, we need a way to say something new about an individual mechanism. Furthermore, we need the ability to say more than one something new about the same mechanism (+indirect:comcast.com/targetrep,nonbulk). Furthermore, some of the somethings have some internal structure (?all/feedback=xxx,hdrs,p=.001). [Note that I'm not proposing syntax here -- the commas in this last example mean something different than the commas in the previous example.] XML gives you all of the above. We don't have any other proposals on the table that give you any of the above. -- jimbo From owner-ietf-mxcomp@mail.imc.org Fri Jun 18 18:55:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29064 for ; Fri, 18 Jun 2004 18:55:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5IMkJV2091527; Fri, 18 Jun 2004 15:46:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5IMkJI0091526; Fri, 18 Jun 2004 15:46:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5IMkJZv091520 for ; Fri, 18 Jun 2004 15:46:19 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 18 Jun 2004 15:46:24 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 18 Jun 2004 15:46:22 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 18 Jun 2004 15:46:24 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: FW: Drive Towards Consensus [was Re: On Extensibility in MARID Records] Date: Fri, 18 Jun 2004 15:46:21 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF42A88E@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: Drive Towards Consensus [was Re: On Extensibility in MARID Records] thread-index: AcRT9wM5NnN27LcWSJOoZkoaZfI/gABh2ZlwAAHT7cA= From: "Jim Lyon" To: "IETF MARID WG" X-OriginalArrivalTime: 18 Jun 2004 22:46:24.0195 (UTC) FILETIME=[15252130:01C45586] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5IMkJZv091521 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Sorry, I pushed the "submit" button before filling in the references. This is a resend, with that fixed. -- jimbo As requested by the cochairs, here are two more examples of scenarios for which the SPF syntax is insufficient. My initial scenario (feedback tied to individual mechanisms, http://www.imc.org/ietf-mxcomp/mail-archive/msg02021.html) kicked off the thread. The second scenario deals with reputation tied to individual mechanisms. The third scenario deals with message types tied to individual mechanisms. Reputations Tied to Individual Mechanisms ----------- ---- -- ---------- ---------- (This is mostly a repeat of http://www.imc.org/ietf-mxcomp/mail-archive/msg02090.html) Suppose I have a small domain with no reputation. Suppose I'm a customer of both MSN and Comcast, and I send some of my outbound mail through MSN's mail servers, and some through Comcast's mail servers. As things currently stand, I'd publish a MARID record like: v=spf1 +indirect:msn.com +indirect:comcast.com -all This authenticates me very well (assuming that MSN and Comcast each do a sufficient job of policing their internal networks to keep other customers from masquerading as me). When we get into the question of reputation, the argument goes something like: If you get mail from me through MSN's mail servers, you should believe it's not spam because MSN does a good job of keeping its customers from sending spam. Similarly, if you get mail from me through Comcasts's mail servers. The degree to which you as a receiver believe my mail is not spam is exactly a function of one of my ISP's reputations. Using invented syntax, I could say something like: v=spf1 +indirect:msn.com/targetrep +indirect:comcast.com/targetrep -all which gets the point across nicely. Contrast this with the case of hotmail's record. Hotmail has more address ranges for outgoing servers than fits into a single DNS record, even using SPF syntax. So they publish something like: v=spf1 +indirect:a.hotmail.com +indirect:b.hotmail.com +indirect:c.hotmail.com -all In this case, the indirections are a mere implementation detail, and receivers shouldn't attempt to read anything into the fact that they received a message from the "b" list of servers instead of the "a" list. As a separate example, consider a domain that sends a lot of spam, through its own servers. It also sends non-spam, indirected through Comcast. It may well publish a MARID record like: v=spf1 +mx +indirect:comcast.com/targetrep -all So, if you get mail directly from this domain's servers, the domain's lousy reputation applies. If you get mail from Comcast's servers, Comcast's reputation applies. (This example sidesteps the question of whether some vigilantes might want to reject a domain's identifiably legitimate mail because it also sends spam -- a question I don't want to go into right now). Message Types Tied to Individual Mechanisms ------- ----- ---- -- ---------- ---------- Many domains send both non-bulk and bulk mail, generally through very different parts of their organization. It may be useful to have annotations on an SPF mechanism that describe the kinds of mail they send. For example: v=spf1 +mx/bulk +indirect:comcast.com/nonbulk -all Summary ------- The common theme among these hard-to-represent-in-SPF extensions is that the extension says something about an individual mechanism, instead of saying something about the domain as a whole -- other proposed extensions that say something about the domain as a whole are much easier to represent using SPF modifiers (unless the somethings have internal structure, in which case it gets hard again). When you put it all together, we need a way to say something new about an individual mechanism. Furthermore, we need the ability to say more than one something new about the same mechanism (+indirect:comcast.com/targetrep,nonbulk). Furthermore, some of the somethings have some internal structure (?all/feedback=xxx,hdrs,p=.001). [Note that I'm not proposing syntax here -- the commas in this last example mean something different than the commas in the previous example.] XML gives you all of the above. We don't have any other proposals on the table that give you any of the above. -- jimbo From owner-ietf-mxcomp@mail.imc.org Fri Jun 18 20:51:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06464 for ; Fri, 18 Jun 2004 20:51:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5J0cSKr013400; Fri, 18 Jun 2004 17:38:28 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5J0cSFf013399; Fri, 18 Jun 2004 17:38:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ernie.mail-abuse.org (Ernie.mail-abuse.org [168.61.5.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5J0cR1C013382 for ; Fri, 18 Jun 2004 17:38:27 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.mail-abuse.org (DDev.mail-abuse.org [168.61.10.124]) by ernie.mail-abuse.org (8.12.0.Beta19/8.12.0) with ESMTP id i5J0cRPQ023335; Fri, 18 Jun 2004 17:38:27 -0700 (PDT) Subject: Re: FW: Drive Towards Consensus [was Re: On Extensibility in MARID Records] From: Douglas Otis To: Jim Lyon Cc: IETF MARID WG In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF42A88E@df-fido-msg.exchange.corp.microsoft.com> References: <81AC085044D04B429F5FB883D94FA1AF42A88E@df-fido-msg.exchange.corp.microsoft.com> Content-Type: text/plain Message-Id: <1087605507.2002.144.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 18 Jun 2004 17:38:27 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2004-06-18 at 15:46, Jim Lyon wrote: > Reputations Tied to Individual Mechanisms > ----------- ---- -- ---------- ---------- > > (This is mostly a repeat of > http://www.imc.org/ietf-mxcomp/mail-archive/msg02090.html) > > Suppose I have a small domain with no reputation. Suppose I'm a > customer of both MSN and Comcast, and I send some of my outbound mail > through MSN's mail servers, and some through Comcast's mail servers. As > things currently stand, I'd publish a MARID record like: > v=spf1 +indirect:msn.com +indirect:comcast.com -all > > This authenticates me very well (assuming that MSN and Comcast each do a > sufficient job of policing their internal networks to keep other > customers from masquerading as me). > > When we get into the question of reputation, the argument goes something > like: If you get mail from me through MSN's mail servers, you should > believe it's not spam because MSN does a good job of keeping its > customers from sending spam. Similarly, if you get mail from me through > Comcasts's mail servers. The degree to which you as a receiver believe > my mail is not spam is exactly a function of one of my ISP's > reputations. Do you expect to increase the workload at the MTA and require vetting of accreditation services based upon the individual? How can this accreditation service be sure they are accounting for the right individual? Although there is some cost associated in creating a domain, there is virtually no cost associated with creating a user. This accreditation service would be left ferreting through forged mail, spoofed complaints, and fictitious users as the IP checks just the domain. I see even more destruction of mail's flexibility in store to support this innovation however. Like a bull in a china shop, this breaks everything around it. Again, the Fenton proposal allows the needed assurance for such individual vetting without destroying mail's best features. Add another SRV record where instead of using _krs (Key Registration Service) use _urs (User Reporting Service) for such an individual service or add to the krs dialog. This URS could establish a dialog to allow complaints to be registered, where the domain can then take the needed administrative action. Accreditation would be based upon the domain and not something as unscalable as a user. Of course complaints would require proper identification using the same key based checks. ; ) Here the Fenton proposal is infinitely extensible without piling everything together and would make such a service achievable. Easily done at the MUA and does not require breaking mail to accomplish this. > Message Types Tied to Individual Mechanisms > ------- ----- ---- -- ---------- ---------- > > Many domains send both non-bulk and bulk mail, generally through very > different parts of their organization. It may be useful to have > annotations on an SPF mechanism that describe the kinds of mail they > send. For example: > v=spf1 +mx/bulk +indirect:comcast.com/nonbulk -all > Sure. I would believe this notation. : ) -Doug From owner-ietf-mxcomp@mail.imc.org Fri Jun 18 22:34:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11193 for ; Fri, 18 Jun 2004 22:34:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5J2MnP7035968; Fri, 18 Jun 2004 19:22:49 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5J2Mn7F035967; Fri, 18 Jun 2004 19:22:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5J2Mmmr035948 for ; Fri, 18 Jun 2004 19:22:48 -0700 (PDT) (envelope-from roy+dated+1090203770.b30417@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i5J2MoRC036118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 19 Jun 2004 02:22:51 GMT (envelope-from roy+dated+1090203770.b30417@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5J2MoK3057955 for ; Sat, 19 Jun 2004 03:22:50 +0100 (BST) (envelope-from roy+dated+1090203770.b30417@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5J2MoQI057954 for ietf-mxcomp@imc.org; Sat, 19 Jun 2004 03:22:50 +0100 (BST) (envelope-from roy+dated+1090203770.b30417@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sat, 19 Jun 2004 03:22:48 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16595.41847.958775.907196@giles.gnomon.org.uk> Date: Sat, 19 Jun 2004 03:22:47 +0100 To: "Jim Lyon" Cc: "John R Levine" , "IETF-MXCOMP" Subject: RE: Against Extensibility in MARID Records In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF42A6DD@df-fido-msg.exchange.corp.microsoft.com> References: <81AC085044D04B429F5FB883D94FA1AF42A6DD@df-fido-msg.exchange.corp.microsoft.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hmmm, I have to say I'm really not that interested in the reputation of my ISP... I'll send mail from my own MTAs, and their reputation will hopefully be based solely on the mail that my systems generate... My gut feeling is that if you're forced to use your ISPs MTA against your will (which boils down to being a residential cable/DSL customer) then your ISP's reputation is going to be pretty low anyway (simply becuase of the nature of virus infected and compromised machines that exist on a typical residential broadband network). Surely MARID makes more sense in a world where people (again) configure their MTAs to deliver direct, rather than smarthosting off their ISPs...? -roy From owner-ietf-mxcomp@mail.imc.org Fri Jun 18 23:22:22 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12791 for ; Fri, 18 Jun 2004 23:22:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5J333aj043508; Fri, 18 Jun 2004 20:03:03 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5J333D9043507; Fri, 18 Jun 2004 20:03:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from polis.nbtsc.org (polis.nbtsc.org [206.168.119.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5J333BM043499 for ; Fri, 18 Jun 2004 20:03:03 -0700 (PDT) (envelope-from aredridel@nbtsc.org) Received: from betelgeuse.theinternetco.net ([206.168.119.12]) by polis.nbtsc.org with asmtp (Exim 4.34) id 1BbW8K-000625-Sr; Fri, 18 Jun 2004 21:03:08 -0600 Subject: RE: Against Extensibility in MARID Records From: Aredridel To: Roy Badami Cc: ietf-mxcomp@imc.org In-Reply-To: <16595.41847.958775.907196@giles.gnomon.org.uk> References: <81AC085044D04B429F5FB883D94FA1AF42A6DD@df-fido-msg.exchange.corp.microsoft.com> <16595.41847.958775.907196@giles.gnomon.org.uk> Content-Type: text/plain Date: Fri, 18 Jun 2004 21:03:08 -0600 Message-Id: <1087614188.12622.14.camel@betelgeuse.theinternetco.net> Mime-Version: 1.0 X-Mailer: Evolution 1.5.9.1 Content-Transfer-Encoding: 7bit X-Scan-Signature: 3c0f8fc028da8990eed41e7f4fe0bb1c Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > My gut feeling is that if you're forced to use your ISPs MTA against > your will (which boils down to being a residential cable/DSL customer) > then your ISP's reputation is going to be pretty low anyway (simply > becuase of the nature of virus infected and compromised machines that > exist on a typical residential broadband network). Agreed -- in the short term. In the future, though, I think we may see a drop in such activity, so the long term seems brighter to me. > Surely MARID makes more sense in a world where people (again) > configure their MTAs to deliver direct, rather than smarthosting off > their ISPs...? For sure. For me, that's a primary goal -- a sort of rebirth of end-to- end in email. If you can hold people (or at least groups under a domain) responsible directly, there won't be so much policing neccesary. Ari From owner-ietf-mxcomp@mail.imc.org Fri Jun 18 23:49:09 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13618 for ; Fri, 18 Jun 2004 23:49:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5J3cq3O051137; Fri, 18 Jun 2004 20:38:52 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5J3cpuG051136; Fri, 18 Jun 2004 20:38:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5J3coSE051120 for ; Fri, 18 Jun 2004 20:38:51 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: gqvkziqfTILF8Y8+ApcY0g 1087616330 Received: from [192.168.1.141] (ns.nextbus.com [64.164.28.194]) by mail.messagingengine.com (Postfix) with ESMTP id 13A1EC0C894; Fri, 18 Jun 2004 23:38:49 -0400 (EDT) Message-ID: <40D3B549.4050803@elvey.com> Date: Fri, 18 Jun 2004 20:38:49 -0700 From: Matthew Elvey User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: wayne Subject: Re: Against Extensibility in MARID Records References: <81AC085044D04B429F5FB883D94FA1AF42A6DD@df-fido-msg.exchange.corp.microsoft.com> In-Reply-To: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I don't find Jimbo's arguments compelling. In the two recent specific examples, I think things are wrong because I expect MARID-based software will check reputation services just on the domain initially looked up; checks on referenced domains isn't necessary, and I don't see why it's a good idea. The third example is of something that I think MARID should NOT support - reputations should be tied to domains. Not to various sets of servers that are authorized to send b a domain. We need to concentrate on what is the least we need to do to accomplish our goal. Are all these extensions necessary or helpful in achieving M.A.R.I.D. or the larger goal. No, MARID will enable antispam efforts to be more proactive and less reactive. These extensions would return to a reactive mode. Another thing is that if regular SPF and new SPF-ID records are both going to be OK, then the regular SPF record has to support this stuff. If XML has stuff that only XML can have, this symmetry is broken! Hence my opinion that regular SPF records, and NO XML is the way to go. I don't think a compromise is a good idea because it will slow adoption, which is far more important than these add-ons. Speed and simplicity and breadth of adoption is what it's about. That's why I want to see SPF records use to validate the EHLO. It'll (play the same record track yet again) solve the problem without the headaches of SRS or end user changes that regular SPF or the new one will require, and hence be much faster to adopt. BTW, Someone at the interim meeting smeared this argument in a content-free way (Ted???). I've presented it in detail here and it went unchallenged. If it's to be challenged, the proper way would have been to respond to my detailed presentation of the argument. Details of my argument as to why CSV is is likely to be adopted so much faster and more easily are here: http://www.imc.org/ietf-mxcomp/mail-archive/msg01226.html and http://www.imc.org/ietf-mxcomp/mail-archive/msg01175.html. Ted, or whoever made that comment, I'd appreciate a response to my argument that is not just an opinion, but a counterargument. (Apologies if I've misidentified the speaker; it was the person at the end of the front main audience table, audience left, if that makes sense.) On 6/18/2004 10:51 AM, wayne sent forth electrons to convey: >>PS: John also said: >> >> >>>If the record is indeed too big for UDP, I hope it's obvious >>>to everyone here why following a pointer to a URL is the same >>>speed as falling back to DNS TCP. >>> >>> >>On this point, I 100% agree. >> >> > >Actually, I think a serious of DNS lookups, especially if done in >parallel, will be quicker than a single TCP transaction. The >three-way handshake on startup and the four-way teardown really kill >the performance of sending one large TCP packet. > > Wayne, reread what John said. Your reply indicates you think he's comparing DNS over UDP with XML over TCP. He's not. He's comparing DNS over TCP with XML over TCP. Still, it's true: a series of DNS over UDP lookups is cheaper than the alternatives. From owner-ietf-mxcomp@mail.imc.org Sat Jun 19 00:05:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13980 for ; Sat, 19 Jun 2004 00:05:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5J3tU7q054494; Fri, 18 Jun 2004 20:55:30 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5J3tUBq054492; Fri, 18 Jun 2004 20:55:30 -0700 (PDT) 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.9) with ESMTP id i5J3tUrO054481 for ; Fri, 18 Jun 2004 20:55:30 -0700 (PDT) (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 i5J3tadb012800 for ; Fri, 18 Jun 2004 20:55:36 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Fri, 18 Jun 2004 20:55:36 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: IETF MARID WG Subject: RE: Drive Towards Consensus [was Re: On Extensibility in MARID Re cords] Date: Fri, 18 Jun 2004 20:55:35 -0700 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: Another example where SPF syntax comes unstuck. A domain uses S/MIME authentication in addition to IP based auth. This allows a mail message from a bank to display the logo of the bank in a privilleged part of the display by means of the X.509 logotypes extension. The following information is needed: * express statement 'all mail is signed' * express the message digest of the signing certificate * express the algorithm supported. Now consider the following complications: * Also support pgp message format * express different signing policies 'mail signed when extension offered' * handle the TLS protocol * encryption * different key distribution structures - web 'o trust, xkms, domain key I don't think anyone can fairly claim that the spf ad-hoc syntax is going to cope with this. OK you can define ad hoc extensions, but the number of degree of freedom are huge. This is not a theoretical proposal. The use of signed mail is already under serious discussion in anti-phishing forums. One could argue that this should be handled by a separate record. But then we are back to the two parsers option anyway. It took me less than half an hour to write a schema for this application in XML. I don't think anyone could claim to write a parser for a corresponding SPF syntax in the same time. From owner-ietf-mxcomp@mail.imc.org Sat Jun 19 00:08:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14249 for ; Sat, 19 Jun 2004 00:08:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5J3nciP053367; Fri, 18 Jun 2004 20:49:38 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5J3ncBP053366; Fri, 18 Jun 2004 20:49:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5J3nbvc053359 for ; Fri, 18 Jun 2004 20:49:37 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: ZqYF+0hi9ZeBhG8wqetYLQ 1087616981 Received: from [192.168.1.141] (ns.nextbus.com [64.164.28.194]) by mail.messagingengine.com (Postfix) with ESMTP id 62FA9C0CA41; Fri, 18 Jun 2004 23:49:41 -0400 (EDT) Message-ID: <40D3B7D5.90803@elvey.com> Date: Fri, 18 Jun 2004 20:49:41 -0700 From: Matthew Elvey User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MXCOMP Subject: Re: CSV, NBB References: <1665390638.20040614190711@brandenburg.com> <20040615031048.GP44160@verdi> <40CE9F08.2050002@elvey.com> <20040615115828.GQ44160@verdi> <1087328029.10303.198484820@webmail.messagingengine.com> <20040616164710.GG38007@verdi> <40D36596.6050907@elvey.com> In-Reply-To: <40D36596.6050907@elvey.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dave, John, Doug: Have you considered and rejected or not considered adding the NBB idea that I threw out a while back to the CSV spec? For convenience: The NBB idea is: Take CSV, and add a new requirement: mail that has failed (as in there is a MARID record AND the sending IP isn't there AND there's no ?all) a 2821.FROM check MUST NOT be bounced; instead it MUST either be refused at SMTP time, or accepted and destroyed. In other words, DON'T require SRS, but DO require that mail that goes via non-SRS systems not lead to bounces to systems that didn't originate the original message. What will this requirement break? Well, let's be up front. Fundamentally it breaks (for a very small subset, as I'll show!) what I think is an oft-broken requirement: no mail be destroyed (or it could specify that such mail goes to postmaster, like double-bounces, but that's a broadly violated requirement already (e.g. some major ISPs dump mail they think is spam into /dev/null.) It doesn't break SRS-compliant forwarders AND it doesn't break non-SRS forwarders, except if the final recipient decides it wants to bounce or refuse a message, that bounce or refusal won't get back to a sender IF she has MARID records. It doesn't break mailing lists or greeting card sites or require that they change. Unlike SPF, it DOESN'T require that every end user use an MTA authorized for the 2822.From they're using! If a legitimate user uses an unauthorized MTA, her mail will still get through, but any email that she sends to invalid addresses (eg. typos) or that bounces for some other reason won't get back to her. A further enhancement would be that SMTP servers that are unable to get a message a trusted user sends out for any reason would be allowed to bounce the message back to the user. If everyone implements SRS, it breaks nothing, and if no one does, the stuff it breaks is, I argue, not critical. From owner-ietf-mxcomp@mail.imc.org Sat Jun 19 08:39:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17955 for ; Sat, 19 Jun 2004 08:39:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5JCPwTD047769; Sat, 19 Jun 2004 05:25:58 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5JCPwDY047768; Sat, 19 Jun 2004 05:25:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5JCPvC3047761 for ; Sat, 19 Jun 2004 05:25:57 -0700 (PDT) (envelope-from roy+dated+1090239957.f98c87@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i5JCPvRC071319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 19 Jun 2004 12:25:58 GMT (envelope-from roy+dated+1090239957.f98c87@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5JCPv4K063940 for ; Sat, 19 Jun 2004 13:25:57 +0100 (BST) (envelope-from roy+dated+1090239957.f98c87@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5JCPvuQ063939 for ietf-mxcomp@imc.org; Sat, 19 Jun 2004 13:25:57 +0100 (BST) (envelope-from roy+dated+1090239957.f98c87@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sat, 19 Jun 2004 13:25:53 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16596.12497.349996.93747@giles.gnomon.org.uk> Date: Sat, 19 Jun 2004 13:25:53 +0100 To: Matthew Elvey Cc: MXCOMP Subject: Re: CSV, NBB In-Reply-To: <40D3B7D5.90803@elvey.com> References: <1665390638.20040614190711@brandenburg.com> <20040615031048.GP44160@verdi> <40CE9F08.2050002@elvey.com> <20040615115828.GQ44160@verdi> <1087328029.10303.198484820@webmail.messagingengine.com> <20040616164710.GG38007@verdi> <40D36596.6050907@elvey.com> <40D3B7D5.90803@elvey.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Matthew" == Matthew Elvey writes: Matthew> The NBB idea is: Take CSV, and add a new requirement: Matthew> mail that has failed (as in there is a MARID record AND Matthew> the sending IP isn't there AND there's no ?all) a Matthew> 2821.FROM check MUST NOT be bounced; instead it MUST Matthew> either be refused at SMTP time, or accepted and Matthew> destroyed. Personally I'm very strongly against any mandate for accepting and destroying messages. I don't believe that this or any other IETF WG should be contemplating removal of the mandate in RFC 1123 5.3.3 and RFC2821 6.1 that once mail has been accepted it MUST be either delivered or bounced. NBB would seem to go against this long established principle that blackholes are bad. The problem is not with messages that are genuinely forged, but with messages that are mistakenly determined to be forged as a result of a configuration error. Obviously rejection at the SMTP level is best (but this may just generate a bounce upstream anyway), but if this is not possible then it is vital that these messages are bounced, rather than discarded, to allow the configuration error to be detected and corrected. NBB is not going to prevent the problem of joe jobs. Nor even would SPFv1. All NBB can do is avoid trying to make the joe job problem worse as a result of MARID/LMAP checks. But we need (and will have) other ways of preventing joe jobs, whether by checking a token in the envelope address, checking the Message-ID, or something else. Once we have protection against unwanted bounces (and we need that anyway) NBB gains us nothing. If we throw away the principle of reliable mail delivery for short term expediency, it will be very difficult to get it back, we'll regret that decision for a long time... Or in summary: the cure is worse than the disease... -roy From owner-ietf-mxcomp@mail.imc.org Sat Jun 19 09:07:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19089 for ; Sat, 19 Jun 2004 09:07:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5JCrCcH052689; Sat, 19 Jun 2004 05:53:12 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5JCrC1N052688; Sat, 19 Jun 2004 05:53:12 -0700 (PDT) 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.9) with ESMTP id i5JCrBFP052679 for ; Sat, 19 Jun 2004 05:53:11 -0700 (PDT) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id 6EAC3E0641; Sat, 19 Jun 2004 08:53:11 -0400 (EDT) Date: Sat, 19 Jun 2004 08:53:11 -0400 From: John Leslie To: Matthew Elvey Cc: MXCOMP Subject: Re: CSV specification revision available Message-ID: <20040619125311.GA73565@verdi> References: <1665390638.20040614190711@brandenburg.com> <20040615031048.GP44160@verdi> <40CE9F08.2050002@elvey.com> <20040615115828.GQ44160@verdi> <1087328029.10303.198484820@webmail.messagingengine.com> <20040616164710.GG38007@verdi> <40D36596.6050907@elvey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40D36596.6050907@elvey.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Matthew Elvey wrote: > On 6/16/2004 9:47 AM, John Leslie sent forth electrons to convey: >> Matthew Elvey wrote: >>> >>> 1) Just as rDNS doesn't tie an IP to a domain for our purposes, perhaps >>> neither does SMTP Auth. >> >> True. SMTP AUTH does not tie to an IP address. >> >> It does, however, authenticate that you're talking with an SMTP client >> worthy of some level of trust (it gave an appropriate response to the >> challenge you issued). It didn't seem a stretch to think that this might >> sometimes prove it trustworthy enough to give a correct EHLO string. >> > It's a huge stretch. I must strenuously object. Noted. (It really doesn't make much difference, so I won't argue.) > > >>> 2) Just as rDNS doesn't tie an IP to a domain for our purposes, >>> STARTTLS might not either - i.e. STARTTLS should be used to validate >>> the identity of the connection initiator, not the connection acceptor. >> >> Agreed: if STARTTLS doesn't validate the initiator, it's useless for >> host name authentication. >> >> However, we realize there _will_ be cases where the SRV lookup doesn't >> return the matching IP address, but local policy may recognize STARTTLS >> as "sufficient authentication". >> > "_will_"? I'd say "might". I'd say "will". (I didn't say it would be common.) > I expect STARTTLS will not take off. > Noted. >>> I guess if either these two methods are mentioned here but not relevant >>> to CSV, that should be stated. >> >> I can't quite agree they're "not relevant"; but I agree that a warning >> label is appropriate. ;^) >> > Ok, I can live with that, grudgingly. Thank you. BTW, the WG versions of the CSV IDs have been submitted and approved by Marshall. Meanwhile, they're available at: http://www.jlc.net/MARID/CSV/ The "intro" has been rewritten: you may be happier with it now. If not, feel free to propose actual wording to improve it. -- John Leslie From owner-ietf-mxcomp@mail.imc.org Sat Jun 19 10:25:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22480 for ; Sat, 19 Jun 2004 10:25:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5JEEDTl067606; Sat, 19 Jun 2004 07:14:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5JEED4i067605; Sat, 19 Jun 2004 07:14:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5JEECH6067587 for ; Sat, 19 Jun 2004 07:14:12 -0700 (PDT) (envelope-from millenix@zemos.net) Received: from fda.zemos.net (millenix-fda.no-ip.org[68.39.78.137]) by comcast.net (rwcrmhc11) with ESMTP id <2004061914140901300ggl7ge>; Sat, 19 Jun 2004 14:14:09 +0000 Received: from localhost (fda [127.0.0.1]) by fda.zemos.net (Postfix) with ESMTP id 4A0D218682; Sat, 19 Jun 2004 10:14:01 -0400 (EDT) Received: from fda.zemos.net ([127.0.0.1]) by localhost (fda [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07657-06; Sat, 19 Jun 2004 10:14:01 -0400 (EDT) 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 A64A418680; Sat, 19 Jun 2004 10:14:00 -0400 (EDT) Message-ID: <40D44A2D.7030000@zemos.net> Date: Sat, 19 Jun 2004 10:14:05 -0400 From: Philip Miller User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040528 Debian/1.6-7 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Aredridel Cc: ietf-mxcomp@imc.org Subject: Re: Against Extensibility in MARID Records References: <81AC085044D04B429F5FB883D94FA1AF42A6DD@df-fido-msg.exchange.corp.microsoft.com> <16595.41847.958775.907196@giles.gnomon.org.uk> <1087614188.12622.14.camel@betelgeuse.theinternetco.net> In-Reply-To: <1087614188.12622.14.camel@betelgeuse.theinternetco.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p9 (Debian) at fda.zemos.net Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Aredridel wrote: >>My gut feeling is that if you're forced to use your ISPs MTA against >>your will (which boils down to being a residential cable/DSL customer) >>then your ISP's reputation is going to be pretty low anyway (simply >>becuase of the nature of virus infected and compromised machines that >>exist on a typical residential broadband network). > > Agreed -- in the short term. In the future, though, I think we may see a > drop in such activity, so the long term seems brighter to me. With some ISPs, we'll see a drop in that activity. Comcast, for example, has been rather proactive about rate-limiting outgoing SMTP through their smarthost. On the other hand, there are many ISPs that don't care. I'd much rather the alternative, that only my reputation applies to my mail. >>Surely MARID makes more sense in a world where people (again) >>configure their MTAs to deliver direct, rather than smarthosting off >>their ISPs...? > > For sure. For me, that's a primary goal -- a sort of rebirth of end-to- > end in email. If you can hold people (or at least groups under a domain) > responsible directly, there won't be so much policing neccesary. That is probably the strongest reason I support the MARID effort. I currently cannot send directly to certain large domains because I'm on residential cable. This is also the reason I support something simple and lightweight, that protects HELO or MAIL FROM instead of body headers. If the recipient has a domain that will put its reputation on the line to vouch for a message, it doesn't need to be the one that appears in the body. We need to create the smallest possible system that can authenticate one protocol field in an SMTP transaction. From that, this or another group can develop stronger mechanisms for combatting forgery and spam, but not until after basic authentication hsa been deployed. Philip Miller From owner-ietf-mxcomp@mail.imc.org Sat Jun 19 11:06:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23905 for ; Sat, 19 Jun 2004 11:06:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5JEqWnf074731; Sat, 19 Jun 2004 07:52:32 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5JEqWgc074730; Sat, 19 Jun 2004 07:52:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5JEqV2i074723 for ; Sat, 19 Jun 2004 07:52:32 -0700 (PDT) (envelope-from aland@newgiles.nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 4DE5516FAB for ; Sat, 19 Jun 2004 10:59:01 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: CSV, NBB In-Reply-To: Your message of "Sat, 19 Jun 2004 13:25:53 BST." <16596.12497.349996.93747@giles.gnomon.org.uk> Date: Sat, 19 Jun 2004 10:59:01 -0400 Message-Id: <20040619145901.4DE5516FAB@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Roy Badami wrote: > Personally I'm very strongly against any mandate for accepting and > destroying messages. This is already happening on the net today, due to deficiencies in SMTP. > I don't believe that this or any other IETF WG should be contemplating > removal of the mandate in RFC 1123 5.3.3 and RFC2821 6.1 that once > mail has been accepted it MUST be either delivered or bounced. That requirement is impossible to implement in practice. SMTP makes *no* provisions for verifying that a bounce path exists. Therefore, once a message has been accepted for delivery, it is *impossible* to bounce it in the general case. The MTA can try, but there's no guarantee that the MAIL FROM parameter will be resolvable, or that the host will even know about the message which caused the bounce. All of the RMX/SPF/etc. proposals can be looked at as giving the recipient more information with which to validate the bounce path. This property is independent of their other effects. > Obviously rejection at the SMTP level is best (but this may just > generate a bounce upstream anyway), but if this is not possible then > it is vital that these messages are bounced, rather than discarded, > to allow the configuration error to be detected and corrected. Bounced where? How can you tell that the bounce path is valid, and that you're not spamming the MAIL FROM site with bounces from forged messages? Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Sat Jun 19 11:07:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23952 for ; Sat, 19 Jun 2004 11:07:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5JEvxmA076024; Sat, 19 Jun 2004 07:57:59 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5JEvxCe076023; Sat, 19 Jun 2004 07:57:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5JEvwK0075985 for ; Sat, 19 Jun 2004 07:57:58 -0700 (PDT) (envelope-from millenix@zemos.net) Received: from fda.zemos.net (millenix-fda.no-ip.org[68.39.78.137]) by comcast.net (sccrmhc12) with ESMTP id <2004061914574501200hnq6je>; Sat, 19 Jun 2004 14:57:55 +0000 Received: from localhost (fda [127.0.0.1]) by fda.zemos.net (Postfix) with ESMTP id 55DB218680; Sat, 19 Jun 2004 10:57:38 -0400 (EDT) Received: from fda.zemos.net ([127.0.0.1]) by localhost (fda [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08244-03; Sat, 19 Jun 2004 10:57:37 -0400 (EDT) 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 D4F291867F; Sat, 19 Jun 2004 10:57:37 -0400 (EDT) Message-ID: <40D45468.3070206@zemos.net> Date: Sat, 19 Jun 2004 10:57:44 -0400 From: Philip Miller User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040528 Debian/1.6-7 X-Accept-Language: en, en-us MIME-Version: 1.0 To: "Hallam-Baker, Phillip" Cc: IETF MARID WG Subject: Re: Drive Towards Consensus [was Re: On Extensibility in MARID Records] References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p9 (Debian) at fda.zemos.net Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hallam-Baker, Phillip wrote: > Another example where SPF syntax comes unstuck. > > A domain uses S/MIME authentication in addition to IP based auth. This S/MIME != MTA Authorization. S/MIME only deals with DATA contents, which can be identical from authorized and unauthorized MTAs. There is no reason that MARID should have anything to do with S/MIME. Thus, there's no problem with SPF syntax not supporting S/MIME. > allows a mail message from a bank to display the logo of the bank in a > privilleged part of the display by means of the X.509 logotypes extension. > > The following information is needed: > > * express statement 'all mail is signed' > * express the message digest of the signing certificate > * express the algorithm supported. Someone should definitely write a standard for expressing that in the DNS. However, that doesn't appear to be in scope for this group. I haven't read the Yahoo DomainKeys proposal, but isn't that exactly what it deals with? > Now consider the following complications: > > * Also support pgp message format > * express different signing policies 'mail signed when extension > offered' PGP and content-signing have nothing to do with the MTA, same as S/MIME. > * handle the TLS protocol TLS is the only piece of this that I can see as being related to MTA authentication or authorization. How about a new mechanism in SPF syntax, 'tls', that specifies the fingerprint of the certificate that the sending MTA will present, or of a CA cert that signed it? Then SPF doesn't need to specify IP addresses any more, since you could express "all mail sent by a server with this cert is from my domain, regardless of where it is connecting from". If you meant "the connecting IP is part of a given set, and it uses TLS with a certain certificate", then I don't think any of the existing proposals cover that. Even if they did, what is the use-case for it? > * encryption Whether it encrypts or not has nothing to do with authentication or authorization. > * different key distribution structures - web 'o trust, xkms, domain > key Again, not relevant. > I don't think anyone can fairly claim that the spf ad-hoc syntax is going to > cope with this. OK you can define ad hoc extensions, but the number of > degree of freedom are huge. Many of us opposing a heavily extensible syntax want to limit that freedom, for simplicity of implementation and ease of deployment. Very simply, I don't want SPF ad-hoc syntax to deal with this, because it's not relevant to the goal we're trying to reach of authorizing the MTA, and not the data the MTA is sending. > This is not a theoretical proposal. The use of signed mail is already under > serious discussion in anti-phishing forums. Good, but it should be independent of protecting domains from MTA identity forgery. > One could argue that this should be handled by a separate record. But then > we are back to the two parsers option anyway. Two parsers, yes, but neither dependent on the other. One could check that the connecting MTA is authorized without checking the signature on the message it sends, or vice-versa, or both. > It took me less than half an hour to write a schema for this application in > XML. I don't think anyone could claim to write a parser for a corresponding > SPF syntax in the same time. No one needs to write that parser for SPF, because it's already written. In Perl, C, Java, and Python. From implementation code that I've looked at, one needs to be able to make a single function call into any one of those languages to check whether a connection is authorized or not. Philip Miller From owner-ietf-mxcomp@mail.imc.org Sat Jun 19 15:17:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05060 for ; Sat, 19 Jun 2004 15:17:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5JIu4gJ024233; Sat, 19 Jun 2004 11:56:04 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5JIu48Y024232; Sat, 19 Jun 2004 11:56:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5JIu3VW024217 for ; Sat, 19 Jun 2004 11:56:03 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: mUj6wh7PRMOJizGbXtXspQ 1087671363 Received: from elvey.com (adsl-63-195-86-147.dsl.snfc21.pacbell.net [63.195.86.147]) by mail.messagingengine.com (Postfix) with ESMTP id 5C268C0C835; Sat, 19 Jun 2004 14:56:01 -0400 (EDT) Message-ID: <40D48C40.10208@elvey.com> Date: Sat, 19 Jun 2004 11:56:00 -0700 From: Matthew Elvey User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roy Badami Cc: MXCOMP Subject: Re: CSV, NBB References: <1665390638.20040614190711@brandenburg.com> <20040615031048.GP44160@verdi> <40CE9F08.2050002@elvey.com> <20040615115828.GQ44160@verdi> <1087328029.10303.198484820@webmail.messagingengine.com> <20040616164710.GG38007@verdi> <40D36596.6050907@elvey.com> <40D3B7D5.90803@elvey.com> <16596.12497.349996.93747@giles.gnomon.org.uk> In-Reply-To: <16596.12497.349996.93747@giles.gnomon.org.uk> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/19/04 5:25 AM, Roy Badami sent forth electrons to convey: >>>>>>"Matthew" == Matthew Elvey writes: >>>>>> >>>>>> > Matthew> The NBB idea is: Take CSV, and add a new requirement: > Matthew> mail that has failed (as in there is a MARID record AND > Matthew> the sending IP isn't there AND there's no ?all) a > Matthew> 2821.FROM check MUST NOT be bounced; instead it MUST > Matthew> either be refused at SMTP time, or accepted and > Matthew> destroyed. > >Personally I'm very strongly against any mandate for accepting and >destroying messages. > > I'm simply being honest about the suggested disposition of such messages, where other proposals avoid *explicitly* saying that in situation S, accepting and destroying a message is appropriate. But it's implicit, even when there are statements such as "An SPF email system MAY choose to reject or discard email on the basis of local policy" and "Policy decisions regarding particular messages are outside the scope of SPF." (See SPF quote below as well.) Is this acceptable? : The NBB idea is: Take CSV, and add a new requirement: mail that has failed (as in there is a MARID record AND the sending IP isn't there AND there's no ?all) a 2821.FROM check should be treated according to local policy for such messages. In other words, DON'T require SRS, but DO enable mail that goes via non-SRS systems that would lead to bounces to systems that didn't originate the original message be treated according to local policy. Are you for other proposals that avoid explicitly saying that in situation S, accepting and destroying a message is appropriate, even though it's obvious that this is what they're endorsing? >I don't believe that this or any other IETF WG should be contemplating >removal of the mandate in RFC 1123 5.3.3 and RFC2821 6.1 that once >mail has been accepted it MUST be either delivered or bounced. > >NBB would seem to go against this long established principle that >blackholes are bad. The problem is not with messages that are >genuinely forged, but with messages that are mistakenly determined to >be forged as a result of a configuration error. > Problems would have to occur simultaneously: * the mail is sent in direct violation of MARID checks, and * the responsible domain admin has said -all (or the equivalent in different syntax), not ~all or ?all. * the mail has gone through a forwarding system and * the forwarding system has not implemented SRS and * the forwarding system (e.g. mailing list) isn't whitelisted. > Obviously rejection >at the SMTP level is best (but this may just generate a bounce >upstream anyway), but if this is not possible then it is vital that >these messages are bounced, rather than discarded, to allow the >configuration error to be detected and corrected. > >NBB is not going to prevent the problem of joe jobs. > Why not? Your statement lacks an argument. >Nor even would SPFv1. > I think that's incorrect too. I believe Meng has said that he'd be happy if this is all that SPF+SRS does. I interpret this to mean Meng disagrees with you on this. "SPF was originally designed to prevent joe-jobs." - http://spf.pobox.com/ This also proves my point earlier - proposals just aren't being up front about it, but clearly the intention is to make it safe to accept and destroy a class of messages. (SPF is supposed to work fine on MUAs.) > All NBB can do is avoid trying to make the joe job problem >worse as a result of MARID/LMAP checks. But we need (and will have) >other ways of preventing joe jobs, whether by checking a token in the >envelope address, checking the Message-ID, or something else. > > No, we have some solutions that ALLOW joe jobs, but make them not directly end-user-visible (if the receiving server doesn't die under the load of the joe-jobs it is receiving). The end system does the accepting and destroying of a message that you say is not appropriate in other situations. Also they don't work when users are able to send messages from wherever (without forging) using their usual email address. With what I'm proposing, they can still do this. >Once we have protection against unwanted bounces (and we need that >anyway) NBB gains us nothing. > > Obviously. The point of NBB is to address this problem. So if it's solved, there's no point. Circular reasoning. The question is why my/another solution is better. From owner-ietf-mxcomp@mail.imc.org Sat Jun 19 16:45:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07693 for ; Sat, 19 Jun 2004 16:45:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5JKIOrb040758; Sat, 19 Jun 2004 13:18:24 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5JKIOtF040757; Sat, 19 Jun 2004 13:18:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tom.iecc.com (tom.iecc.com [208.31.42.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5JKINt6040749 for ; Sat, 19 Jun 2004 13:18:23 -0700 (PDT) (envelope-from johnl@iecc.com) Received: (qmail 15314 invoked from network); 19 Jun 2004 20:18:27 -0000 Received: (ofmipd 127.0.0.1); 19 Jun 2004 20:18:05 -0000 Date: 19 Jun 2004 16:18:27 -0400 Message-ID: From: "John R Levine" To: "Jim Lyon" Cc: "IETF-MXCOMP" Subject: RE: MARID Records and the standards process In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF42A6DD@df-fido-msg.exchange.corp.microsoft.com> References: <81AC085044D04B429F5FB883D94FA1AF42A6DD@df-fido-msg.exchange.corp.microsoft.com> Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > I send some of my outbound mail through MSN's mail servers, and some > through Comcast's mail servers. As things currently stand, I'd publish > a MARID record like: > v=spf1 +indirect:msn.com +indirect:comcast.com -all If I were a spammer sending Ci@l1s spam through zombies on MSN and Comcast, I agree that this is the SPF record I would use. But it is hard for me to imagine why anyone else would believe an attempt to piggyback on MSN and Comcast's reputation unless they already had other reasons to find me credible. > When we get into the question of reputation, the argument goes something > like: If you get mail from me through MSN's mail servers, you should > believe it's not spam because MSN does a good job of keeping its > customers from sending spam. Similarly, if you get mail from me through > Comcasts's mail servers. The degree to which you as a receiver believe > my mail is not spam is exactly a function of one of my ISP's > reputations. Perhaps, but you don't get to say that MSN and Comcast vouch for you. They do. That's why it's pointless to self-publish any reputation info beyond pointers to other sources that people might be willing to believe. In any event, I think that we need to take Vint Cerf's recently cited comments to heart here. He commented (roughly) that the Internet was built by doing experiments and writing up the results so that people could see how well they worked. At this point the only MARID-like thing that's had the benefit of experiments is SPF. SPF has all sorts of shortcomings that we all know, and I find even SPF overcomplex, but at least we have some idea how hard it is to publish and to decode. I'm not ruling out the possibility that people will find useful and interesting info to put into a MARID record that would be complex enough to merit XML, but at this point, it's all hypothetical. The reality is that for a lot of us, an XML parser would double the size of our SMTP daemons, and it'll take a more compelling argument than "we might come up with something" to make it worthwhile. The sensible approach is to send an SPF-ish design down the standards track, and to keep experimenting. Given the reception in the SPF community, they're not going to parse XML no matter what MARID says, and we need to keep in mind that the IETF can't tell anyone to do anything they're not inclined to do. If experiments show that recipients can use big rich XML data to deal with spam significantly better, great. At that point, it should be easy to send MARID 1.1 with XML along the track. But you have to do the work and show us the horse before you can get this cart moving. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor "I dropped the toothpaste", said Tom, crestfallenly. From owner-ietf-mxcomp@mail.imc.org Sat Jun 19 17:08:28 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08316 for ; Sat, 19 Jun 2004 17:08:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5JKmqVw046232; Sat, 19 Jun 2004 13:48:52 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5JKmqYE046231; Sat, 19 Jun 2004 13:48:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5JKmpXF046213 for ; Sat, 19 Jun 2004 13:48:51 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: GzQ/9ZsZncRXjvuBtivSDQ 1087678131 Received: from elvey.com (adsl-63-195-86-147.dsl.snfc21.pacbell.net [63.195.86.147]) by mail.messagingengine.com (Postfix) with ESMTP id 22EF2C09B53; Sat, 19 Jun 2004 16:48:50 -0400 (EDT) Message-ID: <40D4A6B2.4050700@elvey.com> Date: Sat, 19 Jun 2004 13:48:50 -0700 From: Matthew Elvey User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bill.mcinnis@messagelevel.com Cc: ietf-mxcomp@imc.org Subject: Factored lookup - ML patent claim issue. References: <200406181640.AA186450036@messagelevel.com> In-Reply-To: <200406181640.AA186450036@messagelevel.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 6/18/04 1:40 PM, Bill Mcinnis sent forth electrons to convey: > >Simplistically speaking, since domains/networks know how they are configured, why not have a mechanism that can sit on their domain and verify to those asking if a message came from their domain or network rather than trying to explain their whole setup to everyone? Likewise for those receiving the message have a mechanism that does the same thing in reverse. (for full disclosure this process is also something we have patent claims and working code on) That way you don’t have to list all of your users, ips, basically diagram your whole network setup to everyone. > Does ML have patent claims on the factored approach for checking if a domain has said an IP is in an authorized-to-mail part of its network? I.E. DMP's $REV-ADDRESS-1.in-addr._smtp-client.$FQDN ? (Adopted by FSV.) Stuff on factored being a good/bad idea: From Meng's familytree.pdf: "tradeoff: Block vs factored. Block records require more parsing, but subsequent lookups suffer zero marginal DNS cost. Factored records need less parsing, but each new negative means a new DNS lookup." The following section of draft-irtf-asrg-lmap-discussion-01.txt is relevant: 4.2. Network Infrastructure Publication of LMAP information results in a readily available list of IP addresses of hosts authorized to send messages associated with a domain. These lists yield information about the network structure, business relationships, and possibly other information about the domain owner, as growing number of domains are owned by single people or families. Such lists may also provide hostile parties with a list of targets for possible attacks. However, such information is often already publicly accessible through other means. Anyone communicating with individuals at a domain may readily obtain this information, and share it with anyone else. Business relationships have been discovered, for example, prior to official public announcements, by examining DNS records. Nearly all such private information about network structure and relationships may therefore be described as already being readily available. If such information is to be kept secret, it is the users responsibility to send messages in such a way as to keep that information private. From owner-ietf-mxcomp@mail.imc.org Sat Jun 19 17:45:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09366 for ; Sat, 19 Jun 2004 17:45:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5JLTUpA053668; Sat, 19 Jun 2004 14:29:30 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5JLTUSb053667; Sat, 19 Jun 2004 14:29:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tidy.obscurity.org (tidy.obscurity.org [66.199.168.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5JLTUns053651 for ; Sat, 19 Jun 2004 14:29:30 -0700 (PDT) (envelope-from ksoze@obscurity.org) Received: by tidy.obscurity.org (Postfix, from userid 1000) id 99D7F69B10; Sat, 19 Jun 2004 21:29:32 +0000 (UTC) Date: Sat, 19 Jun 2004 14:29:32 -0700 From: Sean Comeau To: "Hallam-Baker, Phillip" Cc: IETF MARID WG Subject: Re: Drive Towards Consensus [was Re: On Extensibility in MARID Re cords] Message-ID: <20040619212932.GC30711@obscurity.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Jun 18, 2004 at 08:55:35PM -0700, Hallam-Baker, Phillip wrote: > > Another example where SPF syntax comes unstuck. > > A domain uses S/MIME authentication in addition to IP based auth. This > allows a mail message from a bank to display the logo of the bank in a > privilleged part of the display by means of the X.509 logotypes extension. > That sounds like something that belongs only in MUAs. I think that's way beyond the scope of SPF and its ilk. > The following information is needed: > > * express statement 'all mail is signed' > * express the message digest of the signing certificate > * express the algorithm supported. > I claim, quite fairly, that spf syntax can handle this. > Now consider the following complications: > > * Also support pgp message format > * express different signing policies 'mail signed when extension > offered' > * handle the TLS protocol > * encryption > * different key distribution structures - web 'o trust, xkms, domain > key > [ ... ] > > This is not a theoretical proposal. The use of signed mail is already under > serious discussion in anti-phishing forums. > It all sounds pretty vague to me. Perhaps you could explain more of the details. > It took me less than half an hour to write a schema for this application in > XML. I don't think anyone could claim to write a parser for a corresponding > SPF syntax in the same time. > that doesn't make any sense. obviously defining a schema/format/syntax takes way less time than writing the code to actually read it. From owner-ietf-mxcomp@mail.imc.org Sat Jun 19 17:59:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09778 for ; Sat, 19 Jun 2004 17:59:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5JLmN0p057163; Sat, 19 Jun 2004 14:48:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5JLmN1K057162; Sat, 19 Jun 2004 14:48:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from goose.ehsco.com (goose.ehsco.com [207.65.203.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5JLmMAu057147 for ; Sat, 19 Jun 2004 14:48:23 -0700 (PDT) (envelope-from ehall@ehsco.com) Received: from [207.65.71.20] (ferret.corp.ntrg.com [207.65.71.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Eric A. Hall", Issuer "Network Technology Research Group Certificate Authority" (verified OK)) by goose.ehsco.com (Postfix ) with ESMTP id 4242220E7B; Sat, 19 Jun 2004 16:48:26 -0500 (CDT) Message-ID: <40D4B489.2080809@ehsco.com> Date: Sat, 19 Jun 2004 16:47:53 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John R Levine Cc: Jim Lyon , IETF-MXCOMP Subject: Re: MARID Records and the standards process References: <81AC085044D04B429F5FB883D94FA1AF42A6DD@df-fido-msg.exchange.corp.microsoft.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/19/2004 3:18 PM, John R Levine wrote: > If experiments show that recipients can use big rich XML data to deal > with spam significantly better, great. At that point, it should be > easy to send MARID 1.1 with XML along the track. But you have to do > the work and show us the horse before you can get this cart moving. I pretty much agree with John but on a slightly different tack. I think we (for some value of 'we') are trying to sneak email policy into an authentication scope, which is cart-horse inversion, as John says. If we really want to detail an email policy architecture, let's work on that as a discrete problem -- heck, we might even end up with receiver-side XML architecture of some kind. Instead it seems like we're trying to come up with excuses to sneak XML into DNS and declare that we've got ourselves an email policy framework. Backwards. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-ietf-mxcomp@mail.imc.org Sat Jun 19 18:02:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09914 for ; Sat, 19 Jun 2004 18:02:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5JLqrm1058015; Sat, 19 Jun 2004 14:52:53 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5JLqrcN058014; Sat, 19 Jun 2004 14:52:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5JLqqka057999 for ; Sat, 19 Jun 2004 14:52:52 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: L2Y4Ytinj+zfETzqfFujwg 1087681972 Received: from elvey.com (adsl-63-195-86-147.dsl.snfc21.pacbell.net [63.195.86.147]) by mail.messagingengine.com (Postfix) with ESMTP id 06AA4C0C8A6; Sat, 19 Jun 2004 17:52:51 -0400 (EDT) Message-ID: <40D4B5B2.1020204@elvey.com> Date: Sat, 19 Jun 2004 14:52:50 -0700 From: Matthew Elvey User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Greg Connor Cc: ietf-mxcomp@imc.org Subject: Re: Working toward unity on XML References: <11604246.1087337651@[10.12.1.26]> In-Reply-To: <11604246.1087337651@[10.12.1.26]> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/15/04 10:14 PM, Greg Connor sent forth electrons to convey: > > > I made the following comment during the jabber session yesterday, when > it seemed we were moving further and further away from an agreement on > XML: > >> gconnor: ...I don't want this issue, which I consider "not really >> central to >> the problem we are trying to solve" to tear the group apart > > > > What I would really prefer to see is a few paragraphs that say: > 1. What position you support Postion 2: no XML > 2. What other fallback or compromise positions you can live with, and CSV+NBB+SPF records replacing HNA. ( ~= 40% solution) Position 1: XML only > 3. How strongly you feel about one or the other. I feel strongly that we need to KISS. Hence 3&4 are even worse than 1, all of which I oppose strongly. We need to stick to DNS over UDP. Otherwise we will end up with a cure that is worse than the disease. Others have detailed the resource and interoperability impact. > > If you respond supporting one extreme, and don't state a compromise > position that you can live with (either 3 or 4 or something else I > haven't spelled out), then you might want to add a footnote saying why > you believe this issue is enough of a dealbreaker that you are not > willing to compromise, and why you are willing to let MARID fail > rather than give in on the issue. I'm not comfortable compromising because I have a real concern that with 1, MARID is more likely to fail. From owner-ietf-mxcomp@mail.imc.org Sat Jun 19 19:58:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14669 for ; Sat, 19 Jun 2004 19:58:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5JNeDPE078208; Sat, 19 Jun 2004 16:40:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5JNeDCh078203; Sat, 19 Jun 2004 16:40:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from miz-mishtal.dbc.mtview.ca.us (adsl-64-168-10-250.dsl.scrm01.pacbell.net [64.168.10.250]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5JNeAsm078177 for ; Sat, 19 Jun 2004 16:40:10 -0700 (PDT) (envelope-from mrose@dbc.mtview.ca.us) Received: from [IPv6:::1] (localhost [127.0.0.1]) by miz-mishtal.dbc.mtview.ca.us (8.12.10/8.12.9) with ESMTP id i5JNccqt003549; Sat, 19 Jun 2004 16:38:38 -0700 (PDT) In-Reply-To: <20040619212932.GC30711@obscurity.org> References: <20040619212932.GC30711@obscurity.org> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "Hallam-Baker, Phillip" , IETF MARID WG From: Marshall Rose Subject: Re: Drive Towards Consensus [was Re: On Extensibility in MARID Re cords] Date: Sat, 19 Jun 2004 16:38:42 -0700 To: Sean Comeau X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit sean - did you miss the part in my email where i very specifically told people not to reply directly to any examples until after sunday, june 20, 2004 23:59:59 us/pacific time? phillip - i ask that you do not reply to sean's note. sean - i ask you to resend that note after the deadline; furthermore, you have been warned. /mtr From owner-ietf-mxcomp@mail.imc.org Sat Jun 19 20:01:28 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14928 for ; Sat, 19 Jun 2004 20:01:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5JNn4xI079880; Sat, 19 Jun 2004 16:49:04 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5JNn4D5079879; Sat, 19 Jun 2004 16:49:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from miz-mishtal.dbc.mtview.ca.us (adsl-64-168-10-250.dsl.scrm01.pacbell.net [64.168.10.250]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5JNn3lE079867 for ; Sat, 19 Jun 2004 16:49:03 -0700 (PDT) (envelope-from mrose@dbc.mtview.ca.us) Received: from [IPv6:::1] (localhost [127.0.0.1]) by miz-mishtal.dbc.mtview.ca.us (8.12.10/8.12.9) with ESMTP id i5JNccqu003549; Sat, 19 Jun 2004 16:39:26 -0700 (PDT) In-Reply-To: <40D45468.3070206@zemos.net> References: <40D45468.3070206@zemos.net> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "Hallam-Baker, Phillip" , IETF MARID WG From: Marshall Rose Subject: Re: Drive Towards Consensus [was Re: On Extensibility in MARID Records] Date: Sat, 19 Jun 2004 16:39:30 -0700 To: Philip Miller X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit philip miller - did you miss the part in my email where i very specifically told people not to reply directly to any examples until after sunday, june 20, 2004 23:59:59 us/pacific time? phillip hallam-baker - i ask that you do not reply to philip miller's note. sean - i ask you to resend that note after the deadline; furthermore, you have been warned. /mtr From owner-ietf-mxcomp@mail.imc.org Sun Jun 20 03:27:57 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19817 for ; Sun, 20 Jun 2004 03:27:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5K77Yx7060380; Sun, 20 Jun 2004 00:07:34 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5K77Yos060379; Sun, 20 Jun 2004 00:07:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5K77YLe060365 for ; Sun, 20 Jun 2004 00:07:34 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Sun, 20 Jun 2004 00:07:34 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 20 Jun 2004 00:07:34 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 20 Jun 2004 00:07:34 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: MARID Records and the standards process Date: Sun, 20 Jun 2004 00:07:23 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF42A93A@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: MARID Records and the standards process thread-index: AcRWOpY00Sflf4P/SyideR61qi3vcwAWAong From: "Jim Lyon" To: "John R Levine" Cc: "IETF-MXCOMP" X-OriginalArrivalTime: 20 Jun 2004 07:07:34.0260 (UTC) FILETIME=[42B6AB40:01C45695] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5K77YLe060372 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit John Levine wrote (regarding a MARID record like +indirect:msn.com/targetrep): > If I were a spammer sending Ci@l1s spam through zombies on > MSN and Comcast, I agree that this is the SPF record I would > use. But it is hard for me to imagine why anyone else would > believe an attempt to piggyback on MSN and Comcast's reputation > unless they already had other reasons to find me credible. You get to piggyback on MSN's reputation exactly when you send mail through their mail servers. If MSN has a reputation for not sending spam, and you get my domain's mail from MSN's servers, then you can be assured it's not spam, because if I try to send spam, MSN will either kick me off, rate-limit me, or fine me. This is exactly why the questions of authentication and reputation are intertwined. You don't get to piggyback on MSN's reputation if your mail doesn't go through MSN's servers. Regarding XML or not, John wrote: > If experiments show that recipients can use big rich XML data > to deal with spam significantly better, great. At that point, > it should be easy to send MARID 1.1 with XML along the track. > But you have to do the work and show us the horse before you > can get this cart moving. Assuming that MARID 1.0 enjoys any success, then if we go down the route you suggest there will be lots of MTAs and other programs out there that understand SPF-style syntax, but not XML. If we then define an XML syntax, it would be a hard step for a domain to publish using it, because their record becomes effectively invisible to all of the then-deployed MTAs out there. In short, discontinuous changes of format seldom happen. Upward-compatible extensions happen all the time. SPF format does not have sufficient extensibility. XML does. -- jimbo From owner-ietf-mxcomp@mail.imc.org Sun Jun 20 04:24:12 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22168 for ; Sun, 20 Jun 2004 04:24:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5K8CQsq090648; Sun, 20 Jun 2004 01:12:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5K8CQ8V090647; Sun, 20 Jun 2004 01:12:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5K8CPfR090616 for ; Sun, 20 Jun 2004 01:12:25 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i5K8Bkqg018345; Sun, 20 Jun 2004 01:11:46 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i5K8Bkk8018342; Sun, 20 Jun 2004 01:11:46 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Sun, 20 Jun 2004 01:11:46 -0700 (PDT) From: "william(at)elan.net" To: "Eric A. Hall" cc: John R Levine , Jim Lyon , IETF-MXCOMP Subject: Re: MARID Records and the standards process In-Reply-To: <40D4B489.2080809@ehsco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, 19 Jun 2004, Eric A. Hall wrote: > On 6/19/2004 3:18 PM, John R Levine wrote: > > > If experiments show that recipients can use big rich XML data to deal > > with spam significantly better, great. At that point, it should be > > easy to send MARID 1.1 with XML along the track. But you have to do > > the work and show us the horse before you can get this cart moving. > > I pretty much agree with John but on a slightly different tack. > > I think we (for some value of 'we') are trying to sneak email policy into > an authentication scope, which is cart-horse inversion, as John says. If > we really want to detail an email policy architecture, let's work on that > as a discrete problem -- heck, we might even end up with receiver-side XML > architecture of some kind. Instead it seems like we're trying to come up > with excuses to sneak XML into DNS and declare that we've got ourselves an > email policy framework. Backwards. I STRONGLY agree with above statements. XML would likely be great for creating wide-scale policy document and I agree with Jim that is what SPF will likely need to become in the future. But this kind of document is almost certain to be larger then what can be put into DNS and we need new protocol for it. At this time I believe we should leave SPF syntax as is with maybe some additions for better extensibility (possibly new scoping operator) and add ability to refer to different external policy service from SPF record. This serves as quick patch that reuses current architecture and can be deployed quickly (which is what this was all about). The new policy service can then be developed in normal IETF process and can reuse current work done by Microsoft in regards to SPF/XML and document and define how to best get to users but would not have constrains of having to be fit into records that using DNS database service forces on us, nor would it have constraints of single-key data lookups which allows for user wildcards and other features. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Sun Jun 20 06:01:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25765 for ; Sun, 20 Jun 2004 06:01:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5K9lQJo035514; Sun, 20 Jun 2004 02:47:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5K9lQn7035513; Sun, 20 Jun 2004 02:47:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (catinthebox.net [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5K9lPEs035477 for ; Sun, 20 Jun 2004 02:47:25 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Sun, 20 Jun 2004 05:50:57 -0400 Received: from ([68.223.169.60]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 1535705032; Sun, 20 Jun 2004 05:50:56 -0400 Message-ID: <000701c456ac$942bf950$6401a8c0@hdev1> From: "Hector Santos" To: "Jim Lyon" , "John R Levine" Cc: "IETF-MXCOMP" References: <81AC085044D04B429F5FB883D94FA1AF42A93A@df-fido-msg.exchange.corp.microsoft.com> Subject: Re: MARID Records and the standards process Date: Sun, 20 Jun 2004 05:54:25 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.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: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Jim Lyon" To: "John R Levine" Cc: "IETF-MXCOMP" Sent: Sunday, June 20, 2004 3:07 AM Subject: RE: MARID Records and the standards process > In short, discontinuous changes of format seldom happen. > Upward-compatible extensions happen all the time. SPF format does not > have sufficient extensibility. XML does. This might be true, but that is only because of the assumptions being used for SPF format. Microsoft has it written that XML can be broken up into multiple records? Correct? So why can't this apply to SPF as well? Sure, XML is ok and will support extensions. But XML doesn't have a copyright on flexible extension layouts or format. Here is example of a simple format and extension concept that is flexibility with extreme easy interpretation. XML requires the reading of the entire required for integrity, the following does not. This is based on a unfinished proposal I was writing awhile back called TIDAL for "Transaction IDentification Authentication Logic" Note: Verbosity of Records intentional for illustration purposes. Also, I did this long ago before I knew any idea of optimization for TXT vs RR. It is the concept that is important here. Not the size or record type. DNS TXT record _tidal.example.com IN TXT "TIDAL.VERSION=1.3" IN TXT "TIDAL.SERVER.PRODUCT=WCSMTP" IN TXT "TIDAL.SERVER.SID=2020-2929-AB2F-9323" IN TXT "TIDAL.SERVER.CHALLENGE=A58F-2322-DE2F-232A" IN TXT "TIDAL.SERVER.FLAGS="AUTHREG, NOSPAM, PTRREQ" IN TXT "TIDAL.SERVER.HOURS.OPEN=9-17 EST, EMPLOYEE, VENDORS" IN TXT "TIDAL.SERVER.HOURS.OPEN=20-23 EST, EXTERNAL" IN TXT "TIDAL.SERVER.HOURS.DAYS=Mon-Fri" IN TXT "TIDAL.SERVER.RFC=3821" IN TXT "TIDAL.CLIENT.ACCEPT.IP4=208.248.131.9" IN TXT "TIDAL.CONTACT.ABUSE="abuse@example.com" IN TXT "TIDAL.UBE.GATEWAY="forspammers.examples.com" IN TXT "TIDAL.MAIL.ATTACHMENTS.SIZE=NONE" IN TXT "TIDAL.MAIL.ATTACHMENTS.RESTRICTED="DOC, JPG, BMP, XLS, RTF" IN TXT "TIDAL.MAIL.RECIPIENT.MAX=10" Minimum TIDAL records required (most systems) TIDAL.VERSION=major.minor TIDAL.CLIENT.ACCEPT.x=y X=Y could be the standard SPF/MCEP concepts that we have today. Since we are talking about possible extension, TIDAL was a proposal that incorporates most of my mail hosting, transport and gateway design experiences in the past 25+ years in multiple C/S and P2P mail networks and as a early pioneer in BBS systems and offline mail systems. In 1984, I designed the 3rd Offline Mail product in the market place behind TAPCIS and QWK. I made the most money off the two since TAPCIS targeted CompusServe, the original QWK targetted PCBOARD and Silver Xpress (my product) called over 20+ BBS Online Mail Hosting Systems, including the top 3 multi-million dollars BBS systems that was helping define the new wave of PC based electronic communications. Of all the mail products that was not under my control was the direct ownership of a BBS product, but we have a product that covered every other aspect of the mail market. As these early markets was evolving to the new Internet, in 1996 we brought the #1 BBS system at the time newly designed for WIndows and the internet called WINSERVER "Wildcat! Interactive Net Server." It was atleast 5 years ahead of its time and today with Microsoft .Net as the closest technology to what we have today. The point of this short resume is to show why I think the following extensions is something I see as fitting the mold of current and future mail design requirements. o Living with SPAM. It should go with saying SPAM is here to stay. The advertising and marketing dollars behind it simply too big to be ignored. The purpose of CANSPAM was to offer a compromise between the capitalistic realisms of the market place and the required correction required in the technology to minimize the end-market concerns and abuse. TIDAL offers a way for spammers to fit into the mail model by helping them be legit. Yet, at the same time, mail systems will like to avoid SPAM or make it available during certain parts of the day. The goal here is to help shift overhead to the spammer by having them lookup the tidal records to determine what are server attribute and policies. What can the spammer learn here? TIDAL.SERVER.FLAGS="AUTHREG, NOSPAM, PTRREQ" TIDAL.SERVER.HOURS.OPEN=9-17 EST, EMPLOYEE, VENDORS TIDAL.SERVER.HOURS.OPEN=20-23 EST, EXTERNAL TIDAL.SERVER.HOURS.DAYS=Mon-Fri TIDAL.SERVER.RFC=3821 TIDAL.UBE.GATEWAY="forspammers.examples.com" The spammer can see what opens is the server open for unsolicated mail, and he can see that the server has provided a specific gateway host to use. He can also see whether the host allows spam and the type of authentication required or checks done to allow mail sending. Of course, these are extensions. You don't need to support them, but if wanted to added more server attribute flags or extensions you can easily do. For example, Microsoft may want to introduce a way for spammers to contact them for registration: TIDAL.UBE.REGISTRATION=http://spammer.registration.microsoft.com o Operational Hours Spammer or not, companies would love to be able to define how their mail servers are being used. This will reduce scalarbility requirements and cost. A Tidal Server can define the hours of operations based on the type of transaction: TIDAL.SERVER.HOURS.OPEN=9-17 EST, EMPLOYEE, VENDORS TIDAL.SERVER.HOURS.OPEN=20-23 EST, EXTERNAL TIDAL.SERVER.HOURS.DAYS=Mon-Fri This basically says the servers are down on the weekends so clients should even try to send mail over the weekend. It also says that only employees and vendors can send mail during business hours and that a 3 hour window is available for anonymous transactions. Why will clients support this? Because they won't be able to send mail otherwise. Clients will support it because the efficient of their operation is improved allowing them schedule mail at the appropiate time. o Acceptable Mail Tidal Servers can define server attributes defining the type of acceptable mail, for example: TIDAL.MAIL.ATTACHMENTS.SIZE=NONE TIDAL.MAIL.ATTACHMENTS.RESTRICTED="DOC, JPG, BMP, XLS, RTF" TIDAL.MAIL.RECIPIENT.MAX=10 In this case, the TIDAL server has no limits on size but it will reject mail containing DOC, JPB, BMP, XLS or RTF context. It also specifies a limit on the number of recepients allowed. Possible MAIL attributes extensions might be Microsoft defining the maximum number of messages allowed per IP TIDAL.MAIL.IPLIMIT=100 TIDAL.MAIL.IPLIMIT.HOURLY=5 TIDAL.MAIL.IPLIMIT.DAILY=10 That basically says that the sender has 100 days since its initial message to send a maximum of 1000 messages but can only do so 10 per day and 5 per hour. You might even want to add an expiration per IP TIDAL.MAIL.IP.EXPIRE=20040701 etc. o Sender Authethication Of course, the main goal in all this is to authenticate the sender. Besides the fact that there is a certain level of "implied authorization" with a client supporting tidal records, at the most basic level, we can have the standard concepts used by SPF/MCEP to define the tidal records: TIDAL.CLIENT.ACCEPT.MX TIDAL.CLIENT.ACCEPT.IP4 TIDAL.CLIENT.ACCEPT.IP6 TIDAL.CLIENT.REJECT.MX TIDAL.CLIENT.REJECT.IP4 TIDAL.CLIENT.REJECT.IP6 etc, a possible extension for reporting can be isolated to just IP6 lookups: TIDAL.CLIENT.REJECT.IP6.REPORT=xxxxxxxxxxxx but TIDAL goes further to promote true Client/Server handshaking negotiation ideas using product identification, serialization, hashing and challenge handshaking response concepts. TIDAL.SERVER.PRODUCT=WCSMTP TIDAL.SERVER.SID=2020-2929-AB2F-9323 TIDAL.SERVER.CHALLENGE=A58F-2322-DE2F-232A But of course, this is all beyond the scope of MARID. Finally, if you have not noticed yet, the TIDAL format is compatible with XML conversion with no lost in functionality. Jim, my main point is that you can be flexibilty with extensions using an easy to write and read non-XML format. With all this said, XML has only one benefit - marketability. Say XML, right or wrong, people have a clue of what it is and what to expect. I just want you to realize that XML and support XML extensions requires the reading and parsing of the entire structure otherwise, some XML parsers, including the Microsoft XML parser will return a "invalid/illegal XML format" error. A parsing logic for SPF (or TIDAL) does not required the reading of all the records. Only what the client understands and supports. This is important because SPF allows for short circuiting. XML may have trouble with this important client conditional logic. XML requires the entire structure to be syntaxically correct first because you can even begin using its rules. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Sun Jun 20 17:29:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00433 for ; Sun, 20 Jun 2004 17:29:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5KLDJQo079289; Sun, 20 Jun 2004 14:13:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5KLDJet079288; Sun, 20 Jun 2004 14:13:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5KLDFog079242 for ; Sun, 20 Jun 2004 14:13:15 -0700 (PDT) (envelope-from roy+dated+1090357996.ded380@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i5KLDGRC047299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 20 Jun 2004 21:13:17 GMT (envelope-from roy+dated+1090357996.ded380@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5KLDGHO045145 for ; Sun, 20 Jun 2004 22:13:16 +0100 (BST) (envelope-from roy+dated+1090357996.ded380@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5KLDGxV045144 for ietf-mxcomp@imc.org; Sun, 20 Jun 2004 22:13:16 +0100 (BST) (envelope-from roy+dated+1090357996.ded380@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sun, 20 Jun 2004 22:13:13 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16597.65000.623072.17644@giles.gnomon.org.uk> Date: Sun, 20 Jun 2004 22:13:12 +0100 To: "Alan DeKok" Cc: ietf-mxcomp@imc.org Subject: Re: CSV, NBB In-Reply-To: <20040619145901.4DE5516FAB@mail.nitros9.org> References: <16596.12497.349996.93747@giles.gnomon.org.uk> <20040619145901.4DE5516FAB@mail.nitros9.org> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Alan" == Alan DeKok writes: Alan> Roy Badami wrote: >> Personally I'm very strongly against any mandate for accepting >> and destroying messages. Alan> This is already happening on the net today, due to Alan> deficiencies in SMTP. I agree it's happening; I remain to be convinced that it's a good thing... Alan> That requirement is impossible to implement in practice. RFC1123 and 2821 do contain a note that this may not be possible in all circumstances. Alan> Bounced where? How can you tell that the bounce path is Alan> valid, and that you're not spamming the MAIL FROM site with Alan> bounces from forged messages? Bounced to the MAIL FROM. I agree that you can't tell that it's authentic. But silently dropping messages when an administrator misconfigures their MARID record is going to make debugging difficult. IMHO the correct place to drop unwanted bounces is at the MTA receiving the bounce, since it is in the best position to determine whether it relates to a message originated by that address. -roy From owner-ietf-mxcomp@mail.imc.org Sun Jun 20 17:56:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01664 for ; Sun, 20 Jun 2004 17:56:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5KLZglH083696; Sun, 20 Jun 2004 14:35:42 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5KLZgjC083695; Sun, 20 Jun 2004 14:35:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5KLZfhQ083689 for ; Sun, 20 Jun 2004 14:35:42 -0700 (PDT) (envelope-from roy+dated+1090359344.501d41@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i5KLZiRC084091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 20 Jun 2004 21:35:44 GMT (envelope-from roy+dated+1090359344.501d41@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5KLZiWH045384 for ; Sun, 20 Jun 2004 22:35:44 +0100 (BST) (envelope-from roy+dated+1090359344.501d41@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5KLZi6P045379 for ietf-mxcomp@imc.org; Sun, 20 Jun 2004 22:35:44 +0100 (BST) (envelope-from roy+dated+1090359344.501d41@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sun, 20 Jun 2004 22:35:42 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16598.814.193830.480774@giles.gnomon.org.uk> Date: Sun, 20 Jun 2004 22:35:42 +0100 To: Matthew Elvey Cc: Roy Badami , MXCOMP Subject: Re: CSV, NBB In-Reply-To: <40D48C40.10208@elvey.com> References: <1665390638.20040614190711@brandenburg.com> <20040615031048.GP44160@verdi> <40CE9F08.2050002@elvey.com> <20040615115828.GQ44160@verdi> <1087328029.10303.198484820@webmail.messagingengine.com> <20040616164710.GG38007@verdi> <40D36596.6050907@elvey.com> <40D3B7D5.90803@elvey.com> <16596.12497.349996.93747@giles.gnomon.org.uk> <40D48C40.10208@elvey.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Matthew" == Matthew Elvey writes: Matthew> Are you for other proposals that avoid explicitly saying Matthew> that in situation S, accepting and destroying a message Matthew> is appropriate, even though it's obvious that this is Matthew> what they're endorsing? No; I'm against blackholing messages under any circumstances. We'll end up with an unreliable mail transport and we'll lose an important debugging aid. Matthew> Problems would have to occur simultaneously: Matthew> * the mail is sent in direct violation of MARID checks, and Matthew> * the responsible domain admin has said -all (or the equivalent Matthew> in different syntax), not ~all or ?all. Matthew> * the mail has gone through a forwarding system and Matthew> * the forwarding system has not implemented SRS and Matthew> * the forwarding system (e.g. mailing list) isn't whitelisted. I'm more concerned with problems like misconfigured MARID records.... >> NBB is not going to prevent the problem of joe jobs. >> Matthew> Why not? Your statement lacks an argument. Because the proposal endorses SMTP level rejection (which I'm all in favour of). In many circumstances this will cause the upstream MTA to bounce the message to the MAIL FROM. >> Nor even would SPFv1. >> Matthew> I think that's incorrect too. Because again SPF mandates SMTP rejections. Consider forged mail sent through an open relay. At the moment, only the undeliverable mail will bounce to the MAIL FROM. SPFv1 causes more of the forged mail to be rejected and actually makes the joe job problem worse... Matthew> I interpret this to mean Meng disagrees with you on this. Matthew> "SPF was originally designed to prevent joe-jobs." - I've never believed this, but that doesn't mean I'm against SPF and other MARID schemes. They're valuable for other reasons. The only way SPFv1 will prevent joe jobs is that if it's so successful and widely deployed that spammers completely give up attempting to send forged mail since they know it zero chance of reaching its recipient. I don't see that happening in the medium term, if ever. Matthew> No, we have some solutions that ALLOW joe jobs, but make Matthew> them not directly end-user-visible (if the receiving Matthew> server doesn't die under the load of the joe-jobs it is Matthew> receiving). Yes, that's true. Matthew> The end system does the accepting and destroying of a Matthew> message that you say is not appropriate in other Matthew> situations. Correct. It's not ideal, but it's the lesser evil. And it happens at a place where useful logging can occur. And I believe it's going to happen anyway. Matthew> Also they don't work when users are able to send messages Matthew> from wherever (without forging) using their usual email Matthew> address. With what I'm proposing, they can still do Matthew> this. Schemes that use a cryptographic checksum (whether in the MAIL FROM, Message-ID or an extension header) can be made to work in these circumstances. Matthew> Obviously. The point of NBB is to address this problem. Matthew> So if it's solved, there's no point. Circular reasoning. Matthew> The question is why my/another solution is better. Because NBB will only prevent forged bounces from arriving in my mailbox if *everyone* on the Internet implements it (and not even then, given upstream bounces). Given that's going to take a long time, I'm going to want to implement one of the other schemes to give me protection now, rather than years from now. The kinds of scheme I describe are starting to be deployed, and I expect them to start becoming commonplace... Given this kind of scheme is going to have to be deployed anyway, NBB adds little value and removes an important reliability principle and debugging tool. -roy From owner-ietf-mxcomp@mail.imc.org Sun Jun 20 17:57:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01712 for ; Sun, 20 Jun 2004 17:57:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5KLlPiD085921; Sun, 20 Jun 2004 14:47:25 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5KLlPSV085920; Sun, 20 Jun 2004 14:47:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5KLlOKi085914 for ; Sun, 20 Jun 2004 14:47:25 -0700 (PDT) (envelope-from roy+dated+1090360047.98f96c@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i5KLlSRC003065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 20 Jun 2004 21:47:29 GMT (envelope-from roy+dated+1090360047.98f96c@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5KLlSMM045425 for ; Sun, 20 Jun 2004 22:47:28 +0100 (BST) (envelope-from roy+dated+1090360047.98f96c@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5KLlSaW045424 for ietf-mxcomp@imc.org; Sun, 20 Jun 2004 22:47:28 +0100 (BST) (envelope-from roy+dated+1090360047.98f96c@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sun, 20 Jun 2004 22:47:27 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16598.1518.910455.761346@giles.gnomon.org.uk> Date: Sun, 20 Jun 2004 22:47:26 +0100 To: Matthew Elvey cc: MXCOMP Subject: Re: CSV, NBB In-Reply-To: <16598.814.193830.480774@giles.gnomon.org.uk> References: <1665390638.20040614190711@brandenburg.com> <20040615031048.GP44160@verdi> <40CE9F08.2050002@elvey.com> <20040615115828.GQ44160@verdi> <1087328029.10303.198484820@webmail.messagingengine.com> <20040616164710.GG38007@verdi> <40D36596.6050907@elvey.com> <40D3B7D5.90803@elvey.com> <16596.12497.349996.93747@giles.gnomon.org.uk> <40D48C40.10208@elvey.com> <16598.814.193830.480774@giles.gnomon.org.uk> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Matthew> Obviously. The point of NBB is to address this problem. Matthew> So if it's solved, there's no point. Circular reasoning. Matthew> The question is why my/another solution is better. I replied: Roy> Because NBB will only prevent forged bounces from arriving in Roy> my mailbox if *everyone* on the Internet implements it (and Roy> not even then, given upstream bounces). Or, put another way: If I implement NBB on *my* MTAs, it does nothing to make *my* life better, but I make a very small step towards making *everyone else's* life better. Once when enough people do likewise, my like gets a lot better. If I implement one of the bounce discarding schemes, *I* benefit immediately and substantially. So there's a much stronger incentive for me to implement. -roy From owner-ietf-mxcomp@mail.imc.org Sun Jun 20 19:12:41 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06521 for ; Sun, 20 Jun 2004 19:12:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5KMsgXi098725; Sun, 20 Jun 2004 15:54:43 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5KMsgTq098724; Sun, 20 Jun 2004 15:54:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5KMseFi098706 for ; Sun, 20 Jun 2004 15:54:40 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: MHMV+kOc4+U7+9IZxH7QOw 1087772080 Received: from elvey.com (adsl-63-195-86-147.dsl.snfc21.pacbell.net [63.195.86.147]) by mail.messagingengine.com (Postfix) with ESMTP id 110A2C0CAF9; Sun, 20 Jun 2004 18:54:39 -0400 (EDT) Message-ID: <40D615AC.1080101@elvey.com> Date: Sun, 20 Jun 2004 15:54:36 -0700 From: Matthew Elvey User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roy Badami Cc: MXCOMP Subject: Re: CSV, NBB References: <1665390638.20040614190711@brandenburg.com> <20040615031048.GP44160@verdi> <40CE9F08.2050002@elvey.com> <20040615115828.GQ44160@verdi> <1087328029.10303.198484820@webmail.messagingengine.com> <20040616164710.GG38007@verdi> <40D36596.6050907@elvey.com> <40D3B7D5.90803@elvey.com> <16596.12497.349996.93747@giles.gnomon.org.uk> <40D48C40.10208@elvey.com> <16598.814.193830.480774@giles.gnomon.org.uk> <16598.1518.910455.761346@giles.gnomon.org.uk> In-Reply-To: <16598.1518.910455.761346@giles.gnomon.org.uk> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/20/04 2:47 PM, Roy Badami sent forth electrons to convey: >If I implement NBB on *my* MTAs, it does nothing to make *my* life >better, but I make a very small step towards making *everyone else's* >life better. Once when enough people do likewise, my like gets a lot >better. > > Not true. If recipients of x %, e.g. 90% of the mail out there implement NBB, then as soon as you publish MARID records for your domain, you'll get around x %, e.g. 90% fewer joe jobs. Meng's latest SPF plan (in which he has borrowed my idea of CSV semantics using SPF records) makes it much easier to implement SPF than the plan in the current RFC draft. Implementation of SPF by nearly all legit senders will be much more feasible soon. Yay! Anyway, if SPF doesn't advocate NBB, then at least in the case of post-SMTP SPF implementations, the SPF-Received header will show a fail, and the would-be joe job victim can potentially detect and take that into account when deciding the disposition of the resulting bounce. But in the (hopefully more common) case of SMTP+SPF receivers, there may not be a way to tell that the bounce was the result of an SPF "fail". Perhaps that can be remedied, e.g. a via a fixed (grep-able) string included in all exp replies. BTW, you are not accurate when you say SPF 'endorses' SMTP rejection. The spec says "An SPF email system MAY choose to reject or discard email on the basis of local policy." It also says "MTAs MAY reject the message using a permanent failure reply code. (Code 550 is RECOMMENDED. ...)" That's MAY, not SHOULD or MUST. I would be interested to hear what others think - should SMTP+SPF receivers reject or discard messages that SPF "fail" (e.g. hit -all, not "error" or "unknown")? (Perhaps it makes sense to reject for a while by default and then sunrise discard as the default.) From owner-ietf-mxcomp@mail.imc.org Sun Jun 20 19:28:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07124 for ; Sun, 20 Jun 2004 19:28:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5KNBUaE001989; Sun, 20 Jun 2004 16:11:30 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5KNBUBt001988; Sun, 20 Jun 2004 16:11:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5KNBSwo001980 for ; Sun, 20 Jun 2004 16:11:28 -0700 (PDT) (envelope-from roy+dated+1090365090.041088@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i5KNBVRC094997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 20 Jun 2004 23:11:32 GMT (envelope-from roy+dated+1090365090.041088@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5KNBV3U045778 for ; Mon, 21 Jun 2004 00:11:31 +0100 (BST) (envelope-from roy+dated+1090365090.041088@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5KNBUpC045773 for ietf-mxcomp@imc.org; Mon, 21 Jun 2004 00:11:30 +0100 (BST) (envelope-from roy+dated+1090365090.041088@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Mon, 21 Jun 2004 00:11:30 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16598.6561.605955.535057@giles.gnomon.org.uk> Date: Mon, 21 Jun 2004 00:11:29 +0100 To: Matthew Elvey Cc: Roy Badami , MXCOMP Subject: Re: CSV, NBB In-Reply-To: <40D615AC.1080101@elvey.com> References: <1665390638.20040614190711@brandenburg.com> <20040615031048.GP44160@verdi> <40CE9F08.2050002@elvey.com> <20040615115828.GQ44160@verdi> <1087328029.10303.198484820@webmail.messagingengine.com> <20040616164710.GG38007@verdi> <40D36596.6050907@elvey.com> <40D3B7D5.90803@elvey.com> <16596.12497.349996.93747@giles.gnomon.org.uk> <40D48C40.10208@elvey.com> <16598.814.193830.480774@giles.gnomon.org.uk> <16598.1518.910455.761346@giles.gnomon.org.uk> <40D615AC.1080101@elvey.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Matthew" == Matthew Elvey writes: >> Matthew> Not true. If recipients of x %, e.g. 90% of the mail out Matthew> there implement NBB, then as soon as you publish MARID Matthew> records for your domain, you'll get around x %, e.g. 90% Matthew> fewer joe jobs. Agreed. But I have to wait for a substantial proportion of the Internet to implement NBB before I begin to see the benefits. Matthew> Meng's latest SPF plan (in which he has borrowed my idea Matthew> of CSV semantics using SPF records) makes it much easier Matthew> to implement SPF than the plan in the current RFC draft. Matthew> Implementation of SPF by nearly all legit senders will be Matthew> much more feasible soon. Yay! It's an interesting idea; do you know if an ID is forthcoming? Matthew> BTW, you are not accurate when you say SPF 'endorses' Matthew> SMTP rejection. The spec says "An SPF email system MAY Matthew> choose to reject or discard email on the basis of local Matthew> policy." It also says "MTAs MAY reject the message using Matthew> a permanent failure reply code. (Code 550 is Matthew> RECOMMENDED. ...)" That's MAY, not SHOULD or MUST. I misremembered. But I'd still call that an endorsement. It's not exactly a SHOULD NOT. Matthew> I would be interested to hear what others think - should Matthew> SMTP+SPF receivers reject or discard messages that SPF Matthew> "fail" (e.g. hit -all, not "error" or "unknown")? Matthew> (Perhaps it makes sense to reject for a while by default Matthew> and then sunrise discard as the default.) I'm dead against that. For the record, this is my current position: I think SMTP-time rejection should be used whenever possible. I'm currently of the position that when it's not possible it's reasonable, and even disirable, to originate a bounce, despite the high probability that the MAIL FROM may be forged. I'm willing to be convinced otherwise on this point though... I'm absolutely dead against the idea of lying in the SMTP response codes, and claiming you've accepted the message when you've already determined you're going to do know such thing. That way lies madness. I can see why it might be expedient to do this (AFAICS it's the only way to prevent upstream bounces to forged addresses) but as I said before (IMHO) the cure is worse than the disease... -roy From owner-ietf-mxcomp@mail.imc.org Sun Jun 20 20:57:39 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11434 for ; Sun, 20 Jun 2004 20:57:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5L0hmic019022; Sun, 20 Jun 2004 17:43:48 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5L0hmL1019021; Sun, 20 Jun 2004 17:43:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5L0hiFF019002 for ; Sun, 20 Jun 2004 17:43:46 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: d+UG4eL/IxwXdkTkhxYbaw 1087778624 Received: from elvey.com (adsl-63-195-86-147.dsl.snfc21.pacbell.net [63.195.86.147]) by mail.messagingengine.com (Postfix) with ESMTP id 30C01C0C601; Sun, 20 Jun 2004 20:43:43 -0400 (EDT) Message-ID: <40D62F3C.1010306@elvey.com> Date: Sun, 20 Jun 2004 17:43:40 -0700 From: Matthew Elvey User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roy Badami Cc: MXCOMP Subject: Re: CSV (NBB, SPF incorporation of HELO check) References: <1665390638.20040614190711@brandenburg.com> <20040615031048.GP44160@verdi> <40CE9F08.2050002@elvey.com> <20040615115828.GQ44160@verdi> <1087328029.10303.198484820@webmail.messagingengine.com> <20040616164710.GG38007@verdi> <40D36596.6050907@elvey.com> <40D3B7D5.90803@elvey.com> <16596.12497.349996.93747@giles.gnomon.org.uk> <40D48C40.10208@elvey.com> <16598.814.193830.480774@giles.gnomon.org.uk> <16598.1518.910455.761346@giles.gnomon.org.uk> <40D615AC.1080101@elvey.com> <16598.6561.605955.535057@giles.gnomon.org.uk> In-Reply-To: <16598.6561.605955.535057@giles.gnomon.org.uk> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/20/04 4:11 PM, Roy Badami sent forth electrons to convey: >>>>>>"Matthew" == Matthew Elvey writes: >>>>>> > Matthew> Meng's latest SPF plan (in which he has borrowed my idea > Matthew> of CSV semantics using SPF records) makes it much easier > Matthew> to implement SPF than the plan in the current RFC draft. > Matthew> Implementation of SPF by nearly all legit senders will be > Matthew> much more feasible soon. Yay! > >It's an interesting idea; do you know if an ID is forthcoming? > > I just posted to spf-discuss for the first time: http://archives.listbox.com/spf-discuss@v2.listbox.com/200406/0958.html I read the thread about this: http://archives.listbox.com/spf-discuss@v2.listbox.com/200406/0886.html The latest I-D is dated May '04, and doesn't reflect this "Unified SPF". We'll see if it's in SenderID, which is what the SPF - CID merger effort is being called, I think. This thread makes me think it will. I'm hopeful that spf code out there will soon check by default as per http://spf.pobox.com/slides/unified%20spf/0428.html. That slide is from the slideshow at http://spf.pobox.com/slides/unified%20spf/index.html that Meng pointed me to. > Matthew> I would be interested to hear what others think - should > Matthew> SMTP+SPF receivers reject or discard messages that SPF > Matthew> "fail" (e.g. hit -all, not "error" or "unknown")? > Matthew> (Perhaps it makes sense to reject for a while by default > Matthew> and then sunrise discard as the default.) > >I'm dead against that. > That was clear. I'm halfway won over, hence the 'what *others* think'. I was going to post there about NBB, but am holding off; if no one likes the idea here, why bring it up there? I figure we'll hear back after the weekend re. > Dave, John, Doug: > Have you considered and rejected or not considered adding the NBB idea > that I threw out a while back to the CSV spec? From owner-ietf-mxcomp@mail.imc.org Sun Jun 20 21:27:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12998 for ; Sun, 20 Jun 2004 21:27:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5L1IM0W025496; Sun, 20 Jun 2004 18:18:22 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5L1ILrI025495; Sun, 20 Jun 2004 18:18:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5L1IHWD025475 for ; Sun, 20 Jun 2004 18:18:17 -0700 (PDT) (envelope-from roy+dated+1090372701.8ae544@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i5L1ILRC057788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 21 Jun 2004 01:18:22 GMT (envelope-from roy+dated+1090372701.8ae544@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5L1ILi5046175 for ; Mon, 21 Jun 2004 02:18:21 +0100 (BST) (envelope-from roy+dated+1090372701.8ae544@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5L1ILLX046170 for ietf-mxcomp@imc.org; Mon, 21 Jun 2004 02:18:21 +0100 (BST) (envelope-from roy+dated+1090372701.8ae544@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Mon, 21 Jun 2004 02:18:20 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16598.14171.860543.907321@giles.gnomon.org.uk> Date: Mon, 21 Jun 2004 02:18:19 +0100 To: Matthew Elvey Cc: Roy Badami , MXCOMP Subject: Re: CSV (NBB, SPF incorporation of HELO check) In-Reply-To: <40D62F3C.1010306@elvey.com> References: <1665390638.20040614190711@brandenburg.com> <20040615031048.GP44160@verdi> <40CE9F08.2050002@elvey.com> <20040615115828.GQ44160@verdi> <1087328029.10303.198484820@webmail.messagingengine.com> <20040616164710.GG38007@verdi> <40D36596.6050907@elvey.com> <40D3B7D5.90803@elvey.com> <16596.12497.349996.93747@giles.gnomon.org.uk> <40D48C40.10208@elvey.com> <16598.814.193830.480774@giles.gnomon.org.uk> <16598.1518.910455.761346@giles.gnomon.org.uk> <40D615AC.1080101@elvey.com> <16598.6561.605955.535057@giles.gnomon.org.uk> <40D62F3C.1010306@elvey.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Matthew" == Matthew Elvey writes: >> It's an interesting idea; do you know if an ID is forthcoming? Matthew> The latest I-D is dated May '04, and doesn't reflect this Matthew> "Unified SPF". We'll see if it's in SenderID, which is Matthew> what the SPF - CID merger effort is being called, I Matthew> think. This thread makes me think it will. If the name SenderID refers to draft-ietf-marid-core (which was my assumption) then it's clearly not in -00. If it refers to something else, then until and unless that proposal is submitted to this WG then I would guess this is probably the wrong forum to discuss it further. >> I'm dead against that. >> Matthew> That was clear. No doubt :-) Still, it's good to state one's position as precisely as possible for the benefit of clarity of discussion... Actually, on reflection I'd like to make one further point: I strongly believe that this point shouldn't be glossed over by any MARID standard. You asked a couple of messages back what I think of proposals that implicitly suggest blackholing messages. I think ambiguity like that would be the worst possible outcome for MARID. If MARID is going to fundamentally change this (or any other) long established principle of Internet e-mail then it needs to be upfront about it. I'll go further and suggest that MARID needs to do one of the following: either 1. Make it clear that all mail that's not accepted MUST be rejected at SMTP time or bounced to the MAIL FROM where possible (as per existing RFCs); or 2. Explicitly update RFC2821 6.1 Even a change from MUST to SHOULD (which would seem entirely reasonable to me in the context of MARID) is a change to RFC2821 and should be documented as such. But having a MARID RFC that is inconsistent with RFC2821 (without updating it) would seem be be unhelpful... Having one that is implicitly so, even more so... -roy From owner-ietf-mxcomp@mail.imc.org Sun Jun 20 21:35:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13368 for ; Sun, 20 Jun 2004 21:35:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5L1QIpb027108; Sun, 20 Jun 2004 18:26:18 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5L1QIE3027107; Sun, 20 Jun 2004 18:26:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5L1QHjg027100 for ; Sun, 20 Jun 2004 18:26:17 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: pzHeZ7VpnsRrhHRu7i42fw 1087781181 Received: from elvey.com (adsl-63-195-86-147.dsl.snfc21.pacbell.net [63.195.86.147]) by mail.messagingengine.com (Postfix) with ESMTP id 03081C0CE79; Sun, 20 Jun 2004 21:26:18 -0400 (EDT) Message-ID: <40D6393C.4060901@elvey.com> Date: Sun, 20 Jun 2004 18:26:20 -0700 From: Matthew Elvey User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MARID WG , wayne Subject: Re: rough consensus and working code References: In-Reply-To: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit A perhaps redundant comment: It would be nice if there was a rough consensus. On 6/15/04 9:35 AM, wayne sent forth electrons to convey: > ... > >So, the first goal of SPF was to make it easy to publish SPF records. >The next goal was to make it easy for mail admins to adopt SPF and SRS >by creating easy-to-install plugins to the major MTAs. It was decided >that any time there was a choice between making things easier for >domain owners and mail admins or making the job of writing SPF >implementations easier, the domain owners and mail admins should win. > > Hmm. I think Meng's Unified SPF plan is a great move in terms of this second goal of making things easy for mail admins. I'm won over. We still use EHLO to select the domain to authenticate; we ditch the PRA and SRS. So our friends you were talking about DON'T HAVE TO DO ANYTHING! The big German hoster just has to make sure that the EHLO its server sends out is a domain that has an SPF record that validates its IP (and reputation/accreditation). SRS doesn't need to be deployed! In my proposal, most domains DON'T NEED new DNS records AT ALL. (And none of this RFrom stuff is necessary either.) Near lightning-fast deployment is feasible. And we're still providing and using M.A.R.I.D. effectively. How cool is that? From owner-ietf-mxcomp@mail.imc.org Sun Jun 20 21:52:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14152 for ; Sun, 20 Jun 2004 21:52:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5L1gZvE030704; Sun, 20 Jun 2004 18:42:35 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5L1gZGb030703; Sun, 20 Jun 2004 18:42:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5L1gYUw030696 for ; Sun, 20 Jun 2004 18:42:34 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: I5mcK0ImGRwkuyWNRkWCkg 1087782158 Received: from elvey.com (adsl-63-195-86-147.dsl.snfc21.pacbell.net [63.195.86.147]) by mail.messagingengine.com (Postfix) with ESMTP id B0FBBC0CED9; Sun, 20 Jun 2004 21:42:37 -0400 (EDT) Message-ID: <40D63D0D.4060103@elvey.com> Date: Sun, 20 Jun 2004 18:42:37 -0700 From: Matthew Elvey User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MXCOMP Subject: Granularity of Reputation (was Re: Against Extensibility in MARID Records References: In-Reply-To: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/18/04 9:05 PM, Hallam-Baker, Phillip sent forth electrons to convey: >I think that there is a good case for tying reputation to a domain. > >But not having actually solved the problem yet (the spam is still >with us), I am not going to argue against tying accreditation or >reputation to a finer granularity. > >I think it is very likely that marketing@anybank.com is going to >be in a different reputation category than jane.doe@anybank.com. > > > I was thinking more about granularity. I think changing granularity from the domain level essentially introduces several security flaws into the system. If I were running a reputation service, I'd be very reluctant to make it possible for the above emails to have separate reputations, or to allow marketing.anybank.dom and billing.anybank.com to have separate reputations. I'd end up playing whackamole if I wasn't extremely careful; email addresses and subdomains are free. I'd *have to* charge for such entries, even if I wanted to run a free service, for it not to be fundmentally broken. Other whackamole security flaw secenarios this would enable: spam run begins, authorized by spammer.dom. SPF record of spammer.dom is changed to redirect from one throwaway, or ?all domain to another, as soon as each is blacklisted. Makes much more sense to blacklist spammer.dom. In other words, (in SPF terms), reputation MUST be tied to . It may in addition be tied to . From owner-ietf-mxcomp@mail.imc.org Sun Jun 20 21:57:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14391 for ; Sun, 20 Jun 2004 21:57:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5L1mTPd032227; Sun, 20 Jun 2004 18:48:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5L1mTcK032226; Sun, 20 Jun 2004 18:48:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5L1mSkw032194 for ; Sun, 20 Jun 2004 18:48:28 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Sun, 20 Jun 2004 18:48:27 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 20 Jun 2004 18:48:27 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 20 Jun 2004 18:48:27 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: rough consensus and working code Date: Sun, 20 Jun 2004 18:47:46 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF42A958@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: rough consensus and working code thread-index: AcRXL08lqcwVVYAHTAy07rTuIMerQwAAfHHg From: "Jim Lyon" To: "Matthew Elvey" , "IETF MARID WG" , "wayne" X-OriginalArrivalTime: 21 Jun 2004 01:48:27.0574 (UTC) FILETIME=[D8CFFD60:01C45731] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5L1mSkw032221 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Matthew Elvey writes: > We still use EHLO to select the domain to authenticate; > we ditch the PRA and SRS. So our friends you were > talking about DON'T HAVE TO DO ANYTHING! The big > German hoster just has to make sure that the EHLO its > server sends out is a domain that has an SPF record > that validates its IP (and reputation/accreditation). > SRS doesn't need to be deployed! In my proposal, most > domains DON'T NEED new DNS records AT ALL. (And none > of this RFrom stuff is necessary either.) Near lightning- >fast deployment is feasible. And we're still providing > and using M.A.R.I.D. effectively. It all sounds good except for one small fact: Knowing that an MTA is who he says he is does nothing to help you know whether he's authorized to send you the mail he's trying to send. For that, you PRS and all the rest. -- jimbo From owner-ietf-mxcomp@mail.imc.org Sun Jun 20 23:16:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18125 for ; Sun, 20 Jun 2004 23:16:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5L37TkP049444; Sun, 20 Jun 2004 20:07:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5L37T5E049443; Sun, 20 Jun 2004 20:07:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.pan-am.ca (205-200-6-46.static.mts.net [205.200.6.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5L37SR7049432 for ; Sun, 20 Jun 2004 20:07:29 -0700 (PDT) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: Wouldn't Mixing DMP with Resent-From: and Submitter... Date: Sun, 20 Jun 2004 22:07:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA8D7@srv1.pan-am.ca> X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Wouldn't Mixing DMP with Resent-From: and Submitter... Thread-Index: AcRXPO99Yp9isnDaQgmJ3c5yiDDnkQ== 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 i5L37TR7049438 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit ...solve the problems of oversized DNS records, non-supported DNS record types, multiple lookups, remailers, certain patent claims, roving users, bandwidth overuse, and possibly a whole host of other yet-undiscovered problems? Or if not DMP, FSV? Admittedly DMP doesn't have a pile of working code. I have source examples but I've tried asking people to write code for mailers other than Exchange, and no one wants to. I've read these unique problems since the start of the list: * Oversized DNS records causing fallback to DNS over TCP or, at minimum, excessive bandwidth use up to 50% more than SMTP alone * Unsupported DNS record types and no agreement on supporting unknown record types * Multiple lookups because of supporting remailers and not depending on wildcard DNS records * Supporting remailers in general including forwarders and mailing lists * Folks coming out of the woodwork declaring IPR on ideas presented here * Supporting dynamic IP mail sending hosts * General bandwidth overuse regardless of wether DNS or another mechanism is used to store records - 12% on average based on this list to a worst case of 50% for a 1 KB message * Polluting DNS name space with strange records and possibly conflicting records DMP has its own problems too. Thanks to Resent-From: (RFC 2822 header) and SUBMITTER (RFC 2821 verb) introduced in marid-core and marid-submitter, these problems would be eliminated: * No more multiple lookups required to support forwarders and remailers * No conflicting with possibly existing records in existing name spaces * Support for after-the-fact (RFC 2822) checking and supporting remailers is introduced * Wildcards COULD be used as they were intended to be used: None of this "_marid.*.$DOMAINNAME" stuff but still not required The problems that remain that I'm aware of are: * Null reverse path (MAIL FROM:) which could be solved via SUBMITTER or Resent-From * Minimum of two lookups for a worst case (first for a specific IP, then for the domain itself, to check if the domain or host participates), but no more four-lookup problems * Allowing dynamic updates to support roving users and dynamic IP, but could be solved with a DDNS implementation * Lack of acceptance of using TXT (or A in the case of FSV) which, if certain vendors would deal with it, be solved with a unique record type * Subdomains could still be spoofed, but a good implementation, through DDNS, could automatically create records for "host.example.com" like "_marid.host.example.com" (someone said this was asking for trouble and promised me an explanation. What was the explanation?) Plus some cosmetic changes would make it more visually appealing: * A shorter record name like _marid.$DOMAINNAME - and each host could have a record with this name appended dynamically to avoid spoofing a host without its own records normally -- PGP key (0x0AFA039E): Sometimes it's hard to tell where the game ends and where reality bites, er, begins. From owner-ietf-mxcomp@mail.imc.org Mon Jun 21 02:28:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13154 for ; Mon, 21 Jun 2004 02:28:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5L6CVhi041164; Sun, 20 Jun 2004 23:12:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5L6CVcP041163; Sun, 20 Jun 2004 23:12:31 -0700 (PDT) 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.9) with ESMTP id i5L6CRFC041109 for ; Sun, 20 Jun 2004 23:12:28 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from pool-521.denpasar.indo.net.id (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i5L6CQl20288; Sun, 20 Jun 2004 23:12:27 -0700 Date: Mon, 21 Jun 2004 14:12:03 +0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <371186530.20040621141203@brandenburg.com> To: John Leslie CC: Matthew Elvey , MXCOMP Subject: Re: CSV specification revision available In-Reply-To: <20040616164710.GG38007@verdi> References: <1665390638.20040614190711@brandenburg.com> <20040615031048.GP44160@verdi> <40CE9F08.2050002@elvey.com> <20040615115828.GQ44160@verdi> <1087328029.10303.198484820@webmail.messagingengine.com> <20040616164710.GG38007@verdi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit John, JL> It does, however, authenticate that you're talking with an SMTP client JL> worthy of some level of trust Given what follows in the rest of the exchange, let me suggest somewhat different wording, in order to make sure that the difference between authentication and accreditation are completely clear, here. (I know John know it, but want to make sure this thread says if VERY explicitly. This is a topic that has been extremely confusing in this forum.): A successful SMTP Auth gives the receiving smtp server a basis for believing that it knows who the sending smtp client is. With that assurance about the identity of the client, the server can proceed to assess the authorization (permission to be an smtp client) and accreditation (degree of trust to give) appropriate for the client. JL> Having said that, it's hard to imagine the case where host name JL> authentication would be the only thing missing _and_ SMTP AUTH would JL> be in use. >> So it perhaps shouldn't be part of the spec, if the purpose is just to >> be a component of CSV. JL> I believe Dave included it for completeness of background, and it JL> really isn't part of our proposal. CSV does not attempt to carefully restrict the combinatorial outcomes of the component sequences. (In english: No doubt there are silly combinations that can occur; we didn't worry ab out it.) The HNA stuff really only attempt to document exsiting mechanisms that can be used for the necessary authentication. That's why it made sense to move it to the CSV appendix rather than keep it in a separate document. JL> However, we realize there _will_ be cases where the SRV lookup doesn't JL> return the matching IP address, but local policy may recognize STARTTLS JL> as "sufficient authentication". In order to avoid confusion, I am inclined to use language like "there will be cases where the DNS server does not return the matching IP address as Additional Information to the SRV lookup. It really isn't the SRV record that is returning the address(es) and even the DNS server is not obligated to. It's only a (very useful) efficiency hack. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Mon Jun 21 02:36:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13840 for ; Mon, 21 Jun 2004 02:36:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5L6Pg7t050869; Sun, 20 Jun 2004 23:25:42 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5L6PgrG050868; Sun, 20 Jun 2004 23:25:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tom.iecc.com (tom.iecc.com [208.31.42.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5L6Pe61050838 for ; Sun, 20 Jun 2004 23:25:41 -0700 (PDT) (envelope-from johnl@iecc.com) Received: (qmail 5731 invoked from network); 21 Jun 2004 06:25:39 -0000 Received: (ofmipd 127.0.0.1); 21 Jun 2004 06:25:17 -0000 Date: 21 Jun 2004 02:25:36 -0400 Message-ID: From: "John R Levine" To: "Jim Lyon" Cc: "IETF-MXCOMP" Subject: RE: MARID Records and the standards process In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF42A93A@df-fido-msg.exchange.corp.microsoft.com> References: <81AC085044D04B429F5FB883D94FA1AF42A93A@df-fido-msg.exchange.corp.microsoft.com> Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > If I were a spammer sending Ci@l1s spam through zombies on > > MSN and Comcast, I agree that this is the SPF record I would > > use. ... > You get to piggyback on MSN's reputation exactly when you send mail > through their mail servers. If MSN has a reputation for not sending > spam, and you get my domain's mail from MSN's servers, then you can be > assured it's not spam, because if I try to send spam, MSN will either > kick me off, rate-limit me, or fine me. ... I understand this argument, but it still strikes me as utterly unpersuasive. For one thing, this kind of piggybacking only makes sense when networks don't have unauthorized users, which means no zombies, and I doubt that any plan that only works when the zombie problem is solved will be usable soon enough to be interesting. If I were that C1@lis spammer sending out tons of spam through WBW (an ISP with a dreadful reputation), I'd publish SPF saying that I use MSN, Comcast, and WBW. I might even sign up for a few MSN and Comcast accounts and trickle out a little mail through them. What reputation do I get? The max? The min? The median? The one whose IPs a particular message came through? That's in effect an IP based reputation system, which I don't think has a lot of support in MARID, given the modest enthusiasm I've seen for CSV. At least as important, MSN and Comcast are going to have reputations that say these are large consumer ISPs with 24/7 abuse desks and other facts that don't trickle down to their customers. They may or may not be willing to vouch for various characteristics of some or all of the domains that their customers use, but they get to decide, not you or me. > In short, discontinuous changes of format seldom happen. Indeed. They only happen when they're useful. You cited http as an extensible format a little while ago, and I can't help but notice that extensible http 1.0 is quite incompatible with non-extensible http 0.9, yet everyone adapted because 1.0 has advantages that made the transition worthwhile. This still boils down to "it might be useful". I have lots of swell anti-spam ideas that might be useful, but I'm not going to tell people to build standards around them until I have some experiece that demonstrates how useful they are. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor "I dropped the toothpaste", said Tom, crestfallenly. From owner-ietf-mxcomp@mail.imc.org Mon Jun 21 04:53:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22502 for ; Mon, 21 Jun 2004 04:53:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5L8emB1014820; Mon, 21 Jun 2004 01:40:48 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5L8emRI014819; Mon, 21 Jun 2004 01:40:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5L8elEL014795 for ; Mon, 21 Jun 2004 01:40:48 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: 08jF2QjhfDVH6iaRv/w0qA 1087807245 Received: from elvey.com (adsl-63-195-86-147.dsl.snfc21.pacbell.net [63.195.86.147]) by mail.messagingengine.com (Postfix) with ESMTP id 4B29CC0CADE; Mon, 21 Jun 2004 04:40:43 -0400 (EDT) Message-ID: <40D69F07.1090707@elvey.com> Date: Mon, 21 Jun 2004 01:40:39 -0700 From: Matthew Elvey User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Lyon Cc: IETF MARID WG Subject: Re: rough consensus and working code References: <81AC085044D04B429F5FB883D94FA1AF42A958@df-fido-msg.exchange.corp.microsoft.com> In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF42A958@df-fido-msg.exchange.corp.microsoft.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit You are overselling. (Surprise, surprise.) On 6/20/04 6:47 PM, Jim Lyon sent forth electrons to convey: >Matthew Elvey writes: > > >>We still use EHLO to select the domain to authenticate; >>we ditch the PRA and SRS. So our friends you were >>talking about DON'T HAVE TO DO ANYTHING! The big >>German hoster just has to make sure that the EHLO its >>server sends out is a domain that has an SPF record >>that validates its IP (and reputation/accreditation). >>SRS doesn't need to be deployed! In my proposal, most >>domains DON'T NEED new DNS records AT ALL. (And none >>of this RFrom stuff is necessary either.) Near lightning- >>fast deployment is feasible. And we're still providing >>and using M.A.R.I.D. effectively. >> >> > >It all sounds good except for one small fact: Knowing that an MTA is >who he says he is does nothing to help you know whether he's authorized >to send you the mail he's trying to send. For that, you PRS and all the >rest. > > No. You'd have made an important point except for one small fact. It would also be accurate to say that PRS also fails to guarantee he's authorized to send you the mail he's trying to send, or even that the message is from who it claims to be from. Even if you're just checking EHLO, 2822.From is fairly well protected from forgery, however it's not guaranteed not to be forged. For details, here's my spf-discuss post, mentioned earlier today on this list, where I explain why just checking EHLO (against SPF and reputation services) is likely to protect 2822.From BETTER than a direct defense, such as PRS, et. al. Perhaps you missed it or failed to understand it. It's http://archives.listbox.com/spf-discuss@v2.listbox.com/200406/0958.html , reposted here: Hello from a regular MARID poster! Meng's latest SPF plan (in which he has borrowed my idea of CSV semantics using SPF records) was influenced by, among other things, a group of us pushing strongly for HELO to always be checked. SPF already required that the HELO be valid, so the change from saying that it MAY be checked to it MUST be checked is not an issue, with respect to senders having to comply with a new requirement. Meng's latest SPF plan, does not require senders to comply with a new requirement at all (vs. the old SPF). In fact, it's now EASIER for senders to comply. MUCH easier. This is why I, at least, pushed hard for the CSV solution (which I'm no longer going to push, because Meng's latest SPF plan does what I've had a burning desire to see MARID do. Let me explain. I'm posting to explain WHY this is a good thing and HOW it will make things EASIER. I think a HELO check accomplishes a lot more than is immediately apparent. I think a HELO check can protect 2822.From:, and with a major tweak, prevent Joe-job damage, while being much easier to implement broadly than other identity checks, and accomplish the goal of tying email better to a responsible party, bringing us much closer to a realistic near-FUSSP. Detailed arguments below. First, a quote from Dave Crocker (2822 author): Breaking legitimate functionality of a system that has been in use for 30 years and is currently relied on by 1 billion people obligates those doing the breaking to be very clear and careful about defining and defending the breakage. That is not happening about this topic. Remember, whatever the source for the domain that MARID validates, blacklists and reputation services will be an integral part of the system. A domain with a MARID record used in email with malicious forged From: is gonna get in an RHSBL lickety-split: If you get word of From: forgery, you're gonna be motivated to do a little work to get the spammer's domain blacklisted, for example by putting him in your RHSDRBL (Right Hand Side Distributed RBL), which will stop the forgery and phishing. If we ensure that HELO passes: Can a spammer set up a domain and rDNS with records under the spec and spoof 2822.From: yes, for all the extant I-Ds, including SPF, and C-ID, (remember, Resent-From, etc. can be abused) BUT not for long - the authorizing domain will get blacklisted PDQ. Is a spammer forced to use a domain set up with records that specify its authorized MTAs: yeah. Are forwarders or remailers' systems broken, requiring new software: no for unified SPF (i.e. with mandatory HELO checks), yes for SPF as it was yes for C-ID (PRA/RFrom). Are users forced to send through MTAs authorized for the domain they use in outgoing mail: no for unified SPF, yes for SPF, C-ID, Y!DK (even stricter!). MTA admins just need to ensure that they are sending appropriate HELO strings, which nearly all already are, and create DNS records. Wow, that's not a lot of systems that need touching, relatively speaking! (Around 2 orders of magnitude fewer than SPF+SRS). ALL the other proposals so far don't accomplish much more than just the HELO check, and yet do impose much larger costs. It ties to domain owner info, instead of the less accurate IP space owner info. Nice, but both are often false. Now that it uses SPF records, it has nifty flexibility and extensions in specifying authorized IPs. Y!DK is even more restrictive (and disruptive), as the keys can only be placed on a much smaller subset of machines than SPF could authorize, the only benefit being it defends against use of bogon or hijacked IP space better. A mailing list post with a forged From proved a point rather well: No proposal with an I-D listed in the MARID charter would have completely prevented the forgery from making it to the list. So if they can't give the list-management software the tools it needs to prevent the forgery, what does all the additional adoption headache they cause buy us? In fact, there's an argument to be made that with HELO, SPF will do a better job preventing the forgery; it goes like this: Because it will have a much lower implementation cost, it will get implemented sooner. After broad adoption, this will be tough: the forger will have just two major options: use an un-blacklisted domain he runs on an MTA he runs (losing anonymity), or free rein over these things run by someone who controls them well enough to keep the domain off BLs (an increasingly hard thing to find). PS Yes, my views on the criticality of MARID directly and fully protecting 2822.From have changed - I didn't see that there was an alternative way to protect it. If you say HELO checks fail to protect 2822.From:, I have two counter-arguments: 1) But SPF fails to protect the domain in From: too. And if we say that's OK, it protects From/Sender/Resent*, then we're saying SPF doesn't protect From 'till everyone upgrades to mail clients that support this. Now we're talking what? Easily 2 orders of magnitude more work than EHLO checks. 2) Not to mention that I explained above how CSV does provide a way to protect From: (through incenting blacklist submission). Initially, I was pushing for CSV mainly because it checked HELO, and I had strongly felt ideas about why a HELO check was the best thing to check. The above is a rephrasing of this post: http://www.imc.org/ietf-mxcomp/mail-archive/msg01175.html and this post: http://www.imc.org/ietf-mxcomp/mail-archive/msg01226.html Unified SPF makes sense because it economizes on human time. The algorithm is a bit more complex, but only needs to be written once (or a few times) and breaks much less legitimate functionality without leaving more illegitimate functionality working than SPF's previous version. In return, it's MUCH easier to deploy, because it requires NO end user action, and eliminates the need for SRS! That's an amazing trade! I welcome your questions and comments. =-=-=-=-=-=-= Greg Conner said: /> Layer 0: HELO and PTR / /> These should bind strongly to IP. Unfortunately there are cases where the / /> HELO is a fake name, or the PTR is missing, or both. At this stage we are / /> looking for a FAIL, in order to spot obvious forgeries like "HELO / /> microsoft.com" or HELO with the receiver's domain as many viruses do. / /> This / /> catches some of the "low-hanging fruits" of the forgery world. By / /> itself a / /> PASS result here doesn't validate the whole email, it's just the bare / /> minimum / /> check for an MTA. / I don't think the implication here is valid. By themselves, Layer 1 or Layer 2 don't validate the email EITHER. They must be used in conjunction with a reputation service - remember, spammers are already sending spam that gets an SPF "pass" w/o a reputation check. When HELO is used in conjunction with an RHSBL and RHSWL or a reputation service, the "pass" DOES validate the whole email. What I like about this new thrust is that the reputation service application to each identity is explicit. From owner-ietf-mxcomp@mail.imc.org Mon Jun 21 05:30:18 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24869 for ; Mon, 21 Jun 2004 05:30:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5L9Icf0027987; Mon, 21 Jun 2004 02:18:38 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5L9Icjg027986; Mon, 21 Jun 2004 02:18:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from orange.csi.cam.ac.uk (exim@orange.csi.cam.ac.uk [131.111.8.77]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5L9IbM2027974 for ; Mon, 21 Jun 2004 02:18:38 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from fanf2 (helo=localhost) by orange.csi.cam.ac.uk with local-esmtp (Exim 4.12) id 1BcKwi-0003q5-00; Mon, 21 Jun 2004 10:18:32 +0100 Date: Mon, 21 Jun 2004 10:18:32 +0100 From: Tony Finch X-X-Sender: fanf2@orange.csi.cam.ac.uk To: Dave Crocker cc: John Leslie , Matthew Elvey , MXCOMP Subject: Re: CSV specification revision available In-Reply-To: <371186530.20040621141203@brandenburg.com> Message-ID: References: <1665390638.20040614190711@brandenburg.com> <20040615031048.GP44160@verdi> <40CE9F08.2050002@elvey.com> <20040615115828.GQ44160@verdi> <1087328029.10303.198484820@webmail.messagingengine.com> <20040616164710.GG38007@verdi> <371186530.20040621141203@brandenburg.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 21 Jun 2004, Dave Crocker wrote: > > A successful SMTP Auth gives the receiving smtp server a basis for > believing that it knows who the sending smtp client is. With that > assurance about the identity of the client, the server can proceed to > assess the authorization (permission to be an smtp client) and > accreditation (degree of trust to give) appropriate for the client. SMTP AUTH doesn't preclude lying in the HELO line. The use of consistent SASL credentials from a particular sender does not imply they use a consistent HELO domain. SMTP AUTH does not authenticate the data that CSA and DNA use to look up the authorization and accreditation, therefore it isn't suitable for use with CSA and DNA -- unless some additional mechanism is documented that fixes this bug. -- Tony Finch http://dotat.at/ From owner-ietf-mxcomp@mail.imc.org Mon Jun 21 09:31:11 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12778 for ; Mon, 21 Jun 2004 09:31:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LDLvX0079842; Mon, 21 Jun 2004 06:21:57 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5LDLv6X079840; Mon, 21 Jun 2004 06:21:57 -0700 (PDT) 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.9) with ESMTP id i5LDLuwG079834 for ; Mon, 21 Jun 2004 06:21:56 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from DialupDps236-189.centrin.net.id (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i5LDLkl20181; Mon, 21 Jun 2004 06:21:47 -0700 Date: Mon, 21 Jun 2004 16:49:28 +0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <977421243.20040621164928@brandenburg.com> To: "Jim Lyon" CC: "IETF-MXCOMP" Subject: Re: Against Extensibility in MARID Records In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF42A63A@df-fido-msg.exchange.corp.microsoft.com> References: <81AC085044D04B429F5FB883D94FA1AF42A63A@df-fido-msg.exchange.corp.microsoft.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: Content-Transfer-Encoding: 7bit Jim, I think your note is particularly useful for prompting us to consider what the history of Internet does and does not contribute to the current consideration. To state my own biases at the start: 1. For all intents and purposes, the Internet has literally no large-scale experience with interesting policy mechanism operated among participants lacking prior arrangement. 2. BGP probably counts as an exception, but we should note just how constrained it is, if we evaluate it as communicating "policy". 3. The DNS is a simple lookup mechanism and our experience with it is in producing simple records. both in terms of searching and in terms of complex records, efforts to make it act more like a general purpose data based have all failed, or at least been highly problematic. 4. Reliance on the DNS for core Internet infrastructure operation dictates that its reliability and performance of those tasks be guarded vigorously, even at the expense of interesting new applications. So with that in mind: JL> In arguing against extensibility, John Levine argues that it's a bad JL> thing (he used the word "chaotic") to have information in a MARID record JL> that is not understood by everyone. I took John's foundation statement as being: > One of the main points of MARID, as I understand it, is to develop > something that can be implemented relatively quickly and will > interoperate among senders and recipients all over the net. These match my own understanding and are extremely important as input to a design process. History with Internet standards that succeed in matching these requirements dictate considerable simplicity and very, very limited choice in the core functionality. Extensibility is restricted to be outside that core. JL> To rebut this, I note that substantially every successful data format JL> and protocol contains buckets for information that isn't globally JL> understood. Such information is never part of the core that is needed to get basic functionality out of the service. Things work quite well without any of the extensibility. JL> For example, consider headers in RFC 2822 mail messages. ... JL> A similar story applies to the headers in HTTP. Internet protocols used between participants without prior arrangement must specify a small, tight core that everyone supports, and that small tight core must do something very useful. Any extensibility must be optional value-add. This is certainly true for email headers, for smtp, and for http headers. There is a very big and very basic difference between extensibility support between consenting participants, versus extensibility that impacts non-consenting participants. It is also worth noting that extensibility is typically a good thing only AFTER the core is operational. For all of the freedom with RFC733/RFC822 headers, folks didn't take all that much advantage of the freedom for many years. And SMTP options did not appear for 10 years. If you want masses of sites to implement something new quickly, make sure that development and adoption take a minimum of effort. JL> Given that we *know* that we'll need more information in the future The problem is that we have no serious idea what that information will be. We all think we do, but there is no experiential basis for knowing what is true. All of the deployed, successful, large-scale systems use remarkably simplistic schemes. Any expectations that there will be deployment of clever, large-scale "policy" analysis engines is not supported by experience, no matter how appealing such engines might seem. I think John Levine's follow-up point, about separation of reputation versus authentication are also fundamental. JL> (most of us are here to reduce spam, not just authenticate MTAs), it JL> behooves us to plan the extensibility now. Please take a look at the history of the SNMP security field. It was an example of a place-holder provided with similar thinking. Security obviously would be needed and we would figure out what that meant later, so let's leave a field that will be define later. It turned out that the security that was need required a rewrite of SNMP. Extensibility is best provided when there is a pretty good idea of the details that will determine how it will be used. The problem for the current discussion is that the "pretty good idea" does not have all that much empirical basis, nor even community consensus. JL> SPF's current modifiers are JL> a step in the right direction (they have the ignore what you don't JL> understand ethos), but as I've argued elsewhere, they aren't sufficient. The problem is that there is actually very little operational experience USING those values to do Internet-scale mail filtering. JL> PS: John also continues the misconception that anything that uses XML JL> will be big enough to require DNS TCP. This just isn't true. It looks JL> like most XML-encoded stuff runs about 20% bigger than SPF-encoded JL> stuff. I think the real issue is the generic and potentially unbounded nature of the extensibility, rather than the syntax used for encoding it. Of course, verbosity is not without its issues, for DNS records. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Mon Jun 21 11:37:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21002 for ; Mon, 21 Jun 2004 11:37:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LFGRWE003954; Mon, 21 Jun 2004 08:16:27 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5LFGR2w003953; Mon, 21 Jun 2004 08:16:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (listserv.winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5LFGQWq003937 for ; Mon, 21 Jun 2004 08:16:26 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Mon, 21 Jun 2004 11:19:54 -0400 Received: from ([68.223.169.60]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 1641840625; Mon, 21 Jun 2004 11:19:51 -0400 Message-ID: <010601c457a3$b59f7ab0$6401a8c0@hdev1> From: "Hector Santos" To: "Dave Crocker" , "Jim Lyon" Cc: "IETF-MXCOMP" References: <81AC085044D04B429F5FB883D94FA1AF42A63A@df-fido-msg.exchange.corp.microsoft.com> <977421243.20040621164928@brandenburg.com> Subject: Re: Against Extensibility in MARID Records Date: Mon, 21 Jun 2004 11:23:22 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.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: Content-Transfer-Encoding: 7bit I would like to state my own bias because of the historistical tradition and design of all mail hosting and transport systems, not just the internet. This is important, because no new considerations or design is going to alter this implementation model. Foremost, the traditional design for SMTP has been for all systems to follow two fundamental rules, with the first being: Rule #1: Authentication is required for routing. No authentication required for final destination. Of course. the principle problem with the "anonymous-like" transaction behavior with final destination mail has been the growth in the abuse, a problem I don't mind saying has been known and documented since the early 1980s. However, the problem was not significant enough until the internet was introduced into the public. Which brings me to fundamental rule #2 that has its origins in the then new email provisions introduced in 1986 ECPA (Electronic Communications Privacy Act) related to email tampering and altering the "intent of the user:" Rule #2: Mail Acceptance must be delivered or bounced. It can't simply disappear. What does this rule mean from a implementation and product liability standpoint, not just for mail transport systems but for all Interactive Online Mail hosting systems dominate during the 1980s early mail days? It meant that a rejection policy was legally acceptable at the user input (online hosting) or for automated systems, at the transport level. If the mail was accepted for posting, then the system had a responsibility to maintain a) the integrity of the mail (privacy for example), b) that it was delivered and c) if it was not delivered, it be returned or a reason provided to the author as to why it was not. This gave strength the new "system policies" that were now required by online hosting systems during a LOGIN process telling users what are the system policies for acceptable mail. But even with a sysop system policy, the "intent of the user" was an important factor in any tort, defamation, malpractice suit. The exception to the 1986 ECPA rule are employer based mail systems. Employees do not have the same right covered by the 1986 ECPA provisions. In any case, to make a long story short, this is why I strongly object to any design concept attempting to address the "anonymous sender" user problem that imposes or requires the acceptance of the payload for POST SMTP analysis. In my view, it will alter the landscape and will open a major "Pandora Box" in new legal issues. It already has begun (See Scott Ricther current lawsuit directly related to "intent" and malpractice), I strongly believe the promotion of POST SMTP validation is the wrong direction. Finally, in direct regards to MARID, if MARID imposes a 2822 validation requirement, this will seriously limit or incur a higher development cost for its consideration into our package. If it is implemented with a 2822 requirement, that will force our design to provide a DATA hook where this can be done and still follow the traditional and legally responsible design. In other words, our MARID implementation will not be for POST SMTP validation operation. Hope this remark was not off base. I am strictly stating how we will be viewing MARID come implementation. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com ----- Original Message ----- From: "Dave Crocker" To: "Jim Lyon" Cc: "IETF-MXCOMP" Sent: Monday, June 21, 2004 4:49 AM Subject: Re: Against Extensibility in MARID Records > > Jim, > > I think your note is particularly useful for prompting us to consider > what the history of Internet does and does not contribute to the > current consideration. > > To state my own biases at the start: > > 1. For all intents and purposes, the Internet has literally no > large-scale experience with interesting policy mechanism operated > among participants lacking prior arrangement. > > 2. BGP probably counts as an exception, but we should note just how > constrained it is, if we evaluate it as communicating "policy". > > 3. The DNS is a simple lookup mechanism and our experience with it is > in producing simple records. both in terms of searching > and in terms of complex records, efforts to make it act more like a > general purpose data based have all failed, or at least been highly > problematic. > > 4. Reliance on the DNS for core Internet infrastructure operation > dictates that its reliability and performance of those tasks be > guarded vigorously, even at the expense of interesting new > applications. > > So with that in mind: > > > JL> In arguing against extensibility, John Levine argues that it's a bad > JL> thing (he used the word "chaotic") to have information in a MARID record > JL> that is not understood by everyone. > > I took John's foundation statement as being: > > > One of the main points of MARID, as I understand it, is to develop > > something that can be implemented relatively quickly and will > > interoperate among senders and recipients all over the net. > > These match my own understanding and are extremely important as input > to a design process. History with Internet standards that succeed in > matching these requirements dictate considerable simplicity and very, > very limited choice in the core functionality. Extensibility is > restricted to be outside that core. > > > JL> To rebut this, I note that substantially every successful data format > JL> and protocol contains buckets for information that isn't globally > JL> understood. > > Such information is never part of the core that is needed to get basic > functionality out of the service. Things work quite well without any > of the extensibility. > > > JL> For example, consider headers in RFC 2822 mail messages. > ... > JL> A similar story applies to the headers in HTTP. > > Internet protocols used between participants without prior arrangement > must specify a small, tight core that everyone supports, and that > small tight core must do something very useful. Any extensibility must > be optional value-add. > > This is certainly true for email headers, for smtp, and for http headers. > > There is a very big and very basic difference between extensibility > support between consenting participants, versus extensibility that > impacts non-consenting participants. > > It is also worth noting that extensibility is typically a good thing > only AFTER the core is operational. For all of the freedom with > RFC733/RFC822 headers, folks didn't take all that much advantage of > the freedom for many years. And SMTP options did not appear for 10 > years. If you want masses of sites to implement something new > quickly, make sure that development and adoption take a minimum of > effort. > > > JL> Given that we *know* that we'll need more information in the future > > The problem is that we have no serious idea what that information will > be. We all think we do, but there is no experiential basis for > knowing what is true. All of the deployed, successful, large-scale > systems use remarkably simplistic schemes. Any expectations that > there will be deployment of clever, large-scale "policy" analysis > engines is not supported by experience, no matter how appealing such > engines might seem. > > I think John Levine's follow-up point, about separation of reputation > versus authentication are also fundamental. > > > JL> (most of us are here to reduce spam, not just authenticate MTAs), it > JL> behooves us to plan the extensibility now. > > Please take a look at the history of the SNMP security field. It was > an example of a place-holder provided with similar thinking. Security > obviously would be needed and we would figure out what that meant > later, so let's leave a field that will be define later. > > It turned out that the security that was need required a rewrite of > SNMP. > > Extensibility is best provided when there is a pretty good idea of the > details that will determine how it will be used. The problem for the > current discussion is that the "pretty good idea" does not have all > that much empirical basis, nor even community consensus. > > > JL> SPF's current modifiers are > JL> a step in the right direction (they have the ignore what you don't > JL> understand ethos), but as I've argued elsewhere, they aren't sufficient. > > The problem is that there is actually very little operational > experience USING those values to do Internet-scale mail filtering. > > > JL> PS: John also continues the misconception that anything that uses XML > JL> will be big enough to require DNS TCP. This just isn't true. It looks > JL> like most XML-encoded stuff runs about 20% bigger than SPF-encoded > JL> stuff. > > I think the real issue is the generic and potentially unbounded nature > of the extensibility, rather than the syntax used for encoding it. Of > course, verbosity is not without its issues, for DNS records. > > > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA , > > From owner-ietf-mxcomp@mail.imc.org Mon Jun 21 14:56:05 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16795 for ; Mon, 21 Jun 2004 14:56:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LIfJgS043955; Mon, 21 Jun 2004 11:41:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5LIfJPs043954; Mon, 21 Jun 2004 11:41:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from smtp-out-2001.amazon.com (smtp-out-2001.amazon.com [207.171.160.37]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LIfJbF043929 for ; Mon, 21 Jun 2004 11:41:19 -0700 (PDT) (envelope-from jonagard@amazon.com) Received: from ex-gate-02.ant.amazon.com by smtp-out-2001.amazon.com with ESMTP (peer crosscheck: [10.16.148.40]) X-Amazon-Corporate-Relay: smtp-out-2001.iad2.amazon.com X-AMAZON-TRACK: Received: from jonagard.desktop.amazon.com ([10.21.12.165]) by ex-gate-02.ant.amazon.com over TLS secured channel with Microsoft SMTPSVC(5.0.2195.6713); Mon, 21 Jun 2004 11:41:14 -0700 From: Jonathan Gardner Organization: Amazon To: IETF MARID WG Subject: Re: Drive Towards Consensus [was Re: On Extensibility in MARID Records] Date: Mon, 21 Jun 2004 11:41:12 -0700 User-Agent: KMail/1.6 References: <81AC085044D04B429F5FB883D94FA1AF42A291@df-fido-msg.exchange.corp.microsoft.com> <1CD00592-BFE8-11D8-BD27-000A95CA7FAE@dbc.mtview.ca.us> <50B2A36E-C00B-11D8-999B-000A95BC6A7E@margaretolson.com> In-Reply-To: <50B2A36E-C00B-11D8-999B-000A95BC6A7E@margaretolson.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="euc-kr" Message-Id: <200406211141.13641.jonagard@amazon.com> X-OriginalArrivalTime: 21 Jun 2004 18:41:14.0570 (UTC) FILETIME=[54C3BAA0:01C457BF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5LIfJbF043949 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I think a general summary for my response is that we have to decide a few issues. (1) What will SenderID do? Will it be limited to just authentication, or will it be expandable in the future? And authentication of what exactly? The sending MTA, or the sending MUA, or what? If we decide that Sender ID will only authenticate whether a particular MTA at an IP address is allowed to send messages for a domain, then Sender ID is sufficient. (2) Also, how will we handle complicated and rare situations? Will we try to write a syntax that handles every imaginable case, or will we accept limitations to the syntax with the idea that the complicated and rare sitatuations should be modified? My responses are embedded below. On Wednesday 16 June 2004 08:06 pm, Margaret Olson wrote: > Here's are my first few examples: > > Example1.com: > example1.com uses two providers: esp.com and personalmail.com . > > Mail originating from personalmail.com is always conversational > (corporate individual mailboxes) and rate limited to 100 messages a day > by personalmail.com > > Mail authored by example1.com originating from esp.com is rate limited > to 4,000 messages a month by esp.com. This mail is bulk mail. > > example1.com is a small b to b service business, as accredited by > accreditors.com > > Note: esp.com and personalmail.com set rate limits on a per customer > basis; these limits are functions of the customer, not functions of the > service that apply in an undifferentiated manner to all customers. I am > taking it as given that esp.com and personalmail.com can write code to > do lookups to check the veracity of their customer's statements on the > MARID record. > I believe that rate limiting should be beyond the scope of Sender ID. For one, it is better implemented on the sending MTA side. This would be an implementation detail for the MTA, and requires no external knowledge to either example1.com or any receiving MTA. The other possibility is to implement rate limiting on the receiving MTA's end. But how can the receiving MTA know how many email messages were sent to other MTAs? How can a receiving MTA trust the number that other MTAs report to it? These difficulties would greatly complicate Sender ID, and so should be external to Sender ID. Thus, no extensions to Sender ID should be created for rate limiting. The question of accreditation is also posed. How does example1.com become accredited with accreditors.com? How does accreditors.com inform other MTAs of their accreditation? How do other MTAs decide what to do with the accreditation information? Despite any answers above, accreditation has nothing to do with authorization. Either an MTA is allowed to send email for a domain or it isn't, and accreditation doesn't affect that. Thus, no extension to Sender ID should be created for accreditation either. In summary, no extensions should be made to Sender ID to describe example1.com's situation. > Example2.com: > Example2.com is a new customer at both personalmail.com and esp.com. > They have no accreditation or reputation, but each service rate limits > them to 100 messages a day and 400 messages a month, with a total > address count of 100. In other words, they can not correspond with more > than 100 different recipients over the period of a month on either > service. > > Receivers side services can sum up the rate limits to calculate the > total number of recipients and messages that can emanate from > example2.com and decide whether it exceeds their policies on > authenticated but unaccredited senders. > The problems with receiving MTAs summing up the number of emails sent for a particular domain are outlined above. Drawing from the conclusions above, no extensions to Sender ID should be made for this situation. I believe that entering into a three-way contract like this is difficult at best. Rather, example2.com would draw up one contract with personalmail.com and another with esp.com. Besides the problems of getting three people to completely agree to anything, the technical problem of reporting the number of emails sent is not a trivial one. > Example3.com: > Example3.com has limited internal controls and has decided to outsource > the whole record management and sending policy enforcement problem to > maridRus.com. They know they send outbound mail through their inbound > servers, but other than that they don't know how they send. > > maridrus.com starts by publishing a record referencing the mx records. > They need two kinds of feedback; abuse complaints, of which they want > 100%, and channels not listed in the example.com records, of which they > want 1 in 1,000 messages. > > Over time, example.com and maridRus.com conclude that esp1.com and > esp2.com, in use by Departments A and B respectively, are authorized > vendors, and that they don't need to duplicate complaint monitoring. > They update the record such that complaints generated on mail on the > esp1 or esp2 channel are handled by the esps, and not copied to > maridRus.com. > Complaint monitoring is a complicated example. How are we to inform receiving MTAs that they should send complaints? For what situations do they send complaints? How do we handle complaint messages to avoid a situation where complaint messages generate more complaint messages? Are receiving MTAs obligated to send complaints? How do we verify that complaint messages are not falsified? Is there a universal standard or do we have to negotiate a method of verification? I believe that complaint messages are beyond the realm of authentication because of the difficulties outlined above. The problems above are almost larger than the original problem of authentication. If ISPs and ESPs want to partner and exchange complaint messages, then that is their right to do so. Encoding such an agreement in Sender ID is not appropriate. Thus, no extensions to Sender ID are needed for this situation. Note that rather than monitoring complaint messaging, a more effective solution would be to audit the email sending facilities of example4.com. After the audit, strict Sender ID records could be published. Any remaining email sending facilities will later be discovered via bounced messaging or human-generated complaints or other signs. > Example4.com > Example4.com is an esp bounce handling domain. This domain appears only > in MAIL-FROM and never in SUBMITTER or the 2822 from address. > It is the responsibility of the sending MTAs to ensure that email is properly formatted. Sender ID, I believe, should only be concerned with authorization. > Example5.com: > [This is included because I think that over time it will be useful to > everyone to have receiving as well as sending policies published, and > having another syntax for that side of the policy equation doesn't make > much sense to me] > > Example5.com publishes their acceptance criteria as well their sending > policies. They accept mail from authenticated but unaccredited senders > who do not send more than 100 messages a day or 400 messages a month. > Otherwise, they accept accreditations from accreditors.com (which > presumably has pass-through arrangements with some number of other > accreditors). example5.com requires confirmed opt in from everyone > except senders accredited as financial institutions by > verythoroughandexpensiveaccreditations.com. For financial institutions > they require only prior business relationship, as defined by > verythoroughandexpensiveaccreditations.com > > This is used by esp.com to decide whether or not to send based on the > characteristics of each of their customers, and to report back to their > customers on what they need to do to get their mail delivered. > Acceptance policies are beyond the original premise of Sender ID. I don't believe publishing such a policy is necessary. Here's my explanation why. esp.com should send the messages. If example5.com accepts it but later sends a bounce mesage, esp.com should forward the bounced messages from example5.com to their customers. If example5.com refuses to accept the mesage, esp.com will return a bounced message to their customer with the error message. It is example5.com's responsibility to provide accurate and descriptive error and bounce messages. - -- Jonathan M. Gardner Mass Mail Systems Developer, Amazon.com jonagard@amazon.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFA1yvIBFeYcclU5Q0RAoFbAJsENmmHSRaTFDh+F18Syb916PMt+gCfUpxT TDE8nK0+HQxVH5fZhoxWgrI= =zcKs -----END PGP SIGNATURE----- From owner-ietf-mxcomp@mail.imc.org Mon Jun 21 16:41:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26962 for ; Mon, 21 Jun 2004 16:41:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LKTxPL061919; Mon, 21 Jun 2004 13:29:59 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5LKTxA1061918; Mon, 21 Jun 2004 13:29:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from republico.estv.ipv.pt (tunadao.ipv.pt [193.137.7.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LKTw82061893 for ; Mon, 21 Jun 2004 13:29:59 -0700 (PDT) (envelope-from lbruno@republico.estv.ipv.pt) Received: from lbruno by republico.estv.ipv.pt with local (Exim 4.22) id 1BcVRX-00021T-6G for ietf-mxcomp@imc.org; Mon, 21 Jun 2004 21:31:03 +0100 Date: Mon, 21 Jun 2004 21:31:03 +0100 From: Luis Bruno To: IETF MARID WG Subject: Re: Drive Towards Consensus [was Re: On Extensibility in MARID Records] Message-ID: <20040621203103.GA7726@republico.estv.ipv.pt> Mail-Followup-To: IETF MARID WG References: <81AC085044D04B429F5FB883D94FA1AF42A291@df-fido-msg.exchange.corp.microsoft.com> <1CD00592-BFE8-11D8-BD27-000A95CA7FAE@dbc.mtview.ca.us> <50B2A36E-C00B-11D8-999B-000A95BC6A7E@margaretolson.com> <200406211141.13641.jonagard@amazon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200406211141.13641.jonagard@amazon.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jonathan Gardner wrote: > If we decide that Sender ID will only authenticate whether a particular MTA > at an IP address is allowed to send messages for a domain, then Sender ID > is sufficient. Sufficient, but not necessary; in other words, overkill. Paging Hector Santos: I couldn't get email directly to you; 550 Return Path not verifiable after RCPT TO: (and postmaster@ didn't work :-) ) -- Luis Bruno UTM: 29T 629481E 4511776N 576m From owner-ietf-mxcomp@mail.imc.org Mon Jun 21 16:42:50 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27362 for ; Mon, 21 Jun 2004 16:42:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LKW9H0062345; Mon, 21 Jun 2004 13:32:09 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5LKW9X5062344; Mon, 21 Jun 2004 13:32:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.glyphic.com (mail.glyphic.com [216.218.209.57]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LKW8t0062310 for ; Mon, 21 Jun 2004 13:32:08 -0700 (PDT) (envelope-from markl@glyphic.com) Received: from [192.168.1.150] (m208-18.dsl.rawbw.com [198.144.208.18]) by mail.glyphic.com (Postfix) with ESMTP id 4135940D3 for ; Mon, 21 Jun 2004 13:32:06 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v618) In-Reply-To: References: <20040619212932.GC30711@obscurity.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0E174519-C3C2-11D8-AA48-000393A56BB6@glyphic.com> Content-Transfer-Encoding: 7bit From: Mark Lentczner Subject: Re: Drive Towards Consensus [was Re: On Extensibility in MARID Re cords] Date: Mon, 21 Jun 2004 13:32:03 -0700 To: IETF MARID WG X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I'd like to respond to the three postings about why SPF syntax is not sufficient that appeared in this thread during the last few days. First, I'd like to state my view that while there are many approaches and parts of the problem of unwanted mail, the original SPF was designed to implement a small, but important, slice of them. When it was seen that several other approaches were converging on similar ground, there was a push to consolidate them and one result of that push was this working group. In light of that, I see that each of the three postings argue that the SPF syntax can't handle something that it wasn't designed to handle. They are issues and approaches that are beyond the original scope of SPF and the similar projects that are trying to be merged here. In particular: 1) Margaret Olson's examples Alas, these examples didn't actually state what aspect SPF couldn't handle. I don't know if the desire is to have mail rate information in SPF, or reputation information or what. As a part of the system, SPF seems to me to work in all the examples given. 2) Jim Lyon's examples These examples focused on assignment of reputation, and how that might depend on the route the mail takes, or even perhaps on different mailbox names within a domain. I contend that these are issues for the reputation systems. All SPF does is authenticate that the domain believes that it's mail could have traveled via a particular MTA. If that check passes, normally, one just feeds the domain name into a reputation system (such as white or black lists.) If there is need for finer grained reputation, then it is up to some reputation service to offer better assessments based on more information. Nothing in any of the proposals tells clients how they should assess reputation. If it is argued that domain name based reputation will be the only de facto available option, then I submit it isn't too hard for large entities to use multiple mail sub-domains: jane_doe@example.com - mail from real people news@support.example.com - mail from opt-in newsletters coolOffer@ads.example.com - unsolicited advertisement 3) Phillip Hallam-Baker's examples These examples are a clear extension into other approaches. None of these examples has anything to do with domain authentication of an IP. To quote Phillip about such extensions: "...the number of degree of freedom are huge". To this end, these examples beg for something much larger than the part of the problem the current projects ever set out to handle. I understand the desire to design a more comprehensive mail policy format. And I understand the desire that such a format be extensible for future approaches that are now only contemplated. However, the proposed XML syntax doesn't achieve this either: While it is true that XML provides a much richer syntactic framework in which to extend an original document format, it says nothing about the semantic meaning of such extensions. In the six months that the XML format has been in public discussion, I haven't seen one proposal that actually includes the rules for semantic interpretation of future extensions. This is no surprise: It is a hard problem. The myriad of possible extensions that have been expressed, and their subtle effects of the semantics of the original format make it clear that defining how clients are to interpret future extensions would be difficult. I maintain that, in the problem space these projects were designed for, namely authentication of the origin of mail based on the domain name, the SPF classic syntax does just fine. There is a little room for extension (defined both syntactically and semantically), just enough to handle a few future ideas within this problem space. I think Dave Crocker's posting from earlier today (http://www.imc.org/ietf-mxcomp/mail-archive/msg02139.html) speaks for this approach eloquently. When a larger framework for mail policy emerges, SPF can easily add a modifier for pointing to it. Or perhaps SPF will have run its course, and the newer framework will simple take over. Either way is fine. Solving the original small, but important slice that all of the original projects targeted should be our first priority. If we can do that, then we show the world, and ourselves, that we are capable of tackling more. - Mark Lentczner Mark Lentczner http://www.ozonehouse.com/mark/ markl@glyphic.com From owner-ietf-mxcomp@mail.imc.org Mon Jun 21 17:04:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29282 for ; Mon, 21 Jun 2004 17:04:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LKt9ih066860; Mon, 21 Jun 2004 13:55:09 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5LKt9Id066859; Mon, 21 Jun 2004 13:55:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LKt9CA066851 for ; Mon, 21 Jun 2004 13:55:09 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.131.244.249] ([::ffff:216.168.239.87]) (AUTH: LOGIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Mon, 21 Jun 2004 16:55:11 -0400 id 0005C55A.40D74B2F.0000207E In-Reply-To: <1CD00592-BFE8-11D8-BD27-000A95CA7FAE@dbc.mtview.ca.us> References: <81AC085044D04B429F5FB883D94FA1AF42A291@df-fido-msg.exchange.corp.microsoft.com> <1CD00592-BFE8-11D8-BD27-000A95CA7FAE@dbc.mtview.ca.us> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <48DFFE06-C3C5-11D8-8D33-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: Ted Hardie , IETF MARID WG From: Andrew Newton Subject: Re: Drive Towards Consensus [was Re: On Extensibility in MARID Records] Date: Mon, 21 Jun 2004 16:55:10 -0400 To: Marshall Rose X-Mailer: Apple Mail (2.613) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jun 16, 2004, at 6:54 PM, Marshall Rose wrote: > starting monday, june 21, 2004 00:00:00 us/pacific time, the working > group may reply to any of these scenario messages for the purpose of > explaining how the SPF syntax is sufficient. Just a reminder: responses on SPF syntax being sufficient are now welcome. -andy From owner-ietf-mxcomp@mail.imc.org Mon Jun 21 17:21:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01218 for ; Mon, 21 Jun 2004 17:21:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LLBRvG069657; Mon, 21 Jun 2004 14:11:27 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5LLBRve069656; Mon, 21 Jun 2004 14:11:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5LLBQoD069643 for ; Mon, 21 Jun 2004 14:11:26 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Mon, 21 Jun 2004 17:15:01 -0400 Received: from ([68.223.169.60]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 1663148891; Mon, 21 Jun 2004 17:15:00 -0400 Message-ID: <000201c457d5$5314f730$6401a8c0@hdev1> From: "Hector Santos" To: "Luis Bruno" , "IETF MARID WG" References: <81AC085044D04B429F5FB883D94FA1AF42A291@df-fido-msg.exchange.corp.microsoft.com> <1CD00592-BFE8-11D8-BD27-000A95CA7FAE@dbc.mtview.ca.us> <50B2A36E-C00B-11D8-999B-000A95BC6A7E@margaretolson.com> <200406211141.13641.jonagard@amazon.com> <20040621203103.GA7726@republico.estv.ipv.pt> Subject: Re: Drive Towards Consensus [was Re: On Extensibility in MARID Records] Date: Mon, 21 Jun 2004 17:18:20 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.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: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Luis Bruno" To: "IETF MARID WG" Sent: Monday, June 21, 2004 4:31 PM Subject: Re: Drive Towards Consensus [was Re: On Extensibility in MARID Records] > > Jonathan Gardner wrote: > > If we decide that Sender ID will only authenticate whether a particular MTA > > at an IP address is allowed to send messages for a domain, then Sender ID > > is sufficient. > > Sufficient, but not necessary; in other words, overkill. > > Paging Hector Santos: I couldn't get email directly to you; 550 Return Path > not verifiable after RCPT TO: (and postmaster@ didn't work :-) ) Oh, I got something this morning directly from you? ----- Original Message ----- From: "Luis Bruno" To: "Hector Santos" Sent: Monday, June 21, 2004 7:01 AM Subject: Re: MARID Records and the standards process And I replied to this. Let me check the anti-spam logs. Ok, your 7am message was validated successfully via CBV: 20040621 07:04:31 ------------------------------------- 20040621 07:04:31 version : 1.62 / 1.54 20040621 07:04:31 calltype : SMTP 20040621 07:04:31 state : rcpt 20040621 07:04:31 srvdom : winserver.com 20040621 07:04:31 srvip : 208.247.131.9 20040621 07:04:31 cip : 193.137.7.30 20040621 07:04:31 cdn : republico.estv.ipv.pt 20040621 07:04:31 from : 20040621 07:04:31 rcpt : 20040621 07:04:31 ruid : 228947 20040621 07:04:31 testorder : FLT RBL SPF CEP CBV 20040621 07:04:31 sapfilter : pass (time:62) 20040621 07:04:31 saprbl : testing 30.7.137.193.sbl.spamhaus.org 20040621 07:04:33 saprbl : testing 30.7.137.193.list.dsbl.org 20040621 07:04:34 saprbl : testing 30.7.137.193.bl.spamcop.net 20040621 07:04:35 saprbl : pass (time:3485) 20040621 07:04:40 sapspf : none (time:4921) 20040621 07:04:40 sapcep : test from=republico.estv.ipv.pt 20040621 07:04:44 sapcep : none (time:4875) 20040621 07:04:46 sapcbv : total mx records: 0 20040621 07:04:51 try domain : republico.estv.ipv.pt ip: 193.137.7.30 20040621 07:04:51 # connecting to 193.137.7.30 20040621 07:04:52 S: 220 republico.estv.ipv.pt ESMTP Exim 4.22 Mon, 21 Jun 2004 12:02:15 +0100 20040621 07:04:52 C: NOOP WCSAP v1.62 Wildcat! Sender Authentication Protocol http://www.santronics.com 20040621 07:04:52 S: 250 OK 20040621 07:04:52 C: HELO mail.winserver.com 20040621 07:04:52 S: 250 republico.estv.ipv.pt Hello ntbbs.winserver.com [208.247.131.9] 20040621 07:04:52 C: MAIL FROM: <> 20040621 07:04:53 S: 250 OK 20040621 07:04:53 C: RCPT TO: 20040621 07:04:53 S: 250 Accepted 20040621 07:04:53 C: RCPT TO: 20040621 07:04:53 S: 550 relay not permitted 20040621 07:04:53 C: QUIT 20040621 07:04:53 sapcbv : 250 20040621 07:04:53 result : accept (-1) 20040621 07:04:53 wcsap finish (22172 msecs) 20040621 07:06:17 ------------------------------------- Why no SPF record? I sent a reply to you, and I see a 10am transaction from you which failed due to your return domain failed. A 451 response was issued to allow you to try again. It was tried 2-3 more times. 20040621 10:18:42 ------------------------------------- 20040621 10:18:42 version : 1.62 / 1.54 20040621 10:18:42 calltype : SMTP 20040621 10:18:42 state : rcpt 20040621 10:18:42 srvdom : winserver.com 20040621 10:18:42 srvip : 208.247.131.9 20040621 10:18:42 cip : 193.137.7.30 20040621 10:18:42 cdn : republico.estv.ipv.pt 20040621 10:18:42 from : 20040621 10:18:42 rcpt : 20040621 10:18:42 ruid : 228947 20040621 10:18:42 testorder : FLT RBL SPF CEP CBV 20040621 10:18:42 sapfilter : pass (time:63) 20040621 10:18:42 saprbl : testing 30.7.137.193.sbl.spamhaus.org 20040621 10:18:42 saprbl : testing 30.7.137.193.list.dsbl.org 20040621 10:18:43 saprbl : testing 30.7.137.193.bl.spamcop.net 20040621 10:18:49 saprbl : pass (time:6906) 20040621 10:18:49 sapspf : none (time:703) 20040621 10:18:49 sapcep : test from=republico.estv.ipv.pt 20040621 10:18:50 sapcep : none (time:1282) 20040621 10:19:00 sapcbv : rejected - can not resolve republico.estv.ipv.pt 20040621 10:19:00 result : reject (0) 20040621 10:19:00 smtp code : 450 20040621 10:19:00 reason : Rejected by WCSAP CBV 20040621 10:19:00 wcsap finish (19094 msecs) 20040621 10:19:50 ----------------------------------- I just tried again manually and your domain still fails MX and A record lookups: d:\wc5beta>nslookup -query=mx republico.estv.ipv.pt DNS request timed out. timeout was 2 seconds. DNS request timed out. timeout was 2 seconds. *** Request to ns1.mia.bellsouth.net timed-out d:\wc5beta>nslookup -query=a republico.estv.ipv.pt DNS request timed out. timeout was 2 seconds. DNS request timed out. timeout was 2 seconds. *** Request to ns1.mia.bellsouth.net timed-out Lesson/Notes here learned? Strict SMTP compliancy works for valid return addresses works. Spammers will not complain about False Positives. However, legitimate people will. But I don't see the FAULT in the SMTP operation. It did its job as it suppose to behave with a strong enforcment of SMTP compliancy - meaning that ADDRESS better be good! By far, this approach as eliminate a majority of the anonymous mail abuse. When MARID is implemented, the 2821 portion of it will replace MCEP (SAPCEP) logic above. At some point, I hope it to replace SPF, but SPF will probably not be removed with the initial implementation. The MARID 2822 logic will be added AFTER the 2821 is validated. Nothing from I see in Microsoft MCEP logic will validate this type of transaction with a high degree of trust. That address better be good when it is provided at MAIL FROM: -- Hector From owner-ietf-mxcomp@mail.imc.org Mon Jun 21 19:00:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12545 for ; Mon, 21 Jun 2004 19:00:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LMlHw4087622; Mon, 21 Jun 2004 15:47:17 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5LMlHeE087621; Mon, 21 Jun 2004 15:47:17 -0700 (PDT) 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.9) with ESMTP id i5LMlH7i087614 for ; Mon, 21 Jun 2004 15:47:17 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i5LMlJrD002546; Mon, 21 Jun 2004 15:47:19 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 21 Jun 2004 15:47:19 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Mark Lentczner'" , IETF MARID WG Subject: RE: Drive Towards Consensus [was Re: On Extensibility in MARID Re cords] Date: Mon, 21 Jun 2004 15:47:12 -0700 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: > In light of that, I see that each of the three postings argue > that the > SPF syntax can't handle something that it wasn't designed to handle. That is why it would be an extension. Seriously, why do you think 'out of scope' is an argument here? If it was in scope it would not be an extension. People have started to work on every one of the proposals made. I would expect some of them at least to be proposed as subject matter for a MARID extension group or a successor group. A detailed writeup of the S/MIME proposal will be submitted before San Diego. The problem with the SPF syntax is that it takes the APL approach. Sure you can create a great syntax for one single purpose with a syntax that assigns functions to character symbols. But in language design terms APL made remarkably impact for a language so widely used. LISP on the other hand has spawned a whole familly of languages, ML, Prolog, Scheme, Orwell and the main advance Java made over C was to abandon some of the more obfuscated syntax forms. > 3) Phillip Hallam-Baker's examples > These examples are a clear extension into other approaches. None of > these examples has anything to do with domain authentication > of an IP. > To quote Phillip about such extensions: "...the number of degree of > freedom are huge". To this end, these examples beg for > something much > larger than the part of the problem the current projects ever set out > to handle. I was referring to the choices when you embedd the necessary data structures in SPF. With XML or S-Expressions or any similar formal data encoding scheme I can write a schema that most people can follow without even reading the spec. There is much less room for mistakes. > I understand the desire to design a more comprehensive mail policy > format. And I understand the desire that such a format be extensible > for future approaches that are now only contemplated. However, the > proposed XML syntax doesn't achieve this either: While it is > true that > XML provides a much richer syntactic framework in which to extend an > original document format, it says nothing about the semantic > meaning of such extensions. That is not the objective. Your argument is like saying, "I understand that a prius has better fuel efficiency than an SUV, but a Prius is no better since it does not run on water" > The myriad of possible extensions that have been expressed, > and their subtle effects of the semantics of the original format make > it clear that defining how clients are to interpret future extensions > would be difficult. It is perfectly simple to interpret the presence of the S/MIME extensions. If you understand the schema you follow that understanding, otherwise you ignore the information - like you would if you do not understand MARID. > When a larger framework for mail policy > emerges, SPF can easily add a modifier for pointing to it. > Or perhaps > SPF will have run its course, and the newer framework will > simple take > over. Either way is fine. No, it is not fine. I cannot tell the media in June that I am enthusiastic about MARID, then tell them in August that MARID is obsolete and must be abandonded. From owner-ietf-mxcomp@mail.imc.org Mon Jun 21 19:18:09 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14337 for ; Mon, 21 Jun 2004 19:18:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LN7JHL090174; Mon, 21 Jun 2004 16:07:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5LN7I0C090173; Mon, 21 Jun 2004 16:07:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from messagelevel.com ([208.253.112.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LN72NR090138 for ; Mon, 21 Jun 2004 16:07:18 -0700 (PDT) (envelope-from bill.mcinnis@messagelevel.com) Date: Mon, 21 Jun 2004 19:07:00 -0400 Message-Id: <200406211907.AA312672458@messagelevel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 From: "Bill Mcinnis" Reply-To: To: CC: Subject: RE: Factored lookup - ML patent claim issue. X-Mailer: X-Declude-Sender: bill.mcinnis@messagelevel.com [127.0.0.1] X-Note: This E-mail was scanned by Declude JunkMail (www.declude.com) for spam. X-Spam-Tests-Failed: None [0] X-Note: This E-mail was sent from ([127.0.0.1]). Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5LN7INR090167 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Exactly. Since DNS is public and queryable in order to ensure routing, we feel that everything will ultimately fall at the message level. Even authorized "users" on a box are the old "Mail From" test which is spoofable and constantly accessed by dictionary attacks. Moreover, although people don't really think of IP spoofing as a concern due to it's unroutable nature in two way conversations, our tests have shown that Spammers are increasingly taking advantage of this on a one way "Broadcast" stream to drop emails with the proper IP's (especially in a private relay system with NAT'ing). In essence they've adapted to the "RMX" test. As such, more IP's within the DNS structure are simply more "roadmaps" for spammers to violate systems. We don't want to go to deep into our Patent claims, but as soon as a method goes beyond the typical domain and IP tests and verifies whether or not an email originated from the system it says it is coming from, is where we may have conflicts. As an aside, Message Level does currently incorporate an "authorized sender" component for distributed systems to send authorized email without having to make their separate systems public. Thereby, taking care of the relay and forward problems inherent within DNS tests. We'd love to show you our prototypes. Bill McInnis www.messagelevel.com -----Original Message----- From: Matthew Elvey [mailto:matthew@elvey.com] Sent: Saturday, June 19, 2004 4:49 PM To: Bill Mcinnis Cc: ietf-mxcomp@imc.org Subject: Factored lookup - ML patent claim issue. On 6/18/04 1:40 PM, Bill Mcinnis sent forth electrons to convey: > >Simplistically speaking, since domains/networks know how they are >configured, why not have a mechanism that can sit on their domain and verify to those asking if a message came from their domain or network rather than trying to explain their whole setup to everyone? Likewise for those receiving the message have a mechanism that does the same thing in reverse. (for full disclosure this process is also something we have patent claims and working code on) That way you don’t have to list all of your users, ips, basically diagram your whole network setup to everyone. > Does ML have patent claims on the factored approach for checking if a domain has said an IP is in an authorized-to-mail part of its network? I.E. DMP's $REV-ADDRESS-1.in-addr._smtp-client.$FQDN ? (Adopted by FSV.) Stuff on factored being a good/bad idea: > Meng's familytree.pdf: "tradeoff: Block vs factored. Block records require more parsing, but subsequent lookups suffer zero marginal DNS cost. Factored records need less parsing, but each new negative means a new DNS lookup." The following section of draft-irtf-asrg-lmap-discussion-01.txt is relevant: 4.2. Network Infrastructure Publication of LMAP information results in a readily available list of IP addresses of hosts authorized to send messages associated with a domain. These lists yield information about the network structure, business relationships, and possibly other information about the domain owner, as growing number of domains are owned by single people or families. Such lists may also provide hostile parties with a list of targets for possible attacks. However, such information is often already publicly accessible through other means. Anyone communicating with individuals at a domain may readily obtain this information, and share it with anyone else. Business relationships have been discovered, for example, prior to official public announcements, by examining DNS records. Nearly all such private information about network structure and relationships may therefore be described as already being readily available. If such information is to be kept secret, it is the users responsibility to send messages in such a way as to keep that information private. ---- This outgoing message is guaranteed to be authentic by MessageLevel users. Guarantee the authenticity of your email @ http://www.messagelevel.com. From owner-ietf-mxcomp@mail.imc.org Mon Jun 21 19:21:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14715 for ; Mon, 21 Jun 2004 19:21:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LN9h36090466; Mon, 21 Jun 2004 16:09:43 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5LN9hYC090465; Mon, 21 Jun 2004 16:09:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from messagelevel.com ([208.253.112.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LN9gq0090456 for ; Mon, 21 Jun 2004 16:09:43 -0700 (PDT) (envelope-from bill.mcinnis@messagelevel.com) Date: Mon, 21 Jun 2004 19:09:46 -0400 Message-Id: <200406211909.AA540410084@messagelevel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 From: "Bill Mcinnis" Reply-To: To: CC: Subject: RE: Factored lookup - ML patent claim issue. X-Mailer: X-Declude-Sender: bill.mcinnis@messagelevel.com [127.0.0.1] X-Note: This E-mail was scanned by Declude JunkMail (www.declude.com) for spam. X-Spam-Tests-Failed: None [0] X-Note: This E-mail was sent from ([127.0.0.1]). Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5LN9hq0090460 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Exactly. Since DNS is public and queryable in order to ensure routing, we feel that everything will ultimately fall at the message level. Even authorized "users" on a box are the old "Mail From" test which is spoofable and constantly accessed by dictionary attacks. Moreover, although people don't really think of IP spoofing as a concern due to it's unroutable nature in two way conversations, our tests have shown that Spammers are increasingly taking advantage of this on a one way "Broadcast" stream to drop emails with the proper IP's (especially in a private relay system with NAT'ing). In essence they've adapted to the "RMX" test. As such, more IP's within the DNS structure are simply more "roadmaps" for spammers to violate systems. We don't want to go to deep into our Patent claims, but as soon as a method goes beyond the typical domain and IP tests and verifies whether or not an email originated from the system it says it is coming from, is where we may have conflicts. As an aside, Message Level does currently incorporate an "authorized sender" component for distributed systems to send authorized email without having to make their separate systems public. Thereby, taking care of the relay and forward problems inherent within DNS tests. We'd love to show you our prototypes. Bill McInnis www.messagelevel.com -----Original Message----- From: Matthew Elvey [mailto:matthew@elvey.com] Sent: Saturday, June 19, 2004 4:49 PM To: Bill Mcinnis Cc: ietf-mxcomp@imc.org Subject: Factored lookup - ML patent claim issue. On 6/18/04 1:40 PM, Bill Mcinnis sent forth electrons to convey: > >Simplistically speaking, since domains/networks know how they are >configured, why not have a mechanism that can sit on their domain and verify to those asking if a message came from their domain or network rather than trying to explain their whole setup to everyone? Likewise for those receiving the message have a mechanism that does the same thing in reverse. (for full disclosure this process is also something we have patent claims and working code on) That way you don’t have to list all of your users, ips, basically diagram your whole network setup to everyone. > Does ML have patent claims on the factored approach for checking if a domain has said an IP is in an authorized-to-mail part of its network? I.E. DMP's $REV-ADDRESS-1.in-addr._smtp-client.$FQDN ? (Adopted by FSV.) Stuff on factored being a good/bad idea: > Meng's familytree.pdf: "tradeoff: Block vs factored. Block records require more parsing, but subsequent lookups suffer zero marginal DNS cost. Factored records need less parsing, but each new negative means a new DNS lookup." The following section of draft-irtf-asrg-lmap-discussion-01.txt is relevant: 4.2. Network Infrastructure Publication of LMAP information results in a readily available list of IP addresses of hosts authorized to send messages associated with a domain. These lists yield information about the network structure, business relationships, and possibly other information about the domain owner, as growing number of domains are owned by single people or families. Such lists may also provide hostile parties with a list of targets for possible attacks. However, such information is often already publicly accessible through other means. Anyone communicating with individuals at a domain may readily obtain this information, and share it with anyone else. Business relationships have been discovered, for example, prior to official public announcements, by examining DNS records. Nearly all such private information about network structure and relationships may therefore be described as already being readily available. If such information is to be kept secret, it is the users responsibility to send messages in such a way as to keep that information private. ---- This outgoing message is guaranteed to be authentic by MessageLevel users. Guarantee the authenticity of your email @ http://www.messagelevel.com. From owner-ietf-mxcomp@mail.imc.org Mon Jun 21 19:22:01 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14774 for ; Mon, 21 Jun 2004 19:22:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LNA2AW090549; Mon, 21 Jun 2004 16:10:02 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5LNA2aR090548; Mon, 21 Jun 2004 16:10:02 -0700 (PDT) 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.9) with ESMTP id i5LNA1U5090541 for ; Mon, 21 Jun 2004 16:10:01 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i5LNA2rH008641; Mon, 21 Jun 2004 16:10:03 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 21 Jun 2004 16:10:02 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'John R Levine'" , Jim Lyon Cc: IETF-MXCOMP Subject: RE: MARID Records and the standards process Date: Mon, 21 Jun 2004 16:09:59 -0700 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 understand this argument, but it still strikes me as utterly > unpersuasive. For one thing, this kind of piggybacking only > makes sense > when networks don't have unauthorized users, which means no > zombies, and I Clearly you do not understand the argument. If MSN is rate limiting then my machine is going to be limited even if it is taken over by a zombie. > I'd publish SPF saying that I use MSN, Comcast, and WBW. I might even > sign up for a few MSN and Comcast accounts and trickle out a > little mail > through them. What reputation do I get? The max? The min? The reputation associated with the path used. > > In short, discontinuous changes of format seldom happen. > > Indeed. They only happen when they're useful. You cited http as an > extensible format a little while ago, and I can't help but notice that > extensible http 1.0 is quite incompatible with non-extensible > http 0.9, > yet everyone adapted because 1.0 has advantages that made the > transition worthwhile. That is a very bad example. I have personal experience of the issues that 0.9 caused. People were still writing new 0.9 servers as late as 1999. Another example of what happens when this approach is taken is RSS. There are so many RSS variants at this point that it will take ATOM a long time just to sort them out. > This still boils down to "it might be useful". Such statements tend to depend on who they come from. When people like Bob and Jim make them I beleive that they require very serious attention. > I have lots of swell > anti-spam ideas that might be useful, but I'm not going to > tell people to > build standards around them until I have some experiece that > demonstrates > how useful they are. So you are instead going to argue for writing a spec that in addition to not supporting them now will make the task of supporting them in the future much harder. From owner-ietf-mxcomp@mail.imc.org Mon Jun 21 19:43:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16480 for ; Mon, 21 Jun 2004 19:43:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LNY2uu095774; Mon, 21 Jun 2004 16:34:02 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5LNY2IR095773; Mon, 21 Jun 2004 16:34:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LNY1Ta095757 for ; Mon, 21 Jun 2004 16:34:01 -0700 (PDT) (envelope-from roy+dated+1090452842.fcc8cc@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i5LNY2RC097676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 21 Jun 2004 23:34:03 GMT (envelope-from roy+dated+1090452842.fcc8cc@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5LNY2p0052950 for ; Tue, 22 Jun 2004 00:34:02 +0100 (BST) (envelope-from roy+dated+1090452842.fcc8cc@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5LNY2Em052949 for ietf-mxcomp@imc.org; Tue, 22 Jun 2004 00:34:02 +0100 (BST) (envelope-from roy+dated+1090452842.fcc8cc@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Tue, 22 Jun 2004 00:34:01 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16599.28777.384010.375277@giles.gnomon.org.uk> Date: Tue, 22 Jun 2004 00:34:01 +0100 To: "Hallam-Baker, Phillip" Cc: "'Mark Lentczner'" , IETF MARID WG Subject: RE: Drive Towards Consensus [was Re: On Extensibility in MARID Re cords] In-Reply-To: References: X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >> However, the proposed XML syntax doesn't achieve this either: >> While it is true that XML provides a much richer syntactic >> framework in which to extend an original document format, it >> says nothing about the semantic meaning of such extensions. Hallam-Baker,> That is not the objective. I think it's important, though. If you have an extensible language, you have to define what a MARIDv1 interpreter should do when it encounters an extension it doesn't understand. Should it ignore attibutes it doesn't recognize, or refuse to interpret the policy at all and simply return unknown? Similarly for unrecognized elements... But if you ignore them, then should they still be descended to look for elements that _are_ recognized? SPF, as I understand it says that unrecognized mechanisms cause the policy to return unknown, but unrecognized modifiers are ignored. It's not a paricularly flexible extension model (and could probably be improved) but at least it defines the semantics... I'm largely agnostic on the syntax issue, though I personally find the SPF syntax more readable than the Caller ID syntax. But I think any extensible syntax proposal (and both SPF and XML fall into this category to greater or lesser degrees) needs to define what a MARIDv1 parser does when it encounters a MARIDv2 or MARID+extensions record. Saying that policies with unrecognized attributes or elements can't be interpreted at all by a MARIDv1 parser is a sufficiently strong deterent against deploying extensions that you'd be better off putting your extensions in a completely new record so as to avoid preventing all the MARIDv1 parsers out there from being able to read even the basic MARIDv1 semantics of your policy. The question then is whether there's some framework for extensions that allows the construction of post-MARIDv1 policies which are still useful to MARIDv1 parsers, without constraining the semantics of what can be done in extensions to the point of causing people to deploy new records anyway. I'm not saying this can't be done, or that it shouldn't be done, but I'm skeptical of the benefits of an extensible syntax in isolation of a defined model for backwards compatibility. For instance, considering XML attributes (since they're a simpler problem than elements), would it make sense to split the attribute name space into two or more classes (perhaps by initial letter) so that unrecognized attributes in one class are ignored, and unrecognized attributes in the another cause the policy as a whole to be ignored. Kind of like the X.509 distinction between critical and non-critical extensions... Actually, I think SPF syntax could benefit from such an enhancement, too. Extension mechanisms and extension modifers could both carry a flag to indicate whether they're critical. Non-critical extensions are ignored if not understood; critical extensions cause the policy as a whole to be ignored if not understood (and hence return unknown). Currently all extension mechanisms are implicitly critical and all extension modifiers are implicitly non-critical, but there's no reason why that needs to be the case... -roy From owner-ietf-mxcomp@mail.imc.org Mon Jun 21 19:45:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16574 for ; Mon, 21 Jun 2004 19:45:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LNbU9E096573; Mon, 21 Jun 2004 16:37:30 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5LNbUCT096572; Mon, 21 Jun 2004 16:37:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from hoster907.com (ns1.hoster907.com [66.211.137.27]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5LNbSjB096555 for ; Mon, 21 Jun 2004 16:37:29 -0700 (PDT) (envelope-from margaret@margaretolson.com) Received: (qmail 2709 invoked from network); 21 Jun 2004 23:38:40 -0000 X-Relay-Users: margaret.user X-Abuse: Send abuse reports to: abuse@suresupport.com Received: from unknown (HELO ?172.16.1.35?) (24.34.60.225) by ns1.hoster907.com with SMTP; 21 Jun 2004 23:38:40 -0000 In-Reply-To: <0E174519-C3C2-11D8-AA48-000393A56BB6@glyphic.com> References: <20040619212932.GC30711@obscurity.org> <0E174519-C3C2-11D8-AA48-000393A56BB6@glyphic.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: IETF MARID WG From: Margaret Olson Subject: Re: Drive Towards Consensus [was Re: On Extensibility in MARID Re cords] Date: Mon, 21 Jun 2004 19:37:26 -0400 To: Mark Lentczner X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jun 21, 2004, at 4:32 PM, Mark Lentczner wrote: > 1) Margaret Olson's examples > Alas, these examples didn't actually state what aspect SPF couldn't > handle. I don't know if the desire is to have mail rate information > in SPF, or reputation information or what. As a part of the system, > SPF seems to me to work in all the examples given. > Yes, the desire is to have mail rate information in the MARID record. I apologize for not being clearer about that. Several people have noticed that you don't necessarily trust the record author - but that is why you accredit both the sender and any channels used with indirect pointers. The rate at which a domain sends mail is an important piece of the risk assessment puzzle - should I accept this mail or not? If I know that you send at a rate that is inconsistent with spamming or if you have a very thorough, audit driven accreditation, then I'll accept your mail. There are many ways in which I can envision transmitting and enforcing rate information; my examples were intended simply to illustrate the problem. MARID on it's own doesn't do very much; it just says that the domain is authorized to send mail via these MTAs. It is essential for a broader solution to the spam and phishing problems but not sufficient. Phill Hallam-Baker and Jim Lyons have made other suggestions for how we might incorporate the reputation, accreditation, signature, and other information that is necessary. I don't think any of us have the complete answer yet but these things are emerging. The will be tied to the authentication. We need to be able to accommodate the additional information, even though we don't have it completely designed at this moment in time. We know it is out there. > 2) Jim Lyon's examples > These examples focused on assignment of reputation, and how that might > depend on the route the mail takes, or even perhaps on different > mailbox names within a domain. I contend that these are issues for > the reputation systems. All SPF does is authenticate that the domain > believes that it's mail could have traveled via a particular MTA. If > that check passes, normally, one just feeds the domain name into a > reputation system (such as white or black lists.) If there is need > for finer grained reputation, then it is up to some reputation service > to offer better assessments based on more information. Nothing in any > of the proposals tells clients how they should assess reputation. If > it is argued that domain name based reputation will be the only de > facto available option, then I submit it isn't too hard for large > entities to use multiple mail sub-domains: > jane_doe@example.com - mail from real people > news@support.example.com - mail from opt-in newsletters > coolOffer@ads.example.com - unsolicited advertisement > Creating sub-domains to make up for a syntax limitation doesn't make any sense to me. > 3) Phillip Hallam-Baker's examples > These examples are a clear extension into other approaches. None of > these examples has anything to do with domain authentication of an IP. > To quote Phillip about such extensions: "...the number of degree of > freedom are huge". To this end, these examples beg for something much > larger than the part of the problem the current projects ever set out > to handle. > > I understand the desire to design a more comprehensive mail policy > format. And I understand the desire that such a format be extensible > for future approaches that are now only contemplated. However, the > proposed XML syntax doesn't achieve this either: While it is true > that XML provides a much richer syntactic framework in which to extend > an original document format, it says nothing about the semantic > meaning of such extensions. > As Jim Lyons stated elsewhere in this thread, you need to stick to upwards compatible extensions. In practical terms, this means you can add information but you can't change the definition of existing information. The XML syntax handles this well. I agree that no amount of syntax will paper over the problems inherent in an extension that changes the meaning of existing published records. Margaret. molson@constantcontact.com margaret@margaretolson.com From owner-ietf-mxcomp@mail.imc.org Mon Jun 21 19:59:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17976 for ; Mon, 21 Jun 2004 19:59:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5LNobbp099936; Mon, 21 Jun 2004 16:50:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5LNobMD099935; Mon, 21 Jun 2004 16:50:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from hoster907.com (ns1.hoster907.com [66.211.137.27]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5LNoaud099929 for ; Mon, 21 Jun 2004 16:50:36 -0700 (PDT) (envelope-from margaret@margaretolson.com) Received: (qmail 5412 invoked from network); 21 Jun 2004 23:51:51 -0000 X-Relay-Users: margaret.user X-Abuse: Send abuse reports to: abuse@suresupport.com Received: from unknown (HELO ?172.16.1.35?) (24.34.60.225) by ns1.hoster907.com with SMTP; 21 Jun 2004 23:51:51 -0000 In-Reply-To: <200406211141.13641.jonagard@amazon.com> References: <81AC085044D04B429F5FB883D94FA1AF42A291@df-fido-msg.exchange.corp.microsoft.com> <1CD00592-BFE8-11D8-BD27-000A95CA7FAE@dbc.mtview.ca.us> <50B2A36E-C00B-11D8-999B-000A95BC6A7E@margaretolson.com> <200406211141.13641.jonagard@amazon.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: IETF MARID WG From: Margaret Olson Subject: Re: Drive Towards Consensus [was Re: On Extensibility in MARID Records] Date: Mon, 21 Jun 2004 19:50:38 -0400 To: Jonathan Gardner X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jun 21, 2004, at 2:41 PM, Jonathan Gardner wrote: > I believe that rate limiting should be beyond the scope of Sender ID. > For > one, it is better implemented on the sending MTA side. This would be an > implementation detail for the MTA, and requires no external knowledge > to > either example1.com or any receiving MTA. > If the receiving MTA wants to know if this small business sends at a rate consistent with a legitimate small business or at a rate consistent with a spammer, then the receiving MTA will want to know the rates. They will also want to know if the sending MTA accredited as enforcing sending limits; this is why you need to know things about both the channel and the sender where the sender and the channel are in different domains. In many cases, they will be in separate domains; there are millions of domains that do not run their own MTAs. > The other possibility is to implement rate limiting on the receiving > MTA's > end. But how can the receiving MTA know how many email messages were > sent > to other MTAs? How can a receiving MTA trust the number that other MTAs > report to it? These difficulties would greatly complicate Sender ID, > and so > should be external to Sender ID. > The rate limiting needs to occur on the sending side, but the receiver needs to know what it is. It is true that we don't at this moment know the specifics of how the accreditation, reputation, and rate limiting will work. But these areas are emerging; the fact that we don't have a spec in hand is not a reason to dismiss the need for them. If anything it's an argument for flexibility. Margaret From owner-ietf-mxcomp@mail.imc.org Mon Jun 21 20:11:30 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18702 for ; Mon, 21 Jun 2004 20:11:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5M04hAK002698; Mon, 21 Jun 2004 17:04:43 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5M04hJQ002697; Mon, 21 Jun 2004 17:04:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5M04gD7002691 for ; Mon, 21 Jun 2004 17:04:42 -0700 (PDT) (envelope-from roy+dated+1090454685.38834f@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i5M04kRC026580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 22 Jun 2004 00:04:47 GMT (envelope-from roy+dated+1090454685.38834f@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5M04kZ2053204 for ; Tue, 22 Jun 2004 01:04:46 +0100 (BST) (envelope-from roy+dated+1090454685.38834f@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5M04jl6053203 for ietf-mxcomp@imc.org; Tue, 22 Jun 2004 01:04:46 +0100 (BST) (envelope-from roy+dated+1090454685.38834f@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Tue, 22 Jun 2004 01:04:45 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16599.30620.503528.353452@giles.gnomon.org.uk> Date: Tue, 22 Jun 2004 01:04:44 +0100 To: Margaret Olson Cc: Jonathan Gardner , IETF MARID WG Subject: Re: Drive Towards Consensus [was Re: On Extensibility in MARID Records] In-Reply-To: References: <81AC085044D04B429F5FB883D94FA1AF42A291@df-fido-msg.exchange.corp.microsoft.com> <1CD00592-BFE8-11D8-BD27-000A95CA7FAE@dbc.mtview.ca.us> <50B2A36E-C00B-11D8-999B-000A95BC6A7E@margaretolson.com> <200406211141.13641.jonagard@amazon.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Margaret" == Margaret Olson writes: Margaret> The rate limiting needs to occur on the sending side, Margaret> but the receiver needs to know what it is. But there's no need for the sender to publish the rate limiting information, because there's little reason for you to trust them. It make more sense for the sender to simply refer to a rate limit policy published by their ISP (which could be achieved by an SPF modifier). The reciever would then query the ISPs rate limiting policy for this domain and (assuming positive accreditation of the ISP) the recipient would then believe it. Obviously the ISP's rate limiting policy would have to specify the IP addresses that they're responsible for (they can't rate limit mail you send out via another source) but this is all information that should be published by the ISP, not the sender. So I don't believe it belongs in policies published by the sender, but in a completely new type of policy published by ISPs who send mail on behalf of their customers. Though, as I said before, I'd like to see a move towards (return to) sites originating (and being responsible for) their own mail rather than relaying through their ISP... -roy From owner-ietf-mxcomp@mail.imc.org Mon Jun 21 21:29:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23232 for ; Mon, 21 Jun 2004 21:29:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5M1KQPV015798; Mon, 21 Jun 2004 18:20:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5M1KQrU015797; Mon, 21 Jun 2004 18:20:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5M1KQYZ015784 for ; Mon, 21 Jun 2004 18:20:26 -0700 (PDT) (envelope-from hardie@qualcomm.com) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i5M1KJ57028591; Mon, 21 Jun 2004 18:20:19 -0700 (PDT) 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 i5M1KG0D000014; Mon, 21 Jun 2004 18:20:17 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: References: <81AC085044D04B429F5FB883D94FA1AF42A291@df-fido-msg.exchange.corp.microsof t.com> <1CD00592-BFE8-11D8-BD27-000A95CA7FAE@dbc.mtview.ca.us> <50B2A36E-C00B-11D8-999B-000A95BC6A7E@margaretolson.com> <200406211141.13641.jonagard@amazon.com> Date: Mon, 21 Jun 2004 18:20:14 -0700 To: Margaret Olson , Jonathan Gardner From: Ted Hardie Subject: Re: Drive Towards Consensus [was Re: On Extensibility in MARID Records] Cc: IETF MARID WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Reading Mark's post and the series of replies, I believe it would be fair to say that his vision of SPF/MARID is a record which allows a domain to make assertions about its own infrastructure that an MTA might be able usefully to check when deciding whether to accept traffic which asserts a relationship to that domain. The extensions of "accreditation, reputation, and rate limiting" which Margaret describe fundamentally involve a 3rd party (since rate limiting only looks really useful if audited). If that is correct, the question becomes: are these third party assertions something that need to be tied to the individual MARID assertions, are they an independent pointer within the record, or are they out of scope? Let's assume for now that at least the pointers to them are in scope. Imagine for a moment that MARID includes an extension that says: these other people also wish to make assertions about me (with the implication that the domain knows about it and is willing to point to it). Is it possible to extend MARID to do that? Sure. Give those records a similar syntax to MARID and it becomes a set of assertions made by two or more different parties about the same domain's infrastructure. Silly states then require meta-reputation to resolve, but that may not be a big deal. Local policy can resolve those towards permissiveness or restriction as required. Is it also possible to do that such that it could be attached to other assertions, as a generic mechanism for per-attribute reputation/accreditation/certification? I think so. That would, again, require the other domain to maintain some record that allowed you to check that they did make such an assertion. As long as the syntax for the per-attribute pointers is reasonably broad, they could be records associated with multiple protocols or domains. This way forward would also allow the original domain owner to specify for which attributes the other domains' views were acceptable to the domain owner (not binding on the recipient, but potentially a useful data point). But the usefulness of either goes back to the issue raised by Roy Badami--what does this mean in the context of the extension processing? The WG discussions so far seem to have gone down two processing paths: one in which MARID processing iterates through separate assertions until one assertion explicitly allows, disallows or marks unknown the message traffic; the other in which all the assertions are taken together to create three sets: allowed, disallowed, not known. In the first approach, new assertions can easily be defined to have a null affect. If the working group takes that approach, though, it seems fairly critical to define the generic "external pointer" syntax now, so that the use of external pointers modifying base assertions does not later render null assertions which would otherwise allow or disallow traffic. An alternate approach there is to specify that modifiers of a certain type can be ignored such that the base processing of the assertions can proceed if they are not understood. That would mean that the syntax of the "external pointer" could be left vague right now, as long as it is known to be of that type. Since the "set construction" mechanism presumes that you will process all the assertions to construct the sets, it is somewhat easier to have mechanisms which allow assertions to be about other assertions. The ability to handle nested assertions is also very handy here. The difficulty with this approach and 3rd party assertions is that the extension mechanism must describe what happens when they cannot be resolved, and the choice of "pretend it wasn't there" is not so easy in the face of nesting and assertions about assertions. A common, practical approach at that point is to limit external assertions to ones in which "pretend it wasn't there" processing does no harm (viz. the GeoPriv limitation that all rules must add permissions, so that the failure to resolve external reference cannot result in disclosure of private information). That can both be a serious limitation and difficult to get right when the base assertion and the 3rd party assertion about it are not coordinated. Without stepping on the toes of the original question asked by the chairs, I'd be interested in hearing whether anyone believes MARID will need the "set construction" mechanism, or whether it can go forward with the iterative processing method. That may tell us something about the extension mechanism choices and what our core needs for syntax are. regards, Ted Hardie From owner-ietf-mxcomp@mail.imc.org Mon Jun 21 23:05:27 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27958 for ; Mon, 21 Jun 2004 23:05:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5M2uAQK024067; Mon, 21 Jun 2004 19:56:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5M2uAoZ024066; Mon, 21 Jun 2004 19:56:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.pan-am.ca (205-200-6-46.static.mts.net [205.200.6.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5M2u74E024056 for ; Mon, 21 Jun 2004 19:56:09 -0700 (PDT) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: Factored lookup - ML patent claim issue. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 21 Jun 2004 21:56:13 -0500 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA8DA@srv1.pan-am.ca> X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Factored lookup - ML patent claim issue. Thread-Index: AcRX5mesEuAENTO8Tem8ePXEAx4G2wAHWvMQ From: "Gordon Fecyk" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5M2uA4E024061 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > Moreover, although people don't really think of IP spoofing as a > concern due to it's unroutable nature in two way conversations, our > tests have shown that Spammers are increasingly taking advantage of > this on a one way "Broadcast" stream to drop emails with the proper > IP's (especially in a private relay system with NAT'ing). To quote an old character named Starbuck: "Felgercarb." SMTP requires end-to-end TCP. The receiving server needs to talk back to the sending client to receive mail. You need two-way communication to use TCP, hence SMTP. Who here has demonstrated a practical TCP spoofing attack? Insecure NATs are another problem entirely but are still at least traceable to the insecure NAT. What you're saying here smacks of, well, there are harsher words than "felgercarb" but they apply here. > We'd love to show you our prototypes. I don't think anyone here's stopping you. Write and send an internet-draft. -- PGP key (0x0AFA039E): Sometimes it's hard to tell where the game ends and where reality bites, er, begins. From owner-ietf-mxcomp@mail.imc.org Mon Jun 21 23:38:13 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29430 for ; Mon, 21 Jun 2004 23:38:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5M3XAH3027045; Mon, 21 Jun 2004 20:33:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5M3XAVx027044; Mon, 21 Jun 2004 20:33:10 -0700 (PDT) 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.9) with ESMTP id i5M3X92t027038 for ; Mon, 21 Jun 2004 20:33:09 -0700 (PDT) (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.34) id 1Bcc1w-00074R-5S for ietf-mxcomp@imc.org; Mon, 21 Jun 2004 22:33:16 -0500 To: "IETF MARID WG" References: <81AC085044D04B429F5FB883D94FA1AF42A88E@df-fido-msg.exchange.corp.microsoft.com> From: wayne Reply-To: "IETF MARID WG" Date: Mon, 21 Jun 2004 22:33:04 -0500 In-Reply-To: <81AC085044D04B429F5FB883D94FA1AF42A88E@df-fido-msg.exchange.corp.microsoft.com> (Jim Lyon's message of "Fri, 18 Jun 2004 15:46:21 -0700") 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 (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: FW: Drive Towards Consensus Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-4.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <81AC085044D04B429F5FB883D94FA1AF42A88E@df-fido-msg.exchange.corp.microsoft.com> "Jim Lyon" writes: > Reputations Tied to Individual Mechanisms > ----------- ---- -- ---------- ---------- > > Suppose I have a small domain with no reputation. [snip] > > Using invented syntax, I could say something like: > v=spf1 +indirect:msn.com/targetrep +indirect:comcast.com/targetrep > -all > which gets the point across nicely. > > [snip] > v=spf1 +indirect:a.hotmail.com +indirect:b.hotmail.com > +indirect:c.hotmail.com -all > > In this case, the indirections are a mere implementation detail, [snip] I like this concept of using the mechanism that caused the IP address to be validated as a way of determining the reputation. This is not unlike the checking of URLs within email to determine of they point to spammers websites. However, I see this as a case of being "not useful because no one will believe unverifiable claims." If you are going to do this kind of reputation checking, you should do it whether there is a "/targetrep" flag or not. A spammer who publishes "v=spf1 include:optinrealbig.com -all" will almost certainly not say to check the target's reputation, but a receiver may find that very useful to check. If the various hotmail include: mechanisms aren't good indicators of reputation, the checking will make no difference. However, there is a chance that, due to the CIDR blocks dedicated to dialups or different countries, the various hotmail include:'s will make a difference. The anti-spam systems that judge the urls within an email don't look for some special tag and for good reason. The same goes for SPF records. > Message Types Tied to Individual Mechanisms > ------- ----- ---- -- ---------- ---------- > > Many domains send both non-bulk and bulk mail, generally through very > different parts of their organization. It may be useful to have > annotations on an SPF mechanism that describe the kinds of mail they > send. For example: > v=spf1 +mx/bulk +indirect:comcast.com/nonbulk -all Again, I see this as a case of being "not useful because no one will believe unverifiable claims." > Summary > ------- > > The common theme among these hard-to-represent-in-SPF extensions is that > the extension says something about an individual mechanism, instead of > saying something about the domain as a whole This is true. The current SPF spec says that modifiers are position independent and therefore you can't use them to mark up individual mechanisms. I think we could change the SPF spec to allow modifiers to be (optionally) position dependant and not cause problems for the installed base of SPF records. That is, we could say that things like "redirect=" and "exp=" are position independent, but allow for new modifiers, such as "targetrep=" and "mailvolume=" to be position dependant. So, it would be possible to say "v=spf1 mx mailvolume=bulk..." and have the mx: mechanism marked up. I have checked the SPF records that are listed in the Adoption Roll and my survey of the 1.3 million email domain names. I could find none that wouldn't work just fine with this change in the SPF spec. I'm not sure I really think it is a good idea to make this change, but I think it is a valid option. -wayne From owner-ietf-mxcomp@mail.imc.org Mon Jun 21 23:38:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29454 for ; Mon, 21 Jun 2004 23:38:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5M3WPMh027001; Mon, 21 Jun 2004 20:32:25 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5M3WPTo027000; Mon, 21 Jun 2004 20:32:25 -0700 (PDT) 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.9) with ESMTP id i5M3WOlQ026993 for ; Mon, 21 Jun 2004 20:32:24 -0700 (PDT) (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.34) id 1Bcc1E-00074B-LT for ietf-mxcomp@imc.org; Mon, 21 Jun 2004 22:32:31 -0500 To: "IETF MARID WG" References: From: wayne Reply-To: "IETF MARID WG" Date: Mon, 21 Jun 2004 22:32:20 -0500 In-Reply-To: (Phillip Hallam-Baker's message of "Fri, 18 Jun 2004 20:55:35 -0700") 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 (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: Drive Towards Consensus Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-4.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In "Hallam-Baker, Phillip" writes: > Another example where SPF syntax comes unstuck. > [out of order reply:] > I don't think anyone can fairly claim that the spf ad-hoc syntax is going to > cope with this. OK you can define ad hoc extensions, but the number of > degree of freedom are huge. On the contrary, I think that these are cases that can easily be handled directly with the current SPF syntax. I don't see any difference between defining extensions as SPF modifiers and defining new labels in the XML markup. > A domain uses S/MIME authentication [...] > > The following information is needed: > > * express statement 'all mail is signed' use the modifier: smime=always > * express the message digest of the signing certificate use the modifier: smime.certdigest= > * express the algorithm supported. use the modifier: smime.alg=rsa Or, just use: smime-info= > Now consider the following complications: > > * Also support pgp message format Use the modifier: pgp=allowed > * express different signing policies 'mail signed when extension > offered' I don't understand this one. > * handle the TLS protocol that is handled just fine with the MTA isn't it? > * encryption use the modifier: encryption= > * different key distribution structures - web 'o trust, xkms, domain > key use the modifiers: webotrust= xkms= dk= > One could argue that this should be handled by a separate record. But then > we are back to the two parsers option anyway. No, because the MTAs would not be *required* to support two (or more) parsers. Many of these options wouldn't require a new parser anyway. -wayne From owner-ietf-mxcomp@mail.imc.org Mon Jun 21 23:39:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29528 for ; Mon, 21 Jun 2004 23:39:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5M3VWog026864; Mon, 21 Jun 2004 20:31:32 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5M3VWBr026863; Mon, 21 Jun 2004 20:31:32 -0700 (PDT) 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.9) with ESMTP id i5M3VVjG026857 for ; Mon, 21 Jun 2004 20:31:31 -0700 (PDT) (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.34) id 1Bcc0N-00073b-3f for ietf-mxcomp@imc.org; Mon, 21 Jun 2004 22:31:37 -0500 To: "IETF MARID WG" References: <81AC085044D04B429F5FB883D94FA1AF42A291@df-fido-msg.exchange.corp.microsoft.com> <1CD00592-BFE8-11D8-BD27-000A95CA7FAE@dbc.mtview.ca.us> From: wayne Reply-To: "IETF MARID WG" Date: Mon, 21 Jun 2004 22:31:26 -0500 In-Reply-To: <1CD00592-BFE8-11D8-BD27-000A95CA7FAE@dbc.mtview.ca.us> (Marshall Rose's message of "Wed, 16 Jun 2004 15:54:24 -0700") 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 (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: Drive Towards Consensus Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-4.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <1CD00592-BFE8-11D8-BD27-000A95CA7FAE@dbc.mtview.ca.us> Marshall Rose writes: > the co-chairs think this is a useful thread; in fact, we're going to > place the following plan in front of the working group: > > it is clear to the co-chairs that the "tipping point" with respect to > the working group's deliberations revolve around the sufficiency of > the SPF syntax to address near-term concerns. if the syntax is > adequate, it is hard to argue for an alternative or future syntax; if > the syntax is inadequate, then the SPF syntax is of transitory use. I've read the proposed scenarios and the replies to them. It is hard to give an overall response without making bland assertions, but it is hard to give point-by-point responses without getting lost in the details. So, in this post, I'll give my overall view of these situations, details will follow in other posts. People advocating XML have given scenarios which are mostly fleshed out versions of what they have been saying all along. This is very good, and it also means that I wasn't surprised by anything. Overall, I found none of the scenarios to give a compelling reason why requiring support of XML would outweight its the negative effects. (These negative effects of XML are caused by both technical and, uh, "emotional" reasons. It is tempting to dismiss the "emotional" reasons, but we have to deal with the real world here.) Briefly, all of the scenarios fall into one or more of the following catagories: * They can easily be handled directly with the current SPF syntax. * They can easily be handled with an SPF modifier that points to where the information can be found. * They are so far beyond the scope of MARID that they dilute and muddle the purpose. * They are not useful because no one will believe unverifiable claims, such as "I send only 100 emails per day". * They can best be handled other ways. * They require email receivers to do work for the senders with no benefit for the receivers. As a result, I don't see them being implemented by the receivers. -wayne From owner-ietf-mxcomp@mail.imc.org Mon Jun 21 23:59:30 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00522 for ; Mon, 21 Jun 2004 23:59:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5M3pIQT028249; Mon, 21 Jun 2004 20:51:18 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5M3pHw2028248; Mon, 21 Jun 2004 20:51:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5M3pHOA028241 for ; Mon, 21 Jun 2004 20:51:17 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from [192.168.2.24] (adsl-64-142-13-68.sonic.net [64.142.13.68]) by a.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i5M3pMGP011210 for ; Mon, 21 Jun 2004 20:51:22 -0700 Subject: Re: Drive Towards Consensus [was Re: On Extensibility in MARID Records] From: Douglas Otis To: MARID Content-Type: text/plain Message-Id: <1087876281.2643.21.camel@bash.adsl-64-142-13-68.sonic.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 21 Jun 2004 20:51:22 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 2004-06-21 at 17:04, Roy Badami wrote: > >>>>> "Margaret" == Margaret Olson writes: > > Margaret> The rate limiting needs to occur on the sending side, > Margaret> but the receiver needs to know what it is. > > But there's no need for the sender to publish the rate limiting > information, because there's little reason for you to trust them. It > make more sense for the sender to simply refer to a rate limit policy > published by their ISP (which could be achieved by an SPF modifier). > > The reciever would then query the ISPs rate limiting policy for this > domain and (assuming positive accreditation of the ISP) the recipient > would then believe it. > > Obviously the ISP's rate limiting policy would have to specify the IP > addresses that they're responsible for (they can't rate limit mail you > send out via another source) but this is all information that should > be published by the ISP, not the sender. > > So I don't believe it belongs in policies published by the sender, but > in a completely new type of policy published by ISPs who send mail on > behalf of their customers. > > Though, as I said before, I'd like to see a move towards (return to) > sites originating (and being responsible for) their own mail rather > than relaying through their ISP... Those sending mail must be accountable whether originating or relaying. Finding a practical way to assess accountability for the administrative entity is the challenge. There are many different schemes to access identities of the author, if the author so wishes. With mechanisms defined in the Fenton "Identified Internet Mail" proposal, organizations can assure recipients of having received valid mail from the indicated author through the use of an HTTP key serving scheme. Although DNS is not able to handle this type of query, the HTTP key server both minimizes queries and leaves the current mail infrastructure intact. Publishing outbound mail paths to restrict the function of error returns essentially hinders posting mail from various access points. As a fix, rewriting envelopes transfers the accountability of the sending administration (the current outbound host) in an effort to repair the damage and allow mail to travel over otherwise unpublished channels. The recipient may see the same name as being the author of the message but must also be wary that my-pda.com is not the same as my-pda.co.jp when these entities are acting as the accountable sending administration. In addition, anyone within such a domain is still able to mimic these headers as being checked. How is this different than authenticating the MTA and _always_ holding this entity accountable? The envelope information is not exposed to the recipient, but even doing so may not be an effective means of countering fraudulent mail. Countering fraudulent mail requires evaluating policies of the administrative entities and refusing service to those known to cause or allow abuse unabated. Rate limiting the receiver could be effective for administrative entities not yet evaluated. Accreditation services could assess the rates of mail by various means (perhaps by way of queries) and tally complaints or evidence of abuse. These accreditation services may also provide a uniform query mechanism to ascertain accreditation, affiliations, as well as authorization and authentication of the address in conjunction with the administrative domain. Such accreditation could combine all these functions into a single query (perhaps in logarithmic form)! ipaddr.helo-domain.accredit.com -> affiliations.time.size.complaints Expecting the MTA to query several records in sequence to assess each message to uncover possible relationships between an author and their means of access results in undefined levels of recursion and extensive computational resources to build complex maps from these distributed structures. Expecting access providers to enable direct SMTP connectivity to simplify this process removes methods for monitoring and controlling abuse. This would drop one form of protection for a dubious, expensive, and highly prone alternative. Already a scheme such as SPF could be considered over extended. Further extensions will only cause greater harm. Instead, ensure the author with an end-to-end scheme such as the Fenton proposal. Insert simple DNS records to assert the authority and authenticity of the MTA by way of CIDR notation or SRV records for a single administrative domain. These records may acquire assistance from the accreditation service, however no scheme will be able to curtail abuse without accreditation services. Policing the channel at the MTA will scale, but not at the message. Expect abusers to be the first to implement all manner and means of affecting a pretense of legitimate commerce. Stop the abuse and then end-to-end remains possible. Don't break mail and DNS with a burden of excessive and complex structures and, in doing so, make the system even more prone. -Doug From owner-ietf-mxcomp@mail.imc.org Tue Jun 22 01:29:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17618 for ; Tue, 22 Jun 2004 01:29:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5M5JoB9041837; Mon, 21 Jun 2004 22:19:50 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5M5JoYZ041836; Mon, 21 Jun 2004 22:19:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from xuxa.iecc.com (xuxa.iecc.com [208.31.42.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5M5JlTs041818 for ; Mon, 21 Jun 2004 22:19:47 -0700 (PDT) (envelope-from johnl@iecc.com) Received: (qmail 20688 invoked by uid 100); 22 Jun 2004 05:19:53 -0000 Date: 22 Jun 2004 05:19:53 -0000 Message-ID: <20040622051953.20687.qmail@xuxa.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: Re: asymmetric routing, was Factored lookup - ML patent claim issue. In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125DA8DA@srv1.pan-am.ca> Organization: I.E.C.C., Trumansburg NY USA Cc: gordonf@pan-am.ca Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >> Moreover, although people don't really think of IP spoofing as a >> concern due to it's unroutable nature in two way conversations, our >> tests have shown that Spammers are increasingly taking advantage of >> this on a one way "Broadcast" stream to drop emails with the proper >> IP's (especially in a private relay system with NAT'ing). Asymmetric routing has been a well-known spammer trick for years. Ernesto Haberli specialized in it. For people not familiar with it, the mail sender has a fast connection like a T1, and a slow disposable connection like a dialup connected to the same computer. The packets all go out with the IP of the slow connection, but sent via the fast connection. This makes it much harder to detect the fact that the spammer's using the fast connection since traceroutes will only show the slow one. This hardly slows delivery at all, since sending e-mail, particularly with large messages, sends out big packets and gets back little ones. The only visible IP is the disposable one; when the ISP gets complaints and cancels the dialup, the spammer just switches to a different dialup account and keeps going. If ISPs did ingress filtering, this wouldn't work, of course. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor "I shook hands with Senators Dole and Inouye," said Tom, disarmingly. From owner-ietf-mxcomp@mail.imc.org Tue Jun 22 01:46:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20540 for ; Tue, 22 Jun 2004 01:46:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5M5cDUh049958; Mon, 21 Jun 2004 22:38:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5M5cDUf049957; Mon, 21 Jun 2004 22:38:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [64.139.47.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5M5cCn5049895 for ; Mon, 21 Jun 2004 22:38:12 -0700 (PDT) (envelope-from gconnor@nekodojo.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by neko-base.nekodojo.org (Postfix) with ESMTP id 8F1351D651 for ; Mon, 21 Jun 2004 22:38:15 -0700 (PDT) Date: Mon, 21 Jun 2004 22:38:16 -0700 From: Greg Connor To: IETF MARID WG Subject: Re: Drive Towards Consensus [was Re: On Extensibility in MARID Re cords] Message-ID: <9100976.1087857496@[10.12.1.26]> In-Reply-To: <0E174519-C3C2-11D8-AA48-000393A56BB6@glyphic.com> References: <0E174519-C3C2-11D8-AA48-000393A56BB6@glyphic.com> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit A lot of good discussion is already going on, and I don't want to take too much time by repeating what others have said. Therefore, I will try to be brief (Hmm, I guess "try" is the operative word here :) First off, extensibility is not bad. I don't think anyone is seriously arguing "extensibility is bad". Rather, I think everyone has their own ideas about how important "extensibility" is compared to other attributes like simplicity, human readability, byte-economy, etc. Since this is a pretty wide spectrum, and "correct" answers lie all along the scale for various stakeholders, I will not try to pull anyone in any direction. The best I can do is encourage everyone to take a few moments to rank qualities in their minds that make up a "good" proposal. Second, let me stress that SPF syntax actually IS extensible. SPF provides four vehicles for extension. Let me review them quickly -- I know people are familiar with the draft and SPF site but just in case it wasn't stated clearly, here they are. 1. Modifiers Modifiers are attribute=value pairs that the receiver may ignore if he doesn't understand them. For example example1.com. IN TXT { "v=spf1 a mx ptr " "rate=100 +include:example1.com.cust-spf.esp.com " "rate=133 +include:example1.com.spf.personalmail.com ~all" } In this example (based on Margaret's first scenario) the "extra" information is understood by whoever wants to understand it, and ignored by anyone who doesn't. (One sort of limiting factor about modifiers is that they are considered to be order-independent and the current spec encourages them to be placed at the end to make this clear. If I were to propose any modification to the current spec, it would be to allow modifiers to be placed inline allowing for the possibility that they might apply/associate the terms appearing after them, if appropriate. This minor change in the spec should not affect any current parser or published records and would just be a clarification...) 2. exists: mechanism exists: makes it possible to do something DMP-like (factored) plus a lot more. Most sites will not need it, but those that do will be quite thankful it is there. I am describing exists: as a "vehicle for extensibility" because it makes a lot of things possible that would not otherwise be achieveable, including many we have not yet thought of. Let me use an example based on Margaret's third situation. example3.com. IN TXT "v=spf1 redirect=example3.com.cust.maridrus.com" example3.com.cust.maridrus.com. IN TXT { "v=spf1 a mx ptr " "-exists:CL.%{i}.FR.%{s}.exceptions.maridrus.com. " " ?all abuse=abuse@maridrus.com" } exceptions.maridrus.com IN NS ns-log1.maridrus.com. exceptions.maridrus.com IN NS ns-log2.maridrus.com. In this example, example3.com delegates their MARID policy management to a third party "maridrus.com". They in turn use an exists: check which is (usually*) triggered only if the a, mx, and ptr tests are not met. By this mechanism, the receiver is required to issue a query ending in exceptions.maridrus.com and containing the IP of the sending client, and the return path of the questionable message. The queries are then logged and unforseen sources of example3.com mail become exposed. (This is also a GREAT way to monitor how well your MARID record is doing at catching all situations, and also a great way to find forwarders that have not been white-listed by the receiver.) (* I say "usually" here because all currently existing SPF implementations have the processing happening in strict order, but if a streamlined parallel-type processor is created later, it's not much of a problem. As long as the receiver re-assembles the steps in the correct order and arrives at the same result, it is permitted to make "extra" queries -- it is the responsibility of the domain using exists: to screen out false-positives. It's also possible for a malicious sender somewhere to just make extra queries to throw off the logging - anyone doing logging would need to be alert for this too.) My second reason for describing "exists:" as a vehicle for extensibility is the little-known secret of exists: the domain owner may decide to customize the DNS server itself. For example, let's say that the maridrus.com service provider wants to do something with the "exceptions.maridrus.com" zone that a static zone file can't do. They want to answer YES to all exceptions *unless* a threshold is reached, and then reply NO to a certain IP, or sender address, or both, if that IP or address has been used too many times outside the policy. They can teach their DNS server to answer NXDOMAIN for the first 100 uses of any IP or email address, and then answer 127.0.0.2 after the limit is reached. This requires a non-standard DNS server, but the sender may bear 100% of the costs of this type of extensibility and still be within the standard. (I know the idea of returning inconsistent results will make Jonathan twitch, but the fact is that DNS servers that serve dynamic/varying information are already out there, e.g. 3DNS/akadns :) 3. Unknown/non-standard mechanisms. The behavior when we come to a non-standard mechanism is well-defined: currently the spec in use today says that processing should stop immediately and an unknown result should be returned (as if ?all had appeared where the non-standard mechanism is). This is not a "forbidden" or even a "bad" practice - it simply gives a reasonable escape clause if you decide to use a mechanism that is not in the pre-existing core set of features. The SPF spec actually uses domainkeys as its example in the draft. v=spf1 a mx ptr domainkeys:_dk.%{d} -all Basically, this means, if you understand what domainkeys: means, proceed ahead with either accepting the mail with DK, or rejecting unsigned mail with confidence. But if you don't understand what domainkeys: means, the record behaves like this for you: v=spf1 a mx ptr ?all That means there IS a way to add semantic (feature-wise) extensibility, but only one way. The "default to unknown" rule is a reasonable default that probably applies well to 90%+ of the cases where you might ever want a new non-core feature. I know that I have proposed alternatives to this default in the past, but frankly I have changed my stance on this a bit, after listening to all the feedback on what people really want from extensibility. Semantic or feature-wise extensibility scares people, a bit. It's not 100% clear that we need it built in the spec, so I am starting to think that "default to unknown" is an extremely reasonable rule. Basically, this is a sane default that *DOES* allow for semantic extensibility -- if the sender and receiver both choose to use a new keyword, they can -- but provides a safety valve that everyone understands. I doubt that people really want more feature-wise extensibility than this, but if they do, they can continue on to the next section. 4. A new version tag This is basically the equivalent of publishing a new/enhanced spec, for example: nekodojo.org. IN TXT "v=spf1 a mx ptr ?all" nekodojo.org. IN TXT "v=marid2 a mx ptr on_error=? { magic:happens } -all" But keep in mind that *anyone* can publish new TXT records with a different prefix; they are not necessarily constrained to obey only the v= values that we dole out. For example: nekodojo.org. IN TXT "v=spf1 a mx ptr ?all" nekodojo.org. IN TXT "v=spf1+d +domainkeys:valid ?exists:%{ir}.non-compliant-lists.yahoo.com -domainkeys:unsigned -all" If length of either becomes a problem, we can do what we always do: use redirection for one version or the other (or both). I know the idea of coming out with a new spec bothers people, but I think PHB's presentation at ETC last week underscores the need for this type of upward mobility: the perfect is the enemy of the good. We can produce good protocols and update them after deployment, much faster than we can roll out perfect protocols. (Demonstrated using example of SSL exploits and updates/fixes). Finally, let me close with asking "What kind of extensibility is *enough*?" Mark addresses this more eloquently than I probably can, so let me quote him a bit here. --Mark Lentczner wrote: > > I understand the desire to design a more comprehensive mail policy > format. And I understand the desire that such a format be extensible for > future approaches that are now only contemplated. However, the proposed > XML syntax doesn't achieve this either: While it is true that XML > provides a much richer syntactic framework in which to extend an original > document format, it says nothing about the semantic meaning of such > extensions. > > I maintain that, in the problem space these projects were designed for, > namely authentication of the origin of mail based on the domain name, the > SPF classic syntax does just fine. There is a little room for extension > (defined both syntactically and semantically), just enough to handle a > few future ideas within this problem space. I think Dave Crocker's > posting from earlier today > (http://www.imc.org/ietf-mxcomp/mail-archive/msg02139.html) speaks for > this approach eloquently. When a larger framework for mail policy > emerges, SPF can easily add a modifier for pointing to it. Or perhaps > SPF will have run its course, and the newer framework will simple take > over. Either way is fine. > > Solving the original small, but important slice that all of the original > projects targeted should be our first priority. If we can do that, then > we show the world, and ourselves, that we are capable of tackling more. I interpret this to mean: 1. Some extensibility, especially relating to our target problem, is good. 2. Our spec maybe (probably) will be part of a larger "email policy" framework in the future. 3. Creating the larger email policy is not exactly our job. Creating a vehicle flexible enough to carry such a framework is not exactly our job. Perhaps we COULD do it, but I am concerned that trying to do so might get in the way of other objectives. 4. We all understand that the LMAP problem is but one step on a long road. If our spec becomes outdated, superseded, deprecated, dropped or whatever, it's probably because something better has come along. That doesn't mean we failed. If our spec is superseded in a year or two, and during that time it makes other things possible (like domain-based reputation systems) then we will have succeeded. Thanks, gregc P.S. You know, who says we have to stop working together when our first spec is proposed standard? I think it's entirely possible that we can keep going with other proposals, best practices statements, etc. If not us, who? :) -- Greg Connor From owner-ietf-mxcomp@mail.imc.org Tue Jun 22 02:12:22 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05301 for ; Tue, 22 Jun 2004 02:12:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5M61v74065171; Mon, 21 Jun 2004 23:01:57 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5M61vS0065170; Mon, 21 Jun 2004 23:01:57 -0700 (PDT) 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.9) with ESMTP id i5M61uKA065158 for ; Mon, 21 Jun 2004 23:01:56 -0700 (PDT) (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.34) id 1BceLz-0000KA-1H for ietf-mxcomp@imc.org; Tue, 22 Jun 2004 01:02:03 -0500 To: "IETF MARID WG" References: <81AC085044D04B429F5FB883D94FA1AF42A291@df-fido-msg.exchange.corp.microsoft.com> <1CD00592-BFE8-11D8-BD27-000A95CA7FAE@dbc.mtview.ca.us> <50B2A36E-C00B-11D8-999B-000A95BC6A7E@margaretolson.com> From: wayne Reply-To: "IETF MARID WG" Date: Tue, 22 Jun 2004 01:01:54 -0500 In-Reply-To: <50B2A36E-C00B-11D8-999B-000A95BC6A7E@margaretolson.com> (Margaret Olson's message of "Wed, 16 Jun 2004 23:06:23 -0400") 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 (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: Drive Towards Consensus Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-3.4 required=4.0 tests=AWL,BAYES_00, NEW_DOMAIN_EXTENSIONS autolearn=no version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <50B2A36E-C00B-11D8-999B-000A95BC6A7E@margaretolson.com> Margaret Olson writes: > Here's are my first few examples: > > Example1.com: > example1.com uses two providers: esp.com and personalmail.com . > > Mail originating from personalmail.com is always conversational > (corporate individual mailboxes) and rate limited to 100 messages a > day by personalmail.com > > Mail authored by example1.com originating from esp.com is rate limited > to 4,000 messages a month by esp.com. This mail is bulk mail. > > example1.com is a small b to b service business, as accredited by > accreditors.com > > Note: esp.com and personalmail.com set rate limits on a per customer > basis; these limits are functions of the customer, not functions of > the service that apply in an undifferentiated manner to all > customers. I am taking it as given that esp.com and personalmail.com > can write code to do lookups to check the veracity of their customer's > statements on the MARID record. With SPFv1, this would be expressed as: "v=spf1 include:esp.com include:personalmail.com -all accred=%{d}.accreditors.com" Rate limiting must be done via the MTAs from those other companies and so that is where such information should be obtained. Otherwise, such information is not trustworth. So, you could have an SPF record that says: "v=spf1 include:esp.com include:personalmail.com -all rate=%{d}._rates.esp.com rate=%{d}._r.personalmail.com" The receiver could then do a DNS lookup on example2.com.rates.esp.com, and parse the TXT record, or use information from an A record or something. > Example2.com: > Example2.com is a new customer at both personalmail.com and > esp.com. They have no accreditation or reputation, but each service > rate limits them to 100 messages a day and 400 messages a month, with > a total address count of 100. In other words, they can not correspond > with more than 100 different recipients over the period of a month on > either service. > > Receivers side services can sum up the rate limits to calculate the > total number of recipients and messages that can emanate from > example2.com and decide whether it exceeds their policies on > authenticated but unaccredited senders. See above for example1.com. I think it addresses this issue. > Example3.com: > Example3.com has limited internal controls and has decided to > outsource the whole record management and sending policy enforcement > problem to maridRus.com. They know they send outbound mail through > their inbound servers, but other than that they don't know how they > send. > > maridrus.com starts by publishing a record referencing the mx > records. They need two kinds of feedback; abuse complaints, of which > they want 100%, and channels not listed in the example.com records, of > which they want 1 in 1,000 messages. Abuse complaints is a hard subject. Many people do not want to send abuse complaints to just anyone because spammers will listwash and/or mark your email address as being live. Right now, you have things like registering at abuse.net and spamcop.net. There is also the RP DNS record that can be used. (RP is the "Responsible Person" for the domain, see RFC1183 published in 1990.) Yes, you could also add a "rp=" modifier to the SPF record, but I'm not sure if that is a good idea. As far as getting information on 0.1% of the messages, I'm not sure I see that as being much more useful than tracking 100% of the messages. If you send X million emails, you are likely to get some fraction of that X million DNS lookups anyway. Using an SPF exists: tracking mechanism, you can efficiently track 100% of the invalid messages. You can use SPF right now to do sampling with records such as: example3.com publishes: "v=spf1 mx redirect=%{d}._customer.maridRus.com" on example3.com._customer.maridRus.com, we have: for 0.1% of the time: "v=spf1 exists:CL.%{i}.FR.%{s}.HE.%{h}.null.%{d} ?all" For the remaining time: "v=spf1 ?all" This can be done with a very simple script, right now, with SPF without any changes at all. You don't have to depend on the receiving side SPF implementation understanding and obeying a new extension. Depending on receiving systems will create a huge sampling bias. You can fine tune things so that the tracking SPF record is deployed more at night than during the day because the spam volume tends to stay much more constant, but your server load is lower. You can deploy the tracking SPF record right when you know you are sending a burst of email. You can do all sorts of stuff that is completely under the domain owner's control and you can do it today. It would take me about 15 minutes to create and test a script to do this on my name server. If you want to get fancier, you can hack up a name server to give out the tracking SPF record one out of 1000 times it is requested. You could decide by the domain requesting the SPF record what kind of tracking you want done and have the name server respond accordingly. Could you imagine the email policy description that would do something like "send me information about invalid domain name usage, but only around 08:00 UTC on the first monday of each month, and only if your from domains x, y, or z, or in *.co.uk, but not ebay.co.uk". You can do this today with SPF and a little creativity with your name server. You will almost certainly never be able to do this if you try adding extensions, even if you use XML. Basically, I'm saying that the right place to evaluate these decisions is at the ESP, rather than forcing/depending on all the receivers in the world to do the decision making for you. > Over time, example.com and maridRus.com conclude that esp1.com and > esp2.com, in use by Departments A and B respectively, are authorized > vendors, and that they don't need to duplicate complaint > monitoring. They update the record such that complaints generated on > mail on the esp1 or esp2 channel are handled by the esps, and not > copied to maridRus.com. Ok, so on example3.com._customer.maridRus.com, we change to: "v=spf1 include:esp1.com include:esp2.com ?all" As far as the abuse reports go, I think it is an incredibly bad idea to send email to some arbitrary email address based on information published in a possibly mallicious DNS record. That is one reason that the RP DNS record has never found favor. Moreover, many people do not want to send abuse reports directly to people who may well be spammers or phishers. The only real solution to abuse complaints are register with spamcop.net, abuse.net and/or send email to abuse@example3.com. If example3.com doesn't want to deal with abuse complaints, it can forward those on to someone else. > Example4.com > Example4.com is an esp bounce handling domain. This domain appears > only in MAIL-FROM and never in SUBMITTER or the 2822 from address. "v=spf1 +all 2822.from=never" Now, this isn't a really good solution in either SPF-classic nor SPF-ID, but the syntax is there. > Example5.com: > [This is included because I think that over time it will be useful to > everyone to have receiving as well as sending policies published, and > having another syntax for that side of the policy equation doesn't > make much sense to me] > > Example5.com publishes their acceptance criteria as well their sending > policies. They accept mail from authenticated but unaccredited senders > who do not send more than 100 messages a day or 400 messages a > month. Otherwise, they accept accreditations from accreditors.com > (which presumably has pass-through arrangements with some number of > other accreditors). example5.com requires confirmed opt in from > everyone except senders accredited as financial institutions by > verythoroughandexpensiveaccreditations.com. For financial institutions > they require only prior business relationship, as defined by > verythoroughandexpensiveaccreditations.com > > This is used by esp.com to decide whether or not to send based on the > characteristics of each of their customers, and to report back to > their customers on what they need to do to get their mail delivered. Example5.com publishes "v=spf1 .... incoming-policy=http://www.%d/incoming-policy.xml" I don't see how your paragraph above leverages much, if anything, of the SPF semantics, and it won't fit into a DNS lookup. > My real concern with SPF is the strong suspicion there is a lot we > haven't thought of yet. I'm sure you are right. I don't see anything that causes a need for XML though. -wayne From owner-ietf-mxcomp@mail.imc.org Tue Jun 22 06:51:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28971 for ; Tue, 22 Jun 2004 06:51:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MAZRxb088677; Tue, 22 Jun 2004 03:35:27 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MAZRed088676; Tue, 22 Jun 2004 03:35:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.michaelbrumm.com (h-68-167-225-114.phndaz91.covad.net [68.167.225.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MAZQab088645 for ; Tue, 22 Jun 2004 03:35:26 -0700 (PDT) (envelope-from me@michaelbrumm.com) Received: from devon ([68.167.225.115]) by mail.michaelbrumm.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 22 Jun 2004 10:35:20 +0000 From: "Michael R. Brumm" To: "IETF MARID WG" Subject: RE: Drive Towards Consensus [was Re: On Extensibility in MARID Re cords] Date: Tue, 22 Jun 2004 04:35:28 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <9100976.1087857496@[10.12.1.26]> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-OriginalArrivalTime: 22 Jun 2004 10:35:20.0765 (UTC) FILETIME=[9E27DED0:01C45844] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5MAZRab088668 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Greg Conner wrote: >(One sort of limiting factor about modifiers is that they are considered to >be order-independent and the current spec encourages them to be placed at >the end to make this clear. If I were to propose any modification to the >current spec, it would be to allow modifiers to be placed inline allowing >for the possibility that they might apply/associate the terms appearing >after them, if appropriate. This minor change in the spec should not >affect any current parser or published records and would just be a >clarification...) Out of all the SPF spec changes proposed in the name of "extensibility" in the last couple months, I'd have to say that IMHO, this is probably the most reasonable. I'd vote for it. Michael R. Brumm From owner-ietf-mxcomp@mail.imc.org Tue Jun 22 07:43:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02097 for ; Tue, 22 Jun 2004 07:43:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MBTTKq000461; Tue, 22 Jun 2004 04:29:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MBTTSH000460; Tue, 22 Jun 2004 04:29:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (ntbbs.santronics.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5MBTSmb000445 for ; Tue, 22 Jun 2004 04:29:28 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Tue, 22 Jun 2004 07:33:07 -0400 Received: from ([68.223.169.60]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 1714634829; Tue, 22 Jun 2004 07:33:06 -0400 Message-ID: <001301c4584d$34ea6880$6401a8c0@hdev1> From: "Hector Santos" To: "IETF MARID WG" References: <81AC085044D04B429F5FB883D94FA1AF42A88E@df-fido-msg.exchange.corp.microsoft.com> Subject: Re: FW: Drive Towards Consensus Date: Tue, 22 Jun 2004 07:34:30 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.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: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "wayne" To: "IETF MARID WG" Sent: Monday, June 21, 2004 11:33 PM Subject: Re: FW: Drive Towards Consensus > > Message Types Tied to Individual Mechanisms > > ------- ----- ---- -- ---------- ---------- > > > > Many domains send both non-bulk and bulk mail, generally through very > > different parts of their organization. It may be useful to have > > annotations on an SPF mechanism that describe the kinds of mail they > > send. For example: > > v=spf1 +mx/bulk +indirect:comcast.com/nonbulk -all > > Again, I see this as a case of being "not useful because no one will > believe unverifiable claims." Jim, I agree with Wayne. I would not support MARID domain defined reputation lookup. In my opinion, reputation lookups should be a server-side sysop defined factor because sysops will trust thier setup. Not the remote domain. In our current design implementation, sysop defined reputation lookups is done first before any LMAP method lookup. I would suggest that Accreditation Service Bureaus (ASB) trying to "buy" into the MARID concept by augmenting into the validation scheme, are probably only going to work (feasible) as a "permit" concept. For illustration purposes only, the domain policy can look like this: (whatever format) MARID=v1.0 ... .... +accred:XYZ-###### -all where XYZ-#### is some combo of site code+permit code assigned by the Accreditation Service Bureau to the domain. If the service is also part of or supports this service, then the ##### number would be part of the lookup table pointing to the site. example, ABC-1002-232. If the server is supporting this permit, then ABC would be associated within the server-side lookup table to get the site or lookup method and the entire permit + IP is used to authorize the sender. Ideally, the ASB can use a permit format for its members that also includes other attributes or factors such as: - Type of Member (Honest Direct Marketer? Company? ISP?) - Expiration Date but then again, this info could also be provided as part of the ASB query response packet as it would offer a dynamic or more current ASB member information. The sysop will be the final judge as to whether it trust the ASB to validate its mail sending members. It (or something similar) is the only way I would implement this concept into our package. Not via a sender defined MARID record with no linkage to the server-side/sysop approved usage. > This is true. The current SPF spec says that modifiers are position > independent and therefore you can't use them to mark up individual > mechanisms. > > I think we could change the SPF spec to allow modifiers to be > (optionally) position dependant and not cause problems for the > installed base of SPF records. That is, we could say that things like > "redirect=" and "exp=" are position independent, but allow for new > modifiers, such as "targetrep=" and "mailvolume=" to be position > dependant. So, it would be possible to say "v=spf1 mx mailvolume=bulk..." > and have the mx: mechanism marked up. > > I have checked the SPF records that are listed in the Adoption Roll > and my survey of the 1.3 million email domain names. I could find > none that wouldn't work just fine with this change in the SPF spec. > > I'm not sure I really think it is a good idea to make this change, but > I think it is a valid option. Wayne, adding unknown extensions before the final ALL directive will break (create a SPF_UNKNOWN directive error) our current installed based of Wildcat! SMTP servers with SPF support. Can't force people to upgrade and it wouldn't be fair in general to all current SPF installations that may not agree with an ever evolving "version of the month" SPF format. Wayne, it is too bad in the "product world", 2nd comers always have the advantage of learning and improving upon the originators of ideas. That is just par for the course. Microsoft has no installed base so they have tons of redesign leverage to get it right. SPF does not. You have an installed base that can not be ignored. The worse thing to do here is to continue to kludge SPF with an ongoing effort to match the XML format. So my recommendation for the MARID version of SPF is either a closer format to XML or its basically time to go to V=SPF2 where you can afford new well defined extended SPF format ideas. This will allow us to maintain compatibility for V=SPF1 systems and also support the new V=SPF2 MARID systems. SPF2 will naturally be backward compatible with the extra considerations for extensions, including the rule order/position issues. Anyway, please kind in mind that this on-going MARID extension "challenge" between SPF vs. XML may be all for nothing (or less value). There is no guarantee implementers will support the extensions. Maybe a few simple ones, but not all. Extensions need to make sense and it can't be something that will increase the cost of implementation or adoption. Lets use Reporting for example. Do you honestly believe that sysops will add overhead to the outgoing queues to send reports? If anything, I see this as a possible "commodity" where maybe the IBM's and the Microsoft's will pay a small fee (penny per report) to ISPs. But I sincerely doubt servers will start to send reports all over the place especially when it becomes a popular extension and sender request. If we were to implement it (and probably will) it will only be offered as part of current Report Generator where the sysop defines the report filters, report formats, etc to create scheduled reports for admins and management. We could offer a dynamic reporting system too if that is what the sysop wants. But in general, do you see what's going here? The extensions, especially something like reporting/notification, increases the design complexity and cost for MARID implementation. All this "extra gravy and candy" extension considerations should be secondary to the key goal of MARID - authentication. It should be explored, no doubt, but from the standpoint that its part growth plans for future versions of MARID. But it should not hinder MARID initial adoption. Don't get me wrong. We love to write feature rich software. But if we use this reporting extension idea, we are talking about 1 versus 3 possibly 4 project development efforts: Core MARID implementation: Total projects = 1 o WCSMTP - New Core MARID options Core MARID Plus Report Extension: Total Projects = 3/4 o WCSMTP with more design issues - New Core MARID options - New Report Control Options - New Report storage design o WCREPORT (Report Generator) - more/new report filtering rules - more/new report output rules o WCEVENT - new MARID Report objects for scheduling o WCBILLING - just in case the SYSOP want to bill IBM for the overhead. Never mind the increase beta testing and longer field testing involved. For what, a report extension? Neat idea, but later. Not now. Lets just make sure that it will be possible to add the extension and others. I believe that is essentially the key idea we want. For now, MARID authentication is the key to get it into the market place first. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Tue Jun 22 08:18:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03807 for ; Tue, 22 Jun 2004 08:18:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MC9JW0009104; Tue, 22 Jun 2004 05:09:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MC9JPF009103; Tue, 22 Jun 2004 05:09:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (news.winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5MC9IqF009090 for ; Tue, 22 Jun 2004 05:09:19 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Tue, 22 Jun 2004 08:12:57 -0400 Received: from ([68.223.169.60]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 1717025157; Tue, 22 Jun 2004 08:12:56 -0400 Message-ID: <001701c45852$c5c06760$6401a8c0@hdev1> From: "Hector Santos" To: "Michael R. Brumm" , "IETF MARID WG" References: Subject: Re: Drive Towards Consensus [was Re: On Extensibility in MARID Re cords] Date: Tue, 22 Jun 2004 08:16:37 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.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: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Michael R. Brumm" To: "IETF MARID WG" Sent: Tuesday, June 22, 2004 6:35 AM Subject: RE: Drive Towards Consensus [was Re: On Extensibility in MARID Re cords] > > Greg Conner wrote: > >(One sort of limiting factor about modifiers is that they are considered to > >be order-independent and the current spec encourages them to be placed at > >the end to make this clear. If I were to propose any modification to the > >current spec, it would be to allow modifiers to be placed inline allowing > >for the possibility that they might apply/associate the terms appearing > >after them, if appropriate. This minor change in the spec should not > >affect any current parser or published records and would just be a > >clarification...) > > Out of all the SPF spec changes proposed in the name of "extensibility" in > the last couple months, I'd have to say that IMHO, this is probably the > most reasonable. I'd vote for it. hmmm, Michael, I think it would be better for SPF to being a new version number at this point with the goal of cleanly defining its new needs. A "V=SPF2" or whatever where the client software would have new and clearer functional specifications in the implementation. For V=SPF1, clients need to continue to support the original functional specs in order to support legacy systems. A legacy client can't be broken with a SPF1 record now having unexpected "parts," including having unknown extensions before the ALL directive or trailing the ALL directive.. Trailing Extensions is a lesser issue, but its support is limited to only those clients that expects the trailing extensions. SPF2 clients will be backward compatible and easily handle both. SPF Documentation won't be a mess. It will be clearly separated - a clean slate to move forward with a new "clean" format and more importantly with MARID in mind, without inline kludges and conflicts with directive processing order presented with attempting to add extensions. From a sysop or domain standpoint, if he wants the use the core original SPF features, then he would define a traditional V=SPF1 without any SPF2 features. This will give him the widest support for legacy SPF1 system and new SPF2 systems. But if he needs SPF2 features, then he would use V=SPF2. Period. Lets not confuse the design. After all, using SPF2 features in a SPF1 record will mostly break the rule processing in legacy SPF1 clients anyway so he is limited to SPF2 systems only. I don't see that as an issue. He will understand that the feature set chosen is only doable with old or new systems anyway. A neat straight forward "Feature/Version Table" will illustrate this to the sysop and help him decide what's he needs. Also, with the new SPF2 specification, it could include a possible provision for domains to defined both records if so desired. SPF1 clients will only read SPF1 and SPF2 clients will read the SPF2 record. The issues regarding duplicity or large record requirements will have to be something the sysops needs to weight. I see this as a now issue. From my standpoint, this will make it easier for me to implement, easily to explain and document for sysop/customers to decide. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Tue Jun 22 11:09:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14973 for ; Tue, 22 Jun 2004 11:09:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MEoGtJ042531; Tue, 22 Jun 2004 07:50:16 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MEoG2Y042530; Tue, 22 Jun 2004 07:50:16 -0700 (PDT) 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.9) with ESMTP id i5MEoFMQ042515 for ; Tue, 22 Jun 2004 07:50:16 -0700 (PDT) (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 CB4E81334E8 for ; Tue, 22 Jun 2004 10:50:13 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 6A453605; Tue, 22 Jun 2004 10:50:13 -0400 (EDT) Date: Tue, 22 Jun 2004 10:50:13 -0400 From: Meng Weng Wong To: ietf-mxcomp@imc.org Subject: Re: FW: Drive Towards Consensus Message-ID: <20040622145013.GD13225@dumbo.pobox.com> References: <81AC085044D04B429F5FB883D94FA1AF42A88E@df-fido-msg.exchange.corp.microsoft.com> <001301c4584d$34ea6880$6401a8c0@hdev1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001301c4584d$34ea6880$6401a8c0@hdev1> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Jun 22, 2004 at 07:34:30AM -0400, Hector Santos wrote: | > > Message Types Tied to Individual Mechanisms | > > ------- ----- ---- -- ---------- ---------- | > > | > > Many domains send both non-bulk and bulk mail, generally through very | > > different parts of their organization. It may be useful to have | > > annotations on an SPF mechanism that describe the kinds of mail they | > > send. For example: | > > v=spf1 +mx/bulk +indirect:comcast.com/nonbulk -all | > | > Again, I see this as a case of being "not useful because no one will | > believe unverifiable claims." | | Jim, I agree with Wayne. I would not support MARID domain defined | reputation lookup. In my opinion, reputation lookups should be a | server-side sysop defined factor because sysops will trust thier setup. Not | the remote domain. In our current design implementation, sysop defined | reputation lookups is done first before any LMAP method lookup. | | I would suggest that Accreditation Service Bureaus (ASB) trying to "buy" | into the MARID concept by augmenting into the validation scheme, are | probably only going to work (feasible) as a "permit" concept. For | illustration purposes only, the domain policy can look like this: | | (whatever format) MARID=v1.0 ... .... +accred:XYZ-###### -all I agree that assertions of rate limiting, etc. should be made by accreditation agencies, not by the sender domains. I say this based on two principles: agency and matching. Agency means that if the assertions are made by the accreditor, a self-policing dynamic keeps both parties honest. The domain wants to do the right thing or lose its accreditation; the accreditor wants to make sure the domain is living up to its standards or it loses its reputation. Matching means that if the assertions are made by the sender domain, without preexisting trust, there is no way for a reputation services to evaluate those assertions. At http://www.isipp.com/codelist.php we see that accreditors have already thought through these issues and have created exactly the kind of data structure that we allude to above. From owner-ietf-mxcomp@mail.imc.org Tue Jun 22 11:09:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14975 for ; Tue, 22 Jun 2004 11:09:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MEuKZD043556; Tue, 22 Jun 2004 07:56:20 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MEuKpo043555; Tue, 22 Jun 2004 07:56:20 -0700 (PDT) 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.9) with ESMTP id i5MEuJgX043548 for ; Tue, 22 Jun 2004 07:56:19 -0700 (PDT) (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 i5MEuKVq012877; Tue, 22 Jun 2004 07:56:20 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 22 Jun 2004 07:56:20 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Ted Hardie'" , Margaret Olson , Jonathan Gardner Cc: IETF MARID WG Subject: RE: Drive Towards Consensus [was Re: On Extensibility in MARID Re cords] Date: Tue, 22 Jun 2004 07:56:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > The extensions of "accreditation, reputation, and rate limiting" which > Margaret describe fundamentally involve a 3rd party (since > rate limiting > only looks really useful if audited). If that is correct, > the question > becomes: are these third party assertions something that need to be > tied to the individual MARID assertions, are they an independent > pointer within the record, or are they out of scope? As a matter of fact, I have made a proposal in this space that does not require audit, except during the manufacture of trustworthy hardware. ObDisc: Patent claims on the above are pending, no license is granted, etc. > Let's assume for now that at least the pointers to them are in scope. > > Imagine for a moment that MARID includes an extension that > says: these > other people also wish to make assertions about me (with the > implication > that the domain knows about it and is willing to point to it). Is it > possible to extend MARID to do that? Sure. Give those records a > similar syntax > to MARID and it becomes a set of assertions made by two or > more different > parties about the same domain's infrastructure. Silly states > then require > meta-reputation to resolve, but that may not be a big deal. I beleive that you will need meta-reputation here for any interpretation. But that is quite easy to synthesize, you simply observe your own mail and complaints from users about spam. > Is it also possible to do that such that it could be attached to other > assertions, as a generic mechanism for per-attribute > reputation/accreditation/certification? I am less worried about the interpretation side as the collection side. I don't want MARID to help interpret data, but I do need it to tell me that data exists. Any positive accreditation service that requires input from the subject is going to be incomplete. Unless you assume that one company is going to have a monopoly here you have to be able to link to the accreditor. > But the usefulness of either goes back to the issue raised by > Roy Badami--what > does this mean in the context of the extension processing? Since you cannot be required to provide accreditation data a processor can always choose to ignore them. > The WG discussions so far seem to have gone down two processing paths: > one in which MARID processing iterates through separate > assertions until > one assertion explicitly allows, disallows or marks unknown the > message traffic; > the other in which all the assertions are taken together to > create three sets: > allowed, disallowed, not known. In the first approach, new > assertions can > easily be defined to have a null affect. I would term these 'authentic', 'forgery' and 'indeterminate'. I am not so keen on the list approach since it does not allow the semantic 'all messages come from this set of IP addresses AND are signed'. > An alternate approach there is to > specify that > modifiers of a certain type can be ignored such that the base > processing > of the assertions can proceed if they are not understood. > That would mean that > the syntax of the "external pointer" could be left vague > right now, as long > as it is known to be of that type. I think this is the best approach. I view the IP address info as being authentication credentials, the accreditation data is attributes that MAY be used in the authentication process at the discretion of the recipient. > A > common, practical approach at that point is to limit external > assertions > to ones in which "pretend it wasn't there" processing does no > harm ( I think that we have no choice on this question. Publishing MARID rules and processing MARID rules are both optional. In SAML I used a three basket approach, an assertion consists of a set of statements, a set of conditions and a set of advice. If a condition is not understood then the whole assertion must be discarded. But SAML could do that because it was a completely new application and there was no existing deployed base. > Without stepping on the toes of the original question asked by the > chairs, I'd be interested in hearing whether anyone believes MARID > will need the "set construction" mechanism, or whether it can > go forward with the iterative processing method. That may > tell us something about the extension mechanism choices and > what our core needs for syntax are. I think it would be useful to introduce a slightly more expressive authentication bucket in the XML syntax, specifically: At present we have a list [A, B, C] Which is A.B.C I would like a set of lists {[A, B, C], [D, E], [F]} Which is A.B.C /\ D.E /\ F Where . is defined as: T.x = T, F.x = F, U.x = x And T /\ x = T, x /\ T = T, U /\ U = U, U /\ F = U, F /\ U = U, F /\ F = F In other words the SPF precedence rules apply within each list but the lists themselves are alternatives and the best alternative wins. From owner-ietf-mxcomp@mail.imc.org Tue Jun 22 11:11:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15105 for ; Tue, 22 Jun 2004 11:11:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MExAKg044057; Tue, 22 Jun 2004 07:59:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MExA8h044056; Tue, 22 Jun 2004 07:59:10 -0700 (PDT) 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.9) with ESMTP id i5MEx9e2044047 for ; Tue, 22 Jun 2004 07:59:09 -0700 (PDT) (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 i5MEx7pa014433; Tue, 22 Jun 2004 07:59:07 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 22 Jun 2004 07:59:07 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Roy Badami'" , Margaret Olson Cc: Jonathan Gardner , IETF MARID WG Subject: RE: Drive Towards Consensus [was Re: On Extensibility in MARID Re cords] Date: Tue, 22 Jun 2004 07:59:05 -0700 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: > >>>>> "Margaret" == Margaret Olson > writes: > > Margaret> The rate limiting needs to occur on the sending side, > Margaret> but the receiver needs to know what it is. > > But there's no need for the sender to publish the rate limiting > information, because there's little reason for you to trust them. The trust issue is not relevant. The sender is publishing a CLAIM. It is for the receiver to validate the claim and decide whether/how to act on it. > Obviously the ISP's rate limiting policy would have to specify the IP > addresses that they're responsible for (they can't rate limit mail you > send out via another source) but this is all information that should > be published by the ISP, not the sender. The sender has to inform the recipient of the existence of the data. > Though, as I said before, I'd like to see a move towards (return to) > sites originating (and being responsible for) their own mail rather > than relaying through their ISP... The anti-spam zealots have done for that plan. Port25 is mostly blocked. From owner-ietf-mxcomp@mail.imc.org Tue Jun 22 11:17:33 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15560 for ; Tue, 22 Jun 2004 11:17:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MF3Pqh044734; Tue, 22 Jun 2004 08:03:25 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MF3Phs044733; Tue, 22 Jun 2004 08:03:25 -0700 (PDT) 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.9) with ESMTP id i5MF3OOC044725 for ; Tue, 22 Jun 2004 08:03:24 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i5MF3RVa016558 for ; Tue, 22 Jun 2004 08:03:27 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 22 Jun 2004 08:03:27 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'IETF MARID WG'" Subject: RE: Drive Towards Consensus Date: Tue, 22 Jun 2004 08:03:26 -0700 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: > use the modifier: smime=always > > > * express the message digest of the signing certificate > > use the modifier: smime.certdigest= > > > * express the algorithm supported. > > use the modifier: smime.alg=rsa > > > Or, just use: smime-info= Which illustrates my point, you need structures and so you have cobbled together an ad-hoc internal syntax to meet this need. With XML I can simply define the data structure and the compiler will construct the parser for me. What you are trying to do here is to constrain the problem to the size of your tool. That is not a very good approach when you are trying to deal with a problem with a legacy system. From owner-ietf-mxcomp@mail.imc.org Tue Jun 22 11:21:49 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15789 for ; Tue, 22 Jun 2004 11:21:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MFAI58046093; Tue, 22 Jun 2004 08:10:18 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MFAIPD046092; Tue, 22 Jun 2004 08:10:18 -0700 (PDT) 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.9) with ESMTP id i5MFAHM3046086 for ; Tue, 22 Jun 2004 08:10:17 -0700 (PDT) (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 1BBE113348E for ; Tue, 22 Jun 2004 11:10:17 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id E052363A; Tue, 22 Jun 2004 11:10:17 -0400 (EDT) Date: Tue, 22 Jun 2004 11:10:17 -0400 From: Meng Weng Wong To: ietf-mxcomp@imc.org Subject: On Language Message-ID: <20040622151017.GE13225@dumbo.pobox.com> References: <20040619212932.GC30711@obscurity.org> <0E174519-C3C2-11D8-AA48-000393A56BB6@glyphic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I would like to request that participants in this working group avoid the use of unspecific language where possible; they lead to confusion. For instance, the "you" intended by the author of a message may or may not match the "you" interpreted by its audience. On Mon, Jun 21, 2004 at 07:37:26PM -0400, Margaret Olson wrote: | Yes, the desire is to have mail rate information in the MARID record. I | apologize for not being clearer about that. Several people have noticed | that you don't necessarily trust the record author - but that is why | you accredit both the sender and any channels used with indirect | pointers. Please correct me if I'm wrong: in the above paragraph, I take the first "you" to mean a receiver with no preexisting relationship with a sender domain. But the second "you" seems to mean "the system in general should provide an architecture in which it is possible for accreditation services to". From owner-ietf-mxcomp@mail.imc.org Tue Jun 22 11:44:22 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17646 for ; Tue, 22 Jun 2004 11:44:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MFX4iS050616; Tue, 22 Jun 2004 08:33:04 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MFX4bY050615; Tue, 22 Jun 2004 08:33:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [64.139.47.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MFX4Xq050604 for ; Tue, 22 Jun 2004 08:33:04 -0700 (PDT) (envelope-from gconnor@nekodojo.org) Received: by neko-base.nekodojo.org (Postfix, from userid 500) id CCFEF1D65C; Tue, 22 Jun 2004 08:33:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by neko-base.nekodojo.org (Postfix) with ESMTP id CC0401D656; Tue, 22 Jun 2004 08:33:06 -0700 (PDT) Date: Tue, 22 Jun 2004 08:33:06 -0700 (PDT) From: Greg Connor To: "Hallam-Baker, Phillip" Cc: "'IETF MARID WG'" Subject: RE: Drive Towards Consensus In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 22 Jun 2004, Hallam-Baker, Phillip wrote: > > What you are trying to do here is to constrain the problem to the size of > your tool. That is not a very good approach when you are trying to deal with > a problem with a legacy system. By "a problem" you mean "a problem other than the one the tool was designed to solve," is that correct? :) Just trying to put the question in context of "how much and what kind of extensibility do you want?" -- Greg Connor gconnor@nekodojo.org Everyone says that having power is a great responsibility. This is a lot of bunk. Responsibility is when someone can blame you if something goes wrong. When you have power you are surrounded by people whose job it is to take the blame for your mistakes. If they're smart, that is. -- Cerebus, "On Governing" From owner-ietf-mxcomp@mail.imc.org Tue Jun 22 11:44:33 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17664 for ; Tue, 22 Jun 2004 11:44:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MFVhvq050335; Tue, 22 Jun 2004 08:31:43 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MFVhpi050334; Tue, 22 Jun 2004 08:31:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MFVhrR050327 for ; Tue, 22 Jun 2004 08:31:43 -0700 (PDT) (envelope-from jimlyon@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 22 Jun 2004 08:31:46 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 22 Jun 2004 08:31:46 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 22 Jun 2004 08:31:45 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7345.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: FW: Drive Towards Consensus Date: Tue, 22 Jun 2004 08:31:41 -0700 Message-ID: <81AC085044D04B429F5FB883D94FA1AF42ACD8@df-fido-msg.exchange.corp.microsoft.com> Thread-Topic: FW: Drive Towards Consensus thread-index: AcRYTW44Nwbufr97SCeALCQccYVksAAH0BmA From: "Jim Lyon" To: "IETF MARID WG" X-OriginalArrivalTime: 22 Jun 2004 15:31:45.0741 (UTC) FILETIME=[06D3D7D0:01C4586E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5MFVhrR050328 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Wayne writes: > I think we could change the SPF spec to allow modifiers to be > (optionally) position dependant and not cause problems for the > installed base of SPF records. That is, we could say that things like > "redirect=" and "exp=" are position independent, but allow for new > modifiers, such as "targetrep=" and "mailvolume=" to be position > dependant. So, it would be possible to say "v=spf1 mx mailvolume=bulk..." > and have the mx: mechanism marked up. I think that direction has some promise. I'll need to think further. (But don't expect much from me for two weeks -- I'll be tramping around Scotland, with only sporadic connectivity and attention. On the other hand, Hector Santos writes: > Wayne, adding unknown extensions before the final ALL directive will break > (create a SPF_UNKNOWN directive error) our current installed based of > Wildcat! SMTP servers with SPF support. Can't force people to upgrade and > it wouldn't be fair in general to all current SPF installations that may not > agree with an ever evolving "version of the month" SPF format. Which means that Wildcat, although deployed, isn't really SPF compliant. The SPF spec requires that unknown modifiers be ignored regardless of position. Regardless of the outcome of this discussion, I'd suggest he fix that bug in the next release. -- jimbo From owner-ietf-mxcomp@mail.imc.org Tue Jun 22 11:48:48 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17804 for ; Tue, 22 Jun 2004 11:48:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MFcPsG051709; Tue, 22 Jun 2004 08:38:25 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MFcPnD051708; Tue, 22 Jun 2004 08:38:25 -0700 (PDT) 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.9) with ESMTP id i5MFcOPd051702 for ; Tue, 22 Jun 2004 08:38:24 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i5MFcRw8000289 for ; Tue, 22 Jun 2004 08:38:27 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 22 Jun 2004 08:38:27 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: IETF MARID WG Subject: Why XML Date: Tue, 22 Jun 2004 08:38:25 -0700 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: All, I think that people need to see some examples of modern programming that XML supports, these examples are in C#, but the metadata extensions in the latest version of Java allow the same effect to be achieved: static XmlSerializer keyInfoReader; // Construct the serializer class from KeyInfoType keyInfoReader = new XmlSerializer (typeof (KeyInfoType)); // Parse a KeyInfoType structure using the generated parser KeyInfoType keyInfoData = (KeyInfoType) keyInfoReader.Deserialize (stringStream); What is going on here is that XmlSerializer is reading the metadata that defines the KeyInfoType structure, generating code to parse that structure, and running it through the parser to generate the class. This could be done at compile time since the methods are all static. The KeyInfoType class is annotated with metadata as follows: [System.Xml.Serialization.XmlTypeAttribute(Namespace="http://www.w3.org/2000 /09/xmldsig#")] [System.Xml.Serialization.XmlRootAttribute("KeyInfo", Namespace="http://www.w3.org/2000/09/xmldsig#", IsNullable=false)] public class KeyInfoType { /// [System.Xml.Serialization.XmlElementAttribute("KeyName", typeof(string))] public string [] KeyName; [System.Xml.Serialization.XmlElementAttribute("KeyValue", typeof(KeyValueType))] public KeyValueType [] KeyValue; ... } This is considerably more verbose than it need be as this code was actually generated directly from the schema using another tool. A change to the schema can be accomodated without the need to change any of the support code. I use the same code to parse XML data structures, save them to disk etc in about six different programs. This is not a new trick of course. People have done the same thing in LISP for years, but that is not quite so interesting as there is only one data structure in LISP. The point is that you can only do this sort of thing if you have a regular syntax for the data structure. ASN.1 and XML are regular enough to make this possible. I cannot write an SpfSerializer class, nor can anyone else. The rules for parsing new data structures are unknowable. The use of metadata is not an obscure programming idiom, it is the standard way to code in the modern programming frameworks. Writing flat code, without making use of metadata is in comparison like writing code in assembly language. Sure I can do it, I used to write video games in Z80 and 6502 assembler back in high school. But I would not write an MUA in assembler and these days I would not write any sort of code without metadata capabilities. The angle bracket stuff is completely irrelevant as far as I and most other XML coders are concerned. It is like x86 assembly code, I know it is there but I don't want to see it. Phill From owner-ietf-mxcomp@mail.imc.org Tue Jun 22 13:15:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28360 for ; Tue, 22 Jun 2004 13:15:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MH7MiA069261; Tue, 22 Jun 2004 10:07:22 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MH7MYW069260; Tue, 22 Jun 2004 10:07:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from hoster907.com (ns1.hoster907.com [66.211.137.27]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5MH7L2T069253 for ; Tue, 22 Jun 2004 10:07:21 -0700 (PDT) (envelope-from margaret@margaretolson.com) Received: (qmail 20505 invoked from network); 22 Jun 2004 16:00:26 -0000 X-Relay-Users: margaret.user X-Abuse: Send abuse reports to: abuse@suresupport.com Received: from unknown (HELO ?192.168.254.158?) (208.198.98.2) by ns1.hoster907.com with SMTP; 22 Jun 2004 16:00:26 -0000 In-Reply-To: <20040622151017.GE13225@dumbo.pobox.com> References: <20040619212932.GC30711@obscurity.org> <0E174519-C3C2-11D8-AA48-000393A56BB6@glyphic.com> <20040622151017.GE13225@dumbo.pobox.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1C1601CC-C465-11D8-B362-000A95BC6A7E@margaretolson.com> Content-Transfer-Encoding: 7bit Cc: ietf-mxcomp@imc.org From: Margaret Olson Subject: Re: On Language Date: Tue, 22 Jun 2004 11:59:14 -0400 To: Meng Weng Wong X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jun 22, 2004, at 11:10 AM, Meng Weng Wong wrote: > > I would like to request that participants in this working > group avoid the use of unspecific language where possible; > they lead to confusion. > > For instance, the "you" intended by the author of a message > may or may not match the "you" interpreted by its audience. > > On Mon, Jun 21, 2004 at 07:37:26PM -0400, Margaret Olson wrote: > | Yes, the desire is to have mail rate information in the MARID > record. I > | apologize for not being clearer about that. Several people have > noticed > | that you don't necessarily trust the record author - but that is why > | you accredit both the sender and any channels used with indirect > | pointers. > > Please correct me if I'm wrong: in the above paragraph, I > take the first "you" to mean a receiver with no preexisting > relationship with a sender domain. > > But the second "you" seems to mean "the system in general > should provide an architecture in which it is possible for > accreditation services to". > Your interpretations are correct. My apologies for the sloppiness - I wrote that message quickly and it shows. Margaret. From owner-ietf-mxcomp@mail.imc.org Tue Jun 22 13:18:13 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29233 for ; Tue, 22 Jun 2004 13:18:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MHDAEL071132; Tue, 22 Jun 2004 10:13:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MHDAwJ071130; Tue, 22 Jun 2004 10:13:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MHD86l071123 for ; Tue, 22 Jun 2004 10:13:09 -0700 (PDT) (envelope-from roy+dated+1090516389.9dbd4b@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i5MHDBRC025888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 22 Jun 2004 17:13:11 GMT (envelope-from roy+dated+1090516389.9dbd4b@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5MHDAsY057845 for ; Tue, 22 Jun 2004 18:13:10 +0100 (BST) (envelope-from roy+dated+1090516389.9dbd4b@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5MHDA44057844 for ietf-mxcomp@imc.org; Tue, 22 Jun 2004 18:13:10 +0100 (BST) (envelope-from roy+dated+1090516389.9dbd4b@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Tue, 22 Jun 2004 18:13:09 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16600.26788.774238.914922@giles.gnomon.org.uk> Date: Tue, 22 Jun 2004 18:13:08 +0100 To: "Hallam-Baker, Phillip" Cc: IETF MARID WG Subject: Why XML In-Reply-To: References: X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Hallam-Baker," == Hallam-Baker, Phillip writes: Hallam-Baker,> The angle bracket stuff is completely irrelevant as Hallam-Baker,> far as I and most other XML coders are Hallam-Baker,> concerned. It is like x86 assembly code, I know it Hallam-Baker,> is there but I don't want to see it. However the angle bracket stuff is what most mail administrators will find themselves staring at when debugging mail deliverability problems. That's my main reason for prefering SPF syntax; I just find it easier to read (visually less cluttered) than XML, and its simpler (less flexible) syntax is easier to parse visually, precisely because of the lack of nested structure. Am I overestimating the extent to which MARID records will end up being written and read by hand by mail admins...? -roy From owner-ietf-mxcomp@mail.imc.org Tue Jun 22 13:26:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01437 for ; Tue, 22 Jun 2004 13:26:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MHKOvp073313; Tue, 22 Jun 2004 10:20:24 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MHKOnt073312; Tue, 22 Jun 2004 10:20:24 -0700 (PDT) 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.9) with ESMTP id i5MHKN8K073299 for ; Tue, 22 Jun 2004 10:20:24 -0700 (PDT) (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 i5MHKPsF011713; Tue, 22 Jun 2004 10:20:25 -0700 (PDT) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 22 Jun 2004 10:20:25 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Roy Badami'" , "Hallam-Baker, Phillip" Cc: IETF MARID WG Subject: RE: Why XML Date: Tue, 22 Jun 2004 10:20:16 -0700 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: > However the angle bracket stuff is what most mail administrators will > find themselves staring at when debugging mail deliverability > problems. > > That's my main reason for prefering SPF syntax; I just find it easier > to read (visually less cluttered) than XML, and its simpler (less > flexible) syntax is easier to parse visually, precisely because of the > lack of nested structure. > > Am I overestimating the extent to which MARID records will end up > being written and read by hand by mail admins...? Take a look at the records being discussed on this list. I don't have a clue what they mean unless I sit with the spec and work them out, I just don't. Sure they might look intuitive if you think that "ps -aux" is a model of clarity in command line syntax, but even a UNIX sysadmin can't say what the effect of that command is without knowing which version of UNIX is running. From owner-ietf-mxcomp@mail.imc.org Tue Jun 22 13:27:28 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01702 for ; Tue, 22 Jun 2004 13:27:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MHKDq8073275; Tue, 22 Jun 2004 10:20:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MHKDr7073274; Tue, 22 Jun 2004 10:20:13 -0700 (PDT) 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.9) with ESMTP id i5MHKC0i073244 for ; Tue, 22 Jun 2004 10:20:13 -0700 (PDT) (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 i5MHK6hv003387 for ietf-mxcomp@imc.org; Tue, 22 Jun 2004 19:20:06 +0200 Received: from danisch.de (localhost [127.0.0.1]) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-5) with ESMTP id i5MHJSTf029643 for ; Tue, 22 Jun 2004 19:19:28 +0200 Message-ID: <40D86A20.6030701@danisch.de> Date: Tue, 22 Jun 2004 19:19:28 +0200 From: Hadmut Danisch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040528 Debian/1.6-7 X-Accept-Language: de-de MIME-Version: 1.0 To: IETF MARID WG Subject: Re: Why XML References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hallam-Baker, Phillip wrote: [ statement voting for XML ] Folks, I fully agree with Phil. There are pretty good reasons to choose XML or ASN.1/DER. If you have a parser for XML or ASN.1, it will be able to parse *any* version of records, even future ones. Keep in mind that you are not designing some application for LAN usage or for those who might want to give it a try. This is about upgrading the world wide e-mail system. This is a single-shot adventure. You won't get a second chance. With ASN.1 or XML you can rely on the fact, that the implementations can at least talk to each other even if written for different versions of the data structures (after all, that's what ASN.1 and XML have been designed for, and there are good reasons why other protocols make use of it). Application writers have learned that using such a structured data language makes programs better, more reliable, more secure, easier to extend, and improves the compatibility between different versions. Why ignore this? I am working on network security and sender authentication since around 1992 and was discussing about e-mail sender authorization in context of RMX for about two years now. Believe me, you will never be able to foresee everything what will come. None of you should believe that he/she is able to design the final protocol solving everything. Be prepared to fail. What would you do if, maybe a year after the world wide rollout, you suddenly realize that there is something you didn't take into consideration? Maybe a new kind of attack? New spamming technologies? New laws? New technology? Maybe a sender identified by the mobile phone number instead of IP address? Any weird method of time slots? Maybe topological authentication? Or maybe a completely new directory service? Who knows? What makes you know that we won't want to have a jpeg portrait image as a method of authentication/authorization in three years? Or any magic device allowing us to send e-mail from every internet cafe authenticated? What will you do then? Tell the world "Sorry, we made a mistake. We have to reinstall the world wide mail system. Please upgrade all world's MTAs to the new version synchronously next wednesday at exactly 11:30 am"? The RMX syntax was a first approach, and SPF is not significantly more modern. These syntax definitions are state of the art - the art of about 10-20 years ago. We shouldn't ignore the progress of computer science and programming technology. How many changes and extensions will SPF syntax take? Isn't every change and extension an odd hack? What makes you rely on the fact that any new extension can be read by any older version? With such a proprietary syntax as SPF, every implementor will write his own parser/interpreter. I guess that a new syntax version will break 5-30% of implementations. In contrast, XML and ASN.1 parsers exist and are proven and tested. You can automatically generate the parsers from the grammar, thus eliminating lots of bugs and security flaws. And as I stated earlier, don't be limited to today's point of view and today's technology. Tomorrow there will be another killer application again requiring protection against fraud and forgery. Maybe voice-over-ip. Maybe instant messaging. What would you do? Start a new discussion for two years and design a new proprietary syntax? Keep in mind that this is a one-shot operation for upgrading a world wide communication network which will only succeed if the world wide communication remains working and compatible without major problems. This requires an extensible, orthogonal and precise definition and a robust and proven method to describe data structures, where parsers can be generated automatically and libraries are ready for use instead of reinventing another wheel. XML parsers exist for most modern programming languages and make it easy to write e.g. a graphical frontend. The art of programming is abstraction between contents and representation. XML and ASN.1 do this all. SPF doesn't. Don't make the mistake to take your own hacking (in)capabilties as a design criterion for a world wide communication protocol. Parsing SPF is a hack. This makes it look easy and comfortable in some people's eyes. But that's wrong. We are not here to design a protocol easy to parse with perl regular expressions. And, by the way, sorry, but can't resist, asking for "who can give an example SPF isn't able to cope with, otherwise it must be good" is not exactly the art of designing good protocols. Or in other words: I vote for ASN.1 or XML (or zipped XML). regards Hadmut From owner-ietf-mxcomp@mail.imc.org Tue Jun 22 13:33:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03304 for ; Tue, 22 Jun 2004 13:33:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MHR4Wx074465; Tue, 22 Jun 2004 10:27:04 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MHR46b074464; Tue, 22 Jun 2004 10:27:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MHR3ae074440 for ; Tue, 22 Jun 2004 10:27:03 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 (unknown [216.191.52.74]) by mail.greatgulfhomes.com (Postfix) with SMTP id 7970036666E; Tue, 22 Jun 2004 13:33:51 -0400 (EDT) From: To: "'Roy Badami'" , "'Hallam-Baker, Phillip'" Cc: "'IETF MARID WG'" Subject: RE: Why XML Date: Tue, 22 Jun 2004 13:27:29 -0400 Message-ID: <012001c4587e$326acc40$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <16600.26788.774238.914922@giles.gnomon.org.uk> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I think you are correct Roy, I have, and will continue to manually code my SPF records. And if I wanted SPF XML records, I would have to do them by hand also (I don't have any XML encoding software, not to say that there won't be any free ones, but I have far better things to spend my software budget on right now). Terry Fielder Manager Software Development and Deployment Great Gulf Homes / Ashton Woods Homes terry@greatgulfhomes.com Fax: (416) 441-9085 > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Roy Badami > Sent: Tuesday, June 22, 2004 1:13 PM > To: Hallam-Baker, Phillip > Cc: IETF MARID WG > Subject: Why XML > > > > >>>>> "Hallam-Baker," == Hallam-Baker, Phillip > writes: > > Hallam-Baker,> The angle bracket stuff is completely irrelevant as > Hallam-Baker,> far as I and most other XML coders are > Hallam-Baker,> concerned. It is like x86 assembly code, I know it > Hallam-Baker,> is there but I don't want to see it. > > However the angle bracket stuff is what most mail administrators will > find themselves staring at when debugging mail deliverability > problems. > > That's my main reason for prefering SPF syntax; I just find it easier > to read (visually less cluttered) than XML, and its simpler (less > flexible) syntax is easier to parse visually, precisely because of the > lack of nested structure. > > Am I overestimating the extent to which MARID records will end up > being written and read by hand by mail admins...? > > -roy > From owner-ietf-mxcomp@mail.imc.org Tue Jun 22 13:55:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07837 for ; Tue, 22 Jun 2004 13:55:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MHn7iB078544; Tue, 22 Jun 2004 10:49:07 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MHn7WG078543; Tue, 22 Jun 2004 10:49:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MHn6eT078537 for ; Tue, 22 Jun 2004 10:49:07 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 (unknown [216.191.52.74]) by mail.greatgulfhomes.com (Postfix) with SMTP id 45F9A3664CF; Tue, 22 Jun 2004 13:55:57 -0400 (EDT) From: To: "'Hadmut Danisch'" , "'IETF MARID WG'" , Subject: RE: Why XML Date: Tue, 22 Jun 2004 13:49:35 -0400 Message-ID: <013001c45881$488c5b80$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <40D86A20.6030701@danisch.de> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Um, how does the complexity of XML improve security. I can think of examples where XML enhancements CAUSED exploits, and there are implementations where the XML implementation poses denial of service exploit by sheer processing power needed for a full XML parser. How is this a "single shot" at upgrading email? The SMTP protocol has been evolving for a VERY long time. Interesting arguments on extensibility. All valid. Also all valid for SPFv1 due to the fact that SPFv1 is extensible. Terry Fielder Manager Software Development and Deployment Great Gulf Homes / Ashton Woods Homes terry@greatgulfhomes.com Fax: (416) 441-9085 > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Hadmut Danisch > Sent: Tuesday, June 22, 2004 1:19 PM > To: IETF MARID WG > Subject: Re: Why XML > > > > Hallam-Baker, Phillip wrote: > [ statement voting for XML ] > > > Folks, > > I fully agree with Phil. There are pretty good reasons to choose > XML or ASN.1/DER. If you have a parser for XML or ASN.1, it will > be able to parse *any* version of records, even future ones. > > Keep in mind that you are not designing some application > for LAN usage or for those who might want to give it a try. > > This is about upgrading the world wide e-mail system. This > is a single-shot adventure. You won't get a second chance. > > With ASN.1 or XML you can rely on the fact, that the > implementations can at least talk to each other even if > written for different versions of the data structures (after > all, that's what ASN.1 and XML have been designed for, > and there are good reasons why other protocols make > use of it). Application writers have learned that using > such a structured data language makes programs > better, more reliable, more secure, easier to extend, > and improves the compatibility between different versions. > > Why ignore this? > > I am working on network security and sender authentication > since around 1992 and was discussing about e-mail sender authorization > in context of RMX for about two years now. Believe me, you will never > be able to foresee everything what will come. > None of you should believe that he/she is able to design the > final protocol solving everything. Be > prepared to fail. What would you do if, maybe a year after the world > wide rollout, you suddenly realize that there is something you didn't > take into consideration? Maybe a new kind of attack? New spamming > technologies? New laws? New technology? Maybe a sender identified > by the mobile phone number instead of IP address? Any weird method > of time slots? Maybe topological authentication? Or maybe a completely > new directory service? Who knows? What makes you know that we > won't want to have a jpeg portrait image as a method of > authentication/authorization in three years? Or any magic device > allowing us to send e-mail from every internet cafe authenticated? > > What will you do then? Tell the world "Sorry, we made a mistake. > We have to reinstall the world wide mail system. Please upgrade all > world's MTAs to the new version synchronously next > wednesday at exactly 11:30 am"? > > > The RMX syntax was a first approach, and SPF is not > significantly more modern. These syntax definitions are state of the > art - the art of about 10-20 years ago. We shouldn't ignore the > progress of computer science and programming technology. > > How many changes and extensions will SPF syntax take? > Isn't every change and extension an odd hack? What makes > you rely on the fact that any new extension can be read by > any older version? With such a proprietary syntax as SPF, > every implementor will write his own parser/interpreter. I guess > that a new syntax version will break 5-30% of implementations. > In contrast, XML and ASN.1 parsers exist and are proven > and tested. You can automatically generate the parsers from > the grammar, thus eliminating lots of bugs and security flaws. > > > And as I stated earlier, don't be limited to today's point of > view and > today's > technology. Tomorrow there will be another killer application again > requiring protection against fraud and forgery. Maybe voice-over-ip. > Maybe instant messaging. What would you do? Start a new discussion > for two years and design a new proprietary syntax? > > Keep in mind that this is a one-shot operation for upgrading > a world wide communication network which will only succeed if > the world wide communication remains working and compatible > without major problems. This requires an extensible, orthogonal > and precise definition and a robust and proven method to > describe data structures, where parsers can be generated automatically > and libraries are ready for use instead of reinventing another wheel. > XML parsers exist for most modern programming languages and make > it easy to write e.g. a graphical frontend. The art of programming > is abstraction between contents and representation. XML and ASN.1 > do this all. SPF doesn't. Don't make the mistake to take your own > hacking (in)capabilties as a design criterion for a world wide > communication > protocol. Parsing SPF is a hack. This makes it look easy and > comfortable > in some people's eyes. But that's wrong. We are not here to design > a protocol easy to parse with perl regular expressions. > > And, by the way, sorry, but can't resist, asking for "who can give > an example SPF isn't able to cope with, otherwise it must be good" is > not exactly the art of designing good protocols. > > > Or in other words: I vote for ASN.1 or XML (or zipped XML). > > > regards > Hadmut > > > > From owner-ietf-mxcomp@mail.imc.org Tue Jun 22 13:57:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08137 for ; Tue, 22 Jun 2004 13:57:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MHnjpj078736; Tue, 22 Jun 2004 10:49:45 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MHnja1078735; Tue, 22 Jun 2004 10:49:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from engine140.deployzone.net (engine140.deployzone.net [193.17.85.140]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5MHnhZe078614 for ; Tue, 22 Jun 2004 10:49:44 -0700 (PDT) (envelope-from chris@zumbrunn.com) Received: from adsl-212-90-218-6.cybernet.ch [212.90.218.6] by engine140.deployzone.net; Tue, 22 Jun 2004 19:49:12 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <88B53594-C474-11D8-A3F4-000A95C969C6@zumbrunn.com> Content-Transfer-Encoding: 7bit Cc: IETF MARID WG From: Chris Zumbrunn Subject: Re: Why XML Date: Tue, 22 Jun 2004 19:49:39 +0200 To: "Hallam-Baker, Phillip" X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 22. Jun 2004, at 17:38, Hallam-Baker, Phillip wrote: > The angle bracket stuff is completely irrelevant as far as I and most > other > XML coders are concerned. It is like x86 assembly code, I know it is > there > but I don't want to see it. Exactly, most everyone doesn't want to see it either. Which is why it doesn't belong in DNS. If it would be true that XML is the format to use then DNS should only contain a pointer to it. Chris From owner-ietf-mxcomp@mail.imc.org Tue Jun 22 14:02:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09101 for ; Tue, 22 Jun 2004 14:02:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MHtk99080154; Tue, 22 Jun 2004 10:55:46 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MHtk65080153; Tue, 22 Jun 2004 10:55:46 -0700 (PDT) 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.9) with ESMTP id i5MHtkA6080147 for ; Tue, 22 Jun 2004 10:55:46 -0700 (PDT) (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 i5MHtRPP025346; Tue, 22 Jun 2004 10:55:27 -0700 (PDT) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 22 Jun 2004 10:55:27 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'terry@ashtonwoodshomes.com'" , "'Roy Badami'" , "Hallam-Baker, Phillip" Cc: "'IETF MARID WG'" Subject: RE: Why XML Date: Tue, 22 Jun 2004 10:55:24 -0700 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 you are correct Roy, I have, and will continue to > manually code my SPF records. And if I > wanted SPF XML records, I would have to do them by hand also > (I don't have any XML encoding > software, not to say that there won't be any free ones, but I > have far better things to spend my > software budget on right now). Back in 1992 there was only one editor capable of WYSWIG editing of HTML and that ran on a NexT box that almost nobody had access to. Even so an awful lot of HTML got written at a time when almost nobody had used anything like SGML before. Pretty much every mail admin is used to dealing with HTML encoded mail, and the quantities of legacy plaintext encoded email are likely to drop significantly over the comming years. Windows admins are likely to see every config file on the system turn XML over the next few releases for sure. I strongly suspect that quite a bit of XMLification will happen even on Linux. The future of messaging is a convergence of what are today artificialy separate protocols. Try reading the web using an RSS reader and you will see an interface that looks identical to a mail or news interface. The only real difference between mail and instant messaging is the priority given to the delivery notice. Same for the telephone, or videoconf. So I really don't expect that the term 'mail admin' will have much relevance in the future as a distinct specialization. If a mail admin can't hack XML then they won't be able to find much of a job. Phill From owner-ietf-mxcomp@mail.imc.org Tue Jun 22 14:25:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12602 for ; Tue, 22 Jun 2004 14:25:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MIHvuR084768; Tue, 22 Jun 2004 11:17:57 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MIHvwm084767; Tue, 22 Jun 2004 11:17:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MIHuQs084760 for ; Tue, 22 Jun 2004 11:17:57 -0700 (PDT) (envelope-from roy+dated+1090520278.4f6593@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i5MIHwRC085948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 22 Jun 2004 18:17:59 GMT (envelope-from roy+dated+1090520278.4f6593@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5MIHwxn058746 for ; Tue, 22 Jun 2004 19:17:58 +0100 (BST) (envelope-from roy+dated+1090520278.4f6593@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5MIHw6v058740 for ietf-mxcomp@imc.org; Tue, 22 Jun 2004 19:17:58 +0100 (BST) (envelope-from roy+dated+1090520278.4f6593@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Tue, 22 Jun 2004 19:17:57 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16600.30676.640092.487143@giles.gnomon.org.uk> Date: Tue, 22 Jun 2004 19:17:56 +0100 To: "Hallam-Baker, Phillip" Cc: "'terry@ashtonwoodshomes.com'" , "'Roy Badami'" , "'IETF MARID WG'" Subject: RE: Why XML In-Reply-To: References: X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Hallam-Baker," == Hallam-Baker, Phillip writes: Hallam-Baker,> So I really don't expect that the term 'mail admin' Hallam-Baker,> will have much relevance in the future as a Hallam-Baker,> distinct specialization. That's quibbling over terminology. _Someone_ is going to have to be responsible for publishing and debugging MARID records, assuming we're still using MARID by that time. Hallam-Baker,> If a mail admin can't hack Hallam-Baker,> XML then they won't be able to find much of a job. That isn't quite what I said. I didn't say that mail admins won't be able to cope with XML, I just said that IMHO SPF syntax is easier to read than the unformatted XML we're contemplating putting in TXT records. -roy From owner-ietf-mxcomp@mail.imc.org Tue Jun 22 14:33:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13895 for ; Tue, 22 Jun 2004 14:33:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MIKC5P085123; Tue, 22 Jun 2004 11:20:12 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MIKCPP085122; Tue, 22 Jun 2004 11:20:12 -0700 (PDT) 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.9) with ESMTP id i5MIK9Zi085113 for ; Tue, 22 Jun 2004 11:20:11 -0700 (PDT) (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 i5MIK9Pe005020; Tue, 22 Jun 2004 20:20:09 +0200 Received: from danisch.de (localhost [127.0.0.1]) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-5) with ESMTP id i5MIFfkV031917; Tue, 22 Jun 2004 20:15:41 +0200 Message-ID: <40D8774D.2000805@danisch.de> Date: Tue, 22 Jun 2004 20:15:41 +0200 From: Hadmut Danisch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040528 Debian/1.6-7 X-Accept-Language: de-de MIME-Version: 1.0 To: Roy Badami , ietf-mxcomp@imc.org Subject: Re: Why XML References: <16600.26788.774238.914922@giles.gnomon.org.uk> In-Reply-To: <16600.26788.774238.914922@giles.gnomon.org.uk> 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: Content-Transfer-Encoding: 7bit Roy Badami wrote: > >However the angle bracket stuff is what most mail administrators will >find themselves staring at when debugging mail deliverability >problems. > >That's my main reason for prefering SPF syntax; I just find it easier >to read (visually less cluttered) than XML, and its simpler (less >flexible) syntax is easier to parse visually, precisely because of the >lack of nested structure. > >Am I overestimating the extent to which MARID records will end up >being written and read by hand by mail admins...? > > > Yes, you are overestimating it by far. Most so called "mail administrators" are not able or not used to fetch DNS records. They are what we call MuFF-clickers (MuFF = Maus und Fenster-Firlefanz = Mouse and Window falderal) By far the most domains (at least in Germany) are domains of private people or small to medium size companies and organizations which don't have a clue about DNS details, they are more or less consumers of ISP services. Very few domain "admins" are able to write a zone file. You have to give them a neat and easy user interface, either some windows program or a web interface. With debugging facilities - Enter an IP address here and see wether e-mail would be accepted or not (and why). Very few people will read or write those records directly without software support. And much fewer people will be able to read SPF but not XML. I guess <<2%. I bet that MARID records will be handled through some software frontend in >97%. So you can use ASN.1 or XML (or zipped XML) as well. It makes writing such programs even easier. There are ready-to-run XML parsers for PHP, Perl, Ruby, ... Don't design the protocol for those few people who fiddle around with DNS records directly. Design the protocol for those who need to handle tens and hundreds of thousands domains automatedly and to provide a web interface. Once we have defined a protocol, we should be able to provide software to cope with it. Microsoft should make a program to read, write, verify, and debug those records easily and make it available, and we should provide such software for Linux/Unix/ Web as well. it must be easy to use. No manual editing of DNS records. Why? What do you think how many mistakes will all admins make on the world? Tell them to keep their fingers off and use a program which generates valid (and tested!) records only. E.g. warn if one entry blocks another. Or if RFC1918 addresses are given. This is basically the same as configuring a firewall. Nice feature: Run it against your local mailbox or MTA log file and show which messages would have been accepted and which would have been denied. This will help people to debug in advance. Such software is needed anyway if the new protocol is to be deployed in finite time. The more people use such an idiot-proof frontend instead of typing in rubbish, the easier it will be to roll it out. Hadmut From owner-ietf-mxcomp@mail.imc.org Tue Jun 22 14:49:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17335 for ; Tue, 22 Jun 2004 14:49:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MIeNE3089243; Tue, 22 Jun 2004 11:40:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MIeND4089242; Tue, 22 Jun 2004 11:40:23 -0700 (PDT) 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.9) with ESMTP id i5MIeKmF089222 for ; Tue, 22 Jun 2004 11:40:22 -0700 (PDT) (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 i5MIe894005592; Tue, 22 Jun 2004 20:40:08 +0200 Received: from danisch.de (localhost [127.0.0.1]) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-5) with ESMTP id i5MIc8ER000303; Tue, 22 Jun 2004 20:38:08 +0200 Message-ID: <40D87C90.9050601@danisch.de> Date: Tue, 22 Jun 2004 20:38:08 +0200 From: Hadmut Danisch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040528 Debian/1.6-7 X-Accept-Language: de-de MIME-Version: 1.0 To: terry@ashtonwoodshomes.com CC: "'IETF MARID WG'" , spf-discuss@v2.listbox.com Subject: Re: Why XML References: <013001c45881$488c5b80$2766f30a@development.greatgulfhomes.com> In-Reply-To: <013001c45881$488c5b80$2766f30a@development.greatgulfhomes.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit terry@ashtonwoodshomes.com wrote: >Um, how does the complexity of XML improve security. I can think of examples where XML enhancements >CAUSED exploits, and there are implementations where the XML implementation poses denial of service >exploit by sheer processing power needed for a full XML parser. > > I do trust a parser generated by a parser generator or a common XML library much more than any hand-coded quick and dirty SPF parser. There is not automated parsing tool for SPF, and a syntax like SPF invites for a quick and dirty implementation. Eats valid SPF records. But that's how buffer overruns are generated. >How is this a "single shot" at upgrading email? The SMTP protocol has been evolving for a VERY long >time. > > That's nonsense. The SMTP protocol was evolving at a time where the "Internet" consisted of a few hundred users and where e-mail was just an experiment, where nobody complained if it didn't work for some time. e-mail was a researchers game, not a highly relevant communication medium. SMTP had time and chance to evolve. But to follow your argument: How much time would you like to have for SPF to evolve? 3 Years? 5? 10? >Interesting arguments on extensibility. All valid. Also all valid for SPFv1 due to the fact that >SPFv1 is extensible. > > > "Extensible"? You mean you can add new, unknown entry types. Is this "Exensibility"? Is it possible to add a time limit to an IP address without loosing backward compatibility? Can I extend an entry giving permission to the address 1.2.3.4 such that it is allowed only during business hours, while keeping compatibility with older version (which would give permission around the clock)? What if I wish to add, e.g. cryptographic keys or jpeg images to the records? What if an entry becomes 180,000 bytes long? Are you sure that all SPF implementations will eat this without problem? No buffer limits? Is SPF really "extensible"? Or is it just not well defined? Is that what you call "Extensibility" more than just a gap in the definition? Hadmut From owner-ietf-mxcomp@mail.imc.org Tue Jun 22 14:52:29 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17925 for ; Tue, 22 Jun 2004 14:52:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MIj8mG090129; Tue, 22 Jun 2004 11:45:08 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MIj8ZK090128; Tue, 22 Jun 2004 11:45:08 -0700 (PDT) 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.9) with ESMTP id i5MIj5a2090113 for ; Tue, 22 Jun 2004 11:45:07 -0700 (PDT) (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 i5MIj8tO005740; Tue, 22 Jun 2004 20:45:08 +0200 Received: from danisch.de (localhost [127.0.0.1]) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-5) with ESMTP id i5MIeZVj000426; Tue, 22 Jun 2004 20:40:35 +0200 Message-ID: <40D87D23.8090502@danisch.de> Date: Tue, 22 Jun 2004 20:40:35 +0200 From: Hadmut Danisch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040528 Debian/1.6-7 X-Accept-Language: de-de MIME-Version: 1.0 To: Chris Zumbrunn CC: IETF MARID WG Subject: Re: Why XML References: <88B53594-C474-11D8-A3F4-000A95C969C6@zumbrunn.com> In-Reply-To: <88B53594-C474-11D8-A3F4-000A95C969C6@zumbrunn.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Chris Zumbrunn wrote: > > Exactly, most everyone doesn't want to see it either. Which is why it > doesn't belong in DNS. > > If it would be true that XML is the format to use then DNS should only > contain a pointer to it. Which was btw the reason for my RMX++ proposal. In RMX++ DNS just contains the pointer. Hadmut From owner-ietf-mxcomp@mail.imc.org Tue Jun 22 15:33:29 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22704 for ; Tue, 22 Jun 2004 15:33:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MJL3L5097019; Tue, 22 Jun 2004 12:21:03 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MJL3Dl097018; Tue, 22 Jun 2004 12:21:03 -0700 (PDT) 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.9) with ESMTP id i5MJL27F097012 for ; Tue, 22 Jun 2004 12:21:02 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i5MJJcWX028988; Tue, 22 Jun 2004 12:19:38 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 22 Jun 2004 12:19:38 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Roy Badami'" , "Hallam-Baker, Phillip" Cc: "'terry@ashtonwoodshomes.com'" , "'IETF MARID WG'" Subject: RE: Why XML Date: Tue, 22 Jun 2004 12:19:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Hallam-Baker,> So I really don't expect that the term 'mail admin' > Hallam-Baker,> will have much relevance in the future as a > Hallam-Baker,> distinct specialization. > > That's quibbling over terminology. _Someone_ is going to have to be > responsible for publishing and debugging MARID records, assuming we're > still using MARID by that time. No, my point is that the messaging admin is going to be admining several services, most of which will be Web Services running over pure XML. > Hallam-Baker,> If a mail admin can't hack > Hallam-Baker,> XML then they won't be able to find much of a job. > > That isn't quite what I said. I didn't say that mail admins won't be > able to cope with XML, I just said that IMHO SPF syntax is easier to > read than the unformatted XML we're contemplating putting in TXT > records. With XML it is a simple matter to add a feature to the DNS retreive tool to format the data in a comprehensible way - take a look at how IE displays XML. that is not possible with the SPF syntax unless the tool understands the version of the syntax used. With XML - extensions to the data structure do not affect tools With SPF - extensions to the data structure require all tools to be rewritten From owner-ietf-mxcomp@mail.imc.org Tue Jun 22 15:39:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23101 for ; Tue, 22 Jun 2004 15:39:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MJU6Pi098831; Tue, 22 Jun 2004 12:30:06 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MJU6ZH098830; Tue, 22 Jun 2004 12:30:06 -0700 (PDT) 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.9) with ESMTP id i5MJU4fk098815 for ; Tue, 22 Jun 2004 12:30:05 -0700 (PDT) (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 i5MJU5U6007289 for ietf-mxcomp@imc.org; Tue, 22 Jun 2004 21:30:05 +0200 Received: from danisch.de (localhost [127.0.0.1]) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-5) with ESMTP id i5MJRaJN002279 for ; Tue, 22 Jun 2004 21:27:36 +0200 Message-ID: <40D88827.5090904@danisch.de> Date: Tue, 22 Jun 2004 21:27:35 +0200 From: Hadmut Danisch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040528 Debian/1.6-7 X-Accept-Language: de-de MIME-Version: 1.0 To: IETF MARID WG Subject: Re: Why not XML References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit wayne wrote: >There are also some not very technical/rational reasons: > >* Many mail admins don't like/understand XML. > > I do know so many mail admins who don't like/understand DNS. Therefore we shouldn't use DNS. >* XML is promoted by MS a lot, and many mail admins don't like MS. > > > Correct. I don't like MS either. As far as I know MS promotes the use of e-mail, computers, and internet. We should stop using e-mail, computers and internet. Hadmut From owner-ietf-mxcomp@mail.imc.org Tue Jun 22 15:43:03 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23443 for ; Tue, 22 Jun 2004 15:43:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MIZrbq088448; Tue, 22 Jun 2004 11:35:53 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MIZrQX088447; Tue, 22 Jun 2004 11:35:53 -0700 (PDT) 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.9) with ESMTP id i5MIZqb4088432 for ; Tue, 22 Jun 2004 11:35:52 -0700 (PDT) (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.34) id 1Bcq7M-0000p4-QJ for ietf-mxcomp@imc.org; Tue, 22 Jun 2004 13:35:55 -0500 To: "IETF MARID WG" References: From: wayne Reply-To: "IETF MARID WG" Date: Tue, 22 Jun 2004 13:35:36 -0500 In-Reply-To: (Phillip Hallam-Baker's message of "Tue, 22 Jun 2004 08:03:26 -0700") 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 (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Why not XML Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-4.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ok folks, I'm way over the 3-post/day suggested limit, so this is my last post for a while. In "Hallam-Baker, Phillip" writes: [quoting out of order:] > > What you are trying to do here is to constrain the problem to the size of > your tool. That is not a very good approach when you are trying to deal with > a problem with a legacy system. Yes, I am trying to constrain the problem to the size of the tools I'm using. In particular, I'm using DNS. Once upon a time, the "exp=" modifier was part of the main SPF record. (exp= provides text that explains why an email was rejected by SPF.) Since the explanation text is often very long and since not everyone would want to see it, I argued that it should be put into a separate location. Likewise, most of these extensions are not going to be wanted by everyone and some are quite large. Adding short pointers to this info in the main SPF record is, IMHO, the way to go. >> [long list of "use the modifier" snipped] > > Which illustrates my point, you need structures and so you have cobbled > together an ad-hoc internal syntax to meet this need. I never said that the syntax had to be different. You did not give enough details about what you wanted for me to show an exact translation. There are lots of very solid technical reasons to not want XML: * The records *are* slightly larger, especially with the original Caller-ID version of the spec. Since the number of bytes is so limited, this is a problem. Not a killer problem in and of itself, but you can't dismiss it either. * In order to save bytes, the XML has to be scrunched together, making it very hard to read and modify. Whitespace makes things much more readable, and SPF uses whitespace. * In order to save bytes, most of the parsing isn't done via XML, you still have to have a complete SPF parser in order to do anything. You still have all the problems with creating an ad-hoc parser, but you have added all the problems of using an XML parser. * XML solves the syntax extension problem, but not the semantic extension problem. * The XML parsers are often very big, compared with the MTAs. When you double the amount of code, as in the case of qmail and libxml, you are more than double the chances of a security hole or allow for some sort of abusive XML document. * Two syntaxes means two different code paths that have to be tested. * Two syntaxes means that people who want to publish something have to make a confusing decision right off the bat. Is one better than the other? Why both? Which should I choose? * Two syntaxes means that anyone who needs to diagnose a problem with the MARID records has to understand both. There are also some not very technical/rational reasons: * Many mail admins don't like/understand XML. * XML is promoted by MS a lot, and many mail admins don't like MS. These latter two reasons have somewhat overshadowed the more technical reasons. I think some people assume that when the technical points are being raised, they are really to hide the irrational reasons and get pissed off by this. This, in turn, pisses the people who feel they have raised valid technical concerns and are being dismissed for being "irrational." XML is a great tool, but it is not a great tool for all jobs. -wayne From owner-ietf-mxcomp@mail.imc.org Tue Jun 22 15:52:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23993 for ; Tue, 22 Jun 2004 15:52:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MJXaEI099420; Tue, 22 Jun 2004 12:33:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MJXaVe099419; Tue, 22 Jun 2004 12:33:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MJXZah099412 for ; Tue, 22 Jun 2004 12:33:35 -0700 (PDT) (envelope-from aland@newgiles.nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 8357516CCA for ; Tue, 22 Jun 2004 15:40:14 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Why XML In-Reply-To: Your message of "Tue, 22 Jun 2004 20:15:41 +0200." <40D8774D.2000805@danisch.de> Date: Tue, 22 Jun 2004 15:40:14 -0400 Message-Id: <20040622194014.8357516CCA@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hadmut Danisch wrote: > By far the most domains (at least in Germany) are domains of > private people or small to medium size companies and organizations > which don't have a clue about DNS details, they are more or less > consumers of ISP services. Very few domain "admins" are able to > write a zone file. You have to give them a neat and easy user > interface, either some windows program or a web interface. Most such systems either: a) have a previously defined MX for the domain, which the user can't change or b) allow the users to add/edit MX's via the web interface. Both methods permit automated addition of a subset of MARID records. This means that most of those users won't even know if MARID is being deployed. With 100x more domains than MX's, this kind of solution is the *only* one which is relevant. > Design the protocol for those who need to handle > tens and hundreds of thousands domains automatedly > and to provide a web interface. I agree. If you have 100 domains for one MX, it doesn't make much sense to administer those domains by hand. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Tue Jun 22 16:02:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24831 for ; Tue, 22 Jun 2004 16:02:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MJqNfc004180; Tue, 22 Jun 2004 12:52:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MJqNGO004179; Tue, 22 Jun 2004 12:52:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MJqM9N004170 for ; Tue, 22 Jun 2004 12:52:22 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 (unknown [216.191.52.74]) by mail.greatgulfhomes.com (Postfix) with SMTP id 6D05136666E; Tue, 22 Jun 2004 15:59:13 -0400 (EDT) From: To: "'Hallam-Baker, Phillip'" , "'Roy Badami'" Cc: "'IETF MARID WG'" Subject: RE: Why XML Date: Tue, 22 Jun 2004 15:52:42 -0400 Message-ID: <015201c45892$819f8080$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit *Displaying* the new extension and actually doing something with it are *completely* different things. With XML programmers might save a bit of coding time in the parser when a new extension arrives, but ultimately someone has to code and produce a new version of the MTA which is actually going to implement the new extension. No matter how you transmit the data for the new extension, that is the inescapable reality. Terry Fielder Manager Software Development and Deployment Great Gulf Homes / Ashton Woods Homes terry@greatgulfhomes.com Fax: (416) 441-9085 > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Hallam-Baker, > Phillip > Sent: Tuesday, June 22, 2004 3:20 PM > To: 'Roy Badami'; Hallam-Baker, Phillip > Cc: 'terry@ashtonwoodshomes.com'; 'IETF MARID WG' > Subject: RE: Why XML > > With XML it is a simple matter to add a feature to the DNS retreive > tool to format the data in a comprehensible way - take a look at how > IE displays XML. > > that is not possible with the SPF syntax unless the tool > understands the > version of the syntax used. > > With XML - extensions to the data structure do not affect tools > With SPF - extensions to the data structure require all tools to be > rewritten > From owner-ietf-mxcomp@mail.imc.org Tue Jun 22 16:04:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24919 for ; Tue, 22 Jun 2004 16:04:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MJw20B005076; Tue, 22 Jun 2004 12:58:02 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MJw2Y9005075; Tue, 22 Jun 2004 12:58:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MJw1ll005060 for ; Tue, 22 Jun 2004 12:58:01 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24494; Tue, 22 Jun 2004 15:58:03 -0400 (EDT) Message-Id: <200406221958.PAA24494@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-mxcomp@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-marid-csv-csa-00.txt Date: Tue, 22 Jun 2004 15:58:03 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the MTA Authorization Records in DNS Working Group of the IETF. Title : Client SMTP Authorization (CSA) Author(s) : D. Otis, et al. Filename : draft-ietf-marid-csv-csa-00.txt Pages : 12 Date : 2004-6-21 Internet operation has typically required no public mechanism for announcing restriction or permission of particular hosts to operate clients or servers for particular services on behalf of particular domains. What is missing is an open, interoperable means by which a trusted agency can announce authorization for a host to operate a service. The current specification supports this capability for sending SMTP clients. Specifically, is a sending SMTP client permitted to act as a client MTA? Has a separate authority given it permission to perform this service? Client SMTP Authorization (CSA) specifies a DNS-based record that states whether an associated host has permission to operate as a client MTA. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marid-csv-csa-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-marid-csv-csa-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-marid-csv-csa-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-22152224.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-marid-csv-csa-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-marid-csv-csa-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-22152224.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-mxcomp@mail.imc.org Tue Jun 22 16:06:44 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25135 for ; Tue, 22 Jun 2004 16:06:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MJw6w7005123; Tue, 22 Jun 2004 12:58:06 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MJw66H005122; Tue, 22 Jun 2004 12:58:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MJw5UA005104 for ; Tue, 22 Jun 2004 12:58:06 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24501; Tue, 22 Jun 2004 15:58:07 -0400 (EDT) Message-Id: <200406221958.PAA24501@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-mxcomp@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-marid-csv-intro-00.txt Date: Tue, 22 Jun 2004 15:58:07 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the MTA Authorization Records in DNS Working Group of the IETF. Title : Client SMTP Validation (CSV) Author(s) : D. Crocker, et al. Filename : draft-ietf-marid-csv-intro-00.txt Pages : 14 Date : 2004-6-21 Internet mail relies on exchanges between systems that have made no prior arrangement with each other. The current service fails to provied an adequate level of accountability for participating hosts. Client SMTP Validation (CSV) provides an economical service that permits an SMTP server to decide whether messages sent by the client SMTP are likely to be well-behaved, or at least to decide whether the client is sufficiently accountable for its actions. CSV provides a small, simple and useful improvement to Internet mail service accountability. It builds upon the existing practise of service providers that accredit the networks from which sending systems are connecting. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marid-csv-intro-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-marid-csv-intro-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-marid-csv-intro-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-22152232.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-marid-csv-intro-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-marid-csv-intro-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-22152232.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-mxcomp@mail.imc.org Tue Jun 22 16:07:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25156 for ; Tue, 22 Jun 2004 16:07:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MJwBwi005136; Tue, 22 Jun 2004 12:58:11 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MJwBnM005135; Tue, 22 Jun 2004 12:58:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MJwAjK005127 for ; Tue, 22 Jun 2004 12:58:10 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24508; Tue, 22 Jun 2004 15:58:12 -0400 (EDT) Message-Id: <200406221958.PAA24508@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-mxcomp@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-marid-csv-dna-00.txt Date: Tue, 22 Jun 2004 15:58:12 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the MTA Authorization Records in DNS Working Group of the IETF. Title : Domain Name Accreditation (DNA) Author(s) : D. Crocker, et al. Filename : draft-ietf-marid-csv-dna-00.txt Pages : 10 Date : 2004-6-21 Increased diversity and abuse of access, across the open Internet, mandates additional accountability for sending SMTP clients, in the absence of prior, direct arrangement with receiving SMTP servers. One means for enabling this is by registration with third-party services that vouch for the policies and accountability of SMTP clients accessing SMTP servers. This specification defines a means for an SMTP client to list third-party services that are prepared to vouch for it, and a means for an SMTP server, or its intermediary, to query vouching services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marid-csv-dna-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-marid-csv-dna-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-marid-csv-dna-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-22152238.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-marid-csv-dna-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-marid-csv-dna-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-22152238.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-mxcomp@mail.imc.org Tue Jun 22 16:11:49 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25360 for ; Tue, 22 Jun 2004 16:11:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MK4dVR006668; Tue, 22 Jun 2004 13:04:39 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MK4deL006664; Tue, 22 Jun 2004 13:04:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MK4cJC006652 for ; Tue, 22 Jun 2004 13:04:38 -0700 (PDT) (envelope-from terry@greatgulfhomes.com) Received: from terrynew2 (unknown [216.191.52.74]) by mail.greatgulfhomes.com (Postfix) with SMTP id D238D3665B7; Tue, 22 Jun 2004 16:11:29 -0400 (EDT) From: To: "'Hadmut Danisch'" , "'IETF MARID WG'" Subject: RE: Why not XML Date: Tue, 22 Jun 2004 16:05:09 -0400 Message-ID: <015901c45894$38935400$2766f30a@development.greatgulfhomes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <40D88827.5090904@danisch.de> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I also know numerous mail admins (many MCXX certified) who don't understand even the simple concepts of the bare SMTP protocol. (Probably because most of them don't get taught what's under the hood). But when I encounter this, I can teach them the necessities for problem solving (telnet port 25, use simple SMTP commands for diagnosis). I cringe at the thought of having to teach someone how to problem solve and debug a bad SPF record in XML. It would be bad enough with SPF v1, a person would have to learn SPF theory and then apply it. But with XML first they would have to be taught XML and only then could we get to the real topic at hand which is the SPF theory. Terry Fielder Manager Software Development and Deployment Great Gulf Homes / Ashton Woods Homes terry@greatgulfhomes.com Fax: (416) 441-9085 > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Hadmut Danisch > Sent: Tuesday, June 22, 2004 3:28 PM > To: IETF MARID WG > Subject: Re: Why not XML > > > > wayne wrote: > > >There are also some not very technical/rational reasons: > > > >* Many mail admins don't like/understand XML. > > > > > > I do know so many mail admins who don't like/understand DNS. > Therefore we shouldn't use DNS. > > >* XML is promoted by MS a lot, and many mail admins don't like MS. > > > > > > > > Correct. I don't like MS either. > > As far as I know MS promotes the use of e-mail, computers, > and internet. > > We should stop using e-mail, computers and internet. > > > Hadmut > From owner-ietf-mxcomp@mail.imc.org Tue Jun 22 16:40:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27045 for ; Tue, 22 Jun 2004 16:40:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MKMZZI010139; Tue, 22 Jun 2004 13:22:35 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MKMZRw010138; Tue, 22 Jun 2004 13:22:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from engine140.deployzone.net (engine140.deployzone.net [193.17.85.140]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5MKMXWd010130 for ; Tue, 22 Jun 2004 13:22:34 -0700 (PDT) (envelope-from chris@zumbrunn.com) Received: from adsl-212-90-218-6.cybernet.ch [212.90.218.6] by engine140.deployzone.net; Tue, 22 Jun 2004 22:22:05 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Phillip Hallam-Baker , Hadmut Danisch From: Chris Zumbrunn Subject: Re: Why XML Date: Tue, 22 Jun 2004 22:22:33 +0200 To: "'IETF MARID WG'" X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 22. Jun 2004, at 20:15, Hadmut Danisch wrote: > Don't design the protocol for those few people who > fiddle around with DNS records directly. > > Design the protocol for those who need to handle > tens and hundreds of thousands domains automatedly > and to provide a web interface. On 22. Jun 2004, at 21:19, Hallam-Baker, Phillip wrote: > With XML it is a simple matter to add a feature to the DNS retreive > tool to format the data in a comprehensible way - take a look at how > IE displays XML. These are really arguments for an XML based DNS system. Of course, defining tomorrows DNS is outside the scope of MARID. XML doesn't belong in todays DNS. In fact, allowing XML in TXT records now might turn into a headache later when a conversion of DNS to XML is considered. Chris From owner-ietf-mxcomp@mail.imc.org Tue Jun 22 19:31:13 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10383 for ; Tue, 22 Jun 2004 19:31:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MNKh1e043838; Tue, 22 Jun 2004 16:20:43 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MNKhAY043837; Tue, 22 Jun 2004 16:20:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tidy.obscurity.org (tidy.obscurity.org [66.199.168.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MNKh1K043829 for ; Tue, 22 Jun 2004 16:20:43 -0700 (PDT) (envelope-from ksoze@obscurity.org) Received: by tidy.obscurity.org (Postfix, from userid 1000) id 5538469B1D; Tue, 22 Jun 2004 23:20:46 +0000 (UTC) Date: Tue, 22 Jun 2004 16:20:46 -0700 From: Sean Comeau To: Hadmut Danisch Cc: IETF MARID WG Subject: Re: Why XML Message-ID: <20040622232046.GF30711@obscurity.org> References: <013001c45881$488c5b80$2766f30a@development.greatgulfhomes.com> <40D87C90.9050601@danisch.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40D87C90.9050601@danisch.de> User-Agent: Mutt/1.5.6i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Jun 22, 2004 at 08:38:08PM +0200, Hadmut Danisch wrote: > > I do trust a parser generated by a parser generator or a common XML > library much more than any hand-coded quick and dirty SPF parser. > There is not automated parsing tool for SPF, and a syntax like SPF > invites for a quick and dirty implementation. Eats valid SPF records. > But that's how buffer overruns are generated. > how about lex? > > What if I wish to add, e.g. cryptographic keys or jpeg images to the > records? What if > an entry becomes 180,000 bytes long? Are you sure that all SPF > implementations > will eat this without problem? No buffer limits? > I don't see how XML would fare any better. The problem is that the record is 180K in size. XML parsers need to use buffers too. The machines XML runs on also have limited amounts of memory. And we are not going to be putting 180K into a resource record. Crypto keys have already been covered, jpegs can be handled in much the same way. > > Is SPF really "extensible"? Or is it just not well defined? > Is that what you call "Extensibility" more than just a gap in the > definition? > Yes, SPF really is extensible. If we need to start dealing with 180K XML files later we can just add: ihopeyourmailserverhasLOTSofmemory=http://host.example.net/bloat.xml After all, when faced with a 180K download the HTTP overhead isn't a problem. Hopefully it won't come to that. From owner-ietf-mxcomp@mail.imc.org Tue Jun 22 20:05:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14880 for ; Tue, 22 Jun 2004 20:05:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5MMr6Mr038999; Tue, 22 Jun 2004 15:53:06 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5MMr66p038998; Tue, 22 Jun 2004 15:53:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from wbm5.pair.net (wbm5.pair.net [66.39.3.85]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5MMq6cP038456 for ; Tue, 22 Jun 2004 15:53:05 -0700 (PDT) (envelope-from scott@kitterman.com) Received: (qmail 50582 invoked by uid 65534); 22 Jun 2004 22:52:09 -0000 Received: from 68.48.133.222 ([68.48.133.222]) (SquirrelMail authenticated user scott@kitterman.com); by webmail5.pair.com with HTTP; Tue, 22 Jun 2004 18:52:09 -0400 (EDT) Message-ID: <61676.68.48.133.222.1087944729.squirrel@68.48.133.222> Date: Tue, 22 Jun 2004 18:52:09 -0400 (EDT) Subject: Re: Why XML From: scott@kitterman.com To: ietf-mxcomp@imc.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hadmut Danisch wrote: > Roy Badami wrote: snip >>Am I overestimating the extent to which MARID records will end up being written and read by hand by mail admins...? snip > > By far the most domains (at least in Germany) are domains of > private people or small to medium size companies and organizations which don't have a clue about DNS details, they are more or less consumers of ISP services. snip I am writing as one of those "private people or small to medium size companies". I was able to digest the SPF spec in a few hours and, with the assistance of the wizard at pobox.com, write a correct and valid SPFv1 record. I was able to do this because the syntax is easily readable, compact, and deterministic. If I had had to learn XML in addition, I think I would never have signed up for the process. There is no ISP that could have written my SPF record. I send mail through different MTAs controlled by different companies depending on if I am connected from my office computer, my handheld, or via webmail from somewhere else. I had to start from the SPF record wizard and build my own record to cover our unique circumstances. I do not believe this will be rare. If MARID is going to be successful, then the parts that relate to individual domains must be simple, compact, and comprehensible. If they aren't, we little people will not be able to participate. If you have to put complexity somewhere, put it in the MTAs and possibly behind the scenes in the DNS servers. Keep the MARID record a simple as possible. If MARID is going to be successful, it is going to have to have a bounded scope so that we can understand what is going to happen to us when we support it (honestly, SPF is pushing the limits in this area). I wouldn't have published SPF records without a solid understanding of what I was signing up for. Whatever you decide on, please do not impose something to complex because the complexity might be needed in the future. A MARID solution that is only useable by e-mail/messaging professionals is going to exclude a lot of domains from participating. Scott Kitterman From owner-ietf-mxcomp@mail.imc.org Tue Jun 22 21:48:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23713 for ; Tue, 22 Jun 2004 21:48:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5N1bN42066040; Tue, 22 Jun 2004 18:37:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5N1bNsM066039; Tue, 22 Jun 2004 18:37:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.mail-abuse.org [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5N1bLoj066009 for ; Tue, 22 Jun 2004 18:37:21 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.mail-abuse.org (DDev.mail-abuse.org [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id 32CEE4149E; Tue, 22 Jun 2004 18:37:13 -0700 (PDT) Subject: Re: Why XML From: Douglas Otis To: Hadmut Danisch Cc: terry@ashtonwoodshomes.com, "'IETF MARID WG'" , spf-discuss@v2.listbox.com In-Reply-To: <40D87C90.9050601@danisch.de> References: <013001c45881$488c5b80$2766f30a@development.greatgulfhomes.com> <40D87C90.9050601@danisch.de> Content-Type: text/plain Message-Id: <1087954632.22641.272.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 22 Jun 2004 18:37:13 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 2004-06-22 at 11:38, Hadmut Danisch wrote: > terry@ashtonwoodshomes.com wrote: > > > Um, how does the complexity of XML improve security. I can think > > of examples where XML enhancements CAUSED exploits, and there are > > implementations where the XML implementation poses denial of service > > exploit by sheer processing power needed for a full XML parser. > > I do trust a parser generated by a parser generator or a common XML > library much more than any hand-coded quick and dirty SPF parser. > There is not automated parsing tool for SPF, and a syntax like SPF > invites for a quick and dirty implementation. Eats valid SPF records. > But that's how buffer overruns are generated. Any mechanism introduced that stems the flow of UCE will be subjected to intensive attack. Introducing a required series of DNS queries to establish permissions increases a data footprint, but also code size may also adversely impact system resources depending upon OS and structure. If used in the normal fashion, no parser is required to utilize DNS answers, so the introduction of a parser increases vulnerabilities. The less rigid and more extensible the syntax, the greater the vulnerabilities. As the allowable answer from DNS is small, any chained records further increases vulnerabilities by increasing both resources and time required to process a message. An attacker "jamming" the checking mechanism might set up DNS servers for domains they control that respond erratically and offer complex record sets with small TTLs. The attacker then sends messages from their domains in an attempt to exhaust resources as a means to have recipients disable the checking processes within the channel. If on average a small enterprise uses two outside services, then normally there will be a need to chain these records as it would be prohibitively difficult to administer otherwise. These outside vendors may in turn also outsource for yet more chaining. As example, a mail server is receiving 50 messages per second that average 4 K bytes in size. If using the SPF/CID mechanism, checking DNS data is indeterminate as there is no limit for the number of sequential queries required to converge upon an answer. RFC1035 indicates 5 to 10 seconds should be considered a worst case resolver interval. If there becomes an average of 10 queries with an average of 5 seconds a query, then this limits each process to about 1 message about every minute. These 10 queries will also add to the traffic at 350 bytes per record a total of 4K bytes of additional traffic for a doubling of the network load. The mail server may normally handle 1,500 simultaneous processes, but at 60 seconds per process, the mail server is reduced to only running 25 messages a second. This may still represent the same amount of network traffic, just half as much mail gets through the network. The concern for the process footprint becomes important as this will impact the number of simultaneous processes able to run on these machines. Should this mechanism only be usable at the MUA, there will be no mitigation with respect to network traffic, as the MUA will consume these same resources, invoke the queries, and even a valid record does not offer assurance the mail is desired. All of this checking will provide a marking scheme that may be inaccurate depending upon the number of users sending from diverse access points, and still possibly forged, especially if checking is moved to the MUA. If forced into its strictest mode, it will cause complaints by forcing users to offer a greater number of return addresses while at the same time removing tools to consolidate the resulting diffusion of mail. The recognizable return address becomes a thing of the past. By insisting records sizes be 20% larger to handle future extensions where version 1 code must accept any and all additional "unknown" data added to the record invites uncontrollable growth of these records. Should an MTA decide a series of 512 byte DNS records is not reasonable because this addition, then those demanding extensibility will complain such limitations are non-compliant with their "vital" need for something else yet to be defined. The further this gets away from the immediately confirmable information using standard DNS queries, the less likely there will be any discernible benefit. > > How is this a "single shot" at upgrading email? The SMTP protocol > > has been evolving for a VERY long time. > > That's nonsense. The SMTP protocol was evolving at a time where > the "Internet" consisted of a few hundred users and where e-mail was > just an experiment, where nobody complained if it didn't work for some > time. e-mail was a researchers game, not a highly relevant communication > medium. SMTP had time and chance to evolve. > > But to follow your argument: How much time would you like to have for > SPF to evolve? 3 Years? 5? 10? As they say, there is more than one way to skin a cat. An extensible protocol does not need to use an extensible record. Mail is one of the most often used applications. Any feature added should not risk breaking both the DNS system as well as the application that it is claiming to improve. If to stop abuse, aim directly at stopping abuse. Attempting to lessen a technique may change the behavior of the abuser but will do little else. In addition, any false assurances adds to the risk of clients being duped with possible suits directed to those that provided false assurances. > > Interesting arguments on extensibility. All valid. Also all valid > > for SPFv1 due to the fact that SPFv1 is extensible. > > "Extensible"? You mean you can add new, unknown entry types. Is this > "Exensibility"? > > Is it possible to add a time limit to an IP address without loosing > backward compatibility? > > Can I extend an entry giving permission to the address 1.2.3.4 such that > it is allowed only during business hours, while keeping compatibility > with older version (which would give permission around the clock)? > > What if I wish to add, e.g. cryptographic keys or jpeg images to the > records? What if an entry becomes 180,000 bytes long? Are you sure that > all SPF implementations will eat this without problem? No buffer limits? > > Is SPF really "extensible"? Or is it just not well defined? > Is that what you call "Extensibility" more than just a gap in the > definition? Extensibility is the road to never ending change, paved by marketing hype, that soon requires complete replacement due to lack of foresight. -Doug From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 01:03:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01923 for ; Wed, 23 Jun 2004 01:03:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5N4sRik099632; Tue, 22 Jun 2004 21:54:27 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5N4sR0b099631; Tue, 22 Jun 2004 21:54:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [64.139.47.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5N4sQRY099625 for ; Tue, 22 Jun 2004 21:54:27 -0700 (PDT) (envelope-from gconnor@nekodojo.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by neko-base.nekodojo.org (Postfix) with ESMTP id 3E6691D651 for ; Tue, 22 Jun 2004 21:54:34 -0700 (PDT) Date: Tue, 22 Jun 2004 21:54:35 -0700 From: Greg Connor To: IETF MARID WG Subject: Re: Why not XML Message-ID: <7242944.1087941275@[10.12.1.26]> In-Reply-To: <40D88827.5090904@danisch.de> References: <40D88827.5090904@danisch.de> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit The appearance of Hadmut Danisch in the In Favor Of XML camp is definitely a blow to the anti-XML team. This, coupled with the support of Phillip Hallam-Baker is almost enough to make the anti-XML team lose hope. Here Hadmut demonstrates a typical argument method in the Not Based On Logic categorym that of making fun of an argument he disagrees with. The listener may be swayed into thinking that if the argument can be mocked, it must not have been serious in the first place. --Hadmut Danisch wrote: > > wayne wrote: > >> There are also some not very technical/rational reasons: >> >> * Many mail admins don't like/understand XML. >> > > I do know so many mail admins who don't like/understand DNS. > Therefore we shouldn't use DNS. Here is another example of the non-logical argument technique called "mocking". "Many mail admins don't like cheese. Therefore, MARID should be made out of bread!" >> * XML is promoted by MS a lot, and many mail admins don't like MS. >> > > Correct. I don't like MS either. > As far as I know MS promotes the use of e-mail, computers, and internet. > We should stop using e-mail, computers and internet. Hmm, that one will be tough to top. But I will try. How about: "MS promotes shareholder value. Therefore we should reject capitalism, move to a commune, and weave MARID records on the same loom we use to weave clothes made of our own hair." Now. All joking aside, I have a great deal of respect for Hadmut and his work... we probably would not have arrived where we are today without him. But, the arguments being made here are not logical ones. In fact, Hadmut's message here is an *excellent* example of someone reacting emotionally (and making an emotional argument) rather than reacting with logic. Surprised? You shouldn't be... because the whole XML issue is VERY emotionally charged. We are all reacting emotionally to it, and you had better believe our customers will react emotionally to it as well. We ignore this point at our peril. Will our customers have an emotional reaction to XML? If so, no army of technical experts will change that reaction. What if it's true, that more admins will adopt it if the record is easy to read with the unaided eye and easy to write with the unaided hand? Is that even a consideration for the "make it future-proof" crew? Would people on this team prefer to create something that expands in 8 directions and comes with a flip-out compass and a toothpick? If it will get used by fewer domains for totally non-technical reasons, is that important? In some years in the industry, I have noticed that a lot of really, really smart, really intelligent people will be unable to deal with emotions on any level. Of course they have them, but they will deny it and provide lengthy, detailed, technical explanations as to why they believe the way they do. The stronger the feeling, the more verbose the so-called logical explanation. These individuals will even use cunning wit to attack someone else ruthlessly, with no way to explain bad behavior other than "Well, he was wrong." (Inconsiderate, even rude behavior such as Hadmut resorted to here is a sign of an emotional reaction in progress.) At the same time, these incredibly smart individuals will often be dumbfounded and helpless when faced with someone else who *admits* to having an emotional reaction. Explaining how you feel to someone who deals on an intellectual plane 99% of the time is like speaking a different language -- they either cannot comprehend, or dismiss it is not logical, therefore stupid. On an emotional level, here are two possible reactions that people might have to XML. 1. Ooooh, shiny. I'll bet it goes fast. I would really like an excuse to take that syntax for a test drive. (Let's call this the "engineer's reaction") 2. Yuck, that's ugly. And 20% longer. I sure hope it works right the first time because I sure don't want to debug it. (Let's call this the "sysadmin's reaction") We have to be ready to deal with BOTH reactions, and since they are emotional reactions, we can't explain them away. We can get around them, but not with engineering powers... the power to change an emotional reaction is reserved only for the marketers :) You know, I'll admit that I'm reacting emotionally too. I'm no different. But, I guess I need to heed my own advice and take a step back. If we have near-agreement on semantics, identities, and features and then totally lose all unity and team spirit over something as simple as syntax, we are guaranteed to look silly and be irrelevant in 5 years, probably less. This outcome would be much worse than publishing a standard that needs revision within a year and is obsolete in three. So. Who is ready to compromise? -- Greg Connor From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 01:50:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04232 for ; Wed, 23 Jun 2004 01:50:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5N5e5b6022536; Tue, 22 Jun 2004 22:40:05 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5N5e5J8022535; Tue, 22 Jun 2004 22:40:05 -0700 (PDT) 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.9) with ESMTP id i5N5e4u0022483 for ; Tue, 22 Jun 2004 22:40:05 -0700 (PDT) (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 i5N5e98N020404; Wed, 23 Jun 2004 07:40:09 +0200 Received: from danisch.de (localhost [127.0.0.1]) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-5) with ESMTP id i5N5bIXr026581; Wed, 23 Jun 2004 07:37:18 +0200 Message-ID: <40D9170D.1040907@danisch.de> Date: Wed, 23 Jun 2004 07:37:17 +0200 From: Hadmut Danisch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040528 Debian/1.6-7 X-Accept-Language: de-de MIME-Version: 1.0 To: scott@kitterman.com CC: ietf-mxcomp@imc.org Subject: Re: Why XML References: <61676.68.48.133.222.1087944729.squirrel@68.48.133.222> In-Reply-To: <61676.68.48.133.222.1087944729.squirrel@68.48.133.222> 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: Content-Transfer-Encoding: 7bit scott@kitterman.com wrote: > >I am writing as one of those "private people or small to medium size >companies". > >I was able to digest the SPF spec in a few hours and, with the assistance >of the wizard at pobox.com, write a correct and valid SPFv1 record. I was >able to do this because the syntax is easily readable, compact, and >deterministic. If I had had to learn XML in addition, I think I would >never have signed up for the process. > > > The fact that you are participating in this discussion and news group shows, that you are much, much more technically experienced than the average user. The average user will have to use a frontend program anyway. regards Hadmut From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 03:06:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19211 for ; Wed, 23 Jun 2004 03:06:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5N6vQJ2060439; Tue, 22 Jun 2004 23:57:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5N6vQkR060438; Tue, 22 Jun 2004 23:57:26 -0700 (PDT) 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.9) with ESMTP id i5N6vMan060398 for ; Tue, 22 Jun 2004 23:57:25 -0700 (PDT) (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 i5N6vMvD021673; Wed, 23 Jun 2004 08:57:22 +0200 Received: from danisch.de (localhost [127.0.0.1]) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-5) with ESMTP id i5N6hB4v029329; Wed, 23 Jun 2004 08:43:11 +0200 Message-ID: <40D9267F.2010309@danisch.de> Date: Wed, 23 Jun 2004 08:43:11 +0200 From: Hadmut Danisch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040528 Debian/1.6-7 X-Accept-Language: de-de MIME-Version: 1.0 To: Greg Connor CC: IETF MARID WG Subject: Emotions, Encoding, and Ignorance (Was: Why not XML) References: <40D88827.5090904@danisch.de> <7242944.1087941275@[10.12.1.26]> In-Reply-To: <7242944.1087941275@[10.12.1.26]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Greg Connor wrote: > > The appearance of Hadmut Danisch in the In Favor Of XML camp is > definitely a blow to the anti-XML team. This, coupled with the > support of Phillip Hallam-Baker is almost enough to make the anti-XML > team lose hope. > > Here Hadmut demonstrates a typical argument method in the Not Based On > Logic categorym that of making fun of an argument he disagrees with. > The listener may be swayed into thinking that if the argument can be > mocked, it must not have been serious in the first place. > > ... > Now. All joking aside, I have a great deal of respect for Hadmut and > his work... we probably would not have arrived where we are today > without him. But, the arguments being made here are not logical ones. > In fact, Hadmut's message here is an *excellent* example of someone > reacting emotionally (and making an emotional argument) rather than > reacting with logic. > This was not meant to be logical. This was not meant to be an argument at all. This was meant to be irony and sarcasm. I wanted to point out on which lousy level this discussion is made. If you didn't realize this and still took this as an argument, you confirmed my point of view. While you were blaming me for beeing emotional, It was you who gave a purely emotional reaction. You were supposed to laugh and cool down. Maybe you have realized that I didn't participate in this discussion for a long time. Guess why? Because this is an endless loop. An emotional loop. Caused by SPF. Why? Because SPF has never been a technical invention. SPF is only a public relations coup of a few people who were hijacking an idea to bring themselves in front of the cameras and the newspapers. I have spoken with several journalists who were intentionally misinformed. If you don't believe this, just have a look at the ASRG history. And that's the reason for emotions. What is the main property of SPF? Nothing but a slightly changed syntax. If we don't stick to SPF syntax, what will remain of the SPF hype? Roughly nothing. That's the reason why so many people desperately defend SPF syntax against any progress. They try to enforce SPF syntax, because that's all SPF consists of. Think about it. Your overreaction to my sarcasm was very meaningful. OK, let's come back to technical arguments. A/The major argument for using SPF is readability. I confirm that readability is a very strong and important argument. But is this correct? No, it isn't. Why not? Because it ignores the fact that DNS records are not readible by default. Readibility of SPF is based on wrong assumptions. It is based on abusing TXT records. The readibility argument includes a lot of ignorance of technical facts. Most people don't seem to be aware of layer models. Have you ever seen DNS records from inside? How DNS records are encoded? They are not readible. They are binary encoded. If you can easily read what nslookup/dig spit out, then this is not a property of DNS records. It is because the dns library includes encoders and decoders for every single DNS record type. What you see is a result of a decoding process, not the DNS record itself. Even TXT records require some encoding. It's extremely simple, but it is there. What does that mean? The whole argument of readibility is pure nonsense. Based on wrong assumptions and ignorance of technical details. What do you believe? Why did I put both a syntax and a binary encoding in the RMX drafts? Because you have to cover both, the external representation and the internal encoding. That's what we have to deal with in context of DNS, whether you like it or not. Of course, you can decide to abuse TXT records or invent a new MARID record type with exactly the the same simple encoding as TXT records. But that itself is a step of engineering most people never thought about. This MARID/SPF/... discussion is a religious controversy, not a technical development process. How do we make it any better? I propose to start beeing aware of having to do two different jobs: - Define an internal encoding - Define an external representation (This requires to understand how DNS works, which is significantly more than just being able to abuse TXT recors...) I'd propose an example. You don't need to stick to it, it's merely to explain what I am talking about. - First, define an abstract semantics. This is almost done. Define that MARID records can authorize IPv6 addresses, IPv4 ranges,etc. - Second, define an internal encoding. I'd prefer ASN.1/DER DER decoders are not that difficult, because in contrast to XML you can work with a simple one byte lookahead. DER de- and encoders can be extremely small and compact. (And I don't know that anyone ever seriously complained that SNMP, X.509,... are encoded in ASN.1). - Define an external representation. This is what nslookup or dig spit out when displaying a query result or what bind eats when reading a zone table. If you don't understand what I am talking about, have a look at the bind sources or the RMX implementation example available at danisch.de Why not having two external representations? You are free to express the ASN.1 encoded information in any readible syntax, both SPF or XML, for zone tables, for human readibility, for printouts, for storage, as a mime type, whatever you want. This way you can have two different representations without having two different types of records. Those who love SPF can have there DNS library compiled that it displays MARID records as SPF. Has advantages on command line tools. And others, including the MS world, can use XML representation. Good for programming languages. Important is that we have two representations, but only a *single* encoding. Only one type of DNS records. That's it. SPF or XML is not a matter of the record itself. It's a matter of the program you use to display the record. - MARID interpreters, those which are built into MTAs, can work directly on the encoding, e.g. ASN.1. This is actually easier or actually not more complicated than parsing SPF. You have automated tools for those who don't know ASN.1. And if you do, it is also a simple afternoons job to write a parser on your own in any available language. So in my eyes, this would be the best solution as long as we are bound to store MARID records in DNS (if not, see RMX++ proposal). regards Hadmut From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 05:21:44 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10481 for ; Wed, 23 Jun 2004 05:21:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5N8w90P016769; Wed, 23 Jun 2004 01:58:09 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5N8w9ZD016768; Wed, 23 Jun 2004 01:58:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5N8w8J7016736 for ; Wed, 23 Jun 2004 01:58:08 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: WEIP0BQCDzjyzrPrnLbNDw 1087981086 Received: from [192.168.5.111] (69-212-77-18.ded.ameritech.net [69.212.77.18]) by mail.messagingengine.com (Postfix) with ESMTP id 96658C0C5D8; Wed, 23 Jun 2004 04:58:05 -0400 (EDT) Message-ID: <40D9461C.1020900@elvey.com> Date: Wed, 23 Jun 2004 03:58:04 -0500 From: Matthew Elvey User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Douglas Otis Cc: "'IETF MARID WG'" , spf-discuss@v2.listbox.com Subject: Re: Why XML References: <013001c45881$488c5b80$2766f30a@development.greatgulfhomes.com> <40D87C90.9050601@danisch.de> <1087954632.22641.272.camel@ddev.mail-abuse.org> In-Reply-To: <1087954632.22641.272.camel@ddev.mail-abuse.org> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/22/04 8:37 PM, Douglas Otis sent forth electrons to convey: >... >Any mechanism introduced that stems the flow of UCE will be subjected to >intensive attack. Introducing a required series of DNS queries to >establish permissions increases a data footprint, but also code size may >also adversely impact system resources depending upon OS and structure. >If used in the normal fashion, no parser is required to utilize DNS >answers, so the introduction of a parser increases vulnerabilities. The >less rigid and more extensible the syntax, the greater the >vulnerabilities. As the allowable answer from DNS is small, any chained >records further increases vulnerabilities by increasing both resources >and time required to process a message. > >An attacker "jamming" the checking mechanism might set up DNS servers >for domains they control that respond erratically and offer complex >record sets with small TTLs. The attacker then sends messages from >their domains in an attempt to exhaust resources as a means to have >recipients disable the checking processes within the channel. If on >average a small enterprise uses two outside services, then normally >there will be a need to chain these records as it would be prohibitively >difficult to administer otherwise. These outside vendors may in turn >also outsource for yet more chaining. > >As example, a mail server is receiving 50 messages per second that >average 4 K bytes in size. If using the SPF/CID mechanism, checking DNS >data is indeterminate as there is no limit for the number of sequential >queries required to converge upon an answer. RFC1035 indicates 5 to 10 >seconds should be considered a worst case resolver interval. If there >becomes an average of 10 queries with an average of 5 seconds a query, >then this limits each process to about 1 message about every minute. >These 10 queries will also add to the traffic at 350 bytes per record a >total of 4K bytes of additional traffic for a doubling of the network >load. The mail server may normally handle 1,500 simultaneous processes, >but at 60 seconds per process, the mail server is reduced to only >running 25 messages a second. This may still represent the same amount >of network traffic, just half as much mail gets through the network. >... > > My mail server already checks over a dozen RBLs, plus doing Razor, DCC, and slews of header and body regexp checks. If MARID is effective enough for long enough that most spammers give up, then .... This will be more realistic: As example, a mail server is receiving 50 messages per second that average 4 K bytes in size. If using the SPF/CID mechanism, checking DNS data is indeterminate as there is no limit for the number of sequential queries required to converge upon an answer. RFC1035 indicates 5 to 10 seconds should be considered a worst case resolver interval. If there becomes an average of 4 queries with an average of 1 second a query, then this limits each process to about _ message about every minute. These 4 queries will also add to the traffic at 50 bytes per record a total of 0.2K bytes of additional traffic for a halving of the network load. The mail server may normally handle 1,500 simultaneous processes, but at 4 seconds per process, the mail server has spare capacity up to 'only' running 4000 messages a second. Of course, CSV queries are efficient even if most of the queries are against spammer domains. Also, you're assuming there are no DNS cache hits. Also, if an SPF query starts with a blacklist check of the domain and that fails, then no further queries will be made. That's efficient. But yeah, spammers trying to gum up the works will result in what you're talking about. From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 06:02:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12993 for ; Wed, 23 Jun 2004 06:02:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5N9nlbg042049; Wed, 23 Jun 2004 02:49:47 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5N9nlZ2042048; Wed, 23 Jun 2004 02:49:47 -0700 (PDT) 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.9) with ESMTP id i5N9nkrU042034 for ; Wed, 23 Jun 2004 02:49:47 -0700 (PDT) (envelope-from cm--jrk@merseymail.com) Received: from mmail by argon.connect.org.uk with local (connectmail/exim) id 1Bd4O0-00044R-Rc for ietf-mxcomp@imc.org; Wed, 23 Jun 2004 10:49:44 +0100 In-Reply-To: Subject: Re: Why not XML To: "IETF MARID WG" From: "Jon Kyme" X-Mailer: [ConnectMail 3.15.6] X-connectmail-Originating-IP: 172.25.243.3 Message-Id: Date: Wed, 23 Jun 2004 10:49:44 +0100 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "wayne": > * The XML parsers are often very big, compared with the MTAs. When > you double the amount of code, as in the case of qmail and libxml, > you are more than double the chances of a security hole or allow for > some sort of abusive XML document. Well, clearly, only an XML parsing application is vulnerable to an abusive XML document (whatever that is). That said, claiming that linking with a XML parsing library will "more than double" the chance of a security hole seems a little wild. I'd be very surprised if XML MARID documents exercised every single line of code in your XML library, so the absolute size of the library isn't necessarily significant, is it? If this kind of security is a such concern for you, the risk is easily mitigated by sensible application design (e.g. don't link it in, have a helper app). I don't see how it can be a show-stopper for XML, for us here. From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 06:50:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16189 for ; Wed, 23 Jun 2004 06:50:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NAfLIv052332; Wed, 23 Jun 2004 03:41:21 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NAfLev052331; Wed, 23 Jun 2004 03:41:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tidy.obscurity.org (tidy.obscurity.org [66.199.168.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NAfL9d052324 for ; Wed, 23 Jun 2004 03:41:21 -0700 (PDT) (envelope-from ksoze@obscurity.org) Received: by tidy.obscurity.org (Postfix, from userid 1000) id 6E84C69B1D; Wed, 23 Jun 2004 10:41:22 +0000 (UTC) Date: Wed, 23 Jun 2004 03:41:22 -0700 From: Sean Comeau To: Hadmut Danisch Cc: Greg Connor , IETF MARID WG Subject: Re: Emotions, Encoding, and Ignorance (Was: Why not XML) Message-ID: <20040623104122.GH30711@obscurity.org> References: <40D88827.5090904@danisch.de> <7242944.1087941275@[10.12.1.26]> <40D9267F.2010309@danisch.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40D9267F.2010309@danisch.de> User-Agent: Mutt/1.5.6i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Jun 23, 2004 at 08:43:11AM +0200, Hadmut Danisch wrote: > OK, let's come back to technical arguments. > excellent! > A/The major argument for using SPF is readability. I confirm that > readability is > a very strong and important argument. > > But is this correct? No, it isn't. Why not? > it is one reason. simplicity of the code that needs to be added to MTAs and making sure the records fit into 512 bytes is another. Your suggestion is the best in all these areas. > > I propose to start beeing aware of having to do two different jobs: > > - Define an internal encoding > > - Define an external representation > [...] I fully agree with you. That is clearly the proper way to do it. The original idea was to use TXT records first, make implementations that can use those available then hope that because the TXT records are in widespread use and because using TXT records that way is such an ugly kludge a new RR type would be created and the TXT record would go away. But people seemed to feel that getting everyone to upgrade their nameservers in addition to their MTAs would be an impossible task. Maybe this standard should ignore the TXT record after all and require a new MARID record. I'd be very happy with that solution. From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 07:04:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17953 for ; Wed, 23 Jun 2004 07:04:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NAuwti055087; Wed, 23 Jun 2004 03:56:58 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NAuwMt055086; Wed, 23 Jun 2004 03:56:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.michaelbrumm.com (h-68-167-225-114.phndaz91.covad.net [68.167.225.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NAuvSG055075 for ; Wed, 23 Jun 2004 03:56:58 -0700 (PDT) (envelope-from me@michaelbrumm.com) Received: from devon ([68.167.225.115]) by mail.michaelbrumm.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 23 Jun 2004 10:56:52 +0000 From: "Michael R. Brumm" To: "IETF MARID WG" Subject: RE: Why not XML Date: Wed, 23 Jun 2004 04:57:03 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <40D9267F.2010309@danisch.de> Importance: Normal X-OriginalArrivalTime: 23 Jun 2004 10:56:52.0911 (UTC) FILETIME=[CABF73F0:01C45910] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5NAuwSG055081 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hadmut Danisch wrote: >Because SPF has never been a technical invention. SPF is only a >public relations coup of a few people who were hijacking an idea >to bring themselves in front of the cameras and the newspapers. >I have spoken with several journalists who were intentionally >misinformed. I'm sure it came as a complete surprise to me that the SPF implementation I worked on for over a month was just a "public relations coup" and has "never been a technical invention". And intentionally misinformed journalists? Isn't that a bit redundant? Can a person actually be guilty of misinforming journalists, or does it occur naturally? >Readibility of SPF is based on wrong assumptions. It is based on >abusing TXT records. Abusing TXT records? Is this your "irony and sarcasm"? I honestly can't tell. >Have you ever seen DNS records from inside? How DNS records are >encoded? They are not readible. They are binary encoded. Using a binary encoding was thrown around a bit in the SPF community. There are plenty of obvious reasons why this wasn't seriously considered. There are already thousands of posts on why the TXT record is the best DNS record solution in the near-term, so I won't get into that. And expressing SPF as binary data in a TXT record makes a lot less sense than just using the SPF syntax. Obviously, the best technical solution would be a binary representation in a newly allocated RR type. However, this is not a practical solution for at least two more years. It really is too bad that RFC 3597 did not come out much earlier. >If we don't stick to SPF syntax, what will remain of the SPF >hype? Roughly nothing. That's the reason why so many people >desperately defend SPF syntax against any progress. They try >to enforce SPF syntax, because that's all SPF consists of. An alternative reason for people defending the SPF syntax might be that it has already progressed through an extensive community discussion, testing, validation, revision, and a significant deployment. That seems like a lot for something that consists of nothing more than a syntax. IMHO, if we don't come up with something soon, SPF will become the defacto-standard (arguably, it already is) without IETF ratification. We can make grand statements, facilitate discussion, and pass resolutions, but if a large enough constituency decides that the IETF has neglected action, then the void will be filled. I hope we have the wisdom to avoid this type of embarrassing and shameful situation. Michael R. Brumm From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 09:45:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00712 for ; Wed, 23 Jun 2004 09:45:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NDX1w1086091; Wed, 23 Jun 2004 06:33:01 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NDX1Z1086090; Wed, 23 Jun 2004 06:33:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from xuxa.iecc.com (xuxa.iecc.com [208.31.42.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NDX08V086082 for ; Wed, 23 Jun 2004 06:33:01 -0700 (PDT) (envelope-from johnl@iecc.com) Received: (qmail 7769 invoked by uid 100); 23 Jun 2004 13:33:02 -0000 Date: 23 Jun 2004 13:33:02 -0000 Message-ID: <20040623133302.7768.qmail@xuxa.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: Re: Why not XML In-Reply-To: Organization: I.E.C.C., Trumansburg NY USA Cc: jrk@merseymail.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > I'd be very surprised if XML MARID documents exercised every single > line of code in your XML library, so the absolute size of the > library isn't necessarily significant, is it? Bad guys can publish any complex and hostile MARID documents they want. Typical MARID documents are indeed likely to be pretty simple, but if word gets around that there's a bug in an XML library, how long will it take until there's MARID data to exploit it? Minutes, I'd guess. From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 09:49:13 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00744 for ; Wed, 23 Jun 2004 09:49:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NDbkBI086909; Wed, 23 Jun 2004 06:37:46 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NDbkJ6086908; Wed, 23 Jun 2004 06:37:46 -0700 (PDT) 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.9) with ESMTP id i5NDbk5m086902 for ; Wed, 23 Jun 2004 06:37:46 -0700 (PDT) (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 i5NDbmGI016779; Wed, 23 Jun 2004 06:37:48 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 23 Jun 2004 06:37:48 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Greg Connor'" , IETF MARID WG Subject: RE: Why not XML Date: Wed, 23 Jun 2004 06:37:46 -0700 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 have to be ready to deal with BOTH reactions, and since they are > emotional reactions, we can't explain them away. We can get > around them, > but not with engineering powers... the power to change an emotional > reaction is reserved only for the marketers :) If the objection to XML is entirely emotional surely our duty is to choose the right architectutral approach. The computing world decided that ASCII was its interchange standard a long time ago. Over the past five years the computing world decided that XML was its standard for data structures. This is a standards body, building standards on standards is usually considered to be the right approach to take. Phill From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 09:52:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00805 for ; Wed, 23 Jun 2004 09:52:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NDVeID085886; Wed, 23 Jun 2004 06:31:40 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NDVesl085885; Wed, 23 Jun 2004 06:31:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from republico.estv.ipv.pt (republico.estv.ipv.pt [193.137.7.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NDVbPf085868 for ; Wed, 23 Jun 2004 06:31:40 -0700 (PDT) (envelope-from lbruno@republico.estv.ipv.pt) Received: from lbruno by republico.estv.ipv.pt with local (Exim 4.22) id 1Bd7rm-0004PU-Vx for ietf-mxcomp@imc.org; Wed, 23 Jun 2004 14:32:42 +0100 Date: Wed, 23 Jun 2004 14:32:42 +0100 From: Luis Bruno To: IETF MARID WG Subject: Re: Emotions, Encoding, and Ignorance (Was: Why not XML) Message-ID: <20040623133242.GB16822@republico.estv.ipv.pt> Mail-Followup-To: IETF MARID WG References: <40D88827.5090904@danisch.de> <7242944.1087941275@[10.12.1.26]> <40D9267F.2010309@danisch.de> <20040623104122.GH30711@obscurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040623104122.GH30711@obscurity.org> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Sean Comeau wrote: > But people seemed to feel that getting everyone to upgrade their > nameservers in addition to their MTAs would be an impossible task. Not to defend Microsoft's existing design but I was under the impression that we're using TXT because of bad design choices by the DNS team at Microsoft. Specifically, they can't query for a new RR type when behind an ISA firewall. > Maybe this standard should [...] require a new MARID record. That's the "clean" approach. However, I don't know how hard that is for the sysadmins. The MTA must be upgraded, that's a given. Would upgrading DNS be a showstopper? You should be able to put structured, binary data in TXT anyway; that's how I read the RFC, anyway. Cheers, -- Luis Bruno UTM: 29T 629481E 4511776N 576m "14) Always remember that Windows NT administration is to Unix and WAN administration, as _Herbie The Love Bug_ is to _Citizen Kane_. Respect your elders and don't trivialize their work." -- Christian Wagner's Tips From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 10:04:05 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00914 for ; Wed, 23 Jun 2004 10:04:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NDsBsO090490; Wed, 23 Jun 2004 06:54:11 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NDsBcW090489; Wed, 23 Jun 2004 06:54:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from aismtp4g.bellsouth.com (aismtp4g.bellsouth.com [139.76.165.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NDsAWe090464 for ; Wed, 23 Jun 2004 06:54:11 -0700 (PDT) (envelope-from Damon.Sauer@BELLSOUTH.COM) Received: from 01al10015010113.ad.bls.com ([90.152.52.35] [90.152.52.35]) by aismtp4g.bellsouth.com with ESMTP for ietf-mxcomp@imc.org; Wed, 23 Jun 2004 09:53:58 -0400 Content-Class: urn:content-classes:message Subject: XML/SPF colaberation MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Wed, 23 Jun 2004 08:53:47 -0500 Message-Id: <38363D9940D92A458010AAE24D162EB9033BF25B@bremocog-55> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: normal Thread-Topic: XML/SPF colaberation Thread-Index: AcRZEQufO66byo/pRRuFSy3g6T5BNwAFmycg From: "Sauer, Damon" To: "IETF MARID WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5NDsBWe090483 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit This battle seems to be taking more and more casualties from both sides. People who were working closely together are now on opposite sides of the fence. I am reading as much as I can and with either scheme I can't see where this would not, at minimum, double the load on the DNS system. So if we are going to go down that path, I would like to submit a "What if" that could work for both proposals. It will require a change in code, but hopefully not a huge one. Could the record first have a pointer in DNS that would tell it where to look and how many bytes the record is? MAIL FROM: Joe@joejobs.com DNS lookup joejobs.com returns _MARID.joejobs.com/SPF/512 This tells the mail system that the record for joejobs.com is at _MARID.joejobs.com, the record is an SPF record and expect the record to be 512bytes long. It will require a second DNS lookup to the MARID record, but it will allow a choice of schema and help resolve the issue of buffer-overflows. I have not thought this through this at all. Just came to me. Regards, Damon Sauer ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 113 From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 10:09:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01047 for ; Wed, 23 Jun 2004 10:09:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NDw1V0091217; Wed, 23 Jun 2004 06:58:01 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NDw1fn091216; Wed, 23 Jun 2004 06:58:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from goose.ehsco.com (goose.ehsco.com [207.65.203.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NDw0If091201 for ; Wed, 23 Jun 2004 06:58:01 -0700 (PDT) (envelope-from ehall@ehsco.com) Received: from [207.65.71.20] (ferret.corp.ntrg.com [207.65.71.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Eric A. Hall", Issuer "Network Technology Research Group Certificate Authority" (verified OK)) by goose.ehsco.com (Postfix ) with ESMTP id 5F4D2460E9 for ; Wed, 23 Jun 2004 08:58:00 -0500 (CDT) Message-ID: <40D98C3A.3050002@ehsco.com> Date: Wed, 23 Jun 2004 08:57:14 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MARID WG Subject: Re: Why not XML References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/23/2004 8:37 AM, Hallam-Baker, Phillip wrote: > This is a standards body, building standards on standards is usually > considered to be the right approach to take. ...where it makes sense. Trying to tunnel HTTP/XML data-models over DNS doesn't make anymore sense than trying to flop it into ARP or ICMP or any other query/response datagram protocol. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 10:22:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02361 for ; Wed, 23 Jun 2004 10:22:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NE8NHn093217; Wed, 23 Jun 2004 07:08:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NE8NMh093216; Wed, 23 Jun 2004 07:08:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (catinthebox.net [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5NE8MZ5093208 for ; Wed, 23 Jun 2004 07:08:22 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Wed, 23 Jun 2004 09:11:53 -0400 Received: from ([68.223.169.60]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 1806960110; Wed, 23 Jun 2004 09:11:51 -0400 Message-ID: <00c201c45924$2e50f9d0$6401a8c0@hdev1> From: "Hector Santos" To: "IETF-MXCOMP" References: <81AC085044D04B429F5FB883D94FA1AF42A88E@df-fido-msg.exchange.corp.microsoft.com> <001301c4584d$34ea6880$6401a8c0@hdev1> <00c101c4587c$18b04250$6401a8c0@hdev1> Subject: Re: Drive Towards Consensus Date: Wed, 23 Jun 2004 09:15:24 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.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: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "wayne" To: "Hector Santos" Sent: Tuesday, June 22, 2004 1:40 PM Subject: Re: FW: Drive Towards Consensus > Caller-ID is dead. It looks like XML will be dead by the end of the > week. I think it is important for the MARID group see what you think. Also, I haven't been paying attention to our statistics over the last few months, but what I see now, June 2004 is the first month that the number of MCEP sites looked up is nearly equal to SPF sites. See http://www.winserver.com/antispam It should be noted the LMAP remains to be a extremely low percentage of the total anti-spam schema. Which brings up another important point related to what you like to bring up much: Total SPF domains currently published vs. MCEP. It is not the total domains in DNS but the "Personal Mail Community and Association" of a particular domain that defines the effectiveness of LMAP. If your domain has a lot of mail from a particular group, and this has a majority support for SPF, your rate will be high. But in general, this will not be the case. On the other hand, if the top ISPs domains exploited by spammers published LMAP records, then overall, everyone will benefit. In addition, if a community of related servers and her customers published records, they will all benefit among themselves as been the case with our network of customers. This all boils down to the #1 benefit of LMAP - protecting your own domain and as we have learned with our product development while implementing the LMAP methods, new SMTP designs should inherently include support for what I called Local DIPs: Local Domain/IP associations. Our statistics shows that atleast 10-15% of spoofers will use your own domains. That is an instant, highly low overhead optimal rejection at SMTP. DNS is not required. And it makes sense. The SMTP receiver should be looking at the 2821 HELO, MAIL FROM domains to perform a straight forward local DIP check. This should be a SMTP BCP or written into the RFC. Just imagine in terms of network topology, if every node did a local DIP check, it would result in major benefit both locally and as a network with absolutely NO DNS overhead, locally or network wide. Anyway, I hope this isn't a cut and dry issue as you stated "Caller ID is Dead", etc. I certainly hope not. I have voiced my opposition only to ONE CONCEPT that Caller ID promotes - 2822 validation I think this is the wrong direction for both local and network wide operations. This will be especially the case if a company like Microsoft does go ahead with Caller ID in her products. This will force many competitors and the industry to support it too thus instantly creating a new undesirable higher than normal PAYLOAD mode of operation. Yet, I am also on record that if we altered the SMTP transaction model to better interact with 2822 validation concepts, then I am for it. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 10:24:49 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02639 for ; Wed, 23 Jun 2004 10:24:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NEEgm0094413; Wed, 23 Jun 2004 07:14:42 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NEEgaI094412; Wed, 23 Jun 2004 07:14:42 -0700 (PDT) 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.9) with ESMTP id i5NEEfg4094405 for ; Wed, 23 Jun 2004 07:14:41 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i5NEEgT8005954; Wed, 23 Jun 2004 07:14:42 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 23 Jun 2004 07:14:42 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'John Levine'" , ietf-mxcomp@imc.org Cc: jrk@merseymail.com Subject: RE: Why not XML Date: Wed, 23 Jun 2004 07:14:41 -0700 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'd be very surprised if XML MARID documents exercised every single > > line of code in your XML library, so the absolute size of the > > library isn't necessarily significant, is it? > > Bad guys can publish any complex and hostile MARID documents they > want. Typical MARID documents are indeed likely to be pretty simple, > but if word gets around that there's a bug in an XML library, how long > will it take until there's MARID data to exploit it? Minutes, I'd > guess. This is uninformed scaremongering. If there is a bug in the XML parser libraries in use today it will be quickly uncovered by other applications where the consequences are likely to be more than a DDoS attack. The advantage of using standards is that you test out your software components in multiple environments. The XML parser in windows is used by IE, web services, etc. etc. The XML parser in apache has been extensively tested in other programs. This is one of the major benefits of standards and software architecture. Look, we know that the messaging world is currently adopting a major XML based standard - RSS/ATOM. It has already adopted HTML and may well adopt Jabber as a standard, if not Jabber whatever does succeed in that space will be a Web Service. So scaremongering about XML parsers is besides the point. I can write an XML parser in a couple of pages of code. All it takes is an FSM with a small amount of support code. It takes a lot more to write a validating parser, but not as much as you might think. And in any case, if you are still using a language that is vulnerable to buffer overflow issues you are a decade out of date. There are plenty of languages that implement bounds checking, Java, C#, FORTRAN, ALGOL60. If people want to write in C I can give them a couple of range checking macros which prevent overrun conditions - starting with: #define strncpy() exit(-1) Phill From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 10:38:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03091 for ; Wed, 23 Jun 2004 10:38:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NESgdv097303; Wed, 23 Jun 2004 07:28:42 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NESgWr097302; Wed, 23 Jun 2004 07:28:42 -0700 (PDT) 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.9) with ESMTP id i5NESfVY097284 for ; Wed, 23 Jun 2004 07:28:42 -0700 (PDT) (envelope-from hadmut@danisch.de) Received: (from hadmut@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) id i5NESbtl031428; Wed, 23 Jun 2004 16:28:37 +0200 From: hadmut@danisch.de Date: Wed, 23 Jun 2004 16:28:36 +0200 To: "Sauer, Damon" Cc: IETF MARID WG Subject: Re: XML/SPF colaberation Message-ID: <20040623142836.GA31067@danisch.de> References: <38363D9940D92A458010AAE24D162EB9033BF25B@bremocog-55> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <38363D9940D92A458010AAE24D162EB9033BF25B@bremocog-55> User-Agent: Mutt/1.5.6i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Jun 23, 2004 at 08:53:47AM -0500, Sauer, Damon wrote: > I am reading as much as I can and with either scheme I can't see where > this would not, at minimum, double the load on the DNS system. ... > Could the record first have a pointer in DNS that would tell it where > to look and how many bytes the record is? That's exactly the problem I tried to solve with RMX++. But nobody listens. Everyone is absolutely bound to the fixed idea of storing everything in DNS, no matter whether DNS is suitable or not. Nobody cares about how DNS works internally. Just (ab)use the TXT records as an arbitrary storage system. Did anyone ever listen to the DNS people who said "Don't do that"? Did anyone care about any other service than e-mail? Did anyone care about capacity of DNS servers? They say they don't want a new RR type to avoid the need of upgrading, therefore TXT is needed. Has anyone ever made a calculation about how much the average DNS traffic and storage will grow and how many DNS servers will need a hardware upgrade instead of just a software upgrade? Has anyone ever cared about the fact that DNS records are internally binary packed and that they usually do not store as text what we see when calling nslookup/dig? This whole SPF vs. XML discussion is ridiculous. This is not a technical discussion. This is a religious matter. This is SPF marketing. Hadmut From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 10:38:41 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03132 for ; Wed, 23 Jun 2004 10:38:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NERvoZ097157; Wed, 23 Jun 2004 07:27:57 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NERvQr097156; Wed, 23 Jun 2004 07:27:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NERsKT097137 for ; Wed, 23 Jun 2004 07:27:56 -0700 (PDT) (envelope-from aland@newgiles.nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id E084616FAB for ; Wed, 23 Jun 2004 10:34:36 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Why not XML In-Reply-To: Your message of "Wed, 23 Jun 2004 08:57:14 CDT." <40D98C3A.3050002@ehsco.com> Date: Wed, 23 Jun 2004 10:34:36 -0400 Message-Id: <20040623143436.E084616FAB@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Eric A. Hall" wrote: > Trying to tunnel HTTP/XML data-models over DNS doesn't make anymore sense > than trying to flop it into ARP or ICMP or any other query/response > datagram protocol. Similarly, trying to put URLs into DNS, and MARID data on web pages wouldn't make sense, as email would be dependent on yet another set of services. What about putting the MARID data in-line in SMTP via an extension? It can be signed, and the keys can go into DNS ala DK, which should validate it. It does mean that the barrier for adoption is higher, as more software has to change, but it does avoid the above problems. Of course, it means that caching of the data becomes more problematic. DNS takes care of that automatically, and that won't be possible if the data is inline. But at ~100 bytes per typical MARID record, itwouldn't be much of a problem to just re-send it. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 10:48:49 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04645 for ; Wed, 23 Jun 2004 10:48:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NEX6mu098649; Wed, 23 Jun 2004 07:33:06 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NEX6H9098648; Wed, 23 Jun 2004 07:33:06 -0700 (PDT) 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.9) with ESMTP id i5NEX4XA098641 for ; Wed, 23 Jun 2004 07:33:05 -0700 (PDT) (envelope-from hadmut@danisch.de) Received: (from hadmut@localhost) by sklave3.rackland.de (8.12.10/8.12.10/Debian-1) id i5NEX6nk031555 for ietf-mxcomp@imc.org; Wed, 23 Jun 2004 16:33:06 +0200 From: hadmut@danisch.de Date: Wed, 23 Jun 2004 16:33:06 +0200 To: IETF MARID WG Subject: Re: Emotions, Encoding, and Ignorance (Was: Why not XML) Message-ID: <20040623143306.GB31067@danisch.de> References: <40D88827.5090904@danisch.de> <7242944.1087941275@[10.12.1.26]> <40D9267F.2010309@danisch.de> <20040623104122.GH30711@obscurity.org> <20040623133242.GB16822@republico.estv.ipv.pt> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040623133242.GB16822@republico.estv.ipv.pt> User-Agent: Mutt/1.5.6i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Jun 23, 2004 at 02:32:42PM +0100, Luis Bruno wrote: > > Specifically, they can't query for a new RR type when behind an ISA > firewall. If so, then ISA is broken. Should we define a badly designed protocol just to workaround broken firewall software? That's a joke... Hadmut From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 11:12:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06497 for ; Wed, 23 Jun 2004 11:12:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NF3Xv0004255; Wed, 23 Jun 2004 08:03:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NF3XRl004254; Wed, 23 Jun 2004 08:03:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tom.iecc.com (tom.iecc.com [208.31.42.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NF3Wpg004240 for ; Wed, 23 Jun 2004 08:03:32 -0700 (PDT) (envelope-from johnl@iecc.com) Received: (qmail 2458 invoked from network); 23 Jun 2004 15:03:34 -0000 Received: (ofmipd 127.0.0.1); 23 Jun 2004 15:03:12 -0000 Date: 23 Jun 2004 11:03:34 -0400 Message-ID: From: "John R Levine" To: "Hallam-Baker, Phillip" Cc: "ietf-mxcomp@imc.org" , "jrk@merseymail.com" Subject: RE: Why not XML In-Reply-To: References: Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > If there is a bug in the XML parser libraries in use today it will be > quickly uncovered by other applications where the consequences are likely > to be more than a DDoS attack. I wouldn't disagree. The main argument agains XML in MARID is that designing for "extensibility" when we have no experience or agreement on what directions the extensions will take is unlikely to be useful. I think it's also a reasonable concern that a design that makes it easy to load up MARID records with lots of data is likely to lead to far more >512 DNS responses than we've had before, and we have no experience to tell us how much of a problem that will be, either. > And in any case, if you are still using a language that is vulnerable to > buffer overflow issues you are a decade out of date. Wel, sure, I write all my applications in perl these days. My MTA, like most MTAs, is written in C but it uses a set of string libraries that don't have the usual buffer overflow problems. Or course, there are a lot more kinds of bugs than buffer overflows, particularly if the semantics of your language (XML or otherwise) can induce its clients to fetch arbitrary data from sites of your choosing. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor "I dropped the toothpaste", said Tom, crestfallenly. From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 11:27:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08325 for ; Wed, 23 Jun 2004 11:27:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NFBtj7005866; Wed, 23 Jun 2004 08:11:55 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NFBt72005865; Wed, 23 Jun 2004 08:11:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.glyphic.com (mail.glyphic.com [216.218.209.57]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NFBtTQ005825 for ; Wed, 23 Jun 2004 08:11:55 -0700 (PDT) (envelope-from markl@glyphic.com) Received: from [192.168.1.150] (m208-18.dsl.rawbw.com [198.144.208.18]) by mail.glyphic.com (Postfix) with ESMTP id E3AD940DB for ; Wed, 23 Jun 2004 08:11:50 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v618) In-Reply-To: <20040623143306.GB31067@danisch.de> References: <40D88827.5090904@danisch.de> <7242944.1087941275@[10.12.1.26]> <40D9267F.2010309@danisch.de> <20040623104122.GH30711@obscurity.org> <20040623133242.GB16822@republico.estv.ipv.pt> <20040623143306.GB31067@danisch.de> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Lentczner Subject: Re: Emotions, Encoding, and Ignorance (Was: Why not XML) Date: Wed, 23 Jun 2004 08:11:50 -0700 To: IETF MARID WG X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, Jun 23, 2004 at 02:32:42PM +0100, Luis Bruno wrote: > Specifically, they can't query for a new RR type when behind an ISA > firewall. On Jun 23, 2004, at 7:33 AM, hadmut@danisch.de wrote: > If so, then ISA is broken. > > Should we define a badly designed protocol just to > workaround broken firewall software? That's a joke... Alas, yes. That is reality. There are too many deployed ISA systems. Oh well.... The same is true for SPF's original choice of TXT vs. a new RR type: There are too many deployed DNS infrastructures that can't handle a new RR type easily. - Mark Mark Lentczner http://www.ozonehouse.com/mark/ markl@glyphic.com From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 11:28:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08451 for ; Wed, 23 Jun 2004 11:28:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NFIAme007210; Wed, 23 Jun 2004 08:18:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NFIAkd007209; Wed, 23 Jun 2004 08:18:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from republico.estv.ipv.pt (republico.estv.ipv.pt [193.137.7.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NFI9EK007194 for ; Wed, 23 Jun 2004 08:18:10 -0700 (PDT) (envelope-from lbruno@republico.estv.ipv.pt) Received: from lbruno by republico.estv.ipv.pt with local (Exim 4.22) id 1Bd9Ww-0004Vy-8y for ietf-mxcomp@imc.org; Wed, 23 Jun 2004 16:19:18 +0100 Date: Wed, 23 Jun 2004 16:19:18 +0100 From: Luis Bruno To: IETF MARID WG Subject: Re: Emotions, Encoding, and Ignorance (Was: Why not XML) Message-ID: <20040623151918.GB17219@republico.estv.ipv.pt> Mail-Followup-To: IETF MARID WG References: <40D88827.5090904@danisch.de> <7242944.1087941275@[10.12.1.26]> <40D9267F.2010309@danisch.de> <20040623104122.GH30711@obscurity.org> <20040623133242.GB16822@republico.estv.ipv.pt> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040623133242.GB16822@republico.estv.ipv.pt> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Luis Bruno wrote: > The MTA must be upgraded, that's a given. Would upgrading DNS be a > showstopper? I meant: Would upgrading DNS servers be a show stopper? -- Luis Bruno UTM: 29T 629481E 4511776N 576m From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 11:30:44 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08538 for ; Wed, 23 Jun 2004 11:30:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NFFi5B006784; Wed, 23 Jun 2004 08:15:44 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NFFiU8006783; Wed, 23 Jun 2004 08:15:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from republico.estv.ipv.pt (tunadao.ipv.pt [193.137.7.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NFFhr8006776 for ; Wed, 23 Jun 2004 08:15:43 -0700 (PDT) (envelope-from lbruno@republico.estv.ipv.pt) Received: from lbruno by republico.estv.ipv.pt with local (Exim 4.22) id 1Bd9UZ-0004Vs-Bj for ietf-mxcomp@imc.org; Wed, 23 Jun 2004 16:16:51 +0100 Date: Wed, 23 Jun 2004 16:16:51 +0100 From: Luis Bruno To: IETF MARID WG Subject: Re: Emotions, Encoding, and Ignorance (Was: Why not XML) Message-ID: <20040623151651.GA17219@republico.estv.ipv.pt> Mail-Followup-To: IETF MARID WG References: <40D88827.5090904@danisch.de> <7242944.1087941275@[10.12.1.26]> <40D9267F.2010309@danisch.de> <20040623104122.GH30711@obscurity.org> <20040623133242.GB16822@republico.estv.ipv.pt> <20040623143306.GB31067@danisch.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040623143306.GB31067@danisch.de> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hadmut Danisch wrote: > Luis Bruno wrote: > > Specifically, they can't query for a new RR type when behind an ISA > > firewall. > > Should we define a badly designed protocol just to workaround broken > firewall software? That's a joke... Yes, the design is a joke. Of course the design is an error; but I've made worse ones in simpler stuff, so I won't flame them. However, we can put the information in TXT, and encode it the same way we would for a new RR type. Should we? I think we should not, but if it doesn't cost us much... I'd rather see Microsoft fixing their stuff. -- Luis Bruno UTM: 29T 629481E 4511776N 576m "14) Always remember that Windows NT administration is to Unix and WAN administration, as _Herbie The Love Bug_ is to _Citizen Kane_. Respect your elders and don't trivialize their work." -- Christian Wagner's Tips From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 11:30:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08541 for ; Wed, 23 Jun 2004 11:30:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NFK9UI007602; Wed, 23 Jun 2004 08:20:09 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NFK9AB007601; Wed, 23 Jun 2004 08:20:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (ntbbs.winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5NFK8dj007595 for ; Wed, 23 Jun 2004 08:20:08 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Wed, 23 Jun 2004 11:23:49 -0400 Received: from ([68.223.169.60]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 1814876891; Wed, 23 Jun 2004 11:23:48 -0400 Message-ID: <011501c45936$9d5fbde0$6401a8c0@hdev1> From: "Hector Santos" To: "Hallam-Baker, Phillip" , Cc: References: Subject: Re: Why not XML Date: Wed, 23 Jun 2004 11:27:31 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.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: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Hallam-Baker, Phillip" To: "'John Levine'" ; Cc: Sent: Wednesday, June 23, 2004 10:14 AM Subject: RE: Why not XML > > > > I'd be very surprised if XML MARID documents exercised every single > > > line of code in your XML library, so the absolute size of the > > > library isn't necessarily significant, is it? > > > > Bad guys can publish any complex and hostile MARID documents they > > want. Typical MARID documents are indeed likely to be pretty simple, > > but if word gets around that there's a bug in an XML library, how long > > will it take until there's MARID data to exploit it? Minutes, I'd > > guess. > > This is uninformed scaremongering. Maybe, but it also a reality. > If there is a bug in the XML parser libraries in use today it will be > quickly uncovered by other applications where the consequences are likely > to be more than a DDoS attack. But as the CodeRed Principle as shown, there will always be enough of a legacy market to still be effective. That is the key most "Ah HA!" discovery, although obvious, that all the hackers have based thier continued hacking on. Its no longer a "Its not worth it." idea. It is 'Lets do it and put it out there. Its bound to find a good number of vulnerable systems." Geez, we still get daily doses of the original CodeRed HTTP request exploits shown in our logs and I keep getting people asking "Hey, what is that?" Go Figure. > The advantage of using standards is that you test out your software > components in multiple environments. The XML parser in windows is > used by IE, web services, etc. etc. The XML parser in apache has been > extensively tested in other programs. Yes, modular programming is benefitial. Both for technical and management reasons. But it is based on having a solid development and design, well tested and not put out before its time. Over the years, can you vouch for Microsoft having a solid engineering team with enough foresight? XP was suppose to be the next secured OS. Well, it turned out to be among the most unsecured OS to to the point the next XP update will fundamentally change a few things and also BREAK alot of software. Anyway, can you vouch that some undocumented enbedded XML attribute that does some undocumented logic doing the object instantiation and parsing is not going to be there? Keep in mind, most people are going to use XML libraries and to do so requires a level of trust and confidence there is not going to be any problems. > Look, we know that the messaging world is currently adopting a major > XML based standard - RSS/ATOM. It has already adopted HTML and may > well adopt Jabber as a standard, if not Jabber whatever does succeed > in that space will be a Web Service. But XML is just a interchange format. It might be a storage format for a NEW systems. But not for standard systems already in place. i.e, XML Web service as a interface into our database backend. That does mean we will use XML for storage. That would be ludricrous. Maybe for a new system just getting into the message world. But I don't see this as became the standard method across the board. > And in any case, if you are still using a language that is vulnerable to > buffer overflow issues you are a decade out of date. Phillip good point, but it might not be the language but the API or the library you are using!. In this case, the XML API components/library or sub-system! Thats been the problem with Microsoft OSes and her API support system. Sure, the applications developers too are all part the problem. But by far, its been the OS and API in Windows. > There are plenty of > languages that implement bounds checking, Java, C#, FORTRAN, ALGOL60. > If people want to write in C I can give them a couple of range checking > macros which prevent overrun conditions - starting with: > > #define strncpy() exit(-1) Remember, there is no such thing as a bad language, just bad programmers. Anyway, I am going to support XML but not using the Microsoft XML library. To use it, requires you to load ATL, ACTIVEX and a whole range of other sub-systems into your product and that is where a GOOD bit of the insecurity evolved from - the OLE introduction into Windows. So I don't think it is scaremongering, but rather a fact of life especially in the Windows world. With all due respect, if you don't know this, you haven't been doing much Windows Development then. With that said, each person/developer needs to makes its own decision on how they will implement XML. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 11:38:49 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09061 for ; Wed, 23 Jun 2004 11:38:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NFK7gm007584; Wed, 23 Jun 2004 08:20:07 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NFK7Qd007583; Wed, 23 Jun 2004 08:20:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.glyphic.com (mail.glyphic.com [216.218.209.57]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NFK6Cv007559 for ; Wed, 23 Jun 2004 08:20:06 -0700 (PDT) (envelope-from markl@glyphic.com) Received: from [192.168.1.150] (m208-18.dsl.rawbw.com [198.144.208.18]) by mail.glyphic.com (Postfix) with ESMTP id 8142F40D3 for ; Wed, 23 Jun 2004 08:20:04 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v618) In-Reply-To: <40D9267F.2010309@danisch.de> References: <40D88827.5090904@danisch.de> <7242944.1087941275@[10.12.1.26]> <40D9267F.2010309@danisch.de> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Lentczner Subject: Re: Emotions, Encoding, and Ignorance (Was: Why not XML) Date: Wed, 23 Jun 2004 08:20:03 -0700 To: IETF MARID WG X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jun 22, 2004, at 11:43 PM, Hadmut Danisch wrote: > Because this is an endless loop. An emotional loop. Caused by SPF. > > Why? > > Because SPF has never been a technical invention. SPF is only a public > relations coup of > a few people who were hijacking an idea to bring themselves in front > of the cameras > and the newspapers. Okay, assuming you mean Meng, and myself in this group, I am very insulted. How dare you imply that the countless hours of work we have put into this are for self-aggrandizement. I don't get paid for this work, nor do I even work for a company that sponsors my involvement. I volunteered my efforts to help a build a tool for everyone. > OK, let's come back to technical arguments. Sorry, I can't right now. I'm far too upset by what you've said above. I am stunned that you would proceed in such a unprofessional manner, and in the public forum of a standards body working group. If your goal was to stymie any rational discussion, you've succeeded. - Mark Lentczner Mark Lentczner http://www.ozonehouse.com/mark/ markl@glyphic.com From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 11:47:27 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09460 for ; Wed, 23 Jun 2004 11:47:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NFXvRG010279; Wed, 23 Jun 2004 08:33:57 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NFXv9a010278; Wed, 23 Jun 2004 08:33:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (mail.catinthebox.net [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5NFXuNi010263 for ; Wed, 23 Jun 2004 08:33:56 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Wed, 23 Jun 2004 11:37:37 -0400 Received: from ([68.223.169.60]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 1815705032; Wed, 23 Jun 2004 11:37:36 -0400 Message-ID: <012701c45938$8b03a8d0$6401a8c0@hdev1> From: "Hector Santos" To: , "Sauer, Damon" Cc: "IETF MARID WG" References: <38363D9940D92A458010AAE24D162EB9033BF25B@bremocog-55> <20040623142836.GA31067@danisch.de> Subject: Re: XML/SPF colaberation Date: Wed, 23 Jun 2004 11:41:02 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.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: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: To: "Sauer, Damon" Cc: "IETF MARID WG" Sent: Wednesday, June 23, 2004 10:28 AM Subject: Re: XML/SPF colaberation > > Has anyone ever made a calculation about how much the > average DNS traffic and storage will grow and how many > DNS servers will need a hardware upgrade instead of just > a software upgrade? > > Has anyone ever cared about the fact that DNS records are > internally binary packed and that they usually do not > store as text what we see when calling nslookup/dig? I don't enough about the DNS server side, but the traffic concerns has been thee numero uno issue I had with this whole LMAP/DNS concept since day one. I mean, it was pretty obvious once you got into it: Remember, the MAJORITY of the mail is spoofed, nearly 60-80% by most industry standards which matches exactly what we see. So for 60-80% of your transactions, you will be exerting a high level of DNS activity resulting in NXDOMAIN or No Records. When we finished our system, it was still not ready for release because the overhead was still too high. Once we implicated what I deem an Important concept recommended and writing in RFC 2821, we reduced the overhead by nearly 35%! With this and additional reduction items that minimized all DNS lookup requirements, we finally released the product. Said one linux developer, "he seen other systems using the same anti-spam features, but your method is more efficient." So efficiency is very important people. But having spoken to some people who seem to have some DNS background, they gave me the idea, this LOOKUP overhead is a non-issue. I kept scratching my head about this because it can't see how it can not be an issue. > This whole SPF vs. XML discussion is ridiculous. > This is not a technical discussion. > This is a religious matter. > This is SPF marketing. I Agree. We need to take our time and do this right. From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 12:00:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10316 for ; Wed, 23 Jun 2004 12:00:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NFijBv012454; Wed, 23 Jun 2004 08:44:45 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NFijOL012453; Wed, 23 Jun 2004 08:44:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from goose.ehsco.com (goose.ehsco.com [207.65.203.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NFijLF012447 for ; Wed, 23 Jun 2004 08:44:45 -0700 (PDT) (envelope-from ehall@ehsco.com) Received: from [207.65.71.20] (ferret.corp.ntrg.com [207.65.71.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Eric A. Hall", Issuer "Network Technology Research Group Certificate Authority" (verified OK)) by goose.ehsco.com (Postfix ) with ESMTP id 6F29A5FD0B for ; Wed, 23 Jun 2004 10:44:47 -0500 (CDT) Message-ID: <40D9A540.30006@ehsco.com> Date: Wed, 23 Jun 2004 10:44:00 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-mxcomp@imc.org Subject: Re: Why not XML References: <20040623143436.E084616FAB@mail.nitros9.org> In-Reply-To: <20040623143436.E084616FAB@mail.nitros9.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/23/2004 9:34 AM, Alan DeKok wrote: > What about putting the MARID data in-line in SMTP via an extension? > It can be signed, and the keys can go into DNS ala DK, which should > validate it. It does mean that the barrier for adoption is higher, as > more software has to change, but it does avoid the above problems. There are lots of good reasons to do this. For one thing, you can define whatever lookup-keys you want, meaning that you can ~extend into per-user policy statements, for example. You can also take advantage of existing AUTH mechanisms to publish ~public policies versus ~private policies. It seems to me that if we really want infinitely extensible policy docs, these kinds of features are going to be important, and given that DNS *DOES NOT* support these kinds of things easily that an appropriate design would favor some kind of service. Note that all of the above assumes that policy will be interpreted by the recipient system, which is not necessarily required. A sender-side policy daemon that returns YES/NO/MAYBE could also work. > Of course, it means that caching of the data becomes more > problematic. DNS takes care of that automatically, and that won't be > possible if the data is inline. But at ~100 bytes per typical MARID > record, itwouldn't be much of a problem to just re-send it. Cache meta-data can be embedded into the XML pretty easily (especially if message-size is no longer an issue), so the real issue is tracking and cleanup code, which nobody wants to write, and which comes with DNS 'for free' [sic]. There are other problems with reusing SMTP -- the biggest one I can think of is the excessive number of round-trip times, which imposes significant latency considerations. Connect->HELO->POLICY-> to a laden serve behind a slow link in ~Ukraine can be expensive. Probably the best generalized approach to the "where's the policy" issue (assumng such a design is taken) is to use a URI syntax, and to define things like SMTP:host and SMTP:MX:domain as eligible candidates (those syntaxes would be useful for other things anyway). -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 12:13:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11066 for ; Wed, 23 Jun 2004 12:13:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NFwtuH015545; Wed, 23 Jun 2004 08:58:55 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NFwtZq015542; Wed, 23 Jun 2004 08:58:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from republico.estv.ipv.pt (republico.estv.ipv.pt [193.137.7.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NFwsBm015527 for ; Wed, 23 Jun 2004 08:58:54 -0700 (PDT) (envelope-from lbruno@republico.estv.ipv.pt) Received: from lbruno by republico.estv.ipv.pt with local (Exim 4.22) id 1BdAAM-0004Yd-M7 for ietf-mxcomp@imc.org; Wed, 23 Jun 2004 17:00:02 +0100 Date: Wed, 23 Jun 2004 17:00:02 +0100 From: Luis Bruno To: IETF MARID WG Subject: Re: XML/SPF colaberation Message-ID: <20040623160002.GA17466@republico.estv.ipv.pt> Mail-Followup-To: IETF MARID WG References: <38363D9940D92A458010AAE24D162EB9033BF25B@bremocog-55> <20040623142836.GA31067@danisch.de> <012701c45938$8b03a8d0$6401a8c0@hdev1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <012701c45938$8b03a8d0$6401a8c0@hdev1> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hector Santos wrote: > Remember, the MAJORITY of the mail is spoofed, nearly 60-80% by most > industry standards which matches exactly what we see. So for 60-80% of > your transactions, you will be exerting a high level of DNS activity > resulting in NXDOMAIN or No Records. Or, if this effort is successful, you get cache hits... ... if it's still cached, that is. Bigger records will result in more cache churn, if I understand DNS correctly. -- Luis Bruno UTM: 29T 629481E 4511776N 576m From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 12:17:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11250 for ; Wed, 23 Jun 2004 12:17:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NG56I9016873; Wed, 23 Jun 2004 09:05:06 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NG56pZ016872; Wed, 23 Jun 2004 09:05:06 -0700 (PDT) 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.9) with ESMTP id i5NG55eN016865 for ; Wed, 23 Jun 2004 09:05:05 -0700 (PDT) (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 i5NG57oj001878; Wed, 23 Jun 2004 18:05:07 +0200 Received: from danisch.de (localhost [127.0.0.1]) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-5) with ESMTP id i5NG0loa017538; Wed, 23 Jun 2004 18:00:47 +0200 Message-ID: <40D9A92F.8050707@danisch.de> Date: Wed, 23 Jun 2004 18:00:47 +0200 From: Hadmut Danisch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040528 Debian/1.6-7 X-Accept-Language: de-de MIME-Version: 1.0 To: "Michael R. Brumm" CC: IETF MARID WG Subject: Re: Why not XML References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Michael R. Brumm wrote: > >I'm sure it came as a complete surprise to me that the SPF implementation I worked on for over a month was just a "public relations coup" and has "never been a technical invention". > > Just spending a month of time doesn't necessarily turn anything into a technical invention. >And intentionally misinformed journalists? Isn't that a bit redundant? Can a person actually be guilty of misinforming journalists, or does it occur naturally? > > Oh yes, a person can intentionally tell the untruth in order to cause the journalist to write the untruth. This is what happened. >Abusing TXT records? Is this your "irony and sarcasm"? I honestly can't tell. > > Ask the DNS people. They'll explain. > >Obviously, the best technical solution would be a binary representation in a newly allocated RR type. However, this is not a practical solution for at least two more years. > Thank you very much for confirming this as the best technical solution. This is exactly where all this discussion started, this is what RMX is. RMX was and is a binary representation in a newly allocated RR type. May I remember you that SPF started as a plagiarism of RMX and was explicitely announced as such? The only "invention" of SPF was to not use a new RR type and to not use binary representation (which was, if I remember well, taken from another proposal). For the purpose of discussion, let's assume that your estimation about two years is correct: RMX is almost two years old by now. SPF is a little bit more than one year old. The SPF circus caused a severe delay in the evolution of such a mechanism, a delay of about a year right now. SPF was the idea to use plaintext in TXT records. And now you say that the best technical solution would be a binary representation in a newly allocated RR type, as RMX proposed from the very beginning, but we can't do this anymore because we now lack that time we've lost through the SPF circus proposing a different way that you now consider as worse? Don't you say that SPF prevented exactly that what you yourself call "the best technical solution"? Is that what you call a technical invention? Hadmut From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 12:29:58 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11974 for ; Wed, 23 Jun 2004 12:29:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NGGvUJ019277; Wed, 23 Jun 2004 09:16:57 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NGGvui019276; Wed, 23 Jun 2004 09:16:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NGGv1p019260 for ; Wed, 23 Jun 2004 09:16:57 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.0.1.153] ([::ffff:64.83.8.178]) (AUTH: LOGIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Wed, 23 Jun 2004 12:16:57 -0400 id 0005C545.40D9ACF9.0000447B In-Reply-To: <40D9267F.2010309@danisch.de> References: <40D88827.5090904@danisch.de> <7242944.1087941275@[10.12.1.26]> <40D9267F.2010309@danisch.de> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: IETF MARID WG From: Andrew Newton Subject: STOP NOW! (was Re: Emotions, Encoding, and Ignorance (Was: Why not XML)) Date: Wed, 23 Jun 2004 12:16:54 -0400 To: Hadmut Danisch X-Mailer: Apple Mail (2.613) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jun 23, 2004, at 2:43 AM, Hadmut Danisch wrote: > Because SPF has never been a technical invention. SPF is only a public > relations coup of > a few people who were hijacking an idea to bring themselves in front > of the cameras > and the newspapers. I have spoken with several journalists who were > intentionally misinformed. > If you don't believe this, just have a look at the ASRG history. Hadmut, This is clearly in violation of the code of conduct I asked all participants to observe, just 6 days ago: http://www.imc.org/ietf-mxcomp/mail-archive/msg02079.html Consider this your first and last warning. -andy From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 12:41:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12410 for ; Wed, 23 Jun 2004 12:41:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NGSgkO022142; Wed, 23 Jun 2004 09:28:42 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NGSgqX022141; Wed, 23 Jun 2004 09:28:42 -0700 (PDT) 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.9) with ESMTP id i5NGSfPF022123 for ; Wed, 23 Jun 2004 09:28:41 -0700 (PDT) (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.34) id 1BdAbt-0005nr-CO for ietf-mxcomp@imc.org; Wed, 23 Jun 2004 11:28:44 -0500 To: "IETF MARID WG" References: <81AC085044D04B429F5FB883D94FA1AF42A88E@df-fido-msg.exchange.corp.microsoft.com> <001301c4584d$34ea6880$6401a8c0@hdev1> <00c101c4587c$18b04250$6401a8c0@hdev1> <00c201c45924$2e50f9d0$6401a8c0@hdev1> From: wayne Reply-To: "IETF MARID WG" Date: Wed, 23 Jun 2004 11:28:29 -0500 In-Reply-To: <00c201c45924$2e50f9d0$6401a8c0@hdev1> (Hector Santos's message of "Wed, 23 Jun 2004 09:15:24 -0400") 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 (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: Drive Towards Consensus Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-4.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <00c201c45924$2e50f9d0$6401a8c0@hdev1> "Hector Santos" writes: > ----- Original Message ----- > From: "wayne" > To: "Hector Santos" > >> Caller-ID is dead. It looks like XML will be dead by the end of the >> week. > > I think it is important for the MARID group see what you think. Well, I don't know if it is normal business practices of Santronics Software, Inc to take private email conversations public, but I will stand by what I was quoted saying. Whether MicroSoft adopts $MARID or not, I really doubt that they will stick with the Caller-ID XML schema (the context of the private emails). Their newer Sender-ID XML schema is both more compact and more powerful. So, yes, I think that Caller-ID is dead. And, yes, it looks to me like XML will be dead by the end of the week. I'm sure everyone here is perfectly capable of deciding how this looks to them. I really doubt that everyone sees eye-to-eye on this issue. > Which brings up another important point related to what you like to bring up > much: Total SPF domains currently published vs. MCEP. Yes, as I mentioned in my private email to you, I plan on publishing an update to my 1.3 million email domain name search today, now that I'm below the 3-post/day suggested limit. -wayne From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 12:41:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12462 for ; Wed, 23 Jun 2004 12:41:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NGUAMZ022467; Wed, 23 Jun 2004 09:30:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NGUA2h022466; Wed, 23 Jun 2004 09:30:10 -0700 (PDT) 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.9) with ESMTP id i5NGU96e022446 for ; Wed, 23 Jun 2004 09:30:09 -0700 (PDT) (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 i5NGU5U6002500; Wed, 23 Jun 2004 18:30:05 +0200 Received: from danisch.de (localhost [127.0.0.1]) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-5) with ESMTP id i5NGPikV018736; Wed, 23 Jun 2004 18:25:44 +0200 Message-ID: <40D9AF08.8020706@danisch.de> Date: Wed, 23 Jun 2004 18:25:44 +0200 From: Hadmut Danisch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040528 Debian/1.6-7 X-Accept-Language: de-de MIME-Version: 1.0 To: Mark Lentczner CC: IETF MARID WG Subject: Re: Emotions, Encoding, and Ignorance (Was: Why not XML) References: <40D88827.5090904@danisch.de> <7242944.1087941275@[10.12.1.26]> <40D9267F.2010309@danisch.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Mark Lentczner wrote: > Okay, assuming you mean Meng, and myself in this group, I am very > insulted. And I felt insulted by what newspapers were writing. But I didn't mean you. And I didn't mean Meng in first place. If you don't know whom I was talking about then you simply don't know what happened in the "history". Maybe you should be better informed before considering yourself as being insulted. > How dare you imply that the countless hours of work we have put into > this are for self-aggrandizement. I dare. Because I have spent not less hours of work, and I didn't get paid either. > I don't get paid for this work, nor do I even work for a company that > sponsors my involvement. I don't get paid for this either, and I do not get sponsored. I even paid the flight to and the stay in San Francisco just for being fooled at the IETF last year at a time were I was unemployed, just to see other people placing themselves in front of the cameras an microphones by giving false information. And I will pay again the flight to IETF in August and will give my vacation days without beeing sponsored. I have spent several months of work and discussion. So don't tell me about beeing insulted. > Sorry, I can't right now. I'm far too upset by what you've said > above. I am stunned that you would proceed in such a unprofessional > manner, and in the public forum of a standards body working group. So everybody who questions SPF or misinforming the press is unprofessional? Inform yourself about the history of SPF before you raise such claims. Do you know that some of the SPF defenders claimed that plagiarism was legitimate because I had failed to do proper marketing for RMX? And you are feeling upset? Hadmut From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 12:46:30 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12659 for ; Wed, 23 Jun 2004 12:46:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NGZEL9023428; Wed, 23 Jun 2004 09:35:14 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NGZEEH023427; Wed, 23 Jun 2004 09:35:14 -0700 (PDT) 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.9) with ESMTP id i5NGZ4df023391 for ; Wed, 23 Jun 2004 09:35:05 -0700 (PDT) (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 i5NGZ7eQ002694; Wed, 23 Jun 2004 18:35:07 +0200 Received: from danisch.de (localhost [127.0.0.1]) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-5) with ESMTP id i5NGWPcr018976; Wed, 23 Jun 2004 18:32:25 +0200 Message-ID: <40D9B098.9000508@danisch.de> Date: Wed, 23 Jun 2004 18:32:24 +0200 From: Hadmut Danisch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040528 Debian/1.6-7 X-Accept-Language: de-de MIME-Version: 1.0 To: Alan DeKok , ietf-mxcomp@imc.org Subject: Re: Why not XML References: <20040623143436.E084616FAB@mail.nitros9.org> In-Reply-To: <20040623143436.E084616FAB@mail.nitros9.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Alan DeKok wrote: > What about putting the MARID data in-line in SMTP via an extension? >It can be signed, and the keys can go into DNS ala DK, which should >validate it. > Actually not a bad idea, but two counter arguments: - This is based on cryptography. This means it has to cope with secret keys. We do not have the hardware to keep secret keys secret. Remember that there are spam armys built from hundres of thousands of machines infected with mailicous code. This code is already collected license keys and such stuff. The same people who wrote this software would immediately start to write routines to collect the keys to generate false records. Today you can buy collections of e-mail address lists. Tomorrow they will come with stolen keys. You would need to have a highly protected issuer of such records. Do you thing thats practical and feasible? - If you, on the other hand, give every sender or domain owner a key to generate the record himself, why to bother with this at all? Why not simply signing the message itself? regards Hadmut From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 13:18:09 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAB14436 for ; Wed, 23 Jun 2004 13:18:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NH9vgc030625; Wed, 23 Jun 2004 10:09:57 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NH9vc2030624; Wed, 23 Jun 2004 10:09:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NH9tFU030596 for ; Wed, 23 Jun 2004 10:09:55 -0700 (PDT) (envelope-from aland@newgiles.nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 18E2816FAB for ; Wed, 23 Jun 2004 13:16:39 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Why not XML In-Reply-To: Your message of "Wed, 23 Jun 2004 10:44:00 CDT." <40D9A540.30006@ehsco.com> Date: Wed, 23 Jun 2004 13:16:39 -0400 Message-Id: <20040623171639.18E2816FAB@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Eric A. Hall" wrote: > There are other problems with reusing SMTP -- the biggest one I can think > of is the excessive number of round-trip times, which imposes significant > latency considerations. Connect->HELO->POLICY-> to a laden serve behind a > slow link in ~Ukraine can be expensive. It's one more SMTP command/response transaction, but that process can be shortened. e.g. As a hack, putting a hash of the policy into the EHLO name. If the recipient recognizes the hash, then the server knows the policy, can apply it, and SMTP proceeds unchanged. If the server doesn't recognize the hash, it can respond with a "policy" request, while simultaneously doing a DNS lookup for the key which signs that policy. In that case, the policy exchange imposes a latency once, and then it can be cached. All that has to go into DNS is a key for signing policies, and a statement saying "yes, we have an SMTP policy: please use SMTP extensions to ask for it." If rogue clients claim association with a domain, they either won't supply a policy (and thus get rejected, due to the domains published requirements), or they can supply a non-signed policy (and thus get rejected), or they can supply the domain's policy, and thus have that policy applied to them. > Probably the best generalized approach to the "where's the policy" issue > (assumng such a design is taken) is to use a URI syntax, and to define > things like SMTP:host and SMTP:MX:domain as eligible candidates (those > syntaxes would be useful for other things anyway). Sounds reasonable. That way we can kill two birds with one stone: DNS will supply information that "our policy is at URI foo", and that policy can be fetched via HTTP, FTP, or supplied in-line in SMTP, if there's an "in-line SMTP" URI. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 13:21:50 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14659 for ; Wed, 23 Jun 2004 13:21:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NHFkdD032143; Wed, 23 Jun 2004 10:15:46 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NHFki8032142; Wed, 23 Jun 2004 10:15:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NHFjP4032135 for ; Wed, 23 Jun 2004 10:15:45 -0700 (PDT) (envelope-from aland@newgiles.nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 21A0016FAB for ; Wed, 23 Jun 2004 13:22:31 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: Why not XML In-Reply-To: Your message of "Wed, 23 Jun 2004 18:32:24 +0200." <40D9B098.9000508@danisch.de> Date: Wed, 23 Jun 2004 13:22:31 -0400 Message-Id: <20040623172231.21A0016FAB@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hadmut Danisch wrote: > - This is based on cryptography. This means it has to cope with > secret keys. We do not have the hardware to keep secret > keys secret. The keys don't have to be that secret if they can change periodically. > The same people who wrote this software would immediately > start to write routines to collect the keys to generate > false records. How? > You would need to have a highly protected issuer of such > records. Do you thing thats practical and feasible? People already control access to their MTA's. I don't see this as much of a problem. > - If you, on the other hand, give every sender or domain owner > a key to generate the record himself, why to bother with this > at all? Why not simply signing the message itself? The message is not the SMTP transation. Putting the policy exchange into the SMTP transaction is semantically similar to using STARTTLS with a client certificate signed by a CA, and then supplying the policy in-line in the TLS tunnel. All of the key exchange issues devolve to getting the key for a root CA, and using it to verify another certificate. The difficulty with that approach is the repudiation of certificates is hard. There's no easy way to distribute certificate revocations, unlike putting ephemeral keys into DNS, where they can expire as quickly as you want. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 13:27:27 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14939 for ; Wed, 23 Jun 2004 13:27:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NHIl5k032684; Wed, 23 Jun 2004 10:18:47 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NHIlLr032683; Wed, 23 Jun 2004 10:18:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.mail-abuse.org [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NHIld3032666 for ; Wed, 23 Jun 2004 10:18:47 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.mail-abuse.org (DDev.mail-abuse.org [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id BDB0E414AC; Wed, 23 Jun 2004 10:18:45 -0700 (PDT) Subject: Re: Why XML From: Douglas Otis To: Matthew Elvey Cc: "'IETF MARID WG'" , spf-discuss@v2.listbox.com In-Reply-To: <40D9461C.1020900@elvey.com> References: <013001c45881$488c5b80$2766f30a@development.greatgulfhomes.com> <40D87C90.9050601@danisch.de> <1087954632.22641.272.camel@ddev.mail-abuse.org> <40D9461C.1020900@elvey.com> Content-Type: text/plain Message-Id: <1088011125.23558.123.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 23 Jun 2004 10:18:45 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-06-23 at 01:58, Matthew Elvey wrote: > On 6/22/04 8:37 PM, Douglas Otis sent forth electrons to convey: > > >... > >Any mechanism introduced that stems the flow of UCE will be subjected to > >intensive attack. Introducing a required series of DNS queries to > >establish permissions increases a data footprint, but also code size may > >also adversely impact system resources depending upon OS and structure. > >If used in the normal fashion, no parser is required to utilize DNS > >answers, so the introduction of a parser increases vulnerabilities. The > >less rigid and more extensible the syntax, the greater the > >vulnerabilities. As the allowable answer from DNS is small, any chained > >records further increases vulnerabilities by increasing both resources > >and time required to process a message. > > > >An attacker "jamming" the checking mechanism might set up DNS servers > >for domains they control that respond erratically and offer complex > >record sets with small TTLs. The attacker then sends messages from > >their domains in an attempt to exhaust resources as a means to have > >recipients disable the checking processes within the channel. If on > >average a small enterprise uses two outside services, then normally > >there will be a need to chain these records as it would be prohibitively > >difficult to administer otherwise. These outside vendors may in turn > >also outsource for yet more chaining. > > > >As example, a mail server is receiving 50 messages per second that > >average 4 K bytes in size. If using the SPF/CID mechanism, checking DNS > >data is indeterminate as there is no limit for the number of sequential > >queries required to converge upon an answer. RFC1035 indicates 5 to 10 > >seconds should be considered a worst case resolver interval. If there > >becomes an average of 10 queries with an average of 5 seconds a query, > >then this limits each process to about 1 message about every minute. > >These 10 queries will also add to the traffic at 350 bytes per record a > >total of 4K bytes of additional traffic for a doubling of the network > >load. The mail server may normally handle 1,500 simultaneous processes, > >but at 60 seconds per process, the mail server is reduced to only > >running 25 messages a second. This may still represent the same amount > >of network traffic, just half as much mail gets through the network. > >... > > My mail server already checks over a dozen RBLs, plus doing Razor, DCC, > and slews of header and body regexp checks. If MARID is effective enough > for long enough that most spammers give up, then .... Unlike these queries in parallel to _known_ servers, the SPF/CID schemes involve a series of queries to _unknown_ and possibly hostile name servers. The SPF/CID _may_ be effective against some false representations, but expect these mechanisms to just change the mode of this fraud. Don't expect SPF/CID to reduce levels of abuse. These schemes fail to stop rogue systems dumping volumes into the channel. In addition, any assurances offered recipients will only bolster fraudulent claims. Expect such fraud to happen more often when channel checking becomes depreciated due to constant attacks. Now those defrauded have cause against those providing false assurances. > This will be more realistic: > > As example, a mail server is receiving 50 messages per second that > average 4 K bytes in size. If using the SPF/CID mechanism, checking DNS > data is indeterminate as there is no limit for the number of sequential > queries required to converge upon an answer. RFC1035 indicates 5 to 10 > seconds should be considered a worst case resolver interval. - > If there becomes an average of 4 queries with an average of 1 second > a query, then this limits each process to about _ message about every > minute. These are messages from hostile domains. Where is there a 4 query limit to fully resolve permissions? > These 4 queries will also add to the traffic at 50 bytes per record a > total of 0.2K bytes of additional traffic for a halving of the network > load. In addition to this estimate ignoring the actual size of the query response, this tread is discussing a requirement that the MTA _MUST_ accept large results even if the information contained is unknown. This was to allow "new" features added at 100 bytes a whack at the whim of vendors. > The mail server may normally handle 1,500 simultaneous processes, > but at 4 seconds per process, the mail server has spare capacity up to > 'only' running 4000 messages a second. This may be a typical baseline before being taken down to 25 messages per second by the attack scenario previously described. > Also, you're assuming there are no DNS cache hits. The cache may be invalidated by small TTL values as stated in the mode of attack. If not, what is the typical cache size and how many entries are typically supported in the DNS cache? Causing a flood of 350 byte responses into the DNS cache will impact more than just mail service. At 250 per second as described, a minute of such may consume 10 M bytes of DNS cache. This assumes there is a local caching name server and results are not isolated to individual processes. > Also, if an SPF query starts with a blacklist check of the domain and > that fails, then no further queries will be made. That's efficient. > But yeah, spammers trying to gum up the works will result in what you're > talking about. If to assure the recipient of the sender's identity, Fenton's Identified Internet Mail proposal stops identity fraud with two determinate queries where fraud is truly curtailed without changes to SMTP. The added overhead for the Fenton proposal is about 600 bytes carried mostly in the SMTP and HTTP stream, where DNS simply returns a single SRV record pointing to the key server. Fenton's scheme has a chance of working and can isolate efforts for critical communications rather than across the board. In addition, it would be reasonable to trust assurances offered by the Fenton proposal. That must not be said of the SPF/CID proposal. As an RBL check against the address of the MTA is the primary protection scheme, not SPF/CID, requiring a single query for an SRV record to check the EHLO domain would allow greater assessment and better protections by then also enabling RHSBL. This would also enable enforcement efforts against abusers, unlike abuse sorted by users with the SPF/CID proposals. SPF/CID fails to assert an accountability claim by the mail sender. This leaves the door open to abuse unabated. -Doug From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 13:28:11 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14999 for ; Wed, 23 Jun 2004 13:28:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NHKJxC032938; Wed, 23 Jun 2004 10:20:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NHKJvE032937; Wed, 23 Jun 2004 10:20:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NHKH1f032920 for ; Wed, 23 Jun 2004 10:20:17 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Message-Id: <4xQIWxkeNJYaeZH1ux8f4w.md5@libertango.oryx.com> From: Arnt Gulbrandsen To: hadmut@danisch.de Subject: Re: XML/SPF colaberation Cc: Damon Sauer , IETF MARID WG References: <38363D9940D92A458010AAE24D162EB9033BF25B@bremocog-55> <20040623142836.GA31067@danisch.de> In-Reply-To: <20040623142836.GA31067@danisch.de> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Wed, 23 Jun 2004 19:24:29 +0200 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: hadmut@danisch.de writes: > On Wed, Jun 23, 2004 at 08:53:47AM -0500, Sauer, Damon wrote: >> I am reading as much as I can and with either scheme I can't see where >> this would not, at minimum, double the load on the DNS system. > ... >> Could the record first have a pointer in DNS that would tell it >> where to look and how many bytes the record is? > > That's exactly the problem I tried to solve with RMX++. > > But nobody listens. Everyone is absolutely bound to the fixed idea of > storing everything in DNS, no matter whether DNS is suitable or not. Seconded. But I don't think that can be changed - it's what the vast majority of the working group wants. (FWIW, I tried to compute the traffic load of DNS vs. RMX++ vs. the RPC mechanism I've been muttering about. Assuming that spammers adapt and some other minor assumptions, I see no significant difference for participating sites.) > This whole SPF vs. XML discussion is ridiculous. Amen. Arnt From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 13:43:52 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18543 for ; Wed, 23 Jun 2004 13:43:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NHZAdg035736; Wed, 23 Jun 2004 10:35:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NHZAhB035735; Wed, 23 Jun 2004 10:35:10 -0700 (PDT) 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.9) with ESMTP id i5NHZ9mL035711 for ; Wed, 23 Jun 2004 10:35:09 -0700 (PDT) (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 i5NHZ7hN004217; Wed, 23 Jun 2004 19:35:07 +0200 Received: from danisch.de (localhost [127.0.0.1]) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-5) with ESMTP id i5NHYADd021517; Wed, 23 Jun 2004 19:34:10 +0200 Message-ID: <40D9BF12.5090209@danisch.de> Date: Wed, 23 Jun 2004 19:34:10 +0200 From: Hadmut Danisch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040528 Debian/1.6-7 X-Accept-Language: de-de MIME-Version: 1.0 To: Alan DeKok CC: ietf-mxcomp@imc.org Subject: Re: Why not XML References: <20040623172231.21A0016FAB@mail.nitros9.org> In-Reply-To: <20040623172231.21A0016FAB@mail.nitros9.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Alan DeKok wrote: > The keys don't have to be that secret if they can change >periodically. > > This sounds to be a lot of overhead and very error-prone. How often do you want to change them? Every day? Reduce the DNS TTL to 24 hours? How would you cope with the latency? I don't think you can do it often enough to defend against stolen key and slow enough to not cause false rejections at the same time. Maybe you'd need a sliding window of several keys,e.g. you generate one key per week and, with respect to the delay cause by DNS propagation, the last three keys are considered valid. You need this, because MTAs can delay mails up to 10 days. So once a spammer got your key he has about three weeks time to use it for spamming. >> The same people who wrote this software would immediately >> start to write routines to collect the keys to generate >> false records. >> >> > > How? > > > Exactly the same way they do steal PINs, TANs, passwords, codes etc. today. Worms already contain elaborated procedures to collect and reveal secrets kept on the hard disk. Looking for such a anti-spam-key is just one more key. > People already control access to their MTA's. I don't see this as >much of a problem. > > Not really. If they did, we would not have open relays. Even if 99,9% of MTAs were secure enough. (And that's a far too high estimation!) How many domains exist? A billion? How many MTAs? How many stolen keys are 0,1 % of them? That's enough for spamming. And how would you do the synchronous update of the DNS zone and the MTA? I do not see how this could be easily and automatedly be done in all cases. > The message is not the SMTP transation. > > > Fully agreed. But if you use secret keys anyway, wouldn't it be better to sign the message? Getting rid of all those forwarding problems? regards Hadmut From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 13:56:01 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21641 for ; Wed, 23 Jun 2004 13:56:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NHklsr038013; Wed, 23 Jun 2004 10:46:47 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NHklCq038012; Wed, 23 Jun 2004 10:46:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from goose.ehsco.com (goose.ehsco.com [207.65.203.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NHklVI038003 for ; Wed, 23 Jun 2004 10:46:47 -0700 (PDT) (envelope-from ehall@ehsco.com) Received: from [207.65.71.20] (ferret.corp.ntrg.com [207.65.71.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Eric A. Hall", Issuer "Network Technology Research Group Certificate Authority" (verified OK)) by goose.ehsco.com (Postfix ) with ESMTP id 1366420E60 for ; Wed, 23 Jun 2004 12:46:49 -0500 (CDT) Message-ID: <40D9C1DA.9090103@ehsco.com> Date: Wed, 23 Jun 2004 12:46:02 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'IETF MARID WG'" Subject: extensibility as an attack vector Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit What is the possibility that an attacker could list a (SID|SPF) record with references to ~thousands of domains, forcing my SMTP server to spend large amounts of time and/or processing power validating the junk data? What other similar kinds of attacks are enabled by infinite extensibility? There is also still the argument that 513-byte records affect a DDoS attack against my domain. The more I think about this, the less I think that extensibility is a good idea in general. I actually think that constraining the authorization data to addresses, mx, and domains is probably best, and requireing everything else go into an external policy document that I will only check in certain other cases. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 13:57:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22090 for ; Wed, 23 Jun 2004 13:57:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NHfoW1037019; Wed, 23 Jun 2004 10:41:50 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NHfogr037018; Wed, 23 Jun 2004 10:41:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [64.139.47.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NHfoX5037001 for ; Wed, 23 Jun 2004 10:41:50 -0700 (PDT) (envelope-from gconnor@nekodojo.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by neko-base.nekodojo.org (Postfix) with ESMTP id 0EA351D651; Wed, 23 Jun 2004 10:41:51 -0700 (PDT) Date: Wed, 23 Jun 2004 10:41:52 -0700 From: Greg Connor To: Hadmut Danisch Cc: IETF MARID WG Subject: Re: Emotions, Encoding, and Ignorance (Was: Why not XML) Message-ID: <5607443.1087987311@Ryoga.corp.sgi.com> In-Reply-To: <40D9267F.2010309@danisch.de> References: <40D9267F.2010309@danisch.de> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hello, I appreciate your taking the time to write a reasonable reply. It is evident that we all feel strongly about this issue (and others) so the best we can do is to be clear about our thoughts, feelings, beliefs and intentions, which it looks like you have done. Here is a quick response to cover a couple points you raised. --Hadmut Danisch wrote: > >> Now. All joking aside, I have a great deal of respect for Hadmut and >> his work... we probably would not have arrived where we are today >> without him. But, the arguments being made here are not logical ones. >> In fact, Hadmut's message here is an *excellent* example of someone >> reacting emotionally (and making an emotional argument) rather than >> reacting with logic. >> > > This was not meant to be logical. > This was not meant to be an argument at all. > > This was meant to be irony and sarcasm. I wanted to point out on which > lousy level this discussion is made. If you didn't realize this and still > took this as an argument, you confirmed my point of view. While you were > blaming me for beeing emotional, It was you who gave a purely emotional > reaction. You were supposed to laugh and cool down. I understand what you mean. I probably wasn't very clear and I apologize. What I meant to say was, making fun of someone else's post is considered rude. If you make someone else the butt of a joke, it's funny, but it's also somewhat inappropriate behavior for a polite civilized list. It's also a warning sign to indicate that someone is reacting emotionally, though there may be other reasons someone might behave rudely that don't have to do with emotions, they are often associated. > Maybe you have realized that I didn't participate in this discussion for > a long time. Guess why? > > Because this is an endless loop. An emotional loop. Caused by SPF. > > Why? > > Because SPF has never been a technical invention. SPF is only a public > relations coup of a few people who were hijacking an idea to bring > themselves in front of the cameras and the newspapers. I have spoken with > several journalists who were intentionally misinformed. If you don't > believe this, just have a look at the ASRG history. This is a common reaction to SPF among technical folks who are aware of its history. I would like to take a moment to address it. SPF is not just a cool idea, it is a number of cool ideas, very few of which are original. It owes its origins to a number of good ideas like RMX, DMP, etc. Its users ought to be grateful to those intrepid inventors such as yourself, and you, Gordon, Andrew Church, Paul Vixie and others who came up with great ideas ought to be proud of yourselves. However, the success of SPF is not built on ideas alone. The success of SPF is built on hard work. It takes hard work to create running code for MTAs. It takes hard work to have discussions with stakeholders and make decisions on what to change. It takes hard work to create web pages and revise them. And it takes hard work to evangelize and market the great ideas so that people will be compelled to try something different and a bit risky. Talking to reporters is also hard work. Just having a great idea is not enough -- if the problem of forgery could be solved by brilliant minds thinking about it, it would be solved already and we would not be on this list. But there comes a time in the life cycle of a great invention when *someone* starts digging the trenches. So, if you and Gordon are the fathers of modern LMAP, Meng Weng Wong is its mother. Of course you care about the little LMAP, but are you willing cook and clean for it and change its pants? THAT is why I have a great deal of respect for SPF and for Meng specifically. He has taken a handful of really good ideas and turned them into a PRODUCT which can be marketed and sold. > And that's the reason for emotions. What is the main property of SPF? > Nothing but a slightly changed syntax. If we don't stick to SPF syntax, > what will remain of the SPF hype? Roughly nothing. That's the reason why > so many people desperately defend SPF syntax against any progress. They > try to enforce SPF syntax, because that's all SPF consists of. I agree that some SPF supporters are having an emotional reaction to XML. However, your emotional reaction to SPF is equally irrational. Can you definitely say beyond a doubt that you support XML for well-considered logical reasons, and NOT because you have an emotional investment in seeing SPF fail? Let's get everything on the table and let's all be clear about our agendas. My agenda here is not to push SPF syntax on people, though I admit that I like SPF syntax and I have a negative reaction to XML because I think it's the wrong tool for the job, but I'm willing to be proved wrong and if XML is the end result of this group, I will support it, because I think MARID is more important than its syntax and can succeed even with a bad choice of syntax. I am willing to set aside my emotional reaction, BUT, if we are trying to sell MARID to ordinary users, we MUST take their emotional reaction into account. If we produce a wonderful, architecturally sound, technological marvel and people don't want to adopt it, how would people like that outcome? > Have you ever seen DNS records from inside? How DNS records are > encoded? They are not readible. They are binary encoded. > ... > What do you believe? Why did I put both a syntax and a binary encoding > in the RMX drafts? Because you have to cover both, the external > representation and the internal encoding. That's what we have to deal > with in context of DNS, whether you like it or not. It's a wonderful idea and we should strongly consider that. I would prefer the TXT to be human-readable and the new RR type that we create to be binary... would that work for you? Of course we would have to update the dns tools to display the data correctly, but that can be done at the same time as the new RR is added. Plus, we can tell the DNS server what additional records to serve along with it, etc. The only drawback there is, what if the DNS tools don't understand the new binary format, when it comes time to revise things? Can we come up with a binary format that is as flexible as XML? > This way you can have two different representations without > having two different types of records. > ... > > Important is that we have two representations, but only a *single* > encoding. Only one type of DNS records. That's it. SPF or XML is not a > matter of the record itself. It's a matter of the program you use to > display the record. > ... > > > So in my eyes, this would be the best solution as long as we > are bound to store MARID records in DNS (if not, see RMX++ proposal). Excellent idea. Let's move forward with that. What would you think about, for ease of deployment pre-bind-10, maybe having the TXT record be SPF format and the _ep record being XML format? I'm just concerned that people will not be able to type binary into their zone files. Thanks again gregc -- Greg Connor From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 14:30:05 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29865 for ; Wed, 23 Jun 2004 14:30:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NIA7Ia042749; Wed, 23 Jun 2004 11:10:07 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NIA7Ki042748; Wed, 23 Jun 2004 11:10:07 -0700 (PDT) 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.9) with ESMTP id i5NIA5KI042741 for ; Wed, 23 Jun 2004 11:10:06 -0700 (PDT) (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 i5NI57JJ005054; Wed, 23 Jun 2004 20:05:07 +0200 Received: from danisch.de (localhost [127.0.0.1]) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-5) with ESMTP id i5NI3iRW022680; Wed, 23 Jun 2004 20:03:44 +0200 Message-ID: <40D9C600.7050908@danisch.de> Date: Wed, 23 Jun 2004 20:03:44 +0200 From: Hadmut Danisch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040528 Debian/1.6-7 X-Accept-Language: de-de MIME-Version: 1.0 To: Arnt Gulbrandsen CC: Damon Sauer , IETF MARID WG Subject: Re: XML/SPF colaberation References: <38363D9940D92A458010AAE24D162EB9033BF25B@bremocog-55> <20040623142836.GA31067@danisch.de> <4xQIWxkeNJYaeZH1ux8f4w.md5@libertango.oryx.com> In-Reply-To: <4xQIWxkeNJYaeZH1ux8f4w.md5@libertango.oryx.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Arnt Gulbrandsen wrote: > > (FWIW, I tried to compute the traffic load of DNS vs. RMX++ vs. the > RPC mechanism I've been muttering about. Assuming that spammers adapt > and some other minor assumptions, I see no significant difference for > participating sites.) Thanks a lot. I didn't compute it, but I roughly estimated this. I do not expect a big difference in traffic. But I do expect Web servers and HTTP proxies to cope much better with this kind of traffic and stored data than DNS servers can. And Web servers do not need any update or new protocol. They are there. Plenty of them. And, as a main advantage, you could choose whether to - put a static MARID record on the server as a file - generate the record dynamically through a simple CGI script - passing the parameters up to the server and do the check in any way you want without change of protocols or MTA software. DNS servers can't do it. I do not see this as the only possible solution. But I'd currently see two technical ways to do it as I mentioned before: - Either the "small" solution: Have a compact binary record in DNS. I'd prefer ASN.1. Write a coder and decoder for the dns library, which converts the binary from and into a readable representation of your choice. If you like it, have nslookup and dig print it in SPF syntax for readability. Or in XML for postprocessing. Give it a command line flag to choose what you want. It is like with those x.509 certificates: They are binary, but you use openssl to convert them into a readable representation. - Or the "big" solution (like RMX++): Have a Pointer in DNS giving a resource locator where to get or where and how to ask for the MARID record. And there a two hybrid solutions: - Ask the DNS for an any record in _marid.domain... If you receive a MARID record, use the small version. If you receive SRV records, use the big one. - Or you receive a MARID record with either regular entries or a special locator entry mimicing the former SRV model. In this way, XML and SPF colaborate very well, because they both are just the external representation and you can arbitrarily choose which you want for any purpose. You have one record and can convert it to both (or other) representations. Best of both worlds. The SPF people get, what they want: They can simply type in SPF statements into their zone files, except that the are of type MAR instead of TXT. And if the dig or nslookup, they see SPF as well. Be happy. The XML people can do it the same way. Be happy as well. The DNS folks get compact binary records, and, btw, the introduction of ASN.1 into DNS. I guess these are two reasons to be happy. And the implementors can - of course after understanding ASN.1 and DER - implement easily, because DER allows decoding with very small, compact, and simple routines in any language, just with a one-byte lookahead. I believe this to be more efficient and faster than parsing SPF records (which might require regular expressions). And you can extend it at any time because ASN.1 is extensible. Unknown record? Just have a critical flag like in x.509 extensions. If you don't understand it and it doesn't have the critical flag, just skip it. It has a length field. Did anyone complain that XML is extensible in syntax, but the semantics is not extensible because requiring new programs? This problem also occured with x.509 certificate extensions. They solved it with a single bit, the critical bit. Unknown extensions where this bit is not set can be silently ignored. And this way you have a very clean separation between internal encoding and external representation. DER is unambigous. Want to embed x.509 certificates, e.g. for SMTP over SSL? They are already ASN.1 encoded. And it is not a big deal to provide a reference implementation of a MARID interpreter which does not require any external library functions (except for fetching other DNS records and such standard stuff). Give MARID records a new OID, as usual in ASN.1, and you can be sure to be able to plug it in into other protocols without major problems. regards Hadmut From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 14:34:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00835 for ; Wed, 23 Jun 2004 14:34:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NIP5Eq046037; Wed, 23 Jun 2004 11:25:05 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NIP59J046036; Wed, 23 Jun 2004 11:25:05 -0700 (PDT) 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.9) with ESMTP id i5NIP4TW046029 for ; Wed, 23 Jun 2004 11:25:04 -0700 (PDT) (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 i5NIP7OE005520; Wed, 23 Jun 2004 20:25:07 +0200 Received: from danisch.de (localhost [127.0.0.1]) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-5) with ESMTP id i5NILKtd023377; Wed, 23 Jun 2004 20:21:20 +0200 Message-ID: <40D9CA1F.704@danisch.de> Date: Wed, 23 Jun 2004 20:21:19 +0200 From: Hadmut Danisch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040528 Debian/1.6-7 X-Accept-Language: de-de MIME-Version: 1.0 To: Greg Connor CC: IETF MARID WG Subject: Re: Emotions, Encoding, and Ignorance (Was: Why not XML) References: <40D9267F.2010309@danisch.de> <5607443.1087987311@Ryoga.corp.sgi.com> In-Reply-To: <5607443.1087987311@Ryoga.corp.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Greg Connor wrote: > > Excellent idea. Let's move forward with that. > > What would you think about, for ease of deployment pre-bind-10, maybe > having the TXT record be SPF format and the _ep record being XML > format? I'm just concerned that people will not be able to type binary > into their zone files. After spending a few more minutes to thing about it, I'd currently propose this (which, I admit, would also require the gods of DNS to move a little bit forward to accept it): MARID records in DNS should be encoded as raw bit/byte sequences. I would keep the encoding out of the DNS internals. If it has not structure, then DNS relays and caches do not have to de- and reencode (what they do, why I had to learn that my early RMX proposals, which made use of DNS compression, would not work). Keeping the record opaque for DNS internals keeps the processing overhead low. There should be a canonical encoding, where you are able to write the MARID as a base64 encoded string into the zone file. This gives you the ability to generate the record with any program of your choice and to encode things which are not yet part of the SPF or XML or whatever representation. An MTA would receive the record as it is, as a bit/byte sequence. DNS does not care about it's structure. The MTA then simply passes this record to the MARID interpreter, together with other parameters (peer IP address, sender address,...). The MARID interpreter then disassembles the ASN.1 encoding. This way anything is completely covered in the MARID interpreter. All DNS parts don't depend on any detail. Now give it eye sugar: Allow the DNS encoder (i.e. bind reading the zone file) to not only understand base64 text representations, but also other representations, like SPF, XML, or whatever future might bring. In the same library, allow MARID records to be converted into any of a list of representations: base64, SPF, XML. This way, it will *always* work with base64. That's the fallback solutions. If you can't upgrade your DNS software, it will always work. If you extend the MARID records, it depends on wether the extension is marked critical or not (see my former posting). Non-critical extensions allow slow upgrades. Or even no upgrades. And then you have time to extend SPF or XML syntax and upgrade the conversion library. Until then, base64 always works. Just hack a perl script to encode new record types. regards Hadmut From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 14:45:12 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02746 for ; Wed, 23 Jun 2004 14:45:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NIZoba048002; Wed, 23 Jun 2004 11:35:50 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NIZoVb048001; Wed, 23 Jun 2004 11:35:50 -0700 (PDT) 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.9) with ESMTP id i5NIZn3m047974 for ; Wed, 23 Jun 2004 11:35:49 -0700 (PDT) (envelope-from rbarclay@comcast.net) Received: from 204.127.205.147 ([204.127.205.147]) by comcast.net (sccrmhc13) with SMTP id <20040623183544016005pdnde>; Wed, 23 Jun 2004 18:35:44 +0000 Received: from [64.210.92.16] by 204.127.205.147; Wed, 23 Jun 2004 18:35:44 +0000 From: rbarclay@comcast.net To: IETF MARID WG Date: Wed, 23 Jun 2004 18:35:44 +0000 Message-Id: <062320041835.237.40D9CD7F000785ED000000ED2200762194970E040C9D0E0D9D@comcast.net> X-Mailer: AT&T Message Center Version 1 (May 18 2004) X-Authenticated-Sender: cmJhcmNsYXlAY29tY2FzdC5uZXQ= Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I would like to suggest, what I hope will lead to some meaningful discussions on a possible path for compromise on two of the biggest issues which have faced this group for quite some time. In the most basic terms the two issues are 1) whether we are creating a Email Policy Publication mechanism that begins by tying a sending MTA to a domain name, or solely an MTA authentication record, 2) and whether the data is stored solely in a TXT record, or we create a new RR. The syntax discussion really should follow the answer to question 1 (and I am a little surprised we never answered this during the time we were supposed to be deciding on semantics). I would also suggest the following four points as ideas that led me to the compromise path which will follow 1) Despite all of the debate about what needs to be expressible in an email policy, no-one debates the need for an authentication mechanism. 2) In an ideal world the data a receiver needs should be as small, clear, and unambiguous as possible. 3) If policies are necessary, and can be manageably placed in DNS directly or via a pointer they need to be extensible. 4) Given the same sender record and the same message the "authentication" question should yield the same answer for all recipients performing the test. So, based on the above here is my suggestion. We split the authentication and the policy expression into two separate problems, and acknowledge that both need to be addressed. We create a new MARID RR which has the sole purpose of encoding the authentication information for a sending domain. The specific encoding syntax should be as small as possible, and because of statement 4 above should specifically not be extensible outside of a standards process. As methods for defining new authentication mechanisms other than IP address based are discussed the method for encoding them can continue to be the work of the MARID WG, I foresee several possibilities on the immediate horizon. We define the existing SenderID proposal as an experimental means of encoding email sending policies in DNS and continue to store that data in the TXT record for now. I am not 100% positive that this is the correct WG to continue efforts in that space or that the policy storage mechanisms have to be limited to DNS, but it seems to me to be valuable work that will need to be addressed somewhere and quickly enough to capitalize on the amount of work and thought which is currently underway in this venue and others. The risk here is that the authentication information is stored twice in DNS and there is the potential for people to create conflicting records (actually this already exists even with one mechanism but is made more likely with two). This really though just emphasizes the need for tools like the SPF and Caller ID wizards to help people accurately create these records. The benefit is that for systems which are only able to query TXT they have a place to look, for systems able to query new RR's they can query either of the two depending on what information they are attempting to find out. If they only want to know if an MTA is legitimately sending on behalf of a domain they can use the MARID record, if valuable new extensions are added and they want to know that information they can retrieve the TXT record. I would further suggest that as an added benefit, since the SenderID record is experimental, that it continue as originally suggested to support both the existing SPF syntax and the XML syntax. The specific details here may or may not end up being of any value, but I believe separating the problems of authentication alone, and of email policy provide a means to resolve some of the more nagging issues (like the arguments for and against XML) on which we are currently hung up. Regards, Robert From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 15:13:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07211 for ; Wed, 23 Jun 2004 15:13:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NJ6iQr054593; Wed, 23 Jun 2004 12:06:44 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NJ6iUk054592; Wed, 23 Jun 2004 12:06:44 -0700 (PDT) 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.9) with ESMTP id i5NJ6hsq054528 for ; Wed, 23 Jun 2004 12:06:43 -0700 (PDT) (envelope-from rbarclay@comcast.net) Received: from 204.127.205.150 ([204.127.205.150]) by comcast.net (sccrmhc13) with SMTP id <20040623190642016005us9qe>; Wed, 23 Jun 2004 19:06:42 +0000 Received: from [64.210.92.16] by 204.127.205.150; Wed, 23 Jun 2004 19:06:40 +0000 From: rbarclay@comcast.net To: rbarclay@comcast.net Cc: IETF MARID WG Subject: Suggestion for a route to compromise Date: Wed, 23 Jun 2004 19:06:40 +0000 Message-Id: <062320041906.15631.40D9D4C00001F7DE00003D0F2200751150970E040C9D0E0D9D@comcast.net> X-Mailer: AT&T Message Center Version 1 (May 18 2004) X-Authenticated-Sender: cmJhcmNsYXlAY29tY2FzdC5uZXQ= Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Sorry here is the same message sent with its intended subject. > > I would like to suggest, what I hope will lead to some meaningful discussions on > a possible path for compromise on two of the biggest issues which have faced > this group for quite some time. In the most basic terms the two issues are > 1) whether we are creating a Email Policy Publication mechanism that begins by > tying a sending MTA to a domain name, or solely an MTA authentication record, > 2) and whether the data is stored solely in a TXT record, or we create a new RR. > The syntax discussion really should follow the answer to question 1 (and I am a > little surprised we never answered this during the time we were supposed to be > deciding on semantics). > > I would also suggest the following four points as ideas that led me to the > compromise path which will follow > > 1) Despite all of the debate about what needs to be expressible in an email > policy, no-one debates the need for an authentication mechanism. > 2) In an ideal world the data a receiver needs should be as small, clear, and > unambiguous as possible. > 3) If policies are necessary, and can be manageably placed in DNS directly or > via a pointer they need to be extensible. > 4) Given the same sender record and the same message the "authentication" > question should yield the same answer for all recipients performing the test. > > > So, based on the above here is my suggestion. > > We split the authentication and the policy expression into two separate > problems, and acknowledge that both need to be addressed. We create a new MARID > RR which has the sole purpose of encoding the authentication information for a > sending domain. The specific encoding syntax should be as small as possible, and > because of statement 4 above should specifically not be extensible outside of a > standards process. As methods for defining new authentication mechanisms other > than IP address based are discussed the method for encoding them can continue to > be the work of the MARID WG, I foresee several possibilities on the immediate > horizon. > We define the existing SenderID proposal as an experimental means of encoding > email sending policies in DNS and continue to store that data in the TXT record > for now. I am not 100% positive that this is the correct WG to continue efforts > in that space or that the policy storage mechanisms have to be limited to DNS, > but it seems to me to be valuable work that will need to be addressed somewhere > and quickly enough to capitalize on the amount of work and thought which is > currently underway in this venue and others. > The risk here is that the authentication information is stored twice in DNS and > there is the potential for people to create conflicting records (actually this > already exists even with one mechanism but is made more likely with two). This > really though just emphasizes the need for tools like the SPF and Caller ID > wizards to help people accurately create these records. The benefit is that for > systems which are only able to query TXT they have a place to look, for systems > able to query new RR's they can query either of the two depending on what > information they are attempting to find out. If they only want to know if an MTA > is legitimately sending on behalf of a domain they can use the MARID record, if > valuable new extensions are added and they want to know that information they > can retrieve the TXT record. > I would further suggest that as an added benefit, since the SenderID record is > experimental, that it continue as originally suggested to support both the > existing SPF syntax and the XML syntax. > > The specific details here may or may not end up being of any value, but I > believe separating the problems of authentication alone, and of email policy > provide a means to resolve some of the more nagging issues (like the arguments > for and against XML) on which we are currently hung up. > > Regards, > > Robert > From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 15:24:50 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08805 for ; Wed, 23 Jun 2004 15:24:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NJCF8G055558; Wed, 23 Jun 2004 12:12:15 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NJCFcj055557; Wed, 23 Jun 2004 12:12:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from xuxa.iecc.com (xuxa.iecc.com [208.31.42.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NJCDBq055550 for ; Wed, 23 Jun 2004 12:12:14 -0700 (PDT) (envelope-from johnl@iecc.com) Received: (qmail 27959 invoked by uid 100); 23 Jun 2004 19:12:17 -0000 Date: 23 Jun 2004 19:12:17 -0000 Message-ID: <20040623191217.27958.qmail@xuxa.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: Re: out of line XML, was Why not XML In-Reply-To: <40D9A540.30006@ehsco.com> Organization: I.E.C.C., Trumansburg NY USA Cc: ehall@ehsco.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >> What about putting the MARID data in-line in SMTP via an extension? The obvious problem is that there's no way to tell if the in-line data is real without making another transaction back to the sender's domain to check. If we have to use a separate TCP session to fetch a possible cachable chunk of XML, the right way to do that is with http and just fetch the policy document. It's defined, it's standard, it's debugged, it's available, and it works. You need a web server to do that, but I would think it'd be a lot easier to set up a little web server than to deploy a yet to be invented overloaded extension to SMTP. Alternatively, the sender could put some kind of signed thing into the message that the recipient could check against a static set of signer keys, but we have that, too. It's S/MIME. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor "A book is a sneeze." - E.B. White, on the writing of Charlotte's Web From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 16:07:29 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12268 for ; Wed, 23 Jun 2004 16:07:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NJu58G065888; Wed, 23 Jun 2004 12:56:05 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NJu56r065887; Wed, 23 Jun 2004 12:56:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [64.139.47.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NJu3sS065880 for ; Wed, 23 Jun 2004 12:56:04 -0700 (PDT) (envelope-from gconnor@nekodojo.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by neko-base.nekodojo.org (Postfix) with ESMTP id 8FD3F1D651; Wed, 23 Jun 2004 12:56:07 -0700 (PDT) Date: Wed, 23 Jun 2004 12:56:08 -0700 From: Greg Connor To: Hadmut Danisch Cc: IETF MARID WG Subject: Re: Emotions, Encoding, and Ignorance (Was: Why not XML) Message-ID: <13664248.1087995368@Ryoga.corp.sgi.com> In-Reply-To: <40D9CA1F.704@danisch.de> References: <40D9CA1F.704@danisch.de> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --Hadmut Danisch wrote: > After spending a few more minutes to thing about it, I'd currently > propose this (which, I admit, would also require the gods of DNS to > move a little bit forward to accept it): > ... > An MTA would receive the record as it is, as a bit/byte sequence. > DNS does not care about it's structure. The MTA then simply passes > this record to the MARID interpreter, together with other parameters > (peer IP address, sender address,...). The MARID interpreter then > disassembles the ASN.1 encoding. > > This way anything is completely covered in the MARID interpreter. > All DNS parts don't depend on any detail. I would agree with this. I like the idea of being able to go forward without waiting for DNS upgrades. Given a choice I would probably lean toward the TXT record being one of the human-readable representations, and the new RR being the "binary" form, but I don't have a strong feeling and I'm willing to be talked out of it :) Question for the DNS/bind gurus out there. Is it possible to put stuff in your zone file using TYPE1234 notation, even if the bind version doesn't support it? We would probably want to go with TXT at first but when we have an RR type it would nice to start using it... I'm not sure if this is possible. > Now give it eye sugar: > > Allow the DNS encoder (i.e. bind reading the zone file) to not only > understand base64 text representations, but also other > representations, like SPF, XML, or whatever future might bring. > > In the same library, allow MARID records to be converted into > any of a list of representations: base64, SPF, XML. > > This way, it will *always* work with base64. That's the fallback > solutions. If you can't upgrade your DNS software, it will always work. Good. Also, when we get around to publishing a new RR and rolling support for it into various DNS servers, we can make a recommendation for other "additional" records that can be stuffed in the response packet. For example, if the a: mx: or include: mechanisms are used, the additional section could include the A, MX, or other MARID record in the first reply packet. This is of course optional for the DNS server, but as long as we are working on a new RR in DNS we might as well make recommendations on additional records too. > If you extend the MARID records, it depends on wether the extension > is marked critical or not (see my former posting). Non-critical extensions > allow slow upgrades. Or even no upgrades. > > And then you have time to extend SPF or XML syntax and upgrade > the conversion library. Until then, base64 always works. Just hack > a perl script to encode new record types. Good stuff. Thanks. -- Greg Connor From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 16:26:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14122 for ; Wed, 23 Jun 2004 16:26:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NKFe51069463; Wed, 23 Jun 2004 13:15:40 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NKFe6u069462; Wed, 23 Jun 2004 13:15:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NKFdih069442 for ; Wed, 23 Jun 2004 13:15:39 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i5NKFffW000342; Wed, 23 Jun 2004 13:15:41 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i5NKFf3E000339; Wed, 23 Jun 2004 13:15:41 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Wed, 23 Jun 2004 13:15:41 -0700 (PDT) From: "william(at)elan.net" To: John Levine cc: ietf-mxcomp@imc.org, Subject: Re: out of line XML, was Why not XML In-Reply-To: <20040623191217.27958.qmail@xuxa.iecc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 23 Jun 2004, John Levine wrote: > >> What about putting the MARID data in-line in SMTP via an extension? > > The obvious problem is that there's no way to tell if the in-line data > is real without making another transaction back to the sender's domain > to check. If we have to use a separate TCP session to fetch a > possible cachable chunk of XML, the right way to do that is with http > and just fetch the policy document. It's defined, it's standard, it's > debugged, it's available, and it works. I agree with you in general (and with Hadmut), but would point out that http is also primarily one-key lookup protocol (which has been extended a lot by means of cgi parameters) and retreiving entire policy document is not the best idea if we're talking about it being so large that its better off at the http server. The best (in my opionion) is to actually work on specifications on new policy document such that it can be deployed over existing pre-built protocol. Protocol should be such that it works both over udp and over tcp (udp preferred if client and server support it) and returns particular data asked based on multiple lookup keys. My preference is something like what CRISP, which is XML specification that should go along with BEEP transport. Other XML possibility which make it easier to deply is one level up based on SOAP with full protocols being either (or all of) SOAP over HTTP and SOAP over BEEP and SOAP on UDP. Non-XML protocol option is LDAP (its supposed to be possible to do it over UDP, but I've never seen anybody implement it) and possibly something else I don't even know about. > You need a web server to do that, but I would think it'd be a lot > easier to set up a little web server than to deploy a yet to be > invented overloaded extension to SMTP. Yes, agreed. And this was also already discussed at asrg before. > Alternatively, the sender could put some kind of signed thing into the > message that the recipient could check against a static set of signer > keys, but we have that, too. It's S/MIME. There is still a need for client to reguarly retrieve CRLs. So we can never completely remove the necessity to do call-back lookup. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 16:52:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16739 for ; Wed, 23 Jun 2004 16:52:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NKdVoB073903; Wed, 23 Jun 2004 13:39:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NKdVwR073902; Wed, 23 Jun 2004 13:39:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from republico.estv.ipv.pt (republico.estv.ipv.pt [193.137.7.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NKdUKU073895 for ; Wed, 23 Jun 2004 13:39:31 -0700 (PDT) (envelope-from lbruno@republico.estv.ipv.pt) Received: from lbruno by republico.estv.ipv.pt with local (Exim 4.22) id 1BdEXx-0005Lp-0h for ietf-mxcomp@imc.org; Wed, 23 Jun 2004 21:40:41 +0100 Date: Wed, 23 Jun 2004 21:40:41 +0100 From: Luis Bruno To: ietf-mxcomp@imc.org Subject: Re: Emotions, Encoding, and Ignorance (Was: Why not XML) Message-ID: <20040623204041.GA19070@republico.estv.ipv.pt> Mail-Followup-To: ietf-mxcomp@imc.org References: <003c01c45957$d0a4e1f0$a561379d@redmond.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003c01c45957$d0a4e1f0$a561379d@redmond.corp.microsoft.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: James Webster wrote privately *and* to the list, but misplaced an 'f'; I won't be snipping much, to save him the trouble of resending. Comments are inline. To: ieft-mxcomp@imc.org James Webster wrote: > Luis Bruno wrote: > > they can't query for a new RR type when behind an ISA firewall. > > I don't believe that the issue is ISA, but rather that the Microsoft DNS > server isn't able to support new RR types, and they don't plan to do so in > the next 5 year OS development cycle. > > The ISA rpc issue that was mentioned was a limitation with the ISA Client. > I would not expect that any sane administrator would install an ISA client > on an internet facing box. ISA support port mapping, and as such has no > issues with pointing to a DNS server that supports new RR types. I was assuming that a MTA might want to query for MARID info, even behind an ISA server. So either I've misunderstood your points, or Jim Lyon's in: http://www.imc.org/ietf-mxcomp/mail-archive/msg01822.html From what I understood of Jim Lyon's message, if you protect your MTA with ISA it can't reach out and fetch unknown-to-ISA records. BTW, my knowledge of Microsoft's products is at user-level. > That said, I suspect there would be MS job security issues with suggesting > that a Microsoft customer use a non-Microsoft product because of > deficiencies in the Microsoft product. There's an implicit corollary to "Don't fix what ain't broke.". Job security isn't a valid argument here. > > That's the "clean" approach. However, I don't know how hard that is for > > the sysadmins. The MTA must be upgraded, that's a given. Would upgrading > > DNS be a showstopper? > > I suspect the requirements of deploying both MTA and DNS upgrades would be a > showstopper to organizations that have different administrators for Mail and > DNS. I was thinking about cost of upgrading *lots* of DNS servers; could you give an example? The one you provided seemed to go around politics; I'd appreciate if you could explain a bit more. > > You should be able to put structured, binary data in TXT anyway; that's > > how I read the RFC, anyway. > > If you are going to use structured binary data, then this should be a new RR > type. There are bound to be more then a few DNS servers that do not support > this. So once again its the RR/TXT argument. I've not tested serving random binary data with TXT. However, as I read the RFC, TXT records contain a string of arbitrary bytes. > Short term (0-5 years) TXT provides a method to quickly deploy a solution. > SPF/XML doesn't really matter since within that time period the vast > majority of the DNS reponses will be no record found. As such the short > term solution should be concerned less with performance and more with ease > of deployment. > > Long term (5+ years) there needs to be a solution that is small and fast, > thus a new binary RR record. It is also likely that any solution will > include deployment tools that can convert records from the short term > solution to a long term solution record. > > Arguing over the details of the short term solution only moves the > deployment of both solutions out without solving the problem. Making sure > the long term solution is designed correctly is far more important. Thanks for your time, everyone. -- Luis Bruno UTM: 29T 629481E 4511776N 576m "14) Always remember that Windows NT administration is to Unix and WAN administration, as _Herbie The Love Bug_ is to _Citizen Kane_. Respect your elders and don't trivialize their work." -- Christian Wagner's Tips From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 17:16:58 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19097 for ; Wed, 23 Jun 2004 17:16:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NL5K8u079144; Wed, 23 Jun 2004 14:05:20 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NL5Kbl079143; Wed, 23 Jun 2004 14:05:20 -0700 (PDT) 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.9) with ESMTP id i5NL5H6R079125 for ; Wed, 23 Jun 2004 14:05:17 -0700 (PDT) (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 06B8A13353F for ; Wed, 23 Jun 2004 17:05:15 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id CF5246C3; Wed, 23 Jun 2004 17:05:15 -0400 (EDT) Date: Wed, 23 Jun 2004 17:05:15 -0400 From: Meng Weng Wong To: "'IETF MARID WG'" Subject: using reputation lookups first Message-ID: <20040623210515.GF13225@dumbo.pobox.com> References: <40D9C1DA.9090103@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40D9C1DA.9090103@ehsco.com> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Jun 23, 2004 at 12:46:02PM -0500, Eric A. Hall wrote: | | What is the possibility that an attacker could list a (SID|SPF) record | with references to ~thousands of domains, forcing my SMTP server to spend | large amounts of time and/or processing power validating the junk data? | What other similar kinds of attacks are enabled by infinite extensibility? These attack scenarios have been raised in the past. Seen from the point of view of "don't spammers want their mail to get through?" they seem unlikely, but if we counter "but spammers may want to attack the integrity of the entire system as a whole" they make more sense. In fact, your attack scenario can be constructed independent of extensibility considerations. The moment you introduce a new behaviour (a MARID dns lookup) you are able to attack it (a slow SERVFAIL will consume resources). Extensibility amplifies the attack in degree but not in kind. We are moving from an "assumed innocent unless proven guilty" model of email to an "asumed guilty unless proven innocent" model. I see this as a simple matter of hygiene in the big city. If the crazy homeless guy on the street offers me a bloodstained driver's license, I won't even get as far as looking at its expiration date; I won't even take it for fear of disease. In the same way, the best defense against the attacks you suggest is to perform the reputation lookup *before* the authentication lookup. If the reputation lookup says "bad guy" then the authentication lookup is moot. If the reputation lookup says "good guy" then you have reason to believe the query won't crash your system. If the reputation lookup says "no reputation, but accredited" you can provisionally assume "good guy". If the reputation lookup says "unknown and unaccredited", If you are being very cautious, you may wish to greylist and return 4xx without doing the auth lookup at all. A distributed reputation system should obtain information fast enough to be useful the next time the query happens. If you are being less cautious, you can do the auth lookup anyway, and if it fails to resolve within a reasonable amount of time, you can abort the lookups and feed a grumpy opinion into your reputation service. The next time the attack occurs, you'll know not to do the auth query. Introduce noise into subsequent iterations according to game theory to create opportunities for forgiveness. Some MTA admins I know are looking at the OS fingerprint of the incoming packets and rejecting any mail that comes from a Windows OS. This blocks a lot of viruses at the cost of cutting out legitimate Windows MTAs. I mention this as an anecdote only. From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 17:43:22 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20540 for ; Wed, 23 Jun 2004 17:43:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NLZFMN085323; Wed, 23 Jun 2004 14:35:15 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NLZFmS085322; Wed, 23 Jun 2004 14:35:15 -0700 (PDT) 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.9) with ESMTP id i5NLZD85085299 for ; Wed, 23 Jun 2004 14:35:14 -0700 (PDT) (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 i5NLZ6B7010449; Wed, 23 Jun 2004 23:35:06 +0200 Received: (from hadmut@localhost) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-5) id i5NLWCiX031352; Wed, 23 Jun 2004 23:32:12 +0200 From: Hadmut Danisch Date: Wed, 23 Jun 2004 23:32:12 +0200 To: "Eric A. Hall" Cc: "'IETF MARID WG'" Subject: Re: extensibility as an attack vector Message-ID: <20040623213212.GA30716@danisch.de> References: <40D9C1DA.9090103@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40D9C1DA.9090103@ehsco.com> User-Agent: Mutt/1.5.6i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Jun 23, 2004 at 12:46:02PM -0500, Eric A. Hall wrote: > > What is the possibility that an attacker could list a (SID|SPF) record > with references to ~thousands of domains, forcing my SMTP server to spend > large amounts of time and/or processing power validating the junk data? > What other similar kinds of attacks are enabled by infinite extensibility? > > There is also still the argument that 513-byte records affect a DDoS > attack against my domain. > > The more I think about this, the less I think that extensibility is a good > idea in general. No. This is not a problem of extensibility. This is an attack outside the threat model. All these caller authorization methods are designed against an attacker who does not want to reveal his identity (=domain). An attacker who attacks you while not hiding his own domain is a different kind of attack. Such an attacker could also simply allow mail from 0.0.0.0/0, thus authorizing all IP addresses in order to allow spam. This has already been discussed more than a year ago in ASRG and addressed in RMX and other proposals. It is up to you to define a policy about domains you're willing to accept mail from. E.g. you could choose to not accept mail from domains authorizing more than 50 IP addresses. Thus the interpreter could reject messages from domains with such a record with thousands of references without performing a single query. And you should do it. Imagin this attack: An attacker is sending millions of spam with his own sender address @attacker.tld His MARID record is generated dynamically with thousand references of the type randomnumber.victim.tld Thus the victim's DNS server will have to serve billions of queries. You need limits. But, if this happens, you know at least the domain the attacks came from. It is similar to the case where the spammer simply used his own domain as a sender address (=does not fake). Fake protection is useless against attackers who do not fake. You still need blacklisting, but now blacklisting is possible. And you need whois entries which allow to identify the person responsible for the domain. regards Hadmut From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 17:51:28 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20794 for ; Wed, 23 Jun 2004 17:51:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NLkAfM087814; Wed, 23 Jun 2004 14:46:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NLkAmH087812; Wed, 23 Jun 2004 14:46:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.pan-am.ca (205-200-6-46.static.mts.net [205.200.6.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NLk9hB087790 for ; Wed, 23 Jun 2004 14:46:09 -0700 (PDT) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: asymmetric routing, was Factored lookup - ML patent claim issue. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 23 Jun 2004 16:46:04 -0500 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA8DB@srv1.pan-am.ca> X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: asymmetric routing, was Factored lookup - ML patent claim issue. Thread-Index: AcRYGI/L04nRFu36RH+eoX5gBAAvLQBUpFvw From: "Gordon Fecyk" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5NLk9hB087803 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > Asymmetric routing has been a well-known spammer trick for years. > Ernesto Haberli specialized in it. The receiving server still needs to talk back to the receiving end of the asymmetric route. Consider this: a receiving server has to talk back to something to establish a TCP connection. That's the IP address that gets recorded in mail server logs. Unless that address happens to belong to, say aol.com and AOL's gone and created a record for it, no way AOL's going to say to others to accept mail from it. Unless of course the receiving end of the asymmetric route is an actual AOL machine that's been compromised. Or maybe someone's hack AOL's DNS servers to create a false record. But then AOL has a whole other problem altogether. -- PGP key (0x0AFA039E): Sometimes it's hard to tell where the game ends and where reality bites, er, begins. From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 17:51:57 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20814 for ; Wed, 23 Jun 2004 17:51:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NLk7ni087798; Wed, 23 Jun 2004 14:46:07 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NLk7BX087797; Wed, 23 Jun 2004 14:46:07 -0700 (PDT) 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.9) with ESMTP id i5NLk6BU087778 for ; Wed, 23 Jun 2004 14:46:07 -0700 (PDT) (envelope-from cm--jrk@merseymail.com) Received: from mmail by argon.connect.org.uk with local (connectmail/exim) id 1BdFZI-0003PI-UT; Wed, 23 Jun 2004 22:46:08 +0100 In-Reply-To: <20040623133302.7768.qmail@xuxa.iecc.com> Subject: Re: Why not XML To: "John Levine" From: "Jon Kyme" Cc: ietf-mxcomp@imc.org X-Mailer: [ConnectMail 3.15.6] X-connectmail-Originating-IP: 82.69.7.27 Message-Id: Date: Wed, 23 Jun 2004 22:46:08 +0100 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >> I'd be very surprised if XML MARID documents exercised every single >> line of code in your XML library, so the absolute size of the >> library isn't necessarily significant, is it? > > >Bad guys can publish any complex and hostile MARID documents they >want. Typical MARID documents are indeed likely to be pretty simple, >but if word gets around that there's a bug in an XML library, how long >will it take until there's MARID data to exploit it? Minutes, I'd >guess. > Yes, using XML exposes you to risks associated with possible faults in code used to parse XML. I don't think anyone will deny this. My issue was with the alleged magnitude of this risk. Suppose, for instance, that resolving of external entities is never undertaken when parsing MARID-XML. So the library code that supports this should never be executed. Hence the MARID-XML parser is likely to be immune to exploits based on faults in this particular code, no matter what bizarre document an 'attacker' publishes. I'm sure it would be possible to estimate the XML library code coverage obtained with MARID XML, look at the bug history of your library, and come up with a good guess for the risk. I'd guess it's likely to be somewhere between zero and 100% :-) There's also the question of what the consequence of such a fault would be? DOS? Spam from the attacking domain? Something worse? Something like SPF-original might be done with a small and proven parser. So the XML-associated risk is avoided, but at what cost? Of course, the only way for recipients to avoid all risk in processing MARID is not to do it. You make a strong argument for publisher execution of the MARID statement. From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 18:16:01 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23561 for ; Wed, 23 Jun 2004 18:16:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NM8GSL092120; Wed, 23 Jun 2004 15:08:16 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NM8GBK092119; Wed, 23 Jun 2004 15:08:16 -0700 (PDT) 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.9) with ESMTP id i5NM8F3G092105 for ; Wed, 23 Jun 2004 15:08:16 -0700 (PDT) (envelope-from cm--jrk@merseymail.com) Received: from mmail by argon.connect.org.uk with local (connectmail/exim) id 1BdFum-0008WB-JS; Wed, 23 Jun 2004 23:08:20 +0100 In-Reply-To: <20040623142836.GA31067@danisch.de> Subject: Re: XML/SPF colaberation To: From: "Jon Kyme" Cc: ietf-mxcomp@imc.org X-Mailer: [ConnectMail 3.15.6] X-connectmail-Originating-IP: 82.69.7.27 Message-Id: Date: Wed, 23 Jun 2004 23:08:20 +0100 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > This whole SPF vs. XML discussion is ridiculous. > This is not a technical discussion. > This is a religious matter. > This is SPF marketing. It certainly does seem like that sometimes, doesn't it. I'd guess that some SPF evangelists believe that proselytizing by any means neccessary is vital to getting the deployment levels up. Some possibilities: (a) MARID fails to be deployed extensively enough to make any difference or (b) MARID works, but could have been better and cheaper (and earlier). or (c) MARID is deployed, new world fails to materialise and everyone gets bored of it in a few years. Any others? From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 18:25:57 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24578 for ; Wed, 23 Jun 2004 18:25:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NMHms0093879; Wed, 23 Jun 2004 15:17:48 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NMHmNk093878; Wed, 23 Jun 2004 15:17:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NMHmiX093872 for ; Wed, 23 Jun 2004 15:17:48 -0700 (PDT) (envelope-from hkatz@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 23 Jun 2004 15:17:53 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 23 Jun 2004 15:17:53 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 23 Jun 2004 15:17:52 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-fido-msg.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 23 Jun 2004 15:18:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C4596F.EC8A5247" Subject: draft-ietf-marid-submitter-01.txt Date: Wed, 23 Jun 2004 15:17:53 -0700 Message-ID: X-MS-Has-Attach: yes Thread-Topic: draft-ietf-marid-submitter-01.txt thread-index: AcRZb+3BR0XFeUEIRziKWfDHUI9aKA== From: "Harry Katz" To: Cc: "Eric Allman" , "Jim Lyon" , "Marshall Rose" , "Andrew Newton" , "IETF MARID List" , "Meng Weng Wong" X-OriginalArrivalTime: 23 Jun 2004 22:18:07.0529 (UTC) FILETIME=[F5EB3190:01C4596F] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C4596F.EC8A5247 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C4596F.EC8A5247" ------_=_NextPart_002_01C4596F.EC8A5247 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Attached is the latest revision to the Responsible Submitter internet-draft. This draft completes the missing sections from the -00 version and addresses a couple of minor issues raised in feedback to the list. Thanks to those who provided that feedback. Comments on this version are welcome. =20 Co-chairs please approve. =20 =20 Thanks ------_=_NextPart_002_01C4596F.EC8A5247 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Attached is the=20 latest revision to the Responsible Submitter internet-draft.  This = draft=20 completes the missing sections from the -00 version and addresses a = couple of=20 minor issues raised in feedback to the list.  Thanks to those who = provided=20 that feedback.   Comments on this version are=20 welcome.
 
Co-chairs please=20 approve. 
 
Thanks
------_=_NextPart_002_01C4596F.EC8A5247-- ------_=_NextPart_001_01C4596F.EC8A5247 Content-Type: text/plain; name="draft-ietf-marid-submitter-01.txt" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-marid-submitter-01.txt Content-Disposition: attachment; filename="draft-ietf-marid-submitter-01.txt" Content-Transfer-Encoding: base64 DQoNCiAgIE1BUklEIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgRS4gQWxsbWFuDQogICBJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgU2VuZG1haWwsIEluYw0KICAgRG9jdW1lbnQ6IGRyYWZ0LWll dGYtbWFyaWQtc3VibWl0dGVyLTAxLnR4dCAgICAgICAgICAgICAgICAgIEguIEthdHoNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1pY3Jv c29mdCBDb3JwDQogICBFeHBpcmVzOiAgRGVjZW1iZXIgMjAwNCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEp1bmUgMjAwNA0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgIFNN VFAgU2VydmljZSBFeHRlbnNpb24gZm9yDQogICAgICAgICBJbmRpY2F0aW5nIHRoZSBSZXNwb25z aWJsZSBTdWJtaXR0ZXIgb2YgYW4gRS1tYWlsIE1lc3NhZ2UNCg0KDQpTdGF0dXMgb2YgdGhpcyBN ZW1vDQoNCiAgIFRoaXMgZG9jdW1lbnQgaXMgYW4gSW50ZXJuZXQtRHJhZnQgYW5kIGlzIGluIGZ1 bGwgY29uZm9ybWFuY2Ugd2l0aA0KICAgYWxsIHByb3Zpc2lvbnMgb2YgU2VjdGlvbiAxMCBvZiBS RkMyMDI2IFtTVERdLg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRz IG9mIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMNCiAgIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3Jv dXBzLiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbw0KICAgZGlzdHJpYnV0ZSB3b3Jr aW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuDQoNCiAgIEludGVybmV0LURyYWZ0cyBh cmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocw0KICAg YW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3Vt ZW50cyBhdCBhbnkNCiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5l dC1EcmFmdHMgYXMgcmVmZXJlbmNlDQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIg dGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iDQoNCiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50 ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgICAgICBodHRwOi8vd3d3LmlldGYu b3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQNCiAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0 IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgICAgICAgaHR0cDovL3d3 dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC4NCg0KQ29weXJpZ2h0IE5vdGljZQ0KDQogICBDb3B5cmln aHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDA0KS4gQWxsIFJpZ2h0cyBSZXNlcnZlZC4N Cg0KQWJzdHJhY3QNCg0KICAgVGhpcyBtZW1vIGRlZmluZXMgYW4gZXh0ZW5zaW9uIHRvIHRoZSBT aW1wbGUgTWFpbCBUcmFuc2ZlciBQcm90b2NvbA0KICAgU01UUCkgc2VydmljZSwgd2hpY2ggYWxs b3dzIGFuIFNNVFAgY2xpZW50IHRvIHNwZWNpZnkgdGhlIHJlc3BvbnNpYmxlDQogICBzdWJtaXR0 ZXIgb2YgYW4gZS1tYWlsIG1lc3NhZ2UuICBUaGUgcmVzcG9uc2libGUgc3VibWl0dGVyIGlzIHRo ZSBlLQ0KICAgbWFpbCBhZGRyZXNzIG9mIHRoZSBlbnRpdHkgbW9zdCByZWNlbnRseSByZXNwb25z aWJsZSBmb3IgaW50cm9kdWNpbmcNCiAgIGEgbWVzc2FnZSBpbnRvIHRoZSB0cmFuc3BvcnQgc3Ry ZWFtLiAgVGhpcyBleHRlbnNpb24gaGVscHMgcmVjZWl2aW5nDQogICBlLW1haWwgc2VydmVycyBl ZmZpY2llbnRseSBkZXRlcm1pbmUgd2hldGhlciB0aGUgU01UUCBjbGllbnQgaXMNCiAgIGF1dGhv cml6ZWQgdG8gdHJhbnNtaXQgbWFpbCBvbiBiZWhhbGYgb2YgdGhlIHJlc3BvbnNpYmxlIHN1Ym1p dHRlcidzDQogICBkb21haW4uDQoNCkNvbnZlbnRpb25zIFVzZWQgaW4gVGhpcyBEb2N1bWVudA0K DQogICBJbiBleGFtcGxlcywgIkM6IiBhbmQgIlM6IiBpbmRpY2F0ZSBsaW5lcyBzZW50IGJ5IHRo ZSBjbGllbnQgYW5kDQogICBzZXJ2ZXIgcmVzcGVjdGl2ZWx5Lg0KDQoNCg0KQWxsbWFuLCBLYXR6 ICAgICAgICAgICBFeHBpcmVzIC0gRGVjZW1iZXIgMjAwNCAgICAgICAgICAgICAgIFtQYWdlIDFd DQoMDQogICAgICAgICAgICAgICAgIFNNVFAgUmVzcG9uc2libGUgU3VibWl0dGVyIEV4dGVuc2lv biAgICAgICAgSnVuZSAyMDA0DQoNCg0KICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5P VCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLA0KICAgIlNIT1VMRCIsICJTSE9V TEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMNCiAg IGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gUkZDLTIxMTkg W0tFWVdPUkRTXS4NCg0KVGFibGUgb2YgQ29udGVudHMNCg0KICAgMS4gSW50cm9kdWN0aW9uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMg0KICAgMi4g VGhlIFNVQk1JVFRFUiBTZXJ2aWNlIEV4dGVuc2lvbi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uMw0KICAgMy4gVGhlIFNVQk1JVFRFUiBLZXl3b3JkIG9mIHRoZSBFSExPIENvbW1hbmQu Li4uLi4uLi4uLi4uLi4uLi4uLi4uNA0KICAgNC4gVGhlIFNVQk1JVFRFUiBQYXJhbWV0ZXIgb2Yg dGhlIE1BSUwgQ29tbWFuZC4uLi4uLi4uLi4uLi4uLi4uLi4uNA0KICAgICAgNC4xIFNldHRpbmcg dGhlIFNVQk1JVFRFUiBQYXJhbWV0ZXIgVmFsdWUuLi4uLi4uLi4uLi4uLi4uLi4uLi4uNA0KICAg ICAgNC4yIFByb2Nlc3NpbmcgdGhlIFNVQk1JVFRFUiBQYXJhbWV0ZXIuLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uNQ0KICAgICAgNC4zIFRyYW5zbWl0dGluZyB0byBhIE5vbi1TVUJNSVRURVIgQXdh cmUgU01UUCBTZXJ2ZXIuLi4uLi4uLi4uNg0KICAgNS4gRXhhbXBsZXMuLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNg0KICAgICAgNS4xIE1haWwg U3VibWlzc2lvbi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNw0K ICAgICAgNS4yIE1haWwgRm9yd2FyZGluZy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uNw0KICAgICAgNS4zIE1vYmlsZSBVc2VyLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uOA0KICAgICAgNS40IEd1ZXN0IEUtbWFpbCBTZXJ2 aWNlLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uOQ0KICAgNi4gU2VjdXJp dHkgQ29uc2lkZXJhdGlvbnMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4x MA0KICAgNy4gUmVmZXJlbmNlcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4xMA0KICAgICAgNy4xIE5vcm1hdGl2ZSBSZWZlcmVuY2VzLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMA0KICAgICAgNy4yIEluZm9ybWF0aXZlIFJl ZmVyZW5jZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMQ0KICAgOC4gQWNr bm93bGVkZ21lbnRzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4xMQ0KICAgOS4gQXV0aG9ycycgQWRkcmVzc2VzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4xMQ0KICAgMTAuIEZ1bGwgQ29weXJpZ2h0IFN0YXRlbWVudC4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMg0KDQoxLiBJbnRyb2R1Y3Rpb24NCg0K ICAgVGhlIHByYWN0aWNlIG9mIGZhbHNpZnlpbmcgdGhlIGlkZW50aXR5IG9mIHRoZSBzZW5kZXIg b2YgYW4gZS1tYWlsDQogICBtZXNzYWdlLCBjb21tb25seSBjYWxsZWQgInNwb29maW5nIiwgaXMg YSBwcmV2YWxlbnQgdGFjdGljIHVzZWQgYnkNCiAgIHNlbmRlcnMgb2YgdW5zb2xpY2l0ZWQgY29t bWVyY2lhbCBlLW1haWwgb3IgInNwYW0iLiAgQSBudW1iZXIgb2YNCiAgIHByb3Bvc2FscyBoYXZl IGJlZW4gcHV0IGZvcndhcmQgdG8gYWRkcmVzcyB0aGUgc3Bvb2ZpbmcgcHJvYmxlbS4NCiAgIE5v dGFibGUgYW1vbmcgdGhlbSBhcmUgW1JNWF0sIFtTUEZdLCBbTE1BUF0gYW5kIFtDQUxMRVJJRF0u DQoNCiAgIFRoZXNlIHByb3Bvc2FscyBoYXZlIG1hbnkga2V5IGVsZW1lbnRzIGluIGNvbW1vbi4g IEluIHBhcnRpY3VsYXIsDQogICB0aGV5IGFsbCBkZXNjcmliZSBhIG1lY2hhbmlzbSBieSB3aGlj aCByZWNlaXZpbmcgZS1tYWlsIHNlcnZlcnMgY2FuDQogICB2YWxpZGF0ZSB3aGV0aGVyIHRoZSBj bGllbnQgTVRBIGlzIGF1dGhvcml6ZWQgdG8gdHJhbnNtaXQgZS1tYWlsDQogICBtZXNzYWdlcyBv biBiZWhhbGYgb2YgdGhlIHNlbmRlcidzIGRvbWFpbi4NCg0KICAgVGhleSBkaWZmZXIgaW4gdGhl aXIgY2hvaWNlIG9mIHRoZSBpZGVudGl0eSB1c2VkIGFzIGEgYmFzaXMgZm9yIHRoZQ0KICAgdmFs aWRhdGlvbiwgdGhhdCBpcywgaW4gdGhlaXIgZGV0ZXJtaW5hdGlvbiBvZiB0aGUgInNlbmRlciIg b2YgdGhlDQogICBtZXNzYWdlLiAgSW4gdGhpcyBzcGVjaWZpY2F0aW9uLCB0aGlzIGlkZW50aXR5 IHdpbGwgYmUgcmVmZXJyZWQgdG8gYXMNCiAgIHRoZSAicHVycG9ydGVkIHJlc3BvbnNpYmxlIGFk ZHJlc3MiIG9mIHRoZSBtZXNzYWdlLCB0aGF0IGlzLCB0aGUNCiAgIEludGVybmV0IGFkZHJlc3Mg ZnJvbSB3aGljaCB0aGUgbWVzc2FnZSBwdXJwb3J0cyB0byBvcmlnaW5hdGUuICBUaGUNCiAgIHB1 cnBvcnRlZCByZXNwb25zaWJsZSBkb21haW4gaXMgdGhlIGRvbWFpbiBwb3J0aW9uIG9mIHRoYXQg YWRkcmVzcy4NCiAgIFtSTVhdLCBbU1BGXSBhbmQgW0xNQVBdIHVzZSB0aGUgZG9tYWluIHBhcnQg b2YgdGhlIGUtbWFpbCBhZGRyZXNzDQogICB1c2VkIG9uIHRoZSBSRkMgMjgyMSBNQUlMIEZST00g Y29tbWFuZCwgYW5kIGluIHNvbWUgY2FzZXMgdGhlIEVITE8NCiAgIGNvbW1hbmQsIGFzIHRoZSBw dXJwb3J0ZWQgcmVzcG9uc2libGUgZG9tYWluLiAgW0NBTExFUklEXSBkZXJpdmVzIHRoZQ0KICAg cHVycG9ydGVkIHJlc3BvbnNpYmxlIGRvbWFpbiBieSBleGFtaW5pbmcgY2VydGFpbiBSRkMgMjgy MiBoZWFkZXJzDQogICBzcGVjaWZpZWQgaW4gdGhlIGJvZHkgb2YgdGhlIG1lc3NhZ2UuDQoNCkFs bG1hbiwgS2F0eiAgICAgICAgICAgRXhwaXJlcyAtIERlY2VtYmVyIDIwMDQgICAgICAgICAgICAg ICBbUGFnZSAyXQ0KDA0KICAgICAgICAgICAgICAgICBTTVRQIFJlc3BvbnNpYmxlIFN1Ym1pdHRl ciBFeHRlbnNpb24gICAgICAgIEp1bmUgMjAwNA0KDQoNCg0KICAgRWFjaCBhcHByb2FjaCBoYXMg Y2VydGFpbiBhZHZhbnRhZ2VzIGFuZCBkaXNhZHZhbnRhZ2VzLg0KDQogICBEZXJpdmluZyB0aGUg cHVycG9ydGVkIHJlc3BvbnNpYmxlIGRvbWFpbiBmcm9tIFJGQyAyODIxIGRhdGEgaGFzIHRoZQ0K ICAgYWR2YW50YWdlIHRoYXQgdmFsaWRhdGlvbiBjYW4gYmUgcGVyZm9ybWVkIGJlZm9yZSB0aGUg U01UUCBjbGllbnQgaGFzDQogICB0cmFuc21pdHRlZCB0aGUgbWVzc2FnZSBib2R5LiAgSWYgc3Bv b2ZpbmcgaXMgZGV0ZWN0ZWQsIHRoZW4gdGhlIFNNVFANCiAgIHNlcnZlciBoYXMgdGhlIG9wcG9y dHVuaXR5LCBkZXBlbmRpbmcgdXBvbiBsb2NhbCBwb2xpY3ksIHRvIHJlamVjdA0KICAgdGhlIG1l c3NhZ2UgYmVmb3JlIGl0IGlzIGV2ZXIgdHJhbnNtaXR0ZWQuICBUaGUgZGlzYWR2YW50YWdlIG9m IHRoaXMNCiAgIGFwcHJvYWNoIGlzIHRoZSByaXNrIG9mIGZhbHNlIHBvc2l0aXZlcywgdGhhdCBp cywgaW5jb3JyZWN0bHkNCiAgIGNvbmNsdWRpbmcgdGhhdCB0aGUgc2VuZGVyJ3MgZS1tYWlsIGFk ZHJlc3MgaGFzIGJlZW4gc3Bvb2ZlZC4gIFRoZXJlDQogICBhcmUgdG9kYXkgbGVnaXRpbWF0ZSBy ZWFzb25zIHdoeSB0aGUgSW50ZXJuZXQgZG9tYWluIG5hbWVzIHVzZWQgaW4NCiAgIFJGQyAyODIx IGNvbW1hbmRzIG1heSBiZSBkaWZmZXJlbnQgZnJvbSB0aGF0IG9mIHRoZSBzZW5kZXIgb2YgYW4g ZS0NCiAgIG1haWwgbWVzc2FnZS4NCg0KICAgRGVyaXZpbmcgdGhlIHB1cnBvcnRlZCByZXNwb25z aWJsZSBkb21haW4gZnJvbSBSRkMgMjgyMiBoZWFkZXJzIGhhcw0KICAgdGhlIGFkdmFudGFnZSBv ZiBiYXNpbmcgdGhlIHNlbmRlciB2YWxpZGF0aW9uIG9uIGFuIGlkZW50aXR5IHRoYXQgaXMNCiAg IHVzdWFsbHkgdmlzaWJsZSB0byB0aGUgZW5kIHJlY2lwaWVudCBvZiB0aGUgbWVzc2FnZS4gIFRo aXMgYWlkcyBpbg0KICAgZGV0ZWN0aW9uIG9mIGEgcGFydGljdWxhcmx5IG5veGlvdXMgZm9ybSBv ZiBzcG9vZmluZyBrbm93biBhcw0KICAgInBoaXNoaW5nIiBpbiB3aGljaCBhIG1hbGljaW91cyBz ZW5kZXIgYXR0ZW1wdHMgdG8gZm9vbCBhIHJlY2lwaWVudA0KICAgaW50byBiZWxpZXZpbmcgdGhh dCBhIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIGEgZmlybSB3ZWxsIGtub3duIHRvDQogICB0aGUg cmVjaXBpZW50LiAgVGhpcyBhcHByb2FjaCBjYXJyaWVzIGEgbG93ZXIgcmlzayBvZiBmYWxzZSBw b3NpdGl2ZXMNCiAgIHNpbmNlIHRoZXJlIGFyZSBmZXdlciBsZWdpdGltYXRlIHJlYXNvbnMgZm9y IFJGQyAyODIyIGhlYWRlcnMgdG8NCiAgIGRpZmZlciBmcm9tIHRoZSB0cnVlIHNlbmRlciBvZiB0 aGUgbWVzc2FnZS4gIFRoZSBkaXNhZHZhbnRhZ2Ugb2YgdGhpcw0KICAgYXBwcm9hY2ggaXMgdGhh dCBpdCBkb2VzIHJlcXVpcmUgcGFyc2luZyBhbmQgYW5hbHlzaXMgb2YgbWVzc2FnZQ0KICAgaGVh ZGVycy4gIEluIHByYWN0aWNlLCBtdWNoIGlmIG5vdCBhbGwgdGhlIG1lc3NhZ2UgYm9keSBpcyBh bHNvDQogICB0cmFuc21pdHRlZCBzaW5jZSB0aGUgU01UUCBwcm90b2NvbCBkZXNjcmliZWQgaW4g UkZDIDI4MjEgcHJvdmlkZXMgbm8NCiAgIG1lY2hhbmlzbSB0byBpbnRlcnJ1cHQgbWVzc2FnZSB0 cmFuc21pc3Npb24gYWZ0ZXIgdGhlIERBVEEgY29tbWFuZA0KICAgaGFzIGJlZW4gaXNzdWVkLg0K DQogICBJdCBpcyBkZXNpcmFibGUgdG8gdW5pZnkgdGhlc2UgdHdvIGFwcHJvYWNoZXMgaW4gYSB3 YXkgdGhhdCBjb21iaW5lcw0KICAgdGhlIGJlbmVmaXRzIG9mIGJvdGggd2hpbGUgbWluaW1pemlu ZyB0aGVpciByZXNwZWN0aXZlIGRpc2FkdmFudGFnZXMuDQoNCiAgIFRoaXMgbWVtbyBkZXNjcmli ZXMganVzdCBzdWNoIGEgdW5pZmllZCBhcHByb2FjaC4gIEl0IHVzZXMgdGhlDQogICBtZWNoYW5p c20gZGVzY3JpYmVkIGluIFtTTVRQXSB0byBkZXNjcmliZSBhbiBleHRlbnNpb24gdG8gdGhlIFNN VFANCiAgIHByb3RvY29sLiAgVXNpbmcgdGhpcyBleHRlbnNpb24sIGFuIFNNVFAgY2xpZW50IGNh biBzcGVjaWZ5IHRoZSBlLQ0KICAgbWFpbCBhZGRyZXNzIG9mIHRoZSBlbnRpdHkgcmVzcG9uc2li bGUgZm9yIHN1Ym1pdHRpbmcgdGhlIG1lc3NhZ2UgdG8NCiAgIHRoZSBTTVRQIGNsaWVudCBpbiBh IG5ldyBTVUJNSVRURVIgcGFyYW1ldGVyIG9mIHRoZSBTTVRQIE1BSUwNCiAgIGNvbW1hbmQuICBT TVRQIHNlcnZlcnMgY2FuIHVzZSB0aGlzIGluZm9ybWF0aW9uIHRvIHZhbGlkYXRlIHRoYXQgdGhl DQogICBTTVRQIGNsaWVudCBpcyBhdXRob3JpemVkIHRvIHRyYW5zbWl0IGUtbWFpbCBvbiBiZWhh bGYgb2YgdGhlDQogICBJbnRlcm5ldCBkb21haW4gY29udGFpbmVkIGluIHRoZSBTVUJNSVRURVIg cGFyYW1ldGVyLg0KDQoyLiBUaGUgU1VCTUlUVEVSIFNlcnZpY2UgRXh0ZW5zaW9uDQoNCiAgIFRo ZSBmb2xsb3dpbmcgU01UUCBzZXJ2aWNlIGV4dGVuc2lvbiBpcyBoZXJlYnkgZGVmaW5lZDoNCg0K ICAgKDEpIFRoZSBuYW1lIG9mIHRoaXMgU01UUCBzZXJ2aWNlIGV4dGVuc2lvbiBpcyAiUmVzcG9u c2libGUNCiAgICAgICBTdWJtaXR0ZXIiOw0KDQogICAoMikgVGhlIEVITE8ga2V5d29yZCB2YWx1 ZSBhc3NvY2lhdGVkIHdpdGggdGhpcyBleHRlbnNpb24gaXMNCiAgICAgICAiU1VCTUlUVEVSIjsN Cg0KQWxsbWFuLCBLYXR6ICAgICAgICAgICBFeHBpcmVzIC0gRGVjZW1iZXIgMjAwNCAgICAgICAg ICAgICAgIFtQYWdlIDNdDQoMDQogICAgICAgICAgICAgICAgIFNNVFAgUmVzcG9uc2libGUgU3Vi bWl0dGVyIEV4dGVuc2lvbiAgICAgICAgSnVuZSAyMDA0DQoNCg0KDQogICAoMykgVGhlIFNVQk1J VFRFUiBrZXl3b3JkIGhhcyBubyBwYXJhbWV0ZXJzOw0KDQogICAoNCkgTm8gYWRkaXRpb25hbCBT TVRQIHZlcmJzIGFyZSBkZWZpbmVkIGJ5IHRoaXMgZXh0ZW5zaW9uOw0KDQogICAoNSkgQW4gb3B0 aW9uYWwgcGFyYW1ldGVyIGlzIGFkZGVkIHRvIHRoZSBNQUlMIGNvbW1hbmQgdXNpbmcgdGhlDQog ICAgICAgZXNtdHAta2V5d29yZCAiU1VCTUlUVEVSIiwgYW5kIGlzIHVzZWQgdG8gc3BlY2lmeSB0 aGUgZS1tYWlsDQogICAgICAgYWRkcmVzcyBvZiB0aGUgZW50aXR5IHJlc3BvbnNpYmxlIGZvciBz dWJtaXR0aW5nIHRoZSBtZXNzYWdlIGZvcg0KICAgICAgIGRlbGl2ZXJ5Ow0KDQogICAoNikgVGhp cyBleHRlbnNpb24gaXMgYXBwcm9wcmlhdGUgZm9yIHRoZSBzdWJtaXNzaW9uIHByb3RvY29sDQog ICAgICAgW1NVQk1JVF0uDQoNCjMuIFRoZSBTVUJNSVRURVIgS2V5d29yZCBvZiB0aGUgRUhMTyBD b21tYW5kDQoNCiAgIEFuIFNNVFAgc2VydmVyIGluY2x1ZGVzIHRoZSBTVUJNSVRURVIga2V5d29y ZCBpbiBpdHMgRUhMTyByZXNwb25zZSB0bw0KICAgdGVsbCB0aGUgU01UUCBjbGllbnQgdGhhdCB0 aGUgU1VCTUlUVEVSIHNlcnZpY2UgZXh0ZW5zaW9uIGlzDQogICBzdXBwb3J0ZWQuDQoNCiAgIFRo ZSBTVUJNSVRURVIga2V5d29yZCBoYXMgbm8gcGFyYW1ldGVycy4NCg0KNC4gVGhlIFNVQk1JVFRF UiBQYXJhbWV0ZXIgb2YgdGhlIE1BSUwgQ29tbWFuZA0KDQogICBJZiB0aGUgU01UUCBzZXJ2ZXIg c3VwcG9ydHMgdGhlIFNVQk1JVFRFUiBleHRlbnNpb24sIHRoZW4gdGhlIFNNVFANCiAgIGNsaWVu dCBNQVkgaW5jbHVkZSB0aGUgU1VCTUlUVEVSIHBhcmFtZXRlciBpbiBNQUlMIGNvbW1hbmRzIGlz c3VlZA0KICAgZHVyaW5nIHRoZSBTTVRQIHNlc3Npb24uDQoNCiAgIFRoZSBzeW50YXggb2YgdGhl IFNVQk1JVFRFUiBwYXJhbWV0ZXIgaXM6DQoNCiAgICAgICJTVUJNSVRURVI9IiBNYWlsYm94DQoN CiAgIHdoZXJlIE1haWxib3ggaXMgdGhlIEFCTkYgW0FCTkZdIHByb2R1Y3Rpb24gZGVmaW5lZCBp biBTZWN0aW9uIDQuMS4yDQogICBvZiBbU01UUF0uICBDaGFyYWN0ZXJzIHN1Y2ggYXMgU1AsICIr IiBhbmQgIj0iIHdoaWNoIG1heSBvY2N1ciBpbiANCiAgIE1haWxib3ggYnV0IGFyZSBub3QgcGVy bWl0dGVkIGluIEVTTVRQIHBhcmFtZXRlciB2YWx1ZXMgTVVTVCBiZSANCiAgIGVuY29kZWQgYXMg Inh0ZXh0IiBhcyBkZXNjcmliZWQgaW4gc2VjdGlvbiA0IG9mIFtEU05dLg0KDQo0LjEgU2V0dGlu ZyB0aGUgU1VCTUlUVEVSIFBhcmFtZXRlciBWYWx1ZQ0KDQogICBUaGUgcHVycG9zZSBvZiB0aGUg U1VCTUlUVEVSIHBhcmFtZXRlciBpcyB0byBhbGxvdyB0aGUgU01UUCBjbGllbnQgdG8NCiAgIGlu ZGljYXRlIHRvIHRoZSBzZXJ2ZXIgdGhlIHB1cnBvcnRlZCByZXNwb25zaWJsZSBhZGRyZXNzIG9m IHRoZQ0KICAgbWVzc2FnZSBkaXJlY3RseSBpbiB0aGUgUkZDIDI4MjEgcHJvdG9jb2wuDQoNCiAg IFRoZXJlZm9yZSwgU01UUCBjbGllbnRzIHRoYXQgc3VwcG9ydCB0aGUgUmVzcG9uc2libGUgU3Vi bWl0dGVyDQogICBleHRlbnNpb24gU0hPVUxEIGluY2x1ZGUgdGhlIFNVTUJJVFRFUiBwYXJhbWV0 ZXIgb24gYWxsIG1lc3NhZ2VzDQogICB3aGVyZSB0aGUgcHVycG9ydGVkIHJlc3BvbnNpYmxlIGFk ZHJlc3MsIGFzIGRlZmluZWQgaW4gc2VjdGlvbiA0IG9mDQogICBbU0VOREVSLUlEXSBkaWZmZXJz IGZyb20gdGhlIE1BSUwgRlJPTSBhZGRyZXNzLg0KDQogICBBdCBzb21lIGZ1dHVyZSB0aW1lLCBp dCBpcyBsaWtlbHkgdGhhdCB1c2Ugb2YgdGhlIFNVQk1JVFRFUiBwYXJhbWV0ZXINCiAgIHdpbGwg YmUgbWFkZSBNQU5EQVRPUlkgd2hlbmV2ZXIgdGhlIHB1cnBvcnRlZCByZXNwb25zaWJsZSBhZGRy ZXNzDQogICBkaWZmZXJzIGZyb20gdGhlIE1BSUwgRlJPTSBhZGRyZXNzLg0KDQpBbGxtYW4sIEth dHogICAgICAgICAgIEV4cGlyZXMgLSBEZWNlbWJlciAyMDA0ICAgICAgICAgICAgICAgW1BhZ2Ug NF0NCgwNCiAgICAgICAgICAgICAgICAgU01UUCBSZXNwb25zaWJsZSBTdWJtaXR0ZXIgRXh0ZW5z aW9uICAgICAgICBKdW5lIDIwMDQNCg0KDQoNCiAgIEZ1cnRoZXJtb3JlLCBjbGllbnRzIE1VU1Qs IGlmIG5lY2Vzc2FyeSwgaW5zZXJ0IHN1Y2ggUkZDIDI4MjIgaGVhZGVycw0KICAgYXMgZGVmaW5l ZCBpbiBzZWN0aW9uIDQgb2YgW1NFTkRFUi1JRF0gaW4gb3JkZXIgdG8gZW5zdXJlIHRoYXQgdGhl DQogICBwdXJwb3J0ZWQgcmVzcG9uc2libGUgYWRkcmVzcyBkZXRlcm1pbmVkIGZyb20gdGhlIFJG QyAyODIyIGhlYWRlcnMNCiAgIG1hdGNoZXMgdGhlIFNVQk1JVFRFUiBhZGRyZXNzLiAgSW4gb3Ro ZXIgd29yZHMsIFNVQk1JVCBzZXJ2ZXJzDQogICBzdXBwb3J0aW5nIFNVQk1JVFRFUiBNVVNUIHNj YW4gdGhlIFJGQyAyODIyIGhlYWRlcnMgZm9yIGEgcHVycG9ydGVkDQogICByZXNwb25zaWJsZSBh ZGRyZXNzIHRvIGJlIGluY2x1ZGVkIGluIHN1YnNlcXVlbnQgU1VCTUlUVEVSDQogICBwYXJhbWV0 ZXJzLCB1bmxlc3MgdGhlIE1VQSBpbmNsdWRlcyB0aGUgcGFyYW1ldGVyIGl0c2VsZi4NCg0KICAg QSBjb21tb24gbW9kZWwgd2lsbCBiZSBmb3IgdGhlIE1haWwgVXNlciBBZ2VudCAoTVVBKSB0byB0 cmFuc21pdCBhDQogICBtZXNzYWdlIHRvIHRoZSBTVUJNSVQgc2VydmVyIFtTVUJNSVRdIHdpdGhv dXQgYSBTVUJNSVRURVIgcGFyYW1ldGVyLg0KICAgVGhlIFNVQk1JVCBzZXJ2ZXIgd2lsbCB0aGVu IHZhbGlkYXRlIHRoYXQgdGhlIE1VQSBpcyBhbGxvd2VkIHRvDQogICBzdWJtaXQgYSBtZXNzYWdl IHVzaW5nIHRoZSBwdXJwb3J0ZWQgUmVzcG9uc2libGUgU3VibWl0dGVyIGFkZHJlc3MNCiAgIHRo cm91Z2ggc29tZSBleHRlcm5hbCBzY2hlbWUsIHBlcmhhcHMgU01UUCBBdXRoZW50aWNhdGlvbiBb U01UUEFVVEhdLg0KICAgVGhlIFNVQk1JVCBzZXJ2ZXIsIGFjdGluZyBhcyBhbiBTTVRQIGNsaWVu dCwgd2lsbCB0aGVuIGFkZCBhDQogICBTVUJNSVRURVIgcGFyYW1ldGVyIGZvciBmdXJ0aGVyIHRy YW5zbWlzc2lvbi4NCg0KICAgQW55IE1UQSBzdXBwb3J0aW5nIHRoZSBSZXNwb25zaWJsZSBTdWJt aXR0ZXIgZXh0ZW5zaW9uIHRoYXQgcmVkaXJlY3RzDQogICBhIG1lc3NhZ2UgZnJvbSB0aGUgYWRk cmVzcyBsaXN0ZWQgaW4gdGhlIFJGQyAyODIxIFJDUFQgVE8gY29tbWFuZA0KICAgTVVTVCBtb2Rp ZnkgdGhlIG1lc3NhZ2UgYnk6DQoNCiAgICAgKGEpICBEZXRlcm1pbmluZyBhIG5ldyBwdXJwb3J0 ZWQgcmVzcG9uc2libGUgYWRkcmVzcyBmb3IgdGhlDQogICAgICAgICAgbWVzc2FnZSB0aGF0IGNh biB2ZXJpZmlhYmx5IGNsYWltIHRvIGJlIHVuZGVyIHRoZSBjb250cm9sIG9mDQogICAgICAgICAg dGhlIE1UQSdzIGRvbWFpbi4gIEZvciBleGFtcGxlLCB0aGUgbmV3IHB1cnBvcnRlZCByZXNwb25z aWJsZQ0KICAgICAgICAgIGFkZHJlc3MgY291bGQgYmUgdGhlIG5hbWUgb2YgYSBmb3J3YXJkZWQg YWRkcmVzcywgdGhlIG5hbWUgb2YNCiAgICAgICAgICBhIG1haWxpbmcgbGlzdCwgb3IgYSBmaXhl ZCBuYW1lIGF0IHRoYXQgZG9tYWluLg0KDQogICAgIChiKSAgSWYgbmVjZXNzYXJ5LCBwcmUtcGVu ZGluZyBhIFJlc2VudC1Gcm9tIG9yIFJlc2VudC1TZW5kZXINCiAgICAgICAgICBoZWFkZXIgZmll bGQgdG8gdGhlIG1lc3NhZ2UgaGVhZGVyIGNvbnRhaW5pbmcgdGhlIG5ldw0KICAgICAgICAgIHB1 cnBvcnRlZCByZXNwb25zaWJsZSBhZGRyZXNzLg0KDQogICAgIChjKSAgSWYgdGhlIHB1cnBvcnRl ZCByZXNwb25zaWJsZSBhZGRyZXNzIGRpZmZlcnMgZnJvbSB0aGUgUkZDIDI4MjENCiAgICAgICAg ICBNQUlMIEZST00gYWRkcmVzcywgYWRkaW5nIG9yIHJlcGxhY2luZyB0aGUgU1VCTUlUVEVSIHBh cmFtZXRlcg0KICAgICAgICAgIHdpdGggdGhlIG5ldyBwdXJwb3J0ZWQgcmVzcG9uc2libGUgYWRk cmVzcy4NCg0KNC4yIFByb2Nlc3NpbmcgdGhlIFNVQk1JVFRFUiBQYXJhbWV0ZXINCg0KICAgUmVj ZWl2ZXJzIG9mIGUtbWFpbCBtZXNzYWdlcyBzZW50IHdpdGggdGhlIFNVQk1JVFRFUiBwYXJhbWV0 ZXIgU0hPVUxEDQogICBzZWxlY3QgdGhlIGRvbWFpbiBwYXJ0IG9mIHRoZSBTVUJNSVRURVIgYWRk cmVzcyB2YWx1ZSBhcyB0aGUNCiAgIHB1cnBvcnRlZCByZXNwb25zaWJsZSBkb21haW4gb2YgdGhl IG1lc3NhZ2UsIGFuZCBTSE9VTEQgcGVyZm9ybSBzdWNoDQogICB0ZXN0cywgaW5jbHVkaW5nIHRo b3NlIGRlZmluZWQgaW4gW1NFTkRFUi1JRF0sIGFzIGFyZSBkZWVtZWQNCiAgIG5lY2Vzc2FyeSB0 byBkZXRlcm1pbmUgd2hldGhlciB0aGUgY29ubmVjdGluZyBTTVRQIGNsaWVudCBpcw0KICAgYXV0 aG9yaXplZCB0byB0cmFuc21pdCBlLW1haWwgbWVzc2FnZXMgb24gYmVoYWxmIG9mIHRoYXQgZG9t YWluLg0KDQogICBXaGVuLCBhdCBzb21lIGZ1dHVyZSB0aW1lLCB1c2Ugb2YgdGhlIFNVQk1JVFRF UiBwYXJhbWV0ZXIgYmVjb21lcw0KICAgTUFOREFUT1JZLCBTTVRQIHNlcnZlcnMgTUFZIHVzZSB0 aGUgZG9tYWluIHBhcnQgb2YgdGhlIE1BSUwgRlJPTQ0KICAgYWRkcmVzcyBhcyB0aGUgcHVycG9y dGVkIHJlc3BvbnNpYmxlIGRvbWFpbiBpbiB0aGUgYWJzZW5jZSBvZiB0aGUNCiAgIFNVQk1JVFRF UiBwYXJhbWV0ZXIuDQoNCg0KDQpBbGxtYW4sIEthdHogICAgICAgICAgIEV4cGlyZXMgLSBEZWNl bWJlciAyMDA0ICAgICAgICAgICAgICAgW1BhZ2UgNV0NCgwNCiAgICAgICAgICAgICAgICAgU01U UCBSZXNwb25zaWJsZSBTdWJtaXR0ZXIgRXh0ZW5zaW9uICAgICAgICBKdW5lIDIwMDQNCg0KDQog ICBJZiB0aGUgYWJvdmUgdGVzdHMgaW5kaWNhdGUgdGhhdCB0aGUgY29ubmVjdGluZyBTTVRQIGNs aWVudCBpcyBub3QNCiAgIGF1dGhvcml6ZWQgdG8gdHJhbnNtaXQgZS1tYWlsIG1lc3NhZ2VzIG9u IGJlaGFsZiBvZiB0aGUgU1VCTUlUVEVSDQogICBkb21haW4sIHRoZSByZWNlaXZpbmcgU01UUCBz ZXJ2ZXIgTUFZIHJlamVjdCB0aGUgbWVzc2FnZSB1c2luZyAiNTUwDQogICA1LjcuMSBTdWJtaXR0 ZXIgbm90IGFsbG93ZWQuIiAgVGhlIHJlY2VpdmluZyBTTVRQIHNlcnZlciBNQVkNCiAgIGFsdGVy bmF0aXZlbHkgcHJvY2VlZCB0byByZWFkIHRoZSBtZXNzYWdlIGFuZCBhcHBseSBsb2NhbCBwb2xp Y3kuDQoNCiAgIElmIHRoZSByZWNlaXZpbmcgU01UUCBzZXJ2ZXIgYWxsb3dzIHRoZSBjb25uZWN0 aW5nIFNNVFAgY2xpZW50IHRvDQogICB0cmFuc21pdCBtZXNzYWdlIGRhdGEsIHRoZW4gdGhlIHNl cnZlciBTSE9VTEQgZGV0ZXJtaW5lIHRoZSBwdXJwb3J0ZWQNCiAgIHJlc3BvbnNpYmxlIGFkZHJl c3Mgb2YgdGhlIG1lc3NhZ2UgYnkgZXhhbWluaW5nIHRoZSBSRkMgMjgyMiBtZXNzYWdlDQogICBo ZWFkZXJzIGFzIGRlc2NyaWJlZCBpbiBbU0VOREVSLUlEXS4gIElmIHRoaXMgcHVycG9ydGVkIHJl c3BvbnNpYmxlDQogICBhZGRyZXNzIGRvZXMgbm90IG1hdGNoIHRoZSBhZGRyZXNzIGFwcGVhcmlu ZyBpbiB0aGUgU1VCTUlUVEVSIA0KICAgcGFyYW1ldGVyLCB0aGUgcmVjZWl2aW5nIFNNVFAgc2Vy dmVyIE1VU1QgcmVqZWN0IHRoZSBtZXNzYWdlIHVzaW5nIA0KICAgIjU1MCA1LjcuMSBTdWJtaXR0 ZXIgZG9lcyBub3QgbWF0Y2ggaGVhZGVyLiINCg0KICAgSWYgbm8gYWRkcmVzcyBoZWFkZXIgbWVl dGluZyB0aGVzZSBjcml0ZXJpYSBpcyBmb3VuZCwgdGhlIFNNVFAgc2VydmVyDQogICBTSE9VTEQg cmVqZWN0IHRoZSBtZXNzYWdlIHVzaW5nICI1NTQgNS43LjcgQ2Fubm90IHZlcmlmeSBzdWJtaXR0 ZXINCiAgIGFkZHJlc3MuIg0KDQogICBWZXJpZnlpbmcgTVRBcyBhcmUgc3Ryb25nbHkgdXJnZWQg dG8gdmFsaWRhdGUgdGhlIFNVQk1JVFRFUiBwYXJhbWV0ZXINCiAgIGFnYWluc3QgdGhlIFJGQyAy ODIyIGhlYWRlcnM7IG90aGVyd2lzZSwgYW4gYXR0YWNrZXIgY2FuIHRyaXZpYWxseQ0KICAgZGVm ZWF0IHRoZSBhbGdvcml0aG0uDQoNCjQuMyBUcmFuc21pdHRpbmcgdG8gYSBOb24tU1VCTUlUVEVS IEF3YXJlIFNNVFAgU2VydmVyDQoNCiAgIFdoZW4gYW4gTVRBIHJlY2VpdmVzIGEgbWVzc2FnZSB3 aXRoIGEgU1VCTUlUVEVSIHBhcmFtZXRlciBhbmQgbXVzdA0KICAgZm9yd2FyZCBpdCB0byBhbm90 aGVyIE1UQSB0aGF0IGRvZXMgbm90IHN1cHBvcnQgdGhlIFNVQk1JVFRFUg0KICAgZXh0ZW5zaW9u LCB0aGUgZm9yd2FyZGluZyBNVEEgTVVTVCB0cmFuc21pdCB0aGUgbWVzc2FnZSB3aXRob3V0IHRo ZQ0KICAgU1VCTUlUVEVSIHBhcmFtZXRlci4gIFRoaXMgc2hvdWxkIGludm9sdmUgbm8gaW5mb3Jt YXRpb24gbG9zcywgc2luY2UNCiAgIHRoZSBTVUJNSVRURVIgcGFyYW1ldGVyIGlzIHJlcXVpcmVk IHRvIGNvbnRhaW4gaW5mb3JtYXRpb24gZGVyaXZlZA0KICAgZnJvbSB0aGUgbWVzc2FnZSBoZWFk ZXJzLg0KDQo1LiBFeGFtcGxlcw0KDQogICBUaGlzIHNlY3Rpb24gcHJvdmlkZXMgZXhhbXBsZXMg b2YgaG93IHRoZSBTVUJNSVRURVIgcGFyYW1ldGVyIHdvdWxkDQogICBiZSB1c2VkLiAgVGhlIGZv bGxvd2luZyBkcmFtYXRpcyBwZXJzb25hZSBhcHBlYXIgaW4gdGhlIGV4YW1wbGVzOg0KDQogICBh bGljZUBleGFtcGxlLmNvbTogdGhlIG9yaWdpbmFsIHNlbmRlciBvZiBlYWNoIGUtbWFpbCBtZXNz YWdlLg0KDQogICBib2JAd29vZGdyb3ZlLmV4YW1wbGUuY29tOiB0aGUgZmluYWwgcmVjaXBpZW50 IG9mIGVhY2ggZS1tYWlsLg0KDQogICBib2JAYWx1bW5pLmFsbWFtYXRlci5lZHU6IGFuIGVtYWls IGFkZHJlc3MgdXNlZCBieSBCb2Igd2hpY2ggaGUgaGFzDQogICBjb25maWd1cmVkIHRvIGZvcndh cmQgbWFpbCB0byBoaXMgb2ZmaWNlIGFjY291bnQgYXQNCiAgIGJvYkB3b29kZ3JvdmUuZXhhbXBs ZS5jb20uDQoNCiAgIGFsaWNlQGNvbnNvbGlkYXRlZG1lc3Nlbmdlci5uZXQ6IGFuIGUtbWFpbCBh Y2NvdW50IHByb3ZpZGVkIHRvIEFsaWNlDQogICBieSBoZXIgbW9iaWxlIGUtbWFpbCBuZXR3b3Jr IGNhcnJpZXIuDQoNCg0KDQoNCg0KQWxsbWFuLCBLYXR6ICAgICAgICAgICBFeHBpcmVzIC0gRGVj ZW1iZXIgMjAwNCAgICAgICAgICAgICAgIFtQYWdlIDZdDQoMDQogICAgICAgICAgICAgICAgIFNN VFAgUmVzcG9uc2libGUgU3VibWl0dGVyIEV4dGVuc2lvbiAgICAgICAgSnVuZSAyMDA0DQoNCg0K NS4xIE1haWwgU3VibWlzc2lvbg0KDQogICBVbmRlciBub3JtYWwgY2lyY3Vtc3RhbmNlcywgQWxp Y2Ugd291bGQgY29uZmlndXJlIGhlciBNVUEgdG8gc3VibWl0DQogICBoZXIgbWVzc2FnZSB0byB0 aGUgbWFpbCBzeXN0ZW0gdXNpbmcgdGhlIFNVQk1JVCBwcm90b2NvbCBbU1VCTUlUXS4NCiAgIFVu ZGVyIG1vc3QgY2lyY3Vtc3RhbmNlcyB0aGlzIHdvdWxkIGxvb2sgbGlrZSBhIG5vcm1hbCwgYXV0 aGVudGljYXRlZA0KICAgU01UUCB0cmFuc2FjdGlvbi4gIFRoZSBTVUJNSVQgc2VydmVyIHdpbGwg ZXh0cmFjdCBoZXIgbmFtZSBmcm9tIHRoZQ0KICAgUkZDIDI4MjIgaGVhZGVycyBmb3IgdXNlIGlu IHRoZSBTVUJNSVRURVIgcGFyYW1ldGVycyBvZiBzdWJzZXF1ZW50DQogICB0cmFuc21pc3Npb25z IG9mIHRoZSBtZXNzYWdlLg0KDQo1LjIgTWFpbCBGb3J3YXJkaW5nDQoNCiAgIFdoZW4gQWxpY2Ug c2VuZHMgYSBtZXNzYWdlIHRvIEJvYiBhdCBoaXMgYWx1bW5pLmFsbWFtYXRlci5lZHUNCiAgIGFj Y291bnQsIHRoZSBTTVRQIHNlc3Npb24gZnJvbSBoZXIgU1VCTUlUIHNlcnZlciBtaWdodCBsb29r IHNvbWV0aGluZw0KICAgbGlrZSB0aGlzOg0KDQogICAgICBTOiAyMjAgYWx1bW5pLmFsbWFtYXRl ci5lZHUgRVNNVFAgc2VydmVyIHJlYWR5DQogICAgICBDOiBFSExPIGV4YW1wbGUuY29tDQogICAg ICBTOiAyNTAtYWx1bW5pLmFsbWFtYXRlci5lZHUNCiAgICAgIFM6IDI1MC1EU04NCiAgICAgIFM6 IDI1MC1BVVRIDQogICAgICBTOiAyNTAtU1VCTUlUVEVSDQogICAgICBTOiAyNTAgU0laRQ0KICAg ICAgQzogTUFJTCBGUk9NOjxhbGljZUBleGFtcGxlLmNvbT4gU1VCTUlUVEVSPWFsaWNlQGV4YW1w bGUuY29tDQogICAgICBTOiAyNTAgPGFsaWNlQGV4YW1wbGUuY29tPiBzZW5kZXIgb2sNCiAgICAg IEM6IFJDUFQgVE86PGJvYkBhbHVtbmkuYWxtYW1hdGVyLmVkdT4NCiAgICAgIFM6IDI1MCA8Ym9i QGFsdW1uaS5hbG1hbWF0ZXIuZWR1PiByZWNpcGllbnQgb2sNCiAgICAgIEM6IERBVEENCiAgICAg IFM6IDM1NCBva2F5LCBzZW5kIG1lc3NhZ2UNCiAgICAgIEM6IChtZXNzYWdlIGJvZHkgZ29lcyBo ZXJlKQ0KICAgICAgQzogLg0KICAgICAgUzogMjUwIG1lc3NhZ2UgYWNjZXB0ZWQNCiAgICAgIEM6 IFFVSVQNCiAgICAgIFM6IDIyMSBnb29kYnllDQoNCiAgIFRoZSBTVUJNSVRURVIgcGFyYW1ldGVy IGlzIG9wdGlvbmFsIGluIHRoaXMgZmlyc3QgZXhhbXBsZSBiZWNhdXNlDQogICBhbGljZUBleGFt cGxlLmNvbSBpcyB0aGUgb3JpZ2luYWwgc2VuZGVyIG9mIHRoZSBtZXNzYWdlLg0KDQogICBUaGUg YWx1bW5pLmFsbWFtYXRlci5lZHUgTVRBIG11c3Qgbm93IGZvcndhcmQgdGhpcyBtZXNzYWdlIHRv DQogICBib2JAd29vZGdyb3ZlLmV4YW1wbGUuY29tLiAgU2luY2UgdGhlIG9yaWdpbmFsIHNlbmRl ciBvZiB0aGUgbWVzc2FnZQ0KICAgaXMgYWxpY2VAZXhhbXBsZS5jb20sIHRoZSBhbHVtbmkuYWxt YW1hdGVyLmVkdSBNVEEgYWRkcyB0aGUgU1VCTUlUVEVSDQogICBwYXJhbWV0ZXIgdG8gaW5kaWNh dGUgdGhlIGZvcndhcmRpbmcgYWRkcmVzcyB0aGF0IGlzIGF1dGhvcml6ZWQgdG8NCiAgIHRyYW5z bWl0IG1haWwgdmlhIHRoYXQgTVRBLiAgVGhlIGZvcndhcmRpbmcgTVRBIGFsc28gaW5zZXJ0cyBh DQogICBSZXNlbnQtRnJvbSBoZWFkZXIgaW4gdGhlIG1lc3NhZ2UgYm9keSB0byBlbnN1cmUgY29u c2lzdGVuY3kgb2YgdGhlDQogICBwdXJwb3J0ZWQgcmVzcG9uc2libGUgZG9tYWluIGRlcml2ZWQg ZnJvbSB0aGUgUkZDIDI4MjIgaGVhZGVycyB3aXRoDQogICB0aGUgU1VCTUlUVEVSIGRvbWFpbi4N Cg0KDQogICAgICBTOiAyMjAgd29vZGdyb3ZlLmV4YW1wbGUuY29tIEVTTVRQIHNlcnZlciByZWFk eQ0KICAgICAgQzogRUhMTyBhbHVtbmkuYWxtYW1hdGVyLmVkdQ0KICAgICAgUzogMjUwLXdvb2Rn cm92ZS5leGFtcGxlLmNvbQ0KDQpBbGxtYW4sIEthdHogICAgICAgICAgIEV4cGlyZXMgLSBEZWNl bWJlciAyMDA0ICAgICAgICAgICAgICAgW1BhZ2UgN10NCgwNCiAgICAgICAgICAgICAgICAgU01U UCBSZXNwb25zaWJsZSBTdWJtaXR0ZXIgRXh0ZW5zaW9uICAgICAgICBKdW5lIDIwMDQNCg0KDQog ICAgICBTOiAyNTAtRFNODQogICAgICBTOiAyNTAtQVVUSA0KICAgICAgUzogMjUwLVNVQk1JVFRF Ug0KICAgICAgUzogMjUwIFNJWkUNCiAgICAgIEM6IE1BSUwgRlJPTTo8YWxpY2VAZXhhbXBsZS5j b20+DQogICAgICAgICAgICAgIFNVQk1JVFRFUj1ib2JAYWx1bW5pLmFsbWFtYXRlci5lZHUNCiAg ICAgIFM6IDI1MCA8YWxpY2VAZXhhbXBsZS5jb20+IHNlbmRlciBvaw0KICAgICAgQzogUkNQVCBU Tzo8Ym9iQHdvb2Rncm92ZS5leGFtcGxlLmNvbT4NCiAgICAgIFM6IDI1MCA8Ym9iQHdvb2Rncm92 ZS5leGFtcGxlLmNvbT4gcmVjaXBpZW50IG9rDQogICAgICBDOiBEQVRBDQogICAgICBTOiAzNTQg b2theSwgc2VuZCBtZXNzYWdlDQogICAgICBDOiBSZXNlbnQtRnJvbTogYm9iQGFsdW1uaS5hbG1h bWF0ZXIuZWR1DQogICAgICBDOiBSZWNlaXZlZCBCeTogLi4uDQogICAgICBDOiAobWVzc2FnZSBi b2R5IGdvZXMgaGVyZSkNCiAgICAgIEM6IC4NCiAgICAgIFM6IDI1MCBtZXNzYWdlIGFjY2VwdGVk DQogICAgICBDOiBRVUlUDQogICAgICBTOiAyMjEgZ29vZGJ5ZQ0KDQo1LjMgTW9iaWxlIFVzZXIN Cg0KICAgQWxpY2UgaXMgYXQgdGhlIGFpcnBvcnQgYW5kIHVzZXMgaGVyIG1vYmlsZSBlLW1haWwg ZGV2aWNlIHRvIHNlbmQgYQ0KICAgbWVzc2FnZSB0byBCb2IuICBUaGUgbWVzc2FnZSB0cmF2ZWxz IHRocm91Z2ggdGhlIGNhcnJpZXIgbmV0d29yaw0KICAgcHJvdmlkZWQgYnkgY29uc29saWRhdGVk bWVzc2VuZ2VyLm5ldCwgYnV0IEFsaWNlIHVzZXMgaGVyIGV4YW1wbGUuY29tDQogICBhZGRyZXNz IG9uIHRoZSBGcm9tIGxpbmUgb2YgYWxsIGhlciBtZXNzYWdlcyBzbyB0aGF0IHJlcGxpZXMgZ28g dG8NCiAgIGhlciBvZmZpY2UgbWFpbGJveC4NCg0KICAgSGVyZSBpcyBhbiBleGFtcGxlIG9mIHRo ZSBTTVRQIHNlc3Npb24gYmV0d2VlbiB0aGUgTVRBcyBhdA0KICAgY29uc29saWRhdGVkbWVzc2Fu Z2VyLm5ldCBhbmQgYWx1bW5pLmFsbWFtYXRlci5lZHUuDQoNCiAgICAgIFM6IDIyMCBhbHVtbmku YWxtYW1hdGVyLmVkdSBFU01UUCBzZXJ2ZXIgcmVhZHkNCiAgICAgIEM6IEVITE8gY29uc29saWRh dGVkbWVzc2VuZ2VyLm5ldA0KICAgICAgUzogMjUwLWFsdW1uaS5hbG1hbWF0ZXIuZWR1DQogICAg ICBTOiAyNTAtRFNODQogICAgICBTOiAyNTAtQVVUSA0KICAgICAgUzogMjUwLVNVQk1JVFRFUg0K ICAgICAgUzogMjUwIFNJWkUNCiAgICAgIEM6IE1BSUwgRlJPTTo8YWxpY2VAZXhhbXBsZS5jb20+ DQogICAgICAgICAgICAgIFNVQk1JVFRFUj1hbGljZUBjb25zb2xpZGF0ZWRtZXNzZW5nZXIubmV0 DQogICAgICBTOiAyNTAgPGFsaWNlQGV4YW1wbGUuY29tPiBzZW5kZXIgb2sNCiAgICAgIEM6IFJD UFQgVE86PGJvYkBhbHVtbmkuYWxtYW1hdGVyLmVkdT4NCiAgICAgIFM6IDI1MCA8Ym9iQGFsdW1u aS5hbG1hbWF0ZXIuZWR1PiByZWNpcGllbnQgb2sNCiAgICAgIEM6IERBVEENCiAgICAgIFM6IDM1 NCBva2F5LCBzZW5kIG1lc3NhZ2UNCiAgICAgIEM6IFNlbmRlcjogYWxpY2VAY29uc29saWRhdGVk bWVzc2VuZ2VyLm5ldA0KICAgICAgQzogUmVjZWl2ZWQgQnk6IC4uLg0KICAgICAgQzogKG1lc3Nh Z2UgYm9keSBnb2VzIGhlcmUpDQogICAgICBDOiAuDQogICAgICBTOiAyNTAgbWVzc2FnZSBhY2Nl cHRlZA0KICAgICAgQzogUVVJVA0KDQpBbGxtYW4sIEthdHogICAgICAgICAgIEV4cGlyZXMgLSBE ZWNlbWJlciAyMDA0ICAgICAgICAgICAgICAgW1BhZ2UgOF0NCgwNCiAgICAgICAgICAgICAgICAg U01UUCBSZXNwb25zaWJsZSBTdWJtaXR0ZXIgRXh0ZW5zaW9uICAgICAgICBKdW5lIDIwMDQNCg0K DQogICAgICBTOiAyMjEgZ29vZGJ5ZQ0KDQogICBOb3RlIHRoYXQgY29uc29saWRhdGVkbWVzc2Vu Z2VyLm5ldCB1c2VzIHRoZSBTVUJNSVRURVIgcGFyYW1ldGVyIHRvDQogICBkZXNpZ25hdGUgYWxp Y2VAY29uc29saWRhdGVkbWVzc2VuZ2VyLm5ldCBhcyB0aGUgcmVzcG9uc2libGUNCiAgIHN1Ym1p dHRlciBmb3IgdGhpcyBtZXNzYWdlLiAgRnVydGhlciB0aGlzIE1UQSBhbHNvIGluc2VydHMgYSBT ZW5kZXINCiAgIGhlYWRlciB0byBlbnN1cmUgY29uc2lzdGVuY3kgb2YgdGhlIHB1cnBvcnRlZCBy ZXNwb25zaWJsZSBkb21haW4NCiAgIGRlcml2ZWQgZnJvbSB0aGUgUkZDIDI4MjIgaGVhZGVycyB3 aXRoIHRoZSBTVUJNSVRURVIgZG9tYWluLg0KDQo1LjQgR3Vlc3QgRS1tYWlsIFNlcnZpY2UNCg0K ICAgV2hpbGUgb24gYSBidXNpbmVzcyB0cmlwLCBBbGljZSB1c2VzIHRoZSBicm9hZGJhbmQgYWNj ZXNzIGZhY2lsaXRpZXMNCiAgIHByb3ZpZGVkIGJ5IHRoZSBFeGVtcGxhciBIb3RlbCB0byBjb25u ZWN0IHRvIHRoZSBJbnRlcm5ldCBhbmQgc2VuZCBlLQ0KICAgbWFpbC4gIFRoZSBob3RlbCByb3V0 ZXMgYWxsIG91dGJvdW5kIGUtbWFpbCB0aHJvdWdoIGl0cyBvd24gU01UUA0KICAgc2VydmVyLCBl bWFpbC5leGVtcGxhcmhvdGVsLmNvbS4NCg0KICAgVGhlIFNNVFAgc2Vzc2lvbiBmb3IgQWxpY2Un cyBtZXNzYWdlIHRvIEJvYiBmcm9tIHRoZSBFeGVtcGxhciBIb3RlbA0KICAgd291bGQgbG9vayBs aWtlIHRoaXM6DQoNCiAgICAgIFM6IDIyMCBhbHVtbmkuYWxtYW1hdGVyLmVkdSBFU01UUCBzZXJ2 ZXIgcmVhZHkNCiAgICAgIEM6IEVITE8gZW1haWwuZXhlbXBsYXJob3RlbC5jb20NCiAgICAgIFM6 IDI1MC1hbHVtbmkuYWxtYW1hdGVyLmVkdQ0KICAgICAgUzogMjUwLURTTg0KICAgICAgUzogMjUw LUFVVEgNCiAgICAgIFM6IDI1MC1TVUJNSVRURVINCiAgICAgIFM6IDI1MCBTSVpFDQogICAgICBD OiBNQUlMIEZST006PGFsaWNlQGV4YW1wbGUuY29tPg0KICAgICAgICAgICAgICBTVUJNSVRURVI9 Z3Vlc3Quc2VydmljZXNAZW1haWwuZXhlbXBsYXJob3RlbC5jb20NCiAgICAgIFM6IDI1MCA8YWxp Y2VAZXhhbXBsZS5jb20+IHNlbmRlciBvaw0KICAgICAgQzogUkNQVCBUTzo8Ym9iQGFsdW1uaS5h bG1hbWF0ZXIuZWR1Pg0KICAgICAgUzogMjUwIDxib2JAYWx1bW5pLmFsbWFtYXRlci5lZHU+IHJl Y2lwaWVudCBvaw0KICAgICAgQzogREFUQQ0KICAgICAgUzogMzU0IG9rYXksIHNlbmQgbWVzc2Fn ZQ0KICAgICAgQzogUmVzZW50LUZyb206IGd1ZXN0LnNlcnZpY2VzQGVtYWlsLmV4ZW1wbGFyaG90 ZWwuY29tDQogICAgICBDOiBSZWNlaXZlZCBCeTogLi4uDQogICAgICBDOiAobWVzc2FnZSBib2R5 IGdvZXMgaGVyZSkNCiAgICAgIEM6IC4NCiAgICAgIFM6IDI1MCBtZXNzYWdlIGFjY2VwdGVkDQog ICAgICBDOiBRVUlUDQogICAgICBTOiAyMjEgZ29vZGJ5ZQ0KDQogICBOb3RlIHRoYXQgZW1haWwu ZXhlbXBsYXJob3RlbC5jb20gdXNlcyB0aGUgU1VCTUlUVEVSIHBhcmFtZXRlciB0bw0KICAgZGVz aWduYXRlIGEgZ2VuZXJpYyBhY2NvdW50IGd1ZXN0LnNlcnZpY2VzQGVtYWlsLmV4ZW1wbGFyaG90 ZWwuY29tIGFzDQogICB0aGUgcmVzcG9uc2libGUgc3VibWl0dGVyIGFkZHJlc3MgZm9yIHRoaXMg bWVzc2FnZS4gIEEgZ2VuZXJpYw0KICAgYWNjb3VudCBpcyB1c2VkIHNpbmNlIEFsaWNlIGhlcnNl bGYgZG9lcyBub3QgaGF2ZSBhbiBhY2NvdW50IGF0IHRoYXQNCiAgIGRvbWFpbi4gIEZ1cnRoZXIg dGhpcyBjbGllbnQgYWxzbyBpbnNlcnRzIGEgUmVzZW50LUZyb20gaGVhZGVyIHRvDQogICBlbnN1 cmUgY29uc2lzdGVuY3kgb2YgdGhlIHB1cnBvcnRlZCByZXNwb25zaWJsZSBkb21haW4gZGVyaXZl ZCBmcm9tDQogICB0aGUgUkZDIDI4MjIgaGVhZGVycyB3aXRoIHRoZSBTVUJNSVRURVIgZG9tYWlu Lg0KDQoNCg0KDQpBbGxtYW4sIEthdHogICAgICAgICAgIEV4cGlyZXMgLSBEZWNlbWJlciAyMDA0 ICAgICAgICAgICAgICAgW1BhZ2UgOV0NCgwNCiAgICAgICAgICAgICAgICAgU01UUCBSZXNwb25z aWJsZSBTdWJtaXR0ZXIgRXh0ZW5zaW9uICAgICAgICBKdW5lIDIwMDQNCg0KDQo2LiBTZWN1cml0 eSBDb25zaWRlcmF0aW9ucw0KDQogICBUaGUgcHVycG9zZSBvZiB0aGlzIGV4dGVuc2lvbiBpcyB0 byBoZWxwIGRldGVyIHRoZSBwcmFjdGljZSBvZg0KICAgZm9yZ2luZyBvciAic3Bvb2ZpbmciIHRo ZSBhZGRyZXNzIG9mIHRoZSBzZW5kZXIgb2YgYW4gZS1tYWlsIG1lc3NhZ2UuDQoNCiAgIEl0IGlz LCBob3dldmVyLCBxdWl0ZSBwb3NzaWJsZSBmb3IgYW4gYXR0YWNrZXIgdG8gZm9yZ2UgdGhlIHZh bHVlIG9mDQogICB0aGUgU1VCTUlUVEVSIHBhcmFtZXRlciBhbHNvLiAgVGhlcmVmb3JlIHRoZSBw cmVzZW5jZSBvZiB0aGUNCiAgIFNVQk1JVFRFUiBwYXJhbWV0ZXIgcHJvdmlkZXMsIGJ5IGl0c2Vs Ziwgbm8gYXNzdXJhbmNlIG9mIHRoZQ0KICAgYXV0aGVudGljaXR5IG9mIHRoZSBtZXNzYWdlIG9y IHRoZSBzZW5kZXIuICBSYXRoZXIsIHRoZSBTVUJNSVRURVINCiAgIHBhcmFtZXRlciBpcyBpbnRl bmRlZCB0byBwcm92aWRlIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gdG8gcmVjZWl2aW5nDQogICBl LW1haWwgc3lzdGVtcyB0byBlbmFibGUgdGhlbiB0byBlZmZpY2llbnRseSBkZXRlcm1pbmUgdGhl IHZhbGlkaXR5DQogICBvZiB0aGUgc2VuZGVyLCBhbmQgc3BlY2lmaWNhbGx5LCB3aGV0aGVyIHRo ZSBTTVRQIGNsaWVudCBpcw0KICAgYXV0aG9yaXplZCB0byB0cmFuc21pdCBlLW1haWwgb24gYmVo YWxmIG9mIHRoZSBwdXJwb3J0ZWQgcmVzcG9uc2libGUNCiAgIHNlbmRlcidzIGRvbWFpbi4gIFNl Y3Rpb24gNC4yIGRlc2NyaWJlcyBob3cgcmVjZWl2aW5nIGUtbWFpbCBzeXN0ZW1zDQogICBzaG91 bGQgcHJvY2VzcyB0aGUgU1VCTUlUVEVSIHBhcmFtZXRlci4NCg0KICAgVGhpcyBleHRlbnNpb24g b2ZmZXJzIG5vIHByb3RlY3Rpb24gYWdhaW5zdCBhIHVzZXIgaW4gb25lIGRvbWFpbg0KICAgc3Bv b2ZpbmcgYW5vdGhlciB1c2VyIHdpdGhpbiB0aGUgc2FtZSBkb21haW4uDQoNCjcuIFJlZmVyZW5j ZXMNCg0KNy4xIE5vcm1hdGl2ZSBSZWZlcmVuY2VzDQoNCiAgICBbQUJORl0gICAgICAgICBDcm9j a2VyLCBELiBhbmQgUC4gT3ZlcmVsbCwgIkF1Z21lbnRlZCBCTkYgZm9yIFN5bnRheA0KICAgICAg ICAgICAgICAgICAgIFNwZWNpZmljYXRpb25zOiBBQk5GIiwgUkZDIDIyMzQsIE5vdmVtYmVyIDE5 OTcuDQoNCiAgICBbRFNOXSAgICAgICAgICBNb29yZSwgSy4sICJTaW1wbGUgTWFpbCBUcmFuc2Zl ciBQcm90b2NvbCAoU01UUCkNCiAgICAgICAgICAgICAgICAgICBTZXJ2aWNlIEV4dGVuc2lvbiBm b3IgRGVsaXZlcnkgU3RhdHVzIE5vdGlmaWNhdGlvbnMNCiAgICAgICAgICAgICAgICAgICAoRFNO cykiLCBSRkMgMzQ2MSwgSmFudWFyeSAyMDAzLg0KDQogICAgW0tFWVdPUkRTXSAgICAgQnJhZG5l ciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlDQogICAgICAgICAg ICAgICAgICAgUmVxdWlyZW1lbnQgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSwgTWFyY2ggMTk5 Ny4NCg0KICAgIFtNU0ctRk9STUFUXSAgIFJlc25pY2ssIFAuLCBFZC4sICJJbnRlcm5ldCBNZXNz YWdlIEZvcm1hdCIsIFJGQw0KICAgICAgICAgICAgICAgICAgIDI4MjIsIEFwcmlsIDIwMDEuDQoN CiAgICBbU0VOREVSLUlEXSAgICBMeW9uLCBKLiBhbmQgTWVuZyBXZW5nIFdvbmcsICJNVEEgQXV0 aGVudGljYXRpb24NCiAgICAgICAgICAgICAgICAgICBSZWNvcmRzIGluIEROUyIsIGRyYWZ0LWll dGYtbWFyaWQtY29yZS0wMSwgSnVuZSAyMDA0Lg0KDQogICAgW1NVQk1JVF0gICAgICAgR2VsbGVu cywgUi4gYW5kIEouIEtsZW5zaW4sICJNZXNzYWdlIFN1Ym1pc3Npb24iLCBSRkMNCiAgICAgICAg ICAgICAgICAgICAyNDc2LCBEZWNlbWJlciAxOTk4Lg0KDQogICAgW1NURF0gICAgICAgICAgQnJh ZG5lciwgUy4sICJUaGUgSW50ZXJuZXQgU3RhbmRhcmRzIFByb2Nlc3MgLS0NCiAgICAgICAgICAg ICAgICAgICBSZXZpc2lvbiAzIiwgQkNQIDksIFJGQyAyMDI2LCBPY3RvYmVyIDE5OTYuDQoNCiAg ICBbU01UUF0gICAgICAgICBLbGVuc2luLCBKLiwgIlNpbXBsZSBNYWlsIFRyYW5zZmVyIFByb3Rv Y29sIiwgUkZDDQogICAgICAgICAgICAgICAgICAgMjgyMSwgQXByaWwgMjAwMS4NCg0KDQoNCkFs bG1hbiwgS2F0eiAgICAgICAgICAgRXhwaXJlcyAtIERlY2VtYmVyIDIwMDQgICAgICAgICAgICAg IFtQYWdlIDEwXQ0KDA0KICAgICAgICAgICAgICAgICBTTVRQIFJlc3BvbnNpYmxlIFN1Ym1pdHRl ciBFeHRlbnNpb24gICAgICAgIEp1bmUgMjAwNA0KDQoNCiAgICBbU01UUEFVVEhdICAgICBNZXll cnMsIEouLCAiU01UUCBTZXJ2aWNlIEV4dGVuc2lvbiBmb3INCiAgICAgICAgICAgICAgICAgICBB dXRoZW50aWNhdGlvbiIsIFJGQyAyNTU0LCBNYXJjaCAxOTk5Lg0KDQo3LjIgSW5mb3JtYXRpdmUg UmVmZXJlbmNlcw0KDQogICAgW0NBTExFUklEXSAgICAgQXRraW5zb24sIEIsIENhbGxlciBJRCBm b3IgRS1tYWlsLCBNYXkgMjAsIDIwMDQsDQogICAgICAgICAgICAgICAgICAgZHJhZnQtYXRraW5z b24tY2FsbGVyaWQtMDAuDQoNCiAgICBbTE1BUF0gICAgICAgICBEZUtvaywgQS4gKEVkLiksIExp Z2h0d2VpZ2h0IE1UQSBBdXRoZW50aWNhdGlvbg0KICAgICAgICAgICAgICAgICAgIFByb3RvY29s IChMTUFQKSBEaXNjdXNzaW9uIGFuZCBBcHBsaWNhYmlsaXR5LA0KICAgICAgICAgICAgICAgICAg IE5vdmVtYmVyIDMsIDIwMDMsIGRyYWZ0LWlydGYtYXNyZy1sbWFwLWRpc2N1c3Npb24tMDAuDQoN CiAgICBbUk1YXSAgICAgICAgICBEYW5pc2NoLCBIYWRtdXQsIFRoZSBSTVggRE5TIFJSIGFuZCBt ZXRob2QgZm9yIFNNVFANCiAgICAgICAgICAgICAgICAgICBTZW5kZXIgQXV0aG9yaXphdGlvbiwg ZHJhZnQtZGFuaXNjaC1kbnMtcnItc210cC0wMy4NCg0KICAgIFtTUEZdICAgICAgICAgIFdvbmcs IE1lbmcgV2VuZywgTWFyayBMZW50Y3puZXIsIFNlbmRlciBQZXJtaXR0ZWQNCiAgICAgICAgICAg ICAgICAgICBGcm9tLCBkcmFmdC1tZW5nd29uZy1zcGYtMDEuDQoNCjguIEFja25vd2xlZGdtZW50 cw0KDQogICBUaGUgYXV0aG9ycyB3b3VsZCBsaWtlIHRvIHRoYW5rIHRoZSBwYXJ0aWNpcGFudHMg b2YgdGhlIE1BUklEIHdvcmtpbmcNCiAgIGdyb3VwIGFuZCB0aGUgZm9sbG93aW5nIGluZGl2aWR1 YWxzIGZvciB0aGVpciBjb21tZW50cyBhbmQNCiAgIHN1Z2dlc3Rpb25zLCB3aGljaCBncmVhdGx5 IGltcHJvdmVkIHRoaXMgZG9jdW1lbnQ6DQoNCiAgICAgIFJvYmVydCBBdGtpbnNvbiwgU2ltb24g QXR0d2VsbCwgSmltIEx5b24sIEJydWNlIE1jTWlsbGFuLA0KICAgICAgU2FtIE5lZWx5LCBQZXRl IFJlc25pY2ssIE5pY2sgU2hlbG5lc3MsIE1lbmcgV2VuZyBXb25nDQoNCjkuIEF1dGhvcnMnIEFk ZHJlc3Nlcw0KDQogICBFcmljIEFsbG1hbg0KICAgU2VuZG1haWwsIEluYy4NCiAgIDY0MjUgQ2hy aXN0aWUgQXZlLCBTdWl0ZSA0MDANCiAgIEVtZXJ5dmlsbGUsIENBIDk0NjA4DQogICBVU0ENCg0K ICAgRS1tYWlsOiBlcmljQHNlbmRtYWlsLmNvbQ0KDQogICBIYXJyeSBLYXR6DQogICBNaWNyb3Nv ZnQgQ29ycC4NCiAgIDEgTWljcm9zb2Z0IFdheQ0KICAgUmVkbW9uZCwgV0EgOTgwNTINCiAgIFVT QQ0KDQogICBFLW1haWw6IGhrYXR6QG1pY3Jvc29mdC5jb20NCg0KDQoNCg0KDQoNCg0KQWxsbWFu LCBLYXR6ICAgICAgICAgICBFeHBpcmVzIC0gRGVjZW1iZXIgMjAwNCAgICAgICAgICAgICAgW1Bh Z2UgMTFdDQoMDQogICAgICAgICAgICAgICAgIFNNVFAgUmVzcG9uc2libGUgU3VibWl0dGVyIEV4 dGVuc2lvbiAgICAgICAgSnVuZSAyMDA0DQoNCg0KMTAuIEZ1bGwgQ29weXJpZ2h0IFN0YXRlbWVu dA0KDQogICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDA0KS4gIFRoaXMg ZG9jdW1lbnQgaXMgc3ViamVjdA0KICAgdG8gdGhlIHJpZ2h0cywgbGljZW5zZXMgYW5kIHJlc3Ry aWN0aW9ucyBjb250YWluZWQgaW4gQkNQIDc4IGFuZA0KICAgZXhjZXB0IGFzIHNldCBmb3J0aCB0 aGVyZWluLCB0aGUgYXV0aG9ycyByZXRhaW4gYWxsIHRoZWlyIHJpZ2h0cy4NCg0KICAgVGhpcyBk b2N1bWVudCBhbmQgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gYXJlIHByb3ZpZGVk IG9uIGFuDQogICAiQVMgSVMiIGJhc2lzIGFuZCBUSEUgQ09OVFJJQlVUT1IsIFRIRSBPUkdBTkla QVRJT04gSEUvU0hFIFJFUFJFU0VOVFMNCiAgIE9SIElTIFNQT05TT1JFRCBCWSAoSUYgQU5ZKSwg VEhFIElOVEVSTkVUIFNPQ0lFVFkgQU5EIFRIRSBJTlRFUk5FVA0KICAgRU5HSU5FRVJJTkcgVEFT SyBGT1JDRSBESVNDTEFJTSBBTEwgV0FSUkFOVElFUywgRVhQUkVTUyBPUiBJTVBMSUVELA0KICAg SU5DTFVESU5HIEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9G IFRIRQ0KICAgSU5GT1JNQVRJT04gSEVSRUlOIFdJTEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMg T1IgQU5ZIElNUExJRUQNCiAgIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5F U1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLg0KDQogICBJbnRlbGxlY3R1YWwgUHJvcGVydHkN Cg0KICAgVGhlIElFVEYgdGFrZXMgbm8gcG9zaXRpb24gcmVnYXJkaW5nIHRoZSB2YWxpZGl0eSBv ciBzY29wZSBvZiBhbnkNCiAgIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBSaWdodHMgb3Igb3RoZXIg cmlnaHRzIHRoYXQgbWlnaHQgYmUgY2xhaW1lZA0KICAgdG8gcGVydGFpbiB0byB0aGUgaW1wbGVt ZW50YXRpb24gb3IgdXNlIG9mIHRoZSB0ZWNobm9sb2d5IGRlc2NyaWJlZA0KICAgaW4gdGhpcyBk b2N1bWVudCBvciB0aGUgZXh0ZW50IHRvIHdoaWNoIGFueSBsaWNlbnNlIHVuZGVyIHN1Y2ggcmln aHRzDQogICBtaWdodCBvciBtaWdodCBub3QgYmUgYXZhaWxhYmxlOyBub3IgZG9lcyBpdCByZXBy ZXNlbnQgdGhhdCBpdCBoYXMNCiAgIG1hZGUgYW55IGluZGVwZW5kZW50IGVmZm9ydCB0byBpZGVu dGlmeSBhbnkgc3VjaCByaWdodHMuIEluZm9ybWF0aW9uDQogICBvbiB0aGUgcHJvY2VkdXJlcyB3 aXRoIHJlc3BlY3QgdG8gcmlnaHRzIGluIFJGQyBkb2N1bWVudHMgY2FuIGJlDQogICBmb3VuZCBp biBCQ1AgNzggYW5kIEJDUCA3OS4NCg0KICAgQ29waWVzIG9mIElQUiBkaXNjbG9zdXJlcyBtYWRl IHRvIHRoZSBJRVRGIFNlY3JldGFyaWF0IGFuZCBhbnkNCiAgIGFzc3VyYW5jZXMgb2YgbGljZW5z ZXMgdG8gYmUgbWFkZSBhdmFpbGFibGUsIG9yIHRoZSByZXN1bHQgb2YgYW4NCiAgIGF0dGVtcHQg bWFkZSB0byBvYnRhaW4gYSBnZW5lcmFsIGxpY2Vuc2Ugb3IgcGVybWlzc2lvbiBmb3IgdGhlIHVz ZSBvZg0KICAgc3VjaCBwcm9wcmlldGFyeSByaWdodHMgYnkgaW1wbGVtZW50ZXJzIG9yIHVzZXJz IG9mIHRoaXMNCiAgIHNwZWNpZmljYXRpb24gY2FuIGJlIG9idGFpbmVkIGZyb20gdGhlIElFVEYg b24tbGluZSBJUFIgcmVwb3NpdG9yeSBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pcHIuDQoN CiAgIFRoZSBJRVRGIGludml0ZXMgYW55IGludGVyZXN0ZWQgcGFydHkgdG8gYnJpbmcgdG8gaXRz IGF0dGVudGlvbiBhbnkNCiAgIGNvcHlyaWdodHMsIHBhdGVudHMgb3IgcGF0ZW50IGFwcGxpY2F0 aW9ucywgb3Igb3RoZXIgcHJvcHJpZXRhcnkNCiAgIHJpZ2h0cyB0aGF0IG1heSBjb3ZlciB0ZWNo bm9sb2d5IHRoYXQgbWF5IGJlIHJlcXVpcmVkIHRvIGltcGxlbWVudA0KICAgdGhpcyBzdGFuZGFy ZC4gIFBsZWFzZSBhZGRyZXNzIHRoZSBpbmZvcm1hdGlvbiB0byB0aGUgSUVURiBhdCBpZXRmLQ0K ICAgaXByQGlldGYub3JnLg0KDQpBY2tub3dsZWRnZW1lbnQNCg0KICAgRnVuZGluZyBmb3IgdGhl IFJGQyBFZGl0b3IgZnVuY3Rpb24gaXMgY3VycmVudGx5IHByb3ZpZGVkIGJ5IHRoZQ0KICAgSW50 ZXJuZXQgU29jaWV0eS4NCg0KDQoNCg0KDQoNCg0KDQoNCkFsbG1hbiwgS2F0eiAgICAgICAgICAg RXhwaXJlcyAtIERlY2VtYmVyIDIwMDQgICAgICAgICAgICAgIFtQYWdlIDEyXQ0KDA== ------_=_NextPart_001_01C4596F.EC8A5247-- From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 19:09:05 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26033 for ; Wed, 23 Jun 2004 19:09:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NMv4kF001255; Wed, 23 Jun 2004 15:57:04 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NMv4Cf001254; Wed, 23 Jun 2004 15:57:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.mail-abuse.org [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NMv4nO001238 for ; Wed, 23 Jun 2004 15:57:04 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.mail-abuse.org (DDev.mail-abuse.org [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id B08D1414AC; Wed, 23 Jun 2004 15:57:04 -0700 (PDT) Subject: Re: using reputation lookups first From: Douglas Otis To: Meng Weng Wong Cc: "'IETF MARID WG'" In-Reply-To: <20040623210515.GF13225@dumbo.pobox.com> References: <40D9C1DA.9090103@ehsco.com> <20040623210515.GF13225@dumbo.pobox.com> Content-Type: text/plain Message-Id: <1088031424.23891.85.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 23 Jun 2004 15:57:04 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-06-23 at 14:05, Meng Weng Wong wrote: > On Wed, Jun 23, 2004 at 12:46:02PM -0500, Eric A. Hall wrote: > | > | What is the possibility that an attacker could list a (SID|SPF) record > | with references to ~thousands of domains, forcing my SMTP server to spend > | large amounts of time and/or processing power validating the junk data? > | What other similar kinds of attacks are enabled by infinite extensibility? > > These attack scenarios have been raised in the past. Seen > from the point of view of "don't spammers want their mail to > get through?" they seem unlikely, but if we counter "but > spammers may want to attack the integrity of the entire > system as a whole" they make more sense. > > In fact, your attack scenario can be constructed independent > of extensibility considerations. The moment you introduce a > new behaviour (a MARID dns lookup) you are able to attack it > (a slow SERVFAIL will consume resources). Extensibility > amplifies the attack in degree but not in kind. By attacking and breaking the MARID mechanism in the channel, assurances offered recipients become easily spoofed. The result of the attack could allow a bonanza of fraud displaying the highly promoted MARID seal of approval. > We are moving from an "assumed innocent unless proven > guilty" model of email to an "assumed guilty unless proven > innocent" model. > > I see this as a simple matter of hygiene in the big city. > If the crazy homeless guy on the street offers me a > bloodstained driver's license, I won't even get as far as > looking at its expiration date; I won't even take it for > fear of disease. > > In the same way, the best defense against the attacks you > suggest is to perform the reputation lookup *before* the > authentication lookup. If the name of the domain is used, there would be no protection afforded. Reputation based upon address is difficult to accurately vet and thus is not as comprehensive. An address also provides no history other than was once known to have been abused. > If the reputation lookup says "bad guy" then the authentication > lookup is moot. > > If the reputation lookup says "good guy" then you have > reason to believe the query won't crash your system. This would suggest that a "good guy" address list be created as protection prior to SPF/CID authentication techniques. This would be difficult to vet and would be prone to false negatives. The service would not see the domain it references. With all this, it sounds as if you are advocating DNS be mirrored privately. Attacks may be staged by selecting diverse and real, but complex and convoluted records. Heavy loads on these name servers could provide erratic responses without a need to engineer this behavior. The SPF/CID process will continue through the entire list as a result. Add to this, the use of hostile name servers offering maniacal records that do authenticate. Frankly, either approach could bring down this complex SPF/CID system regardless of the use of these hygienic precautions. > If the reputation lookup says "no reputation, but > accredited" you can provisionally assume "good guy". This implies yet another category. New to the "good guy" list perhaps? > If the reputation lookup says "unknown and unaccredited", > > If you are being very cautious, you may wish to greylist > and return 4xx without doing the auth lookup at all. A > distributed reputation system should obtain information > fast enough to be useful the next time the query happens. > > If you are being less cautious, you can do the auth lookup > anyway, and if it fails to resolve within a reasonable > amount of time, you can abort the lookups and feed a > grumpy opinion into your reputation service. The next > time the attack occurs, you'll know not to do the auth > query. Introduce noise into subsequent iterations > according to game theory to create opportunities for > forgiveness. > > Some MTA admins I know are looking at the OS fingerprint of > the incoming packets and rejecting any mail that comes from > a Windows OS. This blocks a lot of viruses at the cost of > cutting out legitimate Windows MTAs. I mention this as an > anecdote only. Authorizing and authenticating the MTA can happen at the same moment a query is sent to reputation services, if this authorization and authentication only require return of a single record as illustrated in- http://www.ietf.org/internet-drafts/draft-ietf-marid-csv-csa-00.txt With this approach there would be little exposure to a threat without reliance upon a reputation service. In addition, use of the HELO domain would enable a means to follow-up on abuses needed by authorities. For absolute protection from joe jobs, promote the use of the Fenton proposal for critical communications such as those used for commerce. Perhaps make it criminal not to use this Fenton mechanism when advertising. This Fenton process can safely take place at the MUA and not negatively impact either SMTP or DNS. This krs approach is extensible if desired as it can be scaled. Have it add a photo, voice, or video to help prevent mistaken identifications of the human kind. Importantly, these alternatives would not break the current way mail is used. -Doug From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 19:42:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27862 for ; Wed, 23 Jun 2004 19:42:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NNTvgC007942; Wed, 23 Jun 2004 16:29:57 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NNTvYL007941; Wed, 23 Jun 2004 16:29:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NNTu9n007924 for ; Wed, 23 Jun 2004 16:29:56 -0700 (PDT) (envelope-from roy+dated+1090625397.eed579@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i5NNTvRC029923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 23 Jun 2004 23:29:58 GMT (envelope-from roy+dated+1090625397.eed579@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5NNTvmO067724 for ; Thu, 24 Jun 2004 00:29:57 +0100 (BST) (envelope-from roy+dated+1090625397.eed579@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5NNTvjS067723 for ietf-mxcomp@imc.org; Thu, 24 Jun 2004 00:29:57 +0100 (BST) (envelope-from roy+dated+1090625397.eed579@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Thu, 24 Jun 2004 00:28:56 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16602.4663.751384.263061@giles.gnomon.org.uk> Date: Thu, 24 Jun 2004 00:28:55 +0100 To: "Harry Katz" Cc: "Eric Allman" , "IETF MARID List" , "Meng Weng Wong" Subject: draft-ietf-marid-submitter-01.txt In-Reply-To: References: X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit [Trimmed CC list] Would it be worth adding something along the lines of the following to the end of 4.2? Any MTA not supporting the Responsible Submitter extension that redirects a message from the address listed in the RFC 2821 RCPT TO command is nonetheless encouraged to modify the message according to (a) and (b) above. This is clearly what we want, and what we expect (prior to flag day). Also, I now notice that 4.2 (c) is still too strong (imposing a greater requirement on resending than on initial sending). Using the SUBMITTER parameter when sending is a SHOULD, but when resending it's a MUST. (c) is now confusing anyway, since a resender might change either or both of the PRA and the MAIL FROM, but it always needs to ensure that SUBMITTER is consistent (or absent) even if the new MAIL FROM and new PRA match (which isn't required by the new text, at least by my reading). I think what (c) really wants to say is: (c) Adding, replacing or removing the SUBMITTER parameter such that the message continues to satify the requirements of section 4.1 above, with references in that section to the purported responsible address being taken as references to the new purported responsible address. In particular, consider a SUBMITTER-compliant MTA, which chooses not to observe the SHOULD in section 4.1 and chooses never to include the SUBMITTER parameter in MAIL FROM commands it issues (presumably for reasons of coding expediency when modifying an existing MTA). Now consider a list processor running on the same machine as this MTA. Assume the header changes required by (b) are made by the list processor, and that the MTA is largely unaware of the existence of the list processor (as is typically the case) and treats mail sumbitted to it by the list processor in much the same way as any other mail submitted to it. Such a setup does what we want, but violates (c) as currently written, since what this setup actually does is remove the SUBMITTER parameter, rather than add or replace it. Yet (pre flag day) such a setup should be perfectly valid, since including SUBMITTER is only a SHOULD, not a MUST. -roy From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 19:49:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28280 for ; Wed, 23 Jun 2004 19:49:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NNhS9F010570; Wed, 23 Jun 2004 16:43:28 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NNhSVs010569; Wed, 23 Jun 2004 16:43:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from miz-mishtal.dbc.mtview.ca.us (adsl-64-168-10-250.dsl.scrm01.pacbell.net [64.168.10.250]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NNhRPK010554 for ; Wed, 23 Jun 2004 16:43:27 -0700 (PDT) (envelope-from mrose@dbc.mtview.ca.us) Received: from [IPv6:::1] (localhost [127.0.0.1]) by miz-mishtal.dbc.mtview.ca.us (8.12.10/8.12.9) with ESMTP id i5NNVA3v021894; Wed, 23 Jun 2004 16:31:12 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <68074654-C56D-11D8-B34F-000A95CA7FAE@dbc.mtview.ca.us> Cc: "Jim Lyon" , "Meng Weng Wong" , "Andrew Newton" , , "IETF MARID List" From: Marshall Rose Subject: Re: draft-ietf-marid-core-01.txt Date: Wed, 23 Jun 2004 16:31:09 -0700 To: "Harry Katz" X-Mailer: Apple Mail (2.618) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5NNhSPK010556 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Jun 23, 2004, at 15:13, Harry Katz wrote: > Attached is the latest version of the MARID Core spec, a.k.a. Sender > ID.  Feedback welcome. >   > Co-charis, please approve.  Thanks. > approved. by the way, after -00 is approved, you no longer need to ask for approval... /mtr From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 19:51:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28414 for ; Wed, 23 Jun 2004 19:51:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NNha86010601; Wed, 23 Jun 2004 16:43:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NNhatk010600; Wed, 23 Jun 2004 16:43:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from miz-mishtal.dbc.mtview.ca.us (adsl-64-168-10-250.dsl.scrm01.pacbell.net [64.168.10.250]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NNhZfV010593 for ; Wed, 23 Jun 2004 16:43:35 -0700 (PDT) (envelope-from mrose@dbc.mtview.ca.us) Received: from [IPv6:::1] (localhost [127.0.0.1]) by miz-mishtal.dbc.mtview.ca.us (8.12.10/8.12.9) with ESMTP id i5NNVA3w021894; Wed, 23 Jun 2004 16:31:49 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <7F41BF89-C56D-11D8-B34F-000A95CA7FAE@dbc.mtview.ca.us> Cc: "Eric Allman" , "Jim Lyon" , "Meng Weng Wong" , "Andrew Newton" , , "IETF MARID List" From: Marshall Rose Subject: Re: draft-ietf-marid-submitter-01.txt Date: Wed, 23 Jun 2004 16:31:48 -0700 To: "Harry Katz" X-Mailer: Apple Mail (2.618) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5NNhZfV010594 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Jun 23, 2004, at 15:17, Harry Katz wrote: > Attached is the latest revision to the Responsible Submitter > internet-draft.  This draft completes the missing sections from the > -00 version and addresses a couple of minor issues raised in feedback > to the list.  Thanks to those who provided that feedback.   Comments > on this version are welcome. >   > Co-chairs please approve.  >   > Thanks > thanks! approved (redundant after -00) /mtr From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 19:51:29 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28442 for ; Wed, 23 Jun 2004 19:51:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NNi59S010689; Wed, 23 Jun 2004 16:44:05 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NNi5g3010688; Wed, 23 Jun 2004 16:44:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.mail-abuse.org [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NNi4M6010665 for ; Wed, 23 Jun 2004 16:44:04 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.mail-abuse.org (DDev.mail-abuse.org [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id 77F09414B4; Wed, 23 Jun 2004 16:44:05 -0700 (PDT) Subject: Re: extensibility as an attack vector From: Douglas Otis To: Hadmut Danisch Cc: "Eric A. Hall" , "'IETF MARID WG'" In-Reply-To: <20040623213212.GA30716@danisch.de> References: <40D9C1DA.9090103@ehsco.com> <20040623213212.GA30716@danisch.de> Content-Type: text/plain Message-Id: <1088034245.23891.132.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 23 Jun 2004 16:44:05 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-06-23 at 14:32, Hadmut Danisch wrote: > On Wed, Jun 23, 2004 at 12:46:02PM -0500, Eric A. Hall wrote: > > > > What is the possibility that an attacker could list a (SID|SPF) record > > with references to ~thousands of domains, forcing my SMTP server to spend > > large amounts of time and/or processing power validating the junk data? > > What other similar kinds of attacks are enabled by infinite extensibility? > > > > There is also still the argument that 513-byte records affect a DDoS > > attack against my domain. > > > > The more I think about this, the less I think that extensibility is a good > > idea in general. > > No. This is not a problem of extensibility. > > This is an attack outside the threat model. > All these caller authorization methods are designed against > an attacker who does not want to reveal his identity (=domain). If the attack simply provides the wrong name, it may take a prolonged period to discover this falsehood. The hostile intent is to disable the channel checks for MARID. If the lie is perpetrated many times to different destinations, then the hapless name server would be expected to become erratic. (MARID=DDoS) > An attacker who attacks you while not hiding his own domain is > a different kind of attack. Such an attacker could also simply > allow mail from 0.0.0.0/0, thus authorizing all IP addresses in > order to allow spam. Nothing so brazen is needed. Real open lists provide the same avenue for committing fraud. Without requiring an absolute acceptance of accountability, as perhaps with EHLO, the system remains prone. This absolute is not possible if based upon other identities. It must reference the domain currently sending mail. > This has already been discussed more than a year ago in ASRG and > addressed in RMX and other proposals. It is up to you to define > a policy about domains you're willing to accept mail from. I doubt there is such a safe area with SPF/CID. > E.g. you could choose to not accept mail from domains authorizing > more than 50 IP addresses. If my domain points to AOL as an outside provider and they have this number, then my mail becomes rejected? How can such a policy apply uniformly without millions of exceptions? > Thus the interpreter could reject messages from domains with > such a record with thousands of references without performing > a single query. And you should do it. Whatever limit you define, that will become known to the attacker learning to fly below your radar. > Imagine this attack: An attacker is sending millions of spam with > his own sender address @attacker.tld > His MARID record is generated dynamically with thousand references > of the type randomnumber.victim.tld > > Thus the victim's DNS server will have to serve billions of queries. > You need limits. The standard needs limits. For EHLO checks, it could be just one. > But, if this happens, you know at least the domain the attacks came > from. How? If the attacker referenced an open list, there was never any positive identification. > It is similar to the case where the spammer simply used his > own domain as a sender address (=does not fake). Fake protection is > useless against attackers who do not fake. This was in regard to an attack where even real records offer a means to obfuscate the identify of the host sending mail. With perhaps millions unwilling to close lists due to a loss of an ability to use alternative access, those wishing to abuse the system are afforded ample means to hide their identify and evade being categorized. > You still need blacklisting, but now blacklisting is possible. And you > need whois entries which allow to identify the person responsible for > the domain. How does blacklisting become more effective if the identification remains unknown? SPF/CID create valid reasons for retaining open lists. Their existence doom any scheme that relies upon positive identification. Outside the use of the EHLO domain, where can identification become strict without breaking SMTP? -Doug From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 19:55:39 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28722 for ; Wed, 23 Jun 2004 19:55:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NNlNdB011361; Wed, 23 Jun 2004 16:47:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NNlNsQ011360; Wed, 23 Jun 2004 16:47:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [64.139.47.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NNlMxW011353 for ; Wed, 23 Jun 2004 16:47:22 -0700 (PDT) (envelope-from gconnor@nekodojo.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by neko-base.nekodojo.org (Postfix) with ESMTP id 92C661D651 for ; Wed, 23 Jun 2004 16:47:27 -0700 (PDT) Date: Wed, 23 Jun 2004 16:47:28 -0700 From: Greg Connor To: IETF MARID WG Subject: Could binary encoding really be the answer? Message-ID: <27544286.1088009248@Ryoga.corp.sgi.com> In-Reply-To: <13664248.1087995368@Ryoga.corp.sgi.com> References: <13664248.1087995368@Ryoga.corp.sgi.com> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Team- I am sending my third and final message of the day, in order to express support for Hadmut's suggestion of a binary encoding. I think this is a good idea, and I believe it combines the best of various worlds (extensibility, economy, etc). Here are some highlights. 1. Records can be composed in SPF, XML, or with a wizard. Whatever the input, the DNS format transmitted over the wire is a binary encoding. MTAs need to understand the binary and that's it. 2. DNS servers are not required to read other format, but they can. If they do, you can enter either SPF or XML text in the zone file. DNS tools like dig can display one or both formats. 3. The new binary format applies to the new MARID RR. I would probably want to keep using SPF format in the TXT records in the short term, because I'm not entirely sure of my ability to type binary data into a zone file. TXT records in SPF format are referred to as "legacy format" records. Use of TXT records may be deprecated at some future time when the new RR is widely available. I think this allows for extensibility and reuse of other standards, like the XML team wants, and it also allows for byte economy like the DNS core folks want, and MTA independence that the MTA writers want. I am not sure how Microsoft is going to like this proposal... on the one hand we are approving XML for use in composing the records, which is good, but on the other hand we are defining a new RR and MS needs to fix their servers to understand the new RR. This can take however long it's going to take, and the TXT record is available now, but not in XML. The way I see it, it will be tough for MS to have it both ways: they are probably not going to win approval for a new data format (MARID XML) AND also avoid the work of deploying a new RR. Feedback? Comments? Flames? Hadmut's previous message any my previous reply follows here (in case you were ignoring the other thread :) --Greg Connor wrote: > > --Hadmut Danisch wrote: > >> After spending a few more minutes to thing about it, I'd currently >> propose this (which, I admit, would also require the gods of DNS to >> move a little bit forward to accept it): >> > ... >> An MTA would receive the record as it is, as a bit/byte sequence. >> DNS does not care about it's structure. The MTA then simply passes >> this record to the MARID interpreter, together with other parameters >> (peer IP address, sender address,...). The MARID interpreter then >> disassembles the ASN.1 encoding. >> >> This way anything is completely covered in the MARID interpreter. >> All DNS parts don't depend on any detail. > > > I would agree with this. I like the idea of being able to go forward > without waiting for DNS upgrades. > > Given a choice I would probably lean toward the TXT record being one of > the human-readable representations, and the new RR being the "binary" > form, but I don't have a strong feeling and I'm willing to be talked out > of it :) > > Question for the DNS/bind gurus out there. Is it possible to put stuff > in your zone file using TYPE1234 notation, even if the bind version > doesn't support it? We would probably want to go with TXT at first but > when we have an RR type it would nice to start using it... I'm not sure > if this is possible. > > >> Now give it eye sugar: >> >> Allow the DNS encoder (i.e. bind reading the zone file) to not only >> understand base64 text representations, but also other >> representations, like SPF, XML, or whatever future might bring. >> >> In the same library, allow MARID records to be converted into >> any of a list of representations: base64, SPF, XML. >> >> This way, it will *always* work with base64. That's the fallback >> solutions. If you can't upgrade your DNS software, it will always work. > > > Good. Also, when we get around to publishing a new RR and rolling > support for it into various DNS servers, we can make a recommendation for > other "additional" records that can be stuffed in the response packet. > For example, if the a: mx: or include: mechanisms are used, the > additional section could include the A, MX, or other MARID record in the > first reply packet. This is of course optional for the DNS server, but > as long as we are working on a new RR in DNS we might as well make > recommendations on additional records too. > > >> If you extend the MARID records, it depends on wether the extension >> is marked critical or not (see my former posting). Non-critical >> extensions allow slow upgrades. Or even no upgrades. >> >> And then you have time to extend SPF or XML syntax and upgrade >> the conversion library. Until then, base64 always works. Just hack >> a perl script to encode new record types. > > > Good stuff. Thanks. > > > -- > Greg Connor -- Greg Connor From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 20:06:28 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29330 for ; Wed, 23 Jun 2004 20:06:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NNwd8K013675; Wed, 23 Jun 2004 16:58:39 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NNwdMc013674; Wed, 23 Jun 2004 16:58:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NNwcMM013668 for ; Wed, 23 Jun 2004 16:58:38 -0700 (PDT) (envelope-from roy+dated+1090627122.c8a94b@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i5NNwgRC062423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 23 Jun 2004 23:58:43 GMT (envelope-from roy+dated+1090627122.c8a94b@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5NNwgba067947 for ; Thu, 24 Jun 2004 00:58:42 +0100 (BST) (envelope-from roy+dated+1090627122.c8a94b@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5NNwg7T067946 for ietf-mxcomp@imc.org; Thu, 24 Jun 2004 00:58:42 +0100 (BST) (envelope-from roy+dated+1090627122.c8a94b@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Thu, 24 Jun 2004 00:58:41 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16602.6449.212333.862543@giles.gnomon.org.uk> Date: Thu, 24 Jun 2004 00:58:41 +0100 To: Douglas Otis Cc: Meng Weng Wong , "'IETF MARID WG'" Subject: Re: using reputation lookups first In-Reply-To: <1088031424.23891.85.camel@ddev.mail-abuse.org> References: <40D9C1DA.9090103@ehsco.com> <20040623210515.GF13225@dumbo.pobox.com> <1088031424.23891.85.camel@ddev.mail-abuse.org> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Given the momentum behind SPF, and the desire of Microsoft to do something similar with Caller ID, I think that something very similar in spirit to draft-ietf-marid-core is going to be defined and implemented anyway one way or another, whether blessed by the IETF standards track or not. I think it would be beneficial for this effort to happen within the IETF rather than without. CSV/CSA takes a very different approach, and is also of benefit. Whilst it would be possible to validate the HELO identity using an SPF or XML syntax, the requirements of CSV's problem space make that overkill. The two approaches seem complementary to me; is there any reason why this WG can't advance both to PS? The charter does says: This working group will develop *a* DNS-based mechanism for storing and distributing information associated with that authorization. [emphasis mine] Does this have to be interpreted strictly, or is it possible for the WG to develop *two* DNS-based mechanisms, without being required to conflate them into a single mechanism, if (as I believe it might be) it's technically beneficial to specify them independently, and not try to unify them in any way? -roy From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 20:44:03 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01915 for ; Wed, 23 Jun 2004 20:44:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5O0Yecv020632; Wed, 23 Jun 2004 17:34:40 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5O0YeQ8020631; Wed, 23 Jun 2004 17:34:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from polis.nbtsc.org (polis.nbtsc.org [206.168.119.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5O0YedC020615 for ; Wed, 23 Jun 2004 17:34:40 -0700 (PDT) (envelope-from aredridel@nbtsc.org) Received: from mizar.nbtsc.org ([206.168.67.102]) by polis.nbtsc.org with asmtp (Exim 4.34) id 1BdICR-0006oQ-7z for ietf-mxcomp@imc.org; Wed, 23 Jun 2004 18:34:43 -0600 Subject: Re: Could binary encoding really be the answer? From: Aredridel To: ietf-mxcomp@imc.org In-Reply-To: <27544286.1088009248@Ryoga.corp.sgi.com> References: <13664248.1087995368@Ryoga.corp.sgi.com> <27544286.1088009248@Ryoga.corp.sgi.com> Content-Type: text/plain Date: Wed, 23 Jun 2004 18:35:37 -0600 Message-Id: <1088037337.7206.3.camel@mizar.nbtsc.org> Mime-Version: 1.0 X-Mailer: Evolution 1.5.9.2 Content-Transfer-Encoding: 7bit X-Scan-Signature: ce010cd34cbf3ed31ac774f917887b17 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > I am sending my third and final message of the day, in order to express > support for Hadmut's suggestion of a binary encoding. I think this is a > good idea, and I believe it combines the best of various worlds > (extensibility, economy, etc). Quick sanity check: Any preliminary measures on the savings in such a format? I did a couple checks, but because we're dealing with basically textual information (domain labels) and such small packets, not much is saved in encoding the non-domain-label information more tightly, and gzip is ineffective on such small blocks. Even the XML overhead didn't affect it much. Ari From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 20:47:50 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02107 for ; Wed, 23 Jun 2004 20:47:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5O0ZwRq020864; Wed, 23 Jun 2004 17:35:58 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5O0ZwZh020863; Wed, 23 Jun 2004 17:35:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from aismtp2g.bellsouth.com (aismtp2g.bellsouth.com [139.76.165.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5O0Zvh7020822 for ; Wed, 23 Jun 2004 17:35:58 -0700 (PDT) (envelope-from Damon.Sauer@BellSouth.com) Received: from 01al10015010113.ad.bls.com ([90.152.52.35] [90.152.52.35]) by aismtp2g.bellsouth.com with ESMTP; Wed, 23 Jun 2004 20:35:57 -0400 Content-Class: urn:content-classes:message Subject: RE: Could binary encoding really be the answer? MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Wed, 23 Jun 2004 19:35:51 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-Id: <38363D9940D92A458010AAE24D162EB9B7D2EF@bremocog-55> Importance: normal Thread-Topic: Could binary encoding really be the answer? Thread-Index: AcRZfJzOTGG9HmBMSKqUHbMApySXcQABAeWw From: "Sauer, Damon" To: "IETF MARID WG" , "Greg Connor" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5O0Zwh7020858 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Greg, I have been sending Hadmut a few ideas along these lines. I am not sure how he feels about them though. Basically it would work like this: The original record would have two parts. A pointer to a MARID record and the "Human Readable" version of the SPF or XML record. The MARID record would have the binary SPF/XML data. But wait... there is more... I actually envisioned putting caching DNS on all the MTA's and putting a Huffman Compressed version of the "Human Readable" SPF/XML on the MARID record. When the MTA looked up the MARID record, it would decompress the Huffman code and store it in plain text in the local cached DNS. This way perl parsers, XML readers, Java snippets would be able to use the locally cached DNS file in plain text. The only time the Huffman decompression would have to be used is when the record cache expired or a new domain was looked up. The reasoning behind using the Huffman compression is that it is simple, available for every operating system, speedily decompressed, easily parsed, and very large records can still be sent using UDP. (Not breaking DNS) The "Human Readable" record stored in the non-MARID DNS record is not used in the actual mail delivery but should be required to be there. It doesn't really matter if it is correct or not because the local MTA's DNS would have a "Human Readable" record in its cache anyway. I suppose if you really wanted to be paranoid you could write a milter that compared the two "Human Readable" records after the fact. Or you could go as far as including the HASH of the "Human Readable" version of the Huffman compressed record included in the pointer so that the MTA could check the HASH against the decoded versions hash. The only issue that I see with this is A) Requiring some sort of DNS on all the MTA's and B) Decompressing the Huffman compressed data in stream. Anyway... just an idea. Regards, Damon Sauer -----Original Message----- From: owner-ietf-mxcomp@mail.imc.org [mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Greg Connor Sent: Wednesday, June 23, 2004 7:47 PM To: IETF MARID WG Subject: Could binary encoding really be the answer? Team- I am sending my third and final message of the day, in order to express support for Hadmut's suggestion of a binary encoding. I think this is a good idea, and I believe it combines the best of various worlds (extensibility, economy, etc). Here are some highlights. 1. Records can be composed in SPF, XML, or with a wizard. Whatever the input, the DNS format transmitted over the wire is a binary encoding. MTAs need to understand the binary and that's it. 2. DNS servers are not required to read other format, but they can. If they do, you can enter either SPF or XML text in the zone file. DNS tools like dig can display one or both formats. 3. The new binary format applies to the new MARID RR. I would probably want to keep using SPF format in the TXT records in the short term, because I'm not entirely sure of my ability to type binary data into a zone file. TXT records in SPF format are referred to as "legacy format" records. Use of TXT records may be deprecated at some future time when the new RR is widely available. I think this allows for extensibility and reuse of other standards, like the XML team wants, and it also allows for byte economy like the DNS core folks want, and MTA independence that the MTA writers want. I am not sure how Microsoft is going to like this proposal... on the one hand we are approving XML for use in composing the records, which is good, but on the other hand we are defining a new RR and MS needs to fix their servers to understand the new RR. This can take however long it's going to take, and the TXT record is available now, but not in XML. The way I see it, it will be tough for MS to have it both ways: they are probably not going to win approval for a new data format (MARID XML) AND also avoid the work of deploying a new RR. Feedback? Comments? Flames? Hadmut's previous message any my previous reply follows here (in case you were ignoring the other thread :) --Greg Connor wrote: > > --Hadmut Danisch wrote: > >> After spending a few more minutes to thing about it, I'd currently >> propose this (which, I admit, would also require the gods of DNS to >> move a little bit forward to accept it): >> > ... >> An MTA would receive the record as it is, as a bit/byte sequence. >> DNS does not care about it's structure. The MTA then simply passes >> this record to the MARID interpreter, together with other parameters >> (peer IP address, sender address,...). The MARID interpreter then >> disassembles the ASN.1 encoding. >> >> This way anything is completely covered in the MARID interpreter. >> All DNS parts don't depend on any detail. > > > I would agree with this. I like the idea of being able to go forward > without waiting for DNS upgrades. > > Given a choice I would probably lean toward the TXT record being one of > the human-readable representations, and the new RR being the "binary" > form, but I don't have a strong feeling and I'm willing to be talked out > of it :) > > Question for the DNS/bind gurus out there. Is it possible to put stuff > in your zone file using TYPE1234 notation, even if the bind version > doesn't support it? We would probably want to go with TXT at first but > when we have an RR type it would nice to start using it... I'm not sure > if this is possible. > > >> Now give it eye sugar: >> >> Allow the DNS encoder (i.e. bind reading the zone file) to not only >> understand base64 text representations, but also other >> representations, like SPF, XML, or whatever future might bring. >> >> In the same library, allow MARID records to be converted into >> any of a list of representations: base64, SPF, XML. >> >> This way, it will *always* work with base64. That's the fallback >> solutions. If you can't upgrade your DNS software, it will always work. > > > Good. Also, when we get around to publishing a new RR and rolling > support for it into various DNS servers, we can make a recommendation for > other "additional" records that can be stuffed in the response packet. > For example, if the a: mx: or include: mechanisms are used, the > additional section could include the A, MX, or other MARID record in the > first reply packet. This is of course optional for the DNS server, but > as long as we are working on a new RR in DNS we might as well make > recommendations on additional records too. > > >> If you extend the MARID records, it depends on wether the extension >> is marked critical or not (see my former posting). Non-critical >> extensions allow slow upgrades. Or even no upgrades. >> >> And then you have time to extend SPF or XML syntax and upgrade >> the conversion library. Until then, base64 always works. Just hack >> a perl script to encode new record types. > > > Good stuff. Thanks. > > > -- > Greg Connor -- Greg Connor ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 113 From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 21:01:28 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02678 for ; Wed, 23 Jun 2004 21:01:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5O0o7C5023686; Wed, 23 Jun 2004 17:50:07 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5O0o7EE023685; Wed, 23 Jun 2004 17:50:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5O0o6FZ023664 for ; Wed, 23 Jun 2004 17:50:06 -0700 (PDT) (envelope-from rbarclay@comcast.net) Received: from [127.0.0.1] (unknown[67.176.72.175]) by comcast.net (sccrmhc12) with ESMTP id <20040624005006012008aufle> (Authid: rbarclay); Thu, 24 Jun 2004 00:50:06 +0000 Message-ID: <40DA25C7.2080802@comcast.net> Date: Wed, 23 Jun 2004 18:52:23 -0600 From: Robert Barclay User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Greg Connor , IETF MARID WG Subject: Re: Could binary encoding really be the answer? References: <13664248.1087995368@Ryoga.corp.sgi.com> <27544286.1088009248@Ryoga.corp.sgi.com> In-Reply-To: <27544286.1088009248@Ryoga.corp.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Greg, I agree that this sounds like a workable plan. This along an extremely similar line of thinking as what led me to my compromise proposal sent this morning. You have however expressed many of the points much more clearly. I have a few comments below where I believe a slightly different path is at least worthy of discussion. Greg Connor wrote: > > Team- > > I am sending my third and final message of the day, in order to express > support for Hadmut's suggestion of a binary encoding. I think this is a > good idea, and I believe it combines the best of various worlds > (extensibility, economy, etc). > > Here are some highlights. > > 1. Records can be composed in SPF, XML, or with a wizard. Whatever the > input, the DNS format transmitted over the wire is a binary encoding. > MTAs need to understand the binary and that's it. Works for me. But since even in the current XML most records are still smaller than 512 bytes it would probably be worthwhile to explore exactly how much network traffic this really saves if for no other reason than to enhance the sales pitch to DNS admins who now have to create these records. > 2. DNS servers are not required to read other format, but they can. If > they do, you can enter either SPF or XML text in the zone file. DNS > tools like dig can display one or both formats. Is this implying that DNS servers should store both formats and selectively translate them to their binary representation or that if the DNS server is doing the translation it is up to tools like dig and nslookup to do the translation back to human readable? > 3. The new binary format applies to the new MARID RR. I would probably > want to keep using SPF format in the TXT records in the short term, > because I'm not entirely sure of my ability to type binary data into a > zone file. TXT records in SPF format are referred to as "legacy format" > records. Use of TXT records may be deprecated at some future time when > the new RR is widely available. I would suggest that since in your proposal TXT is used as transitional, and in mine the TXT is used for experimental new extensions that it would not be unreasonable for that record to support both formats, especially since as soon as their MTA and DNS software support it a system can use the standardized, binary formatted MARID record directly. > I think this allows for extensibility and reuse of other standards, like > the XML team wants, and it also allows for byte economy like the DNS > core folks want, and MTA independence that the MTA writers want. > > > I am not sure how Microsoft is going to like this proposal... on the one > hand we are approving XML for use in composing the records, which is > good, but on the other hand we are defining a new RR and MS needs to fix > their servers to understand the new RR. This can take however long it's > going to take, and the TXT record is available now, but not in XML. > > The way I see it, it will be tough for MS to have it both ways: they are > probably not going to win approval for a new data format (MARID XML) AND > also avoid the work of deploying a new RR. > > Feedback? Comments? Flames? I think the success of this group in creating a standard will depend on all of the various stakeholders being willing to compromise and do a little more work than they might strictly like to. The above approach seems reasonable to me. This is just my two cents. Thanks for the clear write up. To the group in general I will say that while I was a bit disheartened over the last few days over the heated and sometimes circular discussions, the willingness to compromise which I have seen today has done a great deal to raise my hopes again. Thanks, Robert > > Hadmut's previous message any my previous reply follows here (in case > you were ignoring the other thread :) > > > --Greg Connor wrote: > >> >> --Hadmut Danisch wrote: >> >>> After spending a few more minutes to thing about it, I'd currently >>> propose this (which, I admit, would also require the gods of DNS to >>> move a little bit forward to accept it): >>> >> ... >> >>> An MTA would receive the record as it is, as a bit/byte sequence. >>> DNS does not care about it's structure. The MTA then simply passes >>> this record to the MARID interpreter, together with other parameters >>> (peer IP address, sender address,...). The MARID interpreter then >>> disassembles the ASN.1 encoding. >>> >>> This way anything is completely covered in the MARID interpreter. >>> All DNS parts don't depend on any detail. >> >> >> >> I would agree with this. I like the idea of being able to go forward >> without waiting for DNS upgrades. >> >> Given a choice I would probably lean toward the TXT record being one of >> the human-readable representations, and the new RR being the "binary" >> form, but I don't have a strong feeling and I'm willing to be talked out >> of it :) >> >> Question for the DNS/bind gurus out there. Is it possible to put stuff >> in your zone file using TYPE1234 notation, even if the bind version >> doesn't support it? We would probably want to go with TXT at first but >> when we have an RR type it would nice to start using it... I'm not sure >> if this is possible. >> >> >>> Now give it eye sugar: >>> >>> Allow the DNS encoder (i.e. bind reading the zone file) to not only >>> understand base64 text representations, but also other >>> representations, like SPF, XML, or whatever future might bring. >>> >>> In the same library, allow MARID records to be converted into >>> any of a list of representations: base64, SPF, XML. >>> >>> This way, it will *always* work with base64. That's the fallback >>> solutions. If you can't upgrade your DNS software, it will always work. >> >> >> >> Good. Also, when we get around to publishing a new RR and rolling >> support for it into various DNS servers, we can make a recommendation for >> other "additional" records that can be stuffed in the response packet. >> For example, if the a: mx: or include: mechanisms are used, the >> additional section could include the A, MX, or other MARID record in the >> first reply packet. This is of course optional for the DNS server, but >> as long as we are working on a new RR in DNS we might as well make >> recommendations on additional records too. >> >> >>> If you extend the MARID records, it depends on wether the extension >>> is marked critical or not (see my former posting). Non-critical >>> extensions allow slow upgrades. Or even no upgrades. >>> >>> And then you have time to extend SPF or XML syntax and upgrade >>> the conversion library. Until then, base64 always works. Just hack >>> a perl script to encode new record types. >> >> >> >> Good stuff. Thanks. >> >> >> -- >> Greg Connor > > > > > -- > Greg Connor > > From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 21:19:26 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03848 for ; Wed, 23 Jun 2004 21:19:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5O19iCP027609; Wed, 23 Jun 2004 18:09:44 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5O19iHd027608; Wed, 23 Jun 2004 18:09:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tom.iecc.com (tom.iecc.com [208.31.42.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5O19h5s027602 for ; Wed, 23 Jun 2004 18:09:44 -0700 (PDT) (envelope-from johnl@iecc.com) Received: (qmail 20143 invoked from network); 24 Jun 2004 01:09:49 -0000 Received: (ofmipd 127.0.0.1); 24 Jun 2004 01:09:27 -0000 Date: 23 Jun 2004 21:09:49 -0400 Message-ID: From: "John R Levine" To: "william(at)elan.net" Cc: "ietf-mxcomp@imc.org" , "ehall@ehsco.com" Subject: Re: out of line XML, was Why not XML In-Reply-To: References: Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > The obvious problem is that there's no way to tell if the in-line data > > is real without making another transaction back to the sender's domain > > to check. If we have to use a separate TCP session to fetch a > > possible cachable chunk of XML, the right way to do that is with http > > and just fetch the policy document. It's defined, it's standard, it's > > debugged, it's available, and it works. > > I agree with you in general (and with Hadmut), but would point out that > http is also primarily one-key lookup protocol (which has been extended a > lot by means of cgi parameters) and retreiving entire policy document is > not the best idea if we're talking about it being so large that its > better off at the http server. You can encode any query you want into a URL. I don't see that as a problem. You want to work in the mailbox, time of day, number of messages, phase of moon, just define some conventions to map the parameters you want into the URL. > The best (in my opionion) is to actually work on specifications on new > policy document such that it can be deployed over existing pre-built > protocol. I entirely agree. That's why I keep saying http. Do experiments with http, then if we find that we're looking up lots of tiny documents, and they'd fit into single packets, and the lookup is a bottleneck, then it'd makes sense to consider some lighter weight protocol. Until then, I don't see any point in defining a policy protocol until we have some experience defining and using policy documents. At this point we don't even know who'll be publishing them and how a mail recipient will decide who to ask. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor "I dropped the toothpaste", said Tom, crestfallenly. From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 21:45:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05337 for ; Wed, 23 Jun 2004 21:45:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5O1awXJ033021; Wed, 23 Jun 2004 18:36:58 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5O1awso033020; Wed, 23 Jun 2004 18:36:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.mail-abuse.org [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5O1awZe033012 for ; Wed, 23 Jun 2004 18:36:58 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.mail-abuse.org (DDev.mail-abuse.org [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id BBBBB414AF; Wed, 23 Jun 2004 18:37:04 -0700 (PDT) Subject: Re: Could binary encoding really be the answer? From: Douglas Otis To: Greg Connor Cc: IETF MARID WG In-Reply-To: <27544286.1088009248@Ryoga.corp.sgi.com> References: <13664248.1087995368@Ryoga.corp.sgi.com> <27544286.1088009248@Ryoga.corp.sgi.com> Content-Type: text/plain Message-Id: <1088041024.23891.158.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 23 Jun 2004 18:37:04 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-06-23 at 16:47, Greg Connor wrote: > Team- > > I am sending my third and final message of the day, in order to express > support for Hadmut's suggestion of a binary encoding. I think this is a > good idea, and I believe it combines the best of various worlds > (extensibility, economy, etc). Perhaps rather than just a single new record type, consider defining a structure composed of new elements where each element is a record type. 1) An address type for CIDR notation for IPv4 and IPv6 addresses. 2) Inverse of the SRV record having a 16 bit field for encoding the protocol being authorized and a name type used to return referenced CIDR notation. Add to this a 16 bit field to declare policy information. Allow the protocol field to be used as a selection field. (Redefine Class perhaps.) 3) A type of PTR record to build external reference lists with a matching protocol field to the inverse SRV record also for selection. This would allow these new records to find greater use than just for MARID. -Doug From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 22:26:30 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08876 for ; Wed, 23 Jun 2004 22:26:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5O2GHt3040227; Wed, 23 Jun 2004 19:16:17 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5O2GHcm040226; Wed, 23 Jun 2004 19:16:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5O2GGWU040219 for ; Wed, 23 Jun 2004 19:16:16 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i5O2GehX015529 for ; Wed, 23 Jun 2004 19:16:40 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i5O2Ge79015526 for ; Wed, 23 Jun 2004 19:16:40 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Wed, 23 Jun 2004 19:16:40 -0700 (PDT) From: "william(at)elan.net" To: IETF MARID WG Subject: Re: Could binary encoding really be the answer? In-Reply-To: <1088041024.23891.158.camel@ddev.mail-abuse.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 23 Jun 2004, Douglas Otis wrote: > 3) A type of PTR record to build external reference lists with a > matching protocol field to the inverse SRV record also for selection. Maybe we should consider just reusing existing PTR record since it has no defined meaning and use for domains (only meaning is for IN-ADDR tree)? And if we need something more advanced, I already wrote how NAPTR records may possibly be used for similar purposes and they are kind of like more enhanced and universal PTR. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Wed Jun 23 23:41:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13728 for ; Wed, 23 Jun 2004 23:41:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5O3WFrF055342; Wed, 23 Jun 2004 20:32:15 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5O3WFi1055341; Wed, 23 Jun 2004 20:32:15 -0700 (PDT) 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.9) with ESMTP id i5O3WEEE055335 for ; Wed, 23 Jun 2004 20:32:14 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i5O3WK6J013597; Wed, 23 Jun 2004 20:32:21 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 23 Jun 2004 20:32:20 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Hector Santos'" , "Hallam-Baker, Phillip" , ietf-mxcomp@imc.org Cc: jrk@merseymail.com Subject: RE: Why not XML Date: Wed, 23 Jun 2004 20:32:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > But as the CodeRed Principle as shown, there will always be > enough of a legacy market to still be effective. Yes, but the point I am making is that when you compare the vulnerabily of deployed, tested code (most XML parsers) vs a new syntax that is less than a year old you cannot fairly make the claim that the new code is likely to be safer. SPF is already a very complex syntax requiring about the same number of state transitions as syntactic parsing of the XML format. > Over the years, can you vouch for Microsoft having a solid > engineering team with enough foresight? Over the years Bill has hired rather a lot of good people, do not blame the current employees of the company for the consequences of a twenty year old code base and supporting every device ever built by any manufacturer. > Anyway, can you vouch that some undocumented enbedded XML > attribute that > does some undocumented logic doing the object instantiation > and parsing is not going to be there? Actually yes I can for the interfaces I use. > > And in any case, if you are still using a language that is > vulnerable to > > buffer overflow issues you are a decade out of date. > > Phillip good point, but it might not be the language but the > API or the > library you are using!. In this case, the XML API > components/library or > sub-system! Then code the stuff yourself. The amount of effort that has gone into this thread could have generated six XML parsers. I would have written one myself and posted it to the list if I had not been submerged with phishing attacks. > > #define strncpy() exit(-1) > > Remember, there is no such thing as a bad language, just bad > programmers. No, there are bad languages. Pascal is Wirthless as one Turing award winner once commented. The lack of bounds checking in C was negligent even at the time. There are no buffer overrun problems in any other commonly used language - except through calls to C substrates. From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 00:00:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14745 for ; Wed, 23 Jun 2004 23:59:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5O3nwhO059850; Wed, 23 Jun 2004 20:49:58 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5O3nw3h059849; Wed, 23 Jun 2004 20:49:58 -0700 (PDT) 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.9) with ESMTP id i5O3nv9q059835 for ; Wed, 23 Jun 2004 20:49:58 -0700 (PDT) (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 AB4B3133559; Wed, 23 Jun 2004 23:50:01 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 63D4C6E1; Wed, 23 Jun 2004 23:50:01 -0400 (EDT) Date: Wed, 23 Jun 2004 23:50:01 -0400 From: Meng Weng Wong To: Roy Badami Cc: "'IETF MARID WG'" Subject: Unified SPF Message-ID: <20040624035001.GG13225@dumbo.pobox.com> References: <40D9C1DA.9090103@ehsco.com> <20040623210515.GF13225@dumbo.pobox.com> <1088031424.23891.85.camel@ddev.mail-abuse.org> <16602.6449.212333.862543@giles.gnomon.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16602.6449.212333.862543@giles.gnomon.org.uk> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Jun 24, 2004 at 12:58:41AM +0100, Roy Badami wrote: | | CSV/CSA takes a very different approach, and is also of benefit. | Whilst it would be possible to validate the HELO identity using an SPF | or XML syntax, the requirements of CSV's problem space make that | overkill. "Overkill" is relative --- if the evalute_spf function is already available, might as well apply it to the HELO name and get back something useful. I have been calling this approach "Unified SPF" --- it embraces the CSV and the MTAMark/SS semantics using the SPF syntax and lookup, just as SPF has embraced the CallerID semantics with SenderID. People have been mentioning Unified SPF on-list a little bit lately but I thought I should probably put it forward officially and see what people think. | The two approaches seem complementary to me; is there any reason why | this WG can't advance both to PS? I explain in more detail at http://spf.pobox.com/slides/unified%20spf/ Comments are welcome. meng From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 01:11:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18526 for ; Thu, 24 Jun 2004 01:11:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5O52ItH074813; Wed, 23 Jun 2004 22:02:18 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5O52I8s074812; Wed, 23 Jun 2004 22:02:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5O52HIa074805 for ; Wed, 23 Jun 2004 22:02:18 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from [192.168.2.24] (adsl-64-142-13-68.sonic.net [64.142.13.68]) by b.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i5O52Okt029685; Wed, 23 Jun 2004 22:02:24 -0700 Subject: Re: Could binary encoding really be the answer? From: Douglas Otis To: "william(at)elan.net" Cc: IETF MARID WG In-Reply-To: References: Content-Type: text/plain Message-Id: <1088053344.2699.9.camel@bash.adsl-64-142-13-68.sonic.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 23 Jun 2004 22:02:24 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-06-23 at 19:16, william(at)elan.net wrote: > On Wed, 23 Jun 2004, Douglas Otis wrote: > > > 3) A type of PTR record to build external reference lists with a > > matching protocol field to the inverse SRV record also for selection. > > Maybe we should consider just reusing existing PTR record since it has > no defined meaning and use for domains (only meaning is for IN-ADDR tree)? > > And if we need something more advanced, I already wrote how NAPTR records > may possibly be used for similar purposes and they are kind of like more > enhanced and universal PTR. I was adding this to employ an additional select mechanism to allow a common record type to be used by more than one protocol while avoiding the problem of special labels as related to wild cards. If such a select field could be added to the inverse SRV record, then having the same mechanism would be helpful for a PTR type of record. It may even be helpful to add a new SRV record with this feature for the same reasons. Okay, this makes 5 new record types. -Doug From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 01:41:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20142 for ; Thu, 24 Jun 2004 01:41:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5O5S5bI087698; Wed, 23 Jun 2004 22:28:05 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5O5S5iJ087697; Wed, 23 Jun 2004 22:28:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5O5S5Y3087689 for ; Wed, 23 Jun 2004 22:28:05 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from [192.168.2.24] (adsl-64-142-13-68.sonic.net [64.142.13.68]) by b.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i5O5S5Ts001380; Wed, 23 Jun 2004 22:28:06 -0700 Subject: Re: Unified SPF From: Douglas Otis To: Meng Weng Wong Cc: Roy Badami , "'IETF MARID WG'" In-Reply-To: <20040624035001.GG13225@dumbo.pobox.com> References: <40D9C1DA.9090103@ehsco.com> <20040623210515.GF13225@dumbo.pobox.com> <1088031424.23891.85.camel@ddev.mail-abuse.org> <16602.6449.212333.862543@giles.gnomon.org.uk> <20040624035001.GG13225@dumbo.pobox.com> Content-Type: text/plain Message-Id: <1088054885.2699.34.camel@bash.adsl-64-142-13-68.sonic.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 23 Jun 2004 22:28:05 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-06-23 at 20:50, Meng Weng Wong wrote: > On Thu, Jun 24, 2004 at 12:58:41AM +0100, Roy Badami wrote: > | > | CSV/CSA takes a very different approach, and is also of benefit. > | Whilst it would be possible to validate the HELO identity using an SPF > | or XML syntax, the requirements of CSV's problem space make that > | overkill. > > "Overkill" is relative --- if the evalute_spf function is > already available, might as well apply it to the HELO name > and get back something useful. > > I have been calling this approach "Unified SPF" --- it > embraces the CSV and the MTAMark/SS semantics using the SPF > syntax and lookup, just as SPF has embraced the CallerID > semantics with SenderID. > > People have been mentioning Unified SPF on-list a little bit > lately but I thought I should probably put it forward > officially and see what people think. > > | The two approaches seem complementary to me; is there any reason why > | this WG can't advance both to PS? > > I explain in more detail at > http://spf.pobox.com/slides/unified%20spf/ > > Comments are welcome. Complexities of the SPF/CID records cause potential exposures needing to be mitigated. If the address is immediately expressed to match against the EHLO domain, this risk can be circumvented if mandated as an absolute requirement. Alternatively, adding an SRV record provides this function without a need to parse textual information and correlates with SMTP host names rather than mail domains. If only employing the EHLO check, the SRV record would be simpler to implement and requires fewer changes to the SMTP server. -Doug From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 03:54:28 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12232 for ; Thu, 24 Jun 2004 03:54:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5O7diUp057912; Thu, 24 Jun 2004 00:39:44 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5O7di9D057911; Thu, 24 Jun 2004 00:39:44 -0700 (PDT) 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.9) with ESMTP id i5O7dhTo057898 for ; Thu, 24 Jun 2004 00:39:43 -0700 (PDT) (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.34) id 1BdOpU-0008QU-O9 for ietf-mxcomp@imc.org; Thu, 24 Jun 2004 02:39:43 -0500 To: "IETF MARID WG" References: From: wayne Reply-To: "IETF MARID WG" Date: Thu, 24 Jun 2004 02:39:28 -0500 In-Reply-To: (wayne@midwestcs.com's message of "Fri, 21 May 2004 16:11:32 -0700") 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 (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: Some stats on TXT usage in domain names (updated) Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-4.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: About a month ago, I posted some stats on the usage of TXT records. Here are some updates There was a net increase of 2040 domains with SPF records, a 32.3% increase in the last month. SPF records are now the most common type of TXT record usage, surpassing the "unix epoch timestamp" that is found in many zones. The SPF adoption roll, despite being down much of this month, had a net increase of 4776 records, a 33.7% increase. (The adoption roll, like most SPF related things, is run by a volunteer.) For Caller-ID records, the was a net increase of 5 records, a 6% increase. 1289260 total domain names (same as last time) 35115 total TXT records found (some domains have more than one) 8360 have SPF records -> 23.8% of all domain level TXT records are spf records. 26359 domains have txt records 6315 domains have spf records 18968 spf_domains adoption roll 87 have Caller-ID records Last months stats as a reference: In wayne writes: > 1289260 total domain names > 33016 total TXT records found (some domains have more than one) > 6320 have SPF records -> 19.1% of all domain level TXT records are > spf records > > 26359 domains have txt records > 6315 domains have spf records > > 1456 domains found that were also in the adopt roll -> 23.0% > > 14192 spf_domains adoption roll > > 61554 estimated domains have SPF records. (This probably misses > most parked domains, of which I have heard rumors that there > are a least a couple hundred thousand with SPF records. > > 82 have Caller-ID records > 57 have both Caller-ID records and SPF records > 45 have "testing=true" in the C-ID records. > 25 have C-ID records only, of which three (10%) are microsoft.com, > exchange.microsoft.com and hotmail.com > From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 06:59:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24928 for ; Thu, 24 Jun 2004 06:59:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OAllVS038095; Thu, 24 Jun 2004 03:47:47 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OAllBM038094; Thu, 24 Jun 2004 03:47:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.michaelbrumm.com (h-68-167-225-114.phndaz91.covad.net [68.167.225.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OAlX3X038073 for ; Thu, 24 Jun 2004 03:47:45 -0700 (PDT) (envelope-from me@michaelbrumm.com) Received: from devon ([68.167.225.115]) by mail.michaelbrumm.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Jun 2004 10:47:31 +0000 From: "Michael R. Brumm" To: "IETF MARID WG" Subject: TXT now, new RR later (was Re: Why not XML) Date: Thu, 24 Jun 2004 04:47:41 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <40D9A92F.8050707@danisch.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-OriginalArrivalTime: 24 Jun 2004 10:47:31.0624 (UTC) FILETIME=[A69B9A80:01C459D8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5OAlk3X038089 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Michael R. Brumm wrote: >Obviously, the best technical solution would be a binary >representation in a newly allocated RR type. However, this is not a >practical solution for at least two more years. It really is too bad >that RFC 3597 did not come out much earlier. Hadmut Danisch wrote: >Thank you very much for confirming this as the best technical solution. >This is exactly where all this discussion started, this is what RMX is. >RMX was and is a binary representation in a newly allocated RR type. You are welcome. Now, if only we can concur on the fact that the best technical solution is not viable for several years because most DNS libraries, clients, sanitizers (firewalls, etc), and servers do not support unknown RR types. SMTP authorization cannot wait for RFC 3597 to be widely deployed. People will not wait this long. Spam is an ever increasing burden on everyone from the postmaster down to the end-user. I'm sure I don't even have to mention this. Hadmut Danisch wrote: >For the purpose of discussion, let's assume that your estimation about >two years is correct: RMX is almost two years old by now. SPF is a >little bit more than one year old. The SPF circus caused a severe >delay in the evolution of such a mechanism, a delay of about a year >right now. SPF was the idea to use plaintext in TXT records. The "SPF circus" hasn't delayed the adoption of RFC 3597, and RMX has not significantly increased the adoption rate of RFC 3597. In any case, the date of RFC 3597 is "September 2003", which is less than 10 months ago. I don't see how we can expect anything as incredibly large-scale as SMTP authorization to be built on something that is so young and not widely implemented. >And now you say that the best technical solution would be a binary >representation in a newly allocated RR type, as RMX proposed from >the very beginning, but we can't do this anymore because we now lack >that time we've lost through the SPF circus proposing a different way >that you now consider as worse? I don't see how we've lost any time to the "SPF circus". SPF and RMX haven't affected RFC 3597 deployment; it's been the other way around. SPF is being adopted and deployed precisely because it can be (right now) in TXT records, while RMX was hindered due to its RR type requirement. The fact that we have a working solution now (SPF syntax in TXT records) doesn't prevent us from transitioning to an RR type in the future. I could be wrong, but I think that most of the SPF community would expect that a new RR type would eventually be allocated, and that use of the TXT record would be depreciated. What we object to is the idea that a new RR type should be immediately required and the TXT record immediately abandoned. This would prevent further adoption, and disenfranchise the large base of early adopters. Michael R. Brumm From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 08:41:44 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06124 for ; Thu, 24 Jun 2004 08:41:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OCTQvp049049; Thu, 24 Jun 2004 05:29:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OCTQRt049048; Thu, 24 Jun 2004 05:29:26 -0700 (PDT) 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.9) with ESMTP id i5OCTQ1s049042 for ; Thu, 24 Jun 2004 05:29:26 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbfujip (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i5OCTPl07074; Thu, 24 Jun 2004 05:29:25 -0700 Date: Thu, 24 Jun 2004 19:00:45 +0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <539458638.20040624190045@brandenburg.com> To: Meng Weng Wong CC: "'IETF MARID WG'" Subject: what, precise, is SPF and what is not SPF? In-Reply-To: <20040624035001.GG13225@dumbo.pobox.com> References: <40D9C1DA.9090103@ehsco.com> <20040623210515.GF13225@dumbo.pobox.com> <1088031424.23891.85.camel@ddev.mail-abuse.org> <16602.6449.212333.862543@giles.gnomon.org.uk> <20040624035001.GG13225@dumbo.pobox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Meng (and everyone else), I'd like to ask that we step back and consider something rather basic. MWW> I have been calling this approach "Unified SPF" --- it MWW> embraces the CSV and the MTAMark/SS semantics using the SPF MWW> syntax and lookup, just as SPF has embraced the CallerID MWW> semantics with SenderID. When I first heard about SPF, I thought I knew what it was. Over time, I have become quite sure that I don't. The text of your note, "Unified SPF" eliminated any doubt that I might have had. A specification that increasingly is described as being able to do everything is one that always confuses the heck out of me. So I would find it extremely helpful to hear some precise descriptions of what this thing called SPF really is and what it really does. When we have a clear and consistent understanding of it, the community can reasonably assess what is reasonably appropriate to count within SPF and what should be counted as outside it. Knowing what is NOT in a mechanism is often more important than knowing what is IN it. For all discussions over recent months, it appears that every feature for spam and spoofing control can be incorporated in SPF. This should give us some pause. Offhand, I cannot think of a successful Internet protocol that has demonstrated this degree of flexibility. By way of pursuing this off of a previous, related thread: MWW> SPF is extensible. Multiple mechanisms can be defined. While other Extensibility is always appealing, but it also often is surprisingly risky, both in the near-term and the long-term. Referring to it can be a mantra for avoiding careful analysis in the near-term and for deferring considering of essential issues. Of course, in the long-term it can fail to support the promised enhancements, at the least resulting in massive opportunity costs. Here, it raises a rather basic question: What, exactly, is SPF? What mechanisms does it provide? What incremental value-add does it create? My reason for asking such a basic question is that I think it is important for the community to be clear about proposals, so they know what they are "buying". The alternative is that they will have unrealistic expectations and wind up at least disappointed, and possibly far worse. (The delays in issuing the recent version of our own CSV proposal was that we felt it essential to hold it to this strict standard of clarity. It turned out to be remarkably difficult to be sufficiently clear about describing the details of functionality, even amongst ourselves.) A number of different answers about SPF are possible. I suspect my own list of choices is woefully incomplete, but here goes: LABEL: SPF is a a suite of essentially independent tools, brought under a common label. Taking the example of the extension you suggest for DomainKeys, SPF does not "do" DomainKeys, Rather, it "refers" to it. What does it actually mean to say that SPF "supports" DomainKeys? At the least, this means that the cited mechanisms need to be evaluated independently, to consider their independent behaviors and merits. CAPABILITIES: SPF is a means of publishing email reception access control capabilities. Hence it permits sending SMTP clients to know what tests they will be subjected to and, by implication, what tests they need to facilitate, such as doing their own publishing of relevant information, marking of individual messages, etc. It is worth noting that the DNS is only one, useful means of getting information published on the net. In fact there are some IETF "capabilities" standards that support alternative means of permitting such publishing through different channels. POLICES: SPF is a means of publishing email reception access control capabilities, as well as detailing parameters for the behavior of the supported mechanisms. Given the current meaning of the "P" in SPF, this might seem the obvious choice, but public discussion usually describes SPF as "doing" the control mechanisms, rather than only "describing" them. PLATFORM: SPF is a means of performing a series of email reception access control tests. It provides an common, integrated platform for these test, leveraging common component mechanisms for efficiencies such as simpler software and easier administration. Including something like DomainKeys would suggest that that this choice does not apply, since DoimainKeys is an entirely independent mechanism. The reason this question is important was underscored at the SPF BOF at Inbox event: a room full of staunch supporters also thought the question important enough to discuss and participants gave significantly different answers. Even supporters are not very clear about the details of the job that SPF does. For a specification that has been around this long, that kind of uncertainty is worthy of note and repair. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 08:42:50 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06200 for ; Thu, 24 Jun 2004 08:42:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OCTQOH049040; Thu, 24 Jun 2004 05:29:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OCTQgC049039; Thu, 24 Jun 2004 05:29:26 -0700 (PDT) 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.9) with ESMTP id i5OCTQN0049033 for ; Thu, 24 Jun 2004 05:29:26 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbfujip (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i5OCTNl07069; Thu, 24 Jun 2004 05:29:23 -0700 Date: Thu, 24 Jun 2004 18:42:17 +0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1646321724.20040624184217@brandenburg.com> To: Matthew Elvey CC: MXCOMP Subject: Re: CSV, NBB In-Reply-To: <40D3B7D5.90803@elvey.com> References: <1665390638.20040614190711@brandenburg.com> <20040615031048.GP44160@verdi> <40CE9F08.2050002@elvey.com> <20040615115828.GQ44160@verdi> <1087328029.10303.198484820@webmail.messagingengine.com> <20040616164710.GG38007@verdi> <40D36596.6050907@elvey.com> <40D3B7D5.90803@elvey.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: Content-Transfer-Encoding: 7bit Matthew, ME> Have you considered and rejected or not considered adding the NBB idea ME> that I threw out a while back to the CSV spec? ... ME> Take CSV, and add a new requirement: mail that has failed (as in ME> there is a MARID record AND the sending IP isn't there AND there's no ME> ?all) a 2821.FROM check MUST NOT be bounced; CSV provides a system for obtaining information about a sending SMTP client. It makes no attempt to dictate how the receiving SMTP server should use that information. This is not an accident. For one thing, that would cross the line into a much fuzzier area, as some of the discussions about this already demonstrated. For another, my own experience is that specifications that are too broad get complicated, take a long time, and ultimately are not very useful. ME> instead it MUST either be ME> refused at SMTP time, or accepted and destroyed. In other words, DON'T ME> require SRS, but DO require that mail that goes via non-SRS systems not ME> lead to bounces to systems that didn't originate the original message. SRS? you mean re-writing stuff? I did not think that CSV said anything at all about address re-writing. At least, I sure hope we didn't... d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 09:21:30 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10293 for ; Thu, 24 Jun 2004 09:21:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ODDsx8052838; Thu, 24 Jun 2004 06:13:54 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5ODDsSW052837; Thu, 24 Jun 2004 06:13:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-9.csi.cam.ac.uk (ppsw-9.csi.cam.ac.uk [131.111.8.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ODDre3052831 for ; Thu, 24 Jun 2004 06:13:54 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:46771) by ppsw-9.csi.cam.ac.uk (old-ppsw.cam.ac.uk [131.111.8.3]:25) with esmtp (Exim 4.34) id 1BdU2z-0007ar-O6 for ietf-mxcomp@imc.org; Thu, 24 Jun 2004 14:13:45 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1BdU2y-0004ok-3H; Thu, 24 Jun 2004 14:13:44 +0100 Date: Thu, 24 Jun 2004 14:13:44 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Roy Badami cc: Harry Katz , Eric Allman , IETF MARID List , Meng Weng Wong Subject: Re: draft-ietf-marid-submitter-01.txt In-Reply-To: <16602.4663.751384.263061@giles.gnomon.org.uk> Message-ID: References: <16602.4663.751384.263061@giles.gnomon.org.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 24 Jun 2004, Roy Badami wrote: > > Would it be worth adding something along the lines of the following to > the end of 4.2? I assume you meant 4.1 here. > Any MTA not supporting the Responsible Submitter extension that > redirects a message from the address listed in the RFC 2821 RCPT TO > command is nonetheless encouraged to modify the message according > to (a) and (b) above. > > This is clearly what we want, and what we expect (prior to flag day). (b) conflicts with the semantics of the Resent- headers specified by RFC 2822. This should be made more clear. Should there be a requirement that SUBMIT servers verify that the SMTP AUTH information corresponds with the SUBMITTER information? Tony. -- f.a.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 6 TO GALE 8, OCCASIONALLY SEVERE GALE 9 AT FIRST, VEERING NORTHWEST 5 OR 6. RAIN. MODERATE OR POOR. From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 09:22:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10454 for ; Thu, 24 Jun 2004 09:22:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OD8S7p052404; Thu, 24 Jun 2004 06:08:28 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OD8Sqf052403; Thu, 24 Jun 2004 06:08:28 -0700 (PDT) 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.9) with ESMTP id i5OD8PMT052395 for ; Thu, 24 Jun 2004 06:08:26 -0700 (PDT) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id 61556E075C; Thu, 24 Jun 2004 09:07:42 -0400 (EDT) Date: Thu, 24 Jun 2004 09:07:42 -0400 From: John Leslie To: Meng Weng Wong Cc: Roy Badami , "'IETF MARID WG'" Subject: Re: Unified SPF Message-ID: <20040624130742.GC3747@verdi> References: <40D9C1DA.9090103@ehsco.com> <20040623210515.GF13225@dumbo.pobox.com> <1088031424.23891.85.camel@ddev.mail-abuse.org> <16602.6449.212333.862543@giles.gnomon.org.uk> <20040624035001.GG13225@dumbo.pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040624035001.GG13225@dumbo.pobox.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Meng Weng Wong wrote: > On Thu, Jun 24, 2004 at 12:58:41AM +0100, Roy Badami wrote: >| >| CSV/CSA takes a very different approach, and is also of benefit. >| Whilst it would be possible to validate the HELO identity using an SPF >| or XML syntax, the requirements of CSV's problem space make that >| overkill. > > "Overkill" is relative --- if the evalute_spf function is > already available, might as well apply it to the HELO name > and get back something useful. The problem with this approach is subtle. Indeed, for a receiving SMTP server which already incorporates SPF, the additional coding to call the subroutine one more time is trivial. But that has little to do with whether it's "overkill", and even less to do with whether it's the right tool for the job. Throughout the SPF design process, there has been a conscious choice to load processing tasks onto the receiving SMTP server in order to make the process of advertising SPF records as simple as possible. (This is based on a belief that it will be easier to convince a few dozen coders of MTA software than to convince millions of domain owners.) Missing from this analysis is the question of convincing hundreds of thousands of MTA managers to enable the SPF function (already programmed) on each MTA. Perhaps I'm more paranoid than I need to be about what the spammers will do. Or perhaps I'm not paranoid enough... But I definitely see spammers upping the ante: they have available millions of zombie computers on "fast" connections, and the managers of those "fast" connections seem determined to do nothing to stop this: merely to limit (some of) these computers to 500 emails per day. Thus, I believe we need a truly "lightweight" mechanism to separate whether we're dealing with an unauthorized zombie computer. SPF is simply _not_ lightweight enough. Please understand: for what it sets out to do, one could argue that SPF _is_ "lightweight". But it sets out to do so much that we cannot place upper bounds on the processing that might be required. If we reach a situation where turning on the SPF feature brings each MTA to its knees, the feature _will_ be turned off quickly. And the management of that MTA won't be inclined to turn it on again. And the word will get out. For our own interests, we want to guard against something like this. We want to protect ourselves from a ten-times increase in activity by zombie computers. For this we need a tool whose processing load is bounded. This is specifically what CSV was designed for. To tackle the RFC2822 header issues, we need the complexity of SPF; to screen out zombie computers, we don't. > I have been calling this approach "Unified SPF" --- it > embraces the CSV and the MTAMark/SS semantics using the SPF > syntax and lookup, just as SPF has embraced the CallerID > semantics with SenderID. There's another issue I suppose deserves mention yet again: that reaching consensus in the MARID WG is just one step towards an IETF standard. (I'll let others judge how close we are to consensus.) SPF is (IMHO) absolutely dependent on the use of TXT records in areas of the DNS tree where other TXT records are likely to be found. We _know_ we're going to face a lot of flak from DNS experts over this issue. This cannot fail (IMHO) to slow down the process of becoming an IETF standard. > People have been mentioning Unified SPF on-list a little bit > lately but I thought I should probably put it forward > officially and see what people think. I think, frankly, that SPF has to stop changing if there's ever to be any hope of progressing to an IETF standard. (It's possible, I suppose, for it to achieve "market-share" without settling down; but that's not what the MARID WG is for.) > | The two approaches seem complementary to me; is there any reason why > | this WG can't advance both to PS? > > I explain in more detail at > http://spf.pobox.com/slides/unified%20spf/ Here, Meng advises folks to not worry about the difference between HELO and RFC2822. Inevitably, that will lead to a large number of domains advertising relatively open SPF records, and those relatively open records being used to "authenticate" HELOs of MTAs which the actual domain never had the slightest intent of trying to control. And, since all of this is publicly available in DNS, spammers will quickly compile a list of these. But it gets worse: Meng actually advises bypassing further checks if the HELO passes SPF checking and the domain passes reputation checks. (Think about it, Meng: I'm sure you'll relent.) Whereas CSV is designed for exactly the purpose of authenticating and authorizing MTAs: there will be no confusion whether we're talking about taking responsibility for the actions of the MTA or trying to control the path which may be used to send email from the domain. Think it through, Meng: ease of advertising should never be sought at the expense of _accuracy_ of advertising. -- John Leslie From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 09:34:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11386 for ; Thu, 24 Jun 2004 09:34:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ODOa5w054180; Thu, 24 Jun 2004 06:24:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5ODOamZ054179; Thu, 24 Jun 2004 06:24:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from nickatestmch2 (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ODOYHh054166 for ; Thu, 24 Jun 2004 06:24:35 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: from mailgatejd ([10.130.130.110]) by nickatestmch2 with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Jun 2004 15:24:24 +0200 Content-Class: urn:content-classes:message Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 24 Jun 2004 15:23:25 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Jun 2004 15:24:27 +0200 Message-ID: Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 24 Jun 2004 15:18:19 +0200 X-Mailer: Microsoft CDO for Windows 2000 Content-Transfer-Encoding: 7bit Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OD8S7p052404; Thu, 24 Jun 2004 06:08:28 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OD8Sqf052403; Thu, 24 Jun 2004 06:08:28 -0700 (PDT) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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.9) with ESMTP id i5OD8PMT052395 for ; Thu, 24 Jun 2004 06:08:26 -0700 (PDT) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id 61556E075C; Thu, 24 Jun 2004 09:07:42 -0400 (EDT) Date: Thu, 24 Jun 2004 15:24:00 +0200 From: "John Leslie" To: , , Cc: "Roy Badami" , "'IETF MARID WG'" Subject: Re: Unified SPF References: <40D9C1DA.9090103@ehsco.com> <20040623210515.GF13225@dumbo.pobox.com> <1088031424.23891.85.camel@ddev.mail-abuse.org> <16602.6449.212333.862543@giles.gnomon.org.uk> <20040624035001.GG13225@dumbo.pobox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20040624035001.GG13225@dumbo.pobox.com> User-Agent: Mutt/1.4.1i List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 24 Jun 2004 13:18:20.0098 (UTC) FILETIME=[B7EB2A20:01C459ED] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Meng Weng Wong wrote: > On Thu, Jun 24, 2004 at 12:58:41AM +0100, Roy Badami wrote: >| >| CSV/CSA takes a very different approach, and is also of benefit. >| Whilst it would be possible to validate the HELO identity using an SPF >| or XML syntax, the requirements of CSV's problem space make that >| overkill. > > "Overkill" is relative --- if the evalute_spf function is > already available, might as well apply it to the HELO name > and get back something useful. The problem with this approach is subtle. Indeed, for a receiving SMTP server which already incorporates SPF, the additional coding to call the subroutine one more time is trivial. But that has little to do with whether it's "overkill", and even less to do with whether it's the right tool for the job. Throughout the SPF design process, there has been a conscious choice to load processing tasks onto the receiving SMTP server in order to make the process of advertising SPF records as simple as possible. (This is based on a belief that it will be easier to convince a few dozen coders of MTA software than to convince millions of domain owners.) Missing from this analysis is the question of convincing hundreds of thousands of MTA managers to enable the SPF function (already programmed) on each MTA. Perhaps I'm more paranoid than I need to be about what the spammers will do. Or perhaps I'm not paranoid enough... But I definitely see spammers upping the ante: they have available millions of zombie computers on "fast" connections, and the managers of those "fast" connections seem determined to do nothing to stop this: merely to limit (some of) these computers to 500 emails per day. Thus, I believe we need a truly "lightweight" mechanism to separate whether we're dealing with an unauthorized zombie computer. SPF is simply _not_ lightweight enough. Please understand: for what it sets out to do, one could argue that SPF _is_ "lightweight". But it sets out to do so much that we cannot place upper bounds on the processing that might be required. If we reach a situation where turning on the SPF feature brings each MTA to its knees, the feature _will_ be turned off quickly. And the management of that MTA won't be inclined to turn it on again. And the word will get out. For our own interests, we want to guard against something like this. We want to protect ourselves from a ten-times increase in activity by zombie computers. For this we need a tool whose processing load is bounded. This is specifically what CSV was designed for. To tackle the RFC2822 header issues, we need the complexity of SPF; to screen out zombie computers, we don't. > I have been calling this approach "Unified SPF" --- it > embraces the CSV and the MTAMark/SS semantics using the SPF > syntax and lookup, just as SPF has embraced the CallerID > semantics with SenderID. There's another issue I suppose deserves mention yet again: that reaching consensus in the MARID WG is just one step towards an IETF standard. (I'll let others judge how close we are to consensus.) SPF is (IMHO) absolutely dependent on the use of TXT records in areas of the DNS tree where other TXT records are likely to be found. We _know_ we're going to face a lot of flak from DNS experts over this issue. This cannot fail (IMHO) to slow down the process of becoming an IETF standard. > People have been mentioning Unified SPF on-list a little bit > lately but I thought I should probably put it forward > officially and see what people think. I think, frankly, that SPF has to stop changing if there's ever to be any hope of progressing to an IETF standard. (It's possible, I suppose, for it to achieve "market-share" without settling down; but that's not what the MARID WG is for.) > | The two approaches seem complementary to me; is there any reason why > | this WG can't advance both to PS? > > I explain in more detail at > http://spf.pobox.com/slides/unified%20spf/ Here, Meng advises folks to not worry about the difference between HELO and RFC2822. Inevitably, that will lead to a large number of domains advertising relatively open SPF records, and those relatively open records being used to "authenticate" HELOs of MTAs which the actual domain never had the slightest intent of trying to control. And, since all of this is publicly available in DNS, spammers will quickly compile a list of these. But it gets worse: Meng actually advises bypassing further checks if the HELO passes SPF checking and the domain passes reputation checks. (Think about it, Meng: I'm sure you'll relent.) Whereas CSV is designed for exactly the purpose of authenticating and authorizing MTAs: there will be no confusion whether we're talking about taking responsibility for the actions of the MTA or trying to control the path which may be used to send email from the domain. Think it through, Meng: ease of advertising should never be sought at the expense of _accuracy_ of advertising. -- John Leslie From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 09:57:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13025 for ; Thu, 24 Jun 2004 09:57:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ODjUg4056272; Thu, 24 Jun 2004 06:45:30 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5ODjUok056271; Thu, 24 Jun 2004 06:45:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ODjTos056265 for ; Thu, 24 Jun 2004 06:45:29 -0700 (PDT) (envelope-from roy+dated+1090676729.c74cf3@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i5ODjURC090920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 24 Jun 2004 13:45:31 GMT (envelope-from roy+dated+1090676729.c74cf3@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5ODjUaM071116 for ; Thu, 24 Jun 2004 14:45:30 +0100 (BST) (envelope-from roy+dated+1090676729.c74cf3@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5ODjTAk071115 for ietf-mxcomp@imc.org; Thu, 24 Jun 2004 14:45:30 +0100 (BST) (envelope-from roy+dated+1090676729.c74cf3@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Thu, 24 Jun 2004 14:45:27 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16602.56055.417659.749499@giles.gnomon.org.uk> Date: Thu, 24 Jun 2004 14:45:27 +0100 To: Tony Finch Cc: Roy Badami , Harry Katz , Eric Allman , IETF MARID List , Meng Weng Wong Subject: Re: draft-ietf-marid-submitter-01.txt In-Reply-To: References: <16602.4663.751384.263061@giles.gnomon.org.uk> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Tony" == Tony Finch writes: >> Would it be worth adding something along the lines of the >> following to the end of 4.2? Tony> I assume you meant 4.1 here. Oops, yes I did. -roy From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 10:06:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14667 for ; Thu, 24 Jun 2004 10:06:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ODt2EC056763; Thu, 24 Jun 2004 06:55:02 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5ODt2N1056762; Thu, 24 Jun 2004 06:55:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from nickatestmch2 (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ODswOe056753 for ; Thu, 24 Jun 2004 06:55:00 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: from mailgatejd ([10.130.130.110]) by nickatestmch2 with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Jun 2004 15:54:55 +0200 Content-Class: urn:content-classes:message Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 24 Jun 2004 15:54:23 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Jun 2004 15:55:25 +0200 Message-ID: Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 24 Jun 2004 15:53:39 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ODjUg4056272; Thu, 24 Jun 2004 06:45:30 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5ODjUok056271; Thu, 24 Jun 2004 06:45:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ODjTos056265 for ; Thu, 24 Jun 2004 06:45:29 -0700 (PDT) (envelope-from roy+dated+1090676729.c74cf3@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i5ODjURC090920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 24 Jun 2004 13:45:31 GMT (envelope-from roy+dated+1090676729.c74cf3@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5ODjUaM071116 for ; Thu, 24 Jun 2004 14:45:30 +0100 (BST) (envelope-from roy+dated+1090676729.c74cf3@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5ODjTAk071115 for ietf-mxcomp@imc.org; Thu, 24 Jun 2004 14:45:30 +0100 (BST) (envelope-from roy+dated+1090676729.c74cf3@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Thu, 24 Jun 2004 14:45:27 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Thu, 24 Jun 2004 15:54:31 +0200 To: , , Cc: "Roy Badami" , "Harry Katz" , "Eric Allman" , "IETF MARID List" , "Meng Weng Wong" Subject: Re: draft-ietf-marid-submitter-01.txt In-Reply-To: References: <16602.4663.751384.263061@giles.gnomon.org.uk> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: "Roy Badami" X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 24 Jun 2004 13:53:40.0086 (UTC) FILETIME=[A787A960:01C459F2] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Tony" == Tony Finch writes: >> Would it be worth adding something along the lines of the >> following to the end of 4.2? Tony> I assume you meant 4.1 here. Oops, yes I did. -roy From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 10:08:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14939 for ; Thu, 24 Jun 2004 10:08:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ODvSaP056902; Thu, 24 Jun 2004 06:57:28 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5ODvS16056901; Thu, 24 Jun 2004 06:57:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ODvRm2056895 for ; Thu, 24 Jun 2004 06:57:27 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i5ODvoE6024690; Thu, 24 Jun 2004 06:57:50 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i5ODvoKj024687; Thu, 24 Jun 2004 06:57:50 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 24 Jun 2004 06:57:50 -0700 (PDT) From: "william(at)elan.net" To: Meng Weng Wong cc: "'IETF MARID WG'" Subject: Re: Unified SPF In-Reply-To: <20040624035001.GG13225@dumbo.pobox.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 23 Jun 2004, Meng Weng Wong wrote: > I explain in more detail at > http://spf.pobox.com/slides/unified%20spf/ > > Comments are welcome. First, thank you for adding lookup at the PTR name, I now feel that MARID live meeting was indeed a usefull event for me to have come to... For technical comment, I think it would be good if SPF had scope modifier where it could be set which identity (or more then one if necessary) is this record for. For example: v=spf1 id:mailfrom { ip4:192.168.0.1/16 } id:submitter { ip4:192.168.0.20/24 } v=spf1 id:mailfrom+submitter ip4:192.168.0.1/16 id:ehlo mx id:all -all This may possibly be as an operator that changes scope of the identity for record that follows to only cover certain specified identity type, if what is being verified is of different identity type, that data is ignored until another modifier is found that changes the scope back to either all or identity type that is wanted. --- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 10:18:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16272 for ; Thu, 24 Jun 2004 10:18:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OE6UTj057703; Thu, 24 Jun 2004 07:06:30 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OE6UUj057702; Thu, 24 Jun 2004 07:06:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from nickatestmch2 (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OE6QqN057683 for ; Thu, 24 Jun 2004 07:06:27 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: from mailgatejd ([10.130.130.110]) by nickatestmch2 with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Jun 2004 16:06:23 +0200 Content-Class: urn:content-classes:message Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 24 Jun 2004 16:05:55 +0200 Message-ID: <1080701c459f4$60353ad0$6e82820a@mailgatejd> Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Jun 2004 16:07:19 +0200 Content-Transfer-Encoding: 7bit X-Mailer: Microsoft CDO for Windows 2000 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 24 Jun 2004 16:06:56 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ODvSaP056902; Thu, 24 Jun 2004 06:57:28 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5ODvS16056901; Thu, 24 Jun 2004 06:57:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ODvRm2056895 for ; Thu, 24 Jun 2004 06:57:27 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.11/8.12.5) with ESMTP id i5ODvoE6024690; Thu, 24 Jun 2004 06:57:50 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.12.11/8.12.5/Submit) with ESMTP id i5ODvoKj024687; Thu, 24 Jun 2004 06:57:50 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 24 Jun 2004 16:05:59 +0200 From: "william\(at\)elan.net" To: , , Cc: "'IETF MARID WG'" Subject: Re: Unified SPF In-Reply-To: <20040624035001.GG13225@dumbo.pobox.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 24 Jun 2004 14:06:56.0381 (UTC) FILETIME=[8228A2D0:01C459F4] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 23 Jun 2004, Meng Weng Wong wrote: > I explain in more detail at > http://spf.pobox.com/slides/unified%20spf/ > > Comments are welcome. First, thank you for adding lookup at the PTR name, I now feel that MARID live meeting was indeed a usefull event for me to have come to... For technical comment, I think it would be good if SPF had scope modifier where it could be set which identity (or more then one if necessary) is this record for. For example: v=spf1 id:mailfrom { ip4:192.168.0.1/16 } id:submitter { ip4:192.168.0.20/24 } v=spf1 id:mailfrom+submitter ip4:192.168.0.1/16 id:ehlo mx id:all -all This may possibly be as an operator that changes scope of the identity for record that follows to only cover certain specified identity type, if what is being verified is of different identity type, that data is ignored until another modifier is found that changes the scope back to either all or identity type that is wanted. --- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 10:27:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17229 for ; Thu, 24 Jun 2004 10:27:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OE7WOt057772; Thu, 24 Jun 2004 07:07:32 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OE7W79057771; Thu, 24 Jun 2004 07:07:32 -0700 (PDT) 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.9) with ESMTP id i5OE7VdU057763 for ; Thu, 24 Jun 2004 07:07:32 -0700 (PDT) (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 i5OE7VmD006235; Thu, 24 Jun 2004 07:07:31 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 24 Jun 2004 07:07:31 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Michael R. Brumm'" , IETF MARID WG Subject: Deployment RE: TXT now, new RR later (was Re: Why not XML) Date: Thu, 24 Jun 2004 07:07:30 -0700 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 don't see how we've lost any time to the "SPF circus". SPF > and RMX haven't affected RFC 3597 deployment; it's been the > other way around. SPF is being adopted and deployed precisely > because it can be (right now) in TXT records, while RMX was > hindered due to its RR type requirement. The brutal fact that must be faced here is that designing a spec is easy, getting a spec deployed is the hard part. It is very easy to get a spec through a standards process without building any of the support that is required for deployment. This whole argument has centered on persuading network ops to deploy MARID records. That is as it should be because at the end of the day the spam filtering companies are not going to pike at XML, it is an insignificant overhead given what they already do. Microsoft has ways of persuading network ops that are not generally available. They also have rather a lot of experience in incremental transitions of large crufty 1980s technology to a modern architecture. From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 10:38:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18302 for ; Thu, 24 Jun 2004 10:38:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OEQsrm059102; Thu, 24 Jun 2004 07:26:54 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OEQse5059101; Thu, 24 Jun 2004 07:26:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gretel.pobox.com (gretel.pobox.com [208.58.1.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OEQqT3059094 for ; Thu, 24 Jun 2004 07:26:53 -0700 (PDT) (envelope-from mengwong@dumbo.pobox.com) Received: from emerald.pobox.com (emerald.pobox.com [208.210.125.30]) by gretel.pobox.com (Postfix) with ESMTP id B0FDF303E73 for ; Thu, 24 Jun 2004 10:26:15 -0400 (EDT) Received: from dumbo.pobox.com (dumbo.pobox.com [208.210.125.24]) by emerald.pobox.com (Postfix) with ESMTP id 8A36B13357A for ; Thu, 24 Jun 2004 10:25:50 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 895496DE; Thu, 24 Jun 2004 10:25:50 -0400 (EDT) Date: Thu, 24 Jun 2004 10:25:50 -0400 From: Meng Weng Wong To: "'IETF MARID WG'" Subject: Re: Unified SPF: scope macro to distinguish identities Message-ID: <20040624142550.GH13225@dumbo.pobox.com> References: <20040624035001.GG13225@dumbo.pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Jun 24, 2004 at 06:57:50AM -0700, william(at)elan.net wrote: | | For technical comment, I think it would be good if SPF had scope modifier | where it could be set which identity (or more then one if necessary) is | this record for. For example: | | v=spf1 id:mailfrom { ip4:192.168.0.1/16 } id:submitter { ip4:192.168.0.20/24 } | v=spf1 id:mailfrom+submitter ip4:192.168.0.1/16 id:ehlo mx id:all -all | | This may possibly be as an operator that changes scope of the identity for | record that follows to only cover certain specified identity type, if what | is being verified is of different identity type, that data is ignored | until another modifier is found that changes the scope back to either all | or identity type that is wanted. A macro to represent scope is probably cleaner than a scope modifier. I want to state up front my assumption that most publishers will never need to distinguish between scopes: most domains should be able to simply set-join all the four scopes into a single record, and apply local policy from there. That is to say, if the policy for HELO names is v=spf1 A -all and the policy for PRA names, if different, is v=spf1 B -all the joint policy can be v=spf1 A B -all However, if it really is important to distinguish the two, domain.com v=spf1 redirect=%{scope}._spf.%{d} helo._spf.domain.com v=spf1 A -all pra._spf.domain.com v=spf1 B -all This solution provides the desired functionality of "which identity?" scoping. In practice the %{scope} would really be a single character not chosen yet. From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 11:03:58 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19965 for ; Thu, 24 Jun 2004 11:03:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OEo6gt061843; Thu, 24 Jun 2004 07:50:06 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OEo6nh061842; Thu, 24 Jun 2004 07:50:06 -0700 (PDT) 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.9) with ESMTP id i5OEo5nN061834 for ; Thu, 24 Jun 2004 07:50:05 -0700 (PDT) (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 827AD133571 for ; Thu, 24 Jun 2004 10:49:46 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 45EA56DE; Thu, 24 Jun 2004 10:49:46 -0400 (EDT) Date: Thu, 24 Jun 2004 10:49:46 -0400 From: Meng Weng Wong To: "'IETF MARID WG'" Subject: Re: Unified SPF: block versus factored records for HELO and MTAMAark scopes Message-ID: <20040624144946.GI13225@dumbo.pobox.com> References: <40D9C1DA.9090103@ehsco.com> <20040623210515.GF13225@dumbo.pobox.com> <1088031424.23891.85.camel@ddev.mail-abuse.org> <16602.6449.212333.862543@giles.gnomon.org.uk> <20040624035001.GG13225@dumbo.pobox.com> <20040624130742.GC3747@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040624130742.GC3747@verdi> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Jun 24, 2004 at 09:07:42AM -0400, John Leslie wrote: | | | Thus, I believe we need a truly "lightweight" mechanism to separate | whether we're dealing with an unauthorized zombie computer. SPF is | simply _not_ lightweight enough. The question of the relative weight of block vs factored records has been addressed in the past. http://www.imc.org/ietf-mxcomp/mail-archive/msg02115.html In my discussions with Microsoft and AOL, I have gathered the impression that large mail receivers favour block records because they are more easily cached and more easily transformed into a representation native to their internal antispam engines. Factored records which require a new lookup for every cache negative are, in their world, not lightweight by comparison. I should have shared this input sooner as a justification for block records. | If we reach a situation where turning on the SPF feature brings | each MTA to its knees, the feature _will_ be turned off quickly. And | the management of that MTA won't be inclined to turn it on again. And | the word will get out. This is an important caveat, and one which we should all do our best to avoid. The folks at sendmail.net are researching this very point as part of their testing and analysis; I expect our speculation about the relative burden of each approach will soon be informed by better data. | HELO and RFC2822. Inevitably, that will lead to a large number of | domains advertising relatively open SPF records, and those relatively | open records being used to "authenticate" HELOs of MTAs which the actual | domain never had the slightest intent of trying to control. And, since | all of this is publicly available in DNS, spammers will quickly compile | a list of these. | | But it gets worse: Meng actually advises bypassing further checks | if the HELO passes SPF checking and the domain passes reputation checks. | (Think about it, Meng: I'm sure you'll relent.) In the next revision of the website I will try to be very clear about the ways in which receivers might put SPF records to use, and how senders can accommodate the different scenarios. | | Think it through, Meng: ease of advertising should never be sought | at the expense of _accuracy_ of advertising. | Yes, this is very true and important. I will also write up some text to explain in detail exactly what the deal is, and what people are buying when they buy in to the system. From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 11:42:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22252 for ; Thu, 24 Jun 2004 11:42:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OFMfYw065168; Thu, 24 Jun 2004 08:22:41 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OFMfWT065167; Thu, 24 Jun 2004 08:22:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (ntbbs.winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5OFMe3W065155 for ; Thu, 24 Jun 2004 08:22:40 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Thu, 24 Jun 2004 10:26:05 -0400 Received: from ([68.223.169.60]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 1897812985; Thu, 24 Jun 2004 10:26:04 -0400 Message-ID: <001801c459f7$ba0ee8f0$6401a8c0@hdev1> From: "Hector Santos" To: "IETF MARID WG" References: Subject: SPF Domain Lookup Analysis [was Re: Some stats on TXT usage in domain names (updated)] Date: Thu, 24 Jun 2004 10:29:47 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.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: Content-Transfer-Encoding: 7bit Wayne, Thanks for posting this information. I would like to also show some SPF stats. Maybe the DNS experts here can make sense of any of this. My concerns are about DNS overhead and redundancy. As I mentioned in one previous messages about statistics, I pointed out what seems to be real factor is not the total SPF records in DNS currently published by how effective that would be on network topology basis or on per node (system) basis. I used the term personal community to reflect how each system has an unique relationship or association with its environment. The easiest example would be a system that gets a lot of AOL.COM senders, will see a higher SPF rate because AOL has a SPF policy published. On the other hand, a system that gets a lot of HOTMAIL.COM senders will see a higher MCEP rate because HOTMAIL.COM has a MCEP policy published. This suggests that it will help tremendously to get the larger more abused ISPs involved in protecting their domains. It also suggest that for the domains you deal most with, you should encourage supporting MARID. Another example is a semi-private system, private in terms that much of the association is established. A company, a service bureau, and ISP or even personal system with your friends, your personal community of people you exchange mail with, etc They are all still open and expose to the network so SPAM is an still a major issue. I would like to show a SPF statistic report breakdown for the month of May/2004: Statistics: May, 2004 day 1 to 31 total connections : 152416 total spf lookup : 4747 ( 3.1%) See Note 1. total spf none : 4258 total spf records : 489 (10.3%) See Note 2: total breakdown : 489 unique: 94 - pass : 349 unique: 33 - fail : 85 unique: 20 - neutral : 40 unique: 29 - softfail : 14 unique: 11 - unknown : 1 unique: 1 - none : 4258 unique: 866 (See Note 2) Note 1: First, we did everything we could to optimize or minimal the need to perform spam checking. Combined with a suite of filtering methods, by the time it reaches the LMAP lookups, only about 3.1% of the total connects are evaluated for SPF. I would say that is an tremendous overhead reduction improvement. Note 2: Of the 4747 SPF lookups, 10.3% have SPF records. That's good I guess for SPF!. However, only 94 of them or 19.2% are unique domains. Another view would be 5 transactions per SPF domain. For the none results, the near same rate 20.3% appears. Most of the none result are redundant. Of course, these rates will differ per system. But it suggest that each system will have a unique and high degree of association with its environment. SPF can gain another Million nodes next month, and I will have the same rate or effectiveness because very little of the new million SPF domains have nothing to do with us or very little of its spoofed domains come our way. What is important is the common systems that call us. What does this say? I believed it says that most of the benefit will come with each system first protected its own domains and then the associations around it. Sounds pretty obvious? But consider that when a virus such as SORBIG exploits an end user, the first group of systems the virus will target is the user's personal community, his ISP and everyone around the ISP. We seen this a number of our ISP customers, especially older ones who were still using non-local user validation at SMTP and depended on the gateway to bounce the mail. They simply were not aware of the new features (new to them) such as SMTP Local User Validation that eliminates bounce needs for RCPT level rejections. So when their users were exploited, their server was overcome with bounces all over the place, further perpetuating the virus distribution. I guess, to use a stupid analogy, it doesn't quite help calling the Roach Exterminator to fume your apartment if your neighbors are not fumed as well. I would love to hear some input. Maybe I am analyzing this wrong, but it kind of tells me there will be high degree DNS lookup overhead as MARID gets started but in the end, it will evolved to a high level of DNS lookup redundancy. Here is the June breakdown up to this point. Statistics: June, 2004 day 1 to 24 total connections : 128942 total spf lookup : 1901 (1.5%) total spf none : 1615 total spf records : 286 (15.04%) total : 286 unique: 72 - pass : 212 unique: 25 - fail : 38 unique: 13 - neutral : 22 unique: 21 - softfail : 11 unique: 10 - unknown : 3 unique: 3 - none : 1615 unique: 649 -- Hector Santos, Santronics Software, Inc. http://www.santronics.com ----- Original Message ----- From: "wayne" To: "IETF MARID WG" Sent: Thursday, June 24, 2004 3:39 AM Subject: Re: Some stats on TXT usage in domain names (updated) > > > About a month ago, I posted some stats on the usage of TXT records. > Here are some updates > > There was a net increase of 2040 domains with SPF records, a 32.3% > increase in the last month. SPF records are now the most common type > of TXT record usage, surpassing the "unix epoch timestamp" that is > found in many zones. > > The SPF adoption roll, despite being down much of this month, had a > net increase of 4776 records, a 33.7% increase. (The adoption roll, > like most SPF related things, is run by a volunteer.) > > For Caller-ID records, the was a net increase of 5 records, a 6% > increase. > > > > > 1289260 total domain names (same as last time) > 35115 total TXT records found (some domains have more than one) > 8360 have SPF records -> 23.8% of all domain level TXT records are > spf records. > > 26359 domains have txt records > 6315 domains have spf records > > 18968 spf_domains adoption roll > > 87 have Caller-ID records > > > > Last months stats as a reference: > > In wayne writes: > > > 1289260 total domain names > > 33016 total TXT records found (some domains have more than one) > > 6320 have SPF records -> 19.1% of all domain level TXT records are > > spf records > > > > 26359 domains have txt records > > 6315 domains have spf records > > > > 1456 domains found that were also in the adopt roll -> 23.0% > > > > 14192 spf_domains adoption roll > > > > 61554 estimated domains have SPF records. (This probably misses > > most parked domains, of which I have heard rumors that there > > are a least a couple hundred thousand with SPF records. > > > > 82 have Caller-ID records > > 57 have both Caller-ID records and SPF records > > 45 have "testing=true" in the C-ID records. > > 25 have C-ID records only, of which three (10%) are microsoft.com, > > exchange.microsoft.com and hotmail.com > > > > From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 11:54:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22955 for ; Thu, 24 Jun 2004 11:54:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OFfFlE066498; Thu, 24 Jun 2004 08:41:15 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OFfFVa066497; Thu, 24 Jun 2004 08:41:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OFfEEO066491 for ; Thu, 24 Jun 2004 08:41:14 -0700 (PDT) (envelope-from roy+dated+1090683675.a5b036@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i5OFfFRC044917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 24 Jun 2004 15:41:16 GMT (envelope-from roy+dated+1090683675.a5b036@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5OFfFEF072206 for ; Thu, 24 Jun 2004 16:41:15 +0100 (BST) (envelope-from roy+dated+1090683675.a5b036@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5OFfF5C072205 for ietf-mxcomp@imc.org; Thu, 24 Jun 2004 16:41:15 +0100 (BST) (envelope-from roy+dated+1090683675.a5b036@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Thu, 24 Jun 2004 16:41:14 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16602.63002.437751.557545@giles.gnomon.org.uk> Date: Thu, 24 Jun 2004 16:41:14 +0100 To: Meng Weng Wong Cc: "'IETF MARID WG'" Subject: Re: Unified SPF: block versus factored records for HELO and MTAMAark scopes In-Reply-To: <20040624144946.GI13225@dumbo.pobox.com> References: <40D9C1DA.9090103@ehsco.com> <20040623210515.GF13225@dumbo.pobox.com> <1088031424.23891.85.camel@ddev.mail-abuse.org> <16602.6449.212333.862543@giles.gnomon.org.uk> <20040624035001.GG13225@dumbo.pobox.com> <20040624130742.GC3747@verdi> <20040624144946.GI13225@dumbo.pobox.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Meng" == Meng Weng Wong writes: Meng> In my discussions with Microsoft and AOL, I have gathered Meng> the impression that large mail receivers favour block Meng> records because they are more easily cached and more easily Meng> transformed into a representation native to their internal Meng> antispam engines. Factored records which require a new Meng> lookup for every cache negative are, in their world, not Meng> lightweight by comparison. But, AIUI, CSV in it's current incarnation involves doing an SRV lookup on the domain name; how is this more heavyweight than doing a TXT lookup. CSV looks just as cacheable to me as SPF, but uses more compact records... -roy From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 11:58:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23326 for ; Thu, 24 Jun 2004 11:58:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OFiIY1066731; Thu, 24 Jun 2004 08:44:18 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OFiIQS066730; Thu, 24 Jun 2004 08:44:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.mail-abuse.org [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OFiINX066720 for ; Thu, 24 Jun 2004 08:44:18 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.mail-abuse.org (DDev.mail-abuse.org [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id 6F3774149E; Thu, 24 Jun 2004 08:44:14 -0700 (PDT) Subject: Re: Could binary encoding really be the answer? From: Douglas Otis To: Peter Koch Cc: MARID In-Reply-To: <200406240830.i5O8U7o07885@grimsvotn.TechFak.Uni-Bielefeld.DE> References: <200406240830.i5O8U7o07885@grimsvotn.TechFak.Uni-Bielefeld.DE> Content-Type: text/plain Message-Id: <1088091854.24590.15.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 24 Jun 2004 08:44:14 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2004-06-24 at 01:30, Peter Koch wrote: > > Perhaps rather than just a single new record type, consider defining a > > structure composed of new elements where each element is a record type. > > > > 1) An address type for CIDR notation for IPv4 and IPv6 addresses. > > other than APL/RFC 3123? Peter, Thank you for the reference. This RFC would need to be elevated to standards track and be one of the types supported. This would mean only 2 new record types need definition. An Inverse SRV record pointing to 3123 address records with a policy field and a protocol selector function. With this, a PTR type using the same selector function as a domain bridging mechanism. If this can happen, add in an SRV record also using the selector function to reinforce this feature. -Doug From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 12:01:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23661 for ; Thu, 24 Jun 2004 12:01:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OFt8Pn068236; Thu, 24 Jun 2004 08:55:08 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OFt8UQ068235; Thu, 24 Jun 2004 08:55:08 -0700 (PDT) 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.9) with ESMTP id i5OFt7nc068220 for ; Thu, 24 Jun 2004 08:55:07 -0700 (PDT) (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 i5OFt7iq000885; Thu, 24 Jun 2004 17:55:07 +0200 Received: from danisch.de (localhost [127.0.0.1]) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-5) with ESMTP id i5OFprZ1007439; Thu, 24 Jun 2004 17:51:53 +0200 Message-ID: <40DAF899.8050307@danisch.de> Date: Thu, 24 Jun 2004 17:51:53 +0200 From: Hadmut Danisch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040528 Debian/1.6-7 X-Accept-Language: de-de MIME-Version: 1.0 To: "Michael R. Brumm" CC: IETF MARID WG Subject: Re: TXT now, new RR later (was Re: Why not XML) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Michael R. Brumm wrote: >SMTP authorization cannot wait for RFC 3597 to be widely deployed. People will not wait this long. Spam is an ever increasing burden on everyone from the postmaster down to the end-user. I'm sure I don't even have to mention this. > >... > > >The "SPF circus" hasn't delayed the adoption of RFC 3597, and RMX has not significantly increased the adoption rate of RFC 3597. In any case, the date of RFC 3597 is "September 2003", which is less than 10 months ago. I don't see how we can expect anything as incredibly large-scale as SMTP authorization to be built on something that is so young and not widely implemented. > > > >... > > >I don't see how we've lost any time to the "SPF circus". SPF and RMX haven't affected RFC 3597 deployment; it's been the other way around. SPF is being adopted and deployed precisely because it can be (right now) in TXT records, while RMX was hindered due to its RR type requirement. > > > I see three arguments in your posting: RFC3597, RFC3597, and RFC3597. This issue had been discussed in ASRG and several mailing lists about a year ago, and had been considered to not be a real problem, because most DNS servers already are able to forward unknown RR types. RFC3597 is not a new invention, merely a description of a status quo already reached with newer DNS servers. (I didn't find this discussion yet in my RMX mail archives, because they are several hundreds of megabytes) BTW, this discussion was the reason why I had to drop the DNS domain name compression from earlier drafts of RMX: I had made use of the domain name compression described in DNS in my test implementation and it had good results depending on the RMX entry type (obviously for those entry types containing a DNS name). I received a hint from a DNS working group that this won't work. Guess why! Because DNS name compression works only if every DNS relay is able to decode and reencode the RR type. This compression method does not work if the DNS server is forwarding the record without modification. And that's the problem: Most modern DNS server already do forward unknown RR types, but due to the fact that they are unknown, the DNS servers can't de- and reencode them. Probably it was that discussion about RMX records why it is stated explicitely in RFC3597 to not use DNS compression for new record types. This problem would not have occured if DNS servers would drop unknown types. So I had to drop the compression from the draft just because too many DNS servers already are forwarding unknown RR types, therefore a new RR type cannot be invented with DNS compression. And, btw, I made some tests with an RMX implementation, were at least the DNS servers involved in the tests were forwarding the RMX records even without beeing patched. So the RFC3597 argument is not a good argument (all three of them). Hadmut From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 12:01:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23664 for ; Thu, 24 Jun 2004 12:01:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OFsIuD068131; Thu, 24 Jun 2004 08:54:18 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OFsInH068130; Thu, 24 Jun 2004 08:54:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from nickatestmch2 (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OFsDlN068107 for ; Thu, 24 Jun 2004 08:54:14 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: from mailgatejd ([10.130.130.110]) by nickatestmch2 with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Jun 2004 17:54:13 +0200 Content-Class: urn:content-classes:message Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 24 Jun 2004 17:53:01 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Jun 2004 17:54:25 +0200 Message-ID: <1a44201c45a03$6f0e0cd0$6e82820a@mailgatejd> Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 24 Jun 2004 17:53:35 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OFfFlE066498; Thu, 24 Jun 2004 08:41:15 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OFfFVa066497; Thu, 24 Jun 2004 08:41:15 -0700 (PDT) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OFfEEO066491 for ; Thu, 24 Jun 2004 08:41:14 -0700 (PDT) (envelope-from roy+dated+1090683675.a5b036@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i5OFfFRC044917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 24 Jun 2004 15:41:16 GMT (envelope-from roy+dated+1090683675.a5b036@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5OFfFEF072206 for ; Thu, 24 Jun 2004 16:41:15 +0100 (BST) (envelope-from roy+dated+1090683675.a5b036@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5OFfF5C072205 for ietf-mxcomp@imc.org; Thu, 24 Jun 2004 16:41:15 +0100 (BST) (envelope-from roy+dated+1090683675.a5b036@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Thu, 24 Jun 2004 16:41:14 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Thu, 24 Jun 2004 17:53:46 +0200 To: , , Cc: "'IETF MARID WG'" Subject: Re: Unified SPF: block versus factored records for HELO and MTAMAarkscopes In-Reply-To: <20040624144946.GI13225@dumbo.pobox.com> References: <40D9C1DA.9090103@ehsco.com><20040623210515.GF13225@dumbo.pobox.com><1088031424.23891.85.camel@ddev.mail-abuse.org><16602.6449.212333.862543@giles.gnomon.org.uk><20040624035001.GG13225@dumbo.pobox.com><20040624130742.GC3747@verdi><20040624144946.GI13225@dumbo.pobox.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: "Roy Badami" X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 24 Jun 2004 15:53:35.0373 (UTC) FILETIME=[684153D0:01C45A03] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Meng" == Meng Weng Wong writes: Meng> In my discussions with Microsoft and AOL, I have gathered Meng> the impression that large mail receivers favour block Meng> records because they are more easily cached and more easily Meng> transformed into a representation native to their internal Meng> antispam engines. Factored records which require a new Meng> lookup for every cache negative are, in their world, not Meng> lightweight by comparison. But, AIUI, CSV in it's current incarnation involves doing an SRV lookup on the domain name; how is this more heavyweight than doing a TXT lookup. CSV looks just as cacheable to me as SPF, but uses more compact records... -roy From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 12:03:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23754 for ; Thu, 24 Jun 2004 12:03:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OFrNE7068073; Thu, 24 Jun 2004 08:53:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OFrN3R068072; Thu, 24 Jun 2004 08:53:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from nickatestmch2 (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OFrK6R068059 for ; Thu, 24 Jun 2004 08:53:21 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: from mailgatejd ([10.130.130.110]) by nickatestmch2 with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Jun 2004 17:53:20 +0200 Content-Class: urn:content-classes:message Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 24 Jun 2004 17:52:50 +0200 Message-ID: <1a2cc01c45a03$4f8c4110$6e82820a@mailgatejd> Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Jun 2004 17:54:13 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 24 Jun 2004 17:53:13 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OFiIY1066731; Thu, 24 Jun 2004 08:44:18 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OFiIQS066730; Thu, 24 Jun 2004 08:44:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.mail-abuse.org [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OFiINX066720 for ; Thu, 24 Jun 2004 08:44:18 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.mail-abuse.org (DDev.mail-abuse.org [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id 6F3774149E; Thu, 24 Jun 2004 08:44:14 -0700 (PDT) Subject: Re: Could binary encoding really be the answer? From: "Douglas Otis" To: , , Cc: "MARID" In-Reply-To: <200406240830.i5O8U7o07885@grimsvotn.TechFak.Uni-Bielefeld.DE> References: <200406240830.i5O8U7o07885@grimsvotn.TechFak.Uni-Bielefeld.DE> Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 24 Jun 2004 17:52:53 +0200 Content-Transfer-Encoding: 7bit List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 24 Jun 2004 15:53:14.0152 (UTC) FILETIME=[5B9B4280:01C45A03] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2004-06-24 at 01:30, Peter Koch wrote: > > Perhaps rather than just a single new record type, consider defining a > > structure composed of new elements where each element is a record type. > > > > 1) An address type for CIDR notation for IPv4 and IPv6 addresses. > > other than APL/RFC 3123? Peter, Thank you for the reference. This RFC would need to be elevated to standards track and be one of the types supported. This would mean only 2 new record types need definition. An Inverse SRV record pointing to 3123 address records with a policy field and a protocol selector function. With this, a PTR type using the same selector function as a domain bridging mechanism. If this can happen, add in an SRV record also using the selector function to reinforce this feature. -Doug From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 12:10:11 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24228 for ; Thu, 24 Jun 2004 12:10:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OG2Zfc069101; Thu, 24 Jun 2004 09:02:35 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OG2ZTe069100; Thu, 24 Jun 2004 09:02:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from nickatestmch2 (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OG2XOo069080 for ; Thu, 24 Jun 2004 09:02:34 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: from mailgatejd ([10.130.130.110]) by nickatestmch2 with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Jun 2004 18:02:33 +0200 Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 24 Jun 2004 18:02:02 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Jun 2004 18:03:26 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 24 Jun 2004 18:01:33 +0200 Message-ID: <1ad0f01c45a04$98dd1050$6e82820a@mailgatejd> Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OFrNE7068073; Thu, 24 Jun 2004 08:53:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OFrN3R068072; Thu, 24 Jun 2004 08:53:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from nickatestmch2 (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OFrK6R068059 for ; Thu, 24 Jun 2004 08:53:21 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: from mailgatejd ([10.130.130.110]) by nickatestmch2 with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Jun 2004 17:53:20 +0200 Content-Class: urn:content-classes:message Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 24 Jun 2004 17:52:50 +0200 Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Jun 2004 17:54:13 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 24 Jun 2004 17:53:13 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OFiIY1066731; Thu, 24 Jun 2004 08:44:18 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OFiIQS066730; Thu, 24 Jun 2004 08:44:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.mail-abuse.org [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OFiINX066720 for ; Thu, 24 Jun 2004 08:44:18 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.mail-abuse.org (DDev.mail-abuse.org [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id 6F3774149E; Thu, 24 Jun 2004 08:44:14 -0700 (PDT) Subject: Re: Could binary encoding really be the answer? From: "Douglas Otis" To: , , Cc: "MARID" In-Reply-To: <200406240830.i5O8U7o07885@grimsvotn.TechFak.Uni-Bielefeld.DE> References: <200406240830.i5O8U7o07885@grimsvotn.TechFak.Uni-Bielefeld.DE> Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 24 Jun 2004 18:02:06 +0200 Content-Transfer-Encoding: 7bit List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 24 Jun 2004 15:53:14.0152 (UTC) FILETIME=[5B9B4280:01C45A03] List-Archive: List-Unsubscribe: List-ID: Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2004-06-24 at 01:30, Peter Koch wrote: > > Perhaps rather than just a single new record type, consider defining a > > structure composed of new elements where each element is a record type. > > > > 1) An address type for CIDR notation for IPv4 and IPv6 addresses. > > other than APL/RFC 3123? Peter, Thank you for the reference. This RFC would need to be elevated to standards track and be one of the types supported. This would mean only 2 new record types need definition. An Inverse SRV record pointing to 3123 address records with a policy field and a protocol selector function. With this, a PTR type using the same selector function as a domain bridging mechanism. If this can happen, add in an SRV record also using the selector function to reinforce this feature. -Doug From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 12:14:41 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24546 for ; Thu, 24 Jun 2004 12:14:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OG29Jh069072; Thu, 24 Jun 2004 09:02:09 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OG29AE069071; Thu, 24 Jun 2004 09:02:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from nickatestmch2 (c187-66.i02-7.onvol.net [213.165.187.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OG27gV069062 for ; Thu, 24 Jun 2004 09:02:08 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: from mailgatejd ([10.130.130.110]) by nickatestmch2 with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Jun 2004 18:02:07 +0200 Content-Class: urn:content-classes:message Received: from gfivpns.gfi.com ([10.130.130.36]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 24 Jun 2004 18:01:36 +0200 Message-ID: <1aca801c45a04$89aa1290$6e82820a@mailgatejd> Received: from server1.gfi.com ([209.61.184.105]) by gfivpns.gfi.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Jun 2004 18:03:00 +0200 X-Mailer: Microsoft CDO for Windows 2000 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 24 Jun 2004 18:00:59 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OFt8Pn068236; Thu, 24 Jun 2004 08:55:08 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OFt8UQ068235; Thu, 24 Jun 2004 08:55:08 -0700 (PDT) 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.9) with ESMTP id i5OFt7nc068220 for ; Thu, 24 Jun 2004 08:55:07 -0700 (PDT) (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 i5OFt7iq000885; Thu, 24 Jun 2004 17:55:07 +0200 Received: from danisch.de (localhost [127.0.0.1]) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-5) with ESMTP id i5OFprZ1007439; Thu, 24 Jun 2004 17:51:53 +0200 Date: Thu, 24 Jun 2004 18:01:40 +0200 From: "Hadmut Danisch" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040528 Debian/1.6-7 X-Accept-Language: de-de MIME-Version: 1.0 To: , , Cc: "IETF MARID WG" Subject: Re: TXT now, new RR later (was Re: Why not XML) References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 24 Jun 2004 16:00:59.0471 (UTC) FILETIME=[70F54DF0:01C45A04] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Michael R. Brumm wrote: >SMTP authorization cannot wait for RFC 3597 to be widely deployed. People will not wait this long. Spam is an ever increasing burden on everyone from the postmaster down to the end-user. I'm sure I don't even have to mention this. > >... > > >The "SPF circus" hasn't delayed the adoption of RFC 3597, and RMX has not significantly increased the adoption rate of RFC 3597. In any case, the date of RFC 3597 is "September 2003", which is less than 10 months ago. I don't see how we can expect anything as incredibly large-scale as SMTP authorization to be built on something that is so young and not widely implemented. > > > >... > > >I don't see how we've lost any time to the "SPF circus". SPF and RMX haven't affected RFC 3597 deployment; it's been the other way around. SPF is being adopted and deployed precisely because it can be (right now) in TXT records, while RMX was hindered due to its RR type requirement. > > > I see three arguments in your posting: RFC3597, RFC3597, and RFC3597. This issue had been discussed in ASRG and several mailing lists about a year ago, and had been considered to not be a real problem, because most DNS servers already are able to forward unknown RR types. RFC3597 is not a new invention, merely a description of a status quo already reached with newer DNS servers. (I didn't find this discussion yet in my RMX mail archives, because they are several hundreds of megabytes) BTW, this discussion was the reason why I had to drop the DNS domain name compression from earlier drafts of RMX: I had made use of the domain name compression described in DNS in my test implementation and it had good results depending on the RMX entry type (obviously for those entry types containing a DNS name). I received a hint from a DNS working group that this won't work. Guess why! Because DNS name compression works only if every DNS relay is able to decode and reencode the RR type. This compression method does not work if the DNS server is forwarding the record without modification. And that's the problem: Most modern DNS server already do forward unknown RR types, but due to the fact that they are unknown, the DNS servers can't de- and reencode them. Probably it was that discussion about RMX records why it is stated explicitely in RFC3597 to not use DNS compression for new record types. This problem would not have occured if DNS servers would drop unknown types. So I had to drop the compression from the draft just because too many DNS servers already are forwarding unknown RR types, therefore a new RR type cannot be invented with DNS compression. And, btw, I made some tests with an RMX implementation, were at least the DNS servers involved in the tests were forwarding the RMX records even without beeing patched. So the RFC3597 argument is not a good argument (all three of them). Hadmut From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 12:39:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27435 for ; Thu, 24 Jun 2004 12:39:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OGU3Fd071341; Thu, 24 Jun 2004 09:30:03 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OGU3fA071340; Thu, 24 Jun 2004 09:30:03 -0700 (PDT) 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.9) with ESMTP id i5OGU2n1071333 for ; Thu, 24 Jun 2004 09:30:03 -0700 (PDT) (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 i5OGU5DV001760 for ietf-mxcomp@imc.org; Thu, 24 Jun 2004 18:30:05 +0200 Received: from danisch.de (localhost [127.0.0.1]) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-5) with ESMTP id i5OGTx5P009003 for ; Thu, 24 Jun 2004 18:29:59 +0200 Message-ID: <40DB0187.7030204@danisch.de> Date: Thu, 24 Jun 2004 18:29:59 +0200 From: Hadmut Danisch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040528 Debian/1.6-7 X-Accept-Language: de-de MIME-Version: 1.0 To: ietf-mxcomp@imc.org Subject: Designing and Allocating a new RR type Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit My current thoughts about how a new RR type should look like: We should not allocate a MARID record type (surprise!) We should contact the DNS crew and cooperate with them to invent a new generic binary container RR type, not specific to MARID. The link to MARID would be in the fqdn, i.e. the _marid. prefix. Giving an entry it's content type not by the RR type only, but by parts of the dns name also is not in the spirit of the original DNS. DNS has nevertheless made this step already with SRV records. So this should not be an issue. This way we also have a container for future work, e.g. when describing what kind of mail a receiver is willing to accept, or records for other kinds of services. Or storing public keys,... As I stated in earlier postings, DNS servers should not modify or decode it, just forward it as it is. It would be to be discussed with the DNS people whether the container should contain - any binary data - ASN.1 encoded data only - ASN.1 tagged with a OID for unambigous identification of the content type I vote for ASN.1 with OID. I believe such an easy to implement and generic record suitable for other uses than MARID too would be accepted and implemented much faster. regards Hadmut From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 13:01:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29498 for ; Thu, 24 Jun 2004 13:01:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OGqHk4073628; Thu, 24 Jun 2004 09:52:17 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OGqHoi073627; Thu, 24 Jun 2004 09:52:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zardoc.esmtp.org (adsl-63-195-85-27.dsl.snfc21.pacbell.net [63.195.85.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OGqHIp073618 for ; Thu, 24 Jun 2004 09:52:17 -0700 (PDT) (envelope-from ca+envelope@esmtp.org) Received: from zardoc.esmtp.org (localhost.endmail.org. [127.0.0.1]) by zardoc.esmtp.org (sendmail X.0.0.PreAlpha13) with ESMTP id S00000000407D45F400; Thu, 24 Jun 2004 09:52:28 -0700 Received: (from ca@localhost) by zardoc.esmtp.org (8.13.0/8.12.10.Beta0/Submit) id i5OGqSb1019782 for ietf-mxcomp@imc.org; Thu, 24 Jun 2004 09:52:28 -0700 (PDT) Date: Thu, 24 Jun 2004 09:52:28 -0700 From: Claus Assmann To: ietf-mxcomp@imc.org Subject: Re: ASN.1 as encoding (was: Designing and Allocating a new RR type) Message-ID: <20040624165228.GA13635@zardoc.esmtp.org> Mail-Followup-To: Claus Assmann , ietf-mxcomp@imc.org References: <40DB0187.7030204@danisch.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40DB0187.7030204@danisch.de> User-Agent: Mutt/1.5.6i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Jun 24, 2004, Hadmut Danisch wrote: > - ASN.1 encoded data only > - ASN.1 tagged with a OID for unambigous identification > of the content type Hmm, people are discussing possible security problems due to the use of XML. What about ASN.1? It seems that writing a parser for it is not trivial; just look at some OpenSSL security advisories: o Security: fix vulnerabilities in ASN.1 parsing CAN-2003-0543, CAN-2003-0544 [0.9.7c & 0.9.6k] o Security: fix additional vulnerability in ASN.1 parsing CAN-2003-0545 [0.9.7c] From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 13:09:33 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00329 for ; Thu, 24 Jun 2004 13:09:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OGwkh7073959; Thu, 24 Jun 2004 09:58:46 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OGwkcg073958; Thu, 24 Jun 2004 09:58:46 -0700 (PDT) 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.9) with ESMTP id i5OGwiTO073949 for ; Thu, 24 Jun 2004 09:58:45 -0700 (PDT) (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 i5OGwfgC002609; Thu, 24 Jun 2004 18:58:41 +0200 Received: from danisch.de (localhost [127.0.0.1]) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-5) with ESMTP id i5OGuBEs010113; Thu, 24 Jun 2004 18:56:11 +0200 Message-ID: <40DB07AB.7080408@danisch.de> Date: Thu, 24 Jun 2004 18:56:11 +0200 From: Hadmut Danisch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040528 Debian/1.6-7 X-Accept-Language: de-de MIME-Version: 1.0 To: Harry Katz CC: Jim Lyon , IETF MARID List Subject: Re: draft-ietf-marid-submitter-01.txt References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070500080207030906070103" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. --------------070500080207030906070103 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Harry Katz wrote: > Attached is the latest revision to the Responsible Submitter > internet-draft. Good proposal. But shouldn't the proposal include an extension to the Received:-Header to include the given (and verified) submitter name? Or a new header entry? In a chain of submissions I'd like to be able to trace the submission back. regards Hadmut --------------070500080207030906070103 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Harry Katz wrote:
Attached is the latest revision to the Responsible Submitter internet-draft. 

Good proposal.

But shouldn't the proposal include an extension to the Received:-Header
to include the given (and verified) submitter name? Or a new header entry?
In a chain of submissions I'd like to be able to trace the submission back.

regards
Hadmut

 --------------070500080207030906070103-- From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 13:23:11 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01957 for ; Thu, 24 Jun 2004 13:23:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OHC9k0075353; Thu, 24 Jun 2004 10:12:09 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OHC933075352; Thu, 24 Jun 2004 10:12:09 -0700 (PDT) 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.9) with ESMTP id i5OHC82S075344 for ; Thu, 24 Jun 2004 10:12:08 -0700 (PDT) (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.34) id 1BdXlT-0005CL-Hy for ietf-mxcomp@imc.org; Thu, 24 Jun 2004 12:12:09 -0500 To: "IETF MARID WG" References: <40DB0187.7030204@danisch.de> From: wayne Reply-To: "IETF MARID WG" Date: Thu, 24 Jun 2004 12:11:55 -0500 In-Reply-To: <40DB0187.7030204@danisch.de> (Hadmut Danisch's message of "Thu, 24 Jun 2004 18:29:59 +0200") 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 (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: Designing and Allocating a new RR type Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.3 required=4.0 tests=AWL,BAYES_00,GREYLIST_ISWHITE autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <40DB0187.7030204@danisch.de> Hadmut Danisch writes: > We should not allocate a MARID record type (surprise!) > > We should contact the DNS crew and cooperate with them > to invent a new generic binary container RR type, not > specific to MARID. Huh. I hadn't thought about that for a binary record. I had thought that the DNS folks should allocate something like 10 generic TXT records in the RR type range of 0-255 and another 100 in the range of 256-65536. People would be free to pick and choose whichever one they wanted with far less chance of collisions. -wayne From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 13:36:09 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03560 for ; Thu, 24 Jun 2004 13:36:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OHP4WT077504; Thu, 24 Jun 2004 10:25:04 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OHP4tR077503; Thu, 24 Jun 2004 10:25:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.mail-abuse.org [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OHP4V5077497 for ; Thu, 24 Jun 2004 10:25:04 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.mail-abuse.org (DDev.mail-abuse.org [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id 2CCD94149E; Thu, 24 Jun 2004 10:25:08 -0700 (PDT) Subject: Re: Designing and Allocating a new RR type From: Douglas Otis To: Hadmut Danisch Cc: MARID In-Reply-To: <40DB0187.7030204@danisch.de> References: <40DB0187.7030204@danisch.de> Content-Type: text/plain Message-Id: <1088097907.24590.58.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 24 Jun 2004 10:25:07 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2004-06-24 at 09:29, Hadmut Danisch wrote: > The link to MARID would be in the fqdn, i.e. the _marid. prefix. > > Giving an entry it's content type not by the RR type only, but by > parts of the dns name also is not in the spirit of the original > DNS. DNS has nevertheless made this step already with > SRV records. So this should not be an issue. This is an issue if wild cards are used. > This way we also have a container for future work, e.g. when > describing what kind of mail a receiver is willing to accept, > or records for other kinds of services. Or storing public keys,... > > As I stated in earlier postings, DNS servers should not modify > or decode it, just forward it as it is. Returning only essential data would be good; preferably in binary structures. > It would be to be discussed with the DNS people whether > the container should contain Named references to RFC 3123 record types returned in the Additional Data section would be one choice. > - any binary data > - ASN.1 encoded data only > - ASN.1 tagged with a OID for unambiguous identification > of the content type > > I vote for ASN.1 with OID. DNS was never designed to return comprehensive answers to simple queries. The query should be specific with the response equally specific. If a broad and comprehensive answer is needed, then use an SRV record to point to a port on an HTTP server. Shifting processing to the sender with an SRV mechanism is safer and more extensible. -Doug From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 13:52:09 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04980 for ; Thu, 24 Jun 2004 13:52:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OHj99p079508; Thu, 24 Jun 2004 10:45:09 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OHj9xU079507; Thu, 24 Jun 2004 10:45:09 -0700 (PDT) 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.9) with ESMTP id i5OHj8ad079500 for ; Thu, 24 Jun 2004 10:45:08 -0700 (PDT) (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 i5OHj5i6003886; Thu, 24 Jun 2004 19:45:05 +0200 Received: from danisch.de (localhost [127.0.0.1]) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-5) with ESMTP id i5OHhE92012039; Thu, 24 Jun 2004 19:43:14 +0200 Message-ID: <40DB12B2.1010508@danisch.de> Date: Thu, 24 Jun 2004 19:43:14 +0200 From: Hadmut Danisch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040528 Debian/1.6-7 X-Accept-Language: de-de MIME-Version: 1.0 To: Douglas Otis CC: MARID Subject: Re: Designing and Allocating a new RR type References: <40DB0187.7030204@danisch.de> <1088097907.24590.58.camel@ddev.mail-abuse.org> In-Reply-To: <1088097907.24590.58.camel@ddev.mail-abuse.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Douglas Otis wrote: >DNS was never designed to return comprehensive answers to simple >queries. The query should be specific with the response equally >specific. If a broad and comprehensive answer is needed, then use an >SRV record to point to a port on an HTTP server. Shifting processing to >the sender with an SRV mechanism is safer and more extensible. > > * sigh * That's why I proposed RMX++ which does exactly that. For exactly those reasons. Almost no resonance yet. Hadmut From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 13:52:39 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05029 for ; Thu, 24 Jun 2004 13:52:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OHkkE6079754; Thu, 24 Jun 2004 10:46:46 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OHkkgT079753; Thu, 24 Jun 2004 10:46:46 -0700 (PDT) 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.9) with ESMTP id i5OHkjEN079744 for ; Thu, 24 Jun 2004 10:46:45 -0700 (PDT) (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 CB677133581; Thu, 24 Jun 2004 13:46:46 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 9FF03628; Thu, 24 Jun 2004 13:46:46 -0400 (EDT) Date: Thu, 24 Jun 2004 13:46:46 -0400 From: Meng Weng Wong To: "'IETF MARID WG'" Cc: Roy Badami Subject: Re: Unified SPF: block versus factored records for HELO and MTAMAark scopes Message-ID: <20040624174646.GJ13225@dumbo.pobox.com> References: <40D9C1DA.9090103@ehsco.com> <20040623210515.GF13225@dumbo.pobox.com> <1088031424.23891.85.camel@ddev.mail-abuse.org> <16602.6449.212333.862543@giles.gnomon.org.uk> <20040624035001.GG13225@dumbo.pobox.com> <20040624130742.GC3747@verdi> <20040624144946.GI13225@dumbo.pobox.com> <16602.63002.437751.557545@giles.gnomon.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16602.63002.437751.557545@giles.gnomon.org.uk> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Jun 24, 2004 at 04:41:14PM +0100, Roy Badami wrote: | | Meng> antispam engines. Factored records which require a new | Meng> lookup for every cache negative are, in their world, not | Meng> lightweight by comparison. | | But, AIUI, CSV in it's current incarnation involves doing an SRV | lookup on the domain name; how is this more heavyweight than doing a | TXT lookup. CSV looks just as cacheable to me as SPF, but uses more | compact records... | I was mainly comparing cache negatives. Scenario: 5 spams that all say MAIL FROM: Let each spam come from a different IP. client ip factored query block query --------- -------------------------- --------------- 192.0.2.1 lookup(aol.com, 192.0.2.1) lookup(aol.com) 192.0.2.2 lookup(aol.com, 192.0.2.2) cached 192.0.2.3 lookup(aol.com, 192.0.2.3) cached 192.0.2.4 lookup(aol.com, 192.0.2.4) cached 192.0.2.5 lookup(aol.com, 192.0.2.5) cached In this scenario, factored queries do not benefit from local DNS caching. So, the theory is: a spam run against a single receiver domain may originate from X distinct IPs. That spam run may forge Y distinct domain names. If X >> Y, a block format is better than factored. If Y >> X, block and factored formats are equivalent within one order of magnitude. Scenarios in which factored formats beat block formats hands down tend to be contrived. The current threat model is lots of zombies, hence lots of IPs. True, there's nothing to stop them from forging lots of domains, too. That's where the MTAMark design proves useful --- it scales well, because only one network owner has to add records. From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 14:14:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08111 for ; Thu, 24 Jun 2004 14:14:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OHxFbf081172; Thu, 24 Jun 2004 10:59:15 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OHxF3g081171; Thu, 24 Jun 2004 10:59:15 -0700 (PDT) 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.9) with ESMTP id i5OHxEjj081165 for ; Thu, 24 Jun 2004 10:59:14 -0700 (PDT) (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 78CBD13357C; Thu, 24 Jun 2004 13:59:17 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 487A361F; Thu, 24 Jun 2004 13:59:17 -0400 (EDT) Date: Thu, 24 Jun 2004 13:59:17 -0400 From: Meng Weng Wong To: Roy Badami Cc: Meng Weng Wong , "'IETF MARID WG'" Subject: Re: Unified SPF: block versus factored records for HELO and MTAMAark scopes Message-ID: <20040624175917.GK13225@dumbo.pobox.com> References: <40D9C1DA.9090103@ehsco.com> <20040623210515.GF13225@dumbo.pobox.com> <1088031424.23891.85.camel@ddev.mail-abuse.org> <16602.6449.212333.862543@giles.gnomon.org.uk> <20040624035001.GG13225@dumbo.pobox.com> <20040624130742.GC3747@verdi> <20040624144946.GI13225@dumbo.pobox.com> <16602.63002.437751.557545@giles.gnomon.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16602.63002.437751.557545@giles.gnomon.org.uk> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Jun 24, 2004 at 04:41:14PM +0100, Roy Badami wrote: | | But, AIUI, CSV in it's current incarnation involves doing an SRV | lookup on the domain name; how is this more heavyweight than doing a | TXT lookup. CSV looks just as cacheable to me as SPF, but uses more | compact records... | OK, speaking of CSV in its current incarnation, can anyone give me a concrete example of how the authentication/authorization procedure operates? In SPF, authentication is simple: you do the SPF TXT lookup, you get back the SPF TXT record, the computer thinks a bit, and you get a well-defined PASS or FAIL or NEUTRAL, etc response. In CSV, http://www.jlc.net/MARID/CSV/draft-ietf-marid-csv-intro-00.html#anchor11 suggests that you do authentication by doing a A lookup of the HELO name; (if an SRV lookup against _client._smtp.DOMAIN returns "2", AND (the IP address of the SMTP client is one of the A records of the HELO name, OR the IP address of the SMTP client was returned in the SRV response's Additional Data section,) THEN that is equivalent to an SPF "PASS". Is that correct? I would request that the next draft of the CSV proposal contain some examples and walkthroughs. From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 14:25:28 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09276 for ; Thu, 24 Jun 2004 14:25:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OIICBS082717; Thu, 24 Jun 2004 11:18:12 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OIICf1082715; Thu, 24 Jun 2004 11:18:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from goose.ehsco.com (goose.ehsco.com [207.65.203.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OIICcV082708 for ; Thu, 24 Jun 2004 11:18:12 -0700 (PDT) (envelope-from ehall@ehsco.com) Received: from [207.65.71.20] (unknown [207.65.71.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Eric A. Hall", Issuer "Network Technology Research Group Certificate Authority" (verified OK)) by goose.ehsco.com (Postfix ) with ESMTP id E28535FE50 for ; Thu, 24 Jun 2004 13:18:12 -0500 (CDT) Message-ID: <40DB1AB9.5030904@ehsco.com> Date: Thu, 24 Jun 2004 13:17:29 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-mxcomp@imc.org Subject: Re: Designing and Allocating a new RR type References: <40DB0187.7030204@danisch.de> In-Reply-To: <40DB0187.7030204@danisch.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I think that the idea of using ASN.1 is fine as an architectural point (DNS certainly suffers from a lack of strict data-typing), but it's overkill for what we need, while the implementation and potential exploit problems are on par with XML. So I don't think we should use it for this specific RR. Too much work for too little gain. Remember that every ~100 bytes of RR data is roughly the same as whatever was cached from PTR/A/NS lookups, and saving ~30% or so on that is a good enough target, so getting to ~70 bytes per RR is really what we should be looking to reasonably achieve. If the scope of data is limited, it will probably be good enough to have coded types and textual field data within the limited subset of types. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 14:25:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09316 for ; Thu, 24 Jun 2004 14:25:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OIGjxG082327; Thu, 24 Jun 2004 11:16:45 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OIGjK8082326; Thu, 24 Jun 2004 11:16:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OIGhjx082320 for ; Thu, 24 Jun 2004 11:16:43 -0700 (PDT) (envelope-from roy+dated+1090693005.63f25c@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i5OIGjRC094548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 24 Jun 2004 18:16:46 GMT (envelope-from roy+dated+1090693005.63f25c@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5OIGjVp015926 for ; Thu, 24 Jun 2004 19:16:45 +0100 (BST) (envelope-from roy+dated+1090693005.63f25c@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5OIGjdF015925 for ietf-mxcomp@imc.org; Thu, 24 Jun 2004 19:16:45 +0100 (BST) (envelope-from roy+dated+1090693005.63f25c@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Thu, 24 Jun 2004 19:16:45 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16603.6796.578700.81170@giles.gnomon.org.uk> Date: Thu, 24 Jun 2004 19:16:44 +0100 To: Meng Weng Wong Cc: "'IETF MARID WG'" , Roy Badami Subject: Re: Unified SPF: block versus factored records for HELO and MTAMAark scopes In-Reply-To: <20040624174646.GJ13225@dumbo.pobox.com> References: <40D9C1DA.9090103@ehsco.com> <20040623210515.GF13225@dumbo.pobox.com> <1088031424.23891.85.camel@ddev.mail-abuse.org> <16602.6449.212333.862543@giles.gnomon.org.uk> <20040624035001.GG13225@dumbo.pobox.com> <20040624130742.GC3747@verdi> <20040624144946.GI13225@dumbo.pobox.com> <16602.63002.437751.557545@giles.gnomon.org.uk> <20040624174646.GJ13225@dumbo.pobox.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Let each spam come from a different IP. client ip factored query block query --------- -------------------------- --------------- 192.0.2.1 lookup(aol.com, 192.0.2.1) lookup(aol.com) 192.0.2.2 lookup(aol.com, 192.0.2.2) cached 192.0.2.3 lookup(aol.com, 192.0.2.3) cached 192.0.2.4 lookup(aol.com, 192.0.2.4) cached 192.0.2.5 lookup(aol.com, 192.0.2.5) cached I still don't see how it's different. In draft-ietf-marid-core, the first of the above will do a TXT query on _ep.aol.com and aol.com. Each of the subsequent lookups will use the positively or negatively cached results. In draft-ietf-marid-csv-csa, the first of the above will do a SRV query on _client._smtp.aol.com. Each of the subsequent lookups will use the positively or negatively cached results. -roy From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 14:36:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10624 for ; Thu, 24 Jun 2004 14:36:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OIRkjo083633; Thu, 24 Jun 2004 11:27:46 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OIRkjb083632; Thu, 24 Jun 2004 11:27:46 -0700 (PDT) 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.9) with ESMTP id i5OIRk82083626 for ; Thu, 24 Jun 2004 11:27:46 -0700 (PDT) (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 i5OIRnuP014358 for ; Thu, 24 Jun 2004 11:27:49 -0700 (PDT) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 24 Jun 2004 11:27:49 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: ietf-mxcomp@imc.org Subject: RE: ASN.1 as encoding (was: Designing and Allocating a new RR typ e) Date: Thu, 24 Jun 2004 11:27:42 -0700 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: > > - ASN.1 encoded data only > > - ASN.1 tagged with a OID for unambigous identification > > of the content type > > Hmm, people are discussing possible security problems due to the > use of XML. What about ASN.1? It seems that writing a parser for > it is not trivial; just look at some OpenSSL security advisories: > > o Security: fix vulnerabilities in ASN.1 parsing > CAN-2003-0543, CAN-2003-0544 > [0.9.7c & 0.9.6k] > o Security: fix additional vulnerability in ASN.1 parsing > CAN-2003-0545 > [0.9.7c] ASN.1 was a great idea and a completely botched design. Worst of all was the DER encoding lunacy which meant that encoding a data set is impossible until the whole data set is available. It is not possible to stream data through an ASN.1 encoder. The DER encoding in X.509 was a bad, bad bad mistake. It please the idiots who thought that C18N was relevant to certs, it is not as is proven by the fact that for years VeriSign certs were not DER encoded. ASN.1 is also much worse than XML in that you cannot understand the data at any level unless you have access to the schema. If ASN.1 had not been botched so badly there would have been no need for XML. ASN.1 put back the widespread use of crypto more than any other factor. Yes I have written ASN.1 encoders and decoders. From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 15:57:44 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22400 for ; Thu, 24 Jun 2004 15:57:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OJoLRL091711; Thu, 24 Jun 2004 12:50:21 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OJoLEP091710; Thu, 24 Jun 2004 12:50:21 -0700 (PDT) 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.9) with ESMTP id i5OJoGn8091701 for ; Thu, 24 Jun 2004 12:50:21 -0700 (PDT) (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 i5OJo8h2007663; Thu, 24 Jun 2004 21:50:08 +0200 Received: from danisch.de (localhost [127.0.0.1]) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-5) with ESMTP id i5OJjCh9017243; Thu, 24 Jun 2004 21:45:12 +0200 Message-ID: <40DB2F48.20700@danisch.de> Date: Thu, 24 Jun 2004 21:45:12 +0200 From: Hadmut Danisch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040528 Debian/1.6-7 X-Accept-Language: de-de MIME-Version: 1.0 To: "Eric A. Hall" CC: ietf-mxcomp@imc.org Subject: Re: Designing and Allocating a new RR type References: <40DB0187.7030204@danisch.de> <40DB1AB9.5030904@ehsco.com> In-Reply-To: <40DB1AB9.5030904@ehsco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Eric A. Hall wrote: >I think that the idea of using ASN.1 is fine as an architectural point >(DNS certainly suffers from a lack of strict data-typing), but it's >overkill for what we need, while the implementation and potential exploit >problems are on par with XML. So I don't think we should use it for this >specific RR. Too much work for too little gain. > > I don't see how ASN.1 should be any more exploitable than SPF. You have a strict set of data types, one-byte-tags and length fields. Even if there were a few bugs in implementations, there were bugs in any kind of software. Are SPF parsers free of bugs by design? Or parsers for other binary formats? Why should writing a new thing from scratch be more safe than e.g. using existing ASN.1/DER parser generators? I believe ASN.1 parsers will be less overhead than SPF due to a small set of well defined data types. Significant fewer cases to handle. Less string operations. Existing tools to check and proofread the structure. On linux there is an asn1dump program, which dumps any ASN.1 structure (if not too much use of IMPLICIT was made). How much overhead is it to have a syntax checker for SPF? Before I got that asn1dump program, I wrote a similar program on my own from scratch. Straigth forward work, rather simple. Much easier than writing an SPF or XML parser. The only disadvantage about ASN.1 is that the existing books about it make it look much more complicated than in actually is. And I believe it is a good design decision to not have a new proprietary encoding for every RR type, but to start using generic standard encoding, as done with e.g. LDAP. >Remember that every ~100 bytes of RR data is roughly the same as whatever >was cached from PTR/A/NS lookups, and saving ~30% or so on that is a good >enough target, so getting to ~70 bytes per RR is really what we should be >looking to reasonably achieve. > > Isn't this a strong argument for ASN.1? DER can be quite compact. I admit that with ASN.1/DER you have two different styles: Have everything tagged and make things a little bit bigger (without using IMPLICIT), or make use of IMPLICIT, omit the tags were redundant, and get a very small and compact encoding, were a parser must know the data structure. But I think having that choice is an advantage, not a disadvantage. ASN.1/DER is well proven. It is used for X.509, SNMP, LDAP, Kerberos V5, ... were they roughly have the same requirements as we have them here. Why should we make a different choice? >If the scope of data is limited, it will probably be good enough to have >coded types and textual field data within the limited subset of types. > > > OK, make a proposal. But I still believe that textual field data is a disadvantage: MARID records will in >99% not be read directly by humans, but interpreted by machines. What is better: Storing IP addresses in decimal ASCII dot notation, and have every machine convert it every time, or to store it as binary in network order? And if read by humans, the DNS records are subject to decoding anyway. regards Hadmut From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 16:05:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23180 for ; Thu, 24 Jun 2004 16:05:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OJuqKe092111; Thu, 24 Jun 2004 12:56:52 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OJuqFY092110; Thu, 24 Jun 2004 12:56:52 -0700 (PDT) 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.9) with ESMTP id i5OJuqcZ092103 for ; Thu, 24 Jun 2004 12:56:52 -0700 (PDT) (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 AE88E133584; Thu, 24 Jun 2004 15:56:55 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 8D32E69C; Thu, 24 Jun 2004 15:56:55 -0400 (EDT) Date: Thu, 24 Jun 2004 15:56:55 -0400 From: Meng Weng Wong To: Roy Badami Cc: "'IETF MARID WG'" Subject: Re: Unified SPF: block versus factored records for HELO and MTAMAarkscopes Message-ID: <20040624195655.GL13225@dumbo.pobox.com> References: <20040624144946.GI13225@dumbo.pobox.com> <1a44201c45a03$6f0e0cd0$6e82820a@mailgatejd> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1a44201c45a03$6f0e0cd0$6e82820a@mailgatejd> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Jun 24, 2004 at 05:53:46PM +0200, Roy Badami wrote: | | But, AIUI, CSV in it's current incarnation involves doing an SRV | lookup on the domain name; how is this more heavyweight than doing a | TXT lookup. CSV looks just as cacheable to me as SPF, but uses more | compact records... | OK, if CSV's authentication procedure is "does an A lookup on the HELO name describe the client IP" then yes, it is just as cacheable. If an ISP wants to set a policy where it always says HELO isp.com instead of HELO mx-1.isp.com HELO mx-2.isp.com HELO mx-3.isp.com then the CSV authentication procedure may not be sufficient. From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 16:47:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02744 for ; Thu, 24 Jun 2004 16:47:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OKcWLQ096345; Thu, 24 Jun 2004 13:38:32 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OKcWtS096344; Thu, 24 Jun 2004 13:38:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OKcVah096338 for ; Thu, 24 Jun 2004 13:38:31 -0700 (PDT) (envelope-from roy+dated+1090701513.0794ae@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i5OKcXlK083919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 24 Jun 2004 20:38:34 GMT (envelope-from roy+dated+1090701513.0794ae@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5OKcY7A016799 for ; Thu, 24 Jun 2004 21:38:34 +0100 (BST) (envelope-from roy+dated+1090701513.0794ae@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5OKcYWr016794 for ietf-mxcomp@imc.org; Thu, 24 Jun 2004 21:38:34 +0100 (BST) (envelope-from roy+dated+1090701513.0794ae@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Thu, 24 Jun 2004 21:38:33 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16603.15304.572135.668380@giles.gnomon.org.uk> Date: Thu, 24 Jun 2004 21:38:32 +0100 To: Meng Weng Wong Cc: Roy Badami , "'IETF MARID WG'" Subject: Re: Unified SPF: block versus factored records for HELO and MTAMAarkscopes In-Reply-To: <20040624195655.GL13225@dumbo.pobox.com> References: <20040624144946.GI13225@dumbo.pobox.com> <1a44201c45a03$6f0e0cd0$6e82820a@mailgatejd> <20040624195655.GL13225@dumbo.pobox.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Meng" == Meng Weng Wong writes: Meng> OK, if CSV's authentication procedure is "does an A lookup Meng> on the HELO name describe the client IP" then yes, it is Meng> just as cacheable. No, an SRV lookup on the HELO (then an A lookup on the result of that). I think it works like an SPF record containing a single 'a' mechanism. Meng> If an ISP wants to set a policy where it always says Meng> HELO isp.com Meng> instead of Meng> HELO mx-1.isp.com HELO mx-2.isp.com HELO mx-3.isp.com Meng> then the CSV authentication procedure may not be sufficient. Normally you'd be expected to have something like: mx-1.isp.com. IN A 1.1.1.1 mx-2.isp.com. IN A 2.2.2.2 mx-3.isp.com. IN A 3.3.3.3 _client._smtp.mx-1.isp.com. IN SRV 1 2 mx-1.isp.com. _client._smtp.mx-2.isp.com. IN SRV 1 2 mx-2.isp.com. _client._smtp.mx-3.isp.com. IN SRV 1 2 mx-3.isp.com. But if you really want to use HELO isp.com, then in CSA I think it is mx-1.isp.com. IN A 1.1.1.1 mx-2.isp.com. IN A 2.2.2.2 mx-3.isp.com. IN A 3.3.3.3 _client._smtp.isp.com. IN SRV 1 2 mx-list.isp.com. mx-list.isp.com. IN A 1.1.1.1 IN A 2.2.2.2 IN A 3.3.3.3 Though the A record could end up getting big for a large ISP -- I think the draft makes the point that ISPs may wish to change their HELO strings to avoid saying HELO isp.com -roy From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 16:57:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09064 for ; Thu, 24 Jun 2004 16:57:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OKnVfM097281; Thu, 24 Jun 2004 13:49:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OKnVpU097280; Thu, 24 Jun 2004 13:49:31 -0700 (PDT) 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.9) with ESMTP id i5OKnUNk097274 for ; Thu, 24 Jun 2004 13:49:31 -0700 (PDT) (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 1E912133586; Thu, 24 Jun 2004 16:49:33 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id DA735607; Thu, 24 Jun 2004 16:49:33 -0400 (EDT) Date: Thu, 24 Jun 2004 16:49:33 -0400 From: Meng Weng Wong To: Roy Badami Cc: "'IETF MARID WG'" Subject: Re: Unified SPF: CSV explained Message-ID: <20040624204933.GM13225@dumbo.pobox.com> References: <20040624144946.GI13225@dumbo.pobox.com> <1a44201c45a03$6f0e0cd0$6e82820a@mailgatejd> <20040624195655.GL13225@dumbo.pobox.com> <16603.15304.572135.668380@giles.gnomon.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16603.15304.572135.668380@giles.gnomon.org.uk> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Jun 24, 2004 at 09:38:32PM +0100, Roy Badami wrote: | | No, an SRV lookup on the HELO (then an A lookup on the result of that). | | I think it works like an SPF record containing a single 'a' mechanism. | | Normally you'd be expected to have something like: | | mx-1.isp.com. IN A 1.1.1.1 | mx-2.isp.com. IN A 2.2.2.2 | mx-3.isp.com. IN A 3.3.3.3 | | _client._smtp.mx-1.isp.com. IN SRV 1 2 mx-1.isp.com. | _client._smtp.mx-2.isp.com. IN SRV 1 2 mx-2.isp.com. | _client._smtp.mx-3.isp.com. IN SRV 1 2 mx-3.isp.com. If this is true, then CSV is logically equivalent to a block record, and my comments about factored records are not relevant. More relevant is my suggestion that doing an SPF lookup against the HELO name can offer the same semantics. Which one is more lightweight becomes a question of whether you already have an SPF library at hand :) From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 18:03:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17059 for ; Thu, 24 Jun 2004 18:03:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OLqeMY004406; Thu, 24 Jun 2004 14:52:40 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OLqeQ6004405; Thu, 24 Jun 2004 14:52:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail1.yozons.com (mail1.yozons.com [206.80.109.179]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OLqdha004399 for ; Thu, 24 Jun 2004 14:52:40 -0700 (PDT) (envelope-from d.wall@computer.org) Received: from rasta (soho2.yozons.com [206.80.109.178] (may be forged)) (authenticated bits=0) by mail1.yozons.com (8.12.8/8.12.8) with ESMTP id i5OLqiX5017168 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 24 Jun 2004 14:52:44 -0700 Message-ID: <0aec01c45a35$531295f0$3201a8c0@rasta> Reply-To: "David Wall" From: "David Wall" To: Subject: Sender identification is not the answer Date: Thu, 24 Jun 2004 14:50:54 -0700 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.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit The problem I have with sender-authentication schemes is they are coverting an open, useful, free and unfettered email solution into something only Big Brother and Big Corporations would ever want. Already, my home ISP blocks sending out emails using my business email address -- because I could be a spammer! People in totalitarian regimes have relied on anonymity in order to share information. Those who squeal on corruption, discuss serious political issues, or simply want to discuss sensitive items without being identified will lose a useful tool at the bequest of businesses. Like the war on terror, this war on spam is causing us to lose focus and make the assumption that the solution is to punish everyone, restrict everyone's freedom, and monitor everyone's actions since we may all be spammers. Back in 1992, I didn't have any spam problems, and big business hadn't yet adopted email for its business communications. Spam has grown with business use, and now businesses are telling us that we all have to change and suffer because of the mess they created. This is not fair, and it won't even work. An AOL employee has just been arrested for selling customer information to spammers, and all ISPs have long had this problem (how long did it take for you to receive your first spam with your new email account?). Businesses should instead leave the free email paradigm and return to a private, secure channel for their communications. You get what you pay for, and email has always been insecure, and these schemes don't even solve that problem. There are already commercial services like Yozons, CertifiedMail, Zixit and Tumbleweed that offer secure messaging in a professional manner. Corporations should stop using free email if they want to remain legitimate, just like they don't contact us over CB radios or via bulletin boards. To stop spammers, we need to educate users that they shouldn't ever buy anything sent to them via email because legitimate businesses don't sell their products this way. They shouldn't click on links in email and they shouldn't open attachments. They should realize that email is insecure and provides no confidentialitity like traditional mail, despite the similar sounding name. Such information could be provided with every new computer and every new ISP account. To stop spammers, we need to buy their products and then follow the money until they are arrested. Given a $25,000 per convicted spammer prize, along with a $50,000 per conviction penalty to help pay for it, I'm sure spammers would be given up quickly. They are not an honest lot and are always looking to make a buck off the pain of others. To stop spammers, Microsoft needs to fix its Outlook and Outlook Express so that reading an email cannot trigger any actions. There's no reason why a data email should ever be executable and send out more emails without your knowledge. Only a fool would have programmed such a "feature" in. Anyway, the idea is that monitoring all of our email activity and forcing us into narrow uses for email is not the answer. Email wants to be free. The Internet servers more than corporate interests and certainly more than U.S. interests. Businesses should leave and use trusted delivery systems from private providers before they should require that we lose our rights. Sincerely, David Wall From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 18:35:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22571 for ; Thu, 24 Jun 2004 18:35:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OMS2HX008338; Thu, 24 Jun 2004 15:28:02 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5OMS2DT008337; Thu, 24 Jun 2004 15:28:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5OMS1Rt008331 for ; Thu, 24 Jun 2004 15:28:01 -0700 (PDT) (envelope-from roy+dated+1090708084.8432b9@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i5OMS5SW056297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 24 Jun 2004 22:28:05 GMT (envelope-from roy+dated+1090708084.8432b9@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5OMS4rG018296 for ; Thu, 24 Jun 2004 23:28:04 +0100 (BST) (envelope-from roy+dated+1090708084.8432b9@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5OMS4Hm018295 for ietf-mxcomp@imc.org; Thu, 24 Jun 2004 23:28:04 +0100 (BST) (envelope-from roy+dated+1090708084.8432b9@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Thu, 24 Jun 2004 23:28:03 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16603.21874.944087.268804@giles.gnomon.org.uk> Date: Thu, 24 Jun 2004 23:28:02 +0100 To: "David Wall" Cc: Subject: Sender identification is not the answer In-Reply-To: <0aec01c45a35$531295f0$3201a8c0@rasta> References: <0aec01c45a35$531295f0$3201a8c0@rasta> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "David" == David Wall writes: David> The problem I have with sender-authentication schemes is David> they are coverting an open, useful, free and unfettered David> email solution into something only Big Brother and Big David> Corporations would ever want. The problem is that if we outlaw forging mail, then we won't be able to forge mail anymore (this was put somewhat more succinctly by someone else, but I can't remember the quote). David> Already, my home ISP blocks sending out emails using my David> business email address -- because I could be a spammer! With any MARID/LMAP scheme, your business has a choice. It can restrict mail to being sent from its servers, or it can allow mail to be sent from any server. No-one is forcing your business to publish a policy that says its mail only comes from its servers; MARID/LMAP gives your business the _choice_ of publishing such a policy. If it chooses to do so, then recipients of mail claiming to be from your business can evaluate that mail against the policy. -roy From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 19:40:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01770 for ; Thu, 24 Jun 2004 19:40:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ONPt0G012333; Thu, 24 Jun 2004 16:25:55 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5ONPt1Y012332; Thu, 24 Jun 2004 16:25:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.mail-abuse.org [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ONPtpL012326 for ; Thu, 24 Jun 2004 16:25:55 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.mail-abuse.org (DDev.mail-abuse.org [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id D7EB3414B5; Thu, 24 Jun 2004 16:26:00 -0700 (PDT) Subject: Re: Sender identification is not the answer From: Douglas Otis To: David Wall Cc: MARID In-Reply-To: <0aec01c45a35$531295f0$3201a8c0@rasta> References: <0aec01c45a35$531295f0$3201a8c0@rasta> Content-Type: text/plain Message-Id: <1088119560.24714.93.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 24 Jun 2004 16:26:00 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2004-06-24 at 14:50, David Wall wrote: > The problem I have with sender-authentication schemes is they are coverting > an open, useful, free and unfettered email solution into something only Big > Brother and Big Corporations would ever want. With the Fenton "Identified-Mail" proposal, sender identification is an option. It is independent of the mail channel and may take place at the mail user agent (MUA) without loss of integrity. This places no restrictions on mail while individuals and corporations alike may quickly implement this method to identify themselves without investing in third-party certificates. This feature is a function of the MUA and can happen tomorrow without any standards enacted, although standards in this area would be beneficial if this is to be widely accepted. There are thousands of mail providers requiring no identification, nor do any MARID proposals curtail this desirable freedom by respecting economies that enable this service. The goal is to curtail the abuse that increases costs that will eventually constrain this freedom. The CSV-HNA-CSA approach attempts to identify domains submitting mail to enable evaluation and follow-up as a means to curtail these costs. Much of this abuse happens over commandeered systems where owners remain oblivious to the subversion of their system. If these systems are forced to identify themselves, this highly criminal act will likely be thwarted. It is a small price where most users will be unaware anything has changed. By ridding the system of those that are largely perpetuating scams and outright theft, the freedom afford mail is preserved. Making it legally required for those that advertise to use the "Identified-Mail" mechanism would further curtail scams based on identity fraud as it would provide verified mail addresses. -Doug From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 19:43:13 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02007 for ; Thu, 24 Jun 2004 19:43:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ONW25h012696; Thu, 24 Jun 2004 16:32:02 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5ONW256012695; Thu, 24 Jun 2004 16:32:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail1.yozons.com (mail1.yozons.com [206.80.109.179]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ONW2Xu012689 for ; Thu, 24 Jun 2004 16:32:02 -0700 (PDT) (envelope-from d.wall@computer.org) Received: from rasta (soho2.yozons.com [206.80.109.178] (may be forged)) (authenticated bits=0) by mail1.yozons.com (8.12.8/8.12.8) with ESMTP id i5ONW1X5017739 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 24 Jun 2004 16:32:01 -0700 Message-ID: <0c3401c45a43$31ce2a40$3201a8c0@rasta> Reply-To: "David Wall" From: "David Wall" To: "Roy Badami" Cc: References: <0aec01c45a35$531295f0$3201a8c0@rasta> <16603.21874.944087.268804@giles.gnomon.org.uk> Subject: Re: Sender identification is not the answer Date: Thu, 24 Jun 2004 16:30:11 -0700 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.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Thanks, Roy, for your comments. > The problem is that if we outlaw forging mail, then we won't be able > to forge mail anymore (this was put somewhat more succinctly by > someone else, but I can't remember the quote). I understand the general sentiment here, but anonymity is useful to a great many people, including people who live in countries in which their governments will use such "well identified" messages against them. In the U.S., the Patriot Act already gives greater reason to suspect someone, monitor them, search their premises, records and emails, and the need for a court order has been greatly diminished. People like to provide tips of suspected activities, blow the whistle on others, etc., and they don't want to be so identified. We'll lose the simplicity of the "pay phone" for making an anonymous call. Besides, as I said, if people WANT such a well authenticated system, they could purchase one today from various vendors who offer just such systems. There's no reason to break email for everyone else. Email is pretty old, and the spam problem is only recent because businesses have adopted this free technology and now want the rest of us to convert to their whims and needs. Also, some people just like to participate in discussions like this one without having to identify themselves further. In fact, this list is rather funny because it sends out messages "on behalf of others," yet if the mail gurus at gnomon.org.uk decided that you could only send through their servers, then you wouldn't even be able to participate in this discussion. I'm using a computer.org account from IEEE, and the same problem would arise from them. > With any MARID/LMAP scheme, your business has a choice. It can > restrict mail to being sent from its servers, or it can allow mail to > be sent from any server. > > No-one is forcing your business to publish a policy that says its mail > only comes from its servers; MARID/LMAP gives your business the > _choice_ of publishing such a policy. If it chooses to do so, then > recipients of mail claiming to be from your business can evaluate that > mail against the policy. That sounds fine, but that's like having a "moment of silence" in Muslim schools attended by Christians and athiests, and then expecting those who don't want to pray to somehow now comply when others around them look on in disapproval. Clearly, the result will be that major ISPs will block email coming from non-authenticated systems, thus making email less useful to those who don't join the club. My company will never say that you can send email using their emails from anywhere -- should they adopt SPF or the like -- because it would imply they endorse spammers. But they also won't take the time to list each employee's home ISP. Besides, most ISPs are blocking this already, so it's not about sender authentication, it's about blocking emails being sent using addresses they don't approve of. The rush to stop spam is stopping legitimate business communications. This seems to me to be more about upping the arms race as the spammers react to these new proposals by hijacking users accounts (and falsely making it seem like the "zombie" victim has authenticated himself and thus will likely be more legally liable for those spams even though he was just a victim), or they will hijack DNS. Why do we want to keep on tacking on small things that never address the real problem? Spam can be stopped simply by educating users not to buy things from spammers. Businesses can move off of free email and grow up and pay for quality services that aren't tainted by spammers, so people no longer expect to receive anything of value through email marketing efforts (you would be suspicious of your bank contacting you over a walkie-talkie, ham radio or CB radio, right?). Legal folks could actually start tracking down spammers by buying the products and following the money and then arresting them (it's already illegal). Heck, we don't have to identify ourselves to mail a letter, why should we have to just to send an email? David From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 19:52:01 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03648 for ; Thu, 24 Jun 2004 19:52:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ONhrga013975; Thu, 24 Jun 2004 16:43:53 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5ONhrHS013974; Thu, 24 Jun 2004 16:43:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail1.yozons.com (mail1.yozons.com [206.80.109.179]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ONhqni013960 for ; Thu, 24 Jun 2004 16:43:52 -0700 (PDT) (envelope-from d.wall@computer.org) Received: from rasta (soho2.yozons.com [206.80.109.178] (may be forged)) (authenticated bits=0) by mail1.yozons.com (8.12.8/8.12.8) with ESMTP id i5ONhtX5017803 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 24 Jun 2004 16:43:55 -0700 Message-ID: <0c4401c45a44$db8810e0$3201a8c0@rasta> Reply-To: "David Wall" From: "David Wall" To: "Douglas Otis" Cc: "MARID" References: <0aec01c45a35$531295f0$3201a8c0@rasta> <1088119560.24714.93.camel@ddev.mail-abuse.org> Subject: Re: Sender identification is not the answer Date: Thu, 24 Jun 2004 16:42:05 -0700 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.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Thanks, Douglas for your comments. > There are thousands of mail providers requiring no identification, nor > do any MARID proposals curtail this desirable freedom by respecting > economies that enable this service. The goal is to curtail the abuse > that increases costs that will eventually constrain this freedom. The > CSV-HNA-CSA approach attempts to identify domains submitting mail to > enable evaluation and follow-up as a means to curtail these costs. As I said before, I don't believe this because all email that doesn't have this identification stamp will be assumed to be suspect over time. In the U.S., you can walk around with carrying identification. If businesses all of a sudden (and they won't because it's bad business, just like this is bad for email) started requiring identification to enter a store since it would help them with theft issues, but said you don't have to have ID, you would find that people would start showing their ID just to avoid being followed everywhere they went in the store. The same will happen here in which all non-authenticated email will be suspicious, will be further analyzed and review, and will likely be tossed out in the fear of preventing spam. > Much of this abuse happens over commandeered systems where owners remain > oblivious to the subversion of their system. If these systems are > forced to identify themselves, this highly criminal act will likely be > thwarted. Except that the commandeered systems will simply send messages out using email addresses from the commandeered domain, so they will all carry the legitimacy of authentication (and the legal exposure) but will still be criminal. > It is a small price where most users will be unaware anything > has changed. By ridding the system of those that are largely > perpetuating scams and outright theft, the freedom afford mail is > preserved. Making it legally required for those that advertise to use > the "Identified-Mail" mechanism would further curtail scams based on > identity fraud as it would provide verified mail addresses. It's already illegal to send spam, and rather than try to force identification on everyone, why not try to prosecute the criminals today. Note that the U.S. can spend over a billion per week to invade Iraq, but apparently cannot even hope to prosecute a few spammers per week. Let's face it, a spammer has to send out lots of messages to lots of people, already making himself more apparent. Next, he has to advertise products and collect money, making it even easier to track down the criminal. Sure, many will be overseas, but if governments cannot cooperate to track down criminals, why do we think the world will cooperate on a sender identification scheme for email? For any solution to be useful, it will have to be accepted widely, which means changes to lots of SMTP servers. All of these changes are simply not necessary if we train users how to avoid being victimized by spammers (every pack of cigarettes contains a warning, but every computer and ISP account is sold without any such warnings), businesses discontinue using email for sensitive communications as they rightly should, and we start enforcing the laws that already exist. David From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 20:01:57 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04455 for ; Thu, 24 Jun 2004 20:01:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ONsWm2014601; Thu, 24 Jun 2004 16:54:32 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5ONsWKw014600; Thu, 24 Jun 2004 16:54:32 -0700 (PDT) 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.9) with ESMTP id i5ONsV7h014594 for ; Thu, 24 Jun 2004 16:54:31 -0700 (PDT) (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 A969F13358C; Thu, 24 Jun 2004 19:54:33 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 7949363A; Thu, 24 Jun 2004 19:54:33 -0400 (EDT) Date: Thu, 24 Jun 2004 19:54:33 -0400 From: Meng Weng Wong To: David Wall Cc: MARID Subject: Re: Sender identification is not the answer Message-ID: <20040624235433.GN13225@dumbo.pobox.com> References: <0aec01c45a35$531295f0$3201a8c0@rasta> <1088119560.24714.93.camel@ddev.mail-abuse.org> <0c4401c45a44$db8810e0$3201a8c0@rasta> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0c4401c45a44$db8810e0$3201a8c0@rasta> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: While these inputs are very important, probably more important in the grand scheme of things than some of the technical discussions we've seen over the last few weeks, I believe this discussion is unfortunately out of scope for our WG. You might find a more receptive forum at ASRG. http://asrg.sp.am/ The job of this working group is to produce proposals that you may find philosophically unpalatable, but if you want to campaign against these concepts your best course of action may be to contact John Gilmore and the EFF. cheers meng On Thu, Jun 24, 2004 at 04:42:05PM -0700, David Wall wrote: | | As I said before, I don't believe this because all email that doesn't have | this identification stamp will be assumed to be suspect over time. In the | U.S., you can walk around with carrying identification. From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 20:15:27 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06590 for ; Thu, 24 Jun 2004 20:15:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5P07EeA015272; Thu, 24 Jun 2004 17:07:14 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5P07EDi015271; Thu, 24 Jun 2004 17:07:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail1.yozons.com (mail1.yozons.com [206.80.109.179]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5P07Da6015265 for ; Thu, 24 Jun 2004 17:07:14 -0700 (PDT) (envelope-from d.wall@computer.org) Received: from rasta (soho2.yozons.com [206.80.109.178] (may be forged)) (authenticated bits=0) by mail1.yozons.com (8.12.8/8.12.8) with ESMTP id i5P07EX5017940 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 24 Jun 2004 17:07:14 -0700 Message-ID: <0c8c01c45a48$1d74de40$3201a8c0@rasta> Reply-To: "David Wall" From: "David Wall" To: "Meng Weng Wong" Cc: References: <0aec01c45a35$531295f0$3201a8c0@rasta> <1088119560.24714.93.camel@ddev.mail-abuse.org> <0c4401c45a44$db8810e0$3201a8c0@rasta> <20040624235433.GN13225@dumbo.pobox.com> Subject: Re: Sender identification is not the answer Date: Thu, 24 Jun 2004 17:05:24 -0700 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.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Thanks. ASRG does look promising. Sorry for having bothered, though I'm not surprised that SPF-charged Pobox people would think otherwise and follow an "identify everyone" philosophy over freedom! It's worked so well in those countries that authenticate their citizens whenever possible... It was not my intent to post to an incorrect list, though I do hope that your proposals are mired in politics, quibbles, legal onslaughts, technical challenges and poor adoption. Best regards, David ----- Original Message ----- From: "Meng Weng Wong" To: "David Wall" Cc: "MARID" Sent: Thursday, June 24, 2004 4:54 PM Subject: Re: Sender identification is not the answer > > While these inputs are very important, probably more > important in the grand scheme of things than some of the > technical discussions we've seen over the last few weeks, I > believe this discussion is unfortunately out of scope for > our WG. You might find a more receptive forum at ASRG. > > http://asrg.sp.am/ > > The job of this working group is to produce proposals that > you may find philosophically unpalatable, but if you want to > campaign against these concepts your best course of action > may be to contact John Gilmore and the EFF. > > cheers > meng From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 20:21:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06726 for ; Thu, 24 Jun 2004 20:21:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5P0D4X3015871; Thu, 24 Jun 2004 17:13:04 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5P0D3g7015870; Thu, 24 Jun 2004 17:13:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.mail-abuse.org [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5P0D3Um015859 for ; Thu, 24 Jun 2004 17:13:03 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.mail-abuse.org (DDev.mail-abuse.org [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id 8A22D414B5; Thu, 24 Jun 2004 17:13:06 -0700 (PDT) Subject: Re: Sender identification is not the answer From: Douglas Otis To: David Wall Cc: MARID In-Reply-To: <0c4401c45a44$db8810e0$3201a8c0@rasta> References: <0aec01c45a35$531295f0$3201a8c0@rasta> <1088119560.24714.93.camel@ddev.mail-abuse.org> <0c4401c45a44$db8810e0$3201a8c0@rasta> Content-Type: text/plain Message-Id: <1088122386.24714.120.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 24 Jun 2004 17:13:06 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2004-06-24 at 16:42, David Wall wrote: > Thanks, Douglas for your comments. > > > There are thousands of mail providers requiring no identification, nor > > do any MARID proposals curtail this desirable freedom by respecting > > economies that enable this service. The goal is to curtail the abuse > > that increases costs that will eventually constrain this freedom. The > > CSV-HNA-CSA approach attempts to identify domains submitting mail to > > enable evaluation and follow-up as a means to curtail these costs. > > As I said before, I don't believe this because all email that doesn't have > this identification stamp will be assumed to be suspect over time. It would not be the mail message examined with CSV-HNA-CSA. It would be the domain handling the mail stream. This is different with respect to SPF/CID. > > Much of this abuse happens over commandeered systems where owners remain > > oblivious to the subversion of their system. If these systems are > > forced to identify themselves, this highly criminal act will likely be > > thwarted. > > Except that the commandeered systems will simply send messages out using > email addresses from the commandeered domain, so they will all carry the > legitimacy of authentication (and the legal exposure) but will still be > criminal. Having these systems identify themselves in this manner, there would be an account for the domain to be examined. Currently there is nothing to allow ready enforcement. These domains would be quickly blacklisted requiring these individuals to repeatedly expose themselves creating more accounts. It may well be these individuals go unprosecuted, but costs of this activity will have been raised with less collateral damage as compared to blocking IP addresses or allowing the abuse to continue unabated. -Doug From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 20:28:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07618 for ; Thu, 24 Jun 2004 20:28:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5P0NEs8016424; Thu, 24 Jun 2004 17:23:14 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5P0NEiX016423; Thu, 24 Jun 2004 17:23:14 -0700 (PDT) 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.9) with ESMTP id i5P0ND3j016417 for ; Thu, 24 Jun 2004 17:23:13 -0700 (PDT) (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 i5P0NIV5016985 for ; Thu, 24 Jun 2004 17:23:18 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 24 Jun 2004 17:23:18 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: MARID Subject: RE: Sender identification is not the answer Date: Thu, 24 Jun 2004 17:23:12 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The problem of spam is due to a lack of accountability. At the dawn of the Internet you could be thrown off for starting a discussion list about wine (according to Dertusos). The question is at what level is that accountability to be applied? Certainly not the individual user, and it is only the individual who has either the right to or expectation of privacy. There is no problem here. It is the parties that provide connectivity to the Internet that are to be held accountable, not the individual. All email requires authentication. Genuinely anonymous email goes straight into my bit bucket via that spam filter. Nobody accepts anonymous email, never did, never will. Email that is authenticated to a psudeonym is not anonymous. From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 20:32:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08093 for ; Thu, 24 Jun 2004 20:32:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5P0Mncx016406; Thu, 24 Jun 2004 17:22:49 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5P0Mn6Q016405; Thu, 24 Jun 2004 17:22:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [64.139.47.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5P0MnDb016399 for ; Thu, 24 Jun 2004 17:22:49 -0700 (PDT) (envelope-from gconnor@nekodojo.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by neko-base.nekodojo.org (Postfix) with ESMTP id 8964F1D651 for ; Thu, 24 Jun 2004 17:22:52 -0700 (PDT) Date: Thu, 24 Jun 2004 17:22:54 -0700 From: Greg Connor To: ietf-mxcomp@imc.org Subject: Re: Sender identification is not the answer Message-ID: <25081505.1088097773@Ryoga.corp.sgi.com> In-Reply-To: <0c8c01c45a48$1d74de40$3201a8c0@rasta> References: <0c8c01c45a48$1d74de40$3201a8c0@rasta> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --David Wall wrote: > > Thanks. ASRG does look promising. Sorry for having bothered, though I'm > not surprised that SPF-charged Pobox people would think otherwise and > follow an "identify everyone" philosophy over freedom! It's worked so > well in those countries that authenticate their citizens whenever > possible... > > It was not my intent to post to an incorrect list, though I do hope that > your proposals are mired in politics, quibbles, legal onslaughts, > technical challenges and poor adoption. These comments are also out of scope and wildly inappropriate. > Best regards, > David > "Cheerfully yours," gregc -- Greg Connor From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 21:40:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12146 for ; Thu, 24 Jun 2004 21:40:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5P1WavJ023072; Thu, 24 Jun 2004 18:32:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5P1WaxZ023071; Thu, 24 Jun 2004 18:32:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (ftp.catinthebox.net [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5P1WZq3023063 for ; Thu, 24 Jun 2004 18:32:35 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Thu, 24 Jun 2004 21:36:20 -0400 Received: from ([68.223.169.60]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 1938027829; Thu, 24 Jun 2004 21:36:19 -0400 Message-ID: <005001c45a55$5d6078e0$6401a8c0@hdev1> From: "Hector Santos" To: "Meng Weng Wong" , "David Wall" Cc: "MARID" References: <0aec01c45a35$531295f0$3201a8c0@rasta> <1088119560.24714.93.camel@ddev.mail-abuse.org> <0c4401c45a44$db8810e0$3201a8c0@rasta> <20040624235433.GN13225@dumbo.pobox.com> Subject: Re: Sender identification is not the answer Date: Thu, 24 Jun 2004 21:40:11 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.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: Content-Transfer-Encoding: 7bit Mr. Wong, Sender-ID is horrible and it will alter the landscape since Microsoft is the author and hence, promotor. I'm so disturbed by all this, I will begin to inform the FCC, the Media and all that have the power to get this stop before it gets started. I've been in the mail business in every aspect, far longer than you and I only say that because it is extremely disturbing that all this is being ignored. If this proposal was from any other author, but Microsoft, it wouldn't see any consideration whatsoever. But we are talking Microsoft here. It will alter the landscape in more ways that anyone anticipated. Sender ID conflicts with many of the US ECPA provisions. There doesn't seem to be much thought put into to see if it passes the legal muster. SenderID is not a reliable concept and it promotes the obstruction of mail delivery and it promotes local policies to be applied at the wrong part of the mail operation. It promote post acceptance Local Policies rejections ideas for any discriminatory whims beyond spam. Where do you think "local policies" evolved from anyway? Not because it was a "neat" idea. It all began with te 1986 US ECPA provisions to help address mail delivery obstruction, mail tampering and privacy issues. I'm not just blurting this out. It has many legal issues. I urge people to review at how this concept of requiring mail to be accepted by SMTP for delayed rejection on unreliable concepts and then leave it for Local Policies to decide. We might kill spam, but will might be killing and severely changing the reliability of the mail network just as well. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com ----- Original Message ----- From: "Meng Weng Wong" To: "David Wall" Cc: "MARID" Sent: Thursday, June 24, 2004 7:54 PM Subject: Re: Sender identification is not the answer > > While these inputs are very important, probably more > important in the grand scheme of things than some of the > technical discussions we've seen over the last few weeks, I > believe this discussion is unfortunately out of scope for > our WG. You might find a more receptive forum at ASRG. > > http://asrg.sp.am/ > > The job of this working group is to produce proposals that > you may find philosophically unpalatable, but if you want to > campaign against these concepts your best course of action > may be to contact John Gilmore and the EFF. > > cheers > meng > > On Thu, Jun 24, 2004 at 04:42:05PM -0700, David Wall wrote: > | > | As I said before, I don't believe this because all email that doesn't have > | this identification stamp will be assumed to be suspect over time. In the > | U.S., you can walk around with carrying identification. > > From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 23:30:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18303 for ; Thu, 24 Jun 2004 23:30:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5P3KK1D030035; Thu, 24 Jun 2004 20:20:20 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5P3KK7n030034; Thu, 24 Jun 2004 20:20:20 -0700 (PDT) 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.9) with ESMTP id i5P3KKe9030028 for ; Thu, 24 Jun 2004 20:20:20 -0700 (PDT) (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 i5P3KQqD026767 for ; Thu, 24 Jun 2004 20:20:26 -0700 (PDT) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 24 Jun 2004 20:20:26 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: MARID Subject: RE: Sender identification is not the answer Date: Thu, 24 Jun 2004 20:20:17 -0700 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: > Mr. Wong, > > Sender-ID is horrible and it will alter the landscape since > Microsoft is the > author and hence, promotor. I'm so disturbed by all this, > I will begin to > inform the FCC, the Media and all that have the power to get this stop > before it gets started. Could people please mark their messages to indicate whether the contents are meant seriously or as a form of self-parody. I am unable to work out which category the above fits in to. From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 23:42:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18896 for ; Thu, 24 Jun 2004 23:42:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5P3Z3rY031882; Thu, 24 Jun 2004 20:35:03 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5P3Z3RM031881; Thu, 24 Jun 2004 20:35:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from xuxa.iecc.com (xuxa.iecc.com [208.31.42.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5P3Z2O2031871 for ; Thu, 24 Jun 2004 20:35:03 -0700 (PDT) (envelope-from johnl@iecc.com) Received: (qmail 17052 invoked by uid 100); 25 Jun 2004 03:35:06 -0000 Date: 25 Jun 2004 03:35:06 -0000 Message-ID: <20040625033506.17051.qmail@xuxa.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: Re: moving the anonymous mail argument to ASRG In-Reply-To: <20040624235433.GN13225@dumbo.pobox.com> Organization: I.E.C.C., Trumansburg NY USA Cc: mengwong@dumbo.pobox.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > You might find a more receptive forum at ASRG. Well, maybe. I have no interest in arguments that it's bad to authenticate mail because people can't send anonymous mail. That leads briskly to a scenario where anyone can say anything, but it's pointless because nobody's listening. There's a variety of ways to send anonymized mail, ranging from web mail to remailers like mixmaster. If someone wants to propose a specific topic related to anonymous mail, perhaps a BCP on anonymizers, I'd be willing to consider it. Regards, John Levine, johnl@taugh.com, ASRG chair From owner-ietf-mxcomp@mail.imc.org Thu Jun 24 23:58:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19359 for ; Thu, 24 Jun 2004 23:58:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5P3qAtC032994; Thu, 24 Jun 2004 20:52:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5P3qAQI032993; Thu, 24 Jun 2004 20:52:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from xuxa.iecc.com (xuxa.iecc.com [208.31.42.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5P3q9Ec032986 for ; Thu, 24 Jun 2004 20:52:09 -0700 (PDT) (envelope-from johnl@iecc.com) Received: (qmail 29609 invoked by uid 100); 25 Jun 2004 03:52:15 -0000 Date: 25 Jun 2004 03:52:15 -0000 Message-ID: <20040625035215.29608.qmail@xuxa.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: Re: Unified SPF: block versus factored records for HELO and MTAMAark scopes In-Reply-To: <20040624144946.GI13225@dumbo.pobox.com> Organization: I.E.C.C., Trumansburg NY USA Cc: mengwong@dumbo.pobox.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >In my discussions with Microsoft and AOL, I have gathered the >impression that large mail receivers favour block records because >they are more easily cached and more easily transformed into a >representation native to their internal antispam engines. Factored >records which require a new lookup for every cache negative are, in >their world, not lightweight by comparison. That's definitely how the Exchange group feels, since Exchange is a single long-running large program with threads handling the SMTP sessions. In this case, it's faster to slurp up all of the domain's info once and cache it inside the application. Most Unix MTAs including sendmail, exim, qmail and (I believe) postfix fork off a process per SMTP session which exits at the end of the session. In this case, any effort beyond that to validate the single IP used in the session is wasted, and the local DNS cache is where the info will be remembered. My impression is that there are a lot of large sites whose MTAs work this way. The reason I concocted FSV, which as you may recall "panders to all factions" is that there are significant communities which do it each way. FSV could serve up block records for people who want block records and factored records for people who want factored records. I realize that there's other ways to deal with this situation. For example, you might have a special purpose DNS cache which fetches block records, but then responds to factored queries from local clients. I know how I might write one of them, but until we try it, I wouldn't want to guess how well it'd work in practice. What this all tells me is that we're still nowhere near ready to standardize anything, because we don't have experimental data to tell us about performance issues, how the bad guys will counterattack, or any other real world problems we'll run into if we actually try to use this stuff. Publishing SPF records isn't enough -- people have to use them to filter mail or at least log info about what happened when they fetched the SPF data and what would have happened if they used that data for mail filtering. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor "I dropped the toothpaste", said Tom, crestfallenly. From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 00:02:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19836 for ; Fri, 25 Jun 2004 00:02:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5P3uoP4033690; Thu, 24 Jun 2004 20:56:50 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5P3uo28033689; Thu, 24 Jun 2004 20:56:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail1.yozons.com (mail1.yozons.com [206.80.109.179]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5P3unvi033683 for ; Thu, 24 Jun 2004 20:56:49 -0700 (PDT) (envelope-from d.wall@computer.org) Received: from rasta (soho2.yozons.com [206.80.109.178] (may be forged)) (authenticated bits=0) by mail1.yozons.com (8.12.8/8.12.8) with ESMTP id i5P3uoX5019242 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 24 Jun 2004 20:56:50 -0700 Message-ID: <0d8501c45a68$30894e60$3201a8c0@rasta> Reply-To: "David Wall" From: "David Wall" To: "John Levine" , Cc: References: <20040625033506.17051.qmail@xuxa.iecc.com> Subject: Re: moving the anonymous mail argument to ASRG Date: Thu, 24 Jun 2004 20:54:53 -0700 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.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > Well, maybe. I have no interest in arguments that it's bad to > authenticate mail because people can't send anonymous mail. That > leads briskly to a scenario where anyone can say anything, but it's > pointless because nobody's listening. I can mail a letter without being identified or authenticated. Why should email be more restrictive than postal mail? Not all authenticated speech is spam. Sometimes it's a call for revolution. Sometimes a call for a rave. Sometimes a call for help with drug problems or other issues in which people don't want to be identified. Are all AA meetings pointless with nobody listening because they only know first names? Such discussions are plain ignorant, and those who fail to abide by liberty are free to use services that are designed specifically for what they want without ruining email for others. Use those systems. > There's a variety of ways to send anonymized mail, ranging from web > mail to remailers like mixmaster. If someone wants to propose a > specific topic related to anonymous mail, perhaps a BCP on > anonymizers, I'd be willing to consider it. Why do all email users have to adapt to those systems. Why don't those who want to be fully authenticated adapt and use systems designed for it. You can pay to send your messages securely, with full tracking and authentication today. These services are great. All businesses SHOULD use them, and I don't know why so many fear open source software but jumped on free email with all its insecure warts. Businesses created the spam mess, and they should leave and use commercials delivery services like they use the post office, FedEx, etc. David From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 00:15:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20327 for ; Fri, 25 Jun 2004 00:14:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5P46f5S034149; Thu, 24 Jun 2004 21:06:41 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5P46fOd034148; Thu, 24 Jun 2004 21:06:41 -0700 (PDT) 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.9) with ESMTP id i5P46eGX034140 for ; Thu, 24 Jun 2004 21:06:41 -0700 (PDT) (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 D7577132D16; Fri, 25 Jun 2004 00:06:45 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id AB1D767C; Fri, 25 Jun 2004 00:06:45 -0400 (EDT) Date: Fri, 25 Jun 2004 00:06:45 -0400 From: Meng Weng Wong To: Hector Santos Cc: MARID Subject: rejection after DATA Message-ID: <20040625040645.GO13225@dumbo.pobox.com> References: <0aec01c45a35$531295f0$3201a8c0@rasta> <1088119560.24714.93.camel@ddev.mail-abuse.org> <0c4401c45a44$db8810e0$3201a8c0@rasta> <20040624235433.GN13225@dumbo.pobox.com> <005001c45a55$5d6078e0$6401a8c0@hdev1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005001c45a55$5d6078e0$6401a8c0@hdev1> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Jun 24, 2004 at 09:40:11PM -0400, Hector Santos wrote: | | I urge people to review at how this concept of requiring mail to be accepted | by SMTP for delayed rejection on unreliable concepts and then leave it for | Local Policies to decide. Can you explain what you mean? In my understanding of SenderID, an MTA can perform 2822 checks, and if it wishes to reject the message as a result of those checks, it can do so after DATA, but before the end of the SMTP transaction. That is to say, << 220 dumbo.pobox.com ESMTP Postfix >> EHLO dumbo.pobox.com << 250-dumbo.pobox.com << 250-PIPELINING << 250-SIZE 10240000 << 250-VRFY << 250-ETRN << 250 8BITMIME >> MAIL FROM: << 250 Ok >> RCPT TO: << 250 Ok >> DATA << 354 End data with . >> From: mengwong@vw.mailzone.com >> To: mengwong@dumbo.pobox.com >> Subject: recipient test >> Message-ID: <1088136255.84763-testmx-mengwong@dumbo.pobox.com> >> >> test >> . here -> << 250 Ok: queued as CEA0E51C >> QUIT << 221 Bye So instead of saying 250 OK, it says 550 Sorry Checks Failed. Silently discarding messages has always been something I've tried strenuously to avoid. From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 00:22:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20733 for ; Fri, 25 Jun 2004 00:22:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5P4EWWx034648; Thu, 24 Jun 2004 21:14:32 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5P4EWEM034647; Thu, 24 Jun 2004 21:14:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [64.139.47.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5P4EVBw034641 for ; Thu, 24 Jun 2004 21:14:31 -0700 (PDT) (envelope-from gconnor@nekodojo.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by neko-base.nekodojo.org (Postfix) with ESMTP id A27ED1D651; Thu, 24 Jun 2004 21:14:38 -0700 (PDT) Date: Thu, 24 Jun 2004 21:14:40 -0700 From: Greg Connor To: David Wall , ietf-mxcomp@imc.org Cc: mengwong@dumbo.pobox.com Subject: Re: moving the anonymous mail argument to ASRG Message-ID: <2340315.1088111680@[10.12.1.26]> In-Reply-To: <0d8501c45a68$30894e60$3201a8c0@rasta> References: <0d8501c45a68$30894e60$3201a8c0@rasta> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit David- In case you missed it the first two times, DO NOT POST ABOUT THIS TOPIC ON THIS LIST ANYMORE. This is a WORKING group, not a play area. If you disagree with, or need clarification of the list policy you should write to the chairperson privately. Everyone else- I would strongly advise not to respond to any post on this topic, whether agreeing or refuting. Just remind people it is off-topic. Replying to any of the specific points is also off-topic and just encourages another response. Thanks. gregc --David Wall wrote: > >> Well, maybe. I have no interest in arguments that it's bad to >> authenticate mail because people can't send anonymous mail. That >> leads briskly to a scenario where anyone can say anything, but it's >> pointless because nobody's listening. > > I can mail a letter without being identified or authenticated. Why should > email be more restrictive than postal mail? > > Not all authenticated speech is spam. Sometimes it's a call for > revolution. Sometimes a call for a rave. Sometimes a call for help with > drug problems or other issues in which people don't want to be > identified. Are all AA meetings pointless with nobody listening because > they only know first names? > > Such discussions are plain ignorant, and those who fail to abide by > liberty are free to use services that are designed specifically for what > they want without ruining email for others. Use those systems. > >> There's a variety of ways to send anonymized mail, ranging from web >> mail to remailers like mixmaster. If someone wants to propose a >> specific topic related to anonymous mail, perhaps a BCP on >> anonymizers, I'd be willing to consider it. > > Why do all email users have to adapt to those systems. Why don't those > who want to be fully authenticated adapt and use systems designed for it. > You can pay to send your messages securely, with full tracking and > authentication today. These services are great. All businesses SHOULD > use them, and I don't know why so many fear open source software but > jumped on free email with all its insecure warts. Businesses created the > spam mess, and they should leave and use commercials delivery services > like they use the post office, FedEx, etc. > > David -- Greg Connor From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 00:23:12 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20789 for ; Fri, 25 Jun 2004 00:23:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5P49CCT034342; Thu, 24 Jun 2004 21:09:12 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5P49CFS034341; Thu, 24 Jun 2004 21:09:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail1.yozons.com (mail1.yozons.com [206.80.109.179]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5P49BxA034334 for ; Thu, 24 Jun 2004 21:09:11 -0700 (PDT) (envelope-from d.wall@computer.org) Received: from rasta (soho2.yozons.com [206.80.109.178] (may be forged)) (authenticated bits=0) by mail1.yozons.com (8.12.8/8.12.8) with ESMTP id i5P49BX5019308 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 24 Jun 2004 21:09:11 -0700 Message-ID: <0dbd01c45a69$ea8d2100$3201a8c0@rasta> Reply-To: "David Wall" From: "David Wall" To: "Hector Santos" , "Meng Weng Wong" Cc: "MARID" References: <0aec01c45a35$531295f0$3201a8c0@rasta> <1088119560.24714.93.camel@ddev.mail-abuse.org> <0c4401c45a44$db8810e0$3201a8c0@rasta> <20040624235433.GN13225@dumbo.pobox.com> <005001c45a55$5d6078e0$6401a8c0@hdev1> Subject: Re: Sender identification is not the answer Date: Thu, 24 Jun 2004 21:07:21 -0700 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.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > Sender ID conflicts with many of the US ECPA provisions. There doesn't > seem to be much thought put into to see if it passes the legal muster. > SenderID is not a reliable concept and it promotes the obstruction of mail > delivery and it promotes local policies to be applied at the wrong > part of the mail operation. It promote post acceptance Local Policies > rejections ideas for any discriminatory whims beyond spam. Where do you > think "local policies" evolved from anyway? Not because it was a "neat" > idea. It all began with te 1986 US ECPA provisions to help address mail > delivery obstruction, mail tampering and privacy issues. I'm not just > blurting this out. It has many legal issues. Sorry the other poster didn't respect your insights just because While I'm not sure about your anger towards Microsoft (I do share my disapproval, though, since Outlook turned innocent email data into executable content without anybody's permission and started the virus revolution that has help drive the spam deluge, along with other helpful things like hiding "known file extensions" so once scary filenames look innocuous: i.e. hello.html.exe would be displayed as hello.html since the '.exe' was a known extension!). Unfortunately, the ECPA has no doubt been gutted by the Patriot Act I & II provisions, but the idea is right. At this point, these systems are saying that they will accept/reject email sent by others to people, but neither the sender nor the recipient has any say. That is a violation of ECPA, and of course many spam filters at ISPs have violated the law for some time. David From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 00:40:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21672 for ; Fri, 25 Jun 2004 00:40:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5P4U6iM036147; Thu, 24 Jun 2004 21:30:06 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5P4U6g1036146; Thu, 24 Jun 2004 21:30:06 -0700 (PDT) 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.9) with ESMTP id i5P4U5Vc036140 for ; Thu, 24 Jun 2004 21:30:05 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i5P4U4kX016324; Thu, 24 Jun 2004 21:30:04 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 24 Jun 2004 21:30:04 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'John Levine'" , ietf-mxcomp@imc.org Cc: mengwong@dumbo.pobox.com Subject: RE: Unified SPF: block versus factored records for HELO and MTAMA ark scopes Date: Thu, 24 Jun 2004 21:30:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Most Unix MTAs including sendmail, exim, qmail and (I believe) postfix > fork off a process per SMTP session which exits at the end of the > session. In this case, any effort beyond that to validate the single > IP used in the session is wasted, and the local DNS cache is where the > info will be remembered. My impression is that there are a lot of > large sites whose MTAs work this way. This is certainly the case historicaly, but this approach is largely due to the very poor performance and stability of early editions of pthreads, problems that are long since fixed. I do not know what the situation is where dedicated edge servers such as spam filtering systems are concerned. I strongly suspect that these are based on very different architectures. Perhaps someone could go and look at what some of these systems do. Even on a UNIX box there are good reasons to prefer a per thread model to a per process model, process creation and teardown in UNIX is only lightweight compared to other O/S. There are also other ways that a UNIX system may be organized. For example if I was operating a large cluster of mail filters I would hive off the task of fetching MARID data and resolving all forms of reputation and accreditation data in a separate system that performed caching. I would not want to store state in the mail server itself for the reason you mention and also because that would load up my external connections (which I pay for) rather than my internal 1Gb ethernet connections which are essentially free. So no, I do not accept this as much of an argument. Block records allow better efficiency in either case. The only argument I see for factored records is on the maintenance side where the records are being synthensized automatically via some form of dynamic DNS. If you have block records you have to either define a custom update protocol (trivial via a web service but must be done) or the dynamic DNS has to read the record, work out the update and write back the update. Of course this could also be solved if the mailer in this case used the sender header to give a unique machine address e.g.: Sender: mailer@pbaker-pc.verisign.com From:pbaker@verisign.com So the MARID record for pbaker-pc.verisign.com would consist of a dynamic dns updated record for my laptop PC and a link to another record giving info like accreditation data for the domain as a whole. OK we don't need factored records here either. Phill From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 00:51:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22255 for ; Fri, 25 Jun 2004 00:51:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5P4hLA5036993; Thu, 24 Jun 2004 21:43:21 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5P4hLZ4036992; Thu, 24 Jun 2004 21:43:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tom.iecc.com (tom.iecc.com [208.31.42.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5P4hKix036986 for ; Thu, 24 Jun 2004 21:43:21 -0700 (PDT) (envelope-from johnl@iecc.com) Received: (qmail 423 invoked from network); 25 Jun 2004 04:43:27 -0000 Received: (ofmipd 127.0.0.1); 25 Jun 2004 04:43:05 -0000 Date: 25 Jun 2004 00:43:26 -0400 Message-ID: From: "John R Levine" To: "Hallam-Baker, Phillip" Cc: "ietf-mxcomp@imc.org" , "mengwong@dumbo.pobox.com" Subject: RE: Unified SPF: block versus factored records for HELO and MTAMA ark scopes In-Reply-To: References: Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Even on a UNIX box there are good reasons to prefer a per thread model > to a per process model, process creation and teardown in UNIX is only > lightweight compared to other O/S. Depends how big the process is. Forking sendmail takes forever, but qmail's server is small and snappy. I realize that one can do threads on Unix boxes, but I don't think that many MTAs actually do so. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor "I dropped the toothpaste", said Tom, crestfallenly. From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 01:05:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22558 for ; Fri, 25 Jun 2004 01:05:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5P4tsv2038159; Thu, 24 Jun 2004 21:55:54 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5P4tsts038158; Thu, 24 Jun 2004 21:55:54 -0700 (PDT) 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.9) with ESMTP id i5P4tru5038152 for ; Thu, 24 Jun 2004 21:55:54 -0700 (PDT) (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 i5P4ttil023172; Thu, 24 Jun 2004 21:55:56 -0700 (PDT) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 24 Jun 2004 21:55:55 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'John R Levine'" , "Hallam-Baker, Phillip" Cc: ietf-mxcomp@imc.org, mengwong@dumbo.pobox.com Subject: RE: Unified SPF: block versus factored records for HELO and MTAMA ark scopes Date: Thu, 24 Jun 2004 21:55:51 -0700 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: > Depends how big the process is. Forking sendmail takes forever, but > qmail's server is small and snappy. I realize that one can > do threads on > Unix boxes, but I don't think that many MTAs actually do so. Well if we really get into UNIX arcanae Apache actually pre-forks the processes as a hunt group and some Unix mail servers do too. I had an office in the AI lab near to Robert Thau trying to make this particular party trick work on the Unix boxen of the day. Not a recommended approach. Even so you still have a process fault rather than a thread switch, if the threads package is half way competent its performance on a dedicated machine should be much better - of course on a shared machine your 16 processes will get far more resources. If you really want performance of course you single thread in a unitary process and use non blocking state machines... Of course to make that trick work you have to really understand the theory. But I have no problem loading up a machine with several thousand simultaneous connections using that method. Beyond that point you have to start writing your own tcp stack or the limitations of the BSD sockets libraries start to bite. Phill From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 01:16:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22990 for ; Fri, 25 Jun 2004 01:16:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5P56JK4040742; Thu, 24 Jun 2004 22:06:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5P56JuF040741; Thu, 24 Jun 2004 22:06:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.omniti.com (longsword.omniti.com [66.80.117.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5P56I12040728 for ; Thu, 24 Jun 2004 22:06:18 -0700 (PDT) (envelope-from jesus@omniti.com) Received: from ([68.55.23.203:50149]) by mail.omniti.com (ecelerity HEAD) with SMTP id EE/E3-20583-DC2BBD04; Fri, 25 Jun 2004 01:06:26 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3E9D38E0-C665-11D8-A39C-000A95D2C768@omniti.com> Content-Transfer-Encoding: 7bit Cc: "'John Levine'" , ietf-mxcomp@imc.org, Theo Schlossnagle , mengwong@dumbo.pobox.com From: Theo Schlossnagle Subject: Re: Unified SPF: block versus factored records for HELO and MTAMA ark scopes Date: Fri, 25 Jun 2004 01:05:15 -0400 To: "Hallam-Baker, Phillip" X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jun 25, 2004, at 12:30 AM, Hallam-Baker, Phillip wrote: >> Most Unix MTAs including sendmail, exim, qmail and (I believe) postfix >> fork off a process per SMTP session which exits at the end of the >> session. In this case, any effort beyond that to validate the single >> IP used in the session is wasted, and the local DNS cache is where the >> info will be remembered. My impression is that there are a lot of >> large sites whose MTAs work this way. > > I do not know what the situation is where dedicated edge servers > such as spam filtering systems are concerned. I strongly suspect > that these are based on very different architectures. Perhaps someone > could go and look at what some of these systems do. Our Edge appliance (and Ecelerity MTA software) does not use a per process model. It actually doesn't use a per thread model either. It is a hybrid model where non-blocking ops are put into a small group of event engine threads and blocking ops are put into a larger group of worker threads. As DNS queries have no good reason to block (there are a handlful of free nonblocking DNS resolving libraries out there) we can realize high concurrency and throughput with DNSBL, SPF, DomainKeys, etc. all performed inline. 100,000 concurrent SMTP sessions all performing DNS based lookups, MySQL lookups, ldap lookups, virus-checks and a slew of other things in real-time (during the SMTP session). > Even on a UNIX box there are good reasons to prefer a per thread model > to a per process model, process creation and teardown in UNIX is only > lightweight compared to other O/S. Threads have costs too. Smaller than processes in most cases and almost negligible if they are user-space threads. However, each has its pros and cons and you have to carry around that thread-stack. So one thread-per connection can be a big big waste. > There are also other ways that a UNIX system may be organized. For > example if I was operating a large cluster of mail filters I would > hive off the task of fetching MARID data and resolving all forms > of reputation and accreditation data in a separate system that > performed caching. Yes... perhaps not "separate", but certainly cached. > I would not want to store state in the mail server itself for the > reason you mention and also because that would load up my external > connections (which I pay for) rather than my internal 1Gb ethernet > connections which are essentially free. You can used a replicated data store. Shared consistent replicated cache across the mail servers. Much better and more reliable than a "backend store" as they usually have to be over-engineered to avoid a single point of failure. // Theo Schlossnagle // Principal Engineer -- http://www.omniti.com/~jesus/ // OmniTI Computer Consulting, Inc. -- http://www.omniti.com/ // Ecelerity: fastest MTA on Earth From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 01:19:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23148 for ; Fri, 25 Jun 2004 01:19:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5P5CanH043408; Thu, 24 Jun 2004 22:12:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5P5Caec043407; Thu, 24 Jun 2004 22:12:36 -0700 (PDT) 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.9) with ESMTP id i5P5CZAQ043385 for ; Thu, 24 Jun 2004 22:12:35 -0700 (PDT) (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.34) id 1Bdj0i-0005Lo-Qm for ietf-mxcomp@imc.org; Fri, 25 Jun 2004 00:12:42 -0500 To: "IETF MARID WG" References: <40D9C1DA.9090103@ehsco.com> <20040623210515.GF13225@dumbo.pobox.com> <1088031424.23891.85.camel@ddev.mail-abuse.org> <16602.6449.212333.862543@giles.gnomon.org.uk> <20040624035001.GG13225@dumbo.pobox.com> From: wayne Reply-To: "IETF MARID WG" Date: Fri, 25 Jun 2004 00:12:24 -0500 In-Reply-To: (John Leslie's message of "Thu, 24 Jun 2004 15:24:00 +0200") 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 (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: Unified SPF Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.3 required=4.0 tests=AWL,BAYES_00,GREYLIST_ISWHITE autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In "John Leslie" writes: > Please understand: for what it sets out to do, one could argue that > SPF _is_ "lightweight". But it sets out to do so much that we cannot > place upper bounds on the processing that might be required. You can place an upper bound on SPF processing, although I think that much stricter limits need to be placed in the standards. (Yes, I have argued with Meng over this subject, I should probably push him again since it has been over a week. ;-) I have also done DoS attack studies on SPF, both from the point of view of attacking the receiving MTA and from the point of view of tricking receiving MTAs into participating in a DDoS attack on someone else. Obviously I can't say there aren't any problems, but this is a security issue that I have certainly investigated. > There's another issue I suppose deserves mention yet again: that > reaching consensus in the MARID WG is just one step towards an IETF > standard. (I'll let others judge how close we are to consensus.) > SPF is (IMHO) absolutely dependent on the use of TXT records in areas > of the DNS tree where other TXT records are likely to be found. We > _know_ we're going to face a lot of flak from DNS experts over this > issue. This cannot fail (IMHO) to slow down the process of becoming > an IETF standard. I have posted data and analysis of the sizes of SPF records and the types and sizes of pre-existing TXT records to this list before. I can give you pointers if you can't find them. (I just posted a short update using the same subject line, "Some stats on TXT usage in domain names") If I could wave a wand and make the problems of using a different RR disappear, I certainly would. However, from my studies, I can't find a serious problem with SPF's use of TXT records. >> | The two approaches seem complementary to me; is there any reason why >> | this WG can't advance both to PS? >> >> I explain in more detail at >> http://spf.pobox.com/slides/unified%20spf/ > > Here, Meng advises folks to not worry about the difference between > HELO and RFC2822. Inevitably, that will lead to a large number of > domains advertising relatively open SPF records, and those relatively > open records being used to "authenticate" HELOs of MTAs which the actual > domain never had the slightest intent of trying to control. And, since > all of this is publicly available in DNS, spammers will quickly compile > a list of these. I understand your concern, but I think the problem will be self-correcting. If spammers run out of domains that haven't published SPF records, and decide that using their own domains is too much of a problem and therefore start trying to use domains which aren't tight enough, I think the domain owners will quickly tighten them down. As Meng mentioned in another post, there are a couple of ways of providing per-scope rules, when they are really needed. > But it gets worse: Meng actually advises bypassing further checks > if the HELO passes SPF checking and the domain passes reputation checks. > (Think about it, Meng: I'm sure you'll relent.) Uh, Hmmm... I'm not Meng, but I have thought about it. I see no problem with an email receiver being able to whitelist anyone they want. Whitelists need a verifiable identity, and using SPF to verify that makes sense to me. -wayne From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 01:38:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24253 for ; Fri, 25 Jun 2004 01:38:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ONVu8q012682; Thu, 24 Jun 2004 16:31:56 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5ONVuqr012681; Thu, 24 Jun 2004 16:31:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-9.csi.cam.ac.uk (ppsw-9.csi.cam.ac.uk [131.111.8.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ONVtEE012675 for ; Thu, 24 Jun 2004 16:31:56 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:50941) by ppsw-9.csi.cam.ac.uk (old-ppsw.cam.ac.uk [131.111.8.3]:25) with esmtp (Exim 4.34) id 1BddhH-0002Mv-Uu for ietf-mxcomp@imc.org; Fri, 25 Jun 2004 00:31:59 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1BddhH-0004Mq-NG for ietf-mxcomp@imc.org; Fri, 25 Jun 2004 00:31:59 +0100 Date: Fri, 25 Jun 2004 00:31:59 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: "'IETF MARID WG'" Subject: Re: Unified SPF: block versus factored records for HELO and MTAMAarkscopes In-Reply-To: <16603.15304.572135.668380@giles.gnomon.org.uk> Message-ID: References: <20040624144946.GI13225@dumbo.pobox.com> <1a44201c45a03$6f0e0cd0$6e82820a@mailgatejd> <20040624195655.GL13225@dumbo.pobox.com> <16603.15304.572135.668380@giles.gnomon.org.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 24 Jun 2004, Roy Badami wrote: > > I think [SRV] works like an SPF record containing a single 'a' > mechanism. It's a bit more subtle than that. A SRV lookup give you an IP address list (the result of an A and AAAA lookup on the SRV target domain name) as well as some auxiliary data. CSV uses the auxiliary data for authorization information (yes, no, dunno) and the addresses for authentication. SPF doesn't distinguish authentication and authorization. However the end result is roughly the same, but CSV is more efficient. Tony. -- f.a.n.finch http://dotat.at/ LOUGH FOYLE TO CARLINGFORD LOUGH: NORTHWEST 5 LOCALLY 6 GRADUALLY DECREASING 2 OR 3 AND BECOMING VARIABLE, LATER INCREASING SOUTH 4 LOCALLY 5. ISOLATED SHOWERS. MAINLY GOOD. MODERATE DECAYING SLIGHT. From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 01:38:57 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24274 for ; Fri, 25 Jun 2004 01:38:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ONtNsO014631; Thu, 24 Jun 2004 16:55:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5ONtNB4014630; Thu, 24 Jun 2004 16:55:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ribbit.roadtoad.net (IDENT:root@ribbit.roadtoad.net [209.209.8.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ONtNSQ014623 for ; Thu, 24 Jun 2004 16:55:23 -0700 (PDT) (envelope-from mark@bitshift.org) Received: from tethys.bitshift.org (c-24-6-150-46.client.comcast.net [24.6.150.46]) by ribbit.roadtoad.net (8.12.9/8.12.2) with ESMTP id i5ONtPtj024999 for ; Thu, 24 Jun 2004 16:55:25 -0700 (PDT) Received: by tethys.bitshift.org (Postfix, from userid 1001) id 1FB6B84F85D; Thu, 24 Jun 2004 16:55:25 -0700 (PDT) Date: Thu, 24 Jun 2004 16:55:25 -0700 From: "Mark C. Langston" To: MARID Subject: Re: Sender identification is not the answer Message-ID: <20040624235525.GI35808@bitshift.org> References: <0aec01c45a35$531295f0$3201a8c0@rasta> <1088119560.24714.93.camel@ddev.mail-abuse.org> <0c4401c45a44$db8810e0$3201a8c0@rasta> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0c4401c45a44$db8810e0$3201a8c0@rasta> User-Agent: Mutt/1.4.1i X-Uptime: 4:49PM up 10 days, 56 mins, 8 users, load averages: 0.04, 0.02, 0.00 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Jun 24, 2004 at 04:42:05PM -0700, David Wall wrote: > > Thanks, Douglas for your comments. > > > There are thousands of mail providers requiring no identification, nor > > do any MARID proposals curtail this desirable freedom by respecting > > economies that enable this service. The goal is to curtail the abuse > > that increases costs that will eventually constrain this freedom. The > > CSV-HNA-CSA approach attempts to identify domains submitting mail to > > enable evaluation and follow-up as a means to curtail these costs. > > As I said before, I don't believe this because all email that doesn't have > this identification stamp will be assumed to be suspect over time. In the > U.S., you can walk around with carrying identification. If businesses all > of a sudden (and they won't because it's bad business, just like this is bad > for email) started requiring identification to enter a store since it would > help them with theft issues, but said you don't have to have ID, you would > find that people would start showing their ID just to avoid being followed > everywhere they went in the store. The same will happen here in which all > non-authenticated email will be suspicious, will be further analyzed and > review, and will likely be tossed out in the fear of preventing spam. [...snip] Just to jump in here with a thought: with respect to email, "identification" does not necessarily have to entail a 1:1 mapping to an individual entity, nor does the "identification" have to have any ties whatsoever to real-world identity. "Identity" can merely be a unique identifying token with which an observed pattern of behavior is associated. Where that unique token needs to be associated with a real-world entity is when someone wants to hold that entity responsible and accountable for the actions taken under the auspices of that unique token. Accountability can also maintain separation from identification on one face, though at some point someone or something has to map identity to entity to enforce accountability. But at that point, your concern isn't over identification, it's over enforcement of accountability, which is a different issue, and one I don't believe MARID is chartered to deal with. -- Mark C. Langston Sr. Unix SysAdmin mark@bitshift.org mark@seti.org Systems & Network Admin SETI Institute http://bitshift.org http://www.seti.org From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 01:51:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24687 for ; Fri, 25 Jun 2004 01:51:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5P5bR8P054798; Thu, 24 Jun 2004 22:37:27 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5P5bRsf054797; Thu, 24 Jun 2004 22:37:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (mail.santronics.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5P5bQrM054778 for ; Thu, 24 Jun 2004 22:37:26 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Fri, 25 Jun 2004 01:41:14 -0400 Received: from ([68.223.169.60]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 1952722266; Fri, 25 Jun 2004 01:41:13 -0400 Message-ID: <019b01c45a77$94757430$6401a8c0@hdev1> From: "Hector Santos" To: "Meng Weng Wong" Cc: "MARID" References: <0aec01c45a35$531295f0$3201a8c0@rasta> <1088119560.24714.93.camel@ddev.mail-abuse.org> <0c4401c45a44$db8810e0$3201a8c0@rasta> <20040624235433.GN13225@dumbo.pobox.com> <005001c45a55$5d6078e0$6401a8c0@hdev1> <20040625040645.GO13225@dumbo.pobox.com> Subject: Re: rejection after DATA Date: Fri, 25 Jun 2004 01:40:14 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.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: Content-Transfer-Encoding: 7bit This is what is so disturbing. Why do I have to explain this? Honestly, I don't want to buck the system or rub or step on any toes. For the most part, I have put my trust in the what I thought ware thousands of man-years in this working group, with the historistical perspective for mail designs and the laws that evolved around them. I tried to provide some input and insight when I thought was appropriate but for the most part, I felt you guys will do the "right thing" Instead, I am either being told to shut up privately or told I'm out of scope or simply completely ignored. By law, rejection is legally acceptable at the transport level and at the posting level for online hosting systems. Once mail is accepted either by transport or by online posting, you MUST: - maintain the intent of the user - maintain integrity - take responsibility for delivery When push comes to shove., that is the law molded by US ECPA and if you been involved in the industry as long as I have to see how it all evolved, you would know all this. I really didn't think I needed to remind anyone of this. So yes, as a response to DATA, it is legally acceptable. But SPF/SENDERID is being promoted to POST SMTP systems and that is where the problem many lies. If you redesign your MTA to do dynamic validation, you conform to the laws. See my comment to David Walls ----- Original Message ----- From: "Meng Weng Wong" To: "Hector Santos" Cc: "MARID" Sent: Friday, June 25, 2004 12:06 AM Subject: rejection after DATA > > On Thu, Jun 24, 2004 at 09:40:11PM -0400, Hector Santos wrote: > | > | I urge people to review at how this concept of requiring mail to be accepted > | by SMTP for delayed rejection on unreliable concepts and then leave it for > | Local Policies to decide. > > Can you explain what you mean? In my understanding of > SenderID, an MTA can perform 2822 checks, and if it wishes > to reject the message as a result of those checks, it can do > so after DATA, but before the end of the SMTP transaction. > > That is to say, > > << 220 dumbo.pobox.com ESMTP Postfix > >> EHLO dumbo.pobox.com > << 250-dumbo.pobox.com > << 250-PIPELINING > << 250-SIZE 10240000 > << 250-VRFY > << 250-ETRN > << 250 8BITMIME > >> MAIL FROM: > << 250 Ok > >> RCPT TO: > << 250 Ok > >> DATA > << 354 End data with . > >> From: mengwong@vw.mailzone.com > >> To: mengwong@dumbo.pobox.com > >> Subject: recipient test > >> Message-ID: <1088136255.84763-testmx-mengwong@dumbo.pobox.com> > >> > >> test > >> . > here -> << 250 Ok: queued as CEA0E51C > >> QUIT > << 221 Bye > > So instead of saying 250 OK, it says 550 Sorry Checks Failed. > > Silently discarding messages has always been something I've > tried strenuously to avoid. > > From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 02:09:13 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04127 for ; Fri, 25 Jun 2004 02:09:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5P62l2A067499; Thu, 24 Jun 2004 23:02:47 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5P62lgZ067498; Thu, 24 Jun 2004 23:02:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (ntbbs.winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5P62k4F067486 for ; Thu, 24 Jun 2004 23:02:46 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Fri, 25 Jun 2004 02:06:37 -0400 Received: from ([68.223.169.60]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 1954244891; Fri, 25 Jun 2004 02:06:36 -0400 Message-ID: <019e01c45a7b$20108f90$6401a8c0@hdev1> From: "Hector Santos" To: "David Wall" , "Meng Weng Wong" Cc: "MARID" References: <0aec01c45a35$531295f0$3201a8c0@rasta> <1088119560.24714.93.camel@ddev.mail-abuse.org> <0c4401c45a44$db8810e0$3201a8c0@rasta> <20040624235433.GN13225@dumbo.pobox.com> <005001c45a55$5d6078e0$6401a8c0@hdev1> <0dbd01c45a69$ea8d2100$3201a8c0@rasta> Subject: Re: Sender identification is not the answer Date: Fri, 25 Jun 2004 02:09:02 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.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: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "David Wall" To: "Hector Santos" ; "Meng Weng Wong" Cc: "MARID" Sent: Friday, June 25, 2004 12:07 AM Subject: Re: Sender identification is not the answer > > Sender ID conflicts with many of the US ECPA provisions. There doesn't > > seem to be much thought put into to see if it passes the legal muster. > > SenderID is not a reliable concept and it promotes the obstruction of mail > > delivery and it promotes local policies to be applied at the wrong > > part of the mail operation. It promote post acceptance Local Policies > > rejections ideas for any discriminatory whims beyond spam. Where do you > > think "local policies" evolved from anyway? Not because it was a "neat" > > idea. It all began with te 1986 US ECPA provisions to help address mail > > delivery obstruction, mail tampering and privacy issues. I'm not just > > blurting this out. It has many legal issues. > > Sorry the other poster didn't respect your insights just because While I'm > not sure about your anger towards Microsoft (I do share my disapproval, > though, since Outlook turned innocent email data into executable content > without anybody's permission and started the virus revolution that has help > drive the spam deluge, along with other helpful things like hiding "known > file extensions" so once scary filenames look innocuous: i.e. hello.html.exe > would be displayed as hello.html since the '.exe' was a known extension!). [Note: I don't have an anger towards Microsoft. There engineering decisions makes me scratch my head but we are a Windows shop with one of the top Windows applications for it. What I want for them to do the right thing especially in an important area like this that will effect the entire world.] > Unfortunately, the ECPA has no doubt been gutted by the Patriot Act I & II > provisions, but the idea is right. At this point, these systems are saying > that they will accept/reject email sent by others to people, but neither the > sender nor the recipient has any say. That is a violation of ECPA, and of > course many spam filters at ISPs have violated the law for some time. Right, the entire history of mail hosting and gateways and transports, which I have part of since the 80s, the growth of Porn, the introduction of alias logins (DIsplay Name) and then even futher relaxation with complete anonymity was all items that I was directly part of one way or another. Our software designs are are molded by the laws. To this day, our mail hosting product does not support true anonymous logins, alias yes, but not anonymous. It was the migtration and integration of SMTP, POP3 and NNTP into our backend that created all the current security issues we have. But we continue to make sure the laws are followed. A good example is how POP3 introduced the mail snooping/previewing mail concept into mail systems were mail previewing was a only a sysop privilege. It took a lot of debates with customers before we finally pressured to change violate the mail integrity. Users now had a way of saying "Hey, I never got that expiration notice!" Mail Recipients were not broken, etc. It was all finally worked out, but it illustrates just one item over the years with mail designs I have been involved with to see the effects of designs. Yes, excellent reminder about the Patriot Acts. It further strengthen the dangerous precedence that is being promoted with SenderID. The Patriot Act now allows labeling an unsolicited sender as a "Terrorist" or the claim the sender is destroying private property as a legal way to circumvent US ECPA. SenderID promotes POST SMTP validation with ideas promoting local policies to obstruct the mail delivery process. All a sysop needs to claim is that the sender was deemed as destroying property or had terrorist behavior. What I am afraid, is that SenderID system, especially when added to passthru/routed system, will begin to get into this unreliable 2822 validation game and destroy mail for any discriminatory reason. "A Spam from a Republican, Accept. A spam from a Democrat. Reject" Sure, silly example. Lets go ahead and open up this Pandora Box and watch what happens. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 02:39:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10587 for ; Fri, 25 Jun 2004 02:39:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5P6SSVY077119; Thu, 24 Jun 2004 23:28:28 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5P6SSSq077118; Thu, 24 Jun 2004 23:28:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5P6SRMT077108 for ; Thu, 24 Jun 2004 23:28:27 -0700 (PDT) (envelope-from hkatz@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 24 Jun 2004 23:28:27 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 24 Jun 2004 23:28:27 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 24 Jun 2004 23:28:27 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-fido-msg.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Jun 2004 23:28:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-39e53a72-cf44-48fa-94c4-2a12b35b115a" Subject: RE: draft-ietf-marid-submitter-01.txt Date: Thu, 24 Jun 2004 23:26:32 -0700 Message-ID: Thread-Topic: draft-ietf-marid-submitter-01.txt thread-index: AcRaDIWq4PZBRItCRv2b0kfm2OoirwAbzcgg From: "Harry Katz" To: "Hadmut Danisch" Cc: "Jim Lyon" , "IETF MARID List" X-OriginalArrivalTime: 25 Jun 2004 06:28:31.0743 (UTC) FILETIME=[A287B0F0:01C45A7D] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPartTM-000-39e53a72-cf44-48fa-94c4-2a12b35b115a Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C45A7D.A00AFA7E" ------_=_NextPart_001_01C45A7D.A00AFA7E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks, Hadmut. =20 Since the SUBMITTER parameter is derived from RFC 2822 headers, I believe you could reconstruct the chain of submitters from the Resent-From or Resent-Sender headers that are written with each Received header. If there is no Resent-* header, then either the Sender or From headers would contain the SUBMITTER value. .=20 ________________________________ From: Hadmut Danisch [mailto:hadmut@danisch.de]=20 Sent: Thursday, June 24, 2004 9:56 AM To: Harry Katz Cc: Jim Lyon; IETF MARID List Subject: Re: draft-ietf-marid-submitter-01.txt =09 =09 Harry Katz wrote:=20 Attached is the latest revision to the Responsible Submitter internet-draft. =20 =09 Good proposal.=20 =09 But shouldn't the proposal include an extension to the Received:-Header to include the given (and verified) submitter name? Or a new header entry? In a chain of submissions I'd like to be able to trace the submission back. =09 regards Hadmut =09 =09 ------_=_NextPart_001_01C45A7D.A00AFA7E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thanks, Hadmut.
 
Since=20 the SUBMITTER parameter is derived from RFC 2822 headers, I believe you = could=20 reconstruct the chain of submitters from the Resent-From or = Resent-Sender=20 headers that are written with each Received header.  If there is no = Resent-* header, then either the Sender or From headers would = contain the=20 SUBMITTER value. .

From: Hadmut Danisch=20 [mailto:hadmut@danisch.de]
Sent: Thursday, June 24, 2004 = 9:56=20 AM
To: Harry Katz
Cc: Jim Lyon; IETF MARID=20 List
Subject: Re:=20 draft-ietf-marid-submitter-01.txt

Harry Katz wrote:=20
Attached is the=20 latest revision to the Responsible Submitter internet-draft. =20

Good=20 proposal.

But shouldn't the proposal include an extension to = the=20 Received:-Header
to include the given (and verified) submitter = name? Or a=20 new header entry?
In a chain of submissions I'd like to be able to = trace=20 the submission=20 back.

regards
Hadmut

<= /HTML> ------_=_NextPart_001_01C45A7D.A00AFA7E-- ------=_NextPartTM-000-39e53a72-cf44-48fa-94c4-2a12b35b115a-- From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 02:45:52 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10826 for ; Fri, 25 Jun 2004 02:45:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5P6bti7080676; Thu, 24 Jun 2004 23:37:55 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5P6btJr080675; Thu, 24 Jun 2004 23:37:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (ntbbs.winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5P6bs0U080655 for ; Thu, 24 Jun 2004 23:37:54 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Fri, 25 Jun 2004 02:41:34 -0400 Received: from ([68.223.169.60]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 1956342141; Fri, 25 Jun 2004 02:41:33 -0400 Message-ID: <01b601c45a80$02344430$6401a8c0@hdev1> From: "Hector Santos" To: "Hallam-Baker, Phillip" , "MARID" References: Subject: Violiates US ECPA: Re: Sender identification is not the answer Date: Fri, 25 Jun 2004 02:45:27 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.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: Content-Transfer-Encoding: 7bit This is not a joke. I am dead serious about this. I changed the subject line. What is quickly becoming a parody is how designs are being discussed; that A) are not going to work very well in the first place, b) increase DNS overhead, c) increase and promote the network transport payload and d) violiates and conflicts with US ECPA provisions and yet doesn't even address the two fundamental mandates of CANSPAM - true sender authentication and topic identification. What is disturbing about it is why I have to remind people about this. Go figure. It took my wife today to say while I was fighting the urge to click the send button: "You got more mail design experience than most in that group you wasting alot of time on. It is time to speak up if you feel Microsoft's proposal is going to change things in negative ways. Press the send button Hector." -- Hector Santos, Santronics Software, Inc. http://www.santronics.com ----- Original Message ----- From: "Hallam-Baker, Phillip" To: "MARID" Sent: Thursday, June 24, 2004 11:20 PM Subject: RE: Sender identification is not the answer > > > > Mr. Wong, > > > > Sender-ID is horrible and it will alter the landscape since > > Microsoft is the > > author and hence, promotor. I'm so disturbed by all this, > > I will begin to > > inform the FCC, the Media and all that have the power to get this stop > > before it gets started. > > Could people please mark their messages to indicate whether the > contents are meant seriously or as a form of self-parody. I am > unable to work out which category the above fits in to. > > From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 07:36:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23885 for ; Fri, 25 Jun 2004 07:36:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PBS2Tk062637; Fri, 25 Jun 2004 04:28:02 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5PBS2M8062636; Fri, 25 Jun 2004 04:28:02 -0700 (PDT) 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.9) with ESMTP id i5PBS2E3062630 for ; Fri, 25 Jun 2004 04:28:02 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from pool-528.denpasar.indo.net.id (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i5PBQLl12775; Fri, 25 Jun 2004 04:26:28 -0700 Date: Fri, 25 Jun 2004 15:28:18 +0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <197394753.20040625152818@brandenburg.com> To: Meng Weng Wong CC: "'IETF MARID WG'" Subject: Re: Unified SPF: block versus factored records for HELO and MTAMAark scopes In-Reply-To: <20040624175917.GK13225@dumbo.pobox.com> References: <40D9C1DA.9090103@ehsco.com> <20040623210515.GF13225@dumbo.pobox.com> <1088031424.23891.85.camel@ddev.mail-abuse.org> <16602.6449.212333.862543@giles.gnomon.org.uk> <20040624035001.GG13225@dumbo.pobox.com> <20040624130742.GC3747@verdi> <20040624144946.GI13225@dumbo.pobox.com> <16602.63002.437751.557545@giles.gnomon.org.uk> <20040624175917.GK13225@dumbo.pobox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Meng, Two responses, for the price of one: MWW> OK, speaking of CSV in its current incarnation, can anyone MWW> give me a concrete example of how the MWW> authentication/authorization procedure operates? MWW> In SPF, authentication is simple: you do the SPF TXT lookup, MWW> you get back the SPF TXT record, Forgive me, but: MWW> the computer thinks a bit, MWW> and you get a well-defined PASS or FAIL or NEUTRAL, etc MWW> response. That sounds quite a bit about the old joke about the blank space in a board that is otherwise filled with equations. The scientist responds to a query by pointing to it and says "that's where a miracle happens". So, yes, your description does indeed sound simple, but that to be because you left out all of the interesting stuff. MWW> In CSV, MWW> http://www.jlc.net/MARID/CSV/draft-ietf-marid-csv-intro-00.html#anchor11 MWW> suggests that you do authentication by doing a A lookup of MWW> the HELO name; It's not a "suggestion". It is a "specification". The differences is important. CSV is very simple and constrained. It is entirely based on the SMTP HELO. If you are using some other identity, then you are not using CSV. That is why the specification has a title that says "client smtp". The HELO is the only place that that client is able to declare its identity. MWW> I would request that the next draft of the CSV proposal MWW> contain some examples and walkthroughs. My co-authors have thoughtfully added a rather nice description of the usage sequence in Section 1 of . More detailed examples are almost always often helpful, so perhaps you could describe what sorts of cases you would like to see described? - - - - - MWW> client ip factored query block query MWW> --------- -------------------------- --------------- MWW> 192.0.2.1 lookup(aol.com, 192.0.2.1) lookup(aol.com) As your discussion highlights, there is some complexity to the desired lookup- and storage- compression efficiencies that folks might seek. The usual implication of such an observation is that folks should be careful about standardizing particular choices, until there is experience with the physics of the service. In any event, as Roy noted, CSV does a forward query based on a domain name. The incoming IP Address may be used by a higher-level CSV process, to do some comparing. So the "factored query" that you describe does not show up in CSV. For that matter, it is not a DNS query, since you do not get to specify two lookup keys in a DNS query. You specify one, a domain name. According to the example you give, the CSV style of query therefore looks like the column marked "block query". In the typical case, returned information will include a set of IP Addresses in the Additional Information field. How the DNS client chooses to organize and use this information is its own business. That choice is not forced upon them by the protocol. At best what you scenario suggests is that a CSV-category module should do its own caching and do it more cleverly than a run-of-the-mill system DNS cache. I suspect the confusion in your comments is between protocol versus implementation. Clearly, one would want the implementation to have a feature along the lines you described, since that gives nice caching behavior. As I understand it, the working group is doing PROTOCOL specification -- specifically a DNS record, though we seem to range rather farther, in order to understand what we need the record FOR. We are not doing implementation standardization. As long as the protocol does not behave in a way that prevents good implementation, then the it is not the working group optimization that you are suggesting. So I am not understanding what difference in protocol behaviors you are distinguishing between SPF and CSV, with respect to the functions raised for this thread. (As I noted in a separate note, the scope of SPF is something I've been finding confusing, so I'm forced to use the CSV scope for this note.) d/ MWW> On Thu, Jun 24, 2004 at 04:41:14PM +0100, Roy Badami wrote: MWW> | | Meng>> antispam engines. Factored records which require a new | Meng>> lookup for every cache negative are, in their world, not | Meng>> lightweight by comparison. MWW> | MWW> | But, AIUI, CSV in it's current incarnation involves doing an SRV MWW> | lookup on the domain name; how is this more heavyweight than doing a MWW> | TXT lookup. CSV looks just as cacheable to me as SPF, but uses more MWW> | compact records... MWW> | MWW> I was mainly comparing cache negatives. MWW> Scenario: 5 spams that all say MAIL FROM: MWW> Let each spam come from a different IP. MWW> client ip factored query block query MWW> --------- -------------------------- --------------- MWW> 192.0.2.1 lookup(aol.com, 192.0.2.1) lookup(aol.com) MWW> 192.0.2.2 lookup(aol.com, 192.0.2.2) cached MWW> 192.0.2.3 lookup(aol.com, 192.0.2.3) cached MWW> 192.0.2.4 lookup(aol.com, 192.0.2.4) cached MWW> 192.0.2.5 lookup(aol.com, 192.0.2.5) cached MWW> In this scenario, factored queries do not benefit from MWW> local DNS caching. MWW> So, the theory is: a spam run against a single receiver MWW> domain may originate from X distinct IPs. MWW> That spam run may forge Y distinct domain names. If X >>> Y, a block format is better than factored. If Y >>> X, block and factored formats are equivalent within MWW> one order of magnitude. MWW> Scenarios in which factored formats beat block formats hands MWW> down tend to be contrived. MWW> The current threat model is lots of zombies, hence lots of MWW> IPs. True, there's nothing to stop them from forging lots MWW> of domains, too. That's where the MTAMark design proves MWW> useful --- it scales well, because only one network owner MWW> has to add records. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 07:45:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24091 for ; Fri, 25 Jun 2004 07:45:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PBPhup062516; Fri, 25 Jun 2004 04:25:43 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5PBPhNP062515; Fri, 25 Jun 2004 04:25:43 -0700 (PDT) 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.9) with ESMTP id i5PBPhOI062509 for ; Fri, 25 Jun 2004 04:25:43 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from pool-528.denpasar.indo.net.id (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i5PBP5l12742; Fri, 25 Jun 2004 04:25:06 -0700 Date: Fri, 25 Jun 2004 15:10:11 +0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1964513122.20040625151011@brandenburg.com> To: Meng Weng Wong CC: "'IETF MARID WG'" , Roy Badami Subject: Re: Unified SPF: block versus factored records for HELO and MTAMAark scopes In-Reply-To: <20040624174646.GJ13225@dumbo.pobox.com> References: <40D9C1DA.9090103@ehsco.com> <20040623210515.GF13225@dumbo.pobox.com> <1088031424.23891.85.camel@ddev.mail-abuse.org> <16602.6449.212333.862543@giles.gnomon.org.uk> <20040624035001.GG13225@dumbo.pobox.com> <20040624130742.GC3747@verdi> <20040624144946.GI13225@dumbo.pobox.com> <16602.63002.437751.557545@giles.gnomon.org.uk> <20040624174646.GJ13225@dumbo.pobox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Meng, As your discussion highlights, there is some complexity to the desired lookup- and storage- compression efficiencies that folks might seek. The usual implication of such an observation is that folks should be careful about standardizing particular choices, until there is experience with the physics of the service. In any event, as Roy noted, CSV does a forward query based on a domain name. The incoming IP Address may be used by a higher-level CSV process, to do some comparing. So the "factored query" that you describe does not show up in CSV. For that matter, it is not a DNS query, since you do not get to specify two lookup keys in a DNS query. You specify one, a domain name. According to the example you give, the CSV style of query therefore looks like the column marked "block query". In the typical case, returned information will include a set of IP Addresses in the Additional Information field. How the DNS client chooses to organize and use this information is its own business. That choice is not forced upon them by the protocol. At best what you scenario suggests is that a CSV-category module should do its own caching and do it more cleverly than a run-of-the-mill system DNS cache. I suspect the confusion in your comments is between protocol versus implementation. Clearly, one would want the implementation to have a feature along the lines you described, since that gives nice caching behavior. As I understand it, the working group is doing PROTOCOL specification -- specifically a DNS record, though we seem to range rather farther, in order to understand what we need the record FOR. We are not doing implementation standardization. As long as the protocol does not behave in a way that prevents good implementation, then the it is not the working group optimization that you are suggesting. So I am not understanding what difference in protocol behaviors you are distinguishing between SPF and CSV, with respect to the functions raised for this thread. (As I noted in a separate note, the scope of SPF is something I've been finding confusing, so I'm forced to use the CSV scope for this note.) d/ MWW> On Thu, Jun 24, 2004 at 04:41:14PM +0100, Roy Badami wrote: MWW> | | Meng>> antispam engines. Factored records which require a new | Meng>> lookup for every cache negative are, in their world, not | Meng>> lightweight by comparison. MWW> | MWW> | But, AIUI, CSV in it's current incarnation involves doing an SRV MWW> | lookup on the domain name; how is this more heavyweight than doing a MWW> | TXT lookup. CSV looks just as cacheable to me as SPF, but uses more MWW> | compact records... MWW> | MWW> I was mainly comparing cache negatives. MWW> Scenario: 5 spams that all say MAIL FROM: MWW> Let each spam come from a different IP. MWW> client ip factored query block query MWW> --------- -------------------------- --------------- MWW> 192.0.2.1 lookup(aol.com, 192.0.2.1) lookup(aol.com) MWW> 192.0.2.2 lookup(aol.com, 192.0.2.2) cached MWW> 192.0.2.3 lookup(aol.com, 192.0.2.3) cached MWW> 192.0.2.4 lookup(aol.com, 192.0.2.4) cached MWW> 192.0.2.5 lookup(aol.com, 192.0.2.5) cached MWW> In this scenario, factored queries do not benefit from MWW> local DNS caching. MWW> So, the theory is: a spam run against a single receiver MWW> domain may originate from X distinct IPs. MWW> That spam run may forge Y distinct domain names. If X >>> Y, a block format is better than factored. If Y >>> X, block and factored formats are equivalent within MWW> one order of magnitude. MWW> Scenarios in which factored formats beat block formats hands MWW> down tend to be contrived. MWW> The current threat model is lots of zombies, hence lots of MWW> IPs. True, there's nothing to stop them from forging lots MWW> of domains, too. That's where the MTAMark design proves MWW> useful --- it scales well, because only one network owner MWW> has to add records. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 09:11:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28496 for ; Fri, 25 Jun 2004 09:11:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PC3CDs065534; Fri, 25 Jun 2004 05:03:12 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5PC3CU5065533; Fri, 25 Jun 2004 05:03:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5PC37ca065524 for ; Fri, 25 Jun 2004 05:03:12 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id 858471A6D8; Fri, 25 Jun 2004 14:03:03 +0200 (CEST) Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) by bra.gulbrandsen.priv.no (Postfix) with SMTP id 051B71A6D2; Fri, 25 Jun 2004 14:02:58 +0200 (CEST) Message-Id: From: Arnt Gulbrandsen To: Dave Crocker Subject: Re: Unified SPF: block versus factored records for HELO and MTAMAark scopes Cc: Meng Weng Wong , Dave Crocker , IETF MARID WG References: <40D9C1DA.9090103@ehsco.com> <20040623210515.GF13225@dumbo.pobox.com> <1088031424.23891.85.camel@ddev.mail-abuse.org> <16602.6449.212333.862543@giles.gnomon.org.uk> <20040624035001.GG13225@dumbo.pobox.com> <20040624130742.GC3747@verdi> <20040624144946.GI13225@dumbo.pobox.com> <16602.63002.437751.557545@giles.gnomon.org.uk> <20040624175917.GK13225@dumbo.pobox.com> <197394753.20040625152818@brandenburg.com> In-Reply-To: <197394753.20040625152818@brandenburg.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Fri, 25 Jun 2004 14:04:24 +0200 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dave Crocker writes: > MWW> the computer thinks a bit, > MWW> and you get a well-defined PASS or FAIL or NEUTRAL, etc > MWW> response. > > That sounds quite a bit about the old joke about the blank space in a > board that is otherwise filled with equations. The scientist responds > to a query by pointing to it and says "that's where a miracle > happens". > > So, yes, your description does indeed sound simple, but that to be > because you left out all of the interesting stuff. Well, it's _possible_ to leave out the interesting stuff if that's defined as a local matter. If the "SPF publisher" is responsible for interpreting his own policy, which is queried via RPC by mail recipients, then there's no reason to specify the interesting stuff as an internet standard. The "SPF publisher" need not run any software server - something like the pobox SPF wizard can easily provide that service. I'd be happy to provide such a wizard. Arnt From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 09:22:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28952 for ; Fri, 25 Jun 2004 09:22:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PDBwSo072389; Fri, 25 Jun 2004 06:11:58 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5PDBwQG072388; Fri, 25 Jun 2004 06:11:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PDBtTL072380 for ; Fri, 25 Jun 2004 06:11:57 -0700 (PDT) (envelope-from rand@sendmail.com) Received: from righton.sendmail.com (ns.sendmail.com [209.246.26.10]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i5PDBle0025842 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 25 Jun 2004 06:11:47 -0700 Received: from sendmail.com (1234bhost111.starwoodbroadband.com [12.182.69.111]) (authenticated bits=0) by righton.sendmail.com (8.12.11/8.12.11) with ESMTP id i5PDBjZM082439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 25 Jun 2004 06:11:46 -0700 (PDT) (envelope-from rand@sendmail.com) Message-ID: <40DC2497.50302@sendmail.com> Date: Fri, 25 Jun 2004 09:11:51 -0400 From: Rand Wacker User-Agent: Mozilla Thunderbird 0.5 (Macintosh/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John R Levine CC: "Hallam-Baker, Phillip" , "ietf-mxcomp@imc.org" , "mengwong@dumbo.pobox.com" Subject: Re: Unified SPF: block versus factored records for HELO and MTAMA ark scopes References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit John R Levine wrote: >>Even on a UNIX box there are good reasons to prefer a per thread model >>to a per process model, process creation and teardown in UNIX is only >>lightweight compared to other O/S. > > Depends how big the process is. Forking sendmail takes forever, but > qmail's server is small and snappy. I realize that one can do threads on > Unix boxes, but I don't think that many MTAs actually do so. I'm not going to disagree that forking on Unix takes longer than utilizing a long-running thread, so that's why we (Sendmail) have been implementing these checks in external milters, which are long-running threaded processes which the MTA can talk to. Existing perceptions of architecture should not be a major burden on the protocol design process; most of those perceptions are out-of-date anyways. ;) -Rand From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 09:31:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29230 for ; Fri, 25 Jun 2004 09:31:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PDKE9d073624; Fri, 25 Jun 2004 06:20:14 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5PDKE3Y073623; Fri, 25 Jun 2004 06:20:14 -0700 (PDT) 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.9) with ESMTP id i5PDKEEQ073617 for ; Fri, 25 Jun 2004 06:20:14 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from pool-522.denpasar.indo.net.id (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i5PDJAl20708; Fri, 25 Jun 2004 06:19:20 -0700 Date: Fri, 25 Jun 2004 21:16:54 +0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1018376265.20040625211654@brandenburg.com> To: Arnt Gulbrandsen CC: Meng Weng Wong , Dave Crocker , IETF MARID WG Subject: Re: Unified SPF: block versus factored records for HELO and MTAMAark scopes In-Reply-To: References: <40D9C1DA.9090103@ehsco.com> <20040623210515.GF13225@dumbo.pobox.com> <1088031424.23891.85.camel@ddev.mail-abuse.org> <16602.6449.212333.862543@giles.gnomon.org.uk> <20040624035001.GG13225@dumbo.pobox.com> <20040624130742.GC3747@verdi> <20040624144946.GI13225@dumbo.pobox.com> <16602.63002.437751.557545@giles.gnomon.org.uk> <20040624175917.GK13225@dumbo.pobox.com> <197394753.20040625152818@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: Content-Transfer-Encoding: 7bit Arnt, >> So, yes, your description does indeed sound simple, but that to be >> because you left out all of the interesting stuff. AG> Well, it's _possible_ to leave out the interesting stuff if that's AG> defined as a local matter. If it were strictly a local matter, it would not need to be published in the DNS. The problem is that the receiving SMTP server is required to interpret the SPF policy that is published by a sender some indeterminate number of MTA hops upstream. That is very much NOT local. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 09:32:49 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29357 for ; Fri, 25 Jun 2004 09:32:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PDQM1d074015; Fri, 25 Jun 2004 06:26:22 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5PDQMeR074014; Fri, 25 Jun 2004 06:26:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from aismtp3g.bellsouth.com (aismtp3g.bellsouth.com [139.76.165.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PDQMhV073999 for ; Fri, 25 Jun 2004 06:26:22 -0700 (PDT) (envelope-from Damon.Sauer@BellSouth.com) Received: from 01al10015010113.ad.bls.com ([90.152.52.35] [90.152.52.35]) by aismtp3g.bellsouth.com with ESMTP for ietf-mxcomp@imc.org; Fri, 25 Jun 2004 09:26:16 -0400 Content-Class: urn:content-classes:message Subject: DNS/MTA mix MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Fri, 25 Jun 2004 08:26:11 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: normal Message-Id: <38363D9940D92A458010AAE24D162EB9B7D311@bremocog-55> Thread-Topic: Unified SPF: block versus factored records for HELO and MTAMA ark scopes Thread-Index: AcRatnJDdoaiH5S7TI6BtkHTfhRWOgAAMavQ From: "Sauer, Damon" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5PDQMhV074009 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit First of all, let me apologize before hand for not being very lengthy with my question. Would a solution that required a caching DNS process on the MTA be a show stopper? I didn't get much valuable feedback on a previous post, so armed with some very wise input from Hadmut, I am trying to put together another suggestion. It however hinges on the feedback to my above question. Regards, Damon Sauer ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 113 From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 09:45:22 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00173 for ; Fri, 25 Jun 2004 09:45:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PDbGew076265; Fri, 25 Jun 2004 06:37:16 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5PDbGRc076264; Fri, 25 Jun 2004 06:37:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5PDbFvs076257 for ; Fri, 25 Jun 2004 06:37:15 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id 7012D1A6D0; Fri, 25 Jun 2004 15:37:16 +0200 (CEST) Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) by bra.gulbrandsen.priv.no (Postfix) with SMTP id 8D2441A6D5; Fri, 25 Jun 2004 15:37:10 +0200 (CEST) Message-Id: From: Arnt Gulbrandsen To: Dave Crocker Subject: Re: Unified SPF: block versus factored records for HELO and MTAMAark scopes Cc: Meng Weng Wong , Dave Crocker , IETF MARID WG References: <40D9C1DA.9090103@ehsco.com> <20040623210515.GF13225@dumbo.pobox.com> <1088031424.23891.85.camel@ddev.mail-abuse.org> <16602.6449.212333.862543@giles.gnomon.org.uk> <20040624035001.GG13225@dumbo.pobox.com> <20040624130742.GC3747@verdi> <20040624144946.GI13225@dumbo.pobox.com> <16602.63002.437751.557545@giles.gnomon.org.uk> <20040624175917.GK13225@dumbo.pobox.com> <197394753.20040625152818@brandenburg.com> <1018376265.20040625211654@brandenburg.com> In-Reply-To: <1018376265.20040625211654@brandenburg.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Fri, 25 Jun 2004 15:38:36 +0200 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dave Crocker writes: > If it were strictly a local matter, it would not need to be published > in the DNS. > > The problem is that the receiving SMTP server is required to interpret > the SPF policy that is published by a sender some indeterminate > number of MTA hops upstream. > > That is very much NOT local. Right. I'd like the publication to contain only an address/port. The receiving SMTP sender looks the address up, makes an RPC to the published address (e.g. using UDP, although BXXP is a possibility too), receives a well-defined FAIL/PASS/NEUTRAL answer, and that's it. The address/port may be located at the site that makes the policy, or it may be at a third party which offers a wizard like that Pobox offers for SPF. Arnt From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 09:48:09 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00262 for ; Fri, 25 Jun 2004 09:48:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PDfLMK076800; Fri, 25 Jun 2004 06:41:21 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5PDfLti076799; Fri, 25 Jun 2004 06:41:21 -0700 (PDT) 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.9) with ESMTP id i5PDfG25076776 for ; Fri, 25 Jun 2004 06:41:16 -0700 (PDT) (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 C00F91335A8; Fri, 25 Jun 2004 09:41:17 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 6EC386E5; Fri, 25 Jun 2004 09:41:17 -0400 (EDT) Date: Fri, 25 Jun 2004 09:41:17 -0400 From: Meng Weng Wong To: Arnt Gulbrandsen Cc: IETF MARID WG Subject: Re: Unified SPF: RPC factored lookups = DVP Message-ID: <20040625134117.GK10659@dumbo.pobox.com> References: <16602.6449.212333.862543@giles.gnomon.org.uk> <20040624035001.GG13225@dumbo.pobox.com> <20040624130742.GC3747@verdi> <20040624144946.GI13225@dumbo.pobox.com> <16602.63002.437751.557545@giles.gnomon.org.uk> <20040624175917.GK13225@dumbo.pobox.com> <197394753.20040625152818@brandenburg.com> <1018376265.20040625211654@brandenburg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Jun 25, 2004 at 03:38:36PM +0200, Arnt Gulbrandsen wrote: | | Right. I'd like the publication to contain only an address/port. The | receiving SMTP sender looks the address up, makes an RPC to the | published address (e.g. using UDP, although BXXP is a possibility too), | receives a well-defined FAIL/PASS/NEUTRAL answer, and that's it. | | The address/port may be located at the site that makes the policy, or it | may be at a third party which offers a wizard like that Pobox offers | for SPF. For the record, the design you describe above has been fleshed out --- as DVP. It was not submitted to this WG but I wanted to mention it for completeness. If anyone's keeping track of MARID/LMAP-family proposals, this should be on the list. http://www.exploits.org/dvp/ From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 10:13:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02415 for ; Fri, 25 Jun 2004 10:13:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PE3389078099; Fri, 25 Jun 2004 07:03:03 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5PE33ia078098; Fri, 25 Jun 2004 07:03:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PE32uj078091 for ; Fri, 25 Jun 2004 07:03:03 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00930; Fri, 25 Jun 2004 10:03:00 -0400 (EDT) Message-Id: <200406251403.KAA00930@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-mxcomp@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-marid-rationale-00.txt Date: Fri, 25 Jun 2004 10:03:00 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the MTA Authorization Records in DNS Working Group of the IETF. Title : Behind The Curtain: An Apology for Sender ID Author(s) : M. Wong Filename : draft-ietf-marid-rationale-00.txt Pages : 19 Date : 2004-6-24 The architecture of Sender ID follows from a set of design decisions. Those decisions were motivated by philosophical, engineering, and political considerations. This document reviews some of the important choice that distinguish Sender ID from alternative possibilities in the same space. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marid-rationale-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-marid-rationale-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-marid-rationale-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-25102517.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-marid-rationale-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-marid-rationale-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-25102517.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 10:24:12 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03577 for ; Fri, 25 Jun 2004 10:24:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PE6L8h078315; Fri, 25 Jun 2004 07:06:21 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5PE6LxZ078314; Fri, 25 Jun 2004 07:06:21 -0700 (PDT) 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.9) with ESMTP id i5PE6LSY078308 for ; Fri, 25 Jun 2004 07:06:21 -0700 (PDT) (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 B9D361335AB; Fri, 25 Jun 2004 10:06:22 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 8397F69F; Fri, 25 Jun 2004 10:06:22 -0400 (EDT) Date: Fri, 25 Jun 2004 10:06:22 -0400 From: Meng Weng Wong To: Dave Crocker Cc: Meng Weng Wong , "'IETF MARID WG'" Subject: CSV details Message-ID: <20040625140622.GP13225@dumbo.pobox.com> References: <40D9C1DA.9090103@ehsco.com> <20040623210515.GF13225@dumbo.pobox.com> <1088031424.23891.85.camel@ddev.mail-abuse.org> <16602.6449.212333.862543@giles.gnomon.org.uk> <20040624035001.GG13225@dumbo.pobox.com> <20040624130742.GC3747@verdi> <20040624144946.GI13225@dumbo.pobox.com> <16602.63002.437751.557545@giles.gnomon.org.uk> <20040624175917.GK13225@dumbo.pobox.com> <197394753.20040625152818@brandenburg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <197394753.20040625152818@brandenburg.com> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Jun 25, 2004 at 03:28:18PM +0800, Dave Crocker wrote: | MWW> In CSV, | MWW> http://www.jlc.net/MARID/CSV/draft-ietf-marid-csv-intro-00.html#anchor11 | MWW> suggests that you do authentication by doing a A lookup of | MWW> the HELO name; | | It's not a "suggestion". It is a "specification". The differences is | important. CSV is very simple and constrained. It is entirely based on | the SMTP HELO. | The text I was referring to said: There is no universal method to authenticate that a host is correctly identifying itself. For most email purposes, it will be sufficient to show that the EHLO domain name forward-resolves to the IP address. "For most email purposes" looks like a loophole to me, which is why I was requesting clarification. If it said "do an A/AAAA lookup on the HELO domain name; the client IP must appear on the list of returned addresses", I would feel I had a better understanding. As things stand now, one could read the draft as saying "for most email purposes, a forward lookup is sufficient; for other purposes, you may need to do an SPF evaluation against the HELO domain name" in which case SPF would be compatible with, and even a part of, the CSV concept. From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 10:54:05 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06551 for ; Fri, 25 Jun 2004 10:54:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PEf8RL080812; Fri, 25 Jun 2004 07:41:08 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5PEf7Fh080811; Fri, 25 Jun 2004 07:41:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from goose.ehsco.com (goose.ehsco.com [207.65.203.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PEf3AP080802 for ; Fri, 25 Jun 2004 07:41:03 -0700 (PDT) (envelope-from ehall@ehsco.com) Received: from [207.65.71.20] (unknown [207.65.71.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Eric A. Hall", Issuer "Network Technology Research Group Certificate Authority" (verified OK)) by goose.ehsco.com (Postfix ) with ESMTP id 6FD195FF1F; Fri, 25 Jun 2004 09:41:04 -0500 (CDT) Message-ID: <40DC394F.2080707@ehsco.com> Date: Fri, 25 Jun 2004 09:40:15 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Meng Weng Wong Cc: Arnt Gulbrandsen , IETF MARID WG Subject: Re: Unified SPF: RPC factored lookups = DVP References: <16602.6449.212333.862543@giles.gnomon.org.uk> <20040624035001.GG13225@dumbo.pobox.com> <20040624130742.GC3747@verdi> <20040624144946.GI13225@dumbo.pobox.com> <16602.63002.437751.557545@giles.gnomon.org.uk> <20040624175917.GK13225@dumbo.pobox.com> <197394753.20040625152818@brandenburg.com> <1018376265.20040625211654@brandenburg.com> <20040625134117.GK10659@dumbo.pobox.com> In-Reply-To: <20040625134117.GK10659@dumbo.pobox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/25/2004 8:41 AM, Meng Weng Wong wrote: > On Fri, Jun 25, 2004 at 03:38:36PM +0200, Arnt Gulbrandsen wrote: > | > | Right. I'd like the publication to contain only an address/port. The > | receiving SMTP sender looks the address up, makes an RPC to the > | published address (e.g. using UDP, although BXXP is a possibility too), > | receives a well-defined FAIL/PASS/NEUTRAL answer, and that's it. > For the record, the design you describe above has been > fleshed out --- as DVP. > http://www.exploits.org/dvp/ That's similar to but barely a fraction of the functionality that Arnt is describing. DVP as described therein only says whether or not an address is valid, while Arnt is saying that the 'sender authorization' problem in its entirety can be handled by such a query-response system. There's a lot to be said for such an approach. The DNS overhead would be reduced to SRV entries. The computational load would be linked to the sender's volume instead of the recipient's volume. Etc. Arnt needs to make some time to write up his proposal still. :) -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 10:59:28 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07235 for ; Fri, 25 Jun 2004 10:59:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PEjtZm081163; Fri, 25 Jun 2004 07:45:55 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5PEjt6t081162; Fri, 25 Jun 2004 07:45:55 -0700 (PDT) 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.9) with ESMTP id i5PEjsM8081156 for ; Fri, 25 Jun 2004 07:45:54 -0700 (PDT) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id D345AE083E; Fri, 25 Jun 2004 10:45:52 -0400 (EDT) Date: Fri, 25 Jun 2004 10:45:52 -0400 From: John Leslie To: Meng Weng Wong Cc: Dave Crocker , "'IETF MARID WG'" Subject: Re: CSV details Message-ID: <20040625144552.GI3747@verdi> References: <20040623210515.GF13225@dumbo.pobox.com> <1088031424.23891.85.camel@ddev.mail-abuse.org> <16602.6449.212333.862543@giles.gnomon.org.uk> <20040624035001.GG13225@dumbo.pobox.com> <20040624130742.GC3747@verdi> <20040624144946.GI13225@dumbo.pobox.com> <16602.63002.437751.557545@giles.gnomon.org.uk> <20040624175917.GK13225@dumbo.pobox.com> <197394753.20040625152818@brandenburg.com> <20040625140622.GP13225@dumbo.pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040625140622.GP13225@dumbo.pobox.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Meng Weng Wong wrote: > > The text I was referring to said: > > There is no universal method to authenticate that a host is > correctly identifying itself. For most email purposes, it > will be sufficient to show that the EHLO domain name > forward-resolves to the IP address. For context, let me quote the rest of section 5.2: ] ] CSV usually returns the list of IP addresses in the reply to the ] SRV query. The Host Name Authentication appendix gives advice on ] how to proceed if no list is returned. ] ] If the list is returned and the actual IP address is in it, the ] receiving SMTP server SHOULD consider the EHLO domain name to be ] authenticated. Conversely, if the list is returned and the ] actual IP address is not in it, the assertion of the EHLO domain ] name SHOULD be considered incorrect, and an error returned. > "For most email purposes" looks like a loophole to me, which > is why I was requesting clarification. The point we intended was that this level of authentication (finding a matching IP address in the response to a forward DNS query) is not sufficiently strong for "all" purposes. If you follow the text, it becomes clear (IMHO) that CSV recommends, at the SHOULD level, accepting this as authentication. > If it said "do an A/AAAA lookup on the HELO domain name; the > client IP must appear on the list of returned addresses", I > would feel I had a better understanding. But there's no reason to say that: it's implied in the SRV query. We could, of course, quibble about whether the SHOULDs should be MUSTs: I'm sure we're open to discussion about that. We tend to be rather conservative in using "MUST". > As things stand now, one could read the draft as saying "for > most email purposes, a forward lookup is sufficient; for > other purposes, you may need to do an SPF evaluation against > the HELO domain name" in which case SPF would be compatible > with, and even a part of, the CSV concept. Try though I might, I cannot read it that way. -- John Leslie From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 11:29:11 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10591 for ; Fri, 25 Jun 2004 11:29:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PFF9te084007; Fri, 25 Jun 2004 08:15:09 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5PFF9k6084006; Fri, 25 Jun 2004 08:15:09 -0700 (PDT) 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.9) with ESMTP id i5PFF5gB083998 for ; Fri, 25 Jun 2004 08:15:08 -0700 (PDT) (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 i5PFF57S032700; Fri, 25 Jun 2004 17:15:05 +0200 Received: from danisch.de (localhost [127.0.0.1]) by andromeda.dresden.danisch.de (8.12.11/8.12.11/Debian-5) with ESMTP id i5PFEf0k029486; Fri, 25 Jun 2004 17:14:41 +0200 Message-ID: <40DC4161.3080503@danisch.de> Date: Fri, 25 Jun 2004 17:14:41 +0200 From: Hadmut Danisch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040528 Debian/1.6-7 X-Accept-Language: de-de MIME-Version: 1.0 To: Hector Santos CC: "Hallam-Baker, Phillip" , MARID Subject: Re: Violiates US ECPA: Re: Sender identification is not the answer References: <01b601c45a80$02344430$6401a8c0@hdev1> In-Reply-To: <01b601c45a80$02344430$6401a8c0@hdev1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hector, Hector Santos wrote: >This is not a joke. I am dead serious about this. I changed the subject >line. > >What is quickly becoming a parody is how designs are being discussed; that >A) are not going to work very well in the first place, b) increase DNS >overhead, c) increase and promote the network transport payload and d) >violiates and conflicts with US ECPA provisions and yet doesn't even address >the two fundamental mandates of CANSPAM - true sender authentication and >topic identification. > > I, as a non-american, find your postings rather difficult to understand. I learned that you seem to blame someone for violating any laws, but I can't see what exactly is your point. Could you be a little bit more verbose and elaborate your statement to give others - or at least me - a chance to understand what you are talking about. I'm not familiar with US ECPA, I don't even know what this is. It would be helpful if you told me what section of that law (I guess it is a law) you are referring to and why. If you are talking about what I guess you are talking about, you might be correct. After all, there is a law in germany too, which prohibits what I believe you were trying to say. Please accept that it is much more difficult for me as a foreigner to follow such statements about US law. Maybe you could provide a link to the text of the law, give a precise citation of the paragraph or section, and explain, how in detail it is violated. I apologize if this has already been mentioned, but I didn't get it. Sorry. I would also be interested in your claims a,b, and c, escpecially if you could explain them. regards Hadmut From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 12:56:50 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22459 for ; Fri, 25 Jun 2004 12:56:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PGjIja090821; Fri, 25 Jun 2004 09:45:18 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5PGjIWJ090820; Fri, 25 Jun 2004 09:45:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.pan-am.ca (205-200-6-46.static.mts.net [205.200.6.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PGjFXh090812 for ; Fri, 25 Jun 2004 09:45:17 -0700 (PDT) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: Sender identification is not the answer MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 25 Jun 2004 11:45:17 -0500 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA8E8@srv1.pan-am.ca> X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Sender identification is not the answer Thread-Index: AcRaN5XNGPdCEgSAQam8JpF6PbpRQAAm5cNg From: "Gordon Fecyk" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5PGjHXh090815 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > Like the war on terror, this war on spam is causing us to > lose focus and > make the assumption that the solution is to punish everyone, restrict > everyone's freedom, and monitor everyone's actions since we may all be > spammers. You forgot the patriotic music in this post - you need a good tune like The Graduate March, America The Beautiful, God Save the Queen or maybe The Star Spangled Banner to really hit home with _this_ speech. /me ducks -- PGP key (0x0AFA039E): Sometimes it's hard to tell where the game ends and where reality bites, er, begins. From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 14:17:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29902 for ; Fri, 25 Jun 2004 14:17:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PI0cOG096551; Fri, 25 Jun 2004 11:00:38 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5PI0cQh096550; Fri, 25 Jun 2004 11:00:38 -0700 (PDT) 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.9) with ESMTP id i5PI0bpK096543 for ; Fri, 25 Jun 2004 11:00:37 -0700 (PDT) (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.34) id 1Bduzq-0003i6-VL for ietf-mxcomp@imc.org; Fri, 25 Jun 2004 13:00:38 -0500 To: "IETF MARID WG" References: <16602.4663.751384.263061@giles.gnomon.org.uk> From: wayne Reply-To: "IETF MARID WG" Date: Fri, 25 Jun 2004 13:00:18 -0500 In-Reply-To: (Tony Finch's message of "Thu, 24 Jun 2004 14:13:44 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: PRA and the dependancy on Resent-* headers. Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.3 required=4.0 tests=AWL,BAYES_00,GREYLIST_ISWHITE autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In Tony Finch writes: > On Thu, 24 Jun 2004, Roy Badami wrote: > >> Any MTA not supporting the Responsible Submitter extension that >> redirects a message from the address listed in the RFC 2821 RCPT TO >> command is nonetheless encouraged to modify the message according >> to (a) and (b) above. >> >> This is clearly what we want, and what we expect (prior to flag day). > > (b) conflicts with the semantics of the Resent- headers specified by > RFC 2822. This should be made more clear. The subject of whether forwarders are supposed to add Resent-* headers came up on the SPF list also. Here is the response I posted there. In one of the IETF jabber sessions, I raised this very point. See the the 15:58:43 entry of: http://www.xmpp.org/ietf-logs/marid@ietf.xmpp.org/2004-04-19.html (I've included a copy of this part of the log at the end of this post) After the jabber session I asked Pete Resnick, the editor of RFC2822 to clarify the issue. He said that when RFC2822 was written, the language about forwarders was intended to be about .forward files. Further, he said, now that the spam discussion has been raised, some consider forwarding services, such as pobox.com, to be gateways rather than forwarders. That is, the email is coming out of the transport system and being re-introduced, just like a mailing list. Now, at the time, I really didn't press Pete on the issue, mostly because Pete didn't seem to be very interested in talking about it. After that one very quick exchange, I let the issue drop. It wasn't very long before I realized that his explantion didn't make much sense. RFC2822 was written in 2001, *long* after both the spam issue and forwarding services like pobox.com had been around. The caller-id PRA algorithm requires unix .forward files to add these headers, so even if you exclude things like pobox.com, even the "original intension" of the RFC2822 language would have to be changed. Also note that the newest version of the Caller-ID PRA algorithm depends on undocumented, non-standard and depreciated headers, such as X-Envelope-To:. Go figure. But, anyway, it is going to be hard to argue against the "interpretation" of RFC2822 by its editor. More over, the AD isn't asking any pointed questions about whether one RFC can standardize stuff that other RFCs seem to frown on. I guess if the IESG doesn't complain, we don't need to worry about it. -wayne The jabber log is: [15:58:53] does RFC2822 allow an email forwarder to modify/add the Resent-* and Sender:headers [15:59:09] Also, you can just use the domain name part of the SRS address [15:59:39] Resent- headers are trace records, they get added to the top of the headers just as Received headers do. [16:00:08] I'm not sure about Sender headers. I think there's only supposed to be one per message, but I've seen examples that have > 1. [16:00:10] On what 2822 allows [16:00:30] pete, [16:00:47] What 2822 "allows" (more to the point, intends as meanings of the fields) is: [16:01:15] Resent-*: Trace fields added by the resender. Matches proposed use. [16:02:01] Sender: Added by the original sender if that differs from the author. But that would invalidate current list use, so it's questionable whether that matches reality. [16:02:03] [16:02:05] RFC2822 and email forwarder [16:02:18] wrs, [16:02:35] My reading of RFC2822 explicitly says that email forwarders are not supposed to use Resent-* [16:02:37] [16:02:42] [16:03:44] all - i'd like to wrap things up as we're coming to the end of the window... [16:03:47] resnick, cts [16:04:37] Shortening what I was going to say: It could be argued that .forward type forwarding is or is not reasonable to use Resent-*. From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 14:49:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02244 for ; Fri, 25 Jun 2004 14:49:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PIfQiP099317; Fri, 25 Jun 2004 11:41:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5PIfQj0099316; Fri, 25 Jun 2004 11:41:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PIfQxY099308 for ; Fri, 25 Jun 2004 11:41:26 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.131.244.249] ([::ffff:216.168.239.87]) (AUTH: LOGIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Fri, 25 Jun 2004 14:41:27 -0400 id 0005C541.40DC71D7.00005F59 Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <43B7A1BD-C6D7-11D8-8404-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: Marshall Rose , Ted Hardie From: Andrew Newton Subject: consensus statement on record syntax and type Date: Fri, 25 Jun 2004 14:41:26 -0400 To: IETF MARID WG X-Mailer: Apple Mail (2.613) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Based on constructive working group discourse, the co-chairs of MARID observe the following: 1) There is consensus within the MARID working group for the use of SPF syntax over other encoding schemes. While this consensus is not unanimous or overwhelming, it is rough consensus. The working group's rough consensus on this issue derives from several considerations; among them is the belief that MARID's output should focus on the short-term needs of MTA authentication (consistent with the charter of the group), and that open-ended extensibility for email policy within a MARID record may lead to problems of interoperability. The co-chairs also note that there were no practical or obvious examples of extensions to a MARID record that could not be represented by the SPF syntax. 2) The consensus for the use of SPF syntax does not preclude continuing work on the PRD and SUBMITTER concepts. The co-chairs note that there has been very constructive discourse on these concepts and that the working group should continue to refine these ideas for use with MARID's output. 3) Despite the working group's consensus for the use of SPF syntax, the co-chairs find that there is no consensus for declaring the SPF specification finished. The co-chairs observe that there are still many unanswered questions regarding extensibility in SPF, specifically how and if SPF modifiers should refer to other policy frameworks and the need to more clearly define default behavior and safe-guard against side-effects caused by unknown SPF modifiers and mechanisms. The co-chairs note that such semantics of extensibility are not specific to any type of syntax or encoding. 4) Finally, the co-chairs observe that the MARID working group has a very strong consensus, though not unanimous, on the reuse of TXT records for initial deployment and on a reuse of TXT syntax in the long term. The consensus is centered around the belief of most participants that a MARID record in TXT form will generally be small enough as to not require DNS over TCP. The co-chairs find that the working group has not come to consensus on the use of a record prefix vs TXT records at the zone apex and has not reached consensus on how to address domains with wildcard MX records. It should be noted that none of the above findings preclude the future re-chartering of MARID to define a new DNS record type and/or a new encoding for that record. To meet the tight deadline this working group as set for itself to have a candidate for a proposed standard by the end of August, 2004, we propose the following schedule of activities: - Due 2004-07-02: Decide if CSV is complimentary, parts to be incorporated, or dropped. - Due 2004-07-08: Decide how MARID output will work with already deployed SPF records (v=spf2?). - Due 2004-07-31: Refine SPF syntax and extensibility semantics. - Due 2004-07-31: Fold in PRD and SUBMITTER. -andy & mtr From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 14:53:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02419 for ; Fri, 25 Jun 2004 14:53:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PIkVCd099563; Fri, 25 Jun 2004 11:46:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5PIkVuJ099562; Fri, 25 Jun 2004 11:46:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PIkVpU099556 for ; Fri, 25 Jun 2004 11:46:31 -0700 (PDT) (envelope-from hkatz@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 25 Jun 2004 11:46:35 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 25 Jun 2004 11:46:28 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 25 Jun 2004 11:46:34 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-fido-msg.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 25 Jun 2004 11:46:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: PRA and the dependancy on Resent-* headers. Date: Fri, 25 Jun 2004 11:46:14 -0700 Message-ID: Thread-Topic: PRA and the dependancy on Resent-* headers. thread-index: AcRa33Yb6rPPIoUvSfepJ+zjuyGQUwABI1WQ From: "Harry Katz" To: "IETF MARID WG" X-OriginalArrivalTime: 25 Jun 2004 18:46:28.0057 (UTC) FILETIME=[B9450C90:01C45AE4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5PIkVpU099557 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Friday, June 25, 2004 11:00 AM, Wayne wrote: > Also note that the newest version of the Caller-ID PRA > algorithm depends on undocumented, non-standard and > depreciated headers, such as X-Envelope-To:. Go figure. The reason we added these headers into the PRA algorithm was to recognize that there are some forwarding MTAs that already insert the equivalent of a Resnt- header into the message and therefore they are already compatible with the Sender ID proposal. Wayne is correct that these are non-standard headers, but it seemed like a relatively benign addition in order to enable forwarders that already add those headers to be deemed compliant. From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 16:42:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11960 for ; Fri, 25 Jun 2004 16:42:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PKTvKR007562; Fri, 25 Jun 2004 13:29:57 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5PKTvi8007561; Fri, 25 Jun 2004 13:29:57 -0700 (PDT) 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.9) with ESMTP id i5PKTurd007550 for ; Fri, 25 Jun 2004 13:29:56 -0700 (PDT) (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 56A18132CDB; Fri, 25 Jun 2004 16:29:59 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 297A9612; Fri, 25 Jun 2004 16:29:59 -0400 (EDT) Date: Fri, 25 Jun 2004 16:29:59 -0400 From: Meng Weng Wong To: John Leslie Cc: "'IETF MARID WG'" Subject: Re: CSV details Message-ID: <20040625202959.GD16052@dumbo.pobox.com> References: <1088031424.23891.85.camel@ddev.mail-abuse.org> <16602.6449.212333.862543@giles.gnomon.org.uk> <20040624035001.GG13225@dumbo.pobox.com> <20040624130742.GC3747@verdi> <20040624144946.GI13225@dumbo.pobox.com> <16602.63002.437751.557545@giles.gnomon.org.uk> <20040624175917.GK13225@dumbo.pobox.com> <197394753.20040625152818@brandenburg.com> <20040625140622.GP13225@dumbo.pobox.com> <20040625144552.GI3747@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040625144552.GI3747@verdi> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Jun 25, 2004 at 10:45:52AM -0400, John Leslie wrote: | ] CSV usually returns the list of IP addresses in the reply to the | ] SRV query. The Host Name Authentication appendix gives advice on | ] how to proceed if no list is returned. | ] | ] If the list is returned and the actual IP address is in it, the | ] receiving SMTP server SHOULD consider the EHLO domain name to be | ] authenticated. Conversely, if the list is returned and the | ] actual IP address is not in it, the assertion of the EHLO domain | ] name SHOULD be considered incorrect, and an error returned. OK, what happens if the list is not returned? From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 16:53:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12752 for ; Fri, 25 Jun 2004 16:53:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PKgEs1008510; Fri, 25 Jun 2004 13:42:14 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5PKgE01008509; Fri, 25 Jun 2004 13:42:14 -0700 (PDT) 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.9) with ESMTP id i5PKgDQ2008498 for ; Fri, 25 Jun 2004 13:42:13 -0700 (PDT) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id 18E62E0618; Fri, 25 Jun 2004 16:42:14 -0400 (EDT) Date: Fri, 25 Jun 2004 16:42:14 -0400 From: John Leslie To: Andrew Newton Cc: IETF MARID WG , Marshall Rose , Ted Hardie Subject: Re: consensus statement on record syntax and type Message-ID: <20040625204214.GL3747@verdi> References: <43B7A1BD-C6D7-11D8-8404-000A95B3BA44@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43B7A1BD-C6D7-11D8-8404-000A95B3BA44@hxr.us> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: NB Speaking only for myself -- not any other CSV authors: Andrew Newton wrote: > > Based on constructive working group discourse, the co-chairs of MARID > observe the following: > > 1) There is consensus within the MARID working group for the use of SPF > syntax over other encoding schemes. While this consensus is not > unanimous or overwhelming, it is rough consensus. The working group's > rough consensus on this issue derives from several considerations; > among them is the belief that MARID's output should focus on the > short-term needs of MTA authentication (consistent with the charter of > the group), and that open-ended extensibility for email policy within a > MARID record may lead to problems of interoperability. The co-chairs > also note that there were no practical or obvious examples of > extensions to a MARID record that could not be represented by the SPF > syntax. If by this, the chairs mean to stop attempting to include an XML syntax, I personally agree that it appears to be the only way to complete our work for RFC2822 headers on schedule. If the chairs mean something else, I must beg that they be more explicit what they mean by "SPF syntax". > 2) The consensus for the use of SPF syntax does not preclude continuing > work on the PRD and SUBMITTER concepts. The co-chairs note that there > has been very constructive discourse on these concepts and that the > working group should continue to refine these ideas for use with > MARID's output. I quite agree. > 3) Despite the working group's consensus for the use of SPF syntax, the > co-chairs find that there is no consensus for declaring the SPF > specification finished... I quite agree. > 4) Finally, the co-chairs observe that the MARID working group has a > very strong consensus, though not unanimous, on the reuse of TXT > records... I agree that TXT records are essential to SPF. (CSV, of course, could function without them.) > To meet the tight deadline this working group as set for itself to have > a candidate for a proposed standard by the end of August, 2004, we > propose the following schedule of activities: > - Due 2004-07-02: Decide if CSV is complementary, parts to be > incorporated, or dropped. A most reasonable date: I think we should look for initial agreement during the Monday jabber; plus a few days on the list to see if there's any wild objection. But personally, I think the middle ground is unwise: it should be edited into shape separately, or dropped. Any parts which the working group would prefer not to include can be removed (or perhaps footnoted to refer to different documents). I feel confident that -- with the single exception of whether to query for SRV or query for the SPF TXT record -- consensus could be reached on schedule. I have no such confidence for merging the two together. > - Due 2004-07-08: Decide how MARID output will work with already > deployed SPF records (v=spf2?). Seems reasonable: I have no strong opinion. > - Due 2004-07-31: Refine SPF syntax and extensibility semantics. > - Due 2004-07-31: Fold in PRD and SUBMITTER. These seem dubious. Recall that that's during the ID blackout period for IETF 60. I think it unwise to do these without externally visible documents. Inevitably (IMHO) this will lead to last-minute changes and confusion during our IETF60 meeting. (BTW, how stable does the schedule seem: are we pretty well set for Wednesday, August 4, at 9:00 a.m. and 3:00 p.m.?) -- John Leslie From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 17:10:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13711 for ; Fri, 25 Jun 2004 17:09:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PKwcLJ009767; Fri, 25 Jun 2004 13:58:38 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5PKwcsH009766; Fri, 25 Jun 2004 13:58:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from miz-mishtal.dbc.mtview.ca.us (adsl-64-168-10-250.dsl.scrm01.pacbell.net [64.168.10.250]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PKwcU2009759 for ; Fri, 25 Jun 2004 13:58:38 -0700 (PDT) (envelope-from mrose@dbc.mtview.ca.us) Received: from [IPv6:::1] (localhost [127.0.0.1]) by miz-mishtal.dbc.mtview.ca.us (8.12.10/8.12.9) with ESMTP id i5PKqs53023528; Fri, 25 Jun 2004 13:52:55 -0700 (PDT) In-Reply-To: <20040625204214.GL3747@verdi> References: <43B7A1BD-C6D7-11D8-8404-000A95B3BA44@hxr.us> <20040625204214.GL3747@verdi> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Andrew Newton , IETF MARID WG , Ted Hardie From: Marshall Rose Subject: Re: consensus statement on record syntax and type Date: Fri, 25 Jun 2004 13:52:52 -0700 To: John Leslie X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > If by this, the chairs mean to stop attempting to include an XML > syntax, I personally agree that it appears to be the only way to > complete our work for RFC2822 headers on schedule. that is a fair reading. >> - Due 2004-07-02: Decide if CSV is complementary, parts to be >> incorporated, or dropped. > > A most reasonable date: I think we should look for initial agreement > during the Monday jabber; plus a few days on the list to see if there's > any wild objection. a good plan. >> - Due 2004-07-31: Refine SPF syntax and extensibility semantics. >> - Due 2004-07-31: Fold in PRD and SUBMITTER. > > These seem dubious. Recall that that's during the ID blackout period > for IETF 60. I think it unwise to do these without externally visible > documents. Inevitably (IMHO) this will lead to last-minute changes and > confusion during our IETF60 meeting. right you are. we will revise the dates. > > (BTW, how stable does the schedule seem: are we pretty well set for > Wednesday, August 4, at 9:00 a.m. and 3:00 p.m.?) that is the schedule that i am planning on. /mtr From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 17:18:26 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13980 for ; Fri, 25 Jun 2004 17:18:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PL88mY010284; Fri, 25 Jun 2004 14:08:08 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5PL88gF010283; Fri, 25 Jun 2004 14:08:08 -0700 (PDT) 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.9) with ESMTP id i5PL87Wv010276 for ; Fri, 25 Jun 2004 14:08:08 -0700 (PDT) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id 13A9AE08DA; Fri, 25 Jun 2004 17:08:13 -0400 (EDT) Date: Fri, 25 Jun 2004 17:08:13 -0400 From: John Leslie To: Meng Weng Wong Cc: John Leslie , "'IETF MARID WG'" Subject: Re: CSV details Message-ID: <20040625210813.GM3747@verdi> References: <16602.6449.212333.862543@giles.gnomon.org.uk> <20040624035001.GG13225@dumbo.pobox.com> <20040624130742.GC3747@verdi> <20040624144946.GI13225@dumbo.pobox.com> <16602.63002.437751.557545@giles.gnomon.org.uk> <20040624175917.GK13225@dumbo.pobox.com> <197394753.20040625152818@brandenburg.com> <20040625140622.GP13225@dumbo.pobox.com> <20040625144552.GI3747@verdi> <20040625202959.GD16052@dumbo.pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040625202959.GD16052@dumbo.pobox.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Meng Weng Wong wrote: > > On Fri, Jun 25, 2004 at 10:45:52AM -0400, John Leslie wrote: >|] CSV usually returns the list of IP addresses in the reply to the >|] SRV query. The Host Name Authentication appendix gives advice on >|] how to proceed if no list is returned. >|] >|] If the list is returned and the actual IP address is in it, the >|] receiving SMTP server SHOULD consider the EHLO domain name to be >|] authenticated. Conversely, if the list is returned and the >|] actual IP address is not in it, the assertion of the EHLO domain >|] name SHOULD be considered incorrect, and an error returned. > > OK, what happens if the list is not returned? There are a number of possibilities: 1) There is no list; name is not authorized: Immediate reject, with error. 2) There is no list; name is authorized: An A)ddress query would be pointless. Some other authentication method needs to be used (a local option) or the "Authentication Failed" error needs to be returned. As noted in draft-ietf-marid-csv-csa, "Regardless of what is specified, this receiving SMTP server may decide to refuse the client if their chosen accreditation service returns 'Unknown'." Our expectation is that without a reasonably good accreditation report, an error will be returned. Even with a good accreditation report, there would need to be some indication of _what_ alternative authentication mechanism to use: otherwise an error will need to be returned. Perhaps accreditation services will choose to recommend a method for domains which fall in this category: the information _that_ they do will be publicly available, after all. Please note that this case is equivalent to "we're not going to tell you what IP addresses might be used" -- thus trusting the EHLO name without authentication is really _not_ justified. 3) There is a list, but the DNS server didn't return it. This probably means the list is too long. Our expectation is that only a domain with good accreditation reports will be considered to deserve the time penalty for what will no doubt turn out to be a TCP DNS query; and any others will be refused with an "Authentication Failed" error. If the receiving SMTP server chooses to pursue this further, we would expect it to do a TCP DNS query and check for a match to the remote IP address of the existing SMTP connection. If found, the authentication (as well as the authorization) would be positive. Note, of course, that most of what I've said is a matter of local policy, and IMHO is inappropriate to specify even at a SHOULD level. However, if WG participants feel differently, I'm happy to write some of this into the CSV documents. -- John Leslie From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 17:19:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14108 for ; Fri, 25 Jun 2004 17:19:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PL9mfe010375; Fri, 25 Jun 2004 14:09:48 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5PL9m0t010374; Fri, 25 Jun 2004 14:09:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PL9muX010364 for ; Fri, 25 Jun 2004 14:09:48 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.131.244.249] ([::ffff:216.168.239.87]) (AUTH: LOGIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Fri, 25 Jun 2004 17:09:50 -0400 id 00057F05.40DC949F.00006FF2 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <43B7A1BD-C6D7-11D8-8404-000A95B3BA44@hxr.us> References: <43B7A1BD-C6D7-11D8-8404-000A95B3BA44@hxr.us> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: consensus statement on record syntax and type Date: Fri, 25 Jun 2004 17:09:49 -0400 To: IETF MARID WG X-Mailer: Apple Mail (2.613) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Adjusting for IETF 60 cut-off dates: - Due 2004-07-02: Decide if CSV is complimentary, parts to be incorporated, or dropped. - Due 2004-07-08: Decide how MARID output will work with already deployed SPF records (v=spf2?). - Due 2004-07-18: Refine SPF syntax and extensibility semantics. - Due 2004-07-18: Fold in PRD and SUBMITTER. -andy From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 18:30:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18316 for ; Fri, 25 Jun 2004 18:30:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PMMNf1016377; Fri, 25 Jun 2004 15:22:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5PMMNXj016376; Fri, 25 Jun 2004 15:22:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tidy.obscurity.org (tidy.obscurity.org [66.199.168.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PMMKNH016359 for ; Fri, 25 Jun 2004 15:22:22 -0700 (PDT) (envelope-from ksoze@obscurity.org) Received: by tidy.obscurity.org (Postfix, from userid 1000) id CE02869B18; Fri, 25 Jun 2004 22:22:23 +0000 (UTC) Date: Fri, 25 Jun 2004 15:22:23 -0700 From: Sean Comeau To: IETF MARID WG Subject: Re: Emotions, Encoding, and Ignorance (Was: Why not XML) Message-ID: <20040625222223.GJ30711@obscurity.org> References: <40D88827.5090904@danisch.de> <7242944.1087941275@[10.12.1.26]> <40D9267F.2010309@danisch.de> <20040623104122.GH30711@obscurity.org> <20040623133242.GB16822@republico.estv.ipv.pt> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040623133242.GB16822@republico.estv.ipv.pt> User-Agent: Mutt/1.5.6i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Jun 23, 2004 at 02:32:42PM +0100, Luis Bruno wrote: > > Sean Comeau wrote: > > But people seemed to feel that getting everyone to upgrade their > > nameservers in addition to their MTAs would be an impossible task. > > Not to defend Microsoft's existing design but I was under the impression > that we're using TXT because of bad design choices by the DNS team at > Microsoft. > > Specifically, they can't query for a new RR type when behind an ISA > firewall. > The reason is because BIND needs to be upgraded to support a new RR and that will take a lot more time and effort than just using something deployed nameservers can use. I don't think that the broken behaviour of one particular firewall is a compelling reason not to use a new record type. From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 19:08:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20032 for ; Fri, 25 Jun 2004 19:08:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PMwVQl018112; Fri, 25 Jun 2004 15:58:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5PMwVYH018111; Fri, 25 Jun 2004 15:58:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PMwTBI018101 for ; Fri, 25 Jun 2004 15:58:29 -0700 (PDT) (envelope-from roy+dated+1090796310.a1d50a@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i5PMwUYX098173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 25 Jun 2004 22:58:31 GMT (envelope-from roy+dated+1090796310.a1d50a@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5PMwUku025647 for ; Fri, 25 Jun 2004 23:58:30 +0100 (BST) (envelope-from roy+dated+1090796310.a1d50a@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5PMwUaB025646 for ietf-mxcomp@imc.org; Fri, 25 Jun 2004 23:58:30 +0100 (BST) (envelope-from roy+dated+1090796310.a1d50a@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Fri, 25 Jun 2004 23:58:27 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16604.44562.882715.386142@giles.gnomon.org.uk> Date: Fri, 25 Jun 2004 23:58:26 +0100 To: "Hector Santos" Cc: "Meng Weng Wong" , "David Wall" , "MARID" Subject: Re: Sender identification is not the answer In-Reply-To: <005001c45a55$5d6078e0$6401a8c0@hdev1> References: <0aec01c45a35$531295f0$3201a8c0@rasta> <1088119560.24714.93.camel@ddev.mail-abuse.org> <0c4401c45a44$db8810e0$3201a8c0@rasta> <20040624235433.GN13225@dumbo.pobox.com> <005001c45a55$5d6078e0$6401a8c0@hdev1> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Hector" == Hector Santos writes: Hector> I urge people to review at how this concept of requiring Hector> mail to be accepted by SMTP for delayed rejection [...] There are many people here I suspect who are against delayed rejection. I'm in favour of SMTP-level rejection; I'm in favour (I think) of MTA-generated bounces and/or of C/R systems for mail that is suspect. In my case this has nothing to do with the legal framework in the US or in any other jurisdiction. I simply don't like systems that throw away suspect mail because that interferes with long established technical principles of mail delivery and in particular of making a genuine best effort to either deliver or bounce every message that is accepted by the mail transport. So please don't assume that all MARID/LMAP proponents are in favour of throwing away mail... :-) -roy From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 19:32:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20769 for ; Fri, 25 Jun 2004 19:32:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PNEgmY018917; Fri, 25 Jun 2004 16:14:42 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5PNEg2f018916; Fri, 25 Jun 2004 16:14:42 -0700 (PDT) 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.9) with ESMTP id i5PNEgMa018910 for ; Fri, 25 Jun 2004 16:14:42 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbfujip (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i5PNEal02292; Fri, 25 Jun 2004 16:14:37 -0700 Date: Sat, 26 Jun 2004 07:14:11 +0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <901871525.20040626071411@brandenburg.com> To: John Leslie CC: Meng Weng Wong , "'IETF MARID WG'" Subject: Re: CSV details In-Reply-To: <20040625144552.GI3747@verdi> References: <20040623210515.GF13225@dumbo.pobox.com> <1088031424.23891.85.camel@ddev.mail-abuse.org> <16602.6449.212333.862543@giles.gnomon.org.uk> <20040624035001.GG13225@dumbo.pobox.com> <20040624130742.GC3747@verdi> <20040624144946.GI13225@dumbo.pobox.com> <16602.63002.437751.557545@giles.gnomon.org.uk> <20040624175917.GK13225@dumbo.pobox.com> <197394753.20040625152818@brandenburg.com> <20040625140622.GP13225@dumbo.pobox.com> <20040625144552.GI3747@verdi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit John, >> As things stand now, one could read the draft as saying "for >> most email purposes, a forward lookup is sufficient; for >> other purposes, you may need to do an SPF evaluation against >> the HELO domain name" in which case SPF would be compatible >> with, and even a part of, the CSV concept. JL> Try though I might, I cannot read it that way. Creative interpretation of one's writing is always helpful for learning how to strengthen it against misunderstanding. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 19:38:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21031 for ; Fri, 25 Jun 2004 19:38:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PNTBaG019493; Fri, 25 Jun 2004 16:29:11 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5PNTBwc019492; Fri, 25 Jun 2004 16:29:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5PNT8mY019477 for ; Fri, 25 Jun 2004 16:29:09 -0700 (PDT) (envelope-from roy+dated+1090798152.f21d17@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i5PNTCYX027664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 25 Jun 2004 23:29:13 GMT (envelope-from roy+dated+1090798152.f21d17@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5PNTCJE025811 for ; Sat, 26 Jun 2004 00:29:12 +0100 (BST) (envelope-from roy+dated+1090798152.f21d17@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5PNTCTc025810 for ietf-mxcomp@imc.org; Sat, 26 Jun 2004 00:29:12 +0100 (BST) (envelope-from roy+dated+1090798152.f21d17@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sat, 26 Jun 2004 00:28:56 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16604.46391.763177.721905@giles.gnomon.org.uk> Date: Sat, 26 Jun 2004 00:28:55 +0100 To: Andrew Newton Cc: IETF MARID WG , Marshall Rose , Ted Hardie Subject: Request for clarification (was: consensus statement on record syntax and type) In-Reply-To: <43B7A1BD-C6D7-11D8-8404-000A95B3BA44@hxr.us> References: <43B7A1BD-C6D7-11D8-8404-000A95B3BA44@hxr.us> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sorry, this has been sort of raised by other posters in this thread, but I'm still slightly confused. You say: Andrew> 1) There is consensus within the MARID working group for Andrew> the use of SPF syntax over other encoding schemes. Does this rule out of scope further work on CSV/CSA's use of SRV records (which are certainly not SPF syntax)? Andrew> - Due 2004-07-02: Decide if CSV is complimentary, parts Andrew> to be incorporated, or dropped. What this means depends very much on the answer to my previous question. Is it an option (given rough concensus) to independently advance the draft-marid-core/submitter document set and the draft-marid-csv-* document set to PS, or is their a requirement to produce a single standards track specification? -roy From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 20:27:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22747 for ; Fri, 25 Jun 2004 20:27:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5Q0MECQ022407; Fri, 25 Jun 2004 17:22:14 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5Q0ME0w022406; Fri, 25 Jun 2004 17:22:14 -0700 (PDT) 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.9) with ESMTP id i5Q0MEJe022399 for ; Fri, 25 Jun 2004 17:22:14 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from bbfujip (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i5Q0MAl07336; Fri, 25 Jun 2004 17:22:12 -0700 Date: Sat, 26 Jun 2004 07:35:55 +0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1633845799.20040626073555@brandenburg.com> To: Andrew Newton CC: IETF MARID WG , Marshall Rose , Ted Hardie Subject: Re: consensus statement on record syntax and type In-Reply-To: <43B7A1BD-C6D7-11D8-8404-000A95B3BA44@hxr.us> References: <43B7A1BD-C6D7-11D8-8404-000A95B3BA44@hxr.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Andrew, AN> - Due 2004-07-02: Decide if CSV is complimentary, parts to be AN> incorporated, or dropped. Since this line from your note did not have any lead-in text, I would appreciate some clarification on this. SPF validates individual messages, using author/sender authority for the latest-hop client MTA. CSV also validates the client MTA, but for the entire session, and independent of the particular message traffic. So I am not seeing how to incorporate one into the other. The fact that you listed the alternative of merging suggests that you have something substantive in mind. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 21:26:41 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25906 for ; Fri, 25 Jun 2004 21:26:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5Q0GWhm022117; Fri, 25 Jun 2004 17:16:32 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5Q0GW7d022116; Fri, 25 Jun 2004 17:16:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5Q0GVa1022109 for ; Fri, 25 Jun 2004 17:16:31 -0700 (PDT) (envelope-from roy+dated+1090800994.69f02e@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i5Q0GZYX084862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 26 Jun 2004 00:16:36 GMT (envelope-from roy+dated+1090800994.69f02e@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5Q0GZ2N025958 for ; Sat, 26 Jun 2004 01:16:35 +0100 (BST) (envelope-from roy+dated+1090800994.69f02e@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5Q0GZBa025957 for ietf-mxcomp@imc.org; Sat, 26 Jun 2004 01:16:35 +0100 (BST) (envelope-from roy+dated+1090800994.69f02e@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sat, 26 Jun 2004 01:16:34 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16604.49250.502543.175893@giles.gnomon.org.uk> Date: Sat, 26 Jun 2004 01:16:34 +0100 To: ietf-mxcomp@imc.org Subject: Backward compatibility with deployed SPF records (and choice of domain) X-Mailer: VM 7.18 under Emacs 21.3.1 From: Roy Badami X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit To address a couple of questions that Andrew Newton raised in his concensus statement. 1. Placement of TXT records. The co-chairs find that the working group has not come to consensus on the use of a record prefix vs TXT records at the zone apex and has not reached consensus on how to address domains with wildcard MX records. First off, I don't think anyone's suggested putting the records at the _zone_ apex (ie the delegation point); I'm assuming that the chairs have been spending too much time reading DNSSEC discussion on namedroppers :-) The term 'zone apex' certainly seemed perfectly reasonable to me on first reading, precisely for that reason... The choice is: should the domain of the identity to be verified be used as the owner name of the TXT record, or should the owner name be a subdomain of that domain, constructed by prepending a suitable prefix to the domain of the identity to be verified? If we wish to support backward compatibility with deployed SPF records -- and I'll note that the statement is worded in such a way as to imply the that the question is _how_ we will do this, not _whether_ we will do this -- then of course placing the TXT record anywhere other than at the domain of the identity in question places extra burden on implementation by having to query for records in two places. So I think that if we are going to seek backwards compatibility with SPF then there should be an assumption towards putting the records in the same place, all other things being equal. In fact putting records in two different places whilst maintaining backwards compatibility adds significant conceptual complexibility -- if a record might exist at either example.com or _ep.example.com then what are the implications of someone forging mail from foo@_ep.example.com ? On to the second point, and how to achieve backward compatibility... If we assume that the changes to SPF syntax and semantics are likely to be relatively small between draft-mengwong-spf and the final version of draft-ietf-marid-core (as is currently the case) then it may well make sense for deployed SPF records to simply be interpreted as if they were MARID records. But there are differences between the two drafts; most notably the identity being checked, and also a minor difference in the specification of the mx mechanism. There will, in a few weeks, very probably be a large number of systems checking SPF records (as defined in draft-mengwong-spf) -- quite possible a much larger community than the community that currently publishes SPF records. The Spamassassin team are preparing for a 3.0 release, which will support SPF checks (though admitedly only if Mail::SPF::Query is also installed). Given MARID records are similar, but not identical, to SPF records, and that it is at least possible that there will shortly be a large number of SPF checkers in real world use, I'd like to propose the following strategy: MARID should define syntax versions 1 and 2 (identified by v=spf1 and v=spf2) as identical. MARID-compliant implementations must interpret both of these records identically, and must use the highest understood version record if multiple versions are found (this is the same rule as in SPF). This gives a publisher three choices: a. Publish a syntax version 1 record. This is a valid MARID record and will also be interpreted by the deployed base of SPF checkers according to the semantics of draft-mengwong-spf (assuming it is syntactically also a valid SPF record) b. Publish a syntax version 2 record. This is again a valid MARID record, but will be ignored by the deployed SPF checkers. c. Publish both. In this case, given the rule of using the highest version record that is understood by the checker, MARID checkers will use the syntax 2 record, and deployed SPF checkers will use the version 1 record. Thoughts? -roy From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 21:38:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27619 for ; Fri, 25 Jun 2004 21:38:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5Q1VgER027764; Fri, 25 Jun 2004 18:31:42 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5Q1VgRb027763; Fri, 25 Jun 2004 18:31:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5Q1Vg5C027757 for ; Fri, 25 Jun 2004 18:31:42 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.0.1.153] ([::ffff:64.83.8.178]) (AUTH: LOGIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Fri, 25 Jun 2004 21:31:45 -0400 id 0005C583.40DCD201.000005B3 In-Reply-To: <16604.46391.763177.721905@giles.gnomon.org.uk> References: <43B7A1BD-C6D7-11D8-8404-000A95B3BA44@hxr.us> <16604.46391.763177.721905@giles.gnomon.org.uk> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <95129516-C710-11D8-97B8-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: Marshall Rose , Ted Hardie , IETF MARID WG From: Andrew Newton Subject: Re: Request for clarification (was: consensus statement on record syntax and type) Date: Fri, 25 Jun 2004 21:31:44 -0400 To: Roy Badami X-Mailer: Apple Mail (2.613) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jun 25, 2004, at 7:28 PM, Roy Badami wrote: > Andrew> 1) There is consensus within the MARID working group for > Andrew> the use of SPF syntax over other encoding schemes. > > Does this rule out of scope further work on CSV/CSA's use of SRV > records (which are certainly not SPF syntax)? The question put before the working group dealt with the extensibility of syntax, with the group being concerned that too much extensibility could potentially harm interoperability. SRV syntax is probably not as extensible as SPF syntax. More to the point, the working group did not discuss SRV extensibility in the context of SPF and XML. So the intent is not to rule out CSV/CSA. > Is it an option (given rough concensus) to independently advance the > draft-marid-core/submitter document set and the draft-marid-csv-* > document set to PS, or is their a requirement to produce a single > standards track specification? It is expected that MARID produce a cohesive, sensible, and interoperable specification that meets our charter objectives. That specification may be contained in a single document or among many. CSV's place in that specification is for the working group to decide. -andy From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 21:39:22 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27692 for ; Fri, 25 Jun 2004 21:39:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5Q1Z0mH027921; Fri, 25 Jun 2004 18:35:00 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5Q1Z0rt027920; Fri, 25 Jun 2004 18:35:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5Q1YxJi027910 for ; Fri, 25 Jun 2004 18:35:00 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.0.1.153] ([::ffff:64.83.8.178]) (AUTH: LOGIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Fri, 25 Jun 2004 21:35:05 -0400 id 0005C583.40DCD2C9.00000622 In-Reply-To: <1633845799.20040626073555@brandenburg.com> References: <43B7A1BD-C6D7-11D8-8404-000A95B3BA44@hxr.us> <1633845799.20040626073555@brandenburg.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0C12A60B-C711-11D8-97B8-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: Marshall Rose , Ted Hardie , IETF MARID WG From: Andrew Newton Subject: Re: consensus statement on record syntax and type Date: Fri, 25 Jun 2004 21:35:03 -0400 To: Dave Crocker X-Mailer: Apple Mail (2.613) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jun 25, 2004, at 7:35 PM, Dave Crocker wrote: > So I am not seeing how to incorporate one into the other. The fact > that you listed the alternative of merging suggests that you have > something substantive in mind. We simply listed the possibilities. The prospect of taking some of the concepts from CSV and placing them in SPF has already been discussed on the list, though not in detail. -andy From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 23:05:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01767 for ; Fri, 25 Jun 2004 23:05:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5Q2uEMa033024; Fri, 25 Jun 2004 19:56:14 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5Q2uERD033023; Fri, 25 Jun 2004 19:56:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (ftp.catinthebox.net [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5Q2uDuQ033016 for ; Fri, 25 Jun 2004 19:56:13 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Fri, 25 Jun 2004 23:00:00 -0400 Received: from ([68.156.249.86]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 2029448672; Fri, 25 Jun 2004 22:59:59 -0400 Message-ID: <001501c45b29$1b138f70$6401a8c0@hdev1> From: "Hector Santos" To: "IETF-MXCOMP" Cc: "Dave Crocker" References: <20040623210515.GF13225@dumbo.pobox.com> <1088031424.23891.85.camel@ddev.mail-abuse.org> <16602.6449.212333.862543@giles.gnomon.org.uk> <20040624035001.GG13225@dumbo.pobox.com> <20040624130742.GC3747@verdi> <20040624144946.GI13225@dumbo.pobox.com> <16602.63002.437751.557545@giles.gnomon.org.uk> <20040624175917.GK13225@dumbo.pobox.com> <197394753.20040625152818@brandenburg.com> <20040625140622.GP13225@dumbo.pobox.com> <20040625144552.GI3747@verdi> <901871525.20040626071411@brandenburg.com> Subject: CVS specifics: Accreditation Date: Fri, 25 Jun 2004 22:52:38 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.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: Content-Transfer-Encoding: 7bit Dave, I am currently looking at the CVS (and DNS and CSA) drafts. Please correct any misunderstanding I may have. I'm sure I did not cover everything so I only have a few comments at this point. The main one that jumps out is this Accreditation Concept. The positive design I see is that you generalized it with a suggested format. This is good. As with the reputation (RBL) designs currently in place, it has a standard response concept allowing for a standard implementation and more importantly allowing customers/operators to chose their favorite RBL systems. The negative is that acceditation server bureaus will be limited, at first, and most likely exclusive to specific group of organizations or type of systems. In the overview, it says "chosen" 3. Query a chosen Accreditation Service for the EHLO domain name (see Domain Name Accreditation (DNA) [ID-Marid-CSVDNA]) Based on what I am seeing in the market place, infopreneurs are making these fee based systems. As I read some of the policies at some of these sites, lookups are free, but membership is fee based. Not a problem, but unless someone champions and puts up free DNA site, it seems the CSV idea will be somewhat crippled which means it only be implemented as part of a total suite of other transaction management technologies. In short, there will probably need to be more than a list of acceditation sites to lookup to make it more effective for operators. I guess, if we implemented CVS with some initial supportive DNA sites, we would be able to help promote this sites and even encourage membership. But I do see a need to offer more than one site, if only because one site is "less" expensive than the other. Currently we allow a unlimited list of RBL sites to lookup. By default, out of the box, the top 3 (most popular) are provided. Which brings me to another related note: RBL is one area of optimization I would like to improve upon as it represents a high percentage of the total validation transaction time. If you agree a list of acceditation sites is needed, then this needs to be optimized as well. Thanks -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Fri Jun 25 23:54:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04060 for ; Fri, 25 Jun 2004 23:54:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5Q3afrs036269; Fri, 25 Jun 2004 20:36:41 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5Q3afff036268; Fri, 25 Jun 2004 20:36:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (catinthebox.net [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5Q3aeRj036262 for ; Fri, 25 Jun 2004 20:36:40 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Fri, 25 Jun 2004 23:40:28 -0400 Received: from ([68.156.249.86]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 2031876594; Fri, 25 Jun 2004 23:40:27 -0400 Message-ID: <001601c45b2e$c24ebda0$6401a8c0@hdev1> From: "Hector Santos" To: "Dave Crocker" , "Andrew Newton" Cc: "IETF-MXCOMP" , "Ted Hardie" , "Marshall Rose" References: <43B7A1BD-C6D7-11D8-8404-000A95B3BA44@hxr.us> <1633845799.20040626073555@brandenburg.com> <0C12A60B-C711-11D8-97B8-000A95B3BA44@hxr.us> Subject: Re: consensus statement on record syntax and type Date: Fri, 25 Jun 2004 23:36:18 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.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: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Andrew Newton" To: "Dave Crocker" Cc: "Marshall Rose" ; "Ted Hardie" ; "IETF MARID WG" Sent: Friday, June 25, 2004 9:35 PM Subject: Re: consensus statement on record syntax and type > On Jun 25, 2004, at 7:35 PM, Dave Crocker wrote: > > So I am not seeing how to incorporate one into the other. The fact > > that you listed the alternative of merging suggests that you have > > something substantive in mind. > > We simply listed the possibilities. The prospect of taking some of the > concepts from CSV and placing them in SPF has already been discussed on > the list, though not in detail. Currently our 2821 based Transaction Management System (TMS) has the following specific order of testing: - FILTER, Admin defined White/Black Accept/Reject Rules - RBL, List of Reputation Lookup Sites. - LMAP (SPF, CEP, DMP) - CBV (Call Back Verifier) MARID will replace LMAP which means SPF stays, DMP (currently undocumented) will be deprecated and CEP pulled and replaced with the future MARID (SPF2) Still fresh at reading CSV (combining it with DNA/CSA), from what I see, the only new concept introduced is the "Accreditation" logic and also possibly (need to read more) solving some level of the possible forwarding issues in the LMAP methods. So as a new product feature customer offering, I can see it fit as follows: - FILTER, Admin defined White/Black Accept/Reject Rules - CSV, Accreditation and CSA Lookup per spec - RBL, List of Reputation Lookup Sites. - MARID (SPF, SPF2, CSV-2) - CBV (Call Back Verifier) I should note RBL currently represents 80% of the total rejection, the best method in the industry hence why it is so popular. So it would be hard to replace/remove it as a TMS feature. In any case, I have to read more, but one of the remaining issues would be the forwarding issue with SPF/MARID. So possible concepts discussed in CSV regarding Address-based Authentication may apply in validating the "routed/forwarded" message (CSV-2 in MARID). Also, on a related note, one part that will be a challenge for implemented or support is the idea of a remote SPF domain record/policy defining the sources used for reputation or accreditation lookups. If it is added it will be done as an option (off). So I would be initially oppose to a SPF2 functional specification enforcing such a directive/mechanism. [X] SPF support [_] Honor Reputation Lookup [?] Honor Accreditation Lookup The main reason is because the sysop will want to apply such look ups across the board, not based on what a specific MARID/SPF domain policy says. The odds are very high, the above options would not be made available since RBL is already in place. If anything, Accreditation may be provided and ON by default if its done in a way that allows the sysop to decide what trusted sites to lookup. But overall, I would prefer to continue to have both separate from MARID. This means I also see CVS having a partial role in a MARID based Transaction Management System. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Sat Jun 26 01:37:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09338 for ; Sat, 26 Jun 2004 01:37:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5Q5ReNY054104; Fri, 25 Jun 2004 22:27:40 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5Q5Re4S054103; Fri, 25 Jun 2004 22:27:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [64.139.47.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5Q5RdFr054083 for ; Fri, 25 Jun 2004 22:27:39 -0700 (PDT) (envelope-from gconnor@nekodojo.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by neko-base.nekodojo.org (Postfix) with ESMTP id 548261D651 for ; Fri, 25 Jun 2004 22:27:45 -0700 (PDT) Date: Fri, 25 Jun 2004 22:27:47 -0700 From: Greg Connor To: ietf-mxcomp@imc.org Subject: Re: Backward compatibility with deployed SPF records (and choice of domain) Message-ID: <5358865.1088202467@[10.12.1.26]> In-Reply-To: <16604.49250.502543.175893@giles.gnomon.org.uk> References: <16604.49250.502543.175893@giles.gnomon.org.uk> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit MOstly agreeing with Roy here, but I'm raising a couple of questions that could use extra pairs of eyes and feedback... > 1. Placement of TXT records. > > The co-chairs find that the working group has not come to consensus on > the use of a record prefix vs [unprefixed] TXT records I think I would agree with Roy that allowing MARID-compliant MTAs to check the unprefixed name is desirable. In other words, if MARID-Brand LMAP works substantially similar to SPF-Brand, let's go ahead and use their data. One concern here is that we would want the semantics to be similar enough to not upset or surprise anyone who isn't expecting their data to be used a slightly different way, but I think we are able to do that. (That certainly was the intent of the SenderID merged proposal) In a straight race, I would probably root for the non-prefixed records to win, simply because the underscore might scare and confuse people (it was removed from early versions of SPF for mostly that reason). I do understand the issue that the prefix is intended to address, but I don't think the research we have shows it is anything to worry about. I think most users will not have TXT records of any other type, and of those that do, the records will mostly be small enough to coexist peacefully. I don't have a strong preference in this area, except that backward compatibility would allow MARID to harness and redirect the momentum SPF has built up. (Of course we will be going through the process of getting our own RR so we will eventually have an escape plan) Does anyone have a strong objection to using unprefixed txt records? > 1b. [the working group] has not > reached consensus on how to address domains with wildcard MX records. > Actually I think this one is pretty easy to fix... if there is a wildcard A or wildcard MX record already there, the site should also create a wildcard TXT record. (I really wish we could go back in time and tell people they need to set up MX records for all deliverable domains and hosts and not fallback to A... any chance we could declare the fallback-to-A practice deprecated? It may be officially outside our scope, but it really makes the job of publishing LMAP records a lot harder.) Let me add this sort of related point... 1c. The group has not agreed on an alternate placement for TXT records other than the label exactly matching the (host part of the) identity being checked. I.e. a MARID record at example.com does not cover user@www.example.com. That means: the domain owner should create LMAP records for ALL hosts in his domain that have A or MX records. (Note that a wildcard TXT record does not cover names that have A or MX but no TXT, only names with no defined data at all) Is this something we need to work on more, or should we leave it like that? We talked about looking for the "closest SOA name" and looking there, and applying the TXT record at that location to other subdomains that have no TXT of their own. Another idea might be to have records set up like: example.com. IN TXT "v=xxx1 a mx ptr ?all" ; only for mail @example.com mail1.example.com. IN TXT "v=xxx1 a -all" ; for @mail1.example.com _all.example.com. IN TXT "v=xxx1 -all" ; for @*.example.com if no TXT In this case I would totally support use of the underscore because this is a little bit of an advanced feature anyway, but it doesn't have to be an underscore to work. Then again this could be a performance problem... if most domains don't have TXT records we would have to do a second query to find the SOA and a third to find the higher-level (either example.com or _all.example.com) so I don't want to push too hard for climbing up the chain if there isn't a lot of support for it. Any feedback as to whether we should pursue this any further or just leave it as the domain itself only and no searching at higher levels? > Given MARID records are similar, but not identical, to SPF records, > and that it is at least possible that there will shortly be a large > number of SPF checkers in real world use, I'd like to propose the > following strategy: > > MARID should define syntax versions 1 and 2 (identified by v=spf1 and > v=spf2) as identical. MARID-compliant implementations must interpret > both of these records identically, and must use the highest understood > version record if multiple versions are found (this is the same rule > as in SPF). I think the records will be similar enough that we can honor the original publisher's intentions. However, there's nothing really *wrong* with defining a new prefix. MTAs will need to be revised a bit anyway to be MARID-compliant, and a TXT lookup will still get both records. What would folks in the group think about defining our own prefix like "v=lmap1"? I think this is only really needed in the off chance that the semantics are different enough for people to notice. I expect that people will continue to publish "v=spf1" for a while until the new MARID-compatible MTAs are widespread, then they could publish either. Someone would really only want to publish both if they want one policy for SPF Classic and a different policy for MARID-Brand LMAP. (I called it LMAP because that seems to be a better name for the protocol, and it leaves the door open for MARID-the-group to work on and publish other stuff. The protocol is important but it's not the only important thing the group has worked on :) -- Greg Connor From owner-ietf-mxcomp@mail.imc.org Sat Jun 26 02:27:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24978 for ; Sat, 26 Jun 2004 02:27:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5Q6LagM079589; Fri, 25 Jun 2004 23:21:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5Q6La1Q079588; Fri, 25 Jun 2004 23:21:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (ntbbs.winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5Q6LZ5L079576 for ; Fri, 25 Jun 2004 23:21:36 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Sat, 26 Jun 2004 02:25:19 -0400 Received: from ([68.156.249.86]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 2041766860; Sat, 26 Jun 2004 02:25:18 -0400 Message-ID: <007201c45b45$c9b722f0$6401a8c0@hdev1> From: "Hector Santos" To: References: <16604.49250.502543.175893@giles.gnomon.org.uk> <5358865.1088202467@[10.12.1.26]> Subject: Re: Backward compatibility with deployed SPF records (and choice of domain) Date: Sat, 26 Jun 2004 02:21:12 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.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: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Greg Connor" To: Sent: Saturday, June 26, 2004 1:27 AM Subject: Re: Backward compatibility with deployed SPF records (and choice of domain) > > In a straight race, I would probably root for the non-prefixed records to > win, simply because the underscore might scare and confuse people (it was > removed from early versions of SPF for mostly that reason). I do > understand the issue that the prefix is intended to address, but I don't > think the research we have shows it is anything to worry about. Probably nothing, but there might be some ergonomic issues here. The following was probably a customer misunderstanding, but recently I took a customer survey to find out who has published SPF or MCEP (_EP.) domains and how (access to DNS). One customer provided the following reason for not implementing the _EP host name for MCEP support. ----- Original Survey Message And Response ----- > We need to know the following: > > With WCSAP, it has the LMAP features, SPF and CEP. Please check all that > applies: > > [X] I have defined an SPF domain policy for my Domains in DNS > [_] I have defined an _EP domain policy for my DOMAINS in DNS > [X] I have not defined any for the following reason: > Please state reason: My DNS host rejected the _EP entry as an invalid host name. I contacted their technical support regarding this and they stated that the leading underscore was a violation of the rules. When I pointed out that this was a requirement for CEP as defined by Microsoft they said they would look into it. Currently they have not gotten back to me. > DNS manager: You manage DNS as follows > > [_] Internal DNS server > [_] Via my ISP using a DNS manager they offer > [X] Other www.dnspark.net --- Back to me --- Like I said, I'm sure it was a customer understanding, but it is happen once, so I'm sure it will happen more. From my standpoint, it was a non-issue for implementation and it did take alittle extra "documentation" to explain it. Anyway, I don't see it as an issue because the way I see it down the road, at some point we will be adding a Setup Wizard and Configuration to help customers create the DNS/MARID entry either automatically or as a Cut/Paste item to be sent to their ISP/DNS server provider, maybe via email for example. This is actually not a bad idea. Back in the fidonet days, before a new mail server was allowed to be put online and connect to the network, he had to install the compliant software and and then send an direct email (called netmail) to his local area network mail host (akin to an ISP today I guess) with a fix set of host registration information that got him into the network node list (akin to DNS). The network host then would test the new mail server for network compliance and only then was his "address" (domain) added to the world wide network node list. I am not in no way suggesting this, but these day, it will help the mail operator from A to Z, from installing/upgrading a system, finding a MARID compliant ISP to register with, sending DNS/MARID information to the ISP to setup, etc. And if the new pressures from the industry asking the ISP to take more responsibility take hold, the ISP might want to do some level of "validation" or background checking before adding the information to his DNS servers. In Fidonet, it was a requirement for network membership. For the Internet, it would just be an optional necessity and prudent/smart business move to help minimize security/spam issues. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Sat Jun 26 04:32:58 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28306 for ; Sat, 26 Jun 2004 04:32:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5Q8LuI8018794; Sat, 26 Jun 2004 01:21:56 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5Q8Lubg018793; Sat, 26 Jun 2004 01:21:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from goose.ehsco.com (goose.ehsco.com [207.65.203.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5Q8LtQq018773 for ; Sat, 26 Jun 2004 01:21:56 -0700 (PDT) (envelope-from ehall@ehsco.com) Received: from [207.65.71.20] (unknown [207.65.71.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Eric A. Hall", Issuer "Network Technology Research Group Certificate Authority" (verified OK)) by goose.ehsco.com (Postfix ) with ESMTP id 67D743E960 for ; Sat, 26 Jun 2004 03:21:53 -0500 (CDT) Message-ID: <40DD31E8.9040900@ehsco.com> Date: Sat, 26 Jun 2004 03:20:56 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: ietf-mxcomp@imc.org Subject: Re: Backward compatibility with deployed SPF records (and choice of domain) References: <16604.49250.502543.175893@giles.gnomon.org.uk> <5358865.1088202467@[10.12.1.26]> In-Reply-To: <5358865.1088202467@[10.12.1.26]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/26/2004 12:27 AM, Greg Connor wrote: > Does anyone have a strong objection to using unprefixed txt records? If the migration to a new RR requires queries for ALL (NOTE: this should be avoided if possible), then it will be easier to implement if there is a prefix. TXT and new RRs can both be fetched with a single query without worrying about overload conditions from SOA, NS, MX, etc. As long as the magic label is short enough, then there's really no reason not to do it. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-ietf-mxcomp@mail.imc.org Sat Jun 26 05:05:39 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29083 for ; Sat, 26 Jun 2004 05:05:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5Q8viEI031608; Sat, 26 Jun 2004 01:57:44 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5Q8vihG031607; Sat, 26 Jun 2004 01:57:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [64.139.47.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5Q8vhjx031598 for ; Sat, 26 Jun 2004 01:57:44 -0700 (PDT) (envelope-from gconnor@nekodojo.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by neko-base.nekodojo.org (Postfix) with ESMTP id B30CB1D651; Sat, 26 Jun 2004 01:57:44 -0700 (PDT) Date: Sat, 26 Jun 2004 01:57:46 -0700 From: Greg Connor To: "Eric A. Hall" Cc: ietf-mxcomp@imc.org Subject: Re: Backward compatibility with deployed SPF records (and choice of domain) Message-ID: <17958302.1088215066@[10.12.1.26]> In-Reply-To: <40DD31E8.9040900@ehsco.com> References: <40DD31E8.9040900@ehsco.com> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > On 6/26/2004 12:27 AM, Greg Connor wrote: > >> Does anyone have a strong objection to using unprefixed txt records? > --"Eric A. Hall" wrote: > If the migration to a new RR requires queries for ALL (NOTE: this should > be avoided if possible), then it will be easier to implement if there is a > prefix. TXT and new RRs can both be fetched with a single query without > worrying about overload conditions from SOA, NS, MX, etc. > > As long as the magic label is short enough, then there's really no reason > not to do it. Hmm, I'm not sure if that was an objection? :) Anyway, I thought one of Ed's points in his presentation was that adding a _prefix had its own set of problems, and wasn't recommended... Or maybe it was just wildcards that had the problem, but as PHB pointed out, you can define a wildcard and the prefixed and non-prefixed versions will both work. You can either have fine-grained control, or wildcards, but not both. I don't see a strong technical reason why not, but I also don't see a strong reason reason we need it. I think I agree with you that ANY-type queries should be avoided. The reason _spf prefix was dropped from SPF was NON-technical, but still an issue we should consider... people didn't understand it, and some still believed underscore was illegal, etc. -- Greg Connor From owner-ietf-mxcomp@mail.imc.org Sat Jun 26 05:28:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29880 for ; Sat, 26 Jun 2004 05:28:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5Q9IF8J039049; Sat, 26 Jun 2004 02:18:15 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5Q9IFZN039047; Sat, 26 Jun 2004 02:18:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from goose.ehsco.com (goose.ehsco.com [207.65.203.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5Q9IFkE039037 for ; Sat, 26 Jun 2004 02:18:15 -0700 (PDT) (envelope-from ehall@ehsco.com) Received: from [207.65.71.20] (unknown [207.65.71.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Eric A. Hall", Issuer "Network Technology Research Group Certificate Authority" (verified OK)) by goose.ehsco.com (Postfix ) with ESMTP id E6E8C2A236; Sat, 26 Jun 2004 04:18:14 -0500 (CDT) Message-ID: <40DD3F19.4060604@ehsco.com> Date: Sat, 26 Jun 2004 04:17:13 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Greg Connor Cc: ietf-mxcomp@imc.org Subject: Re: Backward compatibility with deployed SPF records (and choice of domain) References: <40DD31E8.9040900@ehsco.com> <17958302.1088215066@[10.12.1.26]> In-Reply-To: <17958302.1088215066@[10.12.1.26]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/26/2004 3:57 AM, Greg Connor wrote: > The reason _spf prefix was dropped from SPF was NON-technical, but > still an issue we should consider... people didn't understand it, and > some still believed underscore was illegal, etc. underscore is illegal for hostnames. service names are not hostnames. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-ietf-mxcomp@mail.imc.org Sat Jun 26 05:56:12 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00623 for ; Sat, 26 Jun 2004 05:56:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5Q9gO9J047683; Sat, 26 Jun 2004 02:42:24 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5Q9gOo3047682; Sat, 26 Jun 2004 02:42:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5Q9gNcC047669 for ; Sat, 26 Jun 2004 02:42:23 -0700 (PDT) (envelope-from roy+dated+1090834942.bc16ab@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i5Q9gMYX058093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 26 Jun 2004 09:42:23 GMT (envelope-from roy+dated+1090834942.bc16ab@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5Q9gMfo027776 for ; Sat, 26 Jun 2004 10:42:22 +0100 (BST) (envelope-from roy+dated+1090834942.bc16ab@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5Q9gMUG027775 for ietf-mxcomp@imc.org; Sat, 26 Jun 2004 10:42:22 +0100 (BST) (envelope-from roy+dated+1090834942.bc16ab@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sat, 26 Jun 2004 10:42:20 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16605.17660.425719.942963@giles.gnomon.org.uk> Date: Sat, 26 Jun 2004 10:42:20 +0100 To: "Eric A. Hall" Cc: Greg Connor , ietf-mxcomp@imc.org Subject: Re: Backward compatibility with deployed SPF records (and choice of domain) In-Reply-To: <40DD3F19.4060604@ehsco.com> References: <40DD31E8.9040900@ehsco.com> <17958302.1088215066@[10.12.1.26]> <40DD3F19.4060604@ehsco.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Eric" == Eric A Hall writes: Eric> underscore is illegal for hostnames. service names are not Eric> hostnames. I think there was a concern that many hosted DNS services do not allow underscore anywhere. I'm sure this was discussed on the SPF list some time ago, but I can't remember if the concern was substantiated... -roy From owner-ietf-mxcomp@mail.imc.org Sat Jun 26 06:36:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01677 for ; Sat, 26 Jun 2004 06:36:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5QAKCeQ058337; Sat, 26 Jun 2004 03:20:12 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5QAKCgS058336; Sat, 26 Jun 2004 03:20:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (ntbbs.santronics.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5QAK9U3058330 for ; Sat, 26 Jun 2004 03:20:10 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Sat, 26 Jun 2004 06:23:56 -0400 Received: from ([68.156.249.86]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 2056084172; Sat, 26 Jun 2004 06:23:55 -0400 Message-ID: <00bf01c45b67$20023070$6401a8c0@hdev1> From: "Hector Santos" To: "Eric A. Hall" Cc: References: <40DD31E8.9040900@ehsco.com> <17958302.1088215066@[10.12.1.26]> <40DD3F19.4060604@ehsco.com> Subject: Re: Backward compatibility with deployed SPF records (and choice of domain) Date: Sat, 26 Jun 2004 06:19:51 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.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: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Eric A. Hall" To: "Greg Connor" Cc: Sent: Saturday, June 26, 2004 5:17 AM Subject: Re: Backward compatibility with deployed SPF records (and choice of domain) > On 6/26/2004 3:57 AM, Greg Connor wrote: > > > The reason _spf prefix was dropped from SPF was NON-technical, but > > still an issue we should consider... people didn't understand it, and > > some still believed underscore was illegal, etc. > > underscore is illegal for hostnames. service names are not hostnames. > Did you see my message on this thread? So the customer was right about his ISP saying it was illegal to use _EP.hostname.com for a TXT record? -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Sat Jun 26 06:40:05 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01872 for ; Sat, 26 Jun 2004 06:40:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5QASNJ4059133; Sat, 26 Jun 2004 03:28:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5QASNPf059132; Sat, 26 Jun 2004 03:28:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from goose.ehsco.com (goose.ehsco.com [207.65.203.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5QASMsG059126 for ; Sat, 26 Jun 2004 03:28:22 -0700 (PDT) (envelope-from ehall@ehsco.com) Received: from [207.65.71.20] (unknown [207.65.71.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Eric A. Hall", Issuer "Network Technology Research Group Certificate Authority" (verified OK)) by goose.ehsco.com (Postfix ) with ESMTP id E484C3E96E; Sat, 26 Jun 2004 05:28:22 -0500 (CDT) Message-ID: <40DD4F8D.1040304@ehsco.com> Date: Sat, 26 Jun 2004 05:27:25 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hector Santos Cc: ietf-mxcomp@imc.org Subject: Re: Backward compatibility with deployed SPF records (and choice of domain) References: <40DD31E8.9040900@ehsco.com> <17958302.1088215066@[10.12.1.26]> <40DD3F19.4060604@ehsco.com> <00bf01c45b67$20023070$6401a8c0@hdev1> In-Reply-To: <00bf01c45b67$20023070$6401a8c0@hdev1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/26/2004 5:19 AM, Hector Santos wrote: > So the customer was right about his ISP saying it was illegal to use > _EP.hostname.com for a TXT record? A domain name contains a series of labels. Any label may contain character codes 0x00 through 0xFF. A hostname may only contain labels with a-z, A-Z, 0-9, and "-" (there are length and ordering restrictions too). A TXT RR can be associated with any domain name and is not limited to hostnames. The ISP is wrong. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From owner-ietf-mxcomp@mail.imc.org Sat Jun 26 07:27:05 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03432 for ; Sat, 26 Jun 2004 07:27:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5QAIAGW058248; Sat, 26 Jun 2004 03:18:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5QAIAmU058247; Sat, 26 Jun 2004 03:18:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5QAI99L058239 for ; Sat, 26 Jun 2004 03:18:09 -0700 (PDT) (envelope-from roy+dated+1090837088.bc0304@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i5QAI8YX023618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 26 Jun 2004 10:18:09 GMT (envelope-from roy+dated+1090837088.bc0304@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5QAI8m9027867 for ; Sat, 26 Jun 2004 11:18:08 +0100 (BST) (envelope-from roy+dated+1090837088.bc0304@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5QAI8jd027866 for ietf-mxcomp@imc.org; Sat, 26 Jun 2004 11:18:08 +0100 (BST) (envelope-from roy+dated+1090837088.bc0304@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sat, 26 Jun 2004 11:18:07 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16605.19807.57913.211748@giles.gnomon.org.uk> Date: Sat, 26 Jun 2004 11:18:07 +0100 To: Greg Connor Cc: ietf-mxcomp@imc.org Subject: Re: Backward compatibility with deployed SPF records (and choice of domain) In-Reply-To: <5358865.1088202467@[10.12.1.26]> References: <16604.49250.502543.175893@giles.gnomon.org.uk> <5358865.1088202467@[10.12.1.26]> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Greg" == Greg Connor writes: Greg> Is this something we need to work on more, or should we Greg> leave it like that? We talked about looking for the Greg> "closest SOA name" and looking there, and applying the TXT Greg> record at that location to other subdomains that have no TXT Greg> of their own. Oh, it looks like I'm mistaken then: there _is_ a proposal to put records at the zone apex. My apologies to the chairs for suggesting they were mistaken... Greg> (I really wish we could go back in time and tell people they Greg> need to set up MX records for all deliverable domains and Greg> hosts and not fallback to A... any chance we could declare Greg> the fallback-to-A practice deprecated? It may be officially Greg> outside our scope, but it really makes the job of publishing Greg> LMAP records a lot harder.) I think it's still in moderately widespread use, so in keeping with the philosophy of pragmatism, I think whatever we come up with has to accept that. I don't think I'd be happy with a proposal that recommended rejecting mail from existing zones that neither publish MARID records nor MX records. And anything else adds complexity, since you'd have to figure out in some way whether you were in a MARID-aware subtree of the DNS before drawing any conclusions from the lack of an MX record. Greg> 1c. The group has not agreed on an alternate placement for Greg> TXT records other than the label exactly matching the (host Greg> part of the) identity being checked. I.e. a MARID record at Greg> example.com does not cover user@www.example.com. Greg> That means: the domain owner should create LMAP records for Greg> ALL hosts in his domain that have A or MX records. (Note Greg> that a wildcard TXT record does not cover names that have A Greg> or MX but no TXT, only names with no defined data at all) Greg> Is this something we need to work on more, or should we Greg> leave it like that? We talked about looking for the Greg> "closest SOA name" and looking there, and applying the TXT Greg> record at that location to other subdomains that have no TXT Greg> of their own. I fear that attempting to tackle this problem may be more than we can achieve in the timescales. Unless I'm mistaken, there have not been yet been any IDs submitted to this WG that specify such a solution. I agree that it might be a nice feature of a solution, but perhaps it should be left as an item for future study...? I think the question should be whether this WG believes that the lack of such a mechanism will seriously hamper MARID adoption, and whether there are any obstacles to adding such a mechanism later. If the answer to both questions is 'no' then this should probably be left till later. Greg> What would folks in the group think about defining our own Greg> prefix like "v=lmap1"? I think this is only really needed Greg> in the off chance that the semantics are different enough Greg> for people to notice. I think that given draft-mengwonf-spf and draft-ietf-marid check different identities, the differences are potentially enough for people to notice. It might not matter much, but if we don't allow people to publish records that are _only_ recognized by MARID-compliant systems, then we could be creating problems that will be difficult to fix later. On the other hand I suspect that many people will be able to express a single policy that will be valid for both the MAIL FROM identity used by SPF and for the PRA identity currently used by the MARID drafts. In that case I'd hate for people to have to publish the same record with two different prefixes, since that will increase the size of the response (at least if the records are put in the same place). Hence my proposal. -roy From owner-ietf-mxcomp@mail.imc.org Sat Jun 26 10:27:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10520 for ; Sat, 26 Jun 2004 10:27:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5QEF8bu079530; Sat, 26 Jun 2004 07:15:08 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5QEF8Zv079529; Sat, 26 Jun 2004 07:15:08 -0700 (PDT) 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.9) with ESMTP id i5QEF7Qk079520 for ; Sat, 26 Jun 2004 07:15:07 -0700 (PDT) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id ABFF7E071D; Sat, 26 Jun 2004 10:15:05 -0400 (EDT) Date: Sat, 26 Jun 2004 10:15:05 -0400 From: John Leslie To: Hector Santos Cc: IETF-MXCOMP , Dave Crocker Subject: Re: CVS specifics: Accreditation Message-ID: <20040626141505.GS3747@verdi> References: <20040624035001.GG13225@dumbo.pobox.com> <20040624130742.GC3747@verdi> <20040624144946.GI13225@dumbo.pobox.com> <16602.63002.437751.557545@giles.gnomon.org.uk> <20040624175917.GK13225@dumbo.pobox.com> <197394753.20040625152818@brandenburg.com> <20040625140622.GP13225@dumbo.pobox.com> <20040625144552.GI3747@verdi> <901871525.20040626071411@brandenburg.com> <001501c45b29$1b138f70$6401a8c0@hdev1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001501c45b29$1b138f70$6401a8c0@hdev1> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hector Santos wrote: > > I am currently looking at the CVS (and DNS and CSA) drafts. Thank you. More eyeballs always help. > The negative is that acceditation server bureaus will be limited, at first, > and most likely exclusive to specific group of organizations or type of > systems. I envision several different types of business _adding_ this service at "no additional fee". The first type is the domain-name registrars. They're already taking a per-domain-per year fee and already maintaining DNS servers. This service will differentiate them; and the sufficiently clueful ones will quickly see the business case to add it. > 3. Query a chosen Accreditation Service for the EHLO domain name > (see Domain Name Accreditation (DNA) [ID-Marid-CSVDNA]) > > Based on what I am seeing in the market place, infopreneurs are making > these fee based systems. Indeed: Right-Hand-Side Whitelists are fee-based right now. Their business model limits their ability to market to the masses, so their fees are high. I don't hope to see fees disappear entirely, but I do expect "free with boxtop" levels of pricing for low-volume, well-behaved domains. (OTOH, the current business model, effectively charging postage for any mass-email which bounces or generates complaints, will no doubt continue for mass-emailers.) > ... unless someone champions and puts up free DNA site, it seems the > CSV idea will be somewhat crippled which means it only be implemented > as part of a total suite of other transaction management technologies. (I've already discussed the "free with boxtop" services which will directly rate domains.) The other side of the accreditation service is what we described as "proxy" accreditation lookup (which mysteriously seems to have disappeared from Section 5 of [DNA], though a hint still remains in Section 3). The idea is that the procedure in Section 5 might be performed directly by sites receiving a small amount of email; but for sites with a significant volume of incoming email, these would be delegated to a proxy and performed in the same manner but with results cached and reported separately -- possibly by a single UDP DNS query to the proxy. Operating such a proxy would be as cheap as operating a web proxy; and there would likely be the same informal (no money changing hands) arrangements for sharing the workload. (In either case, distribution of lists recommending weights to be given to different direct-accreditation services would be out-of-band and not worth charging for.) > In short, there will probably need to be more than a list of > acceditation sites to lookup to make it more effective for operators. Agreed. The proxy accreditation-lookup process is needed. > I guess, if we implemented CVS with some initial supportive DNA sites, we > would be able to help promote this sites and even encourage membership. > But I do see a need to offer more than one site, if only because one site > is "less" expensive than the other. I am confident that at least half a dozen registrars would offer the direct-rating service. > RBL is one area of optimization I would like to improve upon as it > represents a high percentage of the total validation transaction time. > If you agree a list of acceditation sites is needed, then this needs to > be optimized as well. Does the proxy-lookup service I described satisfy this concern? -- John Leslie From owner-ietf-mxcomp@mail.imc.org Sat Jun 26 17:42:18 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00653 for ; Sat, 26 Jun 2004 17:42:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5QLVai1050146; Sat, 26 Jun 2004 14:31:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5QLVaU2050145; Sat, 26 Jun 2004 14:31:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (ntbbs.santronics.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5QLVZ5j050130 for ; Sat, 26 Jun 2004 14:31:35 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Sat, 26 Jun 2004 17:35:22 -0400 Received: from ([68.156.249.86]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 2096369610; Sat, 26 Jun 2004 17:35:20 -0400 Message-ID: <014301c45bc4$ed673c60$6401a8c0@hdev1> From: "Hector Santos" To: "John Leslie" Cc: "IETF-MXCOMP" , "Dave Crocker" References: <20040624035001.GG13225@dumbo.pobox.com> <20040624130742.GC3747@verdi> <20040624144946.GI13225@dumbo.pobox.com> <16602.63002.437751.557545@giles.gnomon.org.uk> <20040624175917.GK13225@dumbo.pobox.com> <197394753.20040625152818@brandenburg.com> <20040625140622.GP13225@dumbo.pobox.com> <20040625144552.GI3747@verdi> <901871525.20040626071411@brandenburg.com> <001501c45b29$1b138f70$6401a8c0@hdev1> <20040626141505.GS3747@verdi> Subject: Re: CVS specifics: Accreditation Date: Sat, 26 Jun 2004 17:30:56 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.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: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "John Leslie" To: "Hector Santos" Cc: "IETF-MXCOMP" ; "Dave Crocker" Sent: Saturday, June 26, 2004 10:15 AM Subject: Re: CVS specifics: Accreditation > > I guess, if we implemented CVS with some initial supportive DNA sites, we > > would be able to help promote this sites and even encourage membership. > > But I do see a need to offer more than one site, if only because one site > > is "less" expensive than the other. > > I am confident that at least half a dozen registrars would offer the > direct-rating service. Ok. One of the things I would have to work out when it comes to a "feature" that has 3rd party or marketing tie-ins, is to see how it will be accepted by the customer base. We got bit many years ago when tieing in one the early Online Payment systems via a 3rd party VisaNet clearing house. A combination of customer support disputes with the 3rd party vendor and their eventual demise killed this "Online Subscriber/Billing/Reporting" add-on product line. At this time, the number of payment services like this was limited. Anywa, I try to limit and also make sure any tie-ins offerings is first done with popular and reputable companies, especially it is going to be a "natural" new feature added. > > RBL is one area of optimization I would like to improve upon as it > > represents a high percentage of the total validation transaction time. > > If you agree a list of acceditation sites is needed, then this needs to > > be optimized as well. > > Does the proxy-lookup service I described satisfy this concern? Yes, I believe it will. Thanks -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Sat Jun 26 17:51:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00951 for ; Sat, 26 Jun 2004 17:51:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5QLgXP5051989; Sat, 26 Jun 2004 14:42:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5QLgXY7051988; Sat, 26 Jun 2004 14:42:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5QLgVh3051973 for ; Sat, 26 Jun 2004 14:42:32 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id 8D5321A6C7; Sat, 26 Jun 2004 23:42:33 +0200 (CEST) Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) by bra.gulbrandsen.priv.no (Postfix) with SMTP id 70BAF1A6B5; Sat, 26 Jun 2004 23:42:25 +0200 (CEST) Message-Id: From: Arnt Gulbrandsen To: "Eric A. Hall" Subject: Re: Unified SPF: RPC factored lookups = DVP Cc: Meng Weng Wong , IETF MARID WG References: <16602.6449.212333.862543@giles.gnomon.org.uk> <20040624035001.GG13225@dumbo.pobox.com> <20040624130742.GC3747@verdi> <20040624144946.GI13225@dumbo.pobox.com> <16602.63002.437751.557545@giles.gnomon.org.uk> <20040624175917.GK13225@dumbo.pobox.com> <197394753.20040625152818@brandenburg.com> <1018376265.20040625211654@brandenburg.com> <20040625134117.GK10659@dumbo.pobox.com> <40DC394F.2080707@ehsco.com> In-Reply-To: <40DC394F.2080707@ehsco.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Sat, 26 Jun 2004 23:43:59 +0200 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Eric A. Hall writes: > Arnt needs to make some time to write up his proposal still. :) Be happy to, unless it's a waste of time. The silence does not sound good to my ears. I have a feeling that people really want SPF (optionally with a cosmetic changes, e.g. C-ID) and won't consider anything else. Arnt From owner-ietf-mxcomp@mail.imc.org Sat Jun 26 22:32:28 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12596 for ; Sat, 26 Jun 2004 22:32:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5R2GIlC004613; Sat, 26 Jun 2004 19:16:18 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5R2GIiI004612; Sat, 26 Jun 2004 19:16:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5R2GHbE004606 for ; Sat, 26 Jun 2004 19:16:18 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: Cu3UJeHg+77PfiAL/GabEg 1088302579 Received: from [192.168.0.3] (adsl-63-195-86-147.dsl.snfc21.pacbell.net [63.195.86.147]) by mail.messagingengine.com (Postfix) with ESMTP id A0D25C0D6CB; Sat, 26 Jun 2004 22:16:18 -0400 (EDT) Message-ID: <40DC9D65.3000107@elvey.com> Date: Fri, 25 Jun 2004 16:47:17 -0500 From: Matthew Elvey User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Douglas Otis Cc: "'IETF MARID WG'" , spf-discuss@v2.listbox.com Subject: Re: Why XML References: <013001c45881$488c5b80$2766f30a@development.greatgulfhomes.com> <40D87C90.9050601@danisch.de> <1087954632.22641.272.camel@ddev.mail-abuse.org> <40D9461C.1020900@elvey.com> <1088011125.23558.123.camel@ddev.mail-abuse.org> In-Reply-To: <1088011125.23558.123.camel@ddev.mail-abuse.org> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/23/04 12:18 PM, Douglas Otis sent forth electrons to convey: >On Wed, 2004-06-23 at 01:58, Matthew Elvey wrote: > > >>On 6/22/04 8:37 PM, Douglas Otis sent forth electrons to convey: >> >> >> >>>... >>>Any mechanism introduced that stems the flow of UCE will be subjected to >>>intensive attack. ... >>> >Unlike these queries in parallel to _known_ servers, the SPF/CID schemes >involve a series of queries to _unknown_ and possibly hostile name >servers. > I know that. I did read the first sentence above! I was CLEARLY discussing best case. You just didn't notice. Certainly, worst case is also important. More important, in fact. But best case is important too. > > > >>This will be more realistic: >> >>As example, a mail server is receiving 50 messages per second that >>average 4 K bytes in size. If using the SPF/CID mechanism, checking DNS >>data is indeterminate as there is no limit for the number of sequential >>queries required to converge upon an answer. RFC1035 indicates 5 to 10 >>seconds should be considered a worst case resolver interval. >> >> >- > > >>If there becomes an average of 4 queries with an average of 1 second >>a query, then this limits each process to about _ message about every >>minute. >> >> > >These are messages from hostile domains. > NO THEY ARE NOT. You didn't read my post, particularly what immediately preceeded the above quote/read it selectively. Please do not quote me misleadingly again. Grr... What kind of selective misquoting are you up to? You cut this: "If MARID is effective enough for long enough that most spammers give up, then .... " !!! Sheesh! > >In addition to this estimate ignoring the actual size of the query >response > No; see ?wayne's? data on typical SPF record sizes. From owner-ietf-mxcomp@mail.imc.org Sun Jun 27 05:33:26 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09573 for ; Sun, 27 Jun 2004 05:33:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5R9LJEE007831; Sun, 27 Jun 2004 02:21:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5R9LJ8b007830; Sun, 27 Jun 2004 02:21:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5R9LDJP007795 for ; Sun, 27 Jun 2004 02:21:18 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id E62EC1A6C7; Sun, 27 Jun 2004 11:21:10 +0200 (CEST) Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) by bra.gulbrandsen.priv.no (Postfix) with SMTP id 1EF4D1A6B9; Sun, 27 Jun 2004 11:21:01 +0200 (CEST) Message-Id: <81WH9x0IFJGXKNnlr+0SFg.md5@prosecco.oryx.com> From: Arnt Gulbrandsen To: "Eric A. Hall" Subject: Re: Unified SPF: RPC factored lookups = DVP Cc: Meng Weng Wong , IETF MARID WG References: <16602.6449.212333.862543@giles.gnomon.org.uk> <20040624035001.GG13225@dumbo.pobox.com> <20040624130742.GC3747@verdi> <20040624144946.GI13225@dumbo.pobox.com> <16602.63002.437751.557545@giles.gnomon.org.uk> <20040624175917.GK13225@dumbo.pobox.com> <197394753.20040625152818@brandenburg.com> <1018376265.20040625211654@brandenburg.com> <20040625134117.GK10659@dumbo.pobox.com> <40DC394F.2080707@ehsco.com> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Sun, 27 Jun 2004 11:22:35 +0200 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Arnt Gulbrandsen writes: > Be happy to, unless it's a waste of time. The silence does not sound > good to my ears. I have a feeling that people really want SPF > (optionally with a cosmetic changes, e.g. C-ID) and won't consider > anything else. But I'll see if I can get a draft in tomorrow. Arnt From owner-ietf-mxcomp@mail.imc.org Sun Jun 27 17:57:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07987 for ; Sun, 27 Jun 2004 17:57:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5RLee20084177; Sun, 27 Jun 2004 14:40:40 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5RLeeG4084176; Sun, 27 Jun 2004 14:40:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5RLeeFc084170 for ; Sun, 27 Jun 2004 14:40:40 -0700 (PDT) (envelope-from hkatz@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Sun, 27 Jun 2004 14:40:41 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 27 Jun 2004 14:40:21 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 27 Jun 2004 14:40:41 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-fido-msg.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 27 Jun 2004 14:40:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Backward compatibility with deployed SPF records (and choice of domain) Date: Sun, 27 Jun 2004 14:40:28 -0700 Message-ID: Thread-Topic: Backward compatibility with deployed SPF records (and choice of domain) thread-index: AcRbPzhvT9nlohfwSlWuTZTjpcWYswBTk0fw From: "Harry Katz" To: X-OriginalArrivalTime: 27 Jun 2004 21:40:37.0478 (UTC) FILETIME=[626FA860:01C45C8F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5RLeeFc084171 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Friday, June 25, 2004 10:28 PM, Greg Connor wrote: > > 1. Placement of TXT records. > > > > The co-chairs find that the working group has not come > to consensus on > > the use of a record prefix vs [unprefixed] TXT records > > > I think I would agree with Roy that allowing MARID-compliant > MTAs to check > the unprefixed name is desirable. > > In other words, if MARID-Brand LMAP works substantially similar to > SPF-Brand, let's go ahead and use their data. > > One concern here is that we would want the semantics to be > similar enough > to not upset or surprise anyone who isn't expecting their > data to be used a > slightly different way, but I think we are able to do that. (That > certainly was the intent of the SenderID merged proposal) > > In a straight race, I would probably root for the > non-prefixed records to > win, simply because the underscore might scare and confuse > people (it was > removed from early versions of SPF for mostly that reason). I do > understand the issue that the prefix is intended to address, > but I don't > think the research we have shows it is anything to worry > about. I think > most users will not have TXT records of any other type, and > of those that > do, the records will mostly be small enough to coexist > peacefully. I don't > have a strong preference in this area, except that backward > compatibility > would allow MARID to harness and redirect the momentum SPF > has built up. > (Of course we will be going through the process of getting > our own RR so we > will eventually have an escape plan) > > Does anyone have a strong objection to using unprefixed txt records? > I think this is just going to invite problems down the road. Although data may correctly show that TXT records are not used frequently today, that's no guarantee of future use. Likewise we cannot predict the length of data stored in future TXT records. Multiple TXT records could push responses over the 512 byte threshhold. Segregating MARID records into their own subdomain addresses these issues. We advocate the use of an underscore as a way to celarly distinguish this record from a hostname, but we're not married to it. From owner-ietf-mxcomp@mail.imc.org Sun Jun 27 18:29:11 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10199 for ; Sun, 27 Jun 2004 18:29:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5RMFELd085449; Sun, 27 Jun 2004 15:15:14 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5RMFERV085448; Sun, 27 Jun 2004 15:15:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5RMFD5s085442 for ; Sun, 27 Jun 2004 15:15:13 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from [192.168.2.24] (adsl-64-142-13-68.sonic.net [64.142.13.68]) by a.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i5RMFHCE015148; Sun, 27 Jun 2004 15:15:17 -0700 Subject: Re: Why XML From: Douglas Otis To: Matthew Elvey Cc: "'IETF MARID WG'" , spf-discuss@v2.listbox.com In-Reply-To: <40DC9D65.3000107@elvey.com> References: <013001c45881$488c5b80$2766f30a@development.greatgulfhomes.com> <40D87C90.9050601@danisch.de> <1087954632.22641.272.camel@ddev.mail-abuse.org> <40D9461C.1020900@elvey.com> <1088011125.23558.123.camel@ddev.mail-abuse.org> <40DC9D65.3000107@elvey.com> Content-Type: text/plain Message-Id: <1088374517.2642.187.camel@bash.adsl-64-142-13-68.sonic.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 27 Jun 2004 15:15:17 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Matthew, This was in regard to an attack scenario with motivation given for such. Surprisingly, you base performance using known servers for your best case scenario. In addition, estimates for a DNS response from the the TXT record query must include the size of TXT record with another 56 bytes and the size of the name referenced. I put together what I thought could be considered a reasonable set of circumstances allowed by the draft. I did not take this to an extreme. I wanted to illustrate difficulties identifying these attacks with their potential impact on performance. Even if there are messages processed quickly, the slower messages will very much dominate the load on the servers. As SPF allows open lists, these attacks may never reference any domain or name server owned by the attacker. Should this attack be distributed to many destinations, then the name servers should be expected to become erratic where this will help sustain the attack. SPF never directly establishes the domain accountable for the mail stream. As a result, finding a method of stopping a flood of abusive mail must depend upon methods outside of the SPF. Identification methods available to commerce and advertising could implement the Fenton "Identified Mail" proposal without jeopardizing mail services and this completely guards against identity fraud. SPF interferes with the normal use of mail as well as the Fenton proposal in that it attempts to tie identity to the mail channel. CSV on the other hand protects against abusive domains without increasing risks from attack and leaves the use of mail unchanged. CSV allows follow-up should there be criminal fraud and allows policy evaluation of the domain handling the mail. The types of information gleaned from SPF and CSV are similar in that they both identify outbound SMTP servers. A difference for CSV is that it is comprehensive in that it limits identity to the domain accountable for the mail stream, whereas SPF attempts to correlate domains permitted to carry mail for other domains. As this SPF correlation is never expected to be comprehensive, either this list must be defined as "open" or a method to "usurp" this permission must be allowed. Either exception keeps the door open for abuse and fraud. If SPF is not checked at the channel, then assurances provided the recipient by the SPF mechanism is highly suspect and provides motivations for attack. SPF will also likely lead to greater restrictions on the use of mail addresses and the ability to forward mail to a common account. Both of these outcomes will be onerous for users and providers and again offer motivation for attack. CSV does not change the way mail is used and, for most users, they will only notice a reduction in abuse as it can quickly identify infected systems. Unlike an address method of vetting a sending SMTP client, use of a domain name allows a greater history to be acquired, even where the address may be dynamically assigned or shared and allow assertions of affiliations. Vetting a domain name that handles the mail allows greater speed and accuracy as opposed to only an IP address. -Doug From owner-ietf-mxcomp@mail.imc.org Sun Jun 27 22:51:01 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19835 for ; Sun, 27 Jun 2004 22:51:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5S2VRQv005691; Sun, 27 Jun 2004 19:31:27 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5S2VRle005690; Sun, 27 Jun 2004 19:31:27 -0700 (PDT) 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.9) with ESMTP id i5S2VQv8005683 for ; Sun, 27 Jun 2004 19:31:26 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (verisign.com [65.205.251.55] (may be forged)) by peacock.verisign.com (8.12.10/) with ESMTP id i5S2Ut9J010887; Sun, 27 Jun 2004 19:30:55 -0700 Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Sun, 27 Jun 2004 19:30:55 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Hector Santos'" , "Eric A. Hall" Cc: ietf-mxcomp@imc.org Subject: RE: Backward compatibility with deployed SPF records (and choice of domain) Date: Sun, 27 Jun 2004 19:30:50 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > > The reason _spf prefix was dropped from SPF was NON-technical, but > > > still an issue we should consider... people didn't > understand it, and > > > some still believed underscore was illegal, etc. > > > > underscore is illegal for hostnames. service names are not > hostnames. > > > > Did you see my message on this thread? > > So the customer was right about his ISP saying it was illegal to use > _EP.hostname.com for a TXT record? Prefixes are already used for SRV. People who would not follow the spf group are much more likely to follow advice from the IETF. Phill From owner-ietf-mxcomp@mail.imc.org Mon Jun 28 12:01:11 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13098 for ; Mon, 28 Jun 2004 12:01:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5SFir6P084308; Mon, 28 Jun 2004 08:44:53 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5SFirKP084307; Mon, 28 Jun 2004 08:44:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5SFiqn8084297 for ; Mon, 28 Jun 2004 08:44:53 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: J316Wuw2axGHFoorwKHcJw 1088437492 Received: from [192.168.0.3] (adsl-63-195-86-147.dsl.snfc21.pacbell.net [63.195.86.147]) by mail.messagingengine.com (Postfix) with ESMTP id 51667C0D483; Mon, 28 Jun 2004 11:44:51 -0400 (EDT) Message-ID: <40E03CF3.8000107@elvey.com> Date: Mon, 28 Jun 2004 08:44:51 -0700 From: Matthew Elvey User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: IETF MARID List Subject: Re: draft-ietf-marid-submitter-01.txt References: In-Reply-To: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/24/04 11:26 PM, Harry Katz sent forth electrons to convey: > Thanks, Hadmut. > > Since the SUBMITTER parameter is derived from RFC 2822 headers, I > believe you could reconstruct the chain of submitters from the > Resent-From or Resent-Sender headers that are written with each > Received header. If there is no Resent-* header, then either the > Sender or From headers would contain the SUBMITTER value. Only if you're assuming that the SUBMITTER is added following 'the rules'. The spec doesn't say that mail with a falsified SUBMITTER should be refused or discarded. (I hate all the pussyfooting around the discard option.) Also, I have thought of a possible legal problem with SUBMITTTER - The US' YOU CAN SPAM bill, IIRC, forbids falsified headers. Is the envelope part of the header? Arguably not. If not, will future spammers be able to send email with falsified SUBMITTER info but without falsified headers? OTOH, the headers are misleading if they don't match the SUBMITTER, just like a Subject that doesn't describe the body is misleading. So this is probably a non-issue. From owner-ietf-mxcomp@mail.imc.org Mon Jun 28 13:00:01 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16181 for ; Mon, 28 Jun 2004 13:00:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5SGa0ah090066; Mon, 28 Jun 2004 09:36:00 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5SGa0Mo090065; Mon, 28 Jun 2004 09:36:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [64.139.47.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5SGa0IZ090053 for ; Mon, 28 Jun 2004 09:36:00 -0700 (PDT) (envelope-from gconnor@nekodojo.org) Received: by neko-base.nekodojo.org (Postfix, from userid 500) id 1C14A1D656; Mon, 28 Jun 2004 09:35:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by neko-base.nekodojo.org (Postfix) with ESMTP id 1B3441D651; Mon, 28 Jun 2004 09:35:59 -0700 (PDT) Date: Mon, 28 Jun 2004 09:35:59 -0700 (PDT) From: Greg Connor To: Matthew Elvey Cc: IETF MARID List Subject: Re: draft-ietf-marid-submitter-01.txt In-Reply-To: <40E03CF3.8000107@elvey.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 28 Jun 2004, Matthew Elvey wrote: > Only if you're assuming that the SUBMITTER is added following 'the > rules'. The spec doesn't say that mail with a falsified SUBMITTER > should be refused or discarded. (I hate all the pussyfooting around the > discard option.) Actually that was the original intent -- if it didn't get added to the draft it probably should be. A message that claims a certain SUBMITTER but doesn't have that address in the right place should be rejected after DATA and should not be accepted. > Also, I have thought of a possible legal problem with SUBMITTTER - The > US' YOU CAN SPAM bill, IIRC, forbids falsified headers. Is the envelope > part of the header? Arguably not. If not, will future spammers be able > to send email with falsified SUBMITTER info but without falsified > headers? OTOH, the headers are misleading if they don't match the > SUBMITTER, just like a Subject that doesn't describe the body is > misleading. So this is probably a non-issue. The way it is defined, SUBMITTER needs to reflect one of the headers. If the SUBMITTER says one thing and the headers suggest PRA is different, I would hope it would be rejected. If the questionable message is not rejected for some reason, the MTA should probably insert something in the Received: line or next to it that says "MTA claimed Submitter was x@x" -- Greg Connor gconnor@nekodojo.org Everyone says that having power is a great responsibility. This is a lot of bunk. Responsibility is when someone can blame you if something goes wrong. When you have power you are surrounded by people whose job it is to take the blame for your mistakes. If they're smart, that is. -- Cerebus, "On Governing" From owner-ietf-mxcomp@mail.imc.org Mon Jun 28 13:09:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16654 for ; Mon, 28 Jun 2004 13:09:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5SGtbH1091390; Mon, 28 Jun 2004 09:55:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5SGtbYV091389; Mon, 28 Jun 2004 09:55:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5SGtaj4091382 for ; Mon, 28 Jun 2004 09:55:36 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: NlE2ZialyvmG8VhZkuNRKQ 1088441736 Received: from [192.168.0.3] (adsl-63-195-86-147.dsl.snfc21.pacbell.net [63.195.86.147]) by mail.messagingengine.com (Postfix) with ESMTP id 57D41C0D33F; Mon, 28 Jun 2004 12:55:34 -0400 (EDT) Message-ID: <40E04D86.5070204@elvey.com> Date: Mon, 28 Jun 2004 09:55:34 -0700 From: Matthew Elvey User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Douglas Otis Cc: "'IETF MARID WG'" Subject: Will SPF/Unified SPF/SenderID bring down the 'net? References: <013001c45881$488c5b80$2766f30a@development.greatgulfhomes.com> <40D87C90.9050601@danisch.de> <1087954632.22641.272.camel@ddev.mail-abuse.org> <40D9461C.1020900@elvey.com> <1088011125.23558.123.camel@ddev.mail-abuse.org> <40DC9D65.3000107@elvey.com> <1088374517.2642.187.camel@bash.adsl-64-142-13-68.sonic.net> In-Reply-To: <1088374517.2642.187.camel@bash.adsl-64-142-13-68.sonic.net> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Removing spf-discuss@v2.listbox.com from the cc list; they're not going to abandon their scheme, and they can't address these issues without doing so; the right place for discussion is therefore MARID. On 6/27/04 3:15 PM, Douglas Otis sent forth electrons to convey: >Matthew, > >This was in regard to an attack scenario with motivation given for such. >Surprisingly, you base performance using known servers for your best >case scenario. In addition, estimates for a DNS response from the the >TXT record query must include the size of TXT record with another 56 >bytes and the size of the name referenced. I put together what I >thought could be considered a reasonable set of circumstances allowed by >the draft. I did not take this to an extreme. I wanted to illustrate >difficulties identifying these attacks with their potential impact on >performance. > > Yes, I would like to confirm that I think your scenario is more than reasonable: it represents a likely scenario at some point, should SPF be the base of MARID. >Even if there are messages processed quickly, the slower messages will >very much dominate the load on the servers. As SPF allows open lists, >these attacks may never reference any domain or name server owned by the >attacker. Should this attack be distributed to many destinations, then >the name servers should be expected to become erratic where this will >help sustain the attack. > > Sender ID, IIRC, at least suggests that SPF records that require > 20 queries to resolve are inappropriate. SPF should adopt this, or something stronger, as well (it says something more vague). Even if this was adopted, the DDoS exposure is large. >SPF never directly establishes the domain accountable for the mail >stream. As a result, finding a method of stopping a flood of abusive >mail must depend upon methods outside of the SPF. Identification >methods available to commerce and advertising could implement the Fenton >"Identified Mail" proposal without jeopardizing mail services and this >completely guards against identity fraud. SPF interferes with the >normal use of mail as well as the Fenton proposal in that it attempts to >tie identity to the mail channel. CSV on the other hand protects >against abusive domains without increasing risks from attack and leaves >the use of mail unchanged. CSV allows follow-up should there be >criminal fraud and allows policy evaluation of the domain handling the >mail. > >The types of information gleaned from SPF and CSV are similar in that >they both identify outbound SMTP servers. A difference for CSV is that >it is comprehensive in that it limits identity to the domain accountable >for the mail stream, whereas SPF attempts to correlate domains permitted >to carry mail for other domains. As this SPF correlation is never >expected to be comprehensive, either this list must be defined as "open" >or a method to "usurp" this permission must be allowed. Either >exception keeps the door open for abuse and fraud. > > Can you give an example? I'm not sure I follow. Are you referring to SPF being 'optional', or what? >If SPF is not checked at the channel, then assurances provided the >recipient by the SPF mechanism is highly suspect and provides >motivations for attack. SPF will also likely lead to greater >restrictions on the use of mail addresses and the ability to forward >mail to a common account. Both of these outcomes will be onerous for >users and providers and again offer motivation for attack. > > Not onerous given Unified SPF, which I think you're familiar with. These folks are very unlikely to attack the system. Spammers are likely to attack the system. (Where by attack, I mean not just in the 'argue against' sense, but a real military (e.g. DDoS) sense.) >CSV does not change the way mail is used and, for most users, they will >only notice a reduction in abuse as it can quickly identify infected >systems. Unlike an address method of vetting a sending SMTP client, use >of a domain name allows a greater history to be acquired, even where the >address may be dynamically assigned or shared and allow assertions of >affiliations. Vetting a domain name that handles the mail allows >greater speed and accuracy as opposed to only an IP address. > > If it turns out that SPF adoption leads to significant network harm, then it would be possible to tweak it or replace it with something more effective, with narrower scope, in particular CSV. This is a valuable discussion. Let's flesh out more your attack scenario, so we can be proactive about this. I could see SPF causing some free DNS providers to go belly up. OTOH, DNS is a remarkably efficient protocol, so perhaps SPF is sufficiently lightweight. It seems that traditional BLs were near the tipping point- concerted DDoS attacks brought down some BLs, but were unable to take down others. MARID should be more stable than that. I think we may need to wait for Unified SPF to become an I-D; it's difficult to flesh out its DDoS exposure right now. I suspect it is more resistant. From owner-ietf-mxcomp@mail.imc.org Mon Jun 28 14:21:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20810 for ; Mon, 28 Jun 2004 14:21:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5SI9aaf097721; Mon, 28 Jun 2004 11:09:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5SI9axk097720; Mon, 28 Jun 2004 11:09:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5SI9ZBo097712 for ; Mon, 28 Jun 2004 11:09:35 -0700 (PDT) (envelope-from hkatz@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 28 Jun 2004 11:09:34 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 28 Jun 2004 11:09:31 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 28 Jun 2004 11:09:33 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-fido-msg.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 28 Jun 2004 11:09:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: draft-ietf-marid-submitter-01.txt Date: Mon, 28 Jun 2004 11:09:28 -0700 Message-ID: Thread-Topic: draft-ietf-marid-submitter-01.txt thread-index: AcRdL9L6MrbIp5kpQwiHqXK3rm+08wAChJMw From: "Harry Katz" To: "IETF MARID List" X-OriginalArrivalTime: 28 Jun 2004 18:09:03.0009 (UTC) FILETIME=[FE5B2910:01C45D3A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5SI9ZBo097715 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Monday, June 28, 2004 9:36 AM, Greg Connor wrote: > On Mon, 28 Jun 2004, Matthew Elvey wrote: > > > Only if you're assuming that the SUBMITTER is added following 'the > > rules'. The spec doesn't say that mail with a falsified SUBMITTER > > should be refused or discarded. (I hate all the > pussyfooting around > > the discard option.) > > > Actually that was the original intent -- if it didn't get > added to the draft it probably should be. A message that > claims a certain SUBMITTER but doesn't have that address in > the right place should be rejected after DATA and should not > be accepted. > The spec does say this. From section 4.2: If the receiving SMTP server allows the connecting SMTP client to transmit message data, then the server SHOULD determine the purported responsible address of the message by examining the RFC 2822 message headers as described in [SENDER-ID]. If this purported responsible address does not match the address appearing in the SUBMITTER parameter, the receiving SMTP server MUST reject the message using "550 5.7.1 Submitter does not match header." If this needs some further clarification, please let me know. > > > Also, I have thought of a possible legal problem with > SUBMITTTER - The > > US' YOU CAN SPAM bill, IIRC, forbids falsified headers. Is the > > envelope part of the header? Arguably not. If not, will future > > spammers be able to send email with falsified SUBMITTER info but > > without falsified headers? OTOH, the headers are > misleading if they > > don't match the SUBMITTER, just like a Subject that doesn't > describe > > the body is misleading. So this is probably a non-issue. > > > The way it is defined, SUBMITTER needs to reflect one of the > headers. If the SUBMITTER says one thing and the headers > suggest PRA is different, I would hope it would be rejected. > If the questionable message is not rejected for some reason, > the MTA should probably insert something in the Received: > line or next to it that says "MTA claimed Submitter was x@x" > It should be rejected. From owner-ietf-mxcomp@mail.imc.org Mon Jun 28 14:48:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22073 for ; Mon, 28 Jun 2004 14:48:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5SIcV1b001181; Mon, 28 Jun 2004 11:38:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5SIcVrQ001180; Mon, 28 Jun 2004 11:38:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.mail-abuse.org [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5SIcUtS001170 for ; Mon, 28 Jun 2004 11:38:30 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.mail-abuse.org (DDev.mail-abuse.org [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id 9BC414148A; Mon, 28 Jun 2004 11:38:27 -0700 (PDT) Subject: Re: Will SPF/Unified SPF/SenderID bring down the 'net? From: Douglas Otis To: Matthew Elvey Cc: "'IETF MARID WG'" In-Reply-To: <40E04D86.5070204@elvey.com> References: <013001c45881$488c5b80$2766f30a@development.greatgulfhomes.com> <40D87C90.9050601@danisch.de> <1087954632.22641.272.camel@ddev.mail-abuse.org> <40D9461C.1020900@elvey.com> <1088011125.23558.123.camel@ddev.mail-abuse.org> <40DC9D65.3000107@elvey.com> <1088374517.2642.187.camel@bash.adsl-64-142-13-68.sonic.net> <40E04D86.5070204@elvey.com> Content-Type: text/plain Message-Id: <1088447907.4615.158.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 28 Jun 2004 11:38:27 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 2004-06-28 at 09:55, Matthew Elvey wrote: > On 6/27/04 3:15 PM, Douglas Otis sent forth electrons to convey: > > Matthew, > > > > This was in regard to an attack scenario with motivation given for such. > > Surprisingly, you base performance using known servers for your best > > case scenario. In addition, estimates for a DNS response from the the > > TXT record query must include the size of TXT record with another 56 > > bytes and the size of the name referenced. I put together what I > > thought could be considered a reasonable set of circumstances allowed by > > the draft. I did not take this to an extreme. I wanted to illustrate > > difficulties identifying these attacks with their potential impact on > > performance. > > Yes, I would like to confirm that I think your scenario is more than > reasonable: it represents a likely scenario at some point, should SPF be > the base of MARID. CSV and then SPF if at all. I should also note to assess traffic caused by these queries, the byte count should also include Ethernet (26), IPv4 (20), and UDP (8) overhead for an additional 54 bytes. > > Even if there are messages processed quickly, the slower messages will > > very much dominate the load on the servers. As SPF allows open lists, > > these attacks may never reference any domain or name server owned by the > > attacker. Should this attack be distributed to many destinations, then > > the name servers should be expected to become erratic where this will > > help sustain the attack. > > Sender ID, IIRC, at least suggests that SPF records that require > 20 > queries to resolve are inappropriate. SPF should adopt this, or > something stronger, as well (it says something more vague). Even if > this was adopted, the DDoS exposure is large. Yes, but sadly Sender-ID never ensures accountability to enable repudiation services a means to stop abuse. Sender-ID leaves the door open for abuse and thus can never offer protections from any type of DDoS attack. > > SPF never directly establishes the domain accountable for the mail > > stream. As a result, finding a method of stopping a flood of abusive > > mail must depend upon methods outside of the SPF. Identification > > methods available to commerce and advertising could implement the Fenton > > "Identified Mail" proposal without jeopardizing mail services and this > > completely guards against identity fraud. SPF interferes with the > > normal use of mail as well as the Fenton proposal in that it attempts to > > tie identity to the mail channel. CSV on the other hand protects > > against abusive domains without increasing risks from attack and leaves > > the use of mail unchanged. CSV allows follow-up should there be > > criminal fraud and allows policy evaluation of the domain handling the > > mail. > > > > The types of information gleaned from SPF and CSV are similar in that > > they both identify outbound SMTP servers. A difference for CSV is that > > it is comprehensive in that it limits identity to the domain accountable > > for the mail stream, whereas SPF attempts to correlate domains permitted > > to carry mail for other domains. As this SPF correlation is never > > expected to be comprehensive, either this list must be defined as "open" > > or a method to "usurp" this permission must be allowed. Either > > exception keeps the door open for abuse and fraud. > > Can you give an example? I'm not sure I follow. Are you referring to > SPF being 'optional', or what? SPF does not identify the domain injecting the mail stream. Nor does SPF demand lists being referenced by the message domain to be "closed." This means a repudiation is meaningless if done on "unknown" in the case the list is "open" and the address of the sending SMTP does not match. There is no rejection of the message nor an assessment made against a domain if this message is found to have been abusive. The case of a domain "usurping" permission in SPF is no different than CSV. CSV treats all domains in this manner and allows no exceptions. This means for CSV, only a single query will provide a much smaller and yet comprehensive block record that has the sole purpose of assigning accountability irrespective of message content. There are much stronger and more scalable means to identify the author of a message such as the Fenton "Identified Mail" proposal. There are much more dependable means of establishing mail channel accountability such as CSV. SPF does neither of these functions well, but at a much great risk in terms of causing return addresses to be problematic and in creating DDoS attacks. > > If SPF is not checked at the channel, then assurances provided the > > recipient by the SPF mechanism is highly suspect and provides > > motivations for attack. SPF will also likely lead to greater > > restrictions on the use of mail addresses and the ability to forward > > mail to a common account. Both of these outcomes will be onerous for > > users and providers and again offer motivation for attack. > > Not onerous given Unified SPF, which I think you're familiar with. > These folks are very unlikely to attack the system. Spammers are likely > to attack the system. (Where by attack, I mean not just in the 'argue > against' sense, but a real military (e.g. DDoS) sense.) There are significant problems using a SPF TXT record for CSV. CSV uses the HELO domain and not the return path domain. This record must be specific about the domain sending the mail stream to accurately assess accountability. Such an assessment is not enabled by the SPF record. The resolution of the HELO domain will likely require a specific record label different from that of SPF. I see the SRV record being far more appropriate for use with CSV for these reasons. If there is to be "unification," I would hope to see a required channel check using CSV and then, if there is a desire for "protections" offered by SPF, perform these SPF checks in parallel but of course using SPF records. > > CSV does not change the way mail is used and, for most users, they will > > only notice a reduction in abuse as it can quickly identify infected > > systems. Unlike an address method of vetting a sending SMTP client, use > > of a domain name allows a greater history to be acquired, even where the > > address may be dynamically assigned or shared and allow assertions of > > affiliations. Vetting a domain name that handles the mail allows > > greater speed and accuracy as opposed to only an IP address. > > If it turns out that SPF adoption leads to significant network harm, > then it would be possible to tweak it or replace it with something more > effective, with narrower scope, in particular CSV. This is a valuable > discussion. Let's flesh out more your attack scenario, so we can be > proactive about this. Keep these two specifications separate and apply CSV first for both accurate repudiations and for the protections needed for the possible implementation of SPF. > I could see SPF causing some free DNS providers to go belly up. OTOH, > DNS is a remarkably efficient protocol, so perhaps SPF is sufficiently > lightweight. I fail to see how publishing the correlation of users to domains is ever going to be lightweight. > It seems that traditional BLs were near the tipping point- concerted > DDoS attacks brought down some BLs, but were unable to take down > others. MARID should be more stable than that. > > I think we may need to wait for Unified SPF to become an I-D; it's > difficult to flesh out its DDoS exposure right now. I suspect it is > more resistant. I see genuine value in moving CSV forward irrespective of the deployment of SPF. I see much better ways to identify authors and again point to the Fenton proposal as how to strongly identify the author without breaking mail. I expect CSV being a far more effective tool against mail abuse and a far more effective tool for enforcement. -Doug From owner-ietf-mxcomp@mail.imc.org Mon Jun 28 15:43:05 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26381 for ; Mon, 28 Jun 2004 15:43:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5SJXXFb005698; Mon, 28 Jun 2004 12:33:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5SJXXPc005697; Mon, 28 Jun 2004 12:33:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5SJXV7s005691 for ; Mon, 28 Jun 2004 12:33:32 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25757; Mon, 28 Jun 2004 15:33:33 -0400 (EDT) Message-Id: <200406281933.PAA25757@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-mxcomp@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-marid-core-01.txt Date: Mon, 28 Jun 2004 15:33:33 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the MTA Authorization Records in DNS Working Group of the IETF. Title : MTA Authentication Records in DNS Author(s) : J. Lyon, M. Wong Filename : draft-ietf-marid-core-01.txt Pages : 27 Date : 2004-6-25 Internet mail suffers from the fact that much unwanted mail is sent using spoofed addresses û- 'spoofed' in this case means the address is used without the permission of the domain owner. This document describes the following: mechanisms by which a domain owner can publish its set of outgoing MTAs, mechanisms by which SMTP servers can determine what email address is allegedly responsible for most proximately introducing a message into the Internet mail system, and whether that introduction is authorized by the owner of the domain contained in that email address. The specification is carefully tailored to ensure that the overwhelming majority of legitimate emailers, remailers and mailing list operators are already compliant. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marid-core-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-marid-core-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-marid-core-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-28151302.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-marid-core-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-marid-core-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-28151302.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-mxcomp@mail.imc.org Mon Jun 28 15:53:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27090 for ; Mon, 28 Jun 2004 15:53:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5SJY4T1005721; Mon, 28 Jun 2004 12:34:04 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5SJY4oJ005719; Mon, 28 Jun 2004 12:34:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5SJY46q005713 for ; Mon, 28 Jun 2004 12:34:04 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25783; Mon, 28 Jun 2004 15:34:06 -0400 (EDT) Message-Id: <200406281934.PAA25783@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-mxcomp@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-marid-submitter-01.txt Date: Mon, 28 Jun 2004 15:34:05 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the MTA Authorization Records in DNS Working Group of the IETF. Title : SMTP Service Extension for Indicating the Responsible Submitter of an E-mail Message Author(s) : E. Allman, H. Katz Filename : draft-ietf-marid-submitter-01.txt Pages : 12 Date : 2004-6-25 This memo defines an extension to the Simple Mail Transfer Protocol SMTP) service, which allows an SMTP client to specify the responsible submitter of an e-mail message. The responsible submitter is the e- mail address of the entity most recently responsible for introducing a message into the transport stream. This extension helps receiving e-mail servers efficiently determine whether the SMTP client is authorized to transmit mail on behalf of the responsible submitter's domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marid-submitter-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-marid-submitter-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-marid-submitter-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-28151308.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-marid-submitter-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-marid-submitter-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-28151308.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-mxcomp@mail.imc.org Mon Jun 28 16:48:29 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02950 for ; Mon, 28 Jun 2004 16:48:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5SKauTO009921; Mon, 28 Jun 2004 13:36:56 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5SKau7t009920; Mon, 28 Jun 2004 13:36:56 -0700 (PDT) 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.9) with ESMTP id i5SKatVv009893 for ; Mon, 28 Jun 2004 13:36:55 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (verisign.com [65.205.251.55] (may be forged)) by peacock.verisign.com (8.12.10/) with ESMTP id i5SKau9J015600; Mon, 28 Jun 2004 13:36:56 -0700 Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 28 Jun 2004 13:36:57 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Matthew Elvey'" , Douglas Otis Cc: "'IETF MARID WG'" Subject: RE: Will SPF/Unified SPF/SenderID bring down the 'net? Date: Mon, 28 Jun 2004 13:36:53 -0700 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: > If it turns out that SPF adoption leads to significant network harm, > then it would be possible to tweak it or replace it with > something more effective, with narrower scope, in particular CSV. > This is a valuable discussion. Caller-Id required a single packet in each direction for the vase majority of mail interactions. Furthermore this data is cachable. Based on an estimate of about 10 million active email domains we have worst case a problem that is orders of magnitude less than distributing alt.binaries over a flood fill routing algorithm like NNTP. > Let's flesh out more your attack scenario, so we can be > proactive about this. No, lets consign it to the bit bucket where it belongs. The argument is nothing more than big numbers are scary. Many MTAs are already performing multiple DNS queries per email connection without significant impact on net performance, the only threat here comes from the spam. > I could see SPF causing some free DNS providers to go belly > up. I don't see how. > It seems that traditional BLs were near the tipping point- concerted > DDoS attacks brought down some BLs, but were unable to take down > others. There is no issue here, a DDoS attack against WHAT? Sure DDoS attacks against DNS happen. But what is the scenario being suggested here? A DDoS attack against who? Worst case is that the spammer takes out the DNS server of alice.com and then sends impersonation spam from alice.com. Its hardly convincing, bob.com can see that alice.com is unavailable so the forged messages from the spammer get treated as suspect. Sure its bad that alice.com can't send mail when there is a DDos on its dns. So what? DDoS extortion is already a problem, alice.com is probably a bit more worried about the web site being out of service during this period than the fact that the email is being queued. There is a real DDoS against DNS issue, this attack does not make it any worse. If the problem is serious it should be addressed in its own right. It isa quite easy to deal with for MARID, just keep the last valid result from any site irrespective of the cache status and reuse that in the case of a system being unavailable. From owner-ietf-mxcomp@mail.imc.org Mon Jun 28 17:11:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06136 for ; Mon, 28 Jun 2004 17:11:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5SKoCNs010758; Mon, 28 Jun 2004 13:50:12 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5SKoChU010757; Mon, 28 Jun 2004 13:50:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5SKoC1M010747 for ; Mon, 28 Jun 2004 13:50:12 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: izcvtX5KVqK0UdNFKiq5lw 1088455812 Received: from [142.131.246.167] (unknown [142.131.246.167]) by mail.messagingengine.com (Postfix) with ESMTP id 13F96C0D9E2; Mon, 28 Jun 2004 16:50:11 -0400 (EDT) Message-ID: <40E08484.2010701@elvey.com> Date: Mon, 28 Jun 2004 13:50:12 -0700 From: Matthew Elvey User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Harry Katz Cc: IETF MARID List Subject: Re: draft-ietf-marid-submitter-01.txt References: In-Reply-To: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/28/04 11:09 AM, Harry Katz sent forth electrons to convey: >On Monday, June 28, 2004 9:36 AM, Greg Connor wrote: > > > >>On Mon, 28 Jun 2004, Matthew Elvey wrote: >> >> >> >>>Only if you're assuming that the SUBMITTER is added following 'the >>>rules'. The spec doesn't say that mail with a falsified SUBMITTER >>>should be refused or discarded. (I hate all the >>> >>> >>pussyfooting around >> >> >>>the discard option.) >>> >>> >>Actually that was the original intent -- if it didn't get >>added to the draft it probably should be. A message that >>claims a certain SUBMITTER but doesn't have that address in >>the right place should be rejected after DATA and should not >>be accepted. >> >> >> > >The spec does say this. > Yes. The paragraph you quote is preceeded by: "If the above tests indicate that the connecting SMTP client is not authorized to transmit e-mail messages on behalf of the SUBMITTER domain, the receiving SMTP server MAY reject the message using "550 5.7.1 Submitter not allowed." The receiving SMTP server MAY alternatively proceed to read the message and apply local policy." If the spec is interpreted procedurally, the above could take precedence over the below. That threw me. The reverse precedence is desired. (Case where SUBMITTER does not match header and is not allowed.) > From section 4.2: > > If the receiving SMTP server allows the connecting SMTP client to > transmit message data, then the server SHOULD determine the purported > responsible address of the message by examining the RFC 2822 message > headers as described in [SENDER-ID]. If this purported responsible > address does not match the address appearing in the SUBMITTER > parameter, the receiving SMTP server MUST reject the message using > "550 5.7.1 Submitter does not match header." > >If this needs some further clarification, please let me know. > > > >>>Also, I have thought of a possible legal problem ... >>> Thank, issue resolved. While I'm noting issues in the spec, may I suggest s/firm/entity/ is necessary? Or are firms the only entities with rights anymore? :(... -I can see the headlines now! :) From owner-ietf-mxcomp@mail.imc.org Mon Jun 28 17:30:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08271 for ; Mon, 28 Jun 2004 17:30:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5SLJKOv013940; Mon, 28 Jun 2004 14:19:20 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5SLJKZX013939; Mon, 28 Jun 2004 14:19:20 -0700 (PDT) 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.9) with ESMTP id i5SLJJ63013932 for ; Mon, 28 Jun 2004 14:19:20 -0700 (PDT) (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 E0E71132CFC for ; Mon, 28 Jun 2004 17:19:22 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id AA2D3698; Mon, 28 Jun 2004 17:19:22 -0400 (EDT) Date: Mon, 28 Jun 2004 17:19:22 -0400 From: Meng Weng Wong To: ietf-mxcomp@imc.org Subject: Problem scenarios for SPF vs CSV Message-ID: <20040628211922.GR13225@dumbo.pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: During the Jabber chat, which is viewable at http://www.xmpp.org/ietf-logs/marid@ietf.xmpp.org/2004-06-28.html We agreed to explore the scenarios in which using an SPF query against the HELO domain leads to problems due to overloading. Problem scenarios should start out with: HELO xxx MAIL FROM: They should go on to describe how CSV views the situation, how SPF-against-HELO views the situation, and how the SPF story is problematic in a way the CSV story is not. We should leave aside for now questions of whether the SPF lookup is significantly "heavier-weight" than the CSV lookup. thanks meng From owner-ietf-mxcomp@mail.imc.org Mon Jun 28 19:06:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20954 for ; Mon, 28 Jun 2004 19:06:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5SMrYkM020690; Mon, 28 Jun 2004 15:53:34 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5SMrYuW020689; Mon, 28 Jun 2004 15:53:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.mail-abuse.org [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5SMrTLT020680 for ; Mon, 28 Jun 2004 15:53:33 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.mail-abuse.org (DDev.mail-abuse.org [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id D586A414AC; Mon, 28 Jun 2004 15:53:34 -0700 (PDT) Subject: RE: Will SPF/Unified SPF/SenderID bring down the 'net? From: Douglas Otis To: "Hallam-Baker, Phillip" Cc: "'Matthew Elvey'" , "'IETF MARID WG'" In-Reply-To: References: Content-Type: text/plain Message-Id: <1088463214.4615.258.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 28 Jun 2004 15:53:34 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 2004-06-28 at 13:36, Hallam-Baker, Phillip wrote: > > If it turns out that SPF adoption leads to significant network > > harm, then it would be possible to tweak it or replace it with > > something more effective, with narrower scope, in particular CSV. > > This is a valuable discussion. > > Caller-Id required a single packet in each direction for the vast > majority of mail interactions. > > Furthermore this data is cachable. > > Based on an estimate of about 10 million active email domains > we have worst case a problem that is orders of magnitude less than > distributing alt.binaries over a flood fill routing algorithm > like NNTP. Again, this was in regard to an attack scenario. Assuming best case does not provide meaningful analysis nor is DNS on par with NNTP. > > Let's flesh out more your attack scenario, so we can be > > proactive about this. > > No, lets consign it to the bit bucket where it belongs. The > argument is nothing more than big numbers are scary. > > Many MTAs are already performing multiple DNS queries per > email connection without significant impact on net performance, > the only threat here comes from the spam. Those queries are often to _known_ DNS servers done in parallel. The number of these SPF queries may be chained into a series of 20 queries using the prior SPF specifications. If SPF employed at the MTA forces a defensive mode of closing lists in response to possible DDoS attacks, then these records WILL become more complex to allow the oft needed ability to originate mail from different locations. This complexity introduces a growing hazard. > > I could see SPF causing some free DNS providers to go belly > > up. > > I don't see how. Perhaps reviewing the original message http://www.imc.org/ietf-mxcomp/mail-archive/msg02198.html I could formulate overhead for DNS being roughly the TXT record size + 110 bytes plus the name size assuming just the TXT record was returned in the query. This increases again with the need to discover the NS and SOA for a domain. If the attacker sent spoofed messages to multiple destinations, then the receiving MTAs create DDoS conditions with efforts to query the same server not robust enough to handle the resulting load. This does not require each domain to list 20 records, but rather each domain offers an additional reference on average. If it resolved, the search would conclude, but as this is spoofed, the search continues until the limit or the lists become exhausted. It really does not matter if the list is open or closed for this to be an expensive exercise. > > It seems that traditional BLs were near the tipping point- concerted > > DDoS attacks brought down some BLs, but were unable to take down > > others. > > There is no issue here, a DDoS attack against WHAT? The spoofed source is the means of attack. This happens as the SPF looks to the message source to ascertain permissions. Meng has suggested yet another level of HELO domain queries be added to this sequence as a means to unify SPF+CSV. :-0 > Sure DDoS attacks against DNS happen. But what is the scenario being > suggested here? A DDoS attack against who? > > Worst case is that the spammer takes out the DNS server of alice.com > and then sends impersonation spam from alice.com. Its hardly convincing, > bob.com can see that alice.com is unavailable so the forged messages > from the spammer get treated as suspect. > > Sure its bad that alice.com can't send mail when there is a DDos > on its dns. So what? DDoS extortion is already a problem, alice.com > is probably a bit more worried about the web site being out of service > during this period than the fact that the email is being queued. The problem is not with a particular destination or spoofed source. The problem is that the mail channel becomes clogged if checking SPF in addition to unfortunate DNS servers being hammered. It could be the DNS records are maniacally constructed with short TTLs and the DNS servers engineered to be erratic. I suspect that as SPF becomes widely used, neither of these efforts will be required to stage an attack however. > There is a real DDoS against DNS issue, this attack does not make it > any worse. If the problem is serious it should be addressed in its own > right. That would be to not approve the SPF approach as being inherently prone to abuse DNS and thereby clog mail servers? That would then be to not approve SPF, as with its extensibility, it is inherently abusive to DNS cache? > It isa quite easy to deal with for MARID, just keep the last valid result > from any site irrespective of the cache status and reuse that in the case of > a system being unavailable. These results can be very large as compared to a typical DNS query. If each MTA SPF record contained less than 2 indirections and resulted with an average of 10 overall, this would then represent about 4K bytes of records and perhaps 2 to 3 times this amount in cache. Seeing 80,000 sources per day could mean about 1 GB of DNS cache would be needed. If the average number of indirections exceeded 2, then the number of indirections would require some arbitrary restriction as to the depth allowed. Presently this is set to 20. If so, just double these numbers and reduce throughput even further. This would imply it becomes critical the order records are queried and how loops are discovered. In other words, SPF does not scale and DNS suffers as a result. : < -Doug From owner-ietf-mxcomp@mail.imc.org Mon Jun 28 19:47:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24427 for ; Mon, 28 Jun 2004 19:47:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5SNWQup023550; Mon, 28 Jun 2004 16:32:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5SNWQKv023549; Mon, 28 Jun 2004 16:32:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5SNWPXv023540 for ; Mon, 28 Jun 2004 16:32:25 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: dlj8Vwpdu+sCaQihMxDhNg 1088465547 Received: from [192.168.123.4] (unknown [209.133.65.190]) by mail.messagingengine.com (Postfix) with ESMTP id A2700C0D9A0; Mon, 28 Jun 2004 19:32:25 -0400 (EDT) Message-ID: <40E0AA8B.2050105@elvey.com> Date: Mon, 28 Jun 2004 16:32:27 -0700 From: Matthew Elvey User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hallam-Baker, Phillip" Cc: Douglas Otis , "'IETF MARID WG'" Subject: Re: Will SPF/Unified SPF/SenderID bring down the 'net? References: In-Reply-To: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/28/04 1:36 PM, Hallam-Baker, Phillip sent forth electrons to convey: > > >>If it turns out that SPF adoption leads to significant network harm, >>then it would be possible to tweak it or replace it with >>something more effective, with narrower scope, in particular CSV. >>This is a valuable discussion. >> >> > <> > Caller-Id required a single packet in each direction for the vas[t] > majority of mail interactions. > Please watch your tone. That's incorrect. Please read the earlier post to this thread at http://www.imc.org/ietf-mxcomp/mail-archive/msg02198.html as it argues that this is not the case. I don't see you addressing the concerns Doug raised. Perhaps you were arguing that all mail servers should rely on local caching DNS servers that will cache all the word's active LMAP records. If that's the case, then *perhaps* that does present a strong DDoS defense. Please confirm/flesh out. Does it work in the face of malicious macro SPF records? BTW, I wonder if it would make sense to specify that caching DNS servers MAY cache LMAP records for x hours, even if they have a short TTL. This would reduce DDoS exposure. At what cost, and what's a good x? Without this, it's appropriate to assume that the attackers will publish LMAP records with TTLs ~= 0. MARID provides additional motivation for DDoS against the DNS. From owner-ietf-mxcomp@mail.imc.org Mon Jun 28 19:50:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24651 for ; Mon, 28 Jun 2004 19:50:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5SNecRE024815; Mon, 28 Jun 2004 16:40:38 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5SNecpx024814; Mon, 28 Jun 2004 16:40:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5SNebJI024808 for ; Mon, 28 Jun 2004 16:40:37 -0700 (PDT) (envelope-from hkatz@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 28 Jun 2004 16:40:47 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 28 Jun 2004 16:40:43 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 28 Jun 2004 16:40:37 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-fido-msg.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 28 Jun 2004 16:40:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: draft-ietf-marid-submitter-01.txt Date: Mon, 28 Jun 2004 16:40:42 -0700 Message-ID: Thread-Topic: draft-ietf-marid-submitter-01.txt thread-index: AcRdU/UnfzbDh7hvSvWfmyA0NTPnfwAFDpQw From: "Harry Katz" To: "Matthew Elvey" , "IETF MARID List" X-OriginalArrivalTime: 28 Jun 2004 23:40:43.0821 (UTC) FILETIME=[542A15D0:01C45D69] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5SNebJI024809 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Monday, June 28, 2004 1:50 PM, Matthew Elvey wrote: > On 6/28/04 11:09 AM, Harry Katz sent forth electrons to convey: > > >On Monday, June 28, 2004 9:36 AM, Greg Connor wrote: > > > > > > > >>On Mon, 28 Jun 2004, Matthew Elvey wrote: > >> [snip] > > > Yes. The paragraph you quote is preceeded by: > > "If the above tests indicate that the connecting SMTP > client is not > authorized to transmit e-mail messages on behalf of the SUBMITTER > domain, the receiving SMTP server MAY reject the message > using "550 > 5.7.1 Submitter not allowed." The receiving SMTP server MAY > alternatively proceed to read the message and apply local policy." > > If the spec is interpreted procedurally, the above could take > precedence over the below. > That threw me. The reverse precedence is desired. (Case > where SUBMITTER does not match header and is not allowed.) Good point. If the last sentence of this paragraph is removed, would that make things clearer? It's redundant with the paragraph I quoted (repeated below). > > > From section 4.2: > > > > If the receiving SMTP server allows the connecting SMTP client to > > transmit message data, then the server SHOULD determine > the purported > > responsible address of the message by examining the RFC > 2822 message > > headers as described in [SENDER-ID]. If this purported > responsible > > address does not match the address appearing in the SUBMITTER > > parameter, the receiving SMTP server MUST reject the > message using > > "550 5.7.1 Submitter does not match header." > > > >If this needs some further clarification, please let me know. > > > > From owner-ietf-mxcomp@mail.imc.org Mon Jun 28 20:49:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27646 for ; Mon, 28 Jun 2004 20:49:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5T0U6Sr028021; Mon, 28 Jun 2004 17:30:06 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5T0U6KL028020; Mon, 28 Jun 2004 17:30:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5T0U5cC028014 for ; Mon, 28 Jun 2004 17:30:06 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: dHF+xw9APuGbunoSD4znTQ 1088469009 Received: from [192.168.123.4] (unknown [209.133.65.190]) by mail.messagingengine.com (Postfix) with ESMTP id 1CF8EC0D90F; Mon, 28 Jun 2004 20:30:08 -0400 (EDT) Message-ID: <40E0B811.60004@elvey.com> Date: Mon, 28 Jun 2004 17:30:09 -0700 From: Matthew Elvey User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Harry Katz Cc: MXCOMP Subject: Re: draft-ietf-marid-submitter-01.txt References: In-Reply-To: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/28/04 4:40 PM, Harry Katz sent forth electrons to convey: > >On Monday, June 28, 2004 1:50 PM, Matthew Elvey wrote: > > > >>On 6/28/04 11:09 AM, Harry Katz sent forth electrons to convey: >> >> >> >>>On Monday, June 28, 2004 9:36 AM, Greg Connor wrote: >>> >>> >>> >>> >>> >>>>On Mon, 28 Jun 2004, Matthew Elvey wrote: >>>> >>>> >>>> > >[snip] > > > >>Yes. The paragraph you quote is preceeded by: >> >> "If the above tests indicate that the connecting SMTP >>client is not >> authorized to transmit e-mail messages on behalf of the SUBMITTER >> domain, the receiving SMTP server MAY reject the message >>using "550 >> 5.7.1 Submitter not allowed." The receiving SMTP server MAY >> alternatively proceed to read the message and apply local policy." >> >>If the spec is interpreted procedurally, the above could take >>precedence over the below. >>That threw me. The reverse precedence is desired. (Case >>where SUBMITTER does not match header and is not allowed.) >> >> > >Good point. If the last sentence of this paragraph is removed, would >that make things clearer? It's redundant with the paragraph I quoted >(repeated below). > > > Still isn't clear to me. You've still got a MAY in the first paragraph, followed by a SHOULD in the second. One should have precedence (also I don't see why one is MAY and the other SHOULD). Got the s/firm/entity/ fix? >>>From section 4.2: >>> >>> If the receiving SMTP server allows the connecting SMTP client to >>> transmit message data, then the server SHOULD determine >>> >>> >>the purported >> >> >>> responsible address of the message by examining the RFC >>> >>> >>2822 message >> >> >>> headers as described in [SENDER-ID]. If this purported >>> >>> >>responsible >> >> >>> address does not match the address appearing in the SUBMITTER >>> parameter, the receiving SMTP server MUST reject the >>> >>> >>message using >> >> >>> "550 5.7.1 Submitter does not match header." >>> >>>If this needs some further clarification, please let me know. >>> >>> >>> > > > From owner-ietf-mxcomp@mail.imc.org Mon Jun 28 21:08:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28407 for ; Mon, 28 Jun 2004 21:08:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5T0mXVc029511; Mon, 28 Jun 2004 17:48:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5T0mXMu029510; Mon, 28 Jun 2004 17:48:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5T0mW9Q029499 for ; Mon, 28 Jun 2004 17:48:32 -0700 (PDT) (envelope-from hkatz@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 28 Jun 2004 17:48:43 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 28 Jun 2004 17:48:38 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 28 Jun 2004 17:48:35 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-fido-msg.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 28 Jun 2004 17:48:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: draft-ietf-marid-submitter-01.txt Date: Mon, 28 Jun 2004 17:48:36 -0700 Message-ID: Thread-Topic: draft-ietf-marid-submitter-01.txt thread-index: AcRdcD6ySdkAwT4lRTCx2yg7rqpUuAAALhSg From: "Harry Katz" To: "Matthew Elvey" , "MXCOMP" X-OriginalArrivalTime: 29 Jun 2004 00:48:34.0664 (UTC) FILETIME=[CE936E80:01C45D72] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5T0mW9Q029500 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Monday, June 28, 2004 5:30 PM, Matthew Elvey [mailto:matthew@elvey.com] wrote: > Still isn't clear to me. You've still got a MAY in the first > paragraph, followed by a SHOULD in the second. One should > have precedence (also I don't see why one is MAY and the > other SHOULD). OK, here's a proposed revision to the two paragraphs in 4.2 we've been discussing: If the above tests indicate that the connecting SMTP client is not authorized to transmit e-mail messages on behalf of the SUBMITTER domain, the receiving SMTP server SHOULD reject the message using "550 5.7.1 Submitter not allowed." If the receiving SMTP server allows the connecting SMTP client to transmit message data, then the server SHOULD determine the purported responsible address of the message by examining the RFC 2822 message headers as described in [SENDER-ID]. If this purported responsible address does not match the address appearing in the SUBMITTER parameter, the receiving SMTP server MUST reject the message using "550 5.7.1 Submitter does not match header." So there is an ordering here: - First, the receiver checks the to see if the SUBMITTER domain passes the Sender ID check. - Second, if the receiver decides to accept message data (either because SUBMITTER passed the check, or because SUBMITTER failed the check but the receiver decided to accept message data anyway) then the receiver should ensure the SUBMITTER value matches the PRA and reject if there's a mismatch. > Got the s/firm/entity/ fix? Yes. From owner-ietf-mxcomp@mail.imc.org Mon Jun 28 21:08:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28460 for ; Mon, 28 Jun 2004 21:08:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5T0umjS030102; Mon, 28 Jun 2004 17:56:48 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5T0umdh030101; Mon, 28 Jun 2004 17:56:48 -0700 (PDT) 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.9) with ESMTP id i5T0ulV4030095 for ; Mon, 28 Jun 2004 17:56:47 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC04.vcorp.ad.vrsn.com ([65.205.251.33]) by peacock.verisign.com (8.12.10/) with ESMTP id i5T0uqCN021864; Mon, 28 Jun 2004 17:56:52 -0700 Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 28 Jun 2004 17:56:15 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Matthew Elvey'" , "Hallam-Baker, Phillip" Cc: Douglas Otis , "'IETF MARID WG'" Subject: RE: Will SPF/Unified SPF/SenderID bring down the 'net? Date: Mon, 28 Jun 2004 17:56:13 -0700 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: > > <> > > Caller-Id required a single packet in each direction for the vas[t] > > majority of mail interactions. > > > > Please watch your tone. > That's incorrect. Please read the earlier post to this thread at > http://www.imc.org/ietf-mxcomp/mail-archive/msg02198.html > as it argues that this is not the case. I fail to see the connection between an argument that a 20% increase in data size due to use of XML is significant and the current claim that we risk bringing down the Internet with Sender ID. > I don't see you addressing the concerns Doug raised. There is a proof point here that it is possible to encode the hotmail IP addresses in three packets of data, most records in one packet. Ergo if we end up with something that is dramatically worse than that, like an order of magnitude out there is something really wrong with the protocol we have come up with. > Perhaps you were arguing that all mail servers should rely on local > caching DNS servers that will cache all the word's active > LMAP records. > If that's the case, then *perhaps* that does present a strong DDoS > defense. Please confirm/flesh out. Does it work in the face of > malicious macro SPF records? Only if we decide to support the macro interface. I was hoping that we would reject it on the grounds that all the use cases that have been stated can be implemented anyway. If what you are trying to say is that there must be some limit to the complexity of a query I think that is correct, clearly it is a bad thing if records branch out indefinitely. That is an issue that calls for a security consideration, not hysterical subject headers. > BTW, I wonder if it would make sense to specify that caching > DNS servers > MAY cache LMAP records for x hours, even if they have a short TTL. > This would reduce DDoS exposure. At what cost, and what's a good x? > Without this, it's appropriate to assume that the attackers > will publish LMAP records with TTLs ~= 0. How about simply stating that if a MARID record is retreived and determined to be malicious an MTA SHOULD consider caching that conclusion? If malicious.com or compromised.com have a malicious record in their DNS it should become apparent quite quickly. Also remember that the sender has to be holding an open TCP session during this process with a known source IP port. This is not exactly an anonymous attack. Even if the attack is comming from a zombie, it is worth at least a thousand packets to be able to determine that there is a likely zombie on a network somewhere. No more spam from you, plus report it to the sysadmin responsible. > MARID provides additional motivation for DDoS against the DNS. The argument makes no sense unless you can state which part of the DNS is going to be attacked and how such an attack would make it easier to send spam. The attack that appears likely to me would be for the attacker to send a stream of DNS queries to sender.com which appear to come from receiver.com so that sender.com decides to stop responding to requests from that site, then broadcast a stream of spam. Seems to me that any such attack has the problem that the attack and likely motive become immediately obvious to sender.com. All we need to do is to work out a way to close the loop. From owner-ietf-mxcomp@mail.imc.org Mon Jun 28 21:39:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29504 for ; Mon, 28 Jun 2004 21:39:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5T1OEbq032397; Mon, 28 Jun 2004 18:24:14 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5T1OEvL032396; Mon, 28 Jun 2004 18:24:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5T1ODG1032390 for ; Mon, 28 Jun 2004 18:24:14 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: eQLBkPsmjsNNLnLoaICxVg 1088472255 Received: from [192.168.123.4] (unknown [209.133.65.190]) by mail.messagingengine.com (Postfix) with ESMTP id 2CAA3C0DE1E; Mon, 28 Jun 2004 21:24:13 -0400 (EDT) Message-ID: <40E0C4BF.9030101@elvey.com> Date: Mon, 28 Jun 2004 18:24:15 -0700 From: Matthew Elvey User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hallam-Baker, Phillip" Cc: Douglas Otis , "'IETF MARID WG'" Subject: Re: Will SPF/Unified SPF/SenderID bring down the 'net? References: In-Reply-To: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/28/04 5:56 PM, Hallam-Baker, Phillip sent forth electrons to convey: >>><> >>>Caller-Id required a single packet in each direction for the vas[t] >>>majority of mail interactions. >>> >>> >>> >>Please watch your tone. >>That's incorrect. Please read the earlier post to this thread at >>http://www.imc.org/ietf-mxcomp/mail-archive/msg02198.html >>as it argues that this is not the case. >> >> > >I fail to see the connection between an argument that a 20% > That's not what I'm talking about. Consider the whole post, particularly paragraphs 1-3. Arrgh. The URL is above. >That is an issue that calls for a security consideration, not >hysterical subject headers. > > Ah, that's what set you off. Please address paragraphs 1-3 or don't respond. > > > >>BTW, I wonder if it would make sense to specify that caching >>DNS servers >>MAY cache LMAP records for x hours, even if they have a short TTL. >>This would reduce DDoS exposure. At what cost, and what's a good x? >>Without this, it's appropriate to assume that the attackers >>will publish LMAP records with TTLs ~= 0. >> >> > >How about simply stating that if a MARID record is retreived and >determined to be malicious an MTA SHOULD consider caching that >conclusion? > > An alternative with pluses and minuses. >If malicious.com or compromised.com have a malicious record in >their DNS it should become apparent quite quickly. > > I don't see how. Say 9/10s of a domain's record resolves. How is this domain identifiable as malicious? Maybe it's just under attack. >Also remember that the sender has to be holding an open TCP >session during this process with a known source IP port. This >is not exactly an anonymous attack. > > Again, how is a malicious actor identified automatically? >Even if the attack is comming from a zombie, it is worth at >least a thousand packets to be able to determine that there is >a likely zombie on a network somewhere. No more spam from you, >plus report it to the sysadmin responsible. > > > > >>MARID provides additional motivation for DDoS against the DNS. >> >> > >The argument makes no sense unless you can state which part of the >DNS is going to be attacked and how such an attack would make it >easier to send spam. > > Same way taking down BLs works. It makes 'em problematic (e.g unreliable and/or very resource intensive), so folks stop using 'em. >The attack that appears likely to me would be for the attacker to >send a stream of DNS queries to sender.com which appear to come from >receiver.com so that sender.com decides to stop responding to >requests from that site, then broadcast a stream of spam. > > >Seems to me that any such attack has the problem that the attack >and likely motive become immediately obvious to sender.com. All >we need to do is to work out a way to close the loop. > > And how do we do that? From owner-ietf-mxcomp@mail.imc.org Mon Jun 28 23:06:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02429 for ; Mon, 28 Jun 2004 23:06:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5T2ref2038032; Mon, 28 Jun 2004 19:53:40 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5T2resI038031; Mon, 28 Jun 2004 19:53:40 -0700 (PDT) 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.9) with ESMTP id i5T2re0T038025 for ; Mon, 28 Jun 2004 19:53:40 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54] (may be forged)) by peacock.verisign.com (8.12.10/) with ESMTP id i5T2riCN001515; Mon, 28 Jun 2004 19:53:44 -0700 Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 28 Jun 2004 19:53:45 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Matthew Elvey'" , "Hallam-Baker, Phillip" Cc: Douglas Otis , "'IETF MARID WG'" Subject: RE: Will SPF/Unified SPF/SenderID bring down the 'net? Date: Mon, 28 Jun 2004 19:53:38 -0700 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 fail to see the connection between an argument that a 20% > > > That's not what I'm talking about. Consider the whole post, > particularly paragraphs 1-3. Arrgh. > The URL is above. How about you or Doug try to post a clear attack scenario that shows exactly how such an attack would be performed? I have great difficulty parsing the paragraphs, let alone making sense of statements such as "If used in the normal fashion, no parser is required to utilize DNS answers, so the introduction of a parser increases vulnerabilities. " It is a matter of indisputable fact that all interpretation of DNS records requires the use of some form of parser. So the above appears to be nonsense. "The less rigid and more extensible the syntax, the greater the vulnerabilities. " It is also a matter of indisputable fact that XML can be parsed using a finite state machine of less than 20 states acompanied by a simple stack. I have written such a parser several times. It would therefore seem to me that the competence of the coder is the significant factor here rather than the choice of syntax which is at any rate moot at this point. Having got to the end of paragraph 1 I am unable to find any issue of relevance outside the XML debate, is it possible that you have given the wrong URL? "An attacker "jamming" the checking mechanism might set up DNS servers for domains they control that respond erratically and offer complex record sets with small TTLs." So a DDoS attack on your own ability to send email. this can be addressed by a security consideration. If you have to resolve more than X records then consider the data spurious and reject the mail. "As example, a mail server is receiving 50 messages per second that average 4 K bytes in size." Assume that three contain powerpoint presentations of 1Mb, four contain word documents of 500Kb and five pictures of little Timmy. that would be a more realistic load, but it would prevent the dire conclusion "These 10 queries will also add to the traffic at 350 bytes per record a total of 4K bytes of additional traffic for a doubling of the network load." assuming the attack is present on every email. And the mail server does not get clever and stop accepting emails from malicious IP addresses. Estimates of the number of compromised hosts on the Internet vary, but the highest number in a botnet tends to be in the tens of thousands. If the attacker is using a different bot for each connection that is 3000 bots per minute, 180,000 per hour. This is an attack I really really would like to see, we could map out the zombies on the Internet pretty quick. [Why not just DDoS the email server direct and have done with it????] > >That is an issue that calls for a security consideration, not > >hysterical subject headers. > > > Ah, that's what set you off. Please address paragraphs 1-3 or don't > respond. Please give a clear statement of the issue you are trying to raise. Repeated claims that the issue has been stated do nothing at all. > >If malicious.com or compromised.com have a malicious record in > >their DNS it should become apparent quite quickly. > > > > > I don't see how. Say 9/10s of a domain's record resolves. > How is this > domain identifiable as malicious? > Maybe it's just under attack. If it is under attack then it probably should be ignored until it recovers. All the mail 'from' that source is most likely spam anyway. > >Also remember that the sender has to be holding an open TCP > >session during this process with a known source IP port. This > >is not exactly an anonymous attack. > > > Again, how is a malicious actor identified automatically? By logging the IP address of the source of the attack. > >The argument makes no sense unless you can state which part of the > >DNS is going to be attacked and how such an attack would make it > >easier to send spam. > > > Same way taking down BLs works. It makes 'em problematic (e.g > unreliable and/or very resource intensive), so folks stop using 'em. BLs have a single point of failure that is similar to the problem of running core DNS, you take down one part of the network and in time the rest of the net grinds to a halt. You have failled to show that there is a dependency that looks anything like the dependency that a mail server has on a BL or on core DNS. > >Seems to me that any such attack has the problem that the attack > >and likely motive become immediately obvious to sender.com. All > >we need to do is to work out a way to close the loop. > > > > > And how do we do that? Reporting mechanism to allow sender.com to tell receiver.com that it is observing large numbers of packets that appear to be emitted from that domain. From owner-ietf-mxcomp@mail.imc.org Tue Jun 29 00:12:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05342 for ; Tue, 29 Jun 2004 00:12:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5T3vjsm043089; Mon, 28 Jun 2004 20:57:45 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5T3vjhN043088; Mon, 28 Jun 2004 20:57:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5T3viVZ043070 for ; Mon, 28 Jun 2004 20:57:44 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: Exwv4nHWHRAyDh5dY+4ukQ 1088481466 Received: from [192.168.123.4] (unknown [209.133.65.190]) by mail.messagingengine.com (Postfix) with ESMTP id A2B81C0D941; Mon, 28 Jun 2004 23:57:45 -0400 (EDT) Message-ID: <40E0E8B9.2090500@elvey.com> Date: Mon, 28 Jun 2004 20:57:45 -0700 From: Matthew Elvey User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hallam-Baker, Phillip" Cc: Douglas Otis , "'IETF MARID WG'" Subject: Re: Will SPF/Unified SPF/SenderID bring down the 'net? References: In-Reply-To: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/28/04 7:53 PM, Hallam-Baker, Phillip sent forth electrons to convey: > > > > >>>If malicious.com or compromised.com have a malicious record in >>>their DNS it should become apparent quite quickly. >>> >>> >>> >>> >>I don't see how. Say 9/10s of a domain's record resolves. >>How is this >>domain identifiable as malicious? >>Maybe it's just under attack. >> >> > >If it is under attack then it probably should be ignored until >it recovers. All the mail 'from' that source is most likely spam >anyway. > > > Again, how is this domain identifiable as malicious? Many of your points are predicated on having this ability. > > >>>Also remember that the sender has to be holding an open TCP >>>session during this process with a known source IP port. This >>>is not exactly an anonymous attack. >>> >>> >>> >>Again, how is a malicious actor identified automatically? >> >> > >By logging the IP address of the source of the attack. > > Sorry, but what attack? You have to identify the attack as an attack first; see above. > > > >>>The argument makes no sense unless you can state which part of the >>>DNS is going to be attacked and how such an attack would make it >>>easier to send spam. >>> >>> >>> >>Same way taking down BLs works. It makes 'em problematic (e.g >>unreliable and/or very resource intensive), so folks stop using 'em. >> >> > >BLs have a single point of failure that is similar to the problem >of running core DNS, you take down one part of the network and in >time the rest of the net grinds to a halt. > >You have failled to show that there is a dependency that looks anything >like the dependency that a mail server has on a BL or on core DNS. > > What part of "it makes them very resource intensive, so folks stop using 'em" don't you understand? Here's the three paragraphs, with some editing by me. I'm sorry if you don't understand them, but they are clear. It has nothing to to with XML (which is dead, WRT MARID), at least now. Any mechanism introduced that stems the flow of UCE will be subjected to intensive attack. ... As the allowable answer from DNS is small, any chained records further increases vulnerabilities by increasing both resources and time required to process a message. An attacker "jamming" the checking mechanism might set up DNS servers for domains they control that respond erratically and offer complex record sets with small TTLs. The attacker then sends messages from their domains in an attempt to exhaust resources as a means to have recipients disable the checking processes within the channel. (If on average a small enterprise uses two outside services, then normally there will be a need to chain these records as it would be prohibitively difficult to administer otherwise. These outside vendors may in turn also outsource for yet more chaining.) For example, a mail server is receiving 50 messages per second that average 4 K bytes in size. If using the SPF mechanism, checking DNS data is indeterminate as there is no limit for the number of sequential queries required to converge upon an answer. RFC1035 indicates 5 to 10 seconds should be considered a worst case resolver interval. If there becomes an average of 10 queries with an average of 5 seconds a query, then this limits each process to about 1 message about every minute. These 10 queries will also add to the traffic at 350 bytes per record a total of 4K bytes of additional traffic for a doubling of the network load. The mail server may normally handle 1,500 simultaneous processes, but at 60 seconds per process, the mail server is reduced to only running 25 messages a second. This may still represent the same amount of network traffic, just half as much mail gets through the network. You cannot redefine the size of the emails the attacker sends to make the attack less effective. From owner-ietf-mxcomp@mail.imc.org Tue Jun 29 00:32:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05932 for ; Tue, 29 Jun 2004 00:32:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5T4KBPG045162; Mon, 28 Jun 2004 21:20:11 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5T4KBY7045161; Mon, 28 Jun 2004 21:20:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5T4KAFG045155 for ; Mon, 28 Jun 2004 21:20:10 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: 3GUT9GuE72N0qQPxVqDoFA 1088482817 Received: from [192.168.123.4] (unknown [209.133.65.190]) by mail.messagingengine.com (Postfix) with ESMTP id D54C2C0D955; Tue, 29 Jun 2004 00:20:16 -0400 (EDT) Message-ID: <40E0EDFE.50504@elvey.com> Date: Mon, 28 Jun 2004 21:20:14 -0700 From: Matthew Elvey User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Harry Katz Cc: MXCOMP Subject: Re: draft-ietf-marid-submitter-01.txt References: In-Reply-To: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . 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: Content-Transfer-Encoding: 7bit On 6/28/04 5:48 PM, Harry Katz sent forth electrons to convey: > >OK, here's a proposed revision to the two paragraphs in 4.2 we've been >discussing: > > That works. >>Got the s/firm/entity/ fix? >> >> >Yes. > > Good. Here's another issue: >4. The SUBMITTER Parameter of the MAIL Command > > If the SMTP server supports the SUBMITTER extension, then the SMTP > client MAY include the SUBMITTER parameter in MAIL commands issued > during the SMTP session. > Change to MUST when != From? From owner-ietf-mxcomp@mail.imc.org Tue Jun 29 00:32:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05951 for ; Tue, 29 Jun 2004 00:32:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5T4MFOK045290; Mon, 28 Jun 2004 21:22:15 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5T4MF4A045289; Mon, 28 Jun 2004 21:22:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.mail-abuse.org [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5T4MFiO045280 for ; Mon, 28 Jun 2004 21:22:15 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.mail-abuse.org (DDev.mail-abuse.org [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id D85DB41497; Mon, 28 Jun 2004 21:22:18 -0700 (PDT) Subject: RE: Will SPF/Unified SPF/SenderID bring down the 'net? From: Douglas Otis To: "Hallam-Baker, Phillip" Cc: "'Matthew Elvey'" , "'IETF MARID WG'" In-Reply-To: References: Content-Type: text/plain Message-Id: <1088482938.4998.69.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 28 Jun 2004 21:22:18 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 2004-06-28 at 19:53, Hallam-Baker, Phillip wrote: > > >I fail to see the connection between an argument that a 20% > > > > > That's not what I'm talking about. Consider the whole post, > > particularly paragraphs 1-3. Arrgh. > > The URL is above. > > How about you or Doug try to post a clear attack scenario > that shows exactly how such an attack would be performed? I thought it was clear. > I have great difficulty parsing the paragraphs, let alone making > sense of statements such as > > "If used in the normal fashion, no parser is required to utilize DNS > answers, so the introduction of a parser increases vulnerabilities. " I could have said it takes no "additional" parser to utilize A records or SRV records or many other binary responses offered by DNS. > It is a matter of indisputable fact that all interpretation of > DNS records requires the use of some form of parser. So the > above appears to be nonsense. But the task to parse a SPF requires an additional parser added where either the increase in resources needed or errors created handling malformed input exits where there would have been none if such a parser was not added. > "The > less rigid and more extensible the syntax, the greater the > vulnerabilities. " > > It is also a matter of indisputable fact that XML can be parsed > using a finite state machine of less than 20 states acompanied by > a simple stack. I have written such a parser several times. The larger these records are allowed to grow or the greater their numbers, the greater their risk. I thought the XML issue was resolved. I have yet to see any evidence of this however and this question seems odd in that respect. > "An attacker "jamming" the checking mechanism might set up DNS servers > for domains they control that respond erratically and offer complex > record sets with small TTLs." > > So a DDoS attack on your own ability to send email. this can > be addressed by a security consideration. If you have to resolve > more than X records then consider the data spurious and reject > the mail. Exactly. The goal would be to slow reception and thereby allow greater distribution to a larger array of servers. What is this limit? What is the average number of references to other domains? > "As example, a mail server is receiving 50 messages per second that > average 4 K bytes in size." > > Assume that three contain powerpoint presentations of 1Mb, four > contain word documents of 500Kb and five pictures of little Timmy. > that would be a more realistic load, but it would prevent the > dire conclusion This was not assuming a bandwidth limitation. I only attempted to illustrate that at half the number of messages, the traffic was not changed. > "These 10 queries will also add to the traffic at 350 bytes per record a > total of 4K bytes of additional traffic for a doubling of the network > load." > > assuming the attack is present on every email. And the mail server > does not get clever and stop accepting emails from malicious IP addresses. This could easily be happening from 80,000 addresses. This is a small number out of millions possible. I would not expect too much effort made from normal tactics however. > Estimates of the number of compromised hosts on the Internet vary, but > the highest number in a botnet tends to be in the tens of thousands. > If the attacker is using a different bot for each connection that > is 3000 bots per minute, 180,000 per hour. Such an estimate is low, but using your 10,000 with just 56 k baud links and .4k per message, that would be 175,000 messages per second. If able to reduce mail performance to 25 messages per second, the attack could hinder 7000 mail servers. Bad news for someone I would suspect. > This is an attack I really really would like to see, we could map > out the zombies on the Internet pretty quick. How? You may have captured a series of dynamic IP addresses and others that simply were transferring real mail. Of these messages, none were rejected as they contain nothing to indicate them to be spam. None of the domains in the return path were from closed lists. You will have made little progress in knowing anything for certain. > [Why not just DDoS the email server direct and have done with it????] The attack is to convince providers SPF is not worth it. > > >If malicious.com or compromised.com have a malicious record in > > >their DNS it should become apparent quite quickly. > > > > > > > > I don't see how. Say 9/10s of a domain's record resolves. > > How is this domain identifiable as malicious? > > Maybe it's just under attack. > > If it is under attack then it probably should be ignored until > it recovers. All the mail 'from' that source is most likely spam > anyway. If there is a slow response to a DNS query, then this identifies the source as a spammer? What type of behavior are you recommending? > > >Also remember that the sender has to be holding an open TCP > > >session during this process with a known source IP port. This > > >is not exactly an anonymous attack. > > > > > Again, how is a malicious actor identified automatically? > > By logging the IP address of the source of the attack. How do you identify the attacker? What is different? > > >The argument makes no sense unless you can state which part of the > > >DNS is going to be attacked and how such an attack would make it > > >easier to send spam. > > > > > Same way taking down BLs works. It makes 'em problematic (e.g > > unreliable and/or very resource intensive), so folks stop using 'em. > > BLs have a single point of failure that is similar to the problem > of running core DNS, you take down one part of the network and in > time the rest of the net grinds to a halt. > > You have failled to show that there is a dependency that looks anything > like the dependency that a mail server has on a BL or on core DNS. I would say there is no analogy with a BL and an MTA checking SPF records. A BL can be scaled to handle DoS attacks as there would be an interest to ensure such. Those running mail will now find themselves under attack as a result of a flood of DNS queries resulting from spoofed mail to MTAs employing the SPF mechanism. > > > Seems to me that any such attack has the problem that the attack > > > and likely motive become immediately obvious to sender.com. All > > > we need to do is to work out a way to close the loop. > > > > And how do we do that? > > Reporting mechanism to allow sender.com to tell receiver.com that it > is observing large numbers of packets that appear to be emitted > from that domain. A reporting mechanism to increase the MTA load during a possible attack that can not identify the source of the attack, but knows it is being attacked because it is taking too long to query DNS? What is the source of a well disguised distributed attack anyway? -Doug From owner-ietf-mxcomp@mail.imc.org Tue Jun 29 00:57:28 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06853 for ; Tue, 29 Jun 2004 00:57:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5T4bfgf046406; Mon, 28 Jun 2004 21:37:41 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5T4bf5B046405; Mon, 28 Jun 2004 21:37:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5T4beSB046399 for ; Mon, 28 Jun 2004 21:37:41 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: BENm4ehwVnlhlIuWnksr/Q 1088483867 Received: from [192.168.123.4] (unknown [209.133.65.190]) by mail.messagingengine.com (Postfix) with ESMTP id E50E9C0DE59; Tue, 29 Jun 2004 00:37:46 -0400 (EDT) Message-ID: <40E0F219.6030509@elvey.com> Date: Mon, 28 Jun 2004 21:37:45 -0700 From: Matthew Elvey User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hallam-Baker, Phillip" Cc: Douglas Otis , "'IETF MARID WG'" Subject: Re: Will SPF/Unified SPF/SenderID bring down the 'net? References: In-Reply-To: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Some more comments. 1)Just a note as to why this discussion is important: It is very relevant to the current agenda item: - Due 2004-07-02: Decide if CSV is complimentary, parts to be incorporated, or dropped. Does CSV's greater DDoS resistance matter a lot? Or not? 2)On 6/28/04 5:56 PM, Hallam-Baker, Phillip sent forth electrons to convey: >>>Caller-Id required a single packet in each direction for the vas[t] >>>majority of mail interactions. >>> >>> Do you see why I feld that this statement was incorrect, at least? >> Please read the earlier post to this thread at >>http://www.imc.org/ietf-mxcomp/mail-archive/msg02198.html >> >> >> >> <>I don't see you addressing the concerns Doug raised. >> >>... Does it work in the face of >>malicious macro SPF records? >> >> > >Only if we decide to support the macro interface. I was hoping that >we would reject it on the grounds that all the use cases that have >been stated can be implemented anyway. > > Well, we have a decision to make by 7/2, and currently, macros are in the spec and likely to stay, so our decision should be based on that. >If what you are trying to say is that there must be some limit to the >complexity of a query I think that is correct, clearly it is a bad >thing if records branch out indefinitely. > I'm confident that, without such limits, SPF is likely to be turned off due to attacks on users. I'm saying that we need to explore further whether with limits high enough to allow necessary functionality, it can survive such attacks. I asked before if you were arguing that all mail servers should rely on local caching DNS servers that will cache all the word's active LMAP records. Are you? I'm not trying to deep 6 SPF. I'm trying to make it stronger and better by attacking its weaknesses virtually, while they are readily fixable. Note, I recently expressed my support Unified SPF (which incorporates a CSV-like check). BTW, I was surprised that the -01 SenderID drafts that came out didn't have any Unified SPF stuff in 'em. I interpreted something Meng said to mean that I should expect to see it in a draft soon, so I'm still expecting that. From owner-ietf-mxcomp@mail.imc.org Tue Jun 29 01:19:28 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07643 for ; Tue, 29 Jun 2004 01:19:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5T56gwG050354; Mon, 28 Jun 2004 22:06:42 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5T56gjG050352; Mon, 28 Jun 2004 22:06:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [64.139.47.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5T56f6b050339 for ; Mon, 28 Jun 2004 22:06:41 -0700 (PDT) (envelope-from gconnor@nekodojo.org) Received: by neko-base.nekodojo.org (Postfix, from userid 500) id D7CB91D656; Mon, 28 Jun 2004 22:06:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by neko-base.nekodojo.org (Postfix) with ESMTP id D536C1D651; Mon, 28 Jun 2004 22:06:48 -0700 (PDT) Date: Mon, 28 Jun 2004 22:06:48 -0700 (PDT) From: Greg Connor To: Matthew Elvey Cc: "'IETF MARID WG'" Subject: Re: Will SPF/Unified SPF/SenderID bring down the 'net? In-Reply-To: <40E0E8B9.2090500@elvey.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 28 Jun 2004, Matthew Elvey wrote: > > > >BLs have a single point of failure that is similar to the problem > >of running core DNS, you take down one part of the network and in > >time the rest of the net grinds to a halt. > > > >You have failled to show that there is a dependency that looks anything > >like the dependency that a mail server has on a BL or on core DNS. > > > What part of "it makes them very resource intensive, so folks stop using > 'em" don't you understand? I am going to agree with Phillip on this one. SPF queries don't go to a central location, they go to the spammer's DNS server (or that of whoever the spammer is trying to impersonate. It sounds like the worst they could do would be to make the receiving mail server really busy, stop their own mail from getting through, or pick on one or two other domains that have weak nameservers. I don't see a type of attack that erodes DNS in general for everybody. Furthermore, the spammer is exposing his own IP during the attack so he should be blocked quickly. > Here's the three paragraphs, with some editing by me. > I'm sorry if you don't understand them, but they are clear. > It has nothing to to with XML (which is dead, WRT MARID), at least now. > > Any mechanism introduced that stems the flow of UCE will be subjected to > intensive attack. ... As the allowable answer from DNS is small, any chained > records further increases vulnerabilities by increasing both resources > and time required to process a message. > > An attacker "jamming" the checking mechanism might set up DNS servers > for domains they control that respond erratically and offer complex > record sets with small TTLs. The attacker then sends messages from > their domains in an attempt to exhaust resources as a means to have > recipients disable the checking processes within the channel. (If on > average a small enterprise uses two outside services, then normally > there will be a need to chain these records as it would be prohibitively > difficult to administer otherwise. These outside vendors may in turn > also outsource for yet more chaining.) > > For example, a mail server is receiving 50 messages per second that > average 4 K bytes in size. If using the SPF mechanism, checking DNS > data is indeterminate as there is no limit for the number of sequential > queries required to converge upon an answer. RFC1035 indicates 5 to 10 > seconds should be considered a worst case resolver interval. If there > becomes an average of 10 queries with an average of 5 seconds a query, > then this limits each process to about 1 message about every minute. > These 10 queries will also add to the traffic at 350 bytes per record a > total of 4K bytes of additional traffic for a doubling of the network > load. The mail server may normally handle 1,500 simultaneous processes, > but at 60 seconds per process, the mail server is reduced to only > running 25 messages a second. This may still represent the same amount > of network traffic, just half as much mail gets through the network. > > You cannot redefine the size of the emails the attacker sends to make the attack less effective. This seems reasonably clear, but it doesn't identify a damaging attack. Is the attacker trying to get his message through, or just trying to make trouble for the receiver? We get a lot of spam (attempts anyway) from domains that don't resolve due to timeouts. That means the spammer is already causing resolvers to time out and mail servers to keep connections open for as long as it takes to time out. So, if the main element of the theoretical attack is "lots of mail sent at once and it makes the resolver do lots of queries that time out" -- I think we already have the problem today and are dealing with it. (In several cases I have had to install DNS servers directly on the mail server box to keep it from bogging down our normal nameserver.) In other words, there are already a number of DNS queries being done per message, and many of those time out. 5 more or even 20 more DNS queries are probably not as harmful as, say, increasing the incoming smtp connections, or consuming SMTP sockets with spoofed SYN packets or something. Now, I think it's actually interesting to compare this type of attack scenario with normal spam. Normal spam may be from a domain that doesn't resolve properly, but if the result is a timeout (for spf or for just resolving the MAIL FROM and its MX) then you don't get to go on to the next step. If the DNS responds well enough to keep the connection alive, then the spam is accepted (which consumes more bandwith than the DNS lookups) and sent to SpamAssassin (which consumes CPU, the steps before haven't relied on CPU much). In other words, it is likely that taking a normal spam run and adding recursive SPF queries that respond erratically and don't cache well, might shift more load onto the resolver, but the more effective it is at weighing down the resolver, the more likely the spam will get a 454 answer and not go on to DATA. In that case I get my bandwidth back and I get my CPU back, so the impact is actually less than a normal spam run, approximately. Anyway, if the point of all this is "We should ensure that LMAP queries aren't allowed to be chained more than X deep" or "We should test to make sure that complicated SPF queries don't adversely affect the mail server or its dns server" I would agree with that. I wouldn't describe this as a new attack vector however... anything that starts with "Assume a large number of incoming SMTP connections..." ought to be familiar territory to any mail server operator :) Later gregc -- Greg Connor gconnor@nekodojo.org Everyone says that having power is a great responsibility. This is a lot of bunk. Responsibility is when someone can blame you if something goes wrong. When you have power you are surrounded by people whose job it is to take the blame for your mistakes. If they're smart, that is. -- Cerebus, "On Governing" From owner-ietf-mxcomp@mail.imc.org Tue Jun 29 02:29:01 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24832 for ; Tue, 29 Jun 2004 02:29:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5T6HCbQ082062; Mon, 28 Jun 2004 23:17:12 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5T6HCuC082061; Mon, 28 Jun 2004 23:17:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5T6HB45082034 for ; Mon, 28 Jun 2004 23:17:11 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: +Q9eUQ2MUpvvHA8y+5H2tQ 1088489836 Received: from [192.168.123.4] (unknown [209.133.65.190]) by mail.messagingengine.com (Postfix) with ESMTP id 803F9C0DCE4; Tue, 29 Jun 2004 02:17:15 -0400 (EDT) Message-ID: <40E10966.1040005@elvey.com> Date: Mon, 28 Jun 2004 23:17:10 -0700 From: Matthew Elvey User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Greg Connor Cc: "'IETF MARID WG'" Subject: Re: Will SPF/Unified SPF/SenderID bring down the 'net? References: In-Reply-To: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Doug just responded rather eloquently to this thread, I'll try my best. On 6/28/04 10:06 PM, Greg Connor sent forth electrons to convey: >On Mon, 28 Jun 2004, Matthew Elvey wrote: > > >>>BLs have a single point of failure that is similar to the problem >>>of running core DNS, you take down one part of the network and in >>>time the rest of the net grinds to a halt. >>> >>>You have failled to show that there is a dependency that looks anything >>>like the dependency that a mail server has on a BL or on core DNS. >>> >>> >>> >>What part of "it makes them very resource intensive, so folks stop using >>'em" don't you understand? >> >> > > >I am going to agree with Phillip on this one. SPF queries don't go to a >central location, they go to the spammer's DNS server (or that of whoever the >spammer is trying to impersonate. It sounds like the worst they could do >would be to make the receiving mail server really busy, stop their own mail >from getting through, or pick on one or two other domains that have weak >nameservers. I don't see a type of attack that erodes DNS in general for >everybody. > Again, the attacker's immediate goal is just to get folks to stop using SPF! > Furthermore, the spammer is exposing his own IP during the attack >so he should be blocked quickly. > > Huh? He's got a zombie army, and AGAIN, how do you identify the attack as an attack? > > >>Here's the three paragraphs, with some editing by me. >>I'm sorry if you don't understand them, but they are clear. >>It has nothing to to with XML (which is dead, WRT MARID), at least now. >> >>Any mechanism introduced that stems the flow of UCE will be subjected to >>intensive attack. ... As the allowable answer from DNS is small, any chained >>records further increases vulnerabilities by increasing both resources >>and time required to process a message. >> >>An attacker "jamming" the checking mechanism might set up DNS servers >>for domains they control that respond erratically and offer complex >>record sets with small TTLs. The attacker then sends messages from >>their domains in an attempt to exhaust resources as a means to have >>recipients disable the checking processes within the channel. (If on >>average a small enterprise uses two outside services, then normally >>there will be a need to chain these records as it would be prohibitively >>difficult to administer otherwise. These outside vendors may in turn >>also outsource for yet more chaining.) >> >>For example, a mail server is receiving 50 messages per second that >>average 4 K bytes in size. If using the SPF mechanism, checking DNS >>data is indeterminate as there is no limit for the number of sequential >>queries required to converge upon an answer. RFC1035 indicates 5 to 10 >>seconds should be considered a worst case resolver interval. If there >>becomes an average of 10 queries with an average of 5 seconds a query, >>then this limits each process to about 1 message about every minute. >>These 10 queries will also add to the traffic at 350 bytes per record a >>total of 4K bytes of additional traffic for a doubling of the network >>load. The mail server may normally handle 1,500 simultaneous processes, >>but at 60 seconds per process, the mail server is reduced to only >>running 25 messages a second. This may still represent the same amount >>of network traffic, just half as much mail gets through the network. >> >>You cannot redefine the size of the emails the attacker sends to make the attack less effective. >> >> > > >This seems reasonably clear, but it doesn't identify a damaging attack. Is >the attacker trying to get his message through, or just trying to make trouble >for the receiver? > > The latter!!! Quoting myself: >What part of "it makes [SPF] very resource intensive, so folks stop using >[SPF]" don't you understand? >We get a lot of spam (attempts anyway) from domains that don't resolve due to >timeouts. > Sure, but I bet it's a small fraction. > That means the spammer is already causing resolvers to time out and >mail servers to keep connections open for as long as it takes to time out. > > That's generally one query to a possibly non-responding nameserver per message, not < 20 or < infinity, . >So, if the main element of the theoretical attack is "lots of mail sent at >once and it makes the resolver do lots of queries that time out" -- I think we >already have the problem today and are dealing with it. (In several cases I >have had to install DNS servers directly on the mail server box to keep it >from bogging down our normal nameserver.) > > You can deal with it being 100 x worse? >In other words, there are already a number of DNS queries being done per >message, and many of those time out. 5 more or even 20 more DNS queries are >probably not as harmful as, say, increasing the incoming smtp connections, or >consuming SMTP sockets with spoofed SYN packets or something. > > Possibly. But these wouldn't achieve the attacker's goal. And only a small fraction of these DNS queries time out. >Now, I think it's actually interesting to compare this type of attack scenario >with normal spam. Normal spam may be from a domain that doesn't resolve >properly, but if the result is a timeout (for spf or for just resolving the >MAIL FROM and its MX) then you don't get to go on to the next step. If the >DNS responds well enough to keep the connection alive, then the spam is >accepted (which consumes more bandwith than the DNS lookups) and sent to >SpamAssassin (which consumes CPU, the steps before haven't relied on CPU >much). > >In other words, it is likely that taking a normal spam run and adding >recursive SPF queries that respond erratically and don't cache well, might >shift more load onto the resolver, but the more effective it is at weighing >down the resolver, the more likely the spam will get a 454 answer and not go >on to DATA. In that case I get my bandwidth back and I get my CPU back, so >the impact is actually less than a normal spam run, approximately. > > Well, you get your CPU back, but Doug is arguing that the bandwidth is spent on the SPF queries - ~4k/message. But this is a valid point you make; there is the potential for some win. >Anyway, if the point of all this is "We should ensure that LMAP queries aren't >allowed to be chained more than X deep" or "We should test to make sure that >complicated SPF queries don't adversely affect the mail server or its dns >server" I would agree with that. I wouldn't describe this as a new attack >vector however... anything that starts with "Assume a large number of incoming >SMTP connections..." ought to be familiar territory to any mail server >operator :) > > No. The second half of the sentence could be something they're completely unfamiliar with. In this case, it may well be. > > > From owner-ietf-mxcomp@mail.imc.org Tue Jun 29 06:00:50 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07742 for ; Tue, 29 Jun 2004 06:00:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5T9o8il059403; Tue, 29 Jun 2004 02:50:08 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5T9o858059402; Tue, 29 Jun 2004 02:50:08 -0700 (PDT) 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.9) with ESMTP id i5T9o7mQ059392 for ; Tue, 29 Jun 2004 02:50:07 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.10/) with ESMTP id i5T9rxHF029950; Tue, 29 Jun 2004 02:53:59 -0700 Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 29 Jun 2004 02:50:07 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Matthew Elvey'" Cc: "'Douglas Otis'" , "'IETF MARID WG'" Subject: Re: Will SPF/Unified SPF/SenderID bring down the 'net? Date: Tue, 29 Jun 2004 02:50:05 -0700 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: Since you simply keep repeating the same original statement and make no attempt to clarify it I have to beleive that you do not intend to make your point clearly. I think I made it plain enough that there is no need to distinguish attacks as malicious, any machine that issues a ridiculous record will be ignored, code should be written to tolerate malformed spf records. If a mail server gets 50 messages a second from the same ip address and they are malicious it should block the ip address. A zombie machine rents at about a dollar a month on the black market. It is not reasonable to hypothecate attacks which cost $10 a second (assume bot is detected after 5 attempts). I for one would be very happy if the spammers would act in ways that tell us with certainty the location of their bots. If there is a problem with the spf macro language chuck it out. If there is no problem, but no use case either, chuck it out. -----Original Message----- From: Matthew Elvey [mailto:matthew@elvey.com] Sent: Mon Jun 28 20:57:54 2004 To: Hallam-Baker, Phillip Cc: Douglas Otis; 'IETF MARID WG' Subject: Re: Will SPF/Unified SPF/SenderID bring down the 'net? On 6/28/04 7:53 PM, Hallam-Baker, Phillip sent forth electrons to convey: > > > > >>>If malicious.com or compromised.com have a malicious record in >>>their DNS it should become apparent quite quickly. >>> >>> >>> >>> >>I don't see how. Say 9/10s of a domain's record resolves. >>How is this >>domain identifiable as malicious? >>Maybe it's just under attack. >> >> > >If it is under attack then it probably should be ignored until >it recovers. All the mail 'from' that source is most likely spam >anyway. > > > Again, how is this domain identifiable as malicious? Many of your points are predicated on having this ability. > > >>>Also remember that the sender has to be holding an open TCP >>>session during this process with a known source IP port. This >>>is not exactly an anonymous attack. >>> >>> >>> >>Again, how is a malicious actor identified automatically? >> >> > >By logging the IP address of the source of the attack. > > Sorry, but what attack? You have to identify the attack as an attack first; see above. > > > >>>The argument makes no sense unless you can state which part of the >>>DNS is going to be attacked and how such an attack would make it >>>easier to send spam. >>> >>> >>> >>Same way taking down BLs works. It makes 'em problematic (e.g >>unreliable and/or very resource intensive), so folks stop using 'em. >> >> > >BLs have a single point of failure that is similar to the problem >of running core DNS, you take down one part of the network and in >time the rest of the net grinds to a halt. > >You have failled to show that there is a dependency that looks anything >like the dependency that a mail server has on a BL or on core DNS. > > What part of "it makes them very resource intensive, so folks stop using 'em" don't you understand? Here's the three paragraphs, with some editing by me. I'm sorry if you don't understand them, but they are clear. It has nothing to to with XML (which is dead, WRT MARID), at least now. Any mechanism introduced that stems the flow of UCE will be subjected to intensive attack. ... As the allowable answer from DNS is small, any chained records further increases vulnerabilities by increasing both resources and time required to process a message. An attacker "jamming" the checking mechanism might set up DNS servers for domains they control that respond erratically and offer complex record sets with small TTLs. The attacker then sends messages from their domains in an attempt to exhaust resources as a means to have recipients disable the checking processes within the channel. (If on average a small enterprise uses two outside services, then normally there will be a need to chain these records as it would be prohibitively difficult to administer otherwise. These outside vendors may in turn also outsource for yet more chaining.) For example, a mail server is receiving 50 messages per second that average 4 K bytes in size. If using the SPF mechanism, checking DNS data is indeterminate as there is no limit for the number of sequential queries required to converge upon an answer. RFC1035 indicates 5 to 10 seconds should be considered a worst case resolver interval. If there becomes an average of 10 queries with an average of 5 seconds a query, then this limits each process to about 1 message about every minute. These 10 queries will also add to the traffic at 350 bytes per record a total of 4K bytes of additional traffic for a doubling of the network load. The mail server may normally handle 1,500 simultaneous processes, but at 60 seconds per process, the mail server is reduced to only running 25 messages a second. This may still represent the same amount of network traffic, just half as much mail gets through the network. You cannot redefine the size of the emails the attacker sends to make the attack less effective. From owner-ietf-mxcomp@mail.imc.org Tue Jun 29 06:48:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10466 for ; Tue, 29 Jun 2004 06:48:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TAdRbo069489; Tue, 29 Jun 2004 03:39:27 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5TAdRoo069488; Tue, 29 Jun 2004 03:39:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (listserv.winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5TAdQqT069480 for ; Tue, 29 Jun 2004 03:39:26 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Tue, 29 Jun 2004 06:43:01 -0400 Received: from ([65.10.109.27]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 2316428735; Tue, 29 Jun 2004 06:43:00 -0400 Message-ID: <001501c45dc5$52987480$6401a8c0@hdev1> From: "Hector Santos" To: "Meng Weng Wong" , References: <20040628211922.GR13225@dumbo.pobox.com> Subject: Re: Problem scenarios for SPF vs CSV Date: Tue, 29 Jun 2004 06:39:10 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.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: Content-Transfer-Encoding: 7bit I am just finish reading the JABBER session. Here are some comments I wish to add: o CVS Reviewing CSV more over the last few days, it will present a more or larger implementation issue. I need to ask more questions about, but it has overlapping issues with some SPF logic and more importantly the dependency on other concepts such as accreditation is somewhat, what's the word without offending anyone, well not something I think ready to impose on my customers, atleast not yet. o HELO vs MAIL FROM lookups. One jabber comment was made with a indirect reference to me: "spf has a clause for checking HELO when mail from = <> - some have suggested to just turn that on all the time (i.e. Hector)" Correction: The issue was this: DMP was the first LMAP concept added to my system. DMP offered a dual lookup logic, MAIL FROM and HELO. DMP was protecting very nicely Local Domains Spoofs - the LMAP #1 benefit. In addition, I added configuration options to avoid remote domain look ups because the majority were NONE or NXDOMAIN results creating a new large DNS overhead issue. When SPF was added and DMP was deprecated, Local SPF domain lookup options were offered as well but the default was to check all incoming domains since the SPF database was rapidly growing. Plus we wanted to get some real stats. It wasn't too long when we started to see Local Domain Spoofs into our mail system once protected by DMP. Recognizing the redundancy issue, I suggested to Meng that a new SPF provision be made to allow for HELO checking in NON-NULL situations and also added that it probably only necessary in order to protect local domains. In order words, if the HELO was local, then you can check for it. Otherwise, follow the normal specs. I considered it a "Loophole" that needed to be closed in a young new specification. A major debate started. Fearing that the tide was against the suggestion, I added a variant SPF logic to my package to solve the problem by performing a Local Domain Check rule first. After more field testing and an important high focus to reduce DNS lookups and overall overhead, I moved the Local Domain Checking to SMTP itself. So a Local Domain/IP association without DNS lookups is done now because our SMTP server is 100% aware of the local domains it needs to be aware of anyway as part of the Final vs. Route determination. I removed the variant logic and it is now back to the original SPF lookup logic of only doing a HELO check when MAIL FROM = NULL. Eventually (all a few pulled teeth), Meng added a provision I thought would help SPF. I don't recall reading it in any new spec revisions but did see the message. For me, its a toss up: Check all or minimize it to local domains check only o Mix Policies On a related note, besides the DNS overhead issues, I think it is also important to recognize the following assertion: A MARID result based on HELO lookup should not conflict with a MARID result based on a MAIL FROM lookup. Yet, the additional assertion can be made: A MARID result based on HELO lookup can alter or change a MARID result based on a MAIL FROM lookup. So whether I use CVS or SPF at HELO, I would be more interested in seeing how this can resolve, maybe the forwarding or MUA problem. I have some analysis in his area I hope to finish in the next few days or sooner. -- Hector ----- Original Message ----- From: "Meng Weng Wong" To: Sent: Monday, June 28, 2004 5:19 PM Subject: Problem scenarios for SPF vs CSV > > During the Jabber chat, which is viewable at > > http://www.xmpp.org/ietf-logs/marid@ietf.xmpp.org/2004-06-28.html > > We agreed to explore the scenarios in which using an SPF > query against the HELO domain leads to problems due to > overloading. > > Problem scenarios should start out with: > > HELO xxx > MAIL FROM: > > They should go on to describe how CSV views the situation, > how SPF-against-HELO views the situation, and how the SPF > story is problematic in a way the CSV story is not. > > We should leave aside for now questions of whether the SPF > lookup is significantly "heavier-weight" than the CSV > lookup. > > thanks > meng > > From owner-ietf-mxcomp@mail.imc.org Tue Jun 29 06:51:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10644 for ; Tue, 29 Jun 2004 06:51:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TAgwgw069785; Tue, 29 Jun 2004 03:42:58 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5TAgw99069784; Tue, 29 Jun 2004 03:42:58 -0700 (PDT) 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.9) with ESMTP id i5TAgvBE069776 for ; Tue, 29 Jun 2004 03:42:57 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC04.vcorp.ad.vrsn.com ([65.205.251.33]) by pigeon.verisign.com (8.12.10/) with ESMTP id i5TAknHI013941; Tue, 29 Jun 2004 03:46:49 -0700 Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 29 Jun 2004 03:42:19 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Matthew Elvey'" , "'Greg Connor'" Cc: "'IETF MARID WG'" Subject: Re: Will SPF/Unified SPF/SenderID bring down the 'net? Date: Tue, 29 Jun 2004 03:42:10 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I agree with greg. Any spammer trying the proposed mechanism is going to end up causing the target sysop to come in and see that spf just rejected several hundred thousand spams. I can't see how that would stop the sysop using spf, quite the opposite. I do not have time to analyse arguments in hermeneutic form, nor should this be necessary given that the original speaker is here. Doug might think he has made himself clear, but every time I read a post from him or mathew I see yet another interpretation of the text. I think it is very obvious that any attempt by the spammers to intimidate in the manner suggested is going to fail, it fails for the same reason terrorism fails. The attacker does not have the resources to attack more than a small number of targets at any given time. If your macro language offend yee then pluck it out. There is a separate thread on the factored records issue. I see no reason to specify anything more than a set of ip addresses with the administrative flexibiloity that margaret has argued for. It is possible that an argument could be made for expansion by the username component of the email address. That is a worthwhile discussion. The reason I do not want to go down the csv path is that I have yet to see a clear and concise explanation of the proposal. All I see is fud about other proposals. If there is a there there it will be possible to state in a short post the changes necesary to express csv semantics in spf syntax. -----Original Message----- From: Matthew Elvey [mailto:matthew@elvey.com] Sent: Mon Jun 28 23:37:19 2004 To: Greg Connor Cc: 'IETF MARID WG' Subject: Re: Will SPF/Unified SPF/SenderID bring down the 'net? Doug just responded rather eloquently to this thread, I'll try my best. On 6/28/04 10:06 PM, Greg Connor sent forth electrons to convey: >On Mon, 28 Jun 2004, Matthew Elvey wrote: > > >>>BLs have a single point of failure that is similar to the problem >>>of running core DNS, you take down one part of the network and in >>>time the rest of the net grinds to a halt. >>> >>>You have failled to show that there is a dependency that looks anything >>>like the dependency that a mail server has on a BL or on core DNS. >>> >>> >>> >>What part of "it makes them very resource intensive, so folks stop using >>'em" don't you understand? >> >> > > >I am going to agree with Phillip on this one. SPF queries don't go to a >central location, they go to the spammer's DNS server (or that of whoever the >spammer is trying to impersonate. It sounds like the worst they could do >would be to make the receiving mail server really busy, stop their own mail >from getting through, or pick on one or two other domains that have weak >nameservers. I don't see a type of attack that erodes DNS in general for >everybody. > Again, the attacker's immediate goal is just to get folks to stop using SPF! > Furthermore, the spammer is exposing his own IP during the attack >so he should be blocked quickly. > > Huh? He's got a zombie army, and AGAIN, how do you identify the attack as an attack? > > >>Here's the three paragraphs, with some editing by me. >>I'm sorry if you don't understand them, but they are clear. >>It has nothing to to with XML (which is dead, WRT MARID), at least now. >> >>Any mechanism introduced that stems the flow of UCE will be subjected to >>intensive attack. ... As the allowable answer from DNS is small, any chained >>records further increases vulnerabilities by increasing both resources >>and time required to process a message. >> >>An attacker "jamming" the checking mechanism might set up DNS servers >>for domains they control that respond erratically and offer complex >>record sets with small TTLs. The attacker then sends messages from >>their domains in an attempt to exhaust resources as a means to have >>recipients disable the checking processes within the channel. (If on >>average a small enterprise uses two outside services, then normally >>there will be a need to chain these records as it would be prohibitively >>difficult to administer otherwise. These outside vendors may in turn >>also outsource for yet more chaining.) >> >>For example, a mail server is receiving 50 messages per second that >>average 4 K bytes in size. If using the SPF mechanism, checking DNS >>data is indeterminate as there is no limit for the number of sequential >>queries required to converge upon an answer. RFC1035 indicates 5 to 10 >>seconds should be considered a worst case resolver interval. If there >>becomes an average of 10 queries with an average of 5 seconds a query, >>then this limits each process to about 1 message about every minute. >>These 10 queries will also add to the traffic at 350 bytes per record a >>total of 4K bytes of additional traffic for a doubling of the network >>load. The mail server may normally handle 1,500 simultaneous processes, >>but at 60 seconds per process, the mail server is reduced to only >>running 25 messages a second. This may still represent the same amount >>of network traffic, just half as much mail gets through the network. >> >>You cannot redefine the size of the emails the attacker sends to make the attack less effective. >> >> > > >This seems reasonably clear, but it doesn't identify a damaging attack. Is >the attacker trying to get his message through, or just trying to make trouble >for the receiver? > > The latter!!! Quoting myself: >What part of "it makes [SPF] very resource intensive, so folks stop using >[SPF]" don't you understand? >We get a lot of spam (attempts anyway) from domains that don't resolve due to >timeouts. > Sure, but I bet it's a small fraction. > That means the spammer is already causing resolvers to time out and >mail servers to keep connections open for as long as it takes to time out. > > That's generally one query to a possibly non-responding nameserver per message, not < 20 or < infinity, . >So, if the main element of the theoretical attack is "lots of mail sent at >once and it makes the resolver do lots of queries that time out" -- I think we >already have the problem today and are dealing with it. (In several cases I >have had to install DNS servers directly on the mail server box to keep it >from bogging down our normal nameserver.) > > You can deal with it being 100 x worse? >In other words, there are already a number of DNS queries being done per >message, and many of those time out. 5 more or even 20 more DNS queries are >probably not as harmful as, say, increasing the incoming smtp connections, or >consuming SMTP sockets with spoofed SYN packets or something. > > Possibly. But these wouldn't achieve the attacker's goal. And only a small fraction of these DNS queries time out. >Now, I think it's actually interesting to compare this type of attack scenario >with normal spam. Normal spam may be from a domain that doesn't resolve >properly, but if the result is a timeout (for spf or for just resolving the >MAIL FROM and its MX) then you don't get to go on to the next step. If the >DNS responds well enough to keep the connection alive, then the spam is >accepted (which consumes more bandwith than the DNS lookups) and sent to >SpamAssassin (which consumes CPU, the steps before haven't relied on CPU >much). > >In other words, it is likely that taking a normal spam run and adding >recursive SPF queries that respond erratically and don't cache well, might >shift more load onto the resolver, but the more effective it is at weighing >down the resolver, the more likely the spam will get a 454 answer and not go >on to DATA. In that case I get my bandwidth back and I get my CPU back, so >the impact is actually less than a normal spam run, approximately. > > Well, you get your CPU back, but Doug is arguing that the bandwidth is spent on the SPF queries - ~4k/message. But this is a valid point you make; there is the potential for some win. >Anyway, if the point of all this is "We should ensure that LMAP queries aren't >allowed to be chained more than X deep" or "We should test to make sure that >complicated SPF queries don't adversely affect the mail server or its dns >server" I would agree with that. I wouldn't describe this as a new attack >vector however... anything that starts with "Assume a large number of incoming >SMTP connections..." ought to be familiar territory to any mail server >operator :) > > No. The second half of the sentence could be something they're completely unfamiliar with. In this case, it may well be. > > > From owner-ietf-mxcomp@mail.imc.org Tue Jun 29 07:01:58 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11088 for ; Tue, 29 Jun 2004 07:01:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TArndq071137; Tue, 29 Jun 2004 03:53:49 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5TArnJ8071136; Tue, 29 Jun 2004 03:53:49 -0700 (PDT) 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.9) with ESMTP id i5TArnug071130 for ; Tue, 29 Jun 2004 03:53:49 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (verisign.com [65.205.251.55] (may be forged)) by peacock.verisign.com (8.12.10/) with ESMTP id i5TArkCN012271; Tue, 29 Jun 2004 03:53:46 -0700 Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 29 Jun 2004 03:53:46 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Douglas Otis'" Cc: "'Matthew Elvey'" , "'IETF MARID WG'" Subject: RE: Will SPF/Unified SPF/SenderID bring down the 'net? Date: Tue, 29 Jun 2004 03:53:39 -0700 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: 80,000 spambots? Possible yes. Easy no way. At 50 attacks a second this attack has revealled the ip addresses of the entire cluster in half an hour. It would be much easier to simply ddos the recipients public dns and make them unreachable. That would require far fewer bots and would not require the bots to use tcp and thus reveal their location. I doubt that many dns servers outside core dns can survive a ddos atack from a hundred or so broadband bots. Even under these assumptons the attacker can only ddos 800 sites at once with this cluster. More machines will be offline for non attack reasons. -----Original Message----- From: Douglas Otis [mailto:dotis@mail-abuse.org] Sent: Mon Jun 28 21:22:21 2004 To: Hallam-Baker, Phillip Cc: 'Matthew Elvey'; 'IETF MARID WG' Subject: RE: Will SPF/Unified SPF/SenderID bring down the 'net? On Mon, 2004-06-28 at 19:53, Hallam-Baker, Phillip wrote: > > >I fail to see the connection between an argument that a 20% > > > > > That's not what I'm talking about. Consider the whole post, > > particularly paragraphs 1-3. Arrgh. > > The URL is above. > > How about you or Doug try to post a clear attack scenario > that shows exactly how such an attack would be performed? I thought it was clear. > I have great difficulty parsing the paragraphs, let alone making > sense of statements such as > > "If used in the normal fashion, no parser is required to utilize DNS > answers, so the introduction of a parser increases vulnerabilities. " I could have said it takes no "additional" parser to utilize A records or SRV records or many other binary responses offered by DNS. > It is a matter of indisputable fact that all interpretation of > DNS records requires the use of some form of parser. So the > above appears to be nonsense. But the task to parse a SPF requires an additional parser added where either the increase in resources needed or errors created handling malformed input exits where there would have been none if such a parser was not added. > "The > less rigid and more extensible the syntax, the greater the > vulnerabilities. " > > It is also a matter of indisputable fact that XML can be parsed > using a finite state machine of less than 20 states acompanied by > a simple stack. I have written such a parser several times. The larger these records are allowed to grow or the greater their numbers, the greater their risk. I thought the XML issue was resolved. I have yet to see any evidence of this however and this question seems odd in that respect. > "An attacker "jamming" the checking mechanism might set up DNS servers > for domains they control that respond erratically and offer complex > record sets with small TTLs." > > So a DDoS attack on your own ability to send email. this can > be addressed by a security consideration. If you have to resolve > more than X records then consider the data spurious and reject > the mail. Exactly. The goal would be to slow reception and thereby allow greater distribution to a larger array of servers. What is this limit? What is the average number of references to other domains? > "As example, a mail server is receiving 50 messages per second that > average 4 K bytes in size." > > Assume that three contain powerpoint presentations of 1Mb, four > contain word documents of 500Kb and five pictures of little Timmy. > that would be a more realistic load, but it would prevent the > dire conclusion This was not assuming a bandwidth limitation. I only attempted to illustrate that at half the number of messages, the traffic was not changed. > "These 10 queries will also add to the traffic at 350 bytes per record a > total of 4K bytes of additional traffic for a doubling of the network > load." > > assuming the attack is present on every email. And the mail server > does not get clever and stop accepting emails from malicious IP addresses. This could easily be happening from 80,000 addresses. This is a small number out of millions possible. I would not expect too much effort made from normal tactics however. > Estimates of the number of compromised hosts on the Internet vary, but > the highest number in a botnet tends to be in the tens of thousands. > If the attacker is using a different bot for each connection that > is 3000 bots per minute, 180,000 per hour. Such an estimate is low, but using your 10,000 with just 56 k baud links and .4k per message, that would be 175,000 messages per second. If able to reduce mail performance to 25 messages per second, the attack could hinder 7000 mail servers. Bad news for someone I would suspect. > This is an attack I really really would like to see, we could map > out the zombies on the Internet pretty quick. How? You may have captured a series of dynamic IP addresses and others that simply were transferring real mail. Of these messages, none were rejected as they contain nothing to indicate them to be spam. None of the domains in the return path were from closed lists. You will have made little progress in knowing anything for certain. > [Why not just DDoS the email server direct and have done with it????] The attack is to convince providers SPF is not worth it. > > >If malicious.com or compromised.com have a malicious record in > > >their DNS it should become apparent quite quickly. > > > > > > > > I don't see how. Say 9/10s of a domain's record resolves. > > How is this domain identifiable as malicious? > > Maybe it's just under attack. > > If it is under attack then it probably should be ignored until > it recovers. All the mail 'from' that source is most likely spam > anyway. If there is a slow response to a DNS query, then this identifies the source as a spammer? What type of behavior are you recommending? > > >Also remember that the sender has to be holding an open TCP > > >session during this process with a known source IP port. This > > >is not exactly an anonymous attack. > > > > > Again, how is a malicious actor identified automatically? > > By logging the IP address of the source of the attack. How do you identify the attacker? What is different? > > >The argument makes no sense unless you can state which part of the > > >DNS is going to be attacked and how such an attack would make it > > >easier to send spam. > > > > > Same way taking down BLs works. It makes 'em problematic (e.g > > unreliable and/or very resource intensive), so folks stop using 'em. > > BLs have a single point of failure that is similar to the problem > of running core DNS, you take down one part of the network and in > time the rest of the net grinds to a halt. > > You have failled to show that there is a dependency that looks anything > like the dependency that a mail server has on a BL or on core DNS. I would say there is no analogy with a BL and an MTA checking SPF records. A BL can be scaled to handle DoS attacks as there would be an interest to ensure such. Those running mail will now find themselves under attack as a result of a flood of DNS queries resulting from spoofed mail to MTAs employing the SPF mechanism. > > > Seems to me that any such attack has the problem that the attack > > > and likely motive become immediately obvious to sender.com. All > > > we need to do is to work out a way to close the loop. > > > > And how do we do that? > > Reporting mechanism to allow sender.com to tell receiver.com that it > is observing large numbers of packets that appear to be emitted > from that domain. A reporting mechanism to increase the MTA load during a possible attack that can not identify the source of the attack, but knows it is being attacked because it is taking too long to query DNS? What is the source of a well disguised distributed attack anyway? -Doug From owner-ietf-mxcomp@mail.imc.org Tue Jun 29 10:41:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23819 for ; Tue, 29 Jun 2004 10:41:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TERrn1091038; Tue, 29 Jun 2004 07:27:53 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5TERrGX091037; Tue, 29 Jun 2004 07:27:53 -0700 (PDT) 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.9) with ESMTP id i5TERqNu091008 for ; Tue, 29 Jun 2004 07:27:53 -0700 (PDT) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id CCC00E076E; Tue, 29 Jun 2004 10:27:50 -0400 (EDT) Date: Tue, 29 Jun 2004 10:27:50 -0400 From: John Leslie To: ietf-mxcomp@imc.org Subject: Action items from June 28 jabber Message-ID: <20040629142750.GU3747@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: Andy closed the jabber session with several action items: ] ] andy: We were given 3 use cases today. It would be good if meng could ] take his 2 to the list, and jfenton his to the list. ] andy: Then let's let the CSV proponents explain two things for each, ] 1) how CSV handles them, and ] 2) how SPF does not. I'm waiting on these. ] andy: Also, I'd like to see a list of current MTA behaviors that would ] have to be modified for CSV. ] andy: if any This email will try for a reasonably complete answer on this. The short answer, of course, is the empty list. CSV does not seek to change how email is done. It does not seek to say anything must be done differently. (This is why we see it as orthogonal to SPF.) Operators of MTAs are free to change nothing; and things will work about as well as they do now -- until spammers escalate things so that overly-broad IP blacklists are applied widely and the MTA's IP address finds its way onto them. Possibly, they'll even be miraculously lucky and its IP address _won't_ find its way onto any blacklist. ;^) If/when they get caught by that kind of problem, they need to ensure that the EHLO string the MTA uses is a legal domain name (which it should be already; but I did say _no_ changes were necessary), and that they can cause a simple SRV record to be placed under that domain. Alas, if they waited that long, there won't be time to acquire a good reputation, so if they want an instant fix they'll have to find an accreditation service which already has a good reputation; convince that service to vouch for them; and cause a PTR record to be placed at the EHLO domain. We advise MTA operators not to wait for problems to show up, but to place the SRV record quickly, to show that they acknowledge responsibility for the actions of that MTA, and place PTR records for a few average-or-better accreditation services as well. The syntax of the SRV record is remarkably simple: you have the "target" name, which will be the same as the EHLO string, plus two bits of information, which for the vast majority of cases should be set to authorized=yes and list-empty=no. There is no reason you _need_ to place any PTR records at all -- unless you've left things to the last minute and need to arrange for "instant reputation". Reputation services will naturally assign (over time) good reputations to domains which send enough "ham" and no "spam". And let us not forget the rather significant number of individuals who already find themselves paralyzed by IP blacklists: they can place the SRV and PTR records, demonstrating full accountability and good reputation; and make a convincing case that any receiving SMTP server that now blacklists them (perhaps because they're using a cable provider) can simply implement CSV and stop having to respond to complaints. ;^) -- John Leslie From owner-ietf-mxcomp@mail.imc.org Tue Jun 29 11:00:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25138 for ; Tue, 29 Jun 2004 11:00:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TEnOD6093519; Tue, 29 Jun 2004 07:49:24 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5TEnOvJ093518; Tue, 29 Jun 2004 07:49:24 -0700 (PDT) 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.9) with ESMTP id i5TEnN2Q093509 for ; Tue, 29 Jun 2004 07:49:23 -0700 (PDT) (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 9E51C132D00; Tue, 29 Jun 2004 10:49:23 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 551C9605; Tue, 29 Jun 2004 10:49:23 -0400 (EDT) Date: Tue, 29 Jun 2004 10:49:23 -0400 From: Meng Weng Wong To: ietf-mxcomp@imc.org Cc: John Leslie Subject: SPF vs CSV scenarios Message-ID: <20040629144923.GS13225@dumbo.pobox.com> References: <20040629142750.GU3747@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040629142750.GU3747@verdi> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Jun 29, 2004 at 10:27:50AM -0400, John Leslie wrote: | | Andy closed the jabber session with several action items: | ] | ] andy: We were given 3 use cases today. It would be good if meng could | ] take his 2 to the list, and jfenton his to the list. | ] andy: Then let's let the CSV proponents explain two things for each, | ] 1) how CSV handles them, and | ] 2) how SPF does not. | | I'm waiting on these. I was actually waiting for you to provide them. They were your cases. If you look at the following transcript, you'll see that I had to guess because you weren't telling. [15:41:24] (if jlc gets a spare moment, i'd like to ask for some detail on the use case where there's an actual problem between using an SPF record for the PRD and using an SPF record for EHLO, please) [15:42:11] meng, cts [15:42:40] uh, so, jlc or doug, can you set up a problem scenario? [15:42:44] [15:43:23] just thought maybe you guys had one in mind. [15:43:30] Quick answer on case with problem: workers at home using their cable system to send email for their work domain. [15:43:55] Meng, can you work with that? [15:44:14] lemme see what the EHLO and the MAIL FROM look like real quick. [15:44:38] (taking the MAIL FROM to be close enough to the PRA that SPF Classic and SenderID look the same in this case) [15:45:15] EHLO cable-12-23-34-56.cty.cableco.net? [15:45:20] [15:45:51] john? [15:45:54] Actually, it might be that, or the cable provider might force use of their server. [15:45:58] [15:46:07] ok, so we have two subcases ... [15:46:22] if the cable provider forces use of their server, we have EHLO mta4.cableco.net [15:46:28] MAIL FROM: [15:46:29] ? [15:46:33] [15:46:42] OK [15:46:58] so mta4.cableco.net has an SPF record, and work.com has an SPF record ... and ... ? [15:47:17] and the mta4.cableco.net SPF record is checked at EHLO time, and the work.com record is checked at MAIL FROM time ... [15:48:01] [15:48:10] What happens when mta4.cableco.net gets a bad reputation? [15:48:13] [15:48:28] then work.com has to set up port 587 with SMTP AUTH [15:49:01] if the mta4.cableco.net identity has a bad reputation, then it sucks for the mail sender whether the checks are being done with CSV or SPF, right? [15:50:21] these are two good use cases. perhaps flushing them out on the list is good. From owner-ietf-mxcomp@mail.imc.org Tue Jun 29 11:30:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26656 for ; Tue, 29 Jun 2004 11:30:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TFBXWi095846; Tue, 29 Jun 2004 08:11:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5TFBX02095845; Tue, 29 Jun 2004 08:11:33 -0700 (PDT) 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.9) with ESMTP id i5TFBW3f095838 for ; Tue, 29 Jun 2004 08:11:32 -0700 (PDT) (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 C1AC1132D01; Tue, 29 Jun 2004 11:11:29 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 5FF9663A; Tue, 29 Jun 2004 11:11:29 -0400 (EDT) Date: Tue, 29 Jun 2004 11:11:29 -0400 From: Meng Weng Wong To: John Leslie Cc: ietf-mxcomp@imc.org Subject: Unified SPF overlaps with CSV Message-ID: <20040629151129.GT13225@dumbo.pobox.com> References: <20040629142750.GU3747@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040629142750.GU3747@verdi> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Jun 29, 2004 at 10:27:50AM -0400, John Leslie wrote: | | The short answer, of course, is the empty list. CSV does not seek to | change how email is done. It does not seek to say anything must be done | differently. (This is why we see it as orthogonal to SPF.) To provide clarity, can you explain if by the above "SPF" you mean "Unified SPF" or "SPF Classic"? "Unified SPF" always examines the HELO domain, offers an authentication status, and gives receivers an opportunity to perform whitelisting or rejection operations based on that result. It does this independent of examination of the return-path or the PRA. "SPF Classic" by comparison only performs spoof detection on the HELO name, and always checks the return-path. Unified SPF even solves the forwarding problem by allowing a receiver site to whitelist forwarders by HELO name, overriding the return-path result. It appears to me that the set of features offered by Unified SPF overlaps with the features offered by CSV. Please correct me if I'm wrong; my understanding of CSV is obviously not as good as yours :) | Operators of MTAs are free to change nothing; and things will work | about as well as they do now -- until spammers escalate things so that | overly-broad IP blacklists are applied widely and the MTA's IP address | finds its way onto them. Possibly, they'll even be miraculously lucky | and its IP address _won't_ find its way onto any blacklist. ;^) The above is also true of Unified SPF. | If/when they get caught by that kind of problem, they need to ensure | that the EHLO string the MTA uses is a legal domain name (which it | should be already; but I did say _no_ changes were necessary), and that | they can cause a simple SRV record to be placed under that domain. The above is also true of Unified SPF, except that the record is the SPF TXT or MARID record. | We advise MTA operators not to wait for problems to show up, but | to place the SRV record quickly, to show that they acknowledge | responsibility for the actions of that MTA, and place PTR records | for a few average-or-better accreditation services as well. The above is also true of Unified SPF. | The syntax of the SRV record is remarkably simple: you have the | "target" name, which will be the same as the EHLO string, plus two | bits of information, which for the vast majority of cases should be | set to authorized=yes and list-empty=no. The syntax of the SPF record for the MTA is TXT "v=spf1 a -all". | And let us not forget the rather significant number of individuals | who already find themselves paralyzed by IP blacklists: they can | place the SRV and PTR records, demonstrating full accountability and | good reputation; and make a convincing case that any receiving SMTP | server that now blacklists them (perhaps because they're using a | cable provider) can simply implement CSV and stop having to respond | to complaints. ;^) Yes, it would be a great benefit to the wrongly-blacklisted folks if they could positively accept responsibility at the HELO or return-path levels and thereby override provider-based negativity. This argument is made at http://spf.pobox.com/slides/unified%20spf/0429.html if we replace "MTAMark=no" with "listed on DUL blacklist". cheers menmg From owner-ietf-mxcomp@mail.imc.org Tue Jun 29 12:05:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28717 for ; Tue, 29 Jun 2004 12:05:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TFuEhP099300; Tue, 29 Jun 2004 08:56:14 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5TFuESv099299; Tue, 29 Jun 2004 08:56:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from rose.csi.cam.ac.uk (rose.csi.cam.ac.uk [131.111.8.13]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TFuDNn099292 for ; Tue, 29 Jun 2004 08:56:13 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]) by rose.csi.cam.ac.uk with esmtp (Exim 4.20) id 1BfKxO-0007zI-5b for ietf-mxcomp@imc.org; Tue, 29 Jun 2004 16:55:38 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1BfKxL-0006Gw-JX; Tue, 29 Jun 2004 16:55:35 +0100 Date: Tue, 29 Jun 2004 16:55:35 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: John Leslie cc: ietf-mxcomp@imc.org Subject: Re: Action items from June 28 jabber In-Reply-To: <20040629142750.GU3747@verdi> Message-ID: References: <20040629142750.GU3747@verdi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 29 Jun 2004, John Leslie wrote: > > The syntax of the SRV record is remarkably simple: you have the > "target" name, which will be the same as the EHLO string, plus two > bits of information, which for the vast majority of cases should be > set to authorized=yes and list-empty=no. It might be the case that the EHLO domain is a CNAME, in which case the SRV target should be same as the CNAME target not the EHLO domain itself. Tony. -- f.a.n.finch http://dotat.at/ RATTRAY HEAD TO BERWICK ON TWEED: SOUTHWEST OR WEST 3 OR 4, BACKING SOUTH 4 OR 5. FAIR, THEN RAIN OR SHOWERS. MODERATE OR GOOD. SLIGHT. From owner-ietf-mxcomp@mail.imc.org Tue Jun 29 12:35:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00582 for ; Tue, 29 Jun 2004 12:35:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TGHrTj001682; Tue, 29 Jun 2004 09:17:53 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5TGHrD0001681; Tue, 29 Jun 2004 09:17:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TGHqIk001674 for ; Tue, 29 Jun 2004 09:17:52 -0700 (PDT) (envelope-from hkatz@microsoft.com) Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 29 Jun 2004 09:18:05 -0700 Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 29 Jun 2004 09:17:56 -0700 Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 29 Jun 2004 09:17:55 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-fido-msg.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 29 Jun 2004 09:15:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: draft-ietf-marid-submitter-01.txt Date: Tue, 29 Jun 2004 09:17:52 -0700 Message-ID: Thread-Topic: draft-ietf-marid-submitter-01.txt thread-index: AcRdkGLhP6Tg0jXVTk6LtiLA0uJaqAAY9tsQ From: "Harry Katz" To: "Matthew Elvey" Cc: "MXCOMP" X-OriginalArrivalTime: 29 Jun 2004 16:15:33.0548 (UTC) FILETIME=[4E039EC0:01C45DF4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5TGHqIk001675 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Monday, June 28, 2004 9:20 PM, Matthew Elvey [mailto:matthew@elvey.com] wrote: > On 6/28/04 5:48 PM, Harry Katz sent forth electrons to convey: > > >>Got the s/firm/entity/ fix? > >> > >> > >Yes. > > > > > Good. You're welcome. > > Here's another issue: > > >4. The SUBMITTER Parameter of the MAIL Command > > > > If the SMTP server supports the SUBMITTER extension, then > the SMTP > > client MAY include the SUBMITTER parameter in MAIL > commands issued > > during the SMTP session. > > > Change to MUST when != From? The 2nd paragraph in 4.1 makes your point, so I'm going to delete the above sentence to remove redundancy & contradiction. Thanks. From owner-ietf-mxcomp@mail.imc.org Tue Jun 29 13:04:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02790 for ; Tue, 29 Jun 2004 13:04:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TGq0JE005447; Tue, 29 Jun 2004 09:52:00 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5TGq0wr005446; Tue, 29 Jun 2004 09:52:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.mail-abuse.org [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TGq0aW005439 for ; Tue, 29 Jun 2004 09:52:00 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.mail-abuse.org (DDev.mail-abuse.org [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id 4C73841496; Tue, 29 Jun 2004 09:51:58 -0700 (PDT) Subject: Re: Unified SPF overlaps with CSV From: Douglas Otis To: Meng Weng Wong Cc: John Leslie , MARID In-Reply-To: <20040629151129.GT13225@dumbo.pobox.com> References: <20040629142750.GU3747@verdi> <20040629151129.GT13225@dumbo.pobox.com> Content-Type: text/plain Message-Id: <1088527917.4998.117.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 29 Jun 2004 09:51:57 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 2004-06-29 at 08:11, Meng Weng Wong wrote: > On Tue, Jun 29, 2004 at 10:27:50AM -0400, John Leslie wrote: > | > | The short answer, of course, is the empty list. CSV does not seek to > | change how email is done. It does not seek to say anything must be done > | differently. (This is why we see it as orthogonal to SPF.) > > To provide clarity, can you explain if by the above "SPF" > you mean "Unified SPF" or "SPF Classic"? > > "Unified SPF" always examines the HELO domain, offers an > authentication status, and gives receivers an opportunity to > perform whitelisting or rejection operations based on that > result. It does this independent of examination of the > return-path or the PRA. Details? Where is the draft? > "SPF Classic" by comparison only performs spoof detection on > the HELO name, and always checks the return-path. > > Unified SPF even solves the forwarding problem by allowing a > receiver site to whitelist forwarders by HELO name, > overriding the return-path result. This could be a bad idea. How is the HELO name authenticated and authorized? > It appears to me that the set of features offered by Unified > SPF overlaps with the features offered by CSV. Please > correct me if I'm wrong; my understanding of CSV is > obviously not as good as yours :) Is there an Internet Draft on the Unified SPF. It is hard to do a meaningful review with so many details missing. Also there is yet to be a Internet Draft that documents the current "Core" documents. There is also a very telling item missing. What do you expect to be the average number of indirections per SPF record? What is the maximal depth of recursion? How is path permissions differentiated from administrative ownership? > | Operators of MTAs are free to change nothing; and things will work > | about as well as they do now -- until spammers escalate things so that > | overly-broad IP blacklists are applied widely and the MTA's IP address > | finds its way onto them. Possibly, they'll even be miraculously lucky > | and its IP address _won't_ find its way onto any blacklist. ;^) > > The above is also true of Unified SPF. The major problems result from weak transversal authorization determined by SPF. You may consider these the same, but the details entailing such is important. ACCREDITATION can not be administered if the Authentication and Authorization are not confirmed for unknown, in addition to that determined to be accepted. It is apparent that SPF only provides weak path assurance regarding an accepted message. The assurances for either unknown or rejected messages are nil. That is a huge category left open. > | If/when they get caught by that kind of problem, they need to ensure > | that the EHLO string the MTA uses is a legal domain name (which it > | should be already; but I did say _no_ changes were necessary), and that > | they can cause a simple SRV record to be placed under that domain. > > The above is also true of Unified SPF, except that the > record is the SPF TXT or MARID record. Where is the draft? I do not think these are equivalent and making such claims remains allegation without substance. > | We advise MTA operators not to wait for problems to show up, but > | to place the SRV record quickly, to show that they acknowledge > | responsibility for the actions of that MTA, and place PTR records > | for a few average-or-better accreditation services as well. > > The above is also true of Unified SPF. Again, this overlooks details involved to establish administrative ownership, authentication and authorization. > | The syntax of the SRV record is remarkably simple: you have the > | "target" name, which will be the same as the EHLO string, plus two > | bits of information, which for the vast majority of cases should be > | set to authorized=yes and list-empty=no. > > The syntax of the SPF record for the MTA is TXT "v=spf1 a -all". What does this say exactly? Go look for an address? I would not call this as being the same. In addition, these statements are not about which domain administers the mail server, this makes a statement about what domains may transverse this mail server. > | And let us not forget the rather significant number of individuals > | who already find themselves paralyzed by IP blacklists: they can > | place the SRV and PTR records, demonstrating full accountability and > | good reputation; and make a convincing case that any receiving SMTP > | server that now blacklists them (perhaps because they're using a > | cable provider) can simply implement CSV and stop having to respond > | to complaints. ;^) > > Yes, it would be a great benefit to the wrongly-blacklisted > folks if they could positively accept responsibility at the > HELO or return-path levels and thereby override > provider-based negativity. It is also equally important to assess accountability properly. Do not force individuals to accept accountability for every machine they must list to allow their mail to transverse these other machines. > This argument is made at > > http://spf.pobox.com/slides/unified%20spf/0429.html A slide show provides no details and therefore provides no additional information. -Doug From owner-ietf-mxcomp@mail.imc.org Tue Jun 29 13:24:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03866 for ; Tue, 29 Jun 2004 13:24:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TH8E7p006872; Tue, 29 Jun 2004 10:08:14 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5TH8EcX006871; Tue, 29 Jun 2004 10:08:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.mail-abuse.org [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TH8EdY006862 for ; Tue, 29 Jun 2004 10:08:14 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.mail-abuse.org (DDev.mail-abuse.org [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id 4EF4C41496; Tue, 29 Jun 2004 10:08:12 -0700 (PDT) Subject: RE: Will SPF/Unified SPF/SenderID bring down the 'net? From: Douglas Otis To: "Hallam-Baker, Phillip" Cc: "'Matthew Elvey'" , "'IETF MARID WG'" In-Reply-To: References: Content-Type: text/plain Message-Id: <1088528891.4998.134.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 29 Jun 2004 10:08:11 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 2004-06-29 at 03:53, Hallam-Baker, Phillip wrote: > 80,000 spambots? Possible yes. Easy no way. > > At 50 attacks a second this attack has revealled the ip addresses of the > entire cluster in half an hour. How? You make this assertion but provide no methods as to how these machines are to be identified. The attack would not exist without also legitimate machines also making requests. How do you go about separating the wheat from the chaff? > It would be much easier to simply ddos the recipients public dns and make > them unreachable. That would require far fewer bots and would not require > the bots to use tcp and thus reveal their location. I doubt that many dns > servers outside core dns can survive a ddos atack from a hundred or so > broadband bots. That is not the purpose of the attack however. > Even under these assumptons the attacker can only ddos 800 sites at once > with this cluster. > > More machines will be offline for non attack reasons. Is this your way of saying it does not matter? > > So a DDoS attack on your own ability to send email. this can > > be addressed by a security consideration. If you have to resolve > > more than X records then consider the data spurious and reject > > the mail. Let me ask this again regarding the number of record indirections. Do you see a problem if there are on average 1.1 record indirections? How about 1.6, 2.1? With these average indirections, what is the recursion limits to resolve a permitted transversal path? What algorithm defines loop detection, tree pruning, etc? What is the result if the tree is pruned? > Exactly. The goal would be to slow reception and thereby allow greater > distribution to a larger array of servers. What is this limit? What is > the average number of references to other domains? -Doug From owner-ietf-mxcomp@mail.imc.org Tue Jun 29 13:37:30 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04352 for ; Tue, 29 Jun 2004 13:37:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5THRVOe008093; Tue, 29 Jun 2004 10:27:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5THRVVA008092; Tue, 29 Jun 2004 10:27:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5THRUZk008086 for ; Tue, 29 Jun 2004 10:27:31 -0700 (PDT) (envelope-from roy+dated+1091122050.1372a0@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i5THRVYX057397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 29 Jun 2004 17:27:31 GMT (envelope-from roy+dated+1091122050.1372a0@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5THRUaD033427 for ; Tue, 29 Jun 2004 18:27:30 +0100 (BST) (envelope-from roy+dated+1091122050.1372a0@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5THRUZZ033426 for ietf-mxcomp@imc.org; Tue, 29 Jun 2004 18:27:30 +0100 (BST) (envelope-from roy+dated+1091122050.1372a0@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Tue, 29 Jun 2004 18:27:29 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16609.42624.836197.558170@giles.gnomon.org.uk> Date: Tue, 29 Jun 2004 18:27:28 +0100 To: Tony Finch Cc: John Leslie , ietf-mxcomp@imc.org Subject: Re: Action items from June 28 jabber In-Reply-To: References: <20040629142750.GU3747@verdi> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Tony" == Tony Finch writes: Tony> It might be the case that the EHLO domain is a CNAME Though, strictly, this is illegal according to RFC821/2821. -roy From owner-ietf-mxcomp@mail.imc.org Tue Jun 29 14:55:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08494 for ; Tue, 29 Jun 2004 14:55:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TIdiDx014277; Tue, 29 Jun 2004 11:39:44 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5TIdiX6014276; Tue, 29 Jun 2004 11:39:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [64.139.47.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TIdiAf014270 for ; Tue, 29 Jun 2004 11:39:44 -0700 (PDT) (envelope-from gconnor@nekodojo.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by neko-base.nekodojo.org (Postfix) with ESMTP id BDD4D1D651; Tue, 29 Jun 2004 11:39:45 -0700 (PDT) Date: Tue, 29 Jun 2004 11:39:47 -0700 From: Greg Connor To: Douglas Otis Cc: MARID Subject: Re: Unified SPF overlaps with CSV Message-ID: <11967678.1088509187@Ryoga.corp.sgi.com> In-Reply-To: <1088527917.4998.117.camel@ddev.mail-abuse.org> References: <1088527917.4998.117.camel@ddev.mail-abuse.org> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --Douglas Otis wrote: >> | Operators of MTAs are free to change nothing; and things will work >> | about as well as they do now -- until spammers escalate things so that >> | overly-broad IP blacklists are applied widely and the MTA's IP address >> | finds its way onto them. Possibly, they'll even be miraculously lucky >> | and its IP address _won't_ find its way onto any blacklist. ;^) >> >> The above is also true of Unified SPF. > > The major problems result from weak transversal authorization determined > by SPF. You may consider these the same, but the details entailing such > is important. ACCREDITATION can not be administered if the > Authentication and Authorization are not confirmed for unknown, in > addition to that determined to be accepted. It is apparent that SPF > only provides weak path assurance regarding an accepted message. The > assurances for either unknown or rejected messages are nil. That is a > huge category left open. Doug- I couldn't understand this paragraph, and I think it's important to understand what you're saying here -- some of the keywords suggest that you feel it's an important point. Here are some followup questions. Q. What is a "transversal authorization?" What makes one weak vs. strong? Q. Regarding this sentence, I couldn't quite unwind what you meant, though I am probably close to understanding: > ACCREDITATION can not be administered if the > Authentication and Authorization are not confirmed for unknown, in > addition to that determined to be accepted. I understand this to mean "If the result is "unknown" then accreditation cannot be applied. I would take that as a given, but I believe that is the same with both SPF and CSV. Is this meant to imply that the existence of an "unknown" state itself is a defect? If I understand correctly, CSV also has an "unknown" state. In both proposals, I believe the domain owner has to make sure a PASS or "known good" result is received before honoring any accreditation, right? Anyway, let me know if you meant something else here that I am not understanding. Q. Regarding these two sentences, please clarify: > It is apparent that SPF > only provides weak path assurance regarding an accepted message. The > assurances for either unknown or rejected messages are nil. That is a > huge category left open. Is this meant to state that a CSV "authorized" result is stronger than an SPF PASS result? Why do you say that? Both are comparing an IP address to a DNS record, and in that regard seem to provide very similar features from the technical side. Do you mean that there is a difference in how the records will be interpreted by users? Is it because of the way the drafts are written? I'm trying to understand if it is a difference in the design, or just in how it is used by implementors and explained to users... Also what do you mean by "The assurances for either unknown or rejected messages are nil". What assurance does CSV provide if the status is unknown? If the status is reject/fail, doesn't that mean reject the message, and isn't the "strength" of that assertion the same for both SPF and CSV? Thanks gregc -- Greg Connor From owner-ietf-mxcomp@mail.imc.org Tue Jun 29 14:56:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08560 for ; Tue, 29 Jun 2004 14:56:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TIZldq013362; Tue, 29 Jun 2004 11:35:47 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5TIZlqZ013361; Tue, 29 Jun 2004 11:35:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gold.csi.cam.ac.uk (gold.csi.cam.ac.uk [131.111.8.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TIZjv3013355 for ; Tue, 29 Jun 2004 11:35:46 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]) by gold.csi.cam.ac.uk with esmtp (Exim 4.20) id 1BfNSI-00017K-W4 for ietf-mxcomp@imc.org; Tue, 29 Jun 2004 19:35:42 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1BfNSI-0003y8-U8 for ietf-mxcomp@imc.org; Tue, 29 Jun 2004 19:35:42 +0100 Date: Tue, 29 Jun 2004 19:35:42 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: ietf-mxcomp@imc.org Subject: draft-ietf-marid-core-01 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: There still some serious problems with the PRA algorithm. Checking identities in non-standard headers makes invisible spoofing easier, and substantially negates the benefits of checking header identities instead of envelope identities. Section 7.3 says that "MUAs will need to start displaying at least the header that was verified" but in early deployments the MUA won't know anything about Sender-ID verification. Section 9.2 uses ambiguous language. Forwarding means several different things. If it is being used to mean aliasing (per the language in draft-crocker-email-arch-00) then the recommendation to add a Resent-From header is contrary to the sematics in RFC 2822 section 3.6.6 (see the paragraph starting Note:). This must be made more explicit. The similar recommendation in section 9.3 is only marginally less dubious. The PRA algorithm in section 4 makes a probably-incorrect assumption about the relative priority of Resent-* and Envelope-To. What if a message is re-sent in an RFC 2822 manner to an address which is aliased and which causes an Envelope-To: header to be added at that time? The PRA algorithm will get it wrong. The systems I run will have to be modified to work with any version of the PRA algorithm, since none of them add any of the necessary headers when dealing with aliased addresses. One of the claimed benefits of Sender-ID was that it makes SRS unnecessary, and one of the reasons people dislike SPF/SRS is that it requires systems with aliased addresses to be modified. Not such a good benefit from this perspective! There's also a very tricky problem dealing with messages for multiple recipients, since they may end up going to multiple aliases which target the same destination domain. At the moment we can send a single copy of the message on to its next hop with multiple envelope recipients. This isn't possible with Sender-ID -- adding an Envelope-To: header listing the multiple recipients is a privacy problem (it breaks BCC: and cheapo alias-based mailing lists), and mis-using Resent-From: requires us to de-optimise onward delivery to one recipient per message and I'm not sure we can do so without de-optimising everything. Tony. -- f.a.n.finch http://dotat.at/ BERWICK ON TWEED TO WHITBY: SOUTH 3 OR 4 VEERING SOUTHWEST 4 OR 5 LOCALLY 6. CLOUDY, PERIODS RAIN THEN RISK SHOWERS. GOOD FALLING MODERATE AT TIMES. SLIGHT INCREASING MODERATE. From owner-ietf-mxcomp@mail.imc.org Tue Jun 29 15:45:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12252 for ; Tue, 29 Jun 2004 15:45:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TJXoIa018212; Tue, 29 Jun 2004 12:33:50 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5TJXocs018211; Tue, 29 Jun 2004 12:33:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from turing-police.cirt.vt.edu (IDENT:root@turing-police.cirt.vt.edu [128.173.54.129]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TJXnjh018204 for ; Tue, 29 Jun 2004 12:33:49 -0700 (PDT) (envelope-from Valdis.Kletnieks@vt.edu) Received: from turing-police.cc.vt.edu (IDENT:valdis@turing-police.cc.vt.edu [127.0.0.1]) by turing-police.cc.vt.edu (8.13.0/8.13.0) with ESMTP id i5TJXnog012675; Tue, 29 Jun 2004 15:33:49 -0400 Message-Id: <200406291933.i5TJXnog012675@turing-police.cc.vt.edu> X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4+dev To: Greg Connor Cc: "'IETF MARID WG'" Subject: Re: Will SPF/Unified SPF/SenderID bring down the 'net? In-Reply-To: Your message of "Mon, 28 Jun 2004 22:06:48 PDT." From: Valdis.Kletnieks@vt.edu References: Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1928819899P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Tue, 29 Jun 2004 15:33:49 -0400 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --==_Exmh_1928819899P Content-Type: text/plain; charset=us-ascii On Mon, 28 Jun 2004 22:06:48 PDT, Greg Connor said: > everybody. Furthermore, the spammer is exposing his own IP during the attack > so he should be blocked quickly. OK... I admit I tuned in late... but somehow, it's rather surreal to see "We have their IP so they should be blocked quickly" as a justification. In what way will they be "blocked quickly"? And how will this be an improvement over the blazing speed we currently see on shutting down spam-spewing zombies that we know the IP address of? --==_Exmh_1928819899P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQFA4cQdcC3lWbTT17ARArb1AJwJbc0Yu1EkjcijqIvSbHUUSZwcLgCg2QlA xLt58O6Y/3VhKdDfeNl01lE= =Sn+7 -----END PGP SIGNATURE----- --==_Exmh_1928819899P-- From owner-ietf-mxcomp@mail.imc.org Tue Jun 29 16:00:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13734 for ; Tue, 29 Jun 2004 16:00:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TJpBUW020440; Tue, 29 Jun 2004 12:51:11 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5TJpB7N020439; Tue, 29 Jun 2004 12:51:11 -0700 (PDT) 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.9) with ESMTP id i5TJoWU5020338 for ; Tue, 29 Jun 2004 12:51:11 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.10/) with ESMTP id i5TJsRHF009394; Tue, 29 Jun 2004 12:54:27 -0700 Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 29 Jun 2004 12:50:35 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Douglas Otis'" Cc: "'Matthew Elvey'" , "'IETF MARID WG'" Subject: RE: Will SPF/Unified SPF/SenderID bring down the 'net? Date: Tue, 29 Jun 2004 12:50:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I am not going to play hunt the attack here. Each time I answer one set of questions you redefine your position. Then you claim that your changed position is unchanged and that it is my fault for misinterpreting the original palimcest. If you have 80k bots youcan cause real pain for pretty much any internet site you choose. But the proposed attack is not the way to do it. Clearly branching is not good if it is unbounded. It is not the branch ratio that is the issue though it is the maximal permitted stack depth. -----Original Message----- From: Douglas Otis [mailto:dotis@mail-abuse.org] Sent: Tue Jun 29 10:08:16 2004 To: Hallam-Baker, Phillip Cc: 'Matthew Elvey'; 'IETF MARID WG' Subject: RE: Will SPF/Unified SPF/SenderID bring down the 'net? On Tue, 2004-06-29 at 03:53, Hallam-Baker, Phillip wrote: > 80,000 spambots? Possible yes. Easy no way. > > At 50 attacks a second this attack has revealled the ip addresses of the > entire cluster in half an hour. How? You make this assertion but provide no methods as to how these machines are to be identified. The attack would not exist without also legitimate machines also making requests. How do you go about separating the wheat from the chaff? > It would be much easier to simply ddos the recipients public dns and make > them unreachable. That would require far fewer bots and would not require > the bots to use tcp and thus reveal their location. I doubt that many dns > servers outside core dns can survive a ddos atack from a hundred or so > broadband bots. That is not the purpose of the attack however. > Even under these assumptons the attacker can only ddos 800 sites at once > with this cluster. > > More machines will be offline for non attack reasons. Is this your way of saying it does not matter? > > So a DDoS attack on your own ability to send email. this can > > be addressed by a security consideration. If you have to resolve > > more than X records then consider the data spurious and reject > > the mail. Let me ask this again regarding the number of record indirections. Do you see a problem if there are on average 1.1 record indirections? How about 1.6, 2.1? With these average indirections, what is the recursion limits to resolve a permitted transversal path? What algorithm defines loop detection, tree pruning, etc? What is the result if the tree is pruned? > Exactly. The goal would be to slow reception and thereby allow greater > distribution to a larger array of servers. What is this limit? What is > the average number of references to other domains? -Doug From owner-ietf-mxcomp@mail.imc.org Tue Jun 29 16:38:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17349 for ; Tue, 29 Jun 2004 16:38:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TKL0HG022490; Tue, 29 Jun 2004 13:21:00 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5TKL0Xr022489; Tue, 29 Jun 2004 13:21:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TKKxNu022479 for ; Tue, 29 Jun 2004 13:20:59 -0700 (PDT) (envelope-from roy+dated+1091132462.598271@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i5TKL3YX055967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 29 Jun 2004 20:21:03 GMT (envelope-from roy+dated+1091132462.598271@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5TKL2FO034502 for ; Tue, 29 Jun 2004 21:21:02 +0100 (BST) (envelope-from roy+dated+1091132462.598271@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5TKL2QD034501 for ietf-mxcomp@imc.org; Tue, 29 Jun 2004 21:21:02 +0100 (BST) (envelope-from roy+dated+1091132462.598271@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Tue, 29 Jun 2004 21:21:00 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16609.53036.490480.666054@giles.gnomon.org.uk> Date: Tue, 29 Jun 2004 21:21:00 +0100 To: "Hector Santos" Cc: "Meng Weng Wong" , Subject: Re: Problem scenarios for SPF vs CSV In-Reply-To: <001501c45dc5$52987480$6401a8c0@hdev1> References: <20040628211922.GR13225@dumbo.pobox.com> <001501c45dc5$52987480$6401a8c0@hdev1> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Hector" == Hector Santos writes: Hector> It wasn't too long when we started to see Local Domain Hector> Spoofs into our mail system once protected by DMP. SPF works very well for protecting me from local domain spoofs, but I think this is a red herring (as I _think_ you have concluded yourself). It is (IMHO) already perfectly acceptable for local policy to dictate additional checks to validate mail that purports to be from local domains. You don't need any externally imposed specification in order to allow you to do that. Sure, MARID may well end up being useful as a mechanism for diseminating local policy to your local MTAs, but I don't see that as its objective... -roy From owner-ietf-mxcomp@mail.imc.org Tue Jun 29 16:44:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18201 for ; Tue, 29 Jun 2004 16:44:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TKUWoM023088; Tue, 29 Jun 2004 13:30:32 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5TKUWQ7023087; Tue, 29 Jun 2004 13:30:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TKUVX2023080 for ; Tue, 29 Jun 2004 13:30:31 -0700 (PDT) (envelope-from roy+dated+1091133033.eeed96@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i5TKUXYX062554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 29 Jun 2004 20:30:34 GMT (envelope-from roy+dated+1091133033.eeed96@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5TKUXKl034611 for ; Tue, 29 Jun 2004 21:30:33 +0100 (BST) (envelope-from roy+dated+1091133033.eeed96@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5TKUX6m034610 for ietf-mxcomp@imc.org; Tue, 29 Jun 2004 21:30:33 +0100 (BST) (envelope-from roy+dated+1091133033.eeed96@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Tue, 29 Jun 2004 21:30:32 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16609.53607.699397.966940@giles.gnomon.org.uk> Date: Tue, 29 Jun 2004 21:30:31 +0100 To: "Hallam-Baker, Phillip" Cc: "'Matthew Elvey'" , "'Greg Connor'" , "'IETF MARID WG'" Subject: Re: Will SPF/Unified SPF/SenderID bring down the 'net? In-Reply-To: References: X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Hallam-Baker," == Hallam-Baker, Phillip writes: Hallam-Baker,> There is a separate thread on the factored records Hallam-Baker,> issue. I see no reason to specify anything more Hallam-Baker,> than a set of ip addresses with the administrative Hallam-Baker,> flexibiloity that margaret has argued for. It is Hallam-Baker,> possible that an argument could be made for Hallam-Baker,> expansion by the username component of the email Hallam-Baker,> address. That is a worthwhile discussion. I've seen it argued earlier in the life of SPF that some sites might not wish to make their complete list of outgoing IP addresses easily accessible, and that the exists mechanism in SPF (I guess this is what is meant by a factored record) is of benefit to such sites. An attacker who'd comprpomised an ISP's routing could use block records to rapidly search for domains that list addresses in netblocks the attacker is able to spoof. Factored records make that search much harder. -roy From owner-ietf-mxcomp@mail.imc.org Tue Jun 29 17:26:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23072 for ; Tue, 29 Jun 2004 17:26:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TL63JB025832; Tue, 29 Jun 2004 14:06:03 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5TL63lZ025831; Tue, 29 Jun 2004 14:06:03 -0700 (PDT) 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.9) with ESMTP id i5TL62FS025825 for ; Tue, 29 Jun 2004 14:06:02 -0700 (PDT) (envelope-from john@jlc.net) Received: by mailhost.jlc.net (Postfix, from userid 104) id 3142CE0872; Tue, 29 Jun 2004 17:06:05 -0400 (EDT) Date: Tue, 29 Jun 2004 17:06:05 -0400 From: John Leslie To: Meng Weng Wong Cc: ietf-mxcomp@imc.org, John Leslie Subject: Re: SPF vs CSV scenarios Message-ID: <20040629210605.GX3747@verdi> References: <20040629142750.GU3747@verdi> <20040629144923.GS13225@dumbo.pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040629144923.GS13225@dumbo.pobox.com> User-Agent: Mutt/1.4.1i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'd like to apologize up-front for the length of this post. Feel free to skim it if you think I'll never get to the point. (I'm likely to have guessed wrong on some details of SPF anyway.) Meng Weng Wong wrote: > On Tue, Jun 29, 2004 at 10:27:50AM -0400, John Leslie wrote: >| >| Andy closed the jabber session with several action items: >|] >|] andy: We were given 3 use cases today. It would be good if meng could >|] take his 2 to the list, and jfenton his to the list. >|] andy: Then let's let the CSV proponents explain two things for each, >|] 1) how CSV handles them, and >|] 2) how SPF does not. >... > [15:43:30] Quick answer on case with problem: > workers at home using their cable system to send email for > their work domain. >... > [15:44:14] lemme see what the EHLO and the MAIL > FROM look like real quick. > [15:44:38] (taking the MAIL FROM to be close > enough to the PRA that SPF Classic and SenderID look the > same in this case) > > [15:45:15] EHLO cable-12-23-34-56.cty.cableco.net? >... > [15:45:54] Actually, it might be that, or the > cable provider might force use of their server. >... > [15:46:07] ok, so we have two subcases ... > [15:46:22] if the cable provider forces use of > their server, we have EHLO mta4.cableco.net > [15:46:28] MAIL FROM: >... This case being simpler, let's start with it. CSV will take the EHLO mta4.cableco.net, and do both a reputation check (out-of-band) and a SRV query on _client._smtp.mta4.cableco.net. Hopefully that will return authorized=1 and list-empty=0, and hopefully the IP address will match one on the list returned. Thus authorization will be established. There's a pretty good chance that reputation will come back OK, because reputation services hate to turn off the main mailservers of cable providers. But, IMHO, the cableco.net reputation is unlikely to be good enough to bypass further checks. For the sake of argument, let's say the receiving SMTP server chooses to do SPF checks against the RFC2821 MAIL FROM. This, alas, will flunk if work.com publishes a SPF record which does not include mta4.cableco.net. In practice, cable providers have multiple outgoing MTAs, and work.com will probably have to use the "include" mechanism for a recursive query or a "redirect" modifier to tail-recurse to cableco.net. (More likely the former, since they are likely to have different home-workers at different providers.) Hopefully, this will all result in a SPF "pass". Now we come to the reputation question. The reputation queried will be work.com. Let's break here, and come back to it after discussing what SPF-without-CSV will do. SPF-without-CSV may or may not evaluate the EHLO. (I hope I'm right there: I haven't seen a SPF draft that says otherwise; please correct me, Meng, if I'm wrong.) If it does, I would expect it to yield a "pass", no different from CSV. SPF-without-CSV will evaluate the MAIL-FROM, and the results will be the same as for the with-CSV case. Hopefully that gets us back to where we broke off: the reputation question. The difference between with-CSV and without-CSV will show up in the reputation-service ratings of work.com. In the with-CSV case, reputation-service rating of the EHLO cases will always accurately correlate with the CSV semantics of assuming responsibility, and _if_ (a big if, as things appear right now, but I'm an optimist!) cableco.net ever acquires a good enough reputation on EHLO, work.com will no longer have to include it by reference in its SPF record, eliminating the risk of work.com's reputation being sullied by a cableco.net lapse. Please understand that the social pressure which inflates the cableco.net rating will _not_ similarly inflate the work.com rating. Reputation services will feel much freer to downgrade work.com, and leave it downgraded longer. I fully agree, BTW, that this difference is subtle, and may not be worth worrying about. But we're discussing a case which shouldn't happen in the first place: the case where cableco.net blocks both port 25 direct sending and port 587 submission. The way things _should_ happen Meng described as: > [15:45:15] EHLO cable-12-23-34-56.cty.cableco.net? and > [15:46:28] MAIL FROM: (I think that exact case unlikely, and will describe it only on request: the EHLO string must be programmed, and IMHO it is unlikely that the worker would program that funky cableco string.) Let me instead describe: EHLO mail4.work.com MAIL FROM: worker@work.com CSV will query the reputation of "mail4.work.com" and query for a SRV record at _client._smtp.mail4.work.com. This will return authorized=1 and list-empty=0, and the IP address will match if the DNS record is updated to match the latest IP-shuffle of the cable provider. (If it hasn't we'll get timely warning when tries to send mail from home.) The reputation will match the actual responsibility for operating this MTA: good if it's operated carefully, and bad if it's not. That's important! There's a real incentive to operate carefully. Let's assume that does operate carefully. In that case the reputation report will be excellent, and the receiving SMTP server will be programmed to skip the SPF check on MAIL FROM. But if there is to be a (later) SPF check, work.com has no need to recursively include domains over which it has no control, and can use tricks like the "exists" mechanism to track potential abuse, or simply leave the record open with ?all if no problems show up. Conversely, SPF-without-CSV MAY check EHLO or may not. Hopefully if it check, it'll pass. But reputation services won't have a clean division of responsibilities, because work.com will be forced to use recursive includes. work.com's reputation is likely to suffer when cableco.net suffers a lapse. And, SPF-without-CSV _will_ check MAIL FROM, with the same issues as above. If _this_ difference seems subtle, I must not have explained it very well, because here we have the difference between accurate reputation matched to clean semantics of CSV, versus reputation sullied by the not-too-great reputation of a much larger entity, with semantics so confused that I don't believe any reputation service will be able to sort out the difference between "accept responsibility for the actions of this MTA" and "this MTA is not under our control, but may send our email anyway". -- John Leslie From owner-ietf-mxcomp@mail.imc.org Tue Jun 29 17:43:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26414 for ; Tue, 29 Jun 2004 17:43:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TLUNdc027309; Tue, 29 Jun 2004 14:30:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5TLUN39027308; Tue, 29 Jun 2004 14:30:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.mail-abuse.org [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TLUNU7027296 for ; Tue, 29 Jun 2004 14:30:23 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.mail-abuse.org (DDev.mail-abuse.org [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id 46A3B4148F; Tue, 29 Jun 2004 14:30:19 -0700 (PDT) Subject: Re: Unified SPF overlaps with CSV From: Douglas Otis To: Greg Connor Cc: MARID In-Reply-To: <11967678.1088509187@Ryoga.corp.sgi.com> References: <1088527917.4998.117.camel@ddev.mail-abuse.org> <11967678.1088509187@Ryoga.corp.sgi.com> Content-Type: text/plain Message-Id: <1088544618.4998.249.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 29 Jun 2004 14:30:18 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 2004-06-29 at 11:39, Greg Connor wrote: > --Douglas Otis wrote: > > >> | Operators of MTAs are free to change nothing; and things will work > >> | about as well as they do now -- until spammers escalate things so that > >> | overly-broad IP blacklists are applied widely and the MTA's IP address > >> | finds its way onto them. Possibly, they'll even be miraculously lucky > >> | and its IP address _won't_ find its way onto any blacklist. ;^) > >> > >> The above is also true of Unified SPF. > > > > The major problems result from weak transversal authorization determined > > by SPF. You may consider these the same, but the details entailing such > > is important. ACCREDITATION can not be administered if the > > Authentication and Authorization are not confirmed for unknown, in > > addition to that determined to be accepted. It is apparent that SPF > > only provides weak path assurance regarding an accepted message. The > > assurances for either unknown or rejected messages are nil. That is a > > huge category left open. > > Doug- I couldn't understand this paragraph, and I think it's important to > understand what you're saying here -- some of the keywords suggest that you > feel it's an important point. I am working on a more complete response but felt there was a demand that something be said immediately... > Here are some followup questions. > Q. What is a "transversal authorization?" What makes one weak vs. strong? There are undefined boundaries where SPF/CID _may_ be checked. Headers are easily forged and should there be a machine internal to an undefined administrative region erroneously accepting mail, this puts every message carried in question. I would call this a weak from of identification. What identity is used to assert accountability? Due to this weak from of identity, SPF/CID _MUST_ never be used to assert accountability. If mail was injected somewhere inside a nebulous region devoid of SPF/CID checks, how is this detected? Are those spoofed to be soiled by a machine somewhere not tied down properly? > Q. Regarding this sentence, I couldn't quite unwind what you meant, though > I am probably close to understanding: > > ACCREDITATION can not be administered if the Authentication and > > Authorization are not confirmed for unknown, in addition to that > > determined to be accepted. > I understand this to mean "If the result is "unknown" then accreditation > cannot be applied. I would take that as a given, but I believe that is the > same with both SPF and CSV. If _everyone_ fully implemented SPF, there would still be the category Unknown. If everyone implemented CSV, this category would no longer exist. In addition, the identity established using CSV provides a means to apply accountability. Those being spoofed would not be impacted, just the administrative domain that failed to secure access to _all_ their machines. > Is this meant to imply that the existence of an "unknown" state itself > is a defect? If I understand correctly, CSV also has an "unknown" > state. In both proposals, I believe the domain owner has to make sure > a PASS or "known good" result is received before honoring any > accreditation, right? Anyway, let me know if you meant something > else here that I am not understanding. Yes, there would be an unknown state, but only for those that failed to implement CSV. In the normal operation of SPF/CID, an unknown state must be allowed as an escape for those unable to publish a comprehensive list of domain and address relationships. SPF/CID is unable to scale for a comprehensive list, so by design there exists the unknown state. I venture to say that SPF/CID may not handle even a conservative amount of publishing of these relationships. The full complexity of these relationships may become more pronounced once SPF/CID checks are widely implemented and more domains attempt to "close" their lists due to spam attacks. Attacks deployed against hapless domains that would otherwise wish to publish more but are unable to comply listing all points of mail access. > Q. Regarding these two sentences, please clarify: > > It is apparent that SPF only provides weak path assurance regarding > > an accepted message. The assurances for either unknown or rejected > > messages are nil. That is a huge category left open. > > Is this meant to state that a CSV "authorized" result is stronger than an > SPF PASS result? The area of policy only applies to the MTA server and not to users of mail. Reputation must only apply to the administration of policy for the MTA. Reputation can not scale to the user nor should a mail stream be considered secure to base assumptions about where a message was derived. Who gets credited, should the published permitted path for a message determined abusive traverse many domains? There is virtually no cost associated in creating a user. There is some cost, albeit small, for creating a domain. > Why do you say that? Limiting the results of a check to answer just the question regarding the channel and NEVER the message, then it is possible to ensure a valid answer. > Both are comparing an IP address to a DNS record, and in that regard > seem to provide very similar features from the technical side. Do you > mean that there is a difference in how the records will be interpreted > by users? These lists are not technically the same. One is a list to correlate domains and addresses to express permitted traversals, the other is a list of servers administered by a domain. These sentences include many of the same words, and may even include some of the same addresses, but these lists are not the same nor are they intended to answer the same question. > Is it because of the way the drafts are written? There is a major difference in paradigms where a slight of hand changing a word here and there will not mollify these differences. Publishing in DNS TXT records all mail domain paths using a technique of linked records is a wholly different goal. I would question the suitability of DNS for this. DNS is well suited to answer the question what is the list of addresses associated with a EHLO domain which provide both Authorization and Authentication with perhaps just an SRV record. > I'm trying to understand if it is a difference in the design, or just > in how it is used by implementors and explained to users... The difference is where the problem is addressed. Identify by the name of the domain attempting to inject mail into the system and stop it there rather than looking at each message. Each message may easily pass muster with SPF/CID, in fact, it should be expect this to be the case. > Also what do you mean by "The assurances for either unknown or rejected > messages are nil". What assurance does CSV provide if the status is > unknown? If the status is reject/fail, doesn't that mean reject the > message, and isn't the "strength" of that assertion the same for both SPF > and CSV? Should CSV be fully implemented, there will be no unknowns as opposed to SPF/CID. If there is any abuse discovered, the accounting of this abuse will be accurately applied to the domain and never is the header of a message trusted. The ability of user to forward mail or use their favorite access point to send mail containing their return address remains unchanged. It does however mean for domains to protect their accreditations, they must be responsive to abate abuse. To abate identity fraud, I strongly suggest considering the use of Fenton's "Identified Mail" proposal. This technique scales and does not threaten the integrity of DNS and Mail in the process. Users will still be allowed the freedom to send mail but commerce can be protected in a very strong way against fraud regardless of the path taken. -Doug From owner-ietf-mxcomp@mail.imc.org Tue Jun 29 18:31:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03240 for ; Tue, 29 Jun 2004 18:31:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TMFwYH029746; Tue, 29 Jun 2004 15:15:58 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5TMFw2R029745; Tue, 29 Jun 2004 15:15:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [64.139.47.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TMFsLR029734 for ; Tue, 29 Jun 2004 15:15:56 -0700 (PDT) (envelope-from gconnor@nekodojo.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by neko-base.nekodojo.org (Postfix) with ESMTP id 56CDB1D651 for ; Tue, 29 Jun 2004 15:15:51 -0700 (PDT) Date: Tue, 29 Jun 2004 15:15:49 -0700 From: Greg Connor To: ietf-mxcomp@imc.org Subject: Reminder: three posts daily limit Message-ID: <24929707.1088522149@Ryoga.corp.sgi.com> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I'm going to use my third post of the day to remind people (again): PLEASE don't post more than three times a day. Many of us have limited time to spend on keeping up with MARID posts, and we would like to participate in the conversation as well. Also, if a thread is going back and forth between the same two or three people, those participants need to make sure they have stated their own points clearly, then step back and let the rest of the group comment on the subject. I will also suggest that if we can try to focus on what we agree on, rather than what we disagree on, we will probably find that our ideas are very close and compatible and the differences are minor. Also, remember that the best way to win support for an idea is usually to state your idea clearly and say why you believe it. If you are focusing on disagreeing with someone else's ideas, you are taking the attention away from your own. I would much rather read a few paragraphs that state a particular position than wade through four layers of who-said-what. If you think your point is important enough, take the time to write a few paragraphs that can stand alone. Thanks gregc -- Greg Connor From owner-ietf-mxcomp@mail.imc.org Tue Jun 29 18:37:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03776 for ; Tue, 29 Jun 2004 18:37:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TMT9DR030358; Tue, 29 Jun 2004 15:29:09 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5TMT99C030357; Tue, 29 Jun 2004 15:29:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TMT8cr030343 for ; Tue, 29 Jun 2004 15:29:09 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: g64PlN61YC1V/hT3uhaNFQ 1088548149 Received: from [192.168.1.141] (ns.nextbus.com [64.164.28.194]) by mail.messagingengine.com (Postfix) with ESMTP id 4B6B4C0DE98; Tue, 29 Jun 2004 18:29:08 -0400 (EDT) Message-ID: <40E1ED34.1020501@elvey.com> Date: Tue, 29 Jun 2004 15:29:08 -0700 From: Matthew Elvey User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Meng Weng Wong Cc: ietf-mxcomp@imc.org, John Leslie Subject: Re: SPF vs CSV scenarios References: <20040629142750.GU3747@verdi> <20040629144923.GS13225@dumbo.pobox.com> In-Reply-To: <20040629144923.GS13225@dumbo.pobox.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/29/2004 7:49 AM, Meng Weng Wong sent forth electrons to convey: >On Tue, Jun 29, 2004 at 10:27:50AM -0400, John Leslie wrote: >| >| Andy closed the jabber session with several action items: >| ] >| ] andy: We were given 3 use cases today. It would be good if meng could >| ] take his 2 to the list, and jfenton his to the list. >| ] andy: Then let's let the CSV proponents explain two things for each, >| ] 1) how CSV handles them, and >| ] 2) how SPF does not. >| >| I'm waiting on these. > >I was actually waiting for you to provide them. They were >your cases. > > Yeah, looks like they were mis-assigned, and no one noticed. Anyway, I'd suggest that the lively thread about DDoS attacks presents a situation that CSV handles well, and SPF doesn't handle as well. How poorly it is handled merits further discussion. From owner-ietf-mxcomp@mail.imc.org Tue Jun 29 19:03:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05914 for ; Tue, 29 Jun 2004 19:03:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TMqu3r032929; Tue, 29 Jun 2004 15:52:56 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5TMquoh032928; Tue, 29 Jun 2004 15:52:56 -0700 (PDT) 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.9) with ESMTP id i5TMqtMc032920 for ; Tue, 29 Jun 2004 15:52:55 -0700 (PDT) (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 82364132CFB for ; Tue, 29 Jun 2004 18:52:57 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 25AE96EA; Tue, 29 Jun 2004 18:52:57 -0400 (EDT) Date: Tue, 29 Jun 2004 18:52:57 -0400 From: Meng Weng Wong To: ietf-mxcomp@imc.org Subject: DDOS attacks Message-ID: <20040629225257.GJ16052@dumbo.pobox.com> References: <20040629142750.GU3747@verdi> <20040629144923.GS13225@dumbo.pobox.com> <40E1ED34.1020501@elvey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40E1ED34.1020501@elvey.com> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Jun 29, 2004 at 03:29:08PM -0700, Matthew Elvey wrote: | Yeah, looks like they were mis-assigned, and no one noticed. | Anyway, I'd suggest that the lively thread about DDoS attacks presents a | situation that CSV handles well, and SPF doesn't handle as well. | How poorly it is handled merits further discussion. It seems to me the DDOS attacks we have reviewed so far pretty much boil down to: SECURITY CONSIDERATIONS We take it as a given that malicious entities control large distributed networks of 0wned machines, in the six to eight figure range. These machines are compromised workstation-grade machines that belong to ordinary end-users on broadband connections. They are generally referred to as zombies. Malicious entities who have philosophical objections to a given technology may attempt to dissuade people from adopting that technology by mounting distributed denial-of-service attacks on adopters. The most elegant way to mount such an attack is to contrive a scenario in which the technology itself plays a part in the resulting denial of service. If the attack does not affect those who do not adopt the technology, and only hurts those who do adopt the technology, it gives adopters incentive to abandon the technology. Such an auto-targeting attack can be easily executed using zombie networks. Technologies which are more complex tend, in general, to be more easily attacked in this way than technologies which are simpler. However, the elegant attack is not the only attack. A malicious entity may identify adopters of a given technology in an initial pass, and use the zombies against those adopters directly. The connection between the attack and the objective (discouraging the technology) can be made when an attacker claims responsibility for the attack. Both the elegant and the brute-force attacks are feasible against any open protocol. The only way to avoid these attacks completely is to retreat to a "private club" model, in which nodes do not communicate with other nodes if they have not previously established a trust relationship. A midway position between total openness and a "private club" involves the use of reputation services. If a protocol endpoint tests new connections against a reputation service before engaging more deeply in protocol operation, attacks can be mitigated. From owner-ietf-mxcomp@mail.imc.org Tue Jun 29 19:23:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06826 for ; Tue, 29 Jun 2004 19:23:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TN9XLf034036; Tue, 29 Jun 2004 16:09:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5TN9XVN034035; Tue, 29 Jun 2004 16:09:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TN9UFf034028 for ; Tue, 29 Jun 2004 16:09:31 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: YRV1r6pFe+VO3T4U5DOgdA 1088550573 Received: from [192.168.1.141] (ns.nextbus.com [64.164.28.194]) by mail.messagingengine.com (Postfix) with ESMTP id 9C40BC0DE86; Tue, 29 Jun 2004 19:09:31 -0400 (EDT) Message-ID: <40E1F6AB.9050109@elvey.com> Date: Tue, 29 Jun 2004 16:09:31 -0700 From: Matthew Elvey User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Douglas Otis Cc: Greg Connor , MARID Subject: Re: Unified SPF overlaps with CSV References: <1088527917.4998.117.camel@ddev.mail-abuse.org> <11967678.1088509187@Ryoga.corp.sgi.com> <1088544618.4998.249.camel@ddev.mail-abuse.org> In-Reply-To: <1088544618.4998.249.camel@ddev.mail-abuse.org> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/29/2004 2:30 PM, Douglas Otis sent forth electrons to convey: > I struggled to understand Doug's post for a few minute, and then considering the RHS of Doug's email address ("mail-abuse.org") made it all clear. Put yourself in the shoes of an RHSBL maintainer for a moment. With CSV, if a domain has authorized its use in HELO for an IP, it is reasonable to blacklist said domain for such authorization when it results in spam. And a blacklist of such domains could be quite effective at separating ham and spam with few FPs and FNs. With SPF, if a domain has authorized its use in any of the myriad ways that SPF requires it authorize its use, then it's much less reasonable to blacklist said domain for such authorization when it results in spam. A blacklist of such domains would be much less capable of separating ham and spam with few FPs and FNs. Here's an example: there is no MTA that does a HELO elvey.com. Mail from users at elvey.com is sent through (among others) rr.com and fastmail.fm. rr.com and fastmail.fm will have to publish CSV records, but elvey.com won't. All three will have to publish SPF records. elvey.com. 7201 IN TXT "v=spf1 a mx ip4:63.195.86.147 ip4:66.111.4.0/24 include:webcom.com include:rr.com include:pacbell.net include:nextbus.com include:messagingengine.com ?all match_subdomains=yes" What am I supposed to do if zombies on pacbell.net and rr.com start forging mail from elvey.com? Is MAPS going to point out that it's listed me for having a loose SPF record? Proably. So I must tighten up my SPF record? How, exactly? Assume that just 5% of all domains are in the same kind of situation. Basically, include:rr.com, include:pacbell.net, etc. need to be removed, and I need to set up smarthosts and walk ALL the users using rr.com and pacbell.net through changing their MUA configurations. That would suck! (Assume for the moment that rr.com, pacbell.net, etc. do publish SPF records) I suspect that the scenario I've described is of the kind that Doug is worrying about. From owner-ietf-mxcomp@mail.imc.org Tue Jun 29 19:53:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08580 for ; Tue, 29 Jun 2004 19:53:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TNcUq4036057; Tue, 29 Jun 2004 16:38:30 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5TNcUGn036056; Tue, 29 Jun 2004 16:38:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TNcUwq036048 for ; Tue, 29 Jun 2004 16:38:30 -0700 (PDT) (envelope-from matthew@elvey.com) X-Sasl-enc: JTj90KLaPITKT9cgvcIEqQ 1088552311 Received: from [192.168.1.141] (ns.nextbus.com [64.164.28.194]) by mail.messagingengine.com (Postfix) with ESMTP id 26FBBC0DC3D; Tue, 29 Jun 2004 19:38:29 -0400 (EDT) Message-ID: <40E1FD76.7000805@elvey.com> Date: Tue, 29 Jun 2004 16:38:30 -0700 From: Matthew Elvey User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roy Badami Cc: Greg Connor , meng Weng Wong , "'IETF MARID WG'" Subject: Re: Will SPF/Unified SPF/SenderID bring down the 'net? References: <16609.53607.699397.966940@giles.gnomon.org.uk> In-Reply-To: <16609.53607.699397.966940@giles.gnomon.org.uk> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/29/2004 1:30 PM, Roy Badami sent forth electrons to convey: > >I've seen it argued earlier in the life of SPF that some sites might >not wish to make their complete list of outgoing IP addresses easily >accessible, and that the exists mechanism in SPF (I guess this is what >is meant by a factored record) is of benefit to such sites. An >attacker who'd comprpomised an ISP's routing could use block records >to rapidly search for domains that list addresses in netblocks the >attacker is able to spoof. Factored records make that search much >harder. > Yup. I can't advocate removing the macro abilities of SPF. Unless we make some progress toward showing that Classic SPF with macro abilities doesn't create a tempting and relatively vulnerable target, then I see CSV as necessary before SPF. Makes more sense than dropping macro abilities. Philip is saying in essence that the details of an attack scenario and of CSV are beyond his comprehension at this time* and he and I appear unable to communicate further; each of us feels we have presented our case fully, but we are still far apart. This is unfortunate; I think if we dug deeper we might find that SPF can withstand attack as well as what's out there now. Philip's posts to date don't get us there, so I think we need to agree to disagree. I don't mean anything personal; we just need to have the kind of discussion one would expect a new crypto scheme proposal would engender. BTW, here's a report of a zombie army of over 100,000 IPs attacking the MX host of elvey.com: http://www.emailaddresses.com/forum/showthread.php?postid=198568#post198568 *e.g. It's not about stack depth. Also: "The reason I do not want to go down the csv path is that I have yet to see a clear and concise explanation of the proposal..." If there is a there there it will be possible to state in a short post the changes necesary to express csv semantics in spf syntax. " MOVING FORWARD: Here I try to flesh out further how an attack might (not) work. 1) It would make sense to assume the attacker will have most leaf nodes of the SPF records it published be victim nodes, and that some non-leaf nodes could be as well (e.g. include:msn.com) If we make the (perhaps unwarranted) assumption that SPF checkers rely on local caching DNS resolvers that hold the world's SPF records, then are we safe? No, with a dynamic SPF record with thousands of leaf nodes, all random macros, no DNS resolver can cache that. No scheme for determining that the domain or any IPs involved can be blacklisted thereby has been presented or comes to mind. What if we eliminate macros? Well, a)I don't think we should but b) does it fix the problem? Doug's attack scenario made no use of macros, and seems reasonable, so probably the answer is 'no'. However, let's take a step back. Before fetching the whole SPF record, the domain will be checked with a reputation service. Perhaps we say that the first N (N=3?) UDP DNS queries to fetch an SPF record must either fetch the whole record or specify a reputation service that at least gives the domain enough credibility for a fetch of the rest of the record to be warranted. Thoughts, anyone? Perhaps simply the fact that the domain hasn't been blacklisted gives the domain enough credibility for a fetch of the record to be warranted. Thoughts, anyone? A point that I thought was obvious, but some may have missed: if an SPF record's tree can be ten levels deep, it can require thousands of DNS queries to resove. The number of DNS queries is what needs to be controlled. PS. I wrote this post before reading Greg's about limiting posts, which was probably deservedly targeted partly at me. I'll bite my tongue for a while. Sorry my posts (all to 2 threads) were excessive, and the thread that went downhill. From owner-ietf-mxcomp@mail.imc.org Tue Jun 29 20:13:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09772 for ; Tue, 29 Jun 2004 20:13:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5U030Zo037197; Tue, 29 Jun 2004 17:03:00 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5U0309S037196; Tue, 29 Jun 2004 17:03:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5U02x2C037189 for ; Tue, 29 Jun 2004 17:02:59 -0700 (PDT) (envelope-from roy+dated+1091145780.9676bc@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i5U030YX014741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 30 Jun 2004 00:03:02 GMT (envelope-from roy+dated+1091145780.9676bc@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5U030Xs035771 for ; Wed, 30 Jun 2004 01:03:00 +0100 (BST) (envelope-from roy+dated+1091145780.9676bc@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5U030PM035770 for ietf-mxcomp@imc.org; Wed, 30 Jun 2004 01:03:00 +0100 (BST) (envelope-from roy+dated+1091145780.9676bc@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Wed, 30 Jun 2004 01:02:59 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16610.819.43313.16270@giles.gnomon.org.uk> Date: Wed, 30 Jun 2004 01:02:59 +0100 To: Douglas Otis Cc: Greg Connor , MARID Subject: Sender ID and CSV are complimentary (long - sorry) (was: Unified SPF overlaps with CSV) In-Reply-To: <1088544618.4998.249.camel@ddev.mail-abuse.org> References: <1088527917.4998.117.camel@ddev.mail-abuse.org> <11967678.1088509187@Ryoga.corp.sgi.com> <1088544618.4998.249.camel@ddev.mail-abuse.org> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Douglas" == Douglas Otis writes: Douglas> What identity is used to assert accountability? Due to Douglas> this weak from of identity, SPF/CID _MUST_ never be used Douglas> to assert accountability. If mail was injected somewhere Douglas> inside a nebulous region devoid of SPF/CID checks, how is Douglas> this detected? Are those spoofed to be soiled by a Douglas> machine somewhere not tied down properly? Having been skimming this thread, and not entirely understanding what it was about, I'll have to say I think I agree with this point, although I don't think it's very clearly stated. I'm starting to understand why CSV could be potentialy valuable... NB: The following discussion relates to the drafts that have been submitted to this WG, and to the published SPF ID (draft-mengwong-spf-01). I'm aware of some discussion on the SPF list and subsequently here about "Unified SPF" but no ID yet exists to my knowledge; I'll leave my comments about that till the end... Both draft-mengwong-spf-01 (SPF) and draft-ietf-marid-core-01 (SenderID) are to do with authenticating *messages*. If you receive a message that fails the SPF or SenderID checks, you know the *message* is forged, but you know nothing about who forged it. The fact that an MTA sends you a message that fails SPF/SenderID checks tells you nothing about the propriety of the MTA that sends it to you; just that a forged message was injected into the mailstream at some point, and that MTA (quite possibly perfectly innocently) happened to attempt to deliver it to you. draft-ietf-marid-csv-* authenticates the sending MTA directly (but it doesn't authenticate the message in any way); if you get CSV authentication failures, you know that it's the immediate upstream MTA that's spoofing. But the fact that the MTA is genuine doesn't prove that the message is genuine. What does this gain you in itself? Probably not much. It wouldn't be much effort for spammers/phishers/whatever to give a valid HELO identity in a throwaway domain registered for that purpose. But coupled with reputation/accreditation services, it becomes more valuable. Doing reputation/accreditation by IP address is problematic at best -- it interferes with things like network renumbering, deploying additional MTAs, etc, and has problems when IP addresses are reallocated to other entities. Having an authenticated name for the delivering MTA is a more flexible way of attaching reputations/accrediation to MTAs than the IP blacklists/whitelists (largely blacklists) we currently use. And filtering at that level is clearly useful. Most of us use IP blacklists. And we're now living in a world where open relays no longer account for the majority of spam. Most spam is now direct to MX or delivered via open proxies (in both cases with compromised machines often being used). So establishing reputation at the delivering MTA level would seem to be a valuable tool, and having a mechanism for doing so without requiring that ISPs never renumber their networks for fear of losing their reputution is clearly a good thing. (Obviously reputation at this level is a defense against open relays too, it's just that they're no longer the main threat). It seems to me that SPF/SenderID and CSV solve very different subproblems of the problem space that this WG is interested in, and in particular that they may end up using very different notions of reputation/accreditation. In a scheme like SPF/Caller ID/Sender ID you're looking at reputations of e-mail addresses (or at least their domains). Does this domain originate mail that is legitimate, or does it originate spam? People blacklist/whitelist now on MAIL FROM and From: but it's problematic because it's easily forged. If you can prove an association between the message and the domain, such blacklisting/whitelisting becomes more reliable. Also, at least some of the proposals (namely Caller ID and the Sender ID) are potentially very useful components in an anti-phishing strategy -- ie validating the domain that is displayed to the end user -- even if such strategies also require MUA support. And anti-phishing is clearly something that many people want. In CSV/CSA you're looking at reputations of originating hosts. Is this a well run MTA, or is this some random bot, proxy or open relay that's opening an SMTP connection to me? Granted the fact that it's a well run MTA doesn't prove that forged messages or spam won't pass through it, but in the world we live in a very small proportion of unwanted mail is originated from well-run MTAs, so reputation at that level certainly seems valuable. Most of us do this already based on IP blacklists. Blacklisting/whitelisting (particularly when you get to whitelisting) on an authenticated name of the host seems far more flexible. Based on the above, which I realize might involve a misunderstanding of one or both proposals, it seems to me that Sender ID and CSV attempt to tackly essentially unrelated subproblems within the MARID problem space. I think a lot of the confusion in this and other threads stems from the fact that the two proposals tackle different subproblems, and many WG participants are essentially focussed on just one of them. In fact, it seems to me that the models of reputation and accrediation services that might evolve within these two problem areas are potentially quite different. It also seems to me that Sender ID and CSV can be deployed independently; both publishers and checkers can decide to implement one, the other, or both. Given that, it's not clear to me that it's appropriate to burden CSV with the complexity of an SPF record, since people may wish to deploy CSV without Sender ID. So, in answer to the question: - Due 2004-07-02: Decide if CSV is complimentary, parts to be incorporated, or dropped. My current gut feeling is that this WG should advance draft-ietf-marid-core/submitter and draft-ietf-marid-csv-* to PS without trying to unify them technically. I think the only unification that should happen is (if feasible within the timescales) is in terms of a unified intro/rationale document that describes the framework in which both exist. Part of the reason for my position is that they address different subproblems of the MARID problem space, and that I don't think there is any clear technical benefit in unifying the record formats, given the simplicity of the CSA record. There are also pragmatic reasons for this position. This WG is working on a very tight schedule, and it also is treading into unchartered territory. Despite the SPF adoption to date, nothing has been implemented on a large scale (current SPF deployement is still, in reality, a drop in the ocean) and none of us really knows how this will pan out in practice. We're not going to get this right first time, however hard we try; we have to accept that. Whatever this WG proposes, I'm sure that there will be much more work to do in the future (either by this WG or a successor) in the light of operational experience of those proposals. Given that the groups of people persuing the Sender ID and CSV problem spaces are largely disjoint, keeping the proposals largely independent seems like the most efficient use of this WG's time; and it strikes me that attempting to unify them technically just for the sake of it is likely to consume much WG effort for little or no technical benefit. Only operational experience will tell us the value of MARID in these two problem spaces, and until we have that, I think a 'unified theory of MARID' is premature. Ok, now the promised brief comment on 'Unified SPF': I'm coming the to conclusion that Sender ID shouldn't be extended to check the HELO. SPF checked it only for mail from <>; Sender ID if I'm not mistaken doesn't check it at all. But the semantics of checking HELO are very different from what SPF/Sender ID set out to do. And it's not clear to me that the reputation/accreditation services will work in the same way. Or that the same reputation/accreditation services will be interested in dealing with both problem spaces. The only reasone why SPF checked the HELO (as I see it) was to close the gaping hole left by mail from <>; CSV seems a better solution to that, so leave it out of Sender ID. Sorry to have bored you all with such a long post; hope this makes at least some sense... -roy From owner-ietf-mxcomp@mail.imc.org Tue Jun 29 20:45:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11512 for ; Tue, 29 Jun 2004 20:45:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5U0XDFf038718; Tue, 29 Jun 2004 17:33:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5U0XDJ0038717; Tue, 29 Jun 2004 17:33:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.pan-am.ca (205-200-6-46.static.mts.net [205.200.6.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5U0XBCL038711 for ; Tue, 29 Jun 2004 17:33:12 -0700 (PDT) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: DDOS attacks MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 29 Jun 2004 19:33:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA8EE@srv1.pan-am.ca> Thread-Topic: DDOS attacks Thread-Index: AcReLbLZiH0bqaneQdKBD8W91Ome+gACNl6Q From: "Gordon Fecyk" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5U0XCCL038712 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > It seems to me the DDOS attacks we have reviewed so far > pretty much boil down to: > > SECURITY CONSIDERATIONS Looking at this from a purely administrative point, I question this entire e-mail. > We take it as a given that malicious entities control > large distributed networks of 0wned machines, in the six > to eight figure range. These machines are compromised > workstation-grade machines that belong to ordinary > end-users on broadband connections. They are generally > referred to as zombies. First and foremost, what can a pack of zombie machines do to this system that they can't already do to other systems? Flood e-mail? Perform repeated DNS lookups? Ping the hell out of mail servers or DNS servers? > The most elegant way to mount such an attack is to > contrive a scenario in which the technology itself plays a > part in the resulting denial of service. If the attack > does not affect those who do not adopt the technology, and > only hurts those who do adopt the technology, it gives > adopters incentive to abandon the technology. Such an > auto-targeting attack can be easily executed using zombie > networks. Al Capone of Cyberspace. "Don't even think of doing this or we'll hurt you." That's like telling me not to use Internet Explorer just because you know how to exploit flaws in it. Or Outlook. Or any other big name product or technology. Yet here I am sitting at my desk with the two most dangerous pieces of software on my computer running at the same time, without anti-virus software running even, and I'm not affected by the current garbage. Or the recent garbage. Or the earlier garbage. Or the garbage that is yet to come. So 180solutions knows how to install spyware behind peoples' backs. Big deal - doesn't work if the user can't install anything to begin with (such as on a 2K or XP box with a limited user). Steve Gibson preached to Microsoft pleading not to enable Raw Sockets support in Windows XP. His network was attacked as a result of his ranting - not with r00ted XP boxes exploting raw sockets - but with a plain and simple traffic flood. Yet he maintains TO THIS DAY that Microsoft doomed the Internet SOLELY because of this technology. Bugs and flaws in MARID are going to be the least of your worries when Al Spampone tells you not to use it or else, as you explained later on. > Both the elegant and the brute-force attacks are feasible > against any open protocol. The only way to avoid these > attacks completely is to retreat to a "private club" > model, in which nodes do not communicate with other nodes > if they have not previously established a trust > relationship. > > A midway position between total openness and a "private > club" involves the use of reputation services. If a > protocol endpoint tests new connections against a > reputation service before engaging more deeply in protocol > operation, attacks can be mitigated. I disagree wholehartedly here. Technologies can and do function - often better - in an open environment. PGP is my favorite example here, because there's a lock where you know how the mechanism works, yet it is still extremely difficult to break. A strong lock, indeed. Sure it _had_ bugs. They got fixed. Security by obscurity, or by reputation, is just going to hide problems until they're discovered far too late. Ironically, we don't have to look past our own desktops to see examples. Now do we have anything to hide here? Here's another example: I'm supposedly a fool for leaving my Win2K AD domain's primary DNS server exposed to the Internet. Sure I'm firewalling and port-forwarding everything I need, and if you poked around long enough you'd discover my entire internal AD structure. But what can you do with it? You know my services' CSIDs (I think that's what they're called) but since you can't talk to it through SMB or NetBIOS you're SOL. And when MARID records begin to appear on my domain you're going to know where my authorized SMTP clients will be. So what? None of those IPs or hostnames are yours and unless you r00t my boxes they never will be. -- PGP key (0x0AFA039E): Sometimes it's hard to tell where the game ends and where reality bites, er, begins. From owner-ietf-mxcomp@mail.imc.org Tue Jun 29 21:12:29 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12627 for ; Tue, 29 Jun 2004 21:12:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5U0uFZ7039892; Tue, 29 Jun 2004 17:56:15 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5U0uFha039891; Tue, 29 Jun 2004 17:56:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5U0uEDG039885 for ; Tue, 29 Jun 2004 17:56:15 -0700 (PDT) (envelope-from roy+dated+1091148979.d4a9f7@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i5U0uIYX030003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 30 Jun 2004 00:56:19 GMT (envelope-from roy+dated+1091148979.d4a9f7@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5U0uJn2036031 for ; Wed, 30 Jun 2004 01:56:19 +0100 (BST) (envelope-from roy+dated+1091148979.d4a9f7@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5U0uJPY036030 for ietf-mxcomp@imc.org; Wed, 30 Jun 2004 01:56:19 +0100 (BST) (envelope-from roy+dated+1091148979.d4a9f7@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Wed, 30 Jun 2004 01:56:18 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16610.4018.1181.232165@giles.gnomon.org.uk> Date: Wed, 30 Jun 2004 01:56:18 +0100 To: "Gordon Fecyk" Cc: Subject: RE: DDOS attacks In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125DA8EE@srv1.pan-am.ca> References: <700EEF5641B7E247AC1C9B82C05D125DA8EE@srv1.pan-am.ca> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Gordon" == Gordon Fecyk writes: Gordon> Al Capone of Cyberspace. "Don't even think of doing this Gordon> or we'll hurt you." I can't tell whether that's tongue-in-cheek or not. But if you haven't been following what's been happening to DNS blaklists over the last year, that's pretty much exactly what's going on at the moment. Spammers, hackers and organized crime gangs are very much working together. People running blacklists are getting targetted by large scale DDoS attacks in an attempt to get them to give up, and several prominent blacklists have shut down over the past year because they couldn't cope. All but the largest ISP's are now I suspect likely to be unwilling to host a customer that runs a high profile blacklist, because they know that they can't cope with the inevitable DDoS attacks. -roy From owner-ietf-mxcomp@mail.imc.org Tue Jun 29 22:03:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14922 for ; Tue, 29 Jun 2004 22:03:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5U1ljT8043110; Tue, 29 Jun 2004 18:47:45 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5U1ljqD043109; Tue, 29 Jun 2004 18:47:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5U1lfpU043102 for ; Tue, 29 Jun 2004 18:47:45 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.0.1.153] ([::ffff:64.83.8.178]) (AUTH: LOGIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Tue, 29 Jun 2004 21:47:45 -0400 id 0005C581.40E21BC1.00007BC3 In-Reply-To: <16610.819.43313.16270@giles.gnomon.org.uk> References: <1088527917.4998.117.camel@ddev.mail-abuse.org> <11967678.1088509187@Ryoga.corp.sgi.com> <1088544618.4998.249.camel@ddev.mail-abuse.org> <16610.819.43313.16270@giles.gnomon.org.uk> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <79F4B58C-CA37-11D8-883C-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: MARID From: Andrew Newton Subject: Re: Sender ID and CSV are complimentary (long - sorry) (was: Unified SPF overlaps with CSV) Date: Tue, 29 Jun 2004 21:47:42 -0400 To: Roy Badami X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jun 29, 2004, at 8:02 PM, Roy Badami wrote: > Granted the fact that it's a > well run MTA doesn't prove that forged messages or spam won't pass > through it, but in the world we live in a very small proportion of > unwanted mail is originated from well-run MTAs, so reputation at that > level certainly seems valuable. I have in my notes an interesting tidbit from the MAAWG meeting in DC: Carl Hutzler of AOL said that >70% of spam comes through the mail servers of ISPs. -andy From owner-ietf-mxcomp@mail.imc.org Tue Jun 29 22:47:30 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16486 for ; Tue, 29 Jun 2004 22:47:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5U2Z1mv045550; Tue, 29 Jun 2004 19:35:01 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5U2Z1G2045549; Tue, 29 Jun 2004 19:35:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from xuxa.iecc.com (xuxa.iecc.com [208.31.42.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5U2Z0mm045540 for ; Tue, 29 Jun 2004 19:35:00 -0700 (PDT) (envelope-from sb0-05995ff4e2-johnl@iecc.com) Received: (qmail 28234 invoked by uid 100); 30 Jun 2004 02:35:05 -0000 Date: 30 Jun 2004 02:35:05 -0000 Message-ID: <20040630023505.28233.qmail@xuxa.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: How fragile is SPF ? Organization: I.E.C.C., Trumansburg NY USA Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I set up SPF for one of my subdomains to stress test systems that check SPF on incoming mail. (You know, running code to go with the rough consensus.) You can try them yourself on any subdomain of slow.sp.am, e.g. yourname.slow.sp.am. The extra level of name makes it easier for me to tell from the DNS server logs what the sequence of requests for each message is, of someone's wondering what his system asked as it did the checks. I believe all of the SPF records are syntactically and semantically valid, and they're all well within both the limits of the SPF spec and the implementation limits in the perl reference code. They do nested includes 10 deep and do a few MX lookups, and correctly list the hosts from which .slow,sp.am mail might be sent. Responses fit in 512 byte UDP DNS packets unless you use a really long subdomain name. If you'd be willing to see how your SPF implementation does, either tell it to check any subdomain of slow.sp.am, or I can send you mail and see how your MTA deals with it and you can write back, since the addresses are real. The SPF checks are likely to take an hour or more per message, even though everything is well within the 15 second timeout that the reference SPF code enforces. The point of this is that we all expect bad guys to publish hostile MARID records, so we might as well find out now how much trouble that's going to cause. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY http://www.taugh.com From owner-ietf-mxcomp@mail.imc.org Tue Jun 29 23:15:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17218 for ; Tue, 29 Jun 2004 23:15:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5U33QZk047013; Tue, 29 Jun 2004 20:03:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5U33QOT047010; Tue, 29 Jun 2004 20:03:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.pan-am.ca (205-200-6-46.static.mts.net [205.200.6.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5U33OwG046983 for ; Tue, 29 Jun 2004 20:03:25 -0700 (PDT) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: How fragile is SPF ? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 29 Jun 2004 22:03:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA8F0@srv1.pan-am.ca> Thread-Topic: How fragile is SPF ? Thread-Index: AcReTPKXhaJpIZNTTa6rk1ohB/980wAAbxMA From: "Gordon Fecyk" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5U33PwG047000 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > I set up SPF for one of my subdomains to stress test systems that > check SPF on incoming mail. (You know, running code to go with the > rough consensus.) > The point of this is that we all expect bad guys to publish hostile > MARID records, so we might as well find out now how much trouble > that's going to cause. Good old fashioned testing. Actually, by this time AOL, altavista.com etc must have some hard data on its effects. It's been at least four months. Numbers, anyone? -- PGP key (0x0AFA039E): Sometimes it's hard to tell where the game ends and where reality bites, er, begins. From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 00:45:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20467 for ; Wed, 30 Jun 2004 00:45:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5U4WEAs052909; Tue, 29 Jun 2004 21:32:14 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5U4WE3V052908; Tue, 29 Jun 2004 21:32:14 -0700 (PDT) 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.9) with ESMTP id i5U4WDdR052894 for ; Tue, 29 Jun 2004 21:32:13 -0700 (PDT) (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.34) id 1BfWlX-0003jZ-0z for ietf-mxcomp@imc.org; Tue, 29 Jun 2004 23:32:17 -0500 To: "IETF MARID WG" References: <20040630023505.28233.qmail@xuxa.iecc.com> From: wayne Reply-To: "IETF MARID WG" Date: Tue, 29 Jun 2004 23:32:10 -0500 In-Reply-To: <20040630023505.28233.qmail@xuxa.iecc.com> (John Levine's message of "30 Jun 2004 02:35:05 -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 (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: How fragile is SPF ? Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.3 required=4.0 tests=AWL,BAYES_00,GREYLIST_ISWHITE autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <20040630023505.28233.qmail@xuxa.iecc.com> John Levine writes: > I set up SPF for one of my subdomains to stress test systems that > check SPF on incoming mail. (You know, running code to go with the > rough consensus.) [...] It comes as little surprise to me that the Chair of the IETF Anti-Spam *RESEARCH* Group has actually done research. Thank you! It has been kind of lonely being one of the few to dig up stats. > If you'd be willing to see how your SPF implementation does, either > tell it to check any subdomain of slow.sp.am, or I can send you mail > and see how your MTA deals with it and you can write back, since the > addresses are real. As I mentioned in an earlier (private) email to you, my development version of my SPF implementation has a overall timelimit on an SPF execution. While your very slow NS is by design, in practice, I think we will run into equally slow NS by neglect. The Caller-ID spec has a codified time limit. My suggestion to Meng to add one to the SPF spec got dropped. I think it needs one really needs to be added. > addresses are real. The SPF checks are likely to take an hour or more > per message, even though everything is well within the 15 second > timeout that the reference SPF code enforces. My libspf2 (aka libspf-alt) implmentation runs into other processing restrictions after a couple of minutes. This is still too long. From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 01:20:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22175 for ; Wed, 30 Jun 2004 01:20:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5U58kAw060149; Tue, 29 Jun 2004 22:08:46 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5U58kb0060148; Tue, 29 Jun 2004 22:08:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (ftp.catinthebox.net [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5U58jDg060133 for ; Tue, 29 Jun 2004 22:08:46 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Wed, 30 Jun 2004 01:12:41 -0400 Received: from ([65.10.109.27]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 2383007610; Wed, 30 Jun 2004 01:12:38 -0400 Message-ID: <00de01c45e60$59147200$6401a8c0@hdev1> From: "Hector Santos" To: "Gordon Fecyk" , "IETF-MXCOMP" References: <700EEF5641B7E247AC1C9B82C05D125DA8F0@srv1.pan-am.ca> Subject: Re: How fragile is SPF ? Date: Wed, 30 Jun 2004 01:08:51 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.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: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Gordon Fecyk" To: Sent: Tuesday, June 29, 2004 11:03 PM Subject: RE: How fragile is SPF ? > Good old fashioned testing. > > Actually, by this time AOL, AltaVista.com etc must have some > hard data on its effects. It's been at least four months. > Numbers, anyone? > We have 7-8 months of operational experiences with stored logs. About 1000+ installations by this point. It was a low-key release. In the first few months I was collecting field tester logs to compare results. My own support system stats can be seen at http://www.winserver.com/antispam. I can zip up logs for anyone if you wish to run their own simulator or reporter. They are all very verbose and detailed. Here is my summary points on SPF and overhead issues. MARID can not be a complete open ended lookup system if only for one reason: There is no guarantee of an effective database availability. This is obviously the case during the early stages. But another more obvious reason is that most of the spam is going to be no result or NXDOMAIN. I see four (4) possible future scenarios for spammers when MARID is finally in place: 1) Spammer will comply - Good Spammer, CANSPAM compliant. 2) Spammer will ignore it - Question of legal status unknown. 3) Spammer will SPOOF SPF - Malicious illegal Entry - US ECPA violation 4) Spammers/hacker will overload it - obvious crime. Call the FBI! Of course, the benefit I (and most people) would be looking for is: 5) Spammers are reduced. (Go out of business? Stop trying?) So what I am seeing with my 7-8 months of accumulated data? I need to write some code to get these specific totals, but it is pretty obvious what the trend is. - Hardly any will comply. A few added legit SPF records. - By far, most will ignore it. - Some are spoofing SPF relaxed policy domains (see comment about Neutral/Softail) - 4-6 days with non-stop connections, reaching 100K or more per day. and finally when there were weeks or some patterns where the daily connections were on a down curve, it would PICK right up and by far, the totals were pretty steady in fact, there were weeks where the daily totals differ by less than 1% In the last few months, what have been a steady near 2500 daily total, it is now up to an average 5500 for the month of June. So does it reduce spammers? Unfortunately I can't say that it does, atleast not by what I see. But I believe most people were aware of this and realized the goal in any tools added to control it was to reduce the junk collected to a bare minimum or zilch. We have about a 90-94% rejection rate, so by far, the customer base is extremely happy. My main design work focused was to reduced any DNS lookup required and do add a 2821 rejection IP related concept that further reduced the need to do a final CBV check to see if the return address is acceptable. This might be out of scope but if we concern about SPF abuse and/or DNS overhead/attacks, etc, then it needs to stated that the SMTP servers need to do more to reduce the MARID/DNS requirement in the first place. Its that plain any simple and I believe 100% most implementators will finally see this one they get going with this, like I have. Our SMTP was pretty much a standard system like all others. Didn't have all the stuff it has now until we started to do all this extra checking with DNS. That is why I said it can't be such an open ended equation with the desire to provide the same results we are looking for. Something has to give and I do believe, eventually, others will see that (if not already). One thing SMTP developers can do is to first is to enforce SMTP compliancy. One simple check is the HELO syntax. Go figure, by doing a simple domain literal check, you can knock out 10-12% of the spammers! No DNS lookup required. Another easy item addresses the BULK spammers which is where I get most of my connections (and spam attacks). BULK Spammers need to optimize their throughput too. So they use dumb streaming SMTP clients, possible perl or php scripts that don't support multi-line responses. MARID operators should probably be adding ECPA/CAMSPAM or Local nation legal compliant System Policy statement at the Welcome/Greeting. Believe it or not, this will eliminate atleast 40% of these dumb bulk spammers. They can't handle the perfectly acceptable SMTP compliant Multi-Line Greeting. Have spammers learned? Well, I thought they would! But I continue to see it. I think we are giving more credit then they deserve. But someone brought up a good point. Once everyone applies this idea, then maybe spammers will adjust. I 100% agree, but isn't this good? We want spammers to change! Once they see what is going on, some will begin to make the effort to comply with other SPAM related efforts. Currently, they don't have the incentive to change. And the final SMTP improvement comes straight from RFC 2821 - "Section 3.3 Mail Transactions" should not be ignored. I believe one of the absence MARID parameters is RCPT TO. RCPT TO validation should be performed by SMTP. This saves us another 30-35% of DNS lookups requirements and it makes sense to do an RCPT TO validation. And it makes sense too! MARID is really only for an anonymous sender transactions for final destination mail. A route is by traditional SMTP standards allowed only for authenticated senders using traditional SMTP methods (SMTP AUTH, IP allow relay tables, POPB4SMTP). So for routed mail (RCPT TO is not local), authentication or trust is already required by SMTP thus nullifying any need for LMAP or DNS related sender validation. So doing more at SMTP will clearly reduce much of the MARID overhead related issues. Simply by following the above SMTP level advance checking, you can reduce atleast 70-75% of your MARID lookup needs. You can't ignore it or try to solve this using an open ended MARID/DNS lookup. As far as the SPF malicious abuse, there is not much you can do without following the specs. Of course, you implementation needs to be bug free of buffer exploits. But I have not seen any exploitation in these area, atleast not malicious. Ironically, I did see it from "real systems" in the form of not having a proper setup or just having big records. I seen one policy like so: v=spf1 x.y.0.0/32 +mx -all where the x.y is literally there. By overall, as far as SPF concerns for me there are 2 things: o Macro Expansion: if there is one SPF feature that standouts is the macro expansion thing. This was the last part implemented for us. This could be another argument against it that keeps it from being a straight forward easy implementation. i.e, new implementers who need to use a 3rd party solution as oppose to keeping it in house. So if there is one area that might not be done correctly when done in-house, it could be the macro expansion. o Softfail/Neutral This is what I see happening, however, not at high levels. If I was the author, I would of made it very clear in the SPF specification that the SoftFail/Neutral relaxed fallback should be viewed as a Temporary option with an inherent Expiration or Time Limit (i.e, 6 months?) In my opinion, this will probably be the one area a SPF spoofing spammer will make itself look compliant, but use a relaxed result policy. It also offers spammers a way to look at other SPF domains with relaxed policies. My recommendation is that a SPF client seeing a SoftFail/Neutral should record the first time usage of this record and then place a time limit on its continue usage. I see this softfail/neutral concept as something that starts a new specification with a loophole spammers can use. I understands the reasons for it, but it should be coupled with some enforcement expiration or time limit. AOL.COM should not be using it forever. At some point, they need to change that to a FAIL. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 02:25:41 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17767 for ; Wed, 30 Jun 2004 02:25:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5U69hZl091703; Tue, 29 Jun 2004 23:09:43 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5U69hQj091702; Tue, 29 Jun 2004 23:09:43 -0700 (PDT) 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.9) with ESMTP id i5U69gpJ091693 for ; Tue, 29 Jun 2004 23:09:42 -0700 (PDT) (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.34) id 1BfYHr-0004pH-WC for ietf-mxcomp@imc.org; Wed, 30 Jun 2004 01:09:49 -0500 To: "IETF MARID WG" From: wayne Reply-To: "IETF MARID WG" Date: Wed, 30 Jun 2004 01:09:39 -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 (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: DDoS attacks via SPF Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.3 required=4.0 tests=AWL,BAYES_00,GREYLIST_ISWHITE autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The subject of using SPF to create DDoS attacks is not new. For example, I raised this subject back in December on this thread: http://archives.listbox.com/spf-discuss@v2.listbox.com/200312/0393.html A while back, I took a look at this subject in detail. Sadly, I failed to record all my numbers, so I'm going to have to recreate them if I want to publish them. :-< The conclusion I came to was: The current SPF system is pretty resistant to DoS attacks, but I think the SPF spec needs to have a lot more limits placed on the processing in order to really prevent most abuse. The goal doesn't need to be that SPF can never be abused in any way, just that it is easier and more useful to use other techniques to be abusive. It's kind of like it not being important that you can out-run a lion, just that you can out-run the other people in your safari. Most of the discussions so far have been about a spammer/cracker attacking someone directly using a malicous SPF record. That is, a malicious SPF record is created, then email is sent to the victim's MTA and the processing of the SPF record will cause problems for the victim. I think this is not a huge concern. Reasonable limits can be placed on the processing of SPF records and the victim can adapt when this kind of attack is happening. The much more serious problem, in my opinion, is using SPF to indirectly attack someone. A spammer/cracker could create a malicious SPF record that causes DNS traffic to be directed to the victim when email is sent to *other* MTAs. This is the scenerio outlined in my post from last December. Evil.com creates a record that causes many DNS lookups to be done against victim.com's name server. Evil.com then sends many SMTP commands that cause SPF checks to other MTAs and each of those MTAs and *poof*, victim.com's bandwidth is gone. With the indirect attack, the spammer/cracker is using other, legitimate, MTAs to hide the source of the attack. The victim can't tell the IP addresses of the zombie machines being used, nor can the victim even tell which domain is hosting the malicious SPF records. The other MTAs that are being used may not be experiencing an unusual load or traffic pattern and will probably do nothing to stop the attack. DNS caching actually helps the attacker. The malicious SPF records can have long TTLs. The malicious SPF record can easily cause NXDOMAIN results from the victim's name server, which rarely has a long TTL. The attacker doesn't need to send actual email, many systems will do the SPF checks before the DATA command, so using SMTP pipelining, a single TCP packet can contain many MAIL FROM/RCPT TO/RSET sequences. Ok, after having all these evil ideas of how to abuse SPF, several months ago I sat down and actually tried constructing them. I found that, in practice, it was a lot harder to make an effective attack than I thought. The amount of bandwidth consumed by the SMTP sessions and DNS lookups on the spammer/crackers system is not going to be that much less than the bandwidth generated by the SPF checks being sent to the victim. In particular, I had a hard time getting DNS requests made via TCP to be cached, I found that bind had problems with name compression on several of the more "interesting" malicious SPF records, and in general, name servers consipired to make malicious SPF records less useful. ;-> I hate doing handwaving here, but as I mentioned above, I can't find my numbers from when I did these tests. My conclusion is that the SPF spec *really* needs to have some tighter processing specs added. I sent patches to the spec of to Meng, but they were not included in the most recent version. Once the processing limits get tightened up, I think SPF is in pretty good shape, but more eyes checking this would be better. (Again, thanks to John Levine for doing real research.) For those that want to see the malicous SPF records, dig around in megamx.midwestcs.com, dos.midwestcs.com, dosredirect.midwestcs.com, dosinc.midwestcs.com, and dosexists.midwestcs.com. -wayne From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 02:33:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23248 for ; Wed, 30 Jun 2004 02:33:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5U6DTW8093369; Tue, 29 Jun 2004 23:13:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5U6DTr1093368; Tue, 29 Jun 2004 23:13:29 -0700 (PDT) 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.9) with ESMTP id i5U6DSxb093337 for ; Tue, 29 Jun 2004 23:13:28 -0700 (PDT) (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.34) id 1BfYLa-0004rZ-NJ for ietf-mxcomp@imc.org; Wed, 30 Jun 2004 01:13:35 -0500 To: "IETF MARID WG" References: <700EEF5641B7E247AC1C9B82C05D125DA8F0@srv1.pan-am.ca> From: wayne Reply-To: "IETF MARID WG" Date: Wed, 30 Jun 2004 01:13:30 -0500 In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125DA8F0@srv1.pan-am.ca> (Gordon Fecyk's message of "Tue, 29 Jun 2004 22:03:31 -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 (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: How fragile is SPF ? Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.3 required=4.0 tests=AWL,BAYES_00,GREYLIST_ISWHITE autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <700EEF5641B7E247AC1C9B82C05D125DA8F0@srv1.pan-am.ca> "Gordon Fecyk" writes: > Actually, by this time AOL, altavista.com etc must have some hard data on its > effects. It's been at least four months. Numbers, anyone? Hi. In a private email to John Levine, I promised him I would dig up some data on this. I'm afraid that I have not gotten enough data to be very useful yet, I'm still twisting some arms to see if I can get more. Thank you Hector for coming forward with some data. It was useful. -wayne From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 02:53:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26292 for ; Wed, 30 Jun 2004 02:53:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5U6hZcP005326; Tue, 29 Jun 2004 23:43:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5U6hZW0005325; Tue, 29 Jun 2004 23:43:35 -0700 (PDT) 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.9) with ESMTP id i5U6hZdG005314 for ; Tue, 29 Jun 2004 23:43:35 -0700 (PDT) (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 B38C2132D32 for ; Wed, 30 Jun 2004 02:43:33 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 85B0F650; Wed, 30 Jun 2004 02:43:33 -0400 (EDT) Date: Wed, 30 Jun 2004 02:43:33 -0400 From: Meng Weng Wong To: IETF MARID WG Subject: adding overall timeouts Message-ID: <20040630064333.GU13225@dumbo.pobox.com> References: <20040630023505.28233.qmail@xuxa.iecc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Jun 29, 2004 at 11:32:10PM -0500, wayne wrote: | | The Caller-ID spec has a codified time limit. My suggestion to Meng | to add one to the SPF spec got dropped. I think it needs one really | needs to be added. | OK, how about: If an SPF evaluation fails to resolve an answer within 20 seconds, processing SHOULD abort and return the "error" result. From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 02:53:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26317 for ; Wed, 30 Jun 2004 02:53:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5U6mK65007065; Tue, 29 Jun 2004 23:48:20 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5U6mK3S007064; Tue, 29 Jun 2004 23:48:20 -0700 (PDT) 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.9) with ESMTP id i5U6mJIb007053 for ; Tue, 29 Jun 2004 23:48:19 -0700 (PDT) (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 43D08132D32; Wed, 30 Jun 2004 02:48:18 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id EE16A650; Wed, 30 Jun 2004 02:48:18 -0400 (EDT) Date: Wed, 30 Jun 2004 02:48:18 -0400 From: Meng Weng Wong To: Gordon Fecyk Cc: ietf-mxcomp@imc.org Subject: the hypothetical "spammers will forge TCP SMTP streams" Message-ID: <20040630064818.GV13225@dumbo.pobox.com> References: <700EEF5641B7E247AC1C9B82C05D125DA8EE@srv1.pan-am.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125DA8EE@srv1.pan-am.ca> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Jun 29, 2004 at 07:33:15PM -0500, Gordon Fecyk wrote: | | And when MARID records begin to appear on my domain you're going to know | where my authorized SMTP clients will be. So what? None of those IPs or | hostnames are yours and unless you r00t my boxes they never will be. | Speaking of which, did anyone ever take you up on the offer to forge enough of a TCP sequence to inject mail into your servers? I think that offer's been on the table for more than a year now. From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 03:02:05 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26736 for ; Wed, 30 Jun 2004 03:02:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5U6rxAG008770; Tue, 29 Jun 2004 23:53:59 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5U6rxxm008769; Tue, 29 Jun 2004 23:53:59 -0700 (PDT) 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.9) with ESMTP id i5U6rw2H008758 for ; Tue, 29 Jun 2004 23:53:58 -0700 (PDT) (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 B362D132D71 for ; Wed, 30 Jun 2004 02:53:57 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 808A6650; Wed, 30 Jun 2004 02:53:57 -0400 (EDT) Date: Wed, 30 Jun 2004 02:53:57 -0400 From: Meng Weng Wong To: ietf-mxcomp@imc.org Subject: Re: DDOS attacks Message-ID: <20040630065357.GW13225@dumbo.pobox.com> References: <700EEF5641B7E247AC1C9B82C05D125DA8EE@srv1.pan-am.ca> <16610.4018.1181.232165@giles.gnomon.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16610.4018.1181.232165@giles.gnomon.org.uk> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Jun 30, 2004 at 01:56:18AM +0100, Roy Badami wrote: | | Spammers, hackers and organized crime gangs are very much working | together. People running blacklists are getting targetted by large | scale DDoS attacks in an attempt to get them to give up, and several | prominent blacklists have shut down over the past year because they | couldn't cope. All but the largest ISP's are now I suspect likely to | be unwilling to host a customer that runs a high profile blacklist, | because they know that they can't cope with the inevitable DDoS | attacks. | It seems to me that all the bad guys, put together, collectively control more CPU power and more bandwidth than all the good guys put together. We are besieged. It is no wonder we are transitioning to "assumed guilty unless proven innocent". Other appropriate models include an immune system design, in which complex organisms constantly fend off disease. In that model, it is imperative that the complex organisms keep adapting and differentiating. We, the good guys, need faster and more diverse ways to respond to threats. The commercial antispam and antivirus guys have got it right. The open community do too, with frequent releases of SpamAssassin. Our standards processes need to come up to speed as well. From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 05:58:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05671 for ; Wed, 30 Jun 2004 05:58:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5U9gF90070475; Wed, 30 Jun 2004 02:42:15 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5U9gFAK070473; Wed, 30 Jun 2004 02:42:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gold.csi.cam.ac.uk (gold.csi.cam.ac.uk [131.111.8.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5U9gEF5070461 for ; Wed, 30 Jun 2004 02:42:14 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]) by gold.csi.cam.ac.uk with esmtp (Exim 4.20) id 1BfbbP-00033K-Ri for ietf-mxcomp@imc.org; Wed, 30 Jun 2004 10:42:03 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1BfbbN-0007Q5-CF; Wed, 30 Jun 2004 10:42:01 +0100 Date: Wed, 30 Jun 2004 10:42:01 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Matthew Elvey cc: MARID Subject: Re: Unified SPF overlaps with CSV In-Reply-To: <40E1F6AB.9050109@elvey.com> Message-ID: References: <1088527917.4998.117.camel@ddev.mail-abuse.org> <11967678.1088509187@Ryoga.corp.sgi.com> <1088544618.4998.249.camel@ddev.mail-abuse.org> <40E1F6AB.9050109@elvey.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 29 Jun 2004, Matthew Elvey wrote: > > Here's an example: there is no MTA that does a HELO elvey.com. Mail from > users at elvey.com is sent through (among others) rr.com and fastmail.fm. > rr.com and fastmail.fm will have to publish CSV records, but elvey.com won't. You would probably want to populate your zone with negative CSV records to ensure that all hosts are explicitly unauthorized to use your domain, rather than neither authorized not unauthorized. Tony. -- f.a.n.finch http://dotat.at/ SOUTHEAST FITZROY: NORTH OR NORTHWEST 4 OR 5, OCCASIONALLY 6 IN EAST. FAIR. MAINLY GOOD. From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 06:18:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06216 for ; Wed, 30 Jun 2004 06:18:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UA5JlD079504; Wed, 30 Jun 2004 03:05:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UA5Jak079503; Wed, 30 Jun 2004 03:05:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from purple.csi.cam.ac.uk (purple.csi.cam.ac.uk [131.111.8.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UA5I65079490 for ; Wed, 30 Jun 2004 03:05:18 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]) by purple.csi.cam.ac.uk with esmtp (Exim 4.20) id 1Bfbxq-0005Ox-K9 for ietf-mxcomp@imc.org; Wed, 30 Jun 2004 11:05:14 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk with local-esmtp (Exim 4.34) id 1Bfbxq-0001Cf-FY; Wed, 30 Jun 2004 11:05:14 +0100 Date: Wed, 30 Jun 2004 11:05:14 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Roy Badami cc: MARID Subject: Re: Sender ID and CSV are complimentary (long - sorry) (was: Unified SPF overlaps with CSV) In-Reply-To: <16610.819.43313.16270@giles.gnomon.org.uk> Message-ID: References: <1088527917.4998.117.camel@ddev.mail-abuse.org> <11967678.1088509187@Ryoga.corp.sgi.com> <1088544618.4998.249.camel@ddev.mail-abuse.org> <16610.819.43313.16270@giles.gnomon.org.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 30 Jun 2004, Roy Badami wrote: > > Based on the above, which I realize might involve a misunderstanding > of one or both proposals, it seems to me that Sender ID and CSV > attempt to tackly essentially unrelated subproblems within the MARID > problem space. > > I think a lot of the confusion in this and other threads stems from > the fact that the two proposals tackle different subproblems, and many > WG participants are essentially focussed on just one of them. I think the reason for this confusion is the layering confusion in designated sender schemes. CSV is purely focussed on authenticating the SMTP client, and only checks a single hop of the multi-hop message path; it doesn't attempt to deal with end-to-end authenticity. Designated sender schemes aim to check that the message was sent by the purported sender (which is an end-to-end property, not hop-by-hop) but it does this by checking the last hop, not by checking the original end-point. If you're focussing on the last hop the two schemes can appear to be doing the same thing, but you can see they are not by considering the layers. Tony. -- f.a.n.finch http://dotat.at/ MALIN HEBRIDES: SOUTH OR SOUTHWEST 4 OR 5, OCCASIONALLY 6. RAIN IN EAST AT FIRST, OTHERWISE SQUALLY SHOWERS. MODERATE OR GOOD. From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 09:54:09 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17577 for ; Wed, 30 Jun 2004 09:54:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UDbnWg099176; Wed, 30 Jun 2004 06:37:49 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UDbnv0099175; Wed, 30 Jun 2004 06:37:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gfimalta.com ([194.204.113.148]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UDbkrE099162 for ; Wed, 30 Jun 2004 06:37:47 -0700 (PDT) (envelope-from mengwong@dumbo.pobox.com) Received: from mailgate.gfifax.com ([10.130.130.110]) by gfimalta.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 30 Jun 2004 15:38:01 +0200 Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Wed, 30 Jun 2004 15:32:00 +0200 Received: from server1.gfi.com ([209.61.184.105]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 30 Jun 2004 09:38:50 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 29 Jun 2004 17:26:39 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TFBXWi095846; Tue, 29 Jun 2004 08:11:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5TFBX02095845; Tue, 29 Jun 2004 08:11:33 -0700 (PDT) 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.9) with ESMTP id i5TFBW3f095838 for ; Tue, 29 Jun 2004 08:11:32 -0700 (PDT) (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 C1AC1132D01; Tue, 29 Jun 2004 11:11:29 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 5FF9663A; Tue, 29 Jun 2004 11:11:29 -0400 (EDT) Date: Tue, 29 Jun 2004 11:11:29 -0400 From: Meng Weng Wong To: John Leslie Cc: ietf-mxcomp@imc.org Subject: Unified SPF overlaps with CSV Message-ID: <20040629151129.GT13225@dumbo.pobox.com> References: <20040629142750.GU3747@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040629142750.GU3747@verdi> User-Agent: Mutt/1.3.25i List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 29 Jun 2004 15:26:39.0374 (UTC) FILETIME=[791C32E0:01C45DED] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Jun 29, 2004 at 10:27:50AM -0400, John Leslie wrote: | | The short answer, of course, is the empty list. CSV does not seek to | change how email is done. It does not seek to say anything must be done | differently. (This is why we see it as orthogonal to SPF.) To provide clarity, can you explain if by the above "SPF" you mean "Unified SPF" or "SPF Classic"? "Unified SPF" always examines the HELO domain, offers an authentication status, and gives receivers an opportunity to perform whitelisting or rejection operations based on that result. It does this independent of examination of the return-path or the PRA. "SPF Classic" by comparison only performs spoof detection on the HELO name, and always checks the return-path. Unified SPF even solves the forwarding problem by allowing a receiver site to whitelist forwarders by HELO name, overriding the return-path result. It appears to me that the set of features offered by Unified SPF overlaps with the features offered by CSV. Please correct me if I'm wrong; my understanding of CSV is obviously not as good as yours :) | Operators of MTAs are free to change nothing; and things will work | about as well as they do now -- until spammers escalate things so that | overly-broad IP blacklists are applied widely and the MTA's IP address | finds its way onto them. Possibly, they'll even be miraculously lucky | and its IP address _won't_ find its way onto any blacklist. ;^) The above is also true of Unified SPF. | If/when they get caught by that kind of problem, they need to ensure | that the EHLO string the MTA uses is a legal domain name (which it | should be already; but I did say _no_ changes were necessary), and that | they can cause a simple SRV record to be placed under that domain. The above is also true of Unified SPF, except that the record is the SPF TXT or MARID record. | We advise MTA operators not to wait for problems to show up, but | to place the SRV record quickly, to show that they acknowledge | responsibility for the actions of that MTA, and place PTR records | for a few average-or-better accreditation services as well. The above is also true of Unified SPF. | The syntax of the SRV record is remarkably simple: you have the | "target" name, which will be the same as the EHLO string, plus two | bits of information, which for the vast majority of cases should be | set to authorized=yes and list-empty=no. The syntax of the SPF record for the MTA is TXT "v=spf1 a -all". | And let us not forget the rather significant number of individuals | who already find themselves paralyzed by IP blacklists: they can | place the SRV and PTR records, demonstrating full accountability and | good reputation; and make a convincing case that any receiving SMTP | server that now blacklists them (perhaps because they're using a | cable provider) can simply implement CSV and stop having to respond | to complaints. ;^) Yes, it would be a great benefit to the wrongly-blacklisted folks if they could positively accept responsibility at the HELO or return-path levels and thereby override provider-based negativity. This argument is made at http://spf.pobox.com/slides/unified%20spf/0429.html if we replace "MTAMark=no" with "listed on DUL blacklist". cheers menmg From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 09:54:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17637 for ; Wed, 30 Jun 2004 09:54:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UDhGcv099725; Wed, 30 Jun 2004 06:43:16 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UDhGsU099724; Wed, 30 Jun 2004 06:43:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gfimalta.com ([194.204.113.148]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UDhEmO099717 for ; Wed, 30 Jun 2004 06:43:15 -0700 (PDT) (envelope-from Valdis.Kletnieks@vt.edu) Received: from mailgate.gfifax.com ([10.130.130.110]) by gfimalta.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 30 Jun 2004 15:44:22 +0200 Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Wed, 30 Jun 2004 15:30:57 +0200 Received: from server1.gfi.com ([209.61.184.105]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 30 Jun 2004 09:31:17 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 29 Jun 2004 21:43:16 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TJXoIa018212; Tue, 29 Jun 2004 12:33:50 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5TJXocs018211; Tue, 29 Jun 2004 12:33:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from turing-police.cirt.vt.edu (IDENT:root@turing-police.cirt.vt.edu [128.173.54.129]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TJXnjh018204 for ; Tue, 29 Jun 2004 12:33:49 -0700 (PDT) (envelope-from Valdis.Kletnieks@vt.edu) Received: from turing-police.cc.vt.edu (IDENT:valdis@turing-police.cc.vt.edu [127.0.0.1]) by turing-police.cc.vt.edu (8.13.0/8.13.0) with ESMTP id i5TJXnog012675; Tue, 29 Jun 2004 15:33:49 -0400 Message-Id: <200406291933.i5TJXnog012675@turing-police.cc.vt.edu> X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4+dev To: Greg Connor Cc: "'IETF MARID WG'" Subject: Re: Will SPF/Unified SPF/SenderID bring down the 'net? In-Reply-To: Your message of "Mon, 28 Jun 2004 22:06:48 PDT." From: Valdis.Kletnieks@vt.edu References: Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1928819899P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Tue, 29 Jun 2004 15:33:49 -0400 List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 29 Jun 2004 19:43:16.0204 (UTC) FILETIME=[525602C0:01C45E11] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --==_Exmh_1928819899P Content-Type: text/plain; charset=us-ascii On Mon, 28 Jun 2004 22:06:48 PDT, Greg Connor said: > everybody. Furthermore, the spammer is exposing his own IP during the attack > so he should be blocked quickly. OK... I admit I tuned in late... but somehow, it's rather surreal to see "We have their IP so they should be blocked quickly" as a justification. In what way will they be "blocked quickly"? And how will this be an improvement over the blazing speed we currently see on shutting down spam-spewing zombies that we know the IP address of? --==_Exmh_1928819899P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQFA4cQdcC3lWbTT17ARArb1AJwJbc0Yu1EkjcijqIvSbHUUSZwcLgCg2QlA xLt58O6Y/3VhKdDfeNl01lE= =Sn+7 -----END PGP SIGNATURE----- --==_Exmh_1928819899P-- From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 10:45:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21491 for ; Wed, 30 Jun 2004 10:45:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UESipa003397; Wed, 30 Jun 2004 07:28:44 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UESilo003396; Wed, 30 Jun 2004 07:28:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UESiUe003390 for ; Wed, 30 Jun 2004 07:28:44 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.0.1.153] ([::ffff:64.83.8.178]) (AUTH: LOGIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Wed, 30 Jun 2004 10:28:44 -0400 id 0005C550.40E2CE1C.000045E7 Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: MARID WG From: Andrew Newton Subject: Differences between CSV and Sender-ID Date: Wed, 30 Jun 2004 10:28:41 -0400 X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I have been observing that the recent discussion on CSV in comparison to the SPF/Sender-ID solutions have been between a small, consistent subset of the participants of this mailing list. I can only conclude that others either do not care about these issues or do not understand these issues. After reading every single message over the past couple of threads, I must admit that I do not comprehend many of the points. Therefore, I'd like to get feedback from others: Do you appreciate the difference between a HELO check vs. a MAILFROM/PRA/SUBMITTER check? Do you understand the semantic differences between a CSV check on HELO and an SPF/Sender-ID check on HELO? Is it clear to you that CSV has definite security advantages over SPF/Sender-ID? I'm only asking these questions so that we can hopefully refine the conversation on this topic. -andy From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 11:16:41 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23410 for ; Wed, 30 Jun 2004 11:16:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UEvfCN005224; Wed, 30 Jun 2004 07:57:41 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UEvfuh005223; Wed, 30 Jun 2004 07:57:41 -0700 (PDT) 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.9) with ESMTP id i5UEve8I005217 for ; Wed, 30 Jun 2004 07:57:40 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXC04.vcorp.ad.vrsn.com ([65.205.251.33]) by pigeon.verisign.com (8.12.10/) with ESMTP id i5UEvh0b006495 for ; Wed, 30 Jun 2004 07:57:43 -0700 Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 30 Jun 2004 07:57:09 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'IETF MARID WG'" Subject: RE: DDoS attacks via SPF Date: Wed, 30 Jun 2004 07:57:08 -0700 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: Could weplease reframe this debate? We are discussing attacks on FEATURES of spf. These are not core features by a long way. I suggest that we adopt a set of rules that assure convergence of the series rather that divergence. What I suggest is that a rule with a high divergence potential cannot reference a second such rule. So we can have the following sequence: Example.com. Expand by mail username part Marketing@example.com Pointer to constant.com Constant.com list of ip addresses I still want to kill that macro language. Factored records may have a value but I would like to see them constrained heavily. -----Original Message----- From: wayne [mailto:wayne@midwestcs.com] Sent: Tue Jun 29 23:36:42 2004 To: IETF MARID WG Subject: DDoS attacks via SPF The subject of using SPF to create DDoS attacks is not new. For example, I raised this subject back in December on this thread: http://archives.listbox.com/spf-discuss@v2.listbox.com/200312/0393.html A while back, I took a look at this subject in detail. Sadly, I failed to record all my numbers, so I'm going to have to recreate them if I want to publish them. :-< The conclusion I came to was: The current SPF system is pretty resistant to DoS attacks, but I think the SPF spec needs to have a lot more limits placed on the processing in order to really prevent most abuse. The goal doesn't need to be that SPF can never be abused in any way, just that it is easier and more useful to use other techniques to be abusive. It's kind of like it not being important that you can out-run a lion, just that you can out-run the other people in your safari. Most of the discussions so far have been about a spammer/cracker attacking someone directly using a malicous SPF record. That is, a malicious SPF record is created, then email is sent to the victim's MTA and the processing of the SPF record will cause problems for the victim. I think this is not a huge concern. Reasonable limits can be placed on the processing of SPF records and the victim can adapt when this kind of attack is happening. The much more serious problem, in my opinion, is using SPF to indirectly attack someone. A spammer/cracker could create a malicious SPF record that causes DNS traffic to be directed to the victim when email is sent to *other* MTAs. This is the scenerio outlined in my post from last December. Evil.com creates a record that causes many DNS lookups to be done against victim.com's name server. Evil.com then sends many SMTP commands that cause SPF checks to other MTAs and each of those MTAs and *poof*, victim.com's bandwidth is gone. With the indirect attack, the spammer/cracker is using other, legitimate, MTAs to hide the source of the attack. The victim can't tell the IP addresses of the zombie machines being used, nor can the victim even tell which domain is hosting the malicious SPF records. The other MTAs that are being used may not be experiencing an unusual load or traffic pattern and will probably do nothing to stop the attack. DNS caching actually helps the attacker. The malicious SPF records can have long TTLs. The malicious SPF record can easily cause NXDOMAIN results from the victim's name server, which rarely has a long TTL. The attacker doesn't need to send actual email, many systems will do the SPF checks before the DATA command, so using SMTP pipelining, a single TCP packet can contain many MAIL FROM/RCPT TO/RSET sequences. Ok, after having all these evil ideas of how to abuse SPF, several months ago I sat down and actually tried constructing them. I found that, in practice, it was a lot harder to make an effective attack than I thought. The amount of bandwidth consumed by the SMTP sessions and DNS lookups on the spammer/crackers system is not going to be that much less than the bandwidth generated by the SPF checks being sent to the victim. In particular, I had a hard time getting DNS requests made via TCP to be cached, I found that bind had problems with name compression on several of the more "interesting" malicious SPF records, and in general, name servers consipired to make malicious SPF records less useful. ;-> I hate doing handwaving here, but as I mentioned above, I can't find my numbers from when I did these tests. My conclusion is that the SPF spec *really* needs to have some tighter processing specs added. I sent patches to the spec of to Meng, but they were not included in the most recent version. Once the processing limits get tightened up, I think SPF is in pretty good shape, but more eyes checking this would be better. (Again, thanks to John Levine for doing real research.) For those that want to see the malicous SPF records, dig around in megamx.midwestcs.com, dos.midwestcs.com, dosredirect.midwestcs.com, dosinc.midwestcs.com, and dosexists.midwestcs.com. -wayne From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 11:44:28 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24735 for ; Wed, 30 Jun 2004 11:44:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UFVl9m008645; Wed, 30 Jun 2004 08:31:47 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UFVlab008644; Wed, 30 Jun 2004 08:31:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from svrmail.roving.com (SVRMAIL.roving.com [208.198.98.29]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UFVk4a008620 for ; Wed, 30 Jun 2004 08:31:47 -0700 (PDT) (envelope-from molson@constantcontact.com) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Differences between CSV and Sender-ID Date: Wed, 30 Jun 2004 11:31:42 -0400 Message-ID: <3B7C31950DEB8445B24D3FDF991E81BBD79B@CORPMAIL1.roving.com> Thread-Topic: Differences between CSV and Sender-ID Thread-Index: AcRerxS/fbqQmGPQTuG6OfTrbrlmvQABupDw From: "Olson, Margaret" To: "Andrew Newton" , "MARID WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5UFVl4a008639 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of Andrew Newton > Do you appreciate the difference between a HELO check vs. a > MAILFROM/PRA/SUBMITTER check? Yes > Do you understand the semantic differences between a CSV check on > HELO and an SPF/Sender-ID check on HELO? No. I have found this thread very muddled and difficult to follow. As far as I can tell this has not been stated clearly. > Is it clear to you that CSV has definite security advantages over > SPF/Sender-ID? No. In general it would be helpful if semantics and requirements for semantics were explored prior to discussions of syntax or encoding. Margaret. From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 11:49:44 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24902 for ; Wed, 30 Jun 2004 11:49:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UFc4i8009154; Wed, 30 Jun 2004 08:38:04 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UFc4UA009149; Wed, 30 Jun 2004 08:38:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gfimalta.com ([194.204.113.148]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UFc2VZ009121 for ; Wed, 30 Jun 2004 08:38:03 -0700 (PDT) (envelope-from gconnor@nekodojo.org) Received: from mailgate.gfifax.com ([10.130.130.110]) by gfimalta.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 30 Jun 2004 17:39:07 +0200 Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Wed, 30 Jun 2004 17:27:38 +0200 Received: from server1.gfi.com ([209.61.184.105]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 30 Jun 2004 09:35:11 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 29 Jun 2004 20:53:40 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TIdiDx014277; Tue, 29 Jun 2004 11:39:44 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5TIdiX6014276; Tue, 29 Jun 2004 11:39:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [64.139.47.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TIdiAf014270 for ; Tue, 29 Jun 2004 11:39:44 -0700 (PDT) (envelope-from gconnor@nekodojo.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by neko-base.nekodojo.org (Postfix) with ESMTP id BDD4D1D651; Tue, 29 Jun 2004 11:39:45 -0700 (PDT) Date: Tue, 29 Jun 2004 11:39:47 -0700 From: Greg Connor To: Douglas Otis Cc: MARID Subject: Re: Unified SPF overlaps with CSV Message-ID: <11967678.1088509187@Ryoga.corp.sgi.com> In-Reply-To: <1088527917.4998.117.camel@ddev.mail-abuse.org> References: <1088527917.4998.117.camel@ddev.mail-abuse.org> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 29 Jun 2004 18:53:41.0026 (UTC) FILETIME=[64FDE020:01C45E0A] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --Douglas Otis wrote: >> | Operators of MTAs are free to change nothing; and things will work >> | about as well as they do now -- until spammers escalate things so that >> | overly-broad IP blacklists are applied widely and the MTA's IP address >> | finds its way onto them. Possibly, they'll even be miraculously lucky >> | and its IP address _won't_ find its way onto any blacklist. ;^) >> >> The above is also true of Unified SPF. > > The major problems result from weak transversal authorization determined > by SPF. You may consider these the same, but the details entailing such > is important. ACCREDITATION can not be administered if the > Authentication and Authorization are not confirmed for unknown, in > addition to that determined to be accepted. It is apparent that SPF > only provides weak path assurance regarding an accepted message. The > assurances for either unknown or rejected messages are nil. That is a > huge category left open. Doug- I couldn't understand this paragraph, and I think it's important to understand what you're saying here -- some of the keywords suggest that you feel it's an important point. Here are some followup questions. Q. What is a "transversal authorization?" What makes one weak vs. strong? Q. Regarding this sentence, I couldn't quite unwind what you meant, though I am probably close to understanding: > ACCREDITATION can not be administered if the > Authentication and Authorization are not confirmed for unknown, in > addition to that determined to be accepted. I understand this to mean "If the result is "unknown" then accreditation cannot be applied. I would take that as a given, but I believe that is the same with both SPF and CSV. Is this meant to imply that the existence of an "unknown" state itself is a defect? If I understand correctly, CSV also has an "unknown" state. In both proposals, I believe the domain owner has to make sure a PASS or "known good" result is received before honoring any accreditation, right? Anyway, let me know if you meant something else here that I am not understanding. Q. Regarding these two sentences, please clarify: > It is apparent that SPF > only provides weak path assurance regarding an accepted message. The > assurances for either unknown or rejected messages are nil. That is a > huge category left open. Is this meant to state that a CSV "authorized" result is stronger than an SPF PASS result? Why do you say that? Both are comparing an IP address to a DNS record, and in that regard seem to provide very similar features from the technical side. Do you mean that there is a difference in how the records will be interpreted by users? Is it because of the way the drafts are written? I'm trying to understand if it is a difference in the design, or just in how it is used by implementors and explained to users... Also what do you mean by "The assurances for either unknown or rejected messages are nil". What assurance does CSV provide if the status is unknown? If the status is reject/fail, doesn't that mean reject the message, and isn't the "strength" of that assertion the same for both SPF and CSV? Thanks gregc -- Greg Connor From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 11:52:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25638 for ; Wed, 30 Jun 2004 11:52:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UFdvix009550; Wed, 30 Jun 2004 08:39:57 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UFdvcN009549; Wed, 30 Jun 2004 08:39:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gfimalta.com ([194.204.113.148]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UFdtwB009543 for ; Wed, 30 Jun 2004 08:39:55 -0700 (PDT) (envelope-from wayne@midwestcs.com) Received: from mailgate.gfifax.com ([10.130.130.110]) by gfimalta.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 30 Jun 2004 17:41:03 +0200 Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Wed, 30 Jun 2004 17:27:36 +0200 Received: from server1.gfi.com ([209.61.184.105]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 30 Jun 2004 09:27:51 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 30 Jun 2004 08:19:47 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5U6DTW8093369; Tue, 29 Jun 2004 23:13:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5U6DTr1093368; Tue, 29 Jun 2004 23:13:29 -0700 (PDT) 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.9) with ESMTP id i5U6DSxb093337 for ; Tue, 29 Jun 2004 23:13:28 -0700 (PDT) (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.34) id 1BfYLa-0004rZ-NJ for ietf-mxcomp@imc.org; Wed, 30 Jun 2004 01:13:35 -0500 To: "IETF MARID WG" References: <700EEF5641B7E247AC1C9B82C05D125DA8F0@srv1.pan-am.ca> From: wayne Reply-To: "IETF MARID WG" Date: Wed, 30 Jun 2004 01:13:30 -0500 In-Reply-To: <700EEF5641B7E247AC1C9B82C05D125DA8F0@srv1.pan-am.ca> (Gordon Fecyk's message of "Tue, 29 Jun 2004 22:03:31 -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 (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: How fragile is SPF ? Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.3 required=4.0 tests=AWL,BAYES_00,GREYLIST_ISWHITE autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 30 Jun 2004 06:19:47.0470 (UTC) FILETIME=[3E1ABAE0:01C45E6A] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <700EEF5641B7E247AC1C9B82C05D125DA8F0@srv1.pan-am.ca> "Gordon Fecyk" writes: > Actually, by this time AOL, altavista.com etc must have some hard data on its > effects. It's been at least four months. Numbers, anyone? Hi. In a private email to John Levine, I promised him I would dig up some data on this. I'm afraid that I have not gotten enough data to be very useful yet, I'm still twisting some arms to see if I can get more. Thank you Hector for coming forward with some data. It was useful. -wayne From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 12:15:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26848 for ; Wed, 30 Jun 2004 12:15:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UFxEPJ011663; Wed, 30 Jun 2004 08:59:14 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UFxELR011662; Wed, 30 Jun 2004 08:59:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gfimalta.com ([194.204.113.148]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UFxCZd011654 for ; Wed, 30 Jun 2004 08:59:13 -0700 (PDT) (envelope-from andy@hxr.us) Received: from mailgate.gfifax.com ([10.130.130.110]) by gfimalta.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 30 Jun 2004 18:00:21 +0200 Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Wed, 30 Jun 2004 17:27:16 +0200 Received: from server1.gfi.com ([209.61.184.105]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 30 Jun 2004 09:19:17 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 30 Jun 2004 04:00:38 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5U1ljT8043110; Tue, 29 Jun 2004 18:47:45 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5U1ljqD043109; Tue, 29 Jun 2004 18:47:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5U1lfpU043102 for ; Tue, 29 Jun 2004 18:47:45 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.0.1.153] ([::ffff:64.83.8.178]) (AUTH: LOGIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Tue, 29 Jun 2004 21:47:45 -0400 id 0005C581.40E21BC1.00007BC3 In-Reply-To: <16610.819.43313.16270@giles.gnomon.org.uk> References: <1088527917.4998.117.camel@ddev.mail-abuse.org> <11967678.1088509187@Ryoga.corp.sgi.com> <1088544618.4998.249.camel@ddev.mail-abuse.org> <16610.819.43313.16270@giles.gnomon.org.uk> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <79F4B58C-CA37-11D8-883C-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: MARID From: Andrew Newton Subject: Re: Sender ID and CSV are complimentary (long - sorry) (was: Unified SPF overlaps with CSV) Date: Tue, 29 Jun 2004 21:47:42 -0400 To: Roy Badami X-Mailer: Apple Mail (2.618) List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 30 Jun 2004 02:00:38.0672 (UTC) FILETIME=[0A4C7100:01C45E46] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jun 29, 2004, at 8:02 PM, Roy Badami wrote: > Granted the fact that it's a > well run MTA doesn't prove that forged messages or spam won't pass > through it, but in the world we live in a very small proportion of > unwanted mail is originated from well-run MTAs, so reputation at that > level certainly seems valuable. I have in my notes an interesting tidbit from the MAAWG meeting in DC: Carl Hutzler of AOL said that >70% of spam comes through the mail servers of ISPs. -andy From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 12:17:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26927 for ; Wed, 30 Jun 2004 12:17:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UG36wG011995; Wed, 30 Jun 2004 09:03:06 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UG36sK011994; Wed, 30 Jun 2004 09:03:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gfimalta.com ([194.204.113.148]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UG34FV011987 for ; Wed, 30 Jun 2004 09:03:05 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: from mailgate.gfifax.com ([10.130.130.110]) by gfimalta.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 30 Jun 2004 18:04:08 +0200 Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Wed, 30 Jun 2004 17:27:11 +0200 Received: from server1.gfi.com ([209.61.184.105]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 30 Jun 2004 09:40:27 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 30 Jun 2004 07:17:12 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5U58kAw060149; Tue, 29 Jun 2004 22:08:46 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5U58kb0060148; Tue, 29 Jun 2004 22:08:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (ftp.catinthebox.net [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5U58jDg060133 for ; Tue, 29 Jun 2004 22:08:46 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Wed, 30 Jun 2004 01:12:41 -0400 Received: from ([65.10.109.27]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 2383007610; Wed, 30 Jun 2004 01:12:38 -0400 Message-ID: <00de01c45e60$59147200$6401a8c0@hdev1> From: "Hector Santos" To: "Gordon Fecyk" , "IETF-MXCOMP" References: <700EEF5641B7E247AC1C9B82C05D125DA8F0@srv1.pan-am.ca> Subject: Re: How fragile is SPF ? Date: Wed, 30 Jun 2004 01:08:51 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 30 Jun 2004 05:17:12.0831 (UTC) FILETIME=[802A48F0:01C45E61] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Gordon Fecyk" To: Sent: Tuesday, June 29, 2004 11:03 PM Subject: RE: How fragile is SPF ? > Good old fashioned testing. > > Actually, by this time AOL, AltaVista.com etc must have some > hard data on its effects. It's been at least four months. > Numbers, anyone? > We have 7-8 months of operational experiences with stored logs. About 1000+ installations by this point. It was a low-key release. In the first few months I was collecting field tester logs to compare results. My own support system stats can be seen at http://www.winserver.com/antispam. I can zip up logs for anyone if you wish to run their own simulator or reporter. They are all very verbose and detailed. Here is my summary points on SPF and overhead issues. MARID can not be a complete open ended lookup system if only for one reason: There is no guarantee of an effective database availability. This is obviously the case during the early stages. But another more obvious reason is that most of the spam is going to be no result or NXDOMAIN. I see four (4) possible future scenarios for spammers when MARID is finally in place: 1) Spammer will comply - Good Spammer, CANSPAM compliant. 2) Spammer will ignore it - Question of legal status unknown. 3) Spammer will SPOOF SPF - Malicious illegal Entry - US ECPA violation 4) Spammers/hacker will overload it - obvious crime. Call the FBI! Of course, the benefit I (and most people) would be looking for is: 5) Spammers are reduced. (Go out of business? Stop trying?) So what I am seeing with my 7-8 months of accumulated data? I need to write some code to get these specific totals, but it is pretty obvious what the trend is. - Hardly any will comply. A few added legit SPF records. - By far, most will ignore it. - Some are spoofing SPF relaxed policy domains (see comment about Neutral/Softail) - 4-6 days with non-stop connections, reaching 100K or more per day. and finally when there were weeks or some patterns where the daily connections were on a down curve, it would PICK right up and by far, the totals were pretty steady in fact, there were weeks where the daily totals differ by less than 1% In the last few months, what have been a steady near 2500 daily total, it is now up to an average 5500 for the month of June. So does it reduce spammers? Unfortunately I can't say that it does, atleast not by what I see. But I believe most people were aware of this and realized the goal in any tools added to control it was to reduce the junk collected to a bare minimum or zilch. We have about a 90-94% rejection rate, so by far, the customer base is extremely happy. My main design work focused was to reduced any DNS lookup required and do add a 2821 rejection IP related concept that further reduced the need to do a final CBV check to see if the return address is acceptable. This might be out of scope but if we concern about SPF abuse and/or DNS overhead/attacks, etc, then it needs to stated that the SMTP servers need to do more to reduce the MARID/DNS requirement in the first place. Its that plain any simple and I believe 100% most implementators will finally see this one they get going with this, like I have. Our SMTP was pretty much a standard system like all others. Didn't have all the stuff it has now until we started to do all this extra checking with DNS. That is why I said it can't be such an open ended equation with the desire to provide the same results we are looking for. Something has to give and I do believe, eventually, others will see that (if not already). One thing SMTP developers can do is to first is to enforce SMTP compliancy. One simple check is the HELO syntax. Go figure, by doing a simple domain literal check, you can knock out 10-12% of the spammers! No DNS lookup required. Another easy item addresses the BULK spammers which is where I get most of my connections (and spam attacks). BULK Spammers need to optimize their throughput too. So they use dumb streaming SMTP clients, possible perl or php scripts that don't support multi-line responses. MARID operators should probably be adding ECPA/CAMSPAM or Local nation legal compliant System Policy statement at the Welcome/Greeting. Believe it or not, this will eliminate atleast 40% of these dumb bulk spammers. They can't handle the perfectly acceptable SMTP compliant Multi-Line Greeting. Have spammers learned? Well, I thought they would! But I continue to see it. I think we are giving more credit then they deserve. But someone brought up a good point. Once everyone applies this idea, then maybe spammers will adjust. I 100% agree, but isn't this good? We want spammers to change! Once they see what is going on, some will begin to make the effort to comply with other SPAM related efforts. Currently, they don't have the incentive to change. And the final SMTP improvement comes straight from RFC 2821 - "Section 3.3 Mail Transactions" should not be ignored. I believe one of the absence MARID parameters is RCPT TO. RCPT TO validation should be performed by SMTP. This saves us another 30-35% of DNS lookups requirements and it makes sense to do an RCPT TO validation. And it makes sense too! MARID is really only for an anonymous sender transactions for final destination mail. A route is by traditional SMTP standards allowed only for authenticated senders using traditional SMTP methods (SMTP AUTH, IP allow relay tables, POPB4SMTP). So for routed mail (RCPT TO is not local), authentication or trust is already required by SMTP thus nullifying any need for LMAP or DNS related sender validation. So doing more at SMTP will clearly reduce much of the MARID overhead related issues. Simply by following the above SMTP level advance checking, you can reduce atleast 70-75% of your MARID lookup needs. You can't ignore it or try to solve this using an open ended MARID/DNS lookup. As far as the SPF malicious abuse, there is not much you can do without following the specs. Of course, you implementation needs to be bug free of buffer exploits. But I have not seen any exploitation in these area, atleast not malicious. Ironically, I did see it from "real systems" in the form of not having a proper setup or just having big records. I seen one policy like so: v=spf1 x.y.0.0/32 +mx -all where the x.y is literally there. By overall, as far as SPF concerns for me there are 2 things: o Macro Expansion: if there is one SPF feature that standouts is the macro expansion thing. This was the last part implemented for us. This could be another argument against it that keeps it from being a straight forward easy implementation. i.e, new implementers who need to use a 3rd party solution as oppose to keeping it in house. So if there is one area that might not be done correctly when done in-house, it could be the macro expansion. o Softfail/Neutral This is what I see happening, however, not at high levels. If I was the author, I would of made it very clear in the SPF specification that the SoftFail/Neutral relaxed fallback should be viewed as a Temporary option with an inherent Expiration or Time Limit (i.e, 6 months?) In my opinion, this will probably be the one area a SPF spoofing spammer will make itself look compliant, but use a relaxed result policy. It also offers spammers a way to look at other SPF domains with relaxed policies. My recommendation is that a SPF client seeing a SoftFail/Neutral should record the first time usage of this record and then place a time limit on its continue usage. I see this softfail/neutral concept as something that starts a new specification with a loophole spammers can use. I understands the reasons for it, but it should be coupled with some enforcement expiration or time limit. AOL.COM should not be using it forever. At some point, they need to change that to a FAIL. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 12:17:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26970 for ; Wed, 30 Jun 2004 12:17:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UG2fl9011947; Wed, 30 Jun 2004 09:02:41 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UG2f1m011946; Wed, 30 Jun 2004 09:02:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gfimalta.com ([194.204.113.148]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UG2dIg011934 for ; Wed, 30 Jun 2004 09:02:40 -0700 (PDT) (envelope-from mengwong@dumbo.pobox.com) Received: from mailgate.gfifax.com ([10.130.130.110]) by gfimalta.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 30 Jun 2004 18:03:44 +0200 Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Wed, 30 Jun 2004 17:27:11 +0200 Received: from server1.gfi.com ([209.61.184.105]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 30 Jun 2004 09:33:20 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 29 Jun 2004 16:57:12 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5TEnOD6093519; Tue, 29 Jun 2004 07:49:24 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5TEnOvJ093518; Tue, 29 Jun 2004 07:49:24 -0700 (PDT) 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.9) with ESMTP id i5TEnN2Q093509 for ; Tue, 29 Jun 2004 07:49:23 -0700 (PDT) (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 9E51C132D00; Tue, 29 Jun 2004 10:49:23 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 551C9605; Tue, 29 Jun 2004 10:49:23 -0400 (EDT) Date: Tue, 29 Jun 2004 10:49:23 -0400 From: Meng Weng Wong To: ietf-mxcomp@imc.org Cc: John Leslie Subject: SPF vs CSV scenarios Message-ID: <20040629144923.GS13225@dumbo.pobox.com> References: <20040629142750.GU3747@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040629142750.GU3747@verdi> User-Agent: Mutt/1.3.25i List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 29 Jun 2004 14:57:12.0584 (UTC) FILETIME=[5C057080:01C45DE9] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Jun 29, 2004 at 10:27:50AM -0400, John Leslie wrote: | | Andy closed the jabber session with several action items: | ] | ] andy: We were given 3 use cases today. It would be good if meng could | ] take his 2 to the list, and jfenton his to the list. | ] andy: Then let's let the CSV proponents explain two things for each, | ] 1) how CSV handles them, and | ] 2) how SPF does not. | | I'm waiting on these. I was actually waiting for you to provide them. They were your cases. If you look at the following transcript, you'll see that I had to guess because you weren't telling. [15:41:24] (if jlc gets a spare moment, i'd like to ask for some detail on the use case where there's an actual problem between using an SPF record for the PRD and using an SPF record for EHLO, please) [15:42:11] meng, cts [15:42:40] uh, so, jlc or doug, can you set up a problem scenario? [15:42:44] [15:43:23] just thought maybe you guys had one in mind. [15:43:30] Quick answer on case with problem: workers at home using their cable system to send email for their work domain. [15:43:55] Meng, can you work with that? [15:44:14] lemme see what the EHLO and the MAIL FROM look like real quick. [15:44:38] (taking the MAIL FROM to be close enough to the PRA that SPF Classic and SenderID look the same in this case) [15:45:15] EHLO cable-12-23-34-56.cty.cableco.net? [15:45:20] [15:45:51] john? [15:45:54] Actually, it might be that, or the cable provider might force use of their server. [15:45:58] [15:46:07] ok, so we have two subcases ... [15:46:22] if the cable provider forces use of their server, we have EHLO mta4.cableco.net [15:46:28] MAIL FROM: [15:46:29] ? [15:46:33] [15:46:42] OK [15:46:58] so mta4.cableco.net has an SPF record, and work.com has an SPF record ... and ... ? [15:47:17] and the mta4.cableco.net SPF record is checked at EHLO time, and the work.com record is checked at MAIL FROM time ... [15:48:01] [15:48:10] What happens when mta4.cableco.net gets a bad reputation? [15:48:13] [15:48:28] then work.com has to set up port 587 with SMTP AUTH [15:49:01] if the mta4.cableco.net identity has a bad reputation, then it sucks for the mail sender whether the checks are being done with CSV or SPF, right? [15:50:21] these are two good use cases. perhaps flushing them out on the list is good. From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 12:26:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27326 for ; Wed, 30 Jun 2004 12:26:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UG4Hft012049; Wed, 30 Jun 2004 09:04:17 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UG4HGR012048; Wed, 30 Jun 2004 09:04:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from gfimalta.com ([194.204.113.148]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UG4Fo9012042 for ; Wed, 30 Jun 2004 09:04:16 -0700 (PDT) (envelope-from gordonf@pan-am.ca) Received: from mailgate.gfifax.com ([10.130.130.110]) by gfimalta.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 30 Jun 2004 18:05:24 +0200 Received: from mail pickup service by mailgate.gfifax.com with Microsoft SMTPSVC; Wed, 30 Jun 2004 17:27:09 +0200 Received: from server1.gfi.com ([209.61.184.105]) by mailgate.gfifax.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 30 Jun 2004 09:18:53 +0200 Received: from above.proper.com ([208.184.76.39]) by server1.gfi.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 30 Jun 2004 02:41:47 +0200 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5U0XDFf038718; Tue, 29 Jun 2004 17:33:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5U0XDJ0038717; Tue, 29 Jun 2004 17:33:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.pan-am.ca (205-200-6-46.static.mts.net [205.200.6.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5U0XBCL038711 for ; Tue, 29 Jun 2004 17:33:12 -0700 (PDT) (envelope-from gordonf@pan-am.ca) content-class: urn:content-classes:message Subject: RE: DDOS attacks MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 29 Jun 2004 19:33:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <700EEF5641B7E247AC1C9B82C05D125DA8EE@srv1.pan-am.ca> Thread-Topic: DDOS attacks Thread-Index: AcReLbLZiH0bqaneQdKBD8W91Ome+gACNl6Q From: "Gordon Fecyk" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5U0XCCL038712 List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 30 Jun 2004 00:41:48.0000 (UTC) FILETIME=[06992E00:01C45E3B] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > It seems to me the DDOS attacks we have reviewed so far > pretty much boil down to: > > SECURITY CONSIDERATIONS Looking at this from a purely administrative point, I question this entire e-mail. > We take it as a given that malicious entities control > large distributed networks of 0wned machines, in the six > to eight figure range. These machines are compromised > workstation-grade machines that belong to ordinary > end-users on broadband connections. They are generally > referred to as zombies. First and foremost, what can a pack of zombie machines do to this system that they can't already do to other systems? Flood e-mail? Perform repeated DNS lookups? Ping the hell out of mail servers or DNS servers? > The most elegant way to mount such an attack is to > contrive a scenario in which the technology itself plays a > part in the resulting denial of service. If the attack > does not affect those who do not adopt the technology, and > only hurts those who do adopt the technology, it gives > adopters incentive to abandon the technology. Such an > auto-targeting attack can be easily executed using zombie > networks. Al Capone of Cyberspace. "Don't even think of doing this or we'll hurt you." That's like telling me not to use Internet Explorer just because you know how to exploit flaws in it. Or Outlook. Or any other big name product or technology. Yet here I am sitting at my desk with the two most dangerous pieces of software on my computer running at the same time, without anti-virus software running even, and I'm not affected by the current garbage. Or the recent garbage. Or the earlier garbage. Or the garbage that is yet to come. So 180solutions knows how to install spyware behind peoples' backs. Big deal - doesn't work if the user can't install anything to begin with (such as on a 2K or XP box with a limited user). Steve Gibson preached to Microsoft pleading not to enable Raw Sockets support in Windows XP. His network was attacked as a result of his ranting - not with r00ted XP boxes exploting raw sockets - but with a plain and simple traffic flood. Yet he maintains TO THIS DAY that Microsoft doomed the Internet SOLELY because of this technology. Bugs and flaws in MARID are going to be the least of your worries when Al Spampone tells you not to use it or else, as you explained later on. > Both the elegant and the brute-force attacks are feasible > against any open protocol. The only way to avoid these > attacks completely is to retreat to a "private club" > model, in which nodes do not communicate with other nodes > if they have not previously established a trust > relationship. > > A midway position between total openness and a "private > club" involves the use of reputation services. If a > protocol endpoint tests new connections against a > reputation service before engaging more deeply in protocol > operation, attacks can be mitigated. I disagree wholehartedly here. Technologies can and do function - often better - in an open environment. PGP is my favorite example here, because there's a lock where you know how the mechanism works, yet it is still extremely difficult to break. A strong lock, indeed. Sure it _had_ bugs. They got fixed. Security by obscurity, or by reputation, is just going to hide problems until they're discovered far too late. Ironically, we don't have to look past our own desktops to see examples. Now do we have anything to hide here? Here's another example: I'm supposedly a fool for leaving my Win2K AD domain's primary DNS server exposed to the Internet. Sure I'm firewalling and port-forwarding everything I need, and if you poked around long enough you'd discover my entire internal AD structure. But what can you do with it? You know my services' CSIDs (I think that's what they're called) but since you can't talk to it through SMB or NetBIOS you're SOL. And when MARID records begin to appear on my domain you're going to know where my authorized SMTP clients will be. So what? None of those IPs or hostnames are yours and unless you r00t my boxes they never will be. -- PGP key (0x0AFA039E): Sometimes it's hard to tell where the game ends and where reality bites, er, begins. From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 12:38:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27828 for ; Wed, 30 Jun 2004 12:38:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UGHX0j013534; Wed, 30 Jun 2004 09:17:33 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UGHXjQ013533; Wed, 30 Jun 2004 09:17:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from aismtp1g.bellsouth.com (aismtp1g.bellsouth.com [139.76.165.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UGHX4D013524 for ; Wed, 30 Jun 2004 09:17:33 -0700 (PDT) (envelope-from Damon.Sauer@BELLSOUTH.COM) Received: from 01al10015010113.ad.bls.com ([90.152.52.35] [90.152.52.35]) by aismtp1g.bellsouth.com with ESMTP; Wed, 30 Jun 2004 12:17:30 -0400 Content-Class: urn:content-classes:message Subject: RE: Sender ID and CSV are complimentary (long - sorry) (was: Unified SPF overlaps with CSV) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Importance: normal Date: Wed, 30 Jun 2004 11:17:25 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-Id: <38363D9940D92A458010AAE24D162EB9037F4BCE@bremocog-55> Thread-Topic: Sender ID and CSV are complimentary (long - sorry) (was: Unified SPF overlaps with CSV) Thread-Index: AcReu5JX5dzXwTBNShmnhdKf8RqYXAAAZ9jw From: "Sauer, Damon" To: "Andrew Newton" , "Roy Badami" Cc: "MARID" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i5UGHX4D013528 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit >> Granted the fact that it's a >> well run MTA doesn't prove that forged messages or spam won't pass >> through it, but in the world we live in a very small proportion of >> unwanted mail is originated from well-run MTAs, so reputation at that >> level certainly seems valuable. >I have in my notes an interesting tidbit from the MAAWG meeting in DC: Carl Hutzler of AOL said that >70% of spam comes >>through the mail >servers of ISPs. >-andy I will have to disagree with AOL. I am not affiliated with this service at all, but if you go to http://www.senderbase.org and just take a quick glance, you will see that most spam comes directly from ISP client accounts whose providers have not closed port 25. Regards, Damon Sauer ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 113 From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 13:06:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29439 for ; Wed, 30 Jun 2004 13:06:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UGiDU5015066; Wed, 30 Jun 2004 09:44:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UGiDw9015065; Wed, 30 Jun 2004 09:44:13 -0700 (PDT) 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.9) with ESMTP id i5UGiC4e015059 for ; Wed, 30 Jun 2004 09:44:12 -0700 (PDT) (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.34) id 1BfiBu-0001eC-68 for ietf-mxcomp@imc.org; Wed, 30 Jun 2004 11:44:15 -0500 To: "IETF MARID WG" References: From: wayne Reply-To: "IETF MARID WG" Date: Wed, 30 Jun 2004 11:44:10 -0500 In-Reply-To: (Andrew Newton's message of "Wed, 30 Jun 2004 10:28:41 -0400") 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 (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: Differences between CSV and Sender-ID Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.3 required=4.0 tests=AWL,BAYES_00,GREYLIST_ISWHITE autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In Andrew Newton writes: > Therefore, I'd like to get feedback from others: > Do you appreciate the difference between a HELO check vs. a > MAILFROM/PRA/SUBMITTER check? Yes. > Do you understand the semantic differences between a CSV check on > HELO and an SPF/Sender-ID check on HELO? I don't think there is a significant semantic difference. > Is it clear to you that CSV has definite security advantages over > SPF/Sender-ID? No > I'm only asking these questions so that we can hopefully refine the > conversation on this topic. Thanks, I think these questions are useful. -wayne From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 13:26:50 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00288 for ; Wed, 30 Jun 2004 13:26:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UH9OAr017555; Wed, 30 Jun 2004 10:09:24 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UH9Ogb017554; Wed, 30 Jun 2004 10:09:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.mail-abuse.org [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UH9Ox9017548 for ; Wed, 30 Jun 2004 10:09:24 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.mail-abuse.org (DDev.mail-abuse.org [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id CA35941496; Wed, 30 Jun 2004 10:09:27 -0700 (PDT) Subject: Re: Differences between CSV and Sender-ID From: Douglas Otis To: Andrew Newton Cc: MARID WG In-Reply-To: References: Content-Type: text/plain Message-Id: <1088615367.4998.1421.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 30 Jun 2004 10:09:27 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 2004-60-29 at 21:47:42 -0400, Andrew Newton stated: > I have in my notes an interesting tidbit from the MAAWG meeting in DC: > Carl Hutzler of AOL said that >70% of spam comes through the mail > servers of ISPs. This is not the case for AOL and is perhaps close to a figure of UCE advertising major ISP servers and perhaps this percentage of ISPs not using SAP. It is also close to this figure with respect to the amount of UCE emerging from major ISP networks but specifically from their "servers"? (Although these are often spoofed.) On Wed, 2004-06-30 at 07:28, Andrew Newton asked: > Difference between a HELO check vs. a MAILFROM/PRA/SUBMITTER check? Checking a sending SMTP against 2822 identities may provide a confirmation of permissions granted, via a sequence of DNS TXT records, for a message with this identity to emerge from a particular server. These checks may improve effectiveness of filtering, until abusers adapt or simply "take-out" these checks. Never the less, such confirmation SHOULD NOT be trusted to have been generated by the identity indicated. The mail channel is NOT SECURE and checks at administrative boundaries may not fully ensure mail had not been injected unchecked. The methods of injecting mail is legion and currently 70% of the ISPs do not use SAP! Checking a sending SMTP against the HELO 2821 identity (its own identity) via a DNS record that establishes both authorization and authenticity provides a reasonable level of assurance of the SMTP identity. If there is abuse seen from this server, the administration of this server can be held accountable. As a message MUST NEVER BE TRUSTED without end-to-end checks, the SMTP server offers the only identity where accreditation is applicable. It is the administration of the server that ensures mail is not injected by abusive individuals, and if so, that such abuse is abated. HELO/EHLO is the best method to stop abuse through the use of accreditation of the SMTP administration of policy. MALFROM/PRA /SUMBITTER offers no reliable identity for accreditation of the SMTP administration of policy. Without proper SMTP administration of policy, nothing is abated and there is no means to follow-up on abuse. > Differences between a CSV check on HELO and an SPF/Sender-ID check on > HELO? The CSV check establishes the Authorization and Authentication of the SMTP server identity with a single DNS record to allow follow-up with the server administration (a single domain). SPF/Sender-ID provides correlations between the domain of the message and SMTP server. The identity of the server is obfuscated by a large and complex domain matrix spread over many DNS TXT records that must be parsed, expanded, compiled, and executed (many domains). > Is it clear to you that CSV has definite security advantages over > SPF/Sender-ID? CSV is needed to ward off an exponential rise in mail abuse. CSV does offer security through its ability to establish sender SMTP identity and thereby provide a method of accountability. SPF/Sender-ID offers a substantial security risk through miss use of DNS. It obfuscates the sender SMTP identity and thus prevents any method of accountability. Claims regarding assurance of the 2822 identity are irresponsible with the lack of security existing within the mail channel. -Doug From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 13:36:11 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00519 for ; Wed, 30 Jun 2004 13:36:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UHF5LV018290; Wed, 30 Jun 2004 10:15:05 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UHF5WR018289; Wed, 30 Jun 2004 10:15:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from neko-base.nekodojo.org (neko-base.nekodojo.org [64.139.47.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UHF57p018283 for ; Wed, 30 Jun 2004 10:15:05 -0700 (PDT) (envelope-from gconnor@nekodojo.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by neko-base.nekodojo.org (Postfix) with ESMTP id C0FAE1D651; Wed, 30 Jun 2004 10:15:07 -0700 (PDT) Date: Wed, 30 Jun 2004 10:15:09 -0700 From: Greg Connor To: Andrew Newton Cc: IETF MARID WG Subject: Re: Differences between CSV and Sender-ID Message-ID: <6100752.1088590509@Ryoga.corp.sgi.com> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Thanks Andrew. Let me try to answer by way of summarizing what I think the current areas of disagreement are. I think that the differences are minor and that we will all be able to come to common ground soon. --Andrew Newton wrote: > Do you appreciate the difference between a HELO check vs. a > MAILFROM/PRA/SUBMITTER check? My understanding of the issue: A HELO check can catch some really obvious bad cases (like spam or viruses using the receiver's own name) and some obvious good cases (like people we want to whitelist). Also, some folks would like to protect their own name from being used in HELO by other MTAs (so that it won't appear in Received: lines and cause them to get misdirected abuse reports) -- I think there is general agreement that this doesn't happen often and probably isn't core to MARID, but it's certainly something that some domain owners want. CSV also uses HELO to tie a reputation to the sending MTA. This seems to be based on the assumption that good mail comes from good MTAs, and bad mail comes from bad MTAs, which some have suggested is not well-supported. My opinion: I think checking the HELO *alone* is not an adequate solution to the problem set. I don't think CSV alone is enough to be effective against spam coming from big ISPs, where good and bad mail may flow from the same MTA. If the main thing we want out of MARID is to stop people forging mail apparently-from and bouncing-to our own domains, a MAILFROM/PRA check is going to be required. > Do you understand the semantic > differences between a CSV check on HELO and an SPF/Sender-ID check on > HELO? My understanding of the issue: Mechanically, CSV and SPF are both capable of checking HELO. Speaking only about the mechanisms themselves, here is a quick overview: - If the HELO name is different from the base domain people use for email addresses, - you need an SPF record for each MTA name (HELO name) in addition to the mail domain's SPF record. - CSV is similar - you need a SRV record for each full name used in HELO - though since it doesn't check any other identities, there won't be a CSV record for the mail domain (unless it is a negative record saying "nobody may use this domain for HELO") - If the MTA name is also used as a HELO name for one of the MTAs - In most cases the existing SPF record should be sufficient, since it probably includes that MTA. (If not, for example if the machine calling itself "example.com" is a web server and not one of the MX mailers for the domain, then the bounces or notifications coming from this machine are already blocked by SPF). - If the same name is used for both HELO and email@domain, the SPF record should be a union of the two policies. All machines able to use this name in HELO and all machines able to send outgoing mail from this domain should be listed. It has been proposed that SPF add a macro that sites could use to post a different HELO policy than its PRA policy, but in practice most users will just go with the merged policy (if they are different at all) Semantically, there is some difference in the understanding between what the CSV check means, and what the SPF+HELO check means. The big difference between CSV and SPF+HELO is that CSV's supporters have attached a large amount of significance to the record, since it is ONLY used for HELO names, it seems a lot clearer that "These are the servers I control and I'm the best domain to address your problems to". This is more about what you read into the result when you do the check, and not really a factor of the mechanism. CSV doesn't have an "unknown" mode, and I think some CSV supporters have said this is a good thing. My opinion on this: In the case where you want to permit users to send outgoing mail from another domain, but you don't control their servers and you don't completely trust them, I would strongly recommend admins to use "unknown" status (like ?include or ?ptr). If you add to your SPF record using +include:comcast.net, you are in effect saying "Anyone at comcast.net can claim to be me and the mail is guaranteed not forged". It would be better to use ?include:comcast.net or ?ptr:comcast.net. That way the mail from those domains is still allowed, but not "guaranteed" to be from you. If the result comes back unknown, you can't attach reputation or whitelisting to that transaction, you just have to proceed in "legacy" mode. That is an important part of why I believe most domains can use the same SPF record for HELO purposes and for PRA/MAIL FROM. I guess trying to mingle the two modes without explaining the ? vs. + is probably confusing to people :) but I still believe that the same tool can be used for both jobs. If people are really worried about others forging their name in HELO, but don't want to apply stronger protections to their PRA/MAIL FROM with the same name, there will be a macro-based way to give a stronger HELO policy than PRA/MAIL FROM policy, but I think HELO forgery is not enough of a problem for this to be interesting to most users. >Is it clear to you that CSV has definite security advantages > over SPF/Sender-ID? My understanding of the issue: The recent discussion over possible DDOS involving SPF doesn't really have to do with HELO checking specifically. CSV supporters assert that because it doesn't support redirection, includes, macros or exists mechanisms, that this is a good thing. There is general agreement that the smaller problem of HELO checking can probably be solved with a smaller set of tools, but folks differ on whether they want two sets of tools, or one tool capable for both jobs. Therefore we should separate the issue of "whether SPF has problems" completely from the question of "whether CSV has something SPF doesn't". If SPF has problems, they should be addressed. If CSV has features SPF doesn't have, the group needs to decide whether to advance CSV as well, or try to adapt SPF to include those features. There is some advantage to end-users if we are able to produce a single RFC that can address both problems. My opinion: CSV may have a better security story, but I believe this is a direct result of deciding to include fewer features and less flexibility. Regarding DDOS concerns, I think they can be solved by placing some limits on the amount of recursion possible and the total number of queries needed per mail message, and that should satisfy most concerns. We should probably also do a bit more testing to see what such an attack might do, at the very least because then we can recognize it when it happens and we know what to do :) I think there is enough consensus in the group that we need to protect PRA and/or MAIL FROM, and that HELO is of secondary importance. Not everyone agrees with this, but I think a majority of folks think that HELO checking by itself is not enough. So, if we are going forward with PRA/SenderID or something like it, it should be easy enough to adapt it to HELO checking as well. I don't believe there is enough support in the group to adopt CSV as a second proposal, if SenderID can be easily modified to do both jobs. If we separate the questions of "SPF is bad because X" and "CSV is great for Y", we will probably decide that SenderID needs some minor changes to be fixed, and that CSV provides not enough incremental value to proceed as an independent proposal. Now, this is NOT to say that CSV is anything bad. Not at all. CSV authors and proponents should be proud of the current proposal, even if it doesn't make it to RFC. It has done an excellent job of promoting discussion and alternative ideas, and the latest Unified SPF is a direct result of that. The idea of using the HELO name as a whitelist/reputation identity is a good one. CSV does what it sets out to do rather well, and if that were the complete problem set we were tasked with, CSV might just win. Because people want to protect their PRA/MAIL FROM, and Sender ID is getting some support, it is to the group's advantage to try and merge them into a consistent, cohesive product, but I don't think this diminishes the value of CSV and the ideas it has brought to the table. Sorry this has got so long. Let me just say again, I think we are close to agreement and that the areas where we agree are wide compared to the remaining disagreements. Thanks gregc -- Greg Connor From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 14:20:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03085 for ; Wed, 30 Jun 2004 14:20:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UI5xcC022230; Wed, 30 Jun 2004 11:05:59 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UI5xoK022229; Wed, 30 Jun 2004 11:05:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tom.iecc.com (tom.iecc.com [208.31.42.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UI5wBb022222 for ; Wed, 30 Jun 2004 11:05:58 -0700 (PDT) (envelope-from sb0-05995ff4e2-johnl@iecc.com) Received: (qmail 28414 invoked from network); 30 Jun 2004 18:06:01 -0000 Received: (ofmipd 127.0.0.1); 30 Jun 2004 18:05:39 -0000 Date: 30 Jun 2004 14:06:01 -0400 Message-ID: From: "John R Levine" Reply-To: johnl@iecc.com To: "IETF MARID WG" Subject: CEAS Conference on July 30-31 Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'm on the conference committee, and some of the papers look pretty good. If you want to go, register by tomrrow or the price goes up. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor "I dropped the toothpaste", said Tom, crestfallenly. ---------- Forwarded message ---------- Date: Tue, 29 Jun 2004 13:46:14 -0700 From: Joshua Goodman To: "information@ceas.cc" Subject: First Conference on Email and Anti-Spam (CEAS) -- Early Registration Deadline June 30 The First Conference on Email and Anti-Spam (CEAS) Call for Participation July 30, 31 Mountain View, CA http://www.ceas.cc Immediately Follows AAAI 2004 and The International Spam Law & Policies Conference In Cooperation with The American Association for Artificial Intelligence The International Association for Cryptologic Research The IEEE Technical Committee on Security and Privacy Invited Speakers: Hal Varian, Department of Economics, UC Berkeley Lawrence Lessig, Professor of Law, Stanford University The conference includes presentations of approximately 30 peer reviewed papers on machine-learning, economic, and legal methods for stopping spam as well as more general issues related to email. Early registration deadline is June 30. To learn more about the conference and register, go to http://ceas.cc . General Conference Chair: David Heckerman (Microsoft Research) Program Co-Chairs: Tom Berson (Anagram Laboratories) Joshua Goodman (Microsoft Research) Andrew Ng (Stanford University) CONTACT: information@ceas.cc From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 16:07:03 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11906 for ; Wed, 30 Jun 2004 16:07:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UJmK56030557; Wed, 30 Jun 2004 12:48:20 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UJmK5x030556; Wed, 30 Jun 2004 12:48:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.mail-abuse.org [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UJmK9O030542 for ; Wed, 30 Jun 2004 12:48:20 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.mail-abuse.org (DDev.mail-abuse.org [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id 7A9DE41497; Wed, 30 Jun 2004 12:48:24 -0700 (PDT) Subject: Re: Differences between CSV and Sender-ID From: Douglas Otis To: Greg Connor Cc: Andrew Newton , IETF MARID WG In-Reply-To: <6100752.1088590509@Ryoga.corp.sgi.com> References: <6100752.1088590509@Ryoga.corp.sgi.com> Content-Type: text/plain Message-Id: <1088624903.4998.1592.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 30 Jun 2004 12:48:24 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-06-30 at 10:15, Greg Connor wrote: > Thanks Andrew. Let me try to answer by way of summarizing what I think the > current areas of disagreement are. I think that the differences are minor > and that we will all be able to come to common ground soon. > > --Andrew Newton wrote: > > Do you appreciate the difference between a HELO check vs. a > > MAILFROM/PRA/SUBMITTER check? > > My understanding of the issue: > > A HELO check can catch some really obvious bad cases (like spam or viruses > using the receiver's own name) and some obvious good cases (like people we > want to whitelist). Also, some folks would like to protect their own name > from being used in HELO by other MTAs (so that it won't appear in Received: > lines and cause them to get misdirected abuse reports) -- I think there is > general agreement that this doesn't happen often and probably isn't core to > MARID, but it's certainly something that some domain owners want. There is no means of stopping the problem without first identifying the problem. Any entity can be held accountable provided there are accurate means available. > CSV also uses HELO to tie a reputation to the sending MTA. This seems to > be based on the assumption that good mail comes from good MTAs, and bad > mail comes from bad MTAs, which some have suggested is not well-supported. Through use of dynamic lists identifying abusive MTA servers (this does not include major ISP servers), more than 80% of the abuse is blocked. >From this, I must suspect this suggestion is in error or misunderstood. If this list could be fully vetted, it could be made available. Hence the efforts directed at CSV. : < > My opinion: > > I think checking the HELO *alone* is not an adequate solution to the > problem set. I don't think CSV alone is enough to be effective against > spam coming from big ISPs, where good and bad mail may flow from the same > MTA. This underestimates the potential enabled by CSV. If CSV is acted upon, the next battle will be to get ISPs to utilize SAP. MAILFROM/PRA/ SUBMITTER offers NO help whatsoever in this area however! An accurate accreditation system would help convince ISPs it would be in their interest to implement SAP systems. With SAP, the abuser can be identified and disabled to protect their accreditations. > If the main thing we want out of MARID is to stop people forging mail > apparently-from and bouncing-to our own domains, a MAILFROM/PRA check is > going to be required. First, you need something that can scale. MAILFROM/PRA/SUBMITTER does not scale. Fenton's "Identified Mail" does. If ensuring mail identity were critical, then an end-to-end solution that can reasonably ensure the identity of the sender is needed. MAILFROM/PRA/SUBMITTER will be defeated owing to the general lack of SMTP security and lack of policy enforcement as to make such assurance irresponsible. CSV would allow a measure to judge the level of SMTP security that can not be deduced without accurately identifying the sending SMTP. > > Do you understand the semantic differences between a CSV check on > > HELO and an SPF/Sender-ID check on HELO? > > My understanding of the issue: > > Mechanically, CSV and SPF are both capable of checking HELO. As data to comprise such checks are based upon a wholly different paradigms, these checks do not provide comparable results. CSV answers: "This domain is administratively accountable for this SMTP outbound server." SPF answers: "This matrix of domains employ this server." The domain administratively accountable remains unknown with SPF. In the current core Sender-ID draft the only mention of EHLO is as follows: : Is an SMTP client authorized to use a particular domain name in its : SMTP EHLO command? [CSV] attempts to answer this question. It : suffers from the fact that the EHLO name has a tenuous relationship, : at best, with the contents of any mail message. > Speaking only about the mechanisms themselves, here is a quick overview: > - If the HELO name is different from the base domain people use for email > addresses, > - you need an SPF record for each MTA name (HELO name) in addition to > the mail domain's SPF record. Why add this back into the "core" proposal? CSV and Sender-ID are totally independent functions that need totally different information. > - CSV is similar - you need a SRV record for each full name used in > HELO - though since it doesn't check any other identities, there won't be a > CSV record for the mail domain (unless it is a negative record saying > "nobody may use this domain for HELO") > > - If the MTA name is also used as a HELO name for one of the MTAs > - In most cases the existing SPF record should be sufficient, since > it probably includes that MTA. The fact that the MTA may exist as a subset of the SPF information overlooks that this information is obtained using different labels and that being within a subset of the SPF list offers nothing useful for accreditation. Keep CSV "as is" and keep this check excluded from SPF/Sender-ID. Treat these functions as orthogonal. > (If not, for example if the machine calling itself "example.com" is a > web server and not one of the MX mailers for the domain, then the > bounces or notifications coming from this machine are already blocked > by SPF). If the SMTP server does not belong to the domain, then NO mail will be accepted per CSV. Accreditation could offer extended permissions to enable a greater diversity of mail to emerge, but as SPF/Sender-ID does not scale, a comprehensive list of allowable domains over any SMTP server may require some other out-of-band system, and not DNS. A conventional method would be to publish a _service._tcp.domain SRV record that would locate such an out-of-band service. > - If the same name is used for both HELO and email@domain, the SPF > record should be a union of the two policies. This overlooks the purpose of the CSV mechanism entirely and overlooks the protections offered by a much simpler record. Again these to schemes do not offer the same information. Just because CSV may be seen as a subset of SPF, such a record may be located with a different label but must contain different information (less, far less information.) > All machines able to use this name in HELO and all machines able to > send outgoing mail from this domain should be listed. It has been > proposed that SPF add a macro that sites could use to post a different > HELO policy than its PRA policy, but in practice most users will just > go with the merged policy (if they are different at all) Why preface the use of a simple mechanism with the adoption of an incredibly complex scheme that is yet to be fully documented in any Internet Draft. Now you wish to have a macro to post this information? Why add such a significant amount of time to an issue that can and should be addressed separately? > Semantically, there is some difference in the understanding between what > the CSV check means, and what the SPF+HELO check means. The big difference > between CSV and SPF+HELO is that CSV's supporters have attached a large > amount of significance to the record, since it is ONLY used for HELO names, > it seems a lot clearer that "These are the servers I control and I'm the > best domain to address your problems to". This is more about what you read > into the result when you do the check, and not really a factor of the > mechanism. It would seem you have completely overlooked the need for a valid identity for accreditation. > CSV doesn't have an "unknown" mode, and I think some CSV supporters have > said this is a good thing. CSV does allow "no statement" to be made regarding the sending SMTP server. How this gets interpreted is left to those that make policy. > My opinion on this: > > In the case where you want to permit users to send outgoing mail from > another domain, but you don't control their servers and you don't > completely trust them, I would strongly recommend admins to use "unknown" > status (like ?include or ?ptr). If you add to your SPF record using > +include:comcast.net, you are in effect saying "Anyone at comcast.net can > claim to be me and the mail is guaranteed not forged". > > It would be better to use ?include:comcast.net or ?ptr:comcast.net. That > way the mail from those domains is still allowed, but not "guaranteed" to > be from you. If the result comes back unknown, you can't attach reputation > or whitelisting to that transaction, you just have to proceed in "legacy" > mode. > > That is an important part of why I believe most domains can use the same > SPF record for HELO purposes and for PRA/MAIL FROM. I guess trying to > mingle the two modes without explaining the ? vs. + is probably confusing > to people :) but I still believe that the same tool can be used for both > jobs. Why mingle two records that are naturally accessed using different labels anyway? You have not justified this merger. Saying the SPF syntax can become more obtuse to _help_ differentiate the "group" that _may_ be accountable does not improve the use of CSV. CSV is designed to be resilient and lightweight. > If people are really worried about others forging their name in HELO, but > don't want to apply stronger protections to their PRA/MAIL FROM with the > same name, there will be a macro-based way to give a stronger HELO policy > than PRA/MAIL FROM policy, but I think HELO forgery is not enough of a > problem for this to be interesting to most users. Add another layer to the cake, or is it stuff another nut into the cheek? : ) > >Is it clear to you that CSV has definite security advantages > > over SPF/Sender-ID? > > > My understanding of the issue: > > The recent discussion over possible DDOS involving SPF doesn't really have > to do with HELO checking specifically. CSV supporters assert that because > it doesn't support redirection, includes, macros or exists mechanisms, that > this is a good thing. There is general agreement that the smaller problem > of HELO checking can probably be solved with a smaller set of tools, but > folks differ on whether they want two sets of tools, or one tool capable > for both jobs. Leatherman or hammer? : ) > Therefore we should separate the issue of "whether SPF has problems" > completely from the question of "whether CSV has something SPF doesn't". > If SPF has problems, they should be addressed. If CSV has features SPF > doesn't have, the group needs to decide whether to advance CSV as well, or > try to adapt SPF to include those features. There is some advantage to > end-users if we are able to produce a single RFC that can address both > problems. Each of these two problems represent significantly different time lines. There is no technical merit combining these two functions where even the current MARID "core" document has completely excluded consideration of the EHLO domain. > My opinion: > > CSV may have a better security story, but I believe this is a direct result > of deciding to include fewer features and less flexibility. > > Regarding DDOS concerns, I think they can be solved by placing some limits > on the amount of recursion possible and the total number of queries needed > per mail message, and that should satisfy most concerns. We should > probably also do a bit more testing to see what such an attack might do, at > the very least because then we can recognize it when it happens and we know > what to do :) > > I think there is enough consensus in the group that we need to protect PRA > and/or MAIL FROM, and that HELO is of secondary importance. Not everyone > agrees with this, but I think a majority of folks think that HELO checking > by itself is not enough. So, if we are going forward with PRA/SenderID or > something like it, it should be easy enough to adapt it to HELO checking as > well. I don't believe there is enough support in the group to adopt CSV as > a second proposal, if SenderID can be easily modified to do both jobs. > > If we separate the questions of "SPF is bad because X" and "CSV is great > for Y", we will probably decide that SenderID needs some minor changes to > be fixed, and that CSV provides not enough incremental value to proceed as > an independent proposal. Here we differ greatly in opinions. I do not think that CSV by itself is a complete solution. CSV with accreditation is a potent solution that has much greater promise. I have great concerns regarding expectations of using DNS to publish a correlation of 2822 identities with all servers allowed to carry such messages. DNS was never designed to have a simple query offer such a comprehensive result. This is venturing into regions where there are many looking for a chink in the armor. Why expose yourself to harm if it is not needed? A security concern offers great justification for keeping these two proposals for two separate problem sets, separate. -Doug From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 16:33:48 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14856 for ; Wed, 30 Jun 2004 16:33:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UKLnYV033524; Wed, 30 Jun 2004 13:21:49 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UKLnhI033523; Wed, 30 Jun 2004 13:21:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UKLmgV033516 for ; Wed, 30 Jun 2004 13:21:48 -0700 (PDT) (envelope-from roy+dated+1091218907.91d9e8@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i5UKLind023173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 30 Jun 2004 20:21:45 GMT (envelope-from roy+dated+1091218907.91d9e8@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5UKLlq0040679 for ; Wed, 30 Jun 2004 21:21:47 +0100 (BST) (envelope-from roy+dated+1091218907.91d9e8@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5UKLlx4040678 for ietf-mxcomp@imc.org; Wed, 30 Jun 2004 21:21:47 +0100 (BST) (envelope-from roy+dated+1091218907.91d9e8@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Wed, 30 Jun 2004 21:21:47 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16611.8411.102438.87387@giles.gnomon.org.uk> Date: Wed, 30 Jun 2004 21:21:47 +0100 To: ietf-mxcomp@imc.org Subject: The problem with Unified SPF X-Mailer: VM 7.18 under Emacs 21.3.1 From: Roy Badami X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit OK, here's what I see as the probems with Unified SPF (as I understand the proposal) as compared with using SenderID in conjunction with CSV/CSA. 1. Unified SPF encourages (but doesn't require) the same check to be made on the HELO as on other identities. If this is how it is deployed in practice, it will lead to unnecessarily lax checks on the HELO, which will reduce the effectiveness of the HELO check. A complex SPF record may reference many different providers, whereas a particular HELO string will typically come from a specific MTA. The big problem though is when an SPF record ends in ?all or ~all. It is counterproductive to encourage people to use this same record for HELO checks. You may not know all the MTAs that might sometimes originate mail for your domain, but HELO strings typically identify individual MTAs, and you almost certainly know the exact list of IP addresses in use by a specific MTA under your control. Encouraging people to relax the HELO check just because they don't feel comfortable with a strict PRA (or MAIL FROM) check is undesirable. 2. It's not clear that unifying them (in the sense that I understand is intended by Meng Weng Wong) makes much sense, given the set of valid identities is typically disjoint. Ignoring for a moment the fact that a HELO identity is a domain, whereas a PRA or MAIL FROM is a mailbox, even the domains used are typically disjoint. If example.com is a domain that occurs in the PRA and MAIL FROM, it typically won't be a valid HELO identity. Conversely, mx1.example.com might be a valid HELO identity, but is unlikely to be valid as part of a mailbox. Unifying the proposals syntactically may make sense -- ie using a (subset of) SPF syntax for the CSV/CSA records. I remain to be convinced that unifying them semantically is sensible. 3. The models of reputation and accreditation are different. One is the reputation of a domain, the other is a reputation of a host. It's not clear to me that both of these reputation services will be provided by the same set of providers, so if you're going to try and use a single record for both purposes, you probably want to be able to select separate sets of reputation services for the HELO identity and the PRA/MAIL FROM identities, in order to avoid redundant quieries to the 'wrong' providers. This _could_ be done with a single record, but given (2) above, this starts looking unnecessarily messy to me. -roy From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 16:35:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15082 for ; Wed, 30 Jun 2004 16:35:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UKPBOS033832; Wed, 30 Jun 2004 13:25:11 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UKPBjU033831; Wed, 30 Jun 2004 13:25:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UKPADg033824 for ; Wed, 30 Jun 2004 13:25:10 -0700 (PDT) (envelope-from roy+dated+1091219112.aeb440@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i5UKP8nd023818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 30 Jun 2004 20:25:09 GMT (envelope-from roy+dated+1091219112.aeb440@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5UKPCMp040737 for ; Wed, 30 Jun 2004 21:25:12 +0100 (BST) (envelope-from roy+dated+1091219112.aeb440@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5UKPCOQ040736 for ietf-mxcomp@imc.org; Wed, 30 Jun 2004 21:25:12 +0100 (BST) (envelope-from roy+dated+1091219112.aeb440@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Wed, 30 Jun 2004 21:25:12 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16611.8615.591098.620742@giles.gnomon.org.uk> Date: Wed, 30 Jun 2004 21:25:11 +0100 To: ietf-mxcomp@imc.org Subject: Use of PTR records in CSV/DNA X-Mailer: VM 7.18 under Emacs 21.3.1 From: Roy Badami X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Not an objection, but I'd just like to note that the use of PTR records outside of the in-addr.arpa tree was proposed in RFC1101 for the purposes of mapping network names to their addresses. However, this is not a standards track document (STATUS: UNKNOWN) and I'm not aware of this technique being in widespread use. -roy From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 16:39:09 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15520 for ; Wed, 30 Jun 2004 16:39:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UKP22l033768; Wed, 30 Jun 2004 13:25:02 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UKP27J033767; Wed, 30 Jun 2004 13:25:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (listserv.winserver.com [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i5UKOx1t033726 for ; Wed, 30 Jun 2004 13:25:01 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Wed, 30 Jun 2004 16:28:41 -0400 Received: from ([65.10.109.27]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 2437968922; Wed, 30 Jun 2004 16:28:40 -0400 Message-ID: <016101c45ee0$5272b170$6401a8c0@hdev1> From: "Hector Santos" To: "Andrew Newton" Cc: "IETF-MXCOMP" References: Subject: Re: Differences between CSV and Sender-ID Date: Wed, 30 Jun 2004 16:24:58 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.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: Content-Transfer-Encoding: 7bit Thanks for this Andrew. > Do you appreciate the difference between a HELO check vs. a > MAILFROM/PRA/SUBMITTER check? A resounding yes. > Do you understand the semantic differences between a CSV check on > HELO and an SPF/Sender-ID check on HELO? Yes. > Is it clear to you that CSV has definite security advantages over > SPF/Sender-ID? Yes, but more true if you said "offers some security advantages over.." But what is very important to understand the two are important. They can work together. I hope to show this in my trust analysis (second point below). I will outline my reasoning to help explain my answers to your questions: o In general (CVS or otherwise), a validation at HELO offers an inherent presumption of M2M (machine to machine) trust concept. I agree with the concept especially in internal networks where routers are involved. This may include analysis of the first hop (assuming no tampering) to help in the generation of the trust in non-internal routed situations. It has to do with the circle of trust idea. Dave Crocker has provided excellent writes up/presentations on the concept 1-2 years ago or more. Its on his web site. However, I believe this is all based that the enforcement or following of the traditional SMTP operation of: - Non-Authentication/Trust is not required for Final Destination. - Authentication/Trust required for routes Otherwise you have open relay situations and security violations in internal networks. o I have a LMAP trust analysis showing how HELO validation can help change the results of a SPF MAIL FROM validation. I hope to clean this up for publication here. CSV was not available at the time of this write-up, but it wasn't necessary per se. It is an trust analysis showing how HELO LMAP results can prevail, alter or change or not, the results of a MAIL FROM LMAP results. o The problem with CVS specifically, its in augmentation of a 3rd party concept (accreditation). This introduces a barrier for implementation (atleast for me). I prefer to work with a SMTP based functional protocol, not a system-wide, product or application protocol. o The problem of PRA/SUBMITTER or any related idea (including CVS first hop analysis) is its dependency on post 2821 operations. Basically, what it means from a implementation standpoint, it is outside our design scope. We push all responsibility for post SMTP mail analysis to the system operator (sysop) - by product design which has its beginnings related to product liability. In short, if the sysop wants to use "SpamAssassin, or SendedID", he is on his own here. o To help address the growth of 2822 analysis and also keeping with the design of the system, we offer a DATA hook so that they can run a mail content analysis (like SpamAssasin or McAfee AVS) by hooking it into at 2821 DATA state. The key reason for this was to help solved the huge growth problem of having "good but spoofed return path address" perpetuated with the growth of SORBIG-based email viruses. This exploitation has taken on a Code Red Principle mentality of attacking POST SMTP systems and all the legacy systems that operate in this mode, to help the virus with 2nd tier bounce distribution. Running a mail content analysis/rejection at DATA helps this situation because it eliminates the second level (bounce mail) assault. Basically what the above says from my standpoint, is that I think SPF can help provide additional HELO validation security with a modification of its SPF lookup specifications. CSV can help add more weight with first hop analysis. But all overall, the merging of other concepts such as accreditation is not a welcome idea for me as it makes the whole issue of providing a customer a reliable anti/spam security product or feature more dependent on external, more likely than not, profit driven service bureaus. I wish to keep and implement a solution purely on technical and SMTP/internet standard compliancy grounds. Not saying it can't be offered, but it will make CVS less adoptable in my view. The same is basically true with SenderID. In this case, it requires a change in software and compliance by VALID systems. Therefore, unless we are ready to enforce the idea non-compliance will add some level of acceptable mis-trust and thus rejection and/or scrutiny, I don't see it working very well at all. To support it, we then go back in circles with encouragement of payload transmission. Sure, it can be supported at the DATA hook, but it definitely not something I can't see it putting any weight on the trust concept: - A spammer complies. It doesn't address the validity of the address? - A spammer does not comply. It could be a valid legacy system? My prediction with SenderID or any promotion of a new world-wide standard that requires 2822 analysis: Spammers/Hackers will discover that there is new growth of Microsoft Exchange servers in the market place will accept payload. They increase the payloads to levels that is just under a system limit (ours is 5 megs per email I believe). The goal? Frustrate systems to turn off the option due to new scalability and load balancing problems. Systems that don't support it won't have this problem. Systems that rely solely Microsoft's SenderID are in big trouble. Systems that rely on other 2822 validation ideas suffer too because they will see the growth of higher payloads on their systems too. Of course, I reserve the right to be completely wrong. Nonetheless, right or wrong, it is a valid engineering design consideration that helps reduced consumers risk. Ideas like SendedID and any other 2822 validation logic "cries" for a change in the SMTP transaction protocol, basically a new command to provide the headers. If this was to happen, I'll be among the first to jump on board. In my view, MARID can probably be assisted with other ideas that may help address the current items in discussion: - How will the Spammer React? - Where are we enforcing change? Are the operator or spammer? This is related to Meng's reflection of the "Chaos Theory" - Chaos promotes change/adaptation. Well, we are changing, but is the spammers? How? - Can I lower of cost of operation (TCO) by using CVS, SPF, SPF2? Or is this still going to be a problem, and if so, this MARID help in the tracking/audit process which is required by CANSPAM if you wish to use the new law against a spammer. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com ----- Original Message ----- From: "Andrew Newton" To: "MARID WG" Sent: Wednesday, June 30, 2004 10:28 AM Subject: Differences between CSV and Sender-ID > I have been observing that the recent discussion on CSV in comparison > to the SPF/Sender-ID solutions have been between a small, consistent > subset of the participants of this mailing list. I can only conclude > that others either do not care about these issues or do not understand > these issues. After reading every single message over the past couple > of threads, I must admit that I do not comprehend many of the points. > > Therefore, I'd like to get feedback from others: > Do you appreciate the difference between a HELO check vs. a > MAILFROM/PRA/SUBMITTER check? > Do you understand the semantic differences between a CSV check on > HELO and an SPF/Sender-ID check on HELO? > Is it clear to you that CSV has definite security advantages over > SPF/Sender-ID? > > I'm only asking these questions so that we can hopefully refine the > conversation on this topic. From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 17:32:50 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21730 for ; Wed, 30 Jun 2004 17:32:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ULJZpW039521; Wed, 30 Jun 2004 14:19:35 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5ULJZtn039520; Wed, 30 Jun 2004 14:19:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ULJYdv039505 for ; Wed, 30 Jun 2004 14:19:35 -0700 (PDT) (envelope-from roy+dated+1091222377.5b9c3d@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i5ULJbnd041986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 30 Jun 2004 21:19:38 GMT (envelope-from roy+dated+1091222377.5b9c3d@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5ULJb8C040964 for ; Wed, 30 Jun 2004 22:19:37 +0100 (BST) (envelope-from roy+dated+1091222377.5b9c3d@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5ULJbT2040963 for ietf-mxcomp@imc.org; Wed, 30 Jun 2004 22:19:37 +0100 (BST) (envelope-from roy+dated+1091222377.5b9c3d@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Wed, 30 Jun 2004 22:19:37 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16611.11880.891152.867376@giles.gnomon.org.uk> Date: Wed, 30 Jun 2004 22:19:36 +0100 To: ietf-mxcomp@imc.org Subject: The problem with Unified SPF In-Reply-To: <16611.8411.102438.87387@giles.gnomon.org.uk> References: <16611.8411.102438.87387@giles.gnomon.org.uk> X-Mailer: VM 7.18 under Emacs 21.3.1 From: Roy Badami X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit And to followup: 1a. Even if using the same record for HELO as for other identities provides an acceptable level of assurance (which will only ever be the case when the record ends -all) sharing a complex SPF record will probably result in far more DNS queries to reject a forged HELO than would be necessary if a separate record (of whatever syntax) were used for this purpose. -roy From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 17:34:12 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21803 for ; Wed, 30 Jun 2004 17:34:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ULP86A040930; Wed, 30 Jun 2004 14:25:08 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5ULP82p040929; Wed, 30 Jun 2004 14:25:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ULP8Yd040913 for ; Wed, 30 Jun 2004 14:25:08 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.0.1.153] ([::ffff:64.83.8.178]) (AUTH: LOGIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Wed, 30 Jun 2004 17:25:08 -0400 id 0005C657.40E32FB5.00007233 Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: MARID WG From: Andrew Newton Subject: CSV and STARTTLS Date: Wed, 30 Jun 2004 17:25:06 -0400 X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From section B.4.1 of draft-marid-csv-intro: > B.4.1 StartTLS > > A common certificate method as used with StartTLS [RFC3207] can > authenticate an unknown server after an investment in signed > periodic > digital certificates, encryption capabilities, and services of a > Certificate Authority. This investment creates a barrier for > large-scale use over the open Internet. Reliance on the certificate > signature also adds a need to vet Certificate Authorities in > addition > to the confirmed domains. > > Spontaneous communications are at the core of Internet design and > operation. So omission of a Certificate Authority is typically > allowed of clients. When this is allowed, StartTLS loses any > ability > to authenticate the relationship of the client to its claimed domain > name Does this imply that the strong authentication provided by certificate validation of TLS is to be subjugated by CSV, which is most likely to be weaker authentication? Also, I think many security-minded folks may disagree with the characterization in the first paragraph. Opportunistic encryption with peer authentication using TLS happens every day on the Internet. -andy From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 18:09:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24097 for ; Wed, 30 Jun 2004 18:09:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ULxoPa047591; Wed, 30 Jun 2004 14:59:50 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5ULxokG047590; Wed, 30 Jun 2004 14:59:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.mail-abuse.org [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ULxoB4047551 for ; Wed, 30 Jun 2004 14:59:50 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.mail-abuse.org (DDev.mail-abuse.org [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id 2F2D941493; Wed, 30 Jun 2004 14:59:45 -0700 (PDT) Subject: Re: CSV and STARTTLS From: Douglas Otis To: Andrew Newton Cc: MARID WG In-Reply-To: References: Content-Type: text/plain Message-Id: <1088632784.4998.1710.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 30 Jun 2004 14:59:44 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-06-30 at 14:25, Andrew Newton wrote: > From section B.4.1 of draft-marid-csv-intro: > > > B.4.1 StartTLS > > > > A common certificate method as used with StartTLS [RFC3207] can > > authenticate an unknown server after an investment in signed > > periodic digital certificates, encryption capabilities, and > > services of a Certificate Authority. This investment creates a > > barrier for large-scale use over the open Internet. Reliance on > > the certificate signature also adds a need to vet Certificate > > Authorities in addition to the confirmed domains. > > > > Spontaneous communications are at the core of Internet design and > > operation. So omission of a Certificate Authority is typically > > allowed of clients. When this is allowed, StartTLS loses any > > ability to authenticate the relationship of the client to its > > claimed domain name > > Does this imply that the strong authentication provided by certificate > validation of TLS is to be subjugated by CSV, which is most likely to > be weaker authentication? > > Also, I think many security-minded folks may disagree with the > characterization in the first paragraph. Opportunistic encryption with > peer authentication using TLS happens every day on the Internet. I do not speak for the other authors, but there was a discussion involving this issue that Dave Crocker had been addressing. It is my understanding this needs to change to reflect StartTLS is stronger but defines a different namespace which is why Dave indicates it does not authenticate the HELO domain. He was working on the wording for this. The accreditation may need to compose something like cert-name._ca.cert-auth.accredit.com to recognize this differing namespace for StartTLS. -Doug From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 18:11:22 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24447 for ; Wed, 30 Jun 2004 18:11:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UM3ted048486; Wed, 30 Jun 2004 15:03:55 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UM3tfF048485; Wed, 30 Jun 2004 15:03:55 -0700 (PDT) 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.9) with ESMTP id i5UM3rg1048461 for ; Wed, 30 Jun 2004 15:03:54 -0700 (PDT) (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 47F90132F52; Wed, 30 Jun 2004 18:03:53 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 183E76A4; Wed, 30 Jun 2004 18:03:53 -0400 (EDT) Date: Wed, 30 Jun 2004 18:03:53 -0400 From: Meng Weng Wong To: Roy Badami Cc: ietf-mxcomp@imc.org Subject: Re: The problem with Unified SPF Message-ID: <20040630220353.GX13225@dumbo.pobox.com> References: <16611.8411.102438.87387@giles.gnomon.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16611.8411.102438.87387@giles.gnomon.org.uk> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Jun 30, 2004 at 09:21:47PM +0100, Roy Badami wrote: | | OK, here's what I see as the probems with Unified SPF (as I understand | the proposal) as compared with using SenderID in conjunction with | CSV/CSA. | | A complex SPF record may reference many different providers, | whereas a particular HELO string will typically come from a | specific MTA. The big problem though is when an SPF record ends in | ?all or ~all. It is counterproductive to encourage people to use | this same record for HELO checks. You may not know all the MTAs | that might sometimes originate mail for your domain, but HELO | strings typically identify individual MTAs, and you almost | certainly know the exact list of IP addresses in use by a specific | MTA under your control. Encouraging people to relax the HELO check | just because they don't feel comfortable with a strict PRA (or MAIL | FROM) check is undesirable. | The problem statement seems to assume that domain names used in MAIL FROM will overlap with domain names seen in HELO. If I read this assumption wrongly, please correct me. HELO domain.com MAIL FROM: In this situation, an SPF record could easily become unnecessarily complex for HELO purposes. domain.com. TXT "v=spf1 include:this include:that a mx ?all" If the domain admin changes the HELO string to be: HELO mta1.domain.com MAIL FROM: Then the problem goes away. mta1.domain.com. TXT "v=spf1 a -all" domain.com. TXT "v=spf1 include:this include:that a mx ?all" Is that any better? From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 18:32:48 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26049 for ; Wed, 30 Jun 2004 18:32:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UMIhJd051615; Wed, 30 Jun 2004 15:18:43 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UMIhTL051614; Wed, 30 Jun 2004 15:18:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UMIghe051600 for ; Wed, 30 Jun 2004 15:18:42 -0700 (PDT) (envelope-from roy+dated+1091225925.afeda0@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i5UMIjnd060501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 30 Jun 2004 22:18:45 GMT (envelope-from roy+dated+1091225925.afeda0@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5UMIjVb041290 for ; Wed, 30 Jun 2004 23:18:45 +0100 (BST) (envelope-from roy+dated+1091225925.afeda0@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5UMIjhf041283 for ietf-mxcomp@imc.org; Wed, 30 Jun 2004 23:18:45 +0100 (BST) (envelope-from roy+dated+1091225925.afeda0@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Wed, 30 Jun 2004 23:18:44 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16611.15427.708207.855024@giles.gnomon.org.uk> Date: Wed, 30 Jun 2004 23:18:43 +0100 To: Meng Weng Wong Cc: Roy Badami , ietf-mxcomp@imc.org Subject: Re: The problem with Unified SPF In-Reply-To: <20040630220353.GX13225@dumbo.pobox.com> References: <16611.8411.102438.87387@giles.gnomon.org.uk> <20040630220353.GX13225@dumbo.pobox.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Meng" == Meng Weng Wong writes: Meng> The problem statement seems to assume that domain names used Meng> in MAIL FROM will overlap with domain names seen in HELO. Meng> If I read this assumption wrongly, please correct me. Meng> HELO domain.com Meng> MAIL FROM: Actually, I was assuming that the above case is uncommon. Though we probably need to address it. Meng> If the domain admin changes the HELO string to be: Meng> HELO mta1.domain.com MAIL FROM: Meng> Then the problem goes away. Meng> mta1.domain.com. TXT "v=spf1 a -all" Meng> domain.com. TXT "v=spf1 include:this include:that a mx ?all" Which (almost) boils down to CSV, but using SPF syntax instead of SRV records. I have to say that I hadn't realized this was the intent of Unified SPF. If you're expecting to have separate records for the HELO identitiy and other identities, then I don't see the advantage of making them both generic. The first of your TXT records should be clearly for HELO use only, and the second should be clearly for PRA and MAIL FROM. As it stands, your example still allows anyone to forge a HELO domain.com -roy From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 18:32:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26068 for ; Wed, 30 Jun 2004 18:32:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UMPj6l052956; Wed, 30 Jun 2004 15:25:45 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UMPj8x052955; Wed, 30 Jun 2004 15:25:45 -0700 (PDT) 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.9) with ESMTP id i5UMPCHl052829 for ; Wed, 30 Jun 2004 15:25:44 -0700 (PDT) (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 3EA6A132F52; Wed, 30 Jun 2004 18:25:16 -0400 (EDT) Received: by dumbo.pobox.com (Postfix, from userid 505) id 0C3986A4; Wed, 30 Jun 2004 18:25:16 -0400 (EDT) Date: Wed, 30 Jun 2004 18:25:16 -0400 From: Meng Weng Wong To: Roy Badami Cc: ietf-mxcomp@imc.org Subject: Re: The problem with Unified SPF Message-ID: <20040630222516.GA16052@dumbo.pobox.com> References: <16611.8411.102438.87387@giles.gnomon.org.uk> <20040630220353.GX13225@dumbo.pobox.com> <16611.15427.708207.855024@giles.gnomon.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16611.15427.708207.855024@giles.gnomon.org.uk> User-Agent: Mutt/1.3.25i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Jun 30, 2004 at 11:18:43PM +0100, Roy Badami wrote: | | Meng> mta1.domain.com. TXT "v=spf1 a -all" | Meng> domain.com. TXT "v=spf1 include:this include:that a mx ?all" | | Which (almost) boils down to CSV, but using SPF syntax instead of SRV | records. | | I have to say that I hadn't realized this was the intent of Unified | SPF. Yes, that is the intent of Unified SPF; use a single syntax model to offer different semantics appropriate to each identity context. In the HELO context, you get CSV semantics. In the PRA context, you get Caller ID semantics. In the MAIL-FROM context, you get SPF Classic semantics. In the PTR context, you get MTAMark semantics. The "unification" does not mean all the above identities need to use the same domain name. From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 18:34:30 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26097 for ; Wed, 30 Jun 2004 18:34:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UMQdrp053128; Wed, 30 Jun 2004 15:26:39 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UMQdbE053127; Wed, 30 Jun 2004 15:26:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from xuxa.iecc.com (xuxa.iecc.com [208.31.42.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UMQcaR053119 for ; Wed, 30 Jun 2004 15:26:39 -0700 (PDT) (envelope-from sb0-05995ff4e2-johnl@iecc.com) Received: (qmail 3309 invoked by uid 100); 30 Jun 2004 22:26:43 -0000 Date: 30 Jun 2004 22:26:43 -0000 Message-ID: <20040630222643.3308.qmail@xuxa.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: Re: CSV and STARTTLS In-Reply-To: Organization: I.E.C.C., Trumansburg NY USA Cc: andy@hxr.us Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >> B.4.1 StartTLS ... >Does this imply that the strong authentication provided by certificate >validation of TLS is to be subjugated by CSV, which is most likely to >be weaker authentication? I think you're misreading it. They're saying that in practice people don't use signed SSL certs to validate the other end of an SMTP connection. Looking at the logs of my mail servers, I see plenty of TLS connections, but more often than not the certs are self-signed, and in a lot of cases they just use a default cert shipped with the MTA. If people were going to use TLS certs to authenticate their mail channels, they'd be doing so already, but they're not. Opportunistic encryption is fine, but I don't see that as relating to CSV one way or the other. If you want to do CSV checks and then STARTTLS, you can easily do so. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor "I shook hands with Senators Dole and Inouye," said Tom, disarmingly. From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 19:05:12 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28025 for ; Wed, 30 Jun 2004 19:05:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UMqNxV059142; Wed, 30 Jun 2004 15:52:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UMqNGO059141; Wed, 30 Jun 2004 15:52:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from spike.gnomon.org.uk (spike.gnomon.org.uk [66.45.230.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UMqMaX059133 for ; Wed, 30 Jun 2004 15:52:23 -0700 (PDT) (envelope-from roy+dated+1091227946.a6ada8@gnomon.org.uk) Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i5UMqQnd020824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 30 Jun 2004 22:52:27 GMT (envelope-from roy+dated+1091227946.a6ada8@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5UMqQvW041496 for ; Wed, 30 Jun 2004 23:52:26 +0100 (BST) (envelope-from roy+dated+1091227946.a6ada8@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5UMqQr0041495 for ietf-mxcomp@imc.org; Wed, 30 Jun 2004 23:52:26 +0100 (BST) (envelope-from roy+dated+1091227946.a6ada8@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Wed, 30 Jun 2004 23:52:25 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16611.17449.310982.114325@giles.gnomon.org.uk> Date: Wed, 30 Jun 2004 23:52:25 +0100 To: Andrew Newton Cc: MARID WG Subject: CSV and STARTTLS In-Reply-To: References: X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Andrew" == Andrew Newton writes: Andrew> Opportunistic encryption with peer authentication using Andrew> TLS happens every day on the Internet. I question that peer authentication is commonplace (although I don't doubt that it happens every day). I get the impression most people use self-signed certs with STARTTLS. -roy From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 20:17:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02199 for ; Wed, 30 Jun 2004 20:17:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5UNwZmq072620; Wed, 30 Jun 2004 16:58:35 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5UNwZB9072619; Wed, 30 Jun 2004 16:58:35 -0700 (PDT) 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.9) with ESMTP id i5UNwY2Z072613 for ; Wed, 30 Jun 2004 16:58:34 -0700 (PDT) (envelope-from dhc@dcrocker.net) Received: from [202.159.52.247] (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i5UNwal14083 for ; Wed, 30 Jun 2004 16:58:37 -0700 Date: Thu, 1 Jul 2004 07:58:28 +0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 2 (High) Message-ID: <170501979.20040701075828@brandenburg.com> To: ietf-mxcomp@imc.org Subject: Comparing apples to multiple, hypothetical oranges MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Folks, Having restricted access to the net is forcing me to see working group activity in batches. This can be helpful for noticing patterns, trends, and the like. (It also means I do not get to do coordination with others before posting things. Hence, this is an entirely personal posting rather than one being made "on behalf of" the CSV team.) The current effort to compare CSV "versus" SPF, prompts me to notice that there is no working group effort on a specification called "SPF", nevermind "Unified SPF", Sender ID, or whatever other variant names and versions might be used. There are a couple of IETF working group documents that derive from those outside efforts, but folks do not seem to be referring to working group documents. Yes, the marid-core document cites SPF all over the place, but even it acknowledges that it needs to fix those references. Obviously the chairs will correct me if this assessment is wrong. In that case I will ask them to point me to the working group specifications for these other proposals. Failing that, I will ask about the schedule for getting those proposals documented in the working group. CSV is a concrete specification, contained in three, concise documents, totalling 36 pages, including the usual, repetitious boilerplate. CSV provides for very narrow functionality, so it is easy to understand what it is trying to do and to analyze how it performs. The specifications have undergone relatively little conceptual or functional change. Changes have been for clarification and correctness. This is what incremental effort towards a stable specification requires. By contrast, discussions about "SPF" frequently treat hypothetical capabilities, deployed capabilities, and multiple specifications of capabilities as if they were all the same, single, concrete technology. Perhaps other folks can keep clear what is concrete and what is vague, but I can't. It is always easy to appear to win an argument if one is not burdened with the requirement to be concrete and stable, and abstract hypotheticals are treated the same as reality. Easy, but not technically productive. When a specification is questioned along the lines of "how does this work, exactly?" or "what happens in this case?" or "where does the specification say that?" or the like, it is _always_ useful. When a concrete specification is compared to an entire suite of variant specifications and undocumented concepts, it is _never_ useful for the technical quality of the effort, because it permits assumptions and implications to diverge or slip through unrecognized. This working group has some official documents. I would like to ask that the working group discuss those documents and that it discuss them incrementally. Incremental discussion and resolution is clearly what Andrew is seeking, by virtue of the kinds of questions and action items he has been posting. What I believe needs to change is the scope of the working group's consideration of this family of technologies and ideas currently going under the label "SPF". Specifications and undocumented concepts that are outside the working group ought to remain outside. Undocumented concepts are, of course, fine to consider for inclusion in the working group, but a concept is always vague and its utility is typically not very high until it achieves relatively stable documentation. The draft-ietf-marid-submitter specification is a particularly good example of this process of incorporation. It went quickly from basic idea to clear, concise, concrete specification. Now folks can conduct concrete analysis on it. So: This is a formal request to the working group chairsm, to clarify and restrict working group discussion to working group specifications. I think competitive analysis is a Good Thing. But it needs to based on concrete, incrementally stable specifications. Constantly shifting sands are far too difficult to stand on. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 20:26:02 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02648 for ; Wed, 30 Jun 2004 20:26:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i610CvLJ075649; Wed, 30 Jun 2004 17:12:57 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i610CvG6075648; Wed, 30 Jun 2004 17:12:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.mail-abuse.org [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i610CvSi075642 for ; Wed, 30 Jun 2004 17:12:57 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from DDev.mail-abuse.org (DDev.mail-abuse.org [168.61.10.124]) by harry.mail-abuse.org (Postfix) with ESMTP id 7BD3D41493; Wed, 30 Jun 2004 17:13:03 -0700 (PDT) Subject: Re: The problem with Unified SPF From: Douglas Otis To: Meng Weng Wong Cc: Roy Badami , ietf-mxcomp@imc.org In-Reply-To: <20040630220353.GX13225@dumbo.pobox.com> References: <16611.8411.102438.87387@giles.gnomon.org.uk> <20040630220353.GX13225@dumbo.pobox.com> Content-Type: text/plain Message-Id: <1088640782.4998.1966.camel@ddev.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 30 Jun 2004 17:13:03 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2004-06-30 at 15:03, Meng Weng Wong wrote: > > The problem statement seems to assume that domain names used > in MAIL FROM will overlap with domain names seen in HELO. > If I read this assumption wrongly, please correct me. > > HELO domain.com > MAIL FROM: > > In this situation, an SPF record could easily become > unnecessarily complex for HELO purposes. > > domain.com. TXT "v=spf1 include:this include:that a mx ?all" > > If the domain admin changes the HELO string to be: > > HELO mta1.domain.com > MAIL FROM: > > Then the problem goes away. > > mta1.domain.com. TXT "v=spf1 a -all" > domain.com. TXT "v=spf1 include:this include:that a mx ?all" > > Is that any better? Is Sender-ID depreciated over rejections of XML? Is there a push to restore SPF? It would be nice to see a draft that brings these ideas (2822 identity schemes) into a "unified" document. : ) There is nothing in this SPF record that ensures this is intended to define the MTA host name so it can be spoofed with helo strings selecting the wrong record. It still requires use of a parser to understand the record as opposed to using existing libraries that already include the SRV format. This SPF string may require additional queries to read any number of differing records. The SRV record is able to return a list of addresses, and where these hosts can be assigned using existing tools. CSV and SPF/Sender-ID records are requested at different points within the process, so there may not be a need to spawn a SPF/Sender-ID parser if the connection is rejected by the CSV process. This is a consideration when receiver side resources are considered. If CSV is to provide DDoS protection, using an SRV record improves upon this protection. As these lists may tend to look similar for some, there is great risk of confusion or simply allowing clever spoofing made possible by this overloading of SPF/Sender-ID/CSV. Keep CSV separate using SRV. I do not see these two distinct and separate functions as either competitors or as incompatible. But again, there is no reason to join these two mechanisms into a common record, and many reasons not to join them. -Doug From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 20:41:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03632 for ; Wed, 30 Jun 2004 20:41:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i610OAm8077785; Wed, 30 Jun 2004 17:24:10 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i610OAe1077784; Wed, 30 Jun 2004 17:24:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (mail.catinthebox.net [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id i610O9aY077773 for ; Wed, 30 Jun 2004 17:24:10 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.0.451.1) for ietf-mxcomp@imc.org; Wed, 30 Jun 2004 20:28:05 -0400 Received: from ([65.10.109.27]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.0.451.1) with SMTP id 2452333391; Wed, 30 Jun 2004 20:28:04 -0400 Message-ID: <002901c45f01$c4d7f5b0$6401a8c0@hdev1> From: "Hector Santos" To: "IETF-MXCOMP" Cc: References: <20040630222643.3308.qmail@xuxa.iecc.com> Subject: Re: CSV and STARTTLS Date: Wed, 30 Jun 2004 20:24:16 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.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: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "John Levine" To: Cc: Sent: Wednesday, June 30, 2004 6:26 PM Subject: Re: CSV and STARTTLS > > >> B.4.1 StartTLS ... > > >Does this imply that the strong authentication provided by certificate > >validation of TLS is to be subjugated by CSV, which is most likely to > >be weaker authentication? > > I think you're misreading it. They're saying that in practice people > don't use signed SSL certs to validate the other end of an SMTP > connection. Looking at the logs of my mail servers, I see plenty of > TLS connections, but more often than not the certs are self-signed, > and in a lot of cases they just use a default cert shipped with the > MTA. If people were going to use TLS certs to authenticate their > mail channels, they'd be doing so already, but they're not. Good point. We implemented outbound SSL/TLS but it is rare for us to hear or know if anyone is really using it. I would be interested to know your thoughts as to why "they are not." The only possible reason I can think of is because it usually means exclusive arrangements which is already done with IP Relays tables or SMTP AUTH accounts. Any TLS security advantage is not guarantee between multi-hop routes. > Opportunistic encryption is fine, but I don't see that as relating > to CSV one way or the other. If you want to do CSV checks and then > STARTTLS, you can easily do so. hmmm, the way I see it is probably makes sense after TLS (and possible SMTP AUTH) is established. Here is me reasoning: From RFC 2847: 5.2 Result of the STARTTLS Command Upon completion of the TLS handshake, the SMTP protocol is reset to the initial state (the state in SMTP after a server issues a 220 service ready greeting). The server MUST discard any knowledge obtained from the client, such as the argument to the EHLO command, which was not obtained from the TLS negotiation itself. The client MUST discard any knowledge obtained from the server, such as the list of SMTP service extensions, which was not obtained from the TLS negotiation itself. The client SHOULD send an EHLO command as the first command after a successful TLS negotiation. This could suggest TLS trumps CVS or CVS trump/alter the SASL/TLS standard behavior. A server can offers SASL/TLS which the client may use if offered. When the client issues its EHLO domain, could the server CVS logic be activated in such a way to turn off SASL or TLS EHLO response extensions display? For example: Client - SASL, TLS compliant, may or may not be CVS compliant Server - SASL, TLS, CVS compliant Client connects to server:: S: 220 mail.example.org SMTP service ready C: EHLO mail.john.org CVS activated. You have two scenarios. #1 Client is non CVS compliant and the normal SMTP extension exposes TLS and possible AUTH and other MARID features. S: 250-mail.example.org welcomes you S: 250-SIZE S: 250-SUBMITTER S: 250-AUTH LOGIN [plus other SASL methods. using LOGIN for simplicity] S: 250 STARTTLS #2 Client is CVS compliant. What will be the response? S: 250-mail.example.org welcomes you S: 250 SIZE What you are saying that CVS should not change the response? Right? Ok, I can see that and it makes sense for scenario #2 we have: #2 Client is CVS compliant. Normal SMTP extension response. S: 250-mail.example.org welcomes you S: 250-SIZE S: 250-SUBMITTER S: 250-AUTH LOGIN S: 250 STARTTLS However, the problem (design conflicts) I see is more overhead and whether there is a need for any more validation. If the client CVS is compliant and is accepted, do we need anything else? My plan for implementation, as it has been for all the LMAP (now MARID) is to delay all validation overhead until it is 100% absolutely necessary. Lets go thru this and lets assume that we continue displaying the SMTP extensions after a successful CVS validation has taken place. Scenario 2.1: Client continues with a TLS and fails. Seems easy enough, the transaction doesn't continue. Scenario 2.2: Client continues with a TLS and succeeds In this case, the client per RFC 2847 reissues the EHLO C: STARTTLS S: 220 Go ahead C & S: C: EHLO mail.john.org So what I see here for a CVS server, it needs to turn off CVS validation at this point and offer a new set SMTP extension responses: S: 250-mail.example.org welcomes you again! S: 250-SIZE S: 250-SUBMITTER S: 250 AUTH LOGIN The new implementation question here is whether SUBMITTER and/or AUTH LOGIN are still required. I have no trouble removing SUBMITTER (Badly quoting Dorothy Parker: "Don't throw it away. Throw it away with full force!"). But with SMTP AUTH we now begin to get new design issues and conflicts of whether AUTH is required. This will change quite a few things because the traditional SMTP mode of operation is that trusted transaction using SMTP AUTH or IP relay tables allows for routing, and to allow routing, well, that means "trust!" So to keep with tradition, compatibility, reduce overhead and most importantly sysop expectations for operations intact with all their roaming users, we have no choice but to implement a delayed CVS processing after TLS is applied and the establishment of any SASL negotiation as well. In short: I don't think CVS will directly change TLS but it will change how the SMTP extensions are altered. Will CVS trump SMTP AUTH? It may if its applied before the TLS process. Make sense? Thanks -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 20:57:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04250 for ; Wed, 30 Jun 2004 20:57:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i610gj8X081857; Wed, 30 Jun 2004 17:42:45 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i610gjev081856; Wed, 30 Jun 2004 17:42:45 -0700 (PDT) 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.9) with ESMTP id i610gikj081849 for ; Wed, 30 Jun 2004 17:42:44 -0700 (PDT) (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.34) id 1Bfpf0-0007DZ-UA for ietf-mxcomp@imc.org; Wed, 30 Jun 2004 19:42:50 -0500 To: "IETF MARID WG" References: <16611.8411.102438.87387@giles.gnomon.org.uk> <20040630220353.GX13225@dumbo.pobox.com> <16611.15427.708207.855024@giles.gnomon.org.uk> From: wayne Reply-To: "IETF MARID WG" Date: Wed, 30 Jun 2004 19:42:42 -0500 In-Reply-To: <16611.15427.708207.855024@giles.gnomon.org.uk> (Roy Badami's message of "Wed, 30 Jun 2004 23:18:43 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.midwestcs.com: domain of midwestcs.com designates 206.222.212.237 as permitted sender) client-ip=206.222.212.237; envelope-from=wayne@midwestcs.com; helo=midwestcs.com; X-SA-Exim-Connect-IP: 206.222.212.237 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@midwestcs.com Subject: Re: The problem with Unified SPF Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on backbone.midwestcs.com X-Spam-Status: No, hits=-5.3 required=4.0 tests=AWL,BAYES_00,GREYLIST_ISWHITE autolearn=ham version=2.63 X-SA-Exim-Version: 4.0 (built Sat, 24 Apr 2004 12:31:30 +0200) X-SA-Exim-Scanned: Yes (on backbone.midwestcs.com) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <16611.15427.708207.855024@giles.gnomon.org.uk> Roy Badami writes: > Meng> mta1.domain.com. TXT "v=spf1 a -all" > Meng> domain.com. TXT "v=spf1 include:this include:that a mx ?all" > > Which (almost) boils down to CSV, but using SPF syntax instead of SRV > records. Correctly, although the SPF syntax allows for more flexibility and extensibility. > As it stands, your example still allows anyone to forge a HELO domain.com Sort of. For whitelisting purposes, the only people who can "forge" domain.com in the HELO are those that are allowed by the domain.com SPF record. While this SPF record is not as tight as it could/should be, in practice I don't see much of a problem. Anyone that you trust enough to send email using your domain in the 2821.FROM or 2822.From: would almost certainly be trusted not to forge your 2821.HELO. However, you are right that because the domain.com SPF record ends in ?all, people can't immediately reject random zombie machines that use HELO domain.com. There are two ways to "fix" this: 1) domain.com can transition from using ?all to using ~all or -all 2) if the scope macro variable is allowed (it was suggested as part of the Unified-SPF), then you would need to have something like this: mta1.domain.com. TXT "v=spf1 a -all" domain.com. TXT "v=spf1 include:this include:that a mx redirect=%{scope}._spf.%{d}" helo._spf.domain.com. TXT "v=spf -all" *._spf.domain.com. TXT "v=spf ?all" The extra DNS lookup would only be required if the email didn't pass the other tests. For most domains, this will usually happen only in the case of spam. Actually, there has also been a third suggested way for Unified-SPF to fix this. Use a different version tag, such as: domain.com. TXT "v=spf1 include:this include:that a mx ?all" domain.com. TXT "v=spf1-helo -all" Gain, the complicated cases are only needed for domains that are waffling about their email policies, but want a tight email policy in certain scopes. Personally, I think something like the scope macro-variable needs to be done in Sender-ID anyway since the current SPF records have all been published under the assumption that they apply to 2821.FROM and 2821.HELO scopes and the 2822.From: scope is not always going to be the same. -wayne From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 22:09:49 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07266 for ; Wed, 30 Jun 2004 22:09:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i611x1kI089780; Wed, 30 Jun 2004 18:59:01 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i611x1OX089779; Wed, 30 Jun 2004 18:59:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from xuxa.iecc.com (xuxa.iecc.com [208.31.42.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i611x0Kb089772 for ; Wed, 30 Jun 2004 18:59:00 -0700 (PDT) (envelope-from sb0-0600c6bbe6-johnl@iecc.com) Received: (qmail 14012 invoked by uid 100); 1 Jul 2004 01:59:06 -0000 Date: 1 Jul 2004 01:59:06 -0000 Message-ID: <20040701015906.14011.qmail@xuxa.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: Who are we accrediting? Organization: I.E.C.C., Trumansburg NY USA Cc: gconnor@nekodojo.org Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >I think checking the HELO *alone* is not an adequate solution to the >problem set. I don't think CSV alone is enough to be effective >against spam coming from big ISPs, where good and bad mail may flow >from the same MTA. With any MTA of any size, you're going to get a mix of good and bad mail. A fairly fundamental question is whether we consider that to be a fact of life that MTA operators can't control, or we consider MTA operators to be responsible for the mail that they send, and evalute them in view of their entire mail stream. I realize that opinions differ, but I would like to see a scheme like CSV that uses an IP address to identify an MTA, and handle individual messages using something like Domain Keys that authenticates the message itself rather than a probably shared message source. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor "I shook hands with Senators Dole and Inouye," said Tom, disarmingly. From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 22:09:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07284 for ; Wed, 30 Jun 2004 22:09:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i611uRlm089643; Wed, 30 Jun 2004 18:56:27 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i611uR26089642; Wed, 30 Jun 2004 18:56:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.ecotroph.net [216.93.164.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i611uQfE089634 for ; Wed, 30 Jun 2004 18:56:26 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.0.1.153] ([::ffff:64.83.8.178]) (AUTH: LOGIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Wed, 30 Jun 2004 21:56:30 -0400 id 0005C66E.40E36F4E.00000C1E In-Reply-To: <002901c45f01$c4d7f5b0$6401a8c0@hdev1> References: <20040630222643.3308.qmail@xuxa.iecc.com> <002901c45f01$c4d7f5b0$6401a8c0@hdev1> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "IETF-MXCOMP" From: Andrew Newton Subject: Re: CSV and STARTTLS Date: Wed, 30 Jun 2004 21:56:28 -0400 To: "Hector Santos" X-Mailer: Apple Mail (2.618) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jun 30, 2004, at 8:24 PM, Hector Santos wrote: > The only possible reason I can think of is because it usually means > exclusive arrangements which is already done with IP Relays tables or > SMTP > AUTH accounts. Any TLS security advantage is not guarantee between > multi-hop routes. Not that I disagree with this observation, but couldn't it also apply to CSV since it is doing the same thing? Or in other words, if it isn't worth it to authenticate via TLS because SMTP is a hop-by-hop protocol, why is CSV authentication more compelling? -andy From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 22:13:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07412 for ; Wed, 30 Jun 2004 22:13:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6123sd3090007; Wed, 30 Jun 2004 19:03:54 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6123sKj090006; Wed, 30 Jun 2004 19:03:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from xuxa.iecc.com (xuxa.iecc.com [208.31.42.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6123q2o089999 for ; Wed, 30 Jun 2004 19:03:53 -0700 (PDT) (envelope-from sb0-0600c6bbe6-johnl@iecc.com) Received: (qmail 15276 invoked by uid 100); 1 Jul 2004 02:03:59 -0000 Date: 1 Jul 2004 02:03:59 -0000 Message-ID: <20040701020359.15275.qmail@xuxa.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: Re: CSV and STARTTLS In-Reply-To: <16611.17449.310982.114325@giles.gnomon.org.uk> Organization: I.E.C.C., Trumansburg NY USA Cc: roy@gnomon.org.uk Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Andrew> Opportunistic encryption with peer authentication using > Andrew> TLS happens every day on the Internet. > >I question that peer authentication is commonplace (although I don't >doubt that it happens every day). I get the impression most people >use self-signed certs with STARTTLS. I looked at a bunch of the certs that my MTA met while sending mail today. I'd estimate that about half of them were signed by one of the commercial signers familiar from web SSL certs, and the other half were self-signed. It seems unlikely to me that there's any widescale authentication going on, since the unsigned half would all fail, and I can report that I don't think I've ever seen a remote MTA reject my certs which are only signed by my own local CA whose cert is only known to machines on my network. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY http://www.taugh.com From owner-ietf-mxcomp@mail.imc.org Wed Jun 30 23:13:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09773 for ; Wed, 30 Jun 2004 23:13:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6133a4c093807; Wed, 30 Jun 2004 20:03:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6133as5093806; Wed, 30 Jun 2004 20:03:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zardoc.esmtp.org (adsl-63-195-85-27.dsl.snfc21.pacbell.net [63.195.85.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6133aBg093799 for ; Wed, 30 Jun 2004 20:03:36 -0700 (PDT) (envelope-from ca+envelope@esmtp.org) Received: from zardoc.esmtp.org (localhost.endmail.org. [127.0.0.1]) by zardoc.esmtp.org (sendmail X.0.0.PreAlpha13) with ESMTP (TLS) id S00000000407DA8AD00; Wed, 30 Jun 2004 20:03:52 -0700 Received: (from ca@localhost) by zardoc.esmtp.org (8.13.0/8.12.10.Beta0/Submit) id i6133qPx008750 for ietf-mxcomp@imc.org; Wed, 30 Jun 2004 20:03:52 -0700 (PDT) Date: Wed, 30 Jun 2004 20:03:52 -0700 From: Claus Assmann To: ietf-mxcomp@imc.org Subject: Re: CSV and STARTTLS Message-ID: <20040701030352.GA309@zardoc.esmtp.org> Mail-Followup-To: Claus Assmann , ietf-mxcomp@imc.org References: <20040630222643.3308.qmail@xuxa.iecc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040630222643.3308.qmail@xuxa.iecc.com> User-Agent: Mutt/1.5.6i Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Jun 30, 2004, John Levine wrote: > MTA. If people were going to use TLS certs to authenticate their > mail channels, they'd be doing so already, but they're not. It's hard to do that with the hierarchical structure of X.509 unless you are a commercial entity and you want to pay money a certain company.... I exchange CA certs with some people (and enforce authenticated mails) but it's a bit ugly to maintain. There was a draft that described using the OpenPGP trust structure ("web of trust") which unfortunately didn't lead to an implementation.