Re: email lacks sender address (SOLVED)

[David Wright]

On Sun 08 May 2022 at 19:20:05 (-0600), Charles Curley wrote:
> On Sun, 8 May 2022 19:42:57 -0500 David Wright wrote:
> 
> > I'm really not sure who, and under what circumstances,
> > hostnamectl is for.
> 
> Nor am I, especially after this. According to apt-file, it is in the
> package systemd.
> 
> > I ran:
> > 
> > # hostnamectl set-hostname acerx
> > 
> > and /etc/hostname was changed, but not /etc/hosts, which still had:
> > 
> > 127.0.1.1   acer.corp   acer
> 
> I confirm this. I guess I missed it due to rarely referring to a
> computer by its hostname, but instead by localhost. Sigh. Thanks for
> the catch. It looks like I shall have to adjust my installation scripts.
> 
> > 
> > and also not /etc/mailname. I'm not saying it should have affected
> > those occurrences, but that it's better to check you have the
> > correct, consistent name throughout the system.
> 
> Odd. On the two boxes I used hostnamectl on, mailname is set correctly.
> However, I ran it on installation, and may have fixed that manually
> (but there's no backup file), or by installing postfix subsequently.

Well, I was running hostnamectl after the event, ie on an already
fully-configured system. In your case, you probably configured exim
after setting the hostname (or it's the same name anyway, or whatever).
OTOH I think dpkg-reconfigure reads the mailname from /etc/hosts,
rather than /etc/hostname, initially (ie when /etc/mailname is unset.
If it's already set, it just parrots it.).

> > It's also not clear to me either, where one might insert this command
> > so that it takes effect early enough to avoid polluting the system
> > with wrong names. (The logs, for one example.)
> 
> I run it in a script that I run manually immediately after installation.

I see. And it sets /etc/hostname for good. But I think the OP's
problem might have been that DHCP was overwriting /etc/hostname
each time it ran (or ran at boot time).

> > > > Whats I didn't check  was what my router took to be my host name. 
> > > > It did not reponse to my changed host name and I had to do it
> > > > manually in the router. Doing do seems to have solved my problem.
> > > >  
> > 
> > It would seem then that you were letting DHCP in the router set your
> > hostname as well as the usual IP address, nameservers etc, which
> > could be unfortunate if it doesn't agree. How you avoid that depends
> > ….
> 
> Yup. However I make sure they agree by assigning most hosts a "host"
> statement in dhcpd.conf, and assigning a fixed IP address to a given MAC
> address, and then having dhcpd feed that to bind9.

Similarly here, except that I don't have anything running a DNS
server. But the router's DHCP table's hostname agrees with
/etc/hostname, /etc/hosts, /etc/mailname, and any derived places
like update-exim4.conf.conf and the ssh keys.

BTW my "…" stood for "different with different configurations", and
I don't think I can even avoid it on my own preferred DHCP client,
iwd. (I think I have seen a post proferring a patch to allow it.)

Cheers,
David.

Re: email lacks sender address (SOLVED)

[Charles Curley]

On Sun, 8 May 2022 19:42:57 -0500
David Wright  wrote:

> I'm really not sure who, and under what circumstances,
> hostnamectl is for.

Nor am I, especially after this. According to apt-file, it is in the
package systemd.

> I ran:
> 
> # hostnamectl set-hostname acerx
> 
> and /etc/hostname was changed, but not /etc/hosts, which still had:
> 
> 127.0.1.1   acer.corp   acer

I confirm this. I guess I missed it due to rarely referring to a
computer by its hostname, but instead by localhost. Sigh. Thanks for
the catch. It looks like I shall have to adjust my installation scripts.

> 
> and also not /etc/mailname. I'm not saying it should have affected
> those occurrences, but that it's better to check you have the
> correct, consistent name throughout the system.

Odd. On the two boxes I used hostnamectl on, mailname is set correctly.
However, I ran it on installation, and may have fixed that manually
(but there's no backup file), or by installing postfix subsequently.

> 
> It's also not clear to me either, where one might insert this command
> so that it takes effect early enough to avoid polluting the system
> with wrong names. (The logs, for one example.)

I run it in a script that I run manually immediately after installation.

> 
> > > Whats I didn't check  was what my router took to be my host name. 
> > > It did not reponse to my changed host name and I had to do it
> > > manually in the router. Doing do seems to have solved my problem.
> > >  
> 
> It would seem then that you were letting DHCP in the router set your
> hostname as well as the usual IP address, nameservers etc, which
> could be unfortunate if it doesn't agree. How you avoid that depends
> ….

Yup. However I make sure they agree by assigning most hosts a "host"
statement in dhcpd.conf, and assigning a fixed IP address to a given MAC
address, and then having dhcpd feed that to bind9.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: email lacks sender address (SOLVED)

[David Wright]

On Sun 08 May 2022 at 11:08:08 (-0600), Charles Curley wrote:
> On Sun, 8 May 2022 12:07:00 -0400
> Haines Brown  wrote:
> 
> > When I installed the operating systme, the host name some how at a 
> > numvber appended. I inteded to have nost name lenin, but it ended up 
> > lenin-16. When I discovred that afer installation I corrrected the
> > host name in /etc/hsots and /etc/hostname. 
> 
> Systemd provides a program for setting the host name, called, oddly
> enough, hostnamectl. It may do other things you might have missed.
> 
> I doubt it would have affected your router, though.

I'm really not sure who, and under what circumstances,
hostnamectl is for. I ran:

# hostnamectl set-hostname acerx

and /etc/hostname was changed, but not /etc/hosts, which still had:

127.0.1.1   acer.corp   acer

and also not /etc/mailname. I'm not saying it should have affected
those occurrences, but that it's better to check you have the
correct, consistent name throughout the system.

It's also not clear to me either, where one might insert this command
so that it takes effect early enough to avoid polluting the system
with wrong names. (The logs, for one example.)

> > Whats I didn't check  was what my router took to be my host name. 
> > It did not reponse to my changed host name and I had to do it manually 
> > in the router. Doing do seems to have solved my problem.

It would seem then that you were letting DHCP in the router set your
hostname as well as the usual IP address, nameservers etc, which
could be unfortunate if it doesn't agree. How you avoid that depends ….

Cheers,
David.

Re: email lacks sender address (SOLVED)

[Charles Curley]

On Sun, 8 May 2022 12:07:00 -0400
Haines Brown  wrote:

> When I installed the operating systme, the host name some how at a 
> numvber appended. I inteded to have nost name lenin, but it ended up 
> lenin-16. When I discovred that afer installation I corrrected the
> host name in /etc/hsots and /etc/hostname. 

Systemd provides a program for setting the host name, called, oddly
enough, hostnamectl. It may do other things you might have missed.

I doubt it would have affected your router, though.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: email lacks sender address (SOLVED)

[Haines Brown]

I appreciate tbe rich reponses to my question. I  believe I found the 
answer. Not sure but at least the messages I've been sending now get 
to ter recipients

When I installed the operating systme, the host name some how at a 
numvber appended. I inteded to have nost name lenin, but it ended up 
lenin-16. When I discovred that afer installation I corrrected the
host name in /etc/hsots and /etc/hostname. 

Whats I didn't check  was what my router took to be my host name. 
It did not reponse to my changed host name and I had to do it manually 
in the router. Doing do seems to have solved my problem.

Re: email lacks sender address

[David Wright]

On Thu 28 Apr 2022 at 13:13:19 (-0400), Greg Wooledge wrote:
> On Thu, Apr 28, 2022 at 12:02:50PM -0500, David Wright wrote:
> > $ cat /etc/mailname 
> > acer.corp1
> > $ cat /etc/hosts 
> > 127.0.0.1   localhost
> > 127.0.1.1   acer1.corp  acer1
> > 192.168.1.14axis.corp   axis
> > 
> > # The following lines are desirable for IPv6 capable hosts
> > ::1 localhost ip6-localhost ip6-loopback
> > ff02::1 ip6-allnodes
> > ff02::2 ip6-allrouters
> > $ hostname
> > acer
> 
> But you no longer have 'acer' in your /etc/hosts file.  Your hostname
> therefore won't have *any* canonical form with dots in it.

Ah, that would explain Brian's writing "127.0.1.1 test.axis.corp HOSTNAME".

> > and here's the email on axis:
> > 
> > >From au...@acer.corp Thu Apr 28 11:37:06 2022
> > Return-path: 
> > Envelope-to: auser@axis
> > Delivery-date: Thu, 28 Apr 2022 11:37:06 -0500
> > Received: from [192.168.1.10] (helo=acer)
> > by axis.corp with esmtp (Exim 4.92)
> > (envelope-from )
> > id 1nk78c-0001yL-Bm
> > for auser@axis; Thu, 28 Apr 2022 11:37:06 -0500
> > Received: from auser by acer with local (Exim 4.94.2)
> > (envelope-from )
> > id 1nk78b-HX-6v
> > for auser@axis; Thu, 28 Apr 2022 11:37:05 -0500
> 
> Here, you can see that there was no canonical expansion of "acer" into
> a dot-laden name, so your system only identified itself as "acer".  Not
> as "acer.corp" or anything similar, in its HELO.

Yes, that seems to be the case.

> If one of the entries in your /etc/hosts file had contained "acer" as
> an alias, then the outcome would have been different.
> 
> Interestingly, acer.corp *does* appear in the envelope sender address,
> which you can see in the "From " line and the "Return-path:" header.
> But in the bottom Received: header, it says "envelope-from ".
> I find that quite interesting, but you'd need more knowledge of exim
> configuration than I possess to work out what happened there.

That is coming from the "visible domain" that is for exim's
address-hiding/rewriting facility, "stored" in dc_readhost in
/etc/exim4/update-exim4.conf.conf. When dpkg-reconfigure exim4-config
is run, it reads /etc/mailname for the system's mailname, writes back
whatever you set it to (or leave it as), and then asks for the visible
domain, offering you either the (original) /etc/mailname, or the
current visible domain if it's been set in the past. I left it as it
was originally; for extra tracking, I later changed it to "visi",
confirming that it appears in the mbox "From " line, the return
address, the upper envelope-from, and the From: header.

I've got a bit rusty on exim's wrinkles because, since the start of
lockdown (if you could call it that here in the sticks), I've
configured all my machines bar one to throw all their system emails at
a smarthost machine by IP#:25, and the latter doesn't worry about the
sender's side as long as it arrives from a LAN address. All external
mail is sent directly by mutt, using an explicit envelope-from.

Thanks.

Cheers,
David.

Re: email lacks sender address

[Greg Wooledge]

On Thu, Apr 28, 2022 at 12:02:50PM -0500, David Wright wrote:
> $ cat /etc/mailname 
> acer.corp1
> $ cat /etc/hosts 
> 127.0.0.1   localhost
> 127.0.1.1   acer1.corp  acer1
> 192.168.1.14axis.corp   axis
> 
> # The following lines are desirable for IPv6 capable hosts
> ::1 localhost ip6-localhost ip6-loopback
> ff02::1 ip6-allnodes
> ff02::2 ip6-allrouters
> $ hostname
> acer

But you no longer have 'acer' in your /etc/hosts file.  Your hostname
therefore won't have *any* canonical form with dots in it.

> $ domainname
> (none)

That's an NIS command.  It's used by NIS only.  It has nothing to do
with what you appear to think a "domain name" is.

> and here's the email on axis:
> 
> >From au...@acer.corp Thu Apr 28 11:37:06 2022
> Return-path: 
> Envelope-to: auser@axis
> Delivery-date: Thu, 28 Apr 2022 11:37:06 -0500
> Received: from [192.168.1.10] (helo=acer)
> by axis.corp with esmtp (Exim 4.92)
> (envelope-from )
> id 1nk78c-0001yL-Bm
> for auser@axis; Thu, 28 Apr 2022 11:37:06 -0500
> Received: from auser by acer with local (Exim 4.94.2)
> (envelope-from )
> id 1nk78b-HX-6v
> for auser@axis; Thu, 28 Apr 2022 11:37:05 -0500

Here, you can see that there was no canonical expansion of "acer" into
a dot-laden name, so your system only identified itself as "acer".  Not
as "acer.corp" or anything similar, in its HELO.

If one of the entries in your /etc/hosts file had contained "acer" as
an alias, then the outcome would have been different.

Interestingly, acer.corp *does* appear in the envelope sender address,
which you can see in the "From " line and the "Return-path:" header.
But in the bottom Received: header, it says "envelope-from ".
I find that quite interesting, but you'd need more knowledge of exim
configuration than I possess to work out what happened there.

Re: email lacks sender address

[David Wright]

On Thu 28 Apr 2022 at 15:52:00 (+0100), Brian wrote:
> On Wed 27 Apr 2022 at 14:57:19 -0500, David Wright wrote:

> > The lines which principally concern you/your system are:
> > 
> > 1) The EHLO line, which you typically don't see, is read from
> > /etc/mailname by exim, is set to lenin.histomat.net, and works.
> > You set it early in the debian-installer, if Devuan follows
> > along the same path. You confirmed it immediately after you
> > told exim "mail sent by smarthost; … … ", on the next screen
> > (again, if Devuan follows).
> 
> The EHLO is typically seen in the first Received: header. In your
> case it is axis.corp. It is not obtained from /etc/mailname by exim.
> 
> I would guess you have a line in /etc/hosts like this:
> 
>   127.0.1.1   axis.corpHOSTNAME
> 
> A suitablely configured exim gets the EHLO from this line. To test,
> use
> 
> 127.0.1.1 test.axis.corp  HOSTNAME
> 
> and send a mail.
> 
> I would suggest
> 
>  
> https://wiki.debian.org/PkgExim4UserFAQ#How_does_exim_find_out_its_host_name_to_use_in_HELO.2FEHLO.3F
> 
> as a reasonable source of information.

I haven't yet tried actually prefixing another component, but I did
make some changes (acer is the test subject, axis is the smarthost).
Did you mean:
127.0.1.1 test.acer.corp test   or   127.0.1.1 test.acer.corp acer ?

I'm a bit mystified at the moment, so here's what I did. I edited
mailname and hosts, adding the "1"s, reconfigured exim (making no
changes to the dialog boxes), and rebooted.

$ cat /etc/mailname 
acer.corp1
$ cat /etc/hosts 
127.0.0.1   localhost
127.0.1.1   acer1.corp  acer1
192.168.1.14axis.corp   axis

# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
$ hostname
acer
$ domainname
(none)
$ dnsdomainname
dnsdomainname: Name or service not known
$ mail.mailutils -s acer1.corp1 auser@axis
Cc: 
acer1 in hosts, corp1 in mailname
 
$ 

and here's the email on axis:

>From au...@acer.corp Thu Apr 28 11:37:06 2022
Return-path: 
Envelope-to: auser@axis
Delivery-date: Thu, 28 Apr 2022 11:37:06 -0500
Received: from [192.168.1.10] (helo=acer)
by axis.corp with esmtp (Exim 4.92)
(envelope-from )
id 1nk78c-0001yL-Bm
for auser@axis; Thu, 28 Apr 2022 11:37:06 -0500
Received: from auser by acer with local (Exim 4.94.2)
(envelope-from )
id 1nk78b-HX-6v
for auser@axis; Thu, 28 Apr 2022 11:37:05 -0500
Subject: acer1.corp1
To: auser@axis
X-Mailer: mail (GNU Mailutils 3.10)
Message-Id: 
From: me 
Date: Thu, 28 Apr 2022 11:37:05 -0500

acer1 in hosts, corp1 in mailname
^D

and the logs from each:

2022-04-28 11:37:05 1nk78b-HX-6v <= auser@acer U=auser P=local S=370
2022-04-28 11:37:06 1nk78b-HX-6v => auser@axis R=smarthost 
T=remote_smtp_smarthost H=192.168.1.14 [192.168.1.14] K C="250- 387 byte chunk, 
total 387\\n250 OK id=1nk78c-0001yL-Bm"
2022-04-28 11:37:06 1nk78b-HX-6v Completed

2022-04-28 11:37:06 1nk78c-0001yL-Bm <= au...@acer.corp H=(acer) [192.168.1.10] 
P=esmtp K S=559 id=E1nk78b-HX-6v@acer
2022-04-28 11:37:06 1nk78c-0001yL-Bm => auser  R=local_user 
T=mail_spool
2022-04-28 11:37:06 1nk78c-0001yL-Bm Completed

So, for the hostname, /etc/hostname (acer, untouched) or DHCP (I'm
not sure if my router would send that, though it does know acer's
name) seems to be winning.

Cheers,
David.

Re: email lacks sender address

[Brian]

On Wed 27 Apr 2022 at 14:57:19 -0500, David Wright wrote:

> On Wed 27 Apr 2022 at 08:05:46 (-0400), Haines Brown wrote:
> > 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. 
> 
> OK. So I would drop all conversation about a "Sender: line".
> You are the sender, the person who drops the letter in the blue
> box on the street. The headers that are relevant are "from"
> headers, "From:" in the email and "MAIL FROM" in the envelope.
> So all these error messages that talk about a missing "sender"
> are just using the agent, you, in place of the preposition, from.
> 
> The lines which principally concern you/your system are:
> 
> 1) The EHLO line, which you typically don't see, is read from
> /etc/mailname by exim, is set to lenin.histomat.net, and works.
> You set it early in the debian-installer, if Devuan follows
> along the same path. You confirmed it immediately after you
> told exim "mail sent by smarthost; … … ", on the next screen
> (again, if Devuan follows).

The EHLO is typically seen in the first Received: header. In your
case it is axis.corp. It is not obtained from /etc/mailname by exim.

I would guess you have a line in /etc/hosts like this:

  127.0.1.1   axis.corp  HOSTNAME

A suitablely configured exim gets the EHLO from this line. To test,
use

127.0.1.1 test.axis.corp  HOSTNAME

and send a mail.

I would suggest

 
https://wiki.debian.org/PkgExim4UserFAQ#How_does_exim_find_out_its_host_name_to_use_in_HELO.2FEHLO.3F

as a reasonable source of information.

-- 
Brian.

Re: email lacks sender address

[tomas]

On Wed, Apr 27, 2022 at 10:43:33PM +0200, Vincent Lefevre wrote:
> On 2022-04-27 11:29:17 -0400, Greg Wooledge wrote:
> > So if your /etc/mailname contains lenin.histomat.net then mail sent by
> > john on your system may(!) have a default(!) from/sender address of
> > j...@lenin.histomat.net.  Unless it's overridden.
> > 
> > If what you WANT is for your outgoing mail to appear to come from
> > j...@histomat.net then you should have histomat.net in that file instead.
> > 
> > The fact that lenin.histomat.net has no MX or A records in global DNS
> > means it's completely unsuitable for being the right-hand side of an
> > email address.  So, what you have now is clearly not correct.
> 
> No, this is not necessarily incorrect. If mail is sent locally,
> this is fine. For mail sent to other machines, 2 things can be
> done in such a case:

Agreed. The receiving MTA has to be convinced that the one sending
the stuff is supposed to. What that takes is up to that MTA's admin.

For example, the sender could provide a cerrtificate for the SMTPS
session (I've set up systems like that).

Of course, a random MTA contacting "me" with no MX record is either
misconfigured or (more probably) a low-cost spammer, so I'll tend
to reject that.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: email lacks sender address

[Vincent Lefevre]

On 2022-04-27 14:31:51 -0400, Greg Wooledge wrote:
> Funny thing, though... I'm not sure that /etc/mailname actually does
> anything other than sit there looking cute.  Reading farther along in
> , it says:
> 
>   Exim (i.e. exim 3.x) doesn't read /etc/mailname at all. When you
>   configure it, it prompts you for what it calls the "visible name"
>   of the system. This is stored in /etc/mailname, and also used in a
>   few places in the exim config file.
> 
> But also:
> 
>   Failing to come up with something better exim4 (and mutt) use mailname
>   to qualify recipients and therefore exim4 makes mailname a local
>   domain. If people don't want that, they delete it from the list in
>   the debconf dialog.
> 
> I'm honestly not sure how to interpret that paragraph about exim4.

This means that if you send a mail to "foo" (without a @ followed
by a domain), then "foo" will be qualified with the mailname, i.e.
adding "@" followed by the contents of /etc/mailname.

So, if you have two machines host1.domain.tld and host2.domain.tld,
since their users may be different (typically, root), I think that
it is better to have mailname = FQDN of the machine. Otherwise,
mailname = domain.tld may be fine.

> They're using "local domain" as a technical term with a highly
> specific meaning, but it's something unique to exim4, and I don't
> use exim4 myself.

No, "local domain" just means that the mail is received locally.
If domain.tld is a local domain, then mail sent to f...@domain.tld
will be sent to the mailbox foo on the local machine instead of
being sent through the smarthost (or directly to a MX). This is
not specific to exim.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: email lacks sender address

[Vincent Lefevre]

On 2022-04-27 15:30:33 -0400, Greg Wooledge wrote:
> On Wed, Apr 27, 2022 at 07:26:31PM +0100, Brian wrote:
> > On Wed 27 Apr 2022 at 08:05:46 -0400, Haines Brown wrote:
> > >   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:
> > 
> > This message is from your smarthost, mail.guardedhost.com.
> 
> It doesn't look like it to me.

Agreed. The mail was rejected by the smarthost, and the user's
machine lenin.histomat.net reported this error back to the user
as a mailer-daemon message.

> > > 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 : Sender address rejected:
> > > not owned by user bro...@historicalmaterialism.info
> 
> > > Reporting-MTA: dns; lenin.histomat.net
> 
> > However, the devuan server apparently decides to look at what is in
> > the mail being sent. At least, that is what I surmise from
> > 
> >   ...after pipelined sending data block
> > 
> > It decides to reject the mail on what it sees, not on guardedhost.com
> > being an inappropriate sender.
> 
> That's a very interesting conclusion, but it's not what I'm seeing.
> 
> First, I'm just ignoring the "after pipelined sending data block" part,
> because I don't know what that means.

I think that the data block was sent at the same time that the
sender address was inspected (hence the word "pipelined", which
just means that several operations overlap, which is common in
SMTP to speed up things: the client doesn't have to wait for
the server reply to send the next data).

> The clearest part is ": Sender address rejected".
> That sounds very much like it rejected the message specifically because
> it didn't like the sender address.  The "not owned by user" part
> is supporting detail.  There's nothing here to indicate that it inspected
> the body in order to make its rejection decision.
> 
> So, what I'm seeing here:
> 
> 1) The "Reporting-MTA: dns; lenin.histomat.net" tells us which MTA is
>actually writing this error message.
> 
> 2) "sur...@popcon.devuan.org" is the intended recipient address.
> 
> 3) "host mail.guardedhost.com [216.239.133.245]" is the remote host the
>MTA was talking to when the error occurred.
> 
> 4) The "SMTP error ..." line is gibberish to me, except that it tells us
>that the remote mail server (the smarthost) is who generated the error.
> 
> 5) The two lines starting with "553 5.7.1 ..." were generated by the
>smarthost, and reported here by the local MTA.
> 
> As I've said, I don't use exim myself, so I might be mistaken about some
> or all of these conclusions.  But that's my interpretation.

I entirely agree with this interpretation.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: email lacks sender address

[Vincent Lefevre]

On 2022-04-27 13:46:01 -0400, Haines Brown wrote:
> On Wed, Apr 27, 2022 at 11:29:17AM -0400, Greg Wooledge wrote:
> > If what you WANT is for your outgoing mail to appear to come from
> > j...@histomat.net then you should have histomat.net in that file instead.
> 
> Thanks for the clarifation. I changed it to histomat because I want 
> outgoing mail to appear to come from hai...@histomat.net.

Only if you send mail with just a username in "From:", e.g.

  From: haines

In general, one prefers to handle the "From:" address at the
MUA level.

The only advantage or disadvantage is that if you send a mail to
hai...@histomat.net, I think that it will be sent locally instead
of remotely (that is, going to the smarthost). The local mailbox
and the remote mailbox are generally different. So this depends
on what you prefer.

> However just changing it does not fix my problem.

Not surprising.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: email lacks sender address

[Haines Brown]

On Wed, Apr 27, 2022 at 05:14:34PM +0100, Jonathan Dowland wrote:
> On Wed, Apr 27, 2022 at 10:37:28AM -0400, Haines Brown wrote:
> > Don't my headers show that I'm using Devuan? Devuan is simply Debian
> > without systemd.
> 
> And any bugs they have introduced. We cannot handle support for Devuan
> because we are not responsible for what they release.

Understood

Re: email lacks sender address

[Vincent Lefevre]

On 2022-04-27 11:29:17 -0400, Greg Wooledge wrote:
> So if your /etc/mailname contains lenin.histomat.net then mail sent by
> john on your system may(!) have a default(!) from/sender address of
> j...@lenin.histomat.net.  Unless it's overridden.
> 
> If what you WANT is for your outgoing mail to appear to come from
> j...@histomat.net then you should have histomat.net in that file instead.
> 
> The fact that lenin.histomat.net has no MX or A records in global DNS
> means it's completely unsuitable for being the right-hand side of an
> email address.  So, what you have now is clearly not correct.

No, this is not necessarily incorrect. If mail is sent locally,
this is fine. For mail sent to other machines, 2 things can be
done in such a case:

1. Provide a fully qualified e-mail address when sending the mail.
   This is what one usually does.

2. Configure the local mail server (here, exim) to do address
   rewriting.

(You can also do both.)

For instance, on my laptop, I use

zira:~> cat /etc/mailname
zira.vinc17.org

which is the FQDN of the machine, and it is resolvable locally only.
This is fine for local mail, e.g. sent by cron.

And with Mutt, I provide the correct e-mail address with my_hdr
(to set the "From:" header, which will be used for the envelope),
e.g. vinc...@vinc17.net for this mail message.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: email lacks sender address

[Greg Wooledge]

On Wed, Apr 27, 2022 at 02:57:19PM -0500, David Wright wrote:
> 4) The MAIL FROM address, which is the one that you're having trouble
> with.

Just to keep everything clear, the MAIL FROM address and the envelope
sender address are the same thing.  The colloquial use of "sender" (with
lowercase s, and no colon) in some diagnostic messages may refer to
this address.  Or not.  Interpreting diagnostic messages is an art, not
a science.

The original purpose of the MAIL FROM address is "where to send bounces".
Back in the old days, before spam became so prevalent, a typical email
followed a path something like this:

1) User composes the email using their MUA.

2) The MUA injects the email into the local queue using /usr/sbin/sendmail
   (or /usr/lib/sendmail back then).  At this point, the envelope sender
   (MAIL FROM) and envelope recipient (RCPT TO) addresses are established,
   either by the MUA or by the local MTA.

3) The local MTA attempts delivery of the message to the envelope recipient.

4) The recipient's MTA receives the message and injects it into its own
   local queue.

5) The recipient's MTA attempts local delivery of the message.  If this
   fails, a bounce message is created, and sent back to the sender's
   MAIL FROM address, with an empty MAIL FROM.  The empty MAIL FROM on
   the bounce message prevents infinite bounce loops.  The bounce cannot
   be bounced again.

Step 4 is where a lot of changes have occurred in recent decades.  Back in
the original days of email, the receiving MTA typically did not check
things like "is this address actually deliverable".  It would simply
check whether the "@domain" part was "one of mine", or if the message
would have to be relayed.  Checks for the validity of the full receipient
address, including the left-hand side, were delayed until local delivery
processes took over.

This worked well enough until spam took over the Internet.

Spammers began sending messages with two targets -- the actual recipient,
and a second recipient listed in the MAIL FROM.  If the message was
delivered to the actual recipient, then they got a reader that way.  If
the message wasn't delivered to the actual recipient, it might be
bounced back to the MAIL FROM address, and the second recipient would
see it (along with an error message).

Also, if the first recipient happens to be clever enough to read the email
headers, it would appear that the spam was written by the second
recipient, who is also a victim.

This is known as "joe-jobbing".

Modern MTA strategy is to reject the message during the SMTP transaction
if at all possible, and avoid sending bounces -- because the MAIL FROM
is not reliable.

So, the original purpose of the MAIL FROM (destination for bounces) is
mostly obsolete at this point.  Instead, people are using MAIL FROM as
an identifier for authentication purposes.  It's incredibly weak, and
you can spoof it to anything you like, so it's not really a form of
authentication so much as a "way of preventing simple accidents".

A mail relay (smarthost) might decide that it will only accept your
messages if your MAIL FROM is in a special allowed-list.  This is in
addition to whatever other authentication checks the smarthost may perform,
such as checking that the client's IP is in an allowed-list, or SMTP AUTH
which involves using a username and password, or POP-before-SMTP, which
means that it only permits relaying for clients who have accessed the POP3
service on the same machine within the last n minutes.

Isn't email *fun*?

So anyway, configuring your MAIL FROM (envelope sender) address correctly
is really important.

Re: email lacks sender address

[David Wright]

On Wed 27 Apr 2022 at 08:05:46 (-0400), Haines Brown wrote:
> 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. 

OK. So I would drop all conversation about a "Sender: line".
You are the sender, the person who drops the letter in the blue
box on the street. The headers that are relevant are "from"
headers, "From:" in the email and "MAIL FROM" in the envelope.
So all these error messages that talk about a missing "sender"
are just using the agent, you, in place of the preposition, from.

The lines which principally concern you/your system are:

1) The EHLO line, which you typically don't see, is read from
/etc/mailname by exim, is set to lenin.histomat.net, and works.
You set it early in the debian-installer, if Devuan follows
along the same path. You confirmed it immediately after you
told exim "mail sent by smarthost; … … ", on the next screen
(again, if Devuan follows).

2) Your address for authentication with the smarthost, which appears
to be mail.guardedhost.com. So you've put a line like:

  mail.guardedhost.com:bro...@historicalmaterialism.info:some-secret

into /etc/exim4/passwd.client, and that's working.

3) The From: field in the email header. You're responsible for writing
that, and it will usually be a globally valid email address that
someone replying to you would use as their To: address. I think
you're using exim's rewrite facility to change local addresses to, eg
hai...@histomat.net (you're logged in as haines) and r...@histomat.net
(popcon apparently runs as root).

I don't suppose survey@popcon ever replies to the latter address, but
I assume that people email you at the former address. Whatever
histomat.net runs could be checking that usernames are registered in
some way, but often that's not the case—my own domain places no
limits on the left side of the @.

4) The MAIL FROM address, which is the one that you're having trouble
with. It has to be set, and it has to be acceptable to the people who
run the submission port on mail.guardedhost.com. It doesn't have to
bear any relationship to your machine's name, nor the From: address
in the email itself. It's often something that you paid good money for,
and frequently resembles any email address that's used for
authentication, like your bro...@historicalmaterialism.info address.
It could relate to any domain you buy, or to any ISP you connect to.

> 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?

Already deconstructed in the thread.

> Understood. But my impression is not that there is no Sender: field, 
> but that it is empty (<>).

The MAIL FROM was 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.

Ah, presumably these are the messages that were failing when you wrote
the OP.

> The mail server does not recognize 
> the root@histomat[].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 : Sender address rejected:
> not owned by user bro...@historicalmaterialism.info

That's a different error, 553, not 554, and being sent from the destination.

> The address hai...@histomat.net is owned by 
> bro...@historicalmaterialism.info. Omnis mail server never had a 
> problem with r...@histomat.net before.

The recipient might be testing r...@histomat.net to see if it can send
mail to it. It does this by starting a transaction (that never gets
completed). debian-user does this at least since August 2020, and it
can be a bit of pain.

> > 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?

Yes, just like a letter.

> Does this leave it to mutt to construct the Sender: line?

No "Sender:" line. Mutt constructs the envelope from the From: and To:
but with any extra rules in your configuration, as we have discussed.

> > You have to tell mutt what to use. It can't assume that your $LOGNAME
> > and /etc/mailname are, 

Re: email lacks sender address

[Greg Wooledge]

On Wed, Apr 27, 2022 at 07:26:31PM +0100, Brian wrote:
> On Wed 27 Apr 2022 at 08:05:46 -0400, Haines Brown wrote:
> >   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:
> 
> This message is from your smarthost, mail.guardedhost.com.

It doesn't look like it to me.

> > 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 : Sender address rejected:
> > not owned by user bro...@historicalmaterialism.info

> > Reporting-MTA: dns; lenin.histomat.net

> However, the devuan server apparently decides to look at what is in
> the mail being sent. At least, that is what I surmise from
> 
>   ...after pipelined sending data block
> 
> It decides to reject the mail on what it sees, not on guardedhost.com
> being an inappropriate sender.

That's a very interesting conclusion, but it's not what I'm seeing.

First, I'm just ignoring the "after pipelined sending data block" part,
because I don't know what that means.

The clearest part is ": Sender address rejected".
That sounds very much like it rejected the message specifically because
it didn't like the sender address.  The "not owned by user" part
is supporting detail.  There's nothing here to indicate that it inspected
the body in order to make its rejection decision.

So, what I'm seeing here:

1) The "Reporting-MTA: dns; lenin.histomat.net" tells us which MTA is
   actually writing this error message.

2) "sur...@popcon.devuan.org" is the intended recipient address.

3) "host mail.guardedhost.com [216.239.133.245]" is the remote host the
   MTA was talking to when the error occurred.

4) The "SMTP error ..." line is gibberish to me, except that it tells us
   that the remote mail server (the smarthost) is who generated the error.

5) The two lines starting with "553 5.7.1 ..." were generated by the
   smarthost, and reported here by the local MTA.

As I've said, I don't use exim myself, so I might be mistaken about some
or all of these conclusions.  But that's my interpretation.

Re: email lacks sender address

[Brian]

On Wed 27 Apr 2022 at 13:46:01 -0400, Haines Brown wrote:

> On Wed, Apr 27, 2022 at 11:29:17AM -0400, Greg Wooledge wrote:
>  
> > YOU ARE NOT USING DEBIAN SO WE DON'T KNOW!
> 
> I insist that the Devan operating system I use is identical to Debian 
> except for its lack of systemd. Its installation is identical to 
> that of Debian and all packages come from the Debian repository.

Please do not use that argument here. devuan declares itself as a
*fork* of Debian. That is its main selling point. It is not the
same as Debian when it comes to many aspects of the OSs

Your issue is with a devuan mail server. It should really be discussed
there. Just be thankful you are receiving some help.

-- 
Brian.

Re: email lacks sender address

[Greg Wooledge]

On Wed, Apr 27, 2022 at 01:46:01PM -0400, Haines Brown wrote:
> Thanks for the clarifation. I changed it to histomat because I want 
> outgoing mail to appear to come from hai...@histomat.net.

OK!  We're making progress now.

Funny thing, though... I'm not sure that /etc/mailname actually does
anything other than sit there looking cute.  Reading farther along in
, it says:

  Exim (i.e. exim 3.x) doesn't read /etc/mailname at all. When you
  configure it, it prompts you for what it calls the "visible name"
  of the system. This is stored in /etc/mailname, and also used in a
  few places in the exim config file.

But also:

  Failing to come up with something better exim4 (and mutt) use mailname
  to qualify recipients and therefore exim4 makes mailname a local
  domain. If people don't want that, they delete it from the list in
  the debconf dialog.

I'm honestly not sure how to interpret that paragraph about exim4.
They're using "local domain" as a technical term with a highly specific
meaning, but it's something unique to exim4, and I don't use exim4 myself.

What it *sounds* like is "the content of /etc/mailname will be used in the
configuration dialog as a default value".  In other words, changing the
content of /etc/mailname won't do anything unless you then go through the
next step of configuring exim4's "local domains", whatever those are.

> However just 
> changing it does not fix my problem.

*nod*

> I may have to restart networking. 
> If this works I'll let the thread know.

It won't.  Networking has nothing to do with MTA configuration.

> > YOU ARE NOT USING DEBIAN SO WE DON'T KNOW!
> 
> I insist that the Devan operating system I use is identical to Debian 
> except for its lack of systemd. Its installation is identical to 
> that of Debian and all packages come from the Debian repository.

You have already demonstrated that this is false.  Your popcon package
is sending its results to a different address than the Debian popcon
package uses.  This means the Devuan popcon package is different.  Which
means it's coming from a different repository.

Devuan has *changes*.  That's why you selected it.  That also means that
we, as users of Debian, may not know what all of those changes *are*.

> In network setup during OS installation, if I recall 
> correctly, I'm asked for a) my host name and seprately for b) my 
> domain namer. It is entirely possible that when it asked for my domaiin name 
> that I entered lenin.histomat.net.

None of that is important.

What's important is configuring your MTA correctly.  Which means you stop
relying on what the installer did for you, and just fix things that need
to be fixed.

> But this seems unlikelyi because 
> my e-mail system has been working property until just a week ago. 

So, something changed a week ago.

Did *you* change something?  If so, what?

If not, then perhaps your smarthost's configuration was changed.  Did
your smarthost administrator send you any notifications of changes?
Anything like that?

Or did they just pull the rug out from under you?

> > unicorn:~$ host histomat.net
> > histomat.net has address 216.239.138.216
> > histomat.net mail is handled by 10 postoffice.omnis.com.
> > 
> > unicorn:~$ host postoffice.omnis.com.
> > postoffice.omnis.com has address 216.239.133.242
> > postoffice.omnis.com has IPv6 address 2607:fe90:1:1::1c
> > 
> > The similarity in the two IPv4 addresses catches my attention.  It looks
> > like this histomat.net domain name is "owned by" (or at least handled by)
> > the same people who own/handle postoffice.omnis.com.
> > 
> > I'm guessing that person isn't you.  You don't seem to know enough to be
> > running an Internet domain.
> 
> That is correct. I am not an IT person. My public IP address is indeed 
> 216.239.138.216.

Oh, that's interesting.  So histomat.net points to your machine.

> I assume it is assigned by my ISP. My ISP is Onnis. 

Ah.

> My mail service is also provided by Omnis. Would that explain the 
> similarity of the IP addresses?

Yes.

> > So, that begs the question of why you think it's appropriate to announce
> > yourself as histomat.net in your outgoing communications.
> 
> By "announce" do you refer to my domain name?

I'm talking about the envelope sender address and the From: header address
of your outgoing emails.  (Brian also mentioned the HELO address, but
that usually isn't important.)

Re-read your original error message.  The one where your exim MTA reported
that your smarthost had rejected the message.

Keep staring at it until understanding occurs.

> Are you asking why I use 
> histomat.net as my domain name? That is because it is my domain name. 

It points to your machine, so that sounds correct.

What does it mean that the domain name points to your machine?  It means
that you can use it for *incoming* email.  Other people, trying to send
email to you, will be able to use that domain name to reach you.

Well, they *would* be 

Re: email lacks sender address

[Byung-Hee HWANG]

Celejar  writes:

> (... thanks ...)
> the problem is that it doesn't verify the
> server's SSL certificate, so it's susceptible to a MITM attack by
> someone impersonating Gmail. Again, you'll have to judge for yourself
> whether this is something to worry about.

Now i understood correctly.
Thanks for the summary, Celejar!

Sincerely, Linux fan Byung-Hee

-- 
^고맙습니다 _布德天下_ 감사합니다_^))//

Re: email lacks sender address

[Brian]

On Wed 27 Apr 2022 at 08:05:46 -0400, Haines Brown wrote:

[...]

>   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:

This message is from your smarthost, mail.guardedhost.com. It has
attempted to send mail on your behalf to sur...@popcon.devuan.org.
It tell the server at devuan.org who it is and where the mail is
required to go to.  Those are the only two required items of info
the remote server needs to deliver the mail.
  
> 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 : Sender address rejected:
> not owned by user bro...@historicalmaterialism.info

However, the devuan server apparently decides to look at what is in
the mail being sent. At least, that is what I surmise from

  ...after pipelined sending data block

It decides to reject the mail on what it sees, not on guardedhost.com
being an inappropriate sender. It sees the sender as claiming to be
histomat.net but really being historicalmaterialism.info. This did
noy bother mail.guardedhost.com, but it puts popcon.devuan.org's
knickers in a twist. It rejects the mail.

(People would go beserk if Royal Mail or the US Postal System opend
every envelope and scrutnised its contents. But this is email and
invasion of privacy is all in a good cause).

> 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 : 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.

The problem is not with the Omnis mail server. It did its job.

-- 
Brian.

Re: email lacks sender address

[Haines Brown]

On Wed, Apr 27, 2022 at 11:29:17AM -0400, Greg Wooledge wrote:

> If what you WANT is for your outgoing mail to appear to come from
> j...@histomat.net then you should have histomat.net in that file instead.

Thanks for the clarifation. I changed it to histomat because I want 
outgoing mail to appear to come from hai...@histomat.net. However just 
changing it does not fix my problem. I may have to restart networking. 
If this works I'll let the thread know.

> In this entire thread I have yet to see you simply state what it is
> that you WANT or EXPECT.

Sorry. I simply wanted to fix the problem that some of my outgoing 
mail was rejected because of a protocol error. I wanted mail to get 
to its intended recipient; I expected that to happen.  The problem 
seems to be that Sender: field is empty. 

> YOU ARE NOT USING DEBIAN SO WE DON'T KNOW!

I insist that the Devan operating system I use is identical to Debian 
except for its lack of systemd. Its installation is identical to 
that of Debian and all packages come from the Debian repository.

> As a *guess*, it probably used your hostname, which you gave it, as
> the value of /etc/mailname.  There is no way it could know what you
> want without asking, and there has been a recent trend among OS
> installers to ask fewer questions, and to assume more things.

In network setup during OS installation, if I recall 
correctly, I'm asked for a) my host name and seprately for b) my 
domain namer. It is entirely possible that when it asked for my domaiin name 
that I entered lenin.histomat.net. But this seems unlikelyi because 
my e-mail system has been working property until just a week ago. 

> Of course, since we HAVE NO IDEA HOW YOUR OS'S INSTALLER WORKS, all
> we can do is guess.

If the installer were any different from that of Debian I would have
addressed the difference. Devuan is imply Devian without systemd. The 
installers presumably work the same. 

> > During network setup I entered the 
> > hostname lenin and domain name histomat.net. Or at least that was
> > my intention. 
> 
> It probably decided to use that as your /etc/mailname.

No. The system worked until a week ago.

> Now, let's look at this domain name for a moment.
> 
> unicorn:~$ host histomat.net
> histomat.net has address 216.239.138.216
> histomat.net mail is handled by 10 postoffice.omnis.com.
> 
> unicorn:~$ host postoffice.omnis.com.
> postoffice.omnis.com has address 216.239.133.242
> postoffice.omnis.com has IPv6 address 2607:fe90:1:1::1c
> 
> The similarity in the two IPv4 addresses catches my attention.  It looks
> like this histomat.net domain name is "owned by" (or at least handled by)
> the same people who own/handle postoffice.omnis.com.
> 
> I'm guessing that person isn't you.  You don't seem to know enough to be
> running an Internet domain.

That is correct. I am not an IT person. My public IP address is indeed 
216.239.138.216. I assume it is assigned by my ISP. My ISP is Onnis. 
My mail service is also provided by Omnis. Would that explain the 
similarity of the IP addresses?

> So, that begs the question of why you think it's appropriate to announce
> yourself as histomat.net in your outgoing communications.

By "announce" do you refer to my domain name? Are you asking why I use 
histomat.net as my domain name? That is because it is my domain name. 
I had my ISP create a simple alias for the domain name 
historicalmateiralism.info. It has the same IP address as hstomat.net.

> Furthermore, we've seen evidence that you're using an outgoing mail relay
> (not under your own control) which rejects your outgoing email if you
> try to identify yourself as r...@lenin.histomat.net.  Would it also have
> rejected r...@histomat.net?  Who knows.  Certainly not us, because you
> haven't performed that test and told us the result.

I presume that by "outgoing mail relay" you refer to the mail service 
provided by my ISP. I understand that it will reject 
r...@lenin.histomat.net because my hostname is not part of my domain 
name. 

I have no idea off hand how to test if mail sent from 
r...@histomat.net will get through. All I can think of is telnet. I 
don't know whether mail has an option to define the sender. Perhaps I 
could log in as root and send mail

> This makes me wonder what envelope sender address(es) it WILL accept.
> Knowing that would be incredibly useful.  It may be the single most
> important piece of data you could possibly possess in this entire
> scenario, as it will probably dictate everything there is to be dictated
> about how you should configure your outgoing email.

I know from past success that it will accept mail from haines@histomat 
(and from bro...@historicalmaterialism.info)
 
> Do you have any actual *instructions* or *documentation* that was
> given to you by the histomat.net / postoffice.omnis.com administrators?
> Something that could guide you toward setting up your outgoing email in
> a way they will tolerate?  Or is it going to be 100% 

Re: email lacks sender address

[Jonathan Dowland]

On Wed, Apr 27, 2022 at 10:37:28AM -0400, Haines Brown wrote:

Don't my headers show that I'm using Devuan? Devuan is simply Debian
without systemd.


And any bugs they have introduced. We cannot handle support for Devuan
because we are not responsible for what they release.

--
Please do not CC me for listmail.

  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Re: email lacks sender address

[Brian]

On Wed 27 Apr 2022 at 11:29:17 -0400, Greg Wooledge wrote:

> On Wed, Apr 27, 2022 at 11:05:20AM -0400, Haines Brown wrote:

[...]
 
> > In /etc/hosts I have the line:
> > 
> >   127.0.1.1   lenin.histomat.net  lenin
> 
> Irrelevant, except insofar as it verifies that you correctly typed your
> desired hostname at some point.  Email certainly will not care.

Not entirely. Exim would use lenin.histomat.net as the (E)HELO.
A smaarthost wouls probably not care as it has authenticated
the sender. So, nothing to worry about.

-- 
Brian.

Re: email lacks sender address

[Haines Brown]

On Wed, Apr 27, 2022 at 05:13:51PM +0200, Vincent Lefevre wrote:
> On 2022-04-25 11:39:01 -0400, Haines Brown wrote:
> > Incidentally, I get 
> > 
> >   $ hostname -A
> >   lenin-16.home
> > 
> > that's strange. Should be lenin.histomat.net
> 
> About this point, you should not use "hostname -A", but
> "hostname -f" (or "hostname --fqdn").
> 
> The -A option will just give you the FQDNs associated with
> configured network interfaces, if any; this isn't much useful.

Aha. Thanks
> 

Re: email lacks sender address

[Greg Wooledge]

On Wed, Apr 27, 2022 at 11:05:20AM -0400, Haines Brown wrote:
> If mailname (the value of /etc/mailname) is supposed to be my FQDN, 
> then that would be lenin.histomat.net
> 
>   $ hostname -f
>   lenin.histomat.net 
> 
>   $ nano /etc/mailname
>   lenin.histomat.net

 says:

  If your package needs to know what hostname to use on (for example)
  outgoing news and mail messages which are generated locally, you should
  use the file /etc/mailname. It will contain the portion after the
  username and @ (at) sign for email addresses of users on the machine
  (followed by a newline).

So if your /etc/mailname contains lenin.histomat.net then mail sent by
john on your system may(!) have a default(!) from/sender address of
j...@lenin.histomat.net.  Unless it's overridden.

If what you WANT is for your outgoing mail to appear to come from
j...@histomat.net then you should have histomat.net in that file instead.

The fact that lenin.histomat.net has no MX or A records in global DNS
means it's completely unsuitable for being the right-hand side of an
email address.  So, what you have now is clearly not correct.

> So should the value of /etc/mailname be a FQDN or simply a domain 
> name?

It should be what you WANT TO SEE on the right hand side of the @ sign
in auto-generated from/sender-type addresses in outgoing email.

In this entire thread I have yet to see you simply state what it is
that you WANT or EXPECT.

> If the latter, then the question is how my installion of the operating 
> system managed to get it wrong.

YOU ARE NOT USING DEBIAN SO WE DON'T KNOW!

As a *guess*, it probably used your hostname, which you gave it, as
the value of /etc/mailname.  There is no way it could know what you
want without asking, and there has been a recent trend among OS
installers to ask fewer questions, and to assume more things.

Of course, since we HAVE NO IDEA HOW YOUR OS'S INSTALLER WORKS, all
we can do is guess.

> During network setup I entered the 
> hostname lenin and domain name histomat.net. Or at least that was
> my intention. 

It probably decided to use that as your /etc/mailname.

If that's NOT WHAT YOU WANT, then CHANGE IT.

(Caveat: you can also override the enveloper sender address, the From:
header address, and so on, so that /etc/mailname becomes irrelevant.)

> In /etc/hosts I have the line:
> 
>   127.0.1.1   lenin.histomat.net  lenin

Irrelevant, except insofar as it verifies that you correctly typed your
desired hostname at some point.  Email certainly will not care.

Now, let's look at this domain name for a moment.

unicorn:~$ host histomat.net
histomat.net has address 216.239.138.216
histomat.net mail is handled by 10 postoffice.omnis.com.

unicorn:~$ host postoffice.omnis.com.
postoffice.omnis.com has address 216.239.133.242
postoffice.omnis.com has IPv6 address 2607:fe90:1:1::1c

The similarity in the two IPv4 addresses catches my attention.  It looks
like this histomat.net domain name is "owned by" (or at least handled by)
the same people who own/handle postoffice.omnis.com.

I'm guessing that person isn't you.  You don't seem to know enough to be
running an Internet domain.

So, that begs the question of why you think it's appropriate to announce
yourself as histomat.net in your outgoing communications.

Furthermore, we've seen evidence that you're using an outgoing mail relay
(not under your own control) which rejects your outgoing email if you
try to identify yourself as r...@lenin.histomat.net.  Would it also have
rejected r...@histomat.net?  Who knows.  Certainly not us, because you
haven't performed that test and told us the result.

This makes me wonder what envelope sender address(es) it WILL accept.
Knowing that would be incredibly useful.  It may be the single most
important piece of data you could possibly possess in this entire
scenario, as it will probably dictate everything there is to be dictated
about how you should configure your outgoing email.

Do you have any actual *instructions* or *documentation* that was
given to you by the histomat.net / postoffice.omnis.com administrators?
Something that could guide you toward setting up your outgoing email in
a way they will tolerate?  Or is it going to be 100% guesswork?

(Also, what is mail.guardedhost.com?  I still never saw an answer to that.)

Re: email lacks sender address

[Celejar]

On Wed, 27 Apr 2022 10:04:06 +0900
Byung-Hee HWANG   wrote:

> Dear Celejar,
> 
> Celejar  writes:
> 
> > On Tue, 26 Apr 2022 09:42:38 +0900
> > 황병희  wrote:
> >
> >> Dear Greg,
> >> 
> >> Greg Wooledge  writes:
> >> 
> >> > (... thanks ...)
> >> > unicorn:~$ apt-cache show ssmtp

...

> >> Really i love sSMTP so much!!!
> >
> > FWIW, there's an outstanding ten year old bug against sSMTP pointing
> > out that it doesn't bother to validate server TLS certificates. You'll
> > have to decide whether this bothers you or not:
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662960
> 
> That seems some technical issue. However i have no skills to repair that
> C level program.
> 
> Actually i have no trouble with current sSMTP. Both Gmail and yw-1204
> does not break about this matter (verify certificate). So for a while
> i'll keep this state. It means that i will continue to use the sSMTP.


[From another email by Byung-Hee:]

> Correction: Exactly, i did't see any problems. Because i have been using 
> always
> self-signed certficate with sSMTP.
> 
> Sorry for confusing statement. 

I'm not sure what you are saying here - are you possibly confusing
client and server certificates? - but the problem is not that sSMTP
doesn't work with Gmail - the problem is that it doesn't verify the
server's SSL certificate, so it's susceptible to a MITM attack by
someone impersonating Gmail. Again, you'll have to judge for yourself
whether this is something to worry about.

-- 
Celejar

Re: email lacks sender address

[Haines Brown]

On Wed, Apr 27, 2022 at 10:52:07AM -0400, Greg Wooledge wrote:
> On Wed, Apr 27, 2022 at 10:46:53AM -0400, Haines Brown wrote:
> > In exim4 condiguration I select smarthost.
> 
> Is your smarthost "mail.guardedhost.com"?

I don't understand. I thought the question in exim configuration 
referred to my own set up. I tell exim to use smart host for my 
outcgoing mail. The address mail.guardedhost.com is simply the mail 
serrver address to which I send outgoing mail.
 
> > So did you mean the 
> > recipient mail server must use smarthost?
> 
> That's total nonsense.  A smarthost is for relaying your outgoing mail.

My understanding is that the mail server to which I send mail 
understands SMTP.

Re: email lacks sender address

[Vincent Lefevre]

On 2022-04-25 11:39:01 -0400, Haines Brown wrote:
> Incidentally, I get 
> 
>   $ hostname -A
>   lenin-16.home
> 
> that's strange. Should be lenin.histomat.net

About this point, you should not use "hostname -A", but
"hostname -f" (or "hostname --fqdn").

The -A option will just give you the FQDNs associated with
configured network interfaces, if any; this isn't much useful.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: email lacks sender address

[Haines Brown]

On Wed, Apr 27, 2022 at 03:31:05PM +0100, Brian wrote:
> On Wed 27 Apr 2022 at 15:38:21 +0200, to...@tuxteam.de wrote:
> 
> > On Wed, Apr 27, 2022 at 01:42:05PM +0100, Brian wrote:
> > 
> > [...]
> > 
> > > lenin.histomat.net appears to be unrouteable. How a remote system would
> >^^^
> > > deal with that is anyone's guess.
> > 
> > unresolvable (i.e. there's no (MX) DNS record "out there" for it) is what
> > you want to say?
> 
> I did mean that. Thanks. OTOH, histomat.net is resolvable.

If mailname (the value of /etc/mailname) is supposed to be my FQDN, 
then that would be lenin.histomat.net

  $ hostname -f
  lenin.histomat.net 

  $ nano /etc/mailname
  lenin.histomat.net

True, an MX record refers to a domain name and so I suppose can make 
no sense of a domain prepended with a hostname. 

So should the value of /etc/mailname be a FQDN or simply a domain 
name?

If the latter, then the question is how my installion of the operating 
system managed to get it wrong. During network setup I entered the 
hostname lenin and domain name histomat.net. Or at least that was
my intention. 

In /etc/hosts I have the line:

  127.0.1.1   lenin.histomat.net  lenin

Re: email lacks sender address

[Greg Wooledge]

On Wed, Apr 27, 2022 at 10:46:53AM -0400, Haines Brown wrote:
> In exim4 condiguration I select smarthost.

Is your smarthost "mail.guardedhost.com"?

> So did you mean the 
> recipient mail server must use smarthost?

That's total nonsense.  A smarthost is for relaying your outgoing mail.

Re: email lacks sender address

[Haines Brown]

On Wed, Apr 27, 2022 at 04:26:09PM +0200, Vincent Lefevre wrote:
> On 2022-04-27 09:36:22 -0400, Haines Brown wrote:
> > On Wed, Apr 27, 2022 at 01:42:05PM +0100, Brian wrote:
> > > On Wed 27 Apr 2022 at 08:05:46 -0400, Haines Brown wrote:

> > Thanks for the clarification. 
> > 
> > > > These values are present:
> > > > 
> > > >   $ nano /etec/mailname
> > > >   lenin.histomat.net
> > > 
> > > lenin.histomat.net appears to be unrouteable. How a remote system would
> > > deal with that is anyone's guess.

> > I do not understand. What should /etc/mailname look like?

The reason for my question is that I believe this is the mailname that 
I've always used (except for changing hostname) without any problem.

  $ hostname -f
  lenin.histomat.net

> In general, the FQDN of your machine. It does not need to be
> resolvable, but if it isn't, you will probably need to use a
> smarthost.

In exim4 condiguration I select smarthost. So did you mean the 
recipient mail server must use smarthost?

Re: email lacks sender address

[Haines Brown]

On Wed, Apr 27, 2022 at 08:28:27AM -0400, Greg Wooledge wrote:
> On Wed, Apr 27, 2022 at 08:05:46AM -0400, Haines Brown wrote:
> > 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
> 
> Obvious typo.  This means you are not pasting results directly from a
> terminal into an email.  Instead, you're re-typing them, and making
> tons of errors in the process.  That makes it super hard to know what
> is actually real.

I apologize for the errors. I had just arisen and not yet had my 
coffe. Also as I approach 90 I make more typos. My eyesight is not so 
sharp and my fingerwork don't behave as well.

> > 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 
>
> popcon, not popcorn.
> 
> > root send a priodidic message. The mail server does not recognize 
> > the r...@histomats.net address. It sends me this message:
> 
> *Which* mail server?  Who is "it"?

A company named Omnis provides me with an email account. I presume it 
fumctions as a mail server and does my own machine. The error message 
below came from the former. I simply pasted it.

> >   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 : Sender address rejected:
> > not owned by user bro...@historicalmaterialism.info
> > 
> > Reporting-MTA: dns; lenin.histomat.net

> So, this message was generated by your own MTA running on your own
> computer, after the message was rejected by the receiving MTA.

No. This the mesage sent by the receiving MTA, Omnis.

> There are many things I do not understand in this error message.  For
> starters, who or what is "host mail.guardedhost.com [216.239.133.245]"
> and what do they have to do with anything?

That is the address, less a port number, required by the Omnis server 
for incoming email messages.

> It sounds like something on *your* end.  Maybe you've configured your
> MTA to use a smarthost,

Yes, I did. In exim4 confguration I selected "mail sent by smarthost; 
received via SMTP or fetchmail". I assume the Omnis mail server 
accepts mail using the SMTP protocol.

> and mail.guardedhost.com is your smarthost?

No, that is recipient address provided by Omnis less a port 
number. I send outgoing email to it.
 
> And if so, it's refusing to relay mail from you as long as you claim
> to be r...@histomat.net instead of bro...@historicalmaterialism.info
> or something.

Yes, so it appears. However, popcon has always sent periodic mail 
presumably from root without this problem.

> Also, you appear not to be using Debian, so... all bets are off.

Don't my headers show that I'm using Devuan? Devuan is simply Debian 
without systemd.

Re: email lacks sender address

[Brian]

On Wed 27 Apr 2022 at 15:38:21 +0200, to...@tuxteam.de wrote:

> On Wed, Apr 27, 2022 at 01:42:05PM +0100, Brian wrote:
> 
> [...]
> 
> > lenin.histomat.net appears to be unrouteable. How a remote system would
>^^^
> > deal with that is anyone's guess.
> 
> unresolvable (i.e. there's no (MX) DNS record "out there" for it) is what
> you want to say?

I did mean that. Thanks. OTOH, histomat.net is resolvable.

Re: email lacks sender address

[Vincent Lefevre]

On 2022-04-27 09:36:22 -0400, Haines Brown wrote:
> On Wed, Apr 27, 2022 at 01:42:05PM +0100, Brian wrote:
> > On Wed 27 Apr 2022 at 08:05:46 -0400, Haines Brown wrote:
> 
> > > 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?
> > 
> > No. exim4 uses what is in /etec/mailname as the MAI FROM: (the envelope
> > from).
> 
> Thanks for the clarification. 
> 
> > > These values are present:
> > > 
> > >   $ nano /etec/mailname
> > >   lenin.histomat.net
> > 
> > lenin.histomat.net appears to be unrouteable. How a remote system would
> > deal with that is anyone's guess.
> 
> I do not understand. What should /etc/mailname look like?

In general, the FQDN of your machine. It does not need to be
resolvable, but if it isn't, you will probably need to use a
smarthost.

> I suspect it should simply be histomat.net

You may use it if you own the domain. Otherwise, I think that
this could lead to problems, with mail sent to the wrong place
(think of mail sent to root and mail sent to some external
histomat.net user).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: email lacks sender address

[Vincent Lefevre]

On 2022-04-27 08:05:46 -0400, Haines Brown wrote:
> 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?

On my machine that uses exim (used to send this mail), exim does not
add a "Sender:" line. The exim4(8) man page says for the -f option:

  Processes running  as  root  or  the  Exim  user  are  always
  trusted. Other trusted users are defined by the trusted_users
  or trusted_groups options. In the absence of -f,  or  if  the
  caller  is  not trusted, the sender of a local message is set
  to the caller's login name at the default qualify domain.

But if you set use_envelope_from in Mutt, the -f option will be
used (see OPTENVFROM in sendlib.c).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: email lacks sender address

[tomas]

On Wed, Apr 27, 2022 at 01:42:05PM +0100, Brian wrote:

[...]

> lenin.histomat.net appears to be unrouteable. How a remote system would
   ^^^
> deal with that is anyone's guess.

unresolvable (i.e. there's no (MX) DNS record "out there" for it) is what
you want to say?

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: email lacks sender address

[Haines Brown]

On Wed, Apr 27, 2022 at 01:42:05PM +0100, Brian wrote:
> On Wed 27 Apr 2022 at 08:05:46 -0400, Haines Brown wrote:

> > 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?
> 
> No. exim4 uses what is in /etec/mailname as the MAI FROM: (the envelope
> from).

Thanks for the clarification. 

> > These values are present:
> > 
> >   $ nano /etec/mailname
> >   lenin.histomat.net
> 
> lenin.histomat.net appears to be unrouteable. How a remote system would
> deal with that is anyone's guess.

I do not understand. What should /etc/mailname look like? I suspect it 
should simply be histomat.net and wonder how the host name got in 
there. I changed it to the latter value but still get 5.5.1 Protocol 
error from online email tester. Perhaps I need to restart networking.

Re: email lacks sender address

[Brian]

On Wed 27 Apr 2022 at 08:05:46 -0400, Haines Brown wrote:

> 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?

No. exim4 uses what is in /etec/mailname as the MAI FROM: (the envelope
from).
 
> These values are present:
> 
>   $ nano /etec/mailname
>   lenin.histomat.net

lenin.histomat.net appears to be unrouteable. How a remote system would
deal with that is anyone's guess.

-- 
Brian.

Re: email lacks sender address

[Greg Wooledge]

On Wed, Apr 27, 2022 at 08:05:46AM -0400, Haines Brown wrote:
> 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

Obvious typo.  This means you are not pasting results directly from a
terminal into an email.  Instead, you're re-typing them, and making
tons of errors in the process.  That makes it super hard to know what
is actually real.

>   $ echo $LOGNAME
>   haines

You mentioned $LOCALHOST before, and now suddenly it's $LOGNAME.

> 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 

popcon, not popcorn.

> root send a priodidic message. The mail server does not recognize 
> the r...@histomats.net address. It sends me this message:

*Which* mail server?  Who is "it"?

>   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 : Sender address rejected:
> not owned by user bro...@historicalmaterialism.info
> 
> Reporting-MTA: dns; lenin.histomat.net

So, this message was generated by your own MTA running on your own
computer, after the message was rejected by the receiving MTA.

There are many things I do not understand in this error message.  For
starters, who or what is "host mail.guardedhost.com [216.239.133.245]"
and what do they have to do with anything?

unicorn:~$ host -t mx popcon.devuan.org
popcon.devuan.org mail is handled by 10 mx.devuan.org.
unicorn:~$ host mx.devuan.org
mx.devuan.org has address 141.95.83.167

There's no mention of mail.guardedhost.com or 216.239.133.245 in DNS
at all.

It sounds like something on *your* end.  Maybe you've configured your
MTA to use a smarthost, and mail.guardedhost.com is your smarthost?
And if so, it's refusing to relay mail from you as long as you claim
to be r...@histomat.net instead of bro...@historicalmaterialism.info
or something.

Also, you appear not to be using Debian, so... all bets are off.

Re: email lacks sender address

[Haines Brown]

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 : 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 : 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 

Re: email lacks sender address

[Vincent Lefevre]

On 2022-04-27 09:19:38 -, Curt wrote:
> On 2022-04-26, David Wright  wrote:
> > Well, the simple way, which is why I use it, is to put:
> >
> >   set envelope_from_address="someuser@somedomain"
> >   set use_envelope_from
> 
> The OP sent me an email off-list in which he informed me he was doing
> his best and that he'd changed *both* of the following parameters to
> booleans (yes!). I guess he misunderstood our proofreading. 
> 
>  set envelope_from_address
>  set use_envelope_from

Unfortunately, Mutt doesn't output an error when one uses
"set variable" for non-boolean variables.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: email lacks sender address

[Curt]

On 2022-04-26, David Wright  wrote:
>
> Well, the simple way, which is why I use it, is to put:
>
>   set envelope_from_address="someuser@somedomain"
>   set use_envelope_from

The OP sent me an email off-list in which he informed me he was doing
his best and that he'd changed *both* of the following parameters to
booleans (yes!). I guess he misunderstood our proofreading. 


 set envelope_from_address
 set use_envelope_from

Re: email lacks sender address

[Byung-Hee HWANG]

> Both Gmail and yw-1204
> does not break about this matter (verify certificate).

Correction: Exactly, i did't see any problems. Because i have been using always
self-signed certficate with sSMTP.

Sorry for confusing statement. 

Sincerely, Linux fan Byung-Hee

-- 
^고맙습니다 _布德天下_ 감사합니다_^))//

Re: email lacks sender address

[Byung-Hee HWANG]

Dear Celejar,

Celejar  writes:

> On Tue, 26 Apr 2022 09:42:38 +0900
> 황병희  wrote:
>
>> Dear Greg,
>> 
>> Greg Wooledge  writes:
>> 
>> > (... thanks ...)
>> > unicorn:~$ apt-cache show ssmtp
>> > [...]
>> > Description-en: extremely simple MTA to get mail off the system to
>> > a mail hub
>> >  A secure, effective and simple way of getting mail off a system to your
>> >  mail hub. It contains no suid-binaries or other dangerous things - no mail
>> >  spool to poke around in, and no daemons running in the background. Mail is
>> >  simply forwarded to the configured mailhost. Extremely easy configuration.
>> >
>> > The entire point of this package is that it's meant to be used on a
>> > "dumb client" which does not wish to have its own outgoing mail queue.
>> > Instead, it forwards all of your mail to your "smart host" -- the MTA
>> > that has been set up for your organization's dumb clients to use.
>> >
>> > So, the single piece of information you need in order to use ssmtp is
>> > the hostname of your smart host.  Also known as your mail relay.  Or many
>> > other names.  It's where you want your outgoing mail to be handled.
>> >
>> 
>> Thanks for your time and your life!
>> 
>> Really i love sSMTP so much!!!
>
> FWIW, there's an outstanding ten year old bug against sSMTP pointing
> out that it doesn't bother to validate server TLS certificates. You'll
> have to decide whether this bothers you or not:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662960

That seems some technical issue. However i have no skills to repair that
C level program.

Actually i have no trouble with current sSMTP. Both Gmail and yw-1204
does not break about this matter (verify certificate). So for a while
i'll keep this state. It means that i will continue to use the sSMTP.

Sorry and thanks ^^^

Sincerely, Linux fan Byung-Hee

-- 
^고맙습니다 _布德天下_ 감사합니다_^))//

Re: email lacks sender address

[David Wright]

On Tue 26 Apr 2022 at 09:25:48 (-0400), Haines Brown wrote:
> On Tue, Apr 26, 2022 at 10:10:48AM +0100, Jonathan Dowland wrote:
> > On Mon, Apr 25, 2022 at 11:39:01AM -0400, Haines Brown wrote:
> > > I infer that exim is not being given the envelop address of the
> > > sender.
> > 
> > Quoting /etc/exim4/exim4.conf.template:
> > 
> > # By default, exim forces a Sender: header containing the local
> > # account name at the local host name in all locally submitted messages
> > # that don't have the local account name at the local host name in the
> > # From: header, deletes any Sender: header present in the submitted
> > # message and forces the envelope sender of all locally submitted
> > # messages to the local account name at the local host name.
> > # The following settings allow local users to specify their own envelope 
> > sender
> > # in a locally submitted message. Sender: headers existing in a locally
> > # submitted message are not removed, and no automatic Sender: headers
> > # are added. These settings are fine for most hosts.
> > # If you run exim on a classical multi-user systems where all users
> > # have local mailboxes that can be reached via SMTP from the Internet
> > # with the local FQDN as the domain part of the address, you might want
> > # to disable the following three lines for traceability reasons.
> > .ifndef MAIN_FORCE_SENDER
> > local_from_check = false
> > local_sender_retain = true
> > untrusted_set_sender = *
> > .endif
> > 
> >   Jonathan Dowland
> > ✎j...@debian.org
> >    https://jmtd.net
> 
> Johathan, many thanks for pointing out the content of exim 
> configuration template. The exim config files are so intimidating that 
> unless there is a reason to so so an amateur like myself tries to 
> avoid them.

I would be very surprised if you had /any/ need to configure exim4
beyond what is offered by Debian's  dpkg-reconfigure exim4-config
script (which writes /etc/exim4/update-exim4.conf.conf for you)
and adding a line of credentials to /etc/exim4/passwd.client so
that you can authenticate your system to your smarthost.

> What I get out of this is that my MUA (mutt) might generate a message 
> that lacks a local account name (I assume it is defined by the content 
> of /etc/mailname, whicn in my case happens to be lenin.histomat.net). 
> I infer this is the value that appaars in the Sender: line of the 
> message header consructed by mutt. 
> 
> The above text describes what exim does if that Sender: line in the 
> header happens to be empt or missing. If I understand correctly, exim 
> deletes the empty Sender: line and instead uses the value of 
> /etc/mailname to be the envelop sender. Is this so?

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?

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.)

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.

> The text goes on to say that if the three lines it specifies at the 
> end are present, it allows the user to specify whatever he/she 
> likes to appear as the envelop's sender.
> 
> This raises questions. 
> 
> 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.

It sounds as if you're making too many assumptions about what mutt
can determine about you, like what your sending and receiving email
addresses are. (Like in your next line: without any configuration)

> I already ran mutt without any configuration and it didn't seem to 
> help.  I sumitted by domain name to an online mail tesing site and get 
> "Unverified address: postoffice.omnis.com said: 521 5.5.1 Protocol 
> error." Omnis told me the problem was the Sender: line was empty in 
> some messages.  

This is why I'm struggling to understand your situation. It's not like
mutt to randomly choose whether to bother to add fileds to the header.
What did Omnis actually say, literally?

In your OP, you wrote "554 5.7.1 Empty Sender Address
  is prohibited through this server; from=<>"

I 

Re: email lacks sender address

[Celejar]

On Tue, 26 Apr 2022 09:42:38 +0900
황병희  wrote:

> Dear Greg,
> 
> Greg Wooledge  writes:
> 
> > (... thanks ...)
> > unicorn:~$ apt-cache show ssmtp
> > [...]
> > Description-en: extremely simple MTA to get mail off the system to a mail 
> > hub
> >  A secure, effective and simple way of getting mail off a system to your
> >  mail hub. It contains no suid-binaries or other dangerous things - no mail
> >  spool to poke around in, and no daemons running in the background. Mail is
> >  simply forwarded to the configured mailhost. Extremely easy configuration.
> >
> > The entire point of this package is that it's meant to be used on a
> > "dumb client" which does not wish to have its own outgoing mail queue.
> > Instead, it forwards all of your mail to your "smart host" -- the MTA
> > that has been set up for your organization's dumb clients to use.
> >
> > So, the single piece of information you need in order to use ssmtp is
> > the hostname of your smart host.  Also known as your mail relay.  Or many
> > other names.  It's where you want your outgoing mail to be handled.
> >
> 
> Thanks for your time and your life!
> 
> Really i love sSMTP so much!!!

FWIW, there's an outstanding ten year old bug against sSMTP pointing
out that it doesn't bother to validate server TLS certificates. You'll
have to decide whether this bothers you or not:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662960

-- 
Celejar

Re: email lacks sender address

[Curt]

On 2022-04-26, Vincent Lefevre  wrote:
> On 2022-04-24 23:30:34 -0400, Haines Brown wrote:
>> I placed these two lines in ~./muttrc/muttrc
>> 
>>   set envelope_from_address=hai...@histomat.net
>>   set use_envelope_from=hai...@histomat.net
>> 
>> but still get 521 5.5.1 Protocol error om outgoing messages.
>
> Note that use_envelope_from is a boolean. If you do not get
> an error message from Mutt ("Usage: set variable=yes|no"),
> this means that this muttrc file hasn't been read.
>


Actually, we already pointed this out earlier, and I believe David W.
wondered why no error message was being generated by mutt given this
configuration error (which could be nicely explained by the config file
simply not being read).

But sadly the OP never followed up on these points.

Re: email lacks sender address

[Vincent Lefevre]

On 2022-04-24 23:30:34 -0400, Haines Brown wrote:
> I placed these two lines in ~./muttrc/muttrc
> 
>   set envelope_from_address=hai...@histomat.net
>   set use_envelope_from=hai...@histomat.net
> 
> but still get 521 5.5.1 Protocol error om outgoing messages.

Note that use_envelope_from is a boolean. If you do not get
an error message from Mutt ("Usage: set variable=yes|no"),
this means that this muttrc file hasn't been read.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: email lacks sender address

[Vincent Lefevre]

On 2022-04-26 09:25:48 -0400, Haines Brown wrote:
> What I get out of this is that my MUA (mutt) might generate a message 
> that lacks a local account name (I assume it is defined by the content 
> of /etc/mailname, whicn in my case happens to be lenin.histomat.net). 

No, /etc/mailname is just the FQDN (or something simpler in
some cases).

You should just use

  set use_envelope_from

in your muttrc, and provide a valid "From:" header.

(I use "set envelope_from", but envelope_from is actually the old name
for use_envelope_from.)

And make sure that $sendmail is equivalent to
"/usr/sbin/sendmail -oem -oi".

> Another question. The implication is that if the three lines are 
> present in the exim configuration it whould allow the user to specify 
> the envelop sender.

FYI, I haven't touched these 3 lines.

> Is this merley a statement of fact or is the template file used to
> construct the exim configuration?

Yes, it is used to generate the configuration file, which is
"/var/lib/exim4/config.autogenerated".

> 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?

Probably. But if you provide the correct addresses with Mutt,
this shouldn't matter.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: email lacks sender address

[Haines Brown]

On Tue, Apr 26, 2022 at 10:10:48AM +0100, Jonathan Dowland wrote:
> On Mon, Apr 25, 2022 at 11:39:01AM -0400, Haines Brown wrote:
> > I infer that exim is not being given the envelop address of the
> > sender.
> 
> Quoting /etc/exim4/exim4.conf.template:
> 
> # By default, exim forces a Sender: header containing the local
> # account name at the local host name in all locally submitted messages
> # that don't have the local account name at the local host name in the
> # From: header, deletes any Sender: header present in the submitted
> # message and forces the envelope sender of all locally submitted
> # messages to the local account name at the local host name.
> # The following settings allow local users to specify their own envelope 
> sender
> # in a locally submitted message. Sender: headers existing in a locally
> # submitted message are not removed, and no automatic Sender: headers
> # are added. These settings are fine for most hosts.
> # If you run exim on a classical multi-user systems where all users
> # have local mailboxes that can be reached via SMTP from the Internet
> # with the local FQDN as the domain part of the address, you might want
> # to disable the following three lines for traceability reasons.
> .ifndef MAIN_FORCE_SENDER
> local_from_check = false
> local_sender_retain = true
> untrusted_set_sender = *
> .endif
> 
> Jonathan Dowland
> ✎  j...@debian.org
>  https://jmtd.net

Johathan, many thanks for pointing out the content of exim 
configuration template. The exim config files are so intimidating that 
unless there is a reason to so so an amateur like myself tries to 
avoid them.

What I get out of this is that my MUA (mutt) might generate a message 
that lacks a local account name (I assume it is defined by the content 
of /etc/mailname, whicn in my case happens to be lenin.histomat.net). 
I infer this is the value that appaars in the Sender: line of the 
message header consructed by mutt. 

The above text describes what exim does if that Sender: line in the 
header happens to be empt or missing. If I understand correctly, exim 
deletes the empty Sender: line and instead uses the value of 
/etc/mailname to be the envelop sender. Is this so?

The text goes on to say that if the three lines it specifies at the 
end are present, it allows the user to specify whatever he/she 
likes to appear as the envelop's sender.

This raises questions. 

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. 

I already ran mutt without any configuration and it didn't seem to 
help.  I sumitted by domain name to an online mail tesing site and get 
"Unverified address: postoffice.omnis.com said: 521 5.5.1 Protocol 
error." Omnis told me the problem was the Sender: line was empty in 
some messages.  
 
Another question. The implication is that if the three lines are 
present in the exim configuration it whould allow the user to specify 
the envelop sender. Is this merley a statement of fact or 
is the template file used to construct the exim configuration? If the 
latter, then I should be able to write my own envelope sender line.

I can't imagine why I would want to do that, but if I did, how does 
one go about doing it? In the exim4 configuraiton routine one defines 
the define default system mail name. Is this value the name used for 
the envelope sender? Sometimes I have merely put in the host name and 
some times appended the domain name to it. Seems to work in either 
case. When the problem being discussed came up I changed from the 
former to the latter when I reconfigured exim. It did not help.

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?

Re: email lacks sender address

[Jonathan Dowland]

On Mon, Apr 25, 2022 at 11:39:01AM -0400, Haines Brown wrote:

I infer that exim is not being given the envelop address of the
sender.


Quoting /etc/exim4/exim4.conf.template:

# By default, exim forces a Sender: header containing the local
# account name at the local host name in all locally submitted messages
# that don't have the local account name at the local host name in the
# From: header, deletes any Sender: header present in the submitted
# message and forces the envelope sender of all locally submitted
# messages to the local account name at the local host name.
# The following settings allow local users to specify their own envelope sender
# in a locally submitted message. Sender: headers existing in a locally
# submitted message are not removed, and no automatic Sender: headers
# are added. These settings are fine for most hosts.
# If you run exim on a classical multi-user systems where all users
# have local mailboxes that can be reached via SMTP from the Internet
# with the local FQDN as the domain part of the address, you might want
# to disable the following three lines for traceability reasons.
.ifndef MAIN_FORCE_SENDER
local_from_check = false
local_sender_retain = true
untrusted_set_sender = *
.endif


--
Please do not CC me for listmail.

  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Re: email lacks sender address

[황병희]

Dear Greg,

Greg Wooledge  writes:

> (... thanks ...)
> unicorn:~$ apt-cache show ssmtp
> [...]
> Description-en: extremely simple MTA to get mail off the system to a mail hub
>  A secure, effective and simple way of getting mail off a system to your
>  mail hub. It contains no suid-binaries or other dangerous things - no mail
>  spool to poke around in, and no daemons running in the background. Mail is
>  simply forwarded to the configured mailhost. Extremely easy configuration.
>
> The entire point of this package is that it's meant to be used on a
> "dumb client" which does not wish to have its own outgoing mail queue.
> Instead, it forwards all of your mail to your "smart host" -- the MTA
> that has been set up for your organization's dumb clients to use.
>
> So, the single piece of information you need in order to use ssmtp is
> the hostname of your smart host.  Also known as your mail relay.  Or many
> other names.  It's where you want your outgoing mail to be handled.
>

Thanks for your time and your life!

Really i love sSMTP so much!!!

Thanks again ^^^

Sincerely, Linux fan Byung-Hee

-- 
^고맙습니다 _布德天下_ 감사합니다_^))//

Re: email lacks sender address

[Haines Brown]

On Mon, Apr 25, 2022 at 05:52:48PM +0100, Brian wrote:
> On Mon 25 Apr 2022 at 11:39:01 -0400, Haines Brown wrote:
> 
> > 2022-04-24 10:44:02 1nidSz-00068k-QP rejected from <> U=Debian-exim: 
> > message to>
> > Envelope-from: <>
> > Envelope-to: 
> > 
> > I infer that exim is not being given the envelop address of the
> > sender.
> 
> What do have in /etc/mailname?  

lenin.histomat.net

 

Re: email lacks sender address

[Brian]

On Mon 25 Apr 2022 at 11:39:01 -0400, Haines Brown wrote:

> 2022-04-24 10:44:02 1nidSz-00068k-QP rejected from <> U=Debian-exim: message 
> to>
> Envelope-from: <>
> Envelope-to: 
> 
> I infer that exim is not being given the envelop address of the
> sender.

What do have in /etc/mailname?  

-- 
Brian.

Re: email lacks sender address

[David Wright]

On Mon 25 Apr 2022 at 11:39:01 (-0400), Haines Brown wrote:
> On Sun, Apr 24, 2022 at 11:31:58PM -0500, David Wright wrote:
> > 
> > You need to look¹ at exim's logs (/var/log/exim4/mainlog,
> > /var/log/exim4/mainlog.1 and /var/log/exim4/mainlog.*.gz)
> > to see what it's trying to send. There should be a line
> > where mutt hands your email to exim
> >
> > DATE TIME UNIQUESTRING <= your-from-address U=username … message-ID
> > 
> > the string of interest↑
> > 
> > That should be followed by:
> > 
> > DATE TIME SAMESTRING => to-address A=this B=that …
> 
> 2022-04-24 10:44:02 1nidSz-00068k-QP rejected from <> U=Debian-exim: message 
> to>
> Envelope-from: <>
> Envelope-to: 
> 
> I infer that exim is not being given the envelop address of the
> sender.

Right, so now we need to know the origin of that particular email.
What do the logs show happening at that time.

If you, personally, sent it, presumably from mutt, and presumably
knowing that you did, then there's a problem in mutt, or in your
ability to compose a conforming email.

If the system sent it, which seems more likely because it's to root,
then we need to determine why the system that sent it didn't "know"
who it was. Typical senders include cron, sudo, SMART, etc.

Also, you need to check whether "you" is receiving a failed message
on the system. Because of the contents of /etc/aliases, this is
normally redirected to root/postmaster → root → sysadmin, where
sysadmin is the First User (who set up the machine), ie it should
arrive in /var/mail/you.

> > > what does "test-server.example.net" refer to? Sorry for my ignorance.
> > 
> > Read https://en.wikipedia.org/wiki/Example.com
> 
> Thanks David, but that was not my question. What test server is being 
> takled about?
> 
> I guess that the mail server is my own machine and so try:
> 
>   $ swaks  --to  ri...@yahoo.com --from hai...@histomat.net
>   ...
>   <-  250 STARTTLS
> -> MAIL FROM:
>   <** 553 5.7.2 [TSS09] All messages from 32.210.108.191 will be 
> permanently deferred; Retrying will NOT succeed. See 
>   https://postmaster.yahooinc.com/error-codes
>-> QUIT
>   *** Remote host closed connection unexpectedly.
> 
> Incidentally, I get 
> 
>   $ hostname -A
>   lenin-16.home
> 
> that's strange. Should be lenin.histomat.net

Your example demonstrates what example.net (and its companions,
com/org/edu) is for: example.net is a real domain, designed for use
in internet documentation.

$ ping test-server.example.net
ping: test-server.example.net: Name or service not known
$ ping www.example.net
PING www.example.net (93.184.216.34) 56(84) bytes of data.
64 bytes from 93.184.216.34 (93.184.216.34): icmp_seq=1 ttl=57 time=25.5 ms
^C
--- www.example.net ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 25.477/25.477/25.477/0.000 ms
$ ping example.net
PING example.net (93.184.216.34) 56(84) bytes of data.
64 bytes from 93.184.216.34 (93.184.216.34): icmp_seq=1 ttl=57 time=24.1 ms
64 bytes from 93.184.216.34 (93.184.216.34): icmp_seq=2 ttl=57 time=23.6 ms
^C
--- example.net ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 23.573/23.857/24.142/0.323 ms
$ 

Why do all telephone numbers in the movies start 555 …

Cheers,
David.

Re: email lacks sender address

[Haines Brown]

On Sun, Apr 24, 2022 at 11:31:58PM -0500, David Wright wrote:
> 
> You need to look¹ at exim's logs (/var/log/exim4/mainlog,
> /var/log/exim4/mainlog.1 and /var/log/exim4/mainlog.*.gz)
> to see what it's trying to send. There should be a line
> where mutt hands your email to exim
>
> DATE TIME UNIQUESTRING <= your-from-address U=username … message-ID
> 
> the string of interest↑
> 
> That should be followed by:
> 
> DATE TIME SAMESTRING => to-address A=this B=that …

2022-04-24 10:44:02 1nidSz-00068k-QP rejected from <> U=Debian-exim: message to>
Envelope-from: <>
Envelope-to: 

I infer that exim is not being given the envelop address of the
sender.
 
> > what does "test-server.example.net" refer to? Sorry for my ignorance.
> 
> Read https://en.wikipedia.org/wiki/Example.com

Thanks David, but that was not my question. What test server is being 
takled about?

I guess that the mail server is my own machine and so try:

  $ swaks  --to  ri...@yahoo.com --from hai...@histomat.net
  ...
  <-  250 STARTTLS
-> MAIL FROM:
  <** 553 5.7.2 [TSS09] All messages from 32.210.108.191 will be 
permanently deferred; Retrying will NOT succeed. See 
  https://postmaster.yahooinc.com/error-codes
   -> QUIT
  *** Remote host closed connection unexpectedly.

Incidentally, I get 

  $ hostname -A
  lenin-16.home

that's strange. Should be lenin.histomat.net

Re: email lacks sender address

[David Wright]

On Mon 25 Apr 2022 at 10:24:18 (-0400), Greg Wooledge wrote:
> On Mon, Apr 25, 2022 at 09:18:45AM -0500, David Wright wrote:
> > On Mon 25 Apr 2022 at 12:04:55 (-), Curt wrote:
> > > I thought 'set use_envelope_from' took a boolean value (yes or no). 
> > 
> > Good proofreading, thanks. The fact that this mistake did not
> > produce an error message may be down to the other problem:
> > mutt's configuration file is not called ~./muttrc/muttrc, but
> > either ~./muttrc or  ~./mutt/muttrc (I'm not qualified to
> > comment on the next possibility, $XDG_CONFIG_HOME/mutt/muttrc,
> > which might have something to do with DEs).
> 
> According to 
> :
> 
>   $XDG_CONFIG_HOME defines the base directory relative to which
>   user-specific configuration files should be stored. If $XDG_CONFIG_HOME
>   is either not set or empty, a default equal to $HOME/.config should
>   be used.
> 
> That would make it ~/.config/mutt/muttrc unless that environment variable
> is set (which it never is in any sensible setup).

I suppose that makes my guess close, but no cigar. I have noticed
that more and more packages place their configuration in ~/.config,
which is tidier than scattering them in ~ itself, but hadn't
twigged the reasoning. Most man pages just present the fact as a
fait accompli: "the configuration is in ~/.config/foo". Only about
two dozen of them mention XDG at all on my system's selection.
(I haven't tried to correlate their mentioning XDG with where their
configuration is placed.)

> So, either the OP has placed the wrong lines in the wrong file, or they
> have misrepresented their setup.

Yes, a typo, but one that raises another issue: why no reaction
to mutt's error message when it parses their configuration file?

Cheers,
David.

Re: email lacks sender address

[Haines Brown]

On Mon, Apr 25, 2022 at 09:18:45AM -0500, David Wright wrote:
> On Mon 25 Apr 2022 at 12:04:55 (-), Curt wrote:
> > On 2022-04-25, Haines Brown  wrote:
> > >
> > > I placed these two lines in ~./muttrc/muttrc
> > >
> > >   set envelope_from_address=hai...@histomat.net
> > >   set use_envelope_from=hai...@histomat.net
> > >
> > > but still get 521 5.5.1 Protocol error om outgoing messages.
> >  
> > I thought 'set use_envelope_from' took a boolean value (yes or no). 
> 
> Good proofreading, thanks. The fact that this mistake did not
> produce an error message may be down to the other problem:
> mutt's configuration file is not called ~./muttrc/muttrc, but
> either ~./muttrc or  ~./mutt/muttrc (I'm not qualified to
> comment on the next possibility, $XDG_CONFIG_HOME/mutt/muttrc,
> which might have something to do with DEs).
> 
> Cheers,
> David.

My apoloy for the typo. In fact my confitguration file is 
~/.mutt/muttrc 

Re: email lacks sender address

[Greg Wooledge]

On Mon, Apr 25, 2022 at 09:18:45AM -0500, David Wright wrote:
> On Mon 25 Apr 2022 at 12:04:55 (-), Curt wrote:
> > I thought 'set use_envelope_from' took a boolean value (yes or no). 
> 
> Good proofreading, thanks. The fact that this mistake did not
> produce an error message may be down to the other problem:
> mutt's configuration file is not called ~./muttrc/muttrc, but
> either ~./muttrc or  ~./mutt/muttrc (I'm not qualified to
> comment on the next possibility, $XDG_CONFIG_HOME/mutt/muttrc,
> which might have something to do with DEs).

According to 
:

  $XDG_CONFIG_HOME defines the base directory relative to which
  user-specific configuration files should be stored. If $XDG_CONFIG_HOME
  is either not set or empty, a default equal to $HOME/.config should
  be used.

That would make it ~/.config/mutt/muttrc unless that environment variable
is set (which it never is in any sensible setup).

So, either the OP has placed the wrong lines in the wrong file, or they
have misrepresented their setup.

Re: email lacks sender address

[David Wright]

On Mon 25 Apr 2022 at 12:04:55 (-), Curt wrote:
> On 2022-04-25, Haines Brown  wrote:
> >
> > I placed these two lines in ~./muttrc/muttrc
> >
> >   set envelope_from_address=hai...@histomat.net
> >   set use_envelope_from=hai...@histomat.net
> >
> > but still get 521 5.5.1 Protocol error om outgoing messages.
>  
> I thought 'set use_envelope_from' took a boolean value (yes or no). 

Good proofreading, thanks. The fact that this mistake did not
produce an error message may be down to the other problem:
mutt's configuration file is not called ~./muttrc/muttrc, but
either ~./muttrc or  ~./mutt/muttrc (I'm not qualified to
comment on the next possibility, $XDG_CONFIG_HOME/mutt/muttrc,
which might have something to do with DEs).

Cheers,
David.

Re: email lacks sender address

[Greg Wooledge]

On Sun, Apr 24, 2022 at 11:37:00PM -0400, Haines Brown wrote:
> On Mon, Apr 25, 2022 at 10:16:09AM +0900, 황병희 wrote:
> > Haines Brown  writes:
> > 
> > > (... thanks ...)
> > > 521 5.5.1 Protocol error (154.24 ms)
> > > Unverified address
> > >
> > > I reconfigured exim4 and it has no problem.
> > >
> > 
> > Or you try with sSMTP, very easy!
> > 
> > Sincerely, Linux fan Byung-Hee
> 
> Thanks for the suggestion, but I have same problem with ssmtp as I 
> do with swaks: what does "test-server.example.net" refer to? Sorry
> for my ignorance. 

unicorn:~$ apt-cache show ssmtp
[...]
Description-en: extremely simple MTA to get mail off the system to a mail hub
 A secure, effective and simple way of getting mail off a system to your
 mail hub. It contains no suid-binaries or other dangerous things - no mail
 spool to poke around in, and no daemons running in the background. Mail is
 simply forwarded to the configured mailhost. Extremely easy configuration.

The entire point of this package is that it's meant to be used on a
"dumb client" which does not wish to have its own outgoing mail queue.
Instead, it forwards all of your mail to your "smart host" -- the MTA
that has been set up for your organization's dumb clients to use.

So, the single piece of information you need in order to use ssmtp is
the hostname of your smart host.  Also known as your mail relay.  Or many
other names.  It's where you want your outgoing mail to be handled.

Re: email lacks sender address

[Curt]

On 2022-04-25, Haines Brown  wrote:
>
> I placed these two lines in ~./muttrc/muttrc
>
>   set envelope_from_address=hai...@histomat.net
>   set use_envelope_from=hai...@histomat.net
>
> but still get 521 5.5.1 Protocol error om outgoing messages.
>
>


I thought 'set use_envelope_from' took a boolean value (yes or no). 

Re: email lacks sender address

[황병희]

Haines Brown  writes:

> (... thanks ...)
> Thanks for the suggestion, but I have same problem with ssmtp as I 
> do with swaks: what does "test-server.example.net" refer to?

Sorry i don't know that <>.

> Sorry for my ignorance. 

Don't worry! Always email stuff are not easy, i think...


Sincerely, Linux fan Byung-Hee

-- 
^고맙습니다 _布德天下_ 감사합니다_^))//

Re: email lacks sender address

[황병희]

Dear Jim,

Jim Popovitch  writes:

> On Mon, 2022-04-25 at 10:16 +0900, 황병희 wrote:
>> Haines Brown  writes:
>> 
>> > (... thanks ...)
>> > 521 5.5.1 Protocol error (154.24 ms)
>> > Unverified address
>> > 
>> > I reconfigured exim4 and it has no problem.
>> > 
>> 
>> Or you try with sSMTP, very easy!
>
>
> sSMTP doesn't support or retry multiple servers, and it doesn't respect
> nsswitch.conf settings.

Thanks for guidance ^^^

> -Jim P.

Sincerely, Linux fan Byung-Hee

-- 
^고맙습니다 _布德天下_ 감사합니다_^))//

Re: email lacks sender address

[David Wright]

On Sun 24 Apr 2022 at 23:30:34 (-0400), Haines Brown wrote:
> On Sun, Apr 24, 2022 at 05:31:08PM -0500, David Wright wrote:
> 
> > It looks to me as if you have no /envelope/ sender on some messages.
> > I don't know whether that's caused by exim, say, failing to rewrite
> > an address properly, but it seems unlikely that you're going to
> > compose an email without a From: at the top. (I can't be sure: it
> > might be possible to compose without showing headers, and there's
> > also the possibility of sending emails from the command line.)
> > 
> > You can make mutt ensure that there's an envelope address by setting
> > either (or both, they interact) of envelope_from_address or
> > use_envelope_from. AIUI, exim can still select what actually gets
> > used.
> 
> I placed these two lines in ~./muttrc/muttrc
> 
>   set envelope_from_address=hai...@histomat.net
>   set use_envelope_from=hai...@histomat.net
> 
> but still get 521 5.5.1 Protocol error om outgoing messages.

You need to look¹ at exim's logs (/var/log/exim4/mainlog,
/var/log/exim4/mainlog.1 and /var/log/exim4/mainlog.*.gz)
to see what it's trying to send. There should be a line
where mutt hands your email to exim, looking like:

DATE TIME UNIQUESTRING <= your-from-address U=username … message-ID

the string of interest↑

That should be followed by:

DATE TIME SAMESTRING => to-address A=this B=that …

Compare these lines for a successful email, which finishes with:

… … C="250 2.0.0 Ok:  bytes queued as 12AB34CD56E"
DATE TIME SAMESTRING Completed

and those for an unsuccessful one.

> what does "test-server.example.net" refer to? Sorry for my ignorance.

Read https://en.wikipedia.org/wiki/Example.com

¹ You'll need to be in the adm group, or use sudo, or be root.

Cheers,
David.

Re: email lacks sender address

[Haines Brown]

On Mon, Apr 25, 2022 at 10:16:09AM +0900, 황병희 wrote:
> Haines Brown  writes:
> 
> > (... thanks ...)
> > 521 5.5.1 Protocol error (154.24 ms)
> > Unverified address
> >
> > I reconfigured exim4 and it has no problem.
> >
> 
> Or you try with sSMTP, very easy!
> 
> Sincerely, Linux fan Byung-Hee

Thanks for the suggestion, but I have same problem with ssmtp as I 
do with swaks: what does "test-server.example.net" refer to? Sorry
for my ignorance. 

Re: email lacks sender address

[Haines Brown]

On Sun, Apr 24, 2022 at 05:31:08PM -0500, David Wright wrote:

> It looks to me as if you have no /envelope/ sender on some messages.
> I don't know whether that's caused by exim, say, failing to rewrite
> an address properly, but it seems unlikely that you're going to
> compose an email without a From: at the top. (I can't be sure: it
> might be possible to compose without showing headers, and there's
> also the possibility of sending emails from the command line.)
> 
> You can make mutt ensure that there's an envelope address by setting
> either (or both, they interact) of envelope_from_address or
> use_envelope_from. AIUI, exim can still select what actually gets
> used.

I placed these two lines in ~./muttrc/muttrc

  set envelope_from_address=hai...@histomat.net
  set use_envelope_from=hai...@histomat.net

but still get 521 5.5.1 Protocol error om outgoing messages.

Re: email lacks sender address

[Jim Popovitch]

On Mon, 2022-04-25 at 10:16 +0900, 황병희 wrote:
> Haines Brown  writes:
> 
> > (... thanks ...)
> > 521 5.5.1 Protocol error (154.24 ms)
> > Unverified address
> > 
> > I reconfigured exim4 and it has no problem.
> > 
> 
> Or you try with sSMTP, very easy!


sSMTP doesn't support or retry multiple servers, and it doesn't respect
nsswitch.conf settings.

-Jim P.

Re: email lacks sender address

[황병희]

Haines Brown  writes:

> (... thanks ...)
> 521 5.5.1 Protocol error (154.24 ms)
> Unverified address
>
> I reconfigured exim4 and it has no problem.
>

Or you try with sSMTP, very easy!

Sincerely, Linux fan Byung-Hee

-- 
^고맙습니다 _救濟蒼生_ 감사합니다_^))//

Re: email lacks sender address

[David Wright]

On Sun 24 Apr 2022 at 16:02:31 (-0400), Haines Brown wrote:
> I use mutt to send messages through exim4. Some messages lack a
> sender. Here is a log emtry showing that from: address is blank:
> 
> Apr 24 11:11:29 tev-mail-relay1 postfix/smtpd[510179]: connect from
>   unknown[32.210.108.191]
> Apr 24 11:11:30 tev-mail-relay1 postfix/smtpd[510179]: Anonymous TLS 
> connection
>   established from unknown[32.210.108.191]: TLSv1.3 with cipher
>   TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256)
>   server-signature RSA-PSS (2048 bits) server-digest SHA256
> Apr 24 11:11:30 tev-mail-relay1 postfix/smtpd[510179]: NOQUEUE: milter-reject:
>   MAIL from unknown[32.210.108.191]: 554 5.7.1 Empty Sender Address
>   is prohibited through this server; from=<>
>   proto=ESMTP helo=
>   sasl_username=
> Apr 24 11:11:30 tev-mail-relay1 postfix/smtpd[510179]: disconnect from
>   unknown[32.210.108.191] ehlo=2 starttls=1 auth=1 mail=0/1 rcpt=0/1
>   bdat=0/1 quit=1 commands=5/8
> 
> 521 5.5.1 Protocol error (154.24 ms)
> Unverified address
> 
> I reconfigured exim4 and it has no problem.

It looks to me as if you have no /envelope/ sender on some messages.
I don't know whether that's caused by exim, say, failing to rewrite
an address properly, but it seems unlikely that you're going to
compose an email without a From: at the top. (I can't be sure: it
might be possible to compose without showing headers, and there's
also the possibility of sending emails from the command line.)

You can make mutt ensure that there's an envelope address by setting
either (or both, they interact) of envelope_from_address or
use_envelope_from. AIUI, exim can still select what actually gets
used.

↓ ie the envelope sender …
>   MAIL from unknown[32.210.108.191]: 554 5.7.1 Empty Sender Address
>   is prohibited through this server; from=<>
 … would be here ↑

>   ehlo=2 starttls=1 auth=1 mail=0/1 rcpt=0/1 bdat=0/1 quit=1 commands=5/8

ehlo worked (russian leader)
starttls worked
ehlo worked again
authentication worked
mail from (empty) failed
rcpt to not reached
data not reached
quit on their side worked
makes 5 out of 8.

Cheers,
David.

Re: email lacks sender address

[Jonathan Dowland]

On Sun, Apr 24, 2022 at 04:02:31PM -0400, Haines Brown wrote:

I use mutt to send messages through exim4. Some messages lack a
sender.


Any idea what circumstances result in messages which do, or do not, have
a Sender? Do you have anything relevant in /etc/email-addresses?


Here is a log emtry showing that from: address is blank:


Sender: or From:? or SMTP FROM? I'm not familiar enough with Postfix to
interpret the logs, but,  it seems to be talking about Sender:. 


I would start by trying to rule out some of the software involved here.
Try using swaks to generate test mails to your local exim, ruling out
mutt, and then use swaks directly to your Postfix relay, and see if you
get different results.

--
Please do not CC me for listmail.

  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net