Tony Baldwin wrote: > What else can I do to diagnose this issue and/or, of course, resolve it? I think this must be something other than mutt. In your description you didn't mention how you were sending email and therefore I know you weren't looking at that part of things. I suspect it is in the MTA side of things. Normally (and I say normally in the traditional sense knowing that many people do things differently now) the MUA (mail user agent). The MUA is mutt, mailx, pine, or other. Those MUAs send the message to /usr/sbin/sendmail. The /usr/sbin/sendmail binary is one of Postfix, Exim, Sendmail or other MTA (mail transfer agent). The MTA delivers the message to the next hop in the route to the destination. The next hop is usually controlled by MX DNS records. Of course these days many people are using IMAP to read messages and often using SMTP on the submission port with SASL or various for sending mail. Hard to say what you are using. If you have not customized it then you are using /usr/sbin/sendmail and the message is handed off to your system MTA for delivery. If so then the system MTA will log all of these actions to the system log. Please look in /var/log/mail.log (Postfix logs there) or possibly other location and see what it says. I forget where Exim logs to and exim4 is the default MTA unless you select another. A common thing for me to do is to run "tail -f /var/log/mail.log" in one terminal window while sending mail in another terminal window. Run "mailq" and see what mailq says. If the message is undeliverable but still in the queue the reason will be shown there. Most messages will queue for five days (configurable, maximal_queue_lifetime = 5d for postfix) until it times out. At that point it will generate a bounce message back to the sender. A side note but a useful SMTP debug tool is "swaks". It will show the SMTP handshake and is a useful debug tool. Bob
Attachment:
signature.asc
Description: Digital signature