On 11/22/2012 07:37 PM, mourik jan heupink wrote: > > Inmiddels ben ik een heel eind verder. Postfix lijkt ook een stuk beter > aan te sluiten bij mijn brein dan exmin dat deed. Dank voor die tip. :-)
Ah, ok. Mooi! > Ik wil onze bestaande ldap structuur gebruiken. We hebben daarin > posixGroups waar ik dan een mail attribuut aan toevoeg. Dat werkt prima, > gecheckt met postmap -q enzo. > > Echter: onze memberUids zijn usernames ipv emailadressen. Dit moet > uiteraard ook zo blijven. (de ldap is ook onze linux/samba userdatabase, > dus kan dat niet wijzigen) > > De vraag: Is er een manier om postfix te vertellen dat hij aan het > resultaat van die ldap group expansion nog '@example.com' moet > toevoegen, zodat de uid een mailadres wordt? Zeker. Het zit wel wat verstopt en werkt een beetje andersom. Je voegt het domein niet toe, maar laat postfix alleen daar zoeken als het om een specifiek domein gaat al. Postfix zoekt (bijv in maps die je opgeeft voor virtual_alias_maps) altijd naar de key (linkerkolom). Als je alleen een localpart er in zet, dus niet een heel mail-adres, dan matcht die alias standaard voor elk domein waar je op je server mail voor laat passeren. Dus in principe 'werkt' het ook zo, alleen het werkt iets te goed. Er zijn dus twee opties: ofwel het @domain erbij zetten, maar dat wil je niet, ofwel (ba dum tss) de domain= optie gebruiken, waarmee je postfix vertelt deze lookup-table (die dus ook een ldap-lookup-ding kan zijn) alleen te gebruiken als het adres waar postfix naar op zoek is als key al een van de domeinen in de waarde van 'domain' bevat: Uit http://www.postfix.org/ldap_table.5.html domain (default: no domain list) This is a list of domain names, paths to files, or dictionaries. When specified, only fully qualified search keys with a *non-empty* localpart and a matching domain are eligible for lookup: 'user' lookups, bare domain lookups and "@domain" lookups are not performed. Dus als je dit doet bijv in virtual_alias_maps: query_filter = (memberUids=%u) result_attribute = mail lookup_wildcards = no Dan wordt mail voor zowel [email protected] als [email protected] geforward naar het adres in het mail-ldap-veld van user. En als je dit doet: domain = blaat.example.com query_filter = (memberUids=%u) result_attribute = mail lookup_wildcards = no Dan wordt er geen lookup gedaan als het adres waar postfix naar op zoek is [email protected] is, wel als postfix op zoek is of [email protected] bestaat. Ik heb daar ook een keer ruzie mee gehad. De studentenvereninging waar ik lid ben geweest tijdens mijn studententijd heeft een stuk ldap database ook waarin alle contactgegevens uit de ledenlijst uit hun website in wordt gesynct, dat kunnen ze dan weer in adresboek in thunderbird gebruiken enzo. Hip, want als iemand dus in zijn profiel op de website zijn email-adres aanpast, en iemand anders gaat deze persoon een paar seconden later mailen, dan wordt in het mailprogramma het nieuwe emailadres al met auto-aanvullen uit ldap gebruikt. De volgende vraag was of <uid>@studentenvereninging.example.com dan een alias kon zijn naar het adres dat iemand in zijn profiel zet. Dat is makkelijk omdat eenmalig het adres met iemand zijn leden-id in bijv. mailman voor de wekelijkse nieuwsmailing gezet kan worden, en de alias hem/haar altijd volgt. Alleen als ik dit direct in ldap doe in postfix, dan wil ik dus niet dat: 1) iemand die ldap kan manipuleren van hen in plaats van een uid een heel adres erin zet van iemand anders in een ander domein, en dan opeens een kopie van al zijn mail krijgt. 2) de 'kale' uids die in ldap staan bij hen matchen op elk domein waar ik mail voor afhandel. Dat kan dus met hetzelfde trucje allemaal. Lookup beperken: search_base = ou=leden, dc=studentenvereninging,dc=example,dc=com scope = one domain = studentenvereninging.example.com query_filter = (uid=%u) result_attribute = mail lookup_wildcards = no Overigens, wellicht gebruik je relay_recipient_maps hier in plaats van virtual_alias_maps, omdat er niet zoveel te aliassen is, maar je valide addressen wil weten. In dat geval kun je voor ldap dus ... result_format = OK ... gebruiken. Hm, ik zie dat ik daar nog result_filter gebruik, wat inmiddels deprecated is. Hans vK -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
