I have a Redhat machine with a static IP on an aDSL line. I would like to configure sendmail to forward
user_1@MYDOMAIN.com ---> user_1@aol.com
user_2@MYDOMAIN.com ---> user_2@earthlink.net
user_3@MYDOMAIN.com ---> user_3@msn.net

etc etc...

Additionally

ANYTHING_ELSE@MYDOMAIN.com ---> admin@something.net

no mail should actually stay on the machien as they will all be "Virtual addresses" which just forward somewhere else.

1) What is the easiest way to set this up?
2) What kind of worries do I need to have about spammers using my sendmail install?

You can easily do this with entries in the /etc/aliases file. Any time you make changes, run the "newaliases" command.

There are probably a dozen or more ways to do this, incidentally, but you asked for the easiest way.

If your machine is up to date on patches, and you haven't done anything foolish in /etc/mail/sendmail.mc, you have absolutely no worries about spammers hijacking your mail node.

If you fall behind in patches, or you make unwise configuration choices in sendmail.mc, you will be owned in less than a week. A static IP on a DSL line is the holy grail for spammers; if you set up snort you will see that your address is being attacked 10-500 times a day.

It's worse if you are running a windows box, because the patches do not come out in a timely fashion. But regardless of what OS you run, if you fall behind in patches and you are on a high-bandwidth line, you will be 0wned. Check the HoneyNet Project for documentation of this if you were not already aware of the problem.

/etc/mail/aliases is the quick and dirty way of doing this. /etc/mail/virtusertable gives you more options. Use virtual user table (/etc/mail/virtusertable) with the following entries:

user_1 user_1@aol.com
user_2 user_2@earthlink.net
user_3 user_3@msn.net
@MYDOMAIN.com admin@something.net
@OTHERDOMAIN.BLAH localmachineuser
@FOO.BAR groundcontrol@majortom.blah

The order is important - you want user-specific items first (user1, user2, etc) and then the catch-all (@mydomain.com) last. Once you edit this you will need to re-make the map. In /etc/mail/ type:

makemap -v virtusertable <virtusertable

makemap = command to remake the map
"- v" = verbose - ie, see it happen
virtusertable = name of the database. ".db" will be appended
<virtusertable = ascii file data is snarfed from.

This will create a file called "virtusertable.db" from the file "virtusertable". You do not have to stop/restart sendmail for this to take effect. Note that you can use virtusertable for delivering error messages - ie

userid1 error:userid1 is gone.
@otherdomain.blah error:not here - try mydomain.com

etc.

Agreed. The virtusertable is probably the current best practice (assuming aliases are too simplistic for your needs - there's something to be said for simple solutions to simple problems, too) and it's well supported by the sendmail authors.

Just make sure it's turned on if you decide to use it, and that the file's in the place sendmail.mc says it is. For example,

FEATURE(`virtusertable',`hash -o /etc/mail/virtusertable.db')dnl

Actually I was incorrect in how to generate the table. One actually needs to use:

The order is important - you want user-specific items first (user1, user2, etc) and then the catch-all (@mydomain.com) last. Once you edit this you will need to re-make the map. In /etc/mail/ type:

makemap -v hash virtusertable <virtusertable

makemap = command to remake the map
"- v" = verbose - ie, see it happen
hash = hash tables
virtusertable = name of the database. ".db" will be appended
<virtusertable = ascii file data is snarfed from.

Got a quick question for you Medievalist. You say use

FEATURE(`virtusertable',`hash -o /etc/mail/virtusertable.db')dnl

yet I have found that - at least when compiling with tarballs - one needs to use

FEATURE(virtusertable, `hash -o /etc/mail/virtusertable -T<TMPF>')dnl

My version of sendmail (8.12.9) will complain if I use the first, but shut up if I use the second. What exactly does "-T<TMPF>" do and why is it needed with tarballs and apparently not with RPMs?


Thoughts?

Hmmm... I dunno. Red Hat is famous for adding patches to nearly everything they ship; this is (depending on your philosophy) either a intrinsically wrong thing that subverts the Open Source development process, or a service to customers that allows Red Hat to deliver a polished and cleanly interoperating set of packages. So this may have something to do with Red Hat patches to sendmail; the only way I know to check that is to unbundle the Red Hat source RPM and look at the spec file.

Note that my method uses access.db, and access is the source file for it. Yours references access straight up.

The -T switch is operating on sendmail's hash function, though, so we could look at the source code to find out what it does (assuming that it's comprehensible to mere mortals, that is - I wouldn't be suprised to find the code was very difficult to follow).

Might find an answer on the sendmail list....