[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Email Distribution Lists???



Yeah, the postfix documentation is a little misleading..
Basically they use mailacceptinggeneralid and maildrop as default
attributes which may or may not exist in the LDAP directory..
The easiest way is to just change the configuration for the source to
use different attributes.. For example add these to the configuration
mentioned in the documentation.

ldapsource_query_filter = (uid=%s)
ldapsource_result_attribute = mail

This will do a ldapquery return results where the uid attribute is
"ldapuser" (ie what the mailing list/ distribution group name). and
return the mail attribute(s) which will be used as the addresses to
deliver the mail.

On Mon, 2003-07-21 at 15:13, Michael Dengler wrote:
> OK...I.ve come to the conclusion that I will need to use Postfix to do
> the dirty work for distribution groups. The HOWTO reads:
> 
> ---------------
> 
> Here's a basic example for using LDAP to look up aliases. Assume that in
> main.cf, you have these configuration parameters defined:
> 
> alias_maps = hash:/etc/aliases, ldap:ldapsource
> ldapsource_server_host = ldap.my.com
> ldapsource_search_base = dc=my, dc=com
> 
> Upon receiving mail for a local address "ldapuser" that isn't found in
> the /etc/aliases database, Postfix will search the LDAP server listening
> at port 389 on ldap.my.com. It will bind anonymously, search for any
> directory entries whose mailacceptinggeneralid attribute is "ldapuser",
> read the "maildrop" attributes of those found, and build a list of their
> maildrops, which will be treated as RFC822 addresses to which the
> message will be delivered.
> 
> ------------
> 
> Sounds pretty simple, except being the LDAP newbie that I am, I can't
> seem to find any object class in my schema(s) that has
> mailacceptinggeneralid as an attribute.
> 
> Any Help?
> 
> Thanks
> 
> Mike
> 
> On Mon, 2003-07-21 at 13:27, Michael Ströder wrote:
> > pll+ldap@lanminds.com wrote:
> >  >Michael Ströder wrote:
> >  >>Michael Dengler wrote:
> >  >>
> >  >>>ie. Bill, Ted, and Alice are all members of the payroll dept. with each
> >  >>>one having an address entry in the LDAP directory. I would like to also
> >  >>>have an address called PAYROLL that would contain the email addresses of
> >  >>>Bill, Ted, and Alice. I could simply create an address entry and call it
> >  >>>PAYROLL an enter Bill, Ted, and Alice's email addresses, but this would
> >  >>>be difficult to maintain.
> >  >>
> >  >>Why is that too difficult to maintain? It's a group entry with e-mail
> >  >>addresses stored in the member attribute.
> >  >
> >  > I don't think it's too difficult to maintain, however, you do end up
> >  > having a duplication of data, i.e. the e-mail address.
> >  >
> >  > I would think it better to have a groupOfUniqueNames for each group,
> >  > which lists the DNs of each member.  The MTA should be able to look
> >  > up the list of members of each group, then for each DN, access their
> >  > e-mail address.
> > 
> > Which is a duplication of Distinguised Names... ;-)
> > 
> >  >>Why is that more easy to maintain? Also note that this approach does not
> >  >>scale very well. It's rather a major PITA regarding performance since you
> >  >>have to do n+1 searches for a group of n e-mail recipients.
> >  >
> >  > Exactly. The down side is this involves a second level of redirection,
> >  > but it also keeps the duplication of data to a minimum.  I'm not sure
> >  > it's any less maintenance intensive, though.
> > 
> > Whether it's less maintenance work depends very much on your deployment 
> > scenario.
> > 
> >  > Regardless of whether
> >  > you choose to keep a list of e-mail addresses, or a list of DNs, you
> >  > still have to keep a list of something, so, in this case, it's
> >  > probably more efficient to just keep the list of e-mail addresses in
> >  > the groupOfUniqueNames.
> > 
> > I'd disagree for almost all definitions of "more efficient". ;-)
> > 
> > Ciao, Michael.
> > 
> > 
-- 
Edward Rudd <eddie@omegaware.com>
Home Page <http://urkle.drip.ws/>