ietf-smtp
[Top] [All Lists]

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

2005-05-26 12:00:52


On Thu, 26 May 2005, Bruce Lilly wrote:

your explanation has nothing to do with conflating sending and receiving.

When a piece of software -- categorize it as you will -- connects to
an SMTP server and presents a domain name derived from a receiving
mailbox domain in EHLO/HELO, there is such conflation.  We might
tentatively agree that such software isn't operating according to
assumptions behind the rules of a twenty-year-old protocol, but the
present-day facts of life are such that in many cases there simply is
no other option available to such software.

That's a problem with the sender's configuration, not with CSV. I do know
of software that makes it impossible to fix this kind of configuration
problem, but these email programs are designed to talk to an MSA, in which
case the problem is moot. You claim that nevertheless it is still a
problem because in general SMTP software doesn't know what role its peer
is acting in, but again this is a fallacy because in a specific case the
site's policy can disambiguate, and in fact this kind of disambiguation
is routine in Internet email as a result of the open relay closure.

Exactly so. It seems some folks are confusing the absence of explicit
authorization information in SMTP-the-protocol with the inability to perform
authorization functions in SMTP-the-server. It has long been the case that a
viable SMTP server has to support authorization configuration, the more
flexible the better.

In fact the issue of MTA vs. MSA vs. MUA etc. is at the wrong level and
leads to irrelevant arguments about Internet email architecture. The LMAP
protocols are all intended for use with SMTP over TCP across the public
Internet routed according to RFC 974. They aren't for use within an
organization because in that case other authentication and authorization
mechanisms are more appropriate and more effective. They don't need to
care about braindead MUA software because those SMTP implementations
aren't designed for sending direct to MX.

RIght again, and continued attempts to stretch these things to apply to
MSA or delivery hops, be it in a misguided attempt to overgeneralize
the end to end principle or from a misunderstanding of real-world
architecture, need to stop.

If such a sender wants to use CSV

The problem is where the *sender* *doesn't* want to do so, but some
other party has decided to do so.

If a sender doesn't like their site's policies, they can get another ISP
or have a chat with their sysadmins or whatever.

Yup.

                                Ned