Re: sending automated GPG signed mails from batch job

[Nicolas George]

googly.negotiator...@aceecat.org (12024-05-21):
> > The problem with any automation, anyway if with GnuPG or not, is how
> > to enter the passphrase or PIN to get access to the private key.
> Does the gpg-agent help with that? It is supposed to, I think.

Makes it worse. Without gpg-agent, your automation process needs to
manage the key or their pass phrases securely. With gpg-agent, your
automation process needs to manage the key their pass phrases securely
AND manage the lifetime of the agent.

Regards,

-- 
  Nicolas George

Re: sending automated GPG signed mails from batch job

[Nicolas George]

Matthias Apitz (12024-05-21):
> I do use GnuPG based on OpenPGP SIM cards even in my Linux telephone
> (Pusim L5) for crypting files, ~350 passwords (password-store) and SSH
> connections (the RSA secret is on the OpenPGP card). All works fine and
> gives access to the secrets by entering a 6 digit PIN:

For interactive basic use, GPG is fine.

> The problem with any automation, anyway if with GnuPG or not, is how to
> enter the passphrase or PIN to get access to the private key.

For automation, the key must be unencrypted during the operation. Or the
process must have the pass phrase available, which is equivalent.

The problem is the agent. GPG now insists to handle all private key
operations through an agent started automatically in the background. The
control over the behavior of the agent is very limited. For interactive
use it is fine, you just let your session manage it. But for automation
and tests, you need control.

Also, GPG has its system of trust. For interactive use it is still fine.
But for automation, we need to control which key we use without some
stupid software deciding we are not allowed because it is not trusted.

Agents and trust are high-level issues. Proper design requires low-level
tools that do their job and no more, “Keep It Simple Stupid” and
high-level tools on top of it. GPG does not have the low-level tools,
that makes it unsuitable for automation.

With sq, no such problem, the keys are in pairs of files, it uses the
ones you tell it to use.

Regards,

-- 
  Nicolas George

Re: sending automated GPG signed mails from batch job

[googly . negotiator862]

On Tue, May 21, 2024 at 05:57:00PM GMT, Matthias Apitz wrote:

> The problem with any automation, anyway if with GnuPG or not, is how
> to enter the passphrase or PIN to get access to the private key.

Does the gpg-agent help with that? It is supposed to, I think.

-- 
Ian

Re: sending automated GPG signed mails from batch job

[Matthias Apitz]

El día martes, mayo 21, 2024 a las 10:49:08a. m. +0200, Nicolas George escribió:

> Matthias Apitz (12024-05-21):
> > How could we expand this for signing mails on the fly?
> 
> Hi.
> 
> ...
> 
> - Ditch GPG. GPG has been increasingly incapable of deciding if it is a
>   high-level tool or a low-level tool and batch operation has become
>   increasingly hard or impossible. Instead, you can use Sequoia / sq, a
>   low-level tool suitable for automation.

I do use GnuPG based on OpenPGP SIM cards even in my Linux telephone
(Pusim L5) for crypting files, ~350 passwords (password-store) and SSH
connections (the RSA secret is on the OpenPGP card). All works fine and
gives access to the secrets by entering a 6 digit PIN:

 ┌──┐
 │ Please unlock the card   │
 │  │
 │ Number: 0005 A6FE│
 │ Holder: Matthias Apitz   │
 │  │
 │ PIN  │
 │  │
 │  │
 └──┘


The problem with any automation, anyway if with GnuPG or not, is how to
enter the passphrase or PIN to get access to the private key.

matthias

-- 
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

I am not at war with Russia.
Я не воюю с Россией.
Ich bin nicht im Krieg mit Russland.

Re: sending automated GPG signed mails from batch job

[Nicolas George]

Matthias Apitz (12024-05-21):
> How could we expand this for signing mails on the fly?

Hi.

For fine control, I would suggest:

- Build your mail entirely yourself without relying on a MUA like mutt
  and inject it directly into the MTA local injector /usr/lib/sendmail.

- Ditch GPG. GPG has been increasingly incapable of deciding if it is a
  high-level tool or a low-level tool and batch operation has become
  increasingly hard or impossible. Instead, you can use Sequoia / sq, a
  low-level tool suitable for automation.

Regards,

-- 
  Nicolas George

Re: sending automated GPG signed mails from batch job

[Jan Eden via Mutt-users]

Hi Matthias,

On 2024-05-21 07:45, Matthias Apitz wrote:

> Hello,
> 
> Our Library Management System sends mails to patrons and media vendors
> which are assembled in a shell script with all data (Subject, body, To,
> attachments, etc) by a call to the MUA mutt 2.1.1 which pipes the mail
> to sendmail:
> 
> #!/bin/sh
> #
> # $Id: sisis2mail.sh 381380 2020-11-06 07:49:50Z apitzm $
> #
> # filter mails ensuring mails sent are RFC compilant
> # the mutt program (installed by sisis-pap) assists in that
> # usage: sisis2mail.sh [ --cat [ file ]  |
> #--body-as-text  |
> #--body-as-html  |
> #--body-as-text-and-html |
> #--body-as-attachment|
> #--attach-file filename  |
> #--inline-images dirname ] [ file]
> #
> # input may be a file or stdin
> # output goes to stdout
> ...
> 
> How could we expand this for signing mails on the fly?
> 
> Kevin, I saw your reply in 
> http://lists.mutt.org/pipermail/mutt-users/Week-of-Mon-20210412/002737.html
> ...
> On Mon, Apr 12, 2021 at 09:50:59AM +0200, Tom wrote:
> >I am trying to use a GnuPG key without a passphrase to send *signed* 
> >mails from a cron job for some non-critical, internal reporting. 
> >Searching the archives did not give me the answer.
> 
> Sorry, cryptographic operations are disabled in batch mode.
> 
> I thought I had added a note to the manual about this, but I only see it 
> in the "batch composition flow" section (in git).  I'll add a note to 
> the "encryption and signing" section too.
> 
> -- 
> Kevin J. McCarthy
> 
> Is this still the case, that cryptographic operations are disabled in
> batch mode? I could not locate it in the man pages of mutt and muttrc.
> 
> What other options do we have outside of mutt on Linux?

This is what I do (in Python):

==
import os
import datetime
import __main__ as main
import smtplib
from email.message import Message
from email.mime.multipart import MIMEMultipart
from email import charset
from email.utils import make_msgid
import keyring
import gnupg
import socket

smtp_server = 'mail.example.com'
smtp_user = 'mailu...@example.com'
port = 587
localhost = 'my.local.host'
pgp_entry = 'PGP-NoReply'
pgp_user = pgp_entry

def send_message(subject, body):
now = datetime.datetime.now().strftime('%Y-%m-%d %H:%M:%S')
subject = f'{os.path.basename(main.__file__)}: {subject}'
body = f'{body}\n\n{now}'

base_charset = charset.Charset('utf-8')
base_charset.body_encoding = charset.QP
basemsg = Message()
basemsg.set_payload(body, charset=base_charset)

gpg = gnupg.GPG(gpgbinary='/opt/homebrew/bin/gpg')
basetext = basemsg.as_string().replace('\n', '\r\n')
pgp_passphrase = keyring.get_password(pgp_entry, pgp_user)
signature = str(gpg.sign(basetext, 
keyid='', passphrase=pgp_passphrase, 
detach=True))

signmsg = Message()
signmsg['Content-Type'] = 'application/pgp-signature; 
name="signature.asc"'
signmsg['Content-Description'] = 'OpenPGP digital signature'
signmsg.set_payload(signature)

msg = MIMEMultipart(_subtype="signed", micalg="pgp-sha512", 
protocol="application/pgp-signature")

msg.attach(basemsg)
msg.attach(signmsg)

msg['From'] = 'Script Status '
msg['To'] = 'Admin '
msg['Subject'] = subject
msg['Message-ID'] = make_msgid(domain=localhost)

smtp_password = keyring.get_password(smtp_server, smtp_user)
print('Sending email message... ', end='')
try:
s = smtplib.SMTP(host=smtp_server, local_hostname=localhost, 
port=port)
s.starttls()
s.login(smtp_user, smtp_password)
s.send_message(msg)
print('sent.')
except socket.gaierror:
print('failed (no internet connection).')
del msg
==

- Jan


signature.asc
Description: PGP signature

sending automated GPG signed mails from batch job

[Matthias Apitz]

Hello,

Our Library Management System sends mails to patrons and media vendors
which are assembled in a shell script with all data (Subject, body, To,
attachments, etc) by a call to the MUA mutt 2.1.1 which pipes the mail
to sendmail:

#!/bin/sh
#
# $Id: sisis2mail.sh 381380 2020-11-06 07:49:50Z apitzm $
#
# filter mails ensuring mails sent are RFC compilant
# the mutt program (installed by sisis-pap) assists in that
# usage: sisis2mail.sh [ --cat [ file ]  |
#--body-as-text  |
#--body-as-html  |
#--body-as-text-and-html |
#--body-as-attachment|
#--attach-file filename  |
#--inline-images dirname ] [ file]
#
# input may be a file or stdin
# output goes to stdout
...

How could we expand this for signing mails on the fly?

Kevin, I saw your reply in 
http://lists.mutt.org/pipermail/mutt-users/Week-of-Mon-20210412/002737.html
...
On Mon, Apr 12, 2021 at 09:50:59AM +0200, Tom wrote:
>I am trying to use a GnuPG key without a passphrase to send *signed* 
>mails from a cron job for some non-critical, internal reporting. 
>Searching the archives did not give me the answer.

Sorry, cryptographic operations are disabled in batch mode.

I thought I had added a note to the manual about this, but I only see it 
in the "batch composition flow" section (in git).  I'll add a note to 
the "encryption and signing" section too.

-- 
Kevin J. McCarthy

Is this still the case, that cryptographic operations are disabled in
batch mode? I could not locate it in the man pages of mutt and muttrc.

What other options do we have outside of mutt on Linux?

Thanks

matthias

-- 
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

"Gmail access expires periodically unless renewed by users"

[Greg Marks]

Dear Mutt Developers:

Will we experience difficulties using Mutt to obtain IMAP access to
G-Mail accounts, having configured the Mutt OAuth2 token management
script provided here:

   https://gitlab.com/muttmua/mutt/-/raw/master/contrib/mutt_oauth2.py

once Google changes their access policies governing their so-called
"apps" on June 3, 2024?  I have received a notification from Google
stating:

   You have indicated that your app has features related to "email
   reporting and monitoring," as defined in the Gmail user data
   and developer policy.  This is specified in the Google Cloud
   Platform Console under the Scopes section of the OAuth consent
   screen page.  We would like to remind you that starting June
   3, 2024, apps that use information from emails to provide
   reporting or monitoring services will require periodic Gmail
   access renewals After June 3, 2024, newly granted Gmail
   access for consumer Google accounts to reporting and monitoring
   apps will automatically expire after six months.  Users must
   renew permissions for continued access.  Any existing Gmail
   access granted to these apps will expire on July 15, 2024 unless
   renewed by the user.  Users will be able to renew or revoke this
   access at any time through the "Third-party apps & services"
   page on My Account Test your application(s) to ensure that
   they are able to handle an invalid_grant response from the OAuth
   2.0 servers.  Such handling may include re-authenticating the
   user and requesting user consent to obtain new tokens If
   you take no action, and your application is not able to handle
   user re-authorization after a token expires, you may begin
   to see OAuth errors and your application's functionality may
   be affected.

I more or less followed the instructions here:

   https://gitlab.com/muttmua/mutt/-/blob/master/contrib/mutt_oauth2.py.README

under the section "How to create a Google registration" to create my
"app," which as I understand it is a fictitious piece of software whose
registration is used to obtain OAuth2 tokens for Mutt to access one's
own G-Mail account.  This has worked fine to date.  But I don't know how
to test my "application" to ensure that it can handle an invalid_grant
response from the OAuth 2.0 servers.  I'd like to avert any problems
in advance.

Will this be handled automatically by the mutt_oauth2.py script?
Or will a patch to the script be issued?  Or will we have to log in to
console.developers.google.com with our account and somehow tinker with
the "Application" we've created to obtain client_id and client_secret
credentials to paste into the mutt_oauth2.py script?

Best regards,
Greg Marks


signature.asc
Description: PGP signature

Re: highlighting messages to/cc me on mailing list?

[Cameron Simpson]

On 13May2024 10:49, Joe Damato via Mutt-users  wrote:
And now when I switch to the netdev directory within mutt (by pressing 
c),

I can easily see any messages that mention my email address in any thread
on the list.


Late to the thread, and purely for interest: this is what I use for the 
inverse:


color index white default  "((~P|(%f polyname ~f 'cameron simpson'))) | (~v 
~((~P|(%f polyname ~f 'cameron simpson'"

This highlights messages (or collapsed threads) where I've participated.  
So not things addressed to me, but things from me. This keeps mailing 
list discussions in which I've said something highlighted.


The core thing here is the ~P (messages from me); the polyname thing is 
for Discourse, which I use in mailing list mode, and some other lists.


The polyname address group is for lists where the from address is always 
the list, not the author, and "%f polyname ~f 'cameron simpson'" matches 
those addresses where the comment part of the address contains my name, 
which is what Discourse and a few other things do.


Cheers,
Cameron Simpson 

Re: highlighting messages to/cc me on mailing list?

[Joe Damato via Mutt-users]

On Mon, May 13, 2024 at 06:51:26AM +0200, Christopher Zimmermann wrote:
> On Sun, May 12, 2024 at 04:49:45PM -0700, Joe Damato via Mutt-users wrote:
> > A follow up question: is there a way to apply this to only specific imap
> > directories?
> 
> What you now want to use is a folder hook:
> 
> http://www.mutt.org/doc/manual/#folder-hook

Thanks that worked perfectly.

Just incase anyone stumbles on this thread later, here's what I ended up
doing in my muttrc to help manage email for the netdev kernel mailing
list with my gmail account:

1. My company uses gmail for email, so I setup mutt to use gmail for imap
   and SMTP. There are many guides for this on the internet.
2. Added a "label" in gmail's UI, called "netdev" -- which mutt sees as an
   imap directory.
3. Added a filter in gmail to filder all emails TO netdev@vger..., skip my
   inbox and apply the "netdev" label.
4. In my muttrc I added:

folder-hook netdev "lists netdev@vger"
folder-hook netdev "color index color94 default ~p"

And now when I switch to the netdev directory within mutt (by pressing c),
I can easily see any messages that mention my email address in any thread
on the list.

Thanks everyone for your help, I really appreciate it!

- Joe

Re: highlighting messages to/cc me on mailing list?

[Sirius via Mutt-users]

In days of yore (Sun, 12 May 2024), Joe Damato via Mutt-users thus quoth: 
> I am subscribed to some high traffic email lists (linux kernel development
> stuff).
> 
> There are two cases I am trying to deal with which are fairly similar:
> 
>   1. I am subscribed to a mailing list. I start a thread (usually with git
>  send-email) on the list and other developers on the list reply via
>  "reply-all". Since they reply-all, their message will contain the
>  email list I am subscribed to and my personal email address added to
>  the TO or CC line.
> 
>   2. Occasionally, there are existing threads on the list and others will
>  reply to a message I didn't author, but add me to the CC to ask for my
>  input.

Something I do, and there are multiple ways of doing this, is that I want
to see mails addressed to me (period) highlighted. As long as you set
alternates for the addresses that are 'you', you can color the index with

color index  color94default~p

~P is messages _from_ you, ~F is flagged messages and so on.
http://mutt.org/doc/manual/#tab-patterns has all the patterns you can use.
If you want them to really stand out, you can do

#   fgbg  pattern
color index white red ~p

and they should be hard to miss. This is the same method you would use to
highlight specific headers (like List-Id) in a different colour so they
stand out.

HTH,

-- 
Kind regards,

/S

Re: highlighting messages to/cc me on mailing list?

[Christopher Zimmermann]

On Sun, May 12, 2024 at 04:49:45PM -0700, Joe Damato via Mutt-users wrote:
A follow up question: is there a way to apply this to only specific 
imap directories?


What you now want to use is a folder hook:

http://www.mutt.org/doc/manual/#folder-hook


signature.asc
Description: PGP signature

Re: highlighting messages to/cc me on mailing list?

[Joe Damato via Mutt-users]

On Mon, May 13, 2024 at 12:13:47AM +0200, Francesco Ariis wrote:
> Hello Joe,
> 
> Il 12 maggio 2024 alle 14:47 Joe Damato via Mutt-users ha scritto:
> > Is there any way to get mutt to highlight/colorize/mark or somehow
> > indicate to me messages which specifically have my email in the TO or CC
> > line so that I don't miss those?
> 
> This is what I do. First you add a score rule like
> 
> # ~C: messages either to: or cc: EXPR
> score "~C somename" 120
> 
> and then you assign a colour to messages.
> 
> color index green black "~n >100"
> 
> Scoring emails gives me a crude but effective way to scan important
> messages at first sight.
> Will this do?

Thanks! This seems to have done the trick and I think this should work.

A follow up question: is there a way to apply this to only specific imap
directories?

The way I am using mutt is, again super basic, but:

1. I have a gmail account and mutt configured use gmail's imap/smtp setup.
2. In gmail, I have created some "labels" which appear in mutt as imap
   directories and I've created some filters in gmail to apply labels to
   certain messages.

This has the effect that all messages to netdev@... get labeled "netdev",
and skip my inbox completely (which is nice).

Since "labels" seem to be directories, in mutt I press 'c' and then '?'
and I can select the netdev imap directory showing only netdev related
stuff and I see messages which mention me highlighted in green.

Can I apply the scoring rule only to one imap directory by any chance?

Asking because the scoring basically colors my entire inbox green but works
great in the netdev directory :)

Thanks,
Joe

Re: highlighting messages to/cc me on mailing list?

[Francesco Ariis]

Hello Joe,

Il 12 maggio 2024 alle 14:47 Joe Damato via Mutt-users ha scritto:
> Is there any way to get mutt to highlight/colorize/mark or somehow
> indicate to me messages which specifically have my email in the TO or CC
> line so that I don't miss those?

This is what I do. First you add a score rule like

# ~C: messages either to: or cc: EXPR
score "~C somename" 120

and then you assign a colour to messages.

color index green black "~n >100"

Scoring emails gives me a crude but effective way to scan important
messages at first sight.
Will this do?
—F

highlighting messages to/cc me on mailing list?

[Joe Damato via Mutt-users]

Hi:

I am a new mutt user and spent some time reading some of the docs about
mailing lists, but probably missed something that would help in my case.

I am subscribed to some high traffic email lists (linux kernel development
stuff).

There are two cases I am trying to deal with which are fairly similar:

  1. I am subscribed to a mailing list. I start a thread (usually with git
 send-email) on the list and other developers on the list reply via
 "reply-all". Since they reply-all, their message will contain the
 email list I am subscribed to and my personal email address added to
 the TO or CC line.

  2. Occasionally, there are existing threads on the list and others will
 reply to a message I didn't author, but add me to the CC to ask for my
 input.

Is there any way to get mutt to highlight/colorize/mark or somehow
indicate to me messages which specifically have my email in the TO or CC
line so that I don't miss those?

Right now I have a basic muttrc that has:

set sort=threads
lists netdev@...

and some basic color options.

I am worried about potentially missing messages on the list which mention
me specifically since the message would just appear in some random thread
on the list that I may otherwise not read unless mutt informed somehow that
the message had me in the TO or CC.

Thanks,
Joe

Re: Strange problem on new system with versus (or linefeed versus carriage return)

[Jon LaBadie]

On Thu, May 09, 2024 at 05:59:39PM +0200, Dennis Preiser wrote:

On Thu, May 09, 2024 at 04:24:56PM +0100, Chris Green wrote:

I have the following in muttrc so that hitting 'Enter' (the CR key) on
the keyboard sends an E-Mail after composing it:-

bindcompose \n send-message # rather than 'y'

This works as intended on the old system but not on the new system, it
would seem that mutt sees the 'Enter' key as CR (0x0d) on the new
system whereas on the old system it sees it as LF (0x0a).
Can anyone explain why this is and, more to the point, tell me how to



From the documentation:


| 6.2. Enter versus Return
|
| Prior to version 2.2, Mutt used a default ncurses mode (“nl()”). This
| mode maps keyboard input of either  or  to the same
| value, which Mutt interpreted as  internally.
|
| However, starting in version 2.2, this mode is turned off, allowing
|  and  to be mapped separately, if desired. The default
| keyboard mappings set both, but you can override this or create new
| bindings with one or the other (or both).
|
| Note that in terminal application, such as Mutt,  is the same as
| “\n” and ^J; while  is the same as “\r” and ^M.


Kudos to the document writers!  It is nice to see readable
and complete documentation.




fix it?



bindcompose \r send-message # rather than 'y'



--
Jon H. LaBadie j...@labadie.us
 154 Milkweed Dr (540) 868-8052 (H)
 Lake Frederick, VA 22630(703) 935-6720 (M)

Re: set date_format

[Will Yardley]

On Thu, May 09, 2024 at 06:47:30PM +, Ебрашка wrote:
> Can you tell me how to make the date display in the catalog with letters
> in day/month/year format, i.e. 09/05/2024 I write in muttrc set
> date_format="%d/%m/%Y" and there are no changes.

I think you need to override the default or current setting of
$index_format, and change %{%b %d} to %D (or %d if you want the sender's
time zone)

Maybe someone can better explain this (since the behavior I'm seeing
from %{%b %d} doesn't line up exactly with what I'd expect from TFM),
but I think that will give the behavior you want.

w

set date_format

[Ебрашка]

Can you tell me how to make the date display in the catalog with letters
in day/month/year format, i.e. 09/05/2024 I write in muttrc set
date_format="%d/%m/%Y" and there are no changes.

Re: Strange problem on new system with versus (or linefeed versus carriage return)

[Chris Green]

On Thu, May 09, 2024 at 05:59:39PM +0200, Dennis Preiser wrote:
> On Thu, May 09, 2024 at 04:24:56PM +0100, Chris Green wrote:
> > I have the following in muttrc so that hitting 'Enter' (the CR key) on
> > the keyboard sends an E-Mail after composing it:-
> >
> > bindcompose \n send-message # rather than 'y'
> >
> > This works as intended on the old system but not on the new system, it
> > would seem that mutt sees the 'Enter' key as CR (0x0d) on the new
> > system whereas on the old system it sees it as LF (0x0a).
> > Can anyone explain why this is and, more to the point, tell me how to
> 
> From the documentation:
> 
> | 6.2. Enter versus Return
> | 
> | Prior to version 2.2, Mutt used a default ncurses mode (“nl()”). This
> | mode maps keyboard input of either  or  to the same
> | value, which Mutt interpreted as  internally.
> | 
> | However, starting in version 2.2, this mode is turned off, allowing
> |  and  to be mapped separately, if desired. The default
> | keyboard mappings set both, but you can override this or create new
> | bindings with one or the other (or both).
> | 
> | Note that in terminal application, such as Mutt,  is the same as
> | “\n” and ^J; while  is the same as “\r” and ^M.
> 
Ah, that explains it perfectly, thank you!

> > fix it?
> 
> 
>  bindcompose \r send-message # rather than 'y'
> 
... and that fixes it, more thank you. :-)

-- 
Chris Green

Re: Strange problem on new system with versus (or linefeed versus carriage return)

[Dennis Preiser]

On Thu, May 09, 2024 at 04:24:56PM +0100, Chris Green wrote:
> I have the following in muttrc so that hitting 'Enter' (the CR key) on
> the keyboard sends an E-Mail after composing it:-
>
> bindcompose \n send-message # rather than 'y'
>
> This works as intended on the old system but not on the new system, it
> would seem that mutt sees the 'Enter' key as CR (0x0d) on the new
> system whereas on the old system it sees it as LF (0x0a).
> Can anyone explain why this is and, more to the point, tell me how to

>From the documentation:

| 6.2. Enter versus Return
| 
| Prior to version 2.2, Mutt used a default ncurses mode (“nl()”). This
| mode maps keyboard input of either  or  to the same
| value, which Mutt interpreted as  internally.
| 
| However, starting in version 2.2, this mode is turned off, allowing
|  and  to be mapped separately, if desired. The default
| keyboard mappings set both, but you can override this or create new
| bindings with one or the other (or both).
| 
| Note that in terminal application, such as Mutt,  is the same as
| “\n” and ^J; while  is the same as “\r” and ^M.

> fix it?


 bindcompose \r send-message # rather than 'y'

Dennis

Re: Strange problem on new system with versus (or linefeed versus carriage return)

[Michael Kjörling]

On 9 May 2024 16:24 +0100, from c...@isbd.net (Chris Green):
> I have the following in muttrc so that hitting 'Enter' (the CR key) on
> the keyboard sends an E-Mail after composing it:-
> 
> bindcompose \n send-message # rather than 'y'


> On the new system the help line at the bottom shows:-
> 
> :Send  q:Abort  t:To  c:CC  s:Subj  a:Attach file  d:Descrip  
> ?:Help
> 
> Whereas on the old system it shows:-
> 
> :Send  q:Abort  t:To  c:CC  s:Subj  a:Attach file  d:Descrip  
> ?:Help

Have you tried using  in place of \n in the bind command? Per
http://www.mutt.org/doc/manual/#tab-key-names \n is technically
interpreted as "newline" whereas  is interpreted as the Enter
key; that seems like it might be significant here.

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

Strange problem on new system with versus (or linefeed versus carriage return)

[Chris Green]

I am in the process of migrating from an old system running mutt 2.1.4
on xubuntu 22.04 to a new system running mutt 2.2.12 on xubuntu 24.04.

I have simply copied across all my muttrc configuration etc. without
change, it's all working pretty well except for (so far) one problem:-

I have the following in muttrc so that hitting 'Enter' (the CR key) on
the keyboard sends an E-Mail after composing it:-

bindcompose \n send-message # rather than 'y'

This works as intended on the old system but not on the new system, it
would seem that mutt sees the 'Enter' key as CR (0x0d) on the new
system whereas on the old system it sees it as LF (0x0a).

The Enter key works everywhere else on the system, why is mutt showing
this oddity?

On the new system the help line at the bottom shows:-

:Send  q:Abort  t:To  c:CC  s:Subj  a:Attach file  d:Descrip  ?:Help


Whereas on the old system it shows:-

:Send  q:Abort  t:To  c:CC  s:Subj  a:Attach file  d:Descrip  ?:Help

Can anyone explain why this is and, more to the point, tell me how to
fix it?

-- 
Chris Green

New attachment viewer for macOS

[Robin Sommer]

Hi all,

I used run `qlmanage` to view attachments and HTML bodies on my Mac
but that has always been feeling a bit clumsy. So a little while ago I
ended up trying to write a replacement: a little standalone document
previewer wrapping macOS' *Quick View* for easy use with mutt (and,
more generally, from the command line). I did this originally mostly
as an exercise in SwiftUI but ended up quite liking it, so I figured
I'd send a pointer here in case anybody else is looking for
alternatives.

It's on GitHub at https://github.com/rsmmr/qlview. You can either
build it yourself through Xcode or download a pre-built binary, see
the `README`. There's also some more information on possible ways to
integrate it with mutt through `mailcap` and a macro. This is all a bit
in-progress still too, so feel free to send suggestions or even patches.

Best,

Robin

-- 
Robin Sommer * ICSI * ro...@icir.org * www.icir.org/robin

Intermittent reconnection failure

[Nick via Mutt-users]

Having intermittent trouble with mutt 2.2.12 on debian stable.  It
uses an imap server (dovecot) over a wireguard VPN.  When my laptop
resumes from suspend, a few seconds elapse before the VPN becomes
available and mutt usually reconnects automatically.

Sometimes, about one time in 5, it doesn't.  In those cases I make
mutt reconnect by opening a folder.  It's not a grave problem but I'd
prefer mutt to try a little harder to reconnect, if that can be done.

I'm attaching two extracts from .muttdebug0, running with '-d 2'.
reconn-ok.txt shows mutt reconnecting after running my preconnect
script.  reconn-failed.txt shows mutt failing to reconnect and without
running my preconnect script.  I obscured one folder name with  for
privacy.

Why does mutt sometimes fail to reconnect?

Thanks
-- 
Nick
Asunción 08:36 PYT ►  21°C  ◆  cielo claro  ◆  11Km/h SSE  ◆  66% HR
[2024-04-17 19:44:00] 4< * STATUS Junk (RECENT 2 UIDNEXT 335 UIDVALIDITY 
1519640566 UNSEEN 0)
[2024-04-17 19:44:00] 4< a3058 OK Status completed (0.001 + 0.000 secs).
[2024-04-17 19:44:00] 4< * STATUS *** (RECENT 0 UIDNEXT 1551 UIDVALIDITY 
1519640578 UNSEEN 0)
[2024-04-17 19:44:00] 4< a3059 OK Status completed (0.001 + 0.000 secs).
[2024-04-18 05:41:01] 4> a3060 NOOP
[2024-04-18 05:41:12] tls_socket_read (Error in the pull function.)
[2024-04-18 05:41:16] imap_cmd_step: Error reading server response.
[2024-04-18 05:41:16] A fatal error occurred.  Will attempt reconnection.
[2024-04-18 05:41:16] imap_exec: command failed:
[2024-04-18 05:41:16] Trying to reconnect...
[2024-04-18 05:41:16] Reading imaps://rolly.vpn/INBOX...
[2024-04-18 05:41:16] Executing preconnect: wait-for-ping -v -l 
~/.local/logs/mutt-preconnect.log rolly.vpn 20
[2024-04-18 05:41:16] Preconnect result: 0
[2024-04-18 05:41:16] Looking up rolly.vpn...
[2024-04-18 05:41:16] Connecting to rolly.vpn...
[2024-04-18 05:41:18] SSL/TLS connection using TLS1.3 
(ECDHE-RSA/AES-256-GCM/AEAD)
[2024-04-18 05:41:18] Connected to rolly.vpn:993 on fd=4
[2024-04-18 05:41:18] 4< * OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID 
ENABLE IDLE LITERAL+ AUTH=PLAIN] Dovecot (Debian) ready.
[2024-04-18 05:41:18] imap_authenticate: Using any available method.
[2024-04-18 05:41:18] imap_auth_gsasl: using mech PLAIN
[2024-04-18 05:41:18] Authenticating (PLAIN)...
[2024-04-18 07:55:25] 4< * STATUS Junk (RECENT 2 UIDNEXT 335 UIDVALIDITY 
1519640566 UNSEEN 0)
[2024-04-18 07:55:25] 4< a5509 OK Status completed (0.001 + 0.000 secs).
[2024-04-18 07:55:25] 4< * STATUS *** (RECENT 0 UIDNEXT 1551 UIDVALIDITY 
1519640578 UNSEEN 0)
[2024-04-18 07:55:25] 4< a5510 OK Status completed (0.001 + 0.000 secs).
[2024-04-18 08:26:31] 4> a5511 NOOP
[2024-04-18 08:26:34] 4< * BYE Disconnected for inactivity.
[2024-04-18 08:26:34] Handling BYE
[2024-04-18 08:26:34] Disconnected for inactivity.
[2024-04-18 08:26:36] A fatal error occurred.  Will attempt reconnection.
[2024-04-18 08:26:36] imap_exec: command failed: * BYE Disconnected for 
inactivity.
[2024-04-18 08:26:36] Trying to reconnect...
[2024-04-18 08:26:36] Reading imaps://rolly.vpn/alert...
[2024-04-18 08:26:36] Selecting alert...
[2024-04-18 08:26:36] 5> a0292 STATUS "Drafts" (MESSAGES)
a0293 SELECT "alert"
[2024-04-18 08:26:36] tls_socket_read (Error in the pull function.)
[2024-04-18 08:26:40] imap_cmd_step: Error reading server response.
[2024-04-18 08:26:40] Reconnect failed.  Mailbox closed.
[2024-04-18 08:26:40] mutt_socket_close: Attempt to close closed connection.

Re: Can't sign if I sign

[googly . negotiator862]

On Sat, Apr 13, 2024 at 11:30:55AM +0200, Laura Orvokki Kursula via Mutt-users 
wrote:

> > > I have encountered a strange problem setting up mutt: when I
> > > attach a signature block to my e-mail using `$signature', my PGP
> > > signature is, according to mutt, invalid. E-mails without
> > > signature blocks yield valid PGP signatures. If I go back and
> > > replace the automatic signature with something else, the PGP
> > > signature checks out too. Is this a known issue? Is there
> > > something I can do about it?

> After some more testing, I figured out this issue had nothing at all
> to do with signature blocks, or mutt. The culprit was the silly
> `X-Clacks-Overhead' header I had configured postfix to add ages
> ago. How I came to think it had a correlation with whether or not I
> use a `$signature' remains a mystery; my bet is on a lack of sleep.

But that is even odder. GPG signatures don't cover headers. Is it
possible that your postfix bit was in fact added to the body instead?

-- 
Ian

Re: Can't sign if I sign

[Laura Orvokki Kursula via Mutt-users]

On Sat, Apr 13, 2024 at 07:39:45AM +0200, Sirius via Mutt-users wrote:
> In days of yore (Sat, 13 Apr 2024), Laura Orvokki Kursula via Mutt-users thus 
> quoth: 
> > Hello all
> > 
> > I have encountered a strange problem setting up mutt: when I attach a 
> > signature
> > block to my e-mail using `$signature', my PGP signature is, according to 
> > mutt,
> > invalid. E-mails without signature blocks yield valid PGP signatures. If I 
> > go
> > back and replace the automatic signature with something else, the PGP 
> > signature
> > checks out too. Is this a known issue? Is there something I can do about it?
> 
> That is odd. I do not see that at all (just tested, mutt-2.2.13 on
> Debian). For a gpg signature to be invalid, what is signed has to have
> changed in some way.
> 
> You are doing effectively this in muttrc:
>   set signature="~/.mutt/signature"
> yes? And there is nothing in the signature that could be altered after it
> is pulled into the message and the GnuPG signature is applied, right?

After some more testing, I figured out this issue had nothing at all to do with
signature blocks, or mutt. The culprit was the silly `X-Clacks-Overhead' header
I had configured postfix to add ages ago. How I came to think it had a
correlation with whether or not I use a `$signature' remains a mystery; my bet
is on a lack of sleep.

Thank you for your time.
 
> My questions would be:
>  - mutt gnupg configuration, is it changed in any way from distribution
>default?
>  - version of mutt and what distribution/version are you running?
> 
> My suggestion would be to run mutt with -d1 or -d2 and look at the debug
> output (crank the debug level higher if need be, it goes up to five) to
> work out what happens.
> 
> -- 
> Kind regards,
> 
> /S



-- 
Laura


signature.asc
Description: PGP signature

Re: Can't sign if I sign

[Sirius via Mutt-users]

In days of yore (Sat, 13 Apr 2024), Laura Orvokki Kursula via Mutt-users thus 
quoth: 
> Hello all
> 
> I have encountered a strange problem setting up mutt: when I attach a 
> signature
> block to my e-mail using `$signature', my PGP signature is, according to mutt,
> invalid. E-mails without signature blocks yield valid PGP signatures. If I go
> back and replace the automatic signature with something else, the PGP 
> signature
> checks out too. Is this a known issue? Is there something I can do about it?

That is odd. I do not see that at all (just tested, mutt-2.2.13 on
Debian). For a gpg signature to be invalid, what is signed has to have
changed in some way.

You are doing effectively this in muttrc:
  set signature="~/.mutt/signature"
yes? And there is nothing in the signature that could be altered after it
is pulled into the message and the GnuPG signature is applied, right?

My questions would be:
 - mutt gnupg configuration, is it changed in any way from distribution
   default?
 - version of mutt and what distribution/version are you running?

My suggestion would be to run mutt with -d1 or -d2 and look at the debug
output (crank the debug level higher if need be, it goes up to five) to
work out what happens.

-- 
Kind regards,

/S


signature.asc
Description: PGP signature

Can't sign if I sign

[Laura Orvokki Kursula via Mutt-users]

Hello all

I have encountered a strange problem setting up mutt: when I attach a signature
block to my e-mail using `$signature', my PGP signature is, according to mutt,
invalid. E-mails without signature blocks yield valid PGP signatures. If I go
back and replace the automatic signature with something else, the PGP signature
checks out too. Is this a known issue? Is there something I can do about it?

Thank you all in advance

-- Laura


signature.asc
Description: PGP signature

Re: Question about message id

[Derek Martin]

On Thu, Apr 11, 2024 at 02:35:30PM -0700, googly.negotiator...@aceecat.org 
wrote:
> On Thu, Apr 11, 2024 at 01:13:52PM +1000, raf via Mutt-users wrote:
> - if the mailing list does mess with msgid, it absolutely must do it
>   consistently for all copies of the message.

For existing software that has problems with '/' (because it is a path
separator), the solution is actually trivially simple.  On the way in,
replace it with one of the "specials" that are not allowed in a
message ID, but IS allowed in your system's path names.  On the way
out, do the reverse transformation.

You need only write a simple function that does each thing, and call
them once, when the data is "on the way in" (from whichever source,
either the RFC2822 message form or the on-disk form). Memory is cheap
these days so just save both forms in your data structure and use the
right one for the given context.  Or don't, the perf hit will be
imperceptible to the user (but it's more typing to call the function
every time you need one or the other).  There are probably only a
handful of places you'd need to change, if you wrote suitably modular
software--even in mail software, there are few cases where the message
ID is at all interesting.

-- 
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.



signature.asc
Description: PGP signature

Re: Question about message id

[Derek Martin]

On Thu, Apr 11, 2024 at 01:13:52PM +1000, raf via Mutt-users wrote:
> 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
[...]
> 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.

Yeah, but...

> So it seems that there is a reason to care about this.

I disagree, both for the actual stated case of wanting "the same
beautiful message-ID as Yandex mail" and for the more general case of
controlling message ID format.  It's not something the USER should
ever have to think about, for the reasons I said, quoted above--it's
something only developers should ever have to care about, and even
then only to the point where it complies with standards, which it
does.  If Mutt wants to accommodate broken list archive software (it
IS broken, because it fails to handle the full range of decades-old
standard, documented valid input values), then it should use a format
that does that.  No user should ever have reason to care about this.
Seriously.

> Although one could argue that the mailing list archiving system
> should accept the responsibility of munging message ids to suit its
> own needs.

Indeed.  But even that presupposes the design flaw that leads to the
necessity of doing that.  They could have simply organized the data
differently (e.g. using a database, etc.) that does not have Unix path
name issues.  Also worth pointing out that if the software in question
runs on Windows, there are additional allowed characters that cause
breakage there.

-- 
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.



signature.asc
Description: PGP signature

Re: Question about message id

[googly . negotiator862]

On Thu, Apr 11, 2024 at 01:13:52PM +1000, raf via Mutt-users 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.

I believe it has to be a *syntactically* valid email address,
according to the RFC. So, for example, an all-alphabetical random
string would fail, because it'd lack a "@".

> 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).

I myself see not much wrong with a mailing list doing that, but:

- others seem to feel differently, that modifying the msgid once a
  valid one has been generated by a MUA is gauche. And I understand
  that it makes some things slightly harder, especially if you use fcc
  or similar feature in other MUAs.

- if the mailing list does mess with msgid, it absolutely must do it
  consistently for all copies of the message. Not like the mailman
  managed GNU lists where the msgid was (or still is?) munged if and
  only if the message was crossing a mail / news boundary. I stopped
  following the GNU lists because of that and I never went back.

-- 
Ian

Re: How to delete message with purge=no?

[Sadeep Madurange]

Hello Will,

On 2024-04-10 10:05:50, Will Yardley wrote:
> On Wed, Apr 10, 2024 at 08:22:03PM +0800, Sadeep Madurange wrote:
> > When deleting emails (with d), I get a prompt for purging them. I'd
> > like to silence that prompt with 'no'. And, see the prompt when I
> > change folder, or better yet, when I quit mutt.
> > 
> > Is there a way to do this?
> 
> If I'm understanding your question right, I think if you have
> "delete=ask-yes" in your config, this will already be the case, i.e.,
> it should just be marking the message for deletion, and asking you
> when synchronizing the mailbox, which should already only happen when
> you're changing folder or quitting, unless you explicitly run
> .
> 
> Do you have any macros that might be running ?

You're right. I had 'macro index,pager dd ""' 
in my rc. I removed the  part, and now it's working the
way I want. Thank you!

-- 
Sadeep Madurange
PGP: 103BF9E3E750BF7E

Re: pretty-print mutt emails

[Matthias Apitz]

El día miércoles, abril 10, 2024 a las 06:26:23 -0400, Kurt Hackenberg escribió:

> On Wed, Apr 10, 2024 at 10:23:37AM +0200, Matthias Apitz wrote:
> 
> > I wasn't aware before, that muttprint exists for my mobile phone as
> > well. I've now installed it and configured it, even with the FreeBSD's
> > Beastie in the right corner.
> 
> What?  Do you run FreeBSD and Mutt on the phone?

I use the Purism L5 as my daily driver, see https://puri.sm/products/librem-5/
This runs PureOS, a Debian flavor. On my laptops I run FreeBSD CURRENT
and copied the Beastie.eps file into the installed apt package of
muttprint:

set print_cmd="muttprint --printer - -i /home/purism/guru/Beastie.eps --paper 
A4 --rem_sig | convert - /home/purism/Documents/muttprint.pdf "

matthias

-- 
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

I am not at war with Russia.  Я не воюю с Россией.
Ich bin nicht im Krieg mit Russland.

Re: Question about message id

[raf via Mutt-users]

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: pretty-print mutt emails

[Ken Moffat via Mutt-users]

On Wed, Apr 10, 2024 at 07:25:11AM +0200, Matthias Apitz wrote:
> El día martes, abril 09, 2024 a las 06:54:46 -0400, H escribió:
> 
> > On 04/07/2024 07:42 AM, Matthias Apitz wrote:
> > > I do use on FreeBSD muttprint:
> > >
> > > Name   : muttprint Version: 0.73_5 Installed
> > > on   : Sun Sep 24 11:32:52 2023 CEST Origin :
> > > print/muttprint Architecture   : FreeBSD:14:amd64 Prefix
> > > : /usr/local Categories : print mail Licenses   :
> > > GPLv2 Maintainer : g...@unixarea.de WWW:
> > > http://muttprint.sourceforge.net/ Comment: Utility to
> > > print mail for most any mail client
> > >
> > > Started from ~/.muttrc as:
> > >
> > > $ grep muttprint .muttrc set print_cmd="muttprint --printer
> > > pdf --paper A4 --rem_sig "
> > >
> > > The result is nice and attached.
> > >
> > >   matthias
> > >
> > I would like to try muttprint for my installation of neomutt on
> > CentOS 7. When I visit the sourceforge page above, the latest
> > version for download is 0.72d, not 0.73_5 as you listed above.
> > 0.72d was released 2007-01-08...
> 
> The "_5" in "0.73_5" is FreeBSD'ish. i.e. the version of the
> change of the port. The history is here:
> https://www.freshports.org/print/muttprint/#history.  I don't know
> why the 0.73 source is not available. I have it in my build
> server:
> 
> [guru@jet /usr/ports/distfiles]$ ls -l muttprint-0.73.tar.gz
> -rw-r--r--  1 root wheel 361268 Dec 26  2008 muttprint-0.73.tar.gz
> 
> I could make it available on my Internet host. About any RPM I
> don't know much. On my Linux mobilephone, running a Debian I see:
> 
> $ apt search muttprint muttprint/byzantium 0.73-10 all Pretty
> printing of mails
> 
> muttprint-manual/byzantium 0.73-10 all Manual for muttprint
> 
> HIH
> 
>   matthias
> 
If something is available in debian, debian will ship a '.orig' as
well as all the patches they are using.  Looks as if sid is now on
their 11th revision: https://packages.debian.org/sid/muttprint

ĸen
-- 
I used to farm cats, and let me tell you, their eggs don't taste
nearly as chocolatey as they look.  -- Milton Jones, Mock the Week

Re: pretty-print mutt emails

[Kurt Hackenberg]

On Wed, Apr 10, 2024 at 10:23:37AM +0200, Matthias Apitz wrote:


I wasn't aware before, that muttprint exists for my mobile phone as
well. I've now installed it and configured it, even with the FreeBSD's
Beastie in the right corner.


What?  Do you run FreeBSD and Mutt on the phone?

Re: How to delete message with purge=no?

[Will Yardley]

On Wed, Apr 10, 2024 at 08:22:03PM +0800, Sadeep Madurange wrote:
> When deleting emails (with d), I get a prompt for purging them. I'd like
> to silence that prompt with 'no'. And, see the prompt when I change
> folder, or better yet, when I quit mutt.
> 
> Is there a way to do this?

If I'm understanding your question right, I think if you have
"delete=ask-yes" in your config, this will already be the case, i.e., it
should just be marking the message for deletion, and asking you when
synchronizing the mailbox, which should already only happen when you're
changing folder or quitting, unless you explicitly run .

Do you have any macros that might be running ?

w

Re: Question about message id

[Will Yardley]

On Wed, Apr 10, 2024 at 01:05:09PM +0800, Kevin J. McCarthy wrote:
> On Tue, Apr 09, 2024 at 09:33:06AM -0700, Will Yardley wrote:
> > side note: using quotes around the template screws things up, that is,
> > set message_id_format=""
> > vs
> > set message_id_format=
> > 
> > results in a broken message-id with the quotes inside the angle brackets
> > (Message-ID: <"xyz">)
> 
> That shouldn't be the case.  The outer double quotes are stripped off during
> muttrc evaluation.
> 
> You may want to double check whether you accidentally copy/pasted unicode
> curly quotes.

You're right. That said, maybe we could setup the online version of the
docs to be more copy / pasta compliant?
http://www.mutt.org/doc/manual/#message-id-format

I'd normally expect to be able to copy the whole string (including the
quotes) into a config

Seems like mutt is using "\fC" and "\fP" consistently (intentionally?)
in various sections of the docs in init.h, though. 

The quotes in 2202 are also a little odd with the left / right double
quotes, then outer regular double quotes, then inner regular ones.
https://gitlab.com/muttmua/mutt/-/blob/master/init.h?ref_type=heads#L2202
https://gitlab.com/muttmua/mutt/-/blob/master/init.h?ref_type=heads#L2208

/w

Re: How to delete message with purge=no?

[meine via Mutt-users]

On Wed, Apr 10, 2024 at 08:22:03PM +0800, Sadeep Madurange wrote:
> Hello,
>
> When deleting emails (with d), I get a prompt for purging them. I'd like
> to silence that prompt with 'no'. And, see the prompt when I change
> folder, or better yet, when I quit mutt.
>
> Is there a way to do this?

There are a lot of possibilities for deleting mails and empying the
trash, see http://www.mutt.org/doc/manual/

Here mutt does like you want to have. I looked into my .muttrc but found no 
clue how it works.

KR,

//meine

How to delete message with purge=no?

[Sadeep Madurange]

Hello,

When deleting emails (with d), I get a prompt for purging them. I'd like
to silence that prompt with 'no'. And, see the prompt when I change
folder, or better yet, when I quit mutt.

Is there a way to do this?

-- 
Sadeep Madurange
PGP: 103BF9E3E750BF7E

Re: pretty-print mutt emails

[Nuno Silva via Mutt-users]

On 2024-04-10, Matthias Apitz wrote:

> El día martes, abril 09, 2024 a las 06:54:46 -0400, H escribió:
>
>> On 04/07/2024 07:42 AM, Matthias Apitz wrote:
>> > I do use on FreeBSD muttprint:
>> >
>> > Name   : muttprint
>> > Version: 0.73_5
[...]
>> > WWW: http://muttprint.sourceforge.net/
>> > Comment: Utility to print mail for most any mail client
[...]
>> I would like to try muttprint for my installation of neomutt on
>> CentOS 7. When I visit the sourceforge page above, the latest
>> version for download is 0.72d, not 0.73_5 as you listed above. 0.72d
>> was released 2007-01-08...
>
> The "_5" in "0.73_5" is FreeBSD'ish. i.e. the version of the change of the
> port. The history is here: 
> https://www.freshports.org/print/muttprint/#history.
> I don't know why the 0.73 source is not available. I have it in my
> build server:

It is available on SourceForge (project page) but not on the muttprint
(sourceforge-hosted?) website:

https://sourceforge.net/projects/muttprint/files/ lists 0.73 as the
latest,

https://sourceforge.net/projects/muttprint/files/muttprint/muttprint-0.73/

https://sourceforge.net/p/muttprint/code/HEAD/tree/trunk/muttprint/CHANGES

> [guru@jet /usr/ports/distfiles]$ ls -l muttprint-0.73.tar.gz
> -rw-r--r--  1 root wheel 361268 Dec 26  2008 muttprint-0.73.tar.gz
[...]

-- 
Nuno Silva

Re: pretty-print mutt emails

[Matthias Apitz]

El día miércoles, abril 10, 2024 a las 07:25:11 +0200, Matthias Apitz escribió:

> I could make it available on my Internet host. About any RPM I don't
> know much. On my Linux mobilephone, running a Debian I see:
> 
> $ apt search muttprint
> muttprint/byzantium 0.73-10 all
>   Pretty printing of mails
> 
> muttprint-manual/byzantium 0.73-10 all
>   Manual for muttprint

I wasn't aware before, that muttprint exists for my mobile phone as
well. I've now installed it and configured it, even with the FreeBSD's
Beastie in the right corner. The fonts are a bit ugly, don't know why
(and to busy to investigate this). See attachment.

matthias
-- 
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

I am not at war with Russia.  Я не воюю с Россией.
Ich bin nicht im Krieg mit Russland.


muttprint.pdf
Description: Adobe PDF document

Re: Question about message id

[Ебрашка]

Thanks everyone for the replies and discussion, something to ponder. 

Всем спасибо за ответы и дискуссию, есть над чем поразмышлять. 

Re: pretty-print mutt emails

[Matthias Apitz]

El día martes, abril 09, 2024 a las 06:54:46 -0400, H escribió:

> On 04/07/2024 07:42 AM, Matthias Apitz wrote:
> > I do use on FreeBSD muttprint:
> >
> > Name   : muttprint
> > Version: 0.73_5
> > Installed on   : Sun Sep 24 11:32:52 2023 CEST
> > Origin : print/muttprint
> > Architecture   : FreeBSD:14:amd64
> > Prefix : /usr/local
> > Categories : print mail
> > Licenses   : GPLv2
> > Maintainer : g...@unixarea.de
> > WWW: http://muttprint.sourceforge.net/
> > Comment: Utility to print mail for most any mail client
> >
> > Started from ~/.muttrc as:
> >
> > $ grep muttprint .muttrc
> > set print_cmd="muttprint --printer pdf --paper A4 --rem_sig "
> >
> > The result is nice and attached.
> >
> > matthias
> >
> I would like to try muttprint for my installation of neomutt on CentOS 7. 
> When I visit the sourceforge page above, the latest version for download is 
> 0.72d, not 0.73_5 as you listed above. 0.72d was released 2007-01-08...

The "_5" in "0.73_5" is FreeBSD'ish. i.e. the version of the change of the
port. The history is here: https://www.freshports.org/print/muttprint/#history.
I don't know why the 0.73 source is not available. I have it in my
build server:

[guru@jet /usr/ports/distfiles]$ ls -l muttprint-0.73.tar.gz
-rw-r--r--  1 root wheel 361268 Dec 26  2008 muttprint-0.73.tar.gz

I could make it available on my Internet host. About any RPM I don't
know much. On my Linux mobilephone, running a Debian I see:

$ apt search muttprint
muttprint/byzantium 0.73-10 all
  Pretty printing of mails

muttprint-manual/byzantium 0.73-10 all
  Manual for muttprint

HIH

matthias

-- 
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

I am not at war with Russia.  Я не воюю с Россией.
Ich bin nicht im Krieg mit Russland.

Re: Question about message id

[Kevin J. McCarthy]

On Tue, Apr 09, 2024 at 09:33:06AM -0700, Will Yardley wrote:

side note: using quotes around the template screws things up, that is,
set message_id_format=""
vs
set message_id_format=

results in a broken message-id with the quotes inside the angle brackets
(Message-ID: <"xyz">)


That shouldn't be the case.  The outer double quotes are stripped off 
during muttrc evaluation.


You may want to double check whether you accidentally copy/pasted 
unicode curly quotes.  You can also check the value mutt has read in via 
:set ?message_id_format


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature

Re: pretty-print mutt emails

[H]

On 04/07/2024 07:42 AM, Matthias Apitz wrote:
> I do use on FreeBSD muttprint:
>
> Name   : muttprint
> Version: 0.73_5
> Installed on   : Sun Sep 24 11:32:52 2023 CEST
> Origin : print/muttprint
> Architecture   : FreeBSD:14:amd64
> Prefix : /usr/local
> Categories : print mail
> Licenses   : GPLv2
> Maintainer : g...@unixarea.de
> WWW: http://muttprint.sourceforge.net/
> Comment: Utility to print mail for most any mail client
>
> Started from ~/.muttrc as:
>
> $ grep muttprint .muttrc
> set print_cmd="muttprint --printer pdf --paper A4 --rem_sig "
>
> The result is nice and attached.
>
>   matthias
>
I would like to try muttprint for my installation of neomutt on CentOS 7. When 
I visit the sourceforge page above, the latest version for download is 0.72d, 
not 0.73_5 as you listed above. 0.72d was released 2007-01-08...

Does anyone know if the rpm version on the sourceforge page can be installed on 
CentOS 7? Oops, just tried to download the rpm version and it is not present on 
the page...

Re: Question about message id

[Cameron Simpson]

On 09Apr2024 07:11, Michael Kjörling  wrote:

On 9 Apr 2024 07:32 +1000, from c...@cskk.id.au (Cameron Simpson):
_Or_ you could "set sendmail=" to a script of your own to add a 
message-id

header - that is what mutt uses to deliver the message to a mail system -
you could add a header there then pass the message on to whatever you had
mutt using before.


Wouldn't that at a minimum cause a discrepancy between the message-ID
of what is actually sent, and of what is stored in the Fcc?


If mutt made one, which I gather it actually does (I had thought not).  
Agree such a script should never replace an existing message-id.


Cheers,
Cameron Simpson 

Re: Question about message id

[Dan Ritter]

Cameron Simpson wrote: 
> On 07Apr2024 13:19, Ебрашка  wrote:
> > Question, what should I write in .muttrc to make my outgoing mails have
> > the same beautiful message-ID as Yandex mail?
> > For example Message-Id: <43265...@example.com> consisting of random
> > digits and domain name
> 
> I think it would be enough to supply your own message-id header; I don't
> think it is necessarily mutt making it at all. Mutt hands messages to a mail
> system, and a mail system adds a message-id if one is missing.
> 
> You could (a) turn on "set edit_headers=yes" so the headers are visible in
> your message and (b) have your editor startup make one?
> 
> _Or_ you could "set sendmail=" to a script of your own to add a message-id
> header - that is what mutt uses to deliver the message to a mail system -
> you could add a header there then pass the message on to whatever you had
> mutt using before.

And don't be overly clever and set a custom header to a script
that produces a message-id; that will get evaluated when mutt
starts and not again for every message, thus defeating the
point.

Please don't ask me how I know.


-dsr-

Re: Question about message id

[Derek Martin]

On Tue, Apr 09, 2024 at 09:25:56AM -0700, Will Yardley wrote:
> On Tue, Apr 09, 2024 at 11:33:55AM -0400, Derek Martin wrote:
> > If so that feature may not be working correctly...
> 
> That is the old format for the mutt version I'm using. The new format
> looks like
> 
> 
> 
> Thought you were on that long thread about this when it changed a while
> back, but maybe remembering wrong.

I was--but I guess the source of my confusion is I don't actually care
what the message ID format is (as should no user), so I never bothered
to internalize it, but I vaguely (mis)remembered it had (I thought
one, but at least one) more dot-separated components.

My issue was never with the specifics of the format, but rather the
practical benefit of the changes and the spurious logic in favor of
them vs. the cost of implementing and maintaining them.

Cheers

-- 
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.



signature.asc
Description: PGP signature

Re: Question about message id

[Will Yardley]

On Tue, Apr 09, 2024 at 11:33:55AM -0400, Derek Martin wrote:
> > I think some people mentioned some minor threading issues with the new
> > format?
> 
> Is that so?  I don't recall noticing anything about that... I'd love a
> pointer to some details, if anyone has that.

It's possible that it was since fixed. The issue isn't with threading
_in_ a main client, I think, but with certain web archiving software in
the case where the message-id has a "/" character.

https://people.kernel.org/monsieuricon/fix-your-mutt

> Anyway, I said then, and
> maintain now, that changing the format and making it configurable was
> pointless and added complexity without good technical justification.
> You may have just proven that. =8^)

Right, I was also fine with the old format, which is why I'm glad
there's an option to put it back. I'm not personally interested in
reviving the old argument about whether the new format is better or
worse, as long as there's a simple way to restore the old behavior with
a config option.

side note: using quotes around the template screws things up, that is,
set message_id_format=""
vs
set message_id_format=

results in a broken message-id with the quotes inside the angle brackets
(Message-ID: <"xyz">)

if folks think that's a bug, I'm happy to file an issue about it, though
just not using the quotes worked fine.

/w

Re: Question about message id

[googly . negotiator862]

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?

Talk about bikeshedding :-)

-- 
Ian

Re: Question about message id

[Will Yardley]

On Tue, Apr 09, 2024 at 11:33:55AM -0400, Derek Martin wrote:
> On Tue, Apr 09, 2024 at 08:05:06AM -0700, Will Yardley wrote:
> > On Tue, Apr 09, 2024 at 10:53:41AM -0400, Derek Martin wrote:
> > > The unfathomable thing about this question is why you (or anyone)
> > > should care in the slightest what your message ID looks like.
> > 
> > That's totally true, but I still like the classic Mutt message-id
> > format.
> 
> Did you set your message ID format accordingly, then?  Because the
> message I'm replying to carries this:
> 
> Message-ID: <20240409150506.ga47...@aura.veggiechinese.net>
> 
> If so that feature may not be working correctly...

That is the old format for the mutt version I'm using. The new format
looks like



Thought you were on that long thread about this when it changed a while
back, but maybe remembering wrong.

w

Re: Question about message id

[Derek Martin]

On Tue, Apr 09, 2024 at 08:05:06AM -0700, Will Yardley wrote:
> On Tue, Apr 09, 2024 at 10:53:41AM -0400, Derek Martin wrote:
> > The unfathomable thing about this question is why you (or anyone)
> > should care in the slightest what your message ID looks like.
> 
> That's totally true, but I still like the classic Mutt message-id
> format.

Did you set your message ID format accordingly, then?  Because the
message I'm replying to carries this:

Message-ID: <20240409150506.ga47...@aura.veggiechinese.net>

If so that feature may not be working correctly...

> Maybe it's just nostalgia, but either way, I'm not super
> worried about leaking my PID etc...

Nor should you be--as I pointed out then, the PID is only of any use
to an attacker who is already on your system, which means either:

  1. Your system is already compromised, or
  2. They are a legitimate user on your system, in which case they can
 already easily get the pid of your mail client

In no way can a process ID be construed as sensitive.  If it were
you'd have to disable the ps command, modify the logging of virtually
every network daemon ever, and a whole bunch of other things.

> I think some people mentioned some minor threading issues with the new
> format?

Is that so?  I don't recall noticing anything about that... I'd love a
pointer to some details, if anyone has that.  Anyway, I said then, and
maintain now, that changing the format and making it configurable was
pointless and added complexity without good technical justification.
You may have just proven that. =8^)

-- 
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.



signature.asc
Description: PGP signature

Re: Question about message id

[Will Yardley]

On Tue, Apr 09, 2024 at 10:53:41AM -0400, Derek Martin wrote:
> The unfathomable thing about this question is why you (or anyone)
> should care in the slightest what your message ID looks like.

That's totally true, but I still like the classic Mutt message-id
format. Maybe it's just nostalgia, but either way, I'm not super
worried about leaking my PID etc... so I'm happy someone added the
feature to make it configurable.

I think some people mentioned some minor threading issues with the new
format?

w

Re: Question about message id

[Derek Martin]

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.

From a practical standpoint, the only thing that matters is that the
generator intelligently makes a genuine effort to ensure the generated
message ID is unique (and perhaps that it does not needlessly leak
sensitive details about the user, though no message ID format that I'm
aware of--including Mutt's original default format--ever did that,
emphasis on "sensitive").  You should be able to trust your mail
client to handle that detail on your behalf.  If for some reason you
can't, you should be using different e-mail software.

Truthfully, Mutt typically shouldn't even be in the business of
generating message IDs, where the expectation is that it will hand the
mail off to the MTA running on the user's system, which should
handle message ID generation, so that there is no possibility of
overlap.  [In practice this is unlikely to be a problem, because the
format Mutt uses is different from the major mail transfer agents. 
The probability of an overlap is therefore exceedingly low, and thus
uniqueness is maintained.]

Other than that, as long as replies and message threading work
properly in your mail client, don't even look at it--it is (or should
be) completely opaque to you.

-- 
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.



signature.asc
Description: PGP signature

Re: Question about message id

[Michael Kjörling]

On 9 Apr 2024 07:32 +1000, from c...@cskk.id.au (Cameron Simpson):
> You could (a) turn on "set edit_headers=yes" so the headers are visible in
> your message and (b) have your editor startup make one?

This is what I do in order to have a UUID message-ID, which Mutt
doesn't support natively.


> _Or_ you could "set sendmail=" to a script of your own to add a message-id
> header - that is what mutt uses to deliver the message to a mail system -
> you could add a header there then pass the message on to whatever you had
> mutt using before.

Wouldn't that at a minimum cause a discrepancy between the message-ID
of what is actually sent, and of what is stored in the Fcc?

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

Re: Question about message id

[Will Yardley]

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? 
> For example Message-Id: <43265...@example.com> consisting of random
> digits and domain name

There was a long debate about the message-id format that you could
probably dig up. For a long time, the Mutt ones were a date string
followed by an epoch timestamp.

The change in 2.0 was somewhat controversial. Note that this is now
configurable (which I hadn't known and / or had forgotten), so, assuming
you're using mutt >= 2.1, you can customize it if you'd like using this
config setting:

http://www.mutt.org/doc/manual/#message-id-format

[I'm testing it out myself on this response!]

w

Re: Question about message id

[Cameron Simpson]

On 07Apr2024 13:19, Ебрашка  wrote:

Question, what should I write in .muttrc to make my outgoing mails have
the same beautiful message-ID as Yandex mail?
For example Message-Id: <43265...@example.com> consisting of random
digits and domain name


I think it would be enough to supply your own message-id header; I don't 
think it is necessarily mutt making it at all. Mutt hands messages to a 
mail system, and a mail system adds a message-id if one is missing.


You could (a) turn on "set edit_headers=yes" so the headers are visible 
in your message and (b) have your editor startup make one?


_Or_ you could "set sendmail=" to a script of your own to add a 
message-id header - that is what mutt uses to deliver the message to a 
mail system - you could add a header there then pass the message on to 
whatever you had mutt using before.

--
Cameron Simpson  (formerly c...@zip.com.au)

Madness takes its toll.  Please have exact change.
- Janice Hanes 

Re: Question about message id

[Cameron Simpson]

On 07Apr2024 18:23, Anton Sharonov  wrote:

On Sun, Apr 07, 2024 at 09:23:07AM -0600, Charles Cazabon via Mutt-users wrote:
There's a good reason for that; it help to ensure uniqueness, which 
prevents

problems with threading.  By limiting itself to only digits, Yandex's IDs are
much more likely to collide.


Hm, not sure about that... Given that string is long enough,
random string which consists only out of digits can perhaps
compete with (much shorter) random string of alpha-numeric
characters - in terms of uniqueness probability?


It doesn't matter. The yandex people only need to ensure the uniqueness 
of the stuff left of the "@" (because they're the owners of the stuff on 
the right), and can do whatever is reliably unique for them.


Regardless, just using digits only means the string needs to be a bit 
longer.


Mutt uses more characters because it lets you make the message-id a 
shorter piece of text.

Re: Question about message id

[Michael Kjörling]

On 7 Apr 2024 18:23 +0200, from anton.sharo...@gmail.com (Anton Sharonov):
>>> For example Message-Id: <43265...@example.com> consisting of random
>>> digits and domain name
>> 
>> There's a good reason for that; it help to ensure uniqueness, which prevents
>> problems with threading.  By limiting itself to only digits, Yandex's IDs are
>> much more likely to collide.
> 
> Hm, not sure about that... Given that string is long enough,
> random string which consists only out of digits can perhaps
> compete with (much shorter) random string of alpha-numeric
> characters - in terms of uniqueness probability?

Sure; assuming a Base64 charset, each character encodes log_2(64) = 6
bits; for decimal digits, each character encodes log_2(10) ~ 3.3 bits.

Eight decimal digits encode only about 26 bits; eight Base64
characters encode 48 bits. (To encode 48 bits using only decimal
digits you need at least 15 digits.) So the decimal digits case has a
very much non-trivial chance of a random collision within a fixed
domain name in 8 characters, whereas the Base64 case is significantly
less likely to have collisions within the same number of characters;
in both cases assuming that the part before the @ is assigned at
random. Look up the "birthday paradox".

The value of the Message-ID header is required by RFC 5322 to be
unique. https://www.rfc-editor.org/rfc/rfc5322.html#section-3.6.4 That
has been the case since RFC 822 https://www.rfc-editor.org/rfc/rfc822
(section 4.6.1, page 23). RFC 5322 puts the uniqueness of the message
ID as a "MUST" level requirement, even going so far as to state that
_twice_ within two consecutive sentences. _How you guarantee that
uniqueness_ is up to you, but not following that requirement _is_
going to cause a variety of issues, quite possibly up to and including
messages not being delivered properly. Violate that requirement at
your own peril.

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

Re: Question about message id

[Anton Sharonov]

On Sun, Apr 07, 2024 at 09:23:07AM -0600, Charles Cazabon via Mutt-users wrote:
> Ебрашка  wrote:
> > my mails have Message-ID: .  Question, what
> > should I write in .muttrc to make my outgoing mails have the same beautiful
> > message-ID as Yandex mail? 
> 
> My first question would be, why do you care what the Message-ID: field
> contents look like?  Virtually no-one will ever look at it.

Yes, this here is fully true )))

> 
> > For example Message-Id: <43265...@example.com> consisting of random
> > digits and domain name
> 
> There's a good reason for that; it help to ensure uniqueness, which prevents
> problems with threading.  By limiting itself to only digits, Yandex's IDs are
> much more likely to collide.

Hm, not sure about that... Given that string is long enough,
random string which consists only out of digits can perhaps
compete with (much shorter) random string of alpha-numeric
characters - in terms of uniqueness probability?

> 
> If you absolutely must do this, have a look at the `message_id_format`
> variable.

Good hint ))) Attached is the example (perl) script, which can be used
as:

set message_id_format = "$HOME/bin/mutt_message_id_format_filter '<%z@%f>'|"

This converts "left_part" provided by Mutt %z part of Message-ID
code (ZhJUjJRaE9InvXxm in your example above), into (much longer)
string of only digits (592493855977705398853375435077558962105453
for same example).

String of digits is 1:1 mapping of each byte code of every next
symbol in the source string, used in the triples with some
padding by spaces. Every tripple generates decimal number. All
numbers are put after each other into long result.

Code is certainly ugly but seems to work.

Cheers, Anton
#!/usr/bin/perl -w
use 5.010;
use strict;
my $val = $ARGV[0];

my $debug = 0;

if (! ($val =~ m/^<([^@]+)@([^>]+)>/)) {
print $val; # message format is not recognized
exit 0;
}

my $logfile = undef;
if ($debug) {
my $log_fname = "/tmp/mutt_message_id_format_filter.log";
open ($logfile, ">>", $log_fname)
or die ("Cannot open [$log_fname] for write: $!");
}

my $left_part = $1;
my $host_n_domain = $2;

#abc
print $logfile "left_part = $left_part; host_n_domain = $host_n_domain\n"
if ($debug);

my $new_left_part = "";
while (length($left_part)) {
# extract 3 symbols, pad with blanks
my $bytes = sprintf("%3.3s", substr($left_part, 0, 3));
my $len = length($left_part);
$left_part = substr($left_part, $len >= 3 ? 3 : $len);
print $logfile " bytes = {" . $bytes . "}" if ($debug);
my $num = 0;
for my $i (0..2) {
$num *= 256;
$num += ord(substr($bytes, $i, 1));
}
print $logfile " num = {" . $num . "}\n" if ($debug);
$new_left_part .= $num;
}

print $logfile "\n" if ($debug);
print $logfile "<$new_left_part@" . $host_n_domain . ">" if ($debug);
print "<$new_left_part@" . $host_n_domain . ">";
print $logfile "\n" if ($debug);

Re: Question about message id

[Charles Cazabon via Mutt-users]

Ебрашка  wrote:
> my mails have Message-ID: .  Question, what
> should I write in .muttrc to make my outgoing mails have the same beautiful
> message-ID as Yandex mail? 

My first question would be, why do you care what the Message-ID: field
contents look like?  Virtually no-one will ever look at it.

> For example Message-Id: <43265...@example.com> consisting of random
> digits and domain name

There's a good reason for that; it help to ensure uniqueness, which prevents
problems with threading.  By limiting itself to only digits, Yandex's IDs are
much more likely to collide.

If you absolutely must do this, have a look at the `message_id_format`
variable.

Charles
-- 
---
Charles Cazabon
GPL'ed software available at:   http://pyropus.ca/software/
---

Question about message id

[Ебрашка]

Message-Id: <254061712447...@mail.yandex.ru> - this is how Message-Id
looks like when I receive an e-mail sent from Yandex mail web interface.
When I send a mail via mutt with activated option set hostname =
example.com, my mails have Message-ID: .
Question, what should I write in .muttrc to make my outgoing mails have
the same beautiful message-ID as Yandex mail? 
For example Message-Id: <43265...@example.com> consisting of random
digits and domain name

Re: pretty-print mutt emails

[Matthias Apitz]

I do use on FreeBSD muttprint:

Name   : muttprint
Version: 0.73_5
Installed on   : Sun Sep 24 11:32:52 2023 CEST
Origin : print/muttprint
Architecture   : FreeBSD:14:amd64
Prefix : /usr/local
Categories : print mail
Licenses   : GPLv2
Maintainer : g...@unixarea.de
WWW: http://muttprint.sourceforge.net/
Comment: Utility to print mail for most any mail client

Started from ~/.muttrc as:

$ grep muttprint .muttrc
set print_cmd="muttprint --printer pdf --paper A4 --rem_sig "

The result is nice and attached.

matthias

-- 
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

I am not at war with Russia.
Я не воюю с Россией.
Ich bin nicht im Krieg mit Russland.

Re: pretty-print mutt emails

[Günther Noack]

Hello!

On Wed, Nov 24, 2021 at 05:21:10PM +, Jean Louis wrote:
> * Anders Damsgaard  [2021-11-22 12:05]:
> > * Globe Trotter via Mutt-users  [2021-11-22 00:47:10 
> > +]:
> > > What is the recommended way to pretty-print mutt emails? I found a 
> > > sourceforge perl script called muttprint but that was last updated in 
> > > 2008, and I was wondering what folks here recommended?
> > 
> > I use the following sh(1) script to format the message as troff and
> > convert to pdf: https://adamsgaard.dk/tmp/muttprint-groff.sh
> > 
> > It's a bit ugly in places, but it works for me.  This is an example:
> > https://adamsgaard.dk/tmp/muttprint-example.pdf
> > 
> > I bind it in my muttrc with the following:
> > 
> > set print_command="$HOME/.config/mutt/muttprint-groff.sh"
> 
> Very nice. I find it simple and good. I would like to have the header
> fields rather aligned to left side.
> 
> When using grep, I think `grep -m1' should be used to find the first
> match, as I wonder what would be the result if words like "From:" or
> "Date: " are found in the body of the email, not only in the header.
> 
> I also think I can convert your script to use Asciidoctor instead of
> groff, https://asciidoctor.org/ -- so I will work on it.

I created a Go program for that use case a while ago:

https://gnoack.github.io/mailprint/

I think I am the only user, but it works well for me.

It is mostly tuned for the e-mails from the Linux kernel mailing list,
so it'll print the mails as plain text, with syntax highlighting for
git patches.  It also has support for printing the senders' profile
pictures from a ~/.picons directory [1].

The website has installation instructions and a screenshot.

Under the hood, it is still a shell pipeline piping to groff.  You can
find some more technical background at [2].

–Günther

[1] https://kinzler.com/ftp/faces/
[2] https://blog.gnoack.org/post/mailprint-design/

Sixel profile pictures

[Günther Noack]

Hello Mutt users!

I am currently revamping my old "avatarlookup" tool [1] to work with
terminal sixel graphics [2], so that I can see the sender's profile
picture in the top right corner when viewing an email in mutt.

Previously, I used to use w3m's terminal image hack for that (drawing
over an X11 window, like in [3]), but now that I am using a Wayland
terminal, this is not a good option any more.

Using sixel graphics, the hack works similar, like this:

  message-hook . "set display_filter='/home/gnoack/bin/muttface'"

Unfortunately, the muttface shell script is quite a hack: It
immediately prints the exact input mail back, but then it starts a
subprocess in the background(!) which will after a delay(!) draw the
sender's face directly onto /dev/tty.

Drawbacks are:

  * It depends on timing, and that's unreliable.  The delay is needed
so that it draws over mutt's own rendering of the email.

  * Mutt is unaware of the profile picture and scrolling the mail will
usually render on top of it, sometimes resulting in ugly
artifacts.

Is there a better way to hook into mutt for this use case?

Would it be reasonable to make this a mutt feature? :)
That way, mutt could redraw the picture when needed,
without destroying the layout.

Thanks,
–Günther

[1] https://github.com/gnoack/avatarlookup
[2] https://www.arewesixelyet.com/
[3] https://www.df7cb.de/projects/mutt/x-face/

Re: Mutt showing ? in place of space

[Derek Martin]

On Sat, Mar 30, 2024 at 11:21:21AM -0700, googly.negotiator...@aceecat.org 
wrote:
> ...this type of issue is really tricky because one has to be sure to
> *build* against the packaged (i.e. non-base) libraries, including
> cases like libncurses. IIRC this is far from automatic, some packages
> as shipped link with the base ncurses. One has to inspect the package
> build.

Yeah.  Getting this right is so ridiculously complex that even
remembering all the things that you might need to check is genuinely
challenging.  This is why we really need a detailed FAQ that addresses
all the things.  I've sat down to write one several times, but I
always get interrupted by something that seems to matter more at the
time, so it hasn't happened.  -_-


-- 
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.



signature.asc
Description: PGP signature

Re: Mutt showing ? in place of space

[googly . negotiator862]

On Sat, Mar 30, 2024 at 09:21:53AM -0400, Derek Martin wrote:

> > "Programs in the OpenBSD base system ignore the locale except for
> > the character encoding..."

> Mutt is not part of the "base system" so the limitation on locale
> should not apply to it, and "except for the character encoding"
> absolutely SHOULD apply, since that is specifically what is at issue
> in your case.

In my various attempts to try and learn more about the *BSDs, which
happen periodically when the sky seems to be falling on Linux, I found
that this type of issue is really tricky because one has to be sure to
*build* against the packaged (i.e. non-base) libraries, including
cases like libncurses. IIRC this is far from automatic, some packages
as shipped link with the base ncurses. One has to inspect the package
build.

The same is true for homebrew and linuxbrew.

-- 
Ian

Re: Mutt showing ? in place of space

[Sadeep Madurange]

Hello Derek,

On 2024-03-30 09:21:53, Derek Martin wrote:
> However I would point out that your own post said that you had left
> LANG unset.  Did you try setting LANG (and unsetting all the other
> environment variables, and Mutt's charset variable) as I suggested?
> Did you then also look at the output of the locale command to ensure
> that the settings were correct, as expected based on that setting?
> I'd love to see that output, to confirm or refute whether your system
> is correctly honoring LANG, as its man page seems to say it should...
> And then once you confirmed that locale was correct, did you then try
> Mutt?

I did. However, I set the LANG variable in .profile and .kshrc files,
which I think was the problem. Because, LANG (and the rest) wasn't
updated when in the new session.

> In either case--whether you set only LANG or only LC_CTYPE--you should
> not then need to set Mutt's character set, because it should get it
> from LC_CTYPE (directly or indirectly through inheritance from LANG).

You are right. Setting the charset in muttrc is not necessary.

Basically, you were right on all counts. All I needed was to just set
the LANG variable correctly in .xsession. Now it's working and my locale
is:

LANG=en_US.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_ALL=

> If OpenBSD can't handle this, then perhaps that would make at least
> part of an argument for why end users shouldn't use it as their
> desktop OS...

It was just me all along. OpenBSD is a fantastic desktop OS :) Thank you
for your kind assistance.

-- 
Sadeep Madurange
PGP: 103BF9E3E750BF7E

Re: Mutt showing ? in place of space

[Derek Martin]

Sandeep,

On Sat, Mar 30, 2024 at 10:21:30AM +0800, Sadeep Madurange wrote:
> On 2024-03-29 16:47:22, Derek Martin wrote:
> > [*] Except in extremely rare and completely esoteric cases that apply
> > only to experts... and by now should really apply to no one.
> 
> Thank you for patiently explaining. That was very educational. This is
> what I used to do on Linux in the past, though, without knowing why.
> 
> Unfortunately, this doesn't seem to work on OpenBSD. So, perhaps this
> qualifies as one of the esoteric cases. OpenBSD doesn't seem to pay much
> attention to the LANG variable. Thw following is an excerpt from the
> locale man page:

I don't have an OpenBSD system to test on, so I can't investigate
further, but I wouldn't think so, because:

> "Programs in the OpenBSD base system ignore the locale except for the
> character encoding..."

Mutt is not part of the "base system" so the limitation on locale
should not apply to it, and "except for the character encoding"
absolutely SHOULD apply, since that is specifically what is at issue
in your case.

Reading the rest of the man page, I find some of the additional
details should be applicable to your case as well:

"If the value of LC_CTYPE ends in ‘.UTF-8’, programs in the
OpenBSD base system ignore the beginning of it, treating for
example zh_CN.UTF-8 exactly like en_US.UTF-8. Programs from
packages(7) may however make a difference."

Shocking antiquation aside, this certainly seems to suggest that the
guts of what is necessary for Mutt to have what it needs for the
locale to work correctly do exist on the system.  And the behavior
they describe isn't really all that different from what normally
happens on modern systems with full locale support--the point of
Unicode is that every language's character sets are available
simultaneously, so from a charset perspective the actual language
doesn't matter.  The main difference here appears to be that their
base system only has English translations, so it ignores other aspects
of LANG.

And then this:

"LANG   Fallback if any of the above is unset."

This matches the behavior I explained already in my previous post...
At least according to their man page, everything I described SHOULD
work.  In other words, according to their own man page, if you set
LANG and leave the other variables unset, this should be exactly
equivalent to setting LC_CTYPE for any library functions which honor
that variable, i.e. ALL of the functions which Mutt uses to control
that behavior.  

Separately, though not apparently related to any concerns you have,
Mutt's translations are provided by Mutt--not the base system--so even
that should work correctly if your locale is set properly.  That said,
setting only LC_CTYPE is fine, if you only care about using Unicode as
your character set, and don't want the other behaviors related to e.g.
date & time, money display, etc. to match whatever differences exist
in a UTF-8 environment (in my experience with en_US.UTF-8 the only
difference is default sort order, typically observable in the output
of the ls command, and controlled specifically by LC_COLLATE).

However I would point out that your own post said that you had left
LANG unset.  Did you try setting LANG (and unsetting all the other
environment variables, and Mutt's charset variable) as I suggested?  
Did you then also look at the output of the locale command to ensure
that the settings were correct, as expected based on that setting?
I'd love to see that output, to confirm or refute whether your system
is correctly honoring LANG, as its man page seems to say it should...
And then once you confirmed that locale was correct, did you then try
Mutt?

In either case--whether you set only LANG or only LC_CTYPE--you should
not then need to set Mutt's character set, because it should get it
from LC_CTYPE (directly or indirectly through inheritance from LANG).

All of this behavior that I've described is part of the POSIX
standard, and has been for quite literally decades.  If OpenBSD can't
handle this, then perhaps that would make at least part of an argument
for why end users shouldn't use it as their desktop OS...

-- 
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.



signature.asc
Description: PGP signature

Re: Mutt showing ? in place of space

[Sadeep Madurange]

Hello Derek,

On 2024-03-29 16:47:22, Derek Martin wrote:
> On Sat, Mar 23, 2024 at 07:41:45PM +0800, Sadeep Madurange wrote:
> > Initially, LANG was unset and LC_CTYPE="C". The character encoding
> > was US-ASCII. I changed these variables (i.e., LANG, LC_CTYPE and
> > locale settings) to en_US.UTF-8. Then the ? changed to ?. So, looks
> > like you are on to something. I will check this with OpenBSD
> > community as well.
> > 
> > In Xdefaults, I have set XTerm*utf-8 setting to true as well.
> 
> Your problem is that these settings are not consistent (and you still
> have this problem, because the "solution" proposed by Sirius is
> incorrect--even if it appears to have solved your issue).  By having
> LANG unset, you've told your shell (and therefore everything started
> by it) to use ASCII, but you've explicitly told xterm to use Unicode.
> That's wrong.
> 
> The TL;DR of this is:
> 
> 1. You should NEVER need to set Mutt's charset explicitly. [*]
> 2. Your shell, Mutt, and X should all inherit what they need from your
>LANG environment variable, assuming it is set properly for your
>system and environment (it definitely isn't in your case).
> 3. Setting Mutt's charset may appear to "work" but it's not the
>correct solution, because your shell and terminal settings are
>still inconsistent.  You'll have trouble with other things later if
>you don't fix this.
> 
> [*] Except in extremely rare and completely esoteric cases that apply
> only to experts... and by now should really apply to no one.

Thank you for patiently explaining. That was very educational. This is
what I used to do on Linux in the past, though, without knowing why.

Unfortunately, this doesn't seem to work on OpenBSD. So, perhaps this
qualifies as one of the esoteric cases. OpenBSD doesn't seem to pay much
attention to the LANG variable. Thw following is an excerpt from the
locale man page:

"Programs in the OpenBSD base system ignore the locale except for the
character encoding, and it is not recommended to use any of these
variables except that the following non-default setting is supported as
an option: 

export LC_CTYPE=en_US.UTF-8" [1]

[1] https://man.openbsd.org/locale.1

-- 
Sadeep Madurange
PGP: 103BF9E3E750BF7E

Re: Mutt showing ? in place of space

[Derek Martin]

On Fri, Mar 29, 2024 at 03:03:54PM -0700, Bob Crochelt wrote:
> Thank you Derek!
> Bob Crochelt

No problem, glad I could help.  I had to figure this stuff all out the
hard way 20 years ago, when I moved to Korea and suddently needed to
be able to type in both English and Korean...  I've been answering it
on this list ever since... seriously, see this post from 2006:

  https://marc.info/?l=mutt-users=114434601817142=2

Things were A LOT worse then--Unicode hadn't really been adopted very
much in 2004.  Some of the finer details of how (or rather where) to
set those settings keep changing (in part because young developers
can't leave well enough alone when a solution has been working for
literally decades), and most people don't need to futz with fonts
anymore since Unicode is the default everywhere now, and the modern
font rendering libraries handle all this automatically--but the basics
of the problem and its solution are still the same.

In another such post I commented that this topic comes up often enough
that it really ought to be a FAQ.  Some day I'll take the time to
collect the details in a bit better format and provide one...

-- 
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.


> On Fri, Mar 29, 2024, at 13:47, Derek Martin wrote:
> > On Sat, Mar 23, 2024 at 07:41:45PM +0800, Sadeep Madurange wrote:
> >> Initially, LANG was unset and LC_CTYPE="C". The character encoding was
> >> US-ASCII. I changed these variables (i.e., LANG, LC_CTYPE and locale
> >> settings) to en_US.UTF-8. Then the ? changed to ?. So, looks like you
> >> are on to something. I will check this with OpenBSD community as well.
> >> 
> >> In Xdefaults, I have set XTerm*utf-8 setting to true as well.
> >
> > Your problem is that these settings are not consistent (and you still
> > have this problem, because the "solution" proposed by Sirius is
> > incorrect--even if it appears to have solved your issue).  By having
> > LANG unset, you've told your shell (and therefore everything started
> > by it) to use ASCII, but you've explicitly told xterm to use Unicode.
> > That's wrong.
> >
> > The TL;DR of this is:
> >
> > 1. You should NEVER need to set Mutt's charset explicitly. [*]
> > 2. Your shell, Mutt, and X should all inherit what they need from your
> >LANG environment variable, assuming it is set properly for your
> >system and environment (it definitely isn't in your case).
> > 3. Setting Mutt's charset may appear to "work" but it's not the
> >correct solution, because your shell and terminal settings are
> >still inconsistent.  You'll have trouble with other things later if
> >you don't fix this.
> > 
> > [*] Except in extremely rare and completely esoteric cases that apply
> > only to experts... and by now should really apply to no one.
> >
> >
> > The unfortunately lengthy details:
> > --
> >
> > Displaying characters properly is actually tricky business on modern
> > computers, because of the legacy methods by which we tried to
> > accommodate different languages, and the (relatively) recent advent of
> > Unicode to unify that mess.  All of the following must be set
> > consistently:  Your shell, your terminal program (or your operating
> > system's console), your font, all of your application programs, and
> > when appropriate, the X window system.  If any of these are not
> > consistently set, you can, and eventually WILL, have trouble.  Most
> > modern systems have the concept of a default locale, which is
> > typically set for you at install time, and which every process you
> > start inherits, unless you configure your user environment
> > differently.
> >
> > Fortunately, there is a very simple mechanism by which this happens,
> > which is the LANG environment variable.  There are additional
> > ancillary environment variables which start with "LC_*" but you
> > usually should not have to set any of these, because they inherit
> > their value from LANG if they are not explicitly set.  When you run
> > the locale command, values enclosed in quotes are inherited from LANG,
> > and values NOT enclosed in quotes have been set explicitly:
> >
> > $ locale
> > LANG=en_US.UTF-8
> > LANGUAGE=
> > LC_CTYPE="en_US.UTF-8"
> > LC_NUMERIC="en_US.UTF-8"
> > LC_TIME="en_US.UTF-8"
> > LC_COLLATE=C
> > LC_MONETARY="en_US.UTF-8"
> > LC_MESSAGES="en_US.UTF-8"
> > LC_PAPER="en_US.UTF-8"
> > LC_NAME="en_US.UTF-8"
> > LC_ADDRESS="en_US.UTF-8"
> > LC_TELEPHONE="en_US.UTF-8"
> > LC_MEASUREMENT="en_US.UTF-8"
> > LC_IDENTIFICATION="en_US.UTF-8"
> > LC_ALL=
> >
> > Here you can see that I explicitly set LC_COLLATE=C.  The rest are
> > inherited from LANG.  Typically most users 

Re: Mutt showing ? in place of space

[Bob Crochelt]

Thank you Derek!
Bob Crochelt

On Fri, Mar 29, 2024, at 13:47, Derek Martin wrote:
> On Sat, Mar 23, 2024 at 07:41:45PM +0800, Sadeep Madurange wrote:
>> Initially, LANG was unset and LC_CTYPE="C". The character encoding was
>> US-ASCII. I changed these variables (i.e., LANG, LC_CTYPE and locale
>> settings) to en_US.UTF-8. Then the ? changed to ?. So, looks like you
>> are on to something. I will check this with OpenBSD community as well.
>> 
>> In Xdefaults, I have set XTerm*utf-8 setting to true as well.
>
> Your problem is that these settings are not consistent (and you still
> have this problem, because the "solution" proposed by Sirius is
> incorrect--even if it appears to have solved your issue).  By having
> LANG unset, you've told your shell (and therefore everything started
> by it) to use ASCII, but you've explicitly told xterm to use Unicode.
> That's wrong.
>
> The TL;DR of this is:
>
> 1. You should NEVER need to set Mutt's charset explicitly. [*]
> 2. Your shell, Mutt, and X should all inherit what they need from your
>LANG environment variable, assuming it is set properly for your
>system and environment (it definitely isn't in your case).
> 3. Setting Mutt's charset may appear to "work" but it's not the
>correct solution, because your shell and terminal settings are
>still inconsistent.  You'll have trouble with other things later if
>you don't fix this.
> 
> [*] Except in extremely rare and completely esoteric cases that apply
> only to experts... and by now should really apply to no one.
>
>
> The unfortunately lengthy details:
> --
>
> Displaying characters properly is actually tricky business on modern
> computers, because of the legacy methods by which we tried to
> accommodate different languages, and the (relatively) recent advent of
> Unicode to unify that mess.  All of the following must be set
> consistently:  Your shell, your terminal program (or your operating
> system's console), your font, all of your application programs, and
> when appropriate, the X window system.  If any of these are not
> consistently set, you can, and eventually WILL, have trouble.  Most
> modern systems have the concept of a default locale, which is
> typically set for you at install time, and which every process you
> start inherits, unless you configure your user environment
> differently.
>
> Fortunately, there is a very simple mechanism by which this happens,
> which is the LANG environment variable.  There are additional
> ancillary environment variables which start with "LC_*" but you
> usually should not have to set any of these, because they inherit
> their value from LANG if they are not explicitly set.  When you run
> the locale command, values enclosed in quotes are inherited from LANG,
> and values NOT enclosed in quotes have been set explicitly:
>
> $ locale
> LANG=en_US.UTF-8
> LANGUAGE=
> LC_CTYPE="en_US.UTF-8"
> LC_NUMERIC="en_US.UTF-8"
> LC_TIME="en_US.UTF-8"
> LC_COLLATE=C
> LC_MONETARY="en_US.UTF-8"
> LC_MESSAGES="en_US.UTF-8"
> LC_PAPER="en_US.UTF-8"
> LC_NAME="en_US.UTF-8"
> LC_ADDRESS="en_US.UTF-8"
> LC_TELEPHONE="en_US.UTF-8"
> LC_MEASUREMENT="en_US.UTF-8"
> LC_IDENTIFICATION="en_US.UTF-8"
> LC_ALL=
>
> Here you can see that I explicitly set LC_COLLATE=C.  The rest are
> inherited from LANG.  Typically most users will want to leave all of
> the LC_* variables unset, and inherit from LANG.
>
> I haven't tried a *BSD in a really long while, but if it doesn't ask
> you for your default locale during install, or if you made a mistake
> setting it up, then you should add the settings manually to your login
> shell environment.  If you're using UTF-8 (which you should be--by now
> every modern OS uses it by default), the value of LANG should reflect
> that.  Pretty much no one should be using ASCII anymore (i.e. LANG
> should NEVER be unset).  The most portable way to do that would be to
> include the following in BOTH .profile and .kshrc (or whatever file
> you've set ENV to):
>
> LANG=en_US.UTF-8
> export LANG
>
> [See the Invocation section of the ksh man page for exact details of
> which files you should put this in, but in general it's the ones I
> said.]
>
> Of course if you are not using English, change en_US to whatever your
> default language is, but you'll want to retain the ".UTF-8" portion.
>
> That *should* be sufficient to handle everything... however, there may
> be additional places you'll need to add it for your X applications,
> depending on exactly what OpenBSD does to initialize users' X
> sessions.  In general, the X startup stuff is supposed to make sure
> that it sources the user's environment so that you don't need to
> figure out which of the 17 different files you actually need to put
> this stuff in... but over the years most vendors have bastardized how
> X sessions start 

Re: Mutt showing ? in place of space

[Derek Martin]

On Sat, Mar 23, 2024 at 07:41:45PM +0800, Sadeep Madurange wrote:
> Initially, LANG was unset and LC_CTYPE="C". The character encoding was
> US-ASCII. I changed these variables (i.e., LANG, LC_CTYPE and locale
> settings) to en_US.UTF-8. Then the ? changed to ?. So, looks like you
> are on to something. I will check this with OpenBSD community as well.
> 
> In Xdefaults, I have set XTerm*utf-8 setting to true as well.

Your problem is that these settings are not consistent (and you still
have this problem, because the "solution" proposed by Sirius is
incorrect--even if it appears to have solved your issue).  By having
LANG unset, you've told your shell (and therefore everything started
by it) to use ASCII, but you've explicitly told xterm to use Unicode.
That's wrong.

The TL;DR of this is:

1. You should NEVER need to set Mutt's charset explicitly. [*]
2. Your shell, Mutt, and X should all inherit what they need from your
   LANG environment variable, assuming it is set properly for your
   system and environment (it definitely isn't in your case).
3. Setting Mutt's charset may appear to "work" but it's not the
   correct solution, because your shell and terminal settings are
   still inconsistent.  You'll have trouble with other things later if
   you don't fix this.

[*] Except in extremely rare and completely esoteric cases that apply
only to experts... and by now should really apply to no one.


The unfortunately lengthy details:
--

Displaying characters properly is actually tricky business on modern
computers, because of the legacy methods by which we tried to
accommodate different languages, and the (relatively) recent advent of
Unicode to unify that mess.  All of the following must be set
consistently:  Your shell, your terminal program (or your operating
system's console), your font, all of your application programs, and
when appropriate, the X window system.  If any of these are not
consistently set, you can, and eventually WILL, have trouble.  Most
modern systems have the concept of a default locale, which is
typically set for you at install time, and which every process you
start inherits, unless you configure your user environment
differently.

Fortunately, there is a very simple mechanism by which this happens,
which is the LANG environment variable.  There are additional
ancillary environment variables which start with "LC_*" but you
usually should not have to set any of these, because they inherit
their value from LANG if they are not explicitly set.  When you run
the locale command, values enclosed in quotes are inherited from LANG,
and values NOT enclosed in quotes have been set explicitly:

$ locale
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE=C
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

Here you can see that I explicitly set LC_COLLATE=C.  The rest are
inherited from LANG.  Typically most users will want to leave all of
the LC_* variables unset, and inherit from LANG.

I haven't tried a *BSD in a really long while, but if it doesn't ask
you for your default locale during install, or if you made a mistake
setting it up, then you should add the settings manually to your login
shell environment.  If you're using UTF-8 (which you should be--by now
every modern OS uses it by default), the value of LANG should reflect
that.  Pretty much no one should be using ASCII anymore (i.e. LANG
should NEVER be unset).  The most portable way to do that would be to
include the following in BOTH .profile and .kshrc (or whatever file
you've set ENV to):

LANG=en_US.UTF-8
export LANG

[See the Invocation section of the ksh man page for exact details of
which files you should put this in, but in general it's the ones I
said.]

Of course if you are not using English, change en_US to whatever your
default language is, but you'll want to retain the ".UTF-8" portion.

That *should* be sufficient to handle everything... however, there may
be additional places you'll need to add it for your X applications,
depending on exactly what OpenBSD does to initialize users' X
sessions.  In general, the X startup stuff is supposed to make sure
that it sources the user's environment so that you don't need to
figure out which of the 17 different files you actually need to put
this stuff in... but over the years most vendors have bastardized how
X sessions start up, so you may have to look up or trace out how your
system does it to make sure everything works correctly.  So you might
have to also add it to .xinitrc or .xsession or similar.  Or, if it
does not already, you could simply have your X init thingy source your

Re: Mutt showing ? in place of space

[Sadeep Madurange]

On 2024-03-23 12:52:40, Sirius Rayner-Karlsson via Mutt-users wrote:
> In days of yore (Sat, 23 Mar 2024), Sadeep Madurange thus quoth: 
> > On 2024-03-23 11:10:11, Sirius via Mutt-users wrote:
> > > In days of yore (Sat, 23 Mar 2024), Sadeep Madurange thus quoth: 
> > > > When I view the following email in mutt, I see a bunch of
> > > > question marks where the spaces are. I checked the codepoints
> > > > and they all seem to be the normal space (0x20) character in the
> > > > ASCII table.
> 
> For reference, in my Debian Bookworm, I have the following:
> 
> sirius?~?$?locale
> LANG=sv_SE.UTF8
> LANGUAGE=
> LC_CTYPE="sv_SE.UTF8"
> LC_NUMERIC="sv_SE.UTF8"
> LC_TIME="sv_SE.UTF8"
> LC_COLLATE="sv_SE.UTF8"
> LC_MONETARY="sv_SE.UTF8"
> LC_MESSAGES="sv_SE.UTF8"
> LC_PAPER="sv_SE.UTF8"
> LC_NAME="sv_SE.UTF8"
> LC_ADDRESS="sv_SE.UTF8"
> LC_TELEPHONE="sv_SE.UTF8"
> LC_MEASUREMENT="sv_SE.UTF8"
> LC_IDENTIFICATION="sv_SE.UTF8"
> LC_ALL=
> 
> It may be that you just need to pop in the "set charset="utf-8"" in
> your mutt config and you are good to go.

Thanks for sharing your config. You're right. I needed to add "set
charset=utf-8" to muttrc and set LC_CTYPE. The problem was I had set the
latter in my .kshrc when I needed to set it in .xsession. It's all good
now.

> > Unlikely to be a problem with the font. I'm using DejaVu Sans Mono,
> > which I used on Linux in the past without any problem.
> 
> That should be a good font. If you are in the market for some other
> good fonts, take a look at Monafont.

Thanks for the tip. Always appreciate those :) It looks nice. I will
give it a go.

-- 
Sadeep Madurange
PGP: 103BF9E3E750BF7E

Re: Mutt showing ? in place of space

[Sirius Rayner-Karlsson via Mutt-users]

In days of yore (Sat, 23 Mar 2024), Sadeep Madurange thus quoth: 
> On 2024-03-23 11:10:11, Sirius via Mutt-users wrote:
> > In days of yore (Sat, 23 Mar 2024), Sadeep Madurange thus quoth: 
> > > When I view the following email in mutt, I see a bunch of question marks
> > > where the spaces are. I checked the codepoints and they all seem to be
> > > the normal space (0x20) character in the ASCII table.
> > 
> > My initial guess is that this is not a mutt problem but rather a display
> > problem related to your environment. What does your LANG and LC variables
> > look like and what are your locale settings? If at all possible, run with
> > UTF-8.
> 
> Initially, LANG was unset and LC_CTYPE="C". The character encoding was
> US-ASCII. I changed these variables (i.e., LANG, LC_CTYPE and locale
> settings) to en_US.UTF-8. Then the ? changed to �. So, looks like you
> are on to something. I will check this with OpenBSD community as well.

For reference, in my Debian Bookworm, I have the following:

sirius�~�$�locale
LANG=sv_SE.UTF8
LANGUAGE=
LC_CTYPE="sv_SE.UTF8"
LC_NUMERIC="sv_SE.UTF8"
LC_TIME="sv_SE.UTF8"
LC_COLLATE="sv_SE.UTF8"
LC_MONETARY="sv_SE.UTF8"
LC_MESSAGES="sv_SE.UTF8"
LC_PAPER="sv_SE.UTF8"
LC_NAME="sv_SE.UTF8"
LC_ADDRESS="sv_SE.UTF8"
LC_TELEPHONE="sv_SE.UTF8"
LC_MEASUREMENT="sv_SE.UTF8"
LC_IDENTIFICATION="sv_SE.UTF8"
LC_ALL=

I run this in a WSL on Win11, but have this config replicated across
Fedora, RHEL and Debian VMs and physical systems. In my .mutt/muttrc, I
have the following set:

set ascii_chars=yes
set assumed_charset="utf-8:iso-8859-1:us-ascii"
set charset="utf-8"
set config_charset="utf-8"

It may be that you just need to pop in the "set charset="utf-8"" in your
mutt config and you are good to go.

> In Xdefaults, I have set XTerm*utf-8 setting to true as well.
> 
> > It could also be related to the font used in Xterm, so worth trying
> > another font (preferably one that has a decent portion of the UTF-8
> > glyphs).
> 
> Unlikely to be a problem with the font. I'm using DejaVu Sans Mono,
> which I used on Linux in the past without any problem.

That should be a good font. If you are in the market for some other good
fonts, take a look at Monafont.

> -- 
> Sadeep Madurange
> PGP: 103BF9E3E750BF7E

-- 
Kind regards,

/S

Re: Mutt showing ? in place of space

[Sadeep Madurange]

On 2024-03-23 11:10:11, Sirius via Mutt-users wrote:
> In days of yore (Sat, 23 Mar 2024), Sadeep Madurange thus quoth: 
> > When I view the following email in mutt, I see a bunch of question marks
> > where the spaces are. I checked the codepoints and they all seem to be
> > the normal space (0x20) character in the ASCII table.
> 
> My initial guess is that this is not a mutt problem but rather a display
> problem related to your environment. What does your LANG and LC variables
> look like and what are your locale settings? If at all possible, run with
> UTF-8.

Initially, LANG was unset and LC_CTYPE="C". The character encoding was
US-ASCII. I changed these variables (i.e., LANG, LC_CTYPE and locale
settings) to en_US.UTF-8. Then the ? changed to ?. So, looks like you
are on to something. I will check this with OpenBSD community as well.

In Xdefaults, I have set XTerm*utf-8 setting to true as well.

> It could also be related to the font used in Xterm, so worth trying
> another font (preferably one that has a decent portion of the UTF-8
> glyphs).

Unlikely to be a problem with the font. I'm using DejaVu Sans Mono,
which I used on Linux in the past without any problem.

-- 
Sadeep Madurange
PGP: 103BF9E3E750BF7E

Re: Mutt showing ? in place of space

[Sirius via Mutt-users]

In days of yore (Sat, 23 Mar 2024), Sadeep Madurange thus quoth: 
> Hello,
> 
> When I view the following email in mutt, I see a bunch of question marks
> where the spaces are. I checked the codepoints and they all seem to be
> the normal space (0x20) character in the ASCII table.

My initial guess is that this is not a mutt problem but rather a display
problem related to your environment. What does your LANG and LC variables
look like and what are your locale settings? If at all possible, run with
UTF-8.
It could also be related to the font used in Xterm, so worth trying
another font (preferably one that has a decent portion of the UTF-8
glyphs).

> This happens fairly often. Usually with git patches or emails hat
> contain the output of commands like ifconfig that has indented blocks.
> 
> Any ideas? I'm using OpenBSD and Xterm.
> 
> - Forwarded message -
> 
> Index: 75.html
> ===
> RCS file: /cvs/www/75.html,v
> retrieving revision 1.10
> diff -u -p -r1.10 75.html
> --- 75.html 22 Mar 2024 11:08:09 -?? 1.10
> +++ 75.html 22 Mar 2024 15:22:40 -
> @@ -408,6 +408,7 @@ to 7.5.
>  JDK 8u402, 11.0.22, 17.0.10 and 21.0.2
>  KDE Applications 23.08.4
>  KDE Frameworks 5.115.0
> +?? KDE Plasma 5.27.10
>  Krita 5.2.2
>  LLVM/Clang 13.0.0, 16.0.6 and 17.0.6
>  LibreOffice 24.2.1.2
> 
> - End forwarded message -
> 
> -- 
> Sadeep Madurange
> PGP: 103BF9E3E750BF7E

-- 
Kind regards,

/S

Mutt showing ? in place of space

[Sadeep Madurange]

Hello,

When I view the following email in mutt, I see a bunch of question marks
where the spaces are. I checked the codepoints and they all seem to be
the normal space (0x20) character in the ASCII table.

This happens fairly often. Usually with git patches or emails hat
contain the output of commands like ifconfig that has indented blocks.

Any ideas? I'm using OpenBSD and Xterm.

- Forwarded message -

Index: 75.html
===
RCS file: /cvs/www/75.html,v
retrieving revision 1.10
diff -u -p -r1.10 75.html
--- 75.html 22 Mar 2024 11:08:09 -?? 1.10
+++ 75.html 22 Mar 2024 15:22:40 -
@@ -408,6 +408,7 @@ to 7.5.
 JDK 8u402, 11.0.22, 17.0.10 and 21.0.2
 KDE Applications 23.08.4
 KDE Frameworks 5.115.0
+?? KDE Plasma 5.27.10
 Krita 5.2.2
 LLVM/Clang 13.0.0, 16.0.6 and 17.0.6
 LibreOffice 24.2.1.2

- End forwarded message -

-- 
Sadeep Madurange
PGP: 103BF9E3E750BF7E

mutt 2.2.13 released

[Kevin J. McCarthy]

Hi Mutt Users,

I've just released version 2.2.13.  Instructions for downloading are available
at , or the tarball can be directly
downloaded from .  Please take the time to
verify the signature file against my public key[1].

This is a bug-fix release, fixing two issues with the SMTP client code
and $envelope_from_address.  The first is a possible dangling pointer
issue if $envelope_from_address is changed in an account-hook while
sending.  The second changes the SMTP client to respect
$use_envelope_from, as the sendmail client does.

Thanks to @mhepp63 for reporting the issue, with excellent details and
debugging information.

-Kevin

[1]
My public key is available at:
  - my personal website: https://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



signature.asc
Description: PGP signature

how to display the subscription status of imap folders?

[fi]

Dear Mutt Users

browsing folders of an IMAP server looks like this

 1   N IMAP  ../
 2 IMAP  first.
 3 IMAP +more.
 4 IMAP  xyz.
 5 IMAP +zzz.

one can toggle between all folders and only the subscribed ones using
with the toggle-subscribed command (usually bound to the key "T").

It would be useful to get an information of the subscription state of
a folder when all folders are shown. Then we can easily modify the
subscriotion using the keys "s" and "u".

Is there a way to modify the format of the IMAP browser list in order
to add the subscription status?

Hopefully I have not missed an obvious way to achieve this.

Any advice appretiated and best regards


T. Finke


-- 

T. Finke
f...@igh.de

Re: dynamic sig based off imap folder

[void]

Thank you both. I'll be trying this shortly :D

--

Re: Cascading directory display + Colourised folders after using "c" to indicate folders with mail newer than x hours

[Philip Rhoades via Mutt-users]

People,

I never received a response re the stuff below (so I presume it is not 
possible) - but the colourised folder idea also would be helpful to me . 
.


Thanks,

Phil.


On 2022-07-13 23:58, p...@pricom.com.au wrote:

People,

In my Maildir structure I have subfolders of subfolders eg they look 
like this:


/home/phr/Maildir
/home/phr/Maildir/.00
/home/phr/Maildir/.00.0
/home/phr/Maildir/.00.2045_ru
/home/phr/Maildir/.00.3dcontenth
/home/phr/Maildir/.00.3scale_net
/home/phr/Maildir/.00.4mation_co
/home/phr/Maildir/.00.ChurchOfPe
/home/phr/Maildir/.00.FreeWillsO
/home/phr/Maildir/.00.MeTA1_org
.
.

Is there a way to display like structure like this:

/home/phr/Maildir
+/home/phr/Maildir/.00

where clicking on the '+' can expand the subdirectories?

Thanks,

Phil.


--
Philip Rhoades

PO Box 896
Cowra  NSW  2794
Australia
E-mail:  p...@pricom.com.au

Re: dynamic sig based off imap folder

[Todd Zullinger]

Hi,

void wrote:
> I have various mailing list emails filtered on the server
> by the mail provider going into various imap folders, based
> on various properties of the email, like List-Id: for example.
> 
> What I'd like to have within mutt is for it to dynamically
> decide which signature file to use based on what imap
> folder the mail being replied to is in.
> 
> In the .muttrc there's for example a line like this:
> 
> mailboxes =mutt-users =test
> 
> In the manual, the nearest thing I can find to do what
> I'm describing is in "Example 3.8. Using MuttLisp expressions"
> but I'm unsure what expressions to use for an imap folder,
> how to test to see if mutt is in it.

A folder-hook will do this job nicely¹.  It is uner the
heading "Setting Variables Based Upon Mailbox" and described
as:

It is often desirable to change settings based on which
mailbox you are reading. The folder-hook command
provides a method by which you can execute any
configuration command. regexp is a regular expression
specifying in which mailboxes to execute command before
loading. If a mailbox matches multiple folder-hooks,
they are executed in the order given in the .muttrc. 

Here's an example for setting the signature:

folder-hook .   'set signature=~/.sigs/default'
folder-hook =mailbox-a  'set signature=~/.sigs/mailbox-a'

You set the first one as default so that after you change
from mailbox-a you aren't left with the signature you set
for that mailbox.

Often, you may have other variables to set based on the
folder/mailbox and rather than set them all you can use a
folder-hook to source a file which containsd them all, e.g.:

folder-hook .   'source ~/.mutt/profiles/default'
folder-hook =mailbox-a  'source ~/.mutt/profiles/mailbox-a'

¹ http://www.mutt.org/doc/manual/#folder-hook

HTH,

-- 
Todd


signature.asc
Description: PGP signature

Re: dynamic sig based off imap folder

[Michael Kjörling]

On 14 Jan 2024 15:47 +, from v...@f-m.fm (void):
> What I'd like to have within mutt is for it to dynamically
> decide which signature file to use based on what imap
> folder the mail being replied to is in.

You can use a set of folder-hook stanzas to set $signature.

For example:

folder-hook . 'set signature=~/.signature'
folder-hook =mutt-users 'set signature=~/.signatures/mutt-users'
folder-hook =somewhere/else 'set signature=~/.signatures/somewhere-else'

The "folder-hook ." should come first and establishes a default; the
others effectively set overrides for the default.

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

dynamic sig based off imap folder

[void]

Hi,

I have various mailing list emails filtered on the server
by the mail provider going into various imap folders, based
on various properties of the email, like List-Id: for example.

What I'd like to have within mutt is for it to dynamically
decide which signature file to use based on what imap
folder the mail being replied to is in.

In the .muttrc there's for example a line like this:

mailboxes =mutt-users =test

In the manual, the nearest thing I can find to do what
I'm describing is in "Example 3.8. Using MuttLisp expressions"
but I'm unsure what expressions to use for an imap folder,
how to test to see if mutt is in it.

thanks in advance for any assistance/pointers
--

Re: Threads based on a custom header

[Dan Ritter]

dm1...@gmail.com wrote: 
> Hi all,
> 
> Is it possible to display messages (preferably automatically, as soon
> as the messages get in the mailbox) as one thread based on a value of
> a custom header? That is, all the messages that have the X header with
> the same value.


If you have threading on, when you l_imit your view to messages
with that have that ~h eader, you will see them threaded
according to the normal algorithm, which is probably what you
want.

i.e. if your custom header is X-Foo:, you can use:

l~hX-Foo

and only see X-Foo mail. If you only want to see X-Foo: barbaz, then

l~hX-Foo: barbaz

is your friend.

Introducing new parameters into the threading algorithm is
likely to be... tricky.

If this were a major part of my workload, I would probably use
a sieve or other mailfilter to append the value of X-Foo to
Subject, then drop all the X-Foo messages into their own folder,
and possibly write an outbound filter (replacing sendmail) to
remove the value of X-Foo from the end of Subject.

-dsr-

Threads based on a custom header

[dm1...@gmail.com]

Hi all,

Is it possible to display messages (preferably automatically, as soon
as the messages get in the mailbox) as one thread based on a value of
a custom header? That is, all the messages that have the X header with
the same value.

Best,

--
Dmitry

Re: Forwarding a false positive classified message

[Michael Kjörling]

On 4 Jan 2024 18:42 +0800, from kai.we...@glorybox.de (Kai Weber):
> From time to time I have to report a falsly classified message to my
> mail provider so that they can adjust their filters. I am looking
> for a way to automate that:
> 
> 1. Forward selected mail as attachement to x...@foo.com
> 2. Set Subject to "reporting false positive -- [original subject]"
> 3. open editor with a prefilled message "Hello there, ..."
> 4. save message to my inbox
> 
> I am unsure how to achieve 1-3 with a macro. Is a macro the correct way to do 
> that?

You can set $editor to a script (it will be invoked with as its only
parameter the path to a file containing the message, including headers
if $edit_headers is set) which makes the adjustments you want and then
launches your normal editor or exits with an appropriate status.

formail is useful for reading and modifying mail headers from within a
script.

On another note, please don't use someone's real domain name (like
foo.com) as an example. It's better to use one of the domains reserved
for the purpose; for example, example.com or isp.example. You might
find https://michael.kjorling.se/internet-reserved-names-and-networks/
helpful.

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

Re: Forwarding a false positive classified message

[Todd Zullinger]

Hi,

Kai Weber wrote:
> From time to time I have to report a falsly classified
> message to my mail provider so that they can adjust their
> filters. I am looking for a way to automate that:
> 
> 1. Forward selected mail as attachement to x...@foo.com
> 2. Set Subject to "reporting false positive -- [original subject]"
> 3. open editor with a prefilled message "Hello there, ..."
> 4. save message to my inbox
> 
> I am unsure how to achieve 1-3 with a macro. Is a macro
> the correct way to do that?

I have one which reports missed spam messages.  It looks
roughly like this (edited a bit to remove unrelated parts
and wrap it -- hopefully I haven't broken the syntax in the
process):

macro index ,s "spam-rep...@example.com\
Missed spam\
" "Report missed spam"
macro pager ,s ",s" "Report missed spam"

You would want to replace `Missed spam` with
something like `reporting false positive -- []`.

You would not need `` for non-spam. ;)

I'm sure others here have better macros.  But this works
for me.  Hopefully this gives you some ideas for how to
create something which works for you.

-- 
Todd


signature.asc
Description: PGP signature

Forwarding a false positive classified message

[Kai Weber]

>From time to time I have to report a falsly classified message to my mail 
>provider so that they can adjust their filters. I am looking for a way to 
>automate that:

1. Forward selected mail as attachement to x...@foo.com
2. Set Subject to "reporting false positive -- [original subject]"
3. open editor with a prefilled message "Hello there, ..."
4. save message to my inbox

I am unsure how to achieve 1-3 with a macro. Is a macro the correct way to do 
that?

Re: IMAP && fetch size of message

[Andrew Marks]

You can limit to mail less than a certain size, or within a size range.
http://www.mutt.org/doc/manual/#patterns

~z [MIN]-[MAX]

You can make a macro which applies this limit.

You may also get creative with the header format to highlight mail that
is over a certain size.

I'm not sure about interrupting the download.

Good luck,
Andrew

On Fri, Dec 15, 2023 at 08:11:18AM -0500, Matthias Apitz wrote:
> 
> Hello,
> 
> I'm reading when not at home my mail directly with IMAP in mutt; mutt
> knows perfect the size of the mail (body) when presenting the Index
> page. When reading via datamobile I do not want to fetch mails with tons
> (Megabytes) of attachments. Sometimes I see the size but by accident I do
> start fetching such messages.
> 
> Questions:
> 
> How could I set a limit in mutt that it denies to tech messages with
> size over this limit?
> 
> How can I interrupt such fetch without killing mutt from another
> terminal?
> 
> Thanks
> 
>   matthias
> 
> -- 
> Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
> Public GnuPG key: http://www.unixarea.de/key.pub
> 
> I am not at war with Russia.
> Я не воюю с Россией.
> Ich bin nicht im Krieg mit Russland.

IMAP && fetch size of message

[Matthias Apitz]

Hello,

I'm reading when not at home my mail directly with IMAP in mutt; mutt
knows perfect the size of the mail (body) when presenting the Index
page. When reading via datamobile I do not want to fetch mails with tons
(Megabytes) of attachments. Sometimes I see the size but by accident I do
start fetching such messages.

Questions:

How could I set a limit in mutt that it denies to tech messages with
size over this limit?

How can I interrupt such fetch without killing mutt from another
terminal?

Thanks

matthias

-- 
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

I am not at war with Russia.
Я не воюю с Россией.
Ich bin nicht im Krieg mit Russland.

Re: Changing the behavior of quitting if a filter is applied?

[Cameron Simpson]

On 30Nov2023 07:09, Tim Chase  wrote:

For some reason, the way my brain works, when I have a filter in
place

 l myfilter

my lizard-brain wants to use "q" instead of

 l .

to turn off the filter.  The lizard-brain wins over the conscious
brain (that knows to use `l .`) about half the time.


Ugly suggestion: an "l" macro to invoke "" and rebind "q" to a 
macro which runs "." and unbinds "q"?


Cheers,
Cameron Simpson 

Changing the behavior of quitting if a filter is applied?

[Tim Chase]

For some reason, the way my brain works, when I have a filter in
place

  l myfilter

my lizard-brain wants to use "q" instead of

  l .

to turn off the filter.  The lizard-brain wins over the conscious
brain (that knows to use `l .`) about half the time.

mutt is fast enough that accidentally quitting is easy to (mostly)
remedy by just hitting control+p to recall the previous invocation
and hitting enter.  However, that loses my command/folder/search/pipe
histories.

Is there a way to make "q" behave selectively, depending on whether
a filter is in place, clearing the filter if so, and doing the
normal ask-yes quit behavior otherwise?

Alternatively, if there's a way to preserve those histories over
mutt invocations, that would ease some of the pain.

Thanks!

-tkc

Re: Pipe and replace message

[Jon LaBadie]

On Wed, Nov 22, 2023 at 08:12:17PM +0100, David Santinoli wrote:


Hallo,

I could not find a way to pipe a message to an external filter and have
the output replace the original message.  As a workaround I open the
message in vim, pipe the whole buffer to the filter, and save it back as
a new message while the original one gets marked for deletion.
It works but it's a bit cumbersome.  Anything more straightforward —
possibly from the index screen?

I'm using mutt 2.1.4 as included in Ubuntu 22.04.


Still doing the same thing, but perhaps reducing keystrokes to 2 total.

In your ~/.vimrc file, map a key sequence of your choice to do the work.
For example:

  map  !Gpr -t -d^M:wq^M  


Here I'm mapping my function key F3.  I sometimes use ",," or ",x" as
my mapped sequence.

Editing your message from the index positions the cursor on the first
blank line after the headers.  "!G" sends line to a filter.  The lines
are the current one to the end of the file.  If you want the headers
sent to the filter shift the cursor first.  Such as:

  map  1G!G...

My example filter "pr -t -d" merely double spaces the lines.  Replace
with a call to your filter.

The ^M (essentially ) is typed in as -V followed by the
 key.

The modified message is then saved and the editor exited with:

  :wq^M

The ^M typed as described above.

--
Jon H. LaBadie j...@labadie.us
 154 Milkweed Dr (540) 868-8052 (H)
 Lake Frederick, VA 22630(703) 935-6720 (M)

Re: Pipe and replace message

[Michael Kjörling]

On 22 Nov 2023 20:12 +0100, from da...@santinoli.com (David Santinoli):
> I could not find a way to pipe a message to an external filter and have
> the output replace the original message.

You can set $editor to any script you want and cause 
(or  or  as applicable) to be invoked. Make the
script put the replacement contents (including headers if those are
passed in) back in the named file when you're done, return success,
and you should get much the effect you're after.

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

Pipe and replace message

[David Santinoli]

Hallo,

I could not find a way to pipe a message to an external filter and have
the output replace the original message.  As a workaround I open the
message in vim, pipe the whole buffer to the filter, and save it back as
a new message while the original one gets marked for deletion.
It works but it's a bit cumbersome.  Anything more straightforward —
possibly from the index screen?

I'm using mutt 2.1.4 as included in Ubuntu 22.04.


Thanks,
 David

Re: Re: Profiles and mutt-notmuch

[Jan Eden via Mutt-users]

On 2023-10-29 14:17, Michael Kjörling wrote:

> On 29 Oct 2023 14:44 +0100, from mutt-users@mutt.org (Jan Eden via 
> Mutt-users):
> > for several years, I have used mutt with msmtp, and issues with sending
> > messages were usually returned to mutt and displayed as an error.
> > 
> > Recently, though, mutt displays "Mail sent" even when there is a problem
> > (and the mail is not sent). I always used a simple msmtp configuration,
> > and could not identify any major changes in the msmtp docs related to
> > exit codes.
> 
> What's your $sendmail_wait?

Thank you, that caused the problem! I experimented with msmtpq a while
ago and set sendmail_wait to -1. When returning the config files to
their previous state, I obviously forgot to remove that setting.

Thanks again!

- Jan


signature.asc
Description: PGP signature

Re: Profiles and mutt-notmuch

[Michael Kjörling]

On 29 Oct 2023 14:44 +0100, from mutt-users@mutt.org (Jan Eden via Mutt-users):
> for several years, I have used mutt with msmtp, and issues with sending
> messages were usually returned to mutt and displayed as an error.
> 
> Recently, though, mutt displays "Mail sent" even when there is a problem
> (and the mail is not sent). I always used a simple msmtp configuration,
> and could not identify any major changes in the msmtp docs related to
> exit codes.

What's your $sendmail_wait?

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”