Re: Mail from the command line
2023-02-18 13:44 GMT, Crystal Kolipe : > On Sat, Feb 18, 2023 at 12:47:46PM +, Rodrigo Readi wrote: > Not really. I just described the way that mail is traditionally handled on > a unix workstation, and that still works for a large proportion of users, > myself included. Perhaps not on a workstation, but on a Mainframe, Minicomputer, or just a server. Most people using UNIXoids today do it on "Desktops". They do not have a static IP, their computers are also not an X Terminal. They are just a "Personal Computer", many of them a laptop, and now smartphones. > But you have found that in practice this is not always the case, because > the clients that are available and which broadly implement the standards don't > provide the specific sub-features that you want, such as downloading just > the text part without attachments over IMAP. I was speaking about CLI clients. >> And I repeat, IMAP is not POP3, it is not for retrieving all mails, > > But it [IMAP] can be used for that purpose, and there are good reasons to > prefer it > over POP3 for retrieving all mails because it supports push via the IDLE > command and therefore avoids the need to poll at short intervals. I prefer to retrieve the last headers when I want to read email, you prefer to keep the connection alive. It is a matter of taste. > Since by your own definition, CLI clients are not adapted to your way of > working, but rather still favour the traditional way of downloading all > mail > to a local mail spool, why would it make sense to assume that somebody > asking > about CLI clients and not mentioning remote or mobile access, has these > requirements and has a similar way of working to yours? Good question. I do not know exactly what the OP wants. Perhaps he can say it? Rod.
Re: Mail from the command line
On Sat, Feb 18, 2023 at 12:47:46PM +, Rodrigo Readi wrote: > 2023-02-18 9:47 GMT, Crystal Kolipe : > > Now things have changed, > > Have changed for YOU. It is your solution for your specific way of working > at your place, less mobile. Not really. I just described the way that mail is traditionally handled on a unix workstation, and that still works for a large proportion of users, myself included. > > But locking new users in to using specific programs from ports in order to > > give them a quick answer is not a great solution. In the future they'll > > find > > themselves saying, "I have to use mail client FOO on OpenBSD, because it's > > the only one that supports BAR, which I've come to rely on". > > No. For that there are standards. Here SMTP for sending, IMAP for getting. > You can use any client that follows the standards. But you have found that in practice this is not always the case, because the clients that are available and which broadly implement the standards don't provide the specific sub-features that you want, such as downloading just the text part without attachments over IMAP. > And I repeat, IMAP is not POP3, it is not for retrieving all mails, But it can be used for that purpose, and there are good reasons to prefer it over POP3 for retrieving all mails because it supports push via the IDLE command and therefore avoids the need to poll at short intervals. A very long time ago, I wrote a ~23 Kb perl script to do exactly that, and on the rare occasions that I need to monitor mail from external servers which are not under our direct control and to which I only have POP3/IMAP access, it works fine. > and it was invented for good reasons. > > Unfortunately CLI clients are not being adapted to today's requirements. The OP asked about using mail from the command line without elaborating on his specific configuration, (fixed or mobile, ISP, etc). Since by your own definition, CLI clients are not adapted to your way of working, but rather still favour the traditional way of downloading all mail to a local mail spool, why would it make sense to assume that somebody asking about CLI clients and not mentioning remote or mobile access, has these requirements and has a similar way of working to yours? > Alpine seems to have only one developer. I'm sure they would be happy to receive patches from you :-).
Re: Mail from the command line
2023-02-18 9:47 GMT, Crystal Kolipe : > On Sat, Feb 18, 2023 at 12:50:05AM +, Rodrigo Readi wrote: > When I sit down at my workstation, all of my email is just there. New > mail, complete with all attachments, arrived whilst I was away making coffee > or > whatever, so the download time didn't affect me - it was not done > interactively. You SIT at YOUR workstation. In between you MAKE COFFEE. > Now things have changed, Have changed for YOU. It is your solution for your specific way of working at your place, less mobile. > But locking new users in to using specific programs from ports in order to > give them a quick answer is not a great solution. In the future they'll > find > themselves saying, "I have to use mail client FOO on OpenBSD, because it's > the only one that supports BAR, which I've come to rely on". No. For that there are standards. Here SMTP for sending, IMAP for getting. You can use any client that follows the standards. And I repeat, IMAP is not POP3, it is not for retrieving all mails, and it was invented for good reasons. Unfortunately CLI clients are not being adapted to today's requirements. Alpine seems to have only one developer. Rod.
Re: Mail from the command line
On Sat, Feb 18, 2023 at 12:50:05AM +, Rodrigo Readi wrote: > The OP wanted a simple solution The OP just asked how to use '$ mail on the command line'. This is not very specific, which is why I asked exactly what he was trying to do in my first reply. > and the answers are getting too complicated. [...] > But my mail does not go through my server, but through 3 party providers. > And I want to use IMAP for what it is on my Desktops, and IMAP is not POP3. > > I first see the headers, then I decide for what mail I want to read > the text, and then > for that mail what attachements. I can see the emails on the server with any > Desktop computer anywhere. For that is IMAP. That doesn't sound at all like a simple solution to me. When I sit down at my workstation, all of my email is just there. New mail, complete with all attachments, arrived whilst I was away making coffee or whatever, so the download time didn't affect me - it was not done interactively. I can browse and search all email at the speed of my local disk, using _any_ client program with virtually no special configuration of new clients required. Many years ago, when sendmail was the common MTA on unix-like systems, it was reasonable to tell users, "If you're coming from a non-unix background and want it to 'just work' in a hurry, then use one of the desktop clients". This made sense for new users who had been using Netscape Communicator on another platform, and could use exactly the same application on X. Now things have changed, and configuring smtpd for outgoing mail shouldn't be much of a challenge for anyone with basic experience of OpenBSD. Inbound mail is more complicated because, as I explained before, it depends on the ISP and also your expectations of how the system is going to work. But locking new users in to using specific programs from ports in order to give them a quick answer is not a great solution. In the future they'll find themselves saying, "I have to use mail client FOO on OpenBSD, because it's the only one that supports BAR, which I've come to rely on".
Re: Mail from the command line
2023-02-17 23:50 GMT, Crystal Kolipe : > On Fri, Feb 17, 2023 at 10:02:16PM +, Rodrigo Readi wrote: >> But the main problem remains: with s-nail and mutt you have to >> download all attachments >> even if you only want to read the text. > > Out of interest, why is this an issue in your specific use case? Yes, bandwidth and speed play a big role. Yes, I could download all emails with fetchmail or mbsync. Yes, I could use an Email server, and I have one running, with sendmail and cyrusimap. But my mail does not go through my server, but through 3 party providers. And I want to use IMAP for what it is on my Desktops, and IMAP is not POP3. I first see the headers, then I decide for what mail I want to read the text, and then for that mail what attachements. I can see the emails on the server with any Desktop computer anywhere. For that is IMAP. The OP wanted a simple solution, and the answers are getting too complicated.
Re: Mail from the command line
Rodrigo Readi wrote in : |2023-02-17 19:16 GMT, Steffen Nurpmeso : |>|>> modern requirements (html-mail, attachements). |> |> These both s-nail can (the former likely via mailcap). | |Yes, as I did it with BSD mail. | |But the main problem remains: with s-nail and mutt you have to |download all attachments |even if you only want to read the text. | |Alpine source comes with the old (unfortunately unmantained) UW imap, |the reference |implementation of imap. Alpine client has better imap support. S-nail surely has the weakest IMAP support of the three. mutt can for example use IMAP compression. (Other than that i do not know much of their sources, even though i track both git's.) Well. S-nail can fetch only headers, but if you want to read/save/xy a message then the entire content is downloaded. Maybe an idea to keep in mind for (much) later. For me personally this is uninteresting, i pre-filter on the server and the rest i fetch from within S-nail via SSH, like that i do not need an additional IMAP daemon :). (Actually the development version contains undocumented code to trim messages, one could store and download the trimmed ones. This was meant for a mailing-list implemenation hack that yet did not spring into existence. Whatever.) Well i do not know, mostly if i want to read an email as via looking at the header i need it all; my SMTP server also has a strict size limit, and moreover do not receive (a lot of) multimedia attachments. If, that would surely be a problem. I find that unfriendly, one sometimes sees that on OpenBSD @misc, or huge tgz on @ports; i'd rather like to see an external URL then. There is even an email standard for that, message/external-body;access-type=URL (RFC 2017). But any URL would do. |And xoath2 for gmail is other story. I regret that I began using gmail. --End of --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: Mail from the command line
On Fri, Feb 17, 2023 at 10:02:16PM +, Rodrigo Readi wrote: > But the main problem remains: with s-nail and mutt you have to > download all attachments > even if you only want to read the text. Out of interest, why is this an issue in your specific use case? Is it due to bandwidth usage, (I.E. you are on a metered connection and want to reduce data usage), or is it due to speed, in other words browsing through your inbox is slower than it needs to be due to downloading all attachments instead of just the text part? Storing your mail long-term on a remote server and accessing it via a remote mail access protocol such as IMAP has some convenient perks, but it's by no means the only practical way of working. If you're hitting up against it's limitations then maybe it's time to consider the alternative. If you're not on a metered connection, then having 'real' mail delivery via SMTP right to your desktop or a local mailserver, makes browsing and searching your mailspools faster than it will ever likely be over an internet based IMAP connection. If you need remote access to your mail, there are ways to do this from your own server, and if you don't want to or can't set up inbound SMTP then there are ways to pull mail using POP3 or IMAP and feed it in to the local mail spool.
Re: Mail from the command line
2023-02-17 19:16 GMT, Steffen Nurpmeso : > |>> modern requirements (html-mail, attachements). > > These both s-nail can (the former likely via mailcap). Yes, as I did it with BSD mail. But the main problem remains: with s-nail and mutt you have to download all attachments even if you only want to read the text. Alpine source comes with the old (unfortunately unmantained) UW imap, the reference implementation of imap. Alpine client has better imap support. And xoath2 for gmail is other story. I regret that I began using gmail. Rod.
Re: Mail from the command line
Steffen Nurpmeso wrote in <20230217191605.lu6ph%stef...@sdaoden.eu>: |deich...@placebonol.com wrote in | <11709eb8-1507-4c76-a042-4c1d016e4...@placebonol.com>: ... ||>> And alpine is easier to configure, it works with gmail's xoauth2, Btw i have written a python3 script that can GMail, Outlook and Yandex, and possibly can more. (It is easier to configure than that mutt script in contrib/, or the one one can find in the internet for sendmail oauth, and it works with modern Python3, different to the one that Google provides. The "template" mode writes a template with doc comments.) curl -u moon:mars --basic -O https://git.sdaoden.eu/browse/s-toolbox.git/plain/oauth-helper.py --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: Mail from the command line
deich...@placebonol.com wrote in <11709eb8-1507-4c76-a042-4c1d016e4...@placebonol.com>: |Also take a look at s-nail, it is not an email application, but a very \ |useful utility. It is BSD Mail on steroids i would say in "Theo" mode. (Though a lot is to be done. And unveil() and pledge() even further apart.) |diana Greetings. |On February 17, 2023 9:13:15 AM MST, Andrew Mitchell \ |wrote: |>Thanks, I'll check it out. |>Andrew |> |>Le ven. 17 févr. 2023 à 15:14, Rodrigo Readi a écrit : |> |>> 2023-02-16 13:42 GMT, Andrew : |>>> Thanks Crystal for your reply and encouragement, |>>> I'll explore all your suggestions and references when I have enough \ |>>> time. |>> |>> If you do not have tine, better install and use alpine. |>> |>> You can read mail from a provider with imap without having to download |>> the attachements. |>> Mutt is not able to do that. |>> |>> And alpine is easier to configure, it works with gmail's xoauth2, That can be done with mutt, too. |>> displays html-mail. This is a MIME (mailcap) handler. |>> I like BSD mail program, but unfortunately it is not always (easily) |>> usable due to the |>> modern requirements (html-mail, attachements). These both s-nail can (the former likely via mailcap). --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: Mail from the command line
Also take a look at s-nail, it is not an email application, but a very useful utility. 73 diana On February 17, 2023 9:13:15 AM MST, Andrew Mitchell wrote: >Thanks, I'll check it out. >Andrew > >Le ven. 17 févr. 2023 à 15:14, Rodrigo Readi a écrit : > >> 2023-02-16 13:42 GMT, Andrew : >> > Thanks Crystal for your reply and encouragement, >> > I'll explore all your suggestions and references when I have enough time. >> >> If you do not have tine, better install and use alpine. >> >> You can read mail from a provider with imap without having to download >> the attachements. >> Mutt is not able to do that. >> >> And alpine is easier to configure, it works with gmail's xoauth2, >> displays html-mail. >> >> I like BSD mail program, but unfortunately it is not always (easily) >> usable due to the >> modern requirements (html-mail, attachements). >> >> Rod. >>
Re: Mail from the command line
Thanks, I'll check it out. Andrew Le ven. 17 févr. 2023 à 15:14, Rodrigo Readi a écrit : > 2023-02-16 13:42 GMT, Andrew : > > Thanks Crystal for your reply and encouragement, > > I'll explore all your suggestions and references when I have enough time. > > If you do not have tine, better install and use alpine. > > You can read mail from a provider with imap without having to download > the attachements. > Mutt is not able to do that. > > And alpine is easier to configure, it works with gmail's xoauth2, > displays html-mail. > > I like BSD mail program, but unfortunately it is not always (easily) > usable due to the > modern requirements (html-mail, attachements). > > Rod. >
Re: Mail from the command line
2023-02-16 13:42 GMT, Andrew : > Thanks Crystal for your reply and encouragement, > I'll explore all your suggestions and references when I have enough time. If you do not have tine, better install and use alpine. You can read mail from a provider with imap without having to download the attachements. Mutt is not able to do that. And alpine is easier to configure, it works with gmail's xoauth2, displays html-mail. I like BSD mail program, but unfortunately it is not always (easily) usable due to the modern requirements (html-mail, attachements). Rod.
Re: Mail from the command line
Thanks Crystal for your reply and encouragement, I'll explore all your suggestions and references when I have enough time. Cheers, Andrew Le jeu. 16 févr. 2023 à 12:58, Crystal Kolipe a écrit : > On Thu, Feb 16, 2023 at 12:27:37PM +0100, Andrew wrote: > > *Do you know any recipe for using $ mail on the command line? Or a web > link > > that proposes one.* > > > > The man pages are great but they are meant for people with great > technical > > skills, which I am not. > > What exactly are you trying to set up? > > Local mail works out of the box on a default OpenBSD install, so I'm > assuming > that what you want to do is to send and receive mail to other internet > hosts > without using a desktop/gui client, I.E. using the traditional built-in > mail > functionality typical of a unix-like system. > > This isn't particularly difficult, but it does depend to a certain extent > on > the configuration of your ISP, and also exactly how you want the system to > behave. So it's not possible to give you a simple fixed list of steps to > follow to 'make it work'. > > First up, the /usr/bin/mail utility in base is really a hard link to > /usr/bin/mailx. > > This is a very simple command line mail tool, which you probably don't > want to > use as your mail email application because it's lacking many features. > > Other command line based mail programs are available in ports, such as > mutt, > which is widely used by openbsd developers. > > Then you need to set up smtpd to handle your inbound and outbound mail. > > For outbound mail, you _probably_ want to, (and need to), relay it via your > ISP's 'smarthost', but we would need more information to know this for > certain > and to give specific advice on how to set it up. > > For inbound mail, you have several choices: > > * Run your own MX on a fixed IP broadband link. > * Pick up your mail via POP3 or IMAP from within the mail user agent, > (such as > mutt), and feed it in to your local mail spools that way. > * Pick up your mail via POP3 or IMAP and feed it into the local mail > system. > * Run your own MX on your own server or VM somewhere, and relay it to your > own local, private MX. > * Other options also exist. > > If you are new to this, then you probably want the second option. Maybe > the > third. > > > And web pages are full of phoney tips which rarely work. > > Agreed. > > > I hope that this is the right place for asking such questions. > > Yes, it is. > > But we can't give you a step-by-step guide without a bit more information. >
Re: Mail from the command line
On Thu, Feb 16, 2023 at 12:27:37PM +0100, Andrew wrote: > *Do you know any recipe for using $ mail on the command line? Or a web link > that proposes one.* > > The man pages are great but they are meant for people with great technical > skills, which I am not. What exactly are you trying to set up? Local mail works out of the box on a default OpenBSD install, so I'm assuming that what you want to do is to send and receive mail to other internet hosts without using a desktop/gui client, I.E. using the traditional built-in mail functionality typical of a unix-like system. This isn't particularly difficult, but it does depend to a certain extent on the configuration of your ISP, and also exactly how you want the system to behave. So it's not possible to give you a simple fixed list of steps to follow to 'make it work'. First up, the /usr/bin/mail utility in base is really a hard link to /usr/bin/mailx. This is a very simple command line mail tool, which you probably don't want to use as your mail email application because it's lacking many features. Other command line based mail programs are available in ports, such as mutt, which is widely used by openbsd developers. Then you need to set up smtpd to handle your inbound and outbound mail. For outbound mail, you _probably_ want to, (and need to), relay it via your ISP's 'smarthost', but we would need more information to know this for certain and to give specific advice on how to set it up. For inbound mail, you have several choices: * Run your own MX on a fixed IP broadband link. * Pick up your mail via POP3 or IMAP from within the mail user agent, (such as mutt), and feed it in to your local mail spools that way. * Pick up your mail via POP3 or IMAP and feed it into the local mail system. * Run your own MX on your own server or VM somewhere, and relay it to your own local, private MX. * Other options also exist. If you are new to this, then you probably want the second option. Maybe the third. > And web pages are full of phoney tips which rarely work. Agreed. > I hope that this is the right place for asking such questions. Yes, it is. But we can't give you a step-by-step guide without a bit more information.
Re: Mail from the command line
On Thu, Feb 16, 2023 at 12:27:37PM +0100, Andrew wrote: > > *Do you know any recipe for using $ mail on the command line? Or a web link > that proposes one.* typing "using mail from the command line" into a search engine yields quite a few hits. This one https://phoenixnap.com/kb/linux-mail-command looks like a fairly useful one once you skip the "how to install mailx on Linux" part. - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
