I'm running sendmail 8.13.8 on a Debian 3.1 box, and am in the process
of implementing ldap_routing to reject mail sent to invalid addresses.

For this, I'm doing full LDAP queries, and as far as I can tell so far,
things are working the way I want them to. In particular, if a message
is sent to a bogus address the SMTP connection is closed off with a 550
error.

However, the one problem is that this one completely preempts my aliases
list, and local admin addresses that have been defined there, including
root, postmaster, mailer-daemon, etc. are being rejected unless defined
in LDAP.

This server has several domains (and the LDAP directory supports several
several servers), and I'd really rather not have to go through and have
to list all the iterations of admin ids and domains in LDAP.

Is there another way of doing this, or am I missing something here?

Smith

In article <Gd70h.292$yy2.52@newsfe11.phx> NFN Smith
<worldoff9908@sacbeemail.com> writes:
>
>However, the one problem is that this one completely preempts my aliases
>list, and local admin addresses that have been defined there, including
>root, postmaster, mailer-daemon, etc. are being rejected unless defined
>in LDAP.
>
>This server has several domains (and the LDAP directory supports several
>several servers), and I'd really rather not have to go through and have
>to list all the iterations of admin ids and domains in LDAP.
>
>Is there another way of doing this, or am I missing something here?

From cf/README:

the <bounce> argument, if present and not the word "passthru", dictates
that mail should be bounced if neither a mailHost nor mailRoutingAddress
is found

I.e. give that argument as "passthru", and sendmail will continue trying
to resolve the address by the standard logic. You just need to make sure
that this logic includes "look up local aliases" (e.g. all domains must
be in local-host-names), and *doesn't* include "send onto internal
server without verification" (having all domains in local-host-names
should take care of that too).

--Per Hedeland
per@hedeland.org

Per Hedeland wrote:

> From cf/README:
>
> the <bounce> argument, if present and not the word "passthru", dictates
> that mail should be bounced if neither a mailHost nor mailRoutingAddress
> is found
>
> I.e. give that argument as "passthru", and sendmail will continue trying
> to resolve the address by the standard logic. You just need to make sure
> that this logic includes "look up local aliases" (e.g. all domains must
> be in local-host-names), and *doesn't* include "send onto internal
> server without verification" (having all domains in local-host-names
> should take care of that too).

Somehow I had gotten the impression that "passthru" was synonymous with
a null setting for <bounce>.

I just went back and explicitly specified "passthru", and after getting
the spelling correct, it looks like things are working the way that I
want them to.

Thanks for the feedback.

Smith

In article <MGb0h.299$yy2.180@newsfe11.phx> NFN Smith
<worldoff9908@sacbeemail.com> writes:
>Per Hedeland wrote:
>
>> From cf/README:
>>
>> the <bounce> argument, if present and not the word "passthru", dictates
>> that mail should be bounced if neither a mailHost nor mailRoutingAddress
>> is found
>>
>> I.e. give that argument as "passthru", and sendmail will continue trying
>> to resolve the address by the standard logic. You just need to make sure
>> that this logic includes "look up local aliases" (e.g. all domains must
>> be in local-host-names), and *doesn't* include "send onto internal
>> server without verification" (having all domains in local-host-names
>> should take care of that too).
>
>Somehow I had gotten the impression that "passthru" was synonymous with
>a null setting for <bounce>.

Well, I'm not sure what you mean with "a null setting" - cf/README says
"if present", and at least for me simply leaving it out - as in

FEATURE(`ldap_routing')

or

FEATURE(`ldap_routing', , , , `strip')

- does indeed have the same effect as using passthru.

--Per Hedeland
per@hedeland.org

This is one that I thought I had figured out, but not quite, when I had
to stop before making a trip. I'm just finally getting back to it, but
something isn't quite working, yet.

Per Hedeland wrote:

>
> From cf/README:
>
> the <bounce> argument, if present and not the word "passthru", dictates
> that mail should be bounced if neither a mailHost nor mailRoutingAddress
> is found
>
> I.e. give that argument as "passthru", and sendmail will continue trying
> to resolve the address by the standard logic. You just need to make sure
> that this logic includes "look up local aliases" (e.g. all domains must
> be in local-host-names), and *doesn't* include "send onto internal
> server without verification" (having all domains in local-host-names
> should take care of that too).

At the moment, I have the following in my sendmail.mc file:

> LDAPROUTE_DOMAIN_FILE(`/etc/mail/local-host-names')dnl
> FEATURE(`ldap_routing',`ldap -1 -T<TMPF> -v mailHost -k (&(objectClass=inetOrgPerson)(mail=%0))',`ldap -1 -T<TMPF> -v mailRoutingAddress -k (&(objectClass=inetOrgPerson)(mail=%0))',`passthru ')dnl

(I also have confLDAP_DEFAULT_SPEC defined, but not shown in this example).

I also have all my local domains defined in /etc/mail/local-host-names .

Where I am currently is that I am making the LDAP query, and my LDAP
logs are showing that addresses that are listed in LDAP are being found,
and non-existent addresses are not being found (thus, the query is being
made correctly).

However, if the address is invalid, the message is still being passed
through, and the result continues to be an accept/bounce, rather than
the desired rejection. Messages to addresses in the local sendmail
infrastructure (aliases, virtusertable) are being handled correctly.

So, I'm still trying to get rejection of addresses that aren't defined
in LDAP, and not defined locally.

I think I'm close, but I don't quite have it.

Smith

Have you tried adding entries like the following to your virtusertable
for each of your hosted domains?

@example.com error:5.1.1:550 No such recipient
at example.com



On Nov 16, 11:45 am, NFN Smith <worldoff9...@sacbeemail.com> wrote:
> This is one that I thought I had figured out, but not quite, when I had
> to stop before making a trip. I'm just finally getting back to it, but
> something isn't quite working, yet.
>
> Per Hedeland wrote:
>
> > From cf/README:
>
> > the <bounce> argument, if present and not the word "passthru", dictates
> > that mail should be bounced if neither a mailHost nor mailRoutingAddress
> > is found
>
> > I.e. give that argument as "passthru", and sendmail will continue trying
> > to resolve the address by the standard logic. You just need to make sure
> > that this logic includes "look up local aliases" (e.g. all domains must
> > be in local-host-names), and *doesn't* include "send onto internal
> > server without verification" (having all domains in local-host-names
> > should take care of that too).At the moment, I have the following in my sendmail.mc file:
>
> > LDAPROUTE_DOMAIN_FILE(`/etc/mail/local-host-names')dnl
> > FEATURE(`ldap_routing',`ldap -1 -T<TMPF> -v mailHost -k (&(objectClass=inetOrgPerson)(mail=%0))',`ldap -1 -T<TMPF> -v mailRoutingAddress -k (&(objectClass=inetOrgPerson)(mail=%0))',`passthru ')dnl(I also have confLDAP_DEFAULT_SPEC defined, but not shown in this example).
>
> I also have all my local domains defined in /etc/mail/local-host-names .
>
> Where I am currently is that I am making the LDAP query, and my LDAP
> logs are showing that addresses that are listed in LDAP are being found,
> and non-existent addresses are not being found (thus, the query is being
> made correctly).
>
> However, if the address is invalid, the message is still being passed
> through, and the result continues to be an accept/bounce, rather than
> the desired rejection. Messages to addresses in the local sendmail
> infrastructure (aliases, virtusertable) are being handled correctly.
>
> So, I'm still trying to get rejection of addresses that aren't defined
> in LDAP, and not defined locally.
>
> I think I'm close, but I don't quite have it.
>
> Smith

Brian Ross wrote:
> Have you tried adding entries like the following to your virtusertable
> for each of your hosted domains?
>
> @example.com error:5.1.1:550 No such recipient
> at example.com
>

I just gave that one a try -- that does nicely for addresses that are
defined in aliases or virtusertable, but causes rejection of all other
traffic, including ones with valid LDAP entries.

Essentially, this is the reverse situation of when I was using
ldap_routing with 'bounce' defined (where only messages with valid LDAP
entries were accepted, and addresses locally defined in aliases or
virtusertable were rejected).

Smith

NFN Smith wrote:
> > FEATURE(`ldap_routing',`ldap -1 -T<TMPF> -v mailHost -k (&(objectClass=inetOrgPerson)(mail=%0))',`ldap -1 -T<TMPF> -v mailRoutingAddress -k (&(objectClass=inetOrgPerson)(mail=%0))',`passthru ')dnl
>

I'm not using FEATURE(`ldap_routing', *snip*), but have defined LDAP
individually per ressource, e.g.:

define(`ALIAS_FILE',
`ldap:-k"(&(objectClass=fhMailAlias)(mailAlias=%0))" -v"uid
,mailRoutingAddress"
, /etc/mail/aliases.root, /etc/mail/aliases.mailman, *snip*)

--
ska

In article <Id37h.39430$lv2.37774@newsfe06.phx> NFN Smith
<worldoff9908@sacbeemail.com> writes:
>
>At the moment, I have the following in my sendmail.mc file:
>
>> LDAPROUTE_DOMAIN_FILE(`/etc/mail/local-host-names')dnl
>> FEATURE(`ldap_routing',`ldap -1 -T<TMPF> -v mailHost -k
>(&(objectClass=inetOrgPerson)(mail=%0))',`ldap -1 -T<TMPF> -v
>mailRoutingAddress -k
>(&(objectClass=inetOrgPerson)(mail=%0))',`passthr u')dnl
>
>(I also have confLDAP_DEFAULT_SPEC defined, but not shown in this example).
>
>I also have all my local domains defined in /etc/mail/local-host-names .
>
>Where I am currently is that I am making the LDAP query, and my LDAP
>logs are showing that addresses that are listed in LDAP are being found,
>and non-existent addresses are not being found (thus, the query is being
>made correctly).
>
>However, if the address is invalid, the message is still being passed
>through, and the result continues to be an accept/bounce, rather than
>the desired rejection. Messages to addresses in the local sendmail
>infrastructure (aliases, virtusertable) are being handled correctly.

Could you try this (as root) with one of those invalid addresses:

sendmail -bv -d21.2 address@your.domain

--Per Hedeland
per@hedeland.org

Per Hedeland wrote:

>
> Could you try this (as root) with one of those invalid addresses:
>
> sendmail -bv -d21.2 address@your.domain

I checked with both a valid and invalid address, and except for the
address, both had the same output, where the message passed through all
the rules and selected a mailer. Output (in part) for an invalid
address shows:

> rewrite: ruleset ParseLocal input: bogus < @ fubar . com . >
> rewrite: ruleset ParseLocal returns: bogus < @ fubar . com . >
> rewrite: ruleset Parse1 input: bogus < @ fubar . com . >
> rewrite: ruleset LDAPExpand input: < bogus < @ fubar . com . > > < bogus @ fubar . com > < >
> rewrite: ruleset LDAPExpand input: < bogus < @ fubar . com . > > < @ fubar . com > < >
> rewrite: ruleset LDAPExpand returns: bogus < @ fubar . com . >
> rewrite: ruleset LDAPExpand returns: bogus < @ fubar . com . >
> rewrite: ruleset Parse1 returns: $# cyrusv2 $: bogus
> rewrite: ruleset parse returns: $# cyrusv2 $: bogus
> rewrite: ruleset 2 input: bogus
> rewrite: ruleset 2 returns: bogus
> rewrite: ruleset EnvToSMTP input: bogus
> rewrite: ruleset PseudoToReal input: bogus
> rewrite: ruleset PseudoToReal returns: bogus
> rewrite: ruleset MasqSMTP input: bogus
> rewrite: ruleset MasqSMTP returns: bogus < @ *LOCAL* >
> rewrite: ruleset EnvToSMTP returns: bogus < @ fubar . com . >
> rewrite: ruleset final input: bogus < @ fubar . com . >
> rewrite: ruleset final returns: bogus @ fubar . com
> bogus@aerogram.net... deliverable: mailer cyrusv2, user bogus@fubar.com

Smith

In article <eFp7h.8390$Le1.6365@newsfe10.phx> NFN Smith
<worldoff9908@sacbeemail.com> writes:
>Per Hedeland wrote:
>
>>
>> Could you try this (as root) with one of those invalid addresses:
>>
>> sendmail -bv -d21.2 address@your.domain
>
>I checked with both a valid and invalid address, and except for the
>address, both had the same output, where the message passed through all
>the rules and selected a mailer. Output (in part) for an invalid
>address shows:
>
>> rewrite: ruleset ParseLocal input: bogus < @ fubar . com . >
>> rewrite: ruleset ParseLocal returns: bogus < @ fubar . com . >
>> rewrite: ruleset Parse1 input: bogus < @ fubar . com . >
>> rewrite: ruleset LDAPExpand input: < bogus < @ fubar . com . >
>> < bogus @ fubar . com > < >
>> rewrite: ruleset LDAPExpand input: < bogus < @ fubar . com . >
>> < @ fubar . com > < >
>> rewrite: ruleset LDAPExpand returns: bogus < @ fubar . com . >
>> rewrite: ruleset LDAPExpand returns: bogus < @ fubar . com . >
>> rewrite: ruleset Parse1 returns: $# cyrusv2 $: bogus
>> rewrite: ruleset parse returns: $# cyrusv2 $: bogus

OK, so you are probably (intentionally or not) having sendmail defer the
valid-user check to the cyrusv2 mailer, at which point it is too late to
reject at the SMTP dialogue, since it is completed before sendmail hands
over the message to the mailer. If the users actually exist as local
Unix accounts (not a given with Cyrus), you can just add the 'w' flag to
the cyrusv2 mailer definition - if you are using MAILER(cyrusv2) from a
stock sendmail distribution, this can conveniently be done with

MODIFY_MAILER_FLAGS(`CYRUSV2', `+w')

in your .mc file (verify by checking the F= parameter on the Mcyrusv2
line in the generated sendmail.cf).

If on the other hand the valid local users *don't* necessarily exist as
local accounts, but are (at least some of them) only known internally to
Cyrus, things get a bit trickier - there's no support for doing reject
at the SMTP dialogue in this case with the stock sendmail config
package. I believe Andrzej Filip has devised some scheme for this
though, and posted about it here a number of times - check the group
archives. Or maybe Andrzej will chime in if needed...

--Per Hedeland
per@hedeland.org

Per Hedeland wrote:

> OK, so you are probably (intentionally or not) having sendmail defer the
> valid-user check to the cyrusv2 mailer, at which point it is too late to
> reject at the SMTP dialogue, since it is completed before sendmail hands
> over the message to the mailer.

That seems to be what I'm seeing. By the time a message is handed off
to the cyrusv2 mailer, sendmail has already accepted the message, and
the envelope has been discarded.

> If the users actually exist as local
> Unix accounts (not a given with Cyrus), you can just add the 'w' flag to
> the cyrusv2 mailer definition - if you are using MAILER(cyrusv2) from a
> stock sendmail distribution, this can conveniently be done with
>
> MODIFY_MAILER_FLAGS(`CYRUSV2', `+w')
>
> in your .mc file (verify by checking the F= parameter on the Mcyrusv2
> line in the generated sendmail.cf).

The only users that are locally defined in /etc/passwd would be
application-specific role accounts. Beyond that, the aliases list and
the virtusertable.

I checked this, and the result is that addresses defined locally:
/etc/passwd, aliases and virtusertable are being accepted, but addresses
known only to LDAP are being rejected.

>
> If on the other hand the valid local users *don't* necessarily exist as
> local accounts, but are (at least some of them) only known internally to
> Cyrus, things get a bit trickier - there's no support for doing reject
> at the SMTP dialogue in this case with the stock sendmail config
> package. I believe Andrzej Filip has devised some scheme for this
> though, and posted about it here a number of times - check the group
> archives. Or maybe Andrzej will chime in if needed...

And this is where I need to be going...

I'll make a check of NG archives, as well Andrzej's pages, and hope he
also may also add to this discussion...


Smith

NFN Smith wrote:
> Per Hedeland wrote:
>
> > OK, so you are probably (intentionally or not) having sendmail defer the
> > valid-user check to the cyrusv2 mailer, at which point it is too late to
> > reject at the SMTP dialogue, since it is completed before sendmail hands
> > over the message to the mailer.
>
> That seems to be what I'm seeing. By the time a message is handed off
> to the cyrusv2 mailer, sendmail has already accepted the message, and
> the envelope has been discarded.
>
> > If the users actually exist as local
> > Unix accounts (not a given with Cyrus), you can just add the 'w' flag to
> > the cyrusv2 mailer definition - if you are using MAILER(cyrusv2) from a
> > stock sendmail distribution, this can conveniently be done with
> >
> > MODIFY_MAILER_FLAGS(`CYRUSV2', `+w')
> >
> > in your .mc file (verify by checking the F= parameter on the Mcyrusv2
> > line in the generated sendmail.cf).
>
> The only users that are locally defined in /etc/passwd would be
> application-specific role accounts. Beyond that, the aliases list and
> the virtusertable.
>
> I checked this, and the result is that addresses defined locally:
> /etc/passwd, aliases and virtusertable are being accepted, but addresses
> known only to LDAP are being rejected.
>
> >
> > If on the other hand the valid local users *don't* necessarily exist as
> > local accounts, but are (at least some of them) only known internally to
> > Cyrus, things get a bit trickier - there's no support for doing reject
> > at the SMTP dialogue in this case with the stock sendmail config
> > package. I believe Andrzej Filip has devised some scheme for this
> > though, and posted about it here a number of times - check the group
> > archives. Or maybe Andrzej will chime in if needed...
>
> And this is where I need to be going...
>
> I'll make a check of NG archives, as well Andrzej's pages, and hope he
> also may also add to this discussion...

archived here

http://www.jmaimon.com/sendmail/anfi.homeunix.net

>
>
> Smith

In article <N7o8h.18418$tx3.12022@newsfe07.phx> NFN Smith
<worldoff9908@sacbeemail.com> writes:
>
>> If the users actually exist as local
>> Unix accounts (not a given with Cyrus), you can just add the 'w' flag to
>> the cyrusv2 mailer definition - if you are using MAILER(cyrusv2) from a
>> stock sendmail distribution, this can conveniently be done with
>>
>> MODIFY_MAILER_FLAGS(`CYRUSV2', `+w')
>>
>> in your .mc file (verify by checking the F= parameter on the Mcyrusv2
>> line in the generated sendmail.cf).
>
>The only users that are locally defined in /etc/passwd would be
>application-specific role accounts. Beyond that, the aliases list and
>the virtusertable.
>
>I checked this, and the result is that addresses defined locally:
>/etc/passwd, aliases and virtusertable are being accepted, but addresses
>known only to LDAP are being rejected.

But, but... - you are using ldap_routing, it should take care of the
users defined in LDAP - what are they doing in this post-ldap_routing-
processing step?:-) Do you actually just have ldap_routing "route" to
the local host, using it purely as existence check rather than for
actual routing?

--Per Hedeland
per@hedeland.org

Per Hedeland wrote:

>> I checked this, and the result is that addresses defined locally:
>> /etc/passwd, aliases and virtusertable are being accepted, but addresses
>> known only to LDAP are being rejected.
>
> But, but... - you are using ldap_routing, it should take care of the
> users defined in LDAP - what are they doing in this post-ldap_routing-
> processing step?:-) Do you actually just have ldap_routing "route" to
> the local host, using it purely as existence check rather than for
> actual routing?

That's what I don't get. I thought something odd there.

Let me back up a bit....

When I had ldap_routing set to do 'bounce', mail for addresses known to
LDAP was being accepted, but for addresses defined in aliases and
virtusertable was being rejected.

When I went to 'passthru' that fixed the problem with the locally
defined addresses, but produces the current situation.

Thus, the question becomes in how to get sendmail to reject messages
only if the target address isn't known in LDAP, but without preempting
local definitions (and not having to resort to listing all the local
definitions in LDAP).

Smith

In article <1SF8h.11349$OO2.1623@newsfe06.phx> NFN Smith
<worldoff9908@sacbeemail.com> writes:
>Per Hedeland wrote:
>
>>> I checked this, and the result is that addresses defined locally:
>>> /etc/passwd, aliases and virtusertable are being accepted, but addresses
>>> known only to LDAP are being rejected.
>>
>> But, but... - you are using ldap_routing, it should take care of the
>> users defined in LDAP - what are they doing in this post-ldap_routing-
>> processing step?:-) Do you actually just have ldap_routing "route" to
>> the local host, using it purely as existence check rather than for
>> actual routing?
>
>That's what I don't get. I thought something odd there.

Unfortunately you didn't answer the important question above, the one
without the smiley - having a full understanding of how you actually use
ldap_routing is needed to figure this out. So maybe the simplest way to
get the full details of that is if you run that

sendmail -bv -d21.2 address@your.domain

again, but now with an address that is found in LDAP.

>Let me back up a bit....
>
>When I had ldap_routing set to do 'bounce', mail for addresses known to
>LDAP was being accepted, but for addresses defined in aliases and
>virtusertable was being rejected.
>
>When I went to 'passthru' that fixed the problem with the locally
>defined addresses, but produces the current situation.
>
>Thus, the question becomes in how to get sendmail to reject messages
>only if the target address isn't known in LDAP, but without preempting
>local definitions (and not having to resort to listing all the local
>definitions in LDAP).

Yes, all understood (and info available in the thread:-), but the
question can't be adequately answered without more details.

--Per Hedeland
per@hedeland.org

Per Hedeland wrote:

>>> But, but... - you are using ldap_routing, it should take care of the
>>> users defined in LDAP - what are they doing in this post-ldap_routing-
>>> processing step?:-) Do you actually just have ldap_routing "route" to
>>> the local host, using it purely as existence check rather than for
>>> actual routing?
>> That's what I don't get. I thought something odd there.
>
> Unfortunately you didn't answer the important question above, the one
> without the smiley - having a full understanding of how you actually use
> ldap_routing is needed to figure this out.

Sorry that I missed that.

What should be happening is that mail addressed to Cyrus mailboxes is
being routed via entries in the mailertable. The intent with
ldap_routing would be merely for validity checking of addresses, and not
full routing.

> So maybe the simplest way to
> get the full details of that is if you run that
>
> sendmail -bv -d21.2 address@your.domain
>
> again, but now with an address that is found in LDAP.


Here's the full dump:

> rewrite: ruleset canonify input: root
> rewrite: ruleset Canonify2 input: root
> rewrite: ruleset Canonify2 returns: root
> rewrite: ruleset canonify returns: root
> rewrite: ruleset parse input: root
> rewrite: ruleset Parse0 input: root
> rewrite: ruleset Parse0 returns: root
> rewrite: ruleset ParseLocal input: root
> rewrite: ruleset ParseLocal returns: root
> rewrite: ruleset Parse1 input: root
> rewrite: ruleset Parse1 returns: $# cyrusv2 $: root
> rewrite: ruleset parse returns: $# cyrusv2 $: root
> rewrite: ruleset 2 input: root
> rewrite: ruleset 2 returns: root
> rewrite: ruleset EnvToSMTP input: root
> rewrite: ruleset PseudoToReal input: root
> rewrite: ruleset PseudoToReal returns: root
> rewrite: ruleset MasqSMTP input: root
> rewrite: ruleset MasqSMTP returns: root < @ *LOCAL* >
> rewrite: ruleset EnvToSMTP returns: root < @ fubar . com . >
> rewrite: ruleset final input: root < @ fubar . com . >
> rewrite: ruleset final returns: root @ fubar . com
> rewrite: ruleset canonify input: root
> rewrite: ruleset Canonify2 input: root
> rewrite: ruleset Canonify2 returns: root
> rewrite: ruleset canonify returns: root
> rewrite: ruleset 1 input: root
> rewrite: ruleset 1 returns: root
> rewrite: ruleset final input: root
> rewrite: ruleset final returns: root
> rewrite: ruleset canonify input: gtest0 @ fubar . com
> rewrite: ruleset Canonify2 input: gtest0 < @ fubar . com >
> rewrite: ruleset Canonify2 returns: gtest0 < @ fubar . com . >
> rewrite: ruleset canonify returns: gtest0 < @ fubar . com . >
> rewrite: ruleset parse input: gtest0 < @ fubar . com . >
> rewrite: ruleset Parse0 input: gtest0 < @ fubar . com . >
> rewrite: ruleset Parse0 returns: gtest0 < @ fubar . com . >
> rewrite: ruleset ParseLocal input: gtest0 < @ fubar . com . >
> rewrite: ruleset ParseLocal returns: gtest0 < @ fubar . com . >
> rewrite: ruleset Parse1 input: gtest0 < @ fubar . com . >
> rewrite: ruleset LDAPExpand input: < gtest0 < @ fubar . com . > > < gtest0 @ fubar . com > < >
> rewrite: ruleset LDAPExpand input: < gtest0 < @ fubar . com . > > < @ fubar . com > < >
> rewrite: ruleset LDAPExpand returns: gtest0 < @ fubar . com . >
> rewrite: ruleset LDAPExpand returns: gtest0 < @ fubar . com . >
> rewrite: ruleset Parse1 returns: $# cyrusv2 $: gtest0
> rewrite: ruleset parse returns: $# cyrusv2 $: gtest0
> rewrite: ruleset 2 input: gtest0
> rewrite: ruleset 2 returns: gtest0
> rewrite: ruleset EnvToSMTP input: gtest0
> rewrite: ruleset PseudoToReal input: gtest0
> rewrite: ruleset PseudoToReal returns: gtest0
> rewrite: ruleset MasqSMTP input: gtest0
> rewrite: ruleset MasqSMTP returns: gtest0 < @ *LOCAL* >
> rewrite: ruleset EnvToSMTP returns: gtest0 < @ fubar . com . >
> rewrite: ruleset final input: gtest0 < @ fubar . com . >
> rewrite: ruleset final returns: gtest0 @ fubar . com
> gtest0@fubar.com... deliverable: mailer cyrusv2, user gtest0@fubar.com

That's an LDAP-defined address, and it's being correctly identified.
However, when I run the same thing against a non-existent address, I get
the same output (with the different address, of course), concluding with:

> rewrite: ruleset final returns: bogus @ fubar . com
> bogus@fubar.com... deliverable: mailer cyrusv2, user bogus@fubar.com

An address defined in the virtusertable (spamtrap@fubar.com, which
points to gtest0@fubar.com) is handled correctly:

> rewrite: ruleset final returns: gtest0 @ fubar . com
> gtest0@fubar.com... deliverable: mailer cyrusv2, user gtest0@fubar.com

That's good news.

However, at this point, I'm still not rejecting the messages where the
address isn't in LDAP, and not defined locally.

Thanks for your patience in walking me through this.

Smith

In article <W6L8h.65683$DH2.31213@newsfe10.phx> NFN Smith
<worldoff9908@sacbeemail.com> writes:
>Per Hedeland wrote:
>>
>> Unfortunately you didn't answer the important question above, the one
>> without the smiley - having a full understanding of how you actually use
>> ldap_routing is needed to figure this out.
>
>Sorry that I missed that.
>
>What should be happening is that mail addressed to Cyrus mailboxes is
>being routed via entries in the mailertable. The intent with
>ldap_routing would be merely for validity checking of addresses, and not
>full routing.

So what is ldap_routing expected to return, and how will that be mapped
in the mailertable?

>> So maybe the simplest way to
>> get the full details of that is if you run that
>>
>> sendmail -bv -d21.2 address@your.domain
>>
>> again, but now with an address that is found in LDAP.
>
>
>Here's the full dump:
[snip]
>> rewrite: ruleset canonify input: gtest0 @ fubar . com
>> rewrite: ruleset Canonify2 input: gtest0 < @ fubar . com >
>> rewrite: ruleset Canonify2 returns: gtest0 < @ fubar . com . >
>> rewrite: ruleset canonify returns: gtest0 < @ fubar . com . >
>> rewrite: ruleset parse input: gtest0 < @ fubar . com . >
>> rewrite: ruleset Parse0 input: gtest0 < @ fubar . com . >
>> rewrite: ruleset Parse0 returns: gtest0 < @ fubar . com . >
>> rewrite: ruleset ParseLocal input: gtest0 < @ fubar . com . >
>> rewrite: ruleset ParseLocal returns: gtest0 < @ fubar . com . >
>> rewrite: ruleset Parse1 input: gtest0 < @ fubar . com . >
>> rewrite: ruleset LDAPExpand input: < gtest0 < @ fubar . com .
>> > < gtest0 @ fubar . com > < >
>> rewrite: ruleset LDAPExpand input: < gtest0 < @ fubar . com .
>> > < @ fubar . com > < >
>> rewrite: ruleset LDAPExpand returns: gtest0 < @ fubar . com . >
>> rewrite: ruleset LDAPExpand returns: gtest0 < @ fubar . com . >
>> rewrite: ruleset Parse1 returns: $# cyrusv2 $: gtest0
>> rewrite: ruleset parse returns: $# cyrusv2 $: gtest0
>> rewrite: ruleset 2 input: gtest0
>> rewrite: ruleset 2 returns: gtest0
>> rewrite: ruleset EnvToSMTP input: gtest0
>> rewrite: ruleset PseudoToReal input: gtest0
>> rewrite: ruleset PseudoToReal returns: gtest0
>> rewrite: ruleset MasqSMTP input: gtest0
>> rewrite: ruleset MasqSMTP returns: gtest0 < @ *LOCAL* >
>> rewrite: ruleset EnvToSMTP returns: gtest0 < @ fubar . com . >
>> rewrite: ruleset final input: gtest0 < @ fubar . com . >
>> rewrite: ruleset final returns: gtest0 @ fubar . com
>> gtest0@fubar.com... deliverable: mailer cyrusv2, user gtest0@fubar.com
>
>That's an LDAP-defined address, and it's being correctly identified.

How do you determine that? There is no indication that ldap_routing -
i.e. the LDAPExpand ruleset - succeeded in finding anything at all, and
clear indication that it didn't find the user, since it retries with an
@domain lookup. Finally it returns the input address, this will happen
either if it didn't find anything in LDAP (assuming passthru), or if it
didn't get a new mailRoutingAddress but got a mailHost that was in class
{w} - but if it did the latter in the above trace, it would have been
based only on the domain part.

There is also no indication of a successful mailertable lookup, that
will always be followed by a call to the MailerToTriple ruleset AFAIK,
and there is none in the above trace. The original address returned by
LDAPExpand is apparently resolved to the cyrusv2 mailer due to your
having that defined as the local mailer (note the stripping of the
domain-part, which is then added back in the mailer-specific rulesets).

It seems to me that rather than just munging the output from sendmail,
which makes troubleshooting hard enough, you're actually munging the
*input*, which makes the data entirely useless.

--Per Hedeland
per@hedeland.org

Per Hedeland wrote:

>> What should be happening is that mail addressed to Cyrus mailboxes is
>> being routed via entries in the mailertable. The intent with
>> ldap_routing would be merely for validity checking of addresses, and not
>> full routing.
>
> So what is ldap_routing expected to return, and how will that be mapped
> in the mailertable?

Abstractly, that would be whether the address exists or not. I think
I'm missing something on mapping to the mailertable.

In the mailertable, I have:

fubar.com cyrusv2:/var/lib/imap/socket/lmtp


>>> rewrite: ruleset Parse1 input: gtest0 < @ fubar . com . >
>>> rewrite: ruleset LDAPExpand input: < gtest0 < @ fubar . com .
>>>> < gtest0 @ fubar . com > < >
>>> rewrite: ruleset LDAPExpand input: < gtest0 < @ fubar . com .
>>>> < @ fubar . com > < >
>>> rewrite: ruleset LDAPExpand returns: gtest0 < @ fubar . com . >
>>> rewrite: ruleset LDAPExpand returns: gtest0 < @ fubar . com . >
>>> rewrite: ruleset Parse1 returns: $# cyrusv2 $: gtest0
>>> rewrite: ruleset parse returns: $# cyrusv2 $: gtest0
>>> rewrite: ruleset 2 input: gtest0
>>> rewrite: ruleset 2 returns: gtest0
>>> rewrite: ruleset EnvToSMTP input: gtest0
>>> rewrite: ruleset PseudoToReal input: gtest0
>>> rewrite: ruleset PseudoToReal returns: gtest0
>>> rewrite: ruleset MasqSMTP input: gtest0
>>> rewrite: ruleset MasqSMTP returns: gtest0 < @ *LOCAL* >
>>> rewrite: ruleset EnvToSMTP returns: gtest0 < @ fubar . com . >
>>> rewrite: ruleset final input: gtest0 < @ fubar . com . >
>>> rewrite: ruleset final returns: gtest0 @ fubar . com
>>> gtest0@fubar.com... deliverable: mailer cyrusv2, user gtest0@fubar.com

>> That's an LDAP-defined address, and it's being correctly identified.
>
> How do you determine that?

All I have to go on is the the LDAP logs. When I'm making a query on an
invalid address, I get a log entry that looks like:

> Nov 16 18:23:39 fubar slapd[28582]: conn=6630 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text=

By contrast, if I'm querying on a valid address, the result is
nentries=1. Thus, I'm working on the assumption that this means that
I'm getting a successful lookup. But there's no evidence in sendmail
that there's any indications a positive response from LDAP.

Specifically, an LDAP log looks like:

> Nov 17 06:25:10 fubar slapd[28582]: conn=8863 op=0 BIND dn="cn=Manager,dc=fubar,dc=" method=128
> Nov 17 06:25:10 fubar slapd[28582]: conn=8863 op=0 BIND dn="cn=Manager,dc=fubar,dc=" mech=SIMPLE ssf=0
> Nov 17 06:25:10 fubar slapd[28582]: conn=8863 op=0 RESULT tag=97 err=0 text=
> Nov 17 06:25:10 fubar slapd[28582]: conn=8863 op=1 SRCH base="ou=user,dc=fubar,dc=" scope=2 deref=0 filter="(&(objectClass=inetOrgPerson)(mail=gtest0@ fubar.com))"
> Nov 17 06:25:10 fubar slapd[28582]: conn=8863 op=1 SRCH attr=objectClass mailRoutingAddress
> Nov 17 06:25:10 fubar slapd[28582]: conn=8863 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
> Nov 17 06:25:10 fubar slapd[28582]: conn=8863 op=2 SRCH base="ou=user,dc=fubar,dc=" scope=2 deref=0 filter="(&(objectClass=inetOrgPerson)(mail=gtest0@ fubar.com))"
> Nov 17 06:25:10 fubar slapd[28582]: conn=8863 op=2 SRCH attr=objectClass mailHost
> Nov 17 06:25:10 fubar slapd[28582]: conn=8863 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text=
> Nov 17 06:25:10 fubar slapd[28582]: conn=8863 op=3 SRCH base="ou=user,dc=fubar,dc=" scope=2 deref=0 filter="(&(objectClass=inetOrgPerson)(mail=@fubar. com))"
> Nov 17 06:25:10 fubar slapd[28582]: conn=8863 op=3 SRCH attr=objectClass mailRoutingAddress
> Nov 17 06:25:10 fubar slapd[28582]: conn=8863 op=3 SEARCH RESULT tag=101 err=0 nentries=0 text=
> Nov 17 06:25:10 fubar slapd[28582]: conn=8863 op=4 SRCH base="ou=user,dc=fubar,dc=" scope=2 deref=0 filter="(&(objectClass=inetOrgPerson)(mail=@fubar. com))"
> Nov 17 06:25:10 fubar slapd[28582]: conn=8863 op=4 SRCH attr=objectClass mailHost
> Nov 17 06:25:10 fubar slapd[28582]: conn=8863 op=4 SEARCH RESULT tag=101 err=0 nentries=0 text=
> Nov 17 06:25:12 fubar slapd[28582]: conn=8863 op=5 UNBIND
> Nov 17 06:25:12 fubar slapd[28582]: conn=8863 fd=14 closed

I will verify with the guy that did my LDAP implementation that I have
the query configured correctly, but to me, this dump indicates that I'm
getting successful queries.


> There is no indication that ldap_routing -
> i.e. the LDAPExpand ruleset - succeeded in finding anything at all, and
> clear indication that it didn't find the user, since it retries with an
> @domain lookup.

Right. If the query itself is working, then getting that data back into
sendmail. The other thing I'm seeing in the LDAP log is that we're
actually getting 4 queries -- two that are successful, followed by two
queries on just the domain. I don't know why that's happening. Perhaps
the result that sendmail is getting is the output of the final (failed)
query?

> Finally it returns the input address, this will happen
> either if it didn't find anything in LDAP (assuming passthru), or if it
> didn't get a new mailRoutingAddress but got a mailHost that was in class
> {w} - but if it did the latter in the above trace, it would have been
> based only on the domain part.

I should have asked before: assuming that I am getting a successful
query, how does that information get back into sendmail (that is, how is
it supposed to)?

> There is also no indication of a successful mailertable lookup, that
> will always be followed by a call to the MailerToTriple ruleset AFAIK,
> and there is none in the above trace. The original address returned by
> LDAPExpand is apparently resolved to the cyrusv2 mailer due to your
> having that defined as the local mailer (note the stripping of the
> domain-part, which is then added back in the mailer-specific rulesets).

That would also be a problem. My mailer definitions are:

define(`CYRUSV2_MAILER_ARGS', `FILE /var/run/cyrus/socket/lmtp')dnl
define(`confLOCAL_MAILER',`cyrusv2')dnl
MAILER(cyrusv2_2)dnl

The cyrusv2_2.m4 file is slightly modified from the stock distribution,
where the declaration of cyrusv2 has been changed to:

S=EnvFromSMTP/HdrFromSMTP

>
> It seems to me that rather than just munging the output from sendmail,
> which makes troubleshooting hard enough, you're actually munging the
> *input*, which makes the data entirely useless.

No, I'm only munging the output display. gtest0 is actually a valid
address.

Sorry that I have to munge, because I know it makes it harder for
troubleshooting, but those are the constraints that I have to work under.

Smith

In article <1t%8h.5972$zT4.4391@newsfe11.phx> NFN Smith
<worldoff9908@sacbeemail.com> writes:
>Per Hedeland wrote:
>
>>> What should be happening is that mail addressed to Cyrus mailboxes is
>>> being routed via entries in the mailertable. The intent with
>>> ldap_routing would be merely for validity checking of addresses, and not
>>> full routing.
>>
>> So what is ldap_routing expected to return, and how will that be mapped
>> in the mailertable?
>
>Abstractly, that would be whether the address exists or not.

But I'm not interested in abstractly - I want *concretely*.:-)

>In the mailertable, I have:
>
> fubar.com cyrusv2:/var/lib/imap/socket/lmtp

But I guess you also have fubar.com in local-host-names - mailertable is
never consulted for domains that are considered "local".

>Specifically, an LDAP log looks like:
>
>> Nov 17 06:25:10 fubar slapd[28582]: conn=8863 op=0 BIND
>dn="cn=Manager,dc=fubar,dc=" method=128
>> Nov 17 06:25:10 fubar slapd[28582]: conn=8863 op=0 BIND
>dn="cn=Manager,dc=fubar,dc=" mech=SIMPLE ssf=0
>> Nov 17 06:25:10 fubar slapd[28582]: conn=8863 op=0 RESULT tag=97 err=0 text=
>> Nov 17 06:25:10 fubar slapd[28582]: conn=8863 op=1 SRCH
>base="ou=user,dc=fubar,dc=" scope=2 deref=0
>filter="(&(objectClass=inetOrgPerson)(mail=gtest0 @fubar.com))"
>> Nov 17 06:25:10 fubar slapd[28582]: conn=8863 op=1 SRCH
>attr=objectClass mailRoutingAddress

This means that sendmail wants the value of the mailRoutingAddress
attribute for the "object" that matches the filter.

>> Nov 17 06:25:10 fubar slapd[28582]: conn=8863 op=1 SEARCH RESULT
>tag=101 err=0 nentries=1 text=

And I *guess* that this means that LDAP found a matching object, but it
either didn't have a mailRoutingAddress attribute or it was an empty
string.

>I will verify with the guy that did my LDAP implementation that I have
>the query configured correctly, but to me, this dump indicates that I'm
>getting successful queries.

"Something" succeeds, but I don't think sendmail can realize that - it
asks for the value of an attribute and doesn't get any. Well, actually a
map lookup *can* differentiate between "lookup succeeded but no value
found" and "lookup failed", by means of special map options and ditto
interpretation of the result - I would expect this to work for LDAP
lookups too, but ldap_routing doesn't do that.

>Right. If the query itself is working, then getting that data back into
>sendmail. The other thing I'm seeing in the LDAP log is that we're
>actually getting 4 queries -- two that are successful, followed by two
>queries on just the domain. I don't know why that's happening.

I told you - it's because sendmail considers the first lookups as failed,
and retries with the @domain "wildcard fallback".

>I should have asked before: assuming that I am getting a successful
>query, how does that information get back into sendmail (that is, how is
>it supposed to)?

It is supposed to get an e-mail address for mailRoutingAddress and/or a
next-hop host for mailHost, and then it will combine them into a routing
decision. In principle it will send to mailHost with mailRoutingAddress
as recipient address, but lack of only one of the two is interpreted in
a reasonable manner (e.g. mailRoutingAddress but no mailHost =>
effectively an alias/virtusertable entry). Of course the actual
attribute names are configurable in the ldap_routing arguments.

For *only* "existence check" you could e.g. have mailRoutingAddress ==
original address and no mailHost, or no mailRoutingAddress but mailHost
== localhost or better a real name for the server where local delivery
is done (then it could work for actual routing from other hosts too).

However the solution to your problem that I'm thinking of would require
that you actually get a little something more back from LDAP, to be able
to differentiate from the "passthru" case. Either a mailRoutingAddress
with a different domain-part or a "distinct" value for mailHost could be
used to have mailertable direct the LDAP hits to a different mailer.
E.g. LDAP hits could go to a version of cyrus that didn't have the F=w
check, while the passthrus would go to the local mailer that had one.

The question is of course how things could possibly work for you
*without* "passthru" - are you sure you actually had that working?
If so, maybe you can post the same trace for a valid address with
"bounce", plus the FEATURE(ldap_routing) line you're using for that?

--Per Hedeland
per@hedeland.org