I have a problem that I'm hoping can be solved with a Sendmail based
solution.

There is a community of organizations who need to share sensitive
information via email. As an organization that is trusted by all
parties, we host a smarthost service through which all participating
orgs send all of their outbound email. The smarthost contains the
central list of participating domains and routes email among
participants and/or the Internet. This smarthost ensures that all
email flowing to/from participating orgs is secured within an
authenticated TLS session. The business has deemed this sufficient
security to exchange sensitive information among participating
organizations.

This solution is complemented by an LDAP service that provides a list
of participating organizations' recipients, so that end users know to
whom they can send sensitive information.

We would like to offer some flexibility to the participating orgs such
that they don't have to send Internet-bound email through us. And we
want to do this without introducing a new DNS service. We also don't
want organizations to have to make changes to their systems each time
we add a new organization (i.e. central administration of email routes
required).

We're thinking of having the participating organizations' email
gateways applying the following logic:

For each outbound message:
1) Check the LDAP directory to see if the recipient in the To: field
is participating in the federation.
2) If the recipient is found, send to the smarthost.
3) If the recipient is not found (and we're sure LDAP is functioning),
then use Internet DNS resolve domains and route the message.

To optimize performance, we would like to publish "domain" objects in
the LDAP directory so that the entire (large) directory doesn't have
to be parsed for each message. Additional performance could be had by
caching the list of participating domains that is fetched from the
LDAP directory.

How might we do this with Sendmail? Are there any appliances that
offer such rich outbound routing capabilities?

Thanks for considering my problem.

On Sep 4, 12:54 pm, cliff.patterso...@gmail.com wrote:
> For each outbound message:
> 1) Check the LDAP directory to see if the recipient in the To: field
> is participating in the federation.
> 2) If the recipient is found, send to the smarthost.
> 3) If the recipient is not found (and we're sure LDAP is functioning),
> then use Internet DNS resolve domains and route the message.

> How might we do this with Sendmail? Are there any appliances that
> offer such rich outbound routing capabilities?

I think you could do this with FEATURE(`ldap_routing') and defining
the class $={{LDAPRoute} as an LDAP lookup:
LDAPROUTE_DOMAIN_FILE(`@LDAP')
Look in the cf/README file for more information.

The only drawback is that classes are statically loaded into memory,
so if
you add a new domain to the class, you have to kill and restart the
sendmail
daemon. An ugly solution would be to restart the daemon on a periodic
basis
via cron. If new domains added infrequently, you could also just send
out
a daemon restart notice.

Hope this s

RLH

For info about our "Sendmail and DNS Handson Training or our in depth
"Managing Internet Mail, Setting Up and Trouble Shooting sendmail and
DNS" classes and a schedule of dates and locations, please send email
to info@harker.com, or visit www.harker.com

Robert Harker
Harker Systems
harker@harker.com

On Sep 4, 12:54 pm, cliff.patterso...@gmail.com wrote:
> For each outbound message:
> 1) Check the LDAP directory to see if the recipient in the To: field
> is participating in the federation.
> 2) If the recipient is found, send to the smarthost.
> 3) If the recipient is not found (and we're sure LDAP is functioning),
> then use Internet DNS resolve domains and route the message.

> How might we do this with Sendmail? Are there any appliances that
> offer such rich outbound routing capabilities?

I think you could do this with FEATURE(`ldap_routing') and defining
the class $={{LDAPRoute} as an LDAP lookup:
LDAPROUTE_DOMAIN_FILE(`@LDAP')
Look in the cf/README file for more information.

The only drawback is that classes are statically loaded into memory,
so if
you add a new domain to the class, you have to kill and restart the
sendmail
daemon. An ugly solution would be to restart the daemon on a periodic
basis
via cron. If new domains added infrequently, you could also just send
out
a daemon restart notice.

Hope this s

RLH

For info about our "Sendmail and DNS Handson Training or our in depth
"Managing Internet Mail, Setting Up and Trouble Shooting sendmail and
DNS" classes and a schedule of dates and locations, please send email
to info@harker.com, or visit www.harker.com

Robert Harker
Harker Systems
harker@harker.com