> but when I use Mail.app to send an email, I am the one doing the emailing, not the Google SMTP server acting as a mail transfer agent (MTA)
You seem to be confusing the MSA (https://en.wikipedia.org/wiki/Mail_submission_agent) and the MTA. If today your MUA (Mail.app) tried to connect to the destination mail host via SMTP directly it would get rejected. Some early MUAs did actually do that, but today almost all email gets relayed via an MSA and one or more MTAs.
As the Wikipedia article says, "Many MTAs perform the function of an MSA as well." I was looking at the article about MTAs [0], in which the diagram does not bother showing the sending MUA connecting to a distinct MSA. My MUA would not be rejected by the destination host if the recipient uses the same host as me.
> My MUA would not be rejected by the destination host if the recipient uses the same host as me.
Your MUA would be rejected if it acted as an MTA and connected on port 25 without authenticating. "Using the same host as me" is the case because the mail server knows that it is "your host" because your MUA is connecting to your email server's MSA using SMTP AUTH on port 587 or 465.
Well now you're moving goalposts, qualifying connections by port and authentication. I'm sure what you write is true of most ISPs and major email service providers but there are still SMTP servers in the world that don't require all MUAs to make authenticated connections; there's at least one at my university.
They don't require authentication because they only accept relay requests from within the university network. Otherwise they'd be an open relay, and those tend to relay spam as soon as spammer spot them, then they get blacklisted by most spam filters. In any case, this doesn't affect my main point: by using those, you still don't send your email yourself.
In my book, "sending your own email" means you operate your own mail server, without using any third party relay (not Gmail's, not your ISP's).
I'm personally halfway there: I have root access to a virtual machine on the cloud (gandi.net), and configured it to relay my email for me. Next step would be to have physical control, but I kinda abandoned that idea when I learned that residential IPs are blacklisted (Hotmail even made it an explicit policy, it won't even appear in the recipient's spam folder).
If you use Gmail via webmail at https://mail.google.com or have a MUA like smtpmail.el in Emacs connect to smtp.gmail.com, Gmail is still sending your mail.
We trust the postal office to act as a reliable dumb pipe. Most email services are far from that: they filter inbound email in a way you have little control of. They spy inbound and outbound mail, and use that information to send you ads.
Also, they control your right to send and receive email: if your account is terminated for some reason (they reserve the right to, blah, blah), you cannot move to a new provider, or redirect inbound mail or nothing: they own your email address.
I mean, if you want to make the point that e-mail is not secure, you can say "e-mail is not secure." That's a statement that actually makes sense. Your false pedantry isn't convincing anyone to agree with you, it just makes you sound like a crackpot.
Oh, it's much worse than "email is insecure". It's more like "somebody else controls your email, and they don't have your best interest in mind". What did you think Alphabet was, a charity?
Besides, there's more to it than (in)security. For instance, what happens to your various accounts tied to your email if your account gets terminated? You will not be able to redirect your incoming emails, and notifying your friends will be difficult if you relied on the web interface's address book.
Also, it's a hole ecosystem: if you use a big webmail, then you allow your provider to spy on everyone you exchange emails with. If you have the means to avoid those, it is your responsibility to do so. Surely you don't like inflicting this kind of spying on your friends, do you?
So far, the only reliable way to have proper control over our own email is to control our own domain name, and operate our own mail server. Or at least use small, trustworthy providers. In other words, "send our own email".
It's intellectual property/monopoly all over again. One will chose the terms that suits one's side of the debate. I side for privacy, security, and reliability; and argue that webmail providers do not provide any of them. This thread is the first time my "sending one's own email" wording hasn't been an unmitigated success.
Virtually everyone is clueless. I mean it, most people don't know the first thing about computers, or networks, or how data flows when they send an email or even read a web page. Many others underestimate the actual price they pay for their supposedly free web mail.
The issue here is one of control: relays can basically read every mail they relay, and the likes of Gmail do. Spying on you is how they make money. No targeted ad would be possible otherwise. And the automation only makes it worse (because it scales, and can be repurposed).
And the user can do nothing about it. That total lack of control is why I maintain they do not, in fact, send their own email. Now there's PGP, but that would look conspicuous. If everyone had their own mail server, TLS alone would provide pretty good security.
What angers me the most is, even I don't have a choice: most of my friends use a big webmail provider, which invades my privacy whenever I communicate with them. This would never happen if we all had our own mail servers.
> Now there's PGP, but that would look conspicuous.
Also, it doesn't hide the authenticated user, envelope mail from or envelope rcpt to values used in the message, unless, like you said, the sender and recipient(s) are using their own SMTP servers.
I remember when everyone could have their very own mail servers. Never since have I been offered such a vast and varied selection of ways to increase the size of my penis.
Perhaps I am misunderstanding you, but while it is certainly uncommon, it is absolutely possible to directly deliver mail to a recipient's SMTP server. In many cases, this can be done without any authentication whatsoever.
I run my own mail server. When I send an email via the web interface, would you not agree the MUA is attempting to directly connect to the destination host?
Depending on different factors, it may be classified as spam by the recipient, but from a reputable IP address it shouldn’t normally be rejected outright. Of course there are other factors like SPF, greylisting, etc... but email can be directly delivered.
If you send from non-SPF listed IPs you will get rejected in many places and most likely marked as spam in those you don't. SPF particularly and DKIM and other anti-spam measure are in wide spread use and enforced by the receiving SMTP server either directly or via spam scoring system rules.
You seem to be confusing the MSA (https://en.wikipedia.org/wiki/Mail_submission_agent) and the MTA. If today your MUA (Mail.app) tried to connect to the destination mail host via SMTP directly it would get rejected. Some early MUAs did actually do that, but today almost all email gets relayed via an MSA and one or more MTAs.