None of this experience seems particularly applicable to the question at
hand,
where we are comparing two different mechanisms for exporting only a small
amount of information - SMTP, or some other protocol (of which LDAP is only
a
token example). If an enterprise is reluctant to export "information about
their users" in general, then they will be about as reluctant to do so via
SMTP
as via some other protocol.
I'm afraid this is another piece of theoretical considerations that fly in the
face of actual experience. The obvious counterexample is HTTP.
The relevance of HTTP is even less obvious to me because HTTP and directory
services (LDAP or otherwise) tend to be used in very different ways. I don't
see many sites exporting their company directories via either HTTP or LDAP.
Nor do I see how any of this is relevant to the problem of exporting recpient
capability information for content negotiation.
I do think it's reasonable to assume that any other protocol server is
likely
to be viewed as a separate maintenance burden that needs to be justified,
whereas
a wart on the side of SMTP will probably be viewed as just some incremental
pain
that must be endured. But if large sites end up needing a separate
database server
anyway to support CONNEG because the MX servers don't have direct knowledge
of
recipient capabilities, then that separate maintenance burden is there
anyway,
at least for those sites.
While I obviously cannot speak for all large sites, I can tell you that
database usage is sufficiently pervasive inside the sites I'm familiar with
that this is basically a nonissue.
Well, I guess it hinges on what is meant by "large". Are there a significant
number of sites "large" enough to not have their MX servers deliver directly
to recipient mailboxes, but not "large" enough to be already using a database
to store recipient information? I suspect the answer is yes because there
are other reasons besides scale that a site would not have its MX servers
deliver directly to recipient mailboxes. Inbound firewalls are fairly common,
and some of them operate as relays.
First, this is not a quick dismissal, it is a conclusion based on decades of
experience, experiencce in which LDAP only plays a small and relatively recent
part.
not to dismiss your experience at all - but your stated justification didn't
seem (to me) to be particularly relevant.
Second, I believe the notion of using a directory for this sort of thing has
been discussed in the FAX WG on several occasions. And while it is axiomatic
that nothing precludes the WG's having chosen to use a directory, nothing
requires that a WG pursue it either. I take the rather stunning lack of
interest in this overall approach as yet another sign that it is seen as
nonviable.
again, is this a fax-specific extension or is it supposed to be generally
applicable? I'll readily admit that fax machines don't need a directory.
but should the level of interest within the fax group be used as a measure
of the merit of the idea for other uses of email?
I think there are benefits that favor of a rescap-like approach also.
One is that it allows the conversion to be done by the sender's
MUA - or at any rate as early as possible - whereas with SMTP
this is not always possible because a number of sites either
block access to port 25 on nonlocal servers, or impose interception
proxies that pretend to be the remote server even if it's really a
relay or firewall. I'm very much in favor of having negotiation
and transformation work predictably and with accountability to the
sender rather than having some random MTA in the chain decide that
a conversion is needed.
I agree that predictability is nice, but that's not something any approach can
ever guarantee. Indeed, I can argue that a directory approach will lead to
less
predictability, not more, if for no other reason than directory access will
tend to work locally but not remotely. SMTP access with appropriate caching,
on
the other hand, has the potential to work both locally and globally.
The last two statements seem fairly odd. Maybe the problem is the use of the
word "directory" which isn't my favorite word for this anyway. So let's not
call this a directory - let's call it a capability discovery protocol. Now if
the capability discovery protocol is defined in such a way that in order for
your recipients to benefit from content negotiation you have to make it
accessible
(just like if you want to be able to accept mail then you have to make port 25
accessible) then it seems fairly likely that sites that want to enable content
negotation for their recipients will do so. On the other hand, port 25 is one
of the few ports that is commonly blocked/filtered for outgoing traffic -
perhaps even more often (and with more drastic filtering) than port 80.
So the argument that a facility that requires direct connection over port 25
(from the origin to the MX server, not necessarily to the final MTA)
in order to work properly (i.e. in order to let the sender control the
conversion) will function both locally and globally seems a bit dubious.
Keith