Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #247493 > unrolled thread

email lacks sender address

Back to article view | Back to linux.debian.user

Contents

  email lacks sender address Haines Brown <haines@histomat.net> - 2022-04-24 22:10 +0200
    Re: email lacks sender address Jonathan Dowland <jon+debian-user@dow.land> - 2022-04-24 23:40 +0200
    Re: email lacks sender address David Wright <deblis@lionunicorn.co.uk> - 2022-04-25 00:40 +0200
      Re: email lacks sender address Haines Brown <haines@histomat.net> - 2022-04-25 05:40 +0200
        Re: email lacks sender address David Wright <deblis@lionunicorn.co.uk> - 2022-04-25 06:40 +0200
          Re: email lacks sender address Haines Brown <haines@histomat.net> - 2022-04-25 17:50 +0200
            Re: email lacks sender address David Wright <deblis@lionunicorn.co.uk> - 2022-04-25 18:50 +0200
            Re: email lacks sender address Brian <ad44@cityscape.co.uk> - 2022-04-25 19:00 +0200
              Re: email lacks sender address Haines Brown <haines@histomat.net> - 2022-04-25 21:10 +0200
            Re: email lacks sender address Jonathan Dowland <jon+debian-user@dow.land> - 2022-04-26 11:20 +0200
              Re: email lacks sender address Haines Brown <haines@histomat.net> - 2022-04-26 15:30 +0200
                Re: email lacks sender address Vincent Lefevre <vincent@vinc17.net> - 2022-04-26 17:10 +0200
                Re: email lacks sender address David Wright <deblis@lionunicorn.co.uk> - 2022-04-26 22:30 +0200
                  Re: email lacks sender address Curt <curty@free.fr> - 2022-04-27 11:30 +0200
                    Re: email lacks sender address Vincent Lefevre <vincent@vinc17.net> - 2022-04-27 11:50 +0200
                  Re: email lacks sender address Haines Brown <haines@histomat.net> - 2022-04-27 14:10 +0200
                    Re: email lacks sender address Greg Wooledge <greg@wooledge.org> - 2022-04-27 14:30 +0200
                      Re: email lacks sender address Haines Brown <haines@histomat.net> - 2022-04-27 16:40 +0200
                        Re: email lacks sender address Jonathan Dowland <jon+debian-user@dow.land> - 2022-04-27 18:20 +0200
                          Re: email lacks sender address Haines Brown <haines@histomat.net> - 2022-04-27 23:00 +0200
                    Re: email lacks sender address Brian <ad44@cityscape.co.uk> - 2022-04-27 14:50 +0200
                      Re: email lacks sender address Haines Brown <haines@histomat.net> - 2022-04-27 15:40 +0200
                        Re: email lacks sender address Vincent Lefevre <vincent@vinc17.net> - 2022-04-27 16:30 +0200
                          Re: email lacks sender address Haines Brown <haines@histomat.net> - 2022-04-27 16:50 +0200
                            Re: email lacks sender address Greg Wooledge <greg@wooledge.org> - 2022-04-27 17:00 +0200
                              Re: email lacks sender address Haines Brown <haines@histomat.net> - 2022-04-27 17:30 +0200
                      Re: email lacks sender address <tomas@tuxteam.de> - 2022-04-27 15:40 +0200
                        Re: email lacks sender address Brian <ad44@cityscape.co.uk> - 2022-04-27 16:40 +0200
                          Re: email lacks sender address Haines Brown <haines@histomat.net> - 2022-04-27 17:10 +0200
                            Re: email lacks sender address Greg Wooledge <greg@wooledge.org> - 2022-04-27 17:30 +0200
                              Re: email lacks sender address Brian <ad44@cityscape.co.uk> - 2022-04-27 18:10 +0200
                              Re: email lacks sender address Haines Brown <haines@histomat.net> - 2022-04-27 19:50 +0200
                                Re: email lacks sender address Greg Wooledge <greg@wooledge.org> - 2022-04-27 20:40 +0200
                                  Re: email lacks sender address Vincent Lefevre <vincent@vinc17.net> - 2022-04-27 23:50 +0200
                                Re: email lacks sender address Brian <ad44@cityscape.co.uk> - 2022-04-27 21:10 +0200
                                Re: email lacks sender address Vincent Lefevre <vincent@vinc17.net> - 2022-04-27 23:00 +0200
                              Re: email lacks sender address Vincent Lefevre <vincent@vinc17.net> - 2022-04-27 22:50 +0200
                                Re: email lacks sender address <tomas@tuxteam.de> - 2022-04-28 07:00 +0200
                    Re: email lacks sender address Vincent Lefevre <vincent@vinc17.net> - 2022-04-27 16:20 +0200
                    Re: email lacks sender address Brian <ad44@cityscape.co.uk> - 2022-04-27 20:30 +0200
                      Re: email lacks sender address Greg Wooledge <greg@wooledge.org> - 2022-04-27 21:40 +0200
                        Re: email lacks sender address Vincent Lefevre <vincent@vinc17.net> - 2022-04-27 23:30 +0200
                    Re: email lacks sender address David Wright <deblis@lionunicorn.co.uk> - 2022-04-27 22:00 +0200
                      Re: email lacks sender address Greg Wooledge <greg@wooledge.org> - 2022-04-27 22:30 +0200
                      Re: email lacks sender address Brian <ad44@cityscape.co.uk> - 2022-04-28 17:00 +0200
                        Re: email lacks sender address David Wright <deblis@lionunicorn.co.uk> - 2022-04-28 19:10 +0200
                          Re: email lacks sender address Greg Wooledge <greg@wooledge.org> - 2022-04-28 19:20 +0200
                            Re: email lacks sender address David Wright <deblis@lionunicorn.co.uk> - 2022-04-29 01:50 +0200
            Re: email lacks sender address Vincent Lefevre <vincent@vinc17.net> - 2022-04-27 17:20 +0200
              Re: email lacks sender address Haines Brown <haines@histomat.net> - 2022-04-27 17:30 +0200
        Re: email lacks sender address Curt <curty@free.fr> - 2022-04-25 14:10 +0200
          Re: email lacks sender address David Wright <deblis@lionunicorn.co.uk> - 2022-04-25 16:20 +0200
            Re: email lacks sender address Greg Wooledge <greg@wooledge.org> - 2022-04-25 16:30 +0200
              Re: email lacks sender address David Wright <deblis@lionunicorn.co.uk> - 2022-04-25 17:10 +0200
            Re: email lacks sender address Haines Brown <haines@histomat.net> - 2022-04-25 16:40 +0200
        Re: email lacks sender address Vincent Lefevre <vincent@vinc17.net> - 2022-04-26 17:20 +0200
          Re: email lacks sender address Curt <curty@free.fr> - 2022-04-26 17:40 +0200
    Re: email lacks sender address 황병희 <soyeomul@doraji.xyz> - 2022-04-25 03:20 +0200
      Re: email lacks sender address Jim Popovitch <jim@k4vqc.com> - 2022-04-25 03:50 +0200
        Re: email lacks sender address 황병희 <soyeomul@doraji.xyz> - 2022-04-25 06:50 +0200
      Re: email lacks sender address Haines Brown <haines@histomat.net> - 2022-04-25 05:40 +0200
        Re: email lacks sender address 황병희 <soyeomul@doraji.xyz> - 2022-04-25 07:00 +0200
        Re: email lacks sender address Greg Wooledge <greg@wooledge.org> - 2022-04-25 14:50 +0200
          Re: email lacks sender address 황병희 <soyeomul@doraji.xyz> - 2022-04-26 02:50 +0200
            Re: email lacks sender address Celejar <celejar@gmail.com> - 2022-04-26 18:10 +0200
              Re: email lacks sender address Byung-Hee HWANG <soyeomul@doraji.xyz>  - 2022-04-27 03:10 +0200
                Re: email lacks sender address Byung-Hee HWANG <soyeomul@doraji.xyz>  - 2022-04-27 03:20 +0200
                Re: email lacks sender address Celejar <celejar@gmail.com> - 2022-04-27 17:30 +0200
                  Re: email lacks sender address Byung-Hee HWANG <soyeomul@doraji.xyz>  - 2022-04-27 20:40 +0200
                    Re: email lacks sender address (SOLVED) Haines Brown <haines@histomat.net> - 2022-05-08 18:10 +0200
                      Re: email lacks sender address (SOLVED) Charles Curley <charlescurley@charlescurley.com> - 2022-05-08 19:10 +0200
                        Re: email lacks sender address (SOLVED) David Wright <deblis@lionunicorn.co.uk> - 2022-05-09 02:50 +0200
                          Re: email lacks sender address (SOLVED) Charles Curley <charlescurley@charlescurley.com> - 2022-05-09 03:30 +0200
                            Re: email lacks sender address (SOLVED) David Wright <deblis@lionunicorn.co.uk> - 2022-05-09 04:40 +0200

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#247666

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.

> >     survey@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 <root@histomat.net>: Sender address rejected:
> >     not owned by user brownh@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 "<root@histomat.net>: 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) "survey@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.

[toc] | [prev] | [next] | [standalone]

#247677

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.

> > >     survey@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 <root@histomat.net>: Sender address rejected:
> > >     not owned by user brownh@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 "<root@histomat.net>: 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) "survey@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 <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[toc] | [prev] | [next] | [standalone]

#247667

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:brownh@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
haines@histomat.net (you're logged in as haines) and root@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 brownh@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:
> 
>     survey@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 <root@histomat.net>: Sender address rejected:
>     not owned by user brownh@historicalmaterialism.info

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

> The address haines@histomat.net is owned by 
> brownh@historicalmaterialism.info. Omnis mail server never had a 
> problem with root@histomat.net before.

The recipient might be testing root@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, 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?

It only knows what you tell it. And lenin.histomat.net is OK there.

> > 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="haines@histomat.net"
>   set use_envelope_from
> 
> If these take immediae effect (without restarting mutt), then they did 
> not help.

No, mutt only reads its configuration when you start it. And exim is
similar (dpkg-reconfigure does this for you, of course).

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

Only use_envelope_from is boolean (of the two envelope variables).
set envelope_from_address obviously needs an address (or empty).

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

Yes, but I now suspect that your problem might only have arisen
with the system's emails, and not yours (ie mutt's). I would
need confirmation of that, as you haven't spelled out which
emails fail and which don't.

> > The reason /I/ have to do that is that submission to my ISP requires
> > an email address belonging to them. I've never used my ISP's email
> > system beyond logging in to it every so long to prevent it expiring.
> 
> Seems like my own situation.

Well I thought you'd made some linkage between omnis (looks like your
ISP) and brownh@historicalmaterialism.info (looks like your domain).
My domain is hosted 4000 miles from my ISP in a different country.

> > > In exim configuration I hide outgoing local mail name and provide
> > > the domain name without prepending host name. I assume
> > > this is irrevant and is merley a cosmetic isaue. Is that so?
> > 
> > If it's an email address, it shouldn't cause a problem. I'm assuming
> > that you're doing away with lenin, so to speak, which is probably
> > the correct thing to do, as I'm guessing that you don't run a mail
> > server on lenin.
> 
> Emacs configuration first asks whether to hide the visible domain 
> name. I answer Yes, and so it asks what that name should be. I enter 
> histomat.net. But above you say "an email addess". Did you mean just 
> the domain portion of an address?
> 
> > Summary: tell mutt who you are. And note that "Sender" gets one very
> > trivial mention in mutt's manual (for tagging emails containing such).
> 
> I gather that the two lines above inserted into muttrc should tell 
> mutt who I am. But why out of the blue have they become necessary? And 
> without restarting anything they don't keep the online email tester 
> from saying that haines@histomat.net violates Protocol 521.5.5.1.

I don't know why you're suddenly sending blank FROMs. That would
depend on your answers. As for those rejected at the destination,
that might be down to them changing the checks they make on incoming
mail. That's something that people are tightening up on all the time.
Oh for the good old days!

If push comes to shove, AIUI you can force exim to write a fixed
MAIL FROM on outgoing emails with its -f option, which you'd set
in /etc/default/exim4. But there may be easier ways. I don't think
it's very straightforward to configure Debian's exim to send users'
and system's emails when the user is also trying to manipulate their
address as well. And it gets really hairy if you want to be able
to send and receive emails between machines on the home LAN as well.

PS I can't keep up with some of this thread.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#247669

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.

[toc] | [prev] | [next] | [standalone]

#247705

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.

[toc] | [prev] | [next] | [standalone]

#247711

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

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.14    axis.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 auser@acer.corp Thu Apr 28 11:37:06 2022
Return-path: <auser@acer.corp>
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 <auser@acer.corp>)
        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 <auser@acer>)
        id 1nk78b-0000HX-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: <E1nk78b-0000HX-6v@acer>
From: me <auser@acer.corp>
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-0000HX-6v <= auser@acer U=auser P=local S=370
2022-04-28 11:37:06 1nk78b-0000HX-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-0000HX-6v Completed

2022-04-28 11:37:06 1nk78c-0001yL-Bm <= auser@acer.corp H=(acer) [192.168.1.10] P=esmtp K S=559 id=E1nk78b-0000HX-6v@acer
2022-04-28 11:37:06 1nk78c-0001yL-Bm => auser <auser@axis> 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.

[toc] | [prev] | [next] | [standalone]

#247712

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.14    axis.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 auser@acer.corp Thu Apr 28 11:37:06 2022
> Return-path: <auser@acer.corp>
> 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 <auser@acer.corp>)
>         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 <auser@acer>)
>         id 1nk78b-0000HX-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 <auser@acer>".
I find that quite interesting, but you'd need more knowledge of exim
configuration than I possess to work out what happened there.

[toc] | [prev] | [next] | [standalone]

#247718

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.14    axis.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 auser@acer.corp Thu Apr 28 11:37:06 2022
> > Return-path: <auser@acer.corp>
> > 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 <auser@acer.corp>)
> >         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 <auser@acer>)
> >         id 1nk78b-0000HX-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 <auser@acer>".
> 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.

[toc] | [prev] | [next] | [standalone]

#247640

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 <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[toc] | [prev] | [next] | [standalone]

#247641

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
> 

[toc] | [prev] | [next] | [standalone]

#247516

On 2022-04-25, Haines Brown <haines@histomat.net> wrote:
>
> I placed these two lines in ~./muttrc/muttrc
>
>   set envelope_from_address=haines@histomat.net
>   set use_envelope_from=haines@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). 

[toc] | [prev] | [next] | [standalone]

#247518

On Mon 25 Apr 2022 at 12:04:55 (-0000), Curt wrote:
> On 2022-04-25, Haines Brown <haines@histomat.net> wrote:
> >
> > I placed these two lines in ~./muttrc/muttrc
> >
> >   set envelope_from_address=haines@histomat.net
> >   set use_envelope_from=haines@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.

[toc] | [prev] | [next] | [standalone]

#247520

On Mon, Apr 25, 2022 at 09:18:45AM -0500, David Wright wrote:
> On Mon 25 Apr 2022 at 12:04:55 (-0000), 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 <https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html>:

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

[toc] | [prev] | [next] | [standalone]

#247522

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 (-0000), 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 <https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html>:
> 
>   $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.

[toc] | [prev] | [next] | [standalone]

#247521

On Mon, Apr 25, 2022 at 09:18:45AM -0500, David Wright wrote:
> On Mon 25 Apr 2022 at 12:04:55 (-0000), Curt wrote:
> > On 2022-04-25, Haines Brown <haines@histomat.net> wrote:
> > >
> > > I placed these two lines in ~./muttrc/muttrc
> > >
> > >   set envelope_from_address=haines@histomat.net
> > >   set use_envelope_from=haines@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 

[toc] | [prev] | [next] | [standalone]

#247575

On 2022-04-24 23:30:34 -0400, Haines Brown wrote:
> I placed these two lines in ~./muttrc/muttrc
> 
>   set envelope_from_address=haines@histomat.net
>   set use_envelope_from=haines@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 <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[toc] | [prev] | [next] | [standalone]

#247577

On 2022-04-26, Vincent Lefevre <vincent@vinc17.net> wrote:
> On 2022-04-24 23:30:34 -0400, Haines Brown wrote:
>> I placed these two lines in ~./muttrc/muttrc
>> 
>>   set envelope_from_address=haines@histomat.net
>>   set use_envelope_from=haines@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.

[toc] | [prev] | [next] | [standalone]

#247502

Haines Brown <haines@histomat.net> 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

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

[toc] | [prev] | [next] | [standalone]

#247503

On Mon, 2022-04-25 at 10:16 +0900, 황병희 wrote:
> Haines Brown <haines@histomat.net> 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.

[toc] | [prev] | [next] | [standalone]

#247507

Dear Jim,

Jim Popovitch <jim@k4vqc.com> writes:

> On Mon, 2022-04-25 at 10:16 +0900, 황병희 wrote:
>> Haines Brown <haines@histomat.net> 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

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

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | linux.debian.user

csiph-web