From gatetman at gmail.com Tue Apr 19 09:42:04 2022 From: gatetman at gmail.com (Carl Edquist) Date: Fri Mar 22 14:17:32 2024 Subject: [Alpine-info] O365 XOAUTH2 via fetchmail Message-ID: <3abd874-51a8-cb8d-62f2-9cf98d2b7fe6@gmail.com> Hi all, I am using alpine for an O365 account which requires the "modern authentication" / XOAUTH2. This works and a big thank you to Eduardo (Thanks Eduardo!!) for adding this support to alpine. But for a couple reasons, what I would like to try to do now, if possible, is use fetchmail to retrieve my messages (from O365 with XOAUTH2) into a local mbox file, and have alpine deal just with the local mbox files. (I used to have a setup like this before my O365 account started requiring XOAUTH2). I think I have read in the past that people have gotten something like this working with fetchmail + XOAUTH2. (At least with gmail anyway.) Has anyone gotten something like this working with fetchmail + XOAUTH2 for O365? A big thank you in advance if anyone has any links, or personal tips, etc on getting this working... Thanks! Carl From andrew at aitchison.me.uk Tue Apr 19 11:44:00 2022 From: andrew at aitchison.me.uk (Andrew C Aitchison) Date: Fri Mar 22 14:17:32 2024 Subject: [Alpine-info] O365 XOAUTH2 via fetchmail In-Reply-To: <3abd874-51a8-cb8d-62f2-9cf98d2b7fe6@gmail.com> References: <3abd874-51a8-cb8d-62f2-9cf98d2b7fe6@gmail.com> Message-ID: On Tue, 19 Apr 2022, Carl Edquist wrote: > Hi all, > > I am using alpine for an O365 account which requires the "modern > authentication" / XOAUTH2. This works and a big thank you to Eduardo (Thanks > Eduardo!!) for adding this support to alpine. > > But for a couple reasons, what I would like to try to do now, if possible, is > use fetchmail to retrieve my messages (from O365 with XOAUTH2) into a local > mbox file, and have alpine deal just with the local mbox files. (I used to > have a setup like this before my O365 account started requiring XOAUTH2). > > I think I have read in the past that people have gotten something like this > working with fetchmail + XOAUTH2. (At least with gmail anyway.) > > Has anyone gotten something like this working with fetchmail + XOAUTH2 for > O365? A big thank you in advance if anyone has any links, or personal tips, > etc on getting this working... This is somewhat off-topic. https://lists.sourceforge.net/lists/listinfo/fetchmail-users would be an appropriate place to ask. Short answer: No current release of fetchmail ships with XOAUTH2 support. The current fetchmail is v6.4. Versions 6.5beta and 7alpha are available (and Gentoo Linux is reported to ship with v7). Fecthmail v7 includes XOAUTH2 support and third-party patches for v6.5 and v6.5 exist at http://mmogilvi.users.sourceforge.net/software/oauthbearer.html#setupFetchmail (no 's' in http) and https://www.aitchison.me.uk/fetchmail/ (yes I am responsible for the second set). Matthias Andree, the fetchmail maintainer, is unhappy with the hoops gmail make him jump through to "register" fetchmail https://sourceforge.net/p/fetchmail/mailman/fetchmail-users/?viewmonth=202204&viewday=16 If he cannot get fetchmail to use XOAUTH2 *without* registering the "app" he would appear to be considering whether dropping the feature is an option. -- Andrew C. Aitchison Kendal, UK andrew@aitchison.me.uk From robin.listas at telefonica.net Tue Apr 19 12:04:12 2022 From: robin.listas at telefonica.net (Carlos E. R.) Date: Fri Mar 22 14:17:32 2024 Subject: [Alpine-info] O365 XOAUTH2 via fetchmail In-Reply-To: <3abd874-51a8-cb8d-62f2-9cf98d2b7fe6@gmail.com> References: <3abd874-51a8-cb8d-62f2-9cf98d2b7fe6@gmail.com> Message-ID: On 2022-04-19 18:42, Carl Edquist wrote: > Hi all, > > I am using alpine for an O365 account which requires the "modern > authentication" / XOAUTH2.? This works and a big thank you to Eduardo > (Thanks Eduardo!!) for adding this support to alpine. > > But for a couple reasons, what I would like to try to do now, if > possible, is use fetchmail to retrieve my messages (from O365 with > XOAUTH2) into a local mbox file, and have alpine deal just with the > local mbox files.? (I used to have a setup like this before my O365 > account started requiring XOAUTH2). > > I think I have read in the past that people have gotten something like > this working with fetchmail + XOAUTH2.? (At least with gmail anyway.) > > Has anyone gotten something like this working with fetchmail + XOAUTH2 > for O365?? A big thank you in advance if anyone has any links, or > personal tips, etc on getting this working... Besides what Andrew says, gmail is forcing to activate 2FA/2SV on all accounts, and in that case, using application passwords is easier to do than Xoauth2. I did not like the idea of having to use 2FA on an account is not associated to an android phone (in which you login to google), but can also be the recovery phone that they also force you to input on the account settings. They send an SMS to it, and that works. So I have an android phone in which I login, and use it as recovery phone for other gmail accounts. Yes, many loops. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar) -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 209 bytes Desc: OpenPGP digital signature URL: From alpine.chappa at yandex.com Tue Apr 19 15:50:33 2022 From: alpine.chappa at yandex.com (Eduardo Chappa) Date: Fri Mar 22 14:17:32 2024 Subject: [Alpine-info] O365 XOAUTH2 via fetchmail In-Reply-To: References: <3abd874-51a8-cb8d-62f2-9cf98d2b7fe6@gmail.com> Message-ID: <83544857-15d1-67f3-8576-0738e6d3949a@yandex.com> On Tue, 19 Apr 2022, Andrew C Aitchison wrote: >> Has anyone gotten something like this working with fetchmail + XOAUTH2 >> for O365? A big thank you in advance if anyone has any links, or >> personal tips, etc on getting this working... > > This is somewhat off-topic. > https://lists.sourceforge.net/lists/listinfo/fetchmail-users > would be an appropriate place to ask. I thought initially the same but then i realized that Alpine users might look for answers to their questions about Alpine in an Alpine list instead of a fetchmail list. There are many programs that relate to the use of Alpine and this is one of them, so I reconsidered and thought it was appropriate too. > [...] > Matthias Andree, the fetchmail maintainer, is unhappy with the hoops > gmail make him jump through to "register" fetchmail > https://sourceforge.net/p/fetchmail/mailman/fetchmail-users/?viewmonth=202204&viewday=16 > If he cannot get fetchmail to use XOAUTH2 *without* registering the "app" > he would appear to be considering whether dropping the feature is an > option. This portion is both related and unrelated to Alpine. There is nothing to register when you register really. Let me say it this way. Anyone can go to Google and register Alpine or fetchmail or mutt or firefox, etc. because they are open source applications and what you need is a client-id and client-secret to run your app. That is all. I went through the process of registering Alpine not because I like Google but because Alpine users need it. It does not matter how I feel about the abuses of Google, Alpine users care about reading their email and not my feelings about Google. I ended up giving Alpine users the chance the get their own client-id and client-secret because that is what a Google employee told me that we were going to come down to. The real problem with Google is not the registration. It is the verification (of the app). It costs $75000 to verify an app every year. That is the minimum. I do not make money to give it to Google. I do not make money out of selling anything Alpine related to give it to Google. Worse, no other company requires this. This is an abuse. On the Google side they told me that it was the lawyers who did this, as if it was a logical conclusion of some sort and it could not be therefore modified. It guarantees security, they said, which is something that Google sells (in its advertisements). By now it is too late to do anything. No one can go against the giant, and above all I am sorry people support Google by using their products. However, despite my despise for Google, I will not make Alpine users make my feelings be part of their experience, and I think the same should be said about other programs that people depend on, such as fetchmail. If there is one thing that I think XOAUTH2 is doing to programs like Alpine, fetchmail, etc., is that they are being replaced by other commercial apps completely. The requirement that a users authorizes an app to access their email also is trumped by the requirement that the administrator authorizes the app to access their server, and that is a big issue today as many administrators prefer not to allow apps with which they are unfamiliar for the sake of security and privacy. The real issue is that IMAP and SMTP are being deprecated by the fact that OAUTH2 over HTTPS is sold as a secure/modern authentication, while IMAP and SMTP are not. While it makes no sense to have this discussion in this forum, it is an argument being used today to not to allow users to turn on IMAP and SMTP, and that is an issue for Alpine users. Let me say it differently. The world is changing with the excuse of security and privacy. With that excuse programs like Alpine are being left out. It is important that all of us communicate to other people that Alpine is a safe program to use, that respects your privacy and makes no effort to track you or steal information from anyone. I am working on modernizing Alpine, but the real issue is not if IMAP and SMTP will be killed, the real issue is if Alpine will be given access to IMAP and SMTP by administrators, and that is a bigger issue, because chances are that the administrator that you have to ask this question to will say no. I hope the maintainer of fetchmail decides to include OAUTH2 support. We need programs like fetchmail, mutt, alpine, etc. to keep working in the future. Some Alpine users prefer fecthmail and I hope they will be able to continue using it for many years to come. -- Eduardo From jason-alpine-info at shalott.net Tue Apr 19 17:39:58 2022 From: jason-alpine-info at shalott.net (jason-alpine-info@shalott.net) Date: Fri Mar 22 14:17:32 2024 Subject: [Alpine-info] O365 XOAUTH2 via fetchmail In-Reply-To: <83544857-15d1-67f3-8576-0738e6d3949a@yandex.com> References: <3abd874-51a8-cb8d-62f2-9cf98d2b7fe6@gmail.com> <83544857-15d1-67f3-8576-0738e6d3949a@yandex.com> Message-ID: >>> Has anyone gotten something like this working with fetchmail + XOAUTH2 >>> for O365? >> This is somewhat off-topic. > I thought initially the same but then i realized that Alpine users might > look for answers to their questions about Alpine in an Alpine list > instead of a fetchmail list. There are many programs that relate to the > use of Alpine and this is one of them, so I reconsidered and thought it > was appropriate too. Well, I'll take that as a green light to toss out another alternative. :) OfflineIMAP is a similar program that can fetch mail from a remote IMAP server. It can do both one-way (i.e., only fetch messages, never modify server-side state) and two-way sync (i.e., when you delete a message in the local copy, it will also delete it on the server), and it is known to work with Google and Outlook365, both using OAUTH2. There are a lot of fetchmail-type apps out there, but OfflineIMAP is by far the one that I personally have had the best luck with. I have most often used it to do one-way sync, to keep an immutable backup of all mail that I ever received; but I have also used it in two-way sync mode, and never had any problems. Your mileage may vary, but it is always my first choice in this space. Some links that may help: http://www.offlineimap.org/ https://hobo.house/2017/07/17/using-offlineimap-with-the-gmail-imap-api/ https://github.com/UvA-FNWI/M365-IMAP -Jason From robin.listas at telefonica.net Wed Apr 20 03:12:26 2022 From: robin.listas at telefonica.net (Carlos E. R.) Date: Fri Mar 22 14:17:32 2024 Subject: [Alpine-info] O365 XOAUTH2 via fetchmail In-Reply-To: <83544857-15d1-67f3-8576-0738e6d3949a@yandex.com> References: <3abd874-51a8-cb8d-62f2-9cf98d2b7fe6@gmail.com> <83544857-15d1-67f3-8576-0738e6d3949a@yandex.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2022-04-19 at 16:50 -0600, Eduardo Chappa wrote: > On Tue, 19 Apr 2022, Andrew C Aitchison wrote: > >>> Has anyone gotten something like this working with fetchmail + XOAUTH2 >>> for O365? A big thank you in advance if anyone has any links, or >>> personal tips, etc on getting this working... >> >> This is somewhat off-topic. >> https://lists.sourceforge.net/lists/listinfo/fetchmail-users >> would be an appropriate place to ask. > > I thought initially the same but then i realized that Alpine users might look > for answers to their questions about Alpine in an Alpine list instead of a > fetchmail list. There are many programs that relate to the use of Alpine and > this is one of them, so I reconsidered and thought it was appropriate too. > >> [...] >> Matthias Andree, the fetchmail maintainer, is unhappy with the hoops >> gmail make him jump through to "register" fetchmail >> https://sourceforge.net/p/fetchmail/mailman/fetchmail-users/?viewmonth=202204&viewday=16 >> If he cannot get fetchmail to use XOAUTH2 *without* registering the "app" >> he would appear to be considering whether dropping the feature is an >> option. > > This portion is both related and unrelated to Alpine. > > There is nothing to register when you register really. Let me say it this > way. Anyone can go to Google and register Alpine or fetchmail or mutt or > firefox, etc. because they are open source applications and what you need is > a client-id and client-secret to run your app. That is all. > > I went through the process of registering Alpine not because I like Google > but because Alpine users need it. It does not matter how I feel about the > abuses of Google, Alpine users care about reading their email and not my > feelings about Google. I ended up giving Alpine users the chance the get > their own client-id and client-secret because that is what a Google employee > told me that we were going to come down to. > > The real problem with Google is not the registration. It is the verification > (of the app). It costs $75000 to verify an app every year. That is the > minimum. I do not make money to give it to Google. I do not make money out of > selling anything Alpine related to give it to Google. > Worse, no other company requires this. This is an abuse. Indeed :-( > On the Google side they told me that it was the lawyers who did this, as if > it was a logical conclusion of some sort and it could not be therefore > modified. It guarantees security, they said, which is something that Google > sells (in its advertisements). By now it is too late to do anything. No one > can go against the giant, and above all I am sorry people support Google by > using their products. However, despite my despise for Google, I will not make > Alpine users make my feelings be part of their experience, and I think the > same should be said about other programs that people depend on, such as > fetchmail. > > If there is one thing that I think XOAUTH2 is doing to programs like Alpine, > fetchmail, etc., is that they are being replaced by other commercial apps > completely. The requirement that a users authorizes an app to access their > email also is trumped by the requirement that the administrator authorizes > the app to access their server, and that is a big issue today as many > administrators prefer not to allow apps with which they are unfamiliar for > the sake of security and privacy. I have not changed my use of Alpine one iota. I use fetchmail much less, yes, but not because of gmail, it happened before the oauth nonsense. I stopped using fetchmail because of actually using imap and having more than one computer: I changed to leaving email on the upstream server instead of in my machine. Once a month I move old email out of the upstream imap server to my own machine, using Alpine instead of fetchmail because I have to select what to download. As alternative, some times I "move" email from an upstream imap folder to a local imap server in my machine, using imapsync: imapsync --errorsmax 150 --addheader --no-modulesversion \ --host1 imap.telefonica.net --user1 USER --passfile1 ~/keys/.secret_tesa_L_imapsync \ --host2 telcontar.valinor --user2 cer --passfile2 .secret_imapsync --delete1 \ --folder temp_l --f1f2 temp_l=Tesa_L_tmp (you may remember that I have problems with my ISP and one account: connections break, and this breaks alpine in the middle of moving mail. However, it does not break imapsync. I have no explanation for this) > The real issue is that IMAP and SMTP are being deprecated by the fact that > OAUTH2 over HTTPS is sold as a secure/modern authentication, while IMAP and > SMTP are not. While it makes no sense to have this discussion in this forum, > it is an argument being used today to not to allow users to turn on IMAP and > SMTP, and that is an issue for Alpine users. There is a troll in Usenet that says something interesting (you know that some trolls are not trolling full time and may say interesting things now and then). He says that the real thing about oauth2 is that it permits Google to track us. Google gets to know which application you are using to read email each time, and in which computer. This is possibly true. Fits as well with having to use 2FA/2SV and associating the account with a phone number. Reminds me. This troll also says that it is possible that Google will change something about those of us using application passwords instead of oauth2, because Google is starting to see this as a method to bypass oauth2. This comes from seeing an error message from gmail that says this, but I can not locate it now for pasting here. Another data point: gmail for groups does not force people to use oauth2 or 2FA/2SV. Example: ieee.org accounts. Apparently the decission is up to the administrator of the group, not gmail itself. > Let me say it differently. The world is changing with the excuse of security > and privacy. With that excuse programs like Alpine are being left out. It is > important that all of us communicate to other people that Alpine is a safe > program to use, that respects your privacy and makes no effort to track you > or steal information from anyone. I am working on modernizing Alpine, but the > real issue is not if IMAP and SMTP will be killed, the real issue is if > Alpine will be given access to IMAP and SMTP by administrators, and that is a > bigger issue, because chances are that the administrator that you have to ask > this question to will say no. That's sad. Has not happened to me, fortunately. > > I hope the maintainer of fetchmail decides to include OAUTH2 support. We need > programs like fetchmail, mutt, alpine, etc. to keep working in the future. > Some Alpine users prefer fecthmail and I hope they will be able to continue > using it for many years to come. We'll tell him to read this post of yours :-) - -- Cheers, Carlos E. R. (from openSUSE 15.3 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCYl/cixwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfV/ZYAn1iVlHdpJmXxnjY7wnCn EkUI5IvGAJwNuvb7pXwLq/w5WRuIJqEIWd0IZw== =k80n -----END PGP SIGNATURE----- From gatetman at gmail.com Wed Apr 20 03:59:18 2022 From: gatetman at gmail.com (Carl Edquist) Date: Fri Mar 22 14:17:32 2024 Subject: [Alpine-info] O365 XOAUTH2 via fetchmail In-Reply-To: <83544857-15d1-67f3-8576-0738e6d3949a@yandex.com> References: <3abd874-51a8-cb8d-62f2-9cf98d2b7fe6@gmail.com> <83544857-15d1-67f3-8576-0738e6d3949a@yandex.com> Message-ID: Hi Eduardo, Thanks a bunch for taking the time to give a thoughtful reply! I appreciate getting your philosophical take on these things. It strikes right to the heart on a number of points! ... > This is somewhat off-topic. I wanted to ask here in part because i thought i had remembered seeing something in the past about a script for fetchmail with oauth2 in connection with alpine, but likely i had some details mixed up in my memory. > I hope the maintainer of fetchmail decides to include OAUTH2 support. Actually (and maybe this will be potentially interesting to some others here), apparently the development branch for the unreleased fetchmail 7 does contain some amount of oauth2 support, despite the maintainer's original reluctance. I had heard it was added for gmail, and i wasn't sure if it worked for O365 - though i knew Eduardo had gotten it working for alpine (because i've been using it successfully). (I will probably give the development version of fetchmail 7 a try (it seems to come with an oauth2 renewal script), though it seemed worth a try to see if anyone here had any tips before wasting too much time probably not getting it right.) ... Notably, i am very happy with alpine and its oauth2 support. My problem is not with alpine but with O365's IMAP access, which is really painfully slow and seems to be broken when it comes to searching (eg, an IMAP search for participants only seems to match the names and not the addresses). Fetching to a local mbox file first solves this problem for me completely. Alpine is very snappy with mbox files and search isn't broken. What i do currently is move everything over manually from within alpine, from the O365 IMAP inbox to a local spool mbox. (";aas[enter]adx[enter]") That works fine, but having an external daemon do it is nice for a couple reasons. My *terminal windows* will charmingly let me know that "You have mail in /var/mail/$USER" when new mail arrives (rather than just the alpine window). (And i will continue to get these charming messages even after closing alpine.) And then i can open up as many alpine windows as i like, without having to enter my alpine password, and without having to worry about multiple alpine processes fighting to do the rule for new mail arrival to move it from the IMAP inbox to a local mbox file for me. (The fetchmail daemon also prompts for a password on startup, but this is once per process lifetime, which equates to once per system boot.) I had tried out another approach - to make two separate alpine configs. The first one with a rule to move mail on arrival from an IMAP inbox to a local spool mbox file. The idea is this would sit open as some kind of an, um, foreground daemon that does what i was used to getting out of fetchmail. This could even sit inside a screen(1) session or something. Then a second config that would not use IMAP at all (and not need any password), which would use the local spool mbox as my inbox. This would be the one i'd use for normal alpine driving (reading, composing, etc), and i could open up as many of these as i like in separate windows. The main trouble with this approach (besides it feeling a little clunky, the fetching instance needing to live in a separate pty somewhere), is if the instance connected to IMAP doing the fetching gets a [MAIL FOLDER "INBOX" CLOSED DUE TO ACCESS ERROR], i'm afraid it might get stuck there unnoticed, waiting for user input before it attempts to reconnect. On the other hand, fetchmail polls in a loop, so transient failures don't really cause any noticeable problems. I'd be open to suggestions if anyone has a better way to accomplish this in alpine. ... Jason, thanks also for the tip about OfflineIMAP, and the links. It looks like it might be promising, except that for the time being i am mostly just interested in output to an mbox file, which does not look to be supported or planned: http://www.offlineimap.org/doc/FAQ.html#does-offlineimap-support-mbox-mh-or-anything-else-other-than-maildir > * Does offlineimap support mbox, mh, or anything else other than > Maildir? > > Not directly. Maildir was the easiest to implement. We are not planning > to write an mbox-backend, though if someone sends well-written mbox > support and pledged to support it, it would be committed it to the tree. So it's probably not the first choice for me at the moment. Thanks all for the input! Carl PS, is it time to start a national "Tell your admin how much you love Alpine" day? (perhaps "Alpine Appreciation Day", for short) On Tue, 19 Apr 2022, Eduardo Chappa wrote: > On Tue, 19 Apr 2022, Andrew C Aitchison wrote: > >>> Has anyone gotten something like this working with fetchmail + XOAUTH2 >>> for O365? A big thank you in advance if anyone has any links, or >>> personal tips, etc on getting this working... >> >> This is somewhat off-topic. >> https://lists.sourceforge.net/lists/listinfo/fetchmail-users >> would be an appropriate place to ask. > > I thought initially the same but then i realized that Alpine users might look > for answers to their questions about Alpine in an Alpine list instead of a > fetchmail list. There are many programs that relate to the use of Alpine and > this is one of them, so I reconsidered and thought it was appropriate too. > >> [...] >> Matthias Andree, the fetchmail maintainer, is unhappy with the hoops >> gmail make him jump through to "register" fetchmail >> https://sourceforge.net/p/fetchmail/mailman/fetchmail-users/?viewmonth=202204&viewday=16 >> If he cannot get fetchmail to use XOAUTH2 *without* registering the "app" >> he would appear to be considering whether dropping the feature is an >> option. > > This portion is both related and unrelated to Alpine. > > There is nothing to register when you register really. Let me say it this > way. Anyone can go to Google and register Alpine or fetchmail or mutt or > firefox, etc. because they are open source applications and what you need is > a client-id and client-secret to run your app. That is all. > > I went through the process of registering Alpine not because I like Google > but because Alpine users need it. It does not matter how I feel about the > abuses of Google, Alpine users care about reading their email and not my > feelings about Google. I ended up giving Alpine users the chance the get > their own client-id and client-secret because that is what a Google employee > told me that we were going to come down to. > > The real problem with Google is not the registration. It is the verification > (of the app). It costs $75000 to verify an app every year. That is the > minimum. I do not make money to give it to Google. I do not make money out of > selling anything Alpine related to give it to Google. > Worse, no other company requires this. This is an abuse. > > On the Google side they told me that it was the lawyers who did this, as if > it was a logical conclusion of some sort and it could not be therefore > modified. It guarantees security, they said, which is something that Google > sells (in its advertisements). By now it is too late to do anything. No one > can go against the giant, and above all I am sorry people support Google by > using their products. However, despite my despise for Google, I will not make > Alpine users make my feelings be part of their experience, and I think the > same should be said about other programs that people depend on, such as > fetchmail. > > If there is one thing that I think XOAUTH2 is doing to programs like Alpine, > fetchmail, etc., is that they are being replaced by other commercial apps > completely. The requirement that a users authorizes an app to access their > email also is trumped by the requirement that the administrator authorizes > the app to access their server, and that is a big issue today as many > administrators prefer not to allow apps with which they are unfamiliar for > the sake of security and privacy. > > The real issue is that IMAP and SMTP are being deprecated by the fact that > OAUTH2 over HTTPS is sold as a secure/modern authentication, while IMAP and > SMTP are not. While it makes no sense to have this discussion in this forum, > it is an argument being used today to not to allow users to turn on IMAP and > SMTP, and that is an issue for Alpine users. > > Let me say it differently. The world is changing with the excuse of security > and privacy. With that excuse programs like Alpine are being left out. It is > important that all of us communicate to other people that Alpine is a safe > program to use, that respects your privacy and makes no effort to track you > or steal information from anyone. I am working on modernizing Alpine, but the > real issue is not if IMAP and SMTP will be killed, the real issue is if > Alpine will be given access to IMAP and SMTP by administrators, and that is a > bigger issue, because chances are that the administrator that you have to ask > this question to will say no. > > I hope the maintainer of fetchmail decides to include OAUTH2 support. We need > programs like fetchmail, mutt, alpine, etc. to keep working in the future. > Some Alpine users prefer fecthmail and I hope they will be able to continue > using it for many years to come. > > -- > Eduardo > From andrew at aitchison.me.uk Wed Apr 20 08:17:39 2022 From: andrew at aitchison.me.uk (Andrew C Aitchison) Date: Fri Mar 22 14:17:32 2024 Subject: [Alpine-info] O365 XOAUTH2 via fetchmail In-Reply-To: References: <3abd874-51a8-cb8d-62f2-9cf98d2b7fe6@gmail.com> <83544857-15d1-67f3-8576-0738e6d3949a@yandex.com> Message-ID: <2e5b40cc-a2ec-d59d-51f9-3f5ca2a5e33@aitchison.me.uk> On Wed, 20 Apr 2022, Carl Edquist wrote: >> I hope the maintainer of fetchmail decides to include OAUTH2 support. > > Actually (and maybe this will be potentially interesting to some others > here), apparently the development branch for the unreleased fetchmail 7 does > contain some amount of oauth2 support, despite the maintainer's original > reluctance. OAUTH2 support has been has been in the contrib section of fetchmail 7 for at least 4 years. On Saturday (16 April 2022) Matthias Andree, the fetchmail maintainer, wrote https://sourceforge.net/p/fetchmail/mailman/fetchmail-users/?viewmonth=202204&viewday=16 So if the abomination of hundreds of pages of a "standard" just for authentication by itself does NOT suffice to implement OAuth2, then we should probably leave it out and remove the experimental bits that are in fetchmail's code before a release, even from contrib, and replace them with a document README.OAuth2 that starts with "why does fetchmail not implement OAuth2". Or else somebody show me to a mail service that is not just some SOHO site and that *does* implement OAuth2 without requiring jumping through arbitrary hoops and showing dressage tricks or play sit up and beg or something, then we can implement it and document "why you cannot use OAuth2 with Google" instead. so I fear that the reluctance to support OAUTH2 has not gone away :-( -- Andrew C. Aitchison Kendal, UK andrew@aitchison.me.uk From dandunfee at gmail.com Wed Apr 20 08:43:12 2022 From: dandunfee at gmail.com (dan d.) Date: Fri Mar 22 14:17:32 2024 Subject: [Alpine-info] O365 XOAUTH2 via fetchmail Message-ID: <1fb24b7-c548-1358-bf9-59b574bd4ae@gmail.com> Eduardo, thank you for the effort you make to ensure alpine works well for all, especially as a screen reader user. Your discussion is well above my understanding of email transfer openness and security. My concern is what happns to alpine users come may when gmail restricts access? What must users such as myself do to prepare for it? On Tue, 19 Apr 2022, Eduardo Chappa wrote: > On Tue, 19 Apr 2022, Andrew C Aitchison wrote: > > >> Has anyone gotten something like this working with fetchmail + XOAUTH2 > >> for O365? A big thank you in advance if anyone has any links, or > >> personal tips, etc on getting this working... > > > > This is somewhat off-topic. > > https://lists.sourceforge.net/lists/listinfo/fetchmail-users > > would be an appropriate place to ask. > > I thought initially the same but then i realized that Alpine users might > look for answers to their questions about Alpine in an Alpine list instead > of a fetchmail list. There are many programs that relate to the use of > Alpine and this is one of them, so I reconsidered and thought it was > appropriate too. > > > [...] > > Matthias Andree, the fetchmail maintainer, is unhappy with the hoops > > gmail make him jump through to "register" fetchmail > > https://sourceforge.net/p/fetchmail/mailman/fetchmail-users/?viewmonth=202204&viewday=16 > > If he cannot get fetchmail to use XOAUTH2 *without* registering the "app" > > he would appear to be considering whether dropping the feature is an > > option. > > This portion is both related and unrelated to Alpine. > > There is nothing to register when you register really. Let me say it this > way. Anyone can go to Google and register Alpine or fetchmail or mutt or > firefox, etc. because they are open source applications and what you need > is a client-id and client-secret to run your app. That is all. > > I went through the process of registering Alpine not because I like Google > but because Alpine users need it. It does not matter how I feel about the > abuses of Google, Alpine users care about reading their email and not my > feelings about Google. I ended up giving Alpine users the chance the get > their own client-id and client-secret because that is what a Google > employee told me that we were going to come down to. > > The real problem with Google is not the registration. It is the > verification (of the app). It costs $75000 to verify an app every year. > That is the minimum. I do not make money to give it to Google. I do not > make money out of selling anything Alpine related to give it to Google. > Worse, no other company requires this. This is an abuse. > > On the Google side they told me that it was the lawyers who did this, as > if it was a logical conclusion of some sort and it could not be therefore > modified. It guarantees security, they said, which is something that > Google sells (in its advertisements). By now it is too late to do > anything. No one can go against the giant, and above all I am sorry people > support Google by using their products. However, despite my despise for > Google, I will not make Alpine users make my feelings be part of their > experience, and I think the same should be said about other programs that > people depend on, such as fetchmail. > > If there is one thing that I think XOAUTH2 is doing to programs like > Alpine, fetchmail, etc., is that they are being replaced by other > commercial apps completely. The requirement that a users authorizes an app > to access their email also is trumped by the requirement that the > administrator authorizes the app to access their server, and that is a big > issue today as many administrators prefer not to allow apps with which > they are unfamiliar for the sake of security and privacy. > > The real issue is that IMAP and SMTP are being deprecated by the fact that > OAUTH2 over HTTPS is sold as a secure/modern authentication, while IMAP > and SMTP are not. While it makes no sense to have this discussion in this > forum, it is an argument being used today to not to allow users to turn on > IMAP and SMTP, and that is an issue for Alpine users. > > Let me say it differently. The world is changing with the excuse of > security and privacy. With that excuse programs like Alpine are being left > out. It is important that all of us communicate to other people that > Alpine is a safe program to use, that respects your privacy and makes no > effort to track you or steal information from anyone. I am working on > modernizing Alpine, but the real issue is not if IMAP and SMTP will be > killed, the real issue is if Alpine will be given access to IMAP and SMTP > by administrators, and that is a bigger issue, because chances are that > the administrator that you have to ask this question to will say no. > > I hope the maintainer of fetchmail decides to include OAUTH2 support. We > need programs like fetchmail, mutt, alpine, etc. to keep working in the > future. Some Alpine users prefer fecthmail and I hope they will be able to > continue using it for many years to come. > > -- ent- XR From andrew at aitchison.me.uk Wed Apr 20 08:56:55 2022 From: andrew at aitchison.me.uk (Andrew C Aitchison) Date: Fri Mar 22 14:17:32 2024 Subject: [Alpine-info] O365 XOAUTH2 via fetchmail In-Reply-To: References: <3abd874-51a8-cb8d-62f2-9cf98d2b7fe6@gmail.com> <83544857-15d1-67f3-8576-0738e6d3949a@yandex.com> Message-ID: On Wed, 20 Apr 2022, Carlos E. R. wrote: > He says that the real thing about oauth2 is that it permits Google to track > us. Google gets to know which application you are using to read email each > time, and in which computer. > > This is possibly true. Fits as well with having to use 2FA/2SV and > associating the account with a phone number. IIRC Google detect new combinations of (user, app, device, location) to stop use of phished passwords and other malicious logins, so this could be a legitimate security concern rather than just a complusion to grab data. -- Andrew C. Aitchison Kendal, UK andrew@aitchison.me.uk From alpine.chappa at yandex.com Wed Apr 20 17:49:25 2022 From: alpine.chappa at yandex.com (Eduardo Chappa) Date: Fri Mar 22 14:17:32 2024 Subject: [Alpine-info] O365 XOAUTH2 via fetchmail In-Reply-To: <1fb24b7-c548-1358-bf9-59b574bd4ae@gmail.com> References: <1fb24b7-c548-1358-bf9-59b574bd4ae@gmail.com> Message-ID: <3b21b893-ad70-48af-f0fa-4a2b0f00561e@yandex.com> On Wed, 20 Apr 2022, dan d. wrote: > Eduardo, thank you for the effort you make to ensure alpine works well > for all, especially as a screen reader user. Your discussion is well > above my understanding of email transfer openness and security. My > concern is what happns to alpine users come may when gmail restricts > access? What must users such as myself do to prepare for it? Dan, I will be happy to help you set up xoauth2 with gmail now so that you can move to it without problems. Contact me off-list and I will assist you with it. Same offer goes to anyone who needs help. -- Eduardo From alpine.chappa at yandex.com Wed Apr 20 18:05:03 2022 From: alpine.chappa at yandex.com (Eduardo Chappa) Date: Fri Mar 22 14:17:32 2024 Subject: [Alpine-info] O365 XOAUTH2 via fetchmail In-Reply-To: <2e5b40cc-a2ec-d59d-51f9-3f5ca2a5e33@aitchison.me.uk> References: <3abd874-51a8-cb8d-62f2-9cf98d2b7fe6@gmail.com> <83544857-15d1-67f3-8576-0738e6d3949a@yandex.com> <2e5b40cc-a2ec-d59d-51f9-3f5ca2a5e33@aitchison.me.uk> Message-ID: On Wed, 20 Apr 2022, Andrew C Aitchison wrote: > OAUTH2 support has been has been in the contrib section of fetchmail 7 > for at least 4 years. On Saturday (16 April 2022) Matthias Andree, the > fetchmail maintainer, wrote > https://sourceforge.net/p/fetchmail/mailman/fetchmail-users/?viewmonth=202204&viewday=16 > > So if the abomination of hundreds of pages of a "standard" just for > authentication by itself does NOT suffice to implement OAuth2, then > we should probably leave it out and remove the experimental bits that > are in fetchmail's code before a release, even from contrib, and > replace them with a document README.OAuth2 that starts with "why does > fetchmail not implement OAuth2". > > Or else somebody show me to a mail service that is not just some SOHO > site and that *does* implement OAuth2 without requiring jumping > through arbitrary hoops and showing dressage tricks or play sit up > and beg or something, then we can implement it and document "why you > cannot use OAuth2 with Google" instead. > > so I fear that the reluctance to support OAUTH2 has not gone away :-( This worries me because fetchmail, mutt, alpine, etc. are all in the same boat. Our survival partly depends on the existence of our competitors, because having a mutt user access a server tells administrators to take care of a need that later might come from an Alpine user, and so having a bunch of programs that need access to user data, that respect privacy and security helps all of us. In addition, we (mutt, fetchmail, alpine, etc.) all have to move to modernize our clients, and this is one of the ways in which we have to do it. There are other steps that need to be taken to modernize Alpine that need to be done, which will come later. I accept that IMAP and SMTP access will be gone from some of my accounts but I still need access to that data through Alpine, so lots of work still remains to be done for that to happen and what I hope is that other clients (mutt, fetchmail, etc.) will do the same. Alpine has a robust library to access remote mailboxes and lacks support for some modern access methods. I am working on bringing those to Alpine too, and I hope people will realize that we might have to leave IMAP and SMTP behind some day too, and that that's okay, because we will still have everything we had in the past without these protocols. We are not there yet. We still live in the world of IMAP and SMTP, but it is starting to go away with companies like Google and Microsoft pushing their products and methods and restricting access to their services to competitors like Alpine for reasons of privacy and security concerns. We have to be ready and we will be ready. We will get there, and I hope that other developers like those of Mutt and Fetchmail realize about this now so we can all continue coexisting when the world (or Google and Microsoft) have turned the page on IMAP and SMTP and they do not support these protocols anymore. -- Eduardo From robin.listas at telefonica.net Thu Apr 21 04:15:35 2022 From: robin.listas at telefonica.net (Carlos E. R.) Date: Fri Mar 22 14:17:32 2024 Subject: [Alpine-info] O365 XOAUTH2 via fetchmail In-Reply-To: References: <3abd874-51a8-cb8d-62f2-9cf98d2b7fe6@gmail.com> <83544857-15d1-67f3-8576-0738e6d3949a@yandex.com> Message-ID: <3b3daf2e-5ca4-d354-73d1-c707131d95e5@telefonica.net> On 2022-04-20 12:59, Carl Edquist wrote: > Hi Eduardo, > > Thanks a bunch for taking the time to give a thoughtful reply! ... > (The fetchmail daemon also prompts for a password on startup, but this > is once per process lifetime, which equates to once per system boot.) > > I had tried out another approach - to make two separate alpine configs. > The first one with a rule to move mail on arrival from an IMAP inbox to > a local spool mbox file.? The idea is this would sit open as some kind > of an, um, foreground daemon that does what i was used to getting out of > fetchmail.? This could even sit inside a screen(1) session or something. > Then a second config that would not use IMAP at all (and not need any > password), which would use the local spool mbox as my inbox.? This would > be the one i'd use for normal alpine driving (reading, composing, etc), > and i could open up as many of these as i like in separate windows. > > The main trouble with this approach (besides it feeling a little clunky, > the fetching instance needing to live in a separate pty somewhere), is > if the instance connected to IMAP doing the fetching gets a [MAIL FOLDER > "INBOX" CLOSED DUE TO ACCESS ERROR], i'm afraid it might get stuck there > unnoticed, waiting for user input before it attempts to reconnect.? On > the other hand, fetchmail polls in a loop, so transient failures don't > really cause any noticeable problems. > > I'd be open to suggestions if anyone has a better way to accomplish this > in alpine. > > ... > > Jason, thanks also for the tip about OfflineIMAP, and the links.? It > looks like it might be promising, except that for the time being i am > mostly just interested in output to an mbox file, which does not look to > be supported or planned: imapsync, which I mentioned in another post, doesn't care. It syncs between imap servers, so in my case, one remote, one local using dovecot; and my dovecot writes to mbox. It could be set as a cron job. Of course, if you are not already using a local imap server it is an extra complication. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar) -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 209 bytes Desc: OpenPGP digital signature URL: From dsewell at virginia.edu Thu Apr 21 05:23:28 2022 From: dsewell at virginia.edu (Sewell, David R (drs2n)) Date: Fri Mar 22 14:17:32 2024 Subject: [Alpine-info] O365 XOAUTH2 via fetchmail In-Reply-To: References: <3abd874-51a8-cb8d-62f2-9cf98d2b7fe6@gmail.com> <83544857-15d1-67f3-8576-0738e6d3949a@yandex.com> <2e5b40cc-a2ec-d59d-51f9-3f5ca2a5e33@aitchison.me.uk> Message-ID: I hadn't been paying close enough attention to the list to realize that I could now get Alpine to work with my university's Exchange server. So I followed the instructions, got the token for Microsoft, successfully authenticated?and hit a window saying "Administrator approval required" with a form for me to submit a justification for allowing Alpine to access my account. So I guess someone somewhere in my university's IT division might or might be getting a request and might or might not do anything about it. Just when the technical hurdle is solved, a social/political hurdle crops up. I'll file a help desk ticket in a few days if I don't hear anything and maybe let the list know how it goes?in particular, if the request is denied and what the reasoning might be in that case. David S. -- David Sewell Manager of Digital Initiatives and the Rotunda Imprint The University of Virginia Press Email: dsewell@virginia.edu Tel: +1 434 924 9973 From: Alpine-info on behalf of Eduardo Chappa Date: Wednesday, April 20, 2022 at 9:06 PM To: Andrew C Aitchison , "alpine-info@u.washington.edu" Subject: Re: [Alpine-info] O365 XOAUTH2 via fetchmail On Wed, 20 Apr 2022, Andrew C Aitchison wrote: OAUTH2 support has been has been in the contrib section of fetchmail 7 for at least 4 years. On Saturday (16 April 2022) Matthias Andree, the fetchmail maintainer, wrote https://sourceforge.net/p/fetchmail/mailman/fetchmail-users/?viewmonth=202204&viewday=16 So if the abomination of hundreds of pages of a "standard" just for authentication by itself does NOT suffice to implement OAuth2, then we should probably leave it out and remove the experimental bits that are in fetchmail's code before a release, even from contrib, and replace them with a document README.OAuth2 that starts with "why does fetchmail not implement OAuth2". Or else somebody show me to a mail service that is not just some SOHO site and that *does* implement OAuth2 without requiring jumping through arbitrary hoops and showing dressage tricks or play sit up and beg or something, then we can implement it and document "why you cannot use OAuth2 with Google" instead. so I fear that the reluctance to support OAUTH2 has not gone away :-( This worries me because fetchmail, mutt, alpine, etc. are all in the same boat. Our survival partly depends on the existence of our competitors, because having a mutt user access a server tells administrators to take care of a need that later might come from an Alpine user, and so having a bunch of programs that need access to user data, that respect privacy and security helps all of us. In addition, we (mutt, fetchmail, alpine, etc.) all have to move to modernize our clients, and this is one of the ways in which we have to do it. There are other steps that need to be taken to modernize Alpine that need to be done, which will come later. I accept that IMAP and SMTP access will be gone from some of my accounts but I still need access to that data through Alpine, so lots of work still remains to be done for that to happen and what I hope is that other clients (mutt, fetchmail, etc.) will do the same. Alpine has a robust library to access remote mailboxes and lacks support for some modern access methods. I am working on bringing those to Alpine too, and I hope people will realize that we might have to leave IMAP and SMTP behind some day too, and that that's okay, because we will still have everything we had in the past without these protocols. We are not there yet. We still live in the world of IMAP and SMTP, but it is starting to go away with companies like Google and Microsoft pushing their products and methods and restricting access to their services to competitors like Alpine for reasons of privacy and security concerns. We have to be ready and we will be ready. We will get there, and I hope that other developers like those of Mutt and Fetchmail realize about this now so we can all continue coexisting when the world (or Google and Microsoft) have turned the page on IMAP and SMTP and they do not support these protocols anymore. -- Eduardo _______________________________________________ Alpine-info mailing list Alpine-info@u.washington.edu http://mailman12.u.washington.edu/mailman/listinfo/alpine-info -------------- next part -------------- An HTML attachment was scrubbed... URL: From gatetman at gmail.com Thu Apr 21 05:31:01 2022 From: gatetman at gmail.com (Carl Edquist) Date: Fri Mar 22 14:17:32 2024 Subject: [Alpine-info] O365 XOAUTH2 via fetchmail In-Reply-To: <3b3daf2e-5ca4-d354-73d1-c707131d95e5@telefonica.net> References: <3abd874-51a8-cb8d-62f2-9cf98d2b7fe6@gmail.com> <83544857-15d1-67f3-8576-0738e6d3949a@yandex.com> <3b3daf2e-5ca4-d354-73d1-c707131d95e5@telefonica.net> Message-ID: <8fbf9b20-3480-f7ac-7c6f-edab7bd68979@gmail.com> On Thu, 21 Apr 2022, Carlos E. R. wrote: > imapsync, which I mentioned in another post, doesn't care. It syncs > between imap servers, so in my case, one remote, one local using > dovecot; and my dovecot writes to mbox. > > It could be set as a cron job. > > Of course, if you are not already using a local imap server it is an > extra complication. Thanks again for mentioning this - at some point i may try that out if i get around to setting up dovcot locally. Yeah, while i find the idea of running a local mail server (like dovcot) kind of interesting (and in particular with things like indexed full-text search), i have kind of come full circle and, for the time being anyway, it strikes me that nothing beats the delightfully-retro simplicity of a mailbox just being a file on your filesystem. Mail gets delivered by fetchmail (or whatever) to /var/mail/$USER; you read and compose mail in alpine; and alpine (or your scripts) send it via sendmail. Maybe it's just nostalgia talking, but most of the time i feel like the modern email experience hasn't really improved on the classic model. I get that the idea of IMAP and getting to "leave your mail on the server" is seductively convenient, compared to owning and managing your own data (especially if you want to access it from multiple devices), but then again this probably explains why gmail got to be so big. ... And to follow up on a comment Eduardo made, I do hope that even if the giant corporations manage to exile IMAP and SMTP from their fortresses, these classic protocols will still enjoy a good, long, free life in the wilderness of the borderlands, among their fellow average-sized programs. [insert watercolor painting of early-morning wildlife in the forrest] Carl From gatetman at gmail.com Thu Apr 21 05:37:13 2022 From: gatetman at gmail.com (Carl Edquist) Date: Fri Mar 22 14:17:32 2024 Subject: [Alpine-info] O365 XOAUTH2 via fetchmail In-Reply-To: References: <3abd874-51a8-cb8d-62f2-9cf98d2b7fe6@gmail.com> <83544857-15d1-67f3-8576-0738e6d3949a@yandex.com> <2e5b40cc-a2ec-d59d-51f9-3f5ca2a5e33@aitchison.me.uk> Message-ID: On Thu, 21 Apr 2022, Sewell, David R (drs2n) wrote: > I hadn't been paying close enough attention to the list to realize that > I could now get Alpine to work with my university's Exchange server. So > I followed the instructions, got the token for Microsoft, successfully > authenticated?and hit a window saying "Administrator approval required" > with a form for me to submit a justification for allowing Alpine to > access my account. So I guess someone somewhere in my university's IT > division might or might be getting a request and might or might not do > anything about it. Just when the technical hurdle is solved, a > social/political hurdle crops up. :( > I'll file a help desk ticket in a few days if I don't hear anything and > maybe let the list know how it goes?in particular, if the request is > denied and what the reasoning might be in that case. If they give you trouble, perhaps you can get a "doctor's note" from the maintainer... Carl From robin.listas at telefonica.net Thu Apr 21 05:56:11 2022 From: robin.listas at telefonica.net (Carlos E. R.) Date: Fri Mar 22 14:17:32 2024 Subject: [Alpine-info] O365 XOAUTH2 via fetchmail In-Reply-To: <8fbf9b20-3480-f7ac-7c6f-edab7bd68979@gmail.com> References: <3abd874-51a8-cb8d-62f2-9cf98d2b7fe6@gmail.com> <83544857-15d1-67f3-8576-0738e6d3949a@yandex.com> <3b3daf2e-5ca4-d354-73d1-c707131d95e5@telefonica.net> <8fbf9b20-3480-f7ac-7c6f-edab7bd68979@gmail.com> Message-ID: <90685622-61b2-5b95-06d2-6d0b30a86a00@telefonica.net> On 2022-04-21 14:31, Carl Edquist wrote: > On Thu, 21 Apr 2022, Carlos E. R. wrote: > >> imapsync, which I mentioned in another post, doesn't care. It syncs >> between imap servers, so in my case, one remote, one local using >> dovecot; and my dovecot writes to mbox. >> >> It could be set as a cron job. >> >> Of course, if you are not already using a local imap server it is an >> extra complication. > > Thanks again for mentioning this - at some point i may try that out if i > get around to setting up dovcot locally. > > Yeah, while i find the idea of running a local mail server (like dovcot) > kind of interesting (and in particular with things like indexed > full-text search), i have kind of come full circle and, for the time > being anyway, it strikes me that nothing beats the delightfully-retro > simplicity of a mailbox just being a file on your filesystem.? Mail gets > delivered by fetchmail (or whatever) to /var/mail/$USER; you read and > compose mail in alpine; and alpine (or your scripts) send it via sendmail. Yes, that is (was) my setup. fetchmail + spamassassin + amavis + clamav + procmail delivering to mbox folders. Then at some point I added dovecot (because the imap package from Mark Crispin became unavailable on openSUSE). Dovecot simply uses the existing mbox files and serves them over imap. I can still use fetchmail (and I did for many months), or move email between imap servers using alpine, imapsync, thunderbird, whatever. This actually simplified my setup, in which I can access my local folders both in Alpine and Thunderbird (this email is being composed in the later). It can be done without a local imap server, but that has its own complications (thunderbird does not see a plain mbox file till you add empty indexes). What I don't have currently is dovecot search. > Maybe it's just nostalgia talking, but most of the time i feel like the > modern email experience hasn't really improved on the classic model. > > I get that the idea of IMAP and getting to "leave your mail on the > server" is seductively convenient, compared to owning and managing your > own data (especially if you want to access it from multiple devices), > but then again this probably explains why gmail got to be so big. Yes, the thing is I use several machines. Imap simplfies things. > > ... > > And to follow up on a comment Eduardo made, I do hope that even if the > giant corporations manage to exile IMAP and SMTP from their fortresses, > these classic protocols will still enjoy a good, long, free life in the > wilderness of the borderlands, among their fellow average-sized programs. I hope imap lives forever. I have accounts using plain imap, like telefonica or gmx. And I am using gmail via imap + application passwords, I have not tried oauth in Alpine. > [insert watercolor painting of early-morning wildlife in the forrest] :-) -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar) -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 209 bytes Desc: OpenPGP digital signature URL: From alpine.chappa at yandex.com Thu Apr 21 07:43:56 2022 From: alpine.chappa at yandex.com (Eduardo Chappa) Date: Fri Mar 22 14:17:32 2024 Subject: [Alpine-info] O365 XOAUTH2 via fetchmail In-Reply-To: References: <3abd874-51a8-cb8d-62f2-9cf98d2b7fe6@gmail.com> <83544857-15d1-67f3-8576-0738e6d3949a@yandex.com> <2e5b40cc-a2ec-d59d-51f9-3f5ca2a5e33@aitchison.me.uk> Message-ID: <81d2c904-b562-5a1b-cf70-18d10bbd232a@yandex.com> On Thu, 21 Apr 2022, Carl Edquist wrote: > If they give you trouble, perhaps you can get a "doctor's note" from the > maintainer... The main problem might be ignorance (not intentional) from the administrator of the server. For them "Alpine" might sound like "Aunt Mary's Magic Email Program", hence the fear of the unknown: I cannot trust access to the server to something I have not heard of before. Here are some arguments that can be used to advocate for allowing Alpine access to a server. 1. Alpine respects your privacy: It uses your data only for the purposes intended by the user. This means that it will no access your data unless it needs to and only to accomplish the tasks that the user needs. Alpine does not share any of the information it collects with any other person or entity. The privacy policy is posted at https://alpine.x10host.com/legal/privacy.html 2. Alpine uses XOAUTH2 to login a user to their resources. Alpine does not need to use username/password (which is considered "less" safe) to access a server. If an administrator does not want a user to use username/password it can be disabled from the server side to make sure Alpine users never use their password. 3. Since Alpine supports XOAUTH2, it also supports two-factor authentication. Alpine opens a link to complete the XOAUTH2 authorization stage, and while doing so it can complete two-factor authentication. 4. Alpine does not attempt to access data that it is not allowed to. This means that Alpine will not attempt to access contacts or calendar information that it is not allowed to. The only access that is required to run Alpine is to be able to fully manage email: read, delete, modify and send email. 5. Alpine is already widely deployed across the world. Alpine is distributed by all mayor linux distributions: Ubuntu, Debian, Fedora, Opensuse and many more. Its user basis comes mostly from North America and Europe, and internet searches show that it is used in universities across the world. Here are some links that show administrators at places around the world helping users configure Alpine to access their servers: https://kb.mit.edu/confluence/pages/viewpage.action?pageId=164758928 https://engineering.purdue.edu/ECN/Support/KB/Docs/UsingAlpinewitho365 https://espace.cern.ch/mmmservices-help/AccessingYourMailbox/Alpine/Pages/default.aspx There are many more. 6. The implementation of Alpine using XOAUTH2 has been available for years. This means it has also been tried and tested by many users around the world. If there had been any problems or security concerns with its implementation those problems would already by posted somewhere. The only problems that have been reported for Alpine in the last few years can be seen for example at this page: https://www.cvedetails.com/vulnerability-list/vendor_id-23410/product_id-86426/Alpine-Project-Alpine.html The fact that this page exists shows that Alpine is widely used around the world. 7. The developer of Alpine is active in forums, answers to personal email, takes bug reports seriously and addresses them. If any administrator wishes to contact me directly to address any concerns I am happy to speak to them by any means (email, phone, zoom, etc.) 8. Alpine is in constant development and its code is publicly available and can be found at https://repo.or.cz/alpine.git so anyone can review its code at any time. 9. Users have used Alpine for years and amassed a big amount of email distributed over many folders over years. They have been able to access that email and all information in it with Alpine and losing Alpine access might have a devastating effect over the user. This is particularly troublesome for users that do research in universities across the world that need that access. I hope this helps all of us to talk to administrators and help them see that Alpine is a safe email program. Its interface makes managing email efficient and convenient and that is preferred by many users instead of other more common alternatives that do not match the usage habits of some users of the email service but still makes them efficient workers in their institution. -- Eduardo From dsewell at virginia.edu Thu Apr 21 08:37:04 2022 From: dsewell at virginia.edu (Sewell, David R (drs2n)) Date: Fri Mar 22 14:17:32 2024 Subject: [Alpine-info] O365 XOAUTH2 via fetchmail In-Reply-To: <81d2c904-b562-5a1b-cf70-18d10bbd232a@yandex.com> References: <3abd874-51a8-cb8d-62f2-9cf98d2b7fe6@gmail.com> <83544857-15d1-67f3-8576-0738e6d3949a@yandex.com> <2e5b40cc-a2ec-d59d-51f9-3f5ca2a5e33@aitchison.me.uk> <81d2c904-b562-5a1b-cf70-18d10bbd232a@yandex.com> Message-ID: <51CE0EE8-1ED9-48B3-8F01-8B1D760F3D81@virginia.edu> A very useful summary of Alpine's robustness, thanks! David -- David Sewell Manager of Digital Initiatives and the Rotunda Imprint The University of Virginia Press Email: dsewell@virginia.edu Tel: +1 434 924 9973 From: Alpine-info on behalf of Eduardo Chappa Date: Thursday, April 21, 2022 at 10:46 AM To: Carl Edquist Cc: "alpine-info@u.washington.edu" Subject: Re: [Alpine-info] O365 XOAUTH2 via fetchmail On Thu, 21 Apr 2022, Carl Edquist wrote: If they give you trouble, perhaps you can get a "doctor's note" from the maintainer... The main problem might be ignorance (not intentional) from the administrator of the server. For them "Alpine" might sound like "Aunt Mary's Magic Email Program", hence the fear of the unknown: I cannot trust access to the server to something I have not heard of before. Here are some arguments that can be used to advocate for allowing Alpine access to a server. 1. Alpine respects your privacy: It uses your data only for the purposes intended by the user. This means that it will no access your data unless it needs to and only to accomplish the tasks that the user needs. Alpine does not share any of the information it collects with any other person or entity. The privacy policy is posted at https://alpine.x10host.com/legal/privacy.html 2. Alpine uses XOAUTH2 to login a user to their resources. Alpine does not need to use username/password (which is considered "less" safe) to access a server. If an administrator does not want a user to use username/password it can be disabled from the server side to make sure Alpine users never use their password. 3. Since Alpine supports XOAUTH2, it also supports two-factor authentication. Alpine opens a link to complete the XOAUTH2 authorization stage, and while doing so it can complete two-factor authentication. 4. Alpine does not attempt to access data that it is not allowed to. This means that Alpine will not attempt to access contacts or calendar information that it is not allowed to. The only access that is required to run Alpine is to be able to fully manage email: read, delete, modify and send email. 5. Alpine is already widely deployed across the world. Alpine is distributed by all mayor linux distributions: Ubuntu, Debian, Fedora, Opensuse and many more. Its user basis comes mostly from North America and Europe, and internet searches show that it is used in universities across the world. Here are some links that show administrators at places around the world helping users configure Alpine to access their servers: https://kb.mit.edu/confluence/pages/viewpage.action?pageId=164758928 https://engineering.purdue.edu/ECN/Support/KB/Docs/UsingAlpinewitho365 https://espace.cern.ch/mmmservices-help/AccessingYourMailbox/Alpine/Pages/default.aspx There are many more. 6. The implementation of Alpine using XOAUTH2 has been available for years. This means it has also been tried and tested by many users around the world. If there had been any problems or security concerns with its implementation those problems would already by posted somewhere. The only problems that have been reported for Alpine in the last few years can be seen for example at this page: https://www.cvedetails.com/vulnerability-list/vendor_id-23410/product_id-86426/Alpine-Project-Alpine.html The fact that this page exists shows that Alpine is widely used around the world. 7. The developer of Alpine is active in forums, answers to personal email, takes bug reports seriously and addresses them. If any administrator wishes to contact me directly to address any concerns I am happy to speak to them by any means (email, phone, zoom, etc.) 8. Alpine is in constant development and its code is publicly available and can be found at https://repo.or.cz/alpine.git so anyone can review its code at any time. 9. Users have used Alpine for years and amassed a big amount of email distributed over many folders over years. They have been able to access that email and all information in it with Alpine and losing Alpine access might have a devastating effect over the user. This is particularly troublesome for users that do research in universities across the world that need that access. I hope this helps all of us to talk to administrators and help them see that Alpine is a safe email program. Its interface makes managing email efficient and convenient and that is preferred by many users instead of other more common alternatives that do not match the usage habits of some users of the email service but still makes them efficient workers in their institution. -- Eduardo _______________________________________________ Alpine-info mailing list Alpine-info@u.washington.edu http://mailman12.u.washington.edu/mailman/listinfo/alpine-info -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsiegle at psu.edu Fri Apr 22 12:13:05 2022 From: jsiegle at psu.edu (Jonathan Siegle) Date: Fri Mar 22 14:17:32 2024 Subject: [Alpine-info] O365 XOAUTH2 via fetchmail In-Reply-To: References: <3abd874-51a8-cb8d-62f2-9cf98d2b7fe6@gmail.com> <83544857-15d1-67f3-8576-0738e6d3949a@yandex.com> <2e5b40cc-a2ec-d59d-51f9-3f5ca2a5e33@aitchison.me.uk> Message-ID: <1d8f4ff6-478d-15eb-484d-fe65d083bb26@psu.edu> Yeah, they have to click a few things in portal.azure.com and then it just works. Check out https://engineering.purdue.edu/ECN/Support/KB/Docs/UsingAlpinewitho365 which has a good tip ( touch ~/.pine-passfile ). -Jonathan On 2022-04-21 at 12:23, Sewell, David R (drs2n) wrote: > > I hadn't been paying close enough attention to the list to realize that I could now get Alpine to work with my university's Exchange server. So I followed the instructions, got the token for > Microsoft, successfully authenticated?and hit a window saying "Administrator approval required" with a form for me to submit a justification for allowing Alpine to access my account. So I guess > someone somewhere in my university's IT division might or might be getting a request and might or might not do anything about it. Just when the technical hurdle is solved, a social/political hurdle > crops up. > > ? > > I'll file a help desk ticket in a few days if I don't hear anything and maybe let the list know how it goes?in particular, if the request is denied and what the reasoning might be in that case. > > ? > > David S. > > ? > > --? > > David Sewell > > Manager of Digital Initiatives and the Rotunda Imprint > > The University of Virginia Press > > Email: dsewell@virginia.edu ? Tel: +1 434 924 9973 > > ? > > From: Alpine-info on behalf of Eduardo Chappa > Date: Wednesday, April 20, 2022 at 9:06 PM > To: Andrew C Aitchison , "alpine-info@u.washington.edu" > Subject: Re: [Alpine-info] O365 XOAUTH2 via fetchmail > > ? > > On Wed, 20 Apr 2022, Andrew C Aitchison wrote: > > ? > > OAUTH2 support has been has been in the contrib section of fetchmail 7 > > for at least 4 years. On Saturday (16 April 2022) Matthias Andree, the > > fetchmail maintainer, wrote > > https://sourceforge.net/p/fetchmail/mailman/fetchmail-users/?viewmonth=202204&viewday=16 > > ? > > ????So if the abomination of hundreds of pages of a "standard" just for > > ????authentication by itself does NOT suffice to implement OAuth2, then > > ????we should probably leave it out and remove the experimental bits that > > ????are in fetchmail's code before a release, even from contrib, and > > ????replace them with a document README.OAuth2 that starts with "why does > > ????fetchmail not implement OAuth2". > > ? > > ????Or else somebody show me to a mail service that is not just some SOHO > > ????site and that *does* implement OAuth2 without requiring jumping > > ????through arbitrary hoops and showing dressage tricks or play sit up > > ????and beg or something, then we can implement it and document "why you > > ????cannot use OAuth2 with Google" instead. > > ? > > so I fear that the reluctance to support OAUTH2 has not gone away :-( > > ? > > This worries me because fetchmail, mutt, alpine, etc. are all in the same > > boat. Our survival partly depends on the existence of our competitors, > > because having a mutt user access a server tells administrators to take > > care of a need that later might come from an Alpine user, and so having a > > bunch of programs that need access to user data, that respect privacy and > > security helps all of us. > > ? > > In addition, we (mutt, fetchmail, alpine, etc.) all have to move to > > modernize our clients, and this is one of the ways in which we have to do > > it. There are other steps that need to be taken to modernize Alpine that > > need to be done, which will come later. I accept that IMAP and SMTP access > > will be gone from some of my accounts but I still need access to that data > > through Alpine, so lots of work still remains to be done for that to > > happen and what I hope is that other clients (mutt, fetchmail, etc.) will > > do the same. Alpine has a robust library to access remote mailboxes and > > lacks support for some modern access methods. I am working on bringing > > those to Alpine too, and I hope people will realize that we might have to > > leave IMAP and SMTP behind some day too, and that that's okay, because we > > will still have everything we had in the past without these protocols. > > ? > > We are not there yet. We still live in the world of IMAP and SMTP, but it > > is starting to go away with companies like Google and Microsoft pushing > > their products and methods and restricting access to their services to > > competitors like Alpine for reasons of privacy and security concerns. We > > have to be ready and we will be ready. We will get there, and I hope that > > other developers like those of Mutt and Fetchmail realize about this now > > so we can all continue coexisting when the world (or Google and Microsoft) > > have turned the page on IMAP and SMTP and they do not support these > > protocols anymore. > > ? > > -- > > Eduardo > > _______________________________________________ > > Alpine-info mailing list > > Alpine-info@u.washington.edu > > http://mailman12.u.washington.edu/mailman/listinfo/alpine-info > > ? > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5032 bytes Desc: S/MIME Cryptographic Signature URL: From rvi at sci.fi Sun Apr 24 09:56:01 2022 From: rvi at sci.fi (Riku Virtanen) Date: Fri Mar 22 14:17:32 2024 Subject: [Alpine-info] Advice needed: what SMTP server would work? Message-ID: <918890ef-24bc-e6e4-1371-bf3ca3f858f@sci.fi> Hi all, I have an issue with SMTP server and log in requirement. Currently, my smtp setting is smtp.gmail.com/ssl/user=myusername@gmail.com/auth=xoauth2 Every time I log into a new wifi network, in a hotel, in train etc, I have to open a Internet browser and log into gmail, or I cannot send my emails via Alpine. This (log in process) is a problem when I normally use only command line prompt, and the log into Gmail need to do in startx. Is there any free email provider with smtp support which works without such log in requirement? Regards, Riku From alpine.chappa at yandex.com Sun Apr 24 11:03:09 2022 From: alpine.chappa at yandex.com (Eduardo Chappa) Date: Fri Mar 22 14:17:32 2024 Subject: [Alpine-info] Advice needed: what SMTP server would work? In-Reply-To: <918890ef-24bc-e6e4-1371-bf3ca3f858f@sci.fi> References: <918890ef-24bc-e6e4-1371-bf3ca3f858f@sci.fi> Message-ID: <281bcaed-fe1c-43a2-57ec-45889717a18a@yandex.com> On Sun, 24 Apr 2022, Riku Virtanen wrote: > Every time I log into a new wifi network, in a hotel, in train etc, I > have to open a Internet browser and log into gmail, or I cannot send my > emails via Alpine. This (log in process) is a problem when I normally > use only command line prompt, and the log into Gmail need to do in > startx. > > Is there any free email provider with smtp support which works without > such log in requirement? I use GMX, and it has never asked me to login to their servers to allow me to send email, regardless of where I have been in the world. -- Eduardo From bret.busby at gmail.com Sun Apr 24 11:08:29 2022 From: bret.busby at gmail.com (Bret Busby) Date: Fri Mar 22 14:17:32 2024 Subject: [Alpine-info] Advice needed: what SMTP server would work? In-Reply-To: <918890ef-24bc-e6e4-1371-bf3ca3f858f@sci.fi> References: <918890ef-24bc-e6e4-1371-bf3ca3f858f@sci.fi> Message-ID: On 25/04/2022, Riku Virtanen wrote: > Hi all, > > I have an issue with SMTP server and log in requirement. > > Currently, my smtp setting is > smtp.gmail.com/ssl/user=myusername@gmail.com/auth=xoauth2 > > Every time I log into a new wifi network, in a hotel, in train etc, I have > to > open a Internet browser and log into gmail, or I cannot send my emails via > Alpine. This (log in process) is a problem when I normally use only command > line > prompt, and the log into Gmail need to do in startx. > > Is there any free email provider with smtp support which works without such > log > in requirement? > > Regards, > Riku > > You have posted to the list, from an email address. So, you already have access to an SMTP server. If you want/need an additional email address, depending on the service provider, registering a gTLD domain name, apparently involves, for 10-15USD (the annual cost of the domain name registration, provision and hosting of a single email address. It might not be free of charge, but, 10-15USD is not an expensive annual fee for an email account. -- Bret Busby Armadale West Australia (UTC+0800) .............. From robin.listas at telefonica.net Sun Apr 24 11:55:06 2022 From: robin.listas at telefonica.net (Carlos E. R.) Date: Fri Mar 22 14:17:32 2024 Subject: [Alpine-info] Advice needed: what SMTP server would work? In-Reply-To: <918890ef-24bc-e6e4-1371-bf3ca3f858f@sci.fi> References: <918890ef-24bc-e6e4-1371-bf3ca3f858f@sci.fi> Message-ID: On 2022-04-24 18:56, Riku Virtanen wrote: > Hi all, > > I have an issue with SMTP server and log in requirement. > > Currently, my smtp setting is > smtp.gmail.com/ssl/user=myusername@gmail.com/auth=xoauth2 > > Every time I log into a new wifi network, in a hotel, in train etc, I > have to > open a Internet browser and log into gmail, or I cannot send my emails via > Alpine. This (log in process) is a problem when I normally use only > command line > prompt, and the log into Gmail need to do in startx. Yes, gmail did that to me. They stopped when I activated 2FA in the gmail account, and consequently started using application passwords. This needs you configuring a phone to which they can send SMS messages for confirmation as second factor. > > Is there any free email provider with smtp support which works without > such log in requirement? gmx. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3) From gatetman at gmail.com Tue Apr 26 17:09:57 2022 From: gatetman at gmail.com (Carl Edquist) Date: Fri Mar 22 14:17:32 2024 Subject: [Alpine-info] Advice needed: what SMTP server would work? In-Reply-To: <918890ef-24bc-e6e4-1371-bf3ca3f858f@sci.fi> References: <918890ef-24bc-e6e4-1371-bf3ca3f858f@sci.fi> Message-ID: <2ab2e086-d75e-3f18-add1-29f313a621a2@gmail.com> On Sun, 24 Apr 2022, Riku Virtanen wrote: > Hi all, > > I have an issue with SMTP server and log in requirement. > > Currently, my smtp setting is > smtp.gmail.com/ssl/user=myusername@gmail.com/auth=xoauth2 > > Every time I log into a new wifi network, in a hotel, in train etc, I > have to open a Internet browser and log into gmail, or I cannot send my > emails via Alpine. This (log in process) is a problem when I normally > use only command line prompt, and the log into Gmail need to do in > startx. Apart from the (probably better) solution of finding another email provider; you can get around this with a VPN, which can give you a predictable public IP address despite connecting from wherever. Also, if you happen to have ssh access to a server somewhere with a stable IP address, you could shell in and run alpine from there. Maybe not ideal, but i think each of these will avoid the extra web login. Carl > Is there any free email provider with smtp support which works without > such log in requirement? > > Regards, > Riku > > > _______________________________________________ > Alpine-info mailing list > Alpine-info@u.washington.edu > http://mailman12.u.washington.edu/mailman/listinfo/alpine-info > From andrew at aitchison.me.uk Wed Apr 27 00:38:35 2022 From: andrew at aitchison.me.uk (Andrew C Aitchison) Date: Fri Mar 22 14:17:32 2024 Subject: [Alpine-info] Advice needed: what SMTP server would work? In-Reply-To: <918890ef-24bc-e6e4-1371-bf3ca3f858f@sci.fi> References: <918890ef-24bc-e6e4-1371-bf3ca3f858f@sci.fi> Message-ID: On Sun, 24 Apr 2022, Riku Virtanen wrote: > Hi all, > > I have an issue with SMTP server and log in requirement. > > Currently, my smtp setting is > smtp.gmail.com/ssl/user=myusername@gmail.com/auth=xoauth2 > > Every time I log into a new wifi network, in a hotel, in train etc, I have to > open a Internet browser and log into gmail, or I cannot send my emails via > Alpine. This (log in process) is a problem when I normally use only command > line prompt, and the log into Gmail need to do in startx. startx ? Can you not do the gmail login with lynx and then access mail with alpine ? -- Andrew C. Aitchison Kendal, UK andrew@aitchison.me.uk From slitt at troubleshooters.com Wed Apr 27 12:21:08 2022 From: slitt at troubleshooters.com (Steve Litt) Date: Fri Mar 22 14:17:32 2024 Subject: [Alpine-info] O365 XOAUTH2 via fetchmail In-Reply-To: <90685622-61b2-5b95-06d2-6d0b30a86a00@telefonica.net> References: <3abd874-51a8-cb8d-62f2-9cf98d2b7fe6@gmail.com> <83544857-15d1-67f3-8576-0738e6d3949a@yandex.com> <3b3daf2e-5ca4-d354-73d1-c707131d95e5@telefonica.net> <8fbf9b20-3480-f7ac-7c6f-edab7bd68979@gmail.com> <90685622-61b2-5b95-06d2-6d0b30a86a00@telefonica.net> Message-ID: <20220427152108.65cd1d9a@mydesk.domain.cxm> Carlos E. R. said on Thu, 21 Apr 2022 14:56:11 +0200 >On 2022-04-21 14:31, Carl Edquist wrote: >> On Thu, 21 Apr 2022, Carlos E. R. wrote: >> >>> imapsync, which I mentioned in another post, doesn't care. It syncs >>> between imap servers, so in my case, one remote, one local using >>> dovecot; and my dovecot writes to mbox. >>> >>> It could be set as a cron job. >>> >>> Of course, if you are not already using a local imap server it is >>> an extra complication. >> >> Thanks again for mentioning this - at some point i may try that out >> if i get around to setting up dovcot locally. I've been using a local Dovecot IMAP with Maildir storage for eight years now, and it's been wonderful. I store my downloaded emails in Dovecot, not in my email client. >> >> Yeah, while i find the idea of running a local mail server (like >> dovcot) kind of interesting (and in particular with things like >> indexed full-text search), i have kind of come full circle and, for >> the time being anyway, it strikes me that nothing beats the >> delightfully-retro simplicity of a mailbox just being a file on your >> filesystem.? I would agree with the preceding except for one thing: All email clients suck, and you never know when you're going to have to change email clients. Different email clients use different kinds of files (maildir, mh, and the various variants of mbox), so changing email clients becomes a big todo. With my email safely stored in Dovecot, I can use any email client that can access IMAP. I'm thinking of switching to Alpine. >>Mail gets delivered by fetchmail (or whatever) to >> /var/mail/$USER; you read and compose mail in alpine; and alpine (or >> your scripts) send it via sendmail. > > >Yes, that is (was) my setup. fetchmail + spamassassin + amavis + >clamav >+ procmail delivering to mbox folders. > >Then at some point I added dovecot (because the imap package from Mark >Crispin became unavailable on openSUSE). Dovecot simply uses the >existing mbox files and serves them over imap. I can still use >fetchmail (and I did for many months), or move email between imap >servers using alpine, imapsync, thunderbird, whatever. This is another benefit of a local IMAP server. >This actually simplified my setup, in which I can access my local >folders both in Alpine and Thunderbird (this email is being composed >in the later). It can be done without a local imap server, but that >has its own complications (thunderbird does not see a plain mbox file >till you add empty indexes). > >What I don't have currently is dovecot search. I wonder if this would work for you: https://wiki2.dovecot.org/Tools/Doveadm/SearchQuery >> Maybe it's just nostalgia talking, but most of the time i feel like >> the modern email experience hasn't really improved on the classic >> model. :-) Now what's not to like about DKIM, DMARC, OATH2, and all that other stuff designed to make email inconvenient so people will switch to facebook? >> >> I get that the idea of IMAP and getting to "leave your mail on the >> server" is seductively convenient, compared to owning and managing >> your own data (especially if you want to access it from multiple >> devices), but then again this probably explains why gmail got to be >> so big. By running my own local Dovecot IMAP server locally, leaving the stuff on the server really is convenient. I like having my 20+ years of emails not depending on which email client I happen to use. > > >Yes, the thing is I use several machines. Imap simplfies things. > >> >> ... >> >> And to follow up on a comment Eduardo made, I do hope that even if >> the giant corporations manage to exile IMAP and SMTP from their >> fortresses, these classic protocols will still enjoy a good, long, >> free life in the wilderness of the borderlands, among their fellow >> average-sized programs. I hope so too. > >I hope imap lives forever. Me too. SteveT Steve Litt March 2022 featured book: Making Mental Models: Advanced Edition http://www.troubleshooters.com/mmm From robin.listas at telefonica.net Wed Apr 27 14:41:00 2022 From: robin.listas at telefonica.net (Carlos E. R.) Date: Fri Mar 22 14:17:32 2024 Subject: [Alpine-info] O365 XOAUTH2 via fetchmail In-Reply-To: <20220427152108.65cd1d9a@mydesk.domain.cxm> References: <3abd874-51a8-cb8d-62f2-9cf98d2b7fe6@gmail.com> <83544857-15d1-67f3-8576-0738e6d3949a@yandex.com> <3b3daf2e-5ca4-d354-73d1-c707131d95e5@telefonica.net> <8fbf9b20-3480-f7ac-7c6f-edab7bd68979@gmail.com> <90685622-61b2-5b95-06d2-6d0b30a86a00@telefonica.net> <20220427152108.65cd1d9a@mydesk.domain.cxm> Message-ID: <6c7fb3b8-4cca-3ff5-36d3-0d9dcc8729f6@telefonica.net> On 2022-04-27 21:21, Steve Litt wrote: > Carlos E. R. said on Thu, 21 Apr 2022 14:56:11 +0200 >> On 2022-04-21 14:31, Carl Edquist wrote: >>> On Thu, 21 Apr 2022, Carlos E. R. wrote: >>> >>> Yeah, while i find the idea of running a local mail server (like >>> dovcot) kind of interesting (and in particular with things like >>> indexed full-text search), i have kind of come full circle and, for >>> the time being anyway, it strikes me that nothing beats the >>> delightfully-retro simplicity of a mailbox just being a file on your >>> filesystem. > > I would agree with the preceding except for one thing: All email > clients suck, and you never know when you're going to have to change > email clients. Different email clients use different kinds of files > (maildir, mh, and the various variants of mbox), so changing email > clients becomes a big todo. With my email safely stored in Dovecot, I > can use any email client that can access IMAP. I'm thinking of > switching to Alpine. Both Alpine and Thunderbird use the same mbox format, actually they can share the same file (better not at the same time). With a caveat: if the mbox file is, for example, "thisname" thundebird also needs "thisname.msf", which can be created empty. If it is a directory, it has to be named "thisname.bsd" (compatible with having the files "thisname" and "thisname.msf". This can be done by having Alpine looking at directory "~/Mail", and inside having symlinks to ~/.thunderbird/somewhere/thisname" (or the other way round), which becomes quite complicated to maintain once you have a dozen folders. I did this for several years. In the end, using a local imap server is way simpler ;-) However, as my dovecot uses mbox files, I can look at the mail store directly, with Alpine, bypassing dovecot, which has allowed me to repair corruptions. > >>> Mail gets delivered by fetchmail (or whatever) to >>> /var/mail/$USER; you read and compose mail in alpine; and alpine (or >>> your scripts) send it via sendmail. >> >> >> Yes, that is (was) my setup. fetchmail + spamassassin + amavis + >> clamav >> + procmail delivering to mbox folders. >> >> Then at some point I added dovecot (because the imap package from Mark >> Crispin became unavailable on openSUSE). Dovecot simply uses the >> existing mbox files and serves them over imap. I can still use >> fetchmail (and I did for many months), or move email between imap >> servers using alpine, imapsync, thunderbird, whatever. > > This is another benefit of a local IMAP server. > >> This actually simplified my setup, in which I can access my local >> folders both in Alpine and Thunderbird (this email is being composed >> in the later). It can be done without a local imap server, but that >> has its own complications (thunderbird does not see a plain mbox file >> till you add empty indexes). >> >> What I don't have currently is dovecot search. > > I wonder if this would work for you: > https://wiki2.dovecot.org/Tools/Doveadm/SearchQuery I'll have a look, thanks. ... -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar) -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 209 bytes Desc: OpenPGP digital signature URL: From lucio at lambrate.inaf.it Thu Apr 28 14:22:19 2022 From: lucio at lambrate.inaf.it (Lucio Chiappetti) Date: Fri Mar 22 14:17:32 2024 Subject: [Alpine-info] O365 XOAUTH2 via fetchmail In-Reply-To: <20220427152108.65cd1d9a@mydesk.domain.cxm> References: <20220427152108.65cd1d9a@mydesk.domain.cxm> Message-ID: On Wed, 27 Apr 2022, Steve Litt wrote: > I would agree with the preceding except for one thing: All email clients > suck, and you never know when you're going to have to change email > clients. "not all but most of them" (this is a pun in Italian "tutti no ma buona parte", attributed as a reply of cardinal Caprara to Napoleon, when the latter asked whether all Italians are thieves. "ma buona parte" sounds the same as "ma Buonaparte" ... and Napoleon was born in Corsica when this was under Genua, and he had stolen a lot of masterpieces). I had to change my email client only once, long ago, from IBM Rice Mailer to Alpine (from pre-Internet to SMTP) and was satisfied with both (unlike past and present alternatives). I see no reason to change unless the way mail is *delivered* changes. >> Yes, that is (was) my setup. fetchmail + spamassassin + amavis + clamav >> + procmail delivering to mbox folders. I had for some time SMTP + spamassassin + amavis + procmail on my machine (I doubt I have ever had clamav on MY machine), then we had SMTP + spamassassin + amavis + clamav (yes) on the institute server, and I retained SMTP + procmail on my machine (where I have also an IMAP which I seldom use). Then my institution moved to Gsuite so I now use fetchmail + procmail. Always delivering to mbox folders. (Incidentally Gsuite antispam has much more false positives than our old spamassassin) >> Then at some point I added dovecot (because the imap package from Mark >> Crispin became unavailable on openSUSE). One can compile Crispin's imap from the source distributed with Alpine, that's what I did on openSUSE at the institute. > :-) Now what's not to like about DKIM, DMARC, OATH2, and all that other > stuff designed to make email inconvenient so people will switch to > facebook? Not in my name :-( (or No pasaran!) If the institute Gsuite (which is currently my main e-mail feed, via ssh from home) moves to OATH2 forbidding fetchmail AND imap, I'll guess I'd move at least my private mail to some other provider, and forward the official one to it. I would also not be displeased with running my own SMTP/MX at home, if I'd understand how to get a static IP instead of a CGNAT DHCP to get a domain of my own. > I like having my 20+ years of emails not depending on which email client > I happen to use. I have stuff since 2003 online (locally) in mbox folders, from 1993 on CDs in mbox, and earlier in IBM 'NOTEBOOOK' format (also plain text ... converted from EBCDIC to ASCII long ago :-) >> I hope imap lives forever. > Me too. +1, and alpine too -- Lucio Chiappetti - INAF/IASF - via Corti 12 - 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 Thu Apr 28 17:36:46 2022 From: robin.listas at telefonica.net (Carlos E. R.) Date: Fri Mar 22 14:17:32 2024 Subject: [Alpine-info] O365 XOAUTH2 via fetchmail In-Reply-To: References: <20220427152108.65cd1d9a@mydesk.domain.cxm> Message-ID: <500244c8-054b-4aec-d830-648ee341c484@telefonica.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2022-04-28 at 23:22 +0200, Lucio Chiappetti wrote: > On Wed, 27 Apr 2022, Steve Litt wrote: > >> I would agree with the preceding except for one thing: All email clients >> suck, and you never know when you're going to have to change email >> clients. > > "not all but most of them" (this is a pun in Italian "tutti no ma buona > parte", attributed as a reply of cardinal Caprara to Napoleon, when the > latter asked whether all Italians are thieves. "ma buona parte" sounds the > same as "ma Buonaparte" ... and Napoleon was born in Corsica when this was > under Genua, and he had stolen a lot of masterpieces). :-) > I had to change my email client only once, long ago, from IBM Rice Mailer to > Alpine (from pre-Internet to SMTP) and was satisfied with both (unlike past > and present alternatives). I see no reason to change unless the way mail is > *delivered* changes. Netscape on Win 95 to Alpine on Linux and Netscape. Plus Exchange on a corporate account, Outlook on another... ... >> :-) Now what's not to like about DKIM, DMARC, OATH2, and all that other >> stuff designed to make email inconvenient so people will switch to >> facebook? > > Not in my name :-( (or No pasaran!) > > If the institute Gsuite (which is currently my main e-mail feed, via ssh from > home) moves to OATH2 forbidding fetchmail AND imap, I'll guess I'd move at > least my private mail to some other provider, and forward the official one to > it. Forwarding can also have interesting mishaps ;-) Like the final destination thinking that the forwarded mail is spam and bouncing it, and you getting the reports from the bounces. > > I would also not be displeased with running my own SMTP/MX at home, if I'd > understand how to get a static IP instead of a CGNAT DHCP to get a domain of > my own. No, no way with CGNAT, unless getting an IPv6 address instead. Or with a tunnel. > >> I like having my 20+ years of emails not depending on which email client I >> happen to use. > > I have stuff since 2003 online (locally) in mbox folders, from 1993 on CDs in > mbox, and earlier in IBM 'NOTEBOOOK' format (also plain text ... converted > from EBCDIC to ASCII long ago :-) > >>> I hope imap lives forever. >> Me too. > > +1, and alpine too > > - -- Cheers, Carlos E. R. (from openSUSE 15.3 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCYmszHxwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVLMYAn0RzE3c2ODEIdB8ovCLz 9oeH2WbLAJ9Jc1fP9IiRhq1bRc58jD97In3FcA== =V2f5 -----END PGP SIGNATURE----- From lucio at lambrate.inaf.it Fri Apr 29 12:38:02 2022 From: lucio at lambrate.inaf.it (Lucio Chiappetti) Date: Fri Mar 22 14:17:32 2024 Subject: [Alpine-info] O365 XOAUTH2 via fetchmail In-Reply-To: <500244c8-054b-4aec-d830-648ee341c484@telefonica.net> References: <500244c8-054b-4aec-d830-648ee341c484@telefonica.net> Message-ID: On Fri, 29 Apr 2022, Carlos E. R. wrote: >> If the institute Gsuite (which is currently my main e-mail feed, via >> ssh from home) moves to OATH2 forbidding fetchmail AND imap, I'll guess >> I'd move at least my private mail to some other provider, and forward >> the official one to it. > > Forwarding can also have interesting mishaps ;-) Ready to test it, if FORCED to abandon fetchmail. By the way, I've made a posting to fetchmail-users@lists.sourceforge.net, in reply to a posting by Matthias Andree (the latter was sent to Eduardo in Bcc:) I also kept a copy of some of the latest list(s) correspondence on this issue, but I have to study it, including yours about imapsync (was this the name?). Will that be oauth-free ? >> I would also not be displeased with running my own SMTP/MX at home, if >> I'd understand how to get a static IP instead of a CGNAT DHCP to get a >> domain of my own. > > No, no way with CGNAT, unless getting an IPv6 address instead. Or with a > tunnel. I have an openvpn tunnel with my machine at work, which I use sporadically for NFS mounts. I tested it also with an http proxy to open to the world my local Apache (yes, I do have an Apache httpd which I use only locally as a file manager and mysql frontend :-)) but I am not keeping it on. And I won't not use the tunnel for smtp. I guess this will not be compliant with the GARR AUP. ... who will live, will see -- Lucio Chiappetti - INAF/IASF - via Corti 12 - 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 yandex.com Fri Apr 29 18:45:59 2022 From: alpine.chappa at yandex.com (Eduardo Chappa) Date: Fri Mar 22 14:17:32 2024 Subject: [Alpine-info] O365 XOAUTH2 via fetchmail In-Reply-To: References: <500244c8-054b-4aec-d830-648ee341c484@telefonica.net> Message-ID: <6e12bbf9-0971-48f8-30c2-3548751d9cec@yandex.com> [ Bcc'ed to Matthias Andree ] On Fri, 29 Apr 2022, Lucio Chiappetti wrote: > On Fri, 29 Apr 2022, Carlos E. R. wrote: > >>> If the institute Gsuite (which is currently my main e-mail feed, via >>> ssh from home) moves to OATH2 forbidding fetchmail AND imap, I'll guess >>> I'd move at least my private mail to some other provider, and forward >>> the official one to it. >> >> Forwarding can also have interesting mishaps ;-) > > Ready to test it, if FORCED to abandon fetchmail. > > By the way, I've made a posting to > fetchmail-users@lists.sourceforge.net, in reply to a posting by Matthias > Andree (the latter was sent to Eduardo in Bcc:) > > I also kept a copy of some of the latest list(s) correspondence on this > issue, but I have to study it, including yours about imapsync (was this > the name?). Will that be oauth-free ? I did talk to Matthias over Zoom and we had a conversation on this issues. He does not oppose that OAUTH2 be available to fetchmail users, but the issue is too complicated and he makes some good points on the meaning of this situation. Let me share my experience with registration/verification. Google: They keep changing their requirements and they would issue a client-id and client-secret in the past to any app, but now they only give them to verified apps, so all one can do is to get one for testing, which expires every 7 days, and this leads to going through the authorization process once a week. This is bad for people like us who use apps like fetchmail, alpine or mutt that respect the permissions granted by their users. Microsoft: The experience with microsoft is very good considering the experience with Google. Alpine users do not need to get their own client-id and client-secret if they follow the "device" flow, but need a special client-id and client-secret if they wish to use the Authorize method. The main obstruction is not Microsoft by itself, it is the administrators that do not allow Alpine to access their resources. This is a subtle way to create a monopoly or a situation that only benefits the big companies, at best. If your company allows access to your program, Microsoft is not the obstruction, regardless of the level of verification you have with Microsoft. Yandex: I registered Alpine with Yandex, got my client-secret and client-id and I have never had any obstruction from Yandex or verification to make. All has worked well. In general a program should allow users to go through the authorization stage, and for all I know, fetchmail, alpine and mutt will allow it. This is a good situation. There are more issues that will come up over the future and I am sure we will all be ready to face it when the time comes. -- Eduardo