klukac
asked on
Correcting Sendmail warning that a local address may be forged
I have purchased a fixed IP from a local ISP in Alaska, but my sendmail server is located in Michigan on a /29 network behind a NAT'd firewall. By adding a relay for the Alaska IP in /etc/mail/access.db, I'm able to use my pop3 mail client in Alaska to download mail from Michigan, which is great. However, I get this warning in my maillog:
Jul 9 03:39:47 myhost sendmail[17036]: k697dk7k017036: from=<user1@mydomain.com>,
To get rid of the (may be forged) warning, I added this entry to /etc/mail/relay-domains:
acsalaska.net
1.2.3.4
But that didn't help. I'm registered with Network Solutions, but I don't list routable IPs there that aren't associated with hosting a service, so I'm not sure what to do. I plan to keep the IP in Alaska (because we're moving there) and transition my network from Michigan to Alaska. I understand that the problem is caused by reverse DNS not matching the forward lookup, but the solution to this isn't apparent. I've seen the same error in Michigan when I implemented DHCP - since my client host name(s) could no longer be associated with a fixed IP, I removed the A records and started seeing may-be-forged errors in the maillog. Have read all I can find on how to use the access db to fix this, but no cigar. The solutions may be different, but in any event I need help. Thanks in advance.
Jul 9 03:39:47 myhost sendmail[17036]: k697dk7k017036: from=<user1@mydomain.com>,
To get rid of the (may be forged) warning, I added this entry to /etc/mail/relay-domains:
acsalaska.net
1.2.3.4
But that didn't help. I'm registered with Network Solutions, but I don't list routable IPs there that aren't associated with hosting a service, so I'm not sure what to do. I plan to keep the IP in Alaska (because we're moving there) and transition my network from Michigan to Alaska. I understand that the problem is caused by reverse DNS not matching the forward lookup, but the solution to this isn't apparent. I've seen the same error in Michigan when I implemented DHCP - since my client host name(s) could no longer be associated with a fixed IP, I removed the A records and started seeing may-be-forged errors in the maillog. Have read all I can find on how to use the access db to fix this, but no cigar. The solutions may be different, but in any event I need help. Thanks in advance.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
ok, I found out how to do reverse lookup for DHCP clients, so I'm fairly confident I can fix what's causing the forgery warnings on my LAN clients. The time server connection fails with an error that I'll report to Redhat, and it's probably not related to the forgery warnings anyway. So I'm not sure what to do with this question...if there's nothing more to say, I guess I can close it :(
ASKER
I know that Redhat is not FreeBSD, but it seems odd that sendmail implementations would differ across Linux distributions in a way that affects the terminology.
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/sendmail.html says that:
"Hosts that are listed as OK, which is the default, are allowed to send mail to this host along as the mail's final destination is the local machine... Hosts that have the RELAY option for their hostname are allowed to send mail for any destination through this mail server."
So based on that /etc/mail/access should read:
127.0.0.1 OK
10.0.1 RELAY
1.2.3.4 RELAY
This has no impact on the forgery warning but I find it strange that the same sendmail configuration would have different implications depending on the host version of Linux. Your thoughts?
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/sendmail.html says that:
"Hosts that are listed as OK, which is the default, are allowed to send mail to this host along as the mail's final destination is the local machine... Hosts that have the RELAY option for their hostname are allowed to send mail for any destination through this mail server."
So based on that /etc/mail/access should read:
127.0.0.1 OK
10.0.1 RELAY
1.2.3.4 RELAY
This has no impact on the forgery warning but I find it strange that the same sendmail configuration would have different implications depending on the host version of Linux. Your thoughts?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Hello,
You are correct in why you are receiving the message. The way to eliminate it is to have your ISP change the PTR record or delegate that to you if you want to control it through RFC2317. However, you might be able to trick your local mailserver by putting the IP and the matching hostname in your /etc/hosts and making sure your /etc/nsswitch.conf file has the line with "hosts:" showing "files" before the "dns" so that your mail program looks at /etc/hosts before DNS. Once it finds a satisfying solution in /etc/hosts it goes on with out the warning.
hosts: files dns myhostname
Message me directly if you need more help. I have a little SMTP expertise.
Thanks,
David
You are correct in why you are receiving the message. The way to eliminate it is to have your ISP change the PTR record or delegate that to you if you want to control it through RFC2317. However, you might be able to trick your local mailserver by putting the IP and the matching hostname in your /etc/hosts and making sure your /etc/nsswitch.conf file has the line with "hosts:" showing "files" before the "dns" so that your mail program looks at /etc/hosts before DNS. Once it finds a satisfying solution in /etc/hosts it goes on with out the warning.
hosts: files dns myhostname
Message me directly if you need more help. I have a little SMTP expertise.
Thanks,
David
ASKER
1.2.3.4 OK
and then added a hostname entry:
1-2-3-4-dsl-rb1.acsalaska.
but I still get a mail may be forged entry in the maillog (not sure if having both entries in the access file is a good thing).
Since as you mention the address block concerned is controlled by my ISP's DNS servers, it's possible that there's no solution to this problem...
However there should be a solution to my other problem, which is that I see the same warning when sending mail from a DHCP client on my LAN. The client itself isn't listed in the zone file as it was when I was working with static IPs, but the access file should have taken care of this:
10.0.1 RELAY
To avoid checking local domains against blacklists, I also have this entry:
Connect:10.0.1 OK
Again, don't know if having both entries is a good idea.
Another factor to consider is the time stamp. To my knowledge, I've never been able to connect to a time/NTP server from either my Redhat or my Debian/Ubuntu servers, so I set the time manually, checking it against (ok I'm an idiot) the battery-operated clock in my living room instead of my cellphone. After a power outage I rarely remembered to check the time, which was hardly worth doing since I was winging it anyway.
My client here in Alaska happens to correspond exactly with the time on my cellphone, so it must have some sort of NTP connection. It's 11 minutes off the clock on my Michigan server after accounting for a four-hour difference for time zones. So for example, an email sent from this client at 01:34 pm
shows up in the maillog as having been sent at 17:23:10. Given these discrepancies, it would be more logical for sendmail to issue a warning, however I obviously don't know the exact criteria, so let me know your thoughts on this, thanks.