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
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.
Dave
Thanks for the insight - I'm working on it over the weekend when everyone has gone home.
The public ip from this address is an ADSL link name rather than internal.coxagri.com
Having had a quick look at other people in the same scenario I have some reading to do. If you have any suggestions I'd be happy to hear them.
Thanks
Bryan
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
On 10/6/06, bryan@coxagri.com bryan@coxagri.com wrote:
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.
I think you should just configure your DNS for internal use or at least on the mail server...that way it would resolve mails for your local domain and send mails which are meant for other domains out of your network depending on your ISP
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
This is also possible and would not be much of an issue you would need to tell your ISP or you could do it on your own. Redirect all mail traffice MX to the IP address and you really don't have to do anything on your mail server or on the DNS...
This approach is better is better than fetchmail...
going to point to our adsl router.
Any advice would be much appreciated.
Bryan
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
On Fri, 2006-10-06 at 10:57 +0100, bryan@coxagri.com wrote:
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?
Get it working internally, first, and be certain you're familiar with it (your server, and DNS records in general) before you move beyond internal DNS serving.
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.
First advice: Before setting yourself up with a SMTP server accepting input from the public, learn about spam control. Once you start handling your own mail, you've also got to deal with all the spam that someone else would have been managing for you. You have to learn how to kill it properly, not get exploited, and not get blacklisted.
For internal networking, it probably is easier to have a local DNS server that takes care of address resolution (easier than maintaining hosts files, etc.). But be careful how you organise your internal mail if you want users to be able to post to the outside world using the same e-mail addresses. You won't be able to post from a domain name that's not recognised outside your LAN. There's nothing stopping you from having different responses to domain names inside and outside of your LAN (i.e. using a public domain name, inside and out, but inside your machines all have internal LAN IP addresses, for internal work, outside your domain has a real internet IP address for mail checks, etc.).
Subject: Re: OT sendmail delay
Tim
Thanks for the reply...
On Fri, 2006-10-06 at 10:57 +0100, bryan@coxagri.com wrote:
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?
Get it working internally, first, and be certain you're familiar with it (your server, and DNS records in general) before you move beyond internal DNS serving.
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.
First advice: Before setting yourself up with a SMTP server accepting input from the public, learn about spam control. Once you start handling your own mail, you've also got to deal with all the spam that someone else would have been managing for you. You have to learn how to kill it properly, not get exploited, and not get blacklisted.
The mailserver currently runs spamassassin, and testing with smtp auth and starttls also works. This was a requirement for getting port 25 opened by the isp. I've read about grey listing. Is there anything else you would recommend?
For internal networking, it probably is easier to have a local DNS server that takes care of address resolution (easier than maintaining hosts files, etc.). But be careful how you organise your internal mail if you want users to be able to post to the outside world using the same e-mail addresses. You won't be able to post from a domain name that's not recognised outside your LAN. There's nothing stopping you from having different responses to domain names inside and outside of your LAN (i.e. using a public domain name, inside and out, but inside your machines all have internal LAN IP addresses, for internal work, outside your domain has a real internet IP address for mail checks, etc.).
Everything that goes out is masqueraded as coxagri.com. It goes out to the smarthost at the ISP currently. My test ones made it out of the system OK to an external address. Is there anything else to be aware of?
Thanks
Bryan