Re: Question about message id
On Sun, Apr 07, 2024 at 09:23:07AM -0600, Charles Cazabon via Mutt-users wrote:
> Ебрашка wrote:
> > my mails have Message-ID: . Question, what
> > should I write in .muttrc to make my outgoing mails have the same beautiful
> > message-ID as Yandex mail?
>
> My first question would be, why do you care what the Message-ID: field
> contents look like? Virtually no-one will ever look at it.
Yes, this here is fully true )))
>
> > For example Message-Id: <43265...@example.com> consisting of random
> > digits and domain name
>
> There's a good reason for that; it help to ensure uniqueness, which prevents
> problems with threading. By limiting itself to only digits, Yandex's IDs are
> much more likely to collide.
Hm, not sure about that... Given that string is long enough,
random string which consists only out of digits can perhaps
compete with (much shorter) random string of alpha-numeric
characters - in terms of uniqueness probability?
>
> If you absolutely must do this, have a look at the `message_id_format`
> variable.
Good hint ))) Attached is the example (perl) script, which can be used
as:
set message_id_format = "$HOME/bin/mutt_message_id_format_filter '<%z@%f>'|"
This converts "left_part" provided by Mutt %z part of Message-ID
code (ZhJUjJRaE9InvXxm in your example above), into (much longer)
string of only digits (592493855977705398853375435077558962105453
for same example).
String of digits is 1:1 mapping of each byte code of every next
symbol in the source string, used in the triples with some
padding by spaces. Every tripple generates decimal number. All
numbers are put after each other into long result.
Code is certainly ugly but seems to work.
Cheers, Anton
#!/usr/bin/perl -w
use 5.010;
use strict;
my $val = $ARGV[0];
my $debug = 0;
if (! ($val =~ m/^<([^@]+)@([^>]+)>/)) {
print $val; # message format is not recognized
exit 0;
}
my $logfile = undef;
if ($debug) {
my $log_fname = "/tmp/mutt_message_id_format_filter.log";
open ($logfile, ">>", $log_fname)
or die ("Cannot open [$log_fname] for write: $!");
}
my $left_part = $1;
my $host_n_domain = $2;
#abc
print $logfile "left_part = $left_part; host_n_domain = $host_n_domain\n"
if ($debug);
my $new_left_part = "";
while (length($left_part)) {
# extract 3 symbols, pad with blanks
my $bytes = sprintf("%3.3s", substr($left_part, 0, 3));
my $len = length($left_part);
$left_part = substr($left_part, $len >= 3 ? 3 : $len);
print $logfile " bytes = {" . $bytes . "}" if ($debug);
my $num = 0;
for my $i (0..2) {
$num *= 256;
$num += ord(substr($bytes, $i, 1));
}
print $logfile " num = {" . $num . "}\n" if ($debug);
$new_left_part .= $num;
}
print $logfile "\n" if ($debug);
print $logfile "<$new_left_part@" . $host_n_domain . ">" if ($debug);
print "<$new_left_part@" . $host_n_domain . ">";
print $logfile "\n" if ($debug);
Re: pdf attachments opened in external viewer
On Tue, Aug 15, 2023 at 06:03:22AM +0200, Fourhundred Thecat wrote:
> Hello,
>
> somehow, I got it working, that pdf attachments are opened in external
> viewer (evince). That is very nice.
>
> But, mutt waits for evince to close, before I can continue working in mutt.
>
> This prevents me from opening multiple pdf attachments and leave them
> open, while continue working in mutt.
>
> I guess, I would have to add '&' somewhere, so that evince is opened in
> background ?
>
> But where?
WARNING: solution posted below is experimental and overkill )))
Just to open PDF in mutt is possible to be done much easier!
But for me defined custom macro "v" in the attach menu working fine
in .muttrc:
macro attach v |show-on-host
This pipes the full attachment to the stdin of custom command
"show-on-host". This in turn call another custom command "wmexpl".
This constellation has some history in my configuration and
differentiate if something uses the STDIN and another is taking the
existing filename as argument. I do not use embedded detection of
the file type, done by mutt, and call from my "wmexpl" script
"file" utility, because i like to start the files from command line
outside mutt using the same way/scripts. Just to open PDF in mutt
is possible to be done much easier! For me pdf's are normally
opened with "okular" via "kfmclient exec ..." on KDE. For your case
you would need to add support to open pdf-s via "evince" with
something like (untested):
#~
sub run_via_evince
{
my ($fname) = (@_);
system ('evince "' . $fname . '" &') == 0
or die "failed evince ...: $!";
}
and modify my PDF handler like this:
- $ALLOWED=1if ($FTYPE =~ /.*: PDF document, version [0-9.]+(
\(password protected\))?(, \d+ page\(?s\)?)?( \(zip deflate encoded\))?$/);
+ $handler=\_via_evince if ($FTYPE =~ /.*: PDF document, version [0-9.]+(
\(password protected\))?(, \d+ page\(?s\)?)?( \(zip deflate encoded\))?$/);
relevant lines from show-on-host:
#!/usr/bin/perl -w
use strict;
use 5.010;
my $tmp_base_fname = 'show-on-host' . "__guessMeByContent";
my $tmp_fname = "/tmp/$tmp_base_fname";
open (MYOUT, '>:raw', $tmp_fname) or die("cant open [$tmp_fname] for write:
$!");
while(<>) {
print MYOUT $_;
}
close MYOUT;
system ("cp", $tmp_fname, "/data/sonstiges");
system ("wmexpl", "/data/sonstiges/$tmp_base_fname");
relevant lines from wmexpl:
#!/usr/bin/perl -w
use strict;
use 5.010;
#~
sub run_via_kfmclient
{
my ($fname) = (@_);
dbg("[run_via_kfmclient]: [$fname]");
system('kfmclient exec "' . $fname . '"') == 0
or die "failed to kfmclient exec ...: $!";
}
#~
sub run_via_oo
{
my ($fname) = (@_);
system ('ooffice "' . $fname . '" &') == 0
or die "failed ooffice ...: $!";
}
#~
sub guess_handler
{
my ($FNAME_CMDLINE) = (@_);
my $FTYPE = `file "$FNAME_CMDLINE"`;
dbg ("FTYPE=$FTYPE");
my $ALLOWED = 0;
my $handler = undef;
$ALLOWED=1if ($FTYPE =~ /.*: PDF document, version [0-9.]+(
\(password protected\))?(, \d+ page\(?s\)?)?( \(zip deflate encoded\))?$/);
$handler=\_via_oo if ($FTYPE =~ /.*: Microsoft Word [0-9+]+$/);
$handler=\_via_oo if ($FTYPE =~ /.*: Microsoft OOXML$/);
$ALLOWED=1if ($FTYPE =~ /[^:]+: JPEG image data,/);
$ALLOWED=1if ($FTYPE =~ /[^:]+: PNG image data,/);
#HTML document, ASCII text, with very long lines (559)
$ALLOWED=1if ($FTYPE =~ /[^:]+: HTML document(, ASCII text)?(,(
UTF-8)? Unicode text)?(, with very long lines( \(\d+\))?)?(, UTF-8 text)?$/); #
too restrictive?
$handler=\_via_oo if ($FTYPE =~ /[^:]+: Microsoft Excel [0-9+]+$/);
$handler=\_via_oo if ($FTYPE =~ /[^:]+: OpenDocument Spreadsheet$/);
$handler=\_via_oo if ($FTYPE =~ /[^:]+: Microsoft PowerPoint [0-9+]+$/);
$ALLOWED=1if ($FTYPE =~ /[^:]+: PostScript document text
conforming DSC level 3.0$/);
if ($ALLOWED && !defined($handler)) {
$handler = \_via_kfmclient;
}
return ( $handler, $FTYPE );
}
sub unix_wmexpl
{
my ($FNAME_CMDLINE) = (@_);
my ($handler,$ftype) = _handler($FNAME_CMDLINE);
if (defined($handler))
{
&{$handler}($FNAME_CMDLINE);
}
else
{
die "handler is not defined";
}
}
$FNAME_CMDLINE = $ARGV[0]//".";
_wmexpl($FNAME_CMDLINE);
With best regards, Anton
Re: Newbie help for an imap gmailg connection
Hi, Dan,
On Tue, Apr 11, 2023 at 01:36:08PM -0400, Dan Dunfee wrote:
> [...]
> I want to connect using imap with an gmail account which I hear requires
> some additional security steps these days.
> [...]
For me gmail with mutt via imap to read and smtp to send works fine.
Some time ago i created "app password" via gmail web interface and it
works just perfect since approximately 6 months that way.
>
> Has anyone info/experience about such a mutt imap gamil connection
> possibility?
>
here is relevant snippet from my .muttrc:
# Smtp settings for gmail sending {
set smtp_url = "smtps://anton.sharo...@smtp.gmail.com"
set smtp_pass = "my_very_secret_app_password"
# }
# gmail imap specific {
set ssl_starttls=yes
set ssl_force_tls=yes
set imap_user = "anton.sharo...@gmail.com"
set imap_pass = "my_very_secret_app_password"
set spoolfile = imaps://imap.gmail.com/bSpool
# gmail imap specific }
i have configured via gmail web interface a filter to assign a label
"bSpool" to every incoming mail. That way, working with them in mutt
allows me to just delete messages, which i read, via mutt - and gmail
removes the label "bSpool" from them as a result. At the same time all
messages are still kept on server labeled potenially somehow differently
(my labels were configured long ago before i started to use mutt, and i
like to keep all messages in my gmail box anyway to access them from
other devices).
i saw as well recommendation to use:
set spoolfile = imaps://imap.gmail.com/INBOX
and suspect it will really delete messages from gmail server if you
delete them from within mutt - but it was never my goal and i never
tested such possibility.
Hope that helps, Anton
Re: Two questions regarding header display
> > raf schrieb am Di., 7. Juni 2022, 01:57: > > > > > TERM=screen. > > > > > > It's OK. screen is more important to me than bold > > > headers. > > > > > > On Wed, Jun 08, 2022 at 12:23:07AM +0200, Anton Sharonov > wrote: > > > ... Gnu screen definitely supports bold if running on > > xterm... > > ...not configured in mutt yet by > > now... Reply was from handheld. Now more precise: headers in compose menu, current message in index, status line and top bar in index - all are displayed bold for me. > > TERM value is screen-bce for me. It has to be supported by > > corresponding terminfo entry. That was wrong info: only TERM=xterm-256color works for me. Any other TERM value lead to no bold, not even simple colors are displayed in mutt (via gnu-screen or directly in xterm). > > There is a bunch of color related settings in > > .screenrc on my end as well. Even italic works in xterm+gnu screen but for > > italic you would need to compile not yet released dev version of gnu screen > > (last time checked in 2021, may be they even released since then already) gnu-screen has italic support (which can be seen in vim for example when edit markdown file with syntax enabled) at least in version compiled from https://git.savannah.gnu.org/git/screen.git master (pre 5.0 branch?), f0d6154b95075f1e1198cd1fd12f7516cca57add (Date: Mon Apr 27 18:24:37 2020 +0200). Still no 5.0 tag in git. Most recent v4.9.0 version branch has _lot_ of commits which are not on master at all, may be meanwhile has even italic support merged in. On Wed, Jun 08, 2022 at 11:18:22AM +1000, raf wrote: > > Thanks. It'll probably work if I just switch from "mono" > directives to "color" directives and tell it to use bold > and default colours. Yep, that did it: > > color header bold default default ^(Subject|From|To|Cc|Date): > > cheers, > raf > Everything with "bold" on my end: color header bold color25 color252 "^(Date:|To:|From:|CC:)" color header bold color133 color252 "^Subject:" color indicator bold color16 color153 color status bold color16 color153 cheers, Anton
Take over existing attachments as "Attach: " pseudo-headers
Hi all, Using long time $edit_headers option, just discovered lovely "Attach: " pseudo header, which makes it easy to specify new attachments during message body edit. However it works just one-way - once editor is finished, those pseudo-headers are processed somehow and added to "official" attachment list maintained inside compose menu. Subsequent call of editor from compose menu is made without any "Attach: " pseudo-headers (even though compose menu keeps track of attachments already specified between editor calls). Just curious: is there a way to somehow feed editor with attachments, known on the level of compose menu so far, which would map to set of such "Attach: " pseudo headers during message edit? (did not found any appropriate setting in mutt documentation so far). cheers, Anton
Re: Two questions regarding header display
raf schrieb am Di., 7. Juni 2022, 01:57: > TERM=screen. > > It's OK. screen is more important to me than bold > headers. > Don't give up. Gnu screen definitely supports bold if running on xterm, i see it all the time - in my vim at least, not configured in mutt yet by now. TERM value is screen-bce for me. It has to be supported by corresponding terminfo entry. There is a bunch of color related settings in .screenrc on my end as well. Even italic works in xterm+gnu screen but for italic you would need to compile not yet released dev version of gnu screen (last time checked in 2021, may be they even released since then already) Cheers, Anton
Re: Two questions regarding header display
raf schrieb am So., 5. Juni 2022, 07:52:
> On Sun, Jun 05, 2022 at 12:06:52AM -0400, Jason Franklin
> wrote:
>
> > Greetings:
> >
> > I have two questions regarding header display...
> >
> > First, can the pager display header names in bold if the terminal
> > supports it?
> >
> > Second some senders have weird capitalization of headers. Is it possible
> > to display some canonical representation of any given standard header?
> >
> > To clarify, if the header is sent as "reply-to", I would like to always
> > see "Reply-To" in the pager.
> >
> > Thanks!
> >
> > --
> > Jason
>
> Hi, I don't know about the first part, but the second part
> could be done if procmail or similar is used for local
> delivery, and it passes incoming messages through a filter
> to "correct" the headers to your liking. But it might
> be a hassle if you aren't already using procmail.
>
Will usage of display_filter option with your perl script below not be
already sufficient solution even without procmail?
> ~/.procmailrc:
>
> :0 fw
> | /home/me/bin/fix-mail-headers-filter
>
> /home/me/bin/fix-mail-headers-filter:
>
> #!/usr/bin/env perl
> use warnings;
> use strict;
> # Modify headers if needed (e.g. "reply-to:" to "Reply-To:")
> while (<>)
> {
> # Skip to the following trivial loop after headers
> print, last if /^$/;
> # Replace lowercase at start of word before colon with uppercase
> s/^([^:]*)\b([a-z])/$1\U$2/ while /^[^:]*\b[a-z]/;
> print;
> }
> # Jut print the rest unchanged
> print while (<>);
>
> The above was barely tested. Don't use it without testing it on
> lots of existing mail (one message at a time - see formail(1))
> until you are sure that it works. And note that it doesn't
> convert any uppercase to lowercase, only the other way around.
>
> cheers,
> raf
>
>
