David. thanks for hanging in with me!
On Tue, Apr 26, 2022 at 03:23:17PM -0500, David Wright wrote:
> Do you know why mutt is adding a Sender: line to your emails?
> Did you ask it to, or have you been asked to by someone else?
No, I didn't ask mutt to add a Sender: line and I do not know what
evidence there it that it is doing so.
If I understand correctly, which is always in serious doubt, it is
exim that constructs the Sender: line by combining /etc/mailname and
$LOCALHOST. Is this so?
These values are present:
$ nano /etec/mailname
lenin.histomat.net
$ echo $LOGNAME
haines
> But don't confuse the specific "Sender:" field in the header with the
> conversational use of "sender" to talk about the person/software/system
> that's sending the email. (The emails you send here do not contain
> a Sender: field.)
Understood. But my impression is not that there is no Sender: field,
but that it is empty (<>).
However I'm not clear whether the field is empthy or that what us
in it field is not owned by me. I have popcorn installed, and it has
root send a priodidic message. The mail server does not recognize
the r...@histomats.net address. It sends me this message:
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
sur...@popcon.devuan.org
host mail.guardedhost.com [216.239.133.245]
SMTP error from remote mail server after pipelined sending data block:
553 5.7.1 <r...@histomat.net>: Sender address rejected:
not owned by user bro...@historicalmaterialism.info
Reporting-MTA: dns; lenin.histomat.net
Action: failed
Final-Recipient: rfc822;sur...@popcon.devuan.org
Status: 5.0.0
Remote-MTA: dns; mail.guardedhost.com
Diagnostic-Code: smtp; 553 5.7.1 <r...@histomat.net>: Sender
address rejected: not owned by user bro...@historicalmaterialism.info
The address hai...@histomat.net is owned by
bro...@historicalmaterialism.info. Omnis mail server never had a
problem with r...@histomat.net before.
> A typical, straightforward, email contains a From: field, which is the
> email address of the sender (not Sender), as opposed to the recipient
> (ie the To: field). Again, typically, straightforwardly, the From:
> and To: fields will be used to generate the envelope's MAIL FROM
> and RCPT TO addresses.
Are you saying that the envelope hss MAIL FROM and RCPT TO lines and a
typical email has From: and To: lines? Does this leave it to mutt
to construct the Sender: line?
> > First, the implication seems to be that an empty Sender: line means
> > that mutt is falling down on the job and for some reason this past
> > week ceasad to provide a value for the Sender: line in the header of
> > the some mail it sent to exim. So is the obvious thing to do is fix
> > mutt? Since I've been using the same mutt configuration for years, its
> > not a configuration problem but samage to mutt. Looks like a reinstall
> > and slow reconstruction of its confirturation.
>
> You have to tell mutt what to use. It can't assume that your $LOGNAME
> and /etc/mailname are, taken together, going to generate a satisfactory
> From: field for an email.
And yet it has access to those values. Or should /etc/mailname be
histomat.net rather tnan lenin.histomat.net?
> What did Omnis actually say, literally?
>
> In your OP, you wrote "554 5.7.1 Empty Sender Address
> is prohibited through this server; from=<>"
> (Should I guess that that's Omnis speaking?)
Yes
> I have assumed that "554 5.7.1 Empty Sender Address" is the actual
> response, and it's capitalised, whereas "is prohibited through this
> server" is their gloss, uncapitalised. So I don't think it's saying
> anything about a Sender: field, rather, the MAIL FROM address.
Oh! This hadn't occurred to me. The MAIL FROM belongs to the envelope.
> Well, the simple way, which is why I use it, is to put:
>
> set envelope_from_address="someuser@somedomain"
> set use_envelope_from
>
> into mutt's configuration file (always assuming it gets read!), as
> I wrote before. (At this point, I didn't have an inkling of Sender:
> being involved, and hope that is still true.)
I checked, and the muttrc does get read. I put these two lines into
it:
set envelope_from_address="hai...@histomat.net"
set use_envelope_from
If these take immediae effect (without restarting mutt), then they did
not help. The online email testing utility still returns:
Unverified address: postoffice.omnis.com said: 521 5.5.1 Protocol error 
Error in communication with postoffice.omnis.com
What happened to the objection raised by someone tnat the these lines
should have a binary value?
It strikes me that the addition of these lines are just a work around
for the problem that the envelopoe's MAIL FROM line is
unacceptable.
> The reason /I/ have to do that is that submission to my ISP requires
> an email address belonging to them. I've never used my ISP's email
> system beyond logging in to it every so long to prevent it expiring.
Seems like my own situation.
> > In exim configuration I hide outgoing local mail name and provide
> > the domain name without prepending host name. I assume
> > this is irrevant and is merley a cosmetic isaue. Is that so?
>
> If it's an email address, it shouldn't cause a problem. I'm assuming
> that you're doing away with lenin, so to speak, which is probably
> the correct thing to do, as I'm guessing that you don't run a mail
> server on lenin.
Emacs configuration first asks whether to hide the visible domain
name. I answer Yes, and so it asks what that name should be. I enter
histomat.net. But above you say "an email addess". Did you mean just
the domain portion of an address?
> Summary: tell mutt who you are. And note that "Sender" gets one very
> trivial mention in mutt's manual (for tagging emails containing such).
I gather that the two lines above inserted into muttrc should tell
mutt who I am. But why out of the blue have they become necessary? And
without restarting anything they don't keep the online email tester
from saying that hai...@histomat.net violates Protocol 521.5.5.1.
