Skip to main content

Exim posing as Sendmail: Fixing Sender and Return-Path headers

Exim


If you are having problems changing the Sender and Return-Path headers, make sure that you are editing the right configuration file. On my CentOS 5.6:

[root@server mail]# ll /usr/sbin/sendmail
lrwxrwxrwx 1 root root 21 Oct 26  2009 /usr/sbin/sendmail -> /etc/alternatives/mta
[root@server mail]# ll /etc/alternatives/mta
lrwxrwxrwx 1 root root 23 Apr  9 07:48 /etc/alternatives/mta -> /usr/sbin/sendmail.exim
[root@server mail]# ll /usr/sbin/sendmail.exim 
lrwxrwxrwx 1 root root 4 Apr  9 07:45 /usr/sbin/sendmail.exim -> exim

I spent some time trying to figure out why my changes to the sendmail.mc file were being ignored. Naturally, Exim configuration is different than Sendmail. You need to edit the /etc/exim/exim.conf file:

remote_smtp:
  driver = smtp
  return_path = bounce@domain.com
  headers_rewrite = apache@* info@domain.com s

Don't forget the "s" at the end. See this page for more information: http://www.exim.org/exim-html-2.00/doc/html/spec_32.html#SEC669

If you are OK with displaying the apache user name (ie "Sender: apache@subdomain.domain.com") in the email header, then just update the qualify_domain configuration option in the same file.

qualify_domain = domain.com

This will fix the domain only (ie "Sender: apache@domain.com").

Sendmail


If you are indeed using Sendmail, then update your /etc/mail/sendmail.mc file.

LOCAL_DOMAIN(`domain.com')dnl
MASQUERADE_AS(`domain.com')dnl
FEATURE(`masquerade_envelope')dnl
FEATURE(masquerade_entire_domain)dnl
MASQUERADE_DOMAIN(`domain.com')dnl

If this configuration file does not exist, you need to install the sendmail-cf package first. Once you are done updating all the relevant configuration options, run the following command to generate your /etc/mail/sendmail.cf file.

make -C /etc/mail

Finally, restart sendmail:

service sendmail restart

Comments

Popular posts from this blog

Securing Symfony2 REST services with FOSOAuthServerBundle

Overview In my previous article, I wrote about setting up a Symfony2 REST service using FOSRestBundle. However, this REST service was behind a firewall protected by a generic form_login provider. Not really ideal if you wish to open your REST API to other applications. So in this article, I will try to explain how to set up FOSOAuthServerBundle to protect your REST API methods using OAuth2. Before we start getting into the gritty details, it is a good idea to have a look at the official OAuth2 documentation . Let's begin... FOSOAuthServerBundle Installation You have to install v1.1.0 of FOSOAuthServerBundle if you are using Symfony 2.0.x. If not, see the docs . First, add the following entries to your deps file: [FOSOAuthServerBundle] git=git://github.com/FriendsOfSymfony/FOSOAuthServerBundle.git target=bundles/FOS/OAuthServerBundle version=origin/1.1.x [oauth2-php] git=git://github.com/FriendsOfSymfony/oauth2-php.git Run the vendors script to install these...

Unexpected token "name" of value "if" ("end of statement block" expected) in "WebProfilerBundle:Collector:logger.html.twig"

Encountered this WebProfilerBundle error message when I ran the bin/vendors script to update my Symfony2 bundles. Make sure your deps file is up to date; you need to pay special attention to your version values. In this case, update your twig version to v1.2.0 as illustrated below: [twig] git=http://github.com/fabpot/Twig.git version=v1.2.0 Run the vendors script to update your bundle and the error message should disappear. You can get the most up to date deps file from the symfony-standard repository located at: https://github.com/symfony/symfony-standard/blob/master/deps

A Parcelable Tutorial for Android

Parcelable Interface Overview In one of my earlier posts, I mentioned writing an article about FOSOAuthBundle integration with an Android client. To keep that article to the point, I need to explain some concepts beforehand. One of the important concepts is the Android Parcelable interface that allows data to be transferred between different processes/threads. Certain network operations with Android such as authentication with OAuth2 and then fetching data from a REST endpoint should be performed in the background in order not to block the UI thread. This requires data to be fetched by a service (I have opted for Intent Services in my implementation) in the background and then passed back to the calling activity/fragment with a result callback. This is where the Parcelable interface comes into play. Basically, the Parcelable interface allows your classes to be flattened inside a message container called a Parcel to facilitate high performance inter process communication. The rece...