Modify The Actual Sendmail

Ref. Website :

Modify the actual file


1. The most important change you need to make is this first step. You must comment out the following line:

DAEMON_OPTIONS(`Port=smtp,Addr=, Name=MTA’)dnl

This will allow sendmail to make connections with machines other than the localhost. Duh. The reason for having this line included (turned on) by default will be left as an exercise for the reader.

2. Comment out the following line:


If this line is NOT commented out, you will open yourself up to more spam as sendmail will not do one of its basic checks on the incoming MTA.

3. Another key change is to set up your ISP as your “smart host”. This is done by the following replace:

dnl define(`SMART_HOST’,`smtp.your.provider’)  Becomes

define(`SMART_HOST’,`’)   (or whatever your ISP’s SMTP gateway is)

You are essentially using your ISP as a mail relay. This is the same technique that spammers use (in an attempt) to hide their identity. Here, we do it so that the mail will be sourced from an established IP that will pass a reverse DNS test. The server at will very likely require a login to relay like this. We will take care of that later. Your ISP sees this as an SMTP (port 25) connection just like you sent it from an MUA like Outlook. Most large organizations like AOL, Hotmail and Juno will not accept mail from your DSL or cable-modem address. You do not have to do this to make your server work, but expect a large number of bounces if you don’t.

4. Add the following line:

define(`confBIND_OPTS’, `WorkAroundBrokenAAAA’)dnl

This change is a work-around for broken name servers. Its not a big deal although some of the blacklists (See below) recommend you have this enabled.

5. Replace the following line to fine tune the response to MTA queries and increase your privacy:

define(`confPRIVACY_FLAGS’, `authwarnings,novrfy,noexpn,restrictqrun’)dnl  Becomes

define(`confPRIVACY_FLAGS’, `goaway,restrictqrun’)dnl

This increases security by limiting the amount of information your sendmail server spews out to door-knockers. This is also an anti-spam measure. Note that “goaway” is a short-hand version of many of the flags in the original configuration line.

6. This one is just for fun and probably violates some RFCs so I would not recommend doing it. Add the following:

define(`confSMTP_LOGIN_MSG’,`$j Microsoft SMTPSVC 4.0.1095.2600′)

This makes the mail server advertise itself as the defined string during SMTP connections. I did this in an attempt to fool people into believing that I was running a Microsoft server. Security through obscurity. It doesn’t work. Any scanning tool such as Nessus can see right through this ruse.

7. Uncomment the following line:


Another non-essential change, however it provides some extra information when spammers attempt to connect or relay through your machine.

8. Now we add some heavyweight spam fighters. The blacklists. Add the following lines:

FEATURE(dnsbl,`’,`”550 Mail from site rejected; see”‘)dnl
FEATURE(enhdnsbl,`’,`”550 Server blocked see:”$&{client_addr}’,`t’)dnl
FEATURE(dnsbl, `’, `”550 Email rejected – see”‘)dnl

These are only some of the blacklists available. A good list can be found here. Be careful about using some of those listed on that site as they are very aggressive and may cause false positives. The whole idea of blacklists has caused some vociferous arguments. If you are gun shy about possibly blocking some legitimate email, don’t use them or use something tame like McFadden Associates blacklist which will allow legit users to over-ride your blacklist. The “enhdnsbl” is an enhanced blacklist check that gives you other options on the FEATURE line. Check the homepage of the sites for instructions on how to use the dnsbl command with their particular blacklist.
NOTE: We no longer use or recommend the SORBS blacklist because of unreliable data and inaccessible web page.

9. Replace the following line and modify it as required.

MASQUERADE_AS(`’)dnl Becomes


This causes all sent mail to appear to come from

10. Replace the following line and modify it as required.



Note this is nearly identical to the previous line except without the single quotes. Don’t know about this one although it comes directly from Red Hat documentation, I don’t believe it is required (???).

11. Uncomment the following:


This is similar to the previous masquerade statement except in also masquerades the entire envelope.

12. Uncomment the following line:


This causes all hosts to be masqueraded as even and This will be important if you set up other machines behind your mail server and use it as a gateway.

13. Add the following line:


This will add the domain name to all outbound mail.

14. Replace and modify the following:



This defines the domain name to masquerade.


Other changes beyond

The next step is to modify the ancillary files to let sendmail do its thing.

Setting up the access file

The /etc/mail/access file allows you to block access to the mail server based on host names and IP addresses. You can use this to create blacklists and whitelists although they can be a bit hard to maintain as they are static. There are some lines you need to have in here even if you don’t explicitly list anything else.			RELAY
   	localhost 				RELAY 				RELAY
   	192.168.5 				RELAY
   	192.168.100				RELAY

These allow mail from the local host and from others on your network to use the server to get to the outside world. Of course you will need to modify these networks to your configuration. I have 192.168.5 and 192.168.100 addresses behind my firewall so they are in this list.

The next step is to add the login information to the /etc/mail/access file. This is required to let your ISP server know who you are when you request a relay of mail to the rest of the world. The example below uses plain text logins which means your username and password are sent in plain text. Although this is not secure, it is also not uncommon. You will want to see if they will allow secure password authentication. You can then modify the lines below to use a different method other than LOGIN PLAIN. Also, you will want to make sure privileges on this file are set accordingly so that local users can not see these username/password combinations. This is not a problem as sendmail doesn’t use this file directly, it uses the database hash which will be created later. “U:username1” “P:secret” “M:LOGIN PLAIN” “U:username1” “P:secret” “M:LOGIN PLAIN”

AuthInfo tells sendmail to use this information to answer authorization requests from the remote MTA. The next item is obviously the server name. U is the username to login and P is the password. M is the method of authentication used (see comments in above paragraph).

Setting up the local-host-names file

The /etc/mail/local-host-names file defines the aliases for the local machine. You want to put all the names in here that will be used by sendmail to define the host.

# local-host-names – include all aliases for your machine here.

Pretty self explanatory.

Modifying the aliases file

The /etc/aliases file contains the mail aliases for the server. It is important that some of these be here to be compliant with RFCs. Usually you will only need to edit the last line.

# Person who should get root’s mail
root:           billybob

You may want to add some other lines for something like spamtrap: or any other aliases.


Burn it!

Now we will make sure everything is prepped and ready to use by sendmail. Execute the following commands as root:

/usr/bin/newalises    This activates the changes you made to the /etc/aliases file. Note: if you change aliases in the future, you only need to execute this command, you do not need to restart sendmail for the changes to show through.

makemap hash /etc/mail/access < /etc/mail/access    This creates a hashed version of your access database. This will keep your ISP username and password secure. A new /etc/mail/access.db file will be created.

makemap hash /etc/mail/local-host-names < /etc/mail/local-host-names    Like above, this creates a one-way hash of the local-host-names file you modified.

make -C /etc/mail    (That’s an upper case “C”) This creates the /etc/mail/ file from the /etc/mail/ file you modified earlier. Note: some of the above steps are covered here by the makefile but it won’t hurt to make them again.

Now all you have to do is restart the server.

/sbin/service sendmail restart    This will kill the sendmail job (if its running) and restart it using all your configuration changes.

That’s it! Now just sit back and watch the spam roll in.


makemap hash /etc/mail/mailertable < /etc/mail/mailertable

Comments are closed.