LDAP routing + LDAP virtusertable : SendMail
This is a discussion on LDAP routing + LDAP virtusertable within the SendMail forums in Other Technologies category; mbowie <ebuzmo @ gmail.com> wrote: > On Oct 18, 1:28Â pm, mbowie <ebu...@gmail.com> wrote: >> On Oct 18, 9:57Â am, Andrzej Adam Filip <a...@onet.eu> wrote: >> >> >> >> > mbowie <ebu...@gmail.com> wrote: >> > > On Oct 17, 10:44Â am, Andrzej Adam Filip <a...@onet.eu> wrote: >> > >> Why do you need virtusertable with (experimental support of) >> > >> "per domain fallbacks" in ldap_routing? >> >> > >> > I have another issue to address right now, but once I'm done, I may >> > >> > have a look and see if I can find a way to "unload" the ...
| SendMail Send Mail |
![]() |
| | LinkBack | Thread Tools |
|
#11
| |||
| |||
| > On Oct 18, 1:28Â pm, mbowie <ebu...@gmail.com> wrote: >> On Oct 18, 9:57Â am, Andrzej Adam Filip <a...@onet.eu> wrote: >> >> >> >> > mbowie <ebu...@gmail.com> wrote: >> > > On Oct 17, 10:44Â am, Andrzej Adam Filip <a...@onet.eu> wrote: >> > >> Why do you need virtusertable with (experimental support of) >> > >> "per domain fallbacks" in ldap_routing? >> >> > >> > I have another issue to address right now, but once I'm done, I may >> > >> > have a look and see if I can find a way to "unload" the bounce >> > >> > mechanism the first time the LDAP route is checked, if DOMFAIL is >> > >> > defined. Â >> >> > >> You can use "domain fallback" lookups to make sure "bounce mechanism" >> > >> will not be triggered for the domain. >> >> > >> P.S. >> > >> I have scheduled publishing of the patch at open-sendmail for Sunday. >> >> > > Good afternoon Andrzej, >> >> > > I'm not sure that I understand your reply. >> >> > > I take your first question to be "why do I need this functionality in >> > > the first place", which I believe is explained in my initial post. >> >> > > Regarding the "bounce mechanism", I'm counting on the bounce feature >> > > in LDAP routing to prevent acceptance of messages for invalid >> > > recipients. Â With the patch as it stands, LDAP routing will deny >> > > acceptance of the message on the "first pass", even though it would >> > > have passed on the second try, after being rewritten by the >> > > virtusertable. >> >> > > My apologies if I've misunderstood your statements. >> >> > Could you post chain of ldap_routing and virtusertable rewrites you want >> > to achieve? >> >> > -- >> > [pl>en Andrew] Andrzej Adam Filip : a...@onet.eu : a...@xl.wp.pl >> > Education is what survives when what has been learnt has been forgotten. >> > Â -- B. F. Skinner >> >> Andrzej, >> >> Absolutely... I probably should have included that in the original >> post. >> >> For example: >> - domain-a.com is a virtuser rewrite to domain-b.com... as in "@domain- >> a.com %...@domain-b.com". >> - One of the mailboxes @domain-b.com has a mailRoutingAddress of >> user@, mailLocalAddress entries for info@ and support@ and it also has >> a mailHost entry for "mail0.isp". >> - Mail coming in for i...@domain-a.com will need to be subject to the >> virtusertable mapping before the LDAP routing otherwise (a) LDAP >> routing will bounce the message since it doesn't exist as a >> mailLocalAddress and (b) the mailHost will not be matched, so the >> message cannot be passed to the delivery server. >> - So: (i...@domain-a.com + virtusertable) = i...@domain-b.com + LDAP >> routing = u...@domain-b.com via mail0.isp >> - Also: (f...@domain-a.com + virtusertable) = f...@domain-b.com + LDAP >> routing = message not accepted, as f...@domain-b.com has no >> mailLocalAddress entry >> >> - Another user @domain-b.com may have a regular mailRoutingAddress of >> ot...@domain-b.com, with the mailLocalAddress of the same value but a >> mailHost of "mail1.isp". >> - Thus: (ot...@domain-a.com + virtusertable) = ot...@domain-b.com + >> LDAP routing = ot...@domain-b.com via mail1.isp >> - Also: (ot...@domain-b.com + virtusertable) = ot...@domain-b.com + >> LDAP routing = ot...@domain-b.com via mail1.isp >> >> I hope that makes some sense. >> >> Thanks for sticking with me on this! >> >> Mike. > > Do you think my examples there are feasible or should I consider > looking to implement this functionality in a different manner? I treat posting to c.m.sendmail as a hobby (may do for fun and pleasure), not as a job (must do). You have crossed "<10 minutes per response" limit I do not like to cross :-) I think the best "long run" way to fix your case would be: a) creating option to use separate maps for doing "per domain fallbacks" in ldap_routing [ I posted solutions using extra lookups in ldapmra b) providing and option for doing recursive ldap_routing queries e.g. domain-a ldap_routing generates address in domain-b, and ldap_routing is used again to route domain-b address [ may be with turning it on/off on per domain basis ] With "a" and "b" there should be not need for using vitusertable to add "extra functionality" to ldap_routing. P.S. I do not use ldap_routing so I might miss something subtle. -- [pl>en Andrew] Andrzej Adam Filip : anfi@onet.eu : anfi@xl.wp.pl $you = new YOU; honk() if $you->love(perl) -- Seen on Slashdot |
|
#12
| |||
| |||
| On Oct 25, 3:20 pm, Andrzej Adam Filip <a...@onet.eu> wrote: > mbowie <ebu...@gmail.com> wrote: > > On Oct 18, 1:28 pm, mbowie <ebu...@gmail.com> wrote: > >> On Oct 18, 9:57 am, Andrzej Adam Filip <a...@onet.eu> wrote: > > >> > mbowie <ebu...@gmail.com> wrote: > >> > > On Oct 17, 10:44 am, Andrzej Adam Filip <a...@onet.eu> wrote: > >> > >> Why do you need virtusertable with (experimental support of) > >> > >> "per domain fallbacks" in ldap_routing? > > >> > >> > I have another issue to address right now, but once I'm done, Imay > >> > >> > have a look and see if I can find a way to "unload" the bounce > >> > >> > mechanism the first time the LDAP route is checked, if DOMFAIL is > >> > >> > defined. > > >> > >> You can use "domain fallback" lookups to make sure "bounce mechanism" > >> > >> will not be triggered for the domain. > > >> > >> P.S. > >> > >> I have scheduled publishing of the patch at open-sendmail for Sunday. > > >> > > Good afternoon Andrzej, > > >> > > I'm not sure that I understand your reply. > > >> > > I take your first question to be "why do I need this functionalityin > >> > > the first place", which I believe is explained in my initial post. > > >> > > Regarding the "bounce mechanism", I'm counting on the bounce feature > >> > > in LDAP routing to prevent acceptance of messages for invalid > >> > > recipients. With the patch as it stands, LDAP routing will deny > >> > > acceptance of the message on the "first pass", even though it would > >> > > have passed on the second try, after being rewritten by the > >> > > virtusertable. > > >> > > My apologies if I've misunderstood your statements. > > >> > Could you post chain of ldap_routing and virtusertable rewrites you want > >> > to achieve? > > >> > -- > >> > [pl>en Andrew] Andrzej Adam Filip : a...@onet.eu : a...@xl.wp.pl > >> > Education is what survives when what has been learnt has been forgotten. > >> > -- B. F. Skinner > > >> Andrzej, > > >> Absolutely... I probably should have included that in the original > >> post. > > >> For example: > >> - domain-a.com is a virtuser rewrite to domain-b.com... as in "@domain- > >> a.com %...@domain-b.com". > >> - One of the mailboxes @domain-b.com has a mailRoutingAddress of > >> user@, mailLocalAddress entries for info@ and support@ and it also has > >> a mailHost entry for "mail0.isp". > >> - Mail coming in for i...@domain-a.com will need to be subject to the > >> virtusertable mapping before the LDAP routing otherwise (a) LDAP > >> routing will bounce the message since it doesn't exist as a > >> mailLocalAddress and (b) the mailHost will not be matched, so the > >> message cannot be passed to the delivery server. > >> - So: (i...@domain-a.com + virtusertable) = i...@domain-b.com + LDAP > >> routing = u...@domain-b.com via mail0.isp > >> - Also: (f...@domain-a.com + virtusertable) = f...@domain-b.com + LDAP > >> routing = message not accepted, as f...@domain-b.com has no > >> mailLocalAddress entry > > >> - Another user @domain-b.com may have a regular mailRoutingAddress of > >> ot...@domain-b.com, with the mailLocalAddress of the same value but a > >> mailHost of "mail1.isp". > >> - Thus: (ot...@domain-a.com + virtusertable) = ot...@domain-b.com + > >> LDAP routing = ot...@domain-b.com via mail1.isp > >> - Also: (ot...@domain-b.com + virtusertable) = ot...@domain-b.com + > >> LDAP routing = ot...@domain-b.com via mail1.isp > > >> I hope that makes some sense. > > >> Thanks for sticking with me on this! > > >> Mike. > > > Do you think my examples there are feasible or should I consider > > looking to implement this functionality in a different manner? > > I treat posting to c.m.sendmail as a hobby (may do for fun and pleasure), > not as a job (must do). You have crossed "<10 minutes per response" > limit I do not like to cross :-) > > I think the best "long run" way to fix your case would be: > a) creating option to use separate maps for doing "per domain fallbacks" > in ldap_routing > [ I posted solutions using extra lookups in ldapmra > b) providing and option for doing recursive ldap_routing queries > e.g. domain-a ldap_routing generates address in domain-b, > and ldap_routing is used again to route domain-b address > [ may be with turning it on/off on per domain basis ] > > With "a" and "b" there should be not need for using vitusertable to add > "extra functionality" to ldap_routing. > > P.S. > I do not use ldap_routing so I might miss something subtle. > > -- > [pl>en Andrew] Andrzej Adam Filip : a...@onet.eu : a...@xl.wp.pl > $you = new YOU; > honk() if $you->love(perl) > -- Seen on Slashdot Hi Andrzej, Thanks for the response... I didn't mean to sound as though I was demanding a resolution, I just wanted to make sure this avenue of inquiry was exhausted before I moved on to the next. I'd have to agree that (a) is probably the ideal solution; at least in the scenario's I've considered, the only thing we need virtusertables for is the full domain rewrite. As I said, I'm not familiar with m4, but I think I can probably hack something together. I'll certainly post my results should I get somewhere; just in case someone else comes across a similar need in future. Thank you again for your input, suggestions and guidance; and of course my apologies if I came across as anything other than sincerely appreciative! Cheers, Mike. |
|
#13
| |||
| |||
| Mike Bowie wrote: > On Oct 25, 3:20 pm, Andrzej Adam Filip <a...@onet.eu> wrote: >> mbowie <ebu...@gmail.com> wrote: >>> On Oct 18, 1:28 pm, mbowie <ebu...@gmail.com> wrote: >>>> On Oct 18, 9:57 am, Andrzej Adam Filip <a...@onet.eu> wrote: >>>>> mbowie <ebu...@gmail.com> wrote: >>>>>> On Oct 17, 10:44 am, Andrzej Adam Filip <a...@onet.eu> wrote: >>>>>>> Why do you need virtusertable with (experimental support of) >>>>>>> "per domain fallbacks" in ldap_routing? >>>>>>>> I have another issue to address right now, but once I'm done, I may >>>>>>>> have a look and see if I can find a way to "unload" the bounce >>>>>>>> mechanism the first time the LDAP route is checked, if DOMFAIL is >>>>>>>> defined. >>>>>>> You can use "domain fallback" lookups to make sure "bounce mechanism" >>>>>>> will not be triggered for the domain. >>>>>>> P.S. >>>>>>> I have scheduled publishing of the patch at open-sendmail for Sunday. >>>>>> Good afternoon Andrzej, >>>>>> I'm not sure that I understand your reply. >>>>>> I take your first question to be "why do I need this functionality in >>>>>> the first place", which I believe is explained in my initial post. >>>>>> Regarding the "bounce mechanism", I'm counting on the bounce feature >>>>>> in LDAP routing to prevent acceptance of messages for invalid >>>>>> recipients. With the patch as it stands, LDAP routing will deny >>>>>> acceptance of the message on the "first pass", even though it would >>>>>> have passed on the second try, after being rewritten by the >>>>>> virtusertable. >>>>>> My apologies if I've misunderstood your statements. >>>>> Could you post chain of ldap_routing and virtusertable rewrites you want >>>>> to achieve? >>>>> -- >>>>> [pl>en Andrew] Andrzej Adam Filip : a...@onet.eu : a...@xl.wp.pl >>>>> Education is what survives when what has been learnt has been forgotten. >>>>> -- B. F. Skinner >>>> Andrzej, >>>> Absolutely... I probably should have included that in the original >>>> post. >>>> For example: >>>> - domain-a.com is a virtuser rewrite to domain-b.com... as in "@domain- >>>> a.com %...@domain-b.com". >>>> - One of the mailboxes @domain-b.com has a mailRoutingAddress of >>>> user@, mailLocalAddress entries for info@ and support@ and it also has >>>> a mailHost entry for "mail0.isp". >>>> - Mail coming in for i...@domain-a.com will need to be subject to the >>>> virtusertable mapping before the LDAP routing otherwise (a) LDAP >>>> routing will bounce the message since it doesn't exist as a >>>> mailLocalAddress and (b) the mailHost will not be matched, so the >>>> message cannot be passed to the delivery server. >>>> - So: (i...@domain-a.com + virtusertable) = i...@domain-b.com + LDAP >>>> routing = u...@domain-b.com via mail0.isp >>>> - Also: (f...@domain-a.com + virtusertable) = f...@domain-b.com + LDAP >>>> routing = message not accepted, as f...@domain-b.com has no >>>> mailLocalAddress entry >>>> - Another user @domain-b.com may have a regular mailRoutingAddress of >>>> ot...@domain-b.com, with the mailLocalAddress of the same value but a >>>> mailHost of "mail1.isp". >>>> - Thus: (ot...@domain-a.com + virtusertable) = ot...@domain-b.com + >>>> LDAP routing = ot...@domain-b.com via mail1.isp >>>> - Also: (ot...@domain-b.com + virtusertable) = ot...@domain-b.com + >>>> LDAP routing = ot...@domain-b.com via mail1.isp >>>> I hope that makes some sense. >>>> Thanks for sticking with me on this! >>>> Mike. >>> Do you think my examples there are feasible or should I consider >>> looking to implement this functionality in a different manner? >> I treat posting to c.m.sendmail as a hobby (may do for fun and pleasure), >> not as a job (must do). You have crossed "<10 minutes per response" >> limit I do not like to cross :-) >> >> I think the best "long run" way to fix your case would be: >> a) creating option to use separate maps for doing "per domain fallbacks" >> in ldap_routing >> [ I posted solutions using extra lookups in ldapmra >> b) providing and option for doing recursive ldap_routing queries >> e.g. domain-a ldap_routing generates address in domain-b, >> and ldap_routing is used again to route domain-b address >> [ may be with turning it on/off on per domain basis ] >> >> With "a" and "b" there should be not need for using vitusertable to add >> "extra functionality" to ldap_routing. >> >> P.S. >> I do not use ldap_routing so I might miss something subtle. >> >> -- >> [pl>en Andrew] Andrzej Adam Filip : a...@onet.eu : a...@xl.wp.pl >> $you = new YOU; >> honk() if $you->love(perl) >> -- Seen on Slashdot > > Hi Andrzej, > > Thanks for the response... I didn't mean to sound as though I was > demanding a resolution, I just wanted to make sure this avenue of > inquiry was exhausted before I moved on to the next. > > I'd have to agree that (a) is probably the ideal solution; at least in > the scenario's I've considered, the only thing we need virtusertables > for is the full domain rewrite. As I said, I'm not familiar with m4, > but I think I can probably hack something together. > > I'll certainly post my results should I get somewhere; just in case > someone else comes across a similar need in future. > > Thank you again for your input, suggestions and guidance; and of > course my apologies if I came across as anything other than sincerely > appreciative! > > Cheers, > > Mike. Good day folks, After a bit of poking around, I've reverted back to the initial idea of altering the order of the parse rules to evaluate the virtusertable prior to applying LDAP routing. This was mainly because LDAP routing applies at the user level of our schema, while the virtuser entries live elsewhere... I felt that spreading the LDAP routing data around would be something that could bite me later on; it also looked like the path of least resistance, which was very appealing at my level of expertise. So, I've crafted the attached patch, which (inspired by Andrzej's example) takes effect based on define(`_LDAP_ROUTING_AFTERVIRTUSER_') being included in the mc file. If said define exists, it will exclude the initial LDAP routing invocation and instead apply it right after the virtusertable. Testing so far has shown it's doing what I'd hope... although I've not tested it in the wild as of yet. My only concern is that normally there's a series of IP checks applied for "_MAILER_smtp_" after LDAP routing and before virtusertable... in this case they're fired before both virtusertable and LDAP routing respectively, which means they'll not suffer the effects of any LDAP routing. I know in my case LDAP routing won't be returning anything in IP notation, so I'm expecting that won't present an issue. (Perhaps someone would care to inform me otherwise.) Should my mailer munge the attachment, please accept my apologies and grab a copy from http://www.buzmo.com/projects/sendma...tvirtuser.diff Thanks again to Andrzej for the feedback and suggestions; and in advance to any so inclined to further mold my attempt. Cheers, Mike. --- /usr/share/sendmail/cf/m4/proto.m4.orig Thu Oct 30 12:16:03 2008 +++ /usr/share/sendmail/cf/m4/proto.m4 Thu Oct 30 13:51:02 2008 @@ -1031,9 +1031,12 @@ SParse1 ifdef(`_LDAP_ROUTING_', `dnl # handle LDAP routing for hosts in $={LDAPRoute} +dnl we skip LDAP routing if virtusertable is to be performed first +ifdef(`_LDAP_ROUTING_AFTERVIRTUSER_', `dnl', `dnl R$+ < @ $={LDAPRoute} . > $: $>LDAPExpand <$1 < @ $2 . >> <$1 @ $2> <> -R$+ < @ $={LDAPRouteEquiv} . > $: $>LDAPExpand <$1 < @ $2 . >> <$1 @ $M> <>', -`dnl') +R$+ < @ $={LDAPRouteEquiv} . > $: $>LDAPExpand <$1 < @ $2 . >> <$1 @ $M> <>' +) +', `dnl') ifdef(`_MAILER_smtp_', `# handle numeric address spec @@ -1104,6 +1107,15 @@ `R< $+ > $+ < @ $+ > $: $>ParseLocal $>Parse0 $>canonify $1', `R< $+ > $+ < @ $+ > $: $>Recurse $1') dnl', `dnl') + +ifdef(`_LDAP_ROUTING_', `dnl +# handle LDAP routing for hosts in $={LDAPRoute} +ifdef(`_LDAP_ROUTING_AFTERVIRTUSER_', `dnl +# virtuser has been consulted, so we LDAP route now +R$+ < @ $={LDAPRoute} . > $: $>LDAPExpand <$1 < @ $2 . >> <$1 @ $2> <> +R$+ < @ $={LDAPRouteEquiv} . > $: $>LDAPExpand <$1 < @ $2 . >> <$1 @ $M> <>', +`dnl'), ', +`dnl') # short circuit local delivery so forwarded email works ifdef(`_MAILER_usenet_', `dnl |

