Re: ANNOUNCE: I-D draft-ietf-marid-SPF3-00, etc.

On Thu, 2004-09-16 at 21:58, Matthew Elvey wrote:

> Comparison of SPF3 and CSV+MPR:

> Of bind, GoDaddy and ZoneEdit, only BIND supports what CSV requires. 
> Technically, it's inferior, in that its usage of DNS is less efficient 
> and less standards-based.  MPR also has the cool bit-mapped fields for 
> explicit protection of 2822.From:, etc.  This could be added to SPF3.

Are you referring to web-based GUI interfaces for DNS entries to support
services?  Looking at their documentation, it was not clear that it was
possible to enter a TXT record either.  I would imagine do-it-yourself
providers will offer needed interfaces for elements supporting their
service once it becomes prevalently needed.  CSV is simple enough to
have it defined without any user intervention other than selecting the
host.

It is not clear what was being compared in this sentence.  I will assume
you were saying CSV is inferior.  : )

The SRV record is used extensively by Microsoft and acts as a
replacement for their WINS.  On some older versions of Bind, the name
checking is disabled to allow the underscore.  Use of the SRV record
does not require a text parser to interpret the record.  The SRV record
also automatically assembles relevant address records reported in the
additional data section.  Use of a TXT record which encodes other
domains, users, error messages, hostnames, addresses, settings, macros,
and is extensible will require a forever evolving parser.

With more and more flavors of TXT records employed due to the example
made by SPF, as well as adopting a practice of using wildcards, any use
of an extensible text script is not without risk.  Unlike other DNS
records with content defined by the record type, the TXT record should
assume opaque text strings.

Unlike SPF, names are consistently used and do not require the double
entry of host addresses as SPF may.  The alternative to replicate
address entry when using SPF, is to use record references and then cause
subsequent DNS lookups to then obtain the addresses for each reference. 
SPF is neither more standard or efficient.  The MPR name lists also
removes the need for subsequent lookups which are the bane of the SPF
approach.

The MPR lists, being a separate from the MTA authentication and
authorization, avoids the problems of "open" lists that invite
spoofing.  MPR can be deployed with an "open" list as a SHOULD without
any exploit concerns.  By marking or "coloring" the mail as being
outside the nominal mail channel, this should offer better consumer
protection than that achieved with Sender-ID's PRA algorithm yet not
breaking mail forwarding.

> =-=-=-=-=
> With respect to being able to outright reject forgeries without breaking 
> forwarding: 
> With HELO checks + A&R, I can see this becoming reasonable BCP.  Here's how:
> Forwarders (and mailing list hosts) will be expected to be running 
> MARID on their MTA.  If they are too lazy to do so, then they will be 
> found to be forwarding on obvious (to anyone using MARID) forgeries, and 
> thus their reputations will (justifiably) suffer.  It will probably not 
> be fair to blame 'em for all spam they forward, but it will be fair to 
> blame them for forwarding on obvious forgeries. The responsible 
> forwarders running MARID can be expected to have good HELO reputations.

Is this in reference to CSV?

-Doug