Re: [mailop] Musings on Mail Service Operators
On 2022-02-02 at 21:31 -0600, Scott Mutter wrote: > Email - as we know it - should have been dead years ago. But instead > we keep adding band-aid after band-aid after band-aid to the system. Maybe what you call a band-aid was actually preferable? > Why is it impossible to take a look at what Instant Messaging > protocols, SMTP, SMS do that make them successful and then blend > those together into a new "email-like" system? https://xkcd.com/927/ > > I'm not going to pretend to know what the ultimate solution might > be. One of the major issues with email is the address spoofing that > goes on. Maybe a spoofed address doesn't authenticate with SPF or > DKIM... but that only works if EVERYONE else uses SPF and DKIM... > that's the bandaid. Instant messaging and SMS can't as easily be > spoofed, they may be fake but senders have to register on the > platform in some way (be it a Facebook account, Twitter account, > phone number, etc). Would more need to be done to lock this down? > Absolutely. But it's at least A obstacle that potential abusers have > to overcome. Email doesn't have that. We have seen *a lot* of SMS spoofing (Poland, UK, you're not alone!). Say you receive a SMS with a spoofed sender of "MailopBank" containint a phishing link. Your phone will fill this with all the other (legitimate) SMS you received with a sender of "MailopBank". It's not really the phone fault. It has no other information to tell one "MailopBank" from the other (one might perhaps blame being able to use text as SMS senders). It has no sending IP, no SPF, no DMARC… The reason SMS is still in use is because it provides the lowest level technology, for sending a code to a phone user, be that a flip phone or the latest smartphone release. > Email was first invented in 1971 - that's over 50 years ago. We've > learned a lot about how people tend to use email and how people tend > to abuse email within the past 50 years. Instead of adding new > constructs to email. Why not invent a new, more modern email > alternative? Something that takes a lot of what we've learned from > email usage over the years, what we've seen in instant messaging, > SMS, and other computer communication protocols and builds on that > from the ground up? Wouldn't that be better than constantly adding > band-aids to email/SMTP to fix problems that pop up? At which point does a system become "a more modern alternative"? We could build an email system that used protobufs rather than SMTP, for the sake of making something new, but if it doesn't provide an improvement over SMTP, it's better to use the extensibility mechanism of SMTP. Compatibility is very important. If your new system can be gradually rolled out, and is able to receive messages from the existing systems, that will be preferable. > I'm not a huge fan of mailing lists or distributed mailings (forums > accomplish the same thing with less of the hassle of email > deliverability concerns). So you are advocating for a better email which is able to do less things than mail? Plus, a mailing list is just the ability of sending to multiple users. You could easily have a WhatsApp mailing list bot replacing groups. > Not a huge fan of automatic email forwarders/redirects, which tend to > break SPF and DKIM. Maybe things like these don't need to be > allowed? But the users *really* want to have all their messages on the same mailbox, even if they could easily access the other mailbox. Otherwise we wouldn't need email forwarding. > Yet those platforms don't seem to have an issue in getting people to > use them. Why couldn't a properly reimagined email replacement do > the same thing? And email don't have an issue in getting people using it.* The issues lie on a lower level, like not receiving /certain/ messages, or in the management by some clients, which is interface (you will however face some problems in getting a mail client for your new protocol that is as good as every existing one for "traditional" mail). * Many people don't actually know how to *properly* use email, but that's a slightly different issue. They manage to "use" it. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Musings on Mail Service Operators
On 2/2/2022 10:31 PM, Scott Mutter via mailop wrote: > A lot of the issues stem from the way IT managers, and maybe technology > managers in general bathe in arrogance. "There's no such thing as a > good idea, unless it is *my* idea." It's easier to get blood out of a > stone than for someone in IT to admit that someone else's approach to > something has merit. > > Email - as we know it - should have been dead years ago. > [snip] But it's not dead. Maybe there's a reason for that. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Musings on Mail Service Operators
On 3/2/22 13:59, Andrew C Aitchison via mailop wrote: To me any system that aims to replace email must be based on pushing messages and have a distributed nature. This means that deliverability issues are an inherent risk, in a way that pulling messages from a central/unified service can avoid. Sounds like the fediverse. OStatus (diaspora) and ActivityPub (mastodon) being the relevant protocols. Activitypub is a promising protocol built to do what you describe, albeit aimed at social networking. The problem with that is that they stumbled onto the difficulties email is facing, too: spamming, spoofing, access control and tendency to centralize. They're now trying to get groups implemented but there is no formal protocol oversight so it's the wild wild west. The initial protocol design has some flaws that don't help, either. Seems like there are unavoidable issues in the task itself, not the technology or governance used to implement the task. IMHO if someone wanted to decentralize messaging the "email way" but be a more modern alternative, it would be via an improved ActivityPub-like protocol. --GM ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Musings on Mail Service Operators
> Email - as we know it - should have been dead years ago. But instead we > keep adding band-aid after band-aid after band-aid to the system. It's not that people haven't tried. And not all of them have been wholly unequipped to do so, either. You are of course aware of Professor Dan J. Bernstein's Internet Mail 2000, for example. -- Atro Tossavainen, Chairman of the Board Infinite Mho Oy, Helsinki, Finland tel. +358-44-5000 600, http://www.infinitemho.fi/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Musings on Mail Service Operators
Dnia 3.02.2022 o godz. 11:59:42 Andrew C Aitchison via mailop pisze: > > Having said that, my understanding is that deliverability is also an > issue in Facebook. If some of my posts are not shown to some of my friends, > without them telling Facebook that they did not want to see those messages, > that is a deliverability fail, but since I don't get a failure message > I wont know to complain about the system. Indeed, this is a well known issue on Facebook and other social media platforms. It even has got its own name: "shadow ban". If you are "shadow banned", then you can post your messages, but others won't see that you posted them, unless they specifically check your profile. Some even say that "shadow ban" is not a bug, but a "hidden feature" of Facebook etc. algorithms that is used more and more often. Many people complain about Facebook cutting down visibility of their posts and suggesting use of paid promotion options to increase it. It is a very similar situation to what for example I experience with Gmail, with my messages being constantly sent to Spam folder of Gmail recipients (I don't experience this with any other receiving system, eg. Outlook or Yahoo, only with Gmail), so the recipients don't see them unless I inform them via other means that I have sent them a message (or they look into Spam folder by themselves, which we all know people don't do). It is like I am "shadow banned" on Google. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Musings on Mail Service Operators
On Wed, 2 Feb 2022, Scott Mutter via mailop wrote: A lot of the issues stem from the way IT managers, and maybe technology managers in general bathe in arrogance. "There's no such thing as a good idea, unless it is *my* idea." It's easier to get blood out of a stone than for someone in IT to admit that someone else's approach to something has merit. Email - as we know it - should have been dead years ago. But instead we keep adding band-aid after band-aid after band-aid to the system. Why is it impossible to take a look at what Instant Messaging protocols, SMTP, SMS do that make them successful and then blend those together into a new "email-like" system? I'm not going to pretend to know what the ultimate solution might be. One of the major issues with email is the address spoofing that goes on. Maybe a spoofed address doesn't authenticate with SPF or DKIM... but that only works if EVERYONE else uses SPF and DKIM... that's the bandaid. Instant messaging and SMS can't as easily be spoofed, they may be fake but senders have to register on the platform in some way (be it a Facebook account, Twitter account, phone number, etc). Would more need to be done to lock this down? Absolutely. But it's at least A obstacle that potential abusers have to overcome. Email doesn't have that. Similar to what Jaroslaw described in Poland, here in the UK caller ID spoofing is a significant fraud problem, not sure whether this is SMS or just voice. There is talk of a technical fix but it will take a few years to roll it out ... --- To me any system that aims to replace email must be based on pushing messages and have a distributed nature. This means that deliverability issues are an inherent risk, in a way that pulling messages from a central/unified service can avoid. Having said that, my understanding is that deliverability is also an issue in Facebook. If some of my posts are not shown to some of my friends, without them telling Facebook that they did not want to see those messages, that is a deliverability fail, but since I don't get a failure message I wont know to complain about the system. --- Maybe things like these don't need to be allowed? Unlike you, I prefer mailing lists to fora/forums. There may be features of email that can be dropped, but which ones can we drop without reducing the take-up and stopping the new system from reaching critical mass ? --- I just think it's time we stop worrying about how we're going to carry email over into the 2030s, 2040s, 2050s and on. And instead start looking at how we can create an email replacement from the ground up. Too many people invested in email, you say? Email was around before SMS, before Facebook, before whatever other communication medium kids are using these days. Yet those platforms don't seem to have an issue in getting people to use them. Why couldn't a properly reimagined email replacement do the same thing? SMS piggy-backed on the back of mobile voice. The others are all centralised services; I suspect that it is harder for a distributed system to build market share, yet being distributed is one of email's distinguishing features. -- Andrew C. Aitchison Kendal, UK and...@aitchison.me.uk ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Musings on Mail Service Operators
Dnia 2.02.2022 o godz. 21:31:04 Scott Mutter via mailop pisze: > Instant > messaging and SMS can't as easily be spoofed, they may be fake but senders > have to register on the platform in some way Here in Poland we are now right in the middle of a real-life "experiment" that will probably show how telecoms, and people in general, will cope with phone number spoofing. Since months there is an ongoing activity of scammers who call random people spoofing real bank phone numbers, trying to trick them into installing remote access software on their devices that will the scammers give access to their bank account. There is also a massive wave of spoofed SMS posing as messages from delivery companies, electricity providers etc. informing about some payment being due and with a link leading to fake payment gateways set up to intercept bank account credentials. Just recently something new has appeared: someone calls politicians, celebrities and other publicly known persons, using spoofed phone numbers of public institutions or other politicians, celebrities etc., insulting them, issuing death threats, or "informing" them (posing as eg. a policeman) that someone of their family has died, etc. We will see where this will lead to... -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Musings on Mail Service Operators
On 2/2/2022 7:31 PM, Scott Mutter via mailop wrote: Why is it impossible to take a look at what Instant Messaging protocols, SMTP, SMS do that make them successful and then blend those together into a new "email-like" system? Because replacing widespread systems is vastly harder than one would intuit. Staying with email as the focus, there was early desire to expand from simple text to support multimedia. And there were multiple efforts, from the latter 1970s onward. What succeeded was not replacing existing email but rather adding to it, with an optional layer -- MIME. I'm not going to pretend to know what the ultimate solution might be. One of the major issues with email is the address spoofing that goes on. It is popular to think that this can be solved, but the reality has so far demonstrated that what cannot be solved in the real (wet) world cannot be solved on the Internet. And spoofing, or the like, is part of that wet world, as well as the digital one. The schemes people propose to 'fix' spoofing wind up working less well than hoped, such as by not scaling adequately, or by having collateral downsides. Would more need to be done to lock this down? Absolutely. But it's at least A Locking down tightly has downsides, as well as benefits. Email was first invented in 1971 - that's over 50 years ago. We've This being a list for technicians, forgive me for noting that Ray Tomlinson did NOT invent email in 1971. Email dates back at least to the mid-1960s. Tom van Vleck is the most likely candidate for bragging rights. What Ray did was to creat /networked/ email. And, of course, choose the at-sign as the mailbox@host syntax. Why not invent a new, more modern email alternative? One of the wonders of the Internet is that you are free to go do that. Create it. Deploy it. Develop support for it. If you can. Something that takes a lot of what we've learned from email usage over the years, what we've seen in instant messaging, SMS, and other computer communication protocols and builds on that from the ground up? Wouldn't that be better than constantly adding band-aids to email/SMTP to fix problems that pop up? Possibly, but also apparently not. It is spectacularly difficult, risky and expensive to create a new, distributed infrastructure. By contrast, it is only modestly difficult to add to an existing infrastructure (if one is very careful.) MIME managed to turn text email into multimedia without modifying the global email infrastructure at all. Only the author and the recipients had to adopt it. This is astonishingly cheaper than if they/we had had to create an entire, global infrastructure for multimedia mail. There will come a point at which there is a strong desire to add a feature that we can't figure out how to add to the existing email service. But over those 50 years, we haven't hit that limit yet, in spite of so many changes needed. And don't be afraid to say no when it comes to adding every little feature into this protocol. I'm not a huge fan of mailing lists or distributed mailings (forums accomplish the same thing with less of the hassle of email deliverability concerns). Centralized platforms are much easier to develop and run than distributed ones, of course. But they also are a pain, moving operational hassles to users, when one has to flit from one to the next, checking for new postings. So, again: tradeoffs. d/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Musings on Mail Service Operators
A lot of the issues stem from the way IT managers, and maybe technology managers in general bathe in arrogance. "There's no such thing as a good idea, unless it is *my* idea." It's easier to get blood out of a stone than for someone in IT to admit that someone else's approach to something has merit. Email - as we know it - should have been dead years ago. But instead we keep adding band-aid after band-aid after band-aid to the system. Why is it impossible to take a look at what Instant Messaging protocols, SMTP, SMS do that make them successful and then blend those together into a new "email-like" system? I'm not going to pretend to know what the ultimate solution might be. One of the major issues with email is the address spoofing that goes on. Maybe a spoofed address doesn't authenticate with SPF or DKIM... but that only works if EVERYONE else uses SPF and DKIM... that's the bandaid. Instant messaging and SMS can't as easily be spoofed, they may be fake but senders have to register on the platform in some way (be it a Facebook account, Twitter account, phone number, etc). Would more need to be done to lock this down? Absolutely. But it's at least A obstacle that potential abusers have to overcome. Email doesn't have that. But as others have said there are definitely constraints to these instant messaging and SMS protocols: size, content, searchability, etc. These are things that regular email does well. Email was first invented in 1971 - that's over 50 years ago. We've learned a lot about how people tend to use email and how people tend to abuse email within the past 50 years. Instead of adding new constructs to email. Why not invent a new, more modern email alternative? Something that takes a lot of what we've learned from email usage over the years, what we've seen in instant messaging, SMS, and other computer communication protocols and builds on that from the ground up? Wouldn't that be better than constantly adding band-aids to email/SMTP to fix problems that pop up? And don't be afraid to say no when it comes to adding every little feature into this protocol. I'm not a huge fan of mailing lists or distributed mailings (forums accomplish the same thing with less of the hassle of email deliverability concerns). Not a huge fan of automatic email forwarders/redirects, which tend to break SPF and DKIM. Maybe things like these don't need to be allowed? I just think it's time we stop worrying about how we're going to carry email over into the 2030s, 2040s, 2050s and on. And instead start looking at how we can create an email replacement from the ground up. Too many people invested in email, you say? Email was around before SMS, before Facebook, before whatever other communication medium kids are using these days. Yet those platforms don't seem to have an issue in getting people to use them. Why couldn't a properly reimagined email replacement do the same thing? On Wed, Feb 2, 2022 at 5:52 PM Jaroslaw Rafa via mailop wrote: > Dnia 2.02.2022 o godz. 18:26:38 yuv via mailop pisze: > > > > Either it will go the other way, or folks will move away from email all > > together. I am moving away. I miss the ability to store away in > > Maildir format my correspondence and to look back in the archives to > > Eudora times and earlier, but since I made the decision to prefer other > > methods of electronic communication over email, I feel much better. > > Just out of curiosity: what better methods of communication did you find? I > can't find any. Text messages via phone won't do, any IM-type programs (be > it Facebook Messenger, Signal, Telegram or anything else) won't do either. > They are unsearchable, unmanageable, limited in size and in the type of > content you can send, plus there is the mentioned "walled gardens" issue, > that is, (except of text messages) you have to use the same service than > the > person you try to communicate with. > > For me, still nothing beats e-mail - even with all the deliverability > problems... > -- > Regards, >Jaroslaw Rafa >r...@rafa.eu.org > -- > "In a million years, when kids go to school, they're gonna know: once there > was a Hushpuppy, and she lived with her daddy in the Bathtub." > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop > ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Musings on Mail Service Operators
Dnia 2.02.2022 o godz. 18:26:38 yuv via mailop pisze: > > Either it will go the other way, or folks will move away from email all > together. I am moving away. I miss the ability to store away in > Maildir format my correspondence and to look back in the archives to > Eudora times and earlier, but since I made the decision to prefer other > methods of electronic communication over email, I feel much better. Just out of curiosity: what better methods of communication did you find? I can't find any. Text messages via phone won't do, any IM-type programs (be it Facebook Messenger, Signal, Telegram or anything else) won't do either. They are unsearchable, unmanageable, limited in size and in the type of content you can send, plus there is the mentioned "walled gardens" issue, that is, (except of text messages) you have to use the same service than the person you try to communicate with. For me, still nothing beats e-mail - even with all the deliverability problems... -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Musings on Mail Service Operators
On Wed, 2022-02-02 at 11:20 +0100, Jaroslaw Rafa via mailop wrote: > Dnia 2.02.2022 o godz. 10:47:33 Carsten Schiefner via mailop pisze: > > I start to earnestly wonder when folks [...] > > will attempt to regain knowledge to run their own and small-scale > > mail systems again > > I think it will rather go the other way Probably. Either it will go the other way, or folks will move away from email all together. I am moving away. I miss the ability to store away in Maildir format my correspondence and to look back in the archives to Eudora times and earlier, but since I made the decision to prefer other methods of electronic communication over email, I feel much better. I still owe an answer to Bill about Walled Gardens. It will come, eventually, maybe, if it was not caught in the spam filter. -- Yuval Levy, JD, MBA, CFA Ontario-licensed lawyer ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Musings on Mail Service Operators
On 02.02.2022 11:20, Jaroslaw Rafa via mailop wrote: Dnia 2.02.2022 o godz. 10:47:33 Carsten Schiefner via mailop pisze: Having now also read Michael's call for O365 assistance, I start to earnestly wonder when folks are tired enough of having put their email fate into the hands of a few mega-large Mail Service Operators with kafkaesque and fully intransparent processes and instead will attempt to regain knowledge to run their own and small-scale mail systems again as they realize that proper and flawless electronic communication is part of their core business functions - whatever that business exactly might be. I think it will rather go the other way, because of the scale of those mega-large mail operators. Because of their scale, the average user's perception is that "almost everybody" is using them, so if somebody has problems with delivering mail to them, something must be wrong with the sender, and not with those large operators. They are "too big to be wrong". For the users using them the solution is simple: if you have problems delivering mail to the large operator, you should switch to that operator as well, instead of using some "unknown mail service". Then you will have no problems. And that's exactly what those big operators want... That unfortunately makes quite some sense to me, too, Jaroslaw. And it appears to be a classic perpetrator/victim reversal wrt. to the perception of the public... :-/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Musings on Mail Service Operators
Dnia 2.02.2022 o godz. 10:47:33 Carsten Schiefner via mailop pisze: > Having now also read Michael's call for O365 assistance, I start to > earnestly wonder when folks are tired enough of having put their > email fate into the hands of a few mega-large Mail Service Operators > with kafkaesque and fully intransparent processes and instead will > attempt to regain knowledge to run their own and small-scale mail > systems again as they realize that proper and flawless electronic > communication is part of their core business functions - whatever > that business exactly might be. I think it will rather go the other way, because of the scale of those mega-large mail operators. Because of their scale, the average user's perception is that "almost everybody" is using them, so if somebody has problems with delivering mail to them, something must be wrong with the sender, and not with those large operators. They are "too big to be wrong". For the users using them the solution is simple: if you have problems delivering mail to the large operator, you should switch to that operator as well, instead of using some "unknown mail service". Then you will have no problems. And that's exactly what those big operators want... -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
