MARID-BoF
John Leslie <john@jlc.net> Fri, 27 February 2004 20:02 UTC
Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20307 for <ietf-archive@odin.ietf.org>; Fri, 27 Feb 2004 15:02:14 -0500 (EST)
Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1Awo12-00046i-L0 for ietf-list@asgard.ietf.org; Fri, 27 Feb 2004 14:51:20 -0500
Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1Awo0R-00044h-4n for ietf@asgard.ietf.org; Fri, 27 Feb 2004 14:50:43 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19926 for <ietf@ietf.org>; Fri, 27 Feb 2004 14:50:40 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awo0P-0004Tg-00 for ietf@ietf.org; Fri, 27 Feb 2004 14:50:41 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwnzQ-0004ME-00 for ietf@ietf.org; Fri, 27 Feb 2004 14:49:41 -0500
Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx with esmtp (Exim 4.12) id 1AwnyX-0004Fq-00 for ietf@ietf.org; Fri, 27 Feb 2004 14:48:45 -0500
Received: by mailhost.jlc.net (Postfix, from userid 104) id 6F967E07F4; Fri, 27 Feb 2004 14:48:41 -0500 (EST)
Date: Fri, 27 Feb 2004 14:48:41 -0500
From: John Leslie <john@jlc.net>
To: Ted Hardie <hardie@qualcomm.com>
Cc: IETF Discussion <ietf@ietf.org>
Subject: MARID-BoF
Message-ID: <20040227194841.GG69134@verdi>
References: <Pine.LNX.4.44.0402260836350.6202-100000@lilith.rgb.private.net> <8C2DE558-6872-11D8-997E-000A95CD987A@muada.com> <20040226205953.GA68458@verdi> <p06020401bc64251fe8d7@[205.214.163.20]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <p06020401bc64251fe8d7@[205.214.163.20]>
User-Agent: Mutt/1.4.1i
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: owner-ietf@ietf.org
Precedence: bulk
Ted Hardie <hardie@qualcomm.com> wrote: > > http://www.ietf.org/ietf/04mar/marid.txt In particular: ] Thursday, March 4 at 0900-1130 ] ... ] Current Proposals (1 hour together) ] MTAMARK - draft-stumpf-dns-mtamark-01.txt MTAMARK (17 pages) proposes DNS records in in-addr.arpa to indicate that a particular IP address (or range) is or is not intended to be a Mail-Transfer-Agent. The details of what record formats to use, IMHO, deserve to be discussed by an IETF Working Group. This proposal depends on the authenticity of the in-addr.arpa delegations; thus poorly-maintained regions of in-addr.arpa will necessarily authorize too much or too little. Further discussion of how to determine which regions are well-maintained will be needed, although clearly that can be a local decision. I would suggest the possibility of specifying a similar mechanism not under in-addr.arpa -- but instead under the domain records of any domain one might wish to trust -- showing whether that region of in-addr.arpa is considered well-maintained and trustworthy. ] DRIP - draft-brand-drip-02.txt DRIP (21 pages) proposes adding A(ddress) records for named subdomains to indicate which IP addresses are assigned to SMTP servers authorized to send mail for that domain. This proposal gives a far better presentation of how to implement for IPv6. At first blush, it seems easier to classify well-behaved domains that well-maintained regions of in-addr.arpa; but IMHO the problems are similar, and the implementation of DRIP within MTA software seems more complicated. In any case, I would suggest a parallel specification of vouching for the behavior of domains, under the domain records of any domain one might choose to trust. ] RMX - draft-danisch-dns-rr-smtp-03.txt RMX (35 pages) proposes adding RMX records to return various kinds of methods to determine whether a particular SMTP sender is authorized to send mail for particular email addresses. Adding new DNS record types, of course, is fatal for quick deploying. Thus RMX also presents an alternative to accomplish this with TXT records. IMHO, this scheme is even more complicated, and solves less of the problem. ] DMP - draft-fecyk-dmp-01.txt DMP (36 pages) proposes adding DMP records to identify computers authorized to send SMTP email in the name of a domain, using TXT records in a named subdomain. I'm getting bleary-eyed -- I'm no longer sure which of these proposals is most complicated. This one, at least, appears to present complete details sufficient to implement from. However, I doubt that forcing email with particular From addresses to use a limited set of servers will be considered acceptable. ] SPF - draft-mengwong-spf-00.txt SPF introduces a language for "email-related declarations" in DNS. Messages which do not satisfy the "description" advertised are considered "not legitimate." SPF specifically allows caching the DNS replies. Caching is a general problem in DNS, in that the controls on expiring DNS information are weak. IMHO, the weaknesses of DNS in withdrawing no-longer-valid entries MUST be a charter item for MARID. ] FSV - draft-levine-fsv-00.txt FSV (7 pages -- thanks, John!) proposes both "block" and "factored" DNS records, as A(ddress) records under a _fsv subdomain of the "sending" domain, returning a code for a valid SMTP sendor address. This, IMHO, is subject to the usual comments about end-users accepting limits on which SMTP servers they may use. >> The BoF will explicitly consider how DNS-based MTA authentication >> mechanisms would be implemented and deployed, and it will consider >> the impact on the overall DNS infrastructure of this deployment. In general, I predict a very boring BoF if only those who read every page of every proposal are allowed to speak. ;^) IMHO, the central issue is the level of trust to be given to a particular SMTP sender (by IP address) not well-known to the SMTP receiver. I published my thoughts on this in http://www.jlc.net/whitecap.html (Although it's obvious how to recast this into a DNS-dependent proposal, I do not intend to do so.) I'd like to add a warning to limit the time you spend listening to proposals that the speaker may describe as "the only way" to "cure the spam problem". There is, however, no room for question that _some_ IETF Working Group with a charter relating to spam-abatement is justified. I hope those present will agree that a charter allowing discussion of all these drafts is appropriate. -- John Leslie <john@jlc.net>
- RE: digital signature request Neil Carpenter
- digital signature request gnulinux
- Re: digital signature request Dave Aronson
- Re: digital signature request John Stracke
- Re: digital signature request Dave Aronson
- Re: digital signature request Harald Tveit Alvestrand
- Re: digital signature request John Stracke
- Re: digital signature request Dave Aronson
- RE: digital signature request Ramiro Muñoz Muñoz
- Re: digital signature request gnulinux
- Re: digital signature request Stephen Sprunk
- Re: digital signature request Dave Aronson
- Re: digital signature request Vernon Schryver
- Re: digital signature request gnulinux
- Re: digital signature request Dave Aronson
- Re: digital signature request David Morris
- Re: digital signature request John Stracke
- Re: digital signature request Dean Anderson
- RE: digital signature request gnulinux
- RE: digital signature request Vernon Schryver
- Re: digital signature request Jake Nelson
- Re: digital signature request Robert G. Brown
- RE: digital signature request Robert G. Brown
- Re: digital signature request Dave Aronson
- RE: digital signature request Vernon Schryver
- Re: digital signature request Iljitsch van Beijnum
- Re: digital signature request Ed Gerck
- Re: digital signature request Vernon Schryver
- Re: digital signature request Ed Gerck
- Re: digital signature request Clint Chaplin
- Re: digital signature request Robert G. Brown
- Principles of Spam-abatement John Leslie
- Re: Principles of Spam-abatement Ted Hardie
- Re: digital signature request James Seng
- Re: digital signature request Dean Anderson
- Re: digital signature request Dean Anderson
- Re: digital signature request Ed Gerck
- Re: Principles of Spam-abatement Dave Crocker
- Re: digital signature request Stephen Sprunk
- Re: Principles of Spam-abatement John Leslie
- Re: Principles of Spam-abatement John Leslie
- Re: Principles of Spam-abatement Ted Hardie
- MARID-BoF John Leslie
- Re: Principles of Spam-abatement John Leslie
- Re: Principles of Spam-abatement Vernon Schryver
- Re: Principles of Spam-abatement John Leslie
- List for MARID discussions (Re: Principles of Spa… Harald Tveit Alvestrand
- Re: Principles of Spam-abatement Dave Crocker
- Re: Principles of Spam-abatement Dave Crocker
- Re: Principles of Spam-abatement Paul Vixie
- Re: Principles of Spam-abatement Dave Crocker
- Re: MARID-BoF Markus Stumpf