Re: mutt IMAP configuration for outlook.office365.com
On Wed, Mar 11, 2020 at 06:55:14PM -0500, Greg Marks wrote: > my university e-mail account [..] uses outlook.office365.com [..] Commiserations. Universities used to be capable of hosting their own email servers. > It would be great to get some authoritative guidance on this! Here is my guidance. I would not call it authoritative! > [..] The relevant part of my .muttrc file for this e-mail account > looks like this: > > source "/usr/bin/ccrypt -c .cpt |" > set imap_user=@ > set imap_pass="$password_variable" > [..] > set smtp_pass="$password_variable" > [..] > set smtp_authenticators = "login" > account-hook $folder "set imap_user=@ > imap_pass=$password_variable" > > [..] Up until recently this worked perfectly. It began to fail, > however, after I changed my e-mail account password to something > containing a dollar sign, of the form abc$def. This caused the mutt > IMAP connection to fail, with error messages such as "Could not find > the host outlook.office365.com," and no e-mail would be displayed. I > was able to fix these connection problems by escaping the dollar sign > in the password, redefining $password_variable in the encrypted file > to something of the form abc\$def. [..] > > The remaining problem is that while this allows me to read e-mail, I > am unable to send e-mail. [..] I suspect that that remaining problem occurs because email clients use the SMTP credentials, not IMAP credentials, to send email. I would suggest attempting the same workaround that you used for the IMAP password. I.e. escape the dollar sign in the smtp_pass field with a backslash. Let us know if this works. Sam -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: mutt IMAP configuration for outlook.office365.com
On Thu, Mar 12, 2020 at 02:32:13PM -0500, Greg Marks wrote: > Dear Mr. Kuper, Please don't address me as "Mr", but anyhow... >> I would suggest attempting the same workaround that you used for the >> IMAP password. I.e. escape the dollar sign in the smtp_pass field >> with a backslash. > > But haven't I already done this via these two lines in my .muttrc > file? > >set imap_pass="$password_variable" >set smtp_pass="$password_variable" > > The encrypted file .cpt read at the start of .muttrc > contains one line, of the form: > >set password_variable='abc\$def' Yes, I think you are correct. Sorry for not spotting earlier that both those two lines in your .muttrc reference the same variable. Sam -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Going GUI...er
On Thu, Apr 09, 2020 at 09:32:01AM -0500, Derek Martin wrote: > On Wed, Apr 08, 2020 at 01:17:12PM +0100, Sam Kuper wrote: >> On Tue, Apr 07, 2020 at 09:23:34PM -0500, Derek Martin wrote: >>> Sorry, but this is an archaic way of looking at the problem. >>> People have been doing this for decades now, has become the norm, >>> common practice, and really it is therefore WE who are being >>> inconsiderate by not accepting de facto standards that have been >>> widely adopted for a very long time. >> >> I disagree. You have made a "roads were built for cars" argument*: >> it assumes that today's "de facto standard" trumps historical >> precedent and considerate behaviour. >> >> I've nothing against people sending emails with multiple attachments. >> But expecting the recipient's MUA to parse multiple attachments into >> some kind of combined document is presumptuous, because clearly not >> everyone's MUA does this. > > There's a HUGE difference. Roads existed for millenia before > cars. The timescale isn't the point. My analogy refers only to your argument that today's "de facto standard" trumps historical precedent and considerate behaviour. In this respect, the analogy is accurate. But to avoid sidetracks, I retract it. Sorry it caused confusion. > By the time e-mail was in widespread use (the mid-90's... just > because you may have had it before then does not mean it was wide > spread before that), MIME was already a standard, and the vast > majority of e-mail clients had support for it. The GUI ones had it > built in. I think you are conflating two different things: - The sending of emails with multiple parts/attachments (e.g. via MIME). As noted above, I've nothing against this as long as the attachments *don't* need the MUA to parse and combine them into a new document/rendering. I *agree* that by the mid 90s, many GUI MUAs could handle such emails. - The sending of emails that *do* require the recipient's MUA to parse and combine their parts/attachments in some way. E.g. emails that require the recipient's MUA to parse an HTML part/attachment, figure out which "src" attributes in the HTML refer to images that were also attached to the email, and render the HTML accordingly with the images inline (which requires the MUA to contain or wrap a web browser). I *disagree* that by the mid 90s, most GUI MUAs could handle this. > So your argument is a straw man. Not that I can see. >> And even if yours does: should it? As several people in this thread >> have pointed out (and as is also illustrated in the "Efail" paper by >> Poddebniak et al, linked in my footer), using such an MUA massively >> increases your attack surface. > > Just because the current batch of GUI MUAs does this does not mean > yours *needs* to. That would be the beauty of a GUI Mutt--it already > has the philosophy of not automatically exposing you to all those same > attack vectors. After all, text-based Mutt has exactly the same > attack vetctors; it just does not expose you to them by default--you > have to take action to expose yourself to them. I agree that ideally no MUA, GUI or otherwise, should automatically expose you to attack vectors. Especially not to remote resources. In the case of the Efail vulnerabilities, you will see from Poddebniak, et al, that both Claws (a GUI MUA) *and* Mutt avoided the attacks. So clearly, there are some attacks that both classes of MUA can protect against. As I say, you and I are in agreement on this point. But I disagree that text-based Mutt has "exactly the same attack vectors" as a "GUI Mutt" would have, if that "GUI Mutt" were to parse, combine and render attachments as outlined above. Why? A text-based MUA is very hard to get right. It's not coincidental that Mutt's slogan is "All mail clients suck. This one just sucks less." Nor that despite decades in development, neither Mutt nor any other feature-rich text-based MUA is definitely secure and bug-free. A web browser, especially a graphical web browser, is *much* harder to get right. It has much greater complexity, and consequently a much greater attack surface. For instance, Mutt doesn't need to protect you against the Billion Laughs attack, but an XHTML- or SVG-capable "GUI Mutt" (or the XML library that it calls) would need to. Mutt doesn't need to protect you against raster image decoding vulnerabilities, but a "GUI Mutt" (or the image decoding library that it calls) would need to. And so on. Conclusion: for the same software development resources, you can expect more bugs (including more security bugs) in a GUI MUA that includes or wraps a web browser, than in a text-based MUA. -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Going GUI...er
On Wed, Apr 08, 2020 at 03:08:45PM -0400, Ben Boeckel wrote: > On Wed, Apr 08, 2020 at 14:43:47 -0400, Kurt Hackenberg wrote: >> On 2020-04-07 22:18, Derek Martin wrote: >> >>> Then again, maybe I should just move everything to gmail and be done >>> with it. >> >> Please remember that Google reads your mail. https://mako.cc/copyrighteous/google-has-most-of-my-email-because-it-has-all-of-yours > I have been migrating to fastmail for my stuff (though mailing lists > have not all been migrated yet). I'm happy with it at least. Fastmail is clearly preferable to Gmail, but that isn't saying much. Unlike both of those two: - Posteo's HQ and data center are both in the same, *relatively* privacy-friendly, jurisdiction as each other (Germany), which reduces its legal attack surface; - Posteo's web front end is free software; and - Posteo's servers run on renewable energy. So Derek, if you really are shopping around for webmail, please try Posteo in addition to (or instead of) Gmail or Fastmail. (I don't work for Posteo or have any other affiliation with them. I'm just a customer.) -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Going GUI...er
On Fri, Apr 17, 2020 at 06:08:37PM -0500, Derek Martin wrote:
> On Fri, Apr 10, 2020 at 01:09:12PM +0100, Sam Kuper wrote:
>> On Thu, Apr 09, 2020 at 09:32:01AM -0500, Derek Martin wrote:
>>> On Wed, Apr 08, 2020 at 01:17:12PM +0100, Sam Kuper wrote:
>>>> On Tue, Apr 07, 2020 at 09:23:34PM -0500, Derek Martin wrote:
>>>>> Sorry, but this is an archaic way of looking at the problem.
>>>>> People have been doing this for decades now, has become the norm,
>>>>> common practice, and really it is therefore WE who are being
>>>>> inconsiderate by not accepting de facto standards that have been
>>>>> widely adopted for a very long time.
>>>>
>>>> I disagree. You have made a "roads were built for cars" argument*:
>>>> it assumes that today's "de facto standard" trumps historical
>>>> precedent and considerate behaviour.
>
> And by the way, I ignored this point originally, but doesn't it?
No, it doesn't.
Inconsiderate behaviour is by definition inconsiderate.
Likewise, the fact that something is currently popular does not make it
good.
It is better to be considerate of others, and to evaluate the merits of
one's proposed approach, before acting.
> Even in the case of cars, which you can argue have had deleterious
> effects on society (but I think there's plenty of support for the
> counter-argument), we got to where we got to because it was what most
> people wanted. Technological evolution is about as democratic as it
> gets...
I disagree. Consumption is ultimately constrained by the choices
available to consumers.
If a region's developers and government planners, etc, space houses far
apart and provide negligible public transport or cycling infrastructure
but plentiful cars and car-oriented infrastructure, cars will
predominate there because the region's consumers are hampered in
pursuing other choices. For example, see:
https://en.wikipedia.org/wiki/File:Revised_petrol_use_urban_density.jpg
or
https://www.cambridge.org/core/journals/journal-of-economic-history/article/entrepreneurship-and-the-american-automobile-industry/127DE4B6237E8510ED8501D65DB6C973
Propaganda (e.g. advertising) also has an effect.
Technological evolution is no more democratic than is a gerrymandered
district rife with vote suppression and dubious publicity.
> You can assert that a different solution is better, and your argument
> might be correct on technical merit, but if most people don't agree
> your correctness is irrelevant; you still lose.
If most people dismiss an argument that is technically correct, then we
very likely *all* suffer.
That suffering is not the fault of the people who back the technically
correct argument; it is the fault of the people who dismiss it.
> Just ask BetaMax.
That's a quagmire of a topic!
It's also not relevant here. Betamax machines couldn't generally play
or record VHS tapes and vice versa: "Customers had to choose between
the two as tapes and machines were not compatible between the two
standards," per
https://www.jbs.cam.ac.uk/fileadmin/user_upload/research/workingpapers/wp0720.pdf
By contrast, non-GUI MUAs *can* often render at least some parts of HTML
emails, and GUI MUAs *can* render plain text emails.
It's also not clear that Betamax was "better" than VHS, as you seem to
imply. Betamax's primary advantage over VHS seems only to have been
Betamax's smaller cassette size.
Betamax was *worse* than VHS in terms of recording time:
- Early Betamax tapes could only record 1 hour whereas VHS could record
2 hours at similar quality. So of the two, only VHS tapes could be
used for (typically 90-120 minute) movies.
- Early Betamax tapes could only record 2 hour whereas VHS could record
4 hours at similar quality. So of the two, only VHS tapes could be
used for (typically 3-hour) NFL games and other lengthy events.
Betamax camcorders ("Betamovie") were *worse* than VHS ones insofar as
they could only record tapes, not play them back, whereas VHS camcorders
could do both.
These factors were compounded by Sony's reluctance (and high fees) to
license Betamax so that other manufacturers could profit or innovate
within the format, or even simply rebrand Sony products. I.e. unlike
email, Betamax technologies were not open standards that anyone could
implement. (VHS was much more widely licensed, and therefore more
widely implemented, than Betamax.)
All of the foregoing means that equating text email with Betamax and
"rendered" (for want of a better word) email with VHS, just seems too
much of a leap to be historically or technologically meaningful.
In any case, Betamax and VHS (and derivations thereof) both survived for
about the same duration: their products were manufactured in some form
from ~1975 (Betamax) or ~1976
Re: Going GUI...er
On Tue, Apr 07, 2020 at 09:18:37PM -0500, Derek Martin wrote: > I've said it before--I too would love a mutt-based (or mutt-similar) > GUI mail client. Frankly, no matter how much I love Mutt (and you > know I do), trying to make the case that Mutt's handling of modern, > every-day common e-mail messages is anything but clunky and backward > is insane. If I could find a GUI mailer that had half the power of > Mutt without the crashing/corruption of Claws and similar, I'd marry > that software. =8^) I haven't used it myself so can't personally recommend it, and don't entirely agree with your views above, but mu4e might more closely match your desires: https://www.djcbsoftware.nl/code/mu/mu4e/Viewing-images-inline.html https://www.djcbsoftware.nl/code/mu/mu4e/Displaying-rich_002dtext-messages.html -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Going GUI...er
On Tue, Apr 07, 2020 at 09:23:34PM -0500, Derek Martin wrote: > On Sun, Apr 05, 2020 at 12:09:55AM +0100, Sam Kuper wrote: >> I'll assume you mean that the email has multiple parts or >> attachments, one (or more) of which is an HTML file and one (or more) >> of which is an image file, and that the HTML file has an "img" >> element with a "src" attribute whose value is the name of the image >> file (at some path). >> >> (That is an inconsiderate way to send "email", but some people do >> it.) > > Sorry, but this is an archaic way of looking at the problem. People > have been doing this for decades now, has become the norm, common > practice, and really it is therefore WE who are being inconsiderate by > not accepting de facto standards that have been widely adopted for a > very long time. I disagree. You have made a "roads were built for cars" argument*: it assumes that today's "de facto standard" trumps historical precedent and considerate behaviour. I've nothing against people sending emails with multiple attachments. But expecting the recipient's MUA to parse multiple attachments into some kind of combined document is presumptuous, because clearly not everyone's MUA does this. And even if yours does: should it? As several people in this thread have pointed out (and as is also illustrated in the "Efail" paper by Poddebniak et al, linked in my footer), using such an MUA massively increases your attack surface. Making an MUA that works the way you are calling for and that is also secure might be possible, but I don't know of anyone who has achieved it yet. In the meantime, don't rue the functionality you feel you are missing. Please be thankful for the security and control that you have, and help others to achieve and be thankful for the same. * Historically, roads were *not* built for cars. See: https://www.theguardian.com/books/2014/dec/23/roads-were-not-built-for-cars-carlton-reid-review https://www.theguardian.com/environment/bike-blog/2013/apr/16/roads-not-built-for-cars-book -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Going GUI...er
On Sat, Apr 04, 2020 at 09:41:59AM +0200, Vegard Svanberg wrote:
> I'm increasingly finding myself having to resort to various tricks to
> deal with HTML only emails (with picture attachments), calendar
> invites, and other oddities and awkward stuff people send.
AKA "stuff awkward people send" ;)
This ~/.mailcap works tolerably under Gnome:
text/html; lynx %s; nametemplate=%s.html
text/html; lynx -force_html -width=72 -dump %s | sed -e
's/^[[:space:]][[:space:]][[:space:]]//' ; nametemplate=%s.html; copiousoutput
text/calendar;
/home/sampablokuper/src/mutt_and_neomutt_and_related/mutt-filters/vcalendar-filter;
copiousoutput
application/ics;
/home/sampablokuper/src/mutt_and_neomutt_and_related/mutt-filters/vcalendar-filter;
copiousoutput
application/pdf; evince %s
image/jpeg; /usr/bin/eog %s
(I have attached a copy of the .mailcap file, in case the above was
line-wrapped in transmission.)
Evince and EOG ("Eye of Gnome") are Gnome's PDF and image viewer,
respectively. Use other programs for those tasks if you like.
vcalendar-filter is from https://github.com/terabyte/mutt-filters
Finally, the postscript below (above my email footer) is a snippet from
my muttrc file, that I find helpful for viewing emails and their
attachments, in conjunction with the above .mailcap .
To you: good luck! And to Mutt's creators and maintainers: thank you!
Sam
# == Attachments ==
set attach_format="%u%D%I %t%4n %T%.40d %> %-1.20m/%-12.12M| %17.20e|
%11.12C| %4.12s"
# == Read ==
set pager_context=5
set pager_index_lines=8
set pager_stop=yes # Paging down at end of a msg? Don't jump to next msg
alternative_order text/plain text/enriched text/html # Try HTML last
# See ~/.mailcap for details of auto_view lines
auto_view text/html
auto_view text/calendar
auto_view application/ics
# This line gets rid of iso 8859 issues with attachments
set rfc2047_parameters
# Header weeding
ignore *
unignore from date subject to cc
unignore Message-ID: In-Reply-To: posted-to:
--
A: When it messes up the order in which people normally read text.
Q: When is top-posting a bad thing?
() ASCII ribbon campaign. Please avoid HTML emails & proprietary
/\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
text/html; lynx %s; nametemplate=%s.html
text/html; lynx -force_html -width=72 -dump %s | sed -e
's/^[[:space:]][[:space:]][[:space:]]//' ; nametemplate=%s.html; copiousoutput
text/calendar;
/home/sampablokuper/src/mutt_and_neomutt_and_related/mutt-filters/vcalendar-filter;
copiousoutput
application/ics;
/home/sampablokuper/src/mutt_and_neomutt_and_related/mutt-filters/vcalendar-filter;
copiousoutput
application/pdf; evince %s
image/jpeg; /usr/bin/eog %s
Re: Going GUI...er
On Sun, Apr 05, 2020 at 10:47:56AM +1000, raf wrote: > For other document attachments, I use various mailcap > filters to render things as text such as catdoc, > xls2csv, mutt.octet.filter and mutt.vcard.filter by > David A Pearson, vcalendar-filter by Martyn Smith etc. I knew about some of those, but not all of them. Thank you :) > In my younger, more fanatical days, I wrote a tool > (textmail) to convert everything to plain text as it > arrived to keep my mailbox small. That wouldn't help > you. :-) This one? http://raf.org/textmail/ Again, thank you :) -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Going GUI...er
On Sat, Apr 04, 2020 at 07:18:42PM +0200, steve wrote: > I can display images, read pdf's, etc… but one thing I never managed > to do is open an html file containing images. I mean, I can send the > html part to firefox but the images don't follow. > > How do you guys cope with that? Depends what you mean by "an html file containing images". I'll assume you mean that the email has multiple parts or attachments, one (or more) of which is an HTML file and one (or more) of which is an image file, and that the HTML file has an "img" element with a "src" attribute whose value is the name of the image file (at some path). (That is an inconsiderate way to send "email", but some people do it.) If so, probably the simplest way of coping with that is: - View the HTML file via your preferred browser. - Then view the images separately (hit 'v' in Mutt to see the mail's attachments/parts; move the cursor to the relevant entry; hit 'Enter' to view that image). - Alert the sender of the email to the fact that their email was problematic. - If the sender is unsympathetic, then try to minimise email communications with that person in the future. (Basically, treat them approximately as if they were sending you spam or malware.) Alternatively, you could save the HTML file and the images to some directory, and fix the HTML's "src" attributes if needed to ensure that they point to the image files. Relative paths would be the best choice. (I suppose this could be scripted using Bash/Sed, Perl, Python, or whatever.) You'd then open the HTML file in an image-capable browser, and it should look roughly as the sender intended. Good luck. -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Going GUI...er
On Sun, Apr 05, 2020 at 04:43:20PM -0400, Fred Smith wrote:
> On Sun, Apr 05, 2020 at 12:45:09PM -0700, Felix Finch wrote:
>> On 20200405, Akkana Peck wrote:
>> >Is there any way to configure mutt to alert me at the top of the
>> >message if there are any text/calendar or image/* attachments
>> >anywhere in the message, even as part of a multipart/alternative?
>> >I feel like I miss a lot in mail messages because mutt doesn't tell
>> >me about attachments.
>>
>> I wonder if the number of attachments could be shown in the index?
>
> I don't know about the number, but it IS possible to show a flag
> in the index indicating the presence of one or more attachments...
>
> set index_format="%4C %Z %{%b %d} %-20.20L %?X?^&%4c? %s"
>
> OK, that last one is what sets the attachment indicator. Looks like
> it is the "^&" out near the end.
Unless I am mistaken (quite possible), that flag does not reliably
appear in the presence of text/calendar parts in a multi-part email,
unfortunately.
If I am not mistaken, then this might be a bug :/
--
A: When it messes up the order in which people normally read text.
Q: When is top-posting a bad thing?
() ASCII ribbon campaign. Please avoid HTML emails & proprietary
/\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Going GUI...er
On Sun, Apr 05, 2020 at 01:08:05PM -0700, m...@amrx.net wrote: > On Sun, Apr 05, 2020 at 08:48:35PM +0100, Sam Kuper wrote: >> If/when it becomes possible to RSVP, in a machine-readable fashion >> directly from Mutt, to calendar-invites-sent-via-email, I'll switch >> to that. > > No! The ultimate goal should be do accept calendar invitations from > your calendar! I'm not opposed to this in principle. But first of all, this isn't primarily about my calendar (which might be on paper, or on an offline PDA), it's about RSVPing to invitations sent by other people who do use digital calendars, so that they don't have to manually record the contents of my RSVP on my behalf. I would not want to put them to that trouble if I could easily avoid it. Secondly, even if I had a piece of calendaring software on my PC that I wanted to use for accepting calendar invitations - as you suggest - which protocol should it use for retrieving and replying to those invitations? Where should it retrieve them from, and where should it send the responses? How should I identify my friend John Smith from his and my mutual friend John Smith , if not by their email addresses? How would any of these processes be secured from malfeasance? These are genuine questions. I guess you might suggest CalDAV over HTTPS as the protocol, and propose that my PC's calendaring software should be a CalDAV client. Also that I should run a CalDAV server that can receive meeting invites and that can also forward RSVPs from me to other people's CalDAV servers. And perhaps that I should continue to use email addresses as identifiers though not calendar invite/RSVP destinations. But I'm not aware of any calendaring software that supports anything close to all of this. So, I'm open to enlightenment. > Your mail client is reserved for reading email. MIME attached ics > files to coordinate meeting attendance is an atrocity. As long as it isn't abused as some kind of substitute for having a text/plain message, how is it any more of an atrocity than any other kind of attachment? (Again, this is a genuine question.) -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Going GUI...er
On Sun, Apr 05, 2020 at 08:05:29AM -0700, m...@amrx.net wrote: > Truly, sending the human an E-Mail, to read, is a great response, but > could trigger a frustrating conversation about auto populating > calendar items, be prepared to defend your mutt way of life. Been there, done that. Several times. Still standing, If/when it becomes possible to RSVP, in a machine-readable fashion directly from Mutt, to calendar-invites-sent-via-email, I'll switch to that. At least, as long as the feature is sensibly implemented. Based on Mutt's track reccord, it probably will be. -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Going GUI...er
On Sat, Apr 04, 2020 at 09:06:13AM -0700, Felix Finch wrote: > On 20200404, Sam Kuper wrote: >>This ~/.mailcap works tolerably under Gnome [...] > > I've been using something similar for several years, and one thing > missing from this is a way to respond to invites. Perhaps it's an > Outlook-only thing, but I invariable get followup emails asking me to > click "Accept", and I never see any such links. Looking at it in the > Outlook webmail, there is an RSVP section with buttons for Accept > Yes/No. AFAICT, this is just another Micro$oft lock-in attempt. > Looking at the actual mime part, each invitee has an RSVP section. > >ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Joe Blow > :mailto:jb...@megacorp.com > > [...] Do any calendar filters replicate this RSVP business? [...] I, too, would be grateful to know this. Not because I support lock-in, but because simplifying calendar invites/RSVPs should not be beyond the means of free (as in freedom) software. (Compatibility with proprietary implementations should be a secondary concern.) The key difficulty is likely to be broken time zone implementations (see below). In the meantime, you can just reply to the message (which, after all, was sent as an email): "Thanks, I accept your invitation to the meeting at 5pm PDT on 5th May 2020." N.B. I strongly suggest including the time, zone and date in your reply, as above, because sometimes automated invites: - use the wrong time zone for the event, AND - do not specify the time zone that they are assuming! > The only "http" links are for zoom. Don't be shy about alerting those senders that they are sending you links to malware. Seriously. See: https://gu.com/p/dtx4g N.B. Even MS Outlook should not be sending Zoom links by default (not because Micro$oft cares about giving you malware, but because Zoom is non-Micro$oft). So, those senders presumably installed or configured something at their end that causes those links to be inserted. -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Going GUI...er
On Thu, Apr 23, 2020 at 03:52:53PM -0500, Derek Martin wrote: > On Mon, Apr 20, 2020 at 03:49:46PM +0100, Sam Kuper wrote: >> On Fri, Apr 17, 2020 at 06:08:37PM -0500, Derek Martin wrote: >>> On Fri, Apr 10, 2020 at 01:09:12PM +0100, Sam Kuper wrote: >>>> On Thu, Apr 09, 2020 at 09:32:01AM -0500, Derek Martin wrote: >>>>> On Wed, Apr 08, 2020 at 01:17:12PM +0100, Sam Kuper wrote: >>>>>> On Tue, Apr 07, 2020 at 09:23:34PM -0500, Derek Martin wrote: >>>>>>> Sorry, but this is an archaic way of looking at the problem. >>>>>>> People have been doing this for decades now, has become the >>>>>>> norm, common practice, and really it is therefore WE who are >>>>>>> being inconsiderate by not accepting de facto standards that >>>>>>> have been widely adopted for a very long time. >>>>>> >>>>>> I disagree. You have made a "roads were built for cars" >>>>>> argument*: it assumes that today's "de facto standard" trumps >>>>>> historical precedent and considerate behaviour. >>> >>> And by the way, I ignored this point originally, but doesn't it? >> >> No, it doesn't. >> >> Inconsiderate behaviour is by definition inconsiderate. > > When you're talking about a population of people, who is being > inconsiderate, those who do what the majority prefer, or the minority > who have made up their own mind that their way is better despite > what everyone else does? That's a false dichotomy. >> Likewise, the fact that something is currently popular does not make >> it good. > > It does make it *preferred* though, If you mean "preferred" in the sense of "popular", then yes; that's tautological. But if you mean it in the sense of "good", then you seem to have conceded my point. Bad passwords are popular. They are not preferred. > which is how you have to define what is considerate. Inconsiderate is > doing something that is not preferred. That which is least preferred > is most inconsiderate. Again, no. You are conflating two different concepts, as shown by the following counterexample. In some *urban* subcultures, driving large 4x4 cars is preferred: https://www.macmillandictionary.com/buzzword/entries/chelsea-tractor.html . Yet that is clearly not considerate. It is inconsiderate because those cars are less safe than alternatives of similar or lower cost, including alternatives that provide comparable luggage space and legroom, etc. Specifically, the large 4x4s, compared to those other vehicles in those contexts, are less safe for occupants (lower occupant safety scores), for bystanders (lower bystander safety scores), and for the local and global environments (higher emissions of particulate and climate change pollutants). Moreover, you appear to be committing the logical fallacy called "argumentum ad populum" (aka "majoritarianism"). > If you can't agree with that, we may as well stop discussing it. Up to you. I've been trying to respond constructively to your points, because: - on the one hand, I sympathise with your wish to have an email client that is even more capable than Mutt while sacrificing none of Mutt's good qualities; - on the other hand, some of your arguments are unsound, and this undercuts the strength of your case. That said, I'm not sure I'll continue to contribute to this thread. >>> Technological evolution is about as democratic as it gets... >> >> I disagree. Consumption is ultimately constrained by the choices >> available to consumers. > > No, it isn't. If you are skilled, you can obtain resources to make > what you want. First of all, nobody has infinite skill. As for real people: no, they can't necessarily "obtain resources to make what [they] want". They are, as I stated, constrained by the choices available to them. Those constraints include: - the laws of physics. (Counterexample to prove my point: want to travel faster than light? Good luck with that.); - the laws of economics/psychology (Counterexample to prove my point: want people to work for you, when the company next door offers better pay for otherwise the exact same terms and prospects? Good luck with that.); - the resources available to them (Counterexample to prove my point: want to open a public gay bar in your hometown, but you grew up in Riyadh? Good luck with that.). >> If a region's developers and government planners, etc, space houses >> far apart and provide negligible public transport or cycling >> infrastructure but plentiful cars and car-oriented infrastructure, >> cars will predominate there because t
Re: Going GUI...er
On Tue, Apr 28, 2020 at 06:57:14PM +0100, Sam Kuper wrote: > On Thu, Apr 23, 2020 at 03:52:53PM -0500, Derek Martin wrote: >> On Mon, Apr 20, 2020 at 03:49:46PM +0100, Sam Kuper wrote: > If you want to read my emails [...] By which I meant "If you want to read emails that I have sent ...". >>> 2. You said earlier that "If you're talking about historical >>> precedence then time scale very much is the point." But then you >>> said, "I may be off by a few years ... It doesn't really matter." >> >> 2-3 years is a much smaller discrepancy than several millenia. There >> was vastly more precedence for roads being used by non-car things >> than there was widespread e-mail use not involving GUI clients, >> discounting the previously mentioned small fraction of the population >> who are technically-oriented humans, whether it happened in 3 years >> or 6. Thank you for clarifying your meaning here. -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Elimination of mime/html part
On Thu, Apr 30, 2020 at 08:54:25AM +0200, Angel M Alganza wrote: > [...] I've been looking for ways to remove the text/html part [...] > > Is there an automated way that you know of to get that done? Or do > you know of any third party program that could help me out? Python and some other programming/scripting languages have built-in or third-party email handling libraries that can be used to iterate over messages in a mailbox (mbox, maildir, MH, etc), processing each message in turn. Unfortunately, one of the weaknesses in Python's email handling (which might be related to some ambiguities or flaws in the RFCs on which they are based - I'm not sure) relates to the problem of identifying a "primary" (for want of a better word) text/plain part. So, if you just want to remove text/html parts from each message that also has a text/plain part, you'll probably find Python adequate. But if your use case involves being sure that your script has correctly identified the "primary" text/plain part, then you may have to work around shortcomings in Python's email objects/functions. If you come up with a solution that works for you, please post a follow-up in this thread, ideally with a copy of your source code (or a link to it) so that others can benefit. I would be very interested to see your approach. Good luck! -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Going GUI...er
On Sat, May 02, 2020 at 04:16:45PM -, Grant Edwards wrote: > Insisting that the world switch from HTML to plaintext for e-mail is > just tilting at a windmill. I don't insist that the world switch from HTML to plaintext. I do ask that, at least, compatibility be maintained. (By a similar token, I don't insist that everybody use step-free access, but I do ask that it be provided in as many buildings as possible.) -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Inconvenient Signature Requirements
On Mon, May 04, 2020 at 03:54:09PM -0500, Kevin Monceaux wrote: > My employer is trying to force me to downgrade to Outlook. One of the > powers that be came up with the brilliant idea of having a standard > company signature, with logo, specific font requirements, etc. Is > there any way to include such a signature in e-mails sent from mutt? I don't know the answer to your question, but I do know that you have my utter sympathy. -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Going GUI...er
On Wed, Apr 29, 2020 at 08:56:16AM -0400, Mark H. Wood wrote: > Two cultures in contact, which do not share customs and manners, can > disengage; they can fight; or they can agree on protocols that they > *will* share, even though the protocols make no sense *within* either > culture. > > So how can the flat-text and rich-text and all-up-graphics cultures > play nicely together, with nobody surrendering and being subjugated by > anybody else? The conventional, mutually acceptable approach has, for years, been as follows: - People who prefer to send plain text emails, or plain text emails with attachments intended to be viewed in software other than the MUA, continue to do so, because this approach is compatible with just about every extant MUA in the world. - People who prefer to send rich-text emails do so as multi-part messages that include a plain text part. (The latter is typically generated automatically from the rich text part by the sender's MUA; e.g. translated from HTML into Markdown, so that *emphasis* makes it through to the plain text version.) For maximum compatibility, no part/attachments should require the recipient's MUA to parse HTML or other files into a graphical representation, because not all MUAs can do this. The difficulty experienced by Derek, IIUC, and also by other people on this list, is that some people in the second culture have stopped following the convention above, and have instead begun sending emails that are compatible only with a restricted subset of not-very-secure MUAs. I realise that in many cases, the people in the second culture who have started doing that have done so unwittingly. For instance, because the developers of their MUA changed the MUA's behaviour so that it no longer sends emails that are compatible with traditional MUAs. (Not by default, anyway, and maybe not at all.) One or more variants of Outlook seem to be particularly at fault here. But the emails those people send are of limited compatibility nonetheless, and cannot be viewed as intended without an increased risk of exposure to spyware/malware. For these reasons, the new behaviour is (in my view) inconsiderate. (Insofar as this shift away from compatibility has been caused by corporate software developers, it is reminiscent of General Motors tearing up the streetcar tracks that they had acquired - "People have cars now. They won't need these old things anymore!" - with little care for people who depended upon streetcars for transportation. Or, to use my other analogy, it would be like a handful of maintenance corporations sending workers to their clients' buildings, unbidden, to remove the wheelchair ramps: "Ramps? They're so last century. Everyone should be using an app!") What's the solution to this inconsiderateness? The first response should be to notify the sender. If the sender fails to correct their (or their MUA's) behaviour to bring it back into universal compatibility, then they should be asked again. If they still fail, then they should be treated as the recipient would treat any other antisocial lout, e.g. given a wide berth. Additionally, if the recipient has a disability and the sender's inconsiderate behaviour renders the sender's emails inaccessible to the recipient (even though the recipient can read compatible emails just fine), then the recipient might, in some jurisdictions, be able to bring a legal case against the sender. (IANAL.) This emphasises the closeness of my second analogy above, about the ramps. -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Syntax for creating Muttrc.
On Thu, Oct 01, 2020 at 10:01:56PM -0700, Will Yardley wrote: > On Thu, Oct 01, 2020 at 09:58:17PM -0700, M.R.P. zensky wrote: >> Can someone tell me the syntax for creating a Muttrc file on linux? I >> have installed it on linux and am trying to understand how to >> configure it. > > man 5 muttrc This. If anything in there is confusing, then fall back to the over-arching Mutt manual: http://www.mutt.org/doc/manual/ . If anything in *there* is confusing, then fall back to the supplementary documentation written or sanctioned by Mutt developers/maintainers, which includes an FAQ: https://gitlab.com/muttmua/mutt/-/wikis/home . > and / or looking at the sample [Muttrc] that should ship with Mutt > could be a start. Direct link: https://gitlab.com/muttmua/mutt/-/raw/master/contrib/sample.muttrc-starter > There's also some info at: > https://wiki.archlinux.org/index.php/Mutt#Configuration > > Or search online to find example configs to steal^Wborrow from. Good starting points: https://gitlab.com/muttmua/mutt/-/wikis/ConfigList https://www.fefe.de/muttfaq/faq.html#patient -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Can mutt be persuaded to use a sensible maildir hierarchy?
On Tue, Sep 29, 2020 at 08:13:14AM +0100, Chris Green wrote: > On Mon, Sep 28, 2020 at 05:48:38PM -0500, Derek Martin wrote: >> I confess to some curiosity here... What are you doing in your >> home-grown MDA, that you could not already do with procmail, which >> (if you're on a Linux system at least) your mail system is most >> likely already using to deliver your mail? > > It's all driven from one text file so that when I subscribe to a new > mailing list all I have to do is add an entry to that file. No > changing of procmail rules, no additions to muttrc. I have attached > the filter file to this message, the comments explain it at least as > well as I can here. [..] > > # Mail filterfile, used to generate Mutt aliases and for filtering > # mail into mailboxes, it's used by:- > # getAliases.py - generates mutt aliases for the mailing lists > # getLists.py - generates list names for mutt 'subscribe' and > # 'lists' commands > # filter.py - called by .forward, delivers mail to appropriate > # mail box Nice! If you would be willing to publish/share the Python files (under a Free Software license), that would be great :) -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Can mutt be persuaded to use a sensible maildir hierarchy?
On Wed, Sep 23, 2020 at 09:04:11AM +0100, Chris Green wrote: > On Wed, Sep 23, 2020 at 09:44:22AM +1000, raf wrote: >> On Tue, Sep 22, 2020 at 06:30:52PM +0100, Chris Green wrote: >>> On Tue, Sep 22, 2020 at 05:46:53PM +0100, Chris Green wrote: Is there some way I can get to use real directories to represent my hierarchy of mail? >From more recent emails in this thread, I see that you answered (in the affirmative) your question above. Still, for sake of completeness/posterity. I manually rearrange my mail sometimes and to deal with very long directory names isn't really practical. For example I might decide to move mail as follows:- ~/Mail/folder/travel/zelmaFrance to ~/Mail/folder/travel/france/zelma With real directories such a move isn't too difficult but with the default maildir naming it becomes painful. Painful how? Some software I believe does work the way I want with maildir but the dotted hierarchy seems to be becoming the standard. Is there no way round this? I'd really like to move to maildir but I really can't see it being practical for me as it is. >>> I just run mb2md on my existing mail folders, I ended up with a >>> single directory (~/Maildir) containing 2354 files mostly with >>> ridiculously long names! This just isn't a sensible way to organise >>> my mail. >> >> I might be talking nonsense, but that maildir hierarchy probably is >> the correct thing, as defined by whoever came up with it, and is what >> is needed for all(?) mail software that deals with maildir to work. IIRC: - Maildir was invented by Daniel J. Bernstein, author of the Qmail MTA. - Maildir++, which extends Maildir, was invented by Sam Varshavchik, author of the Courier MTA. I may be wrong, but I believe that with Mutt you can use either Maildir or Maildir++ as you prefer. >> But if you want to manipulate the hierarchy separately from mail >> software, and still have all mail software work correctly, you might >> be able to implement (or convince someone to implement) a userspace >> fuse file system that provides an alternative view of the real >> maildir file system, that can be mounted alongside the real maildir >> directory. Then, whatever mail software you want to use can work with >> the real maildir hierarchy, and you can manipulate it in the way you >> want outside of mail software. I have no idea how much effort would >> be involved in such a fuse file system, though. Creating a FUSE overlay is probably substantially more effort than using an existing tool designed for the task, e.g. an MDA such as: - Procmail - Maildrop (part of Sam Varshavchik's suite of Courier-related software) - Sieve (there are various implementations, of which Dovecot's is perhaps the most widely used; but installing Dovecot is probably overkill for a client machine rather than a server, so Procmail or Maildrop might be better choices) > The only things dealing with the maildirs are my own mail filter > written in Python and mutt, nothing else. Python should be able to handle Maildir and Maildir++ equally well: Maildir is a directory-based mailbox format invented for the qmail mail transfer agent and now widely supported by other programs. Messages in a Maildir mailbox are stored in separate files within a common directory structure. This design allows Maildir mailboxes to be accessed and modified by multiple unrelated programs without data corruption, so file locking is unnecessary. [..] Folders of the style introduced by the Courier mail transfer agent are also supported. Any subdirectory of the main mailbox is considered a folder if '.' is the first character in its name. Folder names are represented by Maildir without the leading '.'. Each folder is itself a Maildir mailbox but should not contain other folders. Instead, a logical nesting is indicated using '.' to delimit levels, e.g., "Archived.2005.07". Source: https://docs.python.org/3.8/library/mailbox.html#mailbox.Maildir > Way back when maildir first appeared and I used qmail the way I want > things to work was the way it *did* work. It's the maildir++ thing > that's broken it. I don't think anyone in the Mutt camp is forcing anyone else to use Maildir++. So, if someone wants to use Qmail-style Maildir with Mutt, the thing for them to do is probably to give it a try and maybe post on the mailing list (or file a bug report) in case of specific problems. Glad you got it working to your satisfaction in the end :) -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Can mutt be persuaded to use a sensible maildir hierarchy?
On Wed, Sep 30, 2020 at 04:39:52PM +0100, Chris Green wrote: > On Wed, Sep 30, 2020 at 03:20:50PM +0100, Sam Kuper wrote: >> On Wed, Sep 30, 2020 at 02:18:08PM +0100, Chris Green wrote: >>> I've attached them here anyway. >> >> Thanks :) Would you be willing to mention a license? [..] > > OK, I've gone with Apache v2, attached again here. Thank you! :) -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Can mutt be persuaded to use a sensible maildir hierarchy?
On Wed, Sep 30, 2020 at 02:18:08PM +0100, Chris Green wrote: > On Wed, Sep 30, 2020 at 12:03:41PM +0100, Sam Kuper wrote: >> On Tue, Sep 29, 2020 at 08:13:14AM +0100, Chris Green wrote: >>> On Mon, Sep 28, 2020 at 05:48:38PM -0500, Derek Martin wrote: >>>> I confess to some curiosity here... What are you doing in your >>>> home-grown MDA >>> >>> It's all driven from one text file so that when I subscribe to a new >>> mailing list all I have to do is add an entry to that file. >> >> Nice! If you would be willing to publish/share the Python files >> (under a Free Software license), that would be great :) > > Absolutely no problem, is there a place to put them on mutt.org? [..] > I keep the code in mercurial [..] Best bet would probably be to: 1. Upload the files to a code hosting repository: gitlab.com; sourcehut.org; notabug.org; or similar. (Sourcehut.org supports Mercurial directly; I think the others only support Git.) 2. Having done that, I guess you could (subject to Kevin McCarthy's approval - he's the Mutt maintainer and I can't speak for him) perhaps edit https://gitlab.com/muttmua/mutt/-/wikis/ConfigTricks to add a sentence or two describing your tools and linking to the hosted version of them that you created in the previous step. > I've attached them here anyway. Thanks :) Would you be willing to mention a license? Without a license, your scripts are technically non-free software, i.e. others don't have the right to distribute them, modify them, or share their modifications. I'd suggest AGPLv3 as a good default Free Software license https://www.gnu.org/licenses/license-list.html#AGPLv3.0 ; but given that these are small (<300LOC) programs, you might prefer a "pushover" license like Apache v2: https://www.gnu.org/licenses/license-recommendations.html#small https://www.gnu.org/licenses/license-list.html#apache2 . -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: support for Office365?
On Sun, Sep 27, 2020 at 10:16:07AM -0400, Spackman, Chris wrote: > On 2020/09/27 at 12:05pm, ed neville wrote: >> Just out of interest, does anyone know /why/ organisations, in their >> rampant desire to outsource to the cloud disable IMAP and SMTP >> protocols whilst doing that? Is something to be feared? Surely MS >> cares only that people pay the monthly rent on Office 365? > > [..] I can't speak to the actual security benefits, but I suspect that > most IT people at the organization assume or expect that everyone uses > Outlook, so why would they need IMAP? This. It is the sort of view that I have encountered in several organisations abandoning sensible email systems in favour of proprietary mainframe spyware. Many of today's IT staff/managers aren't sysadmins in the traditional sense (often don't even have OS-level access to the servers their organisations software runs on, let alone hardware-level), don't know how email systems work under the hood, and are heavily targeted with marketing from companies like Microsoft telling them that if they buy a service like Outlook365 (or whatever it's called these days), then it will handle everything email-related for them and their users and they will never have to understand or be accountable for anything ever again. All too often their response is, "Great!" > It is possible that [Microsoft] also "highly recommend" turning off > "legacy protocols". Again, this. They just go through the process and select the "recommended" settings. If they think about it at all, it doesn't go very deep: they conclude (wrongly, of course) that forcing users off IMAP is an "upgrade" that the users will thank them for :( In short, if your organisation moves its email to something like O365 or Gmail, then your organisation is managed by thoughtless authoritarians, and if you stay there after a change like that then you are only enabling them. If reasoning with them fails, then cut your losses and run. -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: support for Office365?
On Fri, Jun 26, 2020 at 02:20:25PM -0400, Andrew D. Arenson wrote: > My organization is moving to Office365 and have decided, sadly, not to > support IMAP. > > Anyone have insight in how mutt might still be able to connect to > Office365? > > A co-worker has been investigating a project called davmail, which > provides a gateway that sort of translates from Office365's other > protocols to IMAP, as they use a (non-mutt) IMAP mail client. DavMail worked well last time I tried to use it against an Office365 server. Great that it exists. Pity that it should have to. -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: mutt for office 365 mfa
On Wed, Jun 10, 2020 at 02:09:17PM -0400, Scott Brozell wrote: > The organization i work for has forced on us office 365 multi factor > authentication. In addition to outlook duo they are supporting > evolution and have setup a tenant and application id for it. > Is it possible to use those with mutt ? I don't have direct experience of this, but have you tried to set up an "App Password" (which seems to be a password for accessing a specific Office365 inbox over IMAP even when 2FA is enabled)? See https://serverfault.com/a/950594 -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Mutt - a scriptable email client?
On Tue, Jun 09, 2020 at 11:06:57AM +0100, Sam Kuper wrote:
> On Tue, Jun 09, 2020 at 10:36:28AM +0200, Bastian wrote:
>> On 09Jun20 09:51+0200, Kia Niskavaara wrote:
>>> I'm looking for a scriptable email client for linux cli.
>>> Specifically I need to connect it to a Gmail account using IMAP IDLE
>>> so that I will be able to find new emails almost immediately. And
>>> secondly, when new emails arrive, I need a script that automatically
>>> parse the body of every email to look if they match a specific
>>> regular expression - and if they match, then another script should
>>> be executed.
>>
>> This sounds like you are looking for a fetchmail/procmail solution. I
>> still use those since years, well already decades, in very simple
>> way.
>
> Yes :)
>
> For anyone (e.g. the OP) who might be unfamilier with the terms,
> Fetchmail is an "MRA" ("Mail Retrieval Agent") and Procmail is an "MDA"
> ("Mail Delivery Agent").
That said, Mutt can do quite a bit of what you need.
Within Mutt, you can:
1. use the "limit" functionality to find exactly the emails you are
interested in (e.g. new emails matching some regex);
2. use the "tag" functionality to select all those emails; and finally
3. use the "pipe" functionality to send the tagged emails to your
script, via stdin.
I believe you could also put this functionality into a "macro" in Mutt,
so that you could perform all three steps with a single keystroke.
Good luck!
--
A: When it messes up the order in which people normally read text.
Q: When is top-posting a bad thing?
() ASCII ribbon campaign. Please avoid HTML emails & proprietary
/\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Mutt - a scriptable email client?
On Tue, Jun 09, 2020 at 10:36:28AM +0200, Bastian wrote:
> On 09Jun20 09:51+0200, Kia Niskavaara wrote:
>> I'm looking for a scriptable email client for linux cli. Specifically
>> I need to connect it to a Gmail account using IMAP IDLE so that I
>> will be able to find new emails almost immediately. And secondly,
>> when new emails arrive, I need a script that automatically parse the
>> body of every email to look if they match a specific regular
>> expression - and if they match, then another script should be
>> executed.
>
> This sounds like you are looking for a fetchmail/procmail solution. I
> still use those since years, well already decades, in very simple way.
Yes :)
For anyone (e.g. the OP) who might be unfamilier with the terms,
Fetchmail is an "MRA" ("Mail Retrieval Agent") and Procmail is an "MDA"
("Mail Delivery Agent").
The usual way to set things up is so that:
- The MRA retrieves mail (typically via POP3 or IMAP4) from your inbox
on your email server, and optionally gives it to an MDA.
- The MDA applies filtering rules (and optionally invokes external mail
filters - "milters" - like Bogofilter or SpamAssassin) and then
delivers the emails to one or more mailboxes (e.g. mbox files or
Maildir directories) on your hard drive.
Several MRAs (e.g. Getmail, isync, ...) have cursory MDAs built in, so
that they can at least deliver emails into local mailboxes; but for more
advanced filtering, you should use a full-blown MDA (e.g. Procmail,
which is probably the most popular MDA, or maildrop, which I would guess
is the next most popular one).
> But nowadays there are more modern and active developed projects. I
> think getmail and offlineimap are to be named here, too, but I have
> not used them.
Yes.
- Getmail will work, and many people prefer it to Fetchmail.
- Offlineimap may work. It used to be popular, but last time I checked,
it had a bit of a reputation for bugginess.
- I've encountered several people who prefer isync (sometimes known as
mbsync because that's the name of its command-line tool) to
Offlineimap: http://isync.sourceforge.net/ . This is a powerful but
complex tool, and you might find that Getmail is the better option.
Good luck!
--
A: When it messes up the order in which people normally read text.
Q: When is top-posting a bad thing?
() ASCII ribbon campaign. Please avoid HTML emails & proprietary
/\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Macro to mark as "read" and then archive
Dear Mutt nuts,
I wanted a Mutt macro that met the following desiderata:
1. Allows the user to choose, at each invocation, whether to apply the
macro:
- to only the current message (by simply running the macro); or
instead
- to currently-tagged messages (by pressing the tag-prefix key,
which by default is `;`, before running the macro).
2. Marks those message(s) as "read". IIUC, in Mutt this amounts to
marking those message(s) as not "new" and not "old".
3. Moves ("saves") those message(s) to my `$record` mailbox (which, in
Mutt, can be referenced with the mailbox shortcut `<`).
4. Syncs the current mailbox.
I think I succeeded, but it took me a few attempts. I am posting this
to the list in case it is useful for others.
# Attempt 1
Criteria satisfied: 1: yes, 2: no, 3: yes, 4: yes.
macro index,pager ss "
Re: Is it possible to change/add headers to incoming mail?
On Wed, Dec 09, 2020 at 03:23:20AM -0500, Philippe Meunier wrote: > raf wrote: >> for mail delivered locally, procmail could do it. > > procmail is not a good option anymore, and has not been for a while > now: > https://marc.info/?l=openbsd-ports=141634350915839 Debian continues to make security/maintenance patches to Procmail: https://metadata.ftp-master.debian.org/changelogs//main/p/procmail/procmail_3.22-26_changelog So, I hear of lots of people still using it on Debian and derivatives. But yes, avoid excessively old/unpatched versions of Procmail. Maildrop is a popular alternative. -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: mutt 2.0.0 released
On Sat, Nov 07, 2020 at 01:46:16PM -0800, Kevin J. McCarthy wrote: > My thanks to [the contributors], and to all the others who helped by > submitting tickets, testing, doing translation, and just providing > moral support. :-) Mutt is one of a tiny handful of habitable islands in the raging sea of MUAS. It is perhaps the most supportive and rewarding of all of them, when one has learned its terrain. Carefully maintaining and improving it is time valuably spent. I'm sure I'm not alone in being grateful to you for this. Thank you :) -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Truncated link in html email
On Mon, Feb 08, 2021 at 07:23:16PM -0600, boB Stepp wrote: > On 21/02/08 07:04PM, boB Stepp wrote: >> Just now I came across one of those html emails that Mutt + urlview >> does not seem to be able to handle. This was an email from the >> clinic I go to that has embedded a "CLICK TO CHECK-IN" button. Upon >> opening it in Mutt, hitting "v" to view attachments, hitting >> to view it with w3m and finally Ctrl-B to bring up urlview of the >> links I found that the button's link was truncated. What would cause >> this and how might I remedy the situation for the future? This sounds like a bug in urlview (or possibly w3m). Probably best to try to isolate the problem (figure out, for problem URLs, what they have in common; and determine exactly which piece of software is failing to parse them) and report it to the relevant bug-tracker. -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On Mon, Feb 08, 2021 at 02:43:48PM -0600, boB Stepp wrote: > Today's task is to understand and install/configure "notmuch" to > search through this locally stored mail. Notmuch is quite nice in some ways, but (as Dan Bernstein kindly pointed out to me a couple of years ago), it probably isn't necessary for most people because Mutt's "limit" feature is powerful enough. If you can live with the latter, then you can avoid notmuch altogether, which helps to keep your setup simple and your TCB small. >> 2) I would like to remove all email storage from the cloud, that is, >> whether Gmail or ProtonMail, ... > > For now I am abandoning this goal as it was pointed out that I might > want to access certain archived emails from my phone or some other > device outside of my PC. Some people do this by sync'ing their PC's mailboxes with their phone. This can be done various ways, including: - Unison (or rsync, but Unison is safer): https://www.cis.upenn.edu/~bcpierce/unison/ - Hosting your own IMAP server using Dovecot. >> 5) I would like to be able to auto-backup locally stored emails on >> my PC to another hard drive on my local network. I guess this would >> be facilitated by a sensible organization of my PC's email storage? > > Remains to be implemented. The above folder structure should make > this trivial to accomplish. If you use ZFS as your file system, look into Jim Salter's duo of helpful scripts: Sanoid and Syncoid. If you don't use ZFS (or at least another checksumming filesystem like btrfs), then maybe you should. Good luck in your quest! -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: simple formatting possibilities
On Mon, Aug 31, 2020 at 01:06:48PM -0400, Mark H. Wood wrote: > Things like HTML and PDF are designed for finalized documents. PDF, yes. But historically, TimBL very much designed HTML for revisable documents. (Sadly, as was already pointed out earlier in the thread, many people are unwilling to learn how to edit HTML. TimBL accounted for numerous stumbling blocks the Web might face, but is I think still taken aback by the many regrettable vagaries of human psychology.) -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Mailman strips subject from DMARC messages (was: Re: Fwd:)
On Sat, Oct 24, 2020 at 12:49:12PM -0700, Kevin J. McCarthy wrote: > On Sat, Oct 24, 2020 at 12:24:23PM -0700, Kevin J. McCarthy wrote: >> On Sat, Oct 24, 2020 at 02:04:11PM -0400, Remco Rijnders wrote: >>> Unfortunately, the subject of such messages seems to get cleared. I >>> don't think this is something under our control but of the generous >>> people who host the mutt-users mailing list for the project. Kevin, >>> do you know if this is anything that can be changed / fixed? >> >> Whoops, I missed the fact that the wrapper removes the Subject line >> too. That's not convenient at all. Let me see if there is anything >> I can do about that. > > I didn't see any options regarding the wrapper Subject header, so I've > changed the action to munge the From address instead. Mailman's failure to retain the Subject: header when wrapping a DMARC message was a bug, and the Mailman maintainer has issued a patch: https://mail.python.org/archives/list/mailman-us...@python.org/thread/ZVM6I4UTDKHY4EKNLIBIWE4JNC2PYLIS/ -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Marking as unread when moving mail to another folder
On Thu, Jul 16, 2020 at 10:57:13AM +0200, Kai Weber wrote: > I have a save-hook defined to move all mail into a certain folder. > > save-hook "~A" +personal/Archive > > Very often I want to move the mail into the archive without opening the > mail at all but then the mail ends up as unread in the archive. > > I want to mark the mail as "read" when moving. How could I achieve this? > I guess a macro could do it? Should I get rid of the save-hook? This macro may do what you want. It marks mail as "read" and moves it to the $record file. Note that it makes use of `<`, which is Mutt's built-in shortcut for the $record file. # Unlike index mode, pager mode does not accept this macro without # an initial ``. So we need two variants of this macro, one # for each mode. macro index ss"set auto_tag=yesn
Re: Deleting old maildir messages, is what I'm doing OK?
On Mon, Feb 15, 2021 at 06:00:47PM +, Chris Green wrote: > It's odd that none of the "maildir works like this" descriptions I > could find had anything about deleting mails. I agree. That's an unfortunate gap in the literature. -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: [unixbhas...@gmail.com: Notify-send pop up for specific mails]
On Sun, Feb 14, 2021 at 11:24:59AM +1100, Cameron Simpson wrote: > On 13Feb2021 19:29, Bhaskar Chowdhury wrote: >> How?? Show us...share with the people .. > > I collect my email with getmail, deliver to my local "+spool" mail > folder, a Maildir (~/mail/spool). > > I filter my messages using mailfer: > > https://pypi.org/project/cs.app.mailfiler/ > > which monitors multiple Maildirs for new messages, and files them > according to per-folder rules. Nice. I've bookmarked this as a procmail alternative :) > The desktop popup comes from my "alert"r script: > > https://hg.sr.ht/~cameron-simpson/css/browse/bin/alert?rev=tip > > That will issue alerts to a variety of places depending on envvars and > options particularly my dlog (a timestamped text log I use for > reviewing things, since my invoicing system is a ghastly hack held > together with string) and to the desktop. > > The "desktop alert" part of that script is in the $to_desktop > if-statement at the bottom. Presently I'm on a Mac and use the > "terminal-notifier" command to issue a normal Mac Notification popup. > I'd be using whatever Linux desktop notification command line were > suitable were I on Linux. > > I presume there _is_ a standard way to issue a popup alert on Linux > systems these days? I used to just always run a permanent very short > full-width terminal across the top of the screen tailing a log file > myself, crude but effective. The same terminal also accepted commands > if you typed them. This is an interesting bunch of workarounds. Again, thank you for sharing :) -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On Sun, Feb 14, 2021 at 10:25:21AM +0100, Angel M Alganza wrote: > msmtp-queue -r -- runs (flushes) all the contents of the queue > > Try running 'msmtp-queue -r' at your shell. It should trigger sending. > > Adding 'msmtp-queue -r' as a cron job should do it automatically. Exactly. If you want it to try regularly, that's the way to do it. -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Should I have all my mailing lists in both 'lists' and 'subscribe'?
On Mon, Feb 15, 2021 at 01:04:15PM +, ಚಿರಾಗ್ ನಟರಾಜ್ wrote: > 12021/01/05 03:27.03 ನಲ್ಲಿ, Chris Green ಬರೆದರು: >> Currently I automatically add all mailing lists I am subscribed to >> into my muttrc file against both 'lists' and 'subscribe', is this >> correct/OK? >> >> I've never been quite clear why there are two commands. > > [..] More precisely, Mutt maintains lists of patterns for the > addresses of known and subscribed mailing lists. Every subscribed > mailing list is known. To mark a mailing list as known, use the list > command. To mark it as subscribed, use subscribe. (section 3.14) This is really the key point. I.e. Mutt, correctly, makes a distinction between known mailing lists and subscribed ones. So, if you *post* to a mailing list *to which you are not subscribed*: - you should add it to "lists" first, to enable relevant list-related functionality in Mutt such as adding suitable headers. (Which functionality kicks in, in each person's specific case, will depend, as you mentioned, on some of their other Mutt settings.) Alternatively, if you *subscribe* to a mailing list: - add it to "subscribe". This will also enable relevant but slightly different list-related functionality in Mutt. If you previously had that list's address in "lists", you can delete it there, because if it is in "subscribe" then that is sufficient for Mutt to understand that it is a mailing list. > Personally, I just do what you mentioned and haven't had any ill > effects. Once you have entered a subscribed list into "subscribe", entering it into "lists" serves no purpose in the short-term. In the long-term, it has the advantage that if you ever unsubscribe from the list, then you can just remove it from "subscribe" (but not from "lists") and Mutt will still know it is a mailing list. But sure, if you only post to mailing lists to which you subscribe, then there would be no ill-effects (besides perhaps an imperceptible processing delay) to mentioning all the lists both in "lists" and "subscribe". (I belive all the above is accurate. If I am mistaken, somebody please correct me!) Sam -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Deleting old maildir messages, is what I'm doing OK?
On Mon, Feb 15, 2021 at 04:21:11PM +, Chris Green wrote:
> This isn't specifically mutt but it's definitely to do with managing
> mail and there's lots of knowledgeable people here.
>
> I currently have the following two lines in my crontab to delete old
> mails in my junk catching directories, is it OK/safe to do it like
> this?
>
> 20 02 * * * find /home/chris/mail/Ju/*/cur -type f -mtime +7 -exec rm {}
> \;
> 30 02 * * * find /home/chris/mail/Ju/*/new -type f -mtime +7 -exec rm {}
> \;
If you have software expecting to be able to read or write to the files
affected by the above commands, then if that software is not able to
handle the sudden disappearance of those files, it may throw errors or
otherwise misbehave. Software designed to work with Maildirs should
not have problems, though.
Also, unless I am mistaken, `find ... -exec rm () \;` is not atomic, so
a race condition exists: `find` could find a matching file, but then
some other piece of software could delete or rename it before `rm` does.
(If I am mistaken, someone please correct me!)
Finally, I suppose that to be technically correct, you perhaps ought to
first move the files from "new" to "cur", and then delete them from
"cur". A true mail guru may be able to shed light on this.
IMO, the likelihood is low that any of these issues will bite you.
Sam
--
A: When it messes up the order in which people normally read text.
Q: When is top-posting a bad thing?
() ASCII ribbon campaign. Please avoid HTML emails & proprietary
/\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On Fri, Feb 12, 2021 at 01:30:04PM +0100, Angel M Alganza wrote: > On Mon, Feb 01, 2021 at 04:34:47PM -, Grant Edwards wrote: >> I maintained a local queueing MTA for many years, but after multiple >> screwups where mail wasn't getting sent (and I didn't find out in a >> timely manner) I switched to a non-queueing MTA (e.g. ssmtp) and >> later to mutt's SMTP support. > > I did the same myself for years and also switched to ssmtp. But I > belive ssmtp was discontinued, and now I'm using msmtp: > > https://marlam.de/msmtp/ > > I couldn't be happier! A queue script is included with msmtp, so you can have the best of both worlds :) https://git.marlam.de/gitweb/?p=msmtp.git;a=blob_plain;f=scripts/msmtpq/README.msmtpq;hb=HEAD Sam -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Dead url, returning 404 in wiki under configlist/Configs
On Fri, Feb 12, 2021 at 09:45:41AM -0800, Kevin J. McCarthy wrote: > On Fri, Feb 12, 2021 at 02:25:44PM +0530, Bhaskar Chowdhury wrote: >> Please take out the dead url from the Configlist page under Configs > > Thanks, I've removed the dead link. > > Note, to anyone else: although the wiki is not directly publicly > editable, you can clone the https://gitlab.com/muttmua/wiki repos and > submit a merge request too. Thanks. That link's target is still visible in the Wayback Machine, though. Merge request submitted: https://gitlab.com/muttmua/wiki/-/merge_requests/8 -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: UserPages dead url ..the first one the page
On Sat, Feb 13, 2021 at 06:59:04AM +0530, Bhaskar Chowdhury wrote: > On this page : https://gitlab.com/muttmua/mutt/-/wikis/UserPages > > The url: http://mutt.justpickone.org/ -- David T-G > > While clicking on the url Showing: > > "Error resolving “mutt.justpickone.org”: Name or service not known" > > I think it is not maintained anymore. Thanks. Fortunately, the link target is available in the Wayback Machine. Merge request submitted: https://gitlab.com/muttmua/wiki/-/merge_requests/8 -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On Sun, Feb 14, 2021 at 11:00:45AM +1100, Cameron Simpson wrote: > On 13Feb2021 20:03, Sam Kuper wrote: >> A queue script is included with msmtp, so you can have the best of >> both worlds :) >> >> https://git.marlam.de/gitweb/?p=msmtp.git;a=blob_plain;f=scripts/msmtpq/README.msmtpq;hb=HEAD > > Ah, I missed that. Nice. > > Though I still like a local system MTA so that scripts and cron etc > etc can also send email natively. The two approaches can coexist happily on the same machine: - a local MTA for cron, etc.; and - msmtpq for use by Mutt for outbound mail. -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: My experiences with Mutt to date: Suggestions for overcoming some issues
On Sun, Feb 14, 2021 at 02:43:32AM +0100, Angel M Alganza wrote: >On Sun, Feb 14, 2021 at 02:35:38AM +0100, Angel M Alganza wrote: >>On Sat, Feb 13, 2021 at 08:03:49PM +0000, Sam Kuper wrote: >>> On Fri, Feb 12, 2021 at 01:30:04PM +0100, Angel M Alganza wrote: >>>> On Mon, Feb 01, 2021 at 04:34:47PM -, Grant Edwards wrote: >>>>> I maintained a local queueing MTA for many years, but after >>>>> multiple screwups where mail wasn't getting sent (and I didn't >>>>> find out in a timely manner) I switched to a non-queueing MTA >>>>> (e.g. ssmtp) and later to mutt's SMTP support. >>>> >>>> I did the same myself for years and also switched to ssmtp. But I >>>> belive ssmtp was discontinued, and now I'm using msmtp: >>>> >>>>https://marlam.de/msmtp/ >>>> >>>> I couldn't be happier! >>> >>> A queue script is included with msmtp, so you can have the best of >>> both worlds :) >>> >>> https://git.marlam.de/gitweb/?p=msmtp.git;a=blob_plain;f=scripts/msmtpq/README.msmtpq;hb=HEAD >> >> You proved me wrong: I could be happier! >> And I am, since I'm sending this through the msmtp queue. Yay! >> >> Thanks a lot. > > I'm replying to myself to add: send is super-fast now, instant > actually, from Mutt! I love it! Yes, it's great :) I have CC'd Martin Lambers (author of msmtp). Thank you, Martin :) And thank you to Kevin as always, for Mutt :) -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: How to generate html mime message?
On Fri, Feb 12, 2021 at 10:19:07PM -, Grant Edwards wrote: > After a couple years of that, they turned of the SMTP server, so you > can only use Outlook or the OWA web API. No more using mutt for > work... Off-topic, but DavMail might let you resume using Mutt at work. Or switch jobs, since that employer doesn't seem to be a good one. -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: OT: "domain-level" email hosting services?
On Fri, Oct 22, 2021 at 08:43:02PM -0400, Nathan Stratton Treadway wrote: > So on the theory that there are likely to be other users of advanced > email-server functionality among the Mutt folks, I thought I would ask > here to see if anyone has recommendations for mail hosting services > that target neither "consumer" nor "enterprise" clients, but somewhere > in the middle (and which play nicely with Mutt and other IMAP > clients)? > > For example, a service that allows unlimited "aliases" for a set of > domains, pointing to a handful of "user mailboxes" which actually > receive email? Possibly of interest: https://drewdevault.com/2020/06/19/Mail-service-provider-recommendations.html >From that post, Drew's recommendations are: - https://www.migadu.com/ - https://mailbox.org/en/ Alternatively, the following may do what you need. It's a while since I checked, so some of the below may be out of date. Also, I have not used all these services, so in some cases all I have to go on are notes from when I last researched email hosting. - https://www.dreamhost.com/products/email/ - https://kolabnow.com (at least under their "Group" service) - https://www.neomailbox.com - https://novo-ordo.com - https://www.infomaniak.ch - https://runbox.com Good luck! -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: pretty-print mutt emails
On Mon, Nov 22, 2021 at 12:47:10AM +, Globe Trotter via Mutt-users wrote: > What is the recommended way to pretty-print mutt emails? I found a > sourceforge perl script called muttprint but that was last updated in > 2008, and I was wondering what folks here recommended? On systems without a working muttprint or equivalent, a workaround is to pipe the email to stdin of a program with good support (word-wrapping; pagination; choice of font) for printing plain text files. For instance, on GNU/Linux boxes with Gnome, while viewing the email in Mutt, press the pipe (vertical bar) key on your keyboard, and then type `gedit -` followed by . You can then quickly trim headers to taste, and use gedit's printing options to choose your desired wrapping, pagination, typeface and font size, etc. -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: mutt 2.2.0 released
Thank you from me, too!
Re: Unexplained mutt error
On Tue, Feb 22, 2022 at 04:40:06PM -0600, Ion wrote: > Thanks to all of you for trying to solve my problem. But I have been > trying to setup mutt for nine days now. I have followed all your > advice and instructions to the best of my ability, to no avail. [...] > Much as I want to use a CLI client, Thunderbird, Claws, and Evolution > were able to connect me within 15 minutes ... Have you tried using Getmail (or Fetchmail, or mbsync, or OfflineIMAP, etc - i.e. an MRA (mail retrieval agent)) to get a copy of your mail from your Fastmail server to a local Mbox or Maildir? If you can get that working, then you can just point Mutt at the resulting Mbox or Maildir on your local drive, and read your mail that way: mutt -R -f /path/to/local/mbox/or/maildir I.e. rely only on Mutt's MUA functionality, not its MRA functionality. You might even be able to point Mutt at wherever Thunderbird keeps your local mailstore, depending on how you have Thunderbird configured. I.e. let Thunderbird act as your MRA and use Mutt as your MUA: mutt -R -f /path/to/local/Thunderbird/mail/store Don't give up! -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: How is this spam hiding from mutt search?
On Tue, Feb 01, 2022 at 10:16:51AM -0800, Kevin J. McCarthy wrote: > On Tue, Feb 01, 2022 at 10:36:29AM -0500, Ofer Inbar wrote: >> One feature they all share is that "support_id:" prefix in the fake >> email address. > > The ':' isn't allowed in the address local part, so I believe the mutt > parser is rejecting the email address. Because of that there is no > address stored in the "from" list internally. > > You may have to use something like ~h or =h to find the prefix. I'm going to write the terms "colon", "punctuation", "regex", and "regular expression" here, so that anyone searching the mailing list archives for help with this issue in future will more easily be able to find it. Sam -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Can one get at the current mailbox name (directory)?
On Thu, Jan 27, 2022 at 05:31:01PM +, Chris Green wrote: > Is there a way of accessing the current mailbox name (i.e. for maildir > the directory name) in mutt? IIRC, the caret symbol (^) can be used as a shortcut for the current mailbox. Possibly relevant sections of the manual: http://www.mutt.org/doc/manual/#shortcuts http://www.mutt.org/doc/manual/#folder-hook http://www.mutt.org/doc/manual/#mailbox-hook > This is so I can put it in things like a 'set editor=' > command to pass to the 'editor'. Haven't tried using a caret in such a command myself. Let us know how you get on. Best wishes, Sam -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Colours aspell creating messages
On Thu, Apr 21, 2022 at 05:40:20AM +, Piet wrote: > Am 04/20/ schrieb Francesco Ariis: >> Il 20 aprile 2022 alle 12:54 Piet ha scritto: >>> I use Mutt with aspell to check my texts. >>> >>> Unfortunately the aspell dedections from potential errors are >>> highlighted so strong, that the spelled text itself is not visible. >> >> [...] How do you invoke it? Maybe you are using it /inside/ your >> editor of choice? > > [...] thank you very much for your answer. > > The 'magic key' is my editor vim. > > If I change the vim colorscheme to a fitting other one (in my case > 'desert') everything is fine! Also important, in Vim, to use :set background=dark or :set background=light as appropriate for your terminal. Then most colourschemes should work as intended.
Re: New to Mutt, unable to send messages in *any* attempted way
On Wed, May 11, 2022 at 09:51:28PM +0100, Sam Kuper wrote: > Once you know your shell's quoting syntax, you will see that you can > probably achieve your goal in any of several different ways. Which to > use is a matter of taste. > > E.g. > > '/home/.user.gpg' > > vs > > "~"'/.user.gpg' Sorry, my first example above should have been: '/home//.user.gpg' -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Mailcap selectively applying settings
On Thu, May 12, 2022 at 03:38:23PM -0400, Christopher Conforti wrote: > text/html lynx -dump %s | more > > is seemingly ignored, even when there are no other options given for > handling HTML. I may be wrong, but shouldn't there be a semicolon in that entry? I.e. text/html; lynx -dump %s | more If that doesn't help, please unpack what you mean by "seemingly ignored". E.g. give steps to reproduce the problem. That might help someone on this list get a better handle on troubleshooting with you. Sam -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: ask-yes for sending?
On Tue, Jun 07, 2022 at 08:31:50PM +0200, Marcus C. Gottwald wrote: > bwalton.22...@leepfrog.com asked (Tue 2022-Jun-07 10:26:50 -0500): >> Is there a way to configure my muttrc so that when I press "y" to >> send the message, it will prompt for confirmation before actually >> sending? > > In order to avoid accidentally sending a message because of fat > fingers, I moved from using "y" to "Y": > >bind compose y noop >bind compose Y send-message Instead of having Mutt invoke your MTA, you could have it invoke a script that asks you if you really want to send that email, and that only invokes your MTA if the answer is yes. (You could probably modify msmtp-queue to do this, for instance.) -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: ask-yes for sending?
On Tue, Jun 07, 2022 at 10:26:50AM -0500, bwalton.22...@leepfrog.com wrote: > Is there a way to configure my muttrc so that when I press "y" to send > the message, it will prompt for confirmation before actually sending? Instead of having Mutt invoke your MTA, you could have it invoke a script that asks you if you really want to send that email, and that only invokes your MTA if you answer affirmatively. You could perhaps modify msmtp-queue to do this, for instance. -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Mutt configuration tips
On Tue, Jun 14, 2022 at 03:26:47PM -0400, Christopher Conforti wrote: > * If you could give three tips to a new user, what would they be? Maybe these: - Try a bitmap font, for nice crisp text. (You may have to mess with your X or desktop or terminal configurations, to achieve this. But if you have easy access to a console environment (Ctrl+Alt+F2 or whatever) then you may at least be able to see that the effect would be like, and if it's worth it to you.) - Check out MSMTP, and Getmail. - Pay it forward: if you got Mutt working for you, help a friend to learn Mutt, too! (And maybe learn a few new things in the process.) And a bonus: - Give thanks to Michael Elkins, Kevin McCarthy, and everyone else who produces & maintains great free (as in freedom) software like Mutt.
Re: too many useless warnings
On Wed, Jul 27, 2022 at 05:12:51PM +0100, Darac Marjal wrote: > On 27/07/2022 13:08, Fourhundred Thecat wrote: >> Hello, >> >> when I press key that is not bound, I get following warning in the >> lower left corner: >> >> Key is not bound. Press '?' for help. >> >> this is actually a helpful warning/notification that tells me what is >> going on. Without it, I would be left wondering why my action is not >> being executed. >> >> However, when I press PageDown repeatedly, and land at the end of the >> page, I get a warning: >> >> You are on the last page. >> >> In my opinion, this is absolutely useless and superfluous warning. >> Unlike the first case, this is just bombarding me with useless >> information. I can see the key is working all right, I have just >> pressed it one too many times. > > How do you _know_ the key is working, though? Let's say you're paging > down a mailbox and you press PgDn three times. On two of those > presses, the screen updates within milliseconds, showing you more > records. On the third press, nothing happens. So, what's going on? > > * Did you not press hard enough on the key? > * Did you miscount the number of times you pressed the key? > * Has your SSH connection suddenly frozen? > * Is the IMAP server thrashing and it's still trying to read the >headers for those next messages? > * Or, have you just reached the end of the list and there are no more >messages? > > I'd argue that some feedback is better than none. Unless you've > configured your index with some sort of scrollbar (or an indication > that the cursor is on page X of Y) then I don't see how you can tell > the difference between "mutt hasn't responded to the PgDn key yet" vs > "mutt has done what you asked, but there was nothing to do". This. Mutt is doing the right thing here. Little bits of quiet feedback like this are more helpful than not. Fourhundred: bear in mind that some people use Mutt over potentially unstable/laggy SSH connections, where such feedback is especially important. -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: New to Mutt, unable to send messages in *any* attempted way
Hi X Tec, Not sure if you have read this web page? https://gitlab.com/muttmua/mutt/-/wikis/MailConcept You may find life simpler if, following the advice there, you apply the concept of "separation of concerns". https://en.wikipedia.org/wiki/Separation_of_concerns In other words: - use an MRA such as Getmail, Fetchmail, or Retchmail to retrieve your mail from the server; and - either: - (If you don't need complex filtering) use the MRA's built-in MDA to write the retrieved mail to a local inbox. Ideally, a Maildir directory in some sensible location like ~/inbox ; or - (If you do need complex filtering) use a separate MDA like Procmail or Maildrop to perform that processing and to deliver the mails into relevant Maildirs, e.g. ~/mail/personal and ~/mail/work ; and - use Mutt solely as an MUA; and - use either Postfix as your MTA (if you're already good at Postfix), or perhaps better still, use a lightweight MTA like msmtp, which is much easier to configure and manage, and is more than powerful enough for a typical single user. This way, you are playing to each tool's strengths. You also will be able to troubleshoot more easily under this approach, because MTA-related config should live *solely* within the MTA's config file(s); MUA-related config *solely* within the MUA's config file(s); etc. On Sat, May 07, 2022 at 11:11:35AM -0500, X Tec wrote: > Also, Mutt does not say additional stuff or command line output (just > exit code '0') when sending email... 0 means "success", so that's reasonable. > I'm trying to use Mutt with external MTA/SMTP (Postfix in this case), > as the correct way intended, instead of Mutt's builtin SMTP. > > Am I failing? If so, why? Unsure. Consider a simpler MTA such as msmtp. > By the way, in Mutt default pager for reading emails, your words > between underscores '_' (_not_, _may_, etc...) are not being > displayed... Why? Have you searched the bug tracker? https://gitlab.com/muttmua/mutt/-/issues/ >>> Then how do I know the email is really being sent from >>> u...@domain.tld 's account/SMTP? >> >> Hahahaha! You don't! >> [...] >> > Maybe I'm completely confused and lost... > > If sending email from the webmail, I'm sure it gets send from the > email address account/SMTP. Many webmail interfaces map directly to an underlying email account. I guess that's the situation you've encountered. Not all of them do, though! Some webmail instances let users send email from multiple different accounts, or even from one account via another account's SMTP server! (I'm not making a value judgement here: not saying that one approach is right and the other is wrong. Just stating facts.) > Same if sending from the popular "official" email clients (Outlook, > Thunderbird...) Yes, those clients typically map one email address to one SMTP server. > But *not* sure when sending from Mutt... Correct. Mutt is a MUA. It is a very powerful MUA. It does have some MTA functionality, but it's up to you to configure that functionality (or, perhaps better, configure a standalone MTA) to suit you. > And finally, what key to manually force to check for new mail, instead > of waiting or quitting and starting Mutt again? > > Evidently just doing "any" activity in Mutt does not refresh/fetch new > email... In recent(ish) versions of Mutt, activity (e.g. using a cursor key to move up or down the index) *does* cause Mutt to check for new mail in the currently-displayed mailbox (i.e. mbox or Maildir). That's not the same as fetching mail, though. If you want to *fetch* mail, then you need to invoke your MRA (which could be Mutt, but could also be Getmail, Fetchmail, or Retchmail, etc). Sam
Re: New to Mutt, unable to send messages in *any* attempted way
On Mon, May 09, 2022 at 11:01:20PM -0500, x...@trimaso.com.mx wrote: > [...] In the end, I chose to begin with Msmtp instead of Postfix... > Why? Because after just installation, I realized that Postfix is kind > of "overkill" if just wanting to send: it's designed as a full-blown > server for sending and receiving. Msmtp, on the other hand, is just a > SMTP client; no need to setup a whole server. [...] Good call :) If you're using `msmtp`, you may already have read about `msmtpq`. If not, have a quick look at this thread in case it is helpful to you :) http://lists.mutt.org/pipermail/mutt-users/Week-of-Mon-20210208/002485.html > So first read the Msmtp documentation, and then for sending I first > tried: > > printf "%b\n" "$msg" | mutt -s "Test message" -e 'set > my_user="u...@domain.tld"; set my_url="smtp.domain.tld"; set > record=""; set sendmail="/path/to/msmtp --port=587 --tls=on > --host=$my_url --from="SendUser<$my_user>" --auth=on --user=$my_user"' > recei...@domain.tld > > Incientally "--password" is not a valid command line option; so I was > expecting to be prompted for the password, but instead I got this: > > msmtp: authentication method PLAIN needs a password > msmtp: could not send mail > Error sending message, child exited 69 (Service unavailable.). > Could not send the message. I'm not sure: -Why the command line you gave above did not prompt you for a password. As the msmtp docs ( https://marlam.de/msmtp/msmtp.html ) say, "Password method 5: Do not specify a password. Msmtp will then prompt you for it. This means you need to be able to type into a terminal when msmtp runs." Recent versions of Mutt automatically insert a `--` delimiter between the `sendmail` string and the recipient addresses before invoking the chosen MTA. Perhaps your version of Mutt does not, and perhaps this is somehow causing a problem? Consider adding ` --` (without backticks) to the end of the sendmail string in your example above. - Why you say '"--password" is not a valid command line option'. According to msmtp docs, "all settings can also be configured on the command line", and there is indeed a "--password" option: "‘password [secret]’ Set the password for authentication. An empty argument unsets the password. Consider using the ‘passwordeval’ command or a key ring instead of this command, to avoid storing cleartext passwords in the configuration file." > Even after making a very minimalist .msmtprc with *only* the > "password" line (trying plain password for now just for testing), I > kept getting the above error. I did chmod .msmtprc to 600, BTW. > > So had to make a full .msmtprc according to documentation, and tried > this command: > > printf "%b\n" "$msg" | mutt -s "Test message" -e 'set > my_user="u...@domain.tld"; set my_url="smtp.domain.tld"; set > record=""; set from="Send User<$my_user>"; set envelope_from=yes; set > sendmail="/path/to/msmtp"' recei...@domain.tld > > This time it succeeded. > > > > ---So, do I really need to set password apart in some of Msmtp's other > 4 ways in order to successfully use it? In principle, no. msmtp's method 5 (entering the password manually at the terminal) should work. If you cannot get it to work with your version of Mutt, then try it with your version of heirloom mailx. (Perhaps your version of Mutt, which is very old, has a bug that is somehow causing a problem here?) If for some reason it still doesn't work, then perhaps someone else here will spot the reason why. If not, then *maybe* msmtp has a bug. That said, do you really want to manually enter the password each time you send an email? In the long run, you might be better off using method 1 or 2 instead. > ---To respond a received email in Mutt pager I hit 'r', and all the > rest. I only change the destination email address, and eventually > send. But even after successfully sent, the "responded" email in Mutt > pager is not marked with 'r'. Why? Maybe because in your examples above, you set the record variable to ""? I may be wrong, but: I think that in order for Mutt to know whether a message has been replied to, it checks the mailbox specified by the record variable - so if that variable is empty, Mutt has no way of checking. Sam -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: New to Mutt, unable to send messages in *any* attempted way
On Thu, May 05, 2022 at 11:24:36AM -0500, x...@trimaso.com.mx wrote: > *Beforehand*, if you'll answer just with questions without advise, or > mock, just ban me better. I do have questions, but these are to help understand what might be going wrong. > printf "%b\n" "$msg" | mutt -s "Test message" -e "set > my_user=u...@domain.tld; set my_url=smtp.domain.tld; set from='User'; > set use_from=yes; set smtp_url=smtp://$my_user@$my_url; set > smtp_pass=p4ss; set ssl_starttls=yes; set ssl_force_tls=yes" > recei...@domain.tld > > Could not find the host "" > Could not send the message. Are you able to send email via that account using other applications? If so, which other applications? For instance, have you succeeded with the `mail` application? If you're not sure whether you have the `mail` application installed, try entering at your terminal: which mail > Have to explicitly specify the port; though it varies from ISP to > ISP!? In some I need, in some other I don't! Yes. Whether or not you have to explicitly specify the port may depend on the mail server's configuration. This configuration can vary from ISP to ISP. Thankfully, this shouldn't be a problem once you have debugged your issue, because you can save the relevant details (ports, URLs) in a configuration file so that Mutt will know which details to use for which ISP. > What's the difference between Mutt and Neomutt? Which one preferable? Neomutt is a fork of Mutt. Neomutt is maintained by a different person to Mutt. Neomutt includes various third-party extensions to Mutt, and some other changes. If you want a smaller TCB and simpler configuration, Mutt is probably the best option. If you want fancier features, Neomutt is probably the best option. Given that you are experiencing configuration difficulties, I would suggest trying to overcome those first, perhaps with the help of people on this mailing list. If no success, then maybe try a newer version of Mutt next. (I know you said you can't do it, but where there's a will there's a way.) If, once you've got Mutt working and you've lived with it for a while, you decide you want some features that are more readily available in Neomutt then you could switch to Neomutt at that point - but many people find they are delighted with pure Mutt. Good luck! Sam -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: New to Mutt, unable to send messages in *any* attempted way
On Thu, May 05, 2022 at 03:11:48PM -0500, x...@trimaso.com.mx wrote: > On Thu, May 05, 2022 at 12:07:44PM -0500, Kevin J. McCarthy wrote: >> 1) On the command line, the shell will expand shell variables inside >> double quoted strings, before Mutt even sees it. >> >> So in the part "set smtp_url=smtp://$my_user@$my_url" Mutt is >> probably only seeing "set smtp_url=smtp://@", because $my_user and >> $my_url are unset in your shell. You may want to use single-quotes >> around the whole "-e" expression, but then be careful with nested >> single quotes, e.g. the set from='User' part. > > First: had to delete/rename ~/.muttrc, because some previous settings > were perhaps conflicting... Good call. > This seemed to *finally* work (had to play with both single and double > quotes...): > > printf "%b\n" "$msg" | mutt -s "Test message" -e 'set > my_user="u...@domain.tld"; set my_url="smtp.domain.tld"; set > from="Send User "; set > smtp_url="smtp://$my_user:my_p4ss@$my_url:587"; set > ssl_starttls="yes"; set ssl_force_tls="yes"' recei...@domain.tld > > Finally worked -seemingly- Great! > but popped just many doubts: > > ---There's a "sent email" log in local system, where sent emails are > logged. There's always this line: > Message-ID: < @ > mylocalpcu...@localhost.myisp.com > > Is this correct? Almost certainly, yes. Understandably, you may prefer not to divulge that information to the recipients of your emails. I forget how to effect that for the username part, but for the hostname I think it's as simple as setting Mutt's `$hostname` variable. If you have multiple accounts, you may wish to do that via hooks, e.g.: send2-hook '~f @account1\.net$' 'set hostname = "account1.net"' send2-hook '~f @account2\.com$' 'set hostname = "account2.com"' send2-hook '~f @account3\.org$' 'set hostname = "account3.org"' etc. > ---Without "set from=" field, sender becomes > "mylocalpcu...@localhost.myisp.com"... What is this? That is a default value, derived from your system information. > Does the "from" field kind of guarantee that email is being *really* > sent from the u...@domain.tld address, and not from *local rig*? What do you mean? > ---In "set smtp_url" field, if using "$my_user:my_p4ss" notation, this > seems to override the "set smtp_pass" field completely? Mutt has to make one of those override the other. Otherwise, what would Mutt do if a user specified one password in $smtp_url and a different one in $smtp_pass? > ---Seemingly not needed smtp_authenticators... ?? What do you mean? > ---Without smtp_url and smtp_pass fields, where does email go? > recei...@domain.tld doesn't receive it... Depends on your system configuration. Have you looked in /var/mail/ ? > ---Is email really being sent with STARTTLS, as wanted? How can I > tell? Wireshark? :) Probably there are easier ways - someone else might have suggestions. Perhaps setting debug level to `-d 5` would give you the information you need? > ---In "set from=" field, spaces between "Send User" and actual email > address... don't seem to matter? > > > >> Are you able to send email via that account using other applications? > > Yes, I used to use Heirloom Mailx. Thanks for confirming. >> Yes. Whether or not you have to explicitly specify the port may >> depend on the mail server's configuration. This configuration can >> vary from ISP to ISP. > > I didn't mean email provider, but ISP internet service I'm connected > to. > > And did test again: I connected to an internet network, did not > specify port in smtp_url, tried send email, and got: Could not connect > to smtp.domain.tld (No route to host) Tried connecting to a different > internet network, tried to send email using *exact* command, without > port, and *it succceeded*. > > WTH? Does that behaviour happen consistently? I.e. with one ISP connection *never* succeeds without specifying the port, and with the other ISP it *always* succeeds without specifying the port? If so, then that is puzzling. Hopefully someone else on this list can offer a hypothesis. Anyway, congratulations on your progress! Sam -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: New to Mutt, unable to send messages in *any* attempted way
On Wed, May 11, 2022 at 10:54:19AM -0500, X Tec wrote: > Managed to briefly test in a more updated rig with Mutt 2.2.4 and > Msmtp 1.8.11. Good job. I'm in haste, so am skipping over the msmtp password oddness. Maybe another list subscriber will take that up. > The passwordeval with gpg method also works, albeit I wasn't able to > figure out how to use it directly in command line... Trying to use > > set sendmail="/usr/bin/msmtp [...] --passwordeval="gpg --no-tty -q -d > ~/.user.gpg"" > > got this: > > Error in command line: --no-tty: unknown variable > gpg: WARNING: no command supplied. Trying to guess what you mean ... > gpg: processing message failed: Unknown system error > msmtp: cannot read output of 'gpg' > Error sending message, child exited 78 (). > Could not send the message. > > I did figure it's an issue with wrongly used quotes (and the gpg > command needs them), but still haven't been able to solve it... https://tldp.org/LDP/abs/html/quotingvar.html https://mywiki.wooledge.org/Quotes Once you know your shell's quoting syntax, you will see that you can probably achieve your goal in any of several different ways. Which to use is a matter of taste. E.g. '/home/.user.gpg' vs "~"'/.user.gpg' If you still find yourself stuck (or even if you don't), you might want to try using Pass as a wrapper around GPG: https://en.wikipedia.org/wiki/Pass_%28software%29 > On 2022-05-11 09:03:56, Cameron Simpson wrote: >> On 10May2022 07:25, Sam Kuper wrote: >>> On Mon, May 09, 2022 at 11:01:20PM -0500, x...@trimaso.com.mx wrote: >>>> ---To respond a received email in Mutt pager I hit 'r', and all the >>>> rest. I only change the destination email address, and eventually >>>> send. But even after successfully sent, the "responded" email in Mutt >>>> pager is not marked with 'r'. Why? >>> >>> Maybe because in your examples above, you set the record variable to >>> ""? >>> >>> I may be wrong, but: I think that in order for Mutt to know whether >>> a message has been replied to, it checks the mailbox specified by >>> the record variable - so if that variable is empty, Mutt has no way >>> of checking. >> >> I thought it just set a flag on the message. >> >> I forget, is XTec using a local or IMAP mail folder? > > Current IMAP settings (using Starttls): > set folder = "imap://u...@domain.tld@smtp.domain.tld" > set spoolfile = +INBOX > mailboxes = +INBOX > > Also, > set record = "" > set date_format = "%F %T" > set index_format = "%4C %Z %D %-15.15L (%?l?%4l&%4c?) %s" > set sort = reverse-date > > By using '$' I just get "Mailbox is unchanged", even when I know there > are new messages. The only thing that *seemed* to work was "bind > index G imap-fetch-mail" in .muttrc. With this, I could use 'G' to > refresh for newly received emails Still, I kind of expected a > "default" key for that... > > > > ---Just like Msmtp, if the better idea is to not store passwords in > plain text, doesn't Mutt have some type of password "masking" or > something? With GPG, hashed into another file somewhere else, etc... Yes, Mutt does have a way to achieve that. I hate so say "Read The Friendly Manual", but within https://www.mutt.org/doc/manual/#muttrc-syntax you will find this example: set imap_pass="`gpg --batch -q --decrypt ~/.mutt/account.gpg`" https://www.mutt.org/doc/manual/#ex-backtick-dblquotes Best, Sam -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Visualising contents of a Maildir
On Fri, Aug 19, 2022 at 09:08:01AM +0200, martin f krafft via Mutt-users wrote: > Regarding the following, written by "Victor Goff" on 2022-08-18 at 20:09 Uhr > -0400: >> I have used https://tmate.io for those on Windows and those with a >> small amount of experience with computers in general. Since you can >> share a browser, and they can either type with you or not, and they >> do not necessarily need to even generate ssh keys, this is a point >> of allowing that to happen easily. > > Nice, but this isn't going to be a live presentation, so it really has > to be a PDF. Well, you could: - set up Mutt instance as previously suggested (e.g. use muttrc/whatever to capture key-presses other than Up, Down, PgUp, and PgDn), on an internet-connected machine that can accept SSH connections - log in to Mutt instance via tmate.io or other web-based SSH gateway - share link (URL) to intended recipients.
Re: Having problems with POP3 setup
On Mon, Aug 29, 2022 at 03:14:21PM -0500, X Tec wrote:
> I think I kind of sorted the "not a mailbox" issues: each mailbox
> seems to have its own defined directory tree, which will give the
> aforementioned error if not found, or will alternatively be created
> but only when the mailbox is really being used for the first time. So
> I had to do this: mkdir -p
> $HOME/mutt/mail/{inbox,sent,trash}/{cur,new,tmp}
>From memory, that seems about right.
> Now, could someone really help with the other issues, please? Thanks
> again.
>
> On 2022-08-27 11:53:50, X Tec wrote:
>> After exploring all possibilities I could with IMAP, I felt like it
>> was time to give POP3 a try. So tried the following: set
>> pop_user="$user"; set pop_pass="$pass"; set
>> pop_host="pop://$user@$url" set pop_delete=no; set pop_last=yes; set
>> mbox_type=Maildir; set folder=~/mutt/mail; set spoolfile=+inbox; set
>> record=+sent; set trash=+trash; mailboxes +inbox +sent +trash; set
>> ssl_force_tls=yes
>>
>> But it's not working:
>>
>> ---It creates $HOME/mail/, but just "$HOME/mail/inbox is not a
>> mailbox". Ctrl+O to this mailbox gives the same, until hitting 'G'
>> key to fetch email.
Seems like you resolved this issue.
>> ---Fetching email with 'G' key just ignores the "pop_last=yes"
>> setting because it always downloads all email regardless of locally
>> read or not, even though other clients such as Outlook or Thunderbird
>> don't do this mistake. So I don't think server doesn't support the
>> LAST command...
Which version of Mutt are you using?
Hopefully someone else will help.
Alternatively, you could try Getmail by Charles Cazabon, which works
well with Mutt and provides the functionality you are seeking here.
https://pyropus.ca./software/getmail/
>> ---When trying to open the other mailboxes I just get the "not a
>> mailbox" message, either with Ctrl+O or 'G', even if I manually
>> create the corresponding directories
Seems like you resolved this issue.
>> ---A more general thing: what are Ctrl+O ("open mailbox")
In the Mutt manual, the only mention of ^O that I can find is:
^O send attachment with a different name
>> and '$' actually for? [...]
`$` writes pending changes to disk.
>> ---Finally, on IMAP, different email providers seem to have totally
>> different ways to specify their subfolders for the variables $sent,
>> $drafts...: "INBOX.sent", "[Gmail]/Sent Mail", etc. Then how am I
>> suppose to find out which syntax each email service uses?
I believe there are ways to query IMAP for a list of (sub)folders.
Hopefully someone else will help with this.
As an aside: massive corporations who rely on lock-in to retain
customers - e.g. Google (Gmail) and Microsoft (Outlook365, or Live, or
Hotmail, etc), and perhaps Yahoo - seem more likely to have non-standard
IMAP setups on their servers.
"Traditional" email providers are typically more consistent with each
other, and with IMAP standards. Probably because under the hood they
typically run Dovecot, Cyrus, or Panda IMAP (Mark Crispin's post-UW fork
of UW IMAP).
So, to avoid dealing with non-standard IMAP setups, a reasonable
strategy is to avoid the megacorps.
Ideally, find an affordable email provider you like, and support them
by using (and ideally, paying for) their services.
Sam
Re: Visualising contents of a Maildir
On Thu, Aug 18, 2022 at 10:10:38AM +0200, martin f krafft via Mutt-users wrote: > The reason I need this index is that I have to provide evidence of "a > huge volume of mails" on a given topic, without actually sharing the > emails. OK, but... > So I need a PDF index. That is a non-sequitur. In another branch of this thread, I proposed several ways to provide the evidence you need, without sharing the emails AND without creating PDFs. So, unless achieving a PDF is a *requirement* (in which case it might have been helpful to mention that in the first place!), generating a PDF just seems to be an unnecessary headache. > Hence I thought making an HTML table, and then printing that. Easiest. Maybe. Or you could use a lightweight markup language (lighter than HTML) that has tables, and a relevant PDF generator for that markup language. If you like that idea, here's a handy table showing which lightweight markup languages have tables: https://en.wikipedia.org/w/index.php?title=Lightweight_markup_language=1104650806#Comparison_of_language_features and here's another useful table showing which lightweight markup languages also offer PDF output: https://en.wikipedia.org/w/index.php?title=Lightweight_markup_language=1104650806#Comparison_of_implementation_features > A screenshot/bitmap approach would be very hard to turn into a useable > PDF, I think. Depends what you mean by "usable". If all you need is e.g. an image per PDF page, several tools can trivially achieve that (e.g. `img2pdf`). Some tools can also compress the images for you, or you can pipe the images via compression tools before assembling the PDF, to avoid creating a humungous PDF. > Sam is right, threads are digraphs, but Mutt displays them in a table, > and I think that's a good compromise. Fair point, if you're also going to capture the ASCII art that indicates the thread structure. >> I don't think it will be better or easier than what you've done. >> But you could try using a '|' filter in $index_format to append some >> output to a file as a side effect. It would still entail manually >> pgdn'ing through the index. > > Not a bad idea, but unfortunately, the Unicode characters used to > represent threads in mutt's index seem to be some sort of > ncurses-special, and the whole thing would need parsing. But this is > definitely an interesting approach, as I could probably craft an > `$index_format` that generates HTML ``'s, and PgDn'ing over a > thousand messages might be something the X repeat buffer can do. ;) If you find a lightweight markup language that has PDF output AND has table markup tags that correspond one-to-one with the '|' filter's ncurses strings, then you could use the `|` filter as Kevin proposes above, and pipe the output through sed to replace the ncurses strings with lightweight markup language strings. If you really need PDF output, then this may well be the best approach. All best, Sam
Re: Visualising contents of a Maildir
On Wed, Aug 17, 2022 at 04:59:41PM -0500, Derek Martin wrote: > On Wed, Aug 17, 2022 at 09:33:44PM +0000, Sam Kuper wrote: >> On Wed, Aug 17, 2022 at 09:22:31PM +0200, martin f krafft via Mutt-users >> wrote: >> > For reasons you don't want to know, >> >> You may be underestimating the curiosity of your audience. > > I suspect what Sam really meant was, "For reasons that would make you > sad if you knew..." =8^) I think you mean Martin rather than Sam, but that's OK :) >>> Is there a way to "screenshot" the Mutt index beyond the scroll >>> window? >> >> Why would you need to? In what way does Mutt itself not meet your >> requirements? > > Presumably because in order to *share* such a visualization, i.e. with > someone remote, they would have to have a copy of the inbox AND run > Mutt. Or they could just use SSH. If the person viewing the visualization should be prevented from modifying the inbox, then Mutt could be invoked with the `-R` (read-only) option. If the person viewing the visualization should be prevented from seeing the *content* of any of the mails in the inbox, then either: 1. Configure the muttrc, or the shell hosting Mutt, or Mutt itself (edit source and recompile), to intercept and discard any keypresses other than the ones for scrolling up and down Mutt's index. I'd probably attempt those options in that order. 2. Alternatively (or additionally), the underlying message files in the Maildir on the filesystem could be stripped, using a script (Python, Bash, whatever) of all but their headers. This would have some perhaps undesirable side-effects, though: it would affect some fields displayed in Mutt's index view, such as the number of attachments. I probably wouldn't bother with this unless the underlying messages' contents were especially sensitive (e.g. sensitive personal or commercial information). 3. Alternatively (or additionally) again, those underlying message files could instead have their content and attachments replaced by an equivalent quantity of Lorem Ipsum, to at least keep file sizes and number of attachments constant. I probably wouldn't bother with this unless the underlying messages' contents were especially sensitive (e.g. sensitive personal or commercial information) AND the file size / number of attachments metadata were of interest. > Presumably what you'd want is an image or document that contains the > desired visualization, that can be displayed by some common tool > available to the general community, like a web browser, > company-installed word processor or similar productivity app, etc.. SSH is very widely available. It's installed by default on GNU/Linux, and most Unixes including macOS. It is available for Windows via PuTTY or Windows Subsystem for Linux. > Mutt could still meet the need, though it would be some work. You > could screenshot each individual page of the index, and then use an > image editing program to assemble them together. Maybe--if the > resulting image was not too large for your application to handle. Or > you could just paste each image into a document in a word processor, > one image per page... Or use tmux or GNU Screen to copy/paste into a text document? But still, creating a whole new interface onto the index view from scratch seems over-elaborate when Mutt's index view already works perfectly well. > It might be possible to create a virtual desktop large enough to > display the entire index at once, and then use imagemagick or similar > to capture the window to a file, but I suspect there again you may run > into memory problems. Or, again, use tmux or GNU Screen to copy/paste from the virtual desktop into a text document? Again, though, building a whole new interface onto the index view from scratch seems over-elaborate when Mutt's index view already works perfectly well. Sam
Re: Visualising contents of a Maildir
On Thu, Aug 18, 2022 at 10:45:04AM +0100, Sam Kuper wrote: > If you find a lightweight markup language that has PDF output AND has > table markup tags that correspond one-to-one with the '|' filter's > ncurses strings, then you could use the `|` filter as Kevin proposes > above, and pipe the output through sed to replace the ncurses strings > with lightweight markup language strings. > > If you really need PDF output, then this may well be the best > approach. This approach (lightweight markup + sed) might also work with Bastian's suggestion, in another branch of this thread, to use stdout instead of the `|` filter. Sam
Re: Identifying messages with no To: or CC: headers?
On Fri, Sep 02, 2022 at 04:03:22PM -0400, John Hawkinson wrote: >> Could you not prepend your EXPR with something like this? >> >> `^(Delivered|Envelope)-To:\ ` > > I belive that you want this to be all-lowercase, because those headers > can be any case, and mutt will search case-insensitively per sec. 8.3 > of the manual: > >> As for regular expressions, a lower case string search pattern makes >> Mutt perform a case-insensitive search except for IMAP (because for >> IMAP Mutt performs server-side searches which don't support >> case-insensitivity). Good catch, thanks! -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Postponing and forwarding
On Wed, Aug 31, 2022 at 11:51:24AM -0500, X Tec wrote: > When composing an email, I decided to postpone instead of immediately > send. It got saved in Drafts folder, but when deciding to send it, I > opened the draft, but there's no "send" option; just the usual > respond, new email, and the other options when opening any other > message. Then how am I supposed to "send" drafts, without having to, > say, use the "respond" option again? Please read the Mutt manual. Especially note the "Postponing mail" section... http://www.mutt.org/doc/manual/#postponing-mail ... the $recall variable ... http://www.mutt.org/doc/manual/#recall ... and the function that is available from the Index menu and the Pager menu: http://www.mutt.org/doc/manual/#index-map i http://www.mutt.org/doc/manual/#pager-map > Also, how can I *forward* messages to other users? Again, please read the manual. The function is available from the attachment menu, the index menu, and the pager menu. N.B. If you want to forward attachments too (or multiple parts of a multi-part message), you need to enter the attachment menu and select the parts/attachments that you wish to forward. Good luck, Sam
Re: in search of OAuth2 tokens for Microsoft Office 365
On Wed, Oct 26, 2022 at 08:36:49PM -0600, Jon Brinkmann via Mutt-users wrote: > [...] I configured my university account to send copies of all my > email to my Apple iCloud mail, which does support app passwords. > > https://support.apple.com/en-us/HT202304 > https://forums.freebsd.org/threads/mutt-with-icloud-mail.44264/ > > It works well. I had a bit of work to extract mail messages that > Microsoft Exchange rejects with error status codes, e.g., SPF > validation error, to many hops, sender's DMARC policy. I wrote a > short Perl script to extract and restore the attachment containing the > original message. It's processed thousands of rejected messages with > no problems. Is your Perl script published anywhere? If so, would you mind replying to this thread with a link to it? Alternatively, if it isn't published, please could you reply to the list with a copy of the script as an attachment (or, if this list doesn't allow attachments, then in the body of the email). (Office365/etc problems arise frequently enough, as a topic on this mailing list, that it would be good for the list archive to contain comprehensive pointers to resources to help those poor souls unfortunate enough to have to battle this particular abomination from Microsoft's long line of abominations...) Thanks! Sam
Re: The way mutt handles long lines, seems odd/wrong to me
On Sat, Oct 01, 2022 at 09:33:16AM +0100, Chris Green wrote: > On Sat, Oct 01, 2022 at 01:24:37PM +0800, Kevin J. McCarthy wrote: >> In [the] past, I've tried a few things to see if it has an effect on >> the output of long lines, but haven't found anything that makes a >> difference. In the end, I believe it's a side effect of how ncurses >> works. > > Yes, I realise this issue has been looked into before, and no solution > found. [...] I'll have a talk with Tom Dickey who is the maintainer of > both vile and ncurses, he may be able to throw some light on this. Workaround: while viewing an affected email in Mutt, press the vertical bar key (`|`) and then type `less`. This will pipe the email to Less - which, as you've noted, is unaffected by the issue. You can then select URLs or other long whitespace-free text strings per your terminal's normal behaviour. (You probably already knew this! But I'm mentioning it in case not, or in case helpful for anyone else reading this thread.) Cheers! Sam
Re: Identifying messages with no To: or CC: headers?
On Fri, Sep 02, 2022 at 06:24:24PM +, Tim Chase wrote: > On 2022-09-02 20:07, Francesco Ariis wrote: >> Il 02 settembre 2022 alle 18:01 Tim Chase ha scritto: >>> However, often these messages don't have a To: or CC: header, so I >>> can't identify them with a ~C and I don't see an option for >>> identifying messages by the Delivered-To or Envelope-To headers. >>> >>> Is there a good way to identify these messages? >> >> Check ~h and =h, it those don???t do, consider filtering with your >> mail retriever (e.g getmail, that is what I use). > > Hmm, that looks like it might work. Is there further documentation > on the ~h beyond this: > > http://mutt.org/doc/manual/#tab-patterns > > It seems to mostly do what I want, but I don't see a way to limit > it to just the Delivered-To/Envelope-To headers, As Obi-Wan Kenobi didn't say, "Use regular expressions, Luke!" Could you not prepend your EXPR with something like this? `^(Delivered|Envelope)-To:\ ` (Remove the backticks, of course. But don't forget the space after the backslash.) WFM. Sam -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Having problems with POP3 setup
On Fri, Sep 02, 2022 at 01:11:53PM -0500, X Tec wrote: > On 2022-08-31 11:46:15, X Tec wrote: >> On 2022-08-30 18:34:42, Kevin J. McCarthy wrote: >>> On Mon, Aug 29, 2022 at 03:14:21PM -0500, X Tec wrote: Fetching email with 'G' key just ignores the "pop_last=yes" setting because it always downloads all email regardless of locally read or not, even though other clients such as Outlook or Thunderbird don't do this mistake. So I don't think server doesn't support the LAST command... >>> >>> Run with debugging enabled (-d 2) and check the log file to see >>> what the LAST command response is from the server. Since the >>> command was deprecated some time ago, I would venture the server is >>> returning an unknown command error. >> >> With debugger I saw this line: "-ERR Unknown command: LAST"; so I >> think you were right once again... OK, so that's that mystery resolved. >>> Mutt's POP3 support *is* simple, so if LAST isn't supported, the >>> behavior you are seeing with is expected. >>> >>> You may be happier just directly connecting to a pops:// URL via >>> one of your mailboxes instead; or with a more sophisticated tool, >>> such as Getmail (which Sam mentioned). >> >> So if I wanted this function, or the one of "keep messages in server >> for x days", would I need another external POP3 mail fetcher? Yes. There is one caveat. If the POP3 server is totally kooky, then even Getmail or suchlike might be unable to extract the desired behaviour from it. Fortunately, nothing so far seems particularly kooky about the POP3 server in your case. >> I did read in the Mutt wiki that Mutt originally didn't intend to >> have native SMTP support, but it ended up (reluctantly?) being added >> eventually; which is why I decided to learn Msmtp as well. However, I >> was unable to find any proof of this being the same case for IMAP and >> POP3, and I searched the whole wiki and docs. So I thought "so unlike >> SMTP, Mutt has always been supposed to support IMAP and POP3 >> natively". >> >> But then, must I understand that this is *not* the case for POP3? > > Could someone still help with these issues please? Mutt *does* support POP3, but as Kevin pointed out above, its POP3 support is simple, i.e. basic. If you want a more sophisticated MRA (i.e. POP3 client), then a third-party MRA such as Getmail will likely suit you better. Mutt roughly adheres to the Unix philosophy - "Make each program do one thing well." Mutt is an *amazing* MUA. It does not excel at anything else. (Nor should it.) Yes, Mutt has MRA and MTA capabilities, but these are limited. It is *good* that these capabilities are limited because that keeps the codebase, and the consequent bug surface and attack surface, small. (Purists might argue that Mutt should not have MRA or MTA capabilities at *all* - but for better or worse, the pragmatists who argued Mutt should have limited MRA and MTA capabilities got their way.) So, if you want an *amazing* lightweight MTA to sit alongside Mutt, msmtp is a great choice - and it seems you made that choice. Ace! Similarly, if you want an *amazing* lightweight MRA to sit alongside Mutt, Getmail is a great choice. Good luck, Sam -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: setting up subscribed groups
On Fri, Aug 05, 2022 at 07:19:34AM -0400, Jude DaShiell wrote: > Very basic question ahead. In man muttrc subscribe [group-name] > [regexp] [regexp] has two regexp entries beside it. how are those > used correctly to subscribe mutt-users and other groups? It's a bit unclear what you are asking. If you are asking "what does 'regexp'" mean, it's short for "regular expression". "regex" is also short for "regular expression". For more information, try entering man 7 regex at your command line. If, instead, you are asking, why are there *two* "[regexp]" entries in the syntax of the "subscribe" command, note the correct syntax: subscribe [-group name] regexp [ regexp ... ] The square brackets indicate optional paramenters. I guess (but others may correct me) that reason the "subscribe" command allows for more than one regular expression as its parameters, is to allow for cases where, for instance, the user wishes to inform Mutt of subscriptions to: - multiple mailing lists, by using a single invocation of the "subscribe" command; or - a single mailing list that (unusually) uses multiple different list addresses. Sam
Re: Using several SMTP servers
On Thu, Aug 11, 2022 at 06:23:56PM +0200, Sébastien Hinderer wrote: > So far I use exim4 to send e-mails but I didn't see a way to specify > which "smarthost" to use to send e-mails e.g. on the sendmail command > line. So, even if I could use mutt send hooks to choose which SMTP > configuration to use based on my From address, I don't know how to > pass this information to the MTA and I am assuming this should not > even happen. > > One other alternative may be to let mutt send e-mails to SMTP servers > itself, directly, without going through sendmail/exim4, but then I am > wondering what is going to happen if I try to send an e-mail while my > computer is off-line. Am I correct that mutt has no queue or > whatsoever that would allow it to defer sending e-mails until the > computer is back online, which is exactly what the MTA does? > > I can't come up with a satisfactory solution and would really > appreciate feedback on this topic. Consider using msmtp for sending, and msmtp-queue for queueing: https://lists.mutt.org/pipermail/mutt-users/Week-of-Mon-20210208/002485.html Sam
Re: Using several SMTP servers
On Fri, Aug 12, 2022 at 07:01:52PM +0200, Sébastien Hinderer wrote: > 1. Am I correct that it will be possible, when calling smstp-queue, to > specify which smarthost to use? > > In other words, am I correct that this will let me associate one smart > host (SMTP configuration) to each mail in the queue, rather than using > the smae smarthost for allthe mails in the queue? CASE 1 IIRC, msmtp can be configured to use a different smarthost per *email address*. (To emphasise: you would set that up in msmtp's config, not in msmtp-queue's config. msmtp-queue doesn't really have or need much configuration.) So, if that's what you meant, then yes, it's possible. CASE 2 If, instead, you want to be able to choose, per outgoing *email* (rather than per *email address* of yours), which smarthost to use, then I think you would have to either: - write a wrapper for msmtp-queue to give you an interactive menu for choosing which smarthost to use for each outgoing email you send, or - rewrite your installed msmtp-queue script to give you such a menu. The menu part (UI) isn't so hard, but implementing the underlying functionality would be a bit more work. > 2. I think one of the things for which exim is used is the local > delivery of e-mails. So for instance thee-mails from the cron user are > delivered to root, but then the e-mails from root are delivered to my > main local user account and I think it's exim which deals with this > bit Yes, lots of GNU/Linux boxes are set up like that by default. > and I probably won't touch that, unless I have to. Quite right. > Also, there is a subtlety that I'll need to figure out, on Debian. > there are two packages: msmtp and msmtp-mta. the second one conflicts > with exim son both can not coexist on the same system (they both > provide the mail-transpor-agent package). At least that's my > understanding. > > Indeed if I try to install msmtp-mta it wants to remove 7 packages: > exim4 exim4-base exim4-config exim4-daemon-light libgsasl7 > libmailutils6 libmu-dbm6. So I'll start with msmtp alone and see what > happens, perhaps. Alternatively, just install msmtp outside of Debian's package management system? msmtp is (by design, I believe) quite lightweight/standalone, so it's a good candidate for that approach. Good luck, either way! Sam
Re: Using several SMTP servers
On Fri, Aug 12, 2022 at 04:05:55PM +0200, Sébastien Hinderer wrote: > Hello Sam, many thanks for your interesting response! :) > Sam Kuper (2022/08/11 17:43 +): >> Consider using msmtp for sending, and msmtp-queue for queueing: >> >> https://lists.mutt.org/pipermail/mutt-users/Week-of-Mon-20210208/002485.html > > My understanding is that, on one side, mutt would call msmtp-queue as > a replacement for sendmail Yes > and that, on the other side, msmtp needs to somehow be called on a > regular basis to try to send the messages that are in the queue, if > network is available. Is this understanding correct? `msmtp-queue -r` tells msmtp to try to send the emails from msmtp-queue's queue to your mail provider's SMTP server. In order for that to succeed, you need to have a network connection - otherwise the attempt will time-out and the queued mails will stay in msmtp-queue's queue so that you can try again later. So, you can: - Manually run `msmtp-queue -r` when you know you have an internet connection, or - Set up a cron-job to run `msmtp-queue -r` according to your preferred schedule (e.g. every 2 minutes), or - Some combination of the two (i.e. have a cron-job set up, but manually invoke `msmtp-queue -r` on occasions when you don't want to wait for the next cron time-point). It's your choice. > Also, given how important e-mail is, I am a bit worried about the > transition: any advice on how to switch from exim4 to this new set-up > as smoothly as possible and without risking to be unable to send > e-mail for some time? Here is what I would do in that situation: - Read msmtp and msmtp-queue's documentation. - Install and configure msmtp. - Test/tweak/re-test msmtp until working. (E.g. using Mutt or GNU Mailutils's `mail` command to send emails from the command-line, with relevant command-line options set so as to ensure that msmtp is used as the MTA). Hopefully it would work first time, if configured correctly and if your computer has a suitable internet connection. - Install msmtp-queue (it comes bundled with msmtp IIRC) and configure it, including setting up a cron-job if you want one. - Test/tweak/re-test msmtp-queue (similarly to testing msmtp). - Edit your muttrc to tell Mutt to use msmtp-queue instead of Exim. - Check to see if you have anything else installed that depends on Exim. - If so, either leave it as is (probably) or find another solution for those things (if you really want to - but Exim is good for its intended use case). - If not, then uninstall Exim. Good luck! Sam
Re: Using several SMTP servers
On Fri, Aug 12, 2022 at 08:53:23PM +0200, Daniel Tameling wrote: > On Fri, Aug 12, 2022 at 03:58:02PM +0000, Sam Kuper wrote: >> - Test/tweak/re-test msmtp until working. (E.g. using Mutt or GNU >> Mailutils's `mail` command to send emails from the command-line, >> with relevant command-line options set so as to ensure that msmtp >> is used as the MTA). Hopefully it would work first time, if >> configured correctly and if your computer has a suitable internet >> connection. > > You can check whether msmtp is working with just the echo command. Good point - I had forgotten that. Thanks! Sam
Re: Using several SMTP servers
On Fri, Aug 12, 2022 at 10:57:41PM +0200, Sébastien Hinderer wrote: > As I see it, the SMTP configuration to use is fully determined by the > from address of the mail to be sent. > > [...] there shouldn't be any need for interactivity. For each outoging > mail, pick up the right SMTP config based on who (which address) is > sending (From header). As simple as that, I think. Great! In that case, msmtp and msmtp-queue can handle your requirements without modification. Just populate the config files per your needs, set up a cron job if you want it, and hopefully your SMTP woes are over! Sam
Re: mutt, imaps and OAuth2
On Thu, Aug 04, 2022 at 09:40:03AM +0200, Sébastien Hinderer wrote: > I am about to work for an organization whose e-mails are managed by > Google. Commiserations. > I tried to configure mutt to read those e-mails, in particular to make > the OAuth2 authentification method work for imaps [but so far, that > has not succeeded]. Others will be better placed to help you *fix* this. (I'm not a Google customer myself.) As a *temporary workaround*, maybe see if you can edit the GMail/GoogleMail settings so that a copy of each incoming email is forwarded to an email address you control that is hosted by a standards-compliant (and therefore Mutt-friendly) email hosting company. IIRC, the GMail settings interface has an option for this - or failing that, you can create a catch-all "filter" with a rule to forward the emails. That will at least get your inbound mails into Mutt. (Perhaps, as an adjunct to that workaround, if you are lucky, you will manage to get outbound email working directly from Mutt via GMail, so that you can also *send* work emails from Mutt.) Good luck! Sam
Re: mutt, imaps and OAuth2
On Thu, Aug 04, 2022 at 12:14:04PM +0200, Matthias Apitz wrote: > El día Donnerstag, August 04, 2022 a las 10:07:47 +0000, Sam Kuper escribió: >> As a *temporary workaround*, maybe see if you can edit the >> GMail/GoogleMail settings so that a copy of each incoming email is >> forwarded to an email address you control that is hosted by a >> standards-compliant (and therefore Mutt-friendly) email hosting >> company. IIRC, the GMail settings interface has an option for this - >> or failing that, you can create a catch-all "filter" with a rule to >> forward the emails. > > Be prepared to run into troubles sending mails to GMail/GoogleMail. > Google requires very special DNS configs to accept mails for their > users. I gave up on this and do not send any mails to Google users > anymore. I don't see how these remarks relate to my suggestion above? Best regards, Sam
Re: mutt, imaps and OAuth2
On Thu, Aug 04, 2022 at 02:51:14PM +0200, Matthias Apitz wrote: > El día Donnerstag, August 04, 2022 a las 12:23:08 +0000, Sam Kuper escribió: >> On Thu, Aug 04, 2022 at 12:14:04PM +0200, Matthias Apitz wrote: >>> El día Donnerstag, August 04, 2022 a las 10:07:47 +, Sam Kuper escribió: >>>> As a *temporary workaround*, maybe see if you can edit the >>>> GMail/GoogleMail settings so that a copy of each incoming email is >>>> forwarded to an email address you control that is hosted by a >>>> standards-compliant (and therefore Mutt-friendly) email hosting >>>> company. IIRC, the GMail settings interface has an option for this - >>>> or failing that, you can create a catch-all "filter" with a rule to >>>> forward the emails. >>> >>> Be prepared to run into troubles sending mails to GMail/GoogleMail. >>> Google requires very special DNS configs to accept mails for their >>> users. I gave up on this and do not send any mails to Google users >>> anymore. >> >> I don't see how these remarks relate to my suggestion above? > > The relation is: once you have the enail downloaded from another > hosting provider and you want reply upstream through it to > GMail/GoogleMail recipients ... So... your comment *doesn't* relate to my suggestion above - which was about how to get *inbound* emails from Gmail/GoogleMail into Mutt. Sam
Re: Visualising contents of a Maildir
On Wed, Aug 17, 2022 at 09:22:31PM +0200, martin f krafft via Mutt-users wrote: > For reasons you don't want to know, You may be underestimating the curiosity of your audience. > I have to visualise a Maildir with a couple of thousand messages, i.e. > essentially provide a mutt-style index with correspondents, dates, > subjects, and threading, So far, so good. Use Mutt. It does this very nicely. (I'm not trying to be facetious - even with my repetitive answers below. This is a use-case for which Mutt is genuinely well-suited.) > ideally in form of an HTML table. This is puzzling, as follows: - Tables are tabular. - Threads are digraphs (usually polytrees - although in principle a single message can be a reply to *multiple* earlier messages). So there seems to be something of a topological mismatch between your intended input data structure and your intended output data structure. > Apart from the threading, Python's email module can do most of the > work, and combined with e.g. Jinja templating, I should be able to get > results quickly, but since I don't like reinventing wheels, I was > wondering if maybe you had a better idea? Again, Mutt does this very nicely. Why not just use Mutt? > Is there a way to "screenshot" the Mutt index beyond the scroll > window? Why would you need to? In what way does Mutt itself not meet your requirements? > Or can you think of command-line tools that visualise threads? Again: Mutt. (Emacs can do this, too. Probably there are other tools as well.) > Notmuch, which I use, can very quickly list all the threads, including > the count of messages, but I actually need to list to be *really big* > and not condensed, for reasons you don't want to know. > > I can make notmuch output json with threading, and then process that > with Python to create a list, but maybe there's a better tool? Again, why not just use Mutt? Sam
Re: Deleting large number of emails from busy mailbox
On Wed, Mar 15, 2023 at 08:47:44AM +0100, Vegard Svanberg wrote: > Multi-threaded GUI version coming up any time soon? ;-) Let's hope not. That would massively increase Mutt's attack surface and the burden on its maintainer. People who really want to expose themselves to the risk that multi-threaded GUI email clients typically entail, and who are fine with headaches for maintainers, already have several options to choose from. Cheers.
Re: Forward with attachments
On Tue, Apr 18, 2023 at 04:02:36PM -0500, Jason wrote: > 3. Open attachment view, tag all attachments including body, do 'tag > prefix' then 'forward', and select 'no' when asked whether to send as > attachments. This seems to do what I want for the most part, body text > is included in body and regular files are attached, Last time I checked (admittedly, a long time ago), this was the right way to do it. Perhaps someone will chime in with some muttrc settings to reduce the number of keystrokes needed. > although I'm not sure what happens if some of the attachments happen > to be plain text files. Will it dump those into the body as well? Try it and see :)
Re: Forward with attachments
On Thu, Apr 27, 2023 at 11:28:32AM -0400, Ofer Inbar wrote: > These days I usually do it by hitting 'v' on the original, separately > saving the attachments I want as local files, and then re-attaching > them to my reply or forward. If you want to save them locally, fair enough. If not, then after pressing v you can tag multiple attachments and then press the ; key (semicolon) followed by the f key. This will set up a new draft email with the attachments attached.
Re: sample muttrc file for AOL email...
On Thu, Apr 13, 2023 at 04:22:01AM -0500, Lester Rees wrote: > Damn, I never thought getting help configuring Mutt for my AOL email > account would be such a big hassle. I used to use mutt for my Gmail > accounts, but Google, as you know [is phasing out app-specific > passwords]. As others in this thread have noted, Mutt can indeed be used successfully with AOL and with GMail. That said, GMail is not terribly friendly towards people who prefer traditional email clients like Mutt, and given that Yahoo keeps changing hands, it's hard to predict what Yahoo (AOL's owner) will do in future. IMO, the best way to avoid such headaches is to switch to a more ethical, more user-friendly email provider. As you can tell from my email address, I use Posteo, but there are other options, too. For instance, Drew DeVault recommends Migadu.com or Mailbox.org : https://drewdevault.com/2020/06/19/Mail-service-provider-recommendations.html > Instead, I get a whole bunch of hassle from everyone. Leave it human > beings to make things more complicated than they should be!!! > Damn!!! You know, the less I have humans involved with my life, the > less stress and fewer problems I have. It's important to distinguish between: 1. Human beings who are making your life harder and who may not actually care. (E.g. maybe product managers at Google, and perhaps AOL too; miscreants whose abuse of traditional authentication in the past & present has encouraged Google to migrate fully to OAuth.) 2. Human beings who are trying to help you & others like you, because they *do* care. (Volunteers on this mailing list! The authors & maintainers of Mutt! People who run ethical, user-friendly email service providers!) Learning to distinguish between the two groups helps reduce stress. Good luck in your quest. Sam
