[2 days left] What’s wrong with your cloud strategy? Learn why multicloud solutions matter with Nimble Storage.Register Now

x
?
Solved

Correcting Sendmail warning that a local address may be forged

Posted on 2006-07-09
5
Medium Priority
?
1,416 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
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 3
  • 2
5 Comments
 
LVL 22

Assisted Solution

by:pjedmond
pjedmond earned 2000 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 2000 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

 [eBook] Windows Nano Server

Download this FREE eBook and learn all you need to get started with Windows Nano Server, including deployment options, remote management
and troubleshooting tips and tricks

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

The purpose of this article is to demonstrate how we can use conditional statements using Python.
Google Drive is extremely cheap offsite storage, and it's even possible to get extra storage for free for two years.  You can use the free account 15GB, and if you have an Android device..when you install Google Drive for the first time it will give…
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.
Suggested Courses
Course of the Month14 days, 18 hours left to enroll

649 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