From robin.listas at telefonica.net Fri Jun 23 02:48:01 2023 From: robin.listas at telefonica.net (Carlos E. R.) Date: Fri Mar 22 14:17:33 2024 Subject: [Alpine-info] Sudenly, a rule doesn't work. Message-ID: <6b6ff193-e7ff-527c-489e-828b3262550d@telefonica.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have been, for years, using a select messages rule in some accounts. I do, once inside the folder: ; Select R Rule ^T To List Select non offtopic messages on GMX bis The rule is: LIT:pattern="/NICK=Select non offtopic messages on GMX bis/ARBList-Id=project.lists.opensuse.org,support.lists.opensuse.org,factory.lists.opensuse.org,security-announce.lists.opensuse.org,security-announce.lists.opensuse.org,announce.lists.opensuse.org,users.lists.opensuse.org,users-es.lists.opensuse.org,kernel.lists.opensuse.org,test.lists.opensuse.org,kde.lists.opensuse.org,virtual.lists.opensuse.org,translation.lists.opensuse.org,gnome.lists.opensuse.org,security.lists.opensuse.org/FLDTYPE=EMAIL" action="/ISSRCH=1", And suddenly, today it fails: [full text search not supported] Is there something I can do? It is a gmx.es account. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZJVqURwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVkhsAn071GdyQbodyvVcL2GHW 0OqO6du4AJ9sxQwzRlC+pd2hmZhbP9bolnATCw== =QqB6 -----END PGP SIGNATURE----- From dennisdavis at fastmail.fm Sun Jun 25 03:45:06 2023 From: dennisdavis at fastmail.fm (Dennis Davis) Date: Fri Mar 22 14:17:33 2024 Subject: [Alpine-info] Sudenly, a rule doesn't work. In-Reply-To: <6b6ff193-e7ff-527c-489e-828b3262550d@telefonica.net> References: <6b6ff193-e7ff-527c-489e-828b3262550d@telefonica.net> Message-ID: On Fri, 23 Jun 2023, Carlos E. R. wrote: > From: Carlos E. R. > To: Alpine info > Date: Fri, 23 Jun 2023 11:48:01 +0200 (CEST) > Subject: [Alpine-info] Sudenly, a rule doesn't work. > > I have been, for years, using a select messages rule in some > accounts. I do, once inside the folder: > > ; Select > R Rule > ^T To List > Select non offtopic messages on GMX bis > > > The rule is: > > > LIT:pattern="/NICK=Select non offtopic messages on GMX > bis/ARBList-Id=project.lists.opensuse.org,support.lists.opensuse.org,factory.lists.opensuse.org,security-announce.lists.opensuse.org,security-announce.lists.opensuse.org,announce.lists.opensuse.org,users.lists.opensuse.org,users-es.lists.opensuse.org,kernel.lists.opensuse.org,test.lists.opensuse.org,kde.lists.opensuse.org,virtual.lists.opensuse.org,translation.lists.opensuse.org,gnome.lists.opensuse.org,security.lists.opensuse.org/FLDTYPE=EMAIL" > action="/ISSRCH=1", > > > And suddenly, today it fails: > > > [full text search not supported] > > > > Is there something I can do? > > It is a gmx.es account. Long shot: if this is an IMAP account, the following option on the INBOX/Folder specification might help: Loser This option makes sense only for IMAP servers that do not perform a SEARCH command correctly. If your filtering rules fail to filter some messages, that should have been filtered, then this option will make Alpine download all data necessary data to perform that search. There is a performance penalty when using this option. Downloading the data to perform the search will take longer than requesting the IMAP server to perform the filtering, but the filtering will be done correctly. -- Dennis Davis From robin.listas at telefonica.net Sun Jun 25 04:38:30 2023 From: robin.listas at telefonica.net (Carlos E. R.) Date: Fri Mar 22 14:17:33 2024 Subject: [Alpine-info] Sudenly, a rule doesn't work. In-Reply-To: References: <6b6ff193-e7ff-527c-489e-828b3262550d@telefonica.net> Message-ID: <74b74e9a-56aa-62a8-f89b-1ad7b9886d88@telefonica.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2023-06-25 at 11:45 +0100, Dennis Davis wrote: > On Fri, 23 Jun 2023, Carlos E. R. wrote: ... >> And suddenly, today it fails: >> >> >> [full text search not supported] >> >> >> >> Is there something I can do? >> >> It is a gmx.es account. > > Long shot: if this is an IMAP account, the following option on the > INBOX/Folder specification might help: Yes, it is IMAP. > Loser > This option makes sense only for IMAP servers that do not > perform a SEARCH command correctly. If your filtering rules fail > to filter some messages, that should have been filtered, then > this option will make Alpine download all data necessary data > to perform that search. There is a performance penalty when > using this option. Downloading the data to perform the search > will take longer than requesting the IMAP server to perform the > filtering, but the filtering will be done correctly. AH! Trying now. incoming-folders=... "imap Gmx L" {imap.gmx.com/tls/user=myname@gmx.es/loser}INBOX, Yes, the filter runs significantly slower, but it runs. Opening the folder seems as fast as always. I was contemplating as alternative doing the filtering in Thunderbird, where all the messages are cached in local disk, Huh, sorting by threads (K D) is very slow now (the folder has 3200 posts or so). Minutes. Ok, I may then define the inbox twice, one using "loser", and another not. One for using the filter, and another for normal use. Another alternative could be using "imapsync" /somehow/. I haven't yet though out how. Interesting. I have now: incoming-folders="... "imap Gmx L" {imap.gmx.com/tls/user=me@gmx.es}INBOX, ... "imap F Gmx L" {imap.gmx.com/tls/user=me@gmx.es/loser}INBOX, And the sorting by threads on the second one is fast. Wait, things are strange and interesting. If I restart Alpine, then open first "imap Gmx L" and later "imap F Gmx L", sorting is fast, and filtering fails. On both folders, subsequently. If then I exit Alpine, then open first "imap F Gmx L" (the loser version), then sorting is slow and filtering works. On both folders, subsequently It seems Alpine merges the second used configuration of the folder. I then should create a second Alpine instance, with different configuration file, to use the filter. Do you know if this is possible? - -- Cheers, Carlos E. R. (from openSUSE 15.4 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZJgnNxwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfV8HkAn1+uSFK7byRZpWgTnl9C 4mAYQff/AKCSkcNpeYnzXZZjuxmgdrZCRBKUEw== =vYyb -----END PGP SIGNATURE----- From dennisdavis at fastmail.fm Sun Jun 25 09:23:38 2023 From: dennisdavis at fastmail.fm (Dennis Davis) Date: Fri Mar 22 14:17:33 2024 Subject: [Alpine-info] Sudenly, a rule doesn't work. In-Reply-To: <74b74e9a-56aa-62a8-f89b-1ad7b9886d88@telefonica.net> References: <6b6ff193-e7ff-527c-489e-828b3262550d@telefonica.net> <74b74e9a-56aa-62a8-f89b-1ad7b9886d88@telefonica.net> Message-ID: <01cb8740-3c3b-711f-d801-bb04367b5db7@fastmail.fm> On Sun, 25 Jun 2023, Carlos E. R. wrote: > From: Carlos E. R. > To: Alpine info > Date: Sun, 25 Jun 2023 13:38:30 +0200 (CEST) > Subject: Re: [Alpine-info] Sudenly, a rule doesn't work. > > On Sunday, 2023-06-25 at 11:45 +0100, Dennis Davis wrote: > > On Fri, 23 Jun 2023, Carlos E. R. wrote: > > ... > > > > And suddenly, today it fails: > > > > > > > > > [full text search not supported] > > > > > > > > > > > > Is there something I can do? > > > > > > It is a gmx.es account. > > > > Long shot: if this is an IMAP account, the following option on the > > INBOX/Folder specification might help: > > Yes, it is IMAP. > > > Loser > > This option makes sense only for IMAP servers that do not > > perform a SEARCH command correctly. If your filtering rules fail > > to filter some messages, that should have been filtered, then > > this option will make Alpine download all data necessary data > > to perform that search. There is a performance penalty when > > using this option. Downloading the data to perform the search > > will take longer than requesting the IMAP server to perform the > > filtering, but the filtering will be done correctly. > > AH! ... > Another alternative could be using "imapsync" /somehow/. I haven't > yet though out how. If you want bi-directional synchronisation between two IMAP servers you'll need to use something like isync: http://isync.sourceforge.net/ and, of course, the second IMAP server needs to be capable of correctly handling the SEARCH function. ... > I then should create a second Alpine instance, with different > configuration file, to use the filter. Do you know if this is > possible? Yes, alpine will take the config file to use as a command line argument: -p config-file Use config-file as the personal configuration file instead of the default .pinerc. so you can set up a specific configuration file -- .pinerc-gmx -- for this particular case and then set up a shell function or shell script for ease of use. Something simple like: alpine-gmx () { alpine -p ~/.pinerc-gmx "$@"; } as a shell function should suffice. This might seem a little crude and basic. However I suspect it'll be easier than getting two separate IMAP servers synchronised. -- Dennis Davis From robin.listas at telefonica.net Sun Jun 25 10:30:03 2023 From: robin.listas at telefonica.net (Carlos E. R.) Date: Fri Mar 22 14:17:33 2024 Subject: [Alpine-info] Sudenly, a rule doesn't work. In-Reply-To: <01cb8740-3c3b-711f-d801-bb04367b5db7@fastmail.fm> References: <6b6ff193-e7ff-527c-489e-828b3262550d@telefonica.net> <74b74e9a-56aa-62a8-f89b-1ad7b9886d88@telefonica.net> <01cb8740-3c3b-711f-d801-bb04367b5db7@fastmail.fm> Message-ID: <22e12549-158c-3ebe-8004-e805a735edcf@telefonica.net> On 2023-06-25 18:23, Dennis Davis wrote: > On Sun, 25 Jun 2023, Carlos E. R. wrote: >> On Sunday, 2023-06-25 at 11:45 +0100, Dennis Davis wrote: >>> On Fri, 23 Jun 2023, Carlos E. R. wrote: >> >> ... >> >>>> And suddenly, today it fails: >>>> >>>> >>>> [full text search not supported] >>>> >>>> >>>> >>>> Is there something I can do? >>>> >>>> It is a gmx.es account. >>> >>> Long shot: if this is an IMAP account, the following option on the >>> INBOX/Folder specification might help: >> >> Yes, it is IMAP. >> >>> Loser >>> This option makes sense only for IMAP servers that do not >>> perform a SEARCH command correctly. If your filtering rules fail >>> to filter some messages, that should have been filtered, then >>> this option will make Alpine download all data necessary data >>> to perform that search. There is a performance penalty when >>> using this option. Downloading the data to perform the search >>> will take longer than requesting the IMAP server to perform the >>> filtering, but the filtering will be done correctly. >> >> AH! > > ... > >> Another alternative could be using "imapsync" /somehow/. I haven't >> yet though out how. > > If you want bi-directional synchronisation between two IMAP servers > you'll need to use something like isync: > > http://isync.sourceforge.net/ > > and, of course, the second IMAP server needs to be capable of correctly > handling the SEARCH function. I do have a local imap server, but no, the goal is to move out of the remote server mail that fits certain criteria (a filter), not doing a sync. > > ... > >> I then should create a second Alpine instance, with different >> configuration file, to use the filter. Do you know if this is >> possible? > > Yes, alpine will take the config file to use as a command line > argument: > > -p config-file Use config-file as the personal configuration file > instead of the default .pinerc. > > so you can set up a specific configuration file -- .pinerc-gmx -- > for this particular case and then set up a shell function or shell > script for ease of use. Something simple like: > > alpine-gmx () { alpine -p ~/.pinerc-gmx "$@"; } > > as a shell function should suffice. > > This might seem a little crude and basic. However I suspect it'll > be easier than getting two separate IMAP servers synchronised. Thanks, yes :-) I also did: inbox-path={localhost/novalidate-cert/user=cer}INBOX To avoid collision with the main INBOX, which causes a second alpine to "steal the lock" of the first one. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar) -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 209 bytes Desc: OpenPGP digital signature URL: From damion.yates at gmail.com Sun Jun 25 12:41:26 2023 From: damion.yates at gmail.com (damion.yates@gmail.com) Date: Fri Mar 22 14:17:33 2024 Subject: [Alpine-info] Sudenly, a rule doesn't work. In-Reply-To: <6b6ff193-e7ff-527c-489e-828b3262550d@telefonica.net> References: <6b6ff193-e7ff-527c-489e-828b3262550d@telefonica.net> Message-ID: <82079443-3021-5a59-9d50-77d174ac04e1@gmail.com> On Fri, 23 Jun 2023, Carlos E. R. wrote: > I have been, for years, using a select messages rule in some accounts. > I do, once inside the folder: [..snipped..] > And suddenly, today it fails: > > [full text search not supported] > > Is there something I can do? > > It is a gmx.es account. There have been follow-ups with work-arounds. I wanted to comment on the sudden change. I assume they've switched their IMAP serving infra and sadly this will now always be slow unless they change back or can configure full text search in their new infrastructure. If you happened to be keeping the alpine debug logs it might show the point where the server ident changed. I would contact them as it's possible it's just a tick box on whatever service they're using. They might be using an off the shelf imap daemon on their own servers, or might be white labelling a 3rd party service like MS. It's not impossible it was an oversight. OTOH your own sync so a local more capable imap server if you are okay constantly running one, will undoubatbly be fast and useful in its own ways. Best wishes, - Damion From robin.listas at telefonica.net Sun Jun 25 14:12:37 2023 From: robin.listas at telefonica.net (Carlos E. R.) Date: Fri Mar 22 14:17:33 2024 Subject: [Alpine-info] Sudenly, a rule doesn't work. In-Reply-To: <82079443-3021-5a59-9d50-77d174ac04e1@gmail.com> References: <6b6ff193-e7ff-527c-489e-828b3262550d@telefonica.net> <82079443-3021-5a59-9d50-77d174ac04e1@gmail.com> Message-ID: On 2023-06-25 21:41, damion.yates@gmail.com wrote: > On Fri, 23 Jun 2023, Carlos E. R. wrote: > >> I have been, for years, using a select messages rule in some accounts. >> I do, once inside the folder: > > [..snipped..] > >> And suddenly, today it fails: >> >> ???? [full text search not supported] >> >> Is there something I can do? >> >> It is a gmx.es account. > > There have been follow-ups with work-arounds.? I wanted to comment on > the sudden change. > > I assume they've switched their IMAP serving infra and sadly this will > now always be slow unless they change back or can configure full text > search in their new infrastructure. > > If you happened to be keeping the alpine debug logs it might show the > point where the server ident changed. No... I don't have alpine logs. I have imapsync logs, but maybe a year old. They might show a server software change. > > I would contact them as it's possible it's just a tick box on whatever > service they're using.? They might be using an off the shelf imap daemon > on their own servers, or might be white labelling a 3rd party service > like MS. No, they are a big email provider, this is intentional. They are very thick headed, I know from the times I had to talk to them. For instance, lately, I got a virus on the mail, undetected by them. I reported it, an on the feedback they kept using a book of recipes for the answers and talking about how to handle spam instead of malware. > It's not impossible it was an oversight.? OTOH your own sync so a local > more capable imap server if you are okay constantly running one, will > undoubatbly be fast and useful in its own ways. They never supported full search. The problem is that now some headers (List-Id=...) are now excluded from the search on headers. Oh, I don't do a sync. I just use sync software to move old mails now and then to my own local server. So for the daily mail I use their server on several machines. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar) -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 209 bytes Desc: OpenPGP digital signature URL: From ibima-sekretariat at uni-rostock.de Wed Jun 28 05:13:04 2023 From: ibima-sekretariat at uni-rostock.de (UMR IBIMA Sekretariat) Date: Fri Mar 22 14:17:33 2024 Subject: [Alpine-info] Problems with Alpine/Parallels/MacOS, please help Message-ID: I hope to obtain advice, using Alpine in a Parallels virtual machine, running MacOS inside MacOS. All software versions are the most recent ones; fresh installations as of June 2023. - MacOS runs in a virtual machine (VM) using Parallels desktop on MacOS (MacOS is also the host system) - Alpine is running in the VM - Configuration/sent mails/received mails of Alpine should be stored in the host system. For this a shared network folder was created in the host system and connected to the VM. - Files and folders like ".pinerc" and "mail" should be a symlink to the shared network folder. Example: - Mounted network folder is "/Volumes/HostShared" - "/home/username/.pinerc" is symlink to "/Volumes/HostShared/Alpine/.pinerc" - "/home/username/mail" is symlink to "/Volumes/HostShared/Alpine/mail" - other files/folders belonging to Alpine are symlinked as just mentioned. Problems discovered during testing: - Alpine takes a long time trying to save sent messages and then fails. - Alpine refuses to write to .pinerc as it is not located in the home directory. - Yet if files are manually copied to the network folder (by using the symlinks) everything goes fast and as expected. Q.: What could be done to make Alpine work? Thanks a lot in advance! A. Brauer -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew at aitchison.me.uk Thu Jun 29 08:38:58 2023 From: andrew at aitchison.me.uk (Andrew C Aitchison) Date: Fri Mar 22 14:17:33 2024 Subject: [Alpine-info] Problems with Alpine/Parallels/MacOS, please help In-Reply-To: References: Message-ID: <8d695ca3-2953-31eb-17fd-048bf1ebc634@aitchison.me.uk> On Wed, 28 Jun 2023, UMR IBIMA Sekretariat wrote: > I hope to obtain advice, using Alpine in a Parallels virtual machine, > running MacOS inside MacOS. > > All software versions are the most recent ones; fresh installations as of > June 2023. > > ? > > ?? - MacOS runs in a virtual machine (VM) using Parallels desktop on > MacOS (MacOS is also the host system) > > ?? - Alpine is running in the VM > > ?? - Configuration/sent mails/received mails of Alpine should be stored > in the host system. For this a shared network folder was created in the > host system and connected to the VM. > > ?? - Files and folders like ".pinerc" and "mail" should be a symlink to > the shared network folder. > > ? > Example: > > ?? - Mounted network folder is "/Volumes/HostShared" > > ?? - "/home/username/.pinerc" is symlink to > "/Volumes/HostShared/Alpine/.pinerc" > > ?? - "/home/username/mail" is symlink to > "/Volumes/HostShared/Alpine/mail" > > ?? - other files/folders belonging to Alpine are symlinked as just > mentioned. I see no mention of username in the symlink target. Should I assume that the client machine only has one user ? (I assume you aren't confusing the system directory of mailboxes with the user's directory of mail folders). Does alpine run with an particular group id, or setgid or similar ? IIRC MacOS/HFS+ has a wider user/group/permission system than "standard" unix. ACLs or Mandatory access control (MAC) could also be relevant. Is *mounting* the mail folder at /home/username/mail (rather than using a symlink) an option ? There could be other problems with this - on Linux it would break snaps - but it might make a difference. > Problems discovered during testing: > > ?? - Alpine takes a long time trying to save sent messages and then > fails. Could that be a locking issue ? > ?? - Alpine refuses to write to .pinerc as it is not located in the home > directory. Not sure about thus, but if alpine updates by making a new file and mv'ing it over the old one, it would be tricky to fix. > ?? - Yet if files are manually copied to the network folder (by using the > symlinks) everything goes fast and as expected. That suggests to me that some part of user/group/permission is correct, but that some part of permissions/ACL/MAC could be different for alpine. > Q.: What could be done to make Alpine work? > > Thanks a lot in advance! > > > A. Brauer -- Andrew C. Aitchison Kendal, UK andrew@aitchison.me.uk From mattack at apple.com Thu Jun 29 15:41:44 2023 From: mattack at apple.com (Matt Ackeret) Date: Fri Mar 22 14:17:33 2024 Subject: [Alpine-info] Problems with Alpine/Parallels/MacOS, please help In-Reply-To: References: Message-ID: > On Jun 28, 2023, at 5:13 AM, UMR IBIMA Sekretariat wrote: > I hope to obtain advice, using Alpine in a Parallels virtual machine, running MacOS inside MacOS. > All software versions are the most recent ones; fresh installations as of June 2023. This doesn't actually answer your question AT ALL I admit.. But why don't you just run alpine "natively" on the Mac itself? I do it all the time (like right now). (I am typing THiS in Mail, which I run alongside alpine.. each has its own benefits) Basically, what are you trying to accomplish by running it in a VM? -------------- next part -------------- An HTML attachment was scrubbed... URL: