Messages are rejected from a host not in DNS

[dotbill]

I need to have the ability to accept system messages from hosts throughout all of our data centers. The issue is that messages being sent from hosts that don't have the hostname in global DNS, are getting rejected. The work around has been to create an "A" record for each one of these hosts. This is cumbersome. We have 500+ hosts in 9 data centers. My fear is that we may also be missing mail from other sending hosts outside our organization.

Is there a way to turn off the "lookup check" feature?

Thank you

--
Bill

[dkelly]

Bill,

There isn't a way to disable the lookup.

You can allow access based on IP address or the alternative is to run an internal DNS server.

Cheers

Dave

[dotbill]

ok, I am running an internal dns server. The problem I'm describing has to do with Scalix dropping mail from a sender not in DNS by the same name as the sender address in the headers (I believe that's what's going on). I could conceivably add an entry for each sending host within my organization to the smtpd.cfg file and/or DNS zone files, but what about external senders? This is the other problem I'm hoping to solve. I have trouble believing that Scalix can't be configured to accept senders not in DNS. Qmail does, Sendmail and Postfix do.

Am I missing something?

Thanks

-b

[ScalixSupport]

Hi Bill,

I think there's some confusion here. Are the non-DNS servers trying to send to Scalix users within your server or using the Scalix server as a relay?

Thanks,
Rachel

[richa]

For Bill,
We are trying to send email from servers to Scalix.

[milanm]

Hello everyone,

I've spent a few hours today debugging this exact problem and I'd like some help. This is it, in a nutshell:

(1) Our scalix server is the only server in our organization (ourcompany.com)

(2) We have several linux servers in our company that perform various tasks, and from time to time, mail us with the results. We have noticed that these stopped messaging us, whenever their e-mail address includes "servername.ourcompany.com". This happens because scalix attempts to resolve the MX record of "servername.ourcompany.com" and as we don't have our servers exposed to the outside world, this fails.


There are two work-arounds, that I do not like:

(1) A quick and dirty fix is to go into /etc/hosts file on scalix server and to manually add all the servers. This is impractical and I wondered if there was some way to just tell scalix "ok, if you see something coming from ourcompany.com (or any subdomain of it) just accept it, don't do MX lookup on it - or any other DNS resolution".

(2) I could go through every single server and masquerade it so that "somename.ourcompany.com" is re-written as "ourcompany.com". However, I like knowing where the mail came from and I'd really like our servers to keep their own names.


From now on, let's suppose we pick one of our servers, atlas.ourcompany.com, as an example.

When I check the /var/log/maillog file for this entry, here is what I see:

Nov 14 16:10:22 email sendmail[4298]: kAELAH1Q004298: ruleset=check_mail, arg1=<root@atlas.ourcompany.com>, relay=root@localhost, reject=553 5.1.8 <root@atlas.ourcompany.com>... Domain of sender address root@atlas.ourcompany.com does not exist
Nov 14 16:10:22 email sendmail[4298]: kAELAH1Q004298: from=<root@atlas.ourcompany.com>, size=0, class=0, nrcpts=0, proto=ESMTP, relay=root@localhost


Hm, this is weird, I thought to myself. I thought that scalix would by default accept anything coming from our domain (ourcompany.com). After some reading through sendmail documentation and some helpful tips from #sendmail on irc.freenode.net, I stumbled upon concept of access list. This one is defined in /etc/mail/access.

I read up on it made it look like this:

# Check the /usr/share/doc/sendmail/README.cf file for a description
# of the format of this file. (search for access_db in that file)
# The /usr/share/doc/sendmail/README.cf is part of the sendmail-doc
# package.
#
# by default we allow relaying from localhost...
localhost.localdomain RELAY
localhost RELAY
127.0.0.1 RELAY
# added by me
ourcompany.com RELAY
atlas.ourcompany.com OK
someClientTLD.com OK
anotherClientTLD.ca OK


(for not, disregard someClient and anotherClient, I haven't gotten to testing them).

After these changes, I rebuilt the access.db:

makemap hash /etc/mail/access < /etc/mail/access

I then restarted sendmail on my centOS 4.4:

service sendmail restart


I tried another test from atlas.ourcompany.com but it failed with the identical message. At this point, I thought that somehow this access.db is not being read by scalix, or perhaps that something was superseding its authority. So I did a simple test where I added one more line:

rogers.com REJECT

I then rebuilt access.db and restarted sendmail and then I sent myself a message from my rogers.com account. Imagine my surprise when it actually bounced it. So it seems that this access.db is actually being picked up after all.

What I then need to know is why are my local subdomains (atlas.ourcompany.com, ulysses.ourcompany.com, harpy.ourcompany.com, etc.) not being allowed onto scalix? Am I doing something wrong in the settings above?

I should point out that my first experiment did not include atlas.ourcompany.com in access at all (I added it as an act of desperation). My first experiment in /etc/mail/access looked like this:

# Check the /usr/share/doc/sendmail/README.cf file for a description
# of the format of this file. (search for access_db in that file)
# The /usr/share/doc/sendmail/README.cf is part of the sendmail-doc
# package.
#
# by default we allow relaying from localhost...
localhost.localdomain RELAY
localhost RELAY
127.0.0.1 RELAY
ourcompany.com RELAY


And it still didn't work.


I should point out that the only two changes I did on scalix system were:

(1) I added the following to our /etc/mail/local-host-names:

ourcompany.com


(2) I installed spamassassin, following the knowledge base PDF document.



Any and all help appreciated. This is, as far as I can tell, the exact same issue that the original poster is trying to solve. Rather than trying to spam the boards with a new thread, I choose to go to this one. So please let me know why /etc/mail/access isn't working the way I think it should?

[chris]

Ok, you're getting that 553 because there is neither an A nor an MX for that machine. An A record is enough, sendmail just wants to be able to resolve the host.

If you add hostnames in your access that sendmail can't resolve, then it doesn't know which host that is from which it should accept mail. That's why your access doesn't work. If you use the @domain syntax in the access that would fly, but not hosts it can't resolve. The access isn't designed to fix dns problems, but rather to provide host based access control. It's not access control if I can claim to be securehost.yourcompany.com but am really evil.attacker.net ....

The quick and dirty fix is to disable that check by adding

dnl FEATURE(`accept_unresolvable_domains')dnl

to either sendmail.mc or submit.mc (depends on distro - don't have a CentOS on hand to test) then restarting sendmail (the sendmail init script should rebuild your conf automagically) then running omsendin to add the scalix specific stuff to sendmail. If that doesn't work, try deleting sendmail.cf and submit.cf by hand and restarting the daemon again, then omsendin again.

The *clean* fix would be to simply make host.company.com resolve to an ip address. All sendmail wants is an A-record for that host in DNS. If you can dig -t any the host and get an A or an MX back, you're golden.

Hope this helps,

Chris