Lewis <g.kreme@kreme.dont-email.me> wrote:
[...]

> I've had an email address since email addresses contained ! (a bang
> path, it was called).

I already used email nearly a decade before UUCP even existed, so
there you go! :-)

[...]

> POP stores all the mail in a single text file. This was fine when you
> got a few KB of email. It is not great when emails are often in the
> 15-20MB range. An IMAP account has no issues with large mailboxes, and I
> have accounts that have 5GB of mail. I just moved a client to a new
> mailhost and her email archive was 3.7GB, but it was in thousands of
> files, not one single file.
>
> I stopped supporting POP on my own mailserver when a user had a 1.4GB
> mailbox and his checking mail brought the server to it's knees because
> every time he checked mail it had to parse that file. This was in 2000
> or 2001.

I see! Your *server* was badly designed, so you blame the (POP)
*protocol* for that.

[...]

nospam wrote:

>> Much like Android is designed to go beyond the limitations of iOS.
>
> hah, no.

As just one example, Android allows sideloading sans rooting.
iOS doesn't.

Hence, Apple can (and does) restrict apps the average user can load.
Google can't.

>> There are zero app functionalities on iOS not already on Android.
>
> repeating that lie doesn't change the fact that it's a lie, trollboi.

I can easily name many app functionalities on Android not on iOS.
Automatic call recording for one
Graphical wifi debugging for another
Ability to change launchers so you can organize a desktop for another
etc.

All this app functionality is available for free without needing a second
computer and without needing the cloud (the app does it all by its itty
bitty self).

Now it's your turn to provide facts that underlie your belief systems:
Name even a _single_ app functionality that I can load on my iPads
today that provides an app functionality that doesn't exist on Android.

*Name just one*

HINT: You can't.
You'll claim you did and nobody listened.
But you can't. And you never did. And you never will.
All you can do is paste Marketing garbage from Apple advertisements.

The reason there is zero app functionality on iOS not already on Android is
simple.

Apple drasticall limits what apps can do; Google can't.

It has _nothing_ to do with the hardware.
It has everything to do with Apple's control over the apps on the App Store.

Apple drastically limits what apps can be on the Apple App Store.
Google does not.

Google can't even limit what apps the average user can sideload (sans root).
Most people don't understand _why_ iOS is so crippled compared to Android.

But it's not just Android as almost all functionality that is limited by iOS
is already on _every_ other common consumer platform (even on the mac).

It's iOS that's crippled.

Since you claim that this is a lie, simply provide proof of your claim.
*Name just one app functionality on the App Store not available to Android*

Name just one.
--
The most obvious mark of a bullshitter is they can't ever back their claims.

nospam wrote:

>> If you understood what I know
>
> which is absolutely nothing

And yet I have known Apple's R&D expenditure by _any_ means you wish to
count it (whether by percentage or by total or by per employee, etc.)
*is dismal*

Not a single one of you iKooks knew that before I told it to you.

And uneducated ignorant morons like Alan Browne are still desperately
struggling to figure out child-like rationales to explain it away.

Yet, *Apple's MARKETING budget is stupendous*

What I know, none of you iKooks will ever know, which is...
*It's not Apple who is well managed - it's Apple's customer.*
--
You can't make those ungodly profits off of an intelligent customer base.

Lewis <g.kreme@kreme.dont-email.me> wrote:
[...]

> There is NOTHING POP can do that IMAP cannot do. There are many things
> that IMAP can do that POP cannot do.

So you IMAP 'proponents' keep saying! But as has been mentioned - and
dutyfully ignored by the fanbois - there are other aspects to the matter
than just the features of the protocols.

One of the issues which were mentioned - and also ignored, except for
nospam's paper tigers - is the fact that you cannot have one single/
unified folder structure across multiple IMAP servers, i.e. multiple
accounts with multiple MSPs. That's not a limitation of the IMAP
protocol, but an inherent limitation of the structure/design of IMAP
servers.

From several responses it seems that several people need/want that
(single/ unified folder structure) feature, but itheir needs get ignored
and they get snowed under by 'IMAP is best' rants.

N.B.Before you get on my case as well, remember that I'm using POP
*and* IMAP. I'm just using what suits my needs best. No need to get all
religious either way.

[ ...]

Joerg Lorenz <hugybear@gmx.ch> wrote:
> Am 12.03.22 um 02:05 schrieb Ant:
> > In comp.mobile.android Frank Slootweg <this@ddress.is.invalid> wrote:
> > ...
> >> [1] FTR, I'm not a POP 'supporter', I'm a POP user.
> >
> > Ditto. I prefer to keep my e-mails on a single PC. I do use IMAP if I
> > need to keep e-mails on servers when I am not at home to use my home PC.
>
> Once more you prove that you neither understand POP nor IMAP.

Once more you prove that you cannot conceive that people might have
other needs/wants than you.

I prefectly understand what Ant wants/needs/does and - as I said
before - I use both POP and IMAP and understand their features very well,
thank you very much.

On 2022-03-12 10:42 a.m., Andy Burnelli wrote:
> nospam wrote:
>
>>> What's the reason imap can do what pop can't do?
>>
>> because it was designed to go beyond the limitations of pop.
>
> Much like Android is designed to go beyond the limitations of iOS.
>
> There are zero app functionalities on iOS not already on Android.
> There are plenty of app functionalities on Android not on iOS.

Which has nothing to do with the OS per se.

>
> The reasons are the same.
> It's not the hardware.
>
> It's the enormous restrictions Apple places on what apps can do.

In article <t0j046.5l8.1@ID-201911.user.individual.net>, Frank Slootweg
<this@ddress.is.invalid> wrote:

> One of the issues which were mentioned - and also ignored, except for
> nospam's paper tigers - is the fact that you cannot have one single/
> unified folder structure across multiple IMAP servers, i.e. multiple
> accounts with multiple MSPs. That's not a limitation of the IMAP
> protocol, but an inherent limitation of the structure/design of IMAP
> servers.

nope. that's a limitation of the email client.

On 2022-03-12 17:30, J. P. Gilliver (John) wrote:
> On Sat, 12 Mar 2022 at 14:12:40, Carlos E.R. <robin_listas@es.invalid>
> wrote (my responses usually FOLLOW):
> []
>> Nothing in IMAP forces people to keep email on the server. Wrong. It
>> simply _allows_ users to keep mail on the servers if they want, or on
>> their machines if they want. The choice is on the user.
> []
> I'm quite willing to believe you, but isn't that the foundation of what
> seems to be the main advantage touted for IMAP - in other words, if you
> keep all your mail on one local PC (and _not_ on the server) under IMAP,
> doesn't that dismiss that main advantage?

The first time I learned about imap was in a pure mail downloder program
(fetchmail in Linux). And for that download only program, the
documentation explained the advantages of using imap over pop3, for
example in avoiding duplicates.

--
Cheers, Carlos.

On 2022-03-12 20:34, Frank Slootweg wrote:
> Lewis <g.kreme@kreme.dont-email.me> wrote:
> [...]
>
>> There is NOTHING POP can do that IMAP cannot do. There are many things
>> that IMAP can do that POP cannot do.
>
> So you IMAP 'proponents' keep saying! But as has been mentioned - and
> dutyfully ignored by the fanbois - there are other aspects to the matter
> than just the features of the protocols.
>
> One of the issues which were mentioned - and also ignored, except for
> nospam's paper tigers - is the fact that you cannot have one single/
> unified folder structure across multiple IMAP servers, i.e. multiple
> accounts with multiple MSPs. That's not a limitation of the IMAP
> protocol, but an inherent limitation of the structure/design of IMAP
> servers.
>
> From several responses it seems that several people need/want that
> (single/ unified folder structure) feature, but itheir needs get ignored
> and they get snowed under by 'IMAP is best' rants.

That's a feature of the client, not the server. The client designed
chose not to do it. I am not aware of anything in imap that impedes to
do what you propose.

>
> N.B.Before you get on my case as well, remember that I'm using POP
> *and* IMAP. I'm just using what suits my needs best. No need to get all
> religious either way.
>
> [ ...]

--
Cheers, Carlos.

Carlos E.R. <robin_listas@es.invalid> wrote:
> On 2022-03-12 20:34, Frank Slootweg wrote:
> > Lewis <g.kreme@kreme.dont-email.me> wrote:
> > [...]
> >
> >> There is NOTHING POP can do that IMAP cannot do. There are many things
> >> that IMAP can do that POP cannot do.
> >
> > So you IMAP 'proponents' keep saying! But as has been mentioned - and
> > dutyfully ignored by the fanbois - there are other aspects to the matter
> > than just the features of the protocols.
> >
> > One of the issues which were mentioned - and also ignored, except for
> > nospam's paper tigers - is the fact that you cannot have one single/
> > unified folder structure across multiple IMAP servers, i.e. multiple
> > accounts with multiple MSPs. That's not a limitation of the IMAP
> > protocol, but an inherent limitation of the structure/design of IMAP
> > servers.
> >
> > From several responses it seems that several people need/want that
> > (single/ unified folder structure) feature, but itheir needs get ignored
> > and they get snowed under by 'IMAP is best' rants.
>
> That's a feature of the client, not the server. The client designed
> chose not to do it. I am not aware of anything in imap that impedes to
> do what you propose.

As I said, that's how the IMAP *servers* are structured/designed.
And, as I said, it's indeed not a limitation of the IMAP *protocol*.

But as long as IMAP servers are structured/designed as they are and
e-mail clients [1] are not overcoming this limitation, saying that the
IMAP protocol is not the limiting factor is irrelevant semantics. The
end result is still that IMAP servers have this limitation and e-mail
clients are not solving this limitation.

Bottom line: For the people who need/want a single/unified folder
structure accross multiple accounts, POP accounts enable to have such a
(by definition local) folder structure and IMAP accounts do not (unless
they are effectively converted to POP-like functionality). So for
*those* people, IMAP accounts offer no advantages over POP accounts.
Period.

> > N.B.Before you get on my case as well, remember that I'm using POP
> > *and* IMAP. I'm just using what suits my needs best. No need to get all
> > religious either way.
> >
> > [ ...]

[1] Except ofcourse for nospam's unnamed paper tigers.

In article <t0l3db.al0.1@ID-201911.user.individual.net>, Frank Slootweg
<this@ddress.is.invalid> wrote:

> > > One of the issues which were mentioned - and also ignored, except for
> > > nospam's paper tigers - is the fact that you cannot have one single/
> > > unified folder structure across multiple IMAP servers, i.e. multiple
> > > accounts with multiple MSPs. That's not a limitation of the IMAP
> > > protocol, but an inherent limitation of the structure/design of IMAP
> > > servers.
> > >
> > > From several responses it seems that several people need/want that
> > > (single/ unified folder structure) feature, but itheir needs get ignored
> > > and they get snowed under by 'IMAP is best' rants.
> >
> > That's a feature of the client, not the server. The client designed
> > chose not to do it. I am not aware of anything in imap that impedes to
> > do what you propose.
>
> As I said, that's how the IMAP *servers* are structured/designed.
> And, as I said, it's indeed not a limitation of the IMAP *protocol*.

which means it's a limitation of the email app, not imap.

at least you finally agree, yet you continue to argue anyway.

> But as long as IMAP servers are structured/designed as they are and
> e-mail clients [1] are not overcoming this limitation, saying that the
> IMAP protocol is not the limiting factor is irrelevant semantics. The
> end result is still that IMAP servers have this limitation and e-mail
> clients are not solving this limitation.

it's not semantics.

email apps have long overcome that mythical limitation, which was never
actually a limitation in the first place.

*your* choice of email client might not implement that feature, making
it a limitation of that particular app, but that's on you, not imap.

> Bottom line: For the people who need/want a single/unified folder
> structure accross multiple accounts, POP accounts enable to have such a
> (by definition local) folder structure and IMAP accounts do not (unless
> they are effectively converted to POP-like functionality). So for
> *those* people, IMAP accounts offer no advantages over POP accounts.
> Period.

bottom line: you are wrong. what you call a unified folder structure
works with imap without issue and pop offers nothing to make it easier
(it actually makes it worse).

On 13/03/2022 at 14:42, Frank Slootweg wrote:
> Bottom line: For the people who need/want a single/unified folder
> structure accross multiple accounts, POP accounts enable to have such a
> (by definition local) folder structure and IMAP accounts do not (unless
> they are effectively converted to POP-like functionality). So for
> *those* people, IMAP accounts offer no advantages over POP accounts.
> Period.

I see what you are saying. If you are careful enough to download all
emails to all your clients via POP and then manually file them into the
identical folder structures, then all will remain the same on all
clients. But how would that work for sent emails? How would emails
sent using a particular client end up in the sent folders of the other
clients?

--
Wilf

Wilf <wilf@postingx.uk> wrote:
> On 13/03/2022 at 14:42, Frank Slootweg wrote:
> > Bottom line: For the people who need/want a single/unified folder
> > structure accross multiple accounts, POP accounts enable to have such a
> > (by definition local) folder structure and IMAP accounts do not (unless
> > they are effectively converted to POP-like functionality). So for
> > *those* people, IMAP accounts offer no advantages over POP accounts.
> > Period.
>
> I see what you are saying. If you are careful enough to download all
> emails to all your clients via POP and then manually file them into the
> identical folder structures, then all will remain the same on all
> clients. But how would that work for sent emails? How would emails
> sent using a particular client end up in the sent folders of the other
> clients?

No, this is about a single email client on a single device. That is
the usage model of these users (with perhaps the occasional use ('peek')
from another e-mail client on another device). These users are perfectly
happy with that usage model.

*Other* users may want to access their email from multiple devices and
for those users, IMAP is indeed generally the preferred solution.

So all this (non-)discussion is about is that one-size (IMAP) does
*not* fit all, it only fits many and perhaps even most

On 13/03/2022 at 15:34, Frank Slootweg wrote:
> Wilf <wilf@postingx.uk> wrote:
>> On 13/03/2022 at 14:42, Frank Slootweg wrote:
>>> Bottom line: For the people who need/want a single/unified folder
>>> structure accross multiple accounts, POP accounts enable to have such a
>>> (by definition local) folder structure and IMAP accounts do not (unless
>>> they are effectively converted to POP-like functionality). So for
>>> *those* people, IMAP accounts offer no advantages over POP accounts.
>>> Period.
>>
>> I see what you are saying. If you are careful enough to download all
>> emails to all your clients via POP and then manually file them into the
>> identical folder structures, then all will remain the same on all
>> clients. But how would that work for sent emails? How would emails
>> sent using a particular client end up in the sent folders of the other
>> clients?
>
> No, this is about a single email client on a single device. That is
> the usage model of these users (with perhaps the occasional use ('peek')
> from another e-mail client on another device). These users are perfectly
> happy with that usage model.
>
> *Other* users may want to access their email from multiple devices and
> for those users, IMAP is indeed generally the preferred solution.
>
> So all this (non-)discussion is about is that one-size (IMAP) does
> *not* fit all, it only fits many and perhaps even most

Ok, thanks.

--
Wilf

Since some people may be confused, Google equates 2SV with 2FA:
<https://support.google.com/accounts/answer/185839>
"With 2-Step Verification (also known as two-factor authentication),
you add an extra layer of security to your account in case your
password is stolen. After you set up 2-Step Verification,
you'll sign in to your account in two steps using:
1. Something you know, like your password
2. Something you have, like your phone"

While some said 2SV is different from 2FA, Google apparently doesn't agree.

On Thu, 10 Mar 2022 01:37:20 +0000, "J. P. Gilliver (John)"
<G6JPG@255soft.uk> wrote:

>I repeat my earlier observation: it seems to really bug IMAP supporters
>that people use POP, but not vice versa.

I don't get the sense that anyone cares what anyone else uses, but when
people speak up and say they use POP3 because (they think) it can do
something that IMAP4 cannot, it's understandable that more knowledgeable
folks would step in to correct the erroneous thinking. No one is being
forced to change the way they do things but a little education surely
isn't a bad thing.

On 2022-03-18, Char Jackson <none@none.invalid> wrote:
> On Thu, 10 Mar 2022 01:37:20 +0000, "J. P. Gilliver (John)"
><G6JPG@255soft.uk> wrote:
>
>>I repeat my earlier observation: it seems to really bug IMAP
>>supporters that people use POP, but not vice versa.
>
> I don't get the sense that anyone cares what anyone else uses, but
> when people speak up and say they use POP3 because (they think) it can
> do something that IMAP4 cannot, it's understandable that more
> knowledgeable folks would step in to correct the erroneous thinking.
> No one is being forced to change the way they do things but a little
> education surely isn't a bad thing.

You nailed it. Alas, such nuance is lost to the trolls.

--
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

In message <j9jsevF2kk1U1@mid.individual.net> Jolly Roger <jollyroger@pobox.com> wrote:
> On 2022-03-18, Char Jackson <none@none.invalid> wrote:
>> On Thu, 10 Mar 2022 01:37:20 +0000, "J. P. Gilliver (John)"
>><G6JPG@255soft.uk> wrote:
>>
>>>I repeat my earlier observation: it seems to really bug IMAP
>>>supporters that people use POP, but not vice versa.
>>
>> I don't get the sense that anyone cares what anyone else uses, but
>> when people speak up and say they use POP3 because (they think) it can
>> do something that IMAP4 cannot, it's understandable that more
>> knowledgeable folks would step in to correct the erroneous thinking.
>> No one is being forced to change the way they do things but a little
>> education surely isn't a bad thing.

I mean, I did force all my users to stop using POP3 20ish years ago, so
not quite no one. :)

> You nailed it. Alas, such nuance is lost to the trolls.

"I's always dones it this way, i can't be arsed to change anything
ever" seems to be a axiom that rules many people's lives.

--
There are bad people on both sides

Andy Burns wrote:
> Andy Burnelli wrote: > I'm not even sure if I want to use OATH2 (only if
> there is no other way).
>
> I don't understand the reluctance to use oAuth2, it uses your same gmail
> username and after you enter the same password once, it substitutes a
> "token", then in future it logs in using username+token, instead of
> username+passord, what's objectionable about that?
>
> How does google suddenly invade your privacy any more than it does as an
> IMAP/POP user?
>

On PC email clients it's typically not an issue, from what I've
gathered. I already use OAuth2 on SeaMonkey/Thunderbird.

On mobile however, it seems that FairEmail forces you to add the Google
Account to the phone rather than the e-mail app if you want to use
OAuth2, and that is a problem. At least for me.

Andy Burns wrote:

> I don't understand the reluctance to use oAuth2, it uses your same
> gmail username and after you enter the same password once, it
> substitutes a "token", then in future it logs in using
> username+token, instead of username+passord, what's objectionable
> about that?

It's not username+token. It's username+token+tracking. With
username+password, Google couldn't reliably track which host you used to
connect to their e-mail service. The OAUTH2 token is unique to each
host. You cannot use the same OAUTH2 token on multiple hosts. Google
not only know who and when logged into their service, but also from
which host you connected, and identified by something that is more
stable than a dynamic IP address. Just another, and easier, data point
for Google to collect. Some folks don't give a gnat's fart about
getting tracked. Some folks do.

There is no such thing an an OAUTH2 protocol. OAUTH1 was a protocol.
Google mangled OAUTH2 into a framework which means anyone implementing
OAUTH2 can do it their own way. Since Google maneuvered into the OAUTH2
group to control its development, Google's implementation of the
framework is most likely deployed at mail servers. The "standard" for
OAUTH2 evolved through brute force and prevalence.

https://vimeo.com/52882780

Remember when web developers had to add branch code into their HTML web
pages depending on which web client you connected to their site?
Different code was needed to effect the same functionality or content to
accomodate different web browsers. Same for OAUTH.

https://www.cloudsponge.com/blog/how-are-googles-microsofts-and-yahoos-oauth-implementations-different/

If you're concerned about someone hacking your account, and instead of
the verification process to dole out OAUTH2 tokens, you should be using
a unique password at each domain (where you login). If paranoid, change
your unique password at regular intevals. Many companies force
expiration of logins, so employees have to specify a new password to
make sure old ones aren't abused.

There is nothing insecure about using username+password. What is
insecure is the creation, non-uniqueness, and management of the logins
by the users. But, gee, let's track the hosts they're using, too.

VanguardLH wrote:

> The OAUTH2 token is unique to each
> host. You cannot use the same OAUTH2 token on multiple hosts. Google
> not only know who and when logged into their service, but also from
> which host you connected, and identified by something that is more
> stable than a dynamic IP address.

That statement, if true (and I have no reason to doubt it), brings up
questions that would be obvious to anyone trying to figure this out.

1. How does Google (or OAuth2) determine what is a unique host?

2. Why then does Google _still_ hate VPN even when using Thunderbird/OATH2?

Fox McCloud45 wrote:

> On mobile however, it seems that FairEmail forces you to add the Google
> Account to the phone rather than the e-mail app if you want to use
> OAuth2, and that is a problem. At least for me.

Aurggh. <https://i.postimg.cc/DfqZkHSN/telecom01.jpg>

Thank you for testing FairEmail as I am hoping to find _something_ on
Android to replace K9 mail that uses OAth2 as I won't use 2FA/2SV.

Like you, I do _not_ have a Google Account set up on my Android phone.
(that's why I use K9 mail in the first place, instead of the GMail apk)

Please let us know what you end up finding that _does_ work on Android.

Lewis wrote:

> "I's always dones it this way, i can't be arsed to change anything
> ever" seems to be a axiom that rules many people's lives.

Every time iKooks like Lewis are added to any adult OS conversation, these
child-like vitriol filled iKooks bring it down to their kindergarten level.

The _adult_ operating system groups aren't anything like the toy OS groups.
The _adults_ discuss the problem and try to find a working resolution.

We should probably solve this problem by removing the iKoos from replies.

On 2022-03-19 00:39, VanguardLH wrote:
> Andy Burns wrote:
>
>> I don't understand the reluctance to use oAuth2, it uses your same
>> gmail username and after you enter the same password once, it
>> substitutes a "token", then in future it logs in using
>> username+token, instead of username+passord, what's objectionable
>> about that?
>
> It's not username+token. It's username+token+tracking. With
> username+password, Google couldn't reliably track which host you used to
> connect to their e-mail service. The OAUTH2 token is unique to each
> host. You cannot use the same OAUTH2 token on multiple hosts. Google
> not only know who and when logged into their service, but also from
> which host you connected, and identified by something that is more
> stable than a dynamic IP address. Just another, and easier, data point
> for Google to collect. Some folks don't give a gnat's fart about
> getting tracked. Some folks do.

Ok, that's an interesting point.

--
Cheers, Carlos.

On 2022-03-06 17:31, Carlos E.R. wrote:
> On 2022-03-06 16:48, Frank Slootweg wrote:
>> Andy Burns <usenet@andyburns.uk> wrote:
>>> NY wrote:
>
>
>>> WLM ... no idea if it supports oAuth, but even after "less secure
>>> apps" goes
>>> away, if you have 2FA enabled on your google account you should be
>>> able to
>>> create an "app specific password" for any IMAP/POP client.
>>
>>    The Google blurb in the OP doesn't say whether or not (Google) App
>> Passwords are going away. If they are going away, the OP's concern might
>> be real. If not, it's a non-issue.
>
> Not quite.
>
> For example, I have received that blurb only on one gmail account, the
> one that is not associated to any android tablet or phone: thus 2FA can
> not be activated, and thus there are no App Passwords.
>
> A solution for me would be to make this the second account on my phone.
> I don't know.
>
>
> The other accounts I have that have not received the blurb are: one that
> has 2FA enabled, and two accounts that are associated to organizations
> (thus not @gmail.com). Apparently they have different rules defined by
> each organization and their contracts with Google.
>

I just noticed a new behaviour on that second gmail account of mine that
is not associated to an android phone. Meaning, the account is not
registered on a phone, like my main gmail account is. But it does have a
recovery phone registered with gmail, or something similar (I forget which).

Today I reactivated this account, using Thunderbird, on an old computer.
It was set to imap, "normal" authentication, and I changed it to Oauth2
(it was being refused connection, being a "new" connection). And then I
clicked on the main folder.

The usual oauth2 window popped up, and after entering the password it
said that it wanted to send an SMS to my phone ending in X, is it OK? I
hesitated, then said yes. I got the SMS, typed a six digit code, and the
folder opened fine.

Maybe this will be accepted as a 2FA. In that case, this is acceptable
to me.

checking...

No, it wasn't, but I have just activated 2FA using SMS messages. Not
optimal, but acceptable, if they already knew my phone number...

--
Cheers, Carlos.