Hello all,

I've been getting on quite will with sendmail's ldap_routing feature,
but I've hit a snag that I hope someone can help me with.

I'm looking for the equivalent of the %1 [at] domain facility in
virtusertable. Like so:
[at] domain1.com %1 [at] domain2.com

I've created ldap entries that return %1 [at] domain2.com as the
mailRoutingAddress, but this doesn't have the desired affect.

Ldap entries look something like this:
dn: cn= [at] domain1.com,cn=domain1.com,dc=domains
objectClass: inetOrgPerson
objectClass: person
objectClass: top
objectClass: inetLocalMailRecipient
mail: [at] domain1.com
cn: [at] domain1.com
mailRoutingAddress: %1 [at] domain2.com

Sendmail.mc feature looks like this:
FEATURE(`ldap_routing',
`ldap -1 -T<TMPF> -v mailHost -k
(&(objectClass=inetLocalMailRecipient)(mail=%0))',
`ldap -1 -T<TMPF> -v mailRoutingAddress -k
(&(objectClass=inetLocalMailRecipient)(mail=%0))')


When I execute 'sendmail -bv -d21.2 test [at] domain1.com' I get this
result:
<------------snip ---------->
rewrite: ruleset canonify input: test [at] domain1 . com
rewrite: ruleset Canonify2 input: test < [at] domain1 . com >
rewrite: RHS $&{daemon_flags} => "(NULL)"
rewrite: ruleset Canonify2 returns: test < [at] domain1 . com . >
rewrite: ruleset canonify returns: test < [at] domain1 . com . >
rewrite: ruleset parse input: test < [at] domain1 . com . >
rewrite: ruleset Parse0 input: test < [at] domain1 . com . >
rewrite: ruleset Parse0 returns: test < [at] domain1 . com . >
rewrite: ruleset ParseLocal input: test < [at] domain1 . com . >
rewrite: ruleset ParseLocal returns: test < [at] domain1 . com . >
rewrite: ruleset Parse1 input: test < [at] domain1 . com . >
rewrite: ruleset LDAPExpand input: < test < [at] domain1 . com .
> > < test [at] domain1 . com > < >
rewrite: ruleset LDAPExpand input: < test < [at] domain1 . com .
> > < [at] domain1 . com > < >
rewrite: ruleset canonify input: [at] domain2 . com
rewrite: ruleset Canonify2 input: < [at] domain2 . com >
rewrite: RHS $&{daemon_flags} => "(NULL)"
rewrite: ruleset Canonify2 returns: < [at] domain2 . com . >
rewrite: ruleset canonify returns: < [at] domain2 . com . >
rewrite: ruleset Parse0 input: < [at] domain2 . com . >
rewrite: ruleset Parse0 returns: $# error $ [at] 5 . 1 . 3 $:
"553 User address required"
rewrite: ruleset LDAPExpand returns: $# error $ [at] 5 . 1 . 3 $:
"553 User address required"
rewrite: ruleset LDAPExpand returns: $# error $ [at] 5 . 1 . 3 $:
"553 User address required"
rewrite: ruleset Parse1 returns: $# error $ [at] 5 . 1 . 3 $:
"553 User address required"
rewrite: ruleset parse returns: $# error $ [at] 5 . 1 . 3 $:
"553 User address required"
test [at] domain1.com... User address required

Can anyone suggest how I should proceed from here? Any help would be
greatly appreciated.

Thanks,
John

John Mac <knightlore2 [at] googlemail.com> writes:
> I've been getting on quite will with sendmail's ldap_routing feature,
> but I've hit a snag that I hope someone can help me with.
>
> I'm looking for the equivalent of the %1 [at] domain facility in
> virtusertable. Like so:
> [at] domain1.com %1 [at] domain2.com
>
> I've created ldap entries that return %1 [at] domain2.com as the
> mailRoutingAddress, but this doesn't have the desired affect.

*Current* implementation of FEATURE(`ldap_routing') does not support
[at] domain1.com lookups.

It can be added without any need to recompile sendmail binaries, only
sendmail.cf recompilation after patching m4 files would be required.

> [...]
>
> When I execute 'sendmail -bv -d21.2 test [at] domain1.com' I get this
> result:
> [...]

Consider adding also -d60.5 to trace map lookups in future similar tests.

> Can anyone suggest how I should proceed from here? Any help would be
> greatly appreciated.

--
[pl>en: Andrew] Andrzej Adam Filip : anfi [at] priv.onet.pl : anfi [at] xl.wp.pl
If you think nobody cares if you're alive,
try missing a couple of car payments.
-- Earl Wilson

Hi Andrzej,

Thanks for your reply.

On 29 Aug, 11:12, Andrzej Adam Filip <a... [at] onet.eu> wrote:

> *Current* implementation of FEATURE(`ldap_routing') does not support
> [at] domain1.com lookups.

I'm using sendmail 8.13 under CentOS 4.5 and it does support lookups
for [at] domain1.com. The lookup succeeds, but sendmail's interpretation
of the response is the problem.

>
> It can be added without any need to recompile sendmail binaries, only
> sendmail.cf recompilation after patching m4 files would be required.
>

Maybe Redhat have already done that?

> > [...]
>
> > When I execute 'sendmail -bv -d21.2 t... [at] domain1.com' I get this
> > result:
> > [...]
>
> Consider adding also -d60.5 to trace map lookups in future similar tests.

Thanks for the tip. This is the tail end of the output for 'sendmail -
bv -d21.2 -d60.5 test [at] domain1.com':

rewrite: ruleset LDAPExpand input: < test < [at] domain1 . com .
> > < test [at] domain1 . com > < >
map_lookup(ldapmra, test [at] domain1.com, %0=test [at] domain1.com) => NOT
FOUND (68)
map_lookup(ldapmh, test [at] domain1.com, %0=test [at] domain1.com) => NOT FOUND
(68)
rewrite: ruleset LDAPExpand input: < test < [at] domain1 . com .
> > < [at] domain1 . com > < >
map_lookup(ldapmra, [at] domain1.com, %0= [at] domain1.com) => [at] domain2.com (0)
map_lookup(ldapmh, [at] domain1.com, %0= [at] domain1.com) => NOT FOUND (68)
rewrite: ruleset canonify input: [at] domain2 . com
rewrite: ruleset Canonify2 input: < [at] domain2 . com >
rewrite: RHS $&{daemon_flags} => "(NULL)"
map_lookup(host, domain2.com, %0=domain2.com) => domain2.com. (0)
rewrite: ruleset Canonify2 returns: < [at] domain2 . com . >
rewrite: ruleset canonify returns: < [at] domain2 . com . >
rewrite: ruleset Parse0 input: < [at] domain2 . com . >
rewrite: ruleset Parse0 returns: $# error $ [at] 5 . 1 . 3 $:
"553 User address required"
rewrite: ruleset LDAPExpand returns: $# error $ [at] 5 . 1 . 3 $:
"553 User address required"
rewrite: ruleset LDAPExpand returns: $# error $ [at] 5 . 1 . 3 $:
"553 User address required"
rewrite: ruleset Parse1 returns: $# error $ [at] 5 . 1 . 3 $:
"553 User address required"
rewrite: ruleset parse returns: $# error $ [at] 5 . 1 . 3 $:
"553 User address required"
test [at] domain1.com... User address required

The line "rewrite: ruleset canonify input: [at] domain2 . com"
seems to be were things go wrong. %1 appears to have been stripped
from the response.

Regards,
John

John Mac <knightlore2 [at] googlemail.com> writes:

> Hi Andrzej,
>
> Thanks for your reply.
>
> On 29 Aug, 11:12, Andrzej Adam Filip <a... [at] onet.eu> wrote:
>
>> *Current* implementation of FEATURE(`ldap_routing') does not support
>> [at] domain1.com lookups.
>
> I'm using sendmail 8.13 under CentOS 4.5 and it does support lookups
> for [at] domain1.com. The lookup succeeds, but sendmail's interpretation
> of the response is the problem.

Sorry, I have read http://www.sendmail.org/m4/ldap_routing.html based
on sendmail-8.12. It supports only 4 parameters, current version of the
feature by sendmail.org supports two more parameters.
[ you seem to use the fifth - <nodomain> ]

>> [...]
>> Consider adding also -d60.5 to trace map lookups in future similar tests.
>
> Thanks for the tip. This is the tail end of the output for 'sendmail -
> bv -d21.2 -d60.5 test [at] domain1.com':
>
> rewrite: ruleset LDAPExpand input: < test < [at] domain1 . com .
>> > < test [at] domain1 . com > < >
> map_lookup(ldapmra, test [at] domain1.com, %0=test [at] domain1.com) => NOT
> FOUND (68)
> map_lookup(ldapmh, test [at] domain1.com, %0=test [at] domain1.com) => NOT FOUND
> (68)
> rewrite: ruleset LDAPExpand input: < test < [at] domain1 . com .
>> > < [at] domain1 . com > < >
> map_lookup(ldapmra, [at] domain1.com, %0= [at] domain1.com) => [at] domain2.com (0)

Here you can see source of your problems:
1) ldapmra lookup does not return %1 in the lookup result
2) sendmail would not expand it anyway because sendmail is ready to
expand %0 *only*

> map_lookup(ldapmh, [at] domain1.com, %0= [at] domain1.com) => NOT FOUND (68)
> [...]
>
> The line "rewrite: ruleset canonify input: [at] domain2 . com"
> seems to be were things go wrong. %1 appears to have been stripped
> from the response.

<TEST_AT_YOUR_OWN_RISK>

1) Try the following *UNTESTED* patch of cf/m4/proto.m4 file
[ one extra R line before first R line after SLDAPExpand line ]
2) For *initial* test insert it directly in copy of sendmail.cf named
sendmail-test.cf and test it using
sendmail -C sendmail-test.cf -d21.12 -d60.5 -bv test [at] domain1.com
3) wait *at least* two days for comments by other c.m.sendmail readers
before considering to use it a in production server

SLDAPExpand
# do the LDAP lookups
R<$+< [at] $+>>< [at] $+><$*> $: <$(ldapmra [at] $3 $ [at] $1 $: $)> <$(ldapmh [at] $3 $ [at] $1 $: $)> <$1< [at] $2>> < [at] $3> <$4>
R<$+><$+><$*> $: <$(ldapmra $2 $: $)> <$(ldapmh $2 $: $)> <$1> <$2> <$3>

*DO NOT* forget to put tab (\t) before first $: in the new line

</TEST_AT_YOUR_OWN_RISK>

--
[pl>en: Andrew] Andrzej Adam Filip : anfi [at] priv.onet.pl : anfi [at] xl.wp.pl
You can't cheat an honest man.
Never give a sucker an even break or smarten up a chump.
-- W. C. Fields

On 29 Aug, 12:24, Andrzej Adam Filip <a... [at] onet.eu> wrote:
>
> <TEST_AT_YOUR_OWN_RISK>
>
> 1) Try the following *UNTESTED* patch of cf/m4/proto.m4 file
> [ one extra R line before first R line after SLDAPExpand line ]
> 2) For *initial* test insert it directly in copy of sendmail.cf named
> sendmail-test.cf and test it using
> sendmail -C sendmail-test.cf -d21.12 -d60.5 -bv t... [at] domain1.com
> 3) wait *at least* two days for comments by other c.m.sendmail readers
> before considering to use it a in production server
>
> SLDAPExpand
> # do the LDAP lookups
> R<$+< [at] $+>>< [at] $+><$*> $: <$(ldapmra [at] $3 $ [at] $1 $: $)> <$(ldapmh [at] $3 $ [at] $1 $: $)> <$1< [at] $2>> < [at] $3> <$4>
> R<$+><$+><$*> $: <$(ldapmra $2 $: $)> <$(ldapmh $2 $: $)> <$1> <$2> <$3>
>
> *DO NOT* forget to put tab (\t) before first $: in the new line
>
> </TEST_AT_YOUR_OWN_RISK>
>

Thanks Andrzej, you're a genius! I'll obviously do more testing before
going live, but it certainly seems to have done the trick. I'm now
getting the result I expected.

If I experience any unexpected issues, I'll post again.

Best regards and many thanks,
John



> --
> [pl>en: Andrew] Andrzej Adam Filip : a... [at] priv.onet.pl : a... [at] xl.wp.pl
> You can't cheat an honest man.
> Never give a sucker an even break or smarten up a chump.
> -- W. C. Fields

On Aug 29, 12:57 pm, John Mac <knightlo... [at] googlemail.com> wrote:
> On 29 Aug, 12:24, Andrzej Adam Filip <a... [at] onet.eu> wrote:
>
>
> > <TEST_AT_YOUR_OWN_RISK>
>
> > 1) Try the following *UNTESTED* patch of cf/m4/proto.m4 file
> > [ one extra R line before first R line after SLDAPExpand line ]
> > 2) For *initial* test insert it directly in copy ofsendmail.cf named
> > sendmail-test.cf and test it using
> > sendmail-Csendmail-test.cf -d21.12 -d60.5 -bv t... [at] domain1.com
> > 3) wait *at least* two days for comments by other c.m.sendmailreaders
> > before considering to use it a in production server
>
> > SLDAPExpand
> > # do theLDAPlookups
> > R<$+< [at] $+>>< [at] $+><$*> $: <$(ldapmra [at] $3 $ [at] $1 $: $)> <$(ldapmh [at] $3 $ [at] $1 $: $)> <$1< [at] $2>> < [at] $3> <$4>
> > R<$+><$+><$*> $: <$(ldapmra $2 $: $)> <$(ldapmh $2 $: $)> <$1> <$2> <$3>
>
> > *DO NOT* forget to put tab (\t) before first $: in the new line
>
> > </TEST_AT_YOUR_OWN_RISK>
>

I'm afraid I've found a problem. The ldapmh lookup is now broken with
the new rule in place. This is for domains where I *have* specified a
mailHost. When I remove the rule ldapmh works again.

This is an LDAP entry for such a domain:
dn: cn= [at] example1.net,cn=example1.net,dc=domains
objectClass: inetOrgPerson
objectClass: person
objectClass: top
objectClass: inetLocalMailRecipient
mail: [at] example1.net
cn: [at] example1.net
mailHost: mail.example1.net

This is the relevant bit of output of 'sendmail -d21.12 -d60.5 -bv
test [at] example1.net' *with* the new rule in place:
==========================================================
rewrite: ruleset LDAPExpand input: < test < [at] example1 . net .
> > < [at] example1 . net > < >
-----trying rule: < $+ < [at] $+ > > < [at] $+ > < $* >
-----rule matches: $: < $( ldapmra [at] $3 $ [at] $1 $: $) > < $( ldapmh [at] $3
$ [at] $1 $: $) > < $1 < [at] $2 > > < [at] $3 > < $4 >
map_lookup(ldapmra, [at] example1.net, %0= [at] example1.net, %1=test) => NOT
FOUND (68)
map_lookup(ldapmh, [at] example1.net, %0= [at] example1.net, %1=test) =>
mail.example1.net (0)
rewritten as: < > < mail . example1 . net > < test < [at] example1 .
net . > > < [at] example1 . net > < >
-----trying rule: < $+ > < $+ > < $* >
-----rule matches: $: < $( ldapmra $2 $: $) > < $( ldapmh $2 $: $) > <
$1 > < $2 > < $3 >
map_lookup(ldapmra, test< [at] example1.net.>, %0=test< [at] example1.net.>) =>
NOT FOUND (68)
map_lookup(ldapmh, test< [at] example1.net.>, %0=test< [at] example1.net.>) =>
NOT FOUND (68)
rewritten as: < > < > < > < mail . example1 . net > < test < [at]
example1 . net . > > < [at] example1 . net > < >
-----trying rule: < $* < TMPF > > < $* > < $+ > < $+ > < $* >
----- rule fails
-----trying rule: < $* > < $* < TMPF > > < $+ > < $+ > < $* >
----- rule fails
-----trying rule: $* $| TMPF < $* > $| $+
----- rule fails
-----trying rule: < $+ > < $=w > < $+ > < $+ > < $* >
----- rule fails
-----trying rule: < $+ > < > < $+ > < $+ > < $* >
-----rule matches: $ [at] $> Parse0 $> canonify $1
==========================================================

This is the same section of output *without* the new rule:
==========================================================
rewrite: ruleset LDAPExpand input: < test < [at] example1 . net .
> > < test [at] example1 . net > < >
-----trying rule: < $+ > < $+ > < $* >
-----rule matches: $: < $( ldapmra $2 $: $) > < $( ldapmh $2 $: $) > <
$1 > < $2 > < $3 >
map_lookup(ldapmra, test [at] example1.net, %0=test [at] example1.net) => NOT
FOUND (68)
map_lookup(ldapmh, test [at] example1.net, %0=test [at] example1.net) => NOT
FOUND (68)
rewritten as: < > < > < test < [at] example1 . net . > > < test [at]
example1 . net > < >
-----trying rule: < $* < TMPF > > < $* > < $+ > < $+ > < $* >
----- rule fails
-----trying rule: < $* > < $* < TMPF > > < $+ > < $+ > < $* >
----- rule fails
-----trying rule: $* $| TMPF < $* > $| $+
----- rule fails
-----trying rule: < $+ > < $=w > < $+ > < $+ > < $* >
----- rule fails
-----trying rule: < $+ > < > < $+ > < $+ > < $* >
----- rule fails
-----trying rule: < $+ > < $+ > < $+ > < $+ > < $* >
----- rule fails
-----trying rule: < > < $=w > < $+ > < $+ > < $* >
----- rule fails
-----trying rule: < > < $+ > < $+ > < $+ > < $* >
----- rule fails
-----trying rule: < > < > < $+ > < $+ [at] $+ > < $* >
-----rule matches: $ [at] $> LDAPExpand < $1 > < [at] $3 > < $4 >
rewrite: ruleset LDAPExpand input: < test < [at] example1 . net .
> > < [at] example1 . net > < >
-----trying rule: < $+ > < $+ > < $* >
-----rule matches: $: < $( ldapmra $2 $: $) > < $( ldapmh $2 $: $) > <
$1 > < $2 > < $3 >
map_lookup(ldapmra, [at] example1.net, %0= [at] example1.net) => NOT FOUND (68)
map_lookup(ldapmh, [at] example1.net, %0= [at] example1.net) =>
mail.example1.net (0)
rewritten as: < > < mail . example1 . net > < test < [at] example1 .
net . > > < [at] example1 . net > < >
-----trying rule: < $* < TMPF > > < $* > < $+ > < $+ > < $* >
----- rule fails
-----trying rule: < $* > < $* < TMPF > > < $+ > < $+ > < $* >
----- rule fails
-----trying rule: $* $| TMPF < $* > $| $+
----- rule fails
-----trying rule: < $+ > < $=w > < $+ > < $+ > < $* >
----- rule fails
-----trying rule: < $+ > < > < $+ > < $+ > < $* >
----- rule fails
-----trying rule: < $+ > < $+ > < $+ > < $+ > < $* >
----- rule fails
-----trying rule: < > < $=w > < $+ > < $+ > < $* >
----- rule fails
-----trying rule: < > < $+ > < $+ > < $+ > < $* >
-----rule matches: $> LDAPMailertable < $1 > $2
==========================================================

It seems that it goes wrong when this happens:
"rewritten as: < > < > < > < mail . example1 . net > < test < [at]
example1 . net . > > < [at] example1 . net > < >"
As opposed to:
"rewritten as: < > < mail . example1 . net > < test < [at] example1 .
net . > > < [at] example1 . net > < >"

I wish I could fathom the syntax of Sendmail rules myself to fix this
myself, but I'm afraid it's beyond me.

Regards,
John

Try the version below - three extra lines and one modified line:

R$* $: <?> $1
R<?><$+< [at] $+>>< [at] $+><$*> $: <!><$(ldapmra [at] $3 $ [at] $1 $: $)> <$(ldapmh [at] $3 $ [at] $1 $: $)> <$1< [at] $2>> < [at] $3> <$4>
R<?><$+><$+><$*> $: <!><$(ldapmra $2 $: $)> <$(ldapmh $2 $: $)> <$1> <$2> <$3>
R<$->$* $: $2

P.S. It may seem like a slight "overkill" but it may simplify adding new
extra cases in the future e.g. handling of "user [at] " entries.
[ postmaster [at] * or abuse [at] * ]

--
[pl>en: Andrew] Andrzej Adam Filip : anfi [at] priv.onet.pl : anfi [at] xl.wp.pl
The happiest time of a person's life is after his first divorce.
-- J. K. Galbraith

You can try FEATURE(`domaintable', `LDAP')dnl
from cf/README :
domaintable Include a "domain table" which can be used to provide
domain name mapping.


On Aug 29, 12:39 pm, John Mac <knightlo... [at] googlemail.com> wrote:
> Hello all,
>
> I've been getting on quite will with sendmail's ldap_routing feature,
> but I've hit a snag that I hope someone can help me with.
>
> I'm looking for the equivalent of the %1 [at] domain facility in
> virtusertable. Like so:
> [at] domain1.com %... [at] domain2.com
>
> I've created ldap entries that return %... [at] domain2.com as the
> mailRoutingAddress, but this doesn't have the desired affect.
>
> Ldap entries look something like this:
> dn: c... [at] domain1.com,cn=domain1.com,dc=domains
> objectClass: inetOrgPerson
> objectClass: person
> objectClass: top
> objectClass: inetLocalMailRecipient
> mail: [at] domain1.com
> cn: [at] domain1.com
> mailRoutingAddress: %... [at] domain2.com
>
> Sendmail.mc feature looks like this:
> FEATURE(`ldap_routing',
> `ldap -1 -T<TMPF> -v mailHost -k
> (&(objectClass=inetLocalMailRecipient)(mail=%0))',
> `ldap -1 -T<TMPF> -v mailRoutingAddress -k
> (&(objectClass=inetLocalMailRecipient)(mail=%0))')
>
> When I execute 'sendmail -bv -d21.2 t... [at] domain1.com' I get this
> result:
> <------------snip ---------->
> rewrite: ruleset canonify input: test [at] domain1 . com
> rewrite: ruleset Canonify2 input: test < [at] domain1 . com >
> rewrite: RHS $&{daemon_flags} => "(NULL)"
> rewrite: ruleset Canonify2 returns: test < [at] domain1 . com . >
> rewrite: ruleset canonify returns: test < [at] domain1 . com . >
> rewrite: ruleset parse input: test < [at] domain1 . com . >
> rewrite: ruleset Parse0 input: test < [at] domain1 . com . >
> rewrite: ruleset Parse0 returns: test < [at] domain1 . com . >
> rewrite: ruleset ParseLocal input: test < [at] domain1 . com . >
> rewrite: ruleset ParseLocal returns: test < [at] domain1 . com . >
> rewrite: ruleset Parse1 input: test < [at] domain1 . com . >
> rewrite: ruleset LDAPExpand input: < test < [at] domain1 . com .> > < test [at] domain1 . com > < >
>
> rewrite: ruleset LDAPExpand input: < test < [at] domain1 . com .> > < [at] domain1 . com > < >
>
> rewrite: ruleset canonify input: [at] domain2 . com
> rewrite: ruleset Canonify2 input: < [at] domain2 . com >
> rewrite: RHS $&{daemon_flags} => "(NULL)"
> rewrite: ruleset Canonify2 returns: < [at] domain2 . com . >
> rewrite: ruleset canonify returns: < [at] domain2 . com . >
> rewrite: ruleset Parse0 input: < [at] domain2 . com . >
> rewrite: ruleset Parse0 returns: $# error $ [at] 5 . 1 . 3 $:
> "553 User address required"
> rewrite: ruleset LDAPExpand returns: $# error $ [at] 5 . 1 . 3 $:
> "553 User address required"
> rewrite: ruleset LDAPExpand returns: $# error $ [at] 5 . 1 . 3 $:
> "553 User address required"
> rewrite: ruleset Parse1 returns: $# error $ [at] 5 . 1 . 3 $:
> "553 User address required"
> rewrite: ruleset parse returns: $# error $ [at] 5 . 1 . 3 $:
> "553 User address required"
> t... [at] domain1.com... User address required
>
> Can anyone suggest how I should proceed from here? Any help would be
> greatly appreciated.
>
> Thanks,
> John

On 29 Aug, 19:15, Andrzej Adam Filip <a... [at] onet.eu> wrote:
> Try the version below - three extra lines and one modified line:
>
> R$* $: <?> $1
> R<?><$+< [at] $+>>< [at] $+><$*> $: <!><$(ldapmra [at] $3 $ [at] $1 $: $)> <$(ldapmh [at] $3 $ [at] $1 $: $)> <$1< [at] $2>> < [at] $3> <$4>
> R<?><$+><$+><$*> $: <!><$(ldapmra $2 $: $)> <$(ldapmh $2 $: $)> <$1> <$2> <$3>
> R<$->$* $: $2
>
> P.S. It may seem like a slight "overkill" but it may simplify adding new
> extra cases in the future e.g. handling of "user [at] " entries.
> [ postmaster [at] * or abuse [at] * ]
>

Once again, many thanks Andrzej. That's solved the problem. I haven't
tested every possible case yet but so far so good.

I'm slowly beginning to understand the syntax, and I've made another
modification that I thought I should run by you. I noticed that unlike
virtusertable handing, ldap routing doesn't recurse after finding a
result. I've modified a couple of lines in proto.m4 to add this
functionality.

Original:
=========================
# if mailRoutingAddress and local or non-existant mailHost,
# return the new mailRoutingAddress
R<$+> <$=w> <$+> <$+> <$*> $ [at] $>Parse0 $>canonify $1
R<$+> <> <$+> <$+> <$*> $ [at] $>Parse0 $>canonify $1

Changed to:
=========================
# if mailRoutingAddress and local or non-existant mailHost,
# perform recursive lookup
R<$+> <$=w> <$+> <$+> <$*> $ [at] $>Recurse $1
R<$+> <> <$+> <$+> <$*> $ [at] $>Recurse $1

This change has worked for me. Do you see any problem with this
modification?

Thanks,
John

On 30 Aug, 08:28, yolov... [at] gmail.com wrote:
> You can try FEATURE(`domaintable', `LDAP')dnl
> from cf/README :
> domaintable Include a "domain table" which can be used to provide
> domain name mapping.
>

Hi,

Thanks for the suggestion, but having the %1 functionality gives me a
lot more flexibility than domaintable would. It makes ldap routing
work a bit more like virtusertable. So, I can now do things like:
user1 [at] domain1 -> user30 [at] domain2
user2 [at] domain1 -> user32 [at] domain2
user3 [at] domain1 -> user15 [at] domain2
[at] domain1 -> %1 [at] domain3

Regards,
John