ietf-clear
[Top] [All Lists]

[clear] Plan of Action for CSV?

2005-06-20 13:59:34
David Woodhouse <dwmw2(_at_)infradead(_dot_)org> wrote:
On Mon, 2005-06-20 at 20:51 +0000, John Levine wrote:

BUT we have to draw the line somewhere in regard to encoding complexities
of people's configurations into CSV data.  I understand that life can be
complicated, but that way lies the madness that is SPF.

Let's not exaggerate the 'problem' here. Merely accepting more than one
SRV record doesn't come anywhere near the level of complexity of SPF --

   Agreed.

   It does, however, complicate the issue of getting this coded in enough
MTA software to gain widespread adoption.

   Unlike SPF, CSV should in principle be coded to run at EHLO time, which
is not something which has existing hooks in most MTA software.

in fact it never occurred to me _not_ to handle the multiple-record case
even when I was implementing CSA purely in Exim's configuration language
(http://david.woodhou.se/eximconf/include/acl-helo-csv)

   The complexity is substantial, though. One could have to do an arbitrary
number of A)ddress lookups to find whether any of them include the IP
address of the sending SMTP client; then a sanity check would be needed
to ensure that if it mached more than one, the weight and port fields
must agree. And we need to watch out that we don't paint ourselves into
a corner where two versions (priority field) cannot be advertised.

   IMHO, the spec says:
} 
} 5. Client SMTP Authorization SRV Record
}...
} Target:
} A domain name (typically the same as the EHLO domain) that resolves to
} the correct list of IP addresses.

... which means we intended _exactly_one_ list of IP addresses.

My suggestion is that a domain can have one (1) CSV record that can
point to a single name that can have as many A and AAAA records as
needed, and there we draw the line. 

I don't see the point in making that restriction. You'll get all the SRV
records in one query anyway; all you have to do is deal with them if
more than one exists. That really isn't hard, and it's the expected
normal behaviour of DNS records. I see no reason to deviate from that.

   You may get all the _SRV_ RRs in one query, but you're stuck not knowing
whether you've gotten all the A)ddress RRs. (As I understand Exim, you
have to run extra A)ddress queries anyway, so this isn't a cost to you.)

   We're facing the interoperability problem here. You've taken a reasonable
tack on what multiple SRV RRs could mean, but it significantly increases
the complexity. You've implemented a reasonable interpretation; but there
are other interpretations which will seem reasonable to other implementers.
We need to keep CSV lightweight; and frankly, I'd prefer to define more
bits in "port" than require more lookups for cases which, while they may
seem to rare to worry about, could easily be abused.

--
John Leslie <john(_at_)jlc(_dot_)net>