Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #236255 > unrolled thread

Messed up Email

Back to article view | Back to linux.debian.user

Contents

  Messed up Email "Gary L. Roach" <garyroach719@gmail.com> - 2021-06-22 01:30 +0200
    Re: Messed up Email Mark Allums <mark@allums.email> - 2021-06-22 06:10 +0200
    Gmail's special approach to Email [was: Re: Messed up Email] Andrei POPESCU <andreimpopescu@gmail.com> - 2021-06-22 10:50 +0200
      Re: Gmail's special approach to Email [was: Re: Messed up Email]  (SOLVED) "Gary L. Roach" <garyroach719@gmail.com> - 2021-06-22 22:20 +0200
    Re: Messed up Email Brad Rogers <brad@fineby.me.uk> - 2021-06-22 12:40 +0200
      Re: Messed up Email Richard Owlett <rowlett@cloud85.net> - 2021-06-22 13:10 +0200
        Re: Messed up Email Gene Heskett <gheskett@shentel.net> - 2021-06-22 13:20 +0200
          Re: Messed up Email The Wanderer <wanderer@fastmail.fm> - 2021-06-22 13:40 +0200
            Re: Messed up Email Richard Owlett <rowlett@cloud85.net> - 2021-06-22 13:50 +0200
          Re: Messed up Email Joe <joe@jretrading.com> - 2021-06-22 16:50 +0200
      Re: Messed up Email Brian <ad44@cityscape.co.uk> - 2021-06-22 20:40 +0200
        Re: Messed up Email Tixy <tixy@yxit.co.uk> - 2021-06-22 20:50 +0200
          Re: Messed up Email Brian <ad44@cityscape.co.uk> - 2021-06-22 21:00 +0200
        Re: Messed up Email Brad Rogers <brad@fineby.me.uk> - 2021-06-22 21:10 +0200
          Re: Messed up Email Brian <ad44@cityscape.co.uk> - 2021-06-22 21:40 +0200
        Re: Messed up Email Michael Grant <mgrant@grant.org> - 2021-06-23 14:00 +0200
          Re: Messed up Email Brian <ad44@cityscape.co.uk> - 2021-06-23 21:30 +0200
            Re: Messed up Email Brian Thompson <bthompson.deb@gmail.com> - 2021-06-23 23:20 +0200
          Re: Messed up Email Andrei POPESCU <andreimpopescu@gmail.com> - 2021-06-23 23:00 +0200
            Re: Messed up Email Michael Grant <mgrant@grant.org> - 2021-06-23 23:20 +0200
              Re: Messed up Email Andrei POPESCU <andreimpopescu@gmail.com> - 2021-06-24 00:30 +0200
                Re: Messed up Email Celejar <celejar@gmail.com> - 2021-06-24 20:10 +0200
                  Re: Messed up Email Dan Ritter <dsr@randomstring.org> - 2021-06-24 20:20 +0200
                    Re: Messed up Email Andrei POPESCU <andreimpopescu@gmail.com> - 2021-06-26 12:40 +0200
                      Re: Messed up Email Andrei POPESCU <andreimpopescu@gmail.com> - 2021-06-26 13:20 +0200
                        Re: Messed up Email Brian <ad44@cityscape.co.uk> - 2021-06-26 15:10 +0200
                          Re: Messed up Email Andrei POPESCU <andreimpopescu@gmail.com> - 2021-06-26 16:10 +0200
                            Re: Messed up Email Celejar <celejar@gmail.com> - 2021-06-27 17:40 +0200
                      Re: Messed up Email Dan Ritter <dsr@randomstring.org> - 2021-06-26 13:50 +0200
                        Re: Messed up Email Andrei POPESCU <andreimpopescu@gmail.com> - 2021-06-26 16:00 +0200
                          Re: Messed up Email Celejar <celejar@gmail.com> - 2021-06-27 18:00 +0200
                            Re: Messed up Email Andrei POPESCU <andreimpopescu@gmail.com> - 2021-06-28 09:30 +0200
                        Re: Messed up Email Celejar <celejar@gmail.com> - 2021-06-27 17:50 +0200
                      Re: Messed up Email Celejar <celejar@gmail.com> - 2021-06-27 17:30 +0200
                        Re: Messed up Email Andrei POPESCU <andreimpopescu@gmail.com> - 2021-06-28 08:40 +0200
                  Re: Messed up Email Brian <ad44@cityscape.co.uk> - 2021-06-24 22:10 +0200
                    Re: Messed up Email Celejar <celejar@gmail.com> - 2021-06-25 00:50 +0200
                      Re: Messed up Email Brian <ad44@cityscape.co.uk> - 2021-06-25 20:10 +0200
                        Re: Messed up Email Celejar <celejar@gmail.com> - 2021-06-25 20:50 +0200
                        Re: Messed up Email Gene Heskett <gheskett@shentel.net> - 2021-06-26 04:40 +0200
                          Re: Messed up Email John Hasler <john@sugarbit.com> - 2021-06-26 15:20 +0200
                        Re: Messed up Email Andrei POPESCU <andreimpopescu@gmail.com> - 2021-06-26 12:10 +0200
                        Re: Messed up Email Brian <ad44@cityscape.co.uk> - 2021-06-26 14:00 +0200
                  Re: Messed up Email Andrei POPESCU <andreimpopescu@gmail.com> - 2021-06-26 12:20 +0200
                    Re: Messed up Email Celejar <celejar@gmail.com> - 2021-06-27 17:20 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#236393

[Multipart message — attachments visible in raw view] — view raw

On Mi, 23 iun 21, 17:12:07, Michael Grant wrote:
> > Apparently the lines are blurry enough for you to include Signal in that 
> > list.
> 
> Why?  Not blurry at all.  Signal is just as closed a system as
> WhatsApp.  Maybe more private, but unless you know something I don't,
> Signal doesn't talk to anything other than other Signal.  Puppeted
> bridges are not interoperability, as far as I am aware, all users
> still need to be on Signal.

You seem to be using a completely different meaning of 'proprietary' (no 
federation) than I do (closed source software, proprietary protocol that 
must be reversed engineered, patents, etc.).
 
> You'll notice that I didn't put Matrix on that list.  One day there
> will be multiple Matrix servers and clients and it's not dependent on
> any single company's infrastructure.

One day? There are already 3 clients in Debian stable, and there's at 
least matrix.debian.social ;)

(or did you mean server software?)

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#236426

On Thu, 24 Jun 2021 01:25:37 +0300
Andrei POPESCU <andreimpopescu@gmail.com> wrote:

> On Mi, 23 iun 21, 17:12:07, Michael Grant wrote:
> > > Apparently the lines are blurry enough for you to include Signal in that 
> > > list.
> > 
> > Why?  Not blurry at all.  Signal is just as closed a system as
> > WhatsApp.  Maybe more private, but unless you know something I don't,
> > Signal doesn't talk to anything other than other Signal.  Puppeted
> > bridges are not interoperability, as far as I am aware, all users
> > still need to be on Signal.
> 
> You seem to be using a completely different meaning of 'proprietary' (no 
> federation) than I do (closed source software, proprietary protocol that 
> must be reversed engineered, patents, etc.).

Well, Michael's original post that you challenged contrasted:

> a standards based system such as mail or the web and a proprietary
> system such as facebook, WhatsApp, Signal, Telegram, etc etc.

Would you call Signal "a standards based system?" I understand that the
software itself is open source, and the project does publish various
"Signal Protocal" libraries, but I'm not sure that's quite enough to
call it "standards based."

Celejar

[toc] | [prev] | [next] | [standalone]

#236427

Celejar wrote: 
> On Thu, 24 Jun 2021 01:25:37 +0300
> Andrei POPESCU <andreimpopescu@gmail.com> wrote:
> 
> > On Mi, 23 iun 21, 17:12:07, Michael Grant wrote:
> > > > Apparently the lines are blurry enough for you to include Signal in that 
> > > > list.
> > > 
> > > Why?  Not blurry at all.  Signal is just as closed a system as
> > > WhatsApp.  Maybe more private, but unless you know something I don't,
> > > Signal doesn't talk to anything other than other Signal.  Puppeted
> > > bridges are not interoperability, as far as I am aware, all users
> > > still need to be on Signal.
> > 
> > You seem to be using a completely different meaning of 'proprietary' (no 
> > federation) than I do (closed source software, proprietary protocol that 
> > must be reversed engineered, patents, etc.).
> 
> Well, Michael's original post that you challenged contrasted:
> 
> > a standards based system such as mail or the web and a proprietary
> > system such as facebook, WhatsApp, Signal, Telegram, etc etc.
> 
> Would you call Signal "a standards based system?" I understand that the
> software itself is open source, and the project does publish various
> "Signal Protocal" libraries, but I'm not sure that's quite enough to
> call it "standards based."

Rule of thumb: it doesn't matter whether a system is based on a
standard or not; it matters how easily it plays with others. For
word processing systems, you want the input and output formats
to be open standards, but you don't care about the internals.

For communications systems, the question is whether an outside
party can easily use their own software to interact with others.
At one extreme is email, where humans can telnet to port 25 on a
reasonable system and send a message.

At the other end is anything where you can't use a client or a
server that isn't produced/managed by the central authority.
Despite Signal making some of their source available, you can't
write your own Signal client and have it talk to their official
servers.

-dsr-

[toc] | [prev] | [next] | [standalone]

#236476

[Multipart message — attachments visible in raw view] — view raw

On Jo, 24 iun 21, 14:13:42, Dan Ritter wrote:
> 
> At the other end is anything where you can't use a client or a
> server that isn't produced/managed by the central authority.
> Despite Signal making some of their source available, you can't
> write your own Signal client and have it talk to their official
> servers.

Sure, and I don't remember disputing this.

But let's not conflate the Signal software (client, server, etc.), the 
Signal protocol and the Signal *service*.

Could you elaborate on why in your opinion an entity providing a service 
should automatically accept connections from third-party clients and/or 
federate with other service providers?

https://github.com/LibreSignal/LibreSignal/issues/37#issuecomment-217231557

(as is implied from that, Signal did at some point federate)

Or could you explain why Matrix (which as far as I know is already both 
federated and open to any client) is not enough?

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#236479

[Multipart message — attachments visible in raw view] — view raw

On Sb, 26 iun 21, 13:31:33, Andrei POPESCU wrote:
> On Jo, 24 iun 21, 14:13:42, Dan Ritter wrote:
> > 
> > At the other end is anything where you can't use a client or a
> > server that isn't produced/managed by the central authority.
> > Despite Signal making some of their source available, you can't
> > write your own Signal client and have it talk to their official
> > servers.
> 
> Sure, and I don't remember disputing this.
> 
> But let's not conflate the Signal software (client, server, etc.), the 
> Signal protocol and the Signal *service*.
> 
> Could you elaborate on why in your opinion an entity providing a service 
> should automatically accept connections from third-party clients and/or 
> federate with other service providers?
> 
> https://github.com/LibreSignal/LibreSignal/issues/37#issuecomment-217231557
> 
> (as is implied from that, Signal did at some point federate)

Here's a better reference for Moxie's opinion:

https://signal.org/blog/the-ecosystem-is-moving/
 
> Or could you explain why Matrix (which as far as I know is already both 
> federated and open to any client) is not enough?


Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#236486

On Sat 26 Jun 2021 at 14:14:13 +0300, Andrei POPESCU wrote:

> On Sb, 26 iun 21, 13:31:33, Andrei POPESCU wrote:
> > On Jo, 24 iun 21, 14:13:42, Dan Ritter wrote:
> > > 
> > > At the other end is anything where you can't use a client or a
> > > server that isn't produced/managed by the central authority.
> > > Despite Signal making some of their source available, you can't
> > > write your own Signal client and have it talk to their official
> > > servers.
> > 
> > Sure, and I don't remember disputing this.
> > 
> > But let's not conflate the Signal software (client, server, etc.), the 
> > Signal protocol and the Signal *service*.
> > 
> > Could you elaborate on why in your opinion an entity providing a service 
> > should automatically accept connections from third-party clients and/or 
> > federate with other service providers?
> > 
> > https://github.com/LibreSignal/LibreSignal/issues/37#issuecomment-217231557
> > 
> > (as is implied from that, Signal did at some point federate)
> 
> Here's a better reference for Moxie's opinion:
> 
> https://signal.org/blog/the-ecosystem-is-moving/

An interesting read. Countered at

https://matrix.org/blog/2020/01/02/on-privacy-versus-freedom

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#236490

[Multipart message — attachments visible in raw view] — view raw

On Sb, 26 iun 21, 14:05:04, Brian wrote:
> On Sat 26 Jun 2021 at 14:14:13 +0300, Andrei POPESCU wrote:
> 
> 
> An interesting read. Countered at
> 
> https://matrix.org/blog/2020/01/02/on-privacy-versus-freedom

Looking forward for them to prove Moxie wrong, really!


Kind regards,
Andrei
(planning to run my own Matrix server because it seems to be able to 
some app that, for social reasons, I just can't avoid)
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#236543

On Sat, 26 Jun 2021 17:02:10 +0300
Andrei POPESCU <andreimpopescu@gmail.com> wrote:

> On Sb, 26 iun 21, 14:05:04, Brian wrote:
> > On Sat 26 Jun 2021 at 14:14:13 +0300, Andrei POPESCU wrote:
> > 
> > 
> > An interesting read. Countered at
> > 
> > https://matrix.org/blog/2020/01/02/on-privacy-versus-freedom
> 
> Looking forward for them to prove Moxie wrong, really!

I certainly have a much less profound understanding of the issues, both
philosophical and technical, than the experts on both sides of this
debate, but my sympathies lie strongly with the Matrix people. From
their blog post (thanks, Brian) - I think this is worth posting here:

> It’s true that if you’re writing a messaging app optimised for privacy
> at any cost, Moxie’s approach is one way to do it. However, this ends
> up being a perversely closed world - a closed network, where unofficial
> clients are banned, with no platform to build on, no open standards,
> and you end up thoroughly putting all your eggs in one basket, trusting
> past, present & future Signal to retain its values, stay up and somehow
> dodge compromise & censorship… despite probably being the single
> highest value attack target on the ‘net.
> 
> Quite simply, that isn’t a world I want to live in.
> 
> We owe the entire success of the Internet (let alone the Web) to
> openness, interoperability and decentralisation. To declare that
> openness, interoperability and decentralisation is ‘too hard’ and not
> worth the effort when building a messaging solution is to throw away
> all the potential of the vibrancy, creativity and innovation that comes
> from an open network. Sure, you may end up with a super-private
> messaging app - but one that starts to smell alarmingly like a walled
> garden like Facebook’s Internet.org initiative, or an AOL keyword, or
> Google’s AMP.

Celejar

[toc] | [prev] | [next] | [standalone]

#236482

Andrei POPESCU wrote: 
> On Jo, 24 iun 21, 14:13:42, Dan Ritter wrote:
> > 
> > At the other end is anything where you can't use a client or a
> > server that isn't produced/managed by the central authority.
> > Despite Signal making some of their source available, you can't
> > write your own Signal client and have it talk to their official
> > servers.
> 
> Sure, and I don't remember disputing this.
> 
> But let's not conflate the Signal software (client, server, etc.), the 
> Signal protocol and the Signal *service*.
> 
> Could you elaborate on why in your opinion an entity providing a service 
> should automatically accept connections from third-party clients and/or 
> federate with other service providers?
> 
> https://github.com/LibreSignal/LibreSignal/issues/37#issuecomment-217231557
> 
> (as is implied from that, Signal did at some point federate)

Sure. In my opinion, a communication service that does not
federate with open-source clients and servers is a proprietary
service, even if it is free-gratis to use. The owner of that
service can do whatever they want, and nothing short of
government regulation can or will prevent them.

Monopolies are always bad; it's just that sometimes they are economically
worth having when very tightly regulated.

That's an opinion.


> Or could you explain why Matrix (which as far as I know is already both 
> federated and open to any client) is not enough?

Not enough for what? The primary issue I have with Matrix is that
there's too much concentration of servers under the control of
matrix.org - but I think that they believe that too, and that
this will be rectified over the next few years. 

-dsr-

[toc] | [prev] | [next] | [standalone]

#236489

[Multipart message — attachments visible in raw view] — view raw

On Sb, 26 iun 21, 07:41:51, Dan Ritter wrote:
> Andrei POPESCU wrote: 
> 
> Sure. In my opinion, a communication service that does not
> federate with open-source clients and servers is a proprietary
> service, even if it is free-gratis to use. The owner of that
> service can do whatever they want, and nothing short of
> government regulation can or will prevent them.

The legal rights and obligations of service providers are completely 
orthogonal to the software and protocols they are using.

The operator of a mail server (as an example of open protocol) can just 
as well sell or abuse your private communication (didn't this thread 
start out about Gmail?). It's up to the users to vote with their feet 
(or wallet for paid services).
 
> Monopolies are always bad; it's just that sometimes they are economically
> worth having when very tightly regulated.
> 
> That's an opinion.

Monopolies can also be countered by viable alternatives and in my 
experience the only reasonable alternative to WhatsApp is Signal.

That's also an opinion.
 
> > Or could you explain why Matrix (which as far as I know is already both 
> > federated and open to any client) is not enough?
> 
> Not enough for what? The primary issue I have with Matrix is that
> there's too much concentration of servers under the control of
> matrix.org - but I think that they believe that too, and that
> this will be rectified over the next few years. 

Well, apparently lots of people[1] seem very upset about and hell bent 
to change Signal's (the service) policies on federation, third-party 
clients, etc.

Why? There's Matrix, that already has all that. Why insist that 
everybody else has to do that as well? Live and let live, anyone?

[1] not referring to anyone in particular

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#236549

On Sat, 26 Jun 2021 16:51:21 +0300
Andrei POPESCU <andreimpopescu@gmail.com> wrote:

...

> Well, apparently lots of people[1] seem very upset about and hell bent 
> to change Signal's (the service) policies on federation, third-party 
> clients, etc.
> 
> Why? There's Matrix, that already has all that. Why insist that 
> everybody else has to do that as well? Live and let live, anyone?
> 
> [1] not referring to anyone in particular

Should we not criticize software and services that we find problematic
just because alternatives exist? Moreover, I suspect that Signal's
dominance plays a role in hindering the growth of things like Matrix -
when all the privacy and security Big Names rave over Signal and push
it so strongly, then due to network effects (within the privacy and
security conscious community), it becomes more and more necessary to
use it.

This is similar to what I assume many Signal users feel about WhatsApp
- frustration that they have an altogether far superior solution, that
they are severely hampered in their ability to use because everyone
else is using the inferior solution ;)

(Please don't get me wrong - I agree that Signal is a far, far,
superior alternative to WhatsApp, and that the difference between them
is much greater than the difference between Signal and Matrix - I just
mean that people always criticize the shortcomings of dominant software
systems in order to promote the ones they consider preferable and to
increase their usage, which renders them much more useful due to
network effects.)

Celejar

[toc] | [prev] | [next] | [standalone]

#236565

[Multipart message — attachments visible in raw view] — view raw

On Du, 27 iun 21, 11:50:59, Celejar wrote:
> On Sat, 26 Jun 2021 16:51:21 +0300
> Andrei POPESCU <andreimpopescu@gmail.com> wrote:
> 
> ...
> 
> > Well, apparently lots of people[1] seem very upset about and hell bent 
> > to change Signal's (the service) policies on federation, third-party 
> > clients, etc.
> > 
> > Why? There's Matrix, that already has all that. Why insist that 
> > everybody else has to do that as well? Live and let live, anyone?
> > 
> > [1] not referring to anyone in particular
> 
> Should we not criticize software and services that we find problematic
> just because alternatives exist? Moreover, I suspect that Signal's
> dominance plays a role in hindering the growth of things like Matrix -
> when all the privacy and security Big Names rave over Signal and push
> it so strongly, then due to network effects (within the privacy and
> security conscious community), it becomes more and more necessary to
> use it.

Criticizing is of course fair game, lumping it in together with 
WhatsApp, Facebook and Telegram seems excessive to me.
 
> (Please don't get me wrong - I agree that Signal is a far, far,
> superior alternative to WhatsApp, and that the difference between them
> is much greater than the difference between Signal and Matrix - I just
> mean that people always criticize the shortcomings of dominant software
> systems in order to promote the ones they consider preferable and to
> increase their usage, which renders them much more useful due to
> network effects.)

Yes, with the potential risk of doing more harm then good.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#236548

On Sat, 26 Jun 2021 07:41:51 -0400
Dan Ritter <dsr@randomstring.org> wrote:

...

> Not enough for what? The primary issue I have with Matrix is that
> there's too much concentration of servers under the control of
> matrix.org - but I think that they believe that too, and that
> this will be rectified over the next few years. 

They explicitly state this:

> It’s also fair that in a multi-server federated model, users naturally
> tend to sign up on the most prominent server(s) (e.g. the matrix.org
> homeserver in the case of Matrix). In practice, the matrix.org
> homeserver currently makes up about 35% of the visible Matrix network
> by active users. It’s also true that Matrix servers currently store
> metadata about who’s talking to who, and when, as a side-effect of
> storing and relaying messages on behalf of their users. And without an
> adequate protocol governance system in place, a large server could
> start pushing around smaller ones in terms of protocol behaviour. In
> practice, we’re looking into solving metadata protection in Matrix by
> experimenting with hybrid P2P / Client Server models - letting users
> store their metadata purely clientside if they so desire, and
> potentially obfuscating who’s talking to who via mixnets of blinded
> store & forward servers (more about this coming up at FOSDEM). Combined
> with nomadic accounts, this would let us eventually turn off the
> matrix.org server entirely and eliminate the pseudo-centralisation
> effect - the default ‘server’ would be the one running on your client.

https://matrix.org/blog/2020/01/02/on-privacy-versus-freedom

Celejar

[toc] | [prev] | [next] | [standalone]

#236542

On Sat, 26 Jun 2021 13:31:33 +0300
Andrei POPESCU <andreimpopescu@gmail.com> wrote:

> On Jo, 24 iun 21, 14:13:42, Dan Ritter wrote:
> > 
> > At the other end is anything where you can't use a client or a
> > server that isn't produced/managed by the central authority.
> > Despite Signal making some of their source available, you can't
> > write your own Signal client and have it talk to their official
> > servers.
> 
> Sure, and I don't remember disputing this.
> 
> But let's not conflate the Signal software (client, server, etc.), the 
> Signal protocol and the Signal *service*.
> 
> Could you elaborate on why in your opinion an entity providing a service 
> should automatically accept connections from third-party clients and/or 
> federate with other service providers?

Well, would you have no problem with a website that requires the site's
own browser to function, and won't work with standard browsers? I agree
that the site has the legal and even moral right to implement such a
thing, but I wouldn't be happy about it.

Celejar

[toc] | [prev] | [next] | [standalone]

#236563

[Multipart message — attachments visible in raw view] — view raw

On Du, 27 iun 21, 11:27:39, Celejar wrote:
> On Sat, 26 Jun 2021 13:31:33 +0300
> Andrei POPESCU <andreimpopescu@gmail.com> wrote:
> > 
> > Could you elaborate on why in your opinion an entity providing a service 
> > should automatically accept connections from third-party clients and/or 
> > federate with other service providers?
> 
> Well, would you have no problem with a website that requires the site's
> own browser to function, and won't work with standard browsers? I agree
> that the site has the legal and even moral right to implement such a
> thing, but I wouldn't be happy about it.

The internet is big enough for all, user will chose.

If users flock to a closed service the correct thing to do is ask 
ourselves why they are doing this (besides the social network effect) 
and what is missing from the open alternatives.


Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#236430

On Thu 24 Jun 2021 at 14:04:13 -0400, Celejar wrote:

> On Thu, 24 Jun 2021 01:25:37 +0300
> Andrei POPESCU <andreimpopescu@gmail.com> wrote:
> 
> > On Mi, 23 iun 21, 17:12:07, Michael Grant wrote:
> > > > Apparently the lines are blurry enough for you to include Signal in that 
> > > > list.
> > > 
> > > Why?  Not blurry at all.  Signal is just as closed a system as
> > > WhatsApp.  Maybe more private, but unless you know something I don't,
> > > Signal doesn't talk to anything other than other Signal.  Puppeted
> > > bridges are not interoperability, as far as I am aware, all users
> > > still need to be on Signal.
> > 
> > You seem to be using a completely different meaning of 'proprietary' (no 
> > federation) than I do (closed source software, proprietary protocol that 
> > must be reversed engineered, patents, etc.).
> 
> Well, Michael's original post that you challenged contrasted:
> 
> > a standards based system such as mail or the web and a proprietary
> > system such as facebook, WhatsApp, Signal, Telegram, etc etc.
> 
> Would you call Signal "a standards based system?" I understand that the
> software itself is open source, and the project does publish various
> "Signal Protocal" libraries, but I'm not sure that's quite enough to
> call it "standards based."

Michael was desperately trying to sustain his argument that

>  email is NOT gmail and let's not forget this.

Gmail is standards-based. I expext Signal is too; otherwise it would not
work.

standrds-bsaed != free.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#236432

On Thu, 24 Jun 2021 21:03:28 +0100
Brian <ad44@cityscape.co.uk> wrote:

> On Thu 24 Jun 2021 at 14:04:13 -0400, Celejar wrote:
> 
> > On Thu, 24 Jun 2021 01:25:37 +0300
> > Andrei POPESCU <andreimpopescu@gmail.com> wrote:
> > 
> > > On Mi, 23 iun 21, 17:12:07, Michael Grant wrote:
> > > > > Apparently the lines are blurry enough for you to include Signal in that 
> > > > > list.
> > > > 
> > > > Why?  Not blurry at all.  Signal is just as closed a system as
> > > > WhatsApp.  Maybe more private, but unless you know something I don't,
> > > > Signal doesn't talk to anything other than other Signal.  Puppeted
> > > > bridges are not interoperability, as far as I am aware, all users
> > > > still need to be on Signal.
> > > 
> > > You seem to be using a completely different meaning of 'proprietary' (no 
> > > federation) than I do (closed source software, proprietary protocol that 
> > > must be reversed engineered, patents, etc.).
> > 
> > Well, Michael's original post that you challenged contrasted:
> > 
> > > a standards based system such as mail or the web and a proprietary
> > > system such as facebook, WhatsApp, Signal, Telegram, etc etc.
> > 
> > Would you call Signal "a standards based system?" I understand that the
> > software itself is open source, and the project does publish various
> > "Signal Protocal" libraries, but I'm not sure that's quite enough to
> > call it "standards based."
> 
> Michael was desperately trying to sustain his argument that
> 
> >  email is NOT gmail and let's not forget this.
> 
> Gmail is standards-based. I expext Signal is too; otherwise it would not

Is there a published, readily available, complete description of Gmail's
behavior?

> work.

? Are you asserting that any software that works is necessarily
standards-based? If so, you must have a very different definition of
standards-based from mine.

> standrds-bsaed != free.

That's true, of course.

Celejar

[toc] | [prev] | [next] | [standalone]

#236457

On Thu 24 Jun 2021 at 18:41:56 -0400, Celejar wrote:

> On Thu, 24 Jun 2021 21:03:28 +0100
> Brian <ad44@cityscape.co.uk> wrote:
> 
> > On Thu 24 Jun 2021 at 14:04:13 -0400, Celejar wrote:
> > 
> > > On Thu, 24 Jun 2021 01:25:37 +0300
> > > Andrei POPESCU <andreimpopescu@gmail.com> wrote:
> > > 
> > > > On Mi, 23 iun 21, 17:12:07, Michael Grant wrote:
> > > > > > Apparently the lines are blurry enough for you to include Signal in that 
> > > > > > list.
> > > > > 
> > > > > Why?  Not blurry at all.  Signal is just as closed a system as
> > > > > WhatsApp.  Maybe more private, but unless you know something I don't,
> > > > > Signal doesn't talk to anything other than other Signal.  Puppeted
> > > > > bridges are not interoperability, as far as I am aware, all users
> > > > > still need to be on Signal.
> > > > 
> > > > You seem to be using a completely different meaning of 'proprietary' (no 
> > > > federation) than I do (closed source software, proprietary protocol that 
> > > > must be reversed engineered, patents, etc.).
> > > 
> > > Well, Michael's original post that you challenged contrasted:
> > > 
> > > > a standards based system such as mail or the web and a proprietary
> > > > system such as facebook, WhatsApp, Signal, Telegram, etc etc.
> > > 
> > > Would you call Signal "a standards based system?" I understand that the
> > > software itself is open source, and the project does publish various
> > > "Signal Protocal" libraries, but I'm not sure that's quite enough to
> > > call it "standards based."
> > 
> > Michael was desperately trying to sustain his argument that
> > 
> > >  email is NOT gmail and let's not forget this.
> > 
 > Gmail is standards-based. I expext Signal is too; otherwise it would not
> 
> Is there a published, readily available, complete description of Gmail's
> behavior?

It's described in the same document dealing also with Yahoo, gmx and
Zoho :). I expect they have read and taken notice of the RFCs.
 
> > work.
> 
> ? Are you asserting that any software that works is necessarily
> standards-based? If so, you must have a very different definition of
> standards-based from mine.

I wouldn't want to generalise to that extent. However, your mail made
it to LDO and was then delivered to me. Gmail must be doing something
right and standards-based.

> > standrds-bsaed != free.
> 
> That's true, of course.

It is perfectly possible to send and receive mail via gmail without
ever encountering its web interface. That's no different from any
other ISP.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#236458

On Fri, 25 Jun 2021 19:04:57 +0100
Brian <ad44@cityscape.co.uk> wrote:

> On Thu 24 Jun 2021 at 18:41:56 -0400, Celejar wrote:
> 
> > On Thu, 24 Jun 2021 21:03:28 +0100
> > Brian <ad44@cityscape.co.uk> wrote:
> > 
> > > On Thu 24 Jun 2021 at 14:04:13 -0400, Celejar wrote:
> > > 
> > > > On Thu, 24 Jun 2021 01:25:37 +0300
> > > > Andrei POPESCU <andreimpopescu@gmail.com> wrote:
> > > > 
> > > > > On Mi, 23 iun 21, 17:12:07, Michael Grant wrote:
> > > > > > > Apparently the lines are blurry enough for you to include Signal in that 
> > > > > > > list.
> > > > > > 
> > > > > > Why?  Not blurry at all.  Signal is just as closed a system as
> > > > > > WhatsApp.  Maybe more private, but unless you know something I don't,
> > > > > > Signal doesn't talk to anything other than other Signal.  Puppeted
> > > > > > bridges are not interoperability, as far as I am aware, all users
> > > > > > still need to be on Signal.
> > > > > 
> > > > > You seem to be using a completely different meaning of 'proprietary' (no 
> > > > > federation) than I do (closed source software, proprietary protocol that 
> > > > > must be reversed engineered, patents, etc.).
> > > > 
> > > > Well, Michael's original post that you challenged contrasted:
> > > > 
> > > > > a standards based system such as mail or the web and a proprietary
> > > > > system such as facebook, WhatsApp, Signal, Telegram, etc etc.
> > > > 
> > > > Would you call Signal "a standards based system?" I understand that the
> > > > software itself is open source, and the project does publish various
> > > > "Signal Protocal" libraries, but I'm not sure that's quite enough to
> > > > call it "standards based."
> > > 
> > > Michael was desperately trying to sustain his argument that
> > > 
> > > >  email is NOT gmail and let's not forget this.
> > > 
>  > Gmail is standards-based. I expext Signal is too; otherwise it would not
> > 
> > Is there a published, readily available, complete description of Gmail's
> > behavior?
> 
> It's described in the same document dealing also with Yahoo, gmx and
> Zoho :). I expect they have read and taken notice of the RFCs.
>  
> > > work.
> > 
> > ? Are you asserting that any software that works is necessarily
> > standards-based? If so, you must have a very different definition of
> > standards-based from mine.
> 
> I wouldn't want to generalise to that extent. However, your mail made
> it to LDO and was then delivered to me. Gmail must be doing something
> right and standards-based.
> 
> > > standrds-bsaed != free.

No one's denying that Gmail *mostly* follows email standards; the
criticism is that they sometimes deviate from these standards, in
undocumented and often frustrating ways. This may not affect your
use case; that does not mean that it isn't frustrating to others.

> > That's true, of course.
> 
> It is perfectly possible to send and receive mail via gmail without
> ever encountering its web interface. That's no different from any
> other ISP.

Yes, I access Gmail almost exclusively via POP3 and IMAP. And the
clients I use have special workarounds and warnings for Gmail:

https://getmail6.org/faq.html#faq-notabug-gmail-bug
https://www.ubuntubuzz.com/2017/06/how-to-setup-sylpheed-for-gmail-imap-client.html

Celejar

[toc] | [prev] | [next] | [standalone]

#236468

On Friday 25 June 2021 14:29:31 mick crane wrote:

> On 2021-06-25 19:04, Brian wrote:
> <snipped>
>
> > It is perfectly possible to send and receive mail via gmail without
> > ever encountering its web interface. That's no different from any
> > other ISP.
>
> It seems to me they do not honour the "delete" request when collecting
> from IMAP because in my case they certainly go from INBOX but are
> retained in ALL MAIL.
> mick

I've found that switching fetchmail from pop3 access to imap access, 
restores that delete function. However that may be server dependent, my 
server at shentel.net is dovecot. Very few problems.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.debian.user

csiph-web