Re: Logwatch report on another machine?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Tim:
>> If you have a properly set up local DNS and mail system, then your
>> internal mail will be handled all internally, and mail that goes to
>> outside addresses will be relayed from your SMTP server to the ISP's.
>> That's the "smart" part about it - it working out what's internal or
>> external, and routing things accordingly.

Timothy Murphy:
> I think that is exactly my problem -
> sendmail is not distinguishing properly between internal and external mail.

It does it by comparing the recipient domain name against its list of
what's considered local.  If it's on the local list, it handles it
internally.  Or, instead of a list of specific addresses, a rule that
can be applied to all of them.

This is easy to do when the local domain name is different from other
ones, but messier when you're using the same domain names publicly and
internally.

In my case, I've used a subdomain for the lan (e.g. lan.example.com),
and all machines are further sub-domains (e.g. box1.lan.example.com,
box2.lan.example.com, etc.).  So all I've got to do it tell sendmail
that anything inside lan.example.com is internal (one configuration
option setting for all boxes on the LAN, rather than having to list each
machine explicitly).

Since you're using one domain, and making each machine a hostname on the
same domain, you're probably going to have to list each local machine
explicitly.

> I read what you say, but I am not convinced that
> this is the cause of the problem.
> I cannot send email from helen to tim@alfred ,
> whether or not I have "192.168.2.2 alfred alfred.gayleard.com", etc,
> in /etc/hosts or just "192.168.2.2 alfred".

Make life easier for yourself, construct your hosts file as per the man
file (ip, FQDN, aliases).  Do everything according to the guides, you'll
(generally) have less headaches, that way.  Once you start trying to
kludge things, you tend to have to kludge things differently for
different things, some of which don't co-operate.

e.g. 192.168.2.2  alfred.gayleard.com  alfred

However, I think you're going to fall afoul of DNS, and playing with the
hosts file is going to be difficult.  I find it easier not to use them,
at all.

If I look up the MX record for your domain, it's "mail.gayleard.com",
that means that any mail addressed to any user at gayleard.com, and
probably to any subdomain, will use that SMTP server.  The MX record for
the domain will be looked up first, unless you configure sendmail to
work differently (I can't advise on that, I've never condigured sendmail
to work that way).

Play with the "dig" command (from the bind-utils RPM).  If you do "dig
gayleard.com" you'll find the IP for that domain, likewise if you do a
"dig alfred.gayleard.com" (you'll see the IP for that host).

If you do a "dig gayleard.com MX" you'll get the address of the server
handling mail for your domain (mail.gayleard.com).  But if you try to
"dig alfred.gayleard.com MX", there isn't an answer for who'll handle
mail for that particular host.  I'm not quite sure what sendmail will
do, but mail systems would typically not need MX records per subdomain,
there'd be one record for the whole domain, and the mail system would
just look up the MX record for the domain, perhaps not even trying
sub-domains, and mail.gayleard.com would be expected to handle the lot,
especially if sub-domains don't have their own MX records.

e.g. Imagine this:

     1. sending mail to testuser@xxxxxxxxxxxxxxxxxxx
     2. look for a MX record for alfred.gayleard.com to deliver mail,
        but doesn't get an answer
     3. now looks for a MX record for gayleard.com, and does get an
        answer to use mail.gayleard.com, tries sending mail to it
     4. mail.gayleard.com may reject mail for not having a "testuser"
        user
     5. mail.gayleard.com may reject mail because alfred.gayleard.com
        doesn't appear to exist

> I own the domain "gayleard.com".
> I have found there are some advantages in calling my machines
> helen.gayleard.com, alfred.gayleard.com, etc,
> even though these are not accessible from the internet.

That's probably fine for most things, but mail is going to be a curly
problem.  The simplest solution would probably be to abandon hosts file,
and set up an internal DNS server.  You'd serve records internally for
all your hosts name, and importantly, an internal MX record.

I thought of setting up my LAN as you've done, long ago, but decided
that it was too painful to try an work out the wrinkles.  Though I think
you could run an internal DNS server, with all addresses being internal
on the same domain, and either putting up with www.gayleard.com using an
internal address (if you have a public webserver), or putting the
external address in the records and putting up with not being able to
browse to it internally.

Perversely, if you'd used a completely bogus domain name, which usually
isn't a good idea, MX lookups would completely fail, and you'd probably
find the mail server would fall back to using A records (the IP for the
host in question), directly.

Not sure if I've covered all the points now, the brain has gone on
strike.

-- 
[tim@localhost ~]$ uname -r
2.6.25.3-18.fc9.i686

Don't send private replies to my address, the mailbox is ignored.  I
read messages from the public lists.



-- 
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux