ietf
[Top] [All Lists]

MARID-BoF

2004-02-27 13:02:14
Ted Hardie <hardie(_at_)qualcomm(_dot_)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(_at_)jlc(_dot_)net>