David G. Miller wrote:
Bryan Hepworth wrote:
route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.2.0 * 255.255.255.0 U 0 0 0 eth1
169.254.0.0 * 255.255.0.0 U 0 0 0 eth1
94.0.0.0 93.0.0.100 255.0.0.0 UG 0 0 0 eth0
92.0.0.0 93.0.0.100 255.0.0.0 UG 0 0 0 eth0
93.0.0.0 * 255.0.0.0 U 0 0 0 eth0
default 192.168.2.1 0.0.0.0 UG 0 0 0 eth1
The 169.254.0.0 entry is for compatibility with a Microsoft
peer-to-peer networking. It shouldn't hurt anything. The 94.0.0.0,
92.0.0.0 and 93.0.0.0 entries are probably not what you want unless
the route to these subnets should still be out eth0 (the 93.1.1.208
NIC). My take on your original posting was the eth0 was no longer in
use.
dig internal
; <<>> DiG 9.2.4 <<>> any internal.coxagri.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 8694
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
NXDOMAIN is dig's way of saying it can't find an IP address for
internal.coxagri.com. See if you can get this boxes name and IP
address to resolve through dig. Sendmail likes to have it's hostname
resolvable through DNS.
Cheers,
Dave
Dave
Thanks for your reply to this. When I was doing further checks I found
that it was also failing reverse dns look ups. So I bit the bullet and
started to learn about dns. Would you have any advice to offer as to
best practice for this?
I was thinking that we need an internal dns server to keep sendmail
happy with all the internal people that use it to send out email.
Sendmail isn't currently taking mail in yet directly. That's taken from
the box that's hosted at the ISP and brought in by fetchmail. Long term
this was going to change and the MX record externally (at the ISP) was
going to point to our adsl router.
Any advice would be much appreciated.
Bryan
