[Top] [All Lists]

Re: "CSV" [not comma-separated values]

2005-05-26 03:55:59

On Wed, 25 May 2005, Bruce Lilly wrote:
On Wed May 25 2005 13:46, Tony Finch wrote:

You'll have to explain how CSV conflates sending and receiving,

As noted in the SPF discussion, MUA EHLO/HELO names are often extracted
from return path information and are frequently not configurable.

None of the LMAP proposals are applicable for MUA-MSA communication. As I
said before, you can't expect direct MUA-MX communication to work very
well because of MUAs' simplistic SMTP implementations and because of MX's
anti-spam strictness, and no common MUAs support direct-to-MX
communication. So your objections are mistargeted, and what is more your
explanation has nothing to do with conflating sending and receiving.

Some of your following comments also seem to assume that the sender is an
MUA. I'll address them anyway, even though this is somewhat redundant.

and why tying an IP address to a hostname is a problem.

[unstable sender IP addresses]

If such a sender wants to use CSV then they can use dynamic DNS updates
and low TTLs. But in practice outgoing MTAs have stable IP addresses so
this isn't a problem for the vast majority of sites.

Transports other than
TCP are not a problem because CSV isn't applicable to them.

The csv draft doesn't say so.  It *does* say "each SMTP session" and
"Obtain the remote IP address of the TCP connection".

Therefore it's obvious that if there's no TCP connection then CSV isn't
applicable. But I suppose it could be made explicit for readers who can't
draw implications.

CSV isn't mandatory and it falls back gracefully if the sending site
hasn't deployed it.

You'll have to explain what you mean by "deployed" w.r.t. "sending site".

I use the term "site" somewhat informally to mean some computing
infrastructure and its users, all operating according to some
computing policies which may be stricter than is required by Internet
Standards. So if a site has deployed some technology one would expect them
to have informed their users how to use the technology effectively (e.g.
how to configure clients for use at that site) and what site policies
apply to that technology.

For example, if a site deploys CSV then its mobile end-users will probably
be subject to policies saying that their software should use an
appropriate host name in HELO for sending email, or that they should use
TLS+AUTH+RFC2476 for remote message submission.

* I would add that the CSV draft fails to state *which* SRV record(s)
(service, protocol, etc.) to consult,

Incorrect. Section 5 of the CSA spec includes the SRV record specification

and the SRV RFC (2782) is rather opaque (e.g. the syntax specified
begins with _Service._Proto.Name TTL Class but the example seems to
be missing Name, TTL, and Class

It assumes that the reader understands the master zone file format, which
is reasonable for a DNS RFC.

It doesn't try to force people to fix their MTAs that state
invalid hostnames in their HELO commands.

Maybe. But contrary to RFC 2821 it says "A sending SMTP client MUST
supply a published domain name as the parameter to an SMTP HELO or EHLO.
[sic]".  2821 (and 821 before it) explicitly permits an address literal.
There is an (incorrect) assumption throughout the draft that EHLO/HELO
always entails a domain name.

You are making the fallacy of arguing from the general to the specific.
Something that is not true in general may certainly be true in specific
circumstances: in this case the specific circumstance is an SMTP client
that supports CSA.

However I have proposed an extension to CSA which specifies how to put CSA
SRV records in the reverse DNS, so that they can be used with clients that
state an address literal after HELO or which do not say HELO at all.

f.a.n.finch  <dot(_at_)dotat(_dot_)at>