From alpine-info at u.washington.edu Thu Jul 11 14:26:22 2024 From: alpine-info at u.washington.edu (Andrew C Aitchison via Alpine-info) Date: Thu Jul 11 14:26:32 2024 Subject: [Alpine-info] OAUTH Profile for Open Public Clients Message-ID: There is a new ietf draft intended as a public way for mail clients and servers to interoperate when using OAUTH, written by Neil Jenkins of fastmail: https://www.ietf.org/archive/id/draft-jenkins-oauth-public-00.html Currently Alpine have had to code the details of Microsoft, Google and Yahoo OAuth authentication separately, which does not scale. This draft is intended to allow any MTA to use OAUTH with any MUA. -- For those of you who can access the mailop list, Brandon Long of GMail explained some use cases where he considers OAUTH more secure than plain IMAP. These don't sound like the sort of scenarios where alpine would be used, but may be ones that GMail have to worry about: https://list.mailop.org/private/mailop/2024-July/028714.html -- Andrew C. Aitchison Kendal, UK andrew@aitchison.me.uk From alpine-info at u.washington.edu Sat Jul 13 15:52:39 2024 From: alpine-info at u.washington.edu (via Alpine-info) Date: Sat Jul 13 15:52:45 2024 Subject: [Alpine-info] Alpine 2.26 does not save SMTP password in macOS Keychain Message-ID: Using Alpine 2.26 on macOS. Both IMAP and SMTP servers require passwords for auth. Alpine saves the IMAP password in the macOS Keychain, but not the SMTP password so I have to type it at least once per session. Is this a known issue or just a "me problem" that might have a fix? Is there a way to maybe add the key myself to the Keychain? Thanks! From alpine-info at u.washington.edu Sat Jul 13 16:08:13 2024 From: alpine-info at u.washington.edu (via Alpine-info) Date: Sat Jul 13 16:08:18 2024 Subject: [Alpine-info] errors on macOS (installed from homebrew) Message-ID: <8891E663-53F6-4D9C-A8DE-4980EEF88D61.1@smtp-inbound1.duck.com> Installed 2.26 on latest macOS (ARM) from Homebrew. This shows up when I start alpine: 2024-07-13 15:53:34.819 alpine[69425:5984749] CFPropertyListCreateFromXMLData(): Old-style plist parser: missing semicolon in dictionary on line 1. Parsing will be abandoned. Break on _CFPropertyListMissingSemicolon to debug. Not sure whether this is a problem with the Homebrew build or Alpine in general. From alpine-info at u.washington.edu Sun Jul 14 10:42:33 2024 From: alpine-info at u.washington.edu (Eduardo Chappa via Alpine-info) Date: Sun Jul 14 10:42:43 2024 Subject: [Alpine-info] errors on macOS (installed from homebrew) In-Reply-To: <8891E663-53F6-4D9C-A8DE-4980EEF88D61.1@smtp-inbound1.duck.com> References: <8891E663-53F6-4D9C-A8DE-4980EEF88D61.1@smtp-inbound1.duck.com> Message-ID: On Sat, 13 Jul 2024, via Alpine-info wrote: > > Installed 2.26 on latest macOS (ARM) from Homebrew. This shows up when I > start alpine: > > 2024-07-13 15:53:34.819 alpine[69425:5984749] > CFPropertyListCreateFromXMLData(): Old-style plist parser: missing > semicolon in dictionary on line 1. Parsing will be abandoned. Break on > _CFPropertyListMissingSemicolon to debug. > > Not sure whether this is a problem with the Homebrew build or Alpine in > general. Unfortunately I do not have a mac to test this, so if someone else can help you and submit a patch as needed, please do so. Thank you. -- Eduardo From alpine-info at u.washington.edu Sat Jul 20 13:15:54 2024 From: alpine-info at u.washington.edu (James Miller via Alpine-info) Date: Sat Jul 20 13:15:57 2024 Subject: [Alpine-info] copying lengthy embedded url's possible? Message-ID: Here's my scenario. I'm almost always doing my Alpine e-mail tasks while logged in via an ssh session. That is by design since e-mail, for me, is preferably a textual rather than graphical affair. So, think text-mode, keyboard driven. Let's call the computer where Alpine is running the ssh host and the one I've initiated the ssh login from the ssh client. A problem I've encountered but have so far been unable to resolve is that I am sometimes, in order to pass a security check, sent by e-mail some extremely lengthy embedded URL that is supposed to allow me to sign in to some account or other of mine. When this happens, what I'd like to do is open the link in a graphical environment and browser running on the ssh client computer. Were I able to get the whole URL to somehow display in Alpine, I'd just use my mouse to copy it, then paste the URL into a graphical browser: this is what I used to do before such URL's began to exceed all reasonable URL length conventions (I assume for security reasons). I've tried using Alpine's edit URL option but so far that has failed because I can only view/copy, at one time, maybe 50 characters of the hundreds of characters that comprise the URL. Given the complexity of the URL and the fact that numerous segments need to be separately displayed, then copied/pasted, the chance are high that some mistake(s) will be made, thus resulting in an invalid URL. And in addition, the time it can take to copy/paste in this fashion can exceed the validity interval of the URL. So, am I missing some way to display, for copy/pasting purposes, these mile-long URL's in Alpine? If not, can anyone suggest a workaround? Thanks PS I do have on the ssh host a text-mode browser and Alpine is configured to open URL's using that browser, but the lengthy embedded URL's usually fail to open using that means since the page being requested requires a java-enabled browser. From alpine-info at u.washington.edu Sat Jul 20 13:41:41 2024 From: alpine-info at u.washington.edu (Bret Busby via Alpine-info) Date: Sat Jul 20 13:41:59 2024 Subject: [Alpine-info] copying lengthy embedded url's possible? In-Reply-To: References: Message-ID: On 21/7/24 04:15, James Miller via Alpine-info wrote: > Here's my scenario. I'm almost always doing my Alpine e-mail tasks while > logged in via an ssh session. That is by design since e-mail, for me, is > preferably a textual rather than graphical affair. So, think text-mode, > keyboard driven. Let's call the computer where Alpine is running the ssh > host and the one I've initiated the ssh login from the ssh client. > > A problem I've encountered but have so far been unable to resolve is > that I am sometimes, in order to pass a security check, sent by e-mail > some extremely lengthy embedded URL that is supposed to allow me to sign > in to some account or other of mine. When this happens, what I'd like to > do is open the link in a graphical environment and browser running on > the ssh client computer. Were I able to get the whole URL to somehow > display in Alpine, I'd just use my mouse to copy it, then paste the URL > into a graphical browser: this is what I used to do before such URL's > began to exceed all reasonable URL length conventions (I assume for > security reasons). > > I've tried using Alpine's edit URL option but so far that has failed > because I can only view/copy, at one time, maybe 50 characters of the > hundreds of characters that comprise the URL. Given the complexity of > the URL and the fact that numerous segments need to be separately > displayed, then copied/pasted, the chance are high that some mistake(s) > will be made, thus resulting in an invalid URL. And in addition, the > time it can take to copy/paste in this fashion can exceed the validity > interval of the URL. > > So, am I missing some way to display, for copy/pasting purposes, these > mile-long URL's in Alpine? If not, can anyone suggest a workaround? > > Thanks > > PS I do have on the ssh host a text-mode browser and Alpine is > configured to open URL's using that browser, but the lengthy embedded > URL's usually fail to open using that means since the page being > requested requires a java-enabled browser. > _______________________________________________ > Alpine-info mailing list > Alpine-info@u.washington.edu > http://mailman12.u.washington.edu/mailman/listinfo/alpine-info Since you have not specified your operating system platform, the response below, assumes that you are running alpine on Linux. In alpine, I suggest that you use the 'h' to display the full headers, which also displays HTML code, such as hypertext links, then, use 'e' to export the message to (for example) your home directory, as "email.txt" then open the text file with a text editor, such as gedit, then mark and copy the URL. That would put the URL in your clipboard, from whence, you should be able to paste the URL into another application. Works for me. Just be careful of characters (hidden or visible), at the end of text lines, where the URL wraps over multiple lines. Sometimes, that requires a bit of playing around with it, for example, copying and appending parts of the URL, one line at a time. Also, an aspect to remember, is that many excessively long URL's include tracking components and other malicious components, so, you might want to edit the URL's, depending on the nature of the URL's, by truncating at the point where the remainder of the URL, is superfluous to reaching the target. .. Bret Busby Armadale West Australia (UTC+0800) .............. From alpine-info at u.washington.edu Sat Jul 20 14:04:53 2024 From: alpine-info at u.washington.edu (Bret Busby via Alpine-info) Date: Sat Jul 20 14:12:16 2024 Subject: [Alpine-info] copying lengthy embedded url's possible? In-Reply-To: References: Message-ID: On 21/7/24 04:41, Bret Busby wrote: > On 21/7/24 04:15, James Miller via Alpine-info wrote: >> Here's my scenario. I'm almost always doing my Alpine e-mail tasks >> while logged in via an ssh session. That is by design since e-mail, >> for me, is preferably a textual rather than graphical affair. So, >> think text-mode, keyboard driven. Let's call the computer where Alpine >> is running the ssh host and the one I've initiated the ssh login from >> the ssh client. >> >> A problem I've encountered but have so far been unable to resolve is >> that I am sometimes, in order to pass a security check, sent by e-mail >> some extremely lengthy embedded URL that is supposed to allow me to >> sign in to some account or other of mine. When this happens, what I'd >> like to do is open the link in a graphical environment and browser >> running on the ssh client computer. Were I able to get the whole URL >> to somehow display in Alpine, I'd just use my mouse to copy it, then >> paste the URL into a graphical browser: this is what I used to do >> before such URL's began to exceed all reasonable URL length >> conventions (I assume for security reasons). >> >> I've tried using Alpine's edit URL option but so far that has failed >> because I can only view/copy, at one time, maybe 50 characters of the >> hundreds of characters that comprise the URL. Given the complexity of >> the URL and the fact that numerous segments need to be separately >> displayed, then copied/pasted, the chance are high that some >> mistake(s) will be made, thus resulting in an invalid URL. And in >> addition, the time it can take to copy/paste in this fashion can >> exceed the validity interval of the URL. >> >> So, am I missing some way to display, for copy/pasting purposes, these >> mile-long URL's in Alpine? If not, can anyone suggest a workaround? >> >> Thanks >> >> PS I do have on the ssh host a text-mode browser and Alpine is >> configured to open URL's using that browser, but the lengthy embedded >> URL's usually fail to open using that means since the page being >> requested requires a java-enabled browser. > Since you have not specified your operating system platform, the > response below, assumes that you are running alpine on Linux. > > In alpine, I suggest that you use the 'h' to display the full headers, > which also displays HTML code, such as hypertext links, then, use 'e' to > export the message to (for example) your home directory, as > "email.txt" > then open the text file with a text editor, such as gedit, then mark and > copy the URL. > > That would put the URL in your clipboard, from whence, you should be > able to paste the URL into another application. > > Works for me. > > Just be careful of characters (hidden or visible), at the end of text > lines, where the URL wraps over multiple lines. > > Sometimes, that requires a bit of playing around with it, for example, > copying and appending parts of the URL, one line at a time. > > Also, an aspect to remember, is that many excessively long URL's include > tracking components and other malicious components, so, you might want > to edit the URL's, depending on the nature of the URL's, by truncating > at the point where the remainder of the URL, is superfluous to reaching > the target. > > .. > Bret Busby > Armadale > West Australia > (UTC+0800) > .............. > Also something else for you to try; when you see a URL that includes a question mark, try copying and pasting the URL up to, but excluding, the question mark, so that you copy and paste the sequence of characters before the question mark, and, find whether that takes you to the web page that you want to visit. .. Bret Busby Armadale West Australia (UTC+0800) .............. From alpine-info at u.washington.edu Sat Jul 20 14:09:56 2024 From: alpine-info at u.washington.edu (Bret Busby via Alpine-info) Date: Sat Jul 20 14:13:58 2024 Subject: [Alpine-info] Question for List Administrator In-Reply-To: References: Message-ID: <15e8e554-7496-406e-a281-c3ecab0e7ff3@busby.net> On 21/7/24 04:41, Bret Busby via Alpine-info wrote: > On 21/7/24 04:15, James Miller via Alpine-info wrote: Why has the mailing list administration been changed to conceal the email address of posters? Is that to prohibit subscribers from directly contacting a poster of a message, in response to content of a post, and, to prohibit subscribers from blocking email from a particular poster, if a poster shows delinquent behaviour? This change to the mailing list administration is ominous. .. Bret Busby Armadale West Australia (UTC+0800) .............. From alpine-info at u.washington.edu Sat Jul 20 14:49:41 2024 From: alpine-info at u.washington.edu (Milt Epstein via Alpine-info) Date: Sat Jul 20 14:49:50 2024 Subject: [Alpine-info] Question for List Administrator In-Reply-To: <15e8e554-7496-406e-a281-c3ecab0e7ff3@busby.net> References: <15e8e554-7496-406e-a281-c3ecab0e7ff3@busby.net> Message-ID: <401a2932-5d93-ff50-06cc-6b4764d7a380@illinois.edu> I can't speak to the whys and wherefores of why this change was made (or even whether it's a good or bad thing, without hearing the various arguments pro/con), but I'll just say that the email addresses of the posters is still available, in the Reply-To: headers. (And this change looks like it was made a few months ago.) Milt Epstein mepstein@illinois.edu On Sun, 21 Jul 2024, Bret Busby via Alpine-info wrote: > On 21/7/24 04:41, Bret Busby via Alpine-info wrote: > > On 21/7/24 04:15, James Miller via Alpine-info wrote: > > Why has the mailing list administration been changed to conceal the email > address of posters? > > Is that to prohibit subscribers from directly contacting a poster of a > message, in response to content of a post, and, to prohibit subscribers from > blocking email from a particular poster, if a poster shows delinquent > behaviour? > > This change to the mailing list administration is ominous. > > .. > Bret Busby > Armadale > West Australia > (UTC+0800) > .............. > > _______________________________________________ > Alpine-info mailing list > Alpine-info@u.washington.edu > https://urldefense.com/v3/__http://mailman12.u.washington.edu/mailman/listinfo/alpine-info__;!!DZ3fjg!7prUz5vnDUxcB5Q_CbkJKcN6eTntZJufDQOe0IV3JBfdiPLDqVihZKNgmntQ2Bekktcmyq8YYqe9HE7UxxMxa7kyTVA9FRYy$ From alpine-info at u.washington.edu Sat Jul 20 18:22:33 2024 From: alpine-info at u.washington.edu (David Morris via Alpine-info) Date: Sat Jul 20 18:22:38 2024 Subject: [Alpine-info] Question for List Administrator In-Reply-To: <401a2932-5d93-ff50-06cc-6b4764d7a380@illinois.edu> References: <15e8e554-7496-406e-a281-c3ecab0e7ff3@busby.net> <401a2932-5d93-ff50-06cc-6b4764d7a380@illinois.edu> Message-ID: <9889f77-db47-1652-8b3e-135929a7bd@xpasc.com> One suggestion I was going to make ... display of reply-to may be an option that you have to set in alpine. Some other processes I use: 1. I have a gmail account open in a desktop browser. When I encounter a complex email which includes referenced images in the message (e.g., the USPS daily mail digest) I turn headers on, forward the email as an attachment to my gmail account. From there I have clickable links from the gmail view. 2. Since I run my own SMTP server on the same host I use for alpine, I have a folder in my linux account (htmlMail). That folder is available on my desktop via Samba. When viewing the email in alpine, I use "V" to view the attachments and save the html version to the folder. Than I open that file using my browser. 3. Depending on your access to the system running alpine, you could set your ssh client to do X-forwarding and run an X-server on your desktop from which you run Alpine (I use Xming on windows) 4. When I widen my SSH terminal window, Alpine notices and reformat for the new size. So, If I really want access to the URL, I stretch my Alpine window to the full with of the screen. Then I use the Alpine feature to edit the URL (which seems to provide the best access) and copy/paste from there. This is often sufficient to access the full URL, otherwise doing the cut/paste in segments requires fewer segments and fewer potential mistakes (and you don't have to pick the URL out of sometimes complex HTML). On Sat, 20 Jul 2024, Milt Epstein via Alpine-info wrote: > I can't speak to the whys and wherefores of why this change was made > (or even whether it's a good or bad thing, without hearing the various > arguments pro/con), but I'll just say that the email addresses of the > posters is still available, in the Reply-To: headers. (And this > change looks like it was made a few months ago.) > > Milt Epstein > mepstein@illinois.edu > > > On Sun, 21 Jul 2024, Bret Busby via Alpine-info wrote: > > > On 21/7/24 04:41, Bret Busby via Alpine-info wrote: > > > On 21/7/24 04:15, James Miller via Alpine-info wrote: > > > > Why has the mailing list administration been changed to conceal the email > > address of posters? > > > > Is that to prohibit subscribers from directly contacting a poster of a > > message, in response to content of a post, and, to prohibit subscribers from > > blocking email from a particular poster, if a poster shows delinquent > > behaviour? > > > > This change to the mailing list administration is ominous. > > > > .. > > Bret Busby > > Armadale > > West Australia > > (UTC+0800) > > .............. > > > > _______________________________________________ > > Alpine-info mailing list > > Alpine-info@u.washington.edu > > https://urldefense.com/v3/__http://mailman12.u.washington.edu/mailman/listinfo/alpine-info__;!!DZ3fjg!7prUz5vnDUxcB5Q_CbkJKcN6eTntZJufDQOe0IV3JBfdiPLDqVihZKNgmntQ2Bekktcmyq8YYqe9HE7UxxMxa7kyTVA9FRYy$ > _______________________________________________ > Alpine-info mailing list > Alpine-info@u.washington.edu > http://mailman12.u.washington.edu/mailman/listinfo/alpine-info > > ---------- > > This email has been scanned for spam and viruses by Proofpoint Essentials. Visit the following link to report this email as spam: > https://us3.proofpointessentials.com/app/report_spam.php?mod_id=11&mod_option=logitem&report=1&type=easyspam&k=k1&payload=53616c7465645f5f35cd976ca904d54f25ae5183e47346da49ba1e3a6ae5e82e5a32a9e6e9042b5c0ba52bb9a326953f57557c711fafd218e4a30663913d9ba7a4a1e10f6c6e560fee3d4c29e7ee6e2df93bda2a89aeb9cb050700517fffa53721b40c8613e3aae99a4b2ea821115005d69c930026daa37b7fc9593d0b07b8d9a25030dacb4747dd40113c0cd935516c > From alpine-info at u.washington.edu Sat Jul 20 18:38:35 2024 From: alpine-info at u.washington.edu (Milt Epstein via Alpine-info) Date: Sat Jul 20 18:38:53 2024 Subject: [Alpine-info] Question for List Administrator In-Reply-To: <9889f77-db47-1652-8b3e-135929a7bd@xpasc.com> References: <15e8e554-7496-406e-a281-c3ecab0e7ff3@busby.net> <401a2932-5d93-ff50-06cc-6b4764d7a380@illinois.edu> <9889f77-db47-1652-8b3e-135929a7bd@xpasc.com> Message-ID: <2c7a6091-04da-a21f-fe18-0e1fdeeec787@illinois.edu> On Sat, 20 Jul 2024, David Morris via Alpine-info wrote: > One suggestion I was going to make ... display of reply-to may be an > option that you have to set in alpine. [ ... ] Yeah, I use viewer-hdrs for this (note that if you list any headers in that setting, it only shows those headers -- so if you want to see the default set of headers plus some other ones, you must list the default ones in there as well; see the help for that setting for the default set of headers). Milt Epstein mepstein@illinois.edu From alpine-info at u.washington.edu Sat Jul 20 18:52:35 2024 From: alpine-info at u.washington.edu (Damion Yates via Alpine-info) Date: Sat Jul 20 18:52:39 2024 Subject: [Alpine-info] copying lengthy embedded url's possible? In-Reply-To: References: Message-ID: On Saturday 20 July 2024, Bret Busby via Alpine-info < alpine-info@u.washington.edu> wrote: > On 21/7/24 04:41, Bret Busby wrote: > >> On 21/7/24 04:15, James Miller via Alpine-info wrote: >> >>> Here's my scenario. I'm almost always doing my Alpine e-mail tasks while >>> logged in via an ssh session. That is by design since e-mail, for me, is >>> preferably a textual rather than graphical affair. So, think text-mode, >>> keyboard driven. Let's call the computer where Alpine is running the ssh >>> host and the one I've initiated the ssh login from the ssh client. >>> >>> A problem I've encountered but have so far been unable to resolve is >>> that I am sometimes, in order to pass a security check, sent by e-mail some >>> extremely lengthy embedded URL that is supposed to allow me to sign in to >>> some account or other of mine. When this happens, what I'd like to do is >>> open the link in a graphical environment and browser running on the ssh >>> client computer. Were I able to get the whole URL to somehow display in >>> Alpine, I'd just use my mouse to copy it, then paste the URL into a >>> graphical browser: this is what I used to do before such URL's began to >>> exceed all reasonable URL length conventions (I assume for security >>> reasons). >>> >>> I've tried using Alpine's edit URL option but so far that has failed >>> because I can only view/copy, at one time, maybe 50 characters of the >>> hundreds of characters that comprise the URL. Given the complexity of the >>> URL and the fact that numerous segments need to be separately displayed, >>> then copied/pasted, the chance are high that some mistake(s) will be made, >>> thus resulting in an invalid URL. And in addition, the time it can take to >>> copy/paste in this fashion can exceed the validity interval of the URL. >>> >>> So, am I missing some way to display, for copy/pasting purposes, these >>> mile-long URL's in Alpine? If not, can anyone suggest a workaround? >>> >>> Thanks >>> >>> PS I do have on the ssh host a text-mode browser and Alpine is >>> configured to open URL's using that browser, but the lengthy embedded URL's >>> usually fail to open using that means since the page being requested >>> requires a java-enabled browser. >>> >> > > > Since you have not specified your operating system platform, the response >> below, assumes that you are running alpine on Linux. >> >> In alpine, I suggest that you use the 'h' to display the full headers, >> which also displays HTML code, such as hypertext links, then, use 'e' to >> export the message to (for example) your home directory, as >> "email.txt" >> then open the text file with a text editor, such as gedit, then mark and >> copy the URL. >> >> That would put the URL in your clipboard, from whence, you should be able >> to paste the URL into another application. >> >> Works for me. >> >> Just be careful of characters (hidden or visible), at the end of text >> lines, where the URL wraps over multiple lines. >> >> Sometimes, that requires a bit of playing around with it, for example, >> copying and appending parts of the URL, one line at a time. >> >> Also, an aspect to remember, is that many excessively long URL's include >> tracking components and other malicious components, so, you might want to >> edit the URL's, depending on the nature of the URL's, by truncating at the >> point where the remainder of the URL, is superfluous to reaching the target. >> >> .. >> Bret Busby >> Armadale >> West Australia >> (UTC+0800) >> .............. >> >> > Also something else for you to try; when you see a URL that includes a > question mark, try copying and pasting the URL up to, but excluding, the > question mark, so that you copy and paste the sequence of characters before > the question mark, and, find whether that takes you to the web page that > you want to visit. > I've been doing this for many many years, so have several ideas for you: 1) If you use Firefox locally and your remote machine spawns `firefox url` from alpine, then add long as you made the SSH connection using -X, some X11 magic makes the local Firefox jump to the URL. I discovered this when actually wanting the remote server to X forward the whole browser, because the remote machine was on the right LAN for the address in question (I ultimately solved this with an ssh -D socks fwd). I was willing to put up with some graphical slowness for a moment. By killing the local Firefox it did the slow version. I actually had no idea X could do this. Chrome doesn't support this feature, so using chrome it'll possibly slowly spawn your remote chrome over, bit this could corrupt your remote .config/google-chrome/* stuff. The latter also needs a fast and low latency link 2) Configure alpine to spawn your own shell script. That script should echo the URL and sleep for 5 seconds. This will let you c+p cleanly (might require some terminfo config on wide screen wrapping), this is the most likely to solve your issue better than trying to grab parts of the URL from the email, edit URL line or even view headers/raw (which will not resolve quoted-printable). The script can clear the screen and return after. 3) Adapting on the script idea you can have it intelligently determine things about your session. For example in my case my alpine is at work, of I'm there I want to just spawn a new chrome tab, this works fine. If `xlock` is running, I'm likely remote and the script follows different conditional logic. If there is no $DISPLAY then it does the echo & pause thing from 2), if there is, then I use xdotool and xclip to remotely select chrome, ^t and paste a URL in, all over X forwarding. This simulates the firefox ability and is significantly faster than trying to X a whole browser. 4) It may be possible to passphraselessly scp a text file with a URL in a script to something polling locally, assuming you have an sshd. Some more communicated kludge liked this is likely needed of you're using Wayland or a Mac. I'm about 50:50 local and usually `pgrep xlock` tells me if I'm local or sshed in, but I have other complications as I'm within a persistent `screen` session, so I need to fudge $DISPLAY. FWIW I also x forward `xv` for images or use `chafa` for a good ASCII art rendition of images. Let me know how you get on. - Damion -- Damion Yates - damion.yates@gmail.com London, England -------------- next part -------------- An HTML attachment was scrubbed... URL: From alpine-info at u.washington.edu Sat Jul 27 06:05:22 2024 From: alpine-info at u.washington.edu (Olaf Skibbe via Alpine-info) Date: Sat Jul 27 06:05:29 2024 Subject: [Alpine-info] Search problem Message-ID: Hi all, I have a problem concerning the "select" function of alpine. I use the web hoster Strato for e-mail. Since recently, I see the following behavior: I am in the INBOX of the account and want to select all mails from a certain sender. I do ; T F where is in this case something in the "From" header, e.g. ; T F olaf should find mails with a line like this in the header: From: Olaf Skibbe But actually, the result of the sequence "; T F " is always empty, regardless of obvious matching mails. I can select the messages with in the "From:" header by searching for participants: ; T P . But obviously, this selects also mails with in other header fields. I can select the messages if I store them locally and do ; T F within the local folder. It also works as expected if I copy the mail to the INBOX of another account (at a different hoster). And last but not least, I find the messages in the INBOX using Thunderbird and search in the "From:" header. It seems as if searching the "From:" header on the mail server does not work, but searching participants evaluates the "From:" header regardless. All other text select methods (all that starts with "; T") seem to work fine. I suspect that this is not an alpine issue but something going wrong at the mail server at Strato. I would appreciate hints to how I could maybe get around this issue (I use the select functions very much, dozens of times every day for many years) or how I can evaluate the problem in more detail to address the people at Strato with it. Any hints or ideas? Kind regards, Olaf From alpine-info at u.washington.edu Sat Jul 27 14:24:22 2024 From: alpine-info at u.washington.edu (Carlos E. R. via Alpine-info) Date: Sat Jul 27 14:24:36 2024 Subject: [Alpine-info] Search problem In-Reply-To: References: Message-ID: <63d1a53b-e7c0-4f27-940e-47df88616b89@telefonica.net> On 2024-07-27 15:05, Olaf Skibbe via Alpine-info wrote: > Hi all, > > I have a problem concerning the "select" function of alpine. > > I use the web hoster Strato for e-mail. Since recently, I see the > following behavior: > > I am in the INBOX of the account and want to select all mails from a > certain sender. I do > > ; T F > > where is in this case something in the "From" header, > e.g. > > ; T F olaf > > should find mails with a line like this in the header: > > From: Olaf Skibbe > > But actually, the result of the sequence "; T F " is > always empty, regardless of obvious matching mails. > > I can select the messages with in the "From:" header > by searching for participants: > > ; T P . > > But obviously, this selects also mails with in other > header fields. > > I can select the messages if I store them locally and do > > ; T F > > within the local folder. It also works as expected if I copy the mail > to the INBOX of another account (at a different hoster). > > And last but not least, I find the messages in the INBOX using > Thunderbird and search in the "From:" header. > > It seems as if searching the "From:" header on the mail server does > not work, but searching participants evaluates the "From:" header > regardless. All other text select methods (all that starts with "; T") > seem to work fine. > > I suspect that this is not an alpine issue but something going wrong > at the mail server at Strato. > > I would appreciate hints to how I could maybe get around this issue (I > use the select functions very much, dozens of times every day for many > years) or how I can evaluate the problem in more detail to address the > people at Strato with it. > > Any hints or ideas? It is suggestive of a problem I have with search and select (based on headers) on a gmx.es account. Search results using the server are wrong (using a different software, not alpine). I found that I had to tell this software to repeat the search on the downloaded data, instead of asking the server. This is, of course, slow. I had problems with alpine, which I bypass using a different .pinerc profile: "Gmx" {imap.gmx.com/tls/user=robin.listas@gmx.es}INBOX, "F Gmx" {imap.gmx.com/tls/user=robin.listas@gmx.es/loser}INBOX, This forces filtering to use the same trick and do the filtering in local RAM. Alpine is substantially slower with this method, but it works. I got this trick from Eduardo Chappa, thread: Date: Fri, 23 Jun 2023 11:48:01 +0200 (CEST) From: Carlos E. R. To: Alpine info Subject: [Alpine-info] Sudenly, a rule doesn't work. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar) -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 209 bytes Desc: OpenPGP digital signature URL: From alpine-info at u.washington.edu Sat Jul 27 14:25:21 2024 From: alpine-info at u.washington.edu (Eduardo Chappa via Alpine-info) Date: Sat Jul 27 14:25:32 2024 Subject: [Alpine-info] Search problem In-Reply-To: References: Message-ID: <555311c2-9b3b-9d97-9f5b-c1caed9d67e5@yandex.com> On Sat, 27 Jul 2024, Olaf Skibbe via Alpine-info wrote: > I am in the INBOX of the account and want to select all mails from a > certain sender. I do > > ; T F > > where is in this case something in the "From" header, > e.g. > > ; T F olaf > > should find mails with a line like this in the header: > > From: Olaf Skibbe > > But actually, the result of the sequence "; T F " is > always empty, regardless of obvious matching mails. It seems like your IMAP server, who is the one doing the search, is not finding messages. Have you tried searching for an email address instead? Maybe your server searches that field. On another note, Alpine can do the search instead of the server, but this requires that Alpine downloads the information first (which is closer to what Thunderbirds does before it shows your the index). In order to force Alpine to do the search you would have to modify your configuration to add the flag "/loser" into it. For example, if your inbox-path, say, is {some.server.com/ssl/user=yourid}INBOX then that needs to be modified to {some.server.com/ssl/user=yourid/loser}INBOX for Alpine to do the search. Please understand that there is a price to pay here, and that is that Alpine has to download the missing information on the folder, which will take time. The second time a search is done Alpine will search in the cached information, so it will be much faster than the first time, however, in both cases the search will be done correctly. > [...] > I would appreciate hints to how I could maybe get around this issue (I > use the select functions very much, dozens of times every day for many > years) or how I can evaluate the problem in more detail to address the > people at Strato with it. In regards to how to debug this in Alpine, simply reproduce the issue, and once it has been reproduced press M J and set the debug level to 9, then look for the lines that say IMAP DEBUG. The one of interest to you is the one that says "SEARCH FROM" and the contents that follow it immediately. I do not recall how to debug Thunderbird, but a quick search in DuckDuckgo.com will get you the answer your are looking for. I hope this helps. -- Eduardo From alpine-info at u.washington.edu Sun Jul 28 04:38:44 2024 From: alpine-info at u.washington.edu (Olaf Skibbe via Alpine-info) Date: Sun Jul 28 04:38:51 2024 Subject: [Alpine-info] Search problem In-Reply-To: <555311c2-9b3b-9d97-9f5b-c1caed9d67e5@yandex.com> References: <555311c2-9b3b-9d97-9f5b-c1caed9d67e5@yandex.com> Message-ID: <8c2e382a-465a-be5e-9b06-94a281cd8682@kravcenko.com> Dear Eduardo and Carlos, Thank you very much for your support. On Sat, 27 Jul 2024 at 15:25, Eduardo Chappa via Alpine-info wrote: > On Sat, 27 Jul 2024, Olaf Skibbe via Alpine-info wrote: > >> But actually, the result of the sequence "; T F " is >> always empty, regardless of obvious matching mails. > > It seems like your IMAP server, who is the one doing the search, is > not finding messages. Have you tried searching for an email address > instead? Maybe your server searches that field. This does not change the behavior. > On another note, Alpine can do the search instead of the server, but > this requires that Alpine downloads the information first (which is > closer to what Thunderbirds does before it shows your the index). In > order to force Alpine to do the search you would have to modify your > configuration to add the flag "/loser" into it. This works, but... > Please understand that there is a price to pay here, and that is that > Alpine has to download the missing information on the folder, which > will take time. The second time a search is done Alpine will search in > the cached information, so it will be much faster than the first time, > however, in both cases the search will be done correctly. ...does this apply for the full text search as well? I just did ; T A on a 360M sized INBOX with the flag /loser set. It took about 10 seconds, the downloaded data was below 1M. So the full text search is still done on the server, right? If the /loser flag only downloads the headers to search them locally, this might be a way to go. > In regards to how to debug this in Alpine, simply reproduce the issue, > and once it has been reproduced press M J and set the debug level to > 9, then look for the lines that say IMAP DEBUG. The one of interest to > you is the one that says "SEARCH FROM" and the contents that follow it > immediately. Ah, I did not knew this function. I checked this with a pattern which matches the FROM header of one mail in the INBOX: ; T F and got the message: [Select failed. No messages selected.] The journal contains: IMAP DEBUG 12:57:15 7/28: 1800001c SEARCH FROM IMAP DEBUG 12:57:15 7/28: * SEARCH IMAP DEBUG 12:57:15 7/28: 1800001c OK SEARCH completed (0.000 s) Then I did ; T P which selected the expected mail. The journal now contains: IMAP DEBUG 13:02:39 7/28: 18000025 SEARCH OR (TO ) (OR (CC ) (FROM )) IMAP DEBUG 13:02:39 7/28: * SEARCH 5 IMAP DEBUG 13:02:39 7/28: 18000025 OK SEARCH completed (0.009 s) Searching in the CC or the TO header does not select the mail, since the pattern can only be found in the FROM header. Is there something the learn from the debug information? Thanks again, Olaf From alpine-info at u.washington.edu Sun Jul 28 04:56:43 2024 From: alpine-info at u.washington.edu (Olaf Skibbe via Alpine-info) Date: Sun Jul 28 04:56:50 2024 Subject: [Alpine-info] Search problem In-Reply-To: <8c2e382a-465a-be5e-9b06-94a281cd8682@kravcenko.com> References: <555311c2-9b3b-9d97-9f5b-c1caed9d67e5@yandex.com> <8c2e382a-465a-be5e-9b06-94a281cd8682@kravcenko.com> Message-ID: <2ad9d115-dd25-a6aa-c665-c67c82fe5ae3@kravcenko.com> Hi again, It gets weirder: I just received my mail to the list. It appeared in the INBOX as new. Without opening it, I did ; T F skibbe and the message was selected. Note that there are many more messages matching the pattern "skibbe" in the FROM header, but they were not selected. The debug entry is ("Olaf" is the name of the mailbox): imap_cmd(Olaf, SEARCH, 0x1) IMAP DEBUG 13:39:24 7/28: 01000b0a SEARCH FROM skibbe IMAP DEBUG 13:39:24 7/28: * SEARCH 269 IMAP DEBUG 13:39:24 7/28: 01000b0a OK SEARCH completed (0.000 s) cancel_busy_cue(0) stop_after(join=0) tid=824fb140 cancel_busy_cue(0) stop_after(join=0) tid=824fb140 Then I opened the message, got back to the overview and did the same search. Now again nothing was selected. Debug; imap_cmd(Olaf, SEARCH, 0x1) IMAP DEBUG 13:41:17 7/28: 01000b1c SEARCH FROM skibbe IMAP DEBUG 13:41:17 7/28: * SEARCH IMAP DEBUG 13:41:17 7/28: 01000b1c OK SEARCH completed (0.000 s) cancel_busy_cue(0) stop_after(join=0) tid=824fb140 cancel_busy_cue(0) stop_after(join=0) tid=824fb140 I guess I will try to contact Strato about this issue. Best regards, Olaf On Sun, 28 Jul 2024 at 13:38, Olaf Skibbe via Alpine-info wrote: > Dear Eduardo and Carlos, > > Thank you very much for your support. > > On Sat, 27 Jul 2024 at 15:25, Eduardo Chappa via Alpine-info wrote: > >> On Sat, 27 Jul 2024, Olaf Skibbe via Alpine-info wrote: >> >>> But actually, the result of the sequence "; T F " is >>> always empty, regardless of obvious matching mails. >> >> It seems like your IMAP server, who is the one doing the search, is not >> finding messages. Have you tried searching for an email address instead? >> Maybe your server searches that field. > > This does not change the behavior. > >> On another note, Alpine can do the search instead of the server, but this >> requires that Alpine downloads the information first (which is closer to >> what Thunderbirds does before it shows your the index). In order to force >> Alpine to do the search you would have to modify your configuration to add >> the flag "/loser" into it. > > This works, but... > >> Please understand that there is a price to pay here, and that is that >> Alpine has to download the missing information on the folder, which will >> take time. The second time a search is done Alpine will search in the >> cached information, so it will be much faster than the first time, however, >> in both cases the search will be done correctly. > > ...does this apply for the full text search as well? I just did > > ; T A > > on a 360M sized INBOX with the flag /loser set. It took about 10 seconds, the > downloaded data was below 1M. So the full text search is still done on the > server, right? > > If the /loser flag only downloads the headers to search them locally, this > might be a way to go. > >> In regards to how to debug this in Alpine, simply reproduce the issue, and >> once it has been reproduced press M J and set the debug level to 9, then >> look for the lines that say IMAP DEBUG. The one of interest to you is the >> one that says "SEARCH FROM" and the contents that follow it immediately. > > Ah, I did not knew this function. I checked this with a pattern which matches > the FROM header of one mail in the INBOX: > > ; T F > > and got the message: [Select failed. No messages selected.] > > The journal contains: > > IMAP DEBUG 12:57:15 7/28: 1800001c SEARCH FROM > IMAP DEBUG 12:57:15 7/28: * SEARCH > IMAP DEBUG 12:57:15 7/28: 1800001c OK SEARCH completed (0.000 s) > > Then I did > > ; T P > > which selected the expected mail. The journal now contains: > > IMAP DEBUG 13:02:39 7/28: 18000025 SEARCH OR (TO ) (OR (CC > ) (FROM )) > IMAP DEBUG 13:02:39 7/28: * SEARCH 5 > IMAP DEBUG 13:02:39 7/28: 18000025 OK SEARCH completed (0.009 s) > > Searching in the CC or the TO header does not select the mail, since the > pattern can only be found in the FROM header. > > Is there something the learn from the debug information? > > Thanks again, > Olaf > _______________________________________________ > Alpine-info mailing list > Alpine-info@u.washington.edu > http://mailman12.u.washington.edu/mailman/listinfo/alpine-info > From alpine-info at u.washington.edu Sun Jul 28 08:06:02 2024 From: alpine-info at u.washington.edu (Eduardo Chappa via Alpine-info) Date: Sun Jul 28 08:06:14 2024 Subject: [Alpine-info] Search problem In-Reply-To: <2ad9d115-dd25-a6aa-c665-c67c82fe5ae3@kravcenko.com> References: <555311c2-9b3b-9d97-9f5b-c1caed9d67e5@yandex.com> <8c2e382a-465a-be5e-9b06-94a281cd8682@kravcenko.com> <2ad9d115-dd25-a6aa-c665-c67c82fe5ae3@kravcenko.com> Message-ID: <4f325510-9a06-509d-cdaf-0ed21089c27e@yandex.com> On Sun, 28 Jul 2024, Olaf Skibbe wrote: > It gets weirder: > > I just received my mail to the list. It appeared in the INBOX as new. > Without opening it, I did > > ; T F skibbe > > and the message was selected. > [...] It seems that your messages are selected if they are unseen. Try to see if flagging all messages "Not New" (; a a * ! N) and then doing the search produces the correct results. Another suggestion. Try to see if searching headers produces the result. In this case try ; t h From I hope any of this helps. -- Eduardo From alpine-info at u.washington.edu Sun Jul 28 14:44:10 2024 From: alpine-info at u.washington.edu (Olaf Skibbe via Alpine-info) Date: Sun Jul 28 14:44:18 2024 Subject: [Alpine-info] Search problem In-Reply-To: <4f325510-9a06-509d-cdaf-0ed21089c27e@yandex.com> References: <555311c2-9b3b-9d97-9f5b-c1caed9d67e5@yandex.com> <8c2e382a-465a-be5e-9b06-94a281cd8682@kravcenko.com> <2ad9d115-dd25-a6aa-c665-c67c82fe5ae3@kravcenko.com> <4f325510-9a06-509d-cdaf-0ed21089c27e@yandex.com> Message-ID: <32083c72-b05c-67a9-e273-7fbd9a36c7fe@kravcenko.com> On Sun, 28 Jul 2024 at 09:06, Eduardo Chappa wrote: > On Sun, 28 Jul 2024, Olaf Skibbe wrote: > >> It gets weirder: >> >> I just received my mail to the list. It appeared in the INBOX as new. >> Without opening it, I did >> >> ; T F skibbe >> >> and the message was selected. >> [...] > > It seems that your messages are selected if they are unseen. Try to see if > flagging all messages "Not New" (; a a * ! N) and then doing the search > produces the correct results. No, this does not change anything. > Another suggestion. Try to see if searching headers produces the result. In > this case try > > ; t h From Again, same result. I took another look at the Thunderbird search: In the search dialog there is the option "Run search on server". Here, I get the same result: Search for e.g. "From contains " does not find the messages when the search is run on the server, and finds messages when the option is off. In other words: same or similar behavior as alpine. >From that I think it is very likely that the problem is at Strato. For the time being, I will use the setting with /loser. This seems to work sufficiently fast, at least for an temporary solution Eduardo, thanks very much for your patient support! Cheers, Olaf From alpine-info at u.washington.edu Sun Jul 28 15:35:18 2024 From: alpine-info at u.washington.edu (Clark I Anderson via Alpine-info) Date: Sun Jul 28 15:35:21 2024 Subject: [Alpine-info] Please Remove From List Message-ID: <941086388.22254377.1722206118103.JavaMail.zimbra@indra.com> Please Me Remove From List -- Clark Anderson From alpine-info at u.washington.edu Mon Jul 29 02:43:04 2024 From: alpine-info at u.washington.edu (Carlos E. R. via Alpine-info) Date: Mon Jul 29 02:43:12 2024 Subject: [Alpine-info] Please Remove From List In-Reply-To: <941086388.22254377.1722206118103.JavaMail.zimbra@indra.com> References: <941086388.22254377.1722206118103.JavaMail.zimbra@indra.com> Message-ID: <09b58dbc-460e-4e3a-1ee4-f9ce548e67a6@telefonica.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2024-07-28 at 16:35 -0600, Clark I Anderson via Alpine-info wrote: > Please Me Remove From List Do it yourself. Instructions on every list email: List-Unsubscribe: , Send an empty email to "alpine-info-request@mailman12.u.washington.edu" with subject line "unsubscribe" - -- Cheers, Carlos E. R. (from openSUSE 15.5 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZqdkKBwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVhVwAn3xFEVE/MekHcEf7oWDR VEUvB+v/AJ0Q6Y7b1rMwy9M+j2NX3FioShU94g== =LBoG -----END PGP SIGNATURE----- From alpine-info at u.washington.edu Tue Jul 30 13:42:05 2024 From: alpine-info at u.washington.edu (Andrew C Aitchison via Alpine-info) Date: Tue Jul 30 13:42:16 2024 Subject: [Alpine-info] copying lengthy embedded url's possible? In-Reply-To: References: Message-ID: <45cfa4da-20ff-6caf-d70b-1053e9824a21@aitchison.me.uk> >On 21/7/24 04:15, James Miller via Alpine-info wrote: >> >> Here's my scenario. I'm almost always doing my Alpine e-mail tasks while >> logged in via an ssh session. That is by design since e-mail, for me, is >> preferably a textual rather than graphical affair. So, think text-mode, >> keyboard driven. Let's call the computer where Alpine is running the ssh >> host and the one I've initiated the ssh login from the ssh client. >> >> A problem I've encountered but have so far been unable to resolve is >> that I am sometimes, in order to pass a security check, sent by e-mail some >> extremely lengthy embedded URL that is supposed to allow me to sign in to >> some account or other of mine. When this happens, what I'd like to do is >> open the link in a graphical environment and browser running on the ssh >> client computer. Were I able to get the whole URL to somehow display in >> Alpine, I'd just use my mouse to copy it, then paste the URL into a >> graphical browser: this is what I used to do before such URL's began to >> exceed all reasonable URL length conventions (I assume for security >> reasons). >> >> I've tried using Alpine's edit URL option but so far that has failed >> because I can only view/copy, at one time, maybe 50 characters of the >> hundreds of characters that comprise the URL. Given the complexity of the >> URL and the fact that numerous segments need to be separately displayed, >> then copied/pasted, the chance are high that some mistake(s) will be made, >> thus resulting in an invalid URL. And in addition, the time it can take to >> copy/paste in this fashion can exceed the validity interval of the URL. >> >> So, am I missing some way to display, for copy/pasting purposes, these >> mile-long URL's in Alpine? If not, can anyone suggest a workaround? >> >> Thanks >> >> PS I do have on the ssh host a text-mode browser and Alpine is >> configured to open URL's using that browser, but the lengthy embedded URL's >> usually fail to open using that means since the page being requested >> requires a java-enabled browser. On Sun, 21 Jul 2024, Damion Yates via Alpine-info replied: > I've been doing this for many many years, so have several ideas for you: > > 1) If you use Firefox locally and your remote machine spawns `firefox url` > from alpine, then add long as you made the SSH connection using -X, some > X11 magic makes the local Firefox jump to the URL. [ The command `firefox --noremote URL` disables this feature. ] > 2) Configure alpine to spawn your own shell script. That script should echo > the URL and sleep for 5 seconds. This will let you c+p cleanly (might > require some terminfo config on wide screen wrapping), this is the most > likely to solve your issue better than trying to grab parts of the URL from > the email, edit URL line or even view headers/raw (which will not resolve > quoted-printable). The script can clear the screen and return after. Thanks. I have a similar script, but I hadn't thought of getting it to print the URL cleanly. Even when the URL is shown in plain in the message (rather than just being an html link target as in James's case) alpine wraps it before the end of the screen, so copy'n'paste drags in whitespace between the chunks of URL. > 3) Adapting on the script idea you can have it intelligently determine > things about your session. For example in my case my alpine is at work, of > I'm there I want to just spawn a new chrome tab, this works fine. If > `xlock` is running, I'm likely remote and the script follows different > conditional logic. If there is no $DISPLAY then it does the echo & pause > thing from 2), if there is, then I use xdotool and xclip to remotely select > chrome, ^t and paste a URL in, all over X forwarding. This simulates the > firefox ability and is significantly faster than trying to X a whole > browser. Thanks for the suggestion of xclip in this script; it is working very nicely for me using bVNC from an Android tablet. I can now activate the URL from alpine in my VNC session, switch back to the local firefox to paste the URL and view the page. As well as DISPLAY my script uses the XDG_SESSION_TYPE and TERM environment variables to help determine which action to perform. -- Andrew C. Aitchison Kendal, UK andrew@aitchison.me.uk From alpine-info at u.washington.edu Wed Jul 31 04:38:07 2024 From: alpine-info at u.washington.edu (Carlos E. R. via Alpine-info) Date: Wed Jul 31 04:38:13 2024 Subject: [Alpine-info] Question for List Administrator In-Reply-To: <15e8e554-7496-406e-a281-c3ecab0e7ff3@busby.net> References: <15e8e554-7496-406e-a281-c3ecab0e7ff3@busby.net> Message-ID: On 2024-07-20 23:09, Bret Busby via Alpine-info wrote: > On 21/7/24 04:41, Bret Busby via Alpine-info wrote: >> On 21/7/24 04:15, James Miller via Alpine-info wrote: > > Why has the mailing list administration been changed to conceal the > email address of posters? > > Is that to prohibit subscribers from directly contacting a poster of a > message, in response to content of a post, and, to prohibit subscribers > from blocking email from a particular poster, if a poster shows > delinquent behaviour? > > This change to the mailing list administration is ominous. This is because mail having the poster email, but being actually sent by a list server break security features such as DKIM-Signature, dmarc, or others (I don't remember which one, exactly), but make the receiving mail server reject the mail as if forged or manipulated in transit. Thus the list mail server has to change the "From" line and add a new Reply-To: From: Bret Busby via Alpine-info Reply-To: Bret Busby <...> Ie, if doing it the traditional way the receiving servers see that the post is coming from u.washington.edu but have a from address someone.com, which they consider invalid and reject the email. That's hundreds of rejects and mail users angry because their mail is not received by subscribers. It is a consequence of the fight on spam. This is happening on several mail lists. Some do it only for some domains, some do it for everybody. This can not be avoided. I had this explained by an admin on another mail list, but I can not locate his post with the correct explanation. What I wrote is from memory. Oh, found it (the short version): ?It is called "DMARC mitigation". We do that for sending domains with DMARC policies.? Well, u.washington.edu seems to be doing it for everybody. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar) -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 209 bytes Desc: OpenPGP digital signature URL: From alpine-info at u.washington.edu Wed Jul 31 07:29:14 2024 From: alpine-info at u.washington.edu (via Alpine-info) Date: Wed Jul 31 07:29:18 2024 Subject: [Alpine-info] Alpine 2.26 does not save SMTP password in macOS Keychain References: Message-ID: Nobody else using Alpine on Mac and running into this SMTP password saving issue? Alternatively, can I save the SMTP password to a file on Mac or is it all Keychain only? It's hard to find any info on what should work and how. Any tips appreciated, thanks! > Using Alpine 2.26 on macOS. Both IMAP and SMTP servers require passwords > for auth. Alpine saves the IMAP password in the macOS Keychain, but not > the SMTP password so I have to type it at least once per session. > > Is this a known issue or just a "me problem" that might have a fix? Is > there a way to maybe add the key myself to the Keychain? From alpine-info at u.washington.edu Wed Jul 31 10:33:02 2024 From: alpine-info at u.washington.edu (Karen Lewellen via Alpine-info) Date: Wed Jul 31 10:33:06 2024 Subject: [Alpine-info] Question for List Administrator In-Reply-To: References: <15e8e554-7496-406e-a281-c3ecab0e7ff3@busby.net> Message-ID: QWgsIGluZGVlZC4gIEkgaW1hZ2luZSB0aGF0IGl0IGlzICBwYXJ0IG9mIGEgbW92ZSwgc2luY2Ug cm91Z2hseSBNYXJjaCwgDQp3aGVyZSAgbWFueSBtYWlsIHNvdXJjZXMgbGlrZSB5YWhvbyBhbmQg Z29vZ2xlIGFyZSBibG9ja2luZyBhZGRyZXNzZXMgZnJvbSANCnBsYWNlcyB3aGVyZSB0aGUgaG9z dG5hbWUgY2Fubm90IGJlIGlkZW50aWZpZWQgYXMgdGhleSBkZWZpbmUgdGhhdCANCmNvbmNlcHQu DQpJIGNhbiBubyBsb25nZXIgcG9zdCB0byBmcmVlbGlzdC5vcmcgZm9yIGV4YW1wbGUsIGJlY2F1 c2UgdGhlIGd1eSB3aG8gb3ducyANCnNoZWxsd29ybGQgaGFzIG5vdCB1cGRhdGVkIHRoZSBwdHIg cmVjb3JkLi53aWxsIGJlIGludGVyZXN0aW5nIGlmIHRoaXMgDQpwb3N0IGdldHMgIHRocm91Z2gu DQpLYXJlbg0KDQoNCg0KT24gV2VkLCAzMSBKdWwgMjAyNCwgQ2FybG9zIEUuIFIuIHZpYSBBbHBp bmUtaW5mbyB3cm90ZToNCg0KPiBPbiAyMDI0LTA3LTIwIDIzOjA5LCBCcmV0IEJ1c2J5IHZpYSBB bHBpbmUtaW5mbyB3cm90ZToNCj4+ICBPbiAyMS83LzI0IDA0OjQxLCBCcmV0IEJ1c2J5IHZpYSBB bHBpbmUtaW5mbyB3cm90ZToNCj4+ID4gIE9uIDIxLzcvMjQgMDQ6MTUsIEphbWVzIE1pbGxlciB2 aWEgQWxwaW5lLWluZm8gd3JvdGU6DQo+Pg0KPj4gIFdoeSBoYXMgdGhlIG1haWxpbmcgbGlzdCBh ZG1pbmlzdHJhdGlvbiBiZWVuIGNoYW5nZWQgdG8gY29uY2VhbCB0aGUgZW1haWwNCj4+ICBhZGRy ZXNzIG9mIHBvc3RlcnM/DQo+Pg0KPj4gIElzIHRoYXQgdG8gcHJvaGliaXQgc3Vic2NyaWJlcnMg ZnJvbSBkaXJlY3RseSBjb250YWN0aW5nIGEgcG9zdGVyIG9mIGENCj4+ICBtZXNzYWdlLCBpbiBy ZXNwb25zZSB0byBjb250ZW50IG9mIGEgcG9zdCwgYW5kLCB0byBwcm9oaWJpdCBzdWJzY3JpYmVy cw0KPj4gIGZyb20gYmxvY2tpbmcgZW1haWwgZnJvbSBhIHBhcnRpY3VsYXIgcG9zdGVyLCBpZiBh IHBvc3RlciBzaG93cyBkZWxpbnF1ZW50DQo+PiAgYmVoYXZpb3VyPw0KPj4NCj4+ICBUaGlzIGNo YW5nZSB0byB0aGUgbWFpbGluZyBsaXN0IGFkbWluaXN0cmF0aW9uIGlzIG9taW5vdXMuDQo+DQo+ IFRoaXMgaXMgYmVjYXVzZSBtYWlsIGhhdmluZyB0aGUgcG9zdGVyIGVtYWlsLCBidXQgYmVpbmcg YWN0dWFsbHkgc2VudCBieSBhIA0KPiBsaXN0IHNlcnZlciBicmVhayBzZWN1cml0eSBmZWF0dXJl cyBzdWNoIGFzIERLSU0tU2lnbmF0dXJlLCBkbWFyYywgIG9yIG90aGVycyANCj4gKEkgZG9uJ3Qg cmVtZW1iZXIgd2hpY2ggb25lLCBleGFjdGx5KSwgYnV0IG1ha2UgdGhlIHJlY2VpdmluZyBtYWls IHNlcnZlciANCj4gcmVqZWN0IHRoZSBtYWlsIGFzIGlmIGZvcmdlZCBvciBtYW5pcHVsYXRlZCBp biB0cmFuc2l0Lg0KPg0KPiBUaHVzIHRoZSBsaXN0IG1haWwgc2VydmVyIGhhcyB0byBjaGFuZ2Ug dGhlICJGcm9tIiBsaW5lIGFuZCBhZGQgYSBuZXcgDQo+IFJlcGx5LVRvOg0KPg0KPiBGcm9tOiBC cmV0IEJ1c2J5IHZpYSBBbHBpbmUtaW5mbyA8YWxwaW5lLWluZm9AdS53YXNoaW5ndG9uLmVkdT4N Cj4gUmVwbHktVG86IEJyZXQgQnVzYnkgPC4uLj4NCj4NCj4gSWUsIGlmIGRvaW5nIGl0IHRoZSB0 cmFkaXRpb25hbCB3YXkgdGhlIHJlY2VpdmluZyBzZXJ2ZXJzIHNlZSB0aGF0IHRoZSBwb3N0IA0K PiBpcyBjb21pbmcgZnJvbSB1Lndhc2hpbmd0b24uZWR1IGJ1dCBoYXZlIGEgZnJvbSBhZGRyZXNz IHNvbWVvbmUuY29tLCB3aGljaCANCj4gdGhleSBjb25zaWRlciBpbnZhbGlkIGFuZCByZWplY3Qg dGhlIGVtYWlsLiBUaGF0J3MgaHVuZHJlZHMgb2YgcmVqZWN0cyBhbmQgDQo+IG1haWwgdXNlcnMg YW5ncnkgYmVjYXVzZSB0aGVpciBtYWlsIGlzIG5vdCByZWNlaXZlZCBieSBzdWJzY3JpYmVycy4g SXQgaXMgYSANCj4gY29uc2VxdWVuY2Ugb2YgdGhlIGZpZ2h0IG9uIHNwYW0uDQo+DQo+DQo+IFRo aXMgaXMgaGFwcGVuaW5nIG9uIHNldmVyYWwgbWFpbCBsaXN0cy4gU29tZSBkbyBpdCBvbmx5IGZv ciBzb21lIGRvbWFpbnMsIA0KPiBzb21lIGRvIGl0IGZvciBldmVyeWJvZHkuDQo+DQo+IFRoaXMg Y2FuIG5vdCBiZSBhdm9pZGVkLg0KPg0KPg0KPiBJIGhhZCB0aGlzIGV4cGxhaW5lZCBieSBhbiBh ZG1pbiBvbiBhbm90aGVyIG1haWwgbGlzdCwgYnV0IEkgY2FuIG5vdCBsb2NhdGUgDQo+IGhpcyBw b3N0IHdpdGggdGhlIGNvcnJlY3QgZXhwbGFuYXRpb24uIFdoYXQgSSB3cm90ZSBpcyBmcm9tIG1l bW9yeS4NCj4NCj4gT2gsIGZvdW5kIGl0ICh0aGUgc2hvcnQgdmVyc2lvbik6DQo+DQo+IMKrSXQg aXMgY2FsbGVkICJETUFSQyBtaXRpZ2F0aW9uIi4gIFdlIGRvIHRoYXQgZm9yIHNlbmRpbmcgZG9t YWlucyB3aXRoDQo+IERNQVJDIHBvbGljaWVzLsK7DQo+DQo+IFdlbGwsIHUud2FzaGluZ3Rvbi5l ZHUgc2VlbXMgdG8gYmUgZG9pbmcgaXQgZm9yIGV2ZXJ5Ym9keS4NCj4NCj4NCj4NCj4gLS0gDQo+ IENoZWVycyAvIFNhbHVkb3MsDQo+DQo+IAkJIENhcmxvcyBFLiBSLg0KPiAJCSAoZnJvbSAxNS41 IHg4Nl82NCBhdCBUZWxjb250YXIpDQo+DQo+DQo+Cg== From alpine-info at u.washington.edu Wed Jul 31 13:12:35 2024 From: alpine-info at u.washington.edu (Carlos E. R. via Alpine-info) Date: Wed Jul 31 13:12:43 2024 Subject: [Alpine-info] Question for List Administrator In-Reply-To: References: <15e8e554-7496-406e-a281-c3ecab0e7ff3@busby.net> Message-ID: <80ae967f-2b21-4c2f-8423-465d41abd3b1@telefonica.net> On 2024-07-31 19:33, Karen Lewellen via Alpine-info wrote: > Ah, indeed.? I imagine that it is? part of a move, since roughly March, > where? many mail sources like yahoo and google are blocking addresses > from places where the hostname cannot be identified as they define that > concept. > I can no longer post to freelist.org for example, because the guy who > owns shellworld has not updated the ptr record..will be interesting if > this post gets? through. > Karen You have to blame DMARC on your supplier, though, not on the recipient. The receiving server simply follows the orders of the sender domain, ie, shellworld. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar) -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 209 bytes Desc: OpenPGP digital signature URL: