Results 1 to 3 of 3
First, let me apologize for not including a bunch of log files. I haven't posted 15 or more questions/answers to this forum, and I am not allowed to post urls, ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
- 02-27-2012 #1
- Join Date
- Aug 2009
Odd sendmail problem
First, let me apologize for not including a bunch of log files. I haven't posted 15 or more questions/answers to this forum, and I am not allowed to post urls, or the "at" sign in my question. Thus, I can't provide logs.
In any case, here's my issue. I run a small local LAN with traditional inside-the-lan ip addresses attached to a single firewall/router with one static externally visible ip address. I run sendmail and do nameservice from a box on the LAN behind the firewall with standard address translation for nameservice.
This works fine for almost all issues, but a couple of days ago one site has started blocking my email on the basis that it thinks I am likely spam.The blocking is not occurring at the recipient site itself,but is not being relayed by what appears to be a commercial spam protection outfit. The error message on my blocked email, and the errors in /var/log/maillog suggested that the problem was that it couldn't see my MX record on DNS lookup, and thought I might be spoofing through a bad relay.
I hadn't been making my MX record visible because it has a local "illegal" ip address that can't be addressed from the WAN anyway. Against my better judgment, I added the "illegal" address to my external name file in /var/named/chroot/var/named as the MX record.
That caused the site to go ahead and relay the mail to my target.
So, here's my issue. Let's say that XXX is the external ip address of my site (I'd be happy to include the appropriate log and error files, but I can't). Let's assume that YYY is the internal address of my nameserver/mailserver.
For nameservice, I advertise XXX as being the nameserver and use NAT and port forwarding to just send all DNS requests to the nameserver. That works fine. HOWEVER, sendmail insists on bypassing the firewall and identifying the mailserver with the internal address, e.g. when I look at the conversation, I get something like:
/usr/lib/sendmail -v targetaddress < /dev/null
targetaddress... Connecting to [localhost] via relay...
220 servername ESMTP Sendmail 8.14.5/8.14.5; Mon, 27 Feb 2012 12:15:04 -0500
>>> EHLO servername
250-servername Hello servername [YYY], pleased to meet you
Thus, it seems I have two problems. The first is that my mailserver is giving up it's real whole name rather than masquerading as the firewall name, and it's giving up its internal ip address rather than the external address. I would like to masquerade it the same way I do nameservice, but I am clearly not doing so.
How can I make my mailserver inside the firewall pretend to be the firewall with respect to name and ip address? With bind, I can define internal and external zones that take care of it. Is there something similar with sendmail?
My sendmail.cf file, with urls taken out so I can post in the forum is:
dnl define delivery mode: interactive, background, or queued
dnl virtusertable: redirect incoming mail to virtual domain to particular user or domain
FEATURE(`virtusertable',`hash -o /etc/mail/virtusertable')dnl
dnl genericstable: rewrite sender address for outgoing mail
dnl FEATURE(dnsbl, `someplace', `Rejected - see someplace/rbl/')dnl
dnl FEATURE(dnsbl, `someplace3', `Dialup - see someplaceorg/dul/')dnl
dnl FEATURE(dnsbl, `someplace', `Open spam relay - see someplace./rss/')dnl
dnl SASL Configuration
dnl SMTP AUTH in sendmail 8.10-8.13[/url]
dnl Next two lines are for SMTP Authentication
define(`confAUTH_MECHANISMS', `LOGIN PLAIN')dnl
dnl Next line stops sendmail from allowing auth without encryption
define(`confAUTH_OPTIONS', `A p y')dnl
dnl STARTTLS configuration
dnl SMTP STARTTLS in sendmail/Secure Switch
dnl Uncomment next lines to hide identity of mail serve
dnl define(`confSMTP_LOGIN_MSG', `$j server ready at $b')dnl
- 02-27-2012 #2
- Join Date
- Aug 2009
... I should add, in case the above wasn't clear, that "regular" address masquerading works fine in the mail header. It's the ip address that's the issue...
- 02-27-2012 #3
- Join Date
- Aug 2009
Boy do I feel stupid.
Here's the answer.
It *is* just like doing NAT. In the nameserver, for the external named configuration file, I simply added an MX record with the firewall as the mailserver (even though it's really forwarding packets to the mailserver behind the firewall), and CNAME'd the mailserver's complete name back to the firewall. I'd give the example, but I still don't have 15 posts...