Solved

Correcting Sendmail warning that a local address may be forged

Posted on 2006-07-09
5
1,196 Views
Last Modified: 2013-12-16
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>, size=337, class=0, nrcpts=1, msgid=<1152431465.8402.30.camel@localhost.localdomain>, proto=SMTP, daemon=MTA, relay=1-2-3-4-dsl-rb1.acsalaska.net [1.2.3.4] (may be forged)

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.
0
Comment
Question by:klukac
  • 3
  • 2
5 Comments
 
LVL 22

Assisted Solution

by:pjedmond
pjedmond earned 500 total points
ID: 17067315
The 'may be forged' is as a result of charachteristics of the sender and the network connection to the server, and not the configuration of the server. It is there as a warning that the network address may not be accurate. In particular. because your address is being NATed, the IP address of your system (internal to the network), will not match the fixed IP address that you have associated with the DNS name concerned:

Mail header will indicate that the ip of the email source is say 192.168.1.10 (internal ip address) but your PC named mydomain.com......so it obviously won't match.

Next problem is that the fixed IP is reverse DNSed to 1-2-3-4-dsl-rb1.acsalaska.net because the resolving of the address block concerned is done via your ISPs DNS servers.

Your DNS is configured to resolve mydomain.com your fixed ip (1.2.3.4) to the outside of your network.

access.db is used to decide whether to reject or deny mail from various sources. By configuring 1.2.3.4 as relay, then the 1.2.3.4 will be accepted and relayed.

1.2.3.4      RELAY

Adding OK - is an even 'stronger' method of getting the mail accepted from the ip even if other rules might ersult in the email being rejected.

1.2.3.4      OK

..and is probably worth trying. Ultimately, what is being provided is a warning (that the address is spoofed), which indeed it could be.

Try using the OK directive, and see whether that works:

http://www.faqs.org/docs/securing/chap22sec178.html

(   (()
(`-' _\
 ''  ''




0
 

Author Comment

by:klukac
ID: 17077615
Thanks!  However sadly, I see no difference.  I tried first with just the ip (changing it from RELAY to OK)
1.2.3.4                  OK
and then added a hostname entry:
1-2-3-4-dsl-rb1.acsalaska.net    OK
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.



0
 

Author Comment

by:klukac
ID: 17094366
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 :(
0
 

Author Comment

by:klukac
ID: 17131800
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?

0
 
LVL 22

Accepted Solution

by:
pjedmond earned 500 total points
ID: 17138339
Remember that this is a warning only, It is saying that the email is not quite 'perfect', and as a result it is noting that there is the possibility that the email could have been forged. As for the different terminology, I didn't really explain it very well. Because the OK directive is for delivery to local accounts, the sendmail daemon considers that the email is less likely to be 'fraudulen' as most spammers are after systems that 'RELAY'. Hence the checks are less stringent.

BSD principles are even more 'severe' when it comes to security. Hence some warnings that are easy to 'turn off' or ignore on a linux system may require a user response on a BSD system. Although the systems are similar, their 'founding principles' are different.

(   (()
(`-' _\
 ''  ''

0

Featured Post

How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

Join & Write a Comment

Over the last ten+ years I have seen Linux configuration tools come and go. In the early days there was the tried-and-true, all-powerful linuxconf that many thought would remain the one and only Linux configuration tool until the end of times. Well,…
Using 'screen' for session sharing, The Simple Edition Step 1: user starts session with command: screen Step 2: other user (logged in with same user account) connects with command: screen -x Done. Both users are connected to the same CLI sessio…
Get a first impression of how PRTG looks and learn how it works.   This video is a short introduction to PRTG, as an initial overview or as a quick start for new PRTG users.
This demo shows you how to set up the containerized NetScaler CPX with NetScaler Management and Analytics System in a non-routable Mesos/Marathon environment for use with Micro-Services applications.

744 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

12 Experts available now in Live!

Get 1:1 Help Now