I'm using mutt aliases to abreviate recipient names (e.g., jdoe
is defined as an alias to john.doe@example.com
). However, if I mistype an alias (e.g., jdeo
), mutt does not warn me about the fact that the alias doesn't exist. Instead, it autocompletes this using the $hostname
variable, e.g., if my machine has hostname foo.mydomain.net
the bogus alias is replaced by jdeo@foo.mydomain.net
. This is never what I intend to do.
Hence, if I mistype an alias, I don't get any warning, and I have to hope that, when sending the mail, the remote SMTP will refuse it ("User unknown in local recipient table") or will send me a delivery status notification… This is not ideal and I have messed up several times with this.
Instead, I'd like mutt to warn me about aliases that do not exist, i.e., if I type a recipient that doesn't contain "@" and is not a known alias, then mutt should complain and refuse to send the mail.
Is it possible to configure mutt to warn about aliases that do not exist? I was unable to find a relevant configuration option. I also tried to set $hostname
to the empty string, but then mutt happily contacts the remote SMTP and tries to send mail to "jdeo".
Best Answer
By setting
use_domain
to false, you can ensure that addresses that do not correspond to an alias are not expanded with a domain name (so they stay as-is, e.g., "jdeo"). Mutt will still try to send the mail in this case, but at least the remote SMTP server will interpret them as local users so they may get a chance to complain. In this case, mutt will report a visible error (SMTP session failed: 550 5.1.1 <aoeu>: Recipient address rejected: User unknown in local recipient table
) and give you an opportunity to fix the mistake.This is much better than setting
use_domain
to true, because in that case "jdeo" gets expanded to "jdeo@whatever-machine-im-using.tld", and the remote SMTP does not complain.Setting
use_domain
to true doesn't perfectly solve my problem, because it relies on cooperation from the remote SMTP to complain about unknown local recipients during the SMTP session, and it won't catch mistakes which happen to correspond to local recipients. That said, it's good enough and much better for my needs than the default behavior.