0

I am running a sendmail server on CentOS 6.8. For MTA connections on port25 I want to use tcpwrappers to reject host with no PTR DNS record.

so my hosts.allow looks like : sendmail: ALL EXCEPT UNKNOWN

My problem is the mail submission port on 587 seems to share this setting. The result is that roaming users (mostly on US Cellular) who don't have a PTR record for their current IP address get rejected before they can authenticate.

I can fix this by setting up sendmail: ALL in hosts allow, but this about triples the number of garbage connections from spammers on port 25.

Does anyone know a way to make sendmail call libwrap for port 25 connections but not for port 587 connections that will be authenticated ?

Thanks!

Improve this question
3
  • This might be more easily solved via e.g. require_rdns and then allowing your MSA users via delay_checks and AUTH, see cf/README. Commented Jan 27, 2017 at 0:19
  • FEATURE(`require_rdns') Commented Jan 27, 2017 at 0:32
  • FEATURE(`require_rdns') solved the problem. 587 works and 25 is rejected with a 550 error. I had already added the delay_checks hoping it would bypass tcpwrappers. Thanks for the prompt answer! Commented Jan 27, 2017 at 0:34

1 Answer 1

Reset to default
0

tcp_wrappers (last stable release: 1997) dates to an awkward phase of the Internet when OS and applications generally lacked suitable protections; since then OS now ship with firewalls by default and applications have all sorts of business logic available (features and milters in the case of sendmail) to keep the spammers to a dull roar. tcp_wrappers is problematic here as it is a single library, so would need two distinct versions of sendmail and probably some patching of sendmail for one to use the library via sendmail and the other sendmailmsp.

In this case sendmail has suitable features that will reject connections without rdns but allow relay to authenticated connections via the following sendmail.mc defines (see cf/README under the source for details on these, and how to rebuild sendmail.cf):

FEATURE(`delay_checks')dnl FEATURE(`require_rdns')dnl

(Lacking such, the next option would be to carry out the necessary business logic via a milter.) Note that the next expected move from the spammers would be to break an authenticated account and spam via that, so log monitoring, rate throttling, and so forth may need to be in place to limit and detect such.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.