Subject: Re: Max RCPT TO: - option to negotiate?
From: Ned Freed <[email-masked]>
To: Steve Kille <[email-masked]>
Cc: Ned Freed <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, [email-masked]
Date: Fri, 27 Mar 1998 10:25:44 -0800 (PST)

> I noted the reference to Isode's PP (we do still call it PP, but for
> marketing purposes it goes under the title "Internet/X.400 Message Switch".)

I hope you won't mind if I continue to refer to it as PP. I don't call PMDF by
its marketing name either, for that matter.

> You are correct that PP does not implement SMTP pipelining and that it
> is "pipeline clean".  I don't think we would claim pipelining unless
> we made the servers take advantage of it (not a big deal to code, but
> I can't see much benefit, although you would need it for this sort of
> extension).

Um, this demonstrates a misunderstanding of the benefits of pipelining. A
server that claims pipelining but _clients_ are the ones that take advantage of
it. As such, it is beneficial to the community for a pipeline-clean server to
claim pipelining even if the client in the same software package doesn't take
advantage of it (yet).

And if you don't see the advantage, well, I would suggest that you do some
additional timing of SMTP behavior on high latency links. Pipelining often
makes a significant difference.

> You are incorrect in your belief that PP does not implement ESMTP.  We
> have supported ESMTP for some long while and continue to add ESMTP
> extensions.    However, the current relase (not the release which is
> about to ship) can be built with ESMTP turned off, so you will see
> deployed systems which appear not to have ESMTP.

Then you might want to consider enabling it on the version of PP that serves
isode.com. Both it and the half-dozen other PP servers I tested did not offer
ESMTP support.

				Ned

To: Ned Freed <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: Max RCPT TO: - option to negotiate?
Date: Fri, 27 Mar 1998 00:40:55 +0000
From: Steve Kille <[email-masked]>
Sender: [email-masked]

Ned,

You write:

 >
 >> Out of curiosity, what MTA's currently support SMTP pipelining,
 >> and what percentage market share do they currently have in total?
 >
 >Lotus Notes SMTP gateway, ISODE's PP, and MMDF do not as far as I know. (I
 >believe the latter two actually don't implement ESMTP of any sort.)
 >
 >I also suspect that Exchange, NOTES, and PP are "pipeline clean"
 > but don't say so 

I noted the reference to Isode's PP (we do still call it PP, but for
marketing purposes it goes under the title "Internet/X.400 Message Switch".)

You are correct that PP does not implement SMTP pipelining and that it
is "pipeline clean".  I don't think we would claim pipelining unless
we made the servers take advantage of it (not a big deal to code, but
I can't see much benefit, although you would need it for this sort of
extension).

You are incorrect in your belief that PP does not implement ESMTP.  We
have supported ESMTP for some long while and continue to add ESMTP
extensions.    However, the current relase (not the release which is
about to ship) can be built with ESMTP turned off, so you will see
deployed systems which appear not to have ESMTP.  

Steve Kille 
CEO, Isode

Date: Mon, 23 Mar 1998 16:28:35 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: Max RCPT TO: - option to negotiate?
To: Ned Freed <[email-masked]>
Cc: [email-masked], Arnt Gulbrandsen <[email-masked]>, [email-masked]
Sender: [email-masked]

> Ones I know of that do include: Innosoft's PMDF, software.com's Post.Office,
> ISOCOR's NPlex, SMail, and Qmail. Sendmail, Microsoft's Exchange SMTP enabler,
> Lotus Notes SMTP gateway, ISODE's PP, and MMDF do not as far as I know. (I
> believe the latter two actually don't implement ESMTP of any sort.) I've heard
> mixed reports about Pegasus Mail, possibly as a result of there being several
> different SMTP gateways for it. I've heard reports that the USDA's SMTP
> implementation in MUMPS supports pipelining, but cannot find an server to check
> out right now.

Some additions to the list:

   Cisco Multinet SMTP -- server supports pipelining, client doesn't take
                          advantage of it.
   MX -- server supports it, client takes advantage of it.
   Process Software SMTP -- doesn't support EHLO and hence no pipelining.
   CDC Mail*Hub -- doesn't support EHLO and hence no pipelining.
   
Thanks are due to Dan Wing for pointing out the first two.

				Ned

Date: Mon, 23 Mar 1998 15:19:04 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: Max RCPT TO: - option to negotiate?
To: [email-masked]
Cc: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Sender: [email-masked]

> Content-Type: text/plain; charset=us-ascii

> > It -is- protocol bloat, and with ESMTP pipelining the extra commands
> > aren't terribly expensive, so it sounds marginal.

> Sendmail 8.9.0 won't have pipelining, so it DOES mean an extra
> whole round trip per additional RCPT TO:.

> Out of curiosity, what MTA's currently support SMTP pipelining,
> and what percentage market share do they currently have in total?

Ones I know of that do include: Innosoft's PMDF, software.com's Post.Office,
ISOCOR's NPlex, SMail, and Qmail. Sendmail, Microsoft's Exchange SMTP enabler,
Lotus Notes SMTP gateway, ISODE's PP, and MMDF do not as far as I know. (I
believe the latter two actually don't implement ESMTP of any sort.) I've heard
mixed reports about Pegasus Mail, possibly as a result of there being several
different SMTP gateways for it. I've heard reports that the USDA's SMTP
implementation in MUMPS supports pipelining, but cannot find an server to check
out right now.

I also suspect that Exchange, NOTES, and PP are "pipeline clean" but don't say
so. Sendmail is the only MTA I know of that isn't "pipeline clean"; I
understand this is an artefact of the way its implemented and not easily fixed.

I have no data on market share, or at least none that I can post here. I can,
however, say that we've observed that pipelining has improved throughput in
many situations.

BTW, I have no strong feeling either way about this extension. If someone
specifies it I'll implement it in PMDF, if not I won't.

				Ned

To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked]
Subject: Re: Max RCPT TO: - option to negotiate? 
From: [email-masked]
Date: Mon, 23 Mar 1998 10:31:03 -0500
Sender: [email-masked]

--==_Exmh_634613760P
Content-Type: text/plain; charset=us-ascii

On 23 Mar 1998 15:02:49 +0100, Arnt Gulbrandsen said:
> It -is- protocol bloat, and with ESMTP pipelining the extra commands
> aren't terribly expensive, so it sounds marginal.

Sendmail 8.9.0 won't have pipelining, so it DOES mean an extra
whole round trip per additional RCPT TO:.

Out of curiosity, what MTA's currently support SMTP pipelining,
and what percentage market share do they currently have in total?

-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

--==_Exmh_634613760P
Content-Type: application/pgp-signature

--==_Exmh_634613760P--

To: [email-masked]
Cc: [email-masked]
Subject: Re: Max RCPT TO: - option to negotiate?
From: Arnt Gulbrandsen <[email-masked]>
Date: 23 Mar 1998 15:02:49 +0100
Lines: 16
Sender: [email-masked]

[email-masked]
> Does anybody see a need/desire/etc for an ESMTP option to advertise
> this limit, so the upstream end can avoid sending a RCPT TO: that
> will just get 452'd anyhow?
> 
> Straw man proposal:
> 
> 250-MAXRECIP nnn    to state that more than nnn receipts will not be accepted.

FWIW, Zmailer says X-RCPTLIMIT n for some n, but I don't know what its
SMTP response is after n RCPT TO commands.

It -is- protocol bloat, and with ESMTP pipelining the extra commands
aren't terribly expensive, so it sounds marginal.

--Arnt

To: [email-masked]
Subject: Max RCPT TO: - option to negotiate?
From: [email-masked]
Pgp-Action: PGP/MIME-signclear; rfc822=off; originator="<[email-masked]>"
Date: Sun, 22 Mar 1998 00:03:17 -0500
Sender: [email-masked]

Sendmail 8.9.0 (currently in beta test) supports a local configuration option
to limit the maximum number of RCPT TOs as documented thusly:

confMAX_RCPTS_PER_MESSAGE  MaxRecipientsPerMessage
                    [infinite] If set, allow no more than
                    the specified number of recipients in
                    an SMTP envelope.  Further recipients
                    receive a 452 error code (i.e., they
                    are deferred for the next delivery
                    attempt).

Does anybody see a need/desire/etc for an ESMTP option to advertise
this limit, so the upstream end can avoid sending a RCPT TO: that
will just get 452'd anyhow?

Straw man proposal:

250-MAXRECIP nnn    to state that more than nnn receipts will not be accepted.

Comments? 

				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

Date: Fri, 20 Mar 1998 21:58:37 -0800
From: Hans Lachman <[email-masked]>
To: Mark Horton <[email-masked]>
CC: [email-masked]
Subject: Re: Mail Routing and LDAP
Sender: [email-masked]

Mark Horton wrote:
...
> (1) Deliver [email-masked] by looking it up in the directory,
> and delivering to the physical address found in the directory.
> 
> (2) Pass [email-masked] (anything with syntax containing
> dot, equals, slash, colon, or underscore, followed by @lucent.com) to the
> directory lookup to match one or more possible people and deliver to
> their physical addresses.
...
> What it does require, if you're going to use standards-based components,
> then the LDAP client (MTA) and LDAP server have to agree on a few things.
> Most notably, they must agree on two standard attributes: the high-level
> user-visible mail address (such as "[email-masked]") and the physical
> address specifying the mail server ("[email-masked]")
> The job of the MTA, even in the simplest case (1 above) is to take a
> high-level name, look it up in the directory, and get back the physical
> address so it can route the mail there.  For example, the first could be
> called "mail" and the second "MailForwardingAddress".  Or it could look
> for attribute "id" value "mark", and still return a MailForwardingAddress.
> At a bare minimum, we need to agree on these two attributes.

I agree that this would be the bare minimum to standardize
(if any of this is standardized at all).  This would allow different
vendors' MTAs within an organization to do direct routing to each
other, as least for case (1).  Some vendors might still want to
implement different approaches for whatever reason, but I think
there's value in trying to standardize this at some level.

The 'mail' attribute seems to be the choice for the high-level
user-visible address.  As for the physical delivery address, I'd
rather not use 'mailForwardingAddress' since we're already using
that for "forwarding" (one account forwarding its mail to one or
more other accounts; typically user-controlled, like the ".forward"
file), which we consider to be different from "routing" (getting
the mail to the account in question; typically administrator-
controlled, like putting routing aliases in the sendmail aliases file).
For "routing" we have an attribute called 'mailRoutingAddress'.
Our MTA expects that this contains the physical delivery address
(although it's optional if 'mailHost' is set, since we can route
based on that).

For case (2) it may be a little harder to get consensus among
MTA vendors.  Regarding doing address matching against the 'cn'
attribute, we instead provide an attribute 'mailAlternateAddress'
to explicitly set the user's additional email addresses (beyond
the one in their 'mail' attribute).  This makes uniqueness checking
fairly easy, and also avoids "unexpected loss of service" cases due
to someone else getting the same 'cn'.  I understand this was a
problem in some places that had something like the 'cn' matching
functionality.

By the way, the L.A. IETF meeting is coming up.  If you (or anyone
else interested in this) are going, maybe we should find a way to
hook up.

-- Hans

Date: Thu, 19 Mar 1998 23:26:48 -0500
From: Mark Horton <[email-masked]>
Organization: Lucent Technologies
To: [email-masked]
Subject: Re: Mail Routing and LDAP
Sender: [email-masked]

> >   1. UMich's approach (implemented in the "mail500" mailer)
> >   2. Netscape's approach (implemented in the Netscape MTA)
> >   3. Stanford's approach (implemented in Sendmail 8.8.X)

There is another approach which I think is worth consideration.
Bell Labs has been using it for about 10 years now, and it's been
extremely popular.  We're doing it with a proprietary protocol called
POST, with a relational database, but the same concepts and functionality
would seem well suited to LDAP.  Indeed, we'd like to migrate to LDAP
but keep this functionality, and it won't work unless this is somewhat
standardized.

(1) Deliver [email-masked] by looking it up in the directory,
and delivering to the physical address found in the directory.

(2) Pass [email-masked] (anything with syntax containing
dot, equals, slash, colon, or underscore, followed by @lucent.com) to the
directory lookup to match one or more possible people and deliver to
their physical addresses.  Examples of our current syntax:  (my directory
entry is "Mark R Horton".)

[email-masked]        (full name match)
[email-masked]          (partial name match)
[email-masked]           (partial name match)
[email-masked]             (ambiguous - return to sender)
[email-masked]                 (looks up based on "id" field, see (1) above)
mark.horton/state=[email-masked]
ou=bl0311100/all=[email-masked]  (broadcast to all in department)
tl=tmgr/loc=oh0012/all=y@lucentcom (broadcast to all tech mgrs in bldg oh0012)
state=nj/all=[email-masked]       (too many people - send to human moderator)

(all=y says user intends to match > 1 person and this is OK.  Upper/lower
case is ignored.  . and _ mean the same thing, : and / mean same thing.)

This is a very powerful system.  Most users depend on it to broadcast to
everybody in a building, or in a geographic area, or in an organizational
unit.  But if we decided to implement an attribute called shoesize, a user
could send mail to everyone with shoesize=8 without any special coding
or mods to the mail system.  We can't anticipate all the combinations
that users want, but with this system, we don't have to - they all work.

Note that this uses standard SMTP and is interpreted locally, so it does
not depend on special URLs or changes to somebody else's mail system.

Note also that this does *not* force mail to be routed through one machine
called "lucent.com".  "lucent.com" is a domain, not a machine.  Any machine
inside the domain can do the LDAP lookup and deliver directly.  Any machine
outside the domain will follow MX records to get into the domain at some
point, not necessarily always the same point.  Machines inside the domain
that don't understand the protocol will also follow (possibly different)
MX records.

And note that, because of the client/server nature of LDAP, it is not
necessary to have a separate copy of the directory on every mail server,
so you don't have to spend all your resources doing directory synch.
Have just enough LDAP servers to handle the load and be redundant - we
have 3 POST servers to handle hundreds of mail servers in Lucent.

What it does require, if you're going to use standards-based components,
then the LDAP client (MTA) and LDAP server have to agree on a few things.
Most notably, they must agree on two standard attributes: the high-level
user-visible mail address (such as "[email-masked]") and the physical
address specifying the mail server ("[email-masked]")
The job of the MTA, even in the simplest case (1 above) is to take a
high-level name, look it up in the directory, and get back the physical
address so it can route the mail there.  For example, the first could be
called "mail" and the second "MailForwardingAddress".  Or it could look
for attribute "id" value "mark", and still return a MailForwardingAddress.
At a bare minimum, we need to agree on these two attributes.

We could go further and declare RFC-xxxx which specifies the above syntax,
lets each implementation define their own attributes.  The RFC would have
to say something about broadcasts, and define the semantics of "and" and
"or".  (Our implementation is simple: multiple values of the same attribute
are "ored" together, different attributes are "anded".  This works well in
practice.)

Let me say a few words about broadcasts.  The normal behavior if you type
something ambiguous, like "[email-masked]" which matches Mark, Mary,
Matt,... is to reject it - we assume the user made an error and should
have been more specific.  So if the query matches more than 1 person, we
return it to sender (or, ideally, refuse the SMTP so the client can offer
an opportunity to fix it.)

But sometimes you want to broadcast to everybody whose title is "peon".
tl=[email-masked] would be ambiguous and would bounce.  So we put in
an "all=yes" or "all=y" attribute, which forces the user to say "yes,
dammit, I really wanted to do that" and let the broadcast go through.
Thus, tl=peon/all=[email-masked] goes to all the peons.

We've also found we have to guard against broadcast storms.  When you send
mail to 20,000 people by accident (and people do this routinely), if you
don't do anything to prevent it, you get the same old pattern:
A:	Hi, all!  I'm back!
B: 	Welcome back, A!
C:	Who's A?
D:	Stop sending all this mail to 20,000 people!
E:	Take me off this mailing list.
F:	Take me off, too.
G-Z:	Me too.

Our solution to this problem is to implement a limit.  The limit is has
a default (2500 in our case), and can be changed by authorized senders
or in the MTA configuration.  When a broadcast is expanded by the MTA,
the number of matches is counted.  If it exceeds the limit, we silently
forward the message to a configurable Internet e-mail address, the moderator.
(Another implementation is to just reject the mail, but there are often
legitimate needs to exceed the limits.)  The moderator address goes to a
person or group whose job is to read such messages and make a judgement
whether it's a reasonable message and audience.  For the 95% that are
reasonable, they are passed back to the MTA with a higher limit.  For
the mistakes, local policy is followed (we phone the sender and ask if
they really wanted to do that, usually they thank us profusely for
catching their mistake.)

Our system works very well in practice.  Lucent has about 160,000 people
in our directory.  We've been supporting this type of e-mail delivery for
over 10 years, in full production.  We had enough faith in the system to
decree two years ago that all employees use the [email-masked] address
form, which always causes a directory lookup.  We haven't regretted it,
except that existing vendors of e-mail products don't support it as well
as our internally developed system.  Perhaps with an RFC we'll all be
able to reap the benefits of LDAP-based mail delivery.

	Mark

From: Keith Moore <[email-masked]>
To: [email-masked]
Subject: Re: Mail Routing and LDAP 
Date: Thu, 19 Mar 1998 19:52:53 -0500
Sender: [email-masked]

> We propose to discuss the merits of the various approaches and
> determine whether there is interest in standardizing an approach to
> LDAP-based Routing of SMTP Messages.  

I think this is a good idea, *provided* that this is a purely local
thing - hosts outside your domain still route mail using MX records
rather than using the LDAP server.

Keith

Date: Sat, 14 Mar 1998 01:42:28 -0800
From: Stuart Lynne <[email-masked]>
To: [email-masked]
Subject: Re: Mail Routing and LDAP
Sender: [email-masked]

> 
> Various people have implemented various approaches for LDAP-based
> Routing of SMTP Messages. At least three are commonly known:
>  
>   1. UMich's approach (implemented in the "mail500" mailer)
>   2. Netscape's approach (implemented in the Netscape MTA)
>   3. Stanford's approach (implemented in Sendmail 8.8.X)

There will be a generic ldap: lookup mechanism in the next major
release of exim (currently available for testing).

It allows ldap to be used for any data lookup by specifying a standard
LDAP URL. There are two different search modes available. One for
use when you expect a single entry to be returned and multiple entries
are an error (although it permits multiple values from a single entry).
And a second that allows for multiple entries (each with multiple values).

Exim supports various lookup mechanism's, flat file, dbm, db, NIS, NIS+
and now LDAP. For the most part any lookup type can be used wherever
a lookup can be specified. So for example spam filter lists, host relay
control lists, and many other configuration items could be brought in
via LDAP.

The following exim router configuration will utilize ldap to search for
a user with a mail attribute and then use the mailforwardingattribute
to determine what to do with it (using the older Netscape mailrecipient
definition).

  virtual_fireplug_net_aliasfile_ldap:
    condition = "${if match{$self_hostname}{virtual..fireplug.net}{$domain}}"
    driver = aliasfile;
    search_type = ldap,
    expand,
    errors_to = [email-masked]
    queries = "ldap:://wilt.fireplug.net/?mailforwardingaddress?sub?(&(mail=$local_part@$domain)(ou=accounts)):\
	               ldap:://wilt.fireplug.net/?mailforwardingaddress?sub?(&(mail=\\\\2a@$domain)(ou=accounts))"

This is in use here using the older Netscape definition for mailrecipient.
I'll have to re-deploy and try out the newer version of mailrecipient
and which probably means just converting to MailRoutingAddress and
adding provision for the mailHost attribute (which I currently don't
use).

I've been trying variations on the Netscape approach for the last six
months or so. I'm basically happy with the it. 

-- 
Stuart Lynne <[email-masked]>      604-916-4741      <http://www.poste.com>
PGP Fingerprint: 28 E2 A0 15 99 62 9A 00  88 EC A3 EE 2D 1C 15 68

Date: Fri, 13 Mar 1998 20:42:48 -0500
From: Darryl C Price <[email-masked]>
Organization: The Ohio State University
To: [email-masked]
Subject: Re: Mail Routing and LDAP
Sender: [email-masked]

Hans,

Please add Innosoft International's PMDF MTA to this list.     It is a
product that I for one recommend highly.   .... And no,  I don't work for
them.

Darryl Price
University Technology Services
The Ohio State University

Hans Lachman wrote:

> Various people have implemented various approaches for LDAP-based
> Routing of SMTP Messages. At least three are commonly known:
>
>   1. UMich's approach (implemented in the "mail500" mailer)
>   2. Netscape's approach (implemented in the Netscape MTA)
>   3. Stanford's approach (implemented in Sendmail 8.8.X)
>
> There are internet drafts available describing the latter two
> approaches..
>
>   draft-lachman-ldap-mail-routing-01.txt
>   (http://www.imc.org/draft-lachman-ldap-mail-routing)
>
>   draft-ietf-asid-email-routing-su-00.txt
>   (http://www.imc.org/draft-ietf-asid-email-routing-su)
>   (expired, but an update is planned)
>
> We propose to discuss the merits of the various approaches and
> determine whether there is interest in standardizing an approach to
> LDAP-based Routing of SMTP Messages.  The discussion will be held on...
>
>   [email-masked]
>
> Information about subscribing, a list archive, and current discussion
> topics is available at...
>
>   http://www.imc.org/ietf-smtp/
>
> All people interested in this topic are invited to join in the
> discussion.
>
> Regards,
>
> Jeff Hodges & Hans Lachman

Date: Fri, 13 Mar 1998 14:43:07 -0800
From: Hans Lachman <[email-masked]>
Reply-To: [email-masked]
To: [email-masked], [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Mail Routing and LDAP
Sender: [email-masked]

Various people have implemented various approaches for LDAP-based
Routing of SMTP Messages. At least three are commonly known:
 
  1. UMich's approach (implemented in the "mail500" mailer)
  2. Netscape's approach (implemented in the Netscape MTA)
  3. Stanford's approach (implemented in Sendmail 8.8.X)
 
There are internet drafts available describing the latter two
approaches..

  draft-lachman-ldap-mail-routing-01.txt
  (http://www.imc.org/draft-lachman-ldap-mail-routing)

  draft-ietf-asid-email-routing-su-00.txt
  (http://www.imc.org/draft-ietf-asid-email-routing-su)
  (expired, but an update is planned)

We propose to discuss the merits of the various approaches and
determine whether there is interest in standardizing an approach to
LDAP-based Routing of SMTP Messages.  The discussion will be held on...

  [email-masked]

Information about subscribing, a list archive, and current discussion
topics is available at...

  http://www.imc.org/ietf-smtp/

All people interested in this topic are invited to join in the
discussion.

Regards,

Jeff Hodges & Hans Lachman