multipart mails with HTML and PNG/JPEG
Hello,
I often get mails meant for graphical MUA which have parts in HTML and
files like PNG to be used when rendering the mail. The mutt 'v' command
shows (as an example) the parts like this:
v -->
I 1 [multipa/alternativ,
7bit, 14K]
I 2 |-> [text/plain, quoted,
utf-8, 1,9K]
I 3 `-> [multipa/related,
7bit, 12K]
I 4 |-> [text/html, quoted,
utf-8, 11K]
I 5 `-> [image/png,
base64, 0,8K]
The HTML file contains the source of the image in the form
"cid:qrcode-90866c7b-d03d-44fe-b963-d3bed6d08236":
...
At the reception you can use the QR-code for registration.
...
Is there a tool to produce on Linux/FreeBSD a PDF combining HTML +
image. Normally I store the HTML part and PNG part as files and fix the
HTML code to find the file.
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.
reading mails with IMAP w/o fetching attachments
Hello, I sometimes get mail with small ASCII/UTF-8 text and big attachments (JPEG, PDF, ...). Fetching the full mail over data mobile or poor WLAN access is ofc terrible slow. Is there a way to only read the text and decide then to fetch the attachments or not? 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: mutt && oauth2 config
El día Tuesday, June 04, 2024 a las 10:49:13AM +0200, Matthias Apitz escribió: > Produced the URL and loading this in a browser, triggered a request to > whomever and a mail to me from MS-Security with the following content: > > Thunderbird access request received > > Your request has been received. Details of your request are below. > Requested app:Thunderbird > Status: submitted > Request date: June 3, 2024 > Expiration date: July 3, 2024 > > We will see, how this will move now. The result came last Friday: Thunderbird access request denied Your request has been denied. Details of your request are below. Requested app: Thunderbird Status: denied Reason: Please use Outlook Review date:June 7, 2024 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: mutt && oauth2 config
El día martes, junio 04, 2024 a las 09:14:48 +0200, Peter van Ormondt escribió:
> On Mon, Jun 03, 2024 at 12:38:19PM +0200, Matthias Apitz wrote:
> >
> > +Cc: The author of thge page, Peter van Ormondt
> >
> > El día lunes, junio 03, 2024 a las 11:57:58 +0200, Matthias Apitz escribió:
> >
> > >
> > > Hello,
> > >
> > > The page about how to configure mutt with oauth2 support says:
> > >
> > > https://www.vanormondt.net/~peter/blog/2021-03-16-mutt-office365-mfa.html
> > > ...
> > >
> > > Edit the python script and insert your GPG identity in the
> > > "ENCRYPTION_PIPE" construct.
> > > Add client id ('08162f7c-0fd2-4200-a84a-f25a4db0b584') and
> > > client_secret ('TxRBilcHdC6WGBee]fs?QR:SJ8nI[g82'), as per these
> > > instructions, to the "microsoft" registrations.
> > >
> > > My gpg ID is DC4AA850 from the command below:
...
Peter, thanks for the feedback. Reading the Python script (I don't do
Python) I understood that the 1st question should be answered with
'microsoft'. There is another small pitfall: the client values:
'client_id': '08162f7c-0fd2-4200-a84a-f25a4db0b584',
'client_secret': 'TxRBilcHdC6WGBee]fs?QR:SJ8nI[g82',
must be added in the correct (2nd) place.
Running the script as
$ ./mutt_oauth2.py TOKEN_FILENAME --verbose --authorize
Produced the URL and loading this in a browser, triggered a request to
whomever and a mail to me from MS-Security with the following content:
Thunderbird access request received
Your request has been received. Details of your request are below.
Requested app: Thunderbird
Status: submitted
Request date: June 3, 2024
Expiration date:July 3, 2024
We will see, how this will move now.
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: mutt && oauth2 config
+Cc: The author of thge page, Peter van Ormondt
El día lunes, junio 03, 2024 a las 11:57:58 +0200, Matthias Apitz escribió:
>
> Hello,
>
> The page about how to configure mutt with oauth2 support says:
>
> https://www.vanormondt.net/~peter/blog/2021-03-16-mutt-office365-mfa.html
> ...
>
> Edit the python script and insert your GPG identity in the
> "ENCRYPTION_PIPE" construct.
> Add client id ('08162f7c-0fd2-4200-a84a-f25a4db0b584') and client_secret
> ('TxRBilcHdC6WGBee]fs?QR:SJ8nI[g82'), as per these instructions, to the
> "microsoft" registrations.
>
> My gpg ID is DC4AA850 from the command below:
>
> $ gpg --keyid-format short --fingerprint guru
> pub rsa4096/DC4AA850 2024-05-12 [SC]
> Key fingerprint = 895A 3082 6A0A 0269 0D38 5529 B84C 65D9 DC4A A850
> uid [ultimate] Matthias Apitz (OpenPGP card 2)
> sub rsa4096/237B4D65 2024-05-12 [A]
> sub rsa4096/981CBAF1 2024-05-12 [E]
>
> Should this be entered as 'DC4AA850' or as '0xDC4AA850' in the script
> mutt_oauth2.py
Additional question:
$ ./mutt_oauth2.py TOKEN_FILENAME --verbose --authorize
Available app and endpoint registrations: google microsoft
OAuth2 registration: xx
Preferred OAuth2 flow ("authcode" or "localhostauthcode" or "devicecode"):
...
Following the above page, the 2nd question should be answered with
localhostauthcode. What is the answer for the 1st question?
Is there a complete session example for the above script?
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.
mutt && oauth2 config
Hello,
The page about how to configure mutt with oauth2 support says:
https://www.vanormondt.net/~peter/blog/2021-03-16-mutt-office365-mfa.html
...
Edit the python script and insert your GPG identity in the
"ENCRYPTION_PIPE" construct.
Add client id ('08162f7c-0fd2-4200-a84a-f25a4db0b584') and client_secret
('TxRBilcHdC6WGBee]fs?QR:SJ8nI[g82'), as per these instructions, to the
"microsoft" registrations.
My gpg ID is DC4AA850 from the command below:
$ gpg --keyid-format short --fingerprint guru
pub rsa4096/DC4AA850 2024-05-12 [SC]
Key fingerprint = 895A 3082 6A0A 0269 0D38 5529 B84C 65D9 DC4A A850
uid [ultimate] Matthias Apitz (OpenPGP card 2)
sub rsa4096/237B4D65 2024-05-12 [A]
sub rsa4096/981CBAF1 2024-05-12 [E]
Should this be entered as 'DC4AA850' or as '0xDC4AA850' in the script
mutt_oauth2.py
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: sending automated GPG signed mails from batch job
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.
sending automated GPG signed mails from batch job
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
Re: pretty-print mutt emails
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: pretty-print mutt emails
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: pretty-print mutt emails
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: pretty-print mutt emails
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.
IMAP && fetch size of message
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: month September
El día domingo, septiembre 17, 2023 a las 11:12:23p. m. +0200, Francesco Ariis escribió: > `date_format` is passed to `strftime`. Mine is: > > date_format="!%a, %b %d, %Y at %I:%M:%S%p %Z" > # A bang should mean “C (US English) locale, > # but on mine it is still Italian. > > `date "+%b"` returns `set` here, what about on your machine? $ echo $LANG es_ES.UTF-8 $ date "+%b" sept. $ LANG=C date "+%b" Sep $ Thanks matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub Stoppt die Bundeswehr nicht erst vor Stalingrad! Schluss mit Waffenlieferungen an die Ukraine und Schluss mit der Aufrüstung! Stop the German Army already before Stalingrad! End the delivery of weapons to Ukraine!
month September
Why the actual month September is abbreviated with 4 letters in the index: 6 may. 28 Simsondoktor Mü (2,5K) Re: Defekte Schwalbe 7 jul. 05 Matthias Apitz (2,1K) buscando un libro: Las siete vidas de Tanja Nijmei 8 jul. 05 Mail Delivery S (4,6K) Rejected: buscando un libro: Las siete vidas de Ta 9 ago. 07 portal@elster.d (3,9K) Mein ELSTER: Anpassung der Speicherfrist bei besti 10 ago. 18 Dave Cramer (5,5K) Re: Looking for PostgreSQL Tuning Workshop Present 11 sept. 07 Matthias Apitz (1,2M) Re: Status Versicherungsverlauf / SFR 13 sept. 10 Matthias Apitz (3,5K) Fwd: Shipping Parity Investment Opportunity Thanks matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub Stoppt die Bundeswehr nicht erst vor Stalingrad! Schluss mit Waffenlieferungen an die Ukraine und Schluss mit der Aufrüstung! Stop the German Army already before Stalingrad! End the delivery of weapons to Ukraine!
Re: How to abort sending a mail?
El día lunes, junio 26, 2023 a las 03:11:25p. m. +0100, Chris Green escribió: > > I have sometimes the same issue using mutt on my Linux phone where the > > IP to my mobile carrier is not fully up. mutt sits there saying > > > > Connecting to imap.1blu.de > > > > and the only way is to kill the terminal app. > > > Doesn't the sendmail_wait setting address this issue? Or, if you're > using SMTP to send mail the connect_timeout setting. No. It is the initial IMAP connection to read the mail, not the sending connection w/ SMTP directly (i.e. w/o sendmail). matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub NATO must not win the war against Russia. Die NATO darf den Krieg gegen Russland nicht gewinnen!
Re: How to abort sending a mail?
El día lunes, junio 26, 2023 a las 12:55:08 +0200, Max Görner escribió: > Hello all, > > I have a Mutt window open which hangs at the "Connection to ... establishing"¹ > step. This happens very rarely but is quite annoying. In general, I am able to > send mails reliably and without issues. > > My only known option is to kill `mutt`, which I dislike. Is there a better way > to abort that process? > > Best, Max > > 1: Actually, it is "Verbindung zu subdomain.example.com wird aufgebaut …" but >the above translation should do the job. I have sometimes the same issue using mutt on my Linux phone where the IP to my mobile carrier is not fully up. mutt sits there saying Connecting to imap.1blu.de and the only way is to kill the terminal app. Thanks matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub NATO must not win the war against Russia. Die NATO darf den Krieg gegen Russland nicht gewinnen!
Re: IMAP to my company's server is failing
El día miércoles, enero 18, 2023 a las 01:41:16 -0800, Kevin J. McCarthy escribió: > On Wed, Jan 18, 2023 at 08:36:23PM +0100, Matthias Apitz wrote: > > Until today I could read (in my spare time) my company mails with mutt > > and IMAP. Since today it gives in the debug log: > > > > ... > > [2023-01-18 19:21:31] 4< * OK The Microsoft Exchange IMAP4 service is > > ready. > > [RgBSADMAUAAyADgAMQBDAEEAMAAyADAANAAuAEQARQBVAFAAMgA4ADEALgBQAFIATwBEAC4ATwBVAFQATABPAE8ASwAuAEMATwBNAA==] > > [2023-01-18 19:21:31] IMAP queue drained > > [2023-01-18 19:21:31] 4> a CAPABILITY^M > > [2023-01-18 19:21:31] 4< * CAPABILITY IMAP4 IMAP4rev1 AUTH=PLAIN > > AUTH=XOAUTH2 SASL-IR UIDPLUS ID UNSELECT CHILDREN IDLE NAMESPACE LITERAL+ > > [2023-01-18 19:21:31] Handling CAPABILITY > > [2023-01-18 19:21:31] 4< a OK CAPABILITY completed. > > [2023-01-18 19:21:31] IMAP queue drained > > [2023-01-18 19:21:31] imap_authenticate: Trying method login > > Is mutt compiled with any kind of SASL support? What does `mutt -v | > grep SASL` show? It gives: mutt -v | grep SASL -USE_SSL_OPENSSL +USE_SSL_GNUTLS +USE_SASL +USE_GSS +HAVE_GETADDRINFO > Do you have $imap_authenticators set to anything? > I have had: set imap_authenticators="login" but changing it to: set imap_authenticators=plain gives: [2023-01-19 06:59:55] Authenticating (PLAIN)... [2023-01-19 06:59:55] 4> a0001 AUTHENTICATE PLAIN YXBpdHptQG9jbGMub3JnAGFwaXR6bUBvY2xjLm9yZwBNb250ZXJvc3NvLTIwMjM=^M [2023-01-19 07:00:01] 4< a0001 NO AUTHENTICATE failed. [2023-01-19 07:00:01] IMAP queue drained [2023-01-19 07:00:01] imap_auth_sasl: plain failed [2023-01-19 07:00:01] No authenticators available Thanks for your help anyway matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
IMAP to my company's server is failing
Hello, Until today I could read (in my spare time) my company mails with mutt and IMAP. Since today it gives in the debug log: ... [2023-01-18 19:21:31] 4< * OK The Microsoft Exchange IMAP4 service is ready. [RgBSADMAUAAyADgAMQBDAEEAMAAyADAANAAuAEQARQBVAFAAMgA4ADEALgBQAFIATwBEAC4ATwBVAFQATABPAE8ASwAuAEMATwBNAA==] [2023-01-18 19:21:31] IMAP queue drained [2023-01-18 19:21:31] 4> a CAPABILITY^M [2023-01-18 19:21:31] 4< * CAPABILITY IMAP4 IMAP4rev1 AUTH=PLAIN AUTH=XOAUTH2 SASL-IR UIDPLUS ID UNSELECT CHILDREN IDLE NAMESPACE LITERAL+ [2023-01-18 19:21:31] Handling CAPABILITY [2023-01-18 19:21:31] 4< a OK CAPABILITY completed. [2023-01-18 19:21:31] IMAP queue drained [2023-01-18 19:21:31] imap_authenticate: Trying method login [2023-01-18 19:21:31] SASL local ip: 192.168.178.41;23775, remote ip:xxx.xxx.xxx.xxx;993 [2023-01-18 19:21:31] External SSF: 256 [2023-01-18 19:21:31] External authentication name: x...@xxx.org [2023-01-18 19:21:31] Entrando... [2023-01-18 19:21:31] 4> a0001 LOGIN "x...@xxx.org" "xxx-xxx"^M [2023-01-18 19:21:36] 4< a0001 NO LOGIN failed. ... The password is fine and works via OWA365 web access. Can I do something a part of not reading mails anymore in my spare time? Maybe I should not do that anyway. Thanks matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub Schluß mit dem (Wirtschafts-) Krieg gegen Rußland! Schluß mit den Sanktionen! Schluß mit der Unterstützung der faschistoiden Regierungskräfte in der Ukraine! Rußland ist nicht unser Feind, die Regierung der Kriegstreiber ist unser Feind! Druschba / Дружба mit Rußland statt NATO-Krieg gegen Rußland!
[ SOLVED ] Re: A bit off-topic: problems with sending to a Gmail user
El día sábado, marzo 12, 2022 a las 11:12:49a. m. +, Claus Assmann escribió: > On Fri, Mar 11, 2022, Stefan Hagen wrote: > > > > > 550-5.7.26 This message does not have authentication information or > > > > fails to > > > Authenticated in this context means, you don't have SPF / DKIM / DMARC set > > up. > > [more off-topic/rant] > Isn't it nice how Google et.al. enforce things which are > neither mandatory nor really useful to "fight spam"? > All the spam I get at $WORK is from gmail and it has passed > all of those "requirements" -- but the "investment"/"loan"/... > spam/scams are not filtered at all by Google themselves > (hey, why should they do outbound spam filtering? it cost them money > and why should they care? it's not like anyone important would block > gmail -- but Google rejects mail coming to them due to bogus reasons). > > "Solution": ask gmail users to switch to other services which do > not have so many "false positives". > > PS: maybe there is an option in gmail for users to whitelist senders > from whom they want to receive mail? As more and more of my mails, also to friends could not reach them @google.com, I studied the DNS record for SPF a bit and came up with this single line in my DNS: @ TXT v=spf1 ip4:178.254.4.101 include:unixare.de -all and all is fine now. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub Schluß mit dem (Wirtschafts-) Krieg gegen Rußland! Schluß mit den Sanktionen! Druschba / Дружба mit Rußland statt NATO-Krieg gegen Rußland!
Re: mutt, imaps and OAuth2
El día Donnerstag, August 04, 2022 a las 12:23:08 +, Sam Kuper escribió: > On Thu, Aug 04, 2022 at 12:14:04PM +0200, Matthias Apitz wrote: > > El día Donnerstag, August 04, 2022 a las 10:07:47 +, Sam Kuper escribió: > >> As a *temporary workaround*, maybe see if you can edit the > >> GMail/GoogleMail settings so that a copy of each incoming email is > >> forwarded to an email address you control that is hosted by a > >> standards-compliant (and therefore Mutt-friendly) email hosting > >> company. IIRC, the GMail settings interface has an option for this - > >> or failing that, you can create a catch-all "filter" with a rule to > >> forward the emails. > > > > Be prepared to run into troubles sending mails to GMail/GoogleMail. > > Google requires very special DNS configs to accept mails for their > > users. I gave up on this and do not send any mails to Google users > > anymore. > > I don't see how these remarks relate to my suggestion above? The relation is: once you have the enail downloaded from another hosting provider and you want reply upstream through it to GMail/GoogleMail recipients ... matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
Re: mutt, imaps and OAuth2
El día Donnerstag, August 04, 2022 a las 10:07:47 +, Sam Kuper escribió: > On Thu, Aug 04, 2022 at 09:40:03AM +0200, Sébastien Hinderer wrote: > > I am about to work for an organization whose e-mails are managed by > > Google. > > ... > As a *temporary workaround*, maybe see if you can edit the > GMail/GoogleMail settings so that a copy of each incoming email is > forwarded to an email address you control that is hosted by a > standards-compliant (and therefore Mutt-friendly) email hosting company. > IIRC, the GMail settings interface has an option for this - or failing > that, you can create a catch-all "filter" with a rule to forward the > emails. Be prepared to run into troubles sending mails to GMail/GoogleMail. Google requires very special DNS configs to accept mails for their users. I gave up on this and do not send any mails to Google users anymore. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
Re: A bit off-topic: problems with sending to a Gmail user
El día sábado, marzo 12, 2022 a las 10:05:35 +0100, Joerg Dorchain escribió: > Let's go through that: > > - An SPF-entry has to be created in the unixarea.de domain, I would assume > you can do that via the > interface of 1blu.de > > - DKIM-headers can be inserted locally. If you do that with a selector under > the unixarea.de domain, you > have to add the corresponding key in the zone. I would assume you can do > that via the interface of 1blu.de > Alternatively dkim can be implemented at the 1blu.de MTA, which in turn is > solely at their discretion. > > - Same for a DMARC-entry. > > This would make most sense when you enable DNSSEC for the unixarea.de domain. > Check here: > https://dnsviz.net/d/unixarea.de/dnssec/ I would assume you can do that via > the interface of 1blu.de. > Joerg, 1blu is a German ISP where I have rented: - a domain 'unixare.de' - a web space www.unixarea.de on some of its servers - a mail addr g...@unixarea.de which ends up in mbox on its servers and I can read mail with IMAP or some webmail software; and I can send mail with SMTP to one its MTA (smt.1blu.de) - SSH access to an unpriv account on the server to put/get files to/from the web space www.unixarea.de I have no access to any DNS configurations and so I do not see how to follow your hints. Thanks anyway matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
Re: A bit off-topic: problems with sending to a Gmail user
El día viernes, marzo 11, 2022 a las 03:12:41p. m. +0100, Stefan Hagen escribió: > > I've been seeing a lot of that lately. Google seem to have tightened > > their email security practice recently. > > > > It appears that 1blu is doing something that GMail doesn't like. They > > probably have a number of users who have the same problem. I would > > ask them to check their MTA configuration against the section "Make > > sure your messages are authenticated" in the referenced page > > (https://support.google.com/mail/answer/81126#authentication). > > > > > 550-5.7.26 This message does not have authentication information or > > > fails to > > > 550-5.7.26 pass authentication checks. To best protect our users from > > > spam, the > > > 550-5.7.26 message has been blocked. Please visit > > Authenticated in this context means, you don't have SPF / DKIM / DMARC set up. > > You can use this service: https://www.mail-tester.com to test your > setup. It provices you an email address. Send an email to it > and then your mail and server setup will be evaluated. Thank you, Stefan. I did such a test and the result can be seen here: https://www.mail-tester.com/test-ahwup3i9z > This is an example from me: > https://www.mail-tester.com/test-3ghr082f2 > > Feel free to examine it and set your host up in a similiar way. As far as I understand all the changes can't be done on my host (a laptop). I send mails with mutt and mutt with sendmail to smtp.1blu.de And I'm afraid, if I contact the support of 1blu I don't know if they will react (I've mixed experience from the past). I will give it a try... Thanks matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
A bit off-topic: problems with sending to a Gmail user
Hello, I know, it's not the fault of our beloved mutt, but maybe someone is or was in the same problem and knows a solution... We (my family) are member of a fisherman association and I have to send mails to one of the head members in charge for youth training. He has a Google mail account as and any mail gets rejected by Google with the response below. Any idea what I could do? Thanks in advance matthias - Forwarded message from Mail Delivery System - Date: Thu, 10 Mar 2022 18:48:05 +0100 From: Mail Delivery System To: g...@unixarea.de Subject: Mail delivery failed: returning message to sender This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: xxx@gmail.com host gmail-smtp-in.l.google.com [74.125.133.26] SMTP error from remote mail server after pipelined end of data: 550-5.7.26 This message does not have authentication information or fails to 550-5.7.26 pass authentication checks. To best protect our users from spam, the 550-5.7.26 message has been blocked. Please visit 550-5.7.26 https://support.google.com/mail/answer/81126#authentication for more 550 5.7.26 information. x6-20020a7bc20600b003826d797674si3455029wmi.29 - gsmtp Reporting-MTA: dns; ms-10.1blu.de Action: failed Final-Recipient: rfc822;xxx@gmail.com Status: 5.0.0 Remote-MTA: dns; gmail-smtp-in.l.google.com Diagnostic-Code: smtp; 550-5.7.26 This message does not have authentication information or fails to 550-5.7.26 pass authentication checks. To best protect our users from spam, the 550-5.7.26 message has been blocked. Please visit 550-5.7.26 https://support.google.com/mail/answer/81126#authentication for more 550 5.7.26 information. x6-20020a7bc20600b003826d797674si3455029wmi.29 - gsmtp Return-path: Received: from [188.174.56.186] (helo=fritz.box) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nSMtR-00015i-BW for xxx@gmail.com; Thu, 10 Mar 2022 18:48:05 +0100 Date: Thu, 10 Mar 2022 17:48:04 + From: Matthias Apitz Reply-To: Matthias Apitz To: xxx yyy Subject: Fwd: Re: Jugendfischen 2022 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: MIME-Version: 1.0 X-Con-Id: 51246 X-Con-U: 0-guru - End forwarded message - -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
Re: accommodating "possible special characters" in password?
If your mutt is compiled with DEBUG you could use the option '-d5' and will have in the file ~/.muttdebug0 the string it is using as IMAP password. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub August 13, 1961: Better a wall than a war. And, while the GDR was still existing, no German troups and bombs have been killed in Yugoslavia, Afghanistan, Afrika...
Re: accommodating "possible special characters" in password?
El día miércoles, diciembre 15, 2021 a las 08:25:46a. m. -0600, mai...@email.com escribió: > Hello, > > So, I have this recipe set up for one of my accounts for sending email, and > it must be using a special character in the password because Mutt fails (says > something about SASL authentication failed). The same setup with a different > account but same mail service, etc, works just fine. Indeed, the first > account, when I do not specify the password in my .muttrc, but type it in > through mutt, sends email through just fine, so I am thinking that there must > be something in the password amongst the special characters used that mutt > does not like reading from the rc file. I am wondering what those characters > are, and how do I get around it in my muttrc? Probably an Escape sequence? > > Sorry if this is not clear, but thanks in advance for your help, and best > wishes, > Ranjan Ranjan, Without knowing your password string it's only guessing (and I know that you can't post here your password :-)). I would avoid as chars in a password any UTF-8 multibyte char and also only use ASCII printable chars. Best solution for you is just changing the password in your mail server following this rule. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub August 13, 1961: Better a wall than a war. And, while the GDR was still existing, no German troups and bombs have been killed in Yugoslavia, Afghanistan, Afrika...
Re: pretty-print mutt emails
Since ages I do use muttprint (and I'm for FreeBSD the maintainer of the port). It just works fine. matthias signature.asc Description: PGP signature
Re: Deleting Attachments from Index View
El día miércoles, abril 14, 2021 a las 09:42:00p. m. -0400, No Suck escribió: > Thank you for the idea. Unfortunately, testing with a bandwidth monitor > (nethogs) shows that mutt downloads all attachments upon executing > view-attachments from the index view. Can anyone confirm this? ... Correct. I did a test with a mail with a 5 MB attachment over IMAPS. The view-attachments downloads the attachments before presenting the overview. I now even think, there is no other way, because the attachments are in a sequence in the mail body, separated by some describing head lines, and mutt must read the full body to present them. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub ¡Con Cuba no te metas! «» Don't mess with Cuba! «» Leg Dich nicht mit Kuba an! http://www.cubadebate.cu/noticias/2020/12/25/en-video-con-cuba-no-te-metas/
Re: Deleting Attachments from Index View
El día miércoles, abril 14, 2021 a las 01:32:15a. m. -0400, sunnycemet...@gmail.com escribió: > Hello, everyone. I would like to save bandwidth. If an email has a large > attachment that I know I do not need, is it possible to delete the > attachment from mutt's index view and *then* open (download) the message > body? I found no such command in mutt's documentation. > I think, if you use from the Index the command 'v' and them move down to the attachment in question and type 'd' for deletion and go back with 'q' to the Index and then sync with '$', the mail will not be down loaded. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub ¡Con Cuba no te metas! «» Don't mess with Cuba! «» Leg Dich nicht mit Kuba an! http://www.cubadebate.cu/noticias/2020/12/25/en-video-con-cuba-no-te-metas/
Re: Background edit in new terminal window
El día sábado, febrero 20, 2021 a las 12:54:46p. m. +0530, Chinmaya Nagpal
escribió:
> Hi,
>
> I'd like to be able to launch an editor in a new terminal window and
> continue browsing my emails, like the contrib/bgedit-detectgui.sh script
> does but with my editor wrapped in a terminal window instead of with gvim.
And what about storing the mail in question into a temp. mbox file,
launching an additional terminal window with an additional mutt session
with this file.
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
¡Con Cuba no te metas! «» Don't mess with Cuba! «» Leg Dich nicht mit Kuba
an!
http://www.cubadebate.cu/noticias/2020/12/25/en-video-con-cuba-no-te-metas/
signature.asc
Description: PGP signature
Re: textwidth/linewrap
El día jueves, enero 07, 2021 a las 06:40:35p. m. +0100, Jens John escribió: > On Thu, 7 Jan 2021, at 18:25, tech-lists wrote: > > > > I guess lots of people would use mutt with vim-console. > > > > Can anyone tell me please what setting they use for line > > wrapping? I thought in .vimrc it'd be > > > > set textwidth=72 I do use in ~/.muttrc set editor="vim \'+set textwidth=72\' \'+syntax match WarningMsg /\\%>70v.*/\' -i NONE" HIH matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub ¡Con Cuba no te metas! «» Don't mess with Cuba! «» Leg Dich nicht mit Kuba an! http://www.cubadebate.cu/noticias/2020/12/25/en-video-con-cuba-no-te-metas/
Re: Mutt stops showing mail contents
El día martes, diciembre 22, 2020 a las 08:32:06p. m. +0100, Josef Wolf
escribió:
> On Tue, Dec 22, 2020 at 04:58:53PM +0100, Matthias Apitz wrote:
> > And what is this repeated asking with lseek(2) from line 22 to 89 in
> > both cases with
> >
> > 22617 lseek(4, 0, SEEK_CUR)= 4096
> >
> > always getting "yes, next byte to read is number 4096" I don't know where
> > maildir files in mutt are handled.
>
> As I wrote in my prevous post, this are 68 invocations to lseek() and the mail
> file contains 68 header lines. I guess those lseek() calls are somewhere deep
> inside fgets() which mutt uses to read the header line-by-line.
>
> ...
Why fgets(3) should do that? The first fgets(3) call will use a read(2)
sys call to read (as shown in your strace's output) 4096 bytes and every
fgets(3) call will return the bytes until a '\n'; and then the next
line from its internal buffer, until this is exhausted.
I wrote a small C pgm as:
#include
int main()
{
FILE *fp;
char str[4097];
fp = fopen("mail", "r");
while( fgets(str, 4096, fp) != NULL ) {
printf("%s", str);
}
fclose(fp);
return(0);
}
and if you run this with "truss -o tr ./a.out" (FreeBSD has currently no
strace(1)), you will see exactly this:
...
open("mail",O_RDONLY,0666) = 3 (0x3)
fstat(3,{ mode=-rw--- ,inode=13942391,size=4539,blksize=32768 }) = 0 (0x0)
read(3,"From mutt-users-boun...@mutt.org"...,32768) = 4539 (0x11bb)
fstat(1,{ mode=crw--w ,inode=402,size=0,blksize=4096 }) = 0 (0x0)
ioctl(1,TIOCGETA,0x7fffced0) = 0 (0x0)
write(1,"From mutt-users-boun...@mutt.org"...,58) = 58 (0x3a)
write(1,"Return-Path: http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
Без книги нет знания, без знания нет коммунизма (Влaдимир Ильич Ленин)
Without books no knowledge - without knowledge no communism (Vladimir Ilyich
Lenin)
Sin libros no hay saber - sin saber no hay comunismo. (Vladimir Ilich Lenin)
Re: Mutt stops showing mail contents
El día martes, diciembre 22, 2020 a las 02:16:56a. m. +0100, Matthias Apitz escribió: > El día lunes, diciembre 21, 2020 a las 06:55:18p. m. +0100, Josef Wolf > escribió: > > > On Mon, Dec 21, 2020 at 01:32:47PM +0100, Matthias Apitz wrote: > > > Linux has strace(1) (at least it could be installed). I'd start mutt > > > below strace, like that: > > > > > > $ strace -o mutt.tr -f -t mutt . > > > > OK. So here I have attached two strace snippets while mutt is showing a mail > > from a Maildir folder. One snippet shows opening a mail where the body is > > shown and one where the body is not shown. > > > > Below is a diff of those two snippets. The interesting part is in the second > > hunk. This is where the header has been read (every lseek(4,0,SEEK_CUR) > > corresponds to one header line). > > > > After the header has been read, the good invocation will lseek(4,0,SEEK_SET) > > in order to re-read the Maildir file. Then it creates a temp file, dumps the > > contents to this tempfle, and closes it. Then it reopens the file, deletes > > it > > and reads the contents back. > > > > The bad snippet skips all this. It just closes the Maildir file. > > > > Both snippets and the diff are attached to this mail with un-shortened > > strings. Here is the diff with shortened strings for readability: > > > > Smells like a bug in the mutt code you are using on your system. Can you > compile and test an actual code of the original source? > With more time, I looked in detail into the two straces and compared what's going on. The mail in the file /home/jw/Maildir/.ML.mutt/cur/1608410405.M316715P6694.raven.wolf.lan,S=4769,W=4880:2,S" is 4769 bytes in size (headers and body). In the good case mutt reads first 4096 bytes, rewinds the fd, reads the 4096 bytes again and then the additional 673 bytes. See below. The small number at the beginning of the line, like 17, 21, 22, ... is the line number of your files. In the bad case it reads *only* the first block of 4096 bytes and then closes the file descriptor. Somehow it must get the opinion that the rest is not worth to read. But this "opinion" is not based on a sys call result. Why? And what is this repeated asking with lseek(2) from line 22 to 89 in both cases with 22617 lseek(4, 0, SEEK_CUR)= 4096 always getting "yes, next byte to read is number 4096" I don't know where maildir files in mutt are handled. Maybe it's time to look into the source there... matthias good case: 17 22617 openat(AT_FDCWD, "/home/jw/Maildir/.ML.mutt/cur/1608410405.M316715P6694.raven.wolf.lan,S=4769,W=4880:2,S", O_RDONLY) = 4 21 22617 read(4, "Return-Path: ", 4096) = 4096 22 22617 lseek(4, 0, SEEK_CUR)= 4096 ... (rewinds fd 4): 92 22617 lseek(4, 0, SEEK_SET)= 0 93 22617 read(4, "Return-Path: ", 4096) = 4096 ... 103 22617 read(4, " > hours or even days, ...", 4096) = 673 bad case: 17 22617 openat(AT_FDCWD, "/home/jw/Maildir/.ML.mutt/cur/1608410405.M316715P6694.raven.wolf.lan,S=4769,W=4880:2,S", O_RDONLY) = 4 21 22617 read(4, "Return-Path: ", 4096) = 4096 22 22617 lseek(4, 0, SEEK_CUR)= 4096 ... 92 22617 close(4) = 0 93 22617 write(3, "Date: Sat, 19 Dec 2020 21:26:55 +0100\nFrom: Josef Wolf \nTo: mutt-users@mutt.org\nSubject: Re: Mutt stops showing mail contents\nUser-Agent: Mutt/1.10.1 (2018-07-13)\n\n", 182) = 182 -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub Без книги нет знания, без знания нет коммунизма (Влaдимир Ильич Ленин) Without books no knowledge - without knowledge no communism (Vladimir Ilyich Lenin) Sin libros no hay saber - sin saber no hay comunismo. (Vladimir Ilich Lenin)
Re: Mutt stops showing mail contents
El día lunes, diciembre 21, 2020 a las 06:55:18p. m. +0100, Josef Wolf escribió: > On Mon, Dec 21, 2020 at 01:32:47PM +0100, Matthias Apitz wrote: > > Linux has strace(1) (at least it could be installed). I'd start mutt > > below strace, like that: > > > > $ strace -o mutt.tr -f -t mutt . > > OK. So here I have attached two strace snippets while mutt is showing a mail > from a Maildir folder. One snippet shows opening a mail where the body is > shown and one where the body is not shown. > > Below is a diff of those two snippets. The interesting part is in the second > hunk. This is where the header has been read (every lseek(4,0,SEEK_CUR) > corresponds to one header line). > > After the header has been read, the good invocation will lseek(4,0,SEEK_SET) > in order to re-read the Maildir file. Then it creates a temp file, dumps the > contents to this tempfle, and closes it. Then it reopens the file, deletes it > and reads the contents back. > > The bad snippet skips all this. It just closes the Maildir file. > > Both snippets and the diff are attached to this mail with un-shortened > strings. Here is the diff with shortened strings for readability: > Smells like a bug in the mutt code you are using on your system. Can you compile and test an actual code of the original source? matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub Без книги нет знания, без знания нет коммунизма (Влaдимир Ильич Ленин) Without books no knowledge - without knowledge no communism (Vladimir Ilyich Lenin) Sin libros no hay saber - sin saber no hay comunismo. (Vladimir Ilich Lenin)
Re: Mutt stops showing mail contents
El día lunes, diciembre 21, 2020 a las 12:36:19p. m. +0100, Josef Wolf escribió: > On Sun, Dec 20, 2020 at 07:10:40PM -0800, Kevin J. McCarthy wrote: > > It looks like there is a bug filed already: > > <https://bugzilla.opensuse.org/show_bug.cgi?id=1179461> > > > > Josef, I would keep an eye on that to see when it's resolved and pushed out. > Linux has strace(1) (at least it could be installed). I'd start mutt below strace, like that: $ strace -o mutt.tr -f -t mutt . and try to reproduce the error and then investigating the problem in the file mutt.tr to see what mutt is missing or what's going wrong. HIH matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
color of unknown object
Hello, I'm struggling with a color problem in mutt 2.0.2: In the last menu before sending the mail: - y:Send q:Abort t:To c:CC s:Subj a:Attach file d:Descrip ?:Help From: Matthias Apitz To: Matthias Apitz Cc: Bcc: Subject: t Reply-To: Matthias Apitz Fcc: =outboxC720 Security: Sign (PGP/MIME) Sign as: - the background of the header tags like ' From: ' is set to black (as the foreground color) from the beginning of the line to the first blank after the colon and the text is not readable, because foreground and background are identically. What is the name of this object for the value in ~/.muttrc? Thanks matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub Без книги нет знания, без знания нет коммунизма (Влaдимир Ильич Ленин) Without books no knowledge - without knowledge no communism (Vladimir Ilyich Lenin) Sin libros no hay saber - sin saber no hay comunismo. (Vladimir Ilich Lenin)
Re: FCC error, may be caused by missing dir ~/Mail
El día viernes, noviembre 06, 2020 a las 10:02:46a. m. -0800, Ian Zimmerman escribió: > On 2020-11-06 08:25, Matthias Apitz wrote: > > > See also man page of wait(2): the errno=ECHILD: > > >ECHILD (for waitpid() or waitid()) The process specified by pid > >(waitpid()) or idtype and id (waitid()) does not exist or is > >not a child of the calling process. (This can happen for one's > >own child if the action for SIGCHLD is set to SIG_IGN. See > >also the Linux Notes section about threads.) > > So, does mutt set SIG_IGN for SIGCHLD? Maybe it should not, or maybe it > should temporarily restore it in places like this where it synchronously > waits for a child. That seems like a cleaner solution than the proposed > patch. In my case it seems to be the case that the application servers which are using mutt have set SIGCHLD to SIG_IGN. So, mutt, if it depends on sync waiting for it children, should set it to its needs or handle (like the proposed patch does) the ECHILD situation correctly. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub Без книги нет знания, без знания нет коммунизма (Влaдимир Ильич Ленин) Without books no knowledge - without knowledge no communism (Vladimir Ilyich Lenin) Sin libros no hay saber - sin saber no hay comunismo. (Vladimir Ilich Lenin)
Re: FCC error, may be caused by missing dir ~/Mail
El día jueves, noviembre 05, 2020 a las 02:05:38p. m. -0800, Kevin J. McCarthy
escribió:
> On Thu, Nov 05, 2020 at 10:43:17PM +0100, Matthias Apitz wrote:
> >And as I said, all is working fine, i.e. the mails get sent fine, the
> >only problem is this message spilt out by mutt about mail not sent.
> >
> >I will nail this down, it will only take some time, and I feel that it
> >has todo with the handling on SIGCHLD which is set by the application
> >server which calls the master script perhaps to wrong state. Needs some
> >more debugging. Mutt itself isn't the culprit perhaps.
>
> Okay, it definitely sounds like something beyond my ability to assist
> deeply. :-)
>
> From Mutt's point of view, it is looking for the exit code after
> waitpid() finishes. If there is an error from waitpid() or the
> WEXITSTATUS is not 0, then Mutt will print that message out.
Hello Kevin et all,
I think I nailed it down. See the proc chain below. In send_msg() Mutt is
waiting that the forked 'sendmail' process ends but when this happens
the PID does not exist anymore and the wait(2) is returning -1, which
in this case (ECHILD) should not be treated as an error.
This, errno==ECHILD not beeing an error on Linux, was discussed already
a lot of times, see for example here:
https://stackoverflow.com/questions/55150189/linux-system-returns-1-errno-10-no-child-processes
I think the code in sendlib.c line 2286 ... should be changed to something
like this:
diff -c sendlib.c.orig sendlib.c
*** sendlib.c.orig Tue May 30 21:27:53 2017
--- sendlib.c Fri Nov 6 08:16:24 2020
***
*** 2283,2289
}
else
{
! st = (SendmailWait > 0 && errno == EINTR && SigAlrm) ?
S_BKG : S_ERR;
if (SendmailWait > 0 && tempfile && *tempfile)
{
--- 2283,2289
}
else
{
! st = ((SendmailWait > 0 && errno == EINTR && SigAlrm) || (errno ==
ECHILD)) ?
S_BKG : S_ERR;
if (SendmailWait > 0 && tempfile && *tempfile)
{
***
*** 2310,2315
--- 2310,2317
if (pid != -1 && waitpid (pid, &st, 0) > 0)
st = WIFEXITED (st) ? WEXITSTATUS (st) : S_ERR; /* return child status */
+ else if (errno == ECHILD)
+ st = S_BKG;
else
st = S_ERR; /* error */
st = ((SendmailWait > 0 && errno == EINTR && SigAlrm) | (errno == ECHILD)) ?
S_BKG : S_ERR;
For me it solved the problem fine.
Here is the process chain (please use fixed font terminal):
10499 execve("/usr/local/sisis-pap/bin/mutt", ["/usr/local/sisis-pap/bin/mutt",
"-d4", ...
|
|
+ 10499 clone(child_stack=NULL ) = 10502
|
|
+ 10502 clone(child_stack=NULL, flags ...) = 10503
|
|
|
+ 10503 execve("sisis2mail.sh", ["sisis2mail.sh", "--cat",
"--", "foo@zone"] ...
| |
| |
| + 10504 execve("/bin/cat", ["cat", "--"], ...
|
|
10502 10502 wait4(10503,
and then at the end:
10503 exit_group(0) = ?
10503 +++ exited with 0 +++
10502 <... wait4 resumed> 0x7ffc8dc9137c, 0, NULL) = -1 ECHILD (No child
processes)
10502 alarm(0) = 0
10502 rt_sigaction(SIGALRM, {sa_handler=0xd76dd3, sa_mask=[],
sa_flags=SA_RESTORER|0x200, sa_restorer=0x7f9762c035a0}, NULL, 8) = 0
10502 kill(10499, SIG_0)= 0
10502 exit_group(127) = ?
^
10502 +++ exited with 127 +++
10499 <... wait4 resumed> 0x7ffc8dc9137c, 0, NULL) = -1 ECHILD (No child
processes)
10499 rt_sigprocmask(SIG_UNBLOCK, [CHLD], NULL, 8) = 0
10499 rt_sigaction(SIGQUIT, {sa_handler=SIG_IGN, sa_mask=[],
sa_flags=SA_RESTORER, sa_restorer=0x7f9762c035a0}, NULL, 8) = 0
10499 rt_sigaction(SIGINT, {sa_handler=SIG_IGN, sa_mask=[],
sa_flags=SA_RESTORER, sa_restorer=0x7f9762c035a0}, NULL, 8) = 0
10499 write(2, "Fehler 127 beim Versand der Nachricht (Exec error.).", 52) = 52
10499 write(2, "\n", 1) = 1
10499 unlink("/tmp/mutt-srap38dxr1-900118-10499-18399221751636680389") = 0
10499 write(3, "[2020-11-05 09:51:33] ", 22) = 22
10499 write(3, "mutt_free_body: unlinking
/tmp/mutt-srap38dxr1-900118-10499-18399221751636680389.\n", 82) = 82
10499 write(1, "Debugging auf Ebene 4.\nKonnte Nachricht nicht verschicken.\n",
59) = 59
10499 exit_group(1) = ?
10499 +++ exited with 1 +++
See also man page of wait(2): the e
Re: FCC error, may be caused by missing dir ~/Mail
El día jueves, noviembre 05, 2020 a las 11:03:00a. m. -0800, Kevin J. McCarthy escribió: > On Thu, Nov 05, 2020 at 07:55:11PM +0100, Matthias Apitz wrote: > >It *is* supported by mutt using the following trick: one of the arguments > >to mutt is: > > > > | mutt -d4 -e "set sendmail=\"cat --\"" ... | sendmail -t > > I see. But wouldn't the recipients be appended to $sendmail, and then > cat complain with an error message (and error code) that the "recipient" > filenames couldn't be found? The error code would then cause Mutt to > report an error invoking $sendmail... You're correct. I simplified it to make it better understandable. The real call is: | mutt -d4 -e "set sendmail=\"script.sh --\"" ... | sendmail -t and script.sh which is called by mutt as you say correctly as script.sh -- some@zone just ignores the argument 'some@zone' and calls 'cat --' because the mailaddr some@zone comes to the real sendmail in STDIN as To: some@zone Subject: ... ... All the above is done within a shellscript with a lot of options to provide mail as UTF-8 text or HTML and attachments etc. and mutt makes of all the args a well formatted mail with correct headers and attachments to be piped at the end to sendmail. This master script is called from our application servers to send mails to library patrons about fees or books to be returned in time, or to book vendors as orders etc. And mutt does a real nice job here for all our needs. And as I said, all is working fine, i.e. the mails get sent fine, the only problem is this message spilt out by mutt about mail not sent. I will nail this down, it will only take some time, and I feel that it has todo with the handling on SIGCHLD which is set by the application server which calls the master script perhaps to wrong state. Needs some more debugging. Mutt itself isn't the culprit perhaps. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub Без книги нет знания, без знания нет коммунизма (Влaдимир Ильич Ленин) Without books no knowledge - without knowledge no communism (Vladimir Ilyich Lenin) Sin libros no hay saber - sin saber no hay comunismo. (Vladimir Ilich Lenin)
Re: FCC error, may be caused by missing dir ~/Mail
El día jueves, noviembre 05, 2020 a las 10:17:25a. m. -0800, Kevin J. McCarthy escribió: > >Thanks for the reply. The used mutt is version 1.18.3 (see debug log > >below). I put a tee command between mut and sendmail to see what mutt > >is spilling out to sendmail: > > > > ... | mutt -d4 | tee -a acqmail.log | sendmail -t > > Sorry I didn't look closely enough at your original email. It sounds > like you are expecting the stdout of mutt to be the formatted message > which you are then piping to sendmail. Is that correct? Yes, exactly. > As far as I know, that mode of operation isn't supported by Mutt. I'm > confused how it is working, to be honest. Mutt expects either $sendmail > or $smtp_url to be set, and it controls the sending itself. It *is* supported by mutt using the following trick: one of the arguments to mutt is: | mutt -d4 -e "set sendmail=\"cat --\"" ... | sendmail -t i.e. from the point of view of mutt the 'sendmail' is just a 'cat' command and so its output is coming out on STDOUT of the proc. I'm already debugging the process chain with Linux strace and it seems that there is some problem with SIGCHLD in mutt not getting correctly the proc termination of its 'sendmail', seeing it as -127 which causes then the (wrong) assumption that the mail wasn't sent by its 'sendmail' child proc. We will see... matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub Без книги нет знания, без знания нет коммунизма (Влaдимир Ильич Ленин) Without books no knowledge - without knowledge no communism (Vladimir Ilyich Lenin) Sin libros no hay saber - sin saber no hay comunismo. (Vladimir Ilich Lenin)
Re: FCC error, may be caused by missing dir ~/Mail
El día miércoles, noviembre 04, 2020 a las 09:33:34a. m. -0800, Kevin J. McCarthy escribió: > On Wed, Nov 04, 2020 at 01:17:44PM +0100, Matthias Apitz wrote: > >We use mutt in batch mode to assemble mails with all attachments etc. > >and pipe the assembled mail to /usr/lib/sendmail -t which works also > >fine. But is complaining on STDERR that the mail could not be sent with > > > >Could not send the message. > > > >I looked into the source send.c and the error message is triggered by > >some internal FCC error, perhaps just due to the missing ~/Mail dir or > >something the like. The mail is sent fine. > > You didn't mention what version of Mutt you are using on the server. > There has been a fair amount of refactoring in this part of the code the > past few releases, but looking at 1.8.0 (corresponding to your header) > the check is: > >if (fcc_error || (i = send_message (msg)) < 0) > > If there were an fcc_error, the conditional would short-circuit and > send_message() wouldn't be invoked. > > I would double check the problem is with Fcc, if the emails are in fact > sent out. If you're sure that's the problem, perhaps try invoking mutt > with something like: > >mutt -e 'unset record' ... Kevin, Thanks for the reply. The used mutt is version 1.18.3 (see debug log below). I put a tee command between mut and sendmail to see what mutt is spilling out to sendmail: ... | mutt -d4 | tee -a acqmail.log | sendmail -t The file says at the end: $ tail acqmail.log ... ISBN/ISSN: Preis:9.99 EUR Sonstiges: * Mit freundlichen Grüßen i.A.Debugging auf Ebene 4. Konnte Nachricht nicht verschicken. ^^^ That there is no \n between "i.A." and "Debugging auf Ebene 4." is caused by the mail source piped into mutt is lacking an \n on its last line. The debug log contains only: $ cat ~/.muttdebug0 [2020-11-05 09:25:06] Mutt/1.8.3 (2017-05-23) debugging at level 4 [2020-11-05 09:25:06] getdnsdomainname(): dev.x.org [2020-11-05 09:25:06] Reading configuration file '/usr/local/sisis-pap/etc/Muttrc'. [2020-11-05 09:25:06] send.c:1235: mutt_mktemp returns "/tmp/mutt-srap38dxr1-900118-29444-247126431730400576". [2020-11-05 09:25:06] sendlib.c:2743: mutt_mktemp returns "/tmp/mutt-srap38dxr1-900118-29444-154600781884627193". [2020-11-05 09:25:06] mwoh: pfx=[(null)], tag=[Subject], flags=0 value=[Neue Bestellung =?utf-8?Q?h=C3=BCff-001688?= =?utf-8?Q?4?= der Bibliothek Bibliothek der x GmbH] [2020-11-05 09:25:06] send.c:974: mutt_mktemp returns "/tmp/mutt-srap38dxr1-900118-29444-2253970281884134976". [2020-11-05 09:25:06] mwoh: pfx=[(null)], tag=[Subject], flags=0 value=[Neue Bestellung =?utf-8?Q?h=C3=BCff-001688?= =?utf-8?Q?4?= der Bibliothek Bibliothek der x GmbH] [2020-11-05 09:25:06] mutt_free_body: unlinking /tmp/mutt-srap38dxr1-900118-29444-247126431730400576. I've no clue why this message "Konnte Nachricht nicht verschicken." (English: "Could not send the message.") is raised. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub Без книги нет знания, без знания нет коммунизма (Влaдимир Ильич Ленин) Without books no knowledge - without knowledge no communism (Vladimir Ilyich Lenin) Sin libros no hay saber - sin saber no hay comunismo. (Vladimir Ilich Lenin)
FCC error, may be caused by missing dir ~/Mail
Hello, When I call mutt for the first time on some server, it asks me if it should create ~/Mail if this directory does not exist, among others to store in ~/Mail/outbox a copy of outgoing mails. Fine. We use mutt in batch mode to assemble mails with all attachments etc. and pipe the assembled mail to /usr/lib/sendmail -t which works also fine. But is complaining on STDERR that the mail could not be sent with Could not send the message. I looked into the source send.c and the error message is triggered by some internal FCC error, perhaps just due to the missing ~/Mail dir or something the like. The mail is sent fine. How can I disable the error message? Thanks matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub Без книги нет знания, без знания нет коммунизма (Влaдимир Ильич Ленин) Without books no knowledge - without knowledge no communism (Vladimir Ilyich Lenin) Sin libros no hay saber - sin saber no hay comunismo. (Vladimir Ilich Lenin)
IMAPS && Certificate host check failed
Hello, Since some days I get Certificate host check failed: certificate owner does not match hostname pod51010.outlook.com This certificate belongs to: outlook.com Unknown Microsoft Corporation Unknown Redmond Washington US This certificate was issued by: DigiCert Cloud Services CA-1 Unknown DigiCert Inc Unknown Unknown Unknown US This certificate is valid from Oct 7 00:00:00 2020 GMT to Oct 7 12:00:00 2021 GMT -- Mutt: SSL Certificate check (certificate 3 of 3 in chain) (r)eject, accept (o)nce when I connect with mutt to imaps://pod51010.outlook.com/ What could I do? Thanks matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub Без книги нет знания, без знания нет коммунизма (Влaдимир Ильич Ленин) Without books no knowledge - without knowledge no communism (Vladimir Ilyich Lenin) Sin libros no hay saber - sin saber no hay comunismo. (Vladimir Ilich Lenin)
Fwd:
Why I'm / we're getting this type of messages? Thanks matthias - Forwarded message from Globe Trotter via Mutt-users - Date: Sat, 24 Oct 2020 16:45:52 + (UTC) From: Globe Trotter via Mutt-users To: Paul Gilmartin via Mutt-users This message wraps the original message. The sending domain has a DMARC p=reject policy, which unfortunately can cause bounces. See http://www.mutt.org/mail-lists.html#dmarc To remove this message, please change the domain policy to p=none or p=quarantine. Date: Sat, 24 Oct 2020 16:45:52 + (UTC) From: Globe Trotter To: Paul Gilmartin via Mutt-users Subject: have postpone messages have an additional option in mutt? X-Mailer: WebService/1.1.16868 YMailNorrin Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:81.0) Gecko/20100101 Firefox/81.0 Hi, An irritating thing right now is that if I hit q in error after composing a message, I get: Postpone message (yes/no) and if I say no, then the message appears lost. Is is possible to have an an option on this which should be to cancel the postpone question: perhaps a prompt that is [yes/no/cancel] Thanks! - End forwarded message - -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub Без книги нет знания, без знания нет коммунизма (Влaдимир Ильич Ленин) Without books no knowledge - without knowledge no communism (Vladimir Ilyich Lenin) Sin libros no hay saber - sin saber no hay comunismo. (Vladimir Ilich Lenin)
Re: Index screen - could it feature time segments?
El día domingo, agosto 02, 2020 a las 07:57:05a. m. -0400, Remco Rijnders escribió: > On Sun, Aug 02, 2020 at 11:46:43AM +0200, Matthias wrote in > <7f107366-0e85-4e77-819d-65e59217f...@unixarea.de>: > >On Sunday, 2 August 2020 11:24:35 CEST, Leho Kraav wrote: > >>Hi. I'm looking for a way to get mutt index to segment list display > >>with Today, Yesterday, Last Week, 2 weeks ago etc separators. > >... > >In a threaded view, this would lead to the question, where an original > >post and its reply have to be placed if they're two weeks away from > >each other. > > I would guess it would look something like this: > > 115 r Two weeks ago Leho Kraav (5.4K) Index screen - could it feature > time segments? > 116 Yesterday Matthias Apitz ( 25) ├─> > > And it would sort internally in Mutt using the original sorting method > set. When set using a date it would go by the real date and not the > textual representation displayed. Ah, now I understand your intention better. I though you want to draw a horizontal line between the times of Today, Yesterday, Last Week, 2 weeks ago etc. like M$ OutLook it does. What you want to have, is an additional column with some time indicator. Correct? matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub May, 9: Спаси́бо освободители! Thank you very much, Russian liberators!
Re: Index screen - could it feature time segments?
On Sunday, 2 August 2020 11:24:35 CEST, Leho Kraav wrote: Hi. I'm looking for a way to get mutt index to segment list display with Today, Yesterday, Last Week, 2 weeks ago etc separators. Feels like it should be technically possible, but I haven't been able to find a configuration or a patch for this. Your thoughts? In a threaded view, this would lead to the question, where an original post and its reply have to be placed if they're two weeks away from each other. matthias -- Sent from my Ubuntu phone http://www.unixarea.de/ NO to the EU! NEIN zur EU!
Re: extracting subjects lines
El día Sonntag, Juli 19, 2020 a las 08:18:01 +0200, Ulrich Lauther escribió:
> Hi,
>
> I use
> grep "Subject: " /var/mail/$USER
>
> to extract subject-lines from my mail box and get for instance
>
> Subject: =?utf-8?Q?Achtung=20=2D=20don=27t=20say=20that?=
>
> but in mutt, I see
>
> Achtung - don't say that
>
> How can I get the subject lines in clear text?
$ cat subject.pl
#!/usr/local/bin/perl
#
use Encode;
my $subject = "Subject: =?utf-8?Q?Achtung=20=2D=20don=27t=20say=20that?=";
my $escapedHeaderLine = Encode::decode('MIME-Q', $subject);
print $escapedHeaderLine, "\n";
$ ./subject.pl
Subject: Achtung - don't say that
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
May, 9: Спаси́бо освободители! Thank you very much, Russian liberators!
Re: IMAP && Server certificate has expired
El día domingo, mayo 31, 2020 a las 10:56:57a. m. -0400, Ben Boeckel escribió:
> On Sun, May 31, 2020 at 16:43:23 +0200, Matthias Apitz wrote:
> > Doesn't this mean that something on my local system (FreeBSD with
> > OpenSSL, both from end of 2018) is outdated?
> >
> > $ uname -a
> > FreeBSD c720-r342378 13.0-CURRENT FreeBSD 13.0-CURRENT GENERIC amd64
> >
> > $ openssl version
> > OpenSSL 1.1.1a-freebsd 20 Nov 2018
>
> Ah, yes. You need to check your ca-certificates version, not OpenSSL.
> I'm not sure where FreeBSD gets their bundles though (or the
> package/ports name for it). I imagine Mozilla is the source though, but
> the required certs were added back in Firefox 36 days.
I watched with truss which files mutt opens on start:
$ grep cert mutt.tr
open("/usr/local/openssl/cert.pem",O_RDONLY,0666) = 4 (0x4)
open("/home/guru/.mutt_certificates",O_RDONLY,0666) ERR#2 'No such file or
directory'
...
$ ls -l /etc/*/cert.*
lrwxr-xr-x 1 root wheel 38 23 dic. 2018 /etc/ssl/cert.pem ->
/usr/local/share/certs/ca-root-nss.crt
$ ls -l /usr/local/share/certs/ca-root-nss.crt /usr/local/openssl/cert.pem
-rw-r--r-- 1 root wheel 800790 23 dic. 2018 /usr/local/openssl/cert.pem
-rw-r--r-- 1 root wheel 800790 23 dic. 2018
/usr/local/share/certs/ca-root-nss.crt
i.e. I have to bring this up in the FreeBSD mailing list, I think.
I'm wondering why only mutt is affected by this, though.
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
May, 9: Спаси́бо освободители! Thank you very much, Russian liberators!
Re: IMAP && Server certificate has expired
El día domingo, mayo 31, 2020 a las 10:22:06a. m. -0400, Ben Boeckel escribió: > On Sun, May 31, 2020 at 15:20:51 +0200, Matthias Apitz wrote: > > Server certificate has expired > > > > > This certificate belongs to: > >AddTrust External CA Root > >Unknown > >AddTrust AB > >AddTrust External TTP Network > >Unknown > >Unknown > >SE > > Your ISP has been affected by this: > > > https://support.sectigo.com/articles/Knowledge/Sectigo-AddTrust-External-CA-Root-Expiring-May-30-2020 > > They may have fixed it already if the sibling reply is correct. Doesn't this mean that something on my local system (FreeBSD with OpenSSL, both from end of 2018) is outdated? $ uname -a FreeBSD c720-r342378 13.0-CURRENT FreeBSD 13.0-CURRENT GENERIC amd64 $ openssl version OpenSSL 1.1.1a-freebsd 20 Nov 2018 matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub May, 9: Спаси́бо освободители! Thank you very much, Russian liberators!
Re: IMAP && Server certificate has expired
El día domingo, mayo 31, 2020 a las 03:57:46p. m. +0200, li...@2ion.de escribió: > On Sun, May 31, 2020 at 03:20:51PM +0200, Matthias Apitz wrote: > > Any ideas? > > Run mutt with the -d2 switch and it'll store debug information in > ~/.muttdebug0. [2020-05-31 16:17:24] 4> a STARTTLS^M [2020-05-31 16:17:24] 4< a OK Begin TLS negotiation now. [2020-05-31 16:17:24] ssl_load_certificates: loading trusted certificates [2020-05-31 16:17:24] mutt_ssl_starttls: Error loading trusted certificates [2020-05-31 16:17:25] ssl_verify_callback: checking cert chain entry /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root (preverify: 0 skipmode: 0) [2020-05-31 16:17:25] Server certificate has expired > Unless the hoster was just rotating certs when you were looking, your mutt > debug > output will tell you more. Lastly -- make 100% sure that the DNS name is > resolving to the correct IP address for you locally -- compare dig @1.1.1.1 > imap.1blu.de to whatever your mutt debug output shows as well as the output of > dig without the @ clause. $ host imap.1blu.de imap.1blu.de has address 178.254.4.112 imap.1blu.de has address 178.254.4.107 imap.1blu.de has address 178.254.4.109 imap.1blu.de has address 178.254.4.102 imap.1blu.de has address 178.254.4.114 imap.1blu.de has address 178.254.4.77 imap.1blu.de has address 178.254.4.78 imap.1blu.de has address 178.254.4.76 imap.1blu.de has address 178.254.4.116 imap.1blu.de has address 178.254.4.115 imap.1blu.de has address 178.254.4.118 imap.1blu.de has address 178.254.4.123 imap.1blu.de has address 178.254.4.111 imap.1blu.de has address 178.254.4.73 imap.1blu.de has address 178.254.4.122 imap.1blu.de has address 178.254.4.117 imap.1blu.de has address 178.254.4.110 imap.1blu.de has address 178.254.4.103 imap.1blu.de has address 178.254.4.113 imap.1blu.de has address 178.254.4.79 imap.1blu.de has address 178.254.4.108 imap.1blu.de has address 178.254.4.74 Which IP addr you get for imap.1blu.de? matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub May, 9: Спаси́бо освободители! Thank you very much, Russian liberators!
IMAP && Server certificate has expired
Hello, When I connect with mutt directly with IMAP to my ISP with: $ mutt -f imap://imap.1blu.de:143/ I get since some hours: Server certificate has expired and the cert presented gives the information below. I can overcome the situation with 'set ssl_verify_dates=no' in .muttrc, but I'm wondering what should I tell to my ISP as no information about his server (1blu.de) shows up in the expired certificate. Or is this because something on my OpenSSL installation expired? Any ideas? matthias This certificate belongs to: AddTrust External CA Root Unknown AddTrust AB AddTrust External TTP Network Unknown Unknown SE This certificate was issued by: AddTrust External CA Root Unknown AddTrust AB AddTrust External TTP Network Unknown Unknown SE This certificate is valid from May 30 10:48:38 2000 GMT to May 30 10:48:38 2020 GMT SHA1 Fingerprint: 02FA F3E2 9143 5468 6078 5769 4DF5 E45B 6885 1868 SHA256 Fingerprint: 687F A451 3822 78FF F0C8 B11F 8D43 D576 671C 6EB2 BCEA B413 FB83 D965 D06D 2FF2 -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub May, 9: Спаси́бо освободители! Thank you very much, Russian liberators!
Re: providing IMAP password to a mutt running on a remote host
On Friday, 29 May 2020 19:28:26 CEST, Ian Zimmerman wrote: On 2020-05-29 07:33, Matthias Apitz wrote: Has someone an idea how could I provide to the remote mutt session the IMAP credentials stored on my local laptop? If you can talk to the admin of the remote host, you can put the credentials into some Unix environment variables on the laptop and make ssh lob them over (this is controlled by AcceptEnv, SendEnv and SetEnv in ssh configuration, including the sshd on the remote and that's what you need the admin's help for). Then in the remote .muttrc at the place where you need the credentials use a `printenv FOO` construct. I have done something like this but since then my program of radical simplicity has made some progress :-) Thanks for the idea. I made some test and the remote sshd let pass through the TERM env var. So could add to it the IMAP pw and use it in the remote .profile to cut it again in two values for TERM and pw. Thanks. matthias -- Sent from my Ubuntu phone http://www.unixarea.de/ NO to the EU! NEIN zur EU!
providing IMAP password to a mutt running on a remote host
Hello, I often use mutt on some remote Linux host of my ISP about which I do not have control as root, just a SSH login is provided. Due to this I do not want to store the IMAP password in ~/.muttrc or where ever there in plain text. The SSH connection is initiated from my local FreeBSD laptop using RSA and a ssh-agent, i.e. I can do there on the remote host also: $ ssh-add -l 1024 SHA256:kZHWaISpML7rzqVppZNTOR+r+6plvFsc967WqOJ5iKo /home/guru/.ssh/id_rsa (RSA) Has someone an idea how could I provide to the remote mutt session the IMAP credentials stored on my local laptop? And no, I do not want to use IMAP through the SSH tunnel, i.e. run mutt on my laptop, because in the scenario described above the laptop is inside my company and central managed network and I can not use any normal sendmail MX chain, all mail must be passed through a central host (guess, what type of MX this runs :-) ) Thanks matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub May, 9: Спаси́бо освободители! Thank you very much, Russian liberators!
PGP SIGNED MESSAGE in mutt not checked
Hello I receive mails from some friend with the structure shown below, private data removed or overwritten. How mutt could check automagically the signed content or is there something missing in the mail header? Ofc, I can pipe the body through '|gpg2 --verify' or define a key in mutt todo so. But I'd like to have mutt do this on the flight already in the Index page... Thanks - Forwarded message from XX - From: XX Subject: Re: XXXXX To: Matthias Apitz References: <20200206203936.GA2808@c720-r342378> Message-ID: Date: Sun, 16 Feb 2020 18:56:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <20200214212923.GA2743@c720-r342378> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: de-DE X-Envelope-To: g...@unixarea.de Status: RO Content-Length: 1630 Lines: 49 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 -BEGIN PGP SIGNATURE- iF0EARECAB0WIQRUA9NDG0Yepqex7DX6YxG8W2vJLgUCXkmCLQAKCRD6YxG8W2vJ LkwCAJ9onJh++VZB62WNSyJXS//2ZaLIYgCeNMBbplwX1V/3KuOTQ9pi60Z7fCg= =f73L -END PGP SIGNATURE- - End forwarded message - -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub signature.asc Description: PGP signature
Fwd: Re: CDFV2 Microsoft Outlook Message
Hello, Is this an error in mutt itself or in the tool producing the mbox file with this line: - Forwarded message from Matthias Apitz - Date: Wed, 5 Feb 2020 08:00:55 +0100 From: Matthias Apitz To: freebsd-questi...@freebsd.org Subject: Re: CDFV2 Microsoft Outlook Message El día miércoles, febrero 05, 2020 a las 07:11:42a. m. +0100, Matthias Apitz escribió: > > Hello, > > $ file siadmin-error-pg.msg > siadmin-error-pg.msg: CDFV2 Microsoft Outlook Message > > Do we have something in the ports to open or convert such a beast? > ... I should have been looking better myself :-( we have mail/p5-Email-Outlook-Message and with this one can do: $ msgconvert --mbox siadmin-error-pg.mbox siadmin-error-pg.msg The resulting mbox file has a first line like: From "Apitz,Matthias" Wed Feb 5 07:57:08 2020 but after repairing it with vim to: From matthias.ap...@foo.org Wed Feb 5 07:57:08 2020 mutt is willing to open the mbox fine. matthias - End forwarded message - -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub signature.asc Description: PGP signature
Re: How to simulate entering keys into mutt?
On Tue, 7 Jan 2020 16:44:41 +, Chris Green wrote: > I want to emulate typing a dozen or so keys into mutt 'automatically' > so my typing doesn't slow things down. One can't just redirect > standard input because that makes mutt think you want to run in > scripting mode with everything on the command line. > > Is there a quick and easy way to do what I want? > In an X11 environment this should be easy. I did this in the past some 20 years ago for controlling a web site and could look for the C source in my backups. matthias -- Sent using Dekko from my Ubuntu device
Re: Slow changing mbox - continued
El día lunes, enero 06, 2020 a las 08:59:36p. m. +1100, Cameron Simpson escribió: > Matthias suggested this: > > strace -o tr -tt mutt > > If you want less log to deal with you can strace a process from outside: > > strace -o tr -tt -p pid-of-mutt > > That would let you fire it up just before the action (change mailbox) > which you know contains the delay. Might get you a better targeted log. I think one clearly identify with the lines 'read(0, ' when the user input was done and further processed. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub "Glaube wenig, hinterfrage alles, denke selbst: Wie man Manipulationen durchschaut" "Believe little, scrutinise all, think by your own: How see through manipulations" ISBN-10: 386489218X signature.asc Description: PGP signature
usage of PK7SC file/signature smime.p7s
Hello, I got an email signed with an attached file smime.p7s. Can I deal with our beloved mutt with this on FreeBSD-CURRENT, mutt 1.11.1, OpenSSL 1.1.1a-freebsd? Thanks matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub "Glaube wenig, hinterfrage alles, denke selbst: Wie man Manipulationen durchschaut" "Believe little, scrutinise all, think by your own: How see through manipulations" ISBN-10: 386489218X signature.asc Description: PGP signature
Re: Slow changing mbox - continued
El día jueves, enero 02, 2020 a las 12:58:21p. m. +, Chris Green escribió:
> Well I've started trying to diagnose this, I'm less sure now that it
> only happens across the ssh connection, that may be a red herring.
> I've changed the main disk drive on my dekstop system (where mutt
> runs) from a 1TB spinning hard disk to a 1TB SSD and I *think* the
> slowness may be related to this.
>
> With the SSD some things are *much* faster, e.g. loading a 5000
> message mbox (my 'sent' mailbox) is almost instant now whereas it used
> to take several seconds. So the SSD is faster in general, a *lot*
> faster.
>
> I have the recommended trace running and the only significant delays I
> can see are:-
>
> ...
> ...
> ...
> 12:40:19.110589 write(1, "\r\33[J\33[H\33[30m\33[46m---Mutt: ~/Mail"...,
> 3622) = 3622
> 12:40:19.110737 rt_sigaction(SIGINT, {sa_handler=0x55bca4ac2440,
> sa_mask=[], sa_flags=SA_RESTORER, sa_restor er=0x7f00502f1470}, NULL, 8) = 0
> 12:40:19.110791 write(1, "\33[?1h\33=", 7) = 7
> 12:40:19.110826 poll([{fd=0, events=POLLIN}], 1, 15000) = 1 ([{fd=0,
> revents=POLLIN}])
> 12:40:25.110942 read(0, "c", 1) = 1
> 12:40:25.111099 rt_sigaction(SIGINT, {sa_handler=0x55bca4ac2440,
> sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART , sa_restorer=0x7f00502f1470},
> NULL, 8) = 0
> 12:40:25.111211 write(1, "\33[?12l\33[?25h", 12) = 12
> 12:40:25.111433 stat("/home/chris/Mail/In/inbox", {st_mode=S_IFREG|0600,
> st_size=3065472, ...}) = 0
> 12:40:25.111575 stat("/var/mail/chris", {st_mode=S_IFREG|0600,
> st_size=726, ...}) = 0
> 12:40:25.111649 stat("/home/chris/Mail/In/inbox", {st_mode=S_IFREG|0600,
> st_size=3065472, ...}) = 0
> 12:40:25.111712 stat("/home/chris/Mail/Li/alug", {st_mode=S_IFREG|0600,
> st_size=298691, ...}) = 0
> ...
> ...
> ...
> 12:40:25.115157 stat("/home/chris/Mail/In/odin", {st_mode=S_IFREG|0600,
> st_size=1083391, ...}) = 0
> 12:40:25.115348 write(1, "\r\33[60dOpen mailbox ('?' for list"..., 55) =
> 55
> 12:40:25.115450 rt_sigaction(SIGINT, {sa_handler=0x55bca4ac2440,
> sa_mask=[], sa_flags=SA_RESTORER, sa_restor er=0x7f00502f1470}, NULL, 8) = 0
> 12:40:25.115552 read(0, "\r", 1)= 1
> 12:40:27.765854 rt_sigaction(SIGINT, {sa_handler=0x55bca4ac2440,
> sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART , sa_restorer=0x7f00502f1470},
> NULL, 8) = 0
> 12:40:27.766147 write(1, "\33[60;13H: \33[K\33(B\33[m", 19) = 19
> 12:40:27.766445 write(1, "~/Mail/Li/x2go\33(B\33[m", 20) = 20
> 12:40:27.766650 stat("/home/chris/Mail/Li/x2go", {st_mode=S_IFREG|0600,
> st_size=264290, ...}) = 0
> ...
> ...
> ...
> 12:40:27.766999 utime("/home/chris/Mail/Li/x2go", {actime=1577968429 /*
> 2020-01-02T12:33:49+ */, modtime =1577968434 /* 2020-01-02T12:33:54+
> */}) = 0
> 12:40:27.767127 write(1, "\r\33[32mMailbox is unchanged.\33[39m"..., 41)
> = 41
> 12:40:27.767183 stat("/home/chris/Mail/In/inbox", {st_mode=S_IFREG|0600,
> st_size=3065472, ...}) = 0
> 12:40:27.767243 utime("/home/chris/Mail/In/inbox", {actime=1577968819 /*
> 2020-01-02T12:40:19+ */, modtim e=1577966702 /* 2020-01-02T12:05:02+
> */}) = 0
> 12:40:27.767325 close(3)= 0
> 12:40:27.767468 nanosleep({tv_sec=1, tv_nsec=0}, 0x7fff86fc8060) = 0
> 12:40:28.767837 lstat("/home", {st_mode=S_IFDIR|0755, st_size=4096, ...})
> = 0
> 12:40:28.768113 lstat("/home/chris", {st_mode=S_IFDIR|0755, st_size=4096,
> ...}) = 0
> ...
> ...
> ...
>
> I *think* the one that is the delay I'm seeing is that two and a half
> second delay after read(0, "\r", 1). I guess the long delays after
> poll(...) are what one would expect as it's mutt waiting for me to do
> something, and the one second delay at nanosleep() is as coded.
>
> So, what's that read() doing that takes so long?
In the lines:
12:40:25.115552 read(0, "\r", 1)= 1
12:40:27.765854 rt_sigaction(SIGINT, {sa_handler=0x55bca4ac2440, sa_mask=[],
sa_flags=SA_RESTORER|SA_RESTART , sa_restorer=0x7f00502f1470}, NULL, 8) = 0
12:40:27.766147 write(1, "\33[60;13H: \33[K\33(B\33[m", 19) = 19
the time 12:40:25.115552 is when the read(2) sys call on STDIN started
and the next time 12:40:27.765854 when the input was available.
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
"Glaube wenig, hinterfrage alles, denke selbst: Wie man Manipulationen
durchschaut"
"Believe little, scrutinise all, think by your own: How see through
manipulations"
ISBN-10: 386489218X
Re: Why would mutt be slow changing mbox when run over ssh?
El día martes, diciembre 31, 2019 a las 01:12:12p. m. +, Chris Green escribió: > I run mutt via an ssh connection, i.e. I connect from a terminal > window in my laptop (running xubuntu 19.04) to my desktop machine > (running xubuntu 19.10) using ssh and then run mutt. > > For some reason changing from one mbox to another is slow when I do > this, the ssh connection is fast, nothing else slows down and moving > around within the mbox is snappy enough, it's just closing one mbox > and opening the next that's slow. Doing exactly the same thing > directly in a terminal window on my desktop machine doesn't show the > same slowness. By 'slow' I mean a noticeable delay, probably of the > order of a second or two. I do the same often too and see no delay compared a local change or one in a SSH session. I'd run the remote mutt as: strace -o tr -tt mutt and check the file 'tr' (which will have time stamps) for the reason. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
Re: large IMAP mailboxes (OutLook)
El día martes, noviembre 12, 2019 a las 09:37:26p. m. +0100, Anders Damsgaard escribió: > * Matthias Apitz [2019-11-12 21:22:00 +0100]: > > >There is no caching of the mails in any database and update the cached > >information off-line. > > If you haven't already, try setting $header_cache and > $message_cachedir. According to the mutt manual, you are likely to > achieve the best performance if the cache variables point to directories > (you can also store cache in files). If using directories for the caching, > make sure they exist on the file system before launching mutt. You can > safely use the same dir for both. Thanks. You saved my day. I wasn't aware of this. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub "Glaube wenig, hinterfrage alles, denke selbst: Wie man Manipulationen durchschaut" "Believe little, scrutinise all, think by your own: How see through manipulations" ISBN-10: 386489218X
large IMAP mailboxes (OutLook)
Hello, I'm using mutt as well to read/answer mails in my company mail Exchange server using IMAP/SMTP. This works mostly fine and as expected. The only problem is my large INBOX there, some 2000 mails. On any start or connect to the INBOX, mutt fetches all headers to present the list. There is no caching of the mails in any database and update the cached information off-line. >From my Ubuntu smartphone I use Dekko as MUA and this has some daemon in the background and a database of the cached headers. I.e. its start is fast, while the start of mut takes 2-3 minutes fetching the header. Any ideas how to address this? matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub "Glaube wenig, hinterfrage alles, denke selbst: Wie man Manipulationen durchschaut" "Believe little, scrutinise all, think by your own: How see through manipulations" ISBN-10: 386489218X
Re: Creating HTML emails with mutt
El día lunes, octubre 28, 2019 a las 06:33:19p. m. -0400, José María Mateos escribió: > On Mon, Oct 28, 2019 at 11:11:31PM +0100, Matthias Apitz wrote: > >Well, do you speak for you or for a 'lot of people'? Who they are? > >I speak only for my own interests (as I said: I do not need this). > > Talking for myself, I really don't need point 1 (composing of HTML > messages), but number 2, opening links in an easy way, would be a nice > to have. I can always user urlview or send the HTML file to Firefox, but > any of these solutions is slower than simply being able to somehow tell > mutt "open URL #12 from this e-mail", and have that sent to the web > browser. So, run mutt in an unicode-rxvt terminal. It presents URLs underlined and click-able. I do so and sometimes I do hate it: you click into your terminal to get the focus to it, or even as an accident, and hit an URL and it jumps off to FF. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub 3. Oktober! Wir gratulieren! Der Berliner Fernsehturm wird 50 aus: https://www.jungewelt.de/2019/10-02/index.php
Re: Creating HTML emails with mutt
El día martes, octubre 29, 2019 a las 11:19:43a. m. +1300, martin f krafft escribió: > Regarding the following, written by "Matthias Apitz" on 2019-10-28 at 23:11 > Uhr +0100: > >Well, do you speak for you or for a 'lot of people'? Who they are? > >I speak only for my own interests (as I said: I do not need this). > > Matthias, any such feature would of course be optional, and probably > default to off for a long time, so you have nothing to worry about. I don't worry about this. I only do not like people expressing their own interests with a 'lot of people demand xyz'. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub 3. Oktober! Wir gratulieren! Der Berliner Fernsehturm wird 50 aus: https://www.jungewelt.de/2019/10-02/index.php
Re: Creating HTML emails with mutt
El día lunes, octubre 28, 2019 a las 04:50:40p. m. -0500, Derek Martin escribió:
> > FWIW, I (as a mutt user for 15++ years) do not need this. Thanks
>
> Perhaps not, but the fact that it keeps coming up here is pretty clear
> indication that it's a feature that would be useful to a lot of
> people...
Well, do you speak for you or for a 'lot of people'? Who they are?
I speak only for my own interests (as I said: I do not need this).
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
3. Oktober! Wir gratulieren! Der Berliner Fernsehturm wird 50
aus: https://www.jungewelt.de/2019/10-02/index.php
Re: Creating HTML emails with mutt
El día lunes, octubre 28, 2019 a las 03:59:01p. m. -0500, Derek Martin escribió: > FWIW, my two biggest wishlist items for Mutt are: > > 1. the ability to create and send at least simple HTML messages, with >or without multipart alternatives, specifically for basic text >formatting (bold, italics, color) and hypertext links. [It's >expected that an external HTML editor would need to be spawned to >generate the HTML. It makes sense to be able to specify a filter >to convert this to an alternative form for multipart.] > > 2. The ability to natively display a subset of HTML (the same subset) >with the ability to trigger links to open in a browser (or perhaps >execute an arbitrary configured command). Modern terminal windows >can handle all of the formatting required to do just this much... > FWIW, I (as a mutt user for 15++ years) do not need this. Thanks matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub 3. Oktober! Wir gratulieren! Der Berliner Fernsehturm wird 50 aus: https://www.jungewelt.de/2019/10-02/index.php signature.asc Description: PGP signature
Re: Really strange problem with evince PDF reader and .mutt directory
El día domingo, octubre 20, 2019 a las 09:25:46a. m. +0100, Nuno Silva escribió: > On 2019-10-19, José María Mateos wrote: > > > On Sat, 19 Oct 2019 19:17:06 +0100 Chris Green wrote: > >> Running 'evince ~/.mitt/fred.pdf' displays the PDF file successfully > >> but running 'evince ~/.mutt/fred.pdf' produces a Permission Denied > >> message in a pop-up window. All directory names I have tried other > >> than .mutt allow the PDF file to be read. I can't reproduce this on FreeBSD. The OP could run on any Linux (don't know if the problem is on Linux): strace -o evince.tr -f evince ~/.mutt/fred.pdf and look into the file evince.tr which open(2) or stat(2) gives a Permission Denied and why. If the OP can't see this, he/she should post this file somewhere. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub 3. Oktober! Wir gratulieren! Der Berliner Fernsehturm wird 50 aus: https://www.jungewelt.de/2019/10-02/index.php
Re: Unsubscribing from mailing-list threads (was: Preferred way to get imap emails)
El día martes, julio 30, 2019 a las 06:36:35a. m. +0200, Francesco Ariis escribió: > On Tue, Jul 30, 2019 at 06:31:42AM +0200, Matthias Apitz wrote: > > > > I'm a mutt user for many years. From time to time I do miss a feature in > > mutt to mark a given thread as "do not present any mail of this thread > > anymore, just collapse them and mark for deletion on exit". > > > > This is such a thread I would mark as this. > > Maybe this link can be of interest > > http://ariis.it/static/articles/mutt-ml/page.html Thanks for this pointer. The doc describes exactly the problem. But, the proposed solution with a macro deleting threads which follow the rule (copied from the doc): "Threads with only replies means threads where the originating post isn’t present; if it is not present is because we deleted it; if we deleted it we didn’t like it and we don’t want replies to it, too." is not good. Sometimes (many times) I have saved the original post of a "good" thread in some place, for example into the mbox file ~/Mail/mutt and so the above pattern would touch/delete a "good" thread also as a "bad" one. A solution must be based on some kind of a local "database" file of threads marked as "bad" threads (perhaps as patterns) and one must actively store the given "bad" thread into it, for example with M and then a D would later, even in the next mutt session, read this "database" file and delete all threads from the actual mailbox for all patterns in it. I Cc'ed the author of the article: fa...@ariis.it Please keep him/her in Cc when you reply. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
Re: Preferred way to get imap emails
I'm a mutt user for many years. From time to time I do miss a feature in
mutt to mark a given thread as "do not present any mail of this thread
anymore, just collapse them and mark for deletion on exit".
This is such a thread I would mark as this.
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
May, 9: Спаси́бо освободители! Thank you very much, Russian liberators!
Re: Preferred way to get imap emails
El día sábado, julio 27, 2019 a las 08:58:20p. m. +0530, Pankaj Jangid escribió: > Hi, > > I have very recently switched back to mutt. My 1st question is - > is the preferred way to get imap emails in the mutt inbox. 12 years back > I used to fetch everything using fetchmail, using POP3. But now I have a > Gmail account and Gmail is mostly optimised for IMAP usage. IMAP works > flawlessly on mobile also. Back then we used POP3 because internet > bandwidth was a big issue. > > I read about offlineimap. Tried to use it on my machine. But it stops > fetching email when the system goes into sleep. Without restarting > offlineimap service it doesn't work. And lately it has started giving > errors also while fetching from Gmail. > > I tried to configure mutt with imap settings. It is functionally working > fine but each email is separately downloaded when I open it. I have > configured cache so it doesn't happen everytime with the same email. My > 2nd question is - is there a way to pre-fetch all the emails in inbox. I always use fetchmail and pass the mails locally through sendmail --> procmail --> SpamAssassin --> /var/mail/guru \-> /var/mail/spam to get the SPAM filtered out and to get all my mails to my FreeBSD laptop. I have *all* my mails since back to 1998 on my local storage. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub May, 9: Спаси́бо освободители! Thank you very much, Russian liberators!
Re: providing imap_pass but not from ~/.muttrc
El día Thursday, June 13, 2019 a las 03:19:26PM -0400, Ben Boeckel escribió: > > $ ssh -At www.unixarea.de imap_pass=abc bash --login > > Thu Jun 13 20:44:51 CEST 2019 > > ... > > sh4-5:~$ env | grep imap > > imap_pass=abc > > I don't think there's any mechanism in mutt. You might be able to have > `mutt -F <(genmuttrc)` dump it out. It may also be worth just doing `set > imap_pass=...` inside mutt once it has started. I think the best generic approach would be to be able to set in .muttrc something like set imap_pass=" > However, what's your threat model that having it in the file is not OK > but the environment is OK? `/proc/foo/environ` is just as readable on > Linux as muttrc is likely to be. Correct, but you need a bit more knowledge to read it from /proc/PID/... as just grepping/stealing the users home dir. > How are you getting your sendmail password over in order to send email? > Or is it trusted because it's coming from the ISP's VM? It's handed over by mutt to /usr/sbin/sendmail ... on the VM locally. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub May, 9: Спаси́бо освободители! Thank you very much, Russian liberators!
providing imap_pass but not from ~/.muttrc
I often use SSH to connect to my rented VM space of my ISP (which gets me to a Linux server) and I do use mutt from there to check my mails or even to answer, esp. when I do not have my FreeBSD netbook with full Internet and all mails up. I do not want to set 'imap_pass=...' and such values in the ~/.muttrc on this VM. Is there any other way to provide such credentials without to key them in on start of mutt, for example based on an environment variable which I could route to the VM through the SSH session like: $ ssh -At www.unixarea.de imap_pass=abc bash --login Thu Jun 13 20:44:51 CEST 2019 ... sh4-5:~$ env | grep imap imap_pass=abc Any other ideas? The SSH access is RSA based, i.e. without any password, and the private key comes from my OpenPGP card. Best solution would be to use this key as well for the IMAP authentication somehow. Thanks matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub May, 9: Спаси́бо освободители! Thank you very much, Russian liberators! signature.asc Description: PGP signature
GnuPG && mutt
Hello, I'm using GnuPG (with an OpenPGP smartcard) to sign my mails or decrypt mails if they have been encrypted with my pub key. For this I have in ~/.muttrc: set crypt_use_gpgme set crypt_autosign and all this is fine. Yesterday I got a mail which was encrypted with my pub key and after providing the PIN for my OpenPGP card it was decrypted and presented fine in clear text. In the moment of reply it is asking me Enter keyID for u...@bin.org.in and I did not know what to give. mutt says in the header on screen in this moment: Security: Sign, Encrypt (PGP/MIME) Perhaps this was caused by a block in the incoming mail of: Openpgp: preference=signencrypt Autocrypt: addr=u...@bin.org.in; prefer-encrypt=mutual; keydata= mQENBE6aDi0BCACsJrzLOje6TsYzkk89ttxhWffsB/2AnfB8NO+lM25o3HqmTBi2swxVzEQL Dcn/on+HPg9pNl0Srxao7POXwo2TVyO/r5A2ZPn9fGue5z87NqR3HMW6HPnU3HpBNdqZyz40 OFZXe9kCIkBS7RarQUznp2DHtvghFGXZVbKi9X5t6EnQVlIFcj9ESPE9pajf+QwytgCdMqN7 ... How I should handle this exactly with mutt 1.11.1 ? Thanks matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub May, 9: Спаси́бо освободители! Thank you very much, Russian liberators! signature.asc Description: PGP signature
Re: delete-thread key combination?
El día Thursday, May 23, 2019 a las 08:16:31AM +0200, Wim escribió: > Hi Jude, > > On Thursday, 23 May at 00:27, Jude DaShiell wrote: > > > that's listed as ^D. Does that convention translate to shift-6 then type > > upper-case D? > > > > That means one's got to press the 'Esc' and the 'd' keys at the same > time. Isn't this Ctrl+D at the same time? At least this is what I use to delete full threads without reading them. Btw: When I compare mutt with the MUA app on my Ubuntu phone (Dekko), this deletion of full threads is what I most miss in this MUA, esp. if one is subscribed to a lot of technical mailing lists and often it happens that a thread is of no interest or one can't say anything in this for help. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub May, 9: Спаси́бо освободители! Thank you very much, Russian liberators!
Re: Copying text from Mutt viewer also copies trailing space
On Fri, 18 Jan 2019 12:02:36 +0100, Vegard Svanberg wrote: > * m...@raf.org [2019-01-02 05:37]: > >> > > When I copy text from Mutt into whatever else (vim, text >> editor, browser >> > > textarea... doesn't matter), the paste includes the (trailing) spaces >> > > (\s) from column 80-120, so I have to manually remove them. >> >> for me it happens when mutt is in tmux or screen in xterm, >> pasting into gvim. > [snip] > > Thanks for the useful feedback! I use gnome-terminal at the moment so I > don't have that option, however hunting around the web with my > Go(o)g(g)les on, I found this: > > https://mutt-users.mutt.narkive.com/Qw2cfXkS/mutt-gnome-terminal-and-whitespace-fill-issue > > So seems this has been discussed before and that it has to do with the > way Mutt sets the background colour, or something like that. > > There was a suggestion in there to #undef HAVE_BKGDSET in config.h, but > that didn't make any difference for me. There was also a reference to > the ol' trac at dev.mutt.org, but that site isn't online anymore. > > Anyway, will keep hunting - at least this thread confirms I'm not alone. :) +1 (me too) btw: the URL gives error HTTP 500 matthias -- Sent using Dekko from my Ubuntu device http://www.unixarea.de/+49 176 38902045
Re: SMTP error from remote mail server after RCPT TO:
El día viernes, octubre 26, 2018 a las 03:47:03p. m. -0500, Hokan escribió: > This rejection is the result of the "percent hack" implimented on > sendmail, postfix and, perhaps, other mail servers. > > Nothing to do with Mutt. Yes, it's a bit off-topic. And, thanks for the pointer to that "percent hack" I will look for its explanation. Interestingly the mail is accepted and delivered when I send to jW-Leserini Verteil Thanks again matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub October, 7 -- The GDR was different: Peace instead of Bundeswehr and wars, Druschba instead of Nazis, to live instead of to survive. signature.asc Description: PGP signature
SMTP error from remote mail server after RCPT TO:
Hello, This is perhaps not a problem with mutt itself, but maybe some expert can lend me a light. I'm member of a group and as this I do receive mails sent by others to the addr jw%leserini-...@gmx.de. But when I reply, the mail gets rejected, see below. How is this possible that the originator can send this mail to jw%leserini-...@gmx.de but I can not? Thanks matthias - Forwarded message from Mail Delivery System - Date: Fri, 26 Oct 2018 14:51:58 +0200 From: Mail Delivery System To: g...@unixarea.de Subject: Mail delivery failed: returning message to sender This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: jw%leserini-...@gmx.de host 172.16.28.206 [172.16.28.206] SMTP error from remote mail server after RCPT TO:: 550 restricted characters in address Reporting-MTA: dns; sh4-5.1blu.de Action: failed Final-Recipient: rfc822;jw%leserini-...@gmx.de Status: 5.0.0 Remote-MTA: dns; 172.16.28.206 Diagnostic-Code: smtp; 550 restricted characters in address Date: Fri, 26 Oct 2018 14:51:57 +0200 From: Matthias Apitz To: ... Cc: jw%leserini-...@gmx.de Subject: Re: Literaturmesse Nürnberg Hallo, wie ist denn die Rückfahrt geplant. Wir können doch nur alle zusammen mit dem Bayernticket fahren... Gruss matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub October, 7 -- The GDR was different: Peace instead of Bundeswehr and wars, Druschba instead of Nazis, to live instead of to survive. - End forwarded message - -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub October, 7 -- The GDR was different: Peace instead of Bundeswehr and wars, Druschba instead of Nazis, to live instead of to survive. signature.asc Description: PGP signature
Re: Firefox throw can't find temp file error
On Monday, 13 August 2018 18:59:38 CEST, David Woodfall wrote: On Monday 13 August 2018 13:46, Matthias Apitz put forth the proposition: El día Monday, August 13, 2018 a las 12:34:08PM +0100, David Woodfall escribió: ... > PS: > > Do you have your key on a keyserver somewhere? I got a huge 30 sec > delay opening this because I only have keys.gnupg.net set as > keyserver. Not sure if there more popular ones these days? Dave, do you verify gnuPG keys/signs on the fly? Is this secure? Thx Mutt does it automatically. I don't know why it wouldn't be secure. Well, verifying the identity of an unknown person with some server over the Inrernet is not very reliable, isn't it? -- Sent from my Ubuntu phone http://www.unixarea.de/
Re: Firefox throw can't find temp file error
El día Monday, August 13, 2018 a las 12:34:08PM +0100, David Woodfall escribió:
...
> PS:
>
> Do you have your key on a keyserver somewhere? I got a huge 30 sec
> delay opening this because I only have keys.gnupg.net set as
> keyserver. Not sure if there more popular ones these days?
Dave, do you verify gnuPG keys/signs on the fly? Is this secure?
Thx
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/ 📱
+49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
13. August 2018: Manchmal möchte ich nun einen AUSREISEANTRAG stellen.
August 13, 2018: Sometimes I'd like to ask for an exit permission now.
Re: brow.sh terminal html rendering integration?
El día Tuesday, July 10, 2018 a las 12:12:44PM +, Georg Faerber escribió: > On 18-07-10 12:34:13, Matthias Apitz wrote: > > El día Tuesday, July 10, 2018 a las 01:04:15PM +0300, Leho Kraav escribió: > > > Hi all. Discovered https://www.brow.sh today via GitHub trending > > > repos newsletter. > > > > > > Has anybody here tried integrating it w/ mutt? How would we go about > > > it? > > > > Nowadays I would never click on such URL which looks more like a > > phishing attack. If it is not, please provide, for example, the GitHub > > URL. > > Here you go: https://github.com/browsh-org/browsh I cloned the git and is seems not be straight forward to compile an own version. As well it needs internally FF 57++. And, ofc, I'd never use a binary blob for it. matthias -- Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/ 📱 +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
Re: brow.sh terminal html rendering integration?
El día Tuesday, July 10, 2018 a las 01:04:15PM +0300, Leho Kraav escribió: > Hi all. Discovered https://www.brow.sh today via GitHub trending repos > newsletter. > > Has anybody here tried integrating it w/ mutt? How would we go about it? Nowadays I would never click on such URL which looks more like a phishing attack. If it is not, please provide, for example, the GitHub URL. matthias -- Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/ 📱 +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
Re: Disable reply quote
On Thursday, 5 July 2018 08:21:52 CEST, Stefan Hagen wrote: Hi Wim Wim wrote: On Wednesday, 04 July at 10:12, Stefan Hagen wrote: Is there a way to turn off the quote string for replies like forward_quote=no does for forwards? I'm curious: Why do you want to turn it off? matthias -- Sent from my Ubuntu phone http://www.unixarea.de/
Re: Bottom posting v top posting
El día martes, mayo 15, 2018 a las 08:35:50a. m. +0200, Martin Trautmann escribió: > > > Am 14. Mai 2018 18:21:09 MESZ schrieb Ben Oliver : > >This is a cool idea. I use K9 which has decent threading support. > >Mainly > >for reading rather than sending though. > > Could you send me a screenshot please? I also do use k9, but I only do see a > grouping by subject. It lacks a hierarchical tree view. > > Ssh for mutt is an interesting idea, although I have no clue how I would use > vi on a smartphone for composing a reply > . I have as smartphone a BQ E4.5 which comes with an Ubuntu Linux. The normal GUI MUA is Dekko, but I have ported mutt to the device and can read/write and send e-mail written with vim. Anybody wants some screen? matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub May, 9: Спаси́бо освободители! Thank you very much, Russian liberators! signature.asc Description: PGP signature
Re: Mail-Followup-To (was Re: breaking long header lines into 2 (or more) lines)
El día jueves, abril 26, 2018 a las 05:28:55p. m. -0500, Derek Martin escribió: > On Wed, Apr 25, 2018 at 07:31:20PM +0200, Matthias Apitz wrote: > > $ grep -i Mail-Followup-To ~/.muttrc > > $ > > > > as I said, I do not set any Mail-Followup-To; and I think Reply-To: > > and From: is quite normal; > > Reply-To should normally not be set; its purpose is to route mail to > the proper address where you will receive it, in the event that your > ... Hmm, someone set Reply-To in the headers of your mail too. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
Re: Mail-Followup-To (was Re: breaking long header lines into 2 (or more) lines)
El día Wednesday, April 25, 2018 a las 08:23:37PM -0400, Patrick Shanahan escribió: > you might want to reconsider. you said *you* didn't make the setting, > that "mutt" was to blame. there really is no "blame". one must make the > settings to do what they wish and you didn't bother and now try to divert > the responsibility. Wrong. There a good and bad defaults. And the default for follow_up policy is just bad because it does, as you see in my case, things that the user newer wanted and not even was aware of. > make the correct settings and you will get what you wish. > > btw, it is not corrected yet. I know. But I have not had time to think what exactly I will change. matthias -- Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/ 📱 +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
Re: Mail-Followup-To (was Re: breaking long header lines into 2 (or more) lines)
I'm tired of such blames. I'm using mutt for more then 15 years, IIRC. And of course every day you learn something new or something I did wrong. But what you send is not help, but just blames. Thanks matthias -- Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/ 📱 +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
Re: Mail-Followup-To (was Re: breaking long header lines into 2 (or more) lines)
El día miércoles, abril 25, 2018 a las 04:14:52p. m. -0400, Patrick Shanahan escribió: > > Who adds this? mutt by its own? If so, based on what? > > > you do, don't you have man pages for mutt and muttrc? mutt doesn't do > anything except what *you* tell it to. no, mutt does it by its own because the default of 'followup_to' is yes; IMHO it should be changed to 'no'. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
Re: Mail-Followup-To (was Re: breaking long header lines into 2 (or more) lines)
El día miércoles, abril 25, 2018 a las 08:56:26p. m. +0200, Matthias Apitz
escribió:
> El día miércoles, abril 25, 2018 a las 02:46:06p. m. -0400, Patrick Shanahan
> escribió:
>
> > then you have someone in your system makeing changes to your posts,
>
> the 'system' is a FreeBSD netbook using mutt+sendmail;
>
> I will Cc me on this mail to see its sent headers;
The outgoing mails contains a header line:
Mail-Followup-To: Matthias Apitz , mutt-users@mutt.org
Who adds this? mutt by its own? If so, based on what?
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
Re: Mail-Followup-To (was Re: breaking long header lines into 2 (or more) lines)
El día miércoles, abril 25, 2018 a las 02:46:06p. m. -0400, Patrick Shanahan escribió: > then you have someone in your system makeing changes to your posts, the 'system' is a FreeBSD netbook using mutt+sendmail; I will Cc me on this mail to see its sent headers; matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
Re: Mail-Followup-To (was Re: breaking long header lines into 2 (or more) lines)
El día Wednesday, April 25, 2018 a las 10:24:45AM -0700, Will Yardley escribió: > On Wed, Apr 25, 2018 at 09:28:02AM -0700, Kevin J. McCarthy wrote: > > On Wed, Apr 25, 2018 at 05:56:43PM +0200, Matthias Apitz wrote: > > > On Wednesday, 25 April 2018 17:17:54 CEST, Patrick Shanahan > > > > which he did and does regularily: > > > > "Mail-Followup-To: Matthias Apitz , > > > > mutt-users@mutt.org" > > > > > > I do not set this in my mutt. > > > > Try adding mutt-users to your 'subscribe' lists, instead of 'lists'. > > Kind of thread drift, but I actually wonder if Mutt shouldn't move away > from Mail-Followup-To, as it never became a standard, and is not really > adopted by (m)any other commonly used mail clients. > > w > $ grep mutt-users ~/.muttrc send-hook mutt-users@mutt.org 'my_hdr From: Matthias Apitz ' send-hook mutt-users@mutt.org 'my_hdr Reply-To: Matthias Apitz ' lists asterisk-us...@lists.digium.com biblio-progresis...@yahoogrupos.com.mx b...@berklix.org commun...@lists.openmoko.org digikam-us...@kde.org ekiga-devel-l...@gnome.org ekiga-l...@gnome.org enlightenment-us...@lists.sourceforge.net fgcuba-muc-inter...@listen.einewelthaus.de freebsd-...@freebsd.org freebsd-curr...@freebsd.org freebsd-hack...@freebsd.org freebsd-i...@freebsd.org freebsd-j...@freebsd.org freebsd-mob...@freebsd.org freebsd-multime...@freebsd.org freebsd-...@freebsd.org freebsd-po...@freebsd.org freebsd-questi...@freebsd.org freebsd-...@freebsd.org free...@es.freebsd.org gnomemeeting-l...@gnome.org gphoto-u...@lists.sourceforge.net gpsd-us...@lists.berlios.de kde-free...@freebsd.kde.org kde-free...@kde.org l-chix...@glove.org.ve linu...@listas.softwarelibre.cu evolution-l...@gnome.org local-openmoko-sp...@projects.openmoko.org mplayer-us...@mplayerhq.hu mutt-users@mutt.org openmoko-ker...@lists.openmoko.org ubuntu-ph...@lists.launchpad.net betatesters-m10_ubu...@bq.com chromium-os-disc...@chromium.org x...@freebsd.org gnupg-us...@gnupg.org $ grep -i Mail-Followup-To ~/.muttrc $ as I said, I do not set any Mail-Followup-To; and I think Reply-To: and From: is quite normal; matthias -- Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/ 📱 +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
Re: breaking long header lines into 2 (or more) lines
On Wednesday, 25 April 2018 17:17:54 CEST, Patrick Shanahan wrote: * Ian Zimmerman [04-25-18 10:42]: On 2018-04-25 08:10, Matthias Apitz wrote: > > Please don't Cc: me privately on mailing lists and Usenet, if you > > also post the followup to the list or newsgroup. To reply privately > > _only_ on Usenet and on broken lists which rewrite From, fetch the > > TXT record for no-use.mooo.com. > > Hmmm? You Cc'ed me :-) Sorry about that, but it is because the list is of the munging variety (namely, it adds a Reply-To header). I refuse to spend energy compensating for that borkage. Unless you did that yourself, of course - but I'm giving you the benefit of the doubt ;-) which he did and does regularily: "Mail-Followup-To: Matthias Apitz , mutt-users@mutt.org" I do not set this in my mutt. mstthias -- Sent from my Ubuntu phone http://www.unixarea.de/
Re: breaking long header lines into 2 (or more) lines
El día martes, abril 24, 2018 a las 10:45:11p. m. -0700, Ian Zimmerman escribió: > That is odd, it shouldn't work. According to the RFC cited elsewhere in > thread. > > -- > Please don't Cc: me privately on mailing lists and Usenet, > if you also post the followup to the list or newsgroup. > To reply privately _only_ on Usenet and on broken lists > which rewrite From, fetch the TXT record for no-use.mooo.com. Hmmm? You Cc'ed me :-) matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub signature.asc Description: PGP signature
breaking long header lines into 2 (or more) lines
Hello, Long header lines can be split into 2 or more lines and the 2nd line must start with a blank (is TAB allowed too). Is there any rule (RFC) at which char the split is allowed or not allowed? For example, can mail addr lines be broken at any point like this one: To: mutt-users@mut t.org I did tests before asking and such a case like the one with mutt-users@mutt.org above is arriving fine and the line is put together somewhere in the MTA chain. Thanks for any pointer? matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub signature.asc Description: PGP signature
Re: choices on reading HTML emails
El día martes, abril 10, 2018 a las 03:57:53p. m. +0800, Yubin Ruan escribió:
> Hi,
>
> Can anyone share some approaches for reading HTML emails.
I do use what you can see in my header line 'X-message-flag:'
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
signature.asc
Description: PGP signature
Re: html signature?
El día Wednesday, March 07, 2018 a las 08:46:31PM +, Grant Edwards escribió: > >> Do you discard multipart/alternative where there's both text/plain and > >> text/html? That's what I'm leaning towards in the general case. > >> > >> I read this list using slrn via an NNTP server, so that's strictly > >> plain text. > >> > > > > In case of real text/plain part (and not only 'click here to read this > > mail' or other suggestions the like) I do. > > It seems a bit sever to discard emails that include both text/plain > and text/html alternatives. But it's your inbox, do as you please. Sorry, I meant: In case of real text/plain part (and not only 'click here to read this mail' or other suggestions the like) I do READ them. matthias -- Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/ 📱 +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
Re: html signature?
On Wednesday, 7 March 2018 20:13:52 CET, Grant Edwards wrote: On 2018-03-07, Matthias Apitz wrote: I'm used to receive my mails via fetchmail+procmail+mutt and mails in HTML are in best case silently ignored or end up in SPAM folders. You have been adviced. :-) Do you discard multipart/alternative where there's both text/plain and text/html? That's what I'm leaning towards in the general case. I read this list using slrn via an NNTP server, so that's strictly plain text. In case of real text/plain part (and not only 'click here to read this mail' or other suggestions the like) I do. matthias -- Sent from my Ubuntu phone http://www.unixarea.de/
Re: html signature?
On Wednesday, 7 March 2018 19:37:39 CET, Scott Kostyshak wrote: On Tue, Mar 06, 2018 at 08:06:12PM +, Grant Edwards wrote: I've noticed that the handling of text/plain by popular GUI MUAs has gotten so bad in past few years, that I'm now reluctant to send mail in that format. I'm used to receive my mails via fetchmail+procmail+mutt and mails in HTML are in best case silently ignored or end up in SPAM folders. You have been adviced. :-) matthias -- Sent from my Ubuntu phone http://www.unixarea.de/
Re: Remove Subject prefixing (when answering/forwarding) possible?
El día Wednesday, February 28, 2018 a las 10:00:29AM -0800, Kevin J. McCarthy escribió: > Looks like the example might be wrong in the manual, unless there are > regexp library differences. Because ']' is first in the character > class (after the negation), it shouldn't need to be escaped. This works > for me: > subjectrx '\[[^]]*\]:? *' '%L%R' > > If that works for you all, I'll fix up the manual example. The man page for muttrc should be checked/fixed to. On 1.8.0 I saw no hint about 'subjectrx'. Thanks matthias -- Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/ 📱 +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
Re: Remove Subject prefixing (when answering/forwarding) possible?
El día Tuesday, February 27, 2018 a las 10:39:53AM +0100, Ralf Hildebrandt escribió: > I'm using: > > # Erase [ext] tags from e-mails > subjectrx '\[ext\] *' '%L%R' > > to remove the tag "optically". Is there any way of removing the > Subject: prefix when answering/forwarding? How do you configure this exactly in .muttrc? Thanks matthias -- Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/ 📱 +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
