Ted Hardie <hardie@xxxxxxxxxxxx> 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@xxxxxxx>