On Fri, 27 May 2022 09:29:26 -0700, The Real Bev <bashley101@gmail.com>
wrote:

>On 05/26/2022 10:32 PM, Char Jackson wrote:
>> On Thu, 26 May 2022 12:00:32 -0700, The Real Bev <bashley101@gmail.com>
>
>> I think you're asking what happens if you can't access your mail server
>> for some period of time, and the answer is that the protocol that you
>> use to retrieve email (POP vs IMAP) is irrelevant, in that case. If you
>> can't access your mail server, you won't be able to send or receive
>> email for the duration of the service outage. Email that you've already
>> retrieved remains available, of course, exactly the same for both
>> protocols.
>
>Of course I can't access new mail when some part of the net is down.

Ok, good! We're in agreement.
>What I object to is the inability to access OLD mail -- perhaps
>preparing replies to send when the network goes back up. It always has
>come back up again, right?

I'm not familiar with an email client that doesn't automatically store a
local copy of your email, regardless of the protocol you use to retrieve
it from the server. If such a thing exists, others will have to chime
in.

>Outages used to be a lot more common than they are today, but it costs
>nothing (hard drive space is CHEAP now) to keep your own stuff within
>reach at all times. Well, maybe there will be problems if there's a
>power outage in your house and your laptop battery is dead, but we have
>to live dangerously sometimes :-)
>
>>>>>It's ALL cloud, I just want to keep my own stuff within reach.
>>>>
>>>> As above, obviously false.
>>>
>>>Any chance you're Rod Speed? You sound an awful lot like 'them'.
>>
>> I thought you had claimed that IMAP is "ALL cloud", which is false, so I
>> apologize if I misunderstood. Rod Speed would never do that.
>
>Unless you go to special efforts (moving your incoming mail to a
>'local' folder for processing) IMAP IS entirely in the cloud. When the
>net goes down you have NOTHING.

When the net goes down you won't have net access, but you'll still have
all of the email that has already been retrieved. Why wouldn't you?
You're making me think you use webmail or something.

>I would wager a dime (my sucker bet) that most users don't even think
>about saving stuff in a 'local' hierarchy.

I wouldn't be surprised to hear that most users just use webmail these
days. In that case, nothing typically gets lost, but your 'no access to
email without access to net' scenario starts to make sense.

nospam <nospam@nospam.invalid> wrote:
> In article <t6lqev$fr2$1@dont-email.me>, Chris <ithinkiam@gmail.com>
> wrote:
>
>>>>>> Over here anyone who tries to sue a company because they killed their cat
>>>>>> in
>>>>>> one of their magnetrons because previously drying the beast in an oven
>>>>>> worked fine would be "laughed", possibly literally, outof court. Our
>>>>>> legal
>>>>>> system (still) doesn't reward stupidity like that.
>>>>>
>>>>> Give it time. USA culture, like McDonald's, spreads.
>>>>
>>>> Nope. The law here prevents that. It assumes people are reasonable in their
>>>> behaviour. So suing McDs because *you* spilled *your* hot coffee on *your*
>>>> lap is not reasonable behaviour.
>>>
>>> it is when mcdonald's, by their own admission, knowingly served food
>>> that was unfit for human consumption, in particular, coffee that was
>>> about 20-30 degrees hotter than other restaurants and could cause
>>> severe burns within seconds, without any warning of the danger.
>>
>> So just because other restaurants serve cold coffee, they should do the
>> same? lol
>
> nobody was serving cold coffee.

ok. Luke warm.

> it's very simple: mcdonald's sold a product they knew could (and did)
> cause injuries, which occurred at the rate of approximately once every
> 5 days, and did absolutely nothing to mitigate it. they did not even
> test for its safety.

People choke on food all the time. Is that a dangerous product? Should
restaurants be forced to liquidise all food? Just in case.

> that's both unacceptable and illegal.

Of course it isn't. Coffee is meant to be served hot.

> other restaurants served hot coffee, but nowhere near hot enough to
> cause instant burns.
>
>>> mcdonald stated the high temperature created an aroma that increased
>>> sales.
>>>
>>> there were more than 700 burns in the previous ten years (that's about
>>> one *every* *five* days*), including children and instances where
>>> mcdonald's staff spilled it, and did nothing to reduce that number.
>>
>> In a population of 300m, that's tiny. I mean how many billions of coffees
>> do they sell in 10 years?
>
>> 5bn apparently
>> https://www.shopfood.com/restaurants/mcdonalds-coffee/
>
> that was actually one of mcdonald's claims, that the number of burns
> out of billions of cups coffee sold was minor. so what if people were
> injured. no big deal. they're just a number on a spreadsheet.

Of course it matters, but given that 99.999999% of customers are capable of
not burning themselves, it's clearly not a product failure, but a "user
error".

> not surprisingly, the jury found that to be reprehensible.

Whenever it's possible to extract a dollar from a business people are all
over it in the US. Whereas if it restricts their "freedoms" somehow then
who cares if 1m died. They were old and would have died anyway.

> it's a bit like the ford pinto in the 1970s, where ford knew the
> vehicle could explode in a rear-end collision but sold it anyway.
>
> ford chose to not fix the problem because statistically, it would be
> cheaper to pay off the families of who are injured or killed than make
> changes to the design of the vehicle so that it was actually safe.
>
> more recently, bridgestone found a problem with their tires and chose
> to recall them *before* any of them failed and caused harm. that's how
> it's supposed to work.
>
> <https://www.bridgestoneamericas.com/en/newsroom/press-releases/2022/bri
> dgestone-recalls-certain-firestone-transforce-tires>
> There are no known accidents or injuries involving tires subject to
> this recall. However, Bridgestone has determined that affected tires
> were not manufactured according to specification, and this could pose
> a safety risk. Bridgestone has notified regulatory agencies in the
> U.S. and Canada in accordance with applicable laws.
>
> in your world, a couple of tire blowouts and resulting car crashes out
> of billions of miles driven is no big deal. so what if a few people
> die.

No-one died from drinking a hot coffee properly. Whereas dying from driving
your car properly is definitely a problem.

>>> ms. liebeck initially asked that mcdonald's pay her medical expenses,
>>> which mcdonald's had done in previous cases, in this case, about $20k.
>>>
>>> mcdonald's said no, offering only $800.
>>>
>>> ms. liebeck sued, ultimately going to trial after attempts to settle
>>> out of court failed.
>>>
>>> mcdonald's was found to have a 'willful, reckless, malicious or wanton
>>> disregard' for the safety of its patrons (and not just ms. liebeck).
>>
>> By serving hot drinks? Sure. It may be the ruling but it's still dumb. The
>> law often gets things wrong.
>
> not that often, and in this case, it definitely did not.
>
> the law correctly states that you can't intentionally sell a product
> that causes harm.

What about alcohol or tobacco? Or, god forbid, a gun?

The ruling was and is an utter joke. The whole world knows it.

> that's why there are various safety tests, product recalls, etc.
>
> like you, the jury initially thought the whole thing was a farce. after
> all, some old lady spilled hot coffee on herself and sued.
>
> except that after learning the facts of the case, much of it from
> mcdonald's own testimony (which makes it even more compelling), the
> jury realized that mcdonald's didn't give a shit about the safety of
> their patrons.
>
> like ford and the pinto, customers were just a number on a spreadsheet.
>
> in previous instances, mcdonald's *did* cover for medical expenses
> (which means they knew they were doing something wrong, otherwise why
> pay), however, they thought that ms. liebeck was an old lady whom they
> could ignore and get out of it cheap.
>
> that turned out to be a bad decision on mcdonald's part.

Yup. Because they were afraid of a malicious, frivolous suit. Only possible
in the US.

> had mcdonald's simply paid her medical bills ($20k or so) or even
> settled in arbitration (which they also refused), as they did in
> previous instances, it would not have gone to trial and they wouldn't
> have been smacked down in court.
>
> it did go to trial and what the jury heard was that it was *not* just a
> one-time event, but a long pattern of unacceptable practices.
>
> put simply, the jury heard *all* of the facts (the trial itself took
> about a week) and overwhelmingly concluded that mcdonald's was liable.
>
>> Why not sue the car manufacturer for not providing cup holders?
>
> because cup holders had nothing to do with knowingly serving food that
> can burn on contact and is unfit for human consumption as served.
>
> the other incidents include spills *inside* the restaurant, including
> on kids (likely spilled by their parents), as well as mcdonald's own
> staff spilling it on people in the drive-thru.
>
> cup holders are irrelevant.

If the car had cupholders then no coffee would have been spilled.

>>> ms liebeck was awarded $200k in compensatory damages, reduced by 20%
>>> because she was found to be partly at fault
>>
>> Entirely at fault.
>
> nope. only 20% at fault (which is arguably quite generous).

Ridiculous.

> the vehicle was parked and she was the passenger, a perfectly normal
> situation in which one would remove the lid of a beverage.
>
>> In related news knives are sharp, flames burn and ice is
>> slippy.
>
> you are completely missing the point.

Hello pot. Kettle calling.

>>> (despite that she was the
>>> *passenger* in a *parked* vehicle), and an additional $2.7 million in
>>> punitive damages,
>>
>> This is what doesn't exist here. You can only sue for real or actual harm
>> or losses. The US punitive payouts are often ridiculous.
>
> she *did* have real and actual harm.
>
> she had third degree burns, requiring skin grafts and a lengthy
> recovery.

From her own mistake. McDs cannot be held responsible for that. In any sane
legal system, that is.

> that's quite a bit more than 'ouch, that was hot'.
>
> she originally asked for her medical expenses to be paid. mcdonald's
> said no.
>
> the punitive damages in this case was two days of coffee sales, which
> is relatively minor. it was also reduced on appeal, ultimately settling
> for an undisclosed sum believed to be a few hundred thousand dollars.
>
>>> which was roughly two days of coffee sales, reduced
>>> on appeal and ultimately settled for an undisclosed sum.
>>>
>>> <https://www.findlaw.com/injury/product-liability/the-mcdonald-s-coffee-
>>> cup-case-separating-mcfacts-from-mcfiction.html>
>>> <https://www.caoc.org/?pg=facts>
>>> <https://www.tortmuseum.org/liebeck-v-mcdonalds/>
>>>
>>> tl;dr - mcdonald's fucked up. big time.
>>
>> Nope.
>
> nope right back.
>
> read the facts of the case, not what you imagine them to be.

On 05/27/2022 02:12 PM, Char Jackson wrote:
> On Fri, 27 May 2022 09:29:26 -0700, The Real Bev <bashley101@gmail.com>
> wrote:
>
>>On 05/26/2022 10:32 PM, Char Jackson wrote:
>>> On Thu, 26 May 2022 12:00:32 -0700, The Real Bev <bashley101@gmail.com>
>>
>>> I think you're asking what happens if you can't access your mail server
>>> for some period of time, and the answer is that the protocol that you
>>> use to retrieve email (POP vs IMAP) is irrelevant, in that case. If you
>>> can't access your mail server, you won't be able to send or receive
>>> email for the duration of the service outage. Email that you've already
>>> retrieved remains available, of course, exactly the same for both
>>> protocols.
>>
>>Of course I can't access new mail when some part of the net is down.
>
> Ok, good! We're in agreement.
>
>>What I object to is the inability to access OLD mail -- perhaps
>>preparing replies to send when the network goes back up. It always has
>>come back up again, right?
>
> I'm not familiar with an email client that doesn't automatically store a
> local copy of your email, regardless of the protocol you use to retrieve
> it from the server. If such a thing exists, others will have to chime
> in.
>
>>Outages used to be a lot more common than they are today, but it costs
>>nothing (hard drive space is CHEAP now) to keep your own stuff within
>>reach at all times. Well, maybe there will be problems if there's a
>>power outage in your house and your laptop battery is dead, but we have
>>to live dangerously sometimes :-)
>>
>>>>>>It's ALL cloud, I just want to keep my own stuff within reach.
>>>>>
>>>>> As above, obviously false.
>>>>
>>>>Any chance you're Rod Speed? You sound an awful lot like 'them'.
>>>
>>> I thought you had claimed that IMAP is "ALL cloud", which is false, so I
>>> apologize if I misunderstood. Rod Speed would never do that.
>>
>>Unless you go to special efforts (moving your incoming mail to a
>>'local' folder for processing) IMAP IS entirely in the cloud. When the
>>net goes down you have NOTHING.
>
> When the net goes down you won't have net access, but you'll still have
> all of the email that has already been retrieved. Why wouldn't you?
> You're making me think you use webmail or something.

Not willingly! As I understand it, and as I experienced myself with my
new protonmail (IMAP, obviously) account, when you delete the mail at
their site with your computer it disappears from your phone -- barring
some sort of archiving process.

>>I would wager a dime (my sucker bet) that most users don't even think
>>about saving stuff in a 'local' hierarchy.
>
> I wouldn't be surprised to hear that most users just use webmail these
> days. In that case, nothing typically gets lost, but your 'no access to
> email without access to net' scenario starts to make sense.

Granted, such a need is probably rare; but STILL...

If I want to find an email that I'm pretty sure I received from Samsung
(I think, maybe it was Newegg or Tiger...) back in 2018 about that
tablet that stopped working I want to be able to find it NOW. I can
look at a list of perhaps 40 messages at a time that matched my search
criteria. Or I can make guesses. Or just go fish. I have yet to see a
webmail interface that will show me as many words at one time as I would
like. If you use a computer you can fill your screen with thousands of
words. LEGIBLE words. Catering to phone-users completely destroys this
capability.

The new addressbook in the latest Thunderbirds is screamingly inefficient.

--
Cheers, Bev
=====================================================================
If violence isn't solving the problem, you're not using enough of it.

In article <t6rhkn$u0j$1@dont-email.me>, The Real Bev
<bashley101@gmail.com> wrote:

> >>Unless you go to special efforts (moving your incoming mail to a
> >>'local' folder for processing) IMAP IS entirely in the cloud. When the
> >>net goes down you have NOTHING.
> >
> > When the net goes down you won't have net access, but you'll still have
> > all of the email that has already been retrieved. Why wouldn't you?
> > You're making me think you use webmail or something.
>
> Not willingly! As I understand it, and as I experienced myself with my
> new protonmail (IMAP, obviously) account,

not obviously, because unlike most email providers, proton *cannot* use
standard imap (or pop) because it's end-to-end encrypted. this is a
*feature*, and one reason why proton is popular.

proton does offer an imap bridge that runs locally, with an encrypted
connection to their servers, but only for paid accounts, which i doubt
you have.

with the bridge, encryption/decryption is done locally, allowing any
standard email client to be used, which expects email to be in clear
text. on the other side of the bridge, from your computer to proton,
everything is encrypted.

without the bridge, you are limited to webmail, which does the
encryption/decryption locally via javascript.

other email providers (gmail, outlook, yahoo, etc.) offer standard
pop/imap interfaces, which are not encrypted.

> when you delete the mail at
> their site with your computer it disappears from your phone

as it should.

otherwise everything would be out of sync and you wouldn't know on
which device a particular email was stored, making your example below
of searching for a samsung tablet very difficult.

if you want to keep the email, don't delete it.

> -- barring
> some sort of archiving process.

which is available, and with labels/folders for organization.

you can also archive locally, although with proton, you would need the
bridge (not required for others).

> If I want to find an email that I'm pretty sure I received from Samsung
> (I think, maybe it was Newegg or Tiger...) back in 2018 about that
> tablet that stopped working I want to be able to find it NOW.

that's very easy to do, especially if you tagged those emails, such as
'2018', 'receipts', 'tablet', 'samsung', 'purchases over $100' or
whatever else fits the content.

absent that, a keyword search and/or a date range would work, or some
combination thereof.

> I can
> look at a list of perhaps 40 messages at a time that matched my search
> criteria. Or I can make guesses. Or just go fish.

you need better search criteria if you're getting multiple sets of 40
messages for what should be a simple search for a purchase of a
specific product in 2018.

> I have yet to see a
> webmail interface that will show me as many words at one time as I would
> like.

then you haven't seen very many webmail interfaces. they do vary. some
are quite good, while others not so much.

> If you use a computer you can fill your screen with thousands of
> words. LEGIBLE words. Catering to phone-users completely destroys this
> capability.

it doesn't destroy any capability and what you describe can be done via
webmail.

> The new addressbook in the latest Thunderbirds is screamingly inefficient.

then switch to something that is more efficient.

there are many other options.

you complain a lot but never make any changes to address the complaints.

On May 28, 2022, R.Wieser wrote
(in article<news:t6qq0m$14j9$1@gioia.aioe.org>):

>> Because you were snotty and condescending and had no good intentions.
>
> Than with that judgement you blocked yourself and thus have only yourself to
> blame.

The snotty condescending asshat with nothing to offer anyone has decided to
block me for referring to his own posts of no good intentions.

Oh no. Not that. Anything but that.

Ron, the humblest guy in town.

Char Jackson wrote:
> When the net goes down you won't have net access, but you'll still have
> all of the email that has already been retrieved. Why wouldn't you?
> You're making me think you use webmail or something.

Did someone say 'Bingo'

--
....w¡ñ§±¤ñ

The Real Bev <bashley101@gmail.com> wrote:
> On 05/27/2022 02:12 PM, Char Jackson wrote:
>> On Fri, 27 May 2022 09:29:26 -0700, The Real Bev <bashley101@gmail.com>
>> wrote:
>>
>>> On 05/26/2022 10:32 PM, Char Jackson wrote:
>>>> On Thu, 26 May 2022 12:00:32 -0700, The Real Bev <bashley101@gmail.com>
>>>
>>>> I think you're asking what happens if you can't access your mail server
>>>> for some period of time, and the answer is that the protocol that you
>>>> use to retrieve email (POP vs IMAP) is irrelevant, in that case. If you
>>>> can't access your mail server, you won't be able to send or receive
>>>> email for the duration of the service outage. Email that you've already
>>>> retrieved remains available, of course, exactly the same for both
>>>> protocols.
>>>
>>> Of course I can't access new mail when some part of the net is down.
>>
>> Ok, good! We're in agreement.
>>
>>> What I object to is the inability to access OLD mail -- perhaps
>>> preparing replies to send when the network goes back up. It always has
>>> come back up again, right?
>>
>> I'm not familiar with an email client that doesn't automatically store a
>> local copy of your email, regardless of the protocol you use to retrieve
>> it from the server. If such a thing exists, others will have to chime
>> in.
>>
>>> Outages used to be a lot more common than they are today, but it costs
>>> nothing (hard drive space is CHEAP now) to keep your own stuff within
>>> reach at all times. Well, maybe there will be problems if there's a
>>> power outage in your house and your laptop battery is dead, but we have
>>> to live dangerously sometimes :-)
>>>
>>>>>>> It's ALL cloud, I just want to keep my own stuff within reach.
>>>>>>
>>>>>> As above, obviously false.
>>>>>
>>>>> Any chance you're Rod Speed? You sound an awful lot like 'them'.
>>>>
>>>> I thought you had claimed that IMAP is "ALL cloud", which is false, so I
>>>> apologize if I misunderstood. Rod Speed would never do that.
>>>
>>> Unless you go to special efforts (moving your incoming mail to a
>>> 'local' folder for processing) IMAP IS entirely in the cloud. When the
>>> net goes down you have NOTHING.
>>
>> When the net goes down you won't have net access, but you'll still have
>> all of the email that has already been retrieved. Why wouldn't you?
>> You're making me think you use webmail or something.
>
> Not willingly! As I understand it, and as I experienced myself with my
> new protonmail (IMAP, obviously) account, when you delete the mail at
> their site with your computer it disappears from your phone -- barring
> some sort of archiving process.

You make that sound like a bad thing. Why would you want the deleted email
to remain on your phone?

The advantage of IMAP is that all your email is available everywhere you
want it and importantly all the email is in sync.

And just to be clear that doesn't mean your email is only online/cloud.
There's usually a local copy available so that you can find emails offline.

RonTheGuy,

>>> Because you were snotty and condescending and had no good intentions.
>>
>> Than with that judgement you blocked yourself and thus have only yourself
>> to
>> blame.
>
> The snotty condescending asshat with nothing to offer anyone has decided
> to
> block me for referring to his own posts of no good intentions.
>
> Oh no. Not that. Anything but that.

All I see is you repeating the same thing while not providing any
underbuilding for it.

.... say, isn't that what you are currently accusing me of ? :-p

Regards,
Rudy Wieser

Chris,

> You make that sound like a bad thing. Why would you want the deleted email
> to remain on your phone?

Maybe because its relevant on the device that you can take with you, but not
on the 'puter stationary in your house ? Just take anything like a
route description. Or an appointment.

> The advantage of IMAP is that all your email is available everywhere
> you want it and importantly all the email is in sync.

Its either always accessible and you do not need a local copies of the
messages, or it isn't and you can (temporary) be out of sync. Not both at
at the same time.

> And just to be clear that doesn't mean your email is only online/cloud.
> There's usually a local copy available so that you can find emails
> offline.

.... for the times you can not reach the intarwebz perhaps ? :-p

From my POV I see you attribute features of an email client to the IMAP
mechanism. Which muddies the whole discussion quite a bit. As said,
using a client program I can make POP look like IMAP and vice-verse.

Regards,
Rudy Wieser

On Fri, 27 May 2022 16:12:45 -0500
Char Jackson <none@none.invalid> wrote:

> I'm not familiar with an email client that doesn't automatically
> store a local copy of your email, regardless of the protocol you use
> to retrieve it from the server. If such a thing exists, others will
> have to chime in.

Unless I totally misunderstand you, IMAP stores mail on a server (run
by some email service provider), and there is no local copy retained
after the mail item is read.

If you want mail to be retained locally you need something like
Mailstore.

In article <20220528115910.2d8dade8@lmde>, mechanic
<mechanic@example.net> wrote:

> > I'm not familiar with an email client that doesn't automatically
> > store a local copy of your email, regardless of the protocol you use
> > to retrieve it from the server. If such a thing exists, others will
> > have to chime in.
>
> Unless I totally misunderstand you, IMAP stores mail on a server (run
> by some email service provider), and there is no local copy retained
> after the mail item is read.

what you misunderstand is imap itself, as do many others.

a local copy is cached, and can be optionally moved off the server and
archived to wherever you want. however, if it is moved off the server,
it will be inaccessible to devices other than the one on which it was
archived.

In article <t6spq0$1jcv$1@gioia.aioe.org>, R.Wieser
<address@not.available> wrote:

> > You make that sound like a bad thing. Why would you want the deleted email
> > to remain on your phone?
>
> Maybe because its relevant on the device that you can take with you, but not
> on the 'puter stationary in your house ? Just take anything like a
> route description. Or an appointment.

if it's relevant, then it wouldn't be deleted.

if it's a route description, it could be deleted after arriving, and
likely never even seen on a computer in the house.

> > The advantage of IMAP is that all your email is available everywhere
> > you want it and importantly all the email is in sync.
>
> Its either always accessible and you do not need a local copies of the
> messages, or it isn't and you can (temporary) be out of sync. Not both at
> at the same time.

that is false.

> > And just to be clear that doesn't mean your email is only online/cloud.
> > There's usually a local copy available so that you can find emails
> > offline.
>
> ... for the times you can not reach the intarwebz perhaps ? :-p
>
> From my POV I see you attribute features of an email client to the IMAP
> mechanism. Which muddies the whole discussion quite a bit. As said,
> using a client program I can make POP look like IMAP and vice-verse.

either you have magical powers or you don't understand imap.

given that imap can do many things that pop cannot, it's *impossible*
to 'make pop look like imap', at least not without magical powers.

however, since imap can do everything pop can do, it's very easy to do
the opposite, make imap look like pop, although that voids many of the
advantages of imap.

On Sat, 28 May 2022 11:59:10 +0100, mechanic <mechanic@example.net>
wrote:

>On Fri, 27 May 2022 16:12:45 -0500
>Char Jackson <none@none.invalid> wrote:
>
>> I'm not familiar with an email client that doesn't automatically
>> store a local copy of your email, regardless of the protocol you use
>> to retrieve it from the server. If such a thing exists, others will
>> have to chime in.
>
>Unless I totally misunderstand you, IMAP stores mail on a server (run
>by some email service provider), and there is no local copy retained
>after the mail item is read.
>
>If you want mail to be retained locally you need something like
>Mailstore.

Neither of those two statements is correct. I use Thunderbird on my
computer and Bluemail on my phone. Read IMAP messages are retained
locally on both. The same is true of the several other e-mail clients
I've used on both.

On Sat, 28 May 2022 10:34:05 -0400
nospam <nospam@nospam.invalid> wrote:

> In article <20220528115910.2d8dade8@lmde>, mechanic
> <mechanic@example.net> wrote:
>
> > > I'm not familiar with an email client that doesn't automatically
> > > store a local copy of your email, regardless of the protocol you
> > > use to retrieve it from the server. If such a thing exists,
> > > others will have to chime in.
> >
> > Unless I totally misunderstand you, IMAP stores mail on a server
> > (run by some email service provider), and there is no local copy
> > retained after the mail item is read.
>
> what you misunderstand is imap itself, as do many others.
>
> a local copy is cached, and can be optionally moved off the server and
> archived to wherever you want. however, if it is moved off the server,
> it will be inaccessible to devices other than the one on which it was
> archived.

What is cached is maybe a list of headers, not the whole message.
Obviously messages can be copied, replied to and so forth. You
won't get far with that if your network connection is cut. If you
want to move or delete a message, you need to ensure the connection
is restored. This is how IMAP works. If it's implemented properly.

In article <20220528162902.2ce72464@lmde>, mechanic
<mechanic@example.net> wrote:

>
> What is cached is maybe a list of headers, not the whole message.

nope. it's the whole message, or more commonly, messages (plural).

> Obviously messages can be copied, replied to and so forth. You
> won't get far with that if your network connection is cut. If you
> want to move or delete a message, you need to ensure the connection
> is restored. This is how IMAP works. If it's implemented properly.

no, that's not how imap works.

nospam,

>> What is cached is maybe a list of headers, not the whole message.
>
> nope. it's the whole message, or more commonly, messages (plural).

Wrong. Its upto the client program to decide.

But mechanic is right, that is how most email clients do it. For good
reasons.

> no, that's not how imap works.

Yes, that is how it works.

If you do not like it that I just tell you wrong but do not explain why ?
Well, I'm only trying to behave like you yourself are doing. So, tough
luck. :-p

Regards,
Rudy Wieser

On 05/27/2022 06:13 PM, nospam wrote:
> In article <t6rhkn$u0j$1@dont-email.me>, The Real Bev

> you complain a lot but never make any changes to address the complaints.

The required changes are what I'm complaining about!

--
Cheers, Bev
Some people are like Slinkies... Not really good for
anything, but they still bring a smile to your face
when you push them down a flight of stairs.

In article <t6ti9q$1m59$1@gioia.aioe.org>, R.Wieser
<address@not.available> wrote:

>
> >> What is cached is maybe a list of headers, not the whole message.
> >
> > nope. it's the whole message, or more commonly, messages (plural).
>
> Wrong. Its upto the client program to decide.

not wrong. email apps download the headers *and* message bodies.

some email apps have the option to skip large attachments, often useful
for metered connections (e.g., cellular).

you're also snipping to alter context, which you often do and is not
going to go unnoticed.

> But mechanic is right, that is how most email clients do it. For good
> reasons.

no, that's *not* how most email apps do it.

what they do is download new email in its entirety, caching it locally,
which can easily be used for offline reading and replying.

any replies made while offline are queued until the user reconnects.

in other words, it's a sync operation.

you're also ignoring push.

> > no, that's not how imap works.
>
> Yes, that is how it works.

no, it's *not* how it works.

> If you do not like it that I just tell you wrong but do not explain why ?

you don't explain why because don't understand it yourself and *can't*
explain it.

R.Wieser <address@not.available> wrote:
> Chris,
>
>> You make that sound like a bad thing. Why would you want the deleted email
>> to remain on your phone?
>
> Maybe because its relevant on the device that you can take with you, but not
> on the 'puter stationary in your house ? Just take anything like a
> route description. Or an appointment

And then you end up with some emails existing in some devices and not on
others. A recipe for confusion. Why wouldn't you just keep them all sync'd.

>> The advantage of IMAP is that all your email is available everywhere
>> you want it and importantly all the email is in sync.
>
> Its either always accessible and you do not need a local copies of the
> messages, or it isn't and you can (temporary) be out of sync. Not both at
> at the same time.

That doesn't makes sense. You've got four conditions and treating them like
two.

>> And just to be clear that doesn't mean your email is only online/cloud.
>> There's usually a local copy available so that you can find emails
>> offline.
>
> ... for the times you can not reach the intarwebz perhaps ? :-p
>
> From my POV I see you attribute features of an email client to the IMAP
> mechanism. Which muddies the whole discussion quite a bit. As said,
> using a client program I can make POP look like IMAP and vice-verse.
>
> Regards,
> Rudy Wieser
>
>
>

nospam,

> not wrong. email apps download the headers *and* message bodies.

Wrong again.

> no, that's *not* how most email apps do it.

Yes it is.

> you're also ignoring push.

Which also doesn't work without a connection. You lose again.

> no, it's *not* how it works.

Yes, it is.

Are you enjoying yourself yet ?

Regards,
Rudy Wieser

Chris,

> And then you end up with some emails existing in some devices and not on
> others.

Yep.

> A recipe for confusion.

Really ? The route description would lose its value directly after the
endpoint is reached - and the message could than be deleted from the mobile
device.

> Why wouldn't you just keep them all sync'd.

So anyone using one of the other devices sees all kinds of messages they
have zero use for and just clutter their "do I have an important message?"
peek ?

I would not like that. But, to everyone his own. As long as its a
something you can configure.

> That doesn't makes sense. You've got four conditions and treating them
> like two.

Which four ? Afaik I've only named two.

Regards,
Rudy Wieser

In article <t6tmrh$1q18$1@gioia.aioe.org>, R.Wieser
<address@not.available> wrote:

>
> > not wrong. email apps download the headers *and* message bodies.
>
> Wrong again.

not wrong. they download headers *and* message bodies of new emails and
send any unsent queued mail.

as i said (which you snipped), it's a sync operation.

> > no, that's *not* how most email apps do it.
>
> Yes it is.

you snipped to alter context, again.

> > you're also ignoring push.
>
> Which also doesn't work without a connection.

nor does downloading headers, message bodies, or anything else for that
matter.

> You lose again.

i'm not the one who is losing.

> > no, it's *not* how it works.
>
> Yes, it is.

nope. what you describe is *not* how it works.

On 05/28/2022 10:09 AM, Chris wrote:
> R.Wieser <address@not.available> wrote:
>> Chris,
>>
>>> You make that sound like a bad thing. Why would you want the deleted email
>>> to remain on your phone?
>>
>> Maybe because its relevant on the device that you can take with you, but not
>> on the 'puter stationary in your house ? Just take anything like a
>> route description. Or an appointment
>
> And then you end up with some emails existing in some devices and not on
> others. A recipe for confusion. Why wouldn't you just keep them all sync'd.

Because I only want to see URGENT RIGHT NOW messages on my phone, which
I use ONLY RARELY (when I'm away from home and within free wifi hotspot
range) for this purpose. Anything else is just clutter. My REAL email
device is my computer, on which I want to keep everything I want to
actually KEEP regardless of internet status.

Apparently most people use only (or predominantly) their phones for
email. Their preferences would be very different.

--
Cheers, Bev
"I don't care who your father is! Drop that cross
one more time and you're out of the parade!"

On Sat, 28 May 2022 11:59:10 +0100, mechanic <mechanic@example.net>
wrote:

>On Fri, 27 May 2022 16:12:45 -0500
>Char Jackson <none@none.invalid> wrote:
>
>> I'm not familiar with an email client that doesn't automatically
>> store a local copy of your email, regardless of the protocol you use
>> to retrieve it from the server. If such a thing exists, others will
>> have to chime in.
>
>Unless I totally misunderstand you, IMAP stores mail on a server (run
>by some email service provider), and there is no local copy retained
>after the mail item is read.

Like I said, I've not seen an email client that works that way. If I was
looking for a new/different client and I found one that doesn't store a
local copy, I'd immediately reject it.

>If you want mail to be retained locally you need something like
>Mailstore.

Or any decent email client.

On Sat, 28 May 2022 16:29:28 +0100, mechanic <mechanic@example.net>
wrote:

>On Sat, 28 May 2022 10:34:05 -0400
>nospam <nospam@nospam.invalid> wrote:
>
>> In article <20220528115910.2d8dade8@lmde>, mechanic
>> <mechanic@example.net> wrote:
>>
>> > > I'm not familiar with an email client that doesn't automatically
>> > > store a local copy of your email, regardless of the protocol you
>> > > use to retrieve it from the server. If such a thing exists,
>> > > others will have to chime in.
>> >
>> > Unless I totally misunderstand you, IMAP stores mail on a server
>> > (run by some email service provider), and there is no local copy
>> > retained after the mail item is read.
>>
>> what you misunderstand is imap itself, as do many others.
>>
>> a local copy is cached, and can be optionally moved off the server and
>> archived to wherever you want. however, if it is moved off the server,
>> it will be inaccessible to devices other than the one on which it was
>> archived.
>
> What is cached is maybe a list of headers, not the whole message.

Which client does that? I want to be sure to avoid it. Fortunately, the
clients I've looked at don't work that way. They keep a local copy of
all (synched) email.

> Obviously messages can be copied, replied to and so forth. You
> won't get far with that if your network connection is cut. If you
> want to move or delete a message, you need to ensure the connection
> is restored. This is how IMAP works. If it's implemented properly.

That last part is not true. That is NOT how IMAP works.