unqualified aliases usable with relay-domains?

Hi,

I have a sendmail 8.13.8 deployment in the inbound mailstream
before my organizations primary internal mail server. I deal in mail
for only a single domain name.

I need to do some alias expansion on this box based upon LDAP data
such as this:

# msmith, aliases, sendmail, services, mydomain, com
dn:
sendmailMTAKey=msmith,ou=aliases,ou=sendmail,ou=services,dc= mydomain,dc=com
objectClass: sendmailMTAAliasObject
sendmailMTAKey: msmith
sendmailMTAAliasValue: msmith@subdomain.mydomain.com
sendmailMTAAliasValue: msmith@gmail.com

I have an ldap ALIAS_FILE definition filtering on (sendmailMTAKey=
%0) and the alias expansion works in case of RCPT TO: but does
not work in case of RCPT TO:.

I believe that this is due to the fact that I do not have
mydomain.com in Class w. I accept mail for it and relay to it using
mailertable routing. Due to nuances of my Milter configuration, I can
not place mydomain.com in class w as the Milter is designed to work
with non-local mail.

I am finding that sendmail substitutes the fully-qualified
recipient address for %0 and as such I do not get a hit with the LDAP
query (as sendmailMTAKey is unqualified in the source directory).

Is there some way that I can get alias definitions with unqualified
LHS to work in a non-local environment (e.g, for all of my relay-
domains instead of all local-host-names) such that mail addressed to
msmith@mydomain.com (where I relay for mydomain.com) expands according
to an alias entry with LHS of msmith?

Thanks for any insight.

Re: unqualified aliases usable with relay-domains?

In article <1192510627.329928.225370@z24g2000prh.googlegroups.com>
decourl@gmail.com writes:
>
> I have a sendmail 8.13.8 deployment in the inbound mailstream
>before my organizations primary internal mail server. I deal in mail
>for only a single domain name.
>
> I need to do some alias expansion on this box based upon LDAP data
>such as this:
>
> # msmith, aliases, sendmail, services, mydomain, com
> dn:
>sendmailMTAKey=msmith,ou=aliases,ou=sendmail,ou=services,dc =mydomain,dc=com
> objectClass: sendmailMTAAliasObject
> sendmailMTAKey: msmith
> sendmailMTAAliasValue: msmith@subdomain.mydomain.com
> sendmailMTAAliasValue: msmith@gmail.com
>
> I have an ldap ALIAS_FILE definition filtering on (sendmailMTAKey=
>%0) and the alias expansion works in case of RCPT TO: but does
>not work in case of RCPT TO:.
>
> I believe that this is due to the fact that I do not have
>mydomain.com in Class w.

Correct.

> I accept mail for it and relay to it using
>mailertable routing. Due to nuances of my Milter configuration, I can
>not place mydomain.com in class w as the Milter is designed to work
>with non-local mail.

That sounds strange - the domain-stripping that happens with domains in
class w is only when the address is actually about to be handed over to
the local mailer (where aliasing kicks in) - a milter sees only the
original recipient address given at RCPT To:, AFAIK. However sendmail
will never consult the mailertable for domains in class w, so if you
really need that, you still can't use class w.

> I am finding that sendmail substitutes the fully-qualified
>recipient address for %0 and as such I do not get a hit with the LDAP
>query (as sendmailMTAKey is unqualified in the source directory).
>
> Is there some way that I can get alias definitions with unqualified
>LHS to work in a non-local environment (e.g, for all of my relay-
>domains instead of all local-host-names) such that mail addressed to
>msmith@mydomain.com (where I relay for mydomain.com) expands according
>to an alias entry with LHS of msmith?

The only way that I can see would require that you have rules for the
actual mailer chosen for delivery, that strip off the domain-part just
like the standard rules for delivering to the local mailer do. Aliasing
happens internally in the sendmail binary when invoking a mailer that
has the A flag, it's not something you can do with rules in sendmail.cf
at least if you want the one-to-many recipient expansion that aliases
can provide, and from your sample above it seems that you do.

I don't see a way to do that while still using the mailertable though,
but as you say that this is only for one domain and consequently only
one remote host, you should be able to resolve the address to the mailer
+ host with rules too, instead of using the mailertable. Another problem
is that the mailer presumably *wants* the domain-part if it's actually
doing remote delivery via SMTP, but you could hardwire that via the
mailer definition.

A quick hack at that, with absolutely zero testing and assuming that you
want something like the esmtp mailer, could look like this in your .mc
file - I've copied liberally from sendmail.cf, of course (take careful
note of the s):

LOCAL_RULE_0
R $* < @ mydomain.com. > $#mysmtp $@ my.internal.server. $: $1

LOCAL_RULESETS
SMyEnvToSMTP
R$+ $: $>PseudoToReal $1 sender/recipient common
R$+ $: $>MyMasqSMTP $1 qualify unqual'ed names
R$* < @ *LOCAL* > $* $: $1 < @ $j . > $2

SMyMasqSMTP
R$* < @ $* > $* $@ $1 < @ $2 > $3 already fully qualified
R$+ $@ $1 < @ mydomain.com. > add local qualification

MAILER_DEFINITIONS
Mmysmtp, P=[IPC], F=mDFMuXaA, S=EnvFromSMTP/HdrFromSMTP,
R=MyEnvToSMTP/HdrFromSMTP, E=\r\n, L=990,
T=DNS/RFC822/SMTP,
A=TCP $h


But all in all, I think the best solution would be for you to arrange to
have sendmailMTAKey in your LDAP data be a fully-qualified address - hm,
actually I think it should be possible to have both?

--Per Hedeland
per@hedeland.org