Re: et.al.
I think this got attached to the wrong subthread.
On Tue 08 Oct 2019 at 09:08:40 (+0200), Thomas Schmitt wrote:
> i wrote:
> > > I wonder whether my mail provider would allow me to send via SMTP
> > > MAIL FROM:<scdbackup@gmx.net>
> > > From: "Somebody Else" <totally@fake.com>
>
> David Wright wrote:
> > It's fairly easy to find out by trying it out,
>
> I have the technical means but not the courage to challenge my provider.
>
> > Perhaps not as easy as it was,
> > because unencrypted telnet has all but gone.
>
> A few years ago i had to add stunnel to my mail sender tool chain.
>
> > $ openssl s_client -starttls smtp -crlf -connect smtp.some.submission.host.tld:12345
>
> SMTP by hand. Impressive.
Not really. After all, S stands for Simple. It's really not very
different from my interactive Fortran programs from the 1970s,
or the Adventure game from the same era.
https://www.filfre.net/wp-content/uploads/2012/11/think.png
> I would rather tinker with my SMTP sender.
I find exim a lot more complicated to drive. There's an open thread
here that I ought to close: the one where I was trying to set up
intra-LAN emails at home. Having solved it, I ought to post how.
> > ehlo wren.corp
>
> That would be the link between mail and subscription, according to Brian's
> theory (if i understand it correctly).
> Is "....corp" in any way part of your subscription ?
Absolutely not! No, it's just the domain name of my LAN at home. In
my employment days, it was an Internet-resolvable hostname, but
those days are long gone, and all my pretty hostnames are now
corporate gobbledegook.
> The mail, to which this is a reply, has:
> > Received: from david by ....corp with local (Exim 4.92)
> > (envelope-from <deblis@lionunicorn.co.uk>)
> > id 1iHhck-00016w-Lc; Tue, 08 Oct 2019 00:01:26 -0500
>
> In my mailbox the "(envelope-from <...>)" are rather rare on debian-user.
> Most frequent they are inside the gnu.org mail server network.
> About any mail on their lists has them in the Receive: headers which
> gnu.org servers add.
> But Brian and you get them added to the most early "Received:".
Yes, several systems I use have different ways of displaying the
envelope ± HELO along the way at different points. Sometimes
they're labelled smtp.mailfrom and smtp.helo: eg if I send mails
directly to myself (at my real domain).
And IIUI it's the envelope that actually determines where the email
goes, not the To: in the email, though I assume my exim determines
the former from the latter.
(One of the problems in the thread I mentioned is making sure that
exim doesn't rewrite *all* my LAN domain names into my Internet
domain name, but only the emails I'm sending to the ISP's smarthost.)
> > I see lots of DKIM stuff in your emails
>
> In the past i sent mails to the receivers directly. But more and more
> refused on my self-made SMTP. So i went back to the end-user way of
> handing my outgoing mail to my mail provider so that all that fancy
> header stuff gets added.
> Then came end-user encryption (whatever this shall bring as benefit)
> which i could counter by stunnel(8).
>
> Let's see how long they allow me to tickle their servers by hand.
Yes, I don't run my own mail server as it seems quite tricky and
something that you have to keep exactly correct all the time, like
any system that's operating in Real Time—you don't want to drop the
ball just when an importent email arrives.
> > There is no inherent relationship between either "reverse" (from
> > MAIL, SAML, etc., commands) or "forward" (RCPT) addresses in the SMTP
> > transaction ("envelope") and the addresses in the header section.
> > (RFC 5321.)
>
> But the "Received: ...(envelope-from" gesture seems to try to establish
> such a relationship.
> It would be interesting to learn why Exim (or something else ?) adds
> this info.
Because the servers en route to the email's destination never look at
the Header and Body, but only the envelope, AIUI.
> In your case the addresses in "From:" and "(envelope-from"
> are the same. This kills my theory about the reason why Brian's mails
> have "(envelope-from".
AIUI exim rewrites my From: name@wren.corp into name@lionunicorn… and
then copies that into the envelope: I don't try to interfere with the
copying, but I could if my ISP accepts the result. As a 587 submission
port, they might do checking that a 25 transfer port doesn't do.
> > I've always assumed the envelope from is generated from the 'mail
> > from' line, and that the envelope should reach the Debian list
> > processing system unchanged.
>
> I never bothered to find out whether the wide-world mail servers use
> any other protocol or extra SMTP commands to organize their network.
> But if they use RFC5321 like us commoners then your theory looks
> plausible.
>
> Only that Brian stated not to use his subscribed address in "MAIL FROM"
> and not to see it in "(envelope-from ".
> Maybe i got him wrong ?
> (Keeping semi-private mail-addresses out of the list archives might have
> confused our conversation.)
Yes, though I tried guessing in this subthread, but no reply yet.
> > I've always assumed that what is in parentheses is all "noise" as far
> > as SMTP is concerned, like that Exim version number, the envelope-from
> > and, in your email for example, (Client did not present a certificate).
>
> The specs seem to support your assumption. RFC5322 says that the meaning
> of the tokens in "Received:" would be discussed in RFC5321. But there i
> fail to find any tangible info beyond the obvious meaning of "Received:".
>
> "(Client did not present a certificate)" is possibly a future threat for me.
> Why does one have to be a cryptography expert to send a mail ? Grrr...
When I send the openssl, I get back a certificate from Atlanta or
Manchester which is meant to tell me, I assume, that I'm connected to
whomever I think I ought to be. Presumably my ISP could use
out-of-band information to determine who *I* am, but my email host
(to whom I can also submit emails) couldn't do that. In either case,
I guess I could use a certificate (but I don't own one), so I have to
authenticate with them by using a name/password combination. That's
what the 'auth plain' string is doing. So the cryptography is still
there, but done by openssl -starttls.
Cheers,
David.
Reply to: