ietf-smtp
[Top] [All Lists]

"CSV" [not comma-separated values]

2005-05-25 12:42:07

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.  I'm
not talking about obscure products, I'm referring to several of the most
widely used MUAs.

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

It's a matter of context; it's fine for MX, because a sender needs to be
able to determine where to send, and the receiver needs to be prepared
to receive mail.  That does not apply to sending, because a sender requires
no such preparation, and as the sender initiates a connection (N.B. with
no prior arrangement required), the receiver doesn't need to be able to
"find" the sender.  A receiver needs to have a reasonably stable IP address
(at least w.r.t. to DNS TTLs), whereas a sender needs not.  A given sender
might have one IP address now and (e.g. via DHCP or a different physical
connection) have a different IP address a minute, an hour, etc. from now.
It's not unlike a face-to-face meeting at home; somebody wishing to contact
me at home needs an address to be able to do so -- upon knocking on the door,
I answer and the communications begins.  I don't need to be able to know
where to find the initiator; he comes knocking.  He may approach from one
direction today and another tomorrow -- that's irrelevant.

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".

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 see things like "independent accreditation services", and "domain",
and "SRV record" [*] etc. none of which are likely to be under the control
of a typical mobile end-user email sender.

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.

* I would add that the CSV draft fails to state *which* SRV record(s)
(service, protocol, etc.) to consult, how to handle timeouts, etc.,
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 -- in spite of the curious remark that
"the example near the end shows this clearly" (perhaps the example should
use fewer defaults or clearly indicate field delimiters)).