From mbmiller+l at gmail.com Tue May 1 16:57:24 2018 From: mbmiller+l at gmail.com (Mike Miller) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] IMAP connection failing from outside home network Message-ID: I am using Alpine to connect to the secure IMAP server (port 993) on a server in my home. When I connect from other machines on the 192.168.0.XXX network, no problem, but when I try to do it from my laptop from a remote location, it doesn't work. It times out, but it does make some kind of connection. I can see a list of the incoming folders, for example, but the numbers of messages are replaced with question marks and I can't open the folders. I'm not sure of where to look for the cause of the problem. Any ideas? Thanks! Mike From ullbeking at andrewnesbit.org Wed May 2 08:00:12 2018 From: ullbeking at andrewnesbit.org (Andrew Nesbit) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] OpenPGP integration with Alpine Message-ID: Hello, After a long hiatus in my use of Alpine, I've returned to experiment with it. I need to see if it can support my current workflow. The main issue is OpenPGP support. Of course I would prefer full compliance with RFC 3156 "MIME Security with OpenPGP" (https://www.rfc-editor.org/in-notes/rfc3156.txt). I understand that Alpine does not implement this natively. I am using GnuPG, with key management usually performed using its CLI. I searched the mailing list archives and the web for solutions, and discovered a multitude of options. Most seem to involve using external filters and piping messages through `display-filters` and `sending-filters`. I haven't looked at anything in detail yet. For example, I don't know if `sending-filters` is expected to return a fully formed MIME message, or just fragments of one that Alpine subsequently assembles into the outgoing message. Another issue is that each solution has its own set of quirks and gotchas. It seems to be very easy to shoot oneself in the in the foot. Is there a generally accepted set of best practices or tooling in the Alpine community today for sending and receiving OpenPGP/MIME messages? What is the currently recommended state of the art in using GnuPG to encrypt and decrypt message in Alpine? Of course I can do key management using the native GnuPG tools, so I don't expect Alpine to do that for me. But I would expect something that can digitally sign outgoing messages and verify signed, incoming messages. Any suggestions or links would be greatly appreciated. Thanks!! Kindest regards, Andrew -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9 From danm at prime.gushi.org Wed May 2 16:10:22 2018 From: danm at prime.gushi.org (Dan Mahoney (Gushi)) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] OpenPGP integration with Alpine In-Reply-To: References: Message-ID: On Wed, 2 May 2018, Andrew Nesbit wrote: > Hello, > > After a long hiatus in my use of Alpine, I've returned to experiment with it. > I need to see if it can support my current workflow. > > The main issue is OpenPGP support. Of course I would prefer full compliance > with RFC 3156 "MIME Security with OpenPGP" > (https://www.rfc-editor.org/in-notes/rfc3156.txt). I use PGP heavily in both my work and personal lives. Day job is with a well-known company that makes open-source software, where I take part in the security-officer role. In general, *never* having decrypted copies of email on my carry-around terminal is valuable to me. Doug Barton's pine-pgp filters do an admirable job of handling PGP messages when they have the BEGIN PGP message thing, but alpine itself lacks a few things. That said, I should probably start with a better description of the problem you're trying to solve. When you get a "classic" PGP message, it's typically plain-text and has When you get an RFC3156 message, you get two attachments: The first has a mime type of Application/PGP-ENCRYPTED, which turns out to be, in plaintext, something like "Version: 1". The second has a mime-type of application/octet-stream (which most mailers would treat as a binary file), but this too is 7-bit-safe plain text in the normal BEGIN PGP MESSAGE type. So, the one that says encrypted, isn't. And the one that says octet-stream, isn't. And this is per the RFC. That feels broken to me. So, now for the problems presented by this: 1) Alpine's sending filters don't know how to act on anything other than the message body. (Viewing problem) 2) Filters don't know how to change the mime-type of the message body. (Sending problem) 3) Filters they don't know how to detect a specific body *segment* and define a viewer for it. They totally don't know how to define a viewer that says "if a message has two parts, and one is this, the other must be this" (Viewing problem) 4) Alpine lacks a way to define an *inline* viewer for items. I haven't, for example, had much luck displaying inline images with aaview. Alpine's not a browser. (Viewing problem) So, as for "making alpine do this natively" solutions: 5a) I've suggested to eduardo that there may be a simple way forward here -- giving the user a way (via roles, or a menu at send-time) to invoke an alternate sendmail binary that can be used which would invoke GPG, and then hand a message off to sendmail (or the delivery-agent on your local machine which would be aware of. The net effect of this is that the message in your outbox is the *unencrypted* version. The functionality that would be required is twofold. a) The method to choose this to happen. b) The need to call that mailer interactively so you can do pinentry and answer questions. 5b) Making it so a sending filter can affect the WHOLE message, add attachments, add body types, run the message through a virus scanner, attach .vcf files, etc. The net result is that the modified message is what gets saved to your sent-mail folder. But it's more code. It would require: a) A ---- Now, as to how I *actually* use PGP in my day-to-day life. I use DougB's filters. When I send, I get a list of filters that I can send through which will send it on, encrypt it, and sign it. If someone sends me an "inline" pgp message, this is seen by the display filter, whisked off to GPG, and displays in my mailer. The unencrypted message is not saved to my inbox. If someone sends me a "mime" pgp encrypted message, I see a file that I can save, and manually cat into GPG in a terminal window (I use screen, this isn't hard). For sending, I just accept that I will always (if I choose to use GPG) send using the inline method. It's usable, but annoying. I've asked on this list several times about getting the native code in Alpine to make this work. I don't think it's a *lot* of work, but I'm not a C-coder and I don't know the codebase. I've never outright asked Eduardo, publicly or privately, if he's interested in being paid for this work, but if he had an amazon wishlist he wanted to post, I think most people who use this software owe him a debt of gratitude. Alpine, per-se, lacks any kind of real sponsored features or bug-bounties. Eduardo, do you have thoughts on this? Finally, other things I could do that are more rube-goldberg and may be more annoying and hacky in the long term: A) Since I control the horizontal and the vertical on my mail-servers, I could implement an inline-sendmail-milter that handled this for me, similar to how DKIM signs my headers. This would be very very non-interactive, so I don't like it. B) Since I have procmail available to me, it's a trivial amount of code to pipe any pgp-mime mail through a filter that converts it to "inline". C) I've tried without much success to create a way that a GPG program, when it needs a pinentry, will create a new screen in my screen session and alert me to its presense. No real luck there. D) I could do the same thing with whatever sendmail program I tell alpine to use, and just have *all* messages go through it, but perhaps require a header to be present: X-PGP-Do: (encrypt, sign, etc). E) I could have my sending filter hand off internally to GPG, and send the message, and replace it with some kind of sigil that says something like "this messsage was sent enrcypted and the original contents wiped", or even that gives *me* the inline copy, but adds a header that tells my mailer to *not* send it. Many of these break down if you're sending to a remote SMTP server you don't control, of course. Fixing alpine is the real answer. Hope this braindump helps, -Dan -- --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC FB: fb.com/DanielMahoneyIV LI: linkedin.com/in/gushi Site: http://www.gushi.org --------------------------- From dennisdavis at fastmail.fm Wed May 2 23:28:28 2018 From: dennisdavis at fastmail.fm (Dennis Davis) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] OpenPGP integration with Alpine In-Reply-To: References: Message-ID: On Wed, 2 May 2018, Dan Mahoney (Gushi) wrote: > From: "Dan Mahoney (Gushi)" > To: Andrew Nesbit > Cc: alpine-info@u.washington.edu > Date: Wed, 2 May 2018 16:10:22 -0700 (PDT) > Subject: Re: [Alpine-info] OpenPGP integration with Alpine > > On Wed, 2 May 2018, Andrew Nesbit wrote: > > > > After a long hiatus in my use of Alpine, I've returned to > > experiment with it. I need to see if it can support my current > > workflow. > > > > The main issue is OpenPGP support. Of course I would prefer > > full compliance with RFC 3156 "MIME Security with OpenPGP" > > (https://www.rfc-editor.org/in-notes/rfc3156.txt). > > I use PGP heavily in both my work and personal lives. Day job is > with a well-known company that makes open-source software, where > I take part in the security-officer role. In general, *never* > having decrypted copies of email on my carry-around terminal is > valuable to me. > > Doug Barton's pine-pgp filters do an admirable job of handling PGP > messages when they have the BEGIN PGP message thing, but alpine > itself lacks a few things. ... There's also the topal package which attempts to integrate PGP support into alpine. See: https://zircon.org.uk/topal/ I've never tried to use Doug Barton's pine-pgp filters or topal. So can't comment on either. Which makes this message little more than useless :-( However there has been some discussion on both the filters and topal on this mailing list which might be worth tracking down in the mail archives. -- Dennis Davis From ruskie at codemages.net Wed May 2 23:34:44 2018 From: ruskie at codemages.net (=?UTF-8?Q?Andra=C5=BE_'ruskie'_Levstik?=) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] OpenPGP integration with Alpine In-Reply-To: References: Message-ID: :2018-05-03T08:28:Dennis Davis: > There's also the topal package which attempts to integrate PGP > support into alpine. See: > > https://zircon.org.uk/topal/ I've used topal a lot myself - and it worked fine for my needs. -- Andra? 'ruskie' Levstik Geek/Hacker/Tinker Waiting for the computer to reboot. ? From lucio at lambrate.inaf.it Thu May 3 03:16:21 2018 From: lucio at lambrate.inaf.it (Lucio Chiappetti) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] path for certificates Message-ID: Unfortunately my institution is migrating from a site-dependent local e-mail system to a nationwide one based on Gsuite. I found that I can continue working as I used with my Alpine and procmail arrangement using fetchmail (can tell more to interested parties). I have only a CURIOSITY about Alpine certificate validation. If I define an incoming folder or a folder collection on imap.gmail.com:993 Alpine directs me to add the /ssl/novalidate-cert/notls switches. Trying instead to use fetchmail with equivalent "poll imap.gmail.com protocol imap port 993" I get a certificate error which can be easily overcome adding "ssl sslcertpath /etc/ssl/certs" ... ... i.e. all necessary certificates ARE ALREADY THERE in /etc/ssl/certs Is there a way (via a variable environment if not via .pinerc) to tell Alpine to look for certificates in /etc/ssl/certs avoiding the novalidate-cert switches ? -- Lucio Chiappetti - INAF/IASF - via Bassini 15 - I-20133 Milano (Italy) For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html ------------------------------------------------------------------------ "There Is No Cloud It's Just Someone Else's Computer. Non esiste 'il cloud'; e' solo il computer di qualcun altro" From alpine.chappa at gmx.com Thu May 3 11:05:56 2018 From: alpine.chappa at gmx.com (Eduardo Chappa) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] OpenPGP integration with Alpine In-Reply-To: References: Message-ID: On Wed, 2 May 2018, Dan Mahoney (Gushi) wrote: > 5a) I've suggested to eduardo that there may be a simple way forward here -- > giving the user a way (via roles, or a menu at send-time) to invoke an > alternate sendmail binary that can be used which would invoke GPG, and then > hand a message off to sendmail (or the delivery-agent on your local machine > which would be aware of. > [...] Since my name is mentioned... One of the problems that I have to face is to add functionality that can be implemented across operating systems, and across methods of using (e.g. use an SMTP server vs. sendmail) so something like this is only useful in a limited sense. I believe that coding PGP support into Alpine, like there is one for S/MIME support, is the correct way to go. Even if we only get it at the beginning for unix-Alpine, that would be a good step forward. Today S/MIME support is available for all versions of Alpine, including Windows and Unix due to the porting of LibreSSL to Windows. I think that there is already a library for PGP support for both unix-like operating systems and Windows, so this should be possible to get it done. There used to be a branch of re-alpine that was trying to add PGP support, but it was never completed. Maybe Ruskie knows what happened to it. > I've never outright asked Eduardo, publicly or privately, if he's > interested in being paid for this work, but if he had an amazon wishlist > he wanted to post, I think most people who use this software owe him a > debt of gratitude. Alpine, per-se, lacks any kind of real sponsored > features or bug-bounties. Eduardo, do you have thoughts on this? If we can get programmers motivated to contribute to Alpine through a bounty system, that would be great for all of us. The world keeps moving forward and we need to keep moving with it. My son told me, several weeks ago, that I should charge for supportig Alpine. If someone asked me to implement something that I should charge for it. What I told him was that there was no monetary value to implementing any feature because any user could simply choose another free program, instead of paying for a new feature. Many have already done this, and in the big picture we (Alpine users) are a small community. There is no point in trying to make it smaller by charging for my support. I will do it gladly. There are many important people in the world that depend on using Alpine, because of its features. Even if they go to use other email services, they still go back to Alpine for some of these features. I believe adding PGP support is in the list of features that would attract more people to return to Alpine, but it is not going to bring new people into Alpine. We need to avoid the migration out of Alpine by implementing new features, and a bounty system will certainly help with this. We just need to find someone who would be willing to fund this. -- Eduardo From alpine.chappa at gmx.com Fri May 4 18:02:41 2018 From: alpine.chappa at gmx.com (Eduardo Chappa) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] path for certificates In-Reply-To: References: Message-ID: On Thu, 3 May 2018, Lucio Chiappetti wrote: > Is there a way (via a variable environment if not via .pinerc) to tell > Alpine to look for certificates in /etc/ssl/certs avoiding the > novalidate-cert switches ? Alpine does not provide a user a way to specify the location of the certificates in the system. This is detected during compilation, and if the certificates are in a non-standard location, they must be specificied using the --with-ssl-dir= configure option, otherwise users get the failure in validation screen, which can be avoided by configuring Alpine correctly during compilation. Newer versions of Alpine are smarter in detecting the location of your certificates, so you might want to try a later version of Alpine to have this issue solved for you. I hope this helps. -- Eduardo From robin.listas at telefonica.net Sun May 6 05:07:32 2018 From: robin.listas at telefonica.net (Carlos E. R.) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Question about moving mail with procmail and Alpine Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'm testing an idea. This question involves both Alpine and procmail, but I start asking here. Wait, AFAIK there is no procmail mail list, anyway... I copy some already read email from an inbox to a local folder. It remains tagged as read. Then I apply a procmail rule to move from there to the final destination changing the header; the problem is that the posts are now considered "new", and I want them to be considered read or not the same as they were before moving. Is this possible? I can, however, in Alpine mark myself the last posts in the folder as "read", which is a little nuisance but works. The procmail rule is: DELIVER = "/usr/lib/dovecot/dovecot-lda" FORMAIL = "/usr/bin/formail" :0 * ^Delivered-To: (MESELF) { :0f * ^X-Mailinglist: opensuse-offtopic | $FORMAIL -bfi 'Reply-To: "oS (off topic)" ' :0 aw: $HOME/Mail/.D-locks/_Lists/os-ot.lock | $DELIVER -m _Lists/os-ot } And the operation is performed with formail -s procmail ./.procmail_r_tl < alpine_r_tl Where "alpine_r_tl" is the temporary test mail folder. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlru8AwACgkQtTMYHG2NR9X6tACgiKD7sKxSruQqw1PuOmuocaM0 /rcAoJJqU7+jHn7gnDp6G9WsRTrT54ss =Ba+/ -----END PGP SIGNATURE----- From alpine.chappa at gmx.com Sun May 6 08:35:09 2018 From: alpine.chappa at gmx.com (Eduardo Chappa) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Question about moving mail with procmail and Alpine In-Reply-To: References: Message-ID: On Sun, 6 May 2018, Carlos E. R. wrote: > Then I apply a procmail rule to move from there to the final destination > changing the header; the problem is that the posts are now considered > "new", and I want them to be considered read or not the same as they > were before moving. > > Is this possible? When you do this locally, the way that a message is considered new or read depends on the format of the folder. For example, in the case of the Unix format, this depends on the content of the "Status" header. For a message to be considered Read, its value must be "R". In addition, to be considered not new, its value must be "O" (old), so you want Status: RO as a header for the saved message. Just add that header, and that will do the trick. -- Eduardo http://repo.or.cz/alpine.git (Git) RSS: http://repo.or.cz/alpine.git/rss (Git updates) From robin.listas at telefonica.net Sun May 6 10:52:53 2018 From: robin.listas at telefonica.net (Carlos E. R.) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Question about moving mail with procmail and Alpine In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2018-05-06 at 09:35 -0600, Eduardo Chappa wrote: > On Sun, 6 May 2018, Carlos E. R. wrote: > >> Then I apply a procmail rule to move from there to the final destination >> changing the header; the problem is that the posts are now considered >> "new", and I want them to be considered read or not the same as they were >> before moving. >> >> Is this possible? > > When you do this locally, the way that a message is considered new or read > depends on the format of the folder. > > For example, in the case of the Unix format, this depends on the content of > the "Status" header. For a message to be considered Read, its value must be > "R". In addition, to be considered not new, its value must be "O" (old), so > you want > > Status: RO > > as a header for the saved message. Just add that header, and that will do the > trick. Thanks, I'll try that :-) - -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlrvQP0ACgkQtTMYHG2NR9W5ygCfeIaLachRr2cNKbZN+CAZpGyV gnAAn1uUb5pOHIWLRm1J6pPuHx6b2oCm =ZgSX -----END PGP SIGNATURE----- From schamane at fam.tuwien.ac.at Sun May 6 11:16:54 2018 From: schamane at fam.tuwien.ac.at (Andreas Schamanek) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Question about moving mail with procmail and Alpine In-Reply-To: References: Message-ID: On Sun, 6 May 2018, at 14:07, Carlos E. R. wrote: > AFAIK there is no procmail mail list, anyway... There is! It's a quiet, very low traffic place but still hosts a bunch of very helpful and knowledgeable folks: https://mailman.rwth-aachen.de/mailman/listinfo/procmail -- -- Andreas :-) From robin.listas at telefonica.net Sun May 6 11:47:41 2018 From: robin.listas at telefonica.net (Carlos E. R.) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Question about moving mail with procmail and Alpine In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2018-05-06 at 20:16 +0200, Andreas Schamanek wrote: > On Sun, 6 May 2018, at 14:07, Carlos E. R. wrote: > >> AFAIK there is no procmail mail list, anyway... > > There is! It's a quiet, very low traffic place but still hosts a bunch of > very helpful and knowledgeable folks: > https://mailman.rwth-aachen.de/mailman/listinfo/procmail Oh? :-O Many people say procmail is dead. This is a surprise. - -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlrvTc0ACgkQtTMYHG2NR9WW+ACeOrKGHtQds7zyKlwYxKEfasMk aHUAmQEZsJQwRbTkUFYohqGhXb0FBml1 =FFu/ -----END PGP SIGNATURE----- From robin.listas at telefonica.net Tue May 8 04:01:28 2018 From: robin.listas at telefonica.net (Carlos E. R.) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Question about moving mail with procmail and Alpine In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2018-05-06 at 19:52 +0200, Carlos E. R. wrote: > On Sunday, 2018-05-06 at 09:35 -0600, Eduardo Chappa wrote: > >> On Sun, 6 May 2018, Carlos E. R. wrote: >> >>> Then I apply a procmail rule to move from there to the final >>> destination changing the header; the problem is that the posts are >>> now considered "new", and I want them to be considered read or not >>> the same as they were before moving. >>> >>> Is this possible? >> >> When you do this locally, the way that a message is considered new or read >> depends on the format of the folder. >> >> For example, in the case of the Unix format, this depends on the >> content of the "Status" header. For a message to be considered Read, >> its value must be "R". In addition, to be considered not new, its >> value must be "O" (old), so you want >> >> Status: RO >> >> as a header for the saved message. Just add that header, and that will >> do the trick. > > Thanks, I'll try that :-) Well, it did not work out. I changed: :0f * ^X-Mailinglist: opensuse | $FORMAIL -bfi 'Reply-To: "OS-en" ' :0 aw: $HOME/Mail/.D-locks/_Lists/os-en.lock | $DELIVER -m _Lists/os-en to: :0f * ^X-Mailinglist: opensuse | $FORMAIL -bfi 'Reply-To: "OS-en" ' -bfi 'Status: RO' :0 aw: $HOME/Mail/.D-locks/_Lists/os-en.lock | $DELIVER -m _Lists/os-en The rule is applied, because I see this in the mbox file: X-TnetIn-From: opensuse-offtopic+bounces-49234-robin.listas=telefonica.net@opensuse.org X-Spam-Status: No Old-Status: RO Reply-To: "oS (off topic)" X-UID: 23254 Status: X-Keywords: Content-Length: 76498 The "Old-Status:" header means that the command was applied. But the new one is empty, probably the deliver command (/usr/lib/dovecot/dovecot-lda) deletes it. Anyway, I have a working manual method, which is setting read status on the last messages on the folder. Of course, I would prefer all the flags to be kept, but that can not be. - -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlrxg4gACgkQtTMYHG2NR9VokQCfRJb1dAOquALjzp6ZdbYHPdf0 w24AnjqfiSEHnycE7+R6p3btyHFfgkJN =EmZP -----END PGP SIGNATURE----- From alpine.chappa at gmx.com Tue May 8 08:08:02 2018 From: alpine.chappa at gmx.com (Eduardo Chappa) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Question about moving mail with procmail and Alpine In-Reply-To: References: Message-ID: On Tue, 8 May 2018, Carlos E. R. wrote: > Anyway, I have a working manual method, which is setting read status on > the last messages on the folder. Of course, I would prefer all the flags > to be kept, but that can not be. I am sorry to read that the delivery agent is preventing you from doing this. By the way, other flags (Answered, important) appear in the X-Status header. If you can determine the value of that header, you can try to copy it too. -- Eduardo http://repo.or.cz/alpine.git (Git) RSS: http://repo.or.cz/alpine.git/rss (Git updates) From alpine.chappa at gmx.com Tue May 8 08:28:49 2018 From: alpine.chappa at gmx.com (Eduardo Chappa) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Directory for saving configuration files Message-ID: Dear All, I am seeking feedback. When adding features to Alpine, I sometimes think that the only way to add a feature is by adding a special file. For example, in order to save appointments in a calendar, I need a special place to save those appointments. In order to do that, I would probably need to add some type of alpine-ical file or maybe a directory, in case I need to add more things. The point here is that Alpine already has lots of files (created by Alpine) lying around the user directory. Here are a few: .pinerc, .pine-debug[1-4], .pine-crash, .pine-interrupted-mail, .alpine-smime, .addressbook, .addressbook.lu, etc. There are many files already, and I really do not want to add more, when I could put all of them in the same directory. What I am proposing is to add a .alpine directory, and copy (not move) all the files that are outside this directory to the new .alpine directory. Having all files in the same directory will make it easy to add new features to Alpine, as I will have a place to put all files I need to keep. In the new system, the old .pinerc file would be copied to .alpine/pinerc, .alpine-smime would be copied to .alpine/alpine-smime, etc. There would also be a command line option to specify the name of the directory the user wants to use, in case .alpine is not good, and this name would be configurable at compilation time, with the possibility of adding a --without-local-config-dir option to the configure script to completely disable this, but the default would be to enable this new behavior. I can create a branch in git if people are interested in testing this. I am making my own modifications to a local copy of Alpine here, but I am willing to share this, for those that are interested. Thank you for your feedback. -- Eduardo http://repo.or.cz/alpine.git (Git) RSS: http://repo.or.cz/alpine.git/rss (Git updates) From bret.busby at gmail.com Tue May 8 08:53:53 2018 From: bret.busby at gmail.com (Bret Busby) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Directory for saving configuration files In-Reply-To: References: Message-ID: On 08/05/2018, Eduardo Chappa wrote: > Dear All, > > I am seeking feedback. > > When adding features to Alpine, I sometimes think that the only way to > add a feature is by adding a special file. For example, in order to save > appointments in a calendar, I need a special place to save those > appointments. In order to do that, I would probably need to add some type > of alpine-ical file or maybe a directory, in case I need to add more > things. > > The point here is that Alpine already has lots of files (created by > Alpine) lying around the user directory. Here are a few: > > .pinerc, .pine-debug[1-4], .pine-crash, .pine-interrupted-mail, > .alpine-smime, .addressbook, .addressbook.lu, etc. > > There are many files already, and I really do not want to add more, when I > could put all of them in the same directory. > > What I am proposing is to add a .alpine directory, and copy (not move) all > the files that are outside this directory to the new .alpine directory. > Having all files in the same directory will make it easy to add new > features to Alpine, as I will have a place to put all files I need to > keep. > > In the new system, the old .pinerc file would be copied to .alpine/pinerc, > .alpine-smime would be copied to .alpine/alpine-smime, etc. There would > also be a command line option to specify the name of the directory the > user wants to use, in case .alpine is not good, and this name would be > configurable at compilation time, with the possibility of adding a > --without-local-config-dir option to the configure script to completely > disable this, but the default would be to enable this new behavior. > > I can create a branch in git if people are interested in testing this. I > am making my own modifications to a local copy of Alpine here, but I am > willing to share this, for those that are interested. > > Thank you for your feedback. > > -- > Eduardo Hello. This sounds like a good idea, to me, and, follows what other applications have done. In linux, for example, in the /home/ directory, is the .mozilla file hierarchy, which includes a file hierarchy for firefox, which makes it easy to find particular files (and, in the case of firefox, delinquent files, so they can be easily found, and, disciplined/deleted, as required). The suggestion to store the associated files, within a particular dedicated directory, such as .alpine, has, I believe, many advantages, including, as a single example, where a user wants to move the use of the application from one computer to another, it would, I believe, be simpler to copy the mail and the .alpine directory (hierarchy, if it becomes applicable), from one computer to the other, rather than hoping to have captured all required files floating around loose in the (in the case of linux and unixes and unix-lke operating systems) home directory. I think it would also make performing routine backups of data (which, we should all be doing, but, perhaps, do not do, as much as we should), easier, especially where we want to backup particular application data, for example, the data for the alpine application. That way, when things such as the addition of filters, requires ongoing work, the work is not lost, if backup procedures are properly maintained. I was not previously aware that alpine had other files (than .pinerc), that it uses in its application, and, I think that putting all of those files for the application, in a single directory, is a very good idea, and, so, I say, please do it. -- Bret Busby Armadale West Australia .............. "So once you do know what the question actually is, you'll know what the answer means." - Deep Thought, Chapter 28 of Book 1 of "The Hitchhiker's Guide to the Galaxy: A Trilogy In Four Parts", written by Douglas Adams, published by Pan Books, 1992 .................................................... From robin.listas at telefonica.net Tue May 8 09:33:54 2018 From: robin.listas at telefonica.net (Carlos E. R.) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Directory for saving configuration files In-Reply-To: References: Message-ID: On 2018-05-08 17:28, Eduardo Chappa wrote: > What I am proposing is to add a .alpine directory, and copy (not move) > all the files that are outside this directory to the new .alpine > directory. Having all files in the same directory will make it easy to > add new features to Alpine, as I will have a place to put all files I > need to keep. Fine with me :-) However, I think "move" would be better. Perhaps link. But having two copies that may be different would arise the confusion of which is the master one. I would add other files, like .signature* files perhaps. Also, if the directory is used the files should not be dot-files, but dropping the dot would be more adequate, IMO. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 188 bytes Desc: OpenPGP digital signature URL: From bret.busby at gmail.com Tue May 8 09:54:48 2018 From: bret.busby at gmail.com (Bret Busby) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Directory for saving configuration files In-Reply-To: References: Message-ID: On 09/05/2018, Carlos E. R. wrote: > On 2018-05-08 17:28, Eduardo Chappa wrote: > >> What I am proposing is to add a .alpine directory, and copy (not move) >> all the files that are outside this directory to the new .alpine >> directory. Having all files in the same directory will make it easy to >> add new features to Alpine, as I will have a place to put all files I >> need to keep. > > Fine with me :-) > > However, I think "move" would be better. Perhaps link. But having two > copies that may be different would arise the confusion of which is the > master one. > A problem that I have found, with movng, rather than copying, files and directories, etc, is that things can go awry, and, data become vaporised. > I would add other files, like .signature* files perhaps. > With that, I disagree, also. I have a single signature file, which I call from various email applications, and, in using the same, single file, ensures consistency. > Also, if the directory is used the files should not be dot-files, but > dropping the dot would be more adequate, IMO. > Once again, in terms of consistency, in Linux, in the home directory (or, in other operating systems, in the user directory), are various applications' configuration files' directories. Keeping all of these, as "dot files", means that they are kept hidden, unless specifically wanted to be revealed, so that, in viewing the home directory contents, the user does not need to navigate through configuration directories/files, when seeking more commonly accessed data files/directories. > -- > Cheers / Saludos, > > Carlos E. R. > (from 42.3 x86_64 "Malachite" at Telcontar) > > -- Bret Busby Armadale West Australia .............. "So once you do know what the question actually is, you'll know what the answer means." - Deep Thought, Chapter 28 of Book 1 of "The Hitchhiker's Guide to the Galaxy: A Trilogy In Four Parts", written by Douglas Adams, published by Pan Books, 1992 .................................................... From robin.listas at telefonica.net Tue May 8 17:37:50 2018 From: robin.listas at telefonica.net (Carlos E. R.) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Directory for saving configuration files In-Reply-To: References: Message-ID: On 2018-05-08 18:54, Bret Busby wrote: > On 09/05/2018, Carlos E. R. wrote: >> On 2018-05-08 17:28, Eduardo Chappa wrote: >> >>> What I am proposing is to add a .alpine directory, and copy (not move) >>> all the files that are outside this directory to the new .alpine >>> directory. Having all files in the same directory will make it easy to >>> add new features to Alpine, as I will have a place to put all files I >>> need to keep. >> >> Fine with me :-) >> >> However, I think "move" would be better. Perhaps link. But having two >> copies that may be different would arise the confusion of which is the >> master one. >> > > A problem that I have found, with movng, rather than copying, files > and directories, etc, is that things can go awry, and, data become > vaporised. Ah. Then automatically add a comment at the start of the file to say that this file is ignored and where is the right one. But that means a migration phase :-? >> I would add other files, like .signature* files perhaps. >> > > With that, I disagree, also. I have a single signature file, which I > call from various email applications, and, in using the same, single > file, ensures consistency. Ok. I said perhaps, I had my doubts ;-) >> Also, if the directory is used the files should not be dot-files, but >> dropping the dot would be more adequate, IMO. >> > > Once again, in terms of consistency, in Linux, in the home directory > (or, in other operating systems, in the user directory), are various > applications' configuration files' directories. > > Keeping all of these, as "dot files", means that they are kept hidden, > unless specifically wanted to be revealed, so that, in viewing the > home directory contents, the user does not need to navigate through > configuration directories/files, when seeking more commonly accessed > data files/directories. The directory itself is hidden, but the contents of the directory needs not. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" (Minas Tirith)) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 220 bytes Desc: OpenPGP digital signature URL: From polluks at SDF.ORG Thu May 17 07:28:33 2018 From: polluks at SDF.ORG (Stefan A. Haubenthal) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] EFAIL safe? Message-ID: Hi! Did anyone try to attack Alpine? I suppose it's safe like Mutt https://en.wikipedia.org/wiki/EFAIL -- Programmers are lousy lovers. They always try to get the job done (*(* )"/ faster than before. And when they do, they brag that they have \ ( better performance. Programmers are the only men who boast how /' \ small theirs is. // WIL BADEN / y / Stefan Haubenthal \X/ http://stefan-haubenthal.de ICQ #91841784 From alpine.chappa at gmx.com Thu May 17 09:19:15 2018 From: alpine.chappa at gmx.com (Eduardo Chappa) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] EFAIL safe? In-Reply-To: References: Message-ID: On Thu, 17 May 2018, Stefan A. Haubenthal wrote: > Did anyone try to attack Alpine? > I suppose it's safe like Mutt > https://en.wikipedia.org/wiki/EFAIL Dear Stefan, I was informed about the Efail attack last week, and was pointed towards the paper describing the attack, which you can find here: https://efail.de/efail-attack-paper.pdf Alpine only implements S/MIME, so you can ignore the section on OpenPGP in the paper. The attack that envelops the encrypted text around an References: Message-ID: On Thu, May 17, 2018 at 12:19 PM, Eduardo Chappa wrote: > On Thu, 17 May 2018, Stefan A. Haubenthal wrote: > > Did anyone try to attack Alpine? >> I suppose it's safe like Mutt >> https://en.wikipedia.org/wiki/EFAIL >> > > > In any case, reading messages with Alpine will not make you suceptible to > this attack, as long as you let Alpine and no other program handle your > email. The edge case that is slightly susceptible to the attack is that encrypted-then-signed emails from other users could arrive attacked in a couple ways (both based on exploiting a CBC encoding gadget, injecting encrypted text into the message): 1. they can show up with the signature stripped. If you get an encrypted message without a signature, you can no longer trust the contents to be what the user sent. The contents will not be exfiltrated to the attacker by alpine, but you could be "tricked" into clicking a malicious link that does so. Don't trust them any more than you would plain text, except that you can rest assured that no one else saw the content the original person wrote. 2. they can show up with the signature replaced by the attacker with a valid signature of his own. I *think* alpine might barf on these, but other clients can handle this sort of setup. If alpine accepts it, this could be quite deceiving, but would appear to come from the attacker's email, not the original recipient. Trust it as much as you would anything from some random person you don't know. 3. they can show up with a broken signature. In this case, you shouldn't trust the encrypted contents, as the broken signature shows they have been tampered with. Again, nothing will be exfiltrated unless you click on a malicious link or purposefully load up any of the external resources. #2 should be fairly easy to test, but I haven't tried it. To test (for any one interested): * create a signed email, signed by one S/MIME key (let's call it KEY_A) * send that to another email account to get that key loaded in that client. * create a message body * encrypt it with openssl using KEY_A * sign that using a different S/MIME key (let's call it KEY_B) * send that to that same account used as a destination for the second bullet point with a from address matching KEY_B * see what happens on the recipient account I don't believe that condition was considered one that should generate a warning or error in the past, though alpine may not have implemented support for it at all. If it does work, that's one area that could (or should) be updated to generate a warning. There is sort-of a legit reason for case #2, but it's a stretch. Let's say: * person A sends encrypted email to person B and person C * person B accidentally deletes it * person B asks person C to send them a copy of it * person C send it to person B, and (by default) signs the message * person B then has a message signed by C, containing a message encrypted by A, which was encrypted for both B and C so they should still be able to open it. In that case, person C could actually be an attacker, though I don't know what they'd hope to gain from the attack, since they can already read the message. Maybe they just want to put words into someone else's mouth (injecting some text into their encrypted message). Even if person A had signed that encrypted message, person C could strip that signature, then resend it with their own signature. Really though, the signature is the thing that denotes the responsible party, so it's more of a social issue of trust.... but it's still pretty sketchy. The only real fix for that is to change the protocol to use something other than CBC encryption mode (fwiw, Eduardo's idea could help to mitigate the issue, but I don't think it fully closes the hole). FYI, in case anyone wasn't already aware, in the case of both S/MIME and PGP/GPG emails (signed and/or encrypted), they only work on the message body. The email message body DOES _NOT_ include the "Subject" line. Furthermore, it only applies to one mime part of the message, so the message could contain a bunch of other parts that are unsigned or signed by someone else etc. This fact has surprised some very smart people over the years, because it's not very obvious, and none of the email software out there mentions it when you click "encrypt". For example, you can take a signed message from your coworker, change the subject to some thing awful, and manually resend it as them (just forge the From when sending via SMTP, which is particularly easy if you are in the same organization), and send it to anyone you like (ex. their boss). The recipient will see that awful subject, from your coworker, with a valid message signature on the message body. Who cares what's in the message... they might not even read past the subject! Anyway... I'm only mentioning that because the injection of content via additional mime parts isn't news. S/MIME helps, but the standard leaves a lot to be desired. FWIW, I'm not an encryption professional; I've just read way too much about this stuff over the years. HTH, -- Josh I. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alpine.chappa at gmx.com Thu May 17 17:13:44 2018 From: alpine.chappa at gmx.com (Eduardo Chappa) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] EFAIL safe? In-Reply-To: References: Message-ID: On Thu, 17 May 2018, Joshua Miller wrote: > #2 should be fairly easy to test, but I haven't tried it. To test (for any > one interested): > * create a signed email, signed by one S/MIME key (let's call it KEY_A) > * send that to another email account to get that key loaded in that client. > * create a message body > * encrypt it with openssl using KEY_A > * sign that using a different S/MIME key (let's call it KEY_B) Can you expand on that point? You cannot sign plain text. The encrypted message will remain "as is" because the signature will not be part of that block, so for practical purposes, the signing of this block will not be part of the block. > * send that to that same account used as a destination for the second > bullet point with a from address matching KEY_B > * see what happens on the recipient account If you can get a program to do this, let me know. > [...] The only real fix for that is to change the protocol to use > something other than CBC encryption mode (fwiw, Eduardo's idea could > help to mitigate the issue, but I don't think it fully closes the hole). > > [...] > FWIW, I'm not an encryption professional; I've just read way too much about > this stuff over the years. I'd love to read the opinion of a professional, so if anyone knows one, please ask and let me know. Thank you. -- Eduardo From alpine.chappa at gmx.com Sat May 19 18:03:31 2018 From: alpine.chappa at gmx.com (Eduardo Chappa) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] New web site Message-ID: Dear Alpine Enthusiasts, I have created a new free website for both patches and source of Alpine. The new site is http://alpine.x10host.com The patches for Alpine will be located at http://alpine.x10host.com/alpine/ and the official releases of Alpine will always be found at http://alpine.x10host.com/alpine/release The idea of the change in structure in the site is that all old links to alpine.freeiz.com will work again when the domain is changed to alpine.x10host.com. If you run into any trouble with the new site, please let me know. Thank you. -- Eduardo http://repo.or.cz/alpine.git (Git) RSS: http://repo.or.cz/alpine.git/rss (Git updates) From danm at prime.gushi.org Mon May 21 11:17:48 2018 From: danm at prime.gushi.org (Dan Mahoney (Gushi)) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Preheader display? Message-ID: All, There's a "thing" that new mailers are doing, where there's a "preheader" for an HTML message that can be shown in the index view. Indeed, I'm trying to experiment with these as well, since for things like Nagios alerts, more info is useful to help you decide if messages are "signal" or "noise". Implementing this in Alpine would basically mean making alpine message indices multi-line, and also would require alpine to parse the HTML messages at index display time (whereas right now, it just gets the subject from the imap server). Does this seem like something worth doing? If so, how complex would it be? -Dan -- --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC FB: fb.com/DanielMahoneyIV LI: linkedin.com/in/gushi Site: http://www.gushi.org --------------------------- From andrew at aitchison.me.uk Mon May 21 12:09:55 2018 From: andrew at aitchison.me.uk (Andrew C Aitchison) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Preheader display? In-Reply-To: References: Message-ID: On Mon, 21 May 2018, Dan Mahoney (Gushi) wrote: > All, > > There's a "thing" that new mailers are doing, where there's a "preheader" for > an HTML message that can be shown in the index view. > > Indeed, I'm trying to experiment with these as well, since for things like > Nagios alerts, more info is useful to help you decide if messages are > "signal" or "noise". > > Implementing this in Alpine would basically mean making alpine message > indices multi-line, and also would require alpine to parse the HTML messages > at index display time (whereas right now, it just gets the subject from the > imap server). > > Does this seem like something worth doing? Parsing html from every message in the (current page of the) index makes me nervous. Parsing one *selected* HTML message is fair enough, but please don't parse HTML from unopened emails. -- Andrew C. Aitchison Cambridge, UK andrew@aitchison.me.uk From mattack at apple.com Mon May 21 12:21:23 2018 From: mattack at apple.com (Matt Ackeret) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] New web site In-Reply-To: References: Message-ID: On Sat, 19 May 2018, Eduardo Chappa wrote: > and the official releases of Alpine will always be found at > > http://alpine.x10host.com/alpine/release > > The idea of the change in structure in the site is that all old links to > alpine.freeiz.com will work again when the domain is changed to > alpine.x10host.com. > > If you run into any trouble with the new site, please let me know. Not really trouble, but I'd suggest adding a 'release' link to the sidebar, along with the existing patches link. Also, since I think wikipedia won't let you add your own link, I'll try to add it (unless someone else gets to it first). Just so one can find a reasonably sane path to it. I see that the uwashington.edu page now links to wikipedia, which doesn't link to your (new) page, but does have the git URL in the footnotes. From danm at prime.gushi.org Mon May 21 12:22:38 2018 From: danm at prime.gushi.org (Dan Mahoney) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Preheader display? In-Reply-To: References: Message-ID: Or, yanno, give the user a choice and make it off-by-default. Sent from my iPhone > On May 21, 2018, at 12:09, Andrew C Aitchison wrote: > >> On Mon, 21 May 2018, Dan Mahoney (Gushi) wrote: >> >> All, >> >> There's a "thing" that new mailers are doing, where there's a "preheader" for an HTML message that can be shown in the index view. >> >> Indeed, I'm trying to experiment with these as well, since for things like Nagios alerts, more info is useful to help you decide if messages are "signal" or "noise". >> >> Implementing this in Alpine would basically mean making alpine message indices multi-line, and also would require alpine to parse the HTML messages at index display time (whereas right now, it just gets the subject from the imap server). >> >> Does this seem like something worth doing? > > Parsing html from every message in the (current page of the) index makes me nervous. > Parsing one *selected* HTML message is fair enough, but please don't parse HTML > from unopened emails. > > -- > Andrew C. Aitchison Cambridge, UK > andrew@aitchison.me.uk > _______________________________________________ > Alpine-info mailing list > Alpine-info@u.washington.edu > http://mailman13.u.washington.edu/mailman/listinfo/alpine-info From alpine.chappa at gmx.com Mon May 21 12:22:26 2018 From: alpine.chappa at gmx.com (Eduardo Chappa) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Preheader display? In-Reply-To: References: Message-ID: On Mon, 21 May 2018, Dan Mahoney (Gushi) wrote: > There's a "thing" that new mailers are doing, where there's a > "preheader" for an HTML message that can be shown in the index view. Dear Dan, if I understand you correctly, what you are asking is covered by the index tokens OPENINGTEXT and OPENINGTEXTNQ. I used to use them a lot, and I used it in conjuction with colors and the rules patch to give me and even better focus on the text I wanted to read. What these tokens do for you is to give you a snippet of the text in the mesage. Colors help you separate fields in the index better and the replace rules help you target the text you want to read better. Take a look at an example from 10 years ago at http://alpine.x10host.com/alpine/readme/replacerules.html Is that what you are referring to? -- Eduardo From bret.busby at gmail.com Mon May 21 14:11:05 2018 From: bret.busby at gmail.com (Bret Busby) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Preheader display? In-Reply-To: References: Message-ID: On 22/05/2018, Dan Mahoney (Gushi) wrote: > All, > > There's a "thing" that new mailers are doing, where there's a "preheader" > for an HTML message that can be shown in the index view. > > Indeed, I'm trying to experiment with these as well, since for things like > Nagios alerts, more info is useful to help you decide if messages are > "signal" or "noise". > > Implementing this in Alpine would basically mean making alpine message > indices multi-line, and also would require alpine to parse the HTML > messages at index display time (whereas right now, it just gets the > subject from the imap server). > > Does this seem like something worth doing? > > If so, how complex would it be? > > -Dan > I would rather that a filter field and parameter was set up so that HTML messages could be filtered out of the other messages. HTML messages are apparently an attack medium and I would rather be rid of them, if a means of filtering them, to separate them from plain text messages, would be available. -- Bret Busby Armadale West Australia .............. "So once you do know what the question actually is, you'll know what the answer means." - Deep Thought, Chapter 28 of Book 1 of "The Hitchhiker's Guide to the Galaxy: A Trilogy In Four Parts", written by Douglas Adams, published by Pan Books, 1992 .................................................... From danm at prime.gushi.org Mon May 21 14:33:38 2018 From: danm at prime.gushi.org (Dan Mahoney) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] New web site In-Reply-To: References: Message-ID: <40AAD6AB-75DC-4E0A-927A-F06AB861B3FF@prime.gushi.org> Eduardo, Just for the hell of it, has anyone offered to donate an actual domain name to the project? I?d be happy to buy the project something like alpine-mailer.org or something like that for the next ten years and transfer it into your name, so that the site URL isn?t dependent on whomever you happen to have hosting it at the time. This is a solvable problem. Sent from my iPad > On May 21, 2018, at 12:21, Matt Ackeret wrote: > >> On Sat, 19 May 2018, Eduardo Chappa wrote: >> and the official releases of Alpine will always be found at >> >> http://alpine.x10host.com/alpine/release >> >> The idea of the change in structure in the site is that all old links to >> alpine.freeiz.com will work again when the domain is changed to >> alpine.x10host.com. >> >> If you run into any trouble with the new site, please let me know. > > Not really trouble, but I'd suggest adding a 'release' link to the sidebar, > along with the existing patches link. > > Also, since I think wikipedia won't let you add your own link, I'll try to add > it (unless someone else gets to it first). > > Just so one can find a reasonably sane path to it. I see that the > uwashington.edu page now links to wikipedia, which doesn't link to your (new) > page, but does have the git URL in the footnotes. > _______________________________________________ > Alpine-info mailing list > Alpine-info@u.washington.edu > http://mailman13.u.washington.edu/mailman/listinfo/alpine-info From alpine.chappa at gmx.com Mon May 21 15:20:07 2018 From: alpine.chappa at gmx.com (Eduardo Chappa) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] New web site In-Reply-To: <40AAD6AB-75DC-4E0A-927A-F06AB861B3FF@prime.gushi.org> References: <40AAD6AB-75DC-4E0A-927A-F06AB861B3FF@prime.gushi.org> Message-ID: On Mon, 21 May 2018, Dan Mahoney wrote: > Just for the hell of it, has anyone offered to donate an actual domain > name to the project? I?d be happy to buy the project something like > alpine-mailer.org or something like that for the next ten years and > transfer it into your name, so that the site URL isn?t dependent on > whomever you happen to have hosting it at the time. > > This is a solvable problem. Dear Dan, thank you for the message. I know you are right about the long term decision. Let me try the new hosting site for some time before I make a different decision. So far I have had a good experience, and hope it will continue that way. If it does not, then it will be time to make a more permanent decision. Thank you! -- Eduardo From dennisdavis at fastmail.fm Mon May 21 23:44:50 2018 From: dennisdavis at fastmail.fm (Dennis Davis) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Preheader display? In-Reply-To: References: Message-ID: On Tue, 22 May 2018, Bret Busby wrote: > From: Bret Busby > To: alpine-info@u.washington.edu > Date: Mon, 21 May 2018 22:11:05 > Subject: Re: [Alpine-info] Preheader display? ... > HTML messages are apparently an attack medium and I would rather > be rid of them, if a means of filtering them, to separate them > from plain text messages, would be available. You may be referring to the recent concern over HTML messages. If so see Eduardo's recent message: http://mailman13.u.washington.edu/pipermail/alpine-info/2018-May/007979.html Look like alpine isn't vulnerable to such chicanery. -- Dennis Davis From alpine-info-l at usr-local.org Wed May 23 06:24:39 2018 From: alpine-info-l at usr-local.org (Peter) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] New web site In-Reply-To: References: <40AAD6AB-75DC-4E0A-927A-F06AB861B3FF@prime.gushi.org> Message-ID: Hello Eduardo, hello Dan, I guess it is not only about the domain, but also about hosting (I assume, x10host.com offers free hosting only to subdomains of x10host.com) @Eduarso: Thank you for setting up the new site. I was already missing it. If it makes sense to you, I would be happy to offer any DNS configuration you prefer for "alpine.usr-local.org". (Including the offer of a redirect to the current "real" hosting site) Cheers, Peter Am 22.05.18 um 00:20 schrieb Eduardo Chappa: > On Mon, 21 May 2018, Dan Mahoney wrote: > >> Just for the hell of it, has anyone offered to donate an actual domain >> name to the project?? I?d be happy to buy the project something like >> alpine-mailer.org or something like that for the next ten years and >> transfer it into your name, so that the site URL isn?t dependent on >> whomever you happen to have hosting it at the time. >> >> This is a solvable problem. > > Dear Dan, > > ? thank you for the message. I know you are right about the long term > decision. Let me try the new hosting site for some time before I make a > different decision. So far I have had a good experience, and hope it > will continue that way. If it does not, then it will be time to make a > more permanent decision. > > ? Thank you! > From cca at apf.it Wed May 23 08:23:02 2018 From: cca at apf.it (Paolo) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] maildir ... Message-ID: I use pine/alpine from so many years (since 1994-95), that I consider it a basic tool for mail management. I read the notes about the maildir patch, but I couln't find a solution to my problem/need. I usually like to open a generic folder (mbox format), using a simple "pine -f folder-path-name". This is a very confortable way to manage my 20+ years offline archives or the archives of some users that need something particular to do (like delete or find some mail or ...). Is there a way to do something similar with alpine if the mails are stored in maildir format as single files into a folder? I can use system tools like grep & c. but I like my old habits ... ;-) Thanks, Paolo From danm at prime.gushi.org Wed May 23 09:21:31 2018 From: danm at prime.gushi.org (Dan Mahoney (Gushi)) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] New web site In-Reply-To: References: <40AAD6AB-75DC-4E0A-927A-F06AB861B3FF@prime.gushi.org> Message-ID: On Wed, 23 May 2018, Peter wrote: > Hello Eduardo, hello Dan, > > I guess it is not only about the domain, but also about hosting (I assume, > x10host.com offers free hosting only to subdomains of x10host.com) If you like/need, I'll donate hosting as well. I've had a server where I run sites for the past *counts on fingers* 18 years. It's not going away anytime soon. -Dan > > @Eduarso: > > Thank you for setting up the new site. I was already missing it. > > If it makes sense to you, I would be happy to offer any DNS configuration you > prefer for "alpine.usr-local.org". (Including the offer of a redirect to the > current "real" hosting site) > > Cheers, > > Peter > > Am 22.05.18 um 00:20 schrieb Eduardo Chappa: >> On Mon, 21 May 2018, Dan Mahoney wrote: >> >>> Just for the hell of it, has anyone offered to donate an actual domain >>> name to the project?? I?d be happy to buy the project something like >>> alpine-mailer.org or something like that for the next ten years and >>> transfer it into your name, so that the site URL isn?t dependent on >>> whomever you happen to have hosting it at the time. >>> >>> This is a solvable problem. >> >> Dear Dan, >> >> ? thank you for the message. I know you are right about the long term >> decision. Let me try the new hosting site for some time before I make a >> different decision. So far I have had a good experience, and hope it will >> continue that way. If it does not, then it will be time to make a more >> permanent decision. >> >> ? Thank you! >> > > _______________________________________________ > Alpine-info mailing list > Alpine-info@u.washington.edu > http://mailman13.u.washington.edu/mailman/listinfo/alpine-info > -- "Long live little fat girls!" -Recent Taco Bell Ad Slogan, Literally Translated. (Viva Gorditas) --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC FB: fb.com/DanielMahoneyIV LI: linkedin.com/in/gushi Site: http://www.gushi.org --------------------------- From beartooth at comcast.net Wed May 23 09:45:14 2018 From: beartooth at comcast.net (Beartooth) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Directory for saving configuration files In-Reply-To: References: Message-ID: On 05/08/2018 12:54 PM, Bret Busby wrote: [.....] >> I would add other files, like .signature* files perhaps. >> > > With that, I disagree, also. I have a single signature file, which I > call from various email applications, and, in using the same, single > file, ensures consistency. +1 With several dozen signatures, which I change sometimes for reasons and sometimes on whims, I also find it more convenient to keep them all in a single file. When (increasingly with age) I disremember what I called one, it's easy to do ls sig and call up likely ones. -- Beartooth Staffwright, Not Quite Clueless Power User Remember I know little (precious little!) of where up is. From mattack at apple.com Wed May 23 12:14:49 2018 From: mattack at apple.com (Matt Ackeret) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Directory for saving configuration files In-Reply-To: References: Message-ID: <6854AA8D-BC3C-4474-98C4-4862645D35D0@apple.com> > On May 8, 2018, at 9:54 AM, Bret Busby wrote: > > On 09/05/2018, Carlos E. R. wrote: >> On 2018-05-08 17:28, Eduardo Chappa wrote: >> >>> What I am proposing is to add a .alpine directory, and copy (not move) >>> all the files that are outside this directory to the new .alpine >>> directory. Having all files in the same directory will make it easy to >>> add new features to Alpine, as I will have a place to put all files I >>> need to keep. >> >> Fine with me :-) >> >> However, I think "move" would be better. Perhaps link. But having two >> copies that may be different would arise the confusion of which is the >> master one. >> > > A problem that I have found, with movng, rather than copying, files > and directories, etc, is that things can go awry, and, data become > vaporised. (Snarky response) Then someone didn?t add enough safety checks (including to problems they didn?t imagine).. Copy, then if successful, delete the original.. I?d prefer moving too.. From fhdata at unm.edu Wed May 23 12:17:37 2018 From: fhdata at unm.edu (FHDATA) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] PC-PINE Message-ID: hello, is PC-PINE still being maintained? if so, where can one get the binaries? thanks, F- From robin.listas at telefonica.net Wed May 23 14:06:34 2018 From: robin.listas at telefonica.net (Carlos E. R.) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Directory for saving configuration files In-Reply-To: References: Message-ID: <28ec06d8-f0b6-aa36-35d9-461049d70b81@telefonica.net> On 2018-05-23 18:45, Beartooth wrote: > On 05/08/2018 12:54 PM, Bret Busby wrote: > ????[.....] >>> I would add other files, like .signature* files perhaps. >>> >> >> With that, I disagree, also. I have a single signature file, which I >> call from various email applications, and, in using the same, single >> file, ensures consistency. Yes, agreed. > > ????+1 > > ????With several dozen signatures, which I change sometimes for reasons > and sometimes on whims, I also find it more convenient to keep them all > in a single file. When (increasingly with age) I disremember what I > called one, it's easy to do ls sig and call up likely ones. Several signatures in a single file? How does Alpine or Thunderbird choose which signature to use each time? -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 188 bytes Desc: OpenPGP digital signature URL: From bret.busby at gmail.com Wed May 23 15:22:07 2018 From: bret.busby at gmail.com (Bret Busby) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Directory for saving configuration files In-Reply-To: <6854AA8D-BC3C-4474-98C4-4862645D35D0@apple.com> References: <6854AA8D-BC3C-4474-98C4-4862645D35D0@apple.com> Message-ID: On 24/05/2018, Matt Ackeret wrote: > > >> On May 8, 2018, at 9:54 AM, Bret Busby wrote: >> >> On 09/05/2018, Carlos E. R. wrote: >>> On 2018-05-08 17:28, Eduardo Chappa wrote: >>> >>>> What I am proposing is to add a .alpine directory, and copy (not move) >>>> all the files that are outside this directory to the new .alpine >>>> directory. Having all files in the same directory will make it easy to >>>> add new features to Alpine, as I will have a place to put all files I >>>> need to keep. >>> >>> Fine with me :-) >>> >>> However, I think "move" would be better. Perhaps link. But having two >>> copies that may be different would arise the confusion of which is the >>> master one. >>> >> >> A problem that I have found, with movng, rather than copying, files >> and directories, etc, is that things can go awry, and, data become >> vaporised. > > (Snarky response) Then someone didn?t add enough safety checks (including to > problems they didn?t imagine).. Blows loud raspberry... > Copy, then if successful, delete the original.. > We live and we learn (hopefully, and, hopefully, we remember, each subsequent time... > I?d prefer moving too.. I have a response, but, I will keep it to myself... :) -- Bret Busby Armadale West Australia .............. "So once you do know what the question actually is, you'll know what the answer means." - Deep Thought, Chapter 28 of Book 1 of "The Hitchhiker's Guide to the Galaxy: A Trilogy In Four Parts", written by Douglas Adams, published by Pan Books, 1992 .................................................... From alpine-info-l at usr-local.org Thu May 24 06:56:34 2018 From: alpine-info-l at usr-local.org (Peter) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] New web site In-Reply-To: References: Message-ID: <47428fb6-4c8b-f8fe-bd7c-80b89bcfdd72@pooh.in-berlin.de> Am 21.05.18 um 21:21 schrieb Matt Ackeret: > Also, since I think wikipedia won't let you add your own link, I'll try to add > it (unless someone else gets to it first). Done :-) Cheers, Peter -- (Al)pine user since 1993 From alpine-info-l at usr-local.org Thu May 24 06:56:43 2018 From: alpine-info-l at usr-local.org (Peter) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Directory for saving configuration files In-Reply-To: References: Message-ID: Am 08.05.18 um 18:54 schrieb Bret Busby: > On 09/05/2018, Carlos E. R. wrote: >> On 2018-05-08 17:28, Eduardo Chappa wrote: >> >>> What I am proposing is to add a .alpine directory, and copy (not move) Good choice in my opinion. > [...] >> However, I think "move" would be better. Perhaps link. But having two >> copies that may be different would arise the confusion of which is the >> master one. >> > > A problem that I have found, with movng, rather than copying, files > and directories, etc, is that things can go awry, and, data become > vaporised. I am surprised. To my view, "moving" has some kind of transaction safety: Either it's moved or not. While copying interruptions of the process might lead to partially copied content. Furthermore, if copying succeeds, you have two copies of the file lying around. Assume home directories shared among more then one UNIX system, some have new versions of Alpine (using ~/.alpine/pinerc) some old ones still using ~/.pinerc without the user noticing it. What will happen, if the other systems Alpine is upgraded as well? Copied the contents of ~/.pinerc over ~/.alpine/pinerc? Merged? Ignored? I vote for "move and symlink". >> I would add other files, like .signature* files perhaps. >> > > With that, I disagree, also. I have a single signature file, which I Yes, as .signature is not Alpine specific - don't touch it. > [...] >> Also, if the directory is used the files should not be dot-files, but >> dropping the dot would be more adequate, IMO. >> > > Once again, in terms of consistency, in Linux, in the home directory > (or, in other operating systems, in the user directory), are various > applications' configuration files' directories. I think the idea is to have ~/.alpine/pinerc instead of ~/.alpine/.pinerc, which sounds reasonable and completely consistent to UNIX conventions. Cheers, Peter -- (Al)pine user since 1993 From alpine-info-l at usr-local.org Thu May 24 07:43:12 2018 From: alpine-info-l at usr-local.org (Peter) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] PC-PINE In-Reply-To: References: Message-ID: <170a0b6d-8213-5a4c-2ad5-e44b0c55a3ac@usr-local.org> Am 23.05.18 um 21:17 schrieb FHDATA: > > hello, > > is PC-PINE still being maintained? > > if so, where can one get the binaries? How about http://alpine.x10host.com/alpine/info/windows.html? Cheers, Peter -- (Al)pine user since 1993 From beartooth at comcast.net Thu May 24 10:36:48 2018 From: beartooth at comcast.net (Beartooth) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Directory for saving configuration files In-Reply-To: <28ec06d8-f0b6-aa36-35d9-461049d70b81@telefonica.net> References: <28ec06d8-f0b6-aa36-35d9-461049d70b81@telefonica.net> Message-ID: <8a70be64-5c02-314b-e1ec-20c62e0bba3a@comcast.net> On 05/23/2018 05:06 PM, Carlos E. R. wrote: [....] >> ????With several dozen signatures, which I change sometimes for reasons >> and sometimes on whims, I also find it more convenient to keep them all >> in a single file. When (increasingly with age) I disremember what I >> called one, it's easy to do ls sig and call up likely ones. > > Several signatures in a single file? How does Alpine or Thunderbird > choose which signature to use each time? Simple. Signature File = sig/issue works fine with Alpine. Detail: whenever I create a new one, I do "nano -w sig/min" (where 'min' is my minimal signature); when finished, I hit ^x, change the name from 'min' to 'nqc' or whatever, and hit enter. Alpine asks me, with what may be a trace of asperity, whether I want a different name, and I affirm that I do. As to Tbd, I can't answer. I'm using it only because Pan crashes at launch on Fedora 28. I haven't managed to fix that, but I'm confident some developer will; then I'll go back to Pan. (I do know I could use Alpine as a newsreader, and I've done it; but I prefer the separation.) -- Beartooth Staffwright, Not Quite Clueless Power User Remember I know little (precious little!) of where up is. From unrtst at gmail.com Thu May 24 10:43:15 2018 From: unrtst at gmail.com (Joshua Miller) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Directory for saving configuration files In-Reply-To: References: Message-ID: On Thu, May 24, 2018 at 9:56 AM, Peter wrote: > Am 08.05.18 um 18:54 schrieb Bret Busby: > >> On 09/05/2018, Carlos E. R. wrote: >> >>> On 2018-05-08 17:28, Eduardo Chappa wrote: >>> >>> What I am proposing is to add a .alpine directory, and copy (not move) >>>> >>> Regarding copy versus move, as well as symlink options, I'd like to throw another option into the ring: hard link and remove the original. IE: $ mkdir -p ~/.alpine $ ln ~/.pinerc ~/.alpine/pinerc $ rm ~/.pinerc The (albeit small) advantage over a move is that there is no race condition regarding overwriting the destination. It's very handy for new files that need a specific name, by combining that with an initial tmpfile() call to create the original, though that's kinda unrelated to the topic at hang :-) [...] >> Also, if the directory is used the files should not be dot-files, >> but >> >>> dropping the dot would be more adequate, IMO. >>> >>> >> Once again, in terms of consistency, in Linux, in the home directory >> (or, in other operating systems, in the user directory), are various >> applications' configuration files' directories. >> > > I think the idea is to have ~/.alpine/pinerc instead of ~/.alpine/.pinerc, > which sounds reasonable and completely consistent to UNIX conventions. > That would be a great way to catch up to the 20th century (j/k). However, current trend seems to be moving to subdirectories within "~/.config/". For example: $ ls -1 ~/.config dconf enchant evolution geeqie google-chrome gtk-2.0 gtk-3.0 ibus KeePass keepassx libaccounts-glib libreoffice menus mimeapps.list Mousepad pavucontrol.ini pulse ristretto Thunar Trolltech.conf update-notifier user-dirs.dirs user-dirs.locale xfce4 xfce4-session xubuntu I'm a bit torn/undecided on which is better. It seems like a new standard was created with the hopes of unifying the other various standards, which just added one more standard to the various ways things are "normally" done. There's still loads of dot files right in the home dir, and loads of application specific dot directories, as well as the .config stuff. IMNSHO, all of these change suggestions should be part of the build system, rather than new/changed defaults. Ideally, every file used by alpine should probably have a matching option in the "configure" script, and integration into the build process. Each file should also have a corresponding configuration option within the ".pinerc". Most should also have command line options to override their locations. And most should also support those files within IMAP (as is the case for .pinerc). If all that is done, then package maintainers for various distros and platforms can set defaults that make the most sense on those distros/platforms, and users could make a new and old version of alpine work side-by-side sharing the same configuration by setting appropriate options on the command line and/or in the .pinerc. In short: * make them configurable in the build system, as well as .pinerc and/or command line * decide on what the correct defaults are later (or never) :-) BTW, I'm more-or-less just another user, and it'll really be up to whomever implements things. These are just my 2 cents on it. HTH, -- Josh I. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew at aitchison.me.uk Thu May 24 11:47:04 2018 From: andrew at aitchison.me.uk (Andrew C Aitchison) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Directory for saving configuration files In-Reply-To: References: Message-ID: On Thu, 24 May 2018, Joshua Miller wrote: > On Thu, May 24, 2018 at 9:56 AM, Peter wrote: > >> Am 08.05.18 um 18:54 schrieb Bret Busby: >> >>> On 09/05/2018, Carlos E. R. wrote: >>> >>>> On 2018-05-08 17:28, Eduardo Chappa wrote: >>>> >>>> What I am proposing is to add a .alpine directory, and copy (not move) >>>>> >>>> > Regarding copy versus move, as well as symlink options, I'd like to throw > another option into the ring: hard link and remove the original. IE: > $ mkdir -p ~/.alpine > $ ln ~/.pinerc ~/.alpine/pinerc > $ rm ~/.pinerc When you do that, remember to check that the directories are on the same partition/filesystem - or at least be ready in case the ln fails. > The (albeit small) advantage over a move is that there is no race condition > regarding overwriting the destination. It's very handy for new files that > need a specific name, by combining that with an initial tmpfile() call to > create the original, though that's kinda unrelated to the topic at hang :-) It also preserves permissions, ACLs, security context ... which is good. -- Andrew C. Aitchison Cambridge, UK andrew@aitchison.me.uk From robin.listas at telefonica.net Thu May 24 13:53:15 2018 From: robin.listas at telefonica.net (Carlos E. R.) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Directory for saving configuration files In-Reply-To: <8a70be64-5c02-314b-e1ec-20c62e0bba3a@comcast.net> References: <28ec06d8-f0b6-aa36-35d9-461049d70b81@telefonica.net> <8a70be64-5c02-314b-e1ec-20c62e0bba3a@comcast.net> Message-ID: On 2018-05-24 19:36, Beartooth wrote: > On 05/23/2018 05:06 PM, Carlos E. R. wrote: > ????[....] >>> ?????With several dozen signatures, which I change sometimes for reasons >>> and sometimes on whims, I also find it more convenient to keep them all >>> in a single file. When (increasingly with age) I disremember what I >>> called one, it's easy to do ls sig and call up likely ones. >> >> Several signatures in a single file? How does Alpine or Thunderbird >> choose which signature to use each time? > > ????Simple. > ?Signature File????????????????????? = sig/issue > > works fine with Alpine. And how does the signature file look, then? Mine: cer@Telcontar:~> cat .sign.lists > Cheers / Saludos, > > Carlos E. R. > (from 42.3 x86_64 "Malachite" at Telcontar)cer@Telcontar:~> > cer@Telcontar:~> What is then the syntax to have several signatures? > ????Detail: whenever I create a new one, I do "nano -w sig/min" (where > 'min' is my minimal signature); when finished, I hit ^x, change the name > from 'min' to 'nqc' or whatever, and hit enter. Alpine asks me, with > what may be a trace of asperity, whether I want a different name, and I > affirm that I do. > > ????As to Tbd, I can't answer. I'm using it only because Pan crashes at > launch on Fedora 28. I haven't managed to fix that, but I'm confident > some developer will; then I'll go back to Pan. (I do know I could use > Alpine as a newsreader, and I've done it; but I prefer the separation.) Well, I use the same signature files on every mail program I use. On Thunderbird there is only provision to specify the file, or to write a signature in the dialog editor. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 188 bytes Desc: OpenPGP digital signature URL: From fhdata at unm.edu Thu May 24 14:56:21 2018 From: fhdata at unm.edu (FHDATA) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] PC-PINE In-Reply-To: <170a0b6d-8213-5a4c-2ad5-e44b0c55a3ac@usr-local.org> References: <170a0b6d-8213-5a4c-2ad5-e44b0c55a3ac@usr-local.org> Message-ID: On Thu, 24 May 2018, Peter wrote: > Am 23.05.18 um 21:17 schrieb FHDATA: >> >> hello, >> >> is PC-PINE still being maintained? >> >> if so, where can one get the binaries? > > How about http://alpine.x10host.com/alpine/info/windows.html? > > Cheers, > > Peter > -- > (Al)pine user since 1993 > _______________________________________________ > Alpine-info mailing list > Alpine-info@u.washington.edu > http://mailman13.u.washington.edu/mailman/listinfo/alpine-info > true; sorry about that; it's there ... thanks, F- From lucio at lambrate.inaf.it Fri May 25 01:37:21 2018 From: lucio at lambrate.inaf.it (Lucio Chiappetti) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] signatures Re: Directory for saving configuration files In-Reply-To: <28ec06d8-f0b6-aa36-35d9-461049d70b81@telefonica.net> References: <28ec06d8-f0b6-aa36-35d9-461049d70b81@telefonica.net> Message-ID: > Several signatures in a single file? How does Alpine or Thunderbird > choose which signature to use each time? My personal approach is that I have a file ~/.signature which is softlinked to one of the files in ~/.sig/xxxx.signatur, and that is the default signature (if I want to change it long term I relink to another one). In the case I wish to change (for the message) to another of the 40-or-so signatures, I delete the current one then do ^R .sig ^T and select one of the files in ~/.sig (like I did just now) For the cases of roles I have specialized per-role signatures -- ------------------------------------------------------------------------ Lucio Chiappetti - INAF/IASF - via Bassini 15 - I-20133 Milano (Italy) ------------------------------------------------------------------------ The reasonable man tries to adapt himself to the world The unreasonable man tries to adapt the world to himself Therefore all progress depends on the unreasonable man (G.B.Shaw) ------------------------------------------------------------------------ For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html ------------------------------------------------------------------------ From alpine.chappa at gmx.com Fri May 25 14:26:19 2018 From: alpine.chappa at gmx.com (Eduardo Chappa) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Directory for saving configuration files In-Reply-To: References: Message-ID: On Tue, 8 May 2018, Eduardo Chappa wrote: > Dear All, > > I am seeking feedback. Thank you everyone who has contributed to this conversation. It has helped me understand what your expectations are. This message came out long. Sorry, I did not find a way to make it longer....er... shorter. I wanted to talk a little bit about how Alpine is currently coded in regards to the location of signatures (and other configuration files.) Please keep in mind the following sentence, because it is the basis of everything I am going to say later: The main place where Alpine looks for the signature files is in the directory where the .pinerc file is. Let me give an example: Say your .signature file and the .pinerc file are in the home directory, then starting alpine with the command $ alpine will find your signature. However, if your .pinerc file is in the ~/secret_configuration/ directory, and you start alpine using the command $ alpine -p ~/secret_configuration/.pinerc then Alpine will not find your signature if this is at ~/.signature. This can be tested very easily by anyone, and it will work with any version of Alpine. If we follow the same logic, then moving the .pinerc file to another directory, would make it easy for me as programmer, if I could move the .signature file to that directory, so I do not have to add more code to make this work. e.g.: I do not have the .pinerc file in one place and the .signature file in another. That creates confusion for users, because there is a explicit option Signature File = in the configuration screen. However, its default ".signature" is not specified where it should be. All the help text says about this is "This is the name of a file that will be automatically inserted into outgoing messages." If you are using a current version of Alpine, you can read the full help text here: x-alpine-help:h_config_signature_file. What I want to do is to modify this text to read something like: "This is the name of the file in the XYZ directory where your signature is stored." This affects expectations that you have about the change of creating a specific .alpine directory because I am seeing that many of you expect that the .signature file will stay where it is right now, but the .pinerc file will move. That can be done, but the question is why would we prefer that? There are a number of goals I have with this change, here are some: * Finding the files to configure Alpine should be easy. * All files used to configure Alpine should be in one and only one place only. If we keep the signature file(s) and the .pinerc file in different directories, it defeats the whole point of putting things in one place. This is where I am with this at this time: I have coded Alpine to create a .alpine/ directory and move files to sub-directories of this directory: * config/ contains pinerc and pinercex; * addressbook/ contains the addressbook(s); * debug/ contains pine-debug[1-4], and pine-crash; * remote/ contains information on remote files (addressbook, pinerc, etc); * alpine-smime/ is the equivalent of .alpine-smime; * signature/ where signature(s) are saved. In addition, Alpine currently expects to find the password file and the addressbook using the same rules as it uses to find the signature file. These files are unique to Alpine (not shared with other programs) so the fact that .signature is searched for in the same directory than .pinerc makes me think that Alpine thinks that .signature file is a unique file for Alpine, since otherwise it would always be searched, say, in the home directory. There are many things left to do to make this work, but the most important one is to have people currently using this software, to understand what is happening. What I expect is that some of the mentality of sharing files between applications change a little bit. I think the mentality of Alpine users is that configuration files should be shared among applications. Let me give an example to make my point clearer. Take a look at the .mailcap and the .mime-types files. Firefox does not care about these files. Firefox, uses its own mailcap files. Should Alpine have its own mailcap files? Why not? maybe that is a good idea, and maybe we should create an interface so users can edit them, like they configure other options in Alpine. Moving configuration files to a unique directory gives us the opportunity to create .mailcap and .mime-types files that are specific to Alpine. Alpine currently only searches for .mailcap and .mime-types files in the home directory, so these files do not change their expected location if the .pinerc file changes location. This tells me that Alpine does not think that these files are Alpine specific. Ok, I will stop here. There is a rationale for everything I have done so far, but it would make this message even longer if I explained everything in one message. I am happy to explain everything that is happening from this side, and I expect to be able to explain it through discussion. I am not 100% done, I have a few more things to do. If anyone would like a patch to try what I have done so far, please let me know. I will be happy to share it. By the way, the nice thing about all of this, is that after I make all these changes, I can reset them by using the command "rm -rf ~/.alpine" and all goes back to what it used to be without a configuration directory (which Alpine will create automatically the next time I run this patched version, if it is not there.) That is because, I am only testing at this time, and so I am not running it in production mode, so if anyone would like to test it, please let me know. I will be happy to share this work with anyone, but it is not complete yet... Thank you everyone, please keep the feedback coming! It is very useful! -- Eduardo From ullbeking at andrewnesbit.org Sat May 26 07:52:09 2018 From: ullbeking at andrewnesbit.org (Andrew Luke Nesbit) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Directory for saving configuration files In-Reply-To: References: Message-ID: <6245c840-4984-ae4c-ca96-ac281ba7c0b8@andrewnesbit.org> On 25/05/2018 22:26, Eduardo Chappa wrote: > Thank you everyone who has contributed to this conversation. It has > helped me understand what your expectations are. This message came out > long. Sorry, I did not find a way to make it longer....er... shorter. Eduardo, please do not apologize for caring about such an important feature of Alpine :-) I've been following this thread closely. One of my favorite things about this discussion (and others similar to it) is that it is a perfect example of how a problem that looks simple from a distance is actually complex to solve properly. It is a model distillation of just how difficult it is to write robust software. This is the kind of problem I would discuss if I were a teacher of computer science or software engineering. Kind regards, Andrew -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9 From bret.busby at gmail.com Sat May 26 13:20:18 2018 From: bret.busby at gmail.com (Bret Busby) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Directory for saving configuration files In-Reply-To: References: Message-ID: On 26/05/2018, Eduardo Chappa wrote: > On Tue, 8 May 2018, Eduardo Chappa wrote: > >> Dear All, >> >> I am seeking feedback. > > Thank you everyone who has contributed to this conversation. It has helped > me understand what your expectations are. This message came out long. > Sorry, I did not find a way to make it longer....er... shorter. > > I wanted to talk a little bit about how Alpine is currently coded in > regards to the location of signatures (and other configuration files.) > > Please keep in mind the following sentence, because it is the basis of > everything I am going to say later: The main place where Alpine looks for > the signature files is in the directory where the .pinerc file is. > > Let me give an example: Say your .signature file and the .pinerc file are > in the home directory, then starting alpine with the command > > $ alpine > > will find your signature. > In the context of the message regarding the location of the signature file, are you intending to allow the user to set an alternative path, in the configuraturation (s -> c), so that alpine will default to your path for the file, unless the user sets an alternative path (including filename) eg, /home/.signature.txt ? -- Bret Busby Armadale West Australia .............. "So once you do know what the question actually is, you'll know what the answer means." - Deep Thought, Chapter 28 of Book 1 of "The Hitchhiker's Guide to the Galaxy: A Trilogy In Four Parts", written by Douglas Adams, published by Pan Books, 1992 .................................................... From alpine.chappa at gmx.com Sat May 26 15:03:07 2018 From: alpine.chappa at gmx.com (Eduardo Chappa) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Directory for saving configuration files In-Reply-To: References: Message-ID: On Sun, 27 May 2018, Bret Busby wrote: > In the context of the message regarding the location of the signature > file, are you intending to allow the user to set an alternative path, in > the configuraturation (s -> c), so that alpine will default to your path > for the file, unless the user sets an alternative path (including > filename) eg, /home/.signature.txt ? Dear Bret, If you set your signature to be a full path, Alpine will respect that. I will not change that. The problem happens when you make it a relative path (the default.) I intend relative paths to be in relation to ~/.alpine/signature in the future. Remember that the intention is to copy files, not move them. Does that answer your question? -- Eduardo http://alpine.x10host.com/alpine/release (Web) http://repo.or.cz/alpine.git (Git) RSS: http://repo.or.cz/alpine.git/rss (Git updates) RSS: http://alpine.x10host.com/alpine/alpine.xml (Web updates) From beartooth at comcast.net Sun May 27 09:37:15 2018 From: beartooth at comcast.net (Beartooth) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Directory for saving configuration files In-Reply-To: References: Message-ID: > On Tue, 8 May 2018, Eduardo Chappa wrote: [...] > Please keep in mind the following sentence, because it is the basis of > everything I am going to say later: The main place where Alpine looks > for the signature files is in the directory where the .pinerc file is. > > Let me give an example: Say your .signature file and the .pinerc file > are in the home directory, then starting alpine with the command > > $ alpine > > will find your signature. [....] One very small detail. I for one, and probably others who keep lots of different signatures, often want to change only for the current message. At present, doing so is very easy: Set the cursor, hit ^R, and type sig/. Then delete the default signature that's already there. Done. One of the reasons Alpine is so fast and easy to use is its very short commands, such as ^R. If I have to type the whole word 'signature' (let alone '.signature'!), it's going to slow me down -- and worse, cause me to make a lot more typos. Calling that file by its full name will make things easier for beginners, and is therefore a good idea. It would help at least this one mossbeard, though, if you keep it easy to change the default, preferably all at one command. -- Beartooth Staffwright, Not Quite Clueless Power User Remember I know little (precious little!) of where up is. From alpine.chappa at gmx.com Sun May 27 09:53:09 2018 From: alpine.chappa at gmx.com (Eduardo Chappa) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Directory for saving configuration files In-Reply-To: References: Message-ID: On Sun, 27 May 2018, Beartooth wrote: > One very small detail. I for one, and probably others who keep > lots of different signatures, often want to change only for the current > message. At present, doing so is very easy: > > Set the cursor, hit ^R, and type sig/. Then delete the > default signature that's already there. Done. I hear you, but this is not what is meant in this discussion. The ^R command is a general way to include files, not signatures. You could insert anything, not just a signature. This mechanism is not going to change. You will still be able to insert signatures this way in the future. What is going to change is where the signatures that you have configured in your .pinerc will reside. They will be transferred to ./alpine/signature, keeping the same relative location as in your home directory. These files are inserted automatically to your message, so if you actually set up Alpine, say using roles, you could have this done automatically, instead of digging through your sig/ directory, and you would never make a mistake in typing. In fact, if you concatenate all your signatures into one file, then all you have to do is to delete the text you do not want, and not typing would be required. However, if you insist to keep using Alpine as in the past, that will be possible too. You will be given more choices in the future. -- Eduardo http://alpine.x10host.com/alpine/release (Web) http://repo.or.cz/alpine.git (Git) RSS: http://repo.or.cz/alpine.git/rss (Git updates) RSS: http://alpine.x10host.com/alpine/alpine.xml (Web updates) From lucio at lambrate.inaf.it Mon May 28 02:29:30 2018 From: lucio at lambrate.inaf.it (Lucio Chiappetti) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Directory for saving configuration files In-Reply-To: References: Message-ID: On Fri, 25 May 2018, Eduardo Chappa wrote: > * Finding the files to configure Alpine should be easy. > * All files used to configure Alpine should be in one and only one place > only. In principle I'd agree. One thing I like of the customizable software I like (like alpine or fvwm) is that (almost) all configuration is in a single FILE (.pinerc or .fvwm/.fvwm2rc), and that the file is a simple editable kwd=value text file. I'd make two exceptions although I'd never made use of one, and only a little use of the other. - one is using alpine with an "alternate profile" (-p), which probably means an entire alternate directory (this is the feature I never used so far) - the other is alternate roles (I made little use of them) Anyhow for Unix/Linux users soft links are your friends. One can always softlink a file from one directory to another. > .mailcap and the .mime-types files. Firefox does not care about these > files. Firefox, uses its own mailcap files. Now that's a pity. I long abandoned Firefox in favour of Pale Moon since it allows a lot more of customization. Unfortunately in this respect even PM mantains the same model of FF, i.e. their mailcap is not a true mailcap, I have never been able to find where it is and to edit it in an easy way. > Should Alpine have its own mailcap files? Why not? maybe that is a good > idea, Personally I'm quite happy with the current arrangement which provides a Mailcap Search Path and a Mimetype Search Path which can be LISTS of different files. My Mailcap Search Path is ~/.mailcap:~/.mailcap.pine i.e. appends some specific entries to the system ones. My Mimetype Search Path is instead a short pine specific file where I list some common file extensions like "application/pdf pdf PDF" ... which allows alpine to ASK me whether I want to view the file "by extension" if the Content-type is misrepresented by the sender ... I find it a great and reasonable feature by alpine -- Lucio Chiappetti - INAF/IASF - via Bassini 15 - I-20133 Milano (Italy) For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html ------------------------------------------------------------------------ "All that is google does not glitter Nor all who use alpine/procmail are lost" From robin.listas at telefonica.net Mon May 28 04:32:54 2018 From: robin.listas at telefonica.net (Carlos E. R.) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Directory for saving configuration files In-Reply-To: References: Message-ID: <3884f2f9-f486-3612-caad-48984dcc363f@telefonica.net> On 2018-05-28 11:29, Lucio Chiappetti wrote: > On Fri, 25 May 2018, Eduardo Chappa wrote: >> Should Alpine have its own mailcap files? Why not? maybe that is a >> good idea, > > Personally I'm quite happy with the current arrangement which provides a > Mailcap Search Path and a Mimetype Search Path which can be LISTS of > different files. > > My Mailcap Search Path is ~/.mailcap:~/.mailcap.pine i.e. appends some > specific entries to the system ones. > > My Mimetype Search Path is instead a short pine specific file where I > list some common file extensions like "application/pdf?? pdf PDF" ... > which allows alpine to ASK me whether I want to view the file "by > extension" if the Content-type is misrepresented by the sender ... I > find it a great and reasonable feature by alpine openSUSE does no longer provide a mailcap file. I had to copy it over from an older install. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 188 bytes Desc: OpenPGP digital signature URL: From alpine.chappa at gmx.com Mon May 28 11:14:27 2018 From: alpine.chappa at gmx.com (Eduardo Chappa) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Directory for saving configuration files In-Reply-To: References: Message-ID: On Mon, 28 May 2018, Lucio Chiappetti wrote: > On Fri, 25 May 2018, Eduardo Chappa wrote: > >> * Finding the files to configure Alpine should be easy. >> * All files used to configure Alpine should be in one and only one place >> only. > > In principle I'd agree. One thing I like of the customizable software I like > (like alpine or fvwm) is that (almost) all configuration is in a single FILE > (.pinerc or .fvwm/.fvwm2rc), and that the file is a simple editable kwd=value > text file. > > I'd make two exceptions although I'd never made use of one, and only a little > use of the other. > > - one is using alpine with an "alternate profile" (-p), which probably > means an entire alternate directory (this is the feature I never used > so far) > > - the other is alternate roles (I made little use of them) > > Anyhow for Unix/Linux users soft links are your friends. One can always > softlink a file from one directory to another. Yes, I agree that symlinks are your friends. I believe that most users do not use the -p option. To me it makes sense to use -p option when * you need two different configuration files. This has been mostly superseeded by the use of roles; and * you are a developer and would like a convenient way to try someone else's pinerc file to debug someone elses problem. I would discard the second as a concern, because it happens to advanced users only and it is temporary. The first one could happen to more users, and I do not know if there are people using Alpine this way. I imagine that most users do not start Alpine on a regular basis with this option, so what I think should be done in this case is: When a user starts alpine for the first time after this modification is added: * If alpine is started in the normal way (type "alpine" in the command line) copy all configuration files to .alpine and read files from there in the future. * If alpine is started with the -p option, no change in configuration directory will take effect. Alpine will read its configuration according to what the pinerc in the -p option says. After alpine has created a configuration directory. * If alpine is started in the normal way, all configuration files will be read directly from the .alpine directory, and everything will be saved there. Alpine will check if new configuration files have been added to the pinerc file and copy them to the .alpine directory in case they are not there. * If alpine is started with the -p option, alpine will read its configuration from the pinerc file specified in this option, and will ignore the .alpine directory. >> Should Alpine have its own mailcap files? Why not? maybe that is a good >> idea, > > Personally I'm quite happy with the current arrangement which provides a > Mailcap Search Path and a Mimetype Search Path which can be LISTS of > different files. > > My Mailcap Search Path is ~/.mailcap:~/.mailcap.pine i.e. appends some > specific entries to the system ones. > > My Mimetype Search Path is instead a short pine specific file where I > list some common file extensions like "application/pdf pdf PDF" ... > which allows alpine to ASK me whether I want to view the file "by > extension" if the Content-type is misrepresented by the sender ... I > find it a great and reasonable feature by alpine I was thinking of adding a ~/.alpine/apps/mailcap and ~/.alpine/apps/mime-types files to the mailcap path search, and copy the personal ~/.mailcap and ~/.mime-type files there. Then add a configuration screen for mailcap and mime-type files, and forget about the ~/.mailcap and ~/.mime-type files. At least that is the idea at this time. -- Eduardo http://alpine.x10host.com/alpine/release (Web) http://repo.or.cz/alpine.git (Git) RSS: http://repo.or.cz/alpine.git/rss (Git updates) RSS: http://alpine.x10host.com/alpine/alpine.xml (Web updates) From lucio at lambrate.inaf.it Tue May 29 02:12:43 2018 From: lucio at lambrate.inaf.it (Lucio Chiappetti) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Directory for saving configuration files In-Reply-To: References: Message-ID: On Mon, 28 May 2018, Eduardo Chappa wrote: > > I believe that most users do not use the -p option. To me it makes sense > to use -p option when > > * you need two different configuration files. This has been mostly > superseeded by the use of roles; and I *may* think of another case. It does not apply to me because I am not a frequent traveller, and I like to send, receive and store all mail on my local desktop machine. In the rare cases I'm away I activate a personal imap server on my machine. Last time I had a long mission I brought with me a laptop with its own alpine configuration (so I was able to have both local storage and storage at home). Nowadays during short holidays I use a webmailer as imap client (incidentally, WebAlpine distributed with my alpine version, I think I am one of the few users of it) But some of my colleagues are frequent travellers and they use a laptop with a docking station. In such cases, if they were keen alpine users and concerned with keeping their mail private like me (which they aren't) I could imagine one has two .pinerc's - one for local inbox local SMTP local folders - one for IMAP inbox, remote SMTP, mix of local and remote folders > Then add a configuration screen for mailcap and mime-type files, and > forget about the ~/.mailcap and ~/.mime-type files. At least that is the > idea at this time. Could be overshoot, But I've never looked deeply in how many pieces of s/w I use do actually use mailcap nowadays (it's a pity browser don't) -- Lucio Chiappetti - INAF/IASF - via Bassini 15 - I-20133 Milano (Italy) For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html ------------------------------------------------------------------------ "All that is google does not glitter Nor all who use alpine/procmail are lost" From robin.listas at telefonica.net Tue May 29 04:31:46 2018 From: robin.listas at telefonica.net (Carlos E. R.) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Stop Displaying IP Address in Headers of Sent Messages, and more. In-Reply-To: References: Message-ID: On 2018-05-29 12:59, stef_204 wrote: > Alpine 2.21 > Linux x86_64 > > I notice tha sending an email trhough GMail shows the full IP Address in > the headers of the sent message as well as the domain name of my lan e.g. > mybox,my routeur > > Is there a way to sotp Alpine (or GMail) from doing that? > > or at least obfuscating it, etc.? Nope. And this will happen with any mail provider you use. Every server in the process adds at least one "Received:" header with the name and IP of the machine it got the email from. Every machine it passes is recorded. Some machine might not record it, but it would be against the "rules". Even spammers get their IP recorded, but they may obfuscate the issue by adding false headers. But at one point, the "Received:" header are true, at the first "good" machine in the chain, and this one will report where it got the spam mail from. If you want to hide your IP, you have to use something like TOR. And maybe not enough. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 188 bytes Desc: OpenPGP digital signature URL: From robin.listas at telefonica.net Tue May 29 04:39:08 2018 From: robin.listas at telefonica.net (Carlos E. R.) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Force Saved Messages to local folder In-Reply-To: References: Message-ID: On 2018-05-29 13:14, stef_204 wrote: > Alpine 2.21 > Linux x86_64 > > Hi, > > Just recently started to interact with GMail. > > I can't figure out how to force Alpine to use a /local/ folder for saved- > messages; whatever I put in the field: "Default Saved Message Folder" it > creates on GMail. > > All I want is for whatever "saved" messages are saved to a LOCAL folder > only (whatever name: saved-msgs for example). > > How can I accomplish that? > > (I don't have this problem with other IMAP config on non GMAil accounts.) Gmail will always keep a copy. However, maybe you can also store a local copy. I get it automatically, because I send using my local postfix SMTP server, not gmail's. So Alpine sees a standard SMTP. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 188 bytes Desc: OpenPGP digital signature URL: From robin.listas at telefonica.net Tue May 29 05:13:21 2018 From: robin.listas at telefonica.net (Carlos E. R.) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Force Saved Messages to local folder In-Reply-To: References: Message-ID: <8e18e3d6-4f15-f8fd-b14e-042be7423305@telefonica.net> On 2018-05-29 13:45, stef_204 wrote: > On Tue, 29 May 2018 13:39:08 +0200, Carlos E. R. wrote: > >> However, maybe you can also store a local copy. > > OK, but how to make Alpine do that? I don't do anything. There is just a header when composing that has: Fcc : sent-mail Same as on all the accounts. However, I do not currently have a folder with the imap view of gmail, I use a local copy with fetchmail. I don't think it matters, though. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 188 bytes Desc: OpenPGP digital signature URL: From robin.listas at telefonica.net Tue May 29 05:29:22 2018 From: robin.listas at telefonica.net (Carlos E. R.) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Stop Displaying IP Address in Headers of Sent Messages, and more. In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2018-05-29 at 11:48 -0000, stef_204 wrote: > On Tue, 29 May 2018 13:31:46 +0200, Carlos E. R. wrote: > >> If you want to hide your IP, you have to use something like TOR. And >> maybe not enough. > > It's not so much that I'd like to hide it as it is unavoidable that it > will be known, I just want not to advertise it. It is not advertised. I normally don't see yours or anybody, but I can look at them. I see that you are using gmane, for instance: Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1f... for alpine-info@u.washington.edu; Tue, 29 May 2018 13:50:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ > And worse is the name of my lan/local domain. FOR SURE, this can be > obfuscated or omitted? Certainly not :-) You may control what your own system writes, by configuring of modifying your own software toolchain, but there will be one header from gmail saying that it got the email from you. Look. This email from you contains this header - it doesn't have your IP, but gmane IP: Received: from blaine.gmane.org ([195.159.176.226]) by mxe26.s.uw.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id w4... (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 29 May 2018 04:52:21 -0700 It means that the server "mxe26.s.uw.edu" (at the University of Washinton) got an email with id w4... sent by the server blaine.gmane.org. If you send an email via gmail, gmail will record similar data with regard to your machine. Look at one post of mine to this list. It has: Received: from Telcontar.valinor (*.red-....dynamicip.rima-tde.net [79.*.*.*]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: robin.listas2@...) by relayout04.e.movistar.es (Postfix) with ESMTPSA id 40... for ; Tue, 29 May 2018 13:31:47 +0200 (CEST) You can see there that my ISP records my local network name, an invented name (Telcontar.valinor). The name is invented, but the IP is accurate. And none of the headers can be hidden. You may know how to read them or not, but they will be there. You can add faked headers (spammers do), but from one point they get real. - -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlsNR6MACgkQtTMYHG2NR9VoYgCff1yI8Dux7M3U3kKfcsIxfO6K 07AAn0rk+HSSYcxyJnoc5MipjLs8qtJU =Qpb5 -----END PGP SIGNATURE----- From robin.listas at telefonica.net Tue May 29 06:47:49 2018 From: robin.listas at telefonica.net (Carlos E. R.) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Force Saved Messages to local folder In-Reply-To: References: <8e18e3d6-4f15-f8fd-b14e-042be7423305@telefonica.net> Message-ID: <3200551e-9467-f010-5f56-0ccc04066073@telefonica.net> On 2018-05-29 15:20, stef_204 wrote: > On Tue, 29 May 2018 14:13:21 +0200, Carlos E. R. wrote: > >> On 2018-05-29 13:45, stef_204 wrote: >>> On Tue, 29 May 2018 13:39:08 +0200, Carlos E. R. wrote: >>> >>>> However, maybe you can also store a local copy. >>> >>> OK, but how to make Alpine do that? >> >> I don't do anything. >> >> There is just a header when composing that has: >> >> Fcc : sent-mail >> >> >> Same as on all the accounts. >> >> However, I do not currently have a folder with the imap view of gmail, I >> use a local copy with fetchmail. I don't think it matters, though. > > That does not seem to work--whatever value I insert in the corresponding > field it seems to create that folder on GMail's IMAP server for the > account; and save there. As far as I know, it will always be saved on Gmail imap. The question is if it also saves it locally. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 188 bytes Desc: OpenPGP digital signature URL: From lucio at lambrate.inaf.it Tue May 29 07:32:37 2018 From: lucio at lambrate.inaf.it (Lucio Chiappetti) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Force Saved Messages to local folder In-Reply-To: References: Message-ID: On Tue, 29 May 2018, stef_204 wrote: > Just recently started to interact with GMail. My condolences. I'm half-way through a similar process due to arrangements within my institution. > All I want is for whatever "saved" messages are saved to a LOCAL folder > only (whatever name: saved-msgs for example). I am not sure I understand your problem or configuration. My base configuration was that I receive mail on my machine (relayed from my institute MX) and send it from my machine (no SMTP server defined in .pinerc, so it will use my machine's sendmail, who relays to the institute smarthost). So my alpine is fully local, and almost all my folders ARE local. With Fcc: and ctl-T I can go around some hundred LOCAL folders. Without doing anything. I say "almost all" because some folders in the "incoming folder collections" are on remote IMAP or POP servers. > (I don't have this problem with other IMAP config on non GMAil accounts.) I occasionally had an alpine (on a laptop) configured to connect to an IMAP, and in this case I had separate folder collections which were local on the laptop or remote on the IMAP server (which occurred to be my local machine at home). Syntax as per alpine help. Of course the laptop has to point to a valid SMTP server. Now we will have an institution-wide (nationwide institution with several institutes in different cities) Gsuite server (GMAIL commercial product). Presently I am just TESTING the receiving part. If nobody forbids, I won't change the sending part (so I will use my institute's smtp and alpine will continue saving outgoing mail locally). For the receiving part I want to continue using my corpus of procmail rules, so I decided that everything received on Gsuite is transferred to my machine every 5 min by fetchmail. In doing this, I discovered that using POP to connect to Gsuite is better suited to my aims than using IMAP. Actually I have both, since both can be activated at the same time, with the following arrangement. 1) I have a folder in the incoming folder collection which points via IMAP to Gsuite's inbox. I generally do not use it. However if a message arrives to Gsuite before the next run of fetchmail, alpine sees it's there : "Gsuite (1/1)" displayed 2) I have an entire folder collection pointing to the rest of Gsuite default folders BUT the inbox, appears like this in the folder index All Mail[/] Bin[/] Drafts[/] Important[/] Sent Mail[/] Spam[/] Starred[/] I generally do NOT use it, but I could if I wanted to check out spam 3) fetchmail instead connects to Gsuite via POP. I do not want messages to stay on Gsuite over long. I found that GMail IMAP implementation is "funny". If I instruct their IMAP to delete mail retrieved by fetchmail. Gmail saves a copy in "All Mail" If I do the analogous to their POP, Gmail saves a copy in "Bin". Now Bin is normal (alpine can access it, Delete and eXpunge) while "All Mail" is NOT (alpine can access it, Delete marks for deletion but eXpunge is not honoured), There is no way to delete from "All Mail" but using Gmail's webmailer 4) so I decided to use POP with fetchmail, and periodically clean up Gsuite's Bin not to leave anything there. This I can do from Alpine with a single keystroke (Alpine with key definition patch, which is a GREAT feature !). I type L B, and B is defined to this sequence M,L,W,"All Gsuite",^M,G,"Bin",^M,;,A,A,D,X which clears the Bin folder in the All Gsuite collection. -- Lucio Chiappetti - INAF/IASF - via Bassini 15 - I-20133 Milano (Italy) For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html ------------------------------------------------------------------------ "All that is google does not glitter Nor all who use alpine/procmail are lost" From alpine.chappa at gmx.com Tue May 29 07:33:21 2018 From: alpine.chappa at gmx.com (Eduardo Chappa) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Stop Displaying IP Address in Headers of Sent Messages, and more. In-Reply-To: References: Message-ID: On Tue, 29 May 2018, stef_204 wrote: > I notice tha sending an email trhough GMail shows the full IP Address in > the headers of the sent message as well as the domain name of my lan > e.g. mybox,my routeur > > Is there a way to sotp Alpine (or GMail) from doing that? > > or at least obfuscating it, etc.? This is what happens when you connect to the internet. Your IP address is known by the person you are connecting to. In this case, the SMTP server in Gmail knows your IP address because you are connecting to it, and your local address comes as a result of the EHLO command RFC 2821 says the following text: The argument field contains the fully-qualified domain name of the SMTP client if one is available. In situations in which the SMTP client system does not have a meaningful domain name (e.g., when its address is dynamically allocated and no reverse mapping record is available), the client SHOULD send an address literal (see section 4.1.3), optionally followed by information that will help to identify the client system. y The SMTP server identifies itself to the SMTP client in the connection greeting reply and in the response to this command. This is the relevant part of section 4.1.3, referred to above: 4.1.3 Address Literals Sometimes a host is not known to the domain name system and communication (and, in particular, communication to report and repair the error) is blocked. To bypass this barrier a special literal form of the address is allowed as an alternative to a domain name. For IPv4 addresses, this form uses four small decimal integers separated by dots and enclosed by brackets such as [123.255.37.2], which indicates an (IPv4) Internet Address in sequence-of-octets form. I hope this explains what you are seeing. -- Eduardo http://alpine.x10host.com/alpine/release (Web) http://repo.or.cz/alpine.git (Git) RSS: http://repo.or.cz/alpine.git/rss (Git updates) RSS: http://alpine.x10host.com/alpine/alpine.xml (Web updates) From alpine.chappa at gmx.com Tue May 29 07:42:37 2018 From: alpine.chappa at gmx.com (Eduardo Chappa) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Force Saved Messages to local folder In-Reply-To: References: Message-ID: On Tue, 29 May 2018, stef_204 wrote: > I can't figure out how to force Alpine to use a /local/ folder for > saved- messages; whatever I put in the field: "Default Saved Message > Folder" it creates on GMail. Press M S C and set the Default Fcc (File carbon copy) = variable to be the full path of the LOCAL folder where you want to save messages to. A non-full path is interpreted as a relative path in relation to your first collection of folders after the incoming folders collectio. On another note and FYI: Replying to your earlier message got me this message back from yahoo. In case you did not receive my message, look at it in the archives of this mailing list: This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: stef_204@yahoo.com: SMTP error from remote server for MAIL FROM command, host: mta6.am0.yahoodns.net (98.137.159.27) reason: 553 5.7.2 [TSS06] All messages from 82.165.159.42 will be permanently defe rred; Retrying will NOT succeed. See https://help.yahoo.com/kb/postmas ter/SLN3436.html -- Eduardo http://alpine.x10host.com/alpine/release (Web) http://repo.or.cz/alpine.git (Git) RSS: http://repo.or.cz/alpine.git/rss (Git updates) RSS: http://alpine.x10host.com/alpine/alpine.xml (Web updates) From dandunfee at gmail.com Tue May 29 07:50:28 2018 From: dandunfee at gmail.com (dan d.) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] Force Saved Messages to local folder Message-ID: To save a local copy to a folder hit the s key. It will prompt for the name of the folder. If it exists it will save it. If it doesn't, typing a name will bring a prompt to create the folder and then it will save. There are various save related options in the configuration also. On Tue, 29 May 2018, stef_204 wrote: > On Tue, 29 May 2018 13:39:08 +0200, Carlos E. R. wrote: > > > However, maybe you can also store a local copy. > > OK, but how to make Alpine do that? > > _______________________________________________ > Alpine-info mailing list > Alpine-info@u.washington.edu > http://mailman13.u.washington.edu/mailman/listinfo/alpine-info > -- XB From lists at nerdbynature.de Thu May 31 23:24:55 2018 From: lists at nerdbynature.de (Christian Kujau) Date: Tue Jun 12 15:15:06 2018 Subject: [Alpine-info] =?utf-8?b?cGljby5jOjE5MzY6ODogZXJyb3I6IOKAmG1lbnVp?= =?utf-8?q?tems=E2=80=99_undeclared?= Message-ID: Hi, trying to compile today's git checkout fails with: ==================== pico.c: In function ?free_pico_module_globals?: pico.c:1936:8: error: ?menuitems? undeclared (first use in this function) if(menuitems[i].kncp) ^~~~~~~~~ pico.c:1936:8: note: each undeclared identifier is reported only once for each function it appears in Makefile:557: recipe for target 'pico.o' failed ==================== aac7b10863bcfabe936feb5151e7e11123e13306 ("More changes to make Valgrind happy. Work in progress") introduced free_pico_module_globals() and removing this function makes Alpine compile again (see patch attached). Obviously that will not be the proper fix, but I could not find the library that would include that "menuitems" function that is missing here. Christian. -- BOFH excuse #41: interrupt configuration error -------------- next part -------------- A non-text attachment was scrubbed... Name: free_pico_module_globals.patch Type: text/x-diff Size: 975 bytes Desc: URL: