Re: Why use an email client AND sendmail/popa3d - Does this avoid the hijack?
On Thu 26 Nov 2020 at 09:34:25 (+0000), Joe wrote:
> On Wed, 25 Nov 2020 21:57:10 -0600 David Wright wrote:
>
> > Perhaps the problem is similar to the one I had with this list
> > (hence the change I made above). What happened was that my posts'
> > Envelope-from (set to the same as my From address above) was being
> > changed by my mail hosting service to an address on their outgoing
> > mail gateway. AIUI Debian immediately tries to establish an email
> > connection to that address on port 25 to verify it exists, but the
> > outgoing gateway apparently is not an incoming mail receiver, and
> > is not listening on port 25. So Debian rejects the post.
> >
> There should/need be no Envelope-From header in an email as sent, it is
> inserted by the receiving SMTP server as a copy of the sending address
> as used in the SMTP transaction, something which is not a sent header
> and that would not otherwise be available to the end recipient.
When you say "no Envelope-From header", I guess your asking me to make
it clearer in my post that I'm not discussing the email headers at all,
but only the envelope. However, in order to find out what the Envelope-from
of an email was, you have to examine the headers for clues.
Exim uses the term Envelope-from, as seen in your own posts, and
I guess that the number of names "it" has been given reflects the
uses to which it's put. The wiki page lists: return path,
reverse path, envelope from, envelope sender, MAIL FROM, 5321-FROM,
return address, From_, Errors-to, etc [sic], and the page's own name:
Bounce address. The page continues:
"It is not uncommon for a single document to use several of these
names. All of these names refer to the email address provided with
the MAIL FROM command during the SMTP session.
Ordinarily, the bounce address is not seen by email users and,
without standardization of the name, it may cause confusion."
> An SMTP sending server does not need to also receive email. Large
> businesses often use separate servers for send and receive, and often
> contract out one or both functions to different companies e.g. mass
> mailers and spam cleaning services. It should not be assumed that the
> MX record for a domain matches its sending address.
Yes, that's the case here. AFAICT there are three hosts involved in
providing my service: an outgoing, an incoming, and the one hosting
my IMAP and SMTP servers. (There may be others involved in, say,
scanning that I don't know about.)
> What Debian's mail server might well do is to look up the sending
> server's HELO/EHLO, sending address and IP address in public DNS, and
> refuse or delay emails with missing or incorrect records. Exim4 by
> default has rules (thought not enabled by default) for checking these
> things with a view to refusing transactions with spammers.
Yes, some of that information may be difficult to control oneself
(I think you also said that), and it's not always clear exactly
how it was used (ie which bits did they look up, and where)
in order to accept or reject it. AFAICT, in my case, Debian
couldn't get a satisfactory response to its RCPT TO command to
what you've termed the "sending address" (which is what I've been
calling the Envelope-from).
I don't have any idea why the Envelope-from that I set should be
changed to something else in the transfer to bendel.debian.org,
so that's something for me to research when I have the time and
inclination. Debian-user is the only address where I have this
problem with submission. Contemporaneous postings to a gnu.org
list show no change in Envelope-from in the equivalent transfer
from my gateway to eggs.gnu.org, the list's incoming host, nor
even next transfer to lists.gnu.org, the list processor itself.
What's really difficult to tell is whether there's something in
the responses from Debian-user that's causing the change at my
gateway. For example, there may be some unseen exchanges between
the two ends in connection with greylisting.
Cheers,
David.
Reply to: