Several years ago, I'm obviously a bit rusty.
Its on the book shelf, and was on the desk & open when I posted my
question here. I had been trying for a few hours to figure out where in
1200+ pages the answer was hiding.
:-)
>> My guess is that it is something trivially simple, but not necessarily
>> obvious that I am missing.
>
> You need a 'MX' record for '
sub.example.com'. *IF* you want mail handled
> by a _different_ machine than the one at the address that '
sub.exmaple.com'
> resolves to.
>
Yes, I finally got that figured out and implemented.
It can't be a sendmail issue until the DNS is set up correctly.
> *AND* you have to tell sendmail on that 'different' machine that _it_ handles
> mail for that sub-domain.
>
Would these entries in virtusertable
us...@sub.example.com somelocaluser
us...@sub.example.com some...@remote.com
this entry in access
example.com RELAY
or an MX record for
example.com that points to
mx.example.com
be sufficient to do that?
If no, then, I am still confused.
As I now have something that is working right and shouldn't be working
at all.
Currently mail is going to the right place and things are working as
expected.
"
sub.example.com" is not be a member of the '{w}' class or the
'{VirtHost}' class.
echo '$={w}' | sendmail -bt returns
example.com
mx
localhost
[
ip.ad.of.mx]
mx.example.com
echo '$={VirtHost}' | sendmail -bt returns
example1.com
example2.com
example3.com
example4.com
example1-4.com have been set up in virtusertable and VIRTUSEER_DOMAIN
for years & work as expected.
FEATURE(`virtuser_entire_domain') isn't used in our configuration.
the only place that
sub.example.com shows up is in virtusertable
It works now & I don't know why.
:-)
> *BOTH* items are _required_.
>
>
That's what I am hearing, but not what I am seeing
From here it looks like an MX record in DNS for
sub.example.com was all
that I needed.
Any ideas?
--
Sincerely,
Nathan Gibbs
Christ Media
(315) 548-7647
http://www.cmpublishers.com