Preventing Apache From Being A Mail Relay

Home » CentOS » Preventing Apache From Being A Mail Relay
CentOS 18 Comments

I am trying to recall back at least 2 years, and my notes are poor, and my searching appears to be worst…

Seems I recall that last when I set up my apache server, the spammers were posting to it so it would send out the spam on port 25. There was some conf that I did to block this, but I did not document it, and I can’t find any reference to this. I don’t think my memory is that bad, but it IS sunday…

I don’t want to put up this new server and have it flooding the world with spam and then get the server blocked. So do I remember correctly that this was a problem? Is it still, and how is this prevented?

Thanks. Am putting up better notes this time around.

18 thoughts on - Preventing Apache From Being A Mail Relay

  • Am 03.03.2013 22:30, schrieb Robert Moskowitz:

    Don’t run doubtful applications together with apache. Then there is little risk to be misused. Back in time there has been a pretty bad
    “formmail” cgi around which could be easily misused. Be careful with other applications these days like with wordpress and such.

    The default SELinux on CentOS does prevent apache to send mail using the sendmail binary:

    # getsebool httpd_can_sendmail httpd_can_sendmail –> off


  • There was an attack, and if you search you will find references to it, where the spammers post to your web server in such a way that they relay out port 25. They send to your port 80, but you send out port 25. For example:

    My old server has been running smoothly for over two years, but it is time to bring the software current. I did all the work on this back then, or maybe before and copied from my earlier server. This time I am trying to build everything clean and document every change I make.

  • This is probably such an old attack, that ‘modern’ apache builds block it by default. It had nothing to do with email cgi or forms.

  • Since this server is only apache and supplies ntp for internal systems, I am able to run with selinux.

  • I have vague (and very distant ~98ish?) memories of apache deployments coming with a mail.cgi that was poorly secured and often exploited to send out emails, but I think that’s long since gone the way of the dodo birds. you have to go to some lengths to make webservers interact with email servers. if you’re really worried about it, you should also look into removing/blocking proxy connections:

  • Am 03.03.2013 22:49, schrieb Robert Moskowitz:

    Such a misbehaviour would be caused by a misconfigured apache proxy setup.


  • That may have been the attack vector way back when. Now the proxy directives come commented out, so supposedly you are suppose to know the risks of running a proxy.

  • It is coming back now through a pair of dark glasses. Just haven’t built a public web server is so long, as the old one just ran for as little as I needed it, that I lost the notes on the problem. Looks like current defaults do not allow this.

  • Once upon a time, it worked this way out of the box. I did NOT set up proxy, and I was being pounded, and found I had to turn it off. Now knowing what to look for, I found my notes and it was back on my ’07 server.

    There is no reason for a general web server to function as a proxy, so for some time it has come with that part commented out. I looked a another ’10 box (CentOS 5.5) that had apache installed but never used and the proxy part was commented out.

    So yes, anyone turning on proxy today without care gets what they set up. But again, who needs proxying on a general web server?

  • Not anymore. Once upon a time, the internet was a nice place and so what if you proxied? But the dragons were always lurking there, ready to feed…

  • If / when I get the guts to build my own Apache web server…I would think that the ONLY way to do it would be to document EVERYTHING….sort of as a “Just-In-Case” policy?….or is it only after you’ve built it?…and when you make CHANGES to your server….THAT’S when you document everything?….

    EGO II

  • Not to start an selinux flamewar but there is no reason that selinux can not be used on any server in any role serving any content for any audience unless there is a craptastic control panel such as cpanel or others of its ilk present.


  • The workflow I have adopted with respect to system administration is to use a project management application, such as Trac (originally) or Redmine/ChileProject (currently), and to open an issue for each activity that I perform on any of my servers. Therein I record the motivation for the activity, the desired and intended result, and log my time.

    I also record each problem that is encountered, solutions as they are found, and insights as they are revealed. I attach configuration files, copies of related email messages, and make any notes right on the issue. As Redmine allows full-text case-insensitive searches I
    can usually find in fairly short order the details about anything I
    have done that I can at least dimly recall doing.

    I add subsequent maintenance events either directly to the original issue or create a new issue and link that to the original.

    While hardly perfect this practice has saved my behind on several occasions. In fact I would recommend that one document each package install from the initial selection of the software and go on from there. I have had occasion where the question asked of me was “why was this package selected instead of that package?” Having the answer to hand along with the evidence has short-circuited the blame-game on at least one occasion.

  • You can go all the way back to the first release of Fedora or RHEL and check the configuration files. mod_proxy has never been enabled by default, and the included example was not an open one:

    #ProxyRequests On
    # # Order deny,allow
    # Deny from all
    # Allow from

    If you go back as far as Apache 1.0 (late 90s), you’ll find a configuration file that still does not enable proxy by default, but did not include an example of limiting the Proxy command as above.

  • I remember having a problem back in the RH (not RHEL) 5 or 6 era where I was using ProxyPass or rewriterules with [P} and it somehow enabled random proxy requests which I noticed when the logs filled up with requests that were intended to run up to run up some other sites ad counters. It is too far back to remember if that was the default from the install or was related to what I did to enable the specific proxy functions I needed, though.