Using Sendmail Correctly From Your Dynamic ISP Address

Posted: November 30, 2008 in LINUX, SENDMAIL
Tags:

Sendmail Mods — Using Sendmail Correctly From Your Dynamic ISP Address

Modifying the sendmail.mc file to make it work….

Listed below are the changes to a default RH 9 /etc/mail/sendmail.mc file required to operate a mail server behind a non-reversible IP address. This should work for DSL, cable modem and [shudder] dial-up. If you can’t do a reverse DNS lookup on your domain and have it resolve to your IP (dynamic or otherwise) you may have trouble delivering mail to many destinations. These changes are also good for general sendmail set-up except you may want to omit step 3.

You are NOT done once you change the .mc file. There are other changes that need to be done to the server.

shoulder

Anything not listed for change/add/delete here should work fine with the default settings. I do NOT know if this will work for any other installation (e.g. Red Hat 7.2 or Mandrake). This worked with the default sendmail RPM shipped with RH 9 (and subsequent sendmail updates). I gleaned some parts of this from several sources but one of your best resources is the published Red Hat documentation.RTFM. Red Hat has excellent manuals and you will find most of this stuff there.

Some hearty souls may chose to edit the sendmail.cf file directly however I do not see the need for this. The whole idea of the sendmail.mc file is to make the configuration file manageable and to generate the .cf file. When I dove into this, I read as much as I could, including the vaunted O’Reilly Bat Book. Everything I read said to stick with the macros (m4 and mc) and let them generate the .cf. I’ve played with both files from time to time and find the .mc to be much more manageable for my pea-brain. The sendmail.mc file is 145 lines, the sendmail.cf file is 1800 lines. You figure it out….

You will need to run make -C /etc/mail as root to generate the sendmail.cf file from the sendmail.mc macro after you are finished making these changes. You will also need to do a /sbin/service sendmail restart as root once you have made the new sendmail.cf file. More on this below.

Please let me know if you see any errors or omissions in this document. Also, note that I am well aware I am not saving the world here.


 

Some definitions:

Comment out: Place a dnl or a dnl # in front of the line in the macro file. This will cause the m4 compiler to ignore that line.

Uncomment: Remove the dnl or dnl # in front of the line in the macro file. There may also be changes after you uncomment.

Add: New lines that should be added just like they are shown.

Replace: Replace the existing line (which will be shown) with the new line.

Notes: These are listed in roughly the order they appear in the sendmail.mc file, not by importance. I suggest you read through them all and sort out the ones you need. Don’t change the order of things too much as the compiler can get picky if too many things are defined out of order. Also, they insist on using forward-single-quotes (`) which are a pain if you don’t notice them. It is best to copy existing lines and modify them so you don’t mix up the forward and standard quotes.


Modify the actual sendmal.mc 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=127.0.0.1, 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:

FEATURE(`accept_unresolvable_domains’)dnl

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’,`outgoing.earthlink.net’)   (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 outgoing.earthlink.net 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:

FEATURE(`delay_checks’)dnl

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,`zen.spamhaus.org’,`”550 Mail from site rejected; see http://www.spamhaus.org”‘)dnl
FEATURE(enhdnsbl,`bl.spamcop.net’,`”550 Server blocked see: http://spamcop.net/bl.shtml?”$&{client_addr}’,`t’)dnl
FEATURE(dnsbl, `dnsbl.njabl.org’, `”550 Email rejected – see http://njabl.org”‘)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(`mydomain.com’)dnl Becomes

MASQUERADE_AS(`eexamplee.net’)dnl

This causes all sent mail to appear to come from eexamplee.net.

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

MASQUERADE_AS(mydomain.com)dnl Becomes

MASQUERADE_AS(eexamplee.net.)dnl

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:

FEATURE(masquerade_envelope)dnl

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

12. Uncomment the following line:

FEATURE(masquerade_entire_domain)dnl

This causes all hosts to be masqueraded as eexamplee.net even host1.eexamplee.net and hostxyx.eexamplee.net. 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:

FEATURE(always_add_domain)dnl

This will add the domain name to all outbound mail.

14. Replace and modify the following:

MASQUERADE_DOMAIN(`mydomain.com’)dnl Becomes

MASQUERADE_DOMAIN(`eexamplee.net’)dnl

This defines the domain name to masquerade.

 

Other changes beyond sendmail.mc

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.

mail.eexamplee.net RELAY localhost RELAY 127.0.0.1 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.

AuthInfo:earthlink.net “U:username1” “P:secret” “M:LOGIN PLAIN”
AuthInfo:outgoing.earthlink.net “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.
eexamplee.net.net
mail.eexamplee.net

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/sendmail.cf file from the /etc/mail/sendmail.mc 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.

Advertisements

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s