sendmail: how to masquerade aliased To: address

I have an email header where the recipient sees:
From: HPRS Batch <>
To: <benefits@webserver.hprs.local>, <>

Open in new window

The local domain name is hprs.local and the ID "benefits" is in the /etc/mail/aliases file routing to various users. The external domain name is I would like the To: line to read "To: <" instead of having the local domain name. Obviously, an external recipient would not be able to reply to that address.

in my file I have


so why is this address not getting masqueraded?

Slackware 13.37, kernel, sendmail 8.14.4
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

In your file you will see a DM entry, it should be set like this.

# who I masquerade as (null for no masquerading) (see also $=M)
# DM

refresh or restart sendmail

That should solve your problem
MarkAuthor Commented:
carlmd: > In your file you will see a DM entry, ...

I do have that set as you've shown. Note that the sender is being sent from the same hprs.local domain *is* masqueraded:

From: HPRS Batch <>
To: <benefits@webserver.hprs.local>, <>

The 1st recipient is in the /etc/aliases/file as:

benefits:       webadmin,,,

The email is *to* those recipients, but instead of To: it shows  To: benefits@hprs.local. That's the one I want to fix. The mail command in the script is:

 mutt -e 'set content_type="text/html"' -s "subject line"  benefits

Any way to fix this?
You can try the following, one at a time. In set

Depending upon your mc options your may have a section like...

#   Format of headers   #

H?P?Return-Path: <$g>
# HReceived: $?sfrom $s $.$?_($?s$|from $.$_)
HReceived: $?sfrom ( [put your ip address here])
        $.$?{auth_type}(authenticated$?{auth_ssf} (${auth_ssf} bits)$.)
        $.by $j ($v/$Z)$?r with $r$. id $i$?{tls_version}
        (using ${tls_version} with cipher ${cipher} (${cipher_bits} bits) verifi
ed ${verify})$.$?u

I changed it to show your so you can try doing that as well.
Powerful Yet Easy-to-Use Network Monitoring

Identify excessive bandwidth utilization or unexpected application traffic with SolarWinds Bandwidth Analyzer Pack.

MarkAuthor Commented:
Ah ha! This is apparently not a sendmail thing. When I send to a test alias using mail (mailx) it shows the To: address correctly:

When I send using mutt it shows: To: testme@webserver.hprs.local

Odd, because `hostname -f` gives: The mutt variation is one of the aliases in /etc/hosts:    webserver.ohprs.local webserver

Open in new window

I assume, therefore, I need some setting in ~/.muttrc. Do you happen to know what that would be? I'll investigate too.
MarkAuthor Commented:
No luck finding a mutt setting to fix this. Any ideas? Is this just something I'll have to live with with mutt?

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
MarkAuthor Commented:
Thanks, but the problem is the recipient's email, not sender's. Don't know where mutt is getting the webserver.hprs.local domain name other than arbitrarily picking the 2nd alias in the /etc/hosts file:    webserver.ohprs.local webserver

Open in new window

It does the same thing if I send mail to a real local recipient. Doesn't even have to be an alias name.

Seems odd. This must be fairly common for all mutt users. hostname gives:
$ hostname -f

Open in new window

so how is mutt determining the local domain name?
Since mutt is an email client to sendmail, it is obviously overriding the sendmail options, since sendmail does it correctly on it's own.

Have you tried defining mutt aliases in addition to those in sendmail? Look at the section on aliases in:

Also try the following...

HOW-TO 3: Send email with a customized sender name and email address
# The .muttrc file is Mutt's configuration file. It's default location is the $HOME directory.
# If you locate it elsewhere, specify its location with the '-F' flag.
# Add the following to the .muttrc file:
set realname="Joe Bloggs"
set from=""
set use_from=yes
# where:
# realname => Sender's name as it appears in the recipient's mail inbox.
# from => the "reply-to" address
MarkAuthor Commented:
carlmd: > Have you tried defining mutt aliases in addition to those in sendmail?

I've looked at that, but I think having aliases in both /etc/mail/aliases and mutt aliases might confuse my eventual successor beyond what the inconvenience of fooped recipient addresses presents. Mutt is only used when encoding html in messages -- not often. Other non-interactive mode messages are sent using mail(x).

I've tried switching the order of alias names in /etc/hosts from    webserver.ohprs.local webserver

to             webserver.ohprs.local webserver

thinking mutt was getting the domain from there, but no difference. `hostname -f` gives "" and the contents of /etc/HOSTNAME is "".
MarkAuthor Commented:
OK, I think I've found a solution. `mutt -D` dumps config settings. This dumps:


The user has no .muttrc to override, but there is a /etc/mutt/Muttrc. Searching that shows not hostname set. I uncommented the hostname setting and made it:


That finally worked! I have no clue where mutt has been getting webserver.ohprs.local. Even when I removed this alias entirely from the /etc/hosts file it still picked up that FQDN.

I'd be interested if you have a theory on why mutt gets that odd FDQN, other than that, I think my issue is solved.
Not sure if this is the issue, but take a look at:

Also, if you google "mutt fqdn" there is a lot to read.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Email Servers

From novice to tech pro — start learning today.