Re: Question about message id
On Tue, Apr 09, 2024 at 10:53:41AM -0400, Derek Martin wrote: > On Sun, Apr 07, 2024 at 01:19:09PM +, Ебрашка wrote: > > Question, what should I write in .muttrc to make my outgoing mails have > > the same beautiful message-ID as Yandex mail? > > The unfathomable thing about this question is why you (or anyone) > should care in the slightest what your message ID looks like. It's an > esoteric detail about e-mail transfer, the specific contents of which > have no value to users, who in most cases won't even ever see the > message ID, since most mail clients hide that detail from you by > default. You have no practical reason to care what it is as long as > everything is working correctly. It's literally not for you--it's for > your MUA software. The link to a kernel mailing list message that was provided earlier in this discussion said that the choice to use base64 results in the possibility of / characters being included in the message id which causes problems for their archived messages accessible via a web browser. So it seems that there is a reason to care about this. Although one could argue that the mailing list archiving system should accept the responsibility of munging message ids to suit its own needs. I've certainly seen mailing list archives on the web that did munge the message id (but to replace @ characters, I think). cheers, raf > -- > Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 > -=-=-=-=- > This message is posted from an invalid address. Replying to it will result in > undeliverable mail due to spam prevention. Sorry for the inconvenience. >
Re: Setting X-Priority/Priority/Important headers more easiliy?
On Wed, Sep 27, 2023 at 02:36:57PM -0500, Tim Chase
wrote:
> Howdy,
>
> RFC-2156[1] specifies ways to use the headers
>
> Importance: {low, normal, high}
> Priority: {normal, non-urgent, urgent}
> Sensitivity: {Personal, Private, Company-Confidential}
>
> and I've also seen the non-standard
>
> X-Priority: 1 (Highest)
> X-MSMail-Priority: High
>
> (with X-Priority ranging from 1 (Highest) to 5 (lowest)) in the
> wild to convey meta-information about the message.
>
> Does anyone have any suggestions/mappings that might make it easier
> to add/manage add/manage these headers rather than hand-entering
> them with {edit-headers} in the message-compose menu? Preferrably
> picking from a list rather than remembering the exact text/number
> for each header.
>
> Thanks!
>
> -tkc
>
> [1] https://datatracker.ietf.org/doc/html/rfc2156
You can define a macro that uses my_hdr for each such header.
Then each one can be a single keystroke.
cheers,
raf
Re: DKIM fails depending on Content-Transfer-Encoding
On Wed, Sep 06, 2023 at 01:33:30PM +0200, f...@igh.de wrote: > Dear Mutt Users > > recently I experienced DKIM fails that depend on the > Content-Transfer-Encoding of messages text part. > > Being a german I use to write my messages in german with UTF-8 > encoding. I prefer plain text. My e-mails are DKIM signed. I have > checked DKIM to be set up correctly twice. > > By default Mutt does 8bit encoding for text/plain. Now I found that > several (most) of the recipient systems fail to check DKIM. > > If I force Mutt to change the encoding from 8bit to 7bit, base64, or > quoted-printable (using ^E in the compose menu), the DKIM checks > succeed. > > Can I force Mutt to use quoted-printable or base64 by default for > encoding of plain text? > > Does anyone have similar experiences? Is there an explanation for this? > May there be any interference with the MTA? > > Interestingly DKIM checks do not fail if I use non-ASCII characters in > the subject. Also attachements do not cause DKIM to fail. > > Best Regards > > T. Finke > > -- > > T. Finke > f...@igh.de > Hi, This has come up recently in the Postfix mailing list. MTAs can convert 8bit messages when sending to another MTA that doesn't advertise that it can accept 8bit. If the DKIM signing happens before the conversion, then subsequent DKIM checks will fail. Work is being done in Postfix to address this. I don't know about other MTAs. It seems unlikely that there are any MTAs that can't accept 8bit messages, but perhaps there are some that are misconfigured and don't advertise the fact to other MTAs. cheers, raf
Re: Why Mail-Followup-To header for a non-list address?
On Sun, Aug 20, 2023 at 06:25:57PM +0800, "Kevin J. McCarthy" wrote: > On Sun, Aug 20, 2023 at 03:53:09PM +1000, raf via Mutt-users wrote: > > I don't have any "lists" commands. I do have a "subscribe" command > > which refers to mailing lists by their aliases. One of the aliases > > is "debian" and the email address in question does contain "+debian" > > but that shouldn't matter. > > Hi raf, > > 'lists' and 'subscribe' specify regular expressions to match against email > addresses, not aliases. That's most certainly why you are seeing this > behavior. Try tightening the regular expression in the 'subscribe' > command(s). > > -- > Kevin J. McCarthy > GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA Hi Kevin, Thanks! I'm surprised it's taken this long for a problem to get noticed! :-) cheers, raf
Why Mail-Followup-To header for a non-list address?
Hi, Someone recently emailed me. Technically it was a reply to an old email of mine. Since then, a few emails have gone back and forth between us. All of my outgoing mails to this one address have had a Mail-Followup-To header added. I have no idea why. The address isn't mentioned in any "subscribe" or "lists" commands. I don't have any "lists" commands. I do have a "subscribe" command which refers to mailing lists by their aliases. One of the aliases is "debian" and the email address in question does contain "+debian" but that shouldn't matter. I've fixed it with a send-hook that does "set followup_to = no" for that address, but I don't understand why I needed to. Can anyone think what I might have done to cause this? Linux ook 6.1.0-11-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.38-4 (2023-08-08) x86_64 GNU/Linux mutt-2.2.9-1+b1 cheers, raf
Re: Is there any way to view text/html inline *only if* we think text/plain is not right?
On Thu, May 18, 2023 at 07:53:50PM -0400, José María Mateos wrote: > Hi everybody, > > Lately I've been receiving mail in which the text/plain part and the > text/html part are at odds. This is typically caused by generator software > that ignores text/plain, or uses some old version, etc. > > Today I changed my settings to view text/html first via w3m, but I'm not > entirely comfortable with this. > > What I'd really like to do is: > > 1. Display text/plain by default. > 2. If I'm not convinced by that version, press some key and then text/html > is displayed inline (using w3m, lynx, links, or whatever in the ~/.mailcap > file). > 3. If that's still not good enough, use a macro I already have to run > mutt_bgrun and display that mail using Firefox directly. > > I don't know if point 2 is a possibility, to be honest. Does anyone know if > this can be done? > > Thanks a lot, > > -- > José María (Chema) Mateos || https://rinzewind.org I think you can setup two ways of handling an attachment, one for "viewing" and one for "printing". You can make the "view" command treat it as text/plain and make the "print" command treat it as text/html, but I don't remember the details on how to do this. Does anyone else remember? cheers, raf
Re: How do I make mutt send my mails to a remote MSA?
On Mon, Jan 30, 2023 at 04:22:43AM +0200, e wrote: > On Mon, Jan 30, 2023 at 04:10:45AM +0200, e wrote: > > > > Is it possible to use mutt without having an MTA on your own machine? I > > have read that some MUA's use "Message submission" (rfc 2476) > > to send the mail to an MSA that can be on the same network for example. How > > can I do this with mutt? > > Is $smtp_url the situation where a MUA is using "Message submission" and it > sends to an MSA? I expect so. The manpage says the syntax is: smtp[s]://[user[:pass]@]host[:port] If the port isn't provided, it presumably uses port 25, but in that case, the user and password probably aren't helpful (authentication is often not offered on port 25). Your MUA host would have to be considered as local by the MTA server. That might not be possible. If the port is supplied as 465 or 587, it presumably knows the difference (i.e, TLS or STARTTLS, respectively), and the user and password are necessary. Actually, you probably need "smtps:" for port 465 and "smtp:" for port 587. mutt might not handle that for you. So the following would be best: smtps:user:pass@server:465 smtp:user:pass@server:587 These last two might work, but only if the MTA server offers authentication on port 25, or if it trusts your MUA host, respectively. smtp:user:pass@server smtp:server Also note that, when using "smtp:" rather than "smtps:", mutt still encrypts the traffic by default, because $ssl_starttls is yes by default. But you might want to set ssl_force_tls=yes as well. cheers, raf
Re: multiple IMAP accounts on one server?
On Sun, Jan 15, 2023 at 08:58:19PM +0100, Matěj Cepl wrote:
> Hi,
>
> I am looking for the terminal-based MUA which would be able to
> work with my email needs. However, for various reasons I really
> need all my emails stay on multiple IMAP accounts (no local
> emails if possible). I have started with mutt as it is the
> client I know best, but I am not married to it, if you know
> about anything better (Alpine?, notmuch?, anything else) which
> could help me, then I am all ears.
Have a look at neomutt. It's based on mutt, and might or might
not be different in relation to account hooks.
> account-hook .*localhost 'set imap_user=matej imap_pass=secret1 \
> from="Matěj Cepl "
> folder=imap://localhost.localdomain \
> trash=+Trash postponed=+Drafts'
> # account-hook mcepl 'set imap_user=mc...@cepl.eu imap_pass="secret2" \
> # from="Matěj Cepl " \
> # folder=imaps://redcrew.org trash=+Trash postponed=+Drafts'
> account-hook .*redcrew.org 'set imap_user="ma...@ceplovi.cz" \
> imap_pass= "secret3" \
> from="Matěj Cepl " \
> folder=imaps://redcrew.org trash=+Trash postponed=+Drafts'
> account-hook .*suse.de 'set imap_user=mcepl@Thunderbird \
> imap_pass= "secret4" \
> postponed=+INBOX/Drafts from="Matěj Cepl " \
> trash=+INBOX/Trash'
>
> The problem is obviously mc...@cepl.eu account.
>
> * Is it possible to have two account hooks directed against one
> IMAP server?
Kind of. I found this:
[mutt] Multiple email accounts using hooks
https://nixtricks.wordpress.com/2010/05/20/mutt-multiple-email-accounts-using-hooks/
It has an initial account-hook matching . that unsets things,
followed by other account-hooks that sets them depending on
the account.
So, multiple account-hook directives can match the same account.
It just depends on the regular expressions used. But that might
not be useful to you. I'm not sure why you want different
account-hooks for the same account.
If you want two different sets of parameters for the same account
(does that even make sense?), then you might need to put them in
different rc files, and perhaps create key bindings to load the one
you want when you want to change.
> * What EXACTLY are possible values of the first parameter of
> account-hook. Does it have to be domain name of the server, or
> could it be some random string (as shown here in the commented
> out account-hook)?
Good question. It's not clear from just the account-hook entry in
muttrc(5). From the webpage mentioned above, it looks like the
regexp needs to match the imap URI
(e.g., 'imaps://us...@imap.gmail.com/').
> * Is there some patch somewhere, which would support some more
> grown-up version of the accounts settings? I would like to have
> something like
>
> account work { \
> imap_server = imap.suse.de \
> imap_user = mcepl@Thunderbird \
> imap_pass = secret4 \
> ... { any other mutt settings }
> }
>
> account floss { \
> imap_server = redcrew.org \
> imap_user = mc...@cepl.eu \
> imap_pass = secret2 \
> ... { any other mutt settings }
> }
>
> and then I would run
>
> $ mutt -C work
>
> (C as aCcount)
>
> and when inside of mutt I could refer to the other account with
> something like
>
> #floss/INBOX/somewhere
>
> Anybody heard about something like this?
No, but the same thing can be achieved with alternate muttrc files
and the -F option. When you run "mutt -F work" or "mutt -F floss",
the work and floss rc files can contain their specific imap settings,
and then source a common rc file with everything else.
For saving to the other account, macros would help.
If you really like your config syntax above, you could probably
write a little tool that "compiled" it into muttrc syntax.
> Best,
> Matěj
cheers,
raf
Re: Search patterns for multiples address in to or cc
On Sun, Dec 18, 2022 at 09:22:33PM -0300, Marcelo Laia wrote: > I know and I use the ~C, ~b and ~B pattern for a specific search. > > How ever, I would like to search multiples address in to or cc header. Like > this: > > to: someo...@domain1.edu.au, someo...@domain1.edu.au, ... > cc: someo...@domain2.edu.au, someo...@domain10.edu.au, ... > > In fact, I would like to search messages that there are more than one > address in to or cc header. > > This is more a regex that mutt, I think. > > Have you a time to helpe me? > > Thank you so much! > > -- > Marcelo Perhaps you just need '~C @.+,.+@'. That should match two addresses with a comma between them. But I just tried it and it doesn't work. :-( Perhaps ~C matches individual recipients rather than the complete To: and Cc: headers. Replacing ~C with ~h works but it might match other headers. This seems to work: ~h ^(To|Cc):.*@.+,.+@ Of course comments that contain "@" and "," will match as well, but they should be rare. cheers, raf
Re: Flowed text with Emacs
On Tue, Sep 27, 2022 at 12:31:09AM -0400, Kurt Hackenberg wrote: > All, > > Remember the thing I posted here a while ago, a way to use Emacs to compose > text/plain format=flowed? I've made it easier to use. Now it can be used > with or without $edit_headers, and the text format conversions are > automatic. > > It's here: > <https://www.panix.com/~kh/mutt-flowed-text/> > > Try it, let me know how it works for you. I'm not an emacs user, but thanks. I think it's important to support $edit_headers for this. I always need the option of editing headers. cheers, raf
Re: [Mutt] Is linewrap dead?
On Mon, Sep 12, 2022 at 09:07:37PM +0200, Mihai Lazarescu wrote: > On Monday, September 12, 2022 at 15:15:55 +, Nacho via Mutt-users wrote: > > > > What you describe is becoming more and more history, which I regret. > > > Let me give you the link of an article that should interest you. > > > > > > https://cfenollosa.com/blog/after-self-hosting-my-email-for-twenty-three-years-i-have-thrown-in-the-towel-the-oligopoly-has-won.html > > > > I don't agree with that article, it has some technical errors I will not > > discuss > > here because of lack of time and it being off topic. > > > > But in short, today it's just a matter of money and time to have your own > > email system working perfectly, of course the cost have increased wildly in > > the > > last few years and will keep doing so, but at least for me makes all the > > sense > > to pay for it. > > I tend to concur. I run just fine for several years now my own SMTP/IMAP > servers + Let's Encrypt certificate on a cheap VPS (< $20/year). > > It took some work to set it up, but that's it. Surely not a mass solution, > yet feasible and stable. > > Messages sent to Google accounts tick all green boxes. > > Only Microsoft (outlook.com, hotmail.com) seem to filter the whole IP block, > but I am too lazy to ask the provider to fix or change provider altogether. > > Given the cheap VPS, I can mirror the setup on a second VPS from a different > provider with quick DNS switch in case of issues. > > HTH. > > Mihai I haven't noticed any cost increases with my VPS (but I am paying more than $20/year). I've only had two mail receivability problems. It turns out that spamhaus doesn't realise that someone might only have one IPv6 address, so if any of my neighbour VPSs sends spam over IPv6, the whole network block is tainted, so I had to stop my mail server from sending from its IPv6 address. Luckily, the same strange idea doesn't seem to apply to IPv4 (at least for spamhaus). Also, Microsoft once didn't like my IPv4 address so I temporarily routed mail to there via some third party service, but when I asked them to fix it, they did (but they couldn't explain why they didn't like it). Apart from that, it all seems fine (unless I'm deluded). :-) cheers, raf
Re: Is linewrap dead?
On Mon, Sep 05, 2022 at 10:45:09PM -0400, Kurt Hackenberg wrote: > On Tue, Sep 06, 2022 at 08:54:58AM +1000, Cameron Simpson wrote: > > > I'm not sure we're disagreeing here, except for the conceptual > > separation of the space-stuffing step. > > I agree that it's a separate step, or layer. I just think it might better be > done within the editor -- or special-purpose program, or script that runs > two programs -- rather than be done later by Mutt itself. That is, Mutt > could farm out the whole job, rather than have the external program do half > and Mutt do half. > > I would guess that it's split just because it was made for vim, and vim > can't do the space-stuffing. I don't know the history, though. I expect it is done in mutt because it must be done (for transport), and it would be a mistake to assume that it will be done by the editor, whatever editor it is. I don't think that mutt makes any assumptions about which editor is used. Also, vim could do it. Vim can do anything to text, and it can be automated, but of course, it needs to configured to do so. Not necessarily with formatoptions settings, but perhaps with filetype-based autocommands. But I think the real problem with format=flowed, and possibly the reason why the large corporate web-based mail providers don't support it is that it's not sufficiently trivial to make it happen. So maybe it just isn't used by enough people. It seems that vim makes it fairly easy, but that's just one editor. Although the real reason might just be a preference for html email. cheers, raf
Re: Re: Is linewrap dead?
On Sun, Sep 04, 2022 at 05:39:05PM +0200, Jan Eden via Mutt-users wrote: > On 2022-09-04 20:37, Cameron Simpson wrote: > > On 04Sep2022 15:34, raf via Mutt-users wrote: > > > On Sun, Sep 04, 2022 at 01:51:25PM +1000, Cameron Simpson > > > wrote: > > > > > The `md2html` script is my personal script, which wraps `pandoc` > > > > and post munges the HTML to indent the code blocks, which > > > > `pandoc`'s HTML does not please my eye. It's here: > > > > https://github.com/cameron-simpson/css/blob/main/bin-cs/md2html if > > > > anyone wants a starting point. > > > > > > Thanks, Cameron. It's odd that there isn't an md2html program out > > > there already. I had to create one too (using python's markdown > > > module). > > There is a python script provided with mutt > (share/doc/mutt/samples/markdown2html), which can also be found at > https://fossies.org/linux/mutt/contrib/markdown2html . This one also > uses pandoc. > > - Jan Thanks. cheers, raf
Re: Is linewrap dead?
On Mon, Sep 05, 2022 at 08:36:54AM +1000, Cameron Simpson wrote: > On 05Sep2022 08:24, Cameron Simpson wrote: > > On 04Sep2022 11:33, Kurt Hackenberg wrote: > > > But not space-stuffing, right? > > I just reread https://www.rfc-editor.org/rfc/rfc3676#section-4.4 to refresh > my brain. Yeah, I don't think I'd want that when writing a message. > > > > Which I guess is why Mutt space-stuffs the format=flowed that it > > > gets back from the editor. > > Aye. I avoid lines commencing with a ">" just because they look quoted to my > eye anyway, so that aside "live" space stuffing in authoring is something > I'd find distracting. > > Cheers, > Cameron Simpson Hmm. I do "From-munging" on arrival. I should probably read rfc3676 properly. :-) cheers, raf
Re: Is linewrap dead?
On Sun, Sep 04, 2022 at 08:37:21PM +1000, Cameron Simpson
wrote:
> On 04Sep2022 15:34, raf via Mutt-users wrote:
> > On Sun, Sep 04, 2022 at 01:51:25PM +1000, Cameron Simpson
> > wrote:
> [...]
> > > So I've revisited the manual and found the
> > > `$send_multipart_alternative`
> > > option and its friend `$send_multipart_alternative_filter`. They work
> > > well!
> > >
> > > So now I have a mechanism to send: `format=flowed` MarkDown with a
> > > aparallel
> > > HTML alternative. The HTML should render in a "paragraphy" way for the
> > > HTML
> > > people, and the MarkDown keeps me happy.
> > >
> > > My default setting is now:
> > >
> > > set send_multipart_alternative=no
> > > set send_multipart_alternative_filter='echo text/html; echo; exec
> > > md2html'
> > >
> > > which is the inactive form, and I've added:
> > >
> > > message-hook . 'set send_multipart_alternative=no'
> > > message-hook '%f htmlees' 'set send_multipart_alternative=no'
> >
> > Oops. That should be =yes above.
>
> Whoops indeed. I just sketched this out this morning. Thanks for the catch.
> fix applied.
>
> > > The `md2html` script is my personal script, which wraps `pandoc` and
> > > post
> > > munges the HTML to indent the code blocks, which `pandoc`'s HTML does not
> > > please my eye. It's here:
> > > https://github.com/cameron-simpson/css/blob/main/bin-cs/md2html
> > > if anyone wants a starting point.
> >
> > Thanks, Cameron. It's odd that there isn't an md2html
> > program out there already. I had to create one too
> > (using python's markdown module).
>
> Ah, that might be easier to customise. I just tried a few markdown
> converters and ended up with pandoc.
>
> > I like your indenting of code blocks, but it seems to
> > put an additional blank line after each code block.
> > That might not be intentional.
>
> Not intentional. I just wanted to keep the 4 space indent used to trigger a
> code block for the same visual effect, since I use that instead of the
> triple backticks usually. Pandoc tosses those spaces.
That's correct behaviour for markdown. If you want the
output to be indented four spaces, the markdown source
needs to be indented eight spaces. But for email use,
it's a nice idea to do what you're doing.
If you want to prevent the extra line, the sed command
can be changed to remove theindenyt before the closing
line of the code block:
sed '
s/^\(\)\(.*<\/code><\/pre>\)$/\1\2/
t post_pre_code
/^/,/<\/code><\/pre>$/{
s/^//
s/^\(\)/\1/
s/^\(<\/code><\/pre>\)/\1/
}
:post_pre_code
'
> Pandoc's conversion is a bit clunky (but better than discount and the other
> tool I tried).
>
> > And it looks like it
> > doesn't do titles (which default to "-"). I guess that
> > doesn't matter for email use, except that pandoc
> > whinges about it on stderr.
>
> Aye, annoying. There's no context for a title (eg the subject header), I may
> just have to provide something to shut it up. Or shift sideways to the
> Python module, particularly if that does a better job.
>
> > Do you have any advice for automating spaces at the end
> > of non-final paragraph lines for format=flowed in vim?
>
> I use these settings:
> https://github.com/cameron-simpson/css/blob/main/bin/vim-flowed
> which autowraps and leaves trailing spaces automatically.
>
> > Perhaps I could just post-process messages with perl
> > in my mutt-editor wrapper script.
>
> Vim can do 99% of it for you on the fly :-)
Thanks again.
> Cheers,
> Cameron Simpson
cheers,
raf
Re: Is linewrap dead?
On Sun, Sep 04, 2022 at 01:51:25PM +1000, Cameron Simpson wrote: > Well, this has been quite the read. > > As a plain text person (aren't we all?) I find poor quality mail clients > annoying, as shown by the motivating screenshot of a plain text hard folder > message presenting on a narrow portrait mode mail reader. > > There seem to two approaches available: `format=flowed` which works well if > the mail reader supports it, and HTML which is a PITA to author for us. > > Having just got my `format=flowed` stuff working again after being broken > for a long time, and have been using some Discourse forums recently (via > email) which accept MarkDown, I've been filled with enthusiasm for MarkDown > email. And markdown's a decent source for basic HTML, since it's authoring > overhead is low and it is very readable in its raw form. > > So I've revisited the manual and found the `$send_multipart_alternative` > option and its friend `$send_multipart_alternative_filter`. They work well! > > So now I have a mechanism to send: `format=flowed` MarkDown with a aparallel > HTML alternative. The HTML should render in a "paragraphy" way for the HTML > people, and the MarkDown keeps me happy. > > My default setting is now: > > set send_multipart_alternative=no > set send_multipart_alternative_filter='echo text/html; echo; exec md2html' > > which is the inactive form, and I've added: > > message-hook . 'set send_multipart_alternative=no' > message-hook '%f htmlees' 'set send_multipart_alternative=no' Oops. That should be =yes above. > which will be turning it on for people in my (empty so far) "htmlees" mutt > group. I use a similar pattern (`%htmlers`) for preserring HTML over plain > text for certain messages. > > The `md2html` script is my personal script, which wraps `pandoc` and post > munges the HTML to indent the code blocks, which `pandoc`'s HTML does not > please my eye. It's here: > https://github.com/cameron-simpson/css/blob/main/bin-cs/md2html > if anyone wants a starting point. > > I'm probably going to bind a key to turn this mode on at some point. > > Cheers, > Cameron Simpson Thanks, Cameron. It's odd that there isn't an md2html program out there already. I had to create one too (using python's markdown module). I like your indenting of code blocks, but it seems to put an additional blank line after each code block. That might not be intentional. And it looks like it doesn't do titles (which default to "-"). I guess that doesn't matter for email use, except that pandoc whinges about it on stderr. Do you have any advice for automating spaces at the end of non-final paragraph lines for format=flowed in vim? Perhaps I could just post-process messages with perl in my mutt-editor wrapper script. cheers, raf
Re: Having problems with POP3 setup
On Sat, Sep 03, 2022 at 05:35:31PM -0500, x...@trimaso.com.mx wrote: > What's the current panorama for POP3 nowadays? Is it still used or is it > dying? I heard Yahoo dropped POP3 support since years ago, except for paid > users... > > Thanks again. I don't think POP will go away entirely. I can't imagine dovecot removing support for it. The entities that would want to abandon POP are ones like Yahoo/Gmail/Microsoft who store their users' emails. I have a mail server on a little VM that some family members use. I wouldn't want to store their emails indefinitely, or be responsible for backups, so they all connect via POP to fetch mail, which they delete a week or two later (to give multiple devices a chance to see everything), and they handle their own backups. But I suppose it could disappear from big mail providers. When there are choices, they can pick a favourite and make a choice on behalf of their users rather than letting their users make their own choices. But this is speculation. I don't really know. cheers, raf
Re: Is linewrap dead?
On Thu, Sep 01, 2022 at 08:20:21AM +0200, Angel M Alganza wrote: > On Wed, Aug 31, 2022 at 05:22:48PM -0400, Kurt Hackenberg wrote: > > > Very long lines -- one line per paragraph -- changes the meaning of > > After top posting that is probably the most annoying thing on email. > And from what I can tell reading this thread, there will always be some > nasty software and some people who will insist on doing that. > > So, is there a way to instruct Mutt to wrap received mail with long > lines to wrap them for me at a sane length so that I don't have to suffer > those ridiculous long lines? I have this in ~/.muttrc: set markers = no set wrap = -5 which wraps lines at 5 columns in from the right. You can also use a positive number to specify an absolute amount. Turning markers off means that wrapped lines won't start with a "+" character. HAving the + there might be preferable. I remove them so I can copy and paste multi-line wrapped URLs into another window to be opened locally (the email is read remotely via ssh to a vm). So maybe try something like: set wrap = 72 set smart_wrap There are other muttrc variables to look into: e.g. smart_wrap That looks good. I might add that. It wraps at word boundaries. > Of course I can reduce the with of the frame on Notion (my window > manager) where I run Mutt to force the wrapping, but I'd rather keep the > size I use for everything else and have Mutt wrapping the text for me. > > Cheers. > Ángel cheers, raf
Re: Is linewrap dead?
On Wed, Aug 31, 2022 at 02:48:55PM -0500, Derek Martin wrote: > The bottom line is there is absolutely no reason why hard-wrapped > lines of plain text at 72 characters should ever need to display > unreadably for any desktop user, or even anyone on any reasonable > mobile device which can rotate lines parallel to their longer side, > that doesn't boil down to the choice of the user. Flouting the > standards is a bad habit to be in. They exist for good reason; if you > choose to abandon them you do so at your own peril, and the rest of us > should not be expected to accommodate you. > > -- > Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 > -=-=-=-=- I hard wrap at 55 to leave plenty of room for later quoting. I often receive replies from MUAs that wrap quoted text badly (as though they don't know what quoted text is) and so I try to reduce the likelihood of that. Strangely, it seems that some MUAs that treat each line as a paragraph seem to insert an additional newline after each line in what they quote as part of a reply, so I receive replies with a quoted blank line between each original line. It's almost as though they want to think that each line is a separate paragraph on input, but they're not entirely convinced, so for output, they make sure it's a "real" paragraph by adding a blank line between each input "paragraph". It doesn't make a lot of sense. Either a newline marks a paragraph or it doesn't. They can't make up their minds. I sometimes spend time cleaning up this sort of thing (or just removing quote trails), but it would never occur to me to complain to the sender about the formatting of their email. There's no point. Similarly, noone has ever complained about my emails. They might (or might not) have seen them as untidy, but I don't agree that that makes them any less effective as a means of communication. And I wouldn't worry about a recipient thinking that my emails aren't as nice as someone else's. The content of one person's emails would never be the same as the content of someone else's emails, so there is no meaning to any comparison like that. The best definition of technology that I ever heard was: "Anything that doesn't work properly yet". Once technology works properly, we give it a permanent name like chair, or hammer, or pencil. :-) So it's best if everyone just cuts everyone else a lot of slack when it comes to what technology does to our written communications. If someone has too much trouble doing that, for whatever reason (and I'm sure there are valid reasons), and they are receiving emails that do bother them to read, they could consider not reading emails on phones. There are many other reasons to not read email on phones. This might just be another one. Even excluding the whole short attention-span dopamine training thing, I know someone who is often very frustrated with the mail app on their iphone for often not being able to display emails that it composed and sent, complaining that the sender created a malformed email (a bug people have complained about for 10+ years that shows no sign of every being fixed), or emails from one person that are displayed with a different person altogether as the sender). In the grand scheme of things, lines that aren't all the same length seems unimportant. But it's obviously fun to talk about. :-) It would have been great if all of the obvious suspects had been willing at any point in the last 20+ years to pay just one of their many thousands of programmers to spend a little time to implement format=flowed. That would be the best solution to this "problem". But it seems they really really don't want that solution to exist for some reason best known only to themselves. I don't think it's fair or reasonable to blame the senders of emails for a problem caused by the company that created the deliberately limited MUA that the recipient uses, let alone expect those senders to all individually solve the problem. I'd use format=flowed if there was any point, but it doesn't seem that there is. It never makes sense to expect a large number of entities to each solve a problem that could be solved by a tiny number of (more powerful) entities. It's just not efficient or practical or likely to work reliably. cheers, raf
Re: Visualising contents of a Maildir
On Thu, Aug 18, 2022 at 10:10:38AM +0200, martin f krafft via Mutt-users wrote: > Thanks for your responses so far! > > 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. So I > need a PDF index. Hence I thought making an HTML table, and then printing > that. Easiest. > > A screenshot/bitmap approach would be very hard to turn into a useable PDF, > I think. > > Sam is right, threads are digraphs, but Mutt displays them in a table, and I > think that's a good compromise. > > > 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. ;) > > I knew why I'd ask here! ;) > > Thanks, > > -- > @martinkrafft | https://matrix.to/#/#madduck:madduck.net > "i worked myself up from nothing to a state of extreme poverty." > -- groucho marx > spamtraps: madduck.bo...@madduck.net Perhaps notmuch's json output with threading that you mentioned can be fed into jq which could transform it into csv. cheers, raf
Re: [RFC] Remove additional spaces when quoting already-quoted lines
On Sun, Jul 31, 2022 at 01:47:06PM -0400, Kurt Hackenberg
wrote:
> On Sun, Jul 31, 2022 at 06:09:56PM +0200, Thomas Wei??schuh wrote:
>
> >currently mutt always prepends `$indent_string` verbatim to each line when
> >quoting messages.
> >When quoting parts of messages that themselves already were quoted this leads
> >to additional space characters in addition to the quote characters.
> ...
> >I would like to modify the quoting algorithm to remove those additional
> >spaces.
> >
> >```
> ># Quoted twice (new)
> >quux
> >> baz
> >>> bar
> >>>> foo
> >```
> >
> >Even if such a patch is not acceptable to the main mutt project because it is
> >in maintenance mode, I would like to gather feedback from the list about
> >potential issues with interoperability and standards-conformance.
>
> You may not have to modify code. I have this in .muttrc:
>
> set indent_string = '>'
>
> You can see the results of that above.
>
> You could argue that should be the default value of $indent_string.
Not successfully. Changing a default affects all users who are obviously
happy with the default and forces them to "fix" their configuration to put
it back the way it was. There is rarely a good reason to do that. A recently
discovered security flaw is a good reason, but that's about it.
> I agree there should not be a space after the '>'. The trouble is,
> that space is ambiguous: software can't tell whether it's part of the
> quoting or part of the original message.
>
> RFC 3676 (text/plain format=flowed) forbids that space, for that
> reason.
>
> If you propose that software add a space after the rightmost '>', but
> not after others, I think it's thirty years too late to change that
> quoting mechanism. You'd have to change all the mail readers in the
> world, and also RFC 3676. We know that won't happen.
For what it's worth, I prefer '> '. Not because it
avoids the "problem" of not knowing whether or not the
final space is part of the message or part of the
quote (it's part of the quote), but just because I
think it looks better/clearer. The liberal use of
spaces and blank lines can make things so much easier
for a reader to comprehend.
But if you want this behaviour (despite any ambiguity),
mutt doesn't need to change. You can set the editor
parameter to a script that modifies the quoted reply
to your liking before invoking the real editor.
Something like this perhaps:
#!/bin/sh
# Change "> > > blah" quotes to ">>> blah" before editing
perl -i -e '
sub requote { my $s = $_[0]; $s =~ s/ >/>/g; $s; }
while (<>) { s/^([> ]+)/requote($1)/e; print; }
' "$@"
${VISUAL:-${EDITOR:-vi}} "$@"
Note that this script will cope with a mixture like "> >>> > >> blah"
and make it consistent like ">>>>>>> blah". And it won't add a final
space if there isn't one in the input.
I'm sure there's a better way to do it, but this'll do.
A good trick would be to follow any existing quote string. :-)
But the fact that there can be a mixture probably doesn't help.
Hmm, I might adopt the above but do the opposite, and add spaces
where they are "missing". :-)
cheers,
raf
Re: Two questions regarding header display
On Mon, Jun 20, 2022 at 08:15:13AM +1000, Cameron Simpson wrote: > On 07Jun2022 09:56, raf wrote: > >And I'm not sure I can do anything about it. > > There are many things you can do. I see you've already shifted to just > using "bold" etc in your color directives, but also: > - run a personal terminfo record without the color capabilities; > decompile the provided terminfo with untic, edit to remove the colours > (or change the colours to "mono" escape sequences, build new entry > with tic, set $TERMINFO to refer to it > - run mutt itself from a script or alias which sets $TERM just for mutt > i.e. overriding the $TERM provided by screen (which will be describing > the terminal capabilities of screen itself) > - switch from screen to tmux > > Cheers, > Cameron Simpson Thanks. cheers, raf
Re: Mutt configuration tips
On Tue, Jun 14, 2022 at 03:26:47PM -0400, Christopher Conforti wrote: > Hi all, > > I've been using mutt for a bit now. I really like it, because it's > vastly more efficient than the GUI MUA I was using before and so much > more configurable; there are a LOT of options! It seems here lately I > learn about a new one every day that I just happen to have a use for. > > I imagine there are a number of users who, like me, enjoy tinkering > with and tweaking their setup, adjusting every detail to their liking. > So for those who do: > * Have you done anything unusual with your configuration? Why? > * What's your favorite thing about your mutt configuration? Why? > * If you could give three tips to a new user, what would they be? > > Cheers! > -- > Christopher Conforti Hi Christopher, I'll suggest two things. Read man muttrc in full so you know what's available to be configured. You might decide to change something right away, or not. But you'll know what can be done when you encounter something you aren't happy with. Also, look at other people's ~/.muttrc files. There will be plenty online. e.g.: https://github.com/search?q=muttrc But that's probably a small sample. One thing I noticed recently is that it's not good to have lots of "color index..." directives, especially if they all set the same colours. It might be more readable, but it can really slow down paging through the index. One "color index" directive per colour combination with a complicated regex will be ugly, but it will also be much faster. Another tip is that you can do good things setting the editor variable to a script of your own that can perform arbitrary modifications before and/or after invoking the real editor. cheers, raf
Re: Two questions regarding header display
On Wed, Jun 08, 2022 at 12:23:07AM +0200, Anton Sharonov wrote: > raf schrieb am Di., 7. Juni 2022, 01:57: > > > TERM=screen. > > > > It's OK. screen is more important to me than bold > > headers. > > > > Don't give up. Gnu screen definitely supports bold if running on xterm, i > see it all the time - in my vim at least, not configured in mutt yet by > now. TERM value is screen-bce for me. It has to be supported by > corresponding terminfo entry. There is a bunch of color related settings in > .screenrc on my end as well. Even italic works in xterm+gnu screen but for > italic you would need to compile not yet released dev version of gnu screen > (last time checked in 2021, may be they even released since then already) > > Cheers, Anton Thanks. It'll probably work if I just switch from "mono" directives to "color" directives and tell it to use bold and default colours. Yep, that did it: color header bold default default ^(Subject|From|To|Cc|Date): cheers, raf
Re: Two questions regarding header display
On Mon, Jun 06, 2022 at 09:53:35AM -0700, "Kevin J. McCarthy" wrote: > On Tue, Jun 07, 2022 at 12:37:59AM +1000, raf wrote: > > On Sun, Jun 05, 2022 at 07:02:24PM -0700, "Kevin J. McCarthy" > > wrote: > > > TERM=xterm-mono might work for you > > > > Thanks, but that didn't change it. > > Interesting. It works for me, at least on Debian in an xterm. > > You may want to check your terminfo entries, e.g. what do "infocmp xterm | > grep color" and "infocmp xterm-mono | grep color" return? > > -- > Kevin J. McCarthy > GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA I always assumed that xterm was mono because of the existence of xterm-color. I should mention that I run xterm with the resource XTerm*colorMode: False > infocmp xterm-color | grep color colors#8, cols#80, it#8, lines#24, ncv@, pairs#64, > infocmp xterm | grep color colors#8, cols#80, it#8, lines#24, pairs#64, > infocmp xterm-mono | grep color I can see what's breaking it for me. I always run mutt with -n via an alias. If I don't use -n then bold in xterm-mono works. But if I do use -n then the currently selected message doesn't appear in reverse video in the index, so I can't easily tell which one is selected. If I comment out everything in /etc/Muttrc.d/colors.rc (this is on Debian11), then it's fine, and the reverse video and bold work. But the screen program is also (mostly) to blame. I thought it odd that color directives in the system config would affect xterm-mono, and when I uncommented them again, it still worked (unlike my original report). But my alias is actually alias m='screen mutt -n', and within screen, the TERM variable is set to "screen". That's the real reason that setting TERM=xterm-mono didn't work - it was being discarded by screen. And I'm not sure I can do anything about it. If I create a script to set TERM=xterm-mono and then run mutt, and then run that script via screen, screen terminates immediately. It must really want TERM=screen. It's OK. screen is more important to me than bold headers. Thanks. cheers, raf
Re: Two questions regarding header display
On Sun, Jun 05, 2022 at 07:02:24PM -0700, "Kevin J. McCarthy" wrote: > On Mon, Jun 06, 2022 at 10:57:47AM +1000, raf wrote: > > And there's also the "mono" directive for terminals that > > don't support colour, e.g.: > > > > mono header bold ^(Subject|From|To|Cc|Date): > > > > But it doesn't work for me anymore (with TERM=xterm). > > TERM=xterm-mono might work for you Thanks, but that didn't change it. > > And it would bold entire headers, not just their names. > > "color header bold default default ^(Subject|From|To|Cc|Date):" > will work the same, with $header_color_partial unset (the default). > > -- > Kevin J. McCarthy > GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
Re: Two questions regarding header display
On Sun, Jun 05, 2022 at 09:33:43AM -0700, "Kevin J. McCarthy" wrote: > On Sun, Jun 05, 2022 at 10:24:47AM -0400, Jason Franklin wrote: > > On Sun, Jun 05, 2022 at 09:26:04AM +0200, Jakub Jindra wrote: > > > set header_color_partial = yes > > > color hdrdefault FG BG > > > color header FG BG "REGEX" > > > color header FG1 BG1 "REGEX1" > > > > > > tune the colors FG, BG and REGEX to your needs. > > > > I came across that option in the manual, but I couldn't make it work at > > the time. I will have to play around with it a bit. > > See http://www.mutt.org/relnotes/1.9/ for a sample usage. > > Also note, starting with 1.12 you can add attributes before the color name. > > For example, to *only* make the headers bold: > > set header_color_partial > color header bold default default '^[^[:blank:]:]*:' > > -- > Kevin J. McCarthy > GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA And there's also the "mono" directive for terminals that don't support colour, e.g.: mono header bold ^(Subject|From|To|Cc|Date): But it doesn't work for me anymore (with TERM=xterm). I don't know why that is. I think it must have worked in the past. I just "ignore" the headers I don't want to see so it's not really a problem. And it would bold entire headers, not just their names. cheers, raf
Re: Two questions regarding header display
On Sun, Jun 05, 2022 at 11:32:34AM +0200, Anton Sharonov
wrote:
> raf schrieb am So., 5. Juni 2022, 07:52:
>
> > On Sun, Jun 05, 2022 at 12:06:52AM -0400, Jason Franklin
> > wrote:
> >
> > > Greetings:
> > >
> > > I have two questions regarding header display...
> > >
> > > First, can the pager display header names in bold if the terminal
> > > supports it?
> > >
> > > Second some senders have weird capitalization of headers. Is it possible
> > > to display some canonical representation of any given standard header?
> > >
> > > To clarify, if the header is sent as "reply-to", I would like to always
> > > see "Reply-To" in the pager.
> > >
> > > Thanks!
> > >
> > > --
> > > Jason
> >
> > Hi, I don't know about the first part, but the second part
> > could be done if procmail or similar is used for local
> > delivery, and it passes incoming messages through a filter
> > to "correct" the headers to your liking. But it might
> > be a hassle if you aren't already using procmail.
> >
>
> Will usage of display_filter option with your perl script below not be
> already sufficient solution even without procmail?
Good thinking. I just tried it and it works great.
set display_filter = /home/me/bin/fix-mail-headers-filter
But the script needs a fix to prevent changing the From_ mbox header:
/home/me/bin/fix-mail-headers-filter:
#!/usr/bin/env perl
use warnings;
use strict;
# Modify headers if needed (e.g. "reply-to:" to "Reply-To:")
while (<>)
{
# Skip to the following trivial loop after headers
print, last if /^$/;
# Replace lowercase at start of word before colon with uppercase
s/^([^: ]*)\b([a-z])/$1\U$2/ while /^[^: ]*\b[a-z]/;
print;
}
# Just print the rest unchanged
print while (<>);
> > The above was barely tested. Don't use it without testing it on
> > lots of existing mail (one message at a time - see formail(1))
> > until you are sure that it works. And note that it doesn't
> > convert any uppercase to lowercase, only the other way around.
> >
> > cheers,
> > raf
Re: Two questions regarding header display
On Sun, Jun 05, 2022 at 12:06:52AM -0400, Jason Franklin
wrote:
> Greetings:
>
> I have two questions regarding header display...
>
> First, can the pager display header names in bold if the terminal
> supports it?
>
> Second some senders have weird capitalization of headers. Is it possible
> to display some canonical representation of any given standard header?
>
> To clarify, if the header is sent as "reply-to", I would like to always
> see "Reply-To" in the pager.
>
> Thanks!
>
> --
> Jason
Hi, I don't know about the first part, but the second part
could be done if procmail or similar is used for local
delivery, and it passes incoming messages through a filter
to "correct" the headers to your liking. But it might
be a hassle if you aren't already using procmail.
~/.procmailrc:
:0 fw
| /home/me/bin/fix-mail-headers-filter
/home/me/bin/fix-mail-headers-filter:
#!/usr/bin/env perl
use warnings;
use strict;
# Modify headers if needed (e.g. "reply-to:" to "Reply-To:")
while (<>)
{
# Skip to the following trivial loop after headers
print, last if /^$/;
# Replace lowercase at start of word before colon with uppercase
s/^([^:]*)\b([a-z])/$1\U$2/ while /^[^:]*\b[a-z]/;
print;
}
# Jut print the rest unchanged
print while (<>);
The above was barely tested. Don't use it without testing it on
lots of existing mail (one message at a time - see formail(1))
until you are sure that it works. And note that it doesn't
convert any uppercase to lowercase, only the other way around.
cheers,
raf
Re: New to Mutt, unable to send messages in *any* attempted way
On Fri, May 20, 2022 at 05:54:55PM +1000, raf wrote:
> I'm sending a patch that adds an error check for shell
> meta-characters when $sendmail is used. It might have been
> better to check right after reading .muttrc, but this seemed
> like a more natural place to put the code (i.e., right after
> the check that $sendmail exists).
I tried to send the patch to mutt-...@mutt.org a few times but
never received it, so I'll send it here instead.
cheers,
raf
> Subject: [PATCH] Add error when $sendmail has shell metachars
---
sendlib.c | 8
1 file changed, 8 insertions(+)
diff --git a/sendlib.c b/sendlib.c
index 430b5d73..05039714 100644
--- a/sendlib.c
+++ b/sendlib.c
@@ -2706,6 +2706,14 @@ mutt_invoke_sendmail (ADDRESS *from, /* the sender */
return -1;
}
+ /* check for shell meta-characters that won't do what the user expects */
+#define SHELL_NON_SPACE_META_CHARACTERS "|&;()<>[]{}$`'~\"\\*?"
+ if (Sendmail[strcspn(Sendmail, SHELL_NON_SPACE_META_CHARACTERS)] != '\0')
+ {
+mutt_error(_("$sendmail cannot contain shell meta-characters."));
+return -1;
+ }
+
ps = s;
i = 0;
while ((ps = strtok (ps, " ")))
--
2.30.2
Re: New to Mutt, unable to send messages in *any* attempted way
On Fri, May 20, 2022 at 04:20:55PM +1000, raf wrote: > On Thu, May 19, 2022 at 12:05:59PM -0700, "Kevin J. McCarthy" > wrote: > > > On Thu, May 19, 2022 at 01:12:31PM -0500, Derek Martin wrote: > > > On Thu, May 19, 2022 at 11:06:38AM -0700, Kevin J. McCarthy wrote: > > > > Sorry, this isn't currently possible in Mutt. The $sendmail variable is > > > > handled specially: it's tokenized by space and invoked directly via > > > > execvp(). So you won't be able to use arguments with spaces in them > > > > inside > > > > the variable, or any shell quoting since it doesn't pass through the > > > > shell. > > > > > > Couldn't you do something like the following? > > > > > > set my_sendmail=/usr/bin/msmtp [...] --passwordeval=$(gpg --no-tty -q -d > > > ~/.user.gpg)" > > > set sendmail=$my_sendmail > > > > > > Don't know, haven't tried it, but as long as the first thing evaluates > > > to something that sendmail's tokenization can handle, seems like it > > > should work... > > > > $sendmail goes through muttrc evaluation like other variables, but when > > invoked to send an email, the resulting string is tokenized by space, '--' > > and various arguments inserted as needed, and then passed to execvp(). > > > > Yes, this should be documented and I'll add it to the config option shortly. > > > > I don't know why it was written this way, perhaps some security concerns, > > but I agree that it's surprising. > > > > -- > > Kevin J. McCarthy > > GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA > > I think the reason would be that mutt is modifying the > command, not just executing it. It's modifying a > command in a complex external language that it can't > parse by itself unless it imposes very strict > limitations on the allowable syntax of the command. > I don't think it's a security decision. It's just > necessary. How would mutt know how to modify > sendmail="blah1 | blah2 | blah3" ? > > I think this limitation should be documented, but not > fixed. It could be fixed by adding something like % > interpolation placeholders for the things that are > added. But that might break existing commands that > contain %. Maybe # would be a better choice. But it's > still a bad choice. It requires the user to know and > use even more notation. > > An elegant solution already exists. Put complex shell > commands in a file and mutt only needs to see its name. > > But users need to be told when they are required to do > that. So in addition to documenting the limitation, a > new error message when the evaluated $sendmail contains > any (non-space) shell meta-characters would be helpful. > That's a clear indication that the user is expecting > shell parsing that isn't going to happen. Actually, the documentation already did state that $sendmail is a "program and arguments". So it was probably fine. It just didn't explicitly state that it's not an arbitrary shell command. But I see that it's already been improved. I'm sending a patch that adds an error check for shell meta-characters when $sendmail is used. It might have been better to check right after reading .muttrc, but this seemed like a more natural place to put the code (i.e., right after the check that $sendmail exists). cheers, raf
Re: New to Mutt, unable to send messages in *any* attempted way
On Thu, May 19, 2022 at 12:05:59PM -0700, "Kevin J. McCarthy" wrote: > On Thu, May 19, 2022 at 01:12:31PM -0500, Derek Martin wrote: > > On Thu, May 19, 2022 at 11:06:38AM -0700, Kevin J. McCarthy wrote: > > > Sorry, this isn't currently possible in Mutt. The $sendmail variable is > > > handled specially: it's tokenized by space and invoked directly via > > > execvp(). So you won't be able to use arguments with spaces in them > > > inside > > > the variable, or any shell quoting since it doesn't pass through the > > > shell. > > > > Couldn't you do something like the following? > > > > set my_sendmail=/usr/bin/msmtp [...] --passwordeval=$(gpg --no-tty -q -d > > ~/.user.gpg)" > > set sendmail=$my_sendmail > > > > Don't know, haven't tried it, but as long as the first thing evaluates > > to something that sendmail's tokenization can handle, seems like it > > should work... > > $sendmail goes through muttrc evaluation like other variables, but when > invoked to send an email, the resulting string is tokenized by space, '--' > and various arguments inserted as needed, and then passed to execvp(). > > Yes, this should be documented and I'll add it to the config option shortly. > > I don't know why it was written this way, perhaps some security concerns, > but I agree that it's surprising. > > -- > Kevin J. McCarthy > GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA I think the reason would be that mutt is modifying the command, not just executing it. It's modifying a command in a complex external language that it can't parse by itself unless it imposes very strict limitations on the allowable syntax of the command. I don't think it's a security decision. It's just necessary. How would mutt know how to modify sendmail="blah1 | blah2 | blah3" ? I think this limitation should be documented, but not fixed. It could be fixed by adding something like % interpolation placeholders for the things that are added. But that might break existing commands that contain %. Maybe # would be a better choice. But it's still a bad choice. It requires the user to know and use even more notation. An elegant solution already exists. Put complex shell commands in a file and mutt only needs to see its name. But users need to be told when they are required to do that. So in addition to documenting the limitation, a new error message when the evaluated $sendmail contains any (non-space) shell meta-characters would be helpful. That's a clear indication that the user is expecting shell parsing that isn't going to happen. cheers, raf
Re: pattern modifier to select current message in pager?
On Fri, May 06, 2022 at 03:41:56PM -0700, "N.J. Thomas" wrote: > If I am in a folder and I am currently on some message (eg. #702), I'm > looking for a pattern to delete all previous message, up to and > including the selected message. > > I can do this manually by running "D" with the pattern "~m -702" (I had > to type in the number of the currently selected message). > > But if I want to do this for any message I am on (so I can alias > this), I didn't see any pattern modifier in the manual that allowed me > to do this. > > Is this possible? > > thanks, > Thomas Jut guessing, but have you tried: ~m -. In ex/vi, . means the current line. Nope. That doesn't work. Looking at the code, I can see where it would need to be changed (pattern.c:eat_range), but I don't know how to get the index number of the current message. It looks like it's mutt_index_menu()'s MUTTMENU *menu's current field but I don't think that's accessible to eat_range(). It looks like the answer is no. cheers, raf
Re: vs. / vs.
On Wed, Mar 23, 2022 at 06:23:19PM -0400, Kurt Hackenberg wrote: > Procmail is badly outdated, I might be the only person that thinks this, but... If it's still in use and still usable, it's not "outdated". It's just "stable". :-) > and it's a zombie, unmaintained for many years. And yet, Linux distributions (and presumably OpenBSD) manage to apply security patches and keep it compiling on modern systems. That counts as maintenance to me. It just isn't developed anymore. > I suggest that you consider some other delivery agent. > The program fdm looks promising, though I haven't used it. > > Here's a Wikipedia article. > <https://en.wikipedia.org/wiki/Message_delivery_agent> Sieve might be another good one to look at. But I haven't used it. cheers, raf
Re: Filter script to remove html, fullquotes and header lines
On Mon, Mar 21, 2022 at 01:28:28PM +0100, Martin Trautmann wrote: > Am 2022-03-21 um 12:56 schrieb raf: > > textmail can probably do at least some of what you want: > > > >https://raf.org/textmail > >https://github.com/raforg/textmail > > > > and it has some extensibility so you can supply external > > translation programs for the bits it doesn't do. > > > > it can operate on individual mail messages or mbox files. > > check the output carefully. :-) > > Thanks, that looks very helpful to strip attachments, to remove headers > and to convert message bodies - but it lacks the option to perform a > search and replace on message bodies!? The -C option lets you supply a custom external "attachment translation" program. That might help. Something like "-C text/plain:txt:cmd". You just need to write the "cmd" program in the language of your choosing. If it doesn't work, you could modify textmail to do what you need (rather than writing the whole thing) if you like perl. And it might not work. "Converting" to the same mimetype might send it into an infinite loop. :-) I don't think so, but custom translations are done before the built-in ones, so you might need to run textmail twice. I just had a look at your original post. textmail does (1) well. It even detects vestigial text alternatives and doesn't replace html with them. (2) would require a custom translator (but it wouldn't have access to the headers so it can't do the "bonus" part (as is)). it can't delete headers based on their content (as is), only their names, so (3) can't be done as stated. however, you can probably identify the names of headers that are likely to be that long and supply a list of those names. If you try it and run into problems, let me know (off list) and we can probably get it to work. cheers, raf
Re: Filter script to remove html, fullquotes and header lines
On Mon, Mar 21, 2022 at 07:18:01AM +0100, Martin Trautmann wrote: > Am 2022-03-20 um 22:46 schrieb Cameron Simpson: > > I think you'll have to write your own. > > I agree - but I hoped it could have been done with some fine tuning of an > existing script. > > > > At minimum you need a full mail message parser so that you are not > > filtering, say, base64 or QP content incorrectly. So something which > > scans a mailbox and for each message: > > That's why I wondered to do it with mutt - it can do all that stuff. > > > - decodes it completely > > - applies your filters > > - assembles the new message > > and write this out to a new mailbox (so it isn't destructive and can be > > compared to the original - you don't want to accidentally shred your > > archive). > I would work on a copy of the mailbox file first, of course. > > > I'd do this in Python myself - it has a good email library and you can > > do all the things you describe fairly easily with it. > So Python it is... Never programmed it before myself. > > Thans, > Martin i didn't see the original post but... textmail can probably do at least some of what you want: https://raf.org/textmail https://github.com/raforg/textmail and it has some extensibility so you can supply external translation programs for the bits it doesn't do. it can operate on individual mail messages or mbox files. check the output carefully. :-) cheers, raf
Re: A bit off-topic: problems with sending to a Gmail user
On Sat, Mar 12, 2022 at 09:03:37AM +0100, Matthias Apitz wrote: > El día viernes, marzo 11, 2022 a las 03:12:41p. m. +0100, Stefan Hagen > escribió: > > > > I've been seeing a lot of that lately. Google seem to have tightened > > > their email security practice recently. > > > > > > It appears that 1blu is doing something that GMail doesn't like. They > > > probably have a number of users who have the same problem. I would > > > ask them to check their MTA configuration against the section "Make > > > sure your messages are authenticated" in the referenced page > > > (https://support.google.com/mail/answer/81126#authentication). > > > > > > > 550-5.7.26 This message does not have authentication information or > > > > fails to > > > > 550-5.7.26 pass authentication checks. To best protect our users > > > > from spam, the > > > > 550-5.7.26 message has been blocked. Please visit > > > > Authenticated in this context means, you don't have SPF / DKIM / DMARC set > > up. > > > > You can use this service: https://www.mail-tester.com to test your > > setup. It provices you an email address. Send an email to it > > and then your mail and server setup will be evaluated. > > Thank you, Stefan. > > I did such a test and the result can be seen here: > https://www.mail-tester.com/test-ahwup3i9z > > > This is an example from me: > > https://www.mail-tester.com/test-3ghr082f2 > > > > Feel free to examine it and set your host up in a similiar way. > > As far as I understand all the changes can't be done on my host (a > laptop). I send mails with mutt and mutt with sendmail to smtp.1blu.de > > And I'm afraid, if I contact the support of 1blu I don't know if they will > react (I've mixed experience from the past). I will give it a try... > > Thanks > > matthias > > -- > Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 > Public GnuPG key: http://www.unixarea.de/key.pub So it looks like the real problem might be "You're listed in 1 blacklist" (http://www.backscatterer.org). Try to get removed from it. Good luck. It sounds like the mail server you are using needs a configuration change to stop backscatter. Perhaps you could direct your mail server providers to that site. cheers, raf
Re: A bit off-topic: problems with sending to a Gmail user
On Fri, Mar 11, 2022 at 11:55:04PM +, Ken Moffat wrote: > On Sat, Mar 12, 2022 at 09:10:01AM +1100, raf wrote: > > On Fri, Mar 11, 2022 at 03:12:41PM +0100, Stefan Hagen > > wrote: > > > > > > > > > > > 550-5.7.26 This message does not have authentication > > > > > information or fails to 550-5.7.26 pass authentication > > > > > checks. To best protect our users from spam, the > > > > > 550-5.7.26 message has been blocked. Please visit > > > > > > Authenticated in this context means, you don't have SPF / DKIM / > > > DMARC set up. > > > > That's sad. I'm pretty sure that the absence of SPF/DKIM/DMARC was > > never supposed to be interpreted as a failure of any of them. > > Perhaps the sending domain does have SPF but it's not setup > > correctly. It doesn't seem to (unixarea.de). > > > What is *really* sad is that most of the spam which gets through > direct to this account of mine is things apparently from gmail > addresses, pointing to ntlworld/somewhereelse.com addresses inviting > me to login, and with DKIM apparently passing (the last couple I > looked at were relaxed/relaxed). > > ĸen > -- > The beauty of reading a page of de Selby is that it leads one > inescapably to the conclusion that one is not, of all nincompoops, > the greatest.-- du Garbandier That's probably not because it's relaxed/relaxed. It's just that when spammers use gmail to send spam, gmail happily and correctly DKIM-signs the outgoing spam. Gmail only protects gmails users from receiving spam. It doesn't stop them sending spam. At least, that's what seems to be the case. cheers, raf
Re: A bit off-topic: problems with sending to a Gmail user
On Fri, Mar 11, 2022 at 03:12:41PM +0100, Stefan Hagen wrote: > Mark H. Wood wrote (2022-03-11 14:40 CET): > > On Fri, Mar 11, 2022 at 11:43:53AM +0100, Matthias Apitz wrote: > > > I know, it's not the fault of our beloved mutt, but maybe someone is or > > > was in the same problem and knows a solution... > > > > > > We (my family) are member of a fisherman association and I have to send > > > mails to one of the head members in charge for youth training. He has a > > > Google mail account as and any mail gets rejected by > > > Google with the response below. > > > > I've been seeing a lot of that lately. Google seem to have tightened > > their email security practice recently. > > > > It appears that 1blu is doing something that GMail doesn't like. They > > probably have a number of users who have the same problem. I would > > ask them to check their MTA configuration against the section "Make > > sure your messages are authenticated" in the referenced page > > (https://support.google.com/mail/answer/81126#authentication). > > > > > 550-5.7.26 This message does not have authentication information or > > > fails to > > > 550-5.7.26 pass authentication checks. To best protect our users from > > > spam, the > > > 550-5.7.26 message has been blocked. Please visit > > Authenticated in this context means, you don't have SPF / DKIM / DMARC set up. That's sad. I'm pretty sure that the absence of SPF/DKIM/DMARC was never supposed to be interpreted as a failure of any of them. Perhaps the sending domain does have SPF but it's not setup correctly. It doesn't seem to (unixarea.de). > You can use this service: https://www.mail-tester.com to test your > setup. It provices you an email address. Send an email to it > and then your mail and server setup will be evaluated. > > This is an example from me: > https://www.mail-tester.com/test-3ghr082f2 > > Feel free to examine it and set your host up in a similiar way. A good tutorial site for setting it up (at least with debian+postfix) is at https://www.linuxbabe.com/mail-server/build-email-server-from-scratch-debian-postfix-smtp (in 12 parts, part 4 is SPF+DKIM, part 5 is DMARC). > Best Regards, > Stefan cheers, raf
Re: trouble with sending emails from alternate email account
On Sun, Feb 13, 2022 at 11:28:15AM -0600, Ranjan Maitra wrote: > On Sun Feb13'22 09:25:12AM, Charles Cazabon wrote: > > From: Charles Cazabon > > Date: Sun, 13 Feb 2022 09:25:12 -0600 > > To: mutt-users@mutt.org > > Subject: Re: trouble with sending emails from alternate email account > > > > Ranjan Maitra wrote: > > > I am no longer able to send email from mutt from anything other than my > > > office account > > [...] > > >[2022-02-12 23:18:26] 5> AUTH PLAIN (removed) > > >[2022-02-12 23:18:27] 5< 535 Authentication credentials invalid > > >[2022-02-12 23:18:27] 5< 535 Authentication credentials invalid > > > > Looks like your SMTP AUTH credentials are not valid :) You should probably > > contact your mailhost for assistance. > > > > Thank you for this, it turns out that funky .muttrc settings are not > called for, but rather, the issue may be quiet withdrawal of SMTP > access on the base account, followed by my (now) somewhat noisier > withdrawal from that account. > > Best wishes, > Ranjan In case anyone comes here via a search, another reason that authentication credentials can suddenly stop working is because someone has hacked into the email account and changed the password (presumably via a web interface). cheers, raf
Re: mutt 2.2.0 released
On Sat, Feb 12, 2022 at 01:41:14PM -0800, "Kevin J. McCarthy" wrote: > Hello Mutt Users, > > I'm pleased to announce the release of version 2.2.0. > > Instructions for downloading are available at > <http://www.mutt.org/download.html>, or the tarball can be directly > downloaded from <http://ftp.mutt.org/pub/mutt/>. Please take the time to > verify the signature file against my public key[1]. > > This release has new features as well as many bug fixes. Please see the > UPDATING file, and also please take a look at the release notes: > <http://www.mutt.org/relnotes/2.2/>. > > My thanks to everyone who contributed patches, tickets, documentation > updates, and helped test. > > Thank you, > > -Kevin > > > [1] > My public key is available at: > - my personal website: https://www.8t8.us/configs/80316BDA.asc.pubkey > - the mutt website: http://www.mutt.org/keys/kevin.key > - The keys.openpgp.org network > > https://keys.openpgp.org/vks/v1/by-fingerprint/8975A9B33AA37910385C5308ADEF768480316BDA Hi Kevin! Thanks so much for all you do. It's sad to hear that you'll have less time and energy for mutt now. I hope all will be well for you. cheers, raf
Re: Slightly OT: I'm looking for a tool to merge maildirs
On Mon, Jan 24, 2022 at 10:24:41AM +1100, Cameron Simpson wrote: > On 23Jan2022 10:46, Chris Green wrote: > >This is a bit off topic for mutt specifically but it's about doing > >things to the mail I read using mutt, so it's not *very* OT. :-) > > Had you considered a shell script which invokes mutt with -e to copy > messages tagged by criteria from a mail folder to your archive folder? > > Cheers, > Cameron Simpson That sounds clever and simple. I was thinking of https://github.com/lefcha/imapfilter but you'd need to know lua, and have imap access (rather than just file system access) to both sets of messages. cheers, raf
Re: [Mutt] help on complicated per-folder or per-sender sending email hooks
On Sat, Nov 27, 2021 at 12:36:54PM +0100, Mihai Lazarescu wrote: > On Friday, November 26, 2021 at 23:41:46 -0600, mai...@email.com wrote: > > > Basically, if the email is postponed and called from the draft, it uses my > > work account (because that is set up to be the default). Is it possible to > > set things up so that mutt will look at the sending address (@email dot com > > or the work address, say) and decide to use the appropriate smtp? > > send2-hook seems the closest, but it's only triggered after edits: > > http://www.mutt.org/doc/manual/#send2-hook > > «send2-hook is matched every time a message is changed, either by editing > it, or by using the compose menu to change its recipients or subject. > send2-hook is executed after send-hook, and can, e.g., be used to set > parameters such as the $sendmail variable depending on the message's sender > address.» > > For other cases you may want to define macros to manually change the roles, > e.g.: > > macro index,pager,compose ":set from = ...:set smtp_url > = ...:set smtp_pass = ...:set smtp_url" > > The last :set smtp_url just displays the current SMTP URL so you can double > check that you called the right macro. :-) > > Best, > Mihai When I have had to do things based on the sender address, I had to "set editor" to a script that would perform the necessary modifications to the email before and after invoking the real editor on the file. cheers, raf
Re: The (old) linewrap issue with URLs etc.
On Fri, Nov 12, 2021 at 01:53:31PM +, Chris Green wrote: > I have a reasonable workaround, add a pager macro:- > > macro pager l "|less > > I can then right click on the URL in 'less' and select the whole URL. > It would be nice to be able to bypass the "Press any key to continue..." > but I can live with that. (there isn't a prompt_after setting for | > is there?). > > -- > Chris Green You can suppress that. Use less's -e option (to automatically exit the second time it reaches end-of-file), or -E option (to automatically exit the first time it reaches end-of-file). If you always that behaviour, set the environment variable (e.g.) LESS=-e cheers, raf
Re: OT: "domain-level" email hosting services?
On Sat, Oct 23, 2021 at 06:15:35PM +0200, Jens John wrote: > On Sat, 23 Oct 2021, at 16:21, Bastian wrote: > > The stack I use is exim, spamassassin, dovecot on debian > > stable since ~2006. > > If somebody would set something up new today, I would recommend the following > 3-piece software stack: > > 1. postfix as the SMTP server and Let's Encrypt for a proper validated host > SSL certificate > > 2. dovecot as the IMAP mailbox server > > 3. rspamd as the "policy engine". It can validate incoming SPF, > DKIM, DMARC and ARCs which are all current best practice among the > commercial email hosts, and it also can apply DKIM signatures and > ARC seals to outgoing mail in a standards compliant way. The usual > spam learning techniques are all implemented in rspamd, and it can > interface with spamassassin, clamav etc as well. rspamd is very useful > to prevent the piling up of different milters in postfix which work > all differently. Thanks. I didn't realise that rspamd did all that. For anyone using Let's Encrypt / certbot for their mail server certificate, I'd like to throw in a shameless plug for a little program I wrote that makes it easy to properly implement DANE (DNS-Based Authentication of Named Entities), which is supported by both Postfix and Exim. It's at https://github.com/raforg/danectl DANE makes it possible for a mail server administrator to let other mail servers know in advance, not only that encryption is supported, but also precisely which key will be used, thus making it possible to eliminate man-in-the-middle attacks between mail servers (as long as the other mail servers are DANE-aware). It's like MTA-STS except that it's good. You do need DNSSEC for your domain as a prerequisite, but that has become incredibly easy these days (e.g., one extra line of Bind9 config in Debian stable, or a checkbox in Google's Cloud DNS service). Even if you don't have DNSSEC or want this for your own mail server, I'd recommend running a local DNSSEC-validating DNS resolver on your mail server (e.g., Bind9, Unbound), and enabling the client-side of DANE-awareness in your mail server. You'd need /etc/resolve.conf to look like this: nameserver 127.0.0.1 options trust-ad For Postfix, you'd need this in main.cf: smtp_dns_support_level = dnssec smtp_tls_security_level = dane For Exim, you'd need: dns_dnssec_ok = 1 remote_smtp: hosts_try_dane = * cheers, raf
Re: OT: "domain-level" email hosting services?
On Sat, Oct 23, 2021 at 02:22:18PM -0400, Nathan Stratton Treadway wrote: > On Sat, Oct 23, 2021 at 09:55:12 -0400, Ofer Inbar wrote: > > I run postfix on a cheap cloud-hosted linux instance. That does mean > > Thanks all (Ofer, Bastian, raf, etc.) for this suggestion -- I tend to > agree with you that giving up access to the mail server logs would be a > big loss over my current setup. > > Do any of you have specific recommendations for cheap cloud providers > who don't mind customers running their own mail servers on the VMs? The > first couple cloud providers I looked at (e.g. Digital Ocean) seem to > discourage that (and actually mention that SMTP traffic is blocked on > their networks, though I didn't dive in to figure out the details of > what is blocked), so it didn't seem like those we be a good fit for what > I'd be trying to do > > > Nathan I use OVH. Unlike AWS/EC2, OVH gives you virtual console access, so any problems with booting the VPS can be investigated and solved. Their only restriction (if I remember correctly) is that you must not do any port scans or anything illegal from their VPSs. Advice: If your IPv6 address ever gets added to an RBL because the RBL refuses to accept that IPv6 addresses can be assigned individually, and someone nearby is sending spam, you set can set "smtp_address_preference = ipv4" in Postfix's main.cf to only use the IPv4 address to send email (while still allowing the IPv6 address to be used to accept mail). I had to do that because another OVH customer is presuably sending spam. By the way, a good tutorial for setting up postfix and all the addons can be found here: https://www.linuxbabe.com/mail-server/build-email-server-from-scratch-debian-postfix-smtp There are 12+ parts to it. I used it for setting up SPF/DKIM/DMARC. The rest is probably good too. cheers, raf
Re: OT: "domain-level" email hosting services?
On Fri, Oct 22, 2021 at 08:43:02PM -0400, Nathan Stratton Treadway wrote: > I've always just run my own (Linux) email server locally in my home > office, but my current Internet service is soon going to be going away > and I was wondering if it would make sense to move to some sort of > mail-hosting company as part of reorganizing my network setup. > > 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? > > Or alternatively some service that queues incoming Internet mail for my > domains and then allows the queued email to be fetched by my local mail > server for local delivery (thus avoiding having an open SMTP port on my > home connection to the Internet)? > > (I currently host a few domains and deliver mail to ~5 users via hundreds > of aliases) > > Thanks for any ideas I should consider. > > Nathan A cheap virtual private server running postfix, dovecot, amavis, spamassassin or rspamd, postfix-policyd-spf-perl, OpenDKIM, and OpenDMARC will do the trick if you don't mind the hassle of setting everything up. :-) cheers, raf
Re: question/suggestion
On Fri, Oct 08, 2021 at 06:50:24PM +1100, raf wrote: > My advice is, don't worry about the default. > If you don't like it, just change it. > > "man muttrc" and look for "forward_format". > > I think you want something like this in your ~/.muttrc: > > set forward_format = "Fwd: %s" > > or: > > set forward_format = "FW: %s" > > They are both common patterns. > > And they are both much shorter than the default, > since they don't include the forwarder's email > address or the enclosing square brackets. > > Don't get me wrong. You have a good point. The > forwarder's email address doesn't need to appear in the > Subject: header because it also appears in the From: > header (even though many mail clients don't show that > for some reason which is a bad thing), and if it > matters that an email was forwarded, that fact can be > indicated in the Subject: header. > > But changing defaults affects others that might like > things the way they are. Although, I suspect that many > users probably wouldn't mind one way or the other. > I admit that I've never liked "FW:". "Fwd:" is better. > But I'm also OK with it how it is. I don't think I > forward emails very often, so my opinion probably > doesn't matter. > > cheers, > raf Sorry, I just realised that the default forward_format contains the *original* sender's email address. That's not what ends up in the From: header of the forwarded email like I said earlier. That shows how often I forward emails. :-) I think I prefer that to the dominant convention of adding FW: or Fwd: and not including where it is forwarded from. cheers, raf
Re: question/suggestion
My advice is, don't worry about the default. If you don't like it, just change it. "man muttrc" and look for "forward_format". I think you want something like this in your ~/.muttrc: set forward_format = "Fwd: %s" or: set forward_format = "FW: %s" They are both common patterns. And they are both much shorter than the default, since they don't include the forwarder's email address or the enclosing square brackets. Don't get me wrong. You have a good point. The forwarder's email address doesn't need to appear in the Subject: header because it also appears in the From: header (even though many mail clients don't show that for some reason which is a bad thing), and if it matters that an email was forwarded, that fact can be indicated in the Subject: header. But changing defaults affects others that might like things the way they are. Although, I suspect that many users probably wouldn't mind one way or the other. I admit that I've never liked "FW:". "Fwd:" is better. But I'm also OK with it how it is. I don't think I forward emails very often, so my opinion probably doesn't matter. cheers, raf
Re: Binding Space to select-entry gives Key is not bound.
On Mon, Sep 20, 2021 at 08:31:07PM -0700, "Kevin J. McCarthy" wrote: > Thanks raf, I certainly can't say your opinion is due to a lack of > experience with Mutt! However, just to be clear to everyone, my opposition > to the "tag" interpretation is because of Mutt's current usage of > . > > Menus that allow both single and multiple selection (e.g. alias list, file > browser, query menu) use tagging for multiple selection and > for single selection. Menus that allow single selection (e.g. > background-edit list, key selection, postponed list) respond to > by immediately using/processing the entry (and usually, > though not always, exiting the menu afterwards). That convinces me that makes much more sense. There's still so much I don't know about mutt. :-) Great programs are like that. > I understand that in general the term "selection" can be interpreted either > way. But consistent usage within Mutt is important to me, and I think is a > good design principle. Definitely agree. > The default bindings for are overshadowed by the default > bindings for in the index. But for those who re-bind it, > I don't think there's a good reason to drastically change its behavior in > the index, compared to everywhere else in Mutt. As you noted, the way to > operate on or select multiple entries in Mutt is already well established: > via tagging. > > Now, there *is* one case where the index is used as a selection menu: > attaching messages. Currently that interface forces selection (either one > or multiple message) via tagging. One could make an argument > could be used in that case for single selection and immediately returning. > But it would entail some technical changes to an already complicated menu, > as well as requiring a *new* keybinding in the index. Since that operation > isn't all that common I don't know that it would be worth it, but I'd be > open for that discussion (on mutt-dev). I think it's usually a bad idea to implement something that solves a problem that isn't actually affecting anyone yet. This sounds like a case of that. There will definitely be better ways to spend your finite remaining keystrokes. :-) > -- > Kevin J. McCarthy > GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA cheers, raf
Re: Binding Space to select-entry gives Key is not bound.
On Sat, Sep 18, 2021 at 07:28:14PM -0700, "Kevin J. McCarthy" wrote: > On Sat, Sep 18, 2021 at 04:34:10PM -0700, li...@ifohancroft.com wrote: > > Personally, I see a couple of possible solutions for select-message in > > index: > > Thanks for the feedback. > > I don't agree with #3, though. It sounds like you've recently started using > Mutt and are still adjusting to some of the concepts. I understand the > initial confusion, but that's not a justification for changing basic > functionality around. > > #1 is awkward to implement. > > So I'm still debating between making equivalent to > or just having it print an error message. > > > > If your expectation wasn't to display the message with this > > > function, then perhaps it's better to not make it equivalent to > > > display-message, but try to display a more appropriate error message > > > instead. > > > > This is exactly what I meant. I think it would be best to not make it > > equivalent to display-message in the index. > > Since the function isn't currently implemented, I don't see the harm in > making them equivalent. Displaying the message seems the most natural > interpretation of "selection" in the index when compared to its usage in the > other menus. > > Do any old timers have an opinion on this? > > -- > Kevin J. McCarthy > GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA Tagging/untagging the current message seems like another natural interpretation of "select" to me. I'm not advocating for that. It's just what I think of as "selection". But you don't agree with that (the first half of #3). I guess the difference is whether you think that a "selection" can only contain a single item and so the purpose of the selection should be performed immediately (so display-message makes sense), or whether a selection can contain multiple items and so the purpose of the selection might need to be delayed until the selection process is complete (so tag-entry makes sense). But like I said, I'm not advocating for this. I don't even tag messages, and even if I did, there's already a keystroke for doing that. cheers, raf P.S. Thanks so much for all your work on mutt. It's much appreciated, every single day.
Re: using mutt with postfix and localhost:25
On Sun, Sep 12, 2021 at 03:17:46PM +, Globe Trotter via Mutt-users wrote: > So, I do not know if I can do this, but I can send email by > specifically including the smtp with port 25. I dont really need it > for anything else. It is quite likely that I am not understanding the > import of your question. > > All I do is: > > sudo ssh -L 25:mailhub:25 username@your_server > > And then, configuring 'localhost' as my smtp server on port 25 gets my > mail sent directly forward through the SSH link. > > Thanks! Ah, it's making sense now. But is there a reason you need the ssh tunnel? Does it work if you set smtp_url=smtp://mailhub:25 instead? Don't get me wrong, I think there are never enough ssh tunnels in the world, but it might not be needed here. If the postfix server has TLS configured, and will accept the connection, mutt will take advantage of STARTTLS and the traffic will be encrypted. cheers, raf
Re: using mutt with postfix and localhost:25
On Sat, Sep 11, 2021 at 08:23:04AM -0700, Michael Slouber wrote: > On 09/11/21 01:24PM, Globe Trotter via Mutt-users wrote: > > Thanks very much! I am unable to send mail using postfix. However, > > the same setting makes it work for sylpheed when I simply specify > > localhost:25 in the SMTP server so I think that the postfix is set > > up all right, perhaps. If postfix is configured correctly, and mail submitted via localhost:25 does get delivered, then the default value for mutt's sendmail parameter should also work. What do you mean when you say you are unable to send mail using postfix? Sending mail using postfix means using a mail user agent like mutt which by default submits mail for delivery by invoking postfix's sendmail-compatible /usr/sbin/sendmail program to submit mail to postfix's mail queue, after which postfix will deliver it. What acually goes wrong when you try to send email from mutt with the default setting for the sendmail parameter? > This setting in Muttrc works for me: > > set smtp_url = "smtp://localhost:25" This is intended for using a remote smarthost to send mail through. It shouldn't be necessary for localhost. It works, but it's probably slightly slower because it has to perform the SMTP dialogue. If postfix can deliver mail submitted by mutt this way, it should also be able to deliver mail submitted by mutt the default way. cheers, raf
Re: using mutt with postfix and localhost:25
On Sat, Sep 11, 2021 at 05:24:21PM +1000, raf wrote: > On Sat, Sep 11, 2021 at 05:31:13AM +, Globe Trotter via Mutt-users > wrote: > > > Hi, > > > > I have an account where I need to send email through localhost > > (with port 25). I am using postfix currently, but I do not know > > much. Anyway, on sylpheed, I used to say: localhost:25 as the SMTP > > server and life was good. So, my question is how do I set it up for > > this account to use SMTP server localhost:25? (The other accounts are > > personal and will use gmx, etc, SMTP settings). I have been using > > postfix because my work email uses postfix as given by my sysadmin (I > > think that it changes the relayhost name) and perhps the same can be > > done with something like msmtp but i do not know. > > > > Thanks! > > The typical way to submit mail locally is via > /usr/sbin/sendmail. That's the default in mutt (and > probably all other MUAs). The explicit default is: > > set sendmail="/usr/sbin/sendmail -oem -oi" > > You shouldn't have to do anything to make this happen. > It's the default. > > Technically, postfix's sendmail binary doesn't use SMTP > (it runs postdrop to add the message to postfix's mail > queue) but that shouldn't matter. It's functionally > equivalent to using SMTP on localhost:25, so you > shouldn't need to care. > > But, if you really have a reason to avoid the default, > more efficient, already working thing, and make > absolutely sure that you are directly connecting to > localhost:25, you should search for a different > sendmail-compatible program that does SMTP to > localhost:25, install it, and then set mutt's sendmail > variable to refer to that: > > In ~/.muttrc: > set sendmail="/path/to/other/sendmail -oem -oi" > > But it sounds very much as though you really don't need > to do this. It sounds like you just need the local mail > server to deliver mail sent from mutt, and if you have > postfix installed locally and configured OK, that will > just happen. > > cheers, > raf I've probably misunderstood what you are asking. If you have mutt configured for using different accounts, and already have it set up to change hwo it sends mail depending on which account you are looking at, just configure it to use the default sendmail setting above for the account that requires local delivery. If I've still misunderstood, maybe you could show how you are currently configuring mutt to use gmx's SMTP server etc. for the other accounts. cheers, raf
Re: using mutt with postfix and localhost:25
On Sat, Sep 11, 2021 at 05:31:13AM +, Globe Trotter via Mutt-users wrote: > Hi, > > I have an account where I need to send email through localhost > (with port 25). I am using postfix currently, but I do not know > much. Anyway, on sylpheed, I used to say: localhost:25 as the SMTP > server and life was good. So, my question is how do I set it up for > this account to use SMTP server localhost:25? (The other accounts are > personal and will use gmx, etc, SMTP settings). I have been using > postfix because my work email uses postfix as given by my sysadmin (I > think that it changes the relayhost name) and perhps the same can be > done with something like msmtp but i do not know. > > Thanks! The typical way to submit mail locally is via /usr/sbin/sendmail. That's the default in mutt (and probably all other MUAs). The explicit default is: set sendmail="/usr/sbin/sendmail -oem -oi" You shouldn't have to do anything to make this happen. It's the default. Technically, postfix's sendmail binary doesn't use SMTP (it runs postdrop to add the message to postfix's mail queue) but that shouldn't matter. It's functionally equivalent to using SMTP on localhost:25, so you shouldn't need to care. But, if you really have a reason to avoid the default, more efficient, already working thing, and make absolutely sure that you are directly connecting to localhost:25, you should search for a different sendmail-compatible program that does SMTP to localhost:25, install it, and then set mutt's sendmail variable to refer to that: In ~/.muttrc: set sendmail="/path/to/other/sendmail -oem -oi" But it sounds very much as though you really don't need to do this. It sounds like you just need the local mail server to deliver mail sent from mutt, and if you have postfix installed locally and configured OK, that will just happen. cheers, raf
Re: multiple color schemes
On Wed, Sep 08, 2021 at 03:47:00PM -0400, Jon LaBadie wrote: > On Wed, Sep 08, 2021 at 04:31:11PM +1000, raf wrote: > > On Wed, Sep 08, 2021 at 01:20:27AM -0400, Jon LaBadie > > wrote: > > > > > I've always preferred a black letters on white background scheme. > > > However, after cataract surgery I'm considering using a dark > > > background scheme. > > > > > > Has anyone a technique for defining multiple color schemes and > > > toggling among them while using mutt? > > > > > > I already keep my color scheme in a separate file and source > > > that file from ~/.muttrc. To extend that, I created two > > > files for light and dark schemes and separate macros (,l and ,d) > > > to source them while running mutt. > > > > > > I'd like to reduce that to a single macro that toggles between > > > the files or one that allows selecting from multiple scheme > > > files, perhaps in round robin fashion. > > > > Someone else will probably give a better answer, but > > here goes. If you have different colour schemes setup > > in different files, you can probably set up a macro in > > your ~/.muttrc that enables the colour scheme you want > > by sourcing the relevant file. e.g. something like: > > > > macro index something :source colour-scheme-1.muttrc\n > > macro index something :source colour-scheme-2.muttrc\n > > > > Where "something" is a key sequence that doesn't > > already do something you care about (e.g. A1, A2). > > That is exactly what I've currently implemented. > > For macro names, I sometimes pick my favorite single letter > and add a leading comma. So my two macros are named ,d (dark) > and ,l (light). > > > Toggling will be more complicated, but doable, if it's really > > needed. It might involve having the macro source a single file, > > and also run an external command that replaces the contents of > > that file with the "other" file. e.g. something like: > > schemes that edit or copy files seem too prone to unanticipated > mess-ups. > > Jon > -- > Jon H. LaBadie j...@labadie.us > 11226 South Shore Rd. (703) 787-0688 (H) > Reston, VA 20190 (703) 935-6720 (C) Yes. Oleg's approach is much better. cheers, raf
Re: Send mail macro from vim
On Mon, Sep 06, 2021 at 03:48:33PM -0700, Tom Tunguz wrote: > Raf, amazing. Thank you. Brilliant. I mapped it to K (which is unused and > it's now lightning fast) Ky! > > Thank you thank you! That's great. I'm glad it helped. cheers, raf
Re: multiple color schemes
On Wed, Sep 08, 2021 at 01:20:27AM -0400, Jon LaBadie wrote: > I've always preferred a black letters on white background scheme. > However, after cataract surgery I'm considering using a dark > background scheme. > > Has anyone a technique for defining multiple color schemes and > toggling among them while using mutt? > > I already keep my color scheme in a separate file and source > that file from ~/.muttrc. To extend that, I created two > files for light and dark schemes and separate macros (,l and ,d) > to source them while running mutt. > > I'd like to reduce that to a single macro that toggles between > the files or one that allows selecting from multiple scheme > files, perhaps in round robin fashion. > > -- > Jon H. LaBadie mut...@jgcomp.com > 11226 South Shore Rd. (703) 787-0688 (H) > Reston, VA 20190 (703) 935-6720 (C) Someone else will probably give a better answer, but here goes. If you have different colour schemes setup in different files, you can probably set up a macro in your ~/.muttrc that enables the colour scheme you want by sourcing the relevant file. e.g. something like: macro index something :source colour-scheme-1.muttrc\n macro index something :source colour-scheme-2.muttrc\n Where "something" is a key sequence that doesn't already do something you care about (e.g. A1, A2). You might also need to define the macro in other places in addition to "index". Toggling will be more complicated, but doable, if it's really needed. It might involve having the macro source a single file, and also run an external command that replaces the contents of that file with the "other" file. e.g. something like: macro index AA :!toggle-colour-scheme\n:source next-colour-scheme.muttrc\n If you see what I mean (toggle-colour-scheme is a command that swaps the files around). Note: None of this is tested. It's just conjecture. cheers, raf
Re: Send mail macro from vim
On Sun, Sep 05, 2021 at 05:25:16PM -0700, Tom Tunguz wrote:
> To be clear, I've tried this:
>
> macro *compose* \cx ":wq"
>
> On Sun, Sep 5, 2021 at 5:22 PM Tom Tunguz wrote:
>
> > I'd like to set a macro to send mail directly from the compose window
> > using vim.
> >
> > In other words, I'm responding to a mail, I reply to it, open it in vim.
> > Then I want to hit a macro and have it execute :wq and then
> > .
> >
> > I've tried
> >
> > bind macro S ":wq"
> >
> > but that doesn't work. Thank you for your help!
Hi, I'll be very surprised if what you are trying to do
can work. Firstly, I think the "compose" refers to the
compose menu
(http://www.mutt.org/doc/manual/#intro-compose), not
the editor, which is a separate process.
If you want a macro that you can enter while in vim (to
save the file and then tell mutt to send the message),
it would have to be a vim macro, not a mutt macro, and
it would have to do something like place extra
keystrokes into stdin for mutt to consume after vim has
terminated. That might be possible, but I wouldn't know
how to do that. You might have luck asking on the vim
users mailing list (but see below).
But I don't really know much about the compose menu.
Perhaps I'm wrong.
However, what might work is some feature of your
overall environment, rather than individual programs
like mutt or vim. For example, if you use X11, and run
vim from a xterm, and it runs vim in the same xterm
(i.e. not gvim), then you could create the macro as an
Xresource like XTerm*VT100.Translations. It works at
the terminal emulator level, rather than at the level
of the programs running within the terminal emulator.
Maybe something like this:
~/.xresources:
XTerm*VT100.Translations: #override \
Ctrl F1: string(":wq\ny")
No, that doesn't work. The y character gets lots. Vim
must be reading it. And I think you can only translate
a single keystroke combination, not multiple keys like
\cx.
If you use a mac, you might be able to do something
similar with Karabiner, or Automator.
Sorry, I think I've run out of ideas. It seems like
too much effort to save a single keystroke.
But since you're willing to expend three keystrokes
"\cx", you could probably change it to \cy or
similar, where the \c is a vim map that does :wq
and the y is left for mutt to consume. That seems to
work, and you don't even need to pause before the y.
~/.vimrc:
map \c :wq
map! \c :wq
But it won't work if your editor is gvim, and its window
isn't directly over the terminal emulator that mutt is in.
It would be more reliable if you used vim rather than gvim
as the editor, or make sure that your gvim window has the
same size and position as mutt's terminal emulator window.
cheers,
raf
Re: Automatic Key Search for email Sender?
On Tue, Aug 31, 2021 at 06:49:27PM -0700, Will Yardley wrote: > On Tue, Aug 31, 2021 at 05:13:45PM -0400, D.J.J. Ring, Jr. wrote: > > Is there a way to get mutt to automatically search for a gpg key for an > > email sender and put it in my keychain? > > GPG can be configured to do this _if_ the key is on public keyservers > > See: > https://gitlab.com/muttmua/mutt/-/wikis/MuttGuide/UseGPG#retrieval-of-keys-from-a-keyserver That page doesn't mention it, but there are multiple places to get a key from. gpg's --auto-key-locate option lets you specify a comma-separated list of places to look (or multiple instances). See the gpg(1) manpage for details. e.g. --auto-key-locate local,wkd,dane,keyserver-URL (The default is local,wkd). Actually, the manpage says that this is for when encrypting (i.e. sending an email). It doesn't mention verifying a signature (i.e. receiving an email). That seems wierd. cheers, raf
Re: index-format-hook date pattern for current week
On Tue, Aug 31, 2021 at 05:54:23AM -0700, li...@ifohancroft.com wrote: > Hi, > > I am using an index-format-hook inside of index_format, to change the way > the date column is displayed based on how old the email is. > > My current setting is the following: > > # ID, Attachments, Flags, Subject, Correspondent, Date > set index_format = "%4C %?X?& > ?%-1.1@replied@%-2.2@encrypted@%-1.1@flagged@ %-92.92s > %-64.64@correspondent@ %* %10@date@" > > index-format-hook date "~d<1d" "%[%H:%M]" # If it's from today - I only want > the time > index-format-hook date "~d<1w" "%[%d %a]" # If it's from this week - I only > want the day and the date > index-format-hook date "~d<1y" "%[%b %d]" # If it's from this year, I only > want the date and the month > index-format-hook date "~A" "%[%d/%m/%Y]" # If it's from a past year I only > want the date, the month and the year > > The rest works as I want it to and as I expect it to, besides the week > pattern. If any email is from the last seven days, it gets caught by the > week pattern. I don't want that. I want only emails from the current week to > get caught by the week pattern, not all emails from the last 7 days. > > Here's what is currently happening: > > Today is Tuesday, August 31st. In my email, currently, the oldest email > being caught by the week pattern is from Wednesday, August 25th. > > Here's what I want to be happening: > > Today is Tuesday, August 31st. In my email, the oldest email that should be > getting caught by the week pattern should be from Monday, August 30th. > > Is there another week pattern or another pattern in general, that I can use > to make that happen or perhaps a way to make the current pattern work like > this? > > Best Regards, > IFo Hancroft Perhaps you could use an actual date, and cron a weekly update to your .muttrc file (and not leave mutt running for too long). cheers, raf
Re: disable gpg in mutt
On Thu, Aug 26, 2021 at 03:06:18PM +0200, Fourhundred Thecat <400the...@gmx.ch> wrote: > Hello, > > how can I completely disable gpg integration in mutt ? > > If message happens to be encrypted, I would like mutt to simply show me > the source (encrypted). > > I thought, I don't have gpg configured, but when I wanted to compose new > message, this happened: > > Recall postponed message? ([yes]/no): > > Enter PGP passphrase: > > Decryption failed. > > I don't know how that happened. I am using gpg on the same account, but > through Thunderbird client. I have Thunderbird set up locally on my > laptop with gpg, and I am using mutt to read messages remotely on the > server. That is why I don't want to use gpg in mutt, so that I don't > have to type my password on the remote server. > > anyway, > > how can I use mutt unaware of gpg ? > > thanks, I found putting this in my ~/.muttrc helpful when gpgme was turned on in the default system-wide debian config for mutt: set crypt_use_gpgme = no cheers, raf
Re: Wordwrap of long lines
On Wed, Aug 11, 2021 at 05:40:05PM -0400, "D.J.J. Ring, Jr." wrote: > I found that "man mutt" is not the whole manual. There's also "man muttrc" for the config file syntax. That's the most important one. cheers, raf
Re: Using UTC time in Date header
On Fri, May 14, 2021 at 09:43:21PM -0400, John Hawkinson
wrote:
> For what it's worth, I have a desire for the opposite kind of feature,
> although I don't quite know how it should work.
> I want to see and use timezones as displayed in messages as long as
> they are nearby US timezones that my brain is facile with the trivial
> arithmetic for (i.e. US/Eastern, US/Central, US/Pacific, and I suppose
> the rare US/Mountain).
>
> But when a header comes in UTC, I'd much rather convert it to local
> time, especially so I don't have to think about how DST affects the
> offset.
> [...]
> --
> jh...@alum.mit.edu
> John Hawkinson
When my workplace switched to office365 (all but me anyway),
their emails started arriving with UTC date headers. So I
wrote a procmail recipe to filter incoming emails through
a little perl script to convert the date header to my timezone.
it's attached. the local timezone is hardcoded (sorry) but
can be changed as needed.
cheers,
raf
#!/usr/bin/env perl
use warnings;
use strict;
# procmail_filter_fix_outlook_date_header.pl
#
# This is an email filter to be run by procmail as email arrives.
# It replaces UTC Date: headers in incoming email with the local timezone.
# Outlook/Exchange refuses to use the sender's local timezone in Date: headers.
# This can't recover the lost information about the true timezone of the
# sender, but at least you won't need to perform timezone calculations in
# your head when reading emails from your own work colleagues.
#
# usage (in ~/.procmailrc):
#
# :0 fw
# * ^From:.*@(domain_that_uses_exchange\.com|and_another\.com)
# | procmail_filter_fix_outlook_date_header.pl
#
# WARNING: This is hard-coded to convert UTC to Australia/Sydney
# and needs to be modified if you are in a different timezone.
#
# 20200205 raf
# Update these suit your local timezone.
my $local_tz = 'Australia/Sydney'; # Or `cat /etc/timezone` if present ($TZ didn't work for me)
my @local_offsets_by_dst = ('+1000', '+1100'); # How to get these programmatically?
use POSIX;
my %month_name2num = (Jan => 0, Feb => 1, Mar => 2, Apr => 3, May => 4, Jun => 5, Jul => 6, Aug => 7, Sep => 8, Oct => 9, Nov => 10, Dec => 11);
my %month_num2name = (0 => 'Jan', 1 => 'Feb', 2 => 'Mar', 3 => 'Apr', 4 => 'May', 5 => 'Jun', 6 => 'Jul', 7 => 'Aug', 8 => 'Sep', 9 => 'Oct', 10 => 'Nov', 11 => 'Dec');
my %day_num2name = (0 => 'Sun', 1 => 'Mon', 2 => 'Tue', 3 => 'Wed', 4 => 'Thu', 5 => 'Fri', 6 => 'Sat');
while (<>)
{
# Date: Tue, 4 Feb 2020 22:41:34 +
my ($day, $month, $year, $hour, $minute, $second, $eol) = /^Date: (?:Sun|Mon|Tue|Wed|Thu|Fri|Sat),\s+(\d{1,2})\s+(Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec)\s+(\d{4})\s+(\d{1,2}):(\d{2}):(\d{2}) \+(?:\s+\([A-Z]+\))?(\s*)$/;
if (defined $day && defined $month && defined $year && defined $hour && defined $minute && defined $second)
{
print('X-Original-' . $_);
local($ENV{TZ}) = 'UTC';
my $t = mktime $second, $minute, $hour, $day, $month_name2num{$month}, $year - 1900;
$ENV{TZ} = $local_tz;
my ($sec, $min, $hr, $d, $m, $y, $wday, $yday, $isdst) = localtime($t);
$_ = sprintf('Date: %s, %d %s %d %02d:%02d:%02d %s%s',
$day_num2name{$wday}, $d, $month_num2name{$m}, @{[$y + 1900]},
$hr, $min, $sec, $local_offsets_by_dst[$isdst], $eol);
}
print;
}
# vi:set ts=4 sw=4:
Re: Using UTC time in Date header
On Fri, May 14, 2021 at 02:22:43PM -0600, Gregory Anders
wrote:
> Hi all,
>
> The Date: header that Mutt adds to my sent emails includes my time zone
> offset. I would prefer to have the header present the time of my email in
> UTC time (offset 0). I wasn't able to find a setting that controls this. In
> fact, I'm not sure how Mutt is getting my time zone at all, since I'm quite
> sure I haven't set it anywhere in my configuration.
>
> Is this possible to do? If not I may take a stab at creating a patch.
>
> Thanks,
> Greg
hi,
your default timezone would probably have been selected
when your operating system was installed. but it can be
overridden easily.
just create a shell function like this:
mutt() { TZ=UTC /usr/bin/mutt "$@"; }
and put it in a shell startup file.
cheers,
raf
Re: Differences and interactions between subscribe, lists, group, alternates and alias.
On Mon, Feb 15, 2021 at 06:04:03PM -0600, boB Stepp wrote: > On 21/02/16 12:28AM, Øyvind A. Holm wrote: > > On 2021-02-16 00:17:22, Øyvind A. Holm wrote: > > > On 2021-02-15 16:01:06, boB Stepp wrote: > > > > > On Monday, 15 February at 21:53, boB Stepp wrote: > > > > > > And from reading the Mutt manual I have encountered the > > > > > > alternates option, but now I am not sure what it is useful for > > > > > > and how to most effectively use it. > > > > > > > > And "alternates" is still a mystery... > > > > > > It is used if you have any alternate or old email addresses. > > > `alternates` makes it possible for Mutt to mark messages in the index > > > with "F" (from one of your addresses), "+" or "T" (to one of your > > > addresses), etc. For example, > > > > > >alternates job_em...@example.net > > >alternates old_em...@example.com > > >alternates another_...@example.org > > > > > > Now Mutt knows that all these addresses belong to you. > > > > A small correction (even though the above example will work). The > > parameter after `alternates` is a regexp, so a more correct way to write > > them would be > > > >alternates ^job_email@example\.net$ > >alternates ^old_email@example\.com$ > >alternates ^another_old@example\.org$ > > > > to avoid false positives with for example "yet_another_...@example.org". > > So is this mostly to provide labeling information in the index? I suppose it > might be usable for some sort of filtering purposes... > > -- > Wishing you only the best, > > boB Stepp Alternates is also relevant for the reverse_name setting: reverse_name Type: boolean Default: no It may sometimes arrive that you receive mail to a certain machine, move the messages to another machine, and reply to some the messages from there. If this variable is set, the default From: line of the reply messages is built using the address where you received the messages you are replying to if that address matches your “alternates”. If the variable is unset, or the address that would be used doesn't match your “alternates”, the From: line will use your address on the current machine. Also see the “alternates” command. Very handy when you have hundreds of email addresses. cheers, raf
Re: Mutt stops showing mail contents
On Fri, Dec 18, 2020 at 11:16:23AM +0100, Josef Wolf wrote: > Hello, > > I am using mutt for about twwenty years now and am happy so far. > > Usually, I start mutt in a screen session and let it run for a long time, > until I need to reboot the system. This way, I can ssh to my mail host from > everywhere and resume the screen session with the running mutt at any time. > > But last week, mutt started to mis-behave. > > Mutt starts up as always and works as expected. But after some time, it stops > to show mail contents. It still shows the sidebar with all existing folders > and the list of messages in the current folder. But no message bodies or > attachments are shown at all. > > Mutt stops not only to show the contents, but also when replying to a mail > with quote, I end up in an emacs with nothing but the header. So mutt forgets > all the mail contents except the header. > > Changing to a different mail or even to a different folder don't help. The > only way is to quit mutt and start again. Then it works again for several > hours or even days, just to eventually stop showing mail contents again. > > This is mutt-1.10.1 on opensuse-leap-15.1 > > Any help to track this down? > > Might this be a problem with the size of my inbox (currently 2.9gB)? > > -- > Josef Wolf > j...@raven.inka.de You might want to check /var/log/kern.log for I/O errors.
Re: Is it possible to change/add headers to incoming mail?
On Tue, Dec 08, 2020 at 09:34:48PM +, Chris Green wrote: > Are there any mutt hooks which act on incoming mail? > > So I could (for example) add a header to incoming mail which matches > certain criteria. > > -- > Chris Green for mail on an imap server, imapfilter could do it. you'd need to script it in lua. for mail delivered locally, procmail could do it. procmail could detect the need to add the header and then run it through a separate bespoke filter process to add it. cheers, raf
Re: Best way to move large Maildir to another machine?
On Wed, Nov 25, 2020 at 10:30:54PM +, Dave Woodfall wrote: > Hello all, > > I have a Maildir folder which I want to move to another machine: > about 830M with 29000 messages. > > Would just rsync'ing or scp'ing be OK? > > I'm asking because I noticed that either procmail or getmail puts the > hostname in the file names, and I wondered if this would cause > problems at the other end or not when I've setup getmail+procmail on > it? > > Renaming all the files is possible I guess, but would be a task. Although you don't need to rename these files, if you did (or if you wanted to), it isn't difficult. See my "mved" program which lets you rename multiple files/directories easily and safely: http://raf.org/mved https://github.com/raforg/mved Either of these commands would replace the hostname in all files in the current directory: mved '*oldhostname*' =newhostname= mved =oldhostname= =newhostname= The '=' is like '*' but you don't have to quote it from the shell. There are other programs that rename multiple files but they aren't generic enough, or they require the user to know Perl. cheers, raf
Re: Sending all mail in IMAP folder from command line
On Sat, Nov 21, 2020 at 04:10:24PM +1100, Cameron Simpson wrote: > On 21Nov2020 13:07, raf wrote: > >On Sat, Nov 21, 2020 at 10:32:03AM +1100, Cameron Simpson > >wrote: > >> New ticket for amending the manual entry here: > >> https://gitlab.com/muttmua/mutt/-/issues/302 > >> Comments on wording/clarity welcome. > > > >In general, I usually think saying "ignored" is > >ambiguous. Does it mean included but not interpreted as > >you might expect? Or does it mean skipped? i.e. > >deleted? > > I'll change "ignored" to "discarded", since that's what happens. The > parse code reads and assembles a header structure and ignored From_ > lines (ergo, they don't get into that header structure). > > >That code exerpt from parse.c seems to do something > >with the From_ header (setting hdr->received to > >something), so is it really being ignored? > > That's a different branch in the same loop, which ignores ">From ", > which I assume is a workaround for an even more garbled header. Basicly, > this code accepts a file which _looks_ like RFC822 headers and body, and > works around cruft which has historically leaked in (eg "From " and even > ">From "). > > >Note that I haven't read any other part of parse.c, > >just that exerpt, so I don't know what I'm talking about. > > I should have linked off to the code itself, here: > > https://gitlab.com/muttmua/mutt/-/blob/master/parse.c#L1593 > > >And I think the sentence is a bit back to front for > >comprehension purposes. Perhaps I'm being silly, but I > >think it should start by stating what the format is, > >and then go on to say that's it's flexible about it. > > > >How about something like this: > > > > The draft file is expected to contain just the email. > > It is not an mbox file. However, if an mbox From_ header > > is present, it will be accepted. > > Hmm. Pretty wordy. But not bad. How about: > >The draft file is expected to contain just an RFC822 email: >headers and a body. Although it is not an mbox file, if an mbox "From >" pseudo-header is present, it will be silently discarded. > > and I'll put a link to RFC822 and RFC5322 in the SEE ALSO section. > > Cheers, > Cameron Simpson that looks good. cheers, raf
Re: Sending all mail in IMAP folder from command line
On Sat, Nov 21, 2020 at 10:32:03AM +1100, Cameron Simpson wrote: > On 19Nov2020 14:14, raf wrote: > >Just a thought: if it needs to have a From_ mbox > >message header (or if it needs to not have that), it > >might be worth mentioning. Even if the mbox message > >header is optional, it might be worth mentioning that > >it's optional. And I think there are several variations > >on the mbox file format (maybe 5?). Which ones, if any, > >are supported? Nothing's ever obvious or trivial, > >especially when it comes to email. :-) > > New ticket for amending the manual entry here: > > https://gitlab.com/muttmua/mutt/-/issues/302 > > Comments on wording/clarity welcome. > > Cheers, > Cameron Simpson In general, I usually think saying "ignored" is ambiguous. Does it mean included but not interpreted as you might expect? Or does it mean skipped? i.e. deleted? That code exerpt from parse.c seems to do something with the From_ header (setting hdr->received to something), so is it really being ignored? Note that I haven't read any other part of parse.c, just that exerpt, so I don't know what I'm talking about. And I think the sentence is a bit back to front for comprehension purposes. Perhaps I'm being silly, but I think it should start by stating what the format is, and then go on to say that's it's flexible about it. How about something like this: The draft file is expected to contain just the email. It is not an mbox file. However, if an mbox From_ header is present, it will be accepted. cheers, raf
Re: Sending all mail in IMAP folder from command line
On Thu, Nov 19, 2020 at 10:40:43AM +1100, Cameron Simpson wrote: > On 18Nov2020 12:08, Olli Savolainen wrote: > >> You could for this: > >> - save all the messages to a local filesystem maildir folder > >> - write a short shell loop to run mutt -H for each message file in the > >> maildir > > > >Thanks! This is what I was looking for. Couldn’t find any documentation > >on what the file format is but now I know. I suppose this could be > >mentioned on the man page. > > The man page says: > >‐H draft Specify a draft file which contains header and body > to use to send a message. > > Aside from saying that the message includes headers, what else would you > like it to have said? To me that says "a full message with headers". I'm > not sure what else would be useful to know. > > Cheers, > Cameron Simpson Just a thought: if it needs to have a From_ mbox message header (or if it needs to not have that), it might be worth mentioning. Even if the mbox message header is optional, it might be worth mentioning that it's optional. And I think there are several variations on the mbox file format (maybe 5?). Which ones, if any, are supported? Nothing's ever obvious or trivial, especially when it comes to email. :-) cheers, raf
Re: Sending all mail in IMAP folder from command line
On Mon, Nov 16, 2020 at 08:19:21AM +1100, Cameron Simpson wrote: > On 15Nov2020 09:56, Olli Savolainen wrote: > >I have draft messages appearing in an imap folder. I would like to > >write a script that reads a message (or all messages) from that folder > >and sends it as it is, then moving the message to imap Sent folder. > > > >It seems something like mutt -H would do the job, just can’t figure > >out how to get it to read the message from the imap Drafts folder > >instead of a file. > > > >Also not sure what is the file format mutt -H expects if I were to > >read the imap folder messages into a file first? > > > >(If mutt doesn’t work for this I would also welcome help in the form of > >strategic pointers. Also say, a php, python or powershell solution > >would be ok - if you know this particular task would be easy in some > >another ecosystem, tips are welcome. This seems like such a simple task > >to automate that I’m mainly trying to minimize amount of code I’ll need > >to maintain.) > > Is this once off or to happen regularly? > > You could for this: > - save all the messages to a local filesystem maildir folder > - write a short shell loop to run mutt -H for each message file in the > maildir > > Cheers, > Cameron Simpson Another option, especially if you need to do this a lot, is to use imapfilter if you know (or want to learn) lua (https://github.com/lefcha/imapfilter). cheers, raf
Re: Always CC specific messages to some people (send-hook and my_hdr)
so rightly pointed out, automatically cc-ing can lead to unintended emails being sent. Especially when you have configured mutt to automatically set your From: address for one email, and it just stays that way by default for the next email. And even more especially when addresses can be added by a postprocessor after the editor. So, I strongly recommend, that if you use an approach like this, that after you have completed editing your email, and leave the editor, you go back into the editor (with the 'e' keystroke), to check the email again before sending it (with the 'y' keystroke). However, if you only need to auto-cc based on the To: header (and not the From: header), this probably isn't a concern, and you probably don't have to be so careful. But you'll need to assess the risks yourself. Also note that mutt will coalesce multiple Cc: headers into a single one after editing, so you don't need to worry about creating multiple Cc: headers. I hope that helps. If you think this approach will do what you need, but you'd like help modifying the perl to match your exact needs, let me know and I'll modify it for you. I'm assuming that your environment is UNIXy enough for all this to be possible. That might not be the case. cheers, raf
Re: is it possible to have two options for viewing html mail?
On Sun, Oct 25, 2020 at 11:38:01PM +, Globe Trotter via Mutt-users
wrote:
> On Sunday, October 25, 2020, 5:53:20 PM CDT, raf wrote:
>
> On Sun, Oct 25, 2020 at 12:18:26AM +, Globe Trotter via Mutt-users
> wrote:
>
> > On Saturday, 24 October at 22:54, Mutt Users wrote:
> >
> > >> Lots of people send me mail in HTML format (even though I do not
> > >> like it). I have the following set up in my .mailcap:
> > >> text/html; w3m -I %{charset} -T text/html; copiousoutput
> > >> so it converts things using w3m more or less okay, however, I
> > >> am wondering is it possible to have an option for viewing using
> > >> midori/firefox for the cases where w3m is not enough?
> >
> > > I've got this in my mailcap:
> >
> > > text/html; w3m -I %{charset} -T text/html -dump; copiousoutput; print =
> > > qutebrowser %s; nametemplate=%s.html
> >
> > > To open an email in w3m press Enter, in qutebrowser p or whatever
> > > print is bound to. You can adapt this for firefox.
> >
> > > Hope that helps.
> > > Regards Wim
> >
> > This solution does exactly what I want. I wanted to use midori, so I
> > replaced qutebrowser with midori and it works.
> >
> > Is it possible to have multiple options? So, in case midori did not
> > cut it, I would use firefox instead?
> >
> > TIA!
>
> Rather than invoking actual browsers directly, you
> could write a script that presented you with a list of
> options, and you enter your choice. That way, you could
> have more that two options. If always having to select
> a browser manually is too inefficient, you could
> continue to invoke w3m when viewing html, and invoke
> this menu-based browser chooser when "printing" html.
>
> cheers,
> raf
>
> Thanks, where would this option be presented? While I press "p"?
I think that would be best, so that you can decide
whether or not you want to manually select a browser.
By only invoking this script for "printing" the
attachment, you can still access the easier default
behaviour when viewing the attachment. But it probably
means you can't print the attachment, unless you add
that as one of the choices.
> Is the script in mutt or a bash/python/perl/etc script?
It would be a separate script referred to in your .mailcap
file. Here's a sample implementation:
In your ~/.mailcap (or whatever your mailcap_path is set to):
text/html; w3m -I %{charset} -T text/html -dump; copiousoutput; print =
select-browser %s; nametemplate=%s.html
Attached is the command select-browser which would need
to be in your $PATH. Note that it doesn't support all
of the % expansions that mailcap(5) supports. It only
handles the %s filename place holder, but that's
probably fine for web browsers. Adding support for all
the others would make its appearance in the mailcap
file a lot uglier.
cheers,
raf
#!/usr/bin/env perl
use warnings;
use strict;
# select-browser - Let user select a browser manually (via ~/.mailcap entry)
# The order in which browsers are presented to the user
my @order = qw(w3m qutebrowser firefox);
# Browser labels and commands
# Warning: Commands must contain the %s filename place holder.
# Warning: No other mailcap(5) expansions are supported.
# Warning: Doesn't handle filenames containing double quotes.
my %browsers = (
w3m => 'w3m -T text/html -dump "%s"',
qutebrowser => 'qutebrowser "%s"',
firefox => 'firefox "%s"'
);
# Check command line
die "usage: $0 filename.html\n" unless @ARGV;
my $filename = $ARGV[0];
# Prompt the user
$| = 1;
print("Browsers:\n");
printf(" %s: %s\n", $_ + 1, $order[$_]) for (0..$#order);
print("Enter selection: ");
chomp(my $response = );
die("$0: Invalid selection: $response (Must be between 1 and @{[scalar
@order]})\n")
unless $response =~ /^\d+$/ && $response >= 1 && $response <= @order;
# Execute the selected browser
exec sprintf $browsers{$order[$response - 1]}, $filename;
# vi:set ts=4 sw=4:
Re: is it possible to have two options for viewing html mail?
On Sun, Oct 25, 2020 at 12:18:26AM +, Globe Trotter via Mutt-users
wrote:
> On Saturday, 24 October at 22:54, Mutt Users wrote:
>
> >> Lots of people send me mail in HTML format (even though I do not like it).
> >> I have the following set up in my .mailcap:
> >> text/html; w3m -I %{charset} -T text/html; copiousoutput
> >> so it converts things using w3m more or less okay, however, I am wondering
> >> is it possible to have an option for viewing using midori/firefox for the
> >> cases where w3m is not enough?
>
>
> > I've got this in my mailcap:
>
>
> > text/html; w3m -I %{charset} -T text/html -dump; copiousoutput; print =
> > qutebrowser %s; nametemplate=%s.html
>
> > To open an email in w3m press Enter, in qutebrowser p or whatever print is
> > bound to. You can adapt this for firefox.
>
> > Hope that helps.
> > Regards Wim
>
> --
> |\ _,,,---,,_
> ZZZzz /,`.-'`' -. ;-;;,_
> |,4- ) )-,_. ,\ ( `'-'
>
> '---''(_/--' `-'\_)
>
>
> This solution does exactly what I want. I wanted to use midori, so I replaced
> qutebrowser with midori and it works.
>
> Is it possible to have multiple options? So, in case midori did not cut it, I
> would use firefox instead?
>
> TIA!
Rather than invoking actual browsers directly, you
could write a script that presented you with a list of
options, and you enter your choice. That way, you could
have more that two options. If always having to select
a browser manually is too inefficient, you could
continue to invoke w3m when viewing html, and invoke
this menu-based browser chooser when "printing" html.
cheers,
raf
Re: Can mutt be persuaded to use a sensible maildir hierarchy?
On Wed, Sep 30, 2020 at 11:38:06AM +1000, Cameron Simpson
wrote:
> On 29Sep2020 08:13, 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.
>
> Nice. That is very compact.
>
> I dropped procmail years ago too, and my filer rules for eg the mutt
> lists look like this:
>
> muttMutt-Devsender:owner-mutt-...@mutt.org
> muttMutt-Devsender:mutt-dev-boun...@mutt.org
> muttMutt-Users mutt-users@mutt.org
> muttMutt-Users mutt-users@mutt.org@korn.aiss.de
> muttMutt-Users mutt-us...@gbnet.net
> muttMutt-Users sender:owner-mutt-us...@mutt.org
> muttoffline-imapofflineimap-proj...@lists.alioth.debian.org
> muttoffline-imapofflineimap-proj...@alioth-lists.debian.net
> muttoffline-imap
> sender:offlineimap-project-bounces+cs=cskk.id...@lists.alioth.debian.org
>
> Column 1 is the mail folder name. Column 2 is for the X-Label ('.' to
> not apply one). Column 3 is the rule. Absent a header name it matches
> the to/cc/bcc on the "address" part (the bit between the <> after a
> parse).
>
> Cheers,
> Cameron Simpson
I didn't drop procmail. I wrote a program to
generate procmail code from a set of prettier
config files. :-)
cheers,
raf
Re: support for Office365?
On Sun, Sep 27, 2020 at 12:05:36PM +0100, ed neville wrote: > On 2020-06-26 14:20-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. > > > > So, I'll follow up with using that intermediary if need be, but would > > love to hear that mutt could talk directly to Office365 without using > > IMAP. > > 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? > > -- > Best regards, > Ed http://www.s5h.net/ One reason is MFA. Where I work, we are often receiving emails from the hacked email accounts of our clients. cheers, raf
Re: Can mutt be persuaded to use a sensible maildir hierarchy?
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: > > Does mutt still use the (IMHO silly) maildir hierarchy where mail > > 'folders' are simply represented by another '.' and name in the > > maildir directory name? > > > > Is there some way I can get to use real directories to represent my > > hierarchy of mail? 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. > > > > 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. > > -- > Chris Green 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. 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. An alternative, if the only problem is renaming folders, is to write a shell script or something that renames maildir folders. That would be a lot less effort. But I really don't know what I'm talking about. I use mbox. Perhaps you can rename/move folders in a mail client and then you don't need to look at the guts underneath. That would be the easiest way. I know that GUI IMAP clients can do that. Can mutt do that? I found this: https://unix.stackexchange.com/questions/44508/mutt-rename-imap-folder cheers, raf
Re: plain-text email and kernel development
On Tue, Sep 15, 2020 at 08:30:49AM +0200, Francesco Ariis wrote: > Hello mutters, > I have just finished reading this article on The Register: «Relying > on plain-text email is a 'barrier to entry' for kernel development, says > Linux Foundation board member». [1] > > Of course this opinion is not shocking, given that the «Linux Foundation > board member» in question is a Microsoft attaché. > The comment section was definitely not supportive of the idea. > > I post it here as we had our fair share of discussion on plain text vs. rich > text too and I consider the debate not tangential to what mutt is; so it > is interesting to see opinions of the broader open-source community > —F > > [1] https://www.theregister.com/2020/08/25/linux_kernel_email/ i'd be surprised if someone who is technically competent enough to patch the Linux kernel would have much difficulty sending plain text emails. but what do i know? :-) cheers, raf
Re: Is there a hook for modifying a To: field?
On Tue, Aug 25, 2020 at 01:05:39PM +0100, Chris Green wrote: > On Tue, Aug 25, 2020 at 09:15:55AM +1000, raf wrote: > > On Mon, Aug 24, 2020 at 10:32:56AM +0100, Chris Green wrote: > > > > > I am on a mailing list which has two addresses, occasionally when one > > > does L[ist reply] the To: address is:- > > > > > > ix...@ixiemaster.ixion.org.uk, Ixilist > > > > > > At present I normally notice this and remove one of the addresses but > > > it would be nice if I could automate this. Is there a hook (send_hook > > > maybe) that can be used to change this? It can't just change every > > > case of either ix...@ixiemaster.ixion.org.uk or ix...@ixion.org.uk as > > > most of the time a L[ist reply] only gets a single address. > > > > > > -- > > > Chris Green > > > > It seems odd that a mailing list would have two > > addresses. Presumably the are interchangeable. If so, > > perhaps you could use procmail or imapfilter to replace > > all instances of one of the addresses with the other as > > the email arrives. That way, when you read it, mutt > > only sees one of the addresses. > > > It's the only list I'm on that's like this. I have a custom filter > program handling incoming mail so I *could* add a special rule but it > would have to step outside the normal logic of the filter. > > If I replace all occurrences of one address with the other won't mutt > then simply send a L[ist reply] to the same address twice? ... or does > mutt have internal logic such that it won't send mail to duplicated > addresses? > > -- > Chris Green You could apply the transformation to one email manually, and test that. cheers, raf
Re: Is there a hook for modifying a To: field?
On Mon, Aug 24, 2020 at 10:32:56AM +0100, Chris Green wrote: > I am on a mailing list which has two addresses, occasionally when one > does L[ist reply] the To: address is:- > > ix...@ixiemaster.ixion.org.uk, Ixilist > > At present I normally notice this and remove one of the addresses but > it would be nice if I could automate this. Is there a hook (send_hook > maybe) that can be used to change this? It can't just change every > case of either ix...@ixiemaster.ixion.org.uk or ix...@ixion.org.uk as > most of the time a L[ist reply] only gets a single address. > > -- > Chris Green It seems odd that a mailing list would have two addresses. Presumably the are interchangeable. If so, perhaps you could use procmail or imapfilter to replace all instances of one of the addresses with the other as the email arrives. That way, when you read it, mutt only sees one of the addresses. cheers, raf
Re: Inconvenient Signature Requirements
Kevin Monceaux wrote: > Mutt Fans, > > 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? Sadly, I suspect I > already know the answer. > > -- > > Kevin > http://www.RawFedDogs.net > http://www.Lassie.xyz > http://www.WacoAgilityGroup.org > Bruceville, TX > > What's the definition of a legacy system? One that works! > Errare humanum est, ignoscere caninum. Hi Kevin, I assume that the signature and sig_dashes .muttrc variables only work with plain text signatures. I suspect that you could arrange this by having the signature as an html file, defining a macro to attach it (with inline disposition), and then either using the macro keystroke manually when appropriate, or creating a send-hook to "push" the macro keystroke into the keyboard buffer (but this will probably only work if you can set up a pattern in the send-hook for all recipient domains that would require the signature). Good luck. cheers, raf
Re: Elimination of mime/html part
Angel M Alganza wrote: > Hello: > > I keep a few mailbox folders containing a large amount of multipart mail > with a text/plain part and a text/html part, which I would like to > eliminate in order to reduce the amount of disk space used (for a small > device and mainly the IMAP server I keep synced with). > > I've been looking for ways to remove the text/html part with tools like > imapfilter or mbsync/isync that I use to manipulat, sort and > syncronised, but I haven't had any succeed. I can eliminate it by hand > with Mutt, but that'd be really tedious, since I have thousands of mail. > > 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? > > Thank you very much in advance for your help. > > Regards, > Ángel Hi Ángel, I wrote a tool for replacing non-text attachments in email with text versions. It's at http://raf.org/textmail. By default, it replaces HTML attachments with inline plain text attachments that contain just the text within the original document. It also reduces text-versus-html alternative attachments to just the text part. It needs lynx to be installed. If that's the only transformation you want, you'll need to supply lots of options to prevent other default actions. Something like this: textmail -MWERPULIAVXBS That suppresses translating and deleting anything else, just HTML. You can use it in a procmail recipe or apply it to mbox files. WARNING: Please verify it carefully and make sure it's doing what you want before deleting the original mailboxes. Anything that transforms your email should not be trusted until you have reason to trust it. cheers, raf
Re: Going GUI...er
Derek Martin wrote: > Me personally, I just want the ability to render italics, to represent > emphasis. And to be able to read what my boss sent me... whatever it > might be. Yes, I love mutt for its programmability but when you need to see something your boss sent you, I think the best/easiest way is to bounce or save the entire message and display it via an external GUI MUA, rather than saving the html and possibly other attachments and viewing it via an external web browser. But if I had to do it 50 times a day, or reply to those emails with full formatting, the GUI MUA would have to win. Luckily for me, that's not the case. cheers, raf
Re: Going GUI...er
Mark H. Wood wrote: > If I were condemned to use only one of those gooey-fied MUAs, I would > be working on a plugin to configure-off all of the formatting, gather > the attachments into a menu to be viewed or ignored as I choose, pop > up an "are you sure?" dialog before following links, and generally > make it more like Mutt. There is a brilliant "are you sure?" addon for Thunderbird. It's called Torpedo by secuso.org. Not only does it make you wait 3 seconds and confirm before following any link to a domain that you haven't already gone to a few times before, it shows the URL in a way that makes it clear where you're going (e.g. https://paypal.com.evil.com/blah would show evil.com in bold), and if the URL is something like a tinyurl, it'll fetch the real URL and display that instead. It's a fantastic solution to phishing that all GUI MUAs should be doing by default but aren't. cheers, raf
Re: Going GUI...er
Akkana Peck wrote: > Felix Finch writes: > > On 20200405, Sam Kuper wrote: > > > 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." > > > > Now that's an idea I hadn't considered! I was thinking more about > > the calendar program keeping tabs on who had accepted or not. But > > you're right, no need to emulate that. Just reply to the human. That's what I've always done. Nobody has complained yet but I don't get invited to many meetings. > Aside from the question of how to reply to calendar invites, my > problem is seeing them in the first place. I don't get calendar > attachments often, but when I do, I never know they're there. > This happens for two reasons: > [...] > > 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. > > ...Akkana I think you're looking for these [but I'm wrong, see below]: auto_view type[/subtype] [ ... ] unauto_view type[/subtype] [ ... ] This commands permits you to specify that mutt should automatically convert the given MIME types to text/plain when displaying messages. For this to work, there must be a mailcap(5) entry for the given MIME type with the copiousoutput flag set. A subtype of “*” matches any subtype, as does an empty sub‐ type. implicit_autoview Type: boolean Default: no If set to “yes”, mutt will look for a mailcap entry with the “copiousoutput” flag set for every MIME attachment it doesn't have an internal viewer defined for. If such an entry is found, mutt will use the viewer defined in that entry to convert the body part to text form. MIME attachments with 'text' types, with the only exception of text/html, are excluded: they will be shown as they are unless auto_view is specified. I didn't know about implicit_autoview but I have the same problem as you. I just never thought to find a solution. Thanks for asking! I've always had this in my .muttrc: auto_view text/calendar with the appropriate entry in my .mutt.mailcap file: text/calendar; $HOME/bin/mutt.vcalendar.filter; copiousoutput But I didn't know about implicit_autoview so it would only work if I thought to look for attachments. I've just added this to my .muttrc: set implicit_autoview = yes Hmm. It didn't work. I assumed that it would automatically view the attachments with copiousoutput mailcap entries. It doesn't. It seems that implicit_autoview is just an alternative to using the auto_view option and having to list every mimetype. Sorry this didn't help. It seems that "view" here actually means translate into something viewable upon request. It doesn't mean automatically render attachments for which there is such a translation. Such an option would be great. Actually, I've just thought of a non-ideal solution but it'll take some work. If I add support for translating text/calendar to my textmail program, then procmail could be used to process incoming emails just to translate those attachments into text/plain and then mutt would render them automatically because it would see them as text/plain attachments. It implies a dependency on procmail or similar so it might not be suitable in all cases but it would work for me. I don't know how it would work for IMAP accounts. And it would replace the original attachment with its text/plain version which might not always be what you want. A mutt option to automatically render attachments that are automatically translatable to text would be ideal. Perhaps it could be called something like auto_translate / implicit_autotranslate or auto_render / implicit_autorender. cheers, raf
Re: Going GUI...er
Vegard Svanberg wrote: > Hi, > > I love Mutt. > > However, 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. > > My Holy Grail, which would be a native Mutt GUI client, I guess, doesn't > seem to exist. > > I don't know how I would survive with a regular GUI client like > Thunderbird or Evolution. I've tried, but they all suck. Mutt's > keybindings, search and navigation features are irreplaceable. > > Currently I'm running Mutt from a machine which I ssh into from 5 other > computers I use frequently (IMAP backend - self-hosted). > > Suggestions? What does everyone else do? > > -- > Vegard Svanberg [*Takapa@IRC (EFnet)] I use mutt over ssh to read mail on a virtual machine out there somewhere that is also my mail server, so I can't really "display" anything therei (X11 not installed). For most HTML emails, lynx is enough: .mutt.mailcap: text/html; lynx -dump %s; copiousoutput; description=HTML Message; nametemplate=%s.html But when it's not, I have a macro that bounces the email to a local IMAP account: .muttrc: macro index BR bbounce.raf@virt.raf.org\ny and it's fetched by Thunderbird on my laptop. Once read, I delete it in Thunderbird. I concluded that that was the easiest thing to do in my environment and it means that hardly any emails make it to my actual laptop, only the ones I choose to allow there, and they're always work-related ones that I've already seen and know to be legitimate. 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. The vcalendar-filter is very useful for me these days. 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. :-) cheers, raf
Re: conditional automatic cc header?
Kevin J. McCarthy wrote: > On Thu, Apr 02, 2020 at 12:01:38PM +1100, raf wrote: > > Jens John wrote: > > > > > On Wed, 1 Apr 2020, at 06:22, raf wrote: > > > > e.g. Add a CC header to f...@work.com whenever > > > > sending/replying/forwarding from m...@work.com unless the email is > > > > already going to f...@work.com. > > > > > > I think a combination of hooks or only a send2-hook could be used. > > > > > > How about something along these lines (not tested): > > > > > > send2-hook "~f m...@work.com !(~C f...@work.com)" "my_hdr cc: > > > f...@work.com" > > > > thanks. that looks really promising but i can't get it to have any > > effect. i tried reply-hook and send-hook as well but it never triggers. > > i have other (simple) send-hooks that work fine. > > Mutt's send-hook and reply-hook are useful for making configuration and > from-header changes based on recipients. They aren't designed for the > reverse, because they trigger after recipients have been determined. > > The link you posted (albeit at the wrong website) ;-), > <http://www.mutt.org/doc/manual/#compose-flow>, is a good place to look for > the details. > > In bullet 2, my_hdr is processed to add to the initial Cc recipients. Bullet > 3 then prompts using those recipients. All the hook processing occurs > afterwards, so a hook adding Cc my_hdr won't affect the *current* > composition session. > > Unfortunately, that means you have to get creative to do what you want to > do. The perl script you wrote sounds like a good idea. Another idea might > be to set the my_hdr in advance via a folder hook, or via a macro that also > changes the $from setting. > > -- > Kevin J. McCarthy > GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA Hi Kevin, Thanks for the explanation. It's much appreciated. I think I'll stick with the perl script since it's already working. And thanks for all your effort on mutt. It truly does suck less. cheers, raf
Re: conditional automatic cc header?
Cameron Simpson wrote: > On 01Apr2020 12:34, Jens John wrote: > > Apologies for answering a solved thread; I received raf's followup only > > after reconnecting to the server when sending my reply. > > A different (and, better, "in mutt") solution is always welcome. The OP > might adopt it and anyway the rest of us can learn from it. > > Cheers, > Cameron Simpson indeed. it looks like a great solution. hopefully, i can work out why it isn't being triggered for me, and get it working. cheers, raf
Re: conditional automatic cc header?
Jens John wrote: > On Wed, 1 Apr 2020, at 06:22, raf wrote: > > e.g. Add a CC header to f...@work.com whenever > > sending/replying/forwarding from m...@work.com unless the > > email is already going to f...@work.com. > > I think a combination of hooks or only a send2-hook could be used. > > How about something along these lines (not tested): > > send2-hook "~f m...@work.com !(~C f...@work.com)" "my_hdr cc: f...@work.com" thanks. that looks really promising but i can't get it to have any effect. i tried reply-hook and send-hook as well but it never triggers. i have other (simple) send-hooks that work fine. i see a lot of documentation online that says send-hooks match on recipients which might be a reason but man muttrc itself doesn't say that. any pattern that only uses header data should work. and anyway, even tests using ~t didn't work. i must be doing something very dumb. but if i could get it to work, send2-hook looks good. i didn't know about that. according to: https://neomutt.org/guide/advancedusage.html#compose-flow send2-hook happens after editing but it also says that send2-hook is evaluated each time the headers are changed (assuming mutt and neomutt are similar in that regard), so the Cc header might not be there in the editor session but it should at least be added after editing. but i didn't observe that behaviour either. but if it worked, it would handle the case where i have to manually edit the from address in the editor. > I do not know if my_hdr would respect headers that are already > there. For example, if you set a header using the editor CCing a few > people, Fred should only be added. i thought that my_hdr might replace any existing header (for From: it does) but i tested my_hdr Cc: (without the send2-hook) and, if there is already a Cc header, it adds the header content to what is already there. it doesn't replace it or even add a new Cc header. clever little mutt. cheers, raf
Re: conditional automatic cc header?
raf wrote: > What's a good way to automatically add a Cc: header > for a particular address when sending/replying/forwarding? > But not if they're already going to receive the email. > And only when sending from a particular address. > > e.g. Add a CC header to f...@work.com whenever > sending/replying/forwarding from m...@work.com unless the > email is already going to f...@work.com. > > Can it be done in .muttrc or should I automate it in > the editor? I already have mutt's editor variable set > to a script that uses perl to preprocess the file > slightly before starting vim so I could just add to > that but I was wondering if there's another way. I've done it as a perl script that reads the email and adds the Cc: header if necessary. It's run before and after invoking vim in the editor script that is invoked by mutt. I realised that, sometimes, my main email address is in the From: header when the editor starts, not my work email. Sometimes I have to change it manually in the editor, so the preprocessor needs to run after editing as well as before. cheers, raf
conditional automatic cc header?
Hi, What's a good way to automatically add a Cc: header for a particular address when sending/replying/forwarding? But not if they're already going to receive the email. And only when sending from a particular address. e.g. Add a CC header to f...@work.com whenever sending/replying/forwarding from m...@work.com unless the email is already going to f...@work.com. Can it be done in .muttrc or should I automate it in the editor? I already have mutt's editor variable set to a script that uses perl to preprocess the file slightly before starting vim so I could just add to that but I was wondering if there's another way. cheers, raf
Re: Rendering HTML as Markdown in mutt (was: Creating HTML emails with mutt)
Derek Martin wrote: > Hardly anyone uses xterm these days though AFAICT, and configuring it > properly has become a lost art. In fact, quite a few years ago now, I > filed a bug against xterm in some version of Fedora or even Red Hat, > and Red Hat's support people closed the ticket, complaining that xterm > was obsolete and no longer supported. (!!!) i use it all the time. i don't mind if it never changes again but i'd be annoyed if it ever disappeared. cheers, raf
Re: Creating HTML emails with mutt
Derek Martin wrote: > TBH most of the time, if I really need to see what's in an HTML mail, > I just bounce it to gmail. But sometimes that doesn't work either due > to DNS-based spam prevention. Forwarding the email as an attachment rather than bouncing it should solve that. cheers, raf
autoviewing html gone wrong
hi,
i used to have this in my mutt mailcap file:
text/html; lynx -dump %s; copiousoutput
and it was good. it formatted the html and gave me a list of
referenced urls at the bottom.
for some reason i can't remember, i changed it to:
text/html; w3m -I %{charset} -T text/html -dump; copiousoutput;
which does the formatting but doesn't give a list of referenced urls
at the bottom so it's less useful.
if i change it back to using the lynx -dump command then i see the
raw html instead of the formatted html (as though i'd used lynx -source
rather than lynx -dump).
i suspect that must be why i changed it to use w3m in the past.
anyway, if i save the html attachment and run lynx -dump on it
then it shows me the formatting page with the list of referenced
urls like it used to but that isn't what happens when mutt invokes
the same command when autoviewing the attachment.
does anyone have any idea why this might be the case or what i can
do to make lynx work again for autoviewing html in mutt?
cheers,
raf
Re: Sending attachments to Outlook
Dave Dodge wrote: On Mon, Apr 08, 2013 at 10:49:53AM -0300, Leonardo M. Ramé wrote: Hi, this isn't a strictly mutt related question as it can be reproduced on every Linux email client sending attachments to new versions Outlook (from 2007+). When we send emails with attachmets to Outlook, the receiver sees the attachment as winmail.dat instead of what we've sent. If you mean that you attach the file and send it from Outlook, and then the Linux recipient views the message and sees a winmail.dat file, then that is a very well known problem with Outlook. Here's Microsoft's support page explaining how to fix Outlook: http://support.microsoft.com/kb/278061 also, if you are unable to get all outlook-using senders to change their outlook configuration (quite possible), then there are programs that can filter mail messages that contain winmail.dat attachments and convert them into normal messages with normal attachments. one such program is available at http://raf.org/textmail/ but there are probably better ones out there. textmail could be used in a procmail recipe like the one below to just translate winmail.dat attachments and nothing else: :0 fw ! textmail -WEHRPLIAVXBS If you instead mean that mail sent by Linux users show up with winmail.dat when viewed in Outlook, then that is bizarre. If this is happening, then all I can think is that there must be something on the Windows receiving end that is manipulating the messages and adding the winmail.dat; perhaps a filter or relay in an Exchange server. agreed. it's only outlook that creates winmail.dat attachments. even if something else is doing it, you'd think that outlook would be able to interpret the contents of a winmail.dat attachment and display them properly. -Dave Dodge/dodo...@dododge.net cheers, raf
Re: Is it supposed to be possible to deliver mail while mutt has the mbox open?
Chris Green wrote: On Wed, Mar 20, 2013 at 10:11:06AM -0500, David Champion wrote: * On 20 Mar 2013, Chris Green wrote: I suspect my MTA doesn't agree exactly with mutt about where the 'message separator' is. When your script delivers a message, does it append a message and then a blank line, or does it append a blank line and then a message? It appears to add a blank line and then the message. Has the mutt handling of this changed in the last few versions? The python way of doing this is correct according to the RFC as far as I can tell, there *should* be a blank line between the end of a message and the 'From ' starting the next message. Thus the python library I'm using does add this blank line. it is not correct. the blank line should be at the *end* of each message, not at the *start*. think about it. does an mbox file start with a blank line? no. it ends with a blank line. However mutt detects this as an error and outputs the messsage about the mailbox being modified. not an error, just a modification. presumably because there is an extra blank line, mutt sensibly concludes that the message that was previously the last message now has an extra blank line in it (i.e. the line that used to be a message separator but which is now a new last line of the message followed by the new message separator). If, on the other hand, I append a message to my mbox file by hand and I *don't* put a blank line in then mutt is quite happy. Thus mutt is quite happy with the following in an mbox:- because that is correct. the python code needs to be changed to write the From header, then the message, then the blank line. cheers, raf
Re: Alternative use for mutt...
Tom Hudak wrote: Just thought I'd share an alternative to how mutt is generally used, we recently converted over to a new imapd server, which uses mbox mail dirs, from cyrus which uses individual files for each message. In searching for a way to convert quickly and easily from cyrus's message format to mbox, we used mutt to simply connect via imap, save all messages locally, and move the mbox file to the new spool dir where everyone gets all their messages seamlessly. Just thought you would like to know. you might like to try fetchmail for this. it can run the background automatically fetching mail as it arrives. then again, you might not :) raf
Re: Mutt and BCC and Outlook/KMAIL
Jan- Hendrik Palic wrote: On Thu, Nov 23, 2000 at 02:04:30PM +1100, raf wrote: | I got a problem and I don't know, where the problem is. | | I sent yesterday a mail with several adresses in BCC- field. A friend, using | Outlook on Windows ME (I thing Outlook 5.5) is able to see the adresses, | which stand in BCC- fiel. An other friend can see them by using KMAIL on KDE | 2.0. | | My MTA is exim on potato, exim 3.12 and my mutt is a selfcompiled | mutt-1.2.5-4. Whats going wrong? | |shouldn't that be the "Bcc" field (i.e. without the "-")? Yes, youre right, but thats not the problem, why are they shown in several mua's...? What in my configuration is going wrong? sorry about that. i was being stupid. do the intended bcc recipients receive the mail? if not, then it's not being recognised as a header. maybe there's a blank line before it or the line endings are "wrong"? i'd suggest bcc'ing a message to yourself. if you receive the message, save it to a file and examine the file using od or xxd or something to look for anything wierd. what editor do you use to compose the messages? do you have edit_hdrs set in your .muttrc? mutt wouldn't even be sending the bcc header to exim if it recognised it as a bcc header. sendmail does have an option to read the headers in a message given to it, work out the recipients from the headers and then send everything except the bcc header but mutt doesn't rely on that because sendmail isn't the only mta so exim can't be the problem. raf
