[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: et.al.



Hi,

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.
I would rather tinker with my SMTP sender.


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

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


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


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


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


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


Have a nice day :)

Thomas


Reply to: