On Wed, 25 Apr 2001, Chris Newman wrote:
: Now that I've been part of the iPlanet Messaging Server team with a
: released product using laser-style intranet routing, I'm not comfortable
: standardizing a schema for use with SMTP. The idea of multiple MTAs on a
: network which all believe a particular envelope recipient is "local", but
: do different things makes me very uncomfortable. And dealing with multiple
: hosted domains on the same server doesn't improve matters.
:
: Now if we kept the same laser attributes but specified them for use with
: LMTP (RFC 2033), then I'd consider that a great idea. But using them with
: SMTP strikes me as an unwise violation of the Internet mail routing model.
I disagree with some parts of your first paragraph and agree with
parts of your second paragraph. Actually I think this issue is a bit
more complex then LMTP vs SMTP. I also think there is a distinction
between multiple MTA's believing a recipient is "local" and LDAP
routing within an administrative domain.
LMTP is not yet a widely adopted network transport method, and there
are lots of systems (mailhost) that are responsible for final delivery
that only speak SMTP. It is also not uncommon for a site to support
some systems that support LMTP and others that support SMTP for
delivery to the final destination.
I would not be against extending the capabilities of the draft to
support LMTP capable delivery as well as SMTP delivery. I have
struggled with some of this myself.
One thought was to do:
mailhost=imap01.domain.com:LMTP
Another was to possibly:
mailhost=imap01.domain.com
mailhostproto=lmtp
mailhostport=2003
However to date we have not wanted to taint either the Laser
inetlocalmailrecipient objectclass or the Netscape mailrecipient
objectclass (we use both on a regular bases.... I prefer mailrecipient
myself as the mail attribute is used my most clients for outbound
addressing in and LDAP environment [except for the sites we keep
running across that do not use it with fullyqualified host names] ).
Anyhow, we have evaluated attributes like lmtphost and lmtpport, or
messagestorehost and messagestoreproto to try and support this.
On a similar vein I have seen requirements for "inner" and "outer"
routes. For instance, suppose you have subscribers who need to go to
"predelivery" machines for some reason (opt-in virus scanning, content
filtering, etc). It it cumbersome at best to overload mailhost for all
these purposes.
As far as using these for routing, we try to not do "different things"
unless we are the mailhost. We then use additional attributes to route
beyond the "different thing" mailhost. So we use mailhost for the
outer route via SMTP, and some other attributes for additional inner
routes via SMTP or LMTP, once we are the "local" mailhost MTA.
Randall
This archive was generated by hypermail 2.1.2 : Thu Oct 24 2002 - 10:31:46 PDT