"J. P. Gilliver (John)" <G6JPG@255soft.uk> wrote:

> But presumably LISTing just UIDs is a lot quicker than downloading
> whole messages, or even just their headers (how big is an average
> header these days? About 2-4k I suspect.) So if this could be done -
> even if aborted after five or ten minutes - and then something like
> Notepad used to create a file with DELE before each MID, then another
> session run to upload those commands, some progress could be made, in
> chunks of a size big enough to make a difference.

Yep, possible, just like I mentioned using a client-side script to use
the LIST or UIDL commands and then a for-loop to go through the results
to issue a DELE for each item. No date ranging, though, just en masse
deleting. But why bother doing that yourself when you can contact
support to get your account reset which also wipes all messages from
your account?

> Presumably less time (by a manyfold factor) than actually downloading
> hundreds of thousands of complete messages, though?

I didn't say to do LIST, RETR, and DELE. Just do LIST and DELE. If you
look at the sample script that I found, it never does a RETR. If the
intent is to delete without review, RETR is superfluous.

> That's why I was suggesting aborting the LIST command after a few
> minutes, so you can make a batch of DELE commands that is manageable,
> and ends with a QUIT.

You could hardcode the script to add the UIDs (or indexes) in the
for-loop. You could have the script do en masse deletes for all
messages, not just a few at a time. You could write the script to pipe
in the list of UIDs, so the code just does the for-loop but gets the
UIDs piped into the script.

> That'd be the bummer [telnet not supporting TLS to get past
> establishing a session and the USER and PASS commands].

Encrypting the session (or, at least, the login portion) has long been a
requirement to protect the login credentials from hackers sniffing the
traffic. I doubt you'd want your client not using SSL/TLS to encrypt
your login credentials, and even your mail session.

I know local e-mail clients that don't support TLS can use the sTunnel
proxy. The client makes insecure connection to the local sTunnel proxy.
sTunnel (which does support TLS) makes the encrypted connection to the
server. You'd "telnet localhost <port>" where the sTunnel proxy on your
same host is listening for insecure connects on the specified port. You
configure sTunnel, for connections on that particular port, to make
outbound secure connections to a server and its port.

> If available [to get tech support to reset the account], that sounds
> by far the best solution (-:!

The first-level, um, tech (aka phone monkey) you reach won't have the
admin rights to do an account reset. They often won't even connect you
to an admin with privileges to manage the accounts. It take a lot of
effort, and a lot of blathering, to get the monkey to transfer you to a
sysadmin. You can't do that via chat. They cannot connect you to
anyone else, just take a report and forward it somewhere. You need to
make a phone call to get past the phone monkey to escalate (use that
word as they seem to understand what that means) to an admin.

VanguardLH wrote:
> "J. P. Gilliver (John)" <G6JPG@255soft.uk> wrote:
>
>> But presumably LISTing just UIDs is a lot quicker than downloading
>> whole messages, or even just their headers (how big is an average
>> header these days? About 2-4k I suspect.) So if this could be done -
>> even if aborted after five or ten minutes - and then something like
>> Notepad used to create a file with DELE before each MID, then another
>> session run to upload those commands, some progress could be made, in
>> chunks of a size big enough to make a difference.
>
> Yep, possible, just like I mentioned using a client-side script to use
> the LIST or UIDL commands and then a for-loop to go through the results
> to issue a DELE for each item. No date ranging, though, just en masse
> deleting. But why bother doing that yourself when you can contact
> support to get your account reset which also wipes all messages from
> your account?
>
>> Presumably less time (by a manyfold factor) than actually downloading
>> hundreds of thousands of complete messages, though?
>
> I didn't say to do LIST, RETR, and DELE. Just do LIST and DELE. If you
> look at the sample script that I found, it never does a RETR. If the
> intent is to delete without review, RETR is superfluous.
>
>> That's why I was suggesting aborting the LIST command after a few
>> minutes, so you can make a batch of DELE commands that is manageable,
>> and ends with a QUIT.
>
> You could hardcode the script to add the UIDs (or indexes) in the
> for-loop. You could have the script do en masse deletes for all
> messages, not just a few at a time. You could write the script to pipe
> in the list of UIDs, so the code just does the for-loop but gets the
> UIDs piped into the script.
>
>> That'd be the bummer [telnet not supporting TLS to get past
>> establishing a session and the USER and PASS commands].
>
> Encrypting the session (or, at least, the login portion) has long been a
> requirement to protect the login credentials from hackers sniffing the
> traffic. I doubt you'd want your client not using SSL/TLS to encrypt
> your login credentials, and even your mail session.
>
> I know local e-mail clients that don't support TLS can use the sTunnel
> proxy. The client makes insecure connection to the local sTunnel proxy.
> sTunnel (which does support TLS) makes the encrypted connection to the
> server. You'd "telnet localhost <port>" where the sTunnel proxy on your
> same host is listening for insecure connects on the specified port. You
> configure sTunnel, for connections on that particular port, to make
> outbound secure connections to a server and its port.
>
>> If available [to get tech support to reset the account], that sounds
>> by far the best solution (-:!
>
> The first-level, um, tech (aka phone monkey) you reach won't have the
> admin rights to do an account reset. They often won't even connect you
> to an admin with privileges to manage the accounts. It take a lot of
> effort, and a lot of blathering, to get the monkey to transfer you to a
> sysadmin. You can't do that via chat. They cannot connect you to
> anyone else, just take a report and forward it somewhere. You need to
> make a phone call to get past the phone monkey to escalate (use that
> word as they seem to understand what that means) to an admin.

The LIST command on my POP3 server (inside a VM),
doesn't give enough info.

The TOP command gives what appears to be a full header and zero body.

https://i.postimg.cc/G2qNBBTW/telnet-pop3.gif

Using gawk.exe, you can write a script that calls telnet and
pipes the input and output of telnet into the script. This allows
a script to be written, to drive POP3 automatically (as you desire).
Gawk can have multiple files open at the same time, so that if you
need to generate a logfile, that can be done too.

Paul

On Sun, 25 Jul 2021 23:18:40 -0400, Paul <nospam@needed.invalid> wrote:

>J. P. Gilliver (John) wrote:
>> On Sun, 25 Jul 2021 at 13:03:34, Paul <nospam@needed.invalid> wrote (my
>> responses usually follow points raised):
>> []
>>> But pulling all 260000, even if the receiving end has the worlds
>>> best rules engine, that would take many tries, analysis of
>>> failures, and so on.
>>>
>>> Paul
>>
>> Plus it just seems wrong to download messages just to delete them

There's nothing wrong about it. If it's your email, it's yours to do what
you like. I know a lot of email admins and there isn't one who would tell
you that it's wrong to download your email. That's kind of the whole point,
isn't it. The entire purpose of an email server is so that its users can
send and receive (download) email. If the provider has a policy that allows
an email store to grow to 33 GB, then they obviously have a policy that
allows you to download all or part of it.

>> immediately. OK, with fast everything these days, we sometimes _do_ do
>> things inefficiently, but when 33G of messages is involved ...
>
>Guess it depends on your "cap".
>
>One of the companies here, which is proud of itself,
>currently offers a 50GB/mo cap. So yeah, you'd be trembling
>in your boots, at the prospect of 33GB worth of work to do.
>That could easily nudge you into extra-charges country
>for that month.

I forgot that some people still have a monthly data allowance. I haven't
had one since about 2001/2002.

--

Char Jackson

Char Jackson wrote:
> On Sun, 25 Jul 2021 23:18:40 -0400, Paul <nospam@needed.invalid> wrote:
>
>> J. P. Gilliver (John) wrote:
>>> On Sun, 25 Jul 2021 at 13:03:34, Paul <nospam@needed.invalid> wrote (my
>>> responses usually follow points raised):
>>> []
>>>> But pulling all 260000, even if the receiving end has the worlds
>>>> best rules engine, that would take many tries, analysis of
>>>> failures, and so on.
>>>>
>>>> Paul
>>> Plus it just seems wrong to download messages just to delete them
>
> There's nothing wrong about it. If it's your email, it's yours to do what
> you like. I know a lot of email admins and there isn't one who would tell
> you that it's wrong to download your email. That's kind of the whole point,
> isn't it. The entire purpose of an email server is so that its users can
> send and receive (download) email. If the provider has a policy that allows
> an email store to grow to 33 GB, then they obviously have a policy that
> allows you to download all or part of it.

But that's the puzzling/entertaining part :-)

How did they manage to allow a customer to suck up 33GB
of storage space ?

Maybe there is a line on the bill from the ISP...

"Excess Storage - $5 per month"

Paul

"Paul" <nospam@needed.invalid> wrote in message
news:sdlo7b$18e8$1@gioia.aioe.org...
>> If the provider has a policy that allows
>> an email store to grow to 33 GB, then they obviously have a policy that
>> allows you to download all or part of it.
>
> But that's the puzzling/entertaining part :-)
>
> How did they manage to allow a customer to suck up 33GB
> of storage space ?

Yes, that mystified me as well.

I had a report from the customer this morning that he did a send/receive and
Outlook received the remaining 5000 / 1.5 GB emails since January without
any problem. That was without any config change (*) in Outlook since the
last time it was tried (and failed) when there were still 260,000 / 33 GB.

As an aside, someone up-thread suggested using IMAP rather than POP. I'm
always cautious about IMAP because the emails remain on the server, so if a
message/folder is accidentally deleted, you have to ask the ISP to retrieve
it from a backup. With POP, you get a copy of all received emails and so you
can control what you backup and can (as long as you know how) retrieve as
much or as little as you need. POP is also an advantage on a device that
doesn't always have an internet connection - a laptop, phone or tablet that
may sometimes be out of mobile internet range. With POP, you can search
emails that you have already received even when you are off-line, though of
course you can't receive any new ones or reply to any emails until you are
online again.

(*) Unless he's changed anything since the last time I was there, and I'm
not sure he has the knowledge or confidence to do that.

Paul <nospam@needed.invalid> wrote:

> The LIST command on my POP3 server (inside a VM), doesn't give enough
> info.
>
> The TOP command gives what appears to be a full header and zero body.
>
>
> https://i.postimg.cc/G2qNBBTW/telnet-pop3.gif
>
> Using gawk.exe, you can write a script that calls telnet and
> pipes the input and output of telnet into the script. This allows
> a script to be written, to drive POP3 automatically (as you desire).
> Gawk can have multiple files open at the same time, so that if you
> need to generate a logfile, that can be done too.

LIST just returns the indexes of messages. Hopefully your local client
and the server don't get out of sync as to which indexes were previously
retrieved by the client. The UIDL command just returns the UIDs of the
messages, and is more accurate, specific to each message, and doesn't
rely on indexing. You don't need headers to issue a DELE command. You
can either use indexes of messages or their UIDs.

If the OP is going to delete en masse, LIST to get the indexes or UIDL
to get a list of UIDs followed by a for-loop of DELEs will work. I
already mentioned LIST and UIDL do not return any other attributes of a
message, like dates. The Overview and Articles databases just track
message IDs.

Or, are you thinking about doing a date-range deletion in the script's
for-loop? The TOP command (without an argument which specifies how many
lines of the body to include) just returns the headers of a message.
Your script would then have to parse the headers to find the Date header
although the Received header is more accurate. The Date header is added
by the client when it first starts to compose a message. The message
could sit for hours, days, or weeks in the sender's Outbox or Drafts
folder. The first Received header listed in the headers is the last one
prepended. Received headers get prepended to a message as it bounces
through each server, so they are listed in newest-to-oldest in top-down
order. The Date header is not when they sent their message, only when
they first composed it. Received header shows when it showed up in your
account. Also, in the script, if doing date-ranged deleted, to bias the
datestamps to your timezone or to GMT, so the range doesn't go outside
the expected date and times.

On Mon, 26 Jul 2021 at 01:12:04, Char Jackson <none@none.invalid> wrote
(my responses usually follow points raised):
>On Sun, 25 Jul 2021 23:18:40 -0400, Paul <nospam@needed.invalid> wrote:
>
>>J. P. Gilliver (John) wrote:
>>> On Sun, 25 Jul 2021 at 13:03:34, Paul <nospam@needed.invalid> wrote (my
>>> responses usually follow points raised):
>>> []
>>>> But pulling all 260000, even if the receiving end has the worlds
>>>> best rules engine, that would take many tries, analysis of
>>>> failures, and so on.
>>>>
>>>> Paul
>>>
>>> Plus it just seems wrong to download messages just to delete them
>
>There's nothing wrong about it. If it's your email, it's yours to do what
>you like. I know a lot of email admins and there isn't one who would tell
>you that it's wrong to download your email. That's kind of the whole point,

You _are_ trolling, aren't you? I didn't say it seems wrong to download
messages; I said it seems wrong to download messages just to delete
them. (OK, I didn't specifically say "without looking at them", but I
think a reasonable person would deduce that that's what I meant.)

>isn't it. The entire purpose of an email server is so that its users can
>send and receive (download) email. If the provider has a policy that allows
>an email store to grow to 33 GB, then they obviously have a policy that
>allows you to download all or part of it.
>
When I said "wrong", I meant "pointless" and/or "a waste of everybody's
time". I agree that if, as you say, a provider allows such storage, they
probably let you have access to it - but that doesn't make it a sensible
thing to do if all you're going to do is delete them unread.
[]
>I forgot that some people still have a monthly data allowance. I haven't
>had one since about 2001/2002.
>
I'd forgotten that too, though it is a consideration; it was more a
matter of the time needed, even at today's speeds, to download 33G.
(Especially if doing so didn't solve the problem.)

Sounds as if the problem has been solved anyway.
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

The first objective of any tyrant in Whitehall would be to make Parliament
utterly subservient to his will; and the next to overturn or diminish trial by
jury ..." Lord Devlin (http://www.holbornchambers.co.uk)

On Mon, 26 Jul 2021 at 12:28:34, NY <me@privacy.invalid> wrote (my
responses usually follow points raised):
[]
>I had a report from the customer this morning that he did a
>send/receive and Outlook received the remaining 5000 / 1.5 GB emails
>since January without any problem. That was without any config change
>(*) in Outlook since the last time it was tried (and failed) when there
>were still 260,000 / 33 GB.
>
So sounds like all is running smoothly again.

Provided you interact with/visit this person often enough to ensure
proper backups (sounds like he's probably incapable), can I suggest you
tweak his Outlook to _not_ "leave copies on the server" in future?
Please (-:?
>
>As an aside, someone up-thread suggested using IMAP rather than POP.
>I'm always cautious about IMAP because the emails remain on the server,
>so if a message/folder is accidentally deleted, you have to ask the ISP
>to retrieve it from a backup. With POP, you get a copy of all received
>emails and so you can control what you backup and can (as long as you
>know how) retrieve as much or as little as you need. POP is also an
>advantage on a device that doesn't always have an internet connection -
>a laptop, phone or tablet that may sometimes be out of mobile internet
>range. With POP, you can search emails that you have already received
>even when you are off-line, though of course you can't receive any new
>ones or reply to any emails until you are online again.
>
I too don't like IMAP - it seems too much a buying into "cloud" (i. e.
"someone else's computer") philosophy: never being 100% sure where my
emails _are_. I realise I am in a significant minority in this; at least
you've shown me I am not alone!
[]
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

The first objective of any tyrant in Whitehall would be to make Parliament
utterly subservient to his will; and the next to overturn or diminish trial by
jury ..." Lord Devlin (http://www.holbornchambers.co.uk)

On Mon, 26 Jul 2021 12:28:34 +0100, "NY" <me@privacy.invalid> wrote:

>As an aside, someone up-thread suggested using IMAP rather than POP. I'm
>always cautious about IMAP because the emails remain on the server, so if a

On the server, as well as on every machine running an email program that
uses IMAP to sync to the same account on the server.

If your guy had been using IMAP all this time instead of POP, he wouldn't
be in this situation in the first place. Outlook would have complained long
ago, long before it accumulated 260,000 emails in its Inbox folder. He
would have dealt with it before it got out of hand.

The main problem here, the root cause of the issue that you've apparently
been asked to help with, is that the guy was using POP instead of IMAP.
Everything comes back to that.

>message/folder is accidentally deleted, you have to ask the ISP to retrieve
>it from a backup.

Or retrieve it from your own local backup. That'll usually be faster and
easier, assuming the person actually creates backups.

>With POP, you get a copy of all received emails and so you
>can control what you backup and can (as long as you know how) retrieve as
>much or as little as you need. POP is also an advantage on a device that
>doesn't always have an internet connection - a laptop, phone or tablet that
>may sometimes be out of mobile internet range. With POP, you can search
>emails that you have already received even when you are off-line, though of
>course you can't receive any new ones or reply to any emails until you are
>online again.

Exactly the same with IMAP. Where's the POP advantage?

--

Char Jackson

VanguardLH wrote:
> Paul <nospam@needed.invalid> wrote:
>
>> The LIST command on my POP3 server (inside a VM), doesn't give enough
>> info.
>>
>> The TOP command gives what appears to be a full header and zero body.
>>
>>
>> https://i.postimg.cc/G2qNBBTW/telnet-pop3.gif
>>
>> Using gawk.exe, you can write a script that calls telnet and
>> pipes the input and output of telnet into the script. This allows
>> a script to be written, to drive POP3 automatically (as you desire).
>> Gawk can have multiple files open at the same time, so that if you
>> need to generate a logfile, that can be done too.
>
> LIST just returns the indexes of messages. Hopefully your local client
> and the server don't get out of sync as to which indexes were previously
> retrieved by the client. The UIDL command just returns the UIDs of the
> messages, and is more accurate, specific to each message, and doesn't
> rely on indexing. You don't need headers to issue a DELE command. You
> can either use indexes of messages or their UIDs.
>
> If the OP is going to delete en masse, LIST to get the indexes or UIDL
> to get a list of UIDs followed by a for-loop of DELEs will work. I
> already mentioned LIST and UIDL do not return any other attributes of a
> message, like dates. The Overview and Articles databases just track
> message IDs.
>
> Or, are you thinking about doing a date-range deletion in the script's
> for-loop? The TOP command (without an argument which specifies how many
> lines of the body to include) just returns the headers of a message.
> Your script would then have to parse the headers to find the Date header
> although the Received header is more accurate. The Date header is added
> by the client when it first starts to compose a message. The message
> could sit for hours, days, or weeks in the sender's Outbox or Drafts
> folder. The first Received header listed in the headers is the last one
> prepended. Received headers get prepended to a message as it bounces
> through each server, so they are listed in newest-to-oldest in top-down
> order. The Date header is not when they sent their message, only when
> they first composed it. Received header shows when it showed up in your
> account. Also, in the script, if doing date-ranged deleted, to bias the
> datestamps to your timezone or to GMT, so the range doesn't go outside
> the expected date and times.

The hardest part of writing the script, is the date range part :-)

But in this case, the user wants "trimming by years" so
picking off the year field is enough as a go/no-go determination.

Paul

On Mon, 26 Jul 2021 at 13:52:12, Char Jackson <none@none.invalid> wrote
(my responses usually follow points raised):
[]
>The main problem here, the root cause of the issue that you've apparently
>been asked to help with, is that the guy was using POP instead of IMAP.
>Everything comes back to that.
[]
No, it's that he was using POP _and having all his machines (which may
be only one) set to "leave on server"_.

Saying IMAP is better than POP, for all users and in all circumstances,
is arrogant, even if you didn't intend it that way.

The fact that part of IMAP (the customer's Outlook) would have fallen
over, and thus highlight the problem, much earlier, isn't exactly a
ringing endorsement of IMAP (-:
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

A waist is a terrible thing to mind.

On Mon, 26 Jul 2021 20:27:34 +0100, "J. P. Gilliver (John)"
<G6JPG@255soft.uk> wrote:

>On Mon, 26 Jul 2021 at 13:52:12, Char Jackson <none@none.invalid> wrote
>(my responses usually follow points raised):
>[]
>>The main problem here, the root cause of the issue that you've apparently
>>been asked to help with, is that the guy was using POP instead of IMAP.
>>Everything comes back to that.
>[]
>No, it's that he was using POP _and having all his machines (which may
>be only one) set to "leave on server"_.

You're half right. POP, without that option enabled, or IMAP would both
have prevented the problem that started this thread. Of the two protocols,
however, IMAP is by far the better option. POP is all but obsolete.

>Saying IMAP is better than POP, for all users and in all circumstances,
>is arrogant, even if you didn't intend it that way.

I might have agreed with you ~20 years ago, but I see no advantage to using
POP rather than IMAP these days. You'll eventually come around to that
position, but obviously you're taking your time in getting there.*

No one can know every single situation that exists in the world, but it's
pretty safe to say that IMAP is preferable to POP. That'll be a true
statement nearly every time.

>The fact that part of IMAP (the customer's Outlook) would have fallen
>over, and thus highlight the problem, much earlier, isn't exactly a
>ringing endorsement of IMAP (-:

Please explain.

*As another example, I refer you to your SSD versus HDD discussions, where
you cite SSD reliability concerns, even though SSDs are generally more
reliable than HDDs. As above, you'll get there eventually. It's just taking
longer than expected.

--

Char Jackson

On Mon, 26 Jul 2021 19:22:36 +0100, "J. P. Gilliver (John)"
<G6JPG@255soft.uk> wrote:

>On Mon, 26 Jul 2021 at 12:28:34, NY <me@privacy.invalid> wrote (my
>responses usually follow points raised):
>[]
>>I had a report from the customer this morning that he did a
>>send/receive and Outlook received the remaining 5000 / 1.5 GB emails
>>since January without any problem. That was without any config change
>>(*) in Outlook since the last time it was tried (and failed) when there
>>were still 260,000 / 33 GB.
>>
>So sounds like all is running smoothly again.
>
>Provided you interact with/visit this person often enough to ensure
>proper backups (sounds like he's probably incapable), can I suggest you
>tweak his Outlook to _not_ "leave copies on the server" in future?
>Please (-:?
>>
>>As an aside, someone up-thread suggested using IMAP rather than POP.
>>I'm always cautious about IMAP because the emails remain on the server,
>>so if a message/folder is accidentally deleted, you have to ask the ISP
>>to retrieve it from a backup. With POP, you get a copy of all received
>>emails and so you can control what you backup and can (as long as you
>>know how) retrieve as much or as little as you need. POP is also an
>>advantage on a device that doesn't always have an internet connection -
>>a laptop, phone or tablet that may sometimes be out of mobile internet
>>range. With POP, you can search emails that you have already received
>>even when you are off-line, though of course you can't receive any new
>>ones or reply to any emails until you are online again.
>>
>I too don't like IMAP - it seems too much a buying into "cloud" (i. e.
>"someone else's computer") philosophy: never being 100% sure where my
>emails _are_. I realise I am in a significant minority in this; at least
>you've shown me I am not alone!

I've seen that argument before, of course, but in every case it comes from
people who simply don't know how IMAP works. In your case, John, you've
highlighted the problem above: you aren't sure where your email will be
stored. I'd like to think that once you figure out how IMAP works, and how
it doesn't work, you'll probably feel a lot better about it.

I think it was VanguardLH who has written *long* essays on the benefits of
IMAP versus POP, and how to configure it to act the way you want it to act.
Here's my short version. Do you want to leave your email on the server so
that multiple clients can see it? IMAP can do that. Do you want all of your
email to be stored locally, with none left on the server? IMAP can do that,
too. Do you want _some_ email left on the server so other clients can sync
with it and _some_ email only stored locally? IMAP can do that. Do you want
to sync two or more folders, rather than just your Inbox? IMAP can do that.
What can POP do that IMAP can't do?

--

Char Jackson

On Mon, 26 Jul 2021 19:14:04 +0100, "J. P. Gilliver (John)"
<G6JPG@255soft.uk> wrote:

>On Mon, 26 Jul 2021 at 01:12:04, Char Jackson <none@none.invalid> wrote
>(my responses usually follow points raised):
>>On Sun, 25 Jul 2021 23:18:40 -0400, Paul <nospam@needed.invalid> wrote:
>>
>>>J. P. Gilliver (John) wrote:
>>>> On Sun, 25 Jul 2021 at 13:03:34, Paul <nospam@needed.invalid> wrote (my
>>>> responses usually follow points raised):
>>>> []
>>>>> But pulling all 260000, even if the receiving end has the worlds
>>>>> best rules engine, that would take many tries, analysis of
>>>>> failures, and so on.
>>>>>
>>>>> Paul
>>>>
>>>> Plus it just seems wrong to download messages just to delete them
>>
>>There's nothing wrong about it. If it's your email, it's yours to do what
>>you like. I know a lot of email admins and there isn't one who would tell
>>you that it's wrong to download your email. That's kind of the whole point,
>
>You _are_ trolling, aren't you?

No, just a bit frustrated with those who like to take the long way round
the barn.

>I didn't say it seems wrong to download
>messages; I said it seems wrong to download messages just to delete
>them. (OK, I didn't specifically say "without looking at them", but I
>think a reasonable person would deduce that that's what I meant.)

Yes, I knew exactly what you meant, and I simply disagree with you. You've
made it clear that you take no issue with downloading the email. The rub
seems to be the deleting step.

So, after downloading your email, what you do with it is up to you. If you
think you'd feel badly about immediately deleting some or even most of it,
then save it somewhere for a week before deleting it. Problem solved,
right? If a week isn't long enough to keep your anxiety at bay, how about a
month? You know you'll delete it eventually, and you'll do so without
reading it since it's years and years old, so what difference does it make
to delete it immediately versus in a week or in a month? The task is to
remove it from the server, period. That's the problem being solved.

>>isn't it. The entire purpose of an email server is so that its users can
>>send and receive (download) email. If the provider has a policy that allows
>>an email store to grow to 33 GB, then they obviously have a policy that
>>allows you to download all or part of it.
>>
>When I said "wrong", I meant "pointless" and/or "a waste of everybody's
>time". I agree that if, as you say, a provider allows such storage, they
>probably let you have access to it - but that doesn't make it a sensible
>thing to do if all you're going to do is delete them unread.

If the point is to remove 260,000 emails from a mail server, and the web UI
sucks at that task, then a mail client is the obvious choice. I would say
the email client should be the *first* choice, but whatever. What's *not* a
good choice is trying to interact with the mail server via telnet and half
baked scripts. Joe Blow on the street isn't going to get very far that way.

Bottom line, downloading the email is the sensible step, since that solves
the immediate problem with the server. If the email no longer has value,
deleting it is the next sensible step. If that bugs you, archive it for a
period of time before you delete it. I don't see what's so hard about it.

>[]
>>I forgot that some people still have a monthly data allowance. I haven't
>>had one since about 2001/2002.
>>
>I'd forgotten that too, though it is a consideration; it was more a
>matter of the time needed, even at today's speeds, to download 33G.
>(Especially if doing so didn't solve the problem.)
>
>Sounds as if the problem has been solved anyway.

Correct.

--

Char Jackson

Char Jackson <none@none.invalid> wrote:

> On Mon, 26 Jul 2021 19:22:36 +0100, "J. P. Gilliver (John)"
> <G6JPG@255soft.uk> wrote:
>
>>On Mon, 26 Jul 2021 at 12:28:34, NY <me@privacy.invalid> wrote (my
>>responses usually follow points raised):
>>[]
>>>I had a report from the customer this morning that he did a
>>>send/receive and Outlook received the remaining 5000 / 1.5 GB emails
>>>since January without any problem. That was without any config change
>>>(*) in Outlook since the last time it was tried (and failed) when there
>>>were still 260,000 / 33 GB.
>>>
>>So sounds like all is running smoothly again.
>>
>>Provided you interact with/visit this person often enough to ensure
>>proper backups (sounds like he's probably incapable), can I suggest you
>>tweak his Outlook to _not_ "leave copies on the server" in future?
>>Please (-:?
>>>
>>>As an aside, someone up-thread suggested using IMAP rather than POP.
>>>I'm always cautious about IMAP because the emails remain on the server,
>>>so if a message/folder is accidentally deleted, you have to ask the ISP
>>>to retrieve it from a backup. With POP, you get a copy of all received
>>>emails and so you can control what you backup and can (as long as you
>>>know how) retrieve as much or as little as you need. POP is also an
>>>advantage on a device that doesn't always have an internet connection -
>>>a laptop, phone or tablet that may sometimes be out of mobile internet
>>>range. With POP, you can search emails that you have already received
>>>even when you are off-line, though of course you can't receive any new
>>>ones or reply to any emails until you are online again.
>>>
>>I too don't like IMAP - it seems too much a buying into "cloud" (i. e.
>>"someone else's computer") philosophy: never being 100% sure where my
>>emails _are_. I realise I am in a significant minority in this; at least
>>you've shown me I am not alone!
>
> I've seen that argument before, of course, but in every case it comes from
> people who simply don't know how IMAP works. In your case, John, you've
> highlighted the problem above: you aren't sure where your email will be
> stored. I'd like to think that once you figure out how IMAP works, and how
> it doesn't work, you'll probably feel a lot better about it.
>
> I think it was VanguardLH who has written *long* essays on the benefits of
> IMAP versus POP, and how to configure it to act the way you want it to act.
> Here's my short version. Do you want to leave your email on the server so
> that multiple clients can see it? IMAP can do that. Do you want all of your
> email to be stored locally, with none left on the server? IMAP can do that,
> too. Do you want _some_ email left on the server so other clients can sync
> with it and _some_ email only stored locally? IMAP can do that. Do you want
> to sync two or more folders, rather than just your Inbox? IMAP can do that.
> What can POP do that IMAP can't do?

With IMAP, there are local copies of messages, but they are only used
for display. IMAP has 2-way sync between client(s) and server. If one
client moves a message from, say, Inbox to a subfolder called Work under
the folder Archive (i.e., Inbox -> Archive:Work), other IMAP clients
will see the same change. You don't end up with IMAP clients getting
out of sync with each other. If one IMAP client deletes a message
(well, move it into the Trash folder unless permanently deleted), other
IMAP clients will experience the same change to the message.

IMAP also has PUSH: when messages are received in your account's Inbox,
you see a copy immediately show up in your IMAP client's Inbox. You
don't have to wait until the next poll interval. However, the server
can still expire your mail session after which it won't be until your
IMAP client does its next scheduled poll when it gets another mail
session during which new messages will get pushed when they arrive.
Mail sessions are expensive as the server has limited resources, tries
to dole some response to each mail session, and typically has LOTS of
users wanting to access their messages.

IMAP supports additional attributes to messages: seen, deleted,
answered, and flagged. If a user with one IMAP client opens a new
message, it gets flagged seen. If the user then uses another IMAP
client, they don't see the same message as a new message and instead it
is also marked read in the other client.

IMAP supports folders to allow users to organize their e-mails instead
of leaving them into just the Inbox folder. POP has no concept of
folders. POP only understands a mailbox which is presented as an Inbox
folder in the client. The other folders shown in the POP client are
local-only. If a user of a POP client deletes a message which has it
move from Inbox to Trash, that message will not be visible in another
POP client in its Trash folder. You'll have to go to the POP client
that deleted the message (moved into the Trash folder) to recover that
e-mail. Local message stores of seperate POP clients are not
synchronized.

You do get local copies of messages with IMAP. You can include the .ost
file for an IMAP account in your backup. However, users are horrible at
setting up scheduled backups. Some think they can just do manual
backups, but then discover they neglected to do backups for a long time,
so a restore loses a lot of data files, installed programs, and/or
configuration changes to the programs and OS. Backups are more regular
and granular at the server than by the vast majority of users. If you
need to restore your account to a prior state (i.e., before a date), you
can call tech support to get it restored to that date. Sorry, I cannot
address the variability of different e-mail providers regarding their
level of customer support.

Those who feel safer having all of their POP message store (which is
just the Inbox folder as the other folders are local-only and unrelated
to anything on the server) on their local host, that only works if they
have scheduled backups that don't require user intervention to perform.
Relying on humans to manually run backups means they don't get done, or
often enough. Most times when you ask a customer about their backups,
they look like deer caught in headlights.

https://support.microsoft.com/en-us/office/introduction-to-outlook-data-files-pst-and-ost-222eaf92-a995-45d9-bde2-f331f60e2790
Section: Offline Outlook Data File (.ost)
"... use an Offline Outlook Data File (.ost) file to store a
synchronized copy of your mailbox information on your local computer.
When your connection to the mail server is interrupted, for example,
when you're on an airplane without WiFi or if your internet connection
disconnects, you can still access all emails, calendar data, contacts,
and tasks that have been previously downloaded. You can read and compose
messages, create appointments, and add contacts. However, your email
messages won't be sent and no new messages will be downloaded until your
internet connection is restored."

Well, if you don't have a network connection, especially an Internet
connection when using someone else's e-mail service, you also won't be
able to send when using POP, too. Nothing magical there: no network
access, no sending no matter what protocol you try to use. You won't be
posting here on these newsgroups, either, until you reconnect.

There is mention that you cannot import from an .ost file. No need to
since the intent is to perform 2-way sync between client and server.
Importing an .ost would make the client out of sync with the server
regarding different items imported from the .ost file. However, if you
include the .ost file in your backups (you'll need to use a backup
program that supports VSS since Outlook will keep the file open while
Outlook is running), you can simply restore it. The IMAP server will
have to change its message store to match your old local IMAP message
store.

IMAP does not immediately delete messages. Deleting a message simply
flags it for a delete action whenever the IMAP client issues a PURGE
command. A deleted item gets marked for deletion. When the client
issues a Purge command, which could be days or weeks later, is when the
delete-flagged items actually get deleted up on the server. Until the
Purge command is issued, the delete-flagged messages are still in the
local message store (.ost file) but are hidden from the user, or they
are shown with a red strikethrough. There are tools to dig into
Outlook's message store to unflag those hidden messages, but they aren't
for the faint of heart. Because delete-flagged messages can hang around
for a long time inside an IMAP client's message store while also hanging
around up on the server, many clients use event-driven purges. For
example, after a certain time, and when there are a batch of
delete-flagged items, the client will issue the Purge command. Another
method is to issue a Purge when focus changes from the folder where the
delete-flagged items resides, like the user was in the Inbox folder and
then clicks on the Sent folder to change folder focus.

On Mon, 26 Jul 2021 at 21:51:18, Char Jackson <none@none.invalid> wrote
(my responses usually follow points raised):
>On Mon, 26 Jul 2021 19:14:04 +0100, "J. P. Gilliver (John)"
><G6JPG@255soft.uk> wrote:
>
>>On Mon, 26 Jul 2021 at 01:12:04, Char Jackson <none@none.invalid> wrote
>>(my responses usually follow points raised):
>>>On Sun, 25 Jul 2021 23:18:40 -0400, Paul <nospam@needed.invalid> wrote:
>>>
>>>>J. P. Gilliver (John) wrote:
[]
>>>>> Plus it just seems wrong to download messages just to delete them
>>>
>>>There's nothing wrong about it. If it's your email, it's yours to do what
>>>you like. I know a lot of email admins and there isn't one who would tell
>>>you that it's wrong to download your email. That's kind of the whole point,
>>
>>You _are_ trolling, aren't you?
>
>No, just a bit frustrated with those who like to take the long way round
>the barn.
>
>>I didn't say it seems wrong to download
>>messages; I said it seems wrong to download messages just to delete
>>them. (OK, I didn't specifically say "without looking at them", but I
>>think a reasonable person would deduce that that's what I meant.)
>
>Yes, I knew exactly what you meant, and I simply disagree with you. You've
>made it clear that you take no issue with downloading the email. The rub
>seems to be the deleting step.

Quite the opposite! As the aim is to delete them from the server, then
downloading them seems an odd thing to do. Especially as simply
downloading does _not_ delete.

(Looks like the problem's fixed [for now] anyway.)
>
>So, after downloading your email, what you do with it is up to you. If you
>think you'd feel badly about immediately deleting some or even most of it,
>then save it somewhere for a week before deleting it. Problem solved,
>right? If a week isn't long enough to keep your anxiety at bay, how about a
>month? You know you'll delete it eventually, and you'll do so without
>reading it since it's years and years old, so what difference does it make
>to delete it immediately versus in a week or in a month?

No, ideally I don't want to download them _at all_; as I'm not going to
look at them, that seems a pointless action.

> The task is to
>remove it from the server, period. That's the problem being solved.

We agree on something!
[]
>If the point is to remove 260,000 emails from a mail server, and the web UI
>sucks at that task, then a mail client is the obvious choice. I would say
>the email client should be the *first* choice, but whatever. What's *not* a
>good choice is trying to interact with the mail server via telnet and half
>baked scripts. Joe Blow on the street isn't going to get very far that way.

Well, the _normal_ use of a POP email client (let's just consider
reading for now) is to download emails, then (default setting) delete
them from the server. (Actually tell the server to delete them.) If the
email client can tell the server to delete them without downloading them
first, that would be great; I don't know if Outlook or any other POP
receive client _does_ have that function.

(Academic, as looks like the problem's fixed [for now] anyway.)

>
>Bottom line, downloading the email is the sensible step, since that solves
>the immediate problem with the server.

(a) that will only _work_ if doing so definitely also causes the
deletion at the server. (b) if there's _any_ way of doing the deleting
without the downloading, surely that would be better, for this much
data?

> If the email no longer has value,
>deleting it is the next sensible step. If that bugs you, archive it for a
>period of time before you delete it. I don't see what's so hard about it.

I don't have any sort of "emotional attachment" to it! I'd delete it
immediately! Just seemed daft to download it just to delete it. It
_wasn't_ the deleting I had any problem with; it was the downloading,
being done as a _way_ to achieve deletion _on the server_.
[]
>>Sounds as if the problem has been solved anyway.
>
>Correct.
>
So we're arguing about a problem that has been solved - for now anyway.
Though I do hope NY is getting his customer to change his POP _not_ to
"leave copies on the server", or as many here would prefer switch to
IMAP [which will fall over, and so highlight the problem, sooner (-:].
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

"If god doesn't like the way I live, Let him tell me, not you." - unknown

"J. P. Gilliver (John)" <G6JPG@255soft.uk> wrote in message
news:0AtNLd7s1v$gFwVS@255soft.uk...
> On Mon, 26 Jul 2021 at 12:28:34, NY <me@privacy.invalid> wrote (my
> responses usually follow points raised):
> []
>>I had a report from the customer this morning that he did a send/receive
>>and Outlook received the remaining 5000 / 1.5 GB emails since January
>>without any problem. That was without any config change (*) in Outlook
>>since the last time it was tried (and failed) when there were still
>>260,000 / 33 GB.
>>
> So sounds like all is running smoothly again.
>
> Provided you interact with/visit this person often enough to ensure proper
> backups (sounds like he's probably incapable), can I suggest you tweak his
> Outlook to _not_ "leave copies on the server" in future? Please (-:?

He wants several computers to have access to the same incoming email: his
own using Outlook client and two secretaries who use Yahoo webmail. So he
wants messages to stay on the server (hopefully for a limited period of
time) even if he's done a send/receive which would normally do periodically.

I've always understood that this form of multiple-PC access to email is the
reason that "leave messages on server / delete after n days" exists, and is
the best way to solve it. The fact that he's using Outlook and the others
are using webmail isn't significant, I think: even if all were using
Outlook, you'd want messages to remain on the server for a short overlap
time, to allow all readers to see them (and then, maybe, respond to them).

"Char Jackson" <none@none.invalid> wrote in message
news:1uoufgpkradam697k9vc9aniomk50jmtrr@4ax.com...

> I think it was VanguardLH who has written *long* essays on the benefits of
> IMAP versus POP, and how to configure it to act the way you want it to
> act.
> Here's my short version. Do you want to leave your email on the server so
> that multiple clients can see it? IMAP can do that. Do you want all of
> your
> email to be stored locally, with none left on the server? IMAP can do
> that,
> too. Do you want _some_ email left on the server so other clients can sync
> with it and _some_ email only stored locally? IMAP can do that. Do you
> want
> to sync two or more folders, rather than just your Inbox? IMAP can do
> that.
> What can POP do that IMAP can't do?

Ah, I may be about to learn something. IMAP can be configured to copy email
to the client, in the same way that POP can? I never knew that. I wonder why
not?

I'd always understood the IMAP left the email on the server and a message
was never transferred to the client (apart from transiently as you are
viewing it and including parts of it in your reply). Consequently (I
thought) IMAP could not be used to look at old email while offline, in the
same way that webmail needs an online connection.

I'll have to look at how IMAP can be configured to copy messages to the
client for local storage and local backup, so it behaves like POP.

If IMAP can be made to behave like POP (if wanted) but can also do the
various other things you mention, then I agree that POP is no longer
neccesary.

"Char Jackson" <none@none.invalid> wrote in message
news:a7qufghe44f960kqgtu48semplrstrlene@4ax.com...
> If the point is to remove 260,000 emails from a mail server, and the web
> UI
> sucks at that task, then a mail client is the obvious choice. I would say
> the email client should be the *first* choice, but whatever. What's *not*
> a
> good choice is trying to interact with the mail server via telnet and half
> baked scripts. Joe Blow on the street isn't going to get very far that
> way.

The problem in my (the OP's) case was that when the client (Outlook) was
used to try to perform this selective deletion, it choked on the large
amount of data.

Assuming that I was using POP as the transfer protocol (and I accept that
IMAP may be an alternative, maybe even better, solution) then it all hinges
on Outlook doing the deletion *before* rather than *after* it downloads the
messages. You need to see the headers, use those to decide which messages to
delete - eg according to send date) and then delete those messages without
even downloading them. Then download the remainder which you want to keep.

I had contemplated using an old solution such as Mailwasher (*) which did
this: it displayed headers, allowed you to mark what to keep and what to
discard, according to some criterion, and then issued the relevant POP
commands to do this, all before any full messages were downloaded.

(*) I'm sure there are more modern equivalents.

On Tue, 27 Jul 2021 at 15:34:02, NY <me@privacy.invalid> wrote (my
responses usually follow points raised):
[]
>He wants several computers to have access to the same incoming email:
>his own using Outlook client and two secretaries who use Yahoo webmail.
>So he wants messages to stay on the server (hopefully for a limited
>period of time) even if he's done a send/receive which would normally
>do periodically.

I've not heard of the "for a limited period of time" before -
particularly in a POP context. Is that something implemented by the
server, or (one of) the client(s)?

The normal way (I think) to implement multiple access in POP days was to
have one "master" client that had "delete from server" set, and the
others not - but you had to make sure the "master" was the last to
connect. These days, IMAP is probably the better way to implement
multiple access - it certainly avoids the necessity not to connect with
the deleting client until last. (How you sort out deletion from the
server, I leave to one of the IMAP enthusiasts to explain; I rather
suspect it's something you're not supposed to think about, like what
happened _before_ the big bang.)
>
>I've always understood that this form of multiple-PC access to email is
>the reason that "leave messages on server / delete after n days"
>exists, and is the best way to solve it. The fact that he's using

I think the _original_ "delete after n days" was conceived in the days
of very limited server space. (Ideally - from the server operator's
point of view - it would have been "delete over x megabytes", but "after
n days" was more acceptable/comprehensible to all; I think most server
operators had a size limit too.)

>Outlook and the others are using webmail isn't significant, I think:
>even if all were using Outlook, you'd want messages to remain on the
>server for a short overlap time, to allow all readers to see them (and
>then, maybe, respond to them).
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

"If god doesn't like the way I live, Let him tell me, not you." - unknown

NY <me@privacy.invalid> wrote:

> He wants several computers to have access to the same incoming email:
> his own using Outlook client and two secretaries who use Yahoo
> webmail. So he wants messages to stay on the server (hopefully for a
> limited period of time) even if he's done a send/receive which would
> normally do periodically.
>
> I've always understood that this form of multiple-PC access to email
> is the reason that "leave messages on server / delete after n days"
> exists, and is the best way to solve it. The fact that he's using
> Outlook and the others are using webmail isn't significant, I think:
> even if all were using Outlook, you'd want messages to remain on the
> server for a short overlap time, to allow all readers to see them
> (and then, maybe, respond to them).

Since the account is for business use, how long will N be in "delete
after N days"? A business has longer retention of e-mails with
customers, partners, suppliers, etc, perhaps as long as 7 years (40
years if the messages have anything to do with mortgages). Another
reason to investigate the archiving function in Outlook.

"J. P. Gilliver (John)" <G6JPG@255soft.uk> wrote:

> I've not heard of the "for a limited period of time" before -
> particularly in a POP context. Is that something implemented by the
> server, or (one of) the client(s)?

Tis a client-side feature of the e-mail client (Outlook, Thunderbird).
"Leave messages on server for N days" can be configured as to when and
what gets deleted from the server.

- Remove from server after x days
Messages are downloaded to your client, but remain on the server for
the number of days that you specify. Whether you delete or keep the
messages in the client, they get deleted from the server after N days.

- Remove from server when deleted from 'Deleted Items'
Messages are downloaded to your client, but remain on the server
indefinitely *until* you delete them from the client *AND* you empty
the Deleted Items folder; i.e., messages are deleted from the server
after you /permanently/ delete them in the client either by emptying
the Deleted Items folder, or when you use Shift-Del to permanently
delete the selected message. Just deleting the message (moving into
the Delete folder) doesn't remove the message from the server.

Not selecting either of these options leaves messages indefinitely on
the server regardless of whether you keep or delete them in the client.

https://www.slipstick.com/outlook/email/to-leave-internet-messages-on-the-server/

Thunderbird has both options, too. While it has the "Leave messages on
server for N days" option, its auto-delete option is a bit different.
Outlook will issue a DELE command when a message is permanently deleted
(Deleted which moves to Deleted Items, and the Deleted Items folder is
emptied, or Shift+Del is used to immediately permanently delete a
message) while Thunderbird's option is "Until I delete or move them from
Inbox". I can understand Tbird doing it a bit differently since POP has
no concept of folders, so moving out of the Inbox folder means moving
into a local-only folder, not a folder mapped to a server folder when
using IMAP.

On Tue, 27 Jul 2021 15:50:12 +0100, "NY" <me@privacy.invalid> wrote:

>"Char Jackson" <none@none.invalid> wrote in message
>news:a7qufghe44f960kqgtu48semplrstrlene@4ax.com...
>> If the point is to remove 260,000 emails from a mail server, and the web
>> UI
>> sucks at that task, then a mail client is the obvious choice. I would say
>> the email client should be the *first* choice, but whatever. What's *not*
>> a
>> good choice is trying to interact with the mail server via telnet and half
>> baked scripts. Joe Blow on the street isn't going to get very far that
>> way.
>
>The problem in my (the OP's) case was that when the client (Outlook) was
>used to try to perform this selective deletion, it choked on the large
>amount of data.

What isn't clear to me is whether OL *fatally* choked, as in error message
or timeout, or did it choke as in nothing seemed to be happening for a
period of time. You'd expect to see a delay, even a significant delay,
while OL tries to figure out how to handle a quarter of a million of
emails.

>Assuming that I was using POP as the transfer protocol (and I accept that
>IMAP may be an alternative, maybe even better, solution) then it all hinges
>on Outlook doing the deletion *before* rather than *after* it downloads the
>messages.

I don't know why that would be a requirement. I would have expected the
opposite.

<snip>

--

Char Jackson

On Tue, 27 Jul 2021 15:34:02 +0100, "NY" <me@privacy.invalid> wrote:

>"J. P. Gilliver (John)" <G6JPG@255soft.uk> wrote in message
>news:0AtNLd7s1v$gFwVS@255soft.uk...
>> On Mon, 26 Jul 2021 at 12:28:34, NY <me@privacy.invalid> wrote (my
>> responses usually follow points raised):
>> []
>>>I had a report from the customer this morning that he did a send/receive
>>>and Outlook received the remaining 5000 / 1.5 GB emails since January
>>>without any problem. That was without any config change (*) in Outlook
>>>since the last time it was tried (and failed) when there were still
>>>260,000 / 33 GB.
>>>
>> So sounds like all is running smoothly again.
>>
>> Provided you interact with/visit this person often enough to ensure proper
>> backups (sounds like he's probably incapable), can I suggest you tweak his
>> Outlook to _not_ "leave copies on the server" in future? Please (-:?
>
>He wants several computers to have access to the same incoming email: his
>own using Outlook client and two secretaries who use Yahoo webmail. So he
>wants messages to stay on the server (hopefully for a limited period of
>time) even if he's done a send/receive which would normally do periodically.
>
>I've always understood that this form of multiple-PC access to email is the
>reason that "leave messages on server / delete after n days" exists, and is
>the best way to solve it. The fact that he's using Outlook and the others
>are using webmail isn't significant, I think: even if all were using
>Outlook, you'd want messages to remain on the server for a short overlap
>time, to allow all readers to see them (and then, maybe, respond to them).

I would configure Outlook to use IMAP so that, by default, all incoming
email is left on the server. (In addition to being available in Outlook,
both online and offline. People frequently seem to forget that IMAP doesn't
mean email is *only* available on the server.)

Next, I would configure Outlook to move email that's older than X days from
the Inbox folder to a folder that's not synced to the server. That will
remove it from the server, while keeping it available in Outlook. Outlook's
auto archive function can be used to automate that.

For example, if X days is 30, then the secretaries have 30 days in which to
respond to important emails. After that, from their webmail perspective the
old email will be gone/deleted, but if necessary it can still be accessed
on the boss's computer using Outlook. X can be configured to be any
reasonable value.

That's a very simple and basic use case, but much more can be done, if
desired. For example, Outlook's rules engine can be configured to move
specific emails from the Inbox folder to other synced folders, so that the
secretaries don't have to wade through everything to find specific things.
Using IMAP, when Outlook moves an email to another synced folder, the move
will be synced back to the server where the secretaries will then see it in
that other folder. After they've responded and closed out an email
transaction, they could move the emails to yet another synced folder,
_Completed for example, and Outlook will sync itself to that change.
Outlook is the master email client in this scenario, since it has auto
archive settings and a robust rules engine. I've barely scratched the
surface, but it looks like their requirements are very minimal.

--

Char Jackson

On Tue, 27 Jul 2021 15:43:02 +0100, "NY" <me@privacy.invalid> wrote:

>"Char Jackson" <none@none.invalid> wrote in message
>news:1uoufgpkradam697k9vc9aniomk50jmtrr@4ax.com...
>
>> I think it was VanguardLH who has written *long* essays on the benefits of
>> IMAP versus POP, and how to configure it to act the way you want it to
>> act.
>> Here's my short version. Do you want to leave your email on the server so
>> that multiple clients can see it? IMAP can do that. Do you want all of
>> your
>> email to be stored locally, with none left on the server? IMAP can do
>> that,
>> too. Do you want _some_ email left on the server so other clients can sync
>> with it and _some_ email only stored locally? IMAP can do that. Do you
>> want
>> to sync two or more folders, rather than just your Inbox? IMAP can do
>> that.
>> What can POP do that IMAP can't do?
>
>Ah, I may be about to learn something. IMAP can be configured to copy email
>to the client, in the same way that POP can? I never knew that. I wonder why
>not?

I can't speak for every IMAP mail client, but Outlook creates a local copy
by default.

>I'd always understood the IMAP left the email on the server and a message
>was never transferred to the client (apart from transiently as you are
>viewing it and including parts of it in your reply).

No, not true, at least WRT Outlook. Outlook keeps local copies of
IMAP-synced email in *.ost files, and unsynced (local only) email is stored
in *.pst files. When you ask Outlook to move an email from a synced folder
to an unsynced folder, it simply gets copied from the .ost to the relevant
..pst, then flagged for deletion in the .ost. You can have any reasonable
number of .pst files, Outlook calls them data files, each with any
reasonable number of folders within it. Outlook will aggregate them for
you, or you can bring .pst files in and out of Outlook's GUI as you please.

>Consequently (I
>thought) IMAP could not be used to look at old email while offline, in the
>same way that webmail needs an online connection.

No. That wouldn't be very useful.

>I'll have to look at how IMAP can be configured to copy messages to the
>client for local storage and local backup, so it behaves like POP.
>
>If IMAP can be made to behave like POP (if wanted) but can also do the
>various other things you mention, then I agree that POP is no longer
>neccesary.

I made some suggestions in another post, dated just before this one.
Hopefully some of what I wrote can be adapted, bolstered by what VanguardLH
wrote regarding what happens behind the curtain.

--

Char Jackson