Applying virtusertable style rewriting to non local-host-names?

familiacism
familiacism used Ask the Experts™
on
I have a Sendmail 8.12.6 relay box that simply virus/content scans incoming mail before forwarding it on to an internal Lotus Notes system.  What I want to do is provide 'virtusertable' style rewriting to messages coming through this relay that are ultimately destined for another MX.

From what I understand, the virtusertable is only applied to domains listed in the local-domain-names file.
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Top Expert 2005
Commented:
The puspose of the local-host-names file is to tell sendmail what host and domain names that it is to accept mail for. This doesn't necessarily mean that sendmail must deliver the mail to local accounts on that system. It can forward the mail via aliases, mailertable, or virtusetable to other systems.

In this case, what you want to do is to change the MX record for the domain(s), add those domains to the local-host-names file, and add records to virtusertable to redirect the mail to the various mail servers. The virtuserable file would contain entries something like:

user1@domain.tld         a-user@notes.domain.tld
user2@domain.tld         b-user@notes.domain.tld
@domain.tld              %1@notes.domain.tld
...
user1@other.tld          a-user@other.domain.tld
...

There's a good reference on using virtual addresses in sendmail at http://www.sendmail.org/virtual-hosting.html

Note that sendmail will re-write the address to be in the form user@mail-serv.domain.tld. Some mail servers like notes and exchange require a tweak to get them to accept mail addressed to the hostname instead of the domain name.

Author

Commented:
I appreciate the suggestion, but I need a solution that doesn't involve rewriting the domain portion of the recipient address.
Top Expert 2005

Commented:
If you need virtuser name re-writing I think you are stuck with the envelope recipient being user@host.domain.tld. Note that this doesn't change what the user sees, i.e., the From: header is left as it was.

The problem in leaving the host portion as just the domain is that you'd wind up with a mail loop. For mail to reach the sendmail box for any given domain the MX record for that domain has to point to the sendmail box. If the address isn't re-written to be user@host.domain.tld, sendmail would try to locate the mail server by an MX lookup. Since that point to the sendmail box we have a loop.
Ensure you’re charging the right price for your IT

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!

Author

Commented:
I'm NATing the IP associated with the MX record on traffic originating from outside my organization, so that's not necessarily true.

People who are attempting to send mail to my MX servers get NATed to my sendmail virus scanning relay, yet the sendmail system hits the internal notes server when it tries to connect to the same MX.
Top Expert 2005

Commented:
If you have a split DNS, with different targets for the MX records on the inside, then you might be okay with respect to a mail loop. I'd say try it and see what happens. If you attempt that config on a weekend or when there otherwise is little eamil traffic there won't be a serious disruption in service if there's a problem.

Author

Commented:
I tried it on a test system with the following results.  Sorry, I don't know if you can use fixed witdh fonts here.


# sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> $=w
[10.0.0.50]
local-hostname
localhost
[127.0.0.1]
> /map mailertable mydomain.com
map_lookup: mailertable (mydomain.com) no match (0)
> /map virtuser aliasaddress@mydomain.com
map_lookup: virtuser (aliasaddress@mydomain.com) returns realaddress@mydomain.com (0)
> 3,0 aliasaddress@mydomain.com
canonify           input: aliasaddress @ mydomain . com
Canonify2          input: aliasaddress < @ mydomain . com>
Canonify2        returns: aliasaddress < @ mydomain . com . >
canonify         returns: aliasaddress < @ mydomain . com . >
parse              input: aliasaddress < @ mydomain . com . >
Parse0             input: aliasaddress < @ mydomain . com . >
Parse0           returns: aliasaddress < @ mydomain . com . >
ParseLocal         input: aliasaddress < @ mydomain . com . >
ParseLocal       returns: aliasaddress < @ mydomain . com . >
Parse1             input: aliasaddress < @ mydomain . com . >
Mailertable        input: < mydomain . com> aliasaddress < @ mydomain . com. >
Mailertable        input: mydomain . < com> aliasaddress < @ mydomain . com. >
Mailertable      returns: aliasaddress < @ mydomain . com . >
Mailertable      returns: aliasaddress < @ mydomain . com . >
MailerToTriple     input: < > aliasaddress < @ mydomain . com . >
MailerToTriple   returns: aliasaddress < @ mydomain . com . >
Parse1           returns: $# esmtp $@ mydomain . com . $: aliasaddress < @ mydomain . com . >
parse            returns: $# esmtp $@ mydomain . com . $: aliasaddress < @ mydomain . com . >
Top Expert 2005

Commented:
Well, it looks like your virtusertable map works, so re-writing and delivery should work. Try i on the live server and lets see what happens.

Author

Commented:
The virtuser map works.  Unfortunately as the rule parsing output shows, it never gets applied.
Top Expert 2005

Commented:
Right, but what does the local-host-names file contain? It needs the local domain name and mailertable must not contain the domain.

Author

Commented:
If the local-host-names file contains the domain name and the mailertable doesn't, the address will be rewritten then delivered locally instead of relayed.

Author

Commented:
Well I think I found a real simple solution to this issue.  I went into the guts of the virtuser rewriting rules in sendmail.cf and made the following change.

Was:

# handle virtual users
R$+                     $: <!> $1               Mark for lookup
R<!> $+ < @ $={VirtHost} . >   $: < $(virtuser $1 @ $2 $@ $1 $: @ $) > $1 < @ $2 . >
R<!> $+ < @ $=w . >    $: < $(virtuser $1 @ $2 $@ $1 $: @ $) > $1 < @ $2 . >
... more ...


Is now:

# handle virtual users
R$+                     $: <!> $1               Mark for lookup
R<!> $+ < @ $* . >      $: < $(virtuser $1 @ $2 $@ $1 $: @ $) > $1 < @ $2 . >


What this does is instead of mapping against the virtuser map only on local and virthost domains, it maps again the virtuser map for ALL domains.  I can't think of any issue this would cause, except for a slight performance hit on MTAs that accept a lot of mail locally.

Thanks for your help.
I get this: (notice canonify) tcasales is the local user

> 3,0 sales@tcacomputers.com
canonify           input: sales @ tcacomputers . com
Canonify2          input: sales < @ tcacomputers . com >
tcacomputers.com: Name server timeout
Canonify2        returns: sales < @ tcacomputers . com . >
canonify         returns: sales < @ tcacomputers . com . >
== Ruleset 3,0 (3) status 75
parse              input: sales < @ tcacomputers . com . >
Parse0             input: sales < @ tcacomputers . com . >
Parse0           returns: sales < @ tcacomputers . com . >
ParseLocal         input: sales < @ tcacomputers . com . >
ParseLocal       returns: sales < @ tcacomputers . com . >
Parse1             input: sales < @ tcacomputers . com . >
Recurse            input: tcasales
canonify           input: tcasales
Canonify2          input: tcasales
Canonify2        returns: tcasales
canonify         returns: tcasales
parse              input: tcasales
Parse0             input: tcasales
Parse0           returns: tcasales
ParseLocal         input: tcasales
ParseLocal       returns: tcasales
Parse1             input: tcasales
Parse1           returns: $# local $: tcasales
parse            returns: $# local $: tcasales
Recurse          returns: $# local $: tcasales
Parse1           returns: $# local $: tcasales
parse            returns: $# local $: tcasales

I assume that is an error?
Top Expert 2005

Commented:
"tcacomputers.com: Name server timeout" is an error and indicates a DNS problem, which I think we've already solved in your other question.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial